It's not relatively new. That “transaction file” thing in your database? Event Sourcing.
https://goodenoughsoftware.net/2012/03/02/case-studies/
> If you’re not looking at the public chain, you’re wasting your time
I disagree. Not having a single point of failure (one place that can get hacked) is valuable.
> From a trust perspective, it makes no difference if your banking cartel is writing to a Quorum, Hyperledger, or Kafka instance.
Of course it does. The protocol of blockchains makes them work with "proof of X". Appending to any event store, whether in Kafka or SQL does not require proof of anything.
> Blockchains are built for trust, databases for throughput. Event sourcing allows us to achieve a hybrid model with characteristics of both.
No, the reason blockchains can't have high throughpout / almost infinite horizontal scalability... is because there's a logic check. E.g. in bitcoin, you can't send more bitcoins than you have a balance. Event sourcing gives you the high throughpout if there's no logic checks across aggregates --- if there are, you won't have immediate consistency, and you have to be ready for compensating events.
I recommend two books, that cover event sourcing from a Domain Driven Design perspective. The consequences are similar.
https://www.amazon.co.uk/Domain-driven-Design-Tackling-Compl... https://www.amazon.co.uk/Implementing-Domain-Driven-Design-V...
-----------------
If that doesn't do it for you, please just remember the good old CAP theorem.
A Pattern Language, Alexander and Ishikawa and Silverstein http://amzn.to/2s9aSSc
Advanced Programming in the Unix Environment , Stevens http://amzn.to/2qPOMjN
Algorithmics: the Spirit of Computing, Harel http://amzn.to/2rW5FNS
Applied Crytography, Wiley http://amzn.to/2rsULxS
Clean Code, Martin http://amzn.to/2sIOWtQ
Clean Coder, Martin http://amzn.to/2rWgbEP
Code Complete, McConnel http://amzn.to/2qSUIwE
Code: The Hidden Language of Computer Hardware and Software, Petzold http://amzn.to/2rWfR9d
Coders at Work, Seibel http://amzn.to/2qPCasZ
Compilers: Principles, Techniques, & Tools, Aho http://amzn.to/2rCSUVA
Computer Systems: A Programmer's Perspective, O'Hallaron and Bryant http://amzn.to/2qPY5jH
Data Flow Analysis: Theory and Practice, Khedker http://amzn.to/2qTnSvr
Dependency Injection in .NET, Seemann http://amzn.to/2rCz0tV
Domain Driven Design, Evans http://amzn.to/2sIGM4N
Fundamentals of Wireless Communication, Tse and Viswanath http://amzn.to/2rCTmTM
Genetic Programming: An Intrduction, Banzhaf http://amzn.to/2s9sdut
Head First Design Patterns, O'Reilly http://amzn.to/2rCISUB
Implementing Domain-Driven Design, Vernon http://amzn.to/2qQ2G5u
Intrduction to Algorithms, CLRS http://amzn.to/2qXmSBU
Introduction to General Systems Thinking, Weinberg http://amzn.to/2qTuGJw
Joy of Clojure, Fogus and Houser http://amzn.to/2qPL4qr
Let over Lambda, Hoyte http://amzn.to/2rWljcp
Operating Systems: Design and Implementation, Tanenbaum http://amzn.to/2rKudsw
Parsing Techniques, Grune and Jacobs http://amzn.to/2rKNXfn
Peopleware: Productive Projects and Teams, DeMarco and Lister http://amzn.to/2qTu86F
Programming Pearls, Bentley http://amzn.to/2sIRPe9
Software Process Design: Out of the Tar Pit, McGraw-Hill http://amzn.to/2rVX0v0
Software Runaways, Glass http://amzn.to/2qT2mHn
Sorting and Searching, Knuth http://amzn.to/2qQ4NWQ
Structure and Interpretation of Computer Programs, Abelson and Sussman http://amzn.to/2qTflsk
The Art of Unit Testing, Manning http://amzn.to/2rsERDu
The Art of Unix Programming, ESR http://amzn.to/2sIAXUZ
The Design of Design: Essays from a Computer Scientist, Brooks http://amzn.to/2rsPjev
The Effective Engineer, Lau http://amzn.to/2s9fY0X
The Elements of Style, Strunk and White http://amzn.to/2svB3Qz
The Healthy Programmer, Kutner http://amzn.to/2qQ2MtQ
The Linux Programming Interface, Kerrisk http://amzn.to/2rsF8Xi
The Mythical Man-Month, Brooks http://amzn.to/2rt0dAR
The Practice of Programming, Kernighan and Pike http://amzn.to/2qTje0C
The Pragmatic Programmer, Hunt and Thomas http://amzn.to/2s9dlvS
The Psychology of Computer Programming, Weinberg http://amzn.to/2rsPypy
Transaction Processing: Concepts and Techniques, Gray and Reuter http://amzn.to/
Types and Programming Languages, Pierce http://amzn.to/2qT2d6G
Understanding MySQL Internals, Pachev http://amzn.to/2svXuFo
Working Effectively with Legacy Code, Feathers http://amzn.to/2sIr09R
Zen of graphics programming, Abrash http://amzn.to/2rKIW6Q
Apart from my family and some minor health issues, I currently am focused on 2 things: learning Luxembourgish/Luxembourgian and develop a deep understanding of functional programming.
About the former one: that should help me find a job in some Luxembourgish administration (I really wish I'll be able to find one soon).Luxembourg might be a small country, but I think it's managed well, CTIE (Luxembourgish administration that manages most of the IT infrastructure and software used by the state) has quite smart and competent people (also some dumb ones, but where's that not the case?), and I think I like the culture, which is almost my own, as I grew up close to Luxembourg and even went to a german-speaking school, while speaking family-native French (I'm as fluent speaking German as French, no accent).
Regarding the latter one, I started applying functional programming principles early this year, almost as obstinately as I can (and as much as possible using Java 8 then now 17) (I've got more than 16 years of professional experience using Java, both as a developer and software architect).
This was just the beginning of a more insightful journey into new coding practices, which result from one principle I discovered this year: source code should never lie. This became an evidence once I implemented and started to use my self-made "Maybe" type (a better Optional - Optional is quite weak if you want to avoid procedural programming). While using Maybe, it struck me that what I did was just explicitly forcing my code to say the truth. So I started to dig into types and have types represent various states (this may be seen as a better use of object orientation - this is not relevant, what's relevant is the improvement in the quality of my code). Using the multiple types (usually sub-classes) and combining with "fold" methods make a lot of if-else unnecessary and force the developer to handle each case: one can't just forget one case. What one may do is not handle a case, but it remains explicitly visible in the source code, with as much importance as the other cases. Then, the removal of the if-else usually means that the logic is much simpler to read and reason about. Using adequate types also means that only functions of the actual type are available, so we also reap the benefits of OO design. Also, while it is stated that Optional was not made to be serialized, I made my Maybe type so that it may be used in serialized objects and thus accurately reflect the state of affairs.
I'm still discovering FP patterns (for example, I still have to read about how to properly manage IO/side-effects/state. Once I've learned FP patterns, I'll focus on the synthesis of my knowledge of Java, DDD and FP in order to find out how to best apply FP and DDD principles to professional Java projectes, given the constraints of the language, it's modularity (Java 9 modules, Maven modules) and the JVM. I already have the intuition that the Spring framework (which is the de facto standard in Luxembourg businesses) might not be a good fit to serious FP programming - at least not without appropriate abstractions on top of it. This probably already starts with the dependency injection/inversion of control, which, I think (to be confirmed, though), does not make sense if a purely functional approach.
Regarding a Maybe type (I'm picky about naming - remember, code shouldn't lie): I firmly believe that Optional and Option are bad names for this type. As the user of an API/function that may return something or nothing, I don't get a choice about what I receive. Maybe I receive something, maybe I receive nothing. It's not like I receive some option from which to choose. As the one who implements the API, I have indeed the choice to provide something or nothing, so yes, I have some option, but what I'll return may be something or may be null. Thus I strongly recommend to stick with the name Maybe. Option/Optional is just lying to the user of the API/function.
It might just be an anecdote, my own, but I think that using lambdas and a few other FP principles with Java >= 8 for more than 9 months really opened doors in my mind about functional programming and types (way more than following Martin Oderski's FP courses on Coursera), to the point that I now really feel comfortable reading and understanding more advanced literature about FP, even stuff in Haskell. I'm not saying it's easy/simple. But if I focus, I think I'm now able to understand, which might not have been the case just last year. So Java provides, I think, a good enough environment to learn more than the rudiments of FP.
The most important lesson learned this year about programming is: source code must not lie. Replace nullable stuff with Maybe, when a Boolean may be null, don't just use a Boolean, but (for example) reimplement a NullableBool interface that has three types: TrueBool, FalseBool and UndefinedBool/NullBool. To represent two-valued booleans, I have Bool with subclasses TrueBool and FalseBool. Don't hesitate to use multi-valued booleans in cases where you have to represent probabilities (I, for example, have used a TetraValuedBool, which has the types False-Improbable-Probable-True). All these Bool types come with various static functions ('of()' to get/construct an instance) and non-static functions ('fold()'). To allow functions to return results that may represent anomalies, don't hesitate to use a Result type, which has two sub-types, one wrapping anomalies and one wrapping the actual legit result, and, again work with a "fold" function to handle both cases explicitly. Use strong types whenever possible, even if it's just some wrap around a String. Nothing is just a String.
This takes some time to implement, but once you have, it just makes your code easy to read and understand, nothing is hidden anymore: no implicit consequences. Once your code does not lie anymore, it becomes self-documenting, especially given FP is rather declarative (one does rather state what one wants than how to do it). This is rather cool, as you won't have to maintain separate documentation (at least not for developers).
Now, I'm not sure I recommend you do the same: my client will stop my contract by the end of this year because they don't understand the benefits of this higher code quality. They'd have preferred 'simple' procedural code, with which they believe I would have been able to deliver more features faster. Even my developer colleagues don't recognize the beauty of it. This, of course, is utter BS, because their problem is scope creep and they need to designate some responsible for being late. They just decided it's me. I'll be sacrificed on the altar of bad project management. I'm still making up my mind about defending myself and telling my point of view to their superiors: Luxembourg is small, it's not a place where one wants open conflicts, but at the same time, do I have to allow being made responsible for bad PM choices?
The intellectual challenge of combining FP, DDD and Java is absolutely great and quite huge. I couldn't do it just after-work (my wife and I are raising two little boys), because the deeper understanding of these needs regular, almost daily practice and reading about these topics. Doing this at work clearly made me vulnerable in a way I didn't see coming when I began this path, so I definitely can't recommend it to everyone. But I can't wait reaping the results of my deeper understanding of these topics, and I'm really happy to still be a programmer instead of doing some management (that is also an option - I have both experience and university degrees in engineering and in management), it's been a long time since I've had so many interesting intellectual opportunities.
Some references I used this year to improve my programming skills or just enjoyed reading (I consider these to be a good intro into FP and DDD):
- [0] Pragmatic Functional Java: https://dzone.com/articles/introduction-to-pragmatic-functio... ...
- [1] ...and it's related source code (cf. the "core" module), which I used as a reference (no direct dependency), in order to be able to make some changes: https://github.com/siy/pragmatica
- [2] Functional programming made easier: https://leanpub.com/fp-made-easier (that one is quite easy to ready)
- [3] https://dusted.codes/the-type-system-is-a-programmers-best-f... (posted a few days ago on HN)
- [4] https://fsharpforfunandprofit.com/ (I'd really like to do some project in F#)
- [5] https://www.cambridge.org/core/books/purely-functional-data-...
- [6] https://www.amazon.fr/Implementing-Domain-Driven-Design-Vaug...
- [7] https://www.amazon.com/Functional-Programming-Java-Harnessin...