I've been learning Clojure lately. It's my first experience with a Lisp dialect and I'm enjoying it. So far my favorite surprise is REPL! I've heard the promise of “interactive coding” or “live updates” before from other languages, but this is the first time such a promise has actually payed off for me. REPL has had a real impact on my, fairly limited, Clojure programming experience. In this post I'll explore why it works so well for me, while some seemingly similar technologies haven's had nearly as much of an impact.
I like Go programing language, and I like writing command line tools with it. I feel it strikes the perfect balance of convenience without magic, access to OS and portability. I also like using Cobra library for writing my CLIs. It helps me break my app into sub-commands and build consistent and feature rich command line experiences.
However, I've found that Cobra's documentation and its generation tool for scaffolding CLI projects encourage writing code with coupled responsibilities that's hard to test. In this post I'll explore an alternative approach to structuring Cobra based CLI apps. My goal is to decouple business logic from the command line interface, and to cover it with unit tests. I've put together a simple project to showcase the idea: Passgen.
I've already written about my experiences using Spring Cloud Gateway. While the framework continues to provide a great set of features, it does have its quirks. This is a story about one of them.
I love code reviews. I love sharing my solutions with others and receiving their feedback. I love seeing what others have developed and finding ways to improve it. I love thinking about code quality and debating it with others. In this blog post, I hope to pass a little bit of that love on to you.
In this blog post I'll go over building a prototype of Java application that can load and run Kotlin scripts at runtime. Extra requirement is to support scripts written in various mutually incompatible Kotlin language versions. This experiment is an isolated, self-contained project, but it does explore a real-world use-case that I've encountered.
When looking at teams of developers it's rare to find all members at the same skill level. Even in those rare occasions, they are likely to differ in their communication styles and in mental model of the system they are working on. On the other hand, it's important for team members to be able to communicate efficiently and to have a share common model of the application architecture.
Any software system will eventually experience a degradation, outage or a similar incident. Depending on the type of business you're in this can lead to a loss of revenue and clients or even have legal repercussions. That is why it's important to have a good incident management process for resolving incidents, reporting on their impact and preventing them from happening again.
In this blog post I'll describe my personal experience with some challenges of establishing the incident management process and why I built a tabletop role-playing gameDeployments and Disasters to deal with them.
In this part of CLI development series I'll go over some of the more advanced use cases. I've previously discussed general tips for making command line apps nice to use. If you missed that blog post you can find it here.
As use cases grow more complex it makes more and more sense to look for existing solutions and reuse / incorporate them into our own applications. That's why I'll devote more space in this post to highlighting existing projects, as opposed to talking about my own experiences.