I have recently stumbled on a couple posts from
Martin Fowler related to a
NoSQL Distilled joint book authoring effort. The book announcement excites me as I am looking forward to reading it for a several reasons. Primarily because I have been like a overindulged my inner geek this past year – playing and getting a taste of what I call modern persistence systems. Learning and thinking about
Brewer’s CAP theorem and its implications while setting up and trying a few things out with
Cassandra and
Hbase has been very fun to say the least. However, one thing has bothered me… what do we call this new era of persistence methods?
Today, I came across
another post from Fowler where he discussed the term “
NoSQL“, what it means in today’s persistence movements, and how he will be using it in his new book. This made me think about all the terms I have heard recently other than NoSQL. Here are a few others:
- Polyglot Persistence – Another term I learned from reading Flower’s Bliki at least six months ago or more.
- Big Data - Which is typically used to describe the problem of large data sets which cannot typically be accommodated by today’s traditional relational database systems due to cost, performance, and/or other operational concerns.
Another interesting discussion point, is the interest in other data store models some of which academic circles have previously explored. The recent interest, in my opinion is probably due to the changes in computers and networks since the time when the RDBMS became the preferred standard for data persistence many years ago. Ayende Rahien talks about this on a blog post. Some of different store models available (or in development) current NoSQL systems include:
There are many more discussions taking place in today challenging how we think about persistence. Even traditional physical persistence mechanism is in question. A few years ago the idea of using anything other than a hard disk or a SAN for persistent storage would have been absurd. However, a physically distributed in-memory non-relational database is a viable option (most likely this option will be geographically distributed). Other topics of discussion include:
- Clustering techniques
- Distributed systems
Truth is I don’t know what to call this current persistence movement. To me it seems obvious that terms like “NoSQL”, “Big data”, and even “Polyglot Persistence” are insufficient. We are definitely now in a different era where a new persistence paradigm has begun. The relational database management systems no longer the only option. While those systems continue to have their place in today’s computing era, their market share is starting to shrink. Relational databases may even evolve to take advantage of the advancements made in this area.
The development, discussion, and research of new persistence solutions is happening now! Challenges issued to older traditional persistence systems are inspiring the revitalization, evolution, and enhancement of the existing software. Some of the old and new will survive, a few will thrive, and many will die. These are exciting times!
The Clean Coder
I love long breaks from work! Don’t get me wrong, I also love being a software developer and I am very passionate about creating software. However, long breaks give me an opportunity to spend more time exploring technologies which I don’t use day-to-day at my current job. Long breaks also offer a chance to read a little more than usual. This Thanksgiving break was no different. When I wasn’t preoccupied with the family and other holiday activities, I sat down and read Uncle Bob’s The Clean Coder: A Code of Conduct for Professional Programmers.
It really was refreshing reading another person’s thoughts on what makes a software programmer a professional. In many ways, this topic is tough as it is very subjective. Several published books tackle the topic of software craftsmanship, but not many really dive into professionalism. Throughout the chapters, there is discussion about responsible communication, estimation, and making commitments. Important topics such as practicing, learning, and personal commitments for self-improvement are also covered. Overall, the book is pleasing and easy to read as the author shares plenty of his life experience to illustrate his points.
I think there are some areas where the book falls short. For example, the chapter of estimation discusses our responsibility to communicate honest estimates and suggests including confidence factors to allow the product folk and project managers to do their duties. However, you won’t find detailed discourse on estimation techniques. In the books defense, it is not a book about estimation techniques and perhaps detailed discourse on such techniques is out of scope. In my opinion, the author would have overcome this by including more references to material where the reader can acquire or develop those skills.
On the other hand, other chapters (like the one on practicing) did give enough reference material to satisfy my wish for more information. I also found the Appendix filled with lots of goodies to help expand your exposure to reading material and tools.
Bottom line – I recommend this book to any software programmer who is passionate about self-improvement in the professional sense.
At work, an initiative to implement some CQRS style architecture for some of our projects subsystems has begun. We were looking at ways to horizontally scale our system and a colleague suggested that we look at CQRS and Event Sourcing. Over the last month, we have researched the topic, spiked out the implementation, and started migrating some parts of our bounded contexts to make use of the architecture.
Below is a list of links to white papers, blog posts, sample applications, and other information on CQRS and Event Sourcing. There are not listed in any particular order:
I may add links to this post from time to time as I come across useful ones.
