So within the two weeks, I spent a fair amount of time with something that should seem fairly obvious to someone who uses computers a lot, yet that I paid far too little attention in the last couple of years of my life. Now you may wonder what I’m getting at, but no worries, I’ll get there. Let me ask you something first. How many hours per week do you spend in front of your computer? Let me guess, probably most of your waking hours, considering that you read a software-related blog. But is your workplace ideal or even anywhere close to it?
This is a rant.
Most of this week, I was working on the client-side codebase of my BirdWatch application in order to remove the hairball in its architecture that I mentioned last week. That’s been going really well. But how do I make the readers aware of what I am working on right now? Your time is precious, so you may only want to read the stuff that I feel good about already, unless you have the time to dive deeper and compare the good, the bad and the ugly. That’s fine, too, but it’s just going to involve more effort on your part.
I’ve been struggling with finishing the next chapter of my “Building a System in Clojure” book. I tried to explain and draw the client-side architecture, but instead I’ve been procrastinating 1 around the conceptual drawings for days and now I realize why. The current architecture of the BirdWatch web client just plain sucks.
Last week, I published the very first version of my “Building a System in Clojure” book. I’m thrilled by the amount of interest it has already generated and I’ll do my best to live up to your expectations.
I thought about where to take my series about Building a System in Clojure next and realized that I don’t like the format of a blog series all that much. Instead, the format of a book seems like a better choice; one where you, the potential reader, are invited to provide feedback from the very first moment of the writing process. I have already started that process and for now I have transferred the existing articles from the series into the book without much further editing. Over the next couple of weeks, I will be working on making the content more consistent with the book format. The book is available for free on leanpub.com. Iff (if and only if) you find the content to be of value, you can pay a suggested price, but that’s entirely up to you and something you can decide on later.
Last week was great. I had just come back from my trip to the United States the week before, where I attended the Conj and got to hang out with dear friends in both Washington DC and New York City. I used to live in DC in 2009 and 2010, and it was really good to be back. Last Friday, I had a talk at Clojure eXchange in London about my BirdWatch application and my journey to Clojure. I think there should be a recording somewhere, but I haven’t checked it out just yet. The day before that, I had parted from Scala with a farewell letter here on this blog. It took me by surprise how much attention this little letter received 1, considering that it was really only between Scala and me.
Do you remember how we first met, back in 2012? I thought your functional approach was fresh, and different. For a while I believed we were made for each other. A first project was a success; on my own I was comfortable with the good parts of you. But as soon as I started working in teams writing Scala, your immense syntax started drowning me. At first, I took it as a compliment that you tried to please me by offering me to work the way I liked. But then I noticed that it wasn’t something you did for me in particular. Instead, you try to be everybody’s darling by offering every software development paradigm known to man.
TL;DR: I realized how much I disliked the process of logging data structures to the console and then trying to find them and repeatedly commenting out and uncommenting println statements. So I decided to fix that.
Last week, I drew a picture of how I wanted to break apart a monolithic application and instead run different parts of the application in separate processes / separate JVMs. The idea was to have a single client for the connection to the Twitter Streaming API and the persistence of the received Tweets in ElasticSearch, plus multiple machines to serve WebSocket connections to the client. For the communication between the processes, I picked Redis Pub/Sub because its model of communication appears to suit the requirements really well. As cute as the drawing may be, I prefer code (plus drawing), so I took the previous monolith apart over the weekend and put Redis in between for communication. It worked really well and here’s how.