Background So my goal today is to try and give an argument for reducing the amount of shared code and limiting or eliminating the coupling of the systems with binary dependencies. The punchlines of this text are sall taken from the fantastic talk given by Ben Christensen titled “Don’t Build a Distributed Monolith” that can greatly help in putting some developers’ personal observations into context.
I’m talking about shared libraries and network clients.
Having taken Functional Programming with Scala presented by Martin Odersky, I have found the idea behind it rather difficult to understand and very amusing at the same time. Coming from an imperative world, everything looks quite bizarre at the moment. In the past few weeks, I kept wondering: What is the reason for this recent comeback of functional programming? May the history of great men who created our universe shed some light on my confusion…
After graduating about two years ago, I came to know more about the software industry and read about its all time high focus on processes and metrics as a way to ensure code quality. It is understandable, millions and billions of code has been and is being written. The software industry suffers from a miserable failure rate and there are millions of dollars at stake. Scrum seems to be the winner of the agile method wars.
Let’s face the truth, hard-core geeks can often have trouble in communicating their thoughts and ideas. Good software craftsman who can communicate effectively are indeed a rarity. You quickly observe this as soon as you start punching in code at your very first desk right after school. A “battle-worn veteran” such as Oracle’s Eric Lowe has written about this topic over and over. There is no China Wall between failed and successful projects, there is a thin line which is only defended by effective dissemination of key information amongst engineers.
This is the republished version of the great article written by Andriy Redko.
In today’s post we are going to unveil some very interesting (in my opinion) architecture styles: event sourcing and command query responsibility segregation (CQRS). Essentially, in both of them events are in the heart of the system design and reflect any changes of the state which are happening. It is quite different from the traditional CRUD architecture where usually only the last known state is kept, with any historical background effectively lost.
A couple of days ago I came across an article titled “Choose Boring Technology”. A few of my friends had shared this on Linkedin and since it was also referenced in some of the mailing lists I am a member of, I felt compelled to write up a response.
McKinley Paradigm of Boredom In his article, McKinley argues that a software engineer’s “function in a nutshell is to map business problems onto a solution space that involves choices of software” and argues that best tool for the job will inevitably lead to a mess.
Early in my career I landed on a project that was halfway through the launch. The project had been delayed a few times and higher management was getting increasingly agitated. Our sales team had lined up the ads and delays in an Advertising Based Revenue Model was simply intolerable. Engineering leads saw the salvation in cool technology so everything was cutting-edge. We sure had fun talking about advantages of Solr? Scalability of Cassandra and awesomeness of Zookeeper; too busy to try to fill the communication gap with the business team.
Every now and then a beautiful new language emerges and dies quickly lacking marketing and backing of the giants. While it’s very, very sad, learning a new language is not about the next “ big thing”. It’s about thinking in different ways outside of normal thought patterns.
This talk was organized not only in an attempt to discuss the importance of this challenge with colleagues, but also to introduce a fairly new jvm language and a paradigm quite different from imperative programming.