PurelyFunctional.tv Newsletter 254: Calm, Microservices, Complexity
Issue 254 - December 4, 2017
By the time you get this, I will have nearly arrived in Prague. I've been invited to give a talk at a new event called LambdUp. If you're in the area, you should give it a shot. Prague is a beautiful city. The event is one day, with two workshops in the morning and talks in the afternoon. It's 78 Euros! With world-class speakers! Probably the best deal in Europe.
Will I see you there?
PS Want to get this in your email? Subscribe!
Well, we're less than 3 months till Clojure SYNC begins. I'm very excited, and you should be, too. The speakers are awesome and talking about very relevant topics. If you like the kinds of deeper ideas that I link to and write about in this newsletter, the conference will be that times 10 (because there are ten speakers!). If you're planning on coming, please get your lodging booked because the special reservations we have with the hotel will end on December 21!
Don't forget that Clojure/West is not happening in 2018. Clojure SYNC is the conference to go to for far-reaching ideas in the Clojure world.
Bobby Calderwood presents a compelling model for how microservice systems could be architected, based on functional programming principles. I think that the idea of separating services into three types is especially useful.
Kent Beck has aggregated some tips he uses to keep complexity small by breaking it up in to chunks. But more importantly, he talks about needing these because of limitations he has. I've known many programmers who can do more complex stuff that I can in their heads. But then when they write out the solution, it's a big mess. Sure, it works, but it's not good code. Very often, our limitations are what lead us to develop good habits.
I had never heard of this "movement" and was glad to see someone is thinking about it as we live with more and more technology.
A cute article by Jasmine Jaksic about how she uses an engineering technique to resolve disputes resulting from miscommunication. To be honest, this rang a lot of bells with me. I've tried in the past to "debug" miscommunications in the past, with very bad results. It doesn't work if the other person does not get what you're doing. To them, it seems like you're trying to rewrite history. To me, I wanted to clarify the intention of each exchange!
Does programming really change us so much that we start to see any system as debuggable? Or is it something in programmers beforehand that makes us able and willing to do that?
Colin Fleming, the creator of Cursive, was on the Talking Kotlin podcast. It's great to hear him comparing Clojure to Kotlin, and where the strengths of each lie. It's so cool that these two languages can complement each other in the same application.
One worry I've seen in the Re-frame community is how best to structure your database. I've put together another guide all about how to structure your database, including what concerns are important and which ones can be ignored.
This course is just getting better and better. I'm working my way through my notes. Here are the lessons I recorded last week:
- Interceptors Overview - if you're curious about how interceptors work and how they form the foundations of event handling
- Interceptor example - we build an Undo system using interceptors
- HTML / DB Isolation - this explains what is, in my opinion, the most important feature of Re-frame as an application framework
- Reactive Subscriptions walkthrough - we trace through several reactive subscriptions to see exactly when they update