Here’s my first attempt to summarize most important things happened in my professional life (mostly programming) this year, for future self. May be it’ll be interesting for someone else too.
Pretty much every web developer has built HTTP APIs. How does it usually happen? If you have good practices established in your team you probably start with a whiteboarding session. Good one-hour exercise with your colleagues produces something that we call “API spec”. It might look like this:
Great job everyone! Although, we forgot a few “minor” things:
- Error messages and error HTTP codes
- Authorization and authentication
- Schema for the entities
- … >_<
- And the most important, does it actually satisfy consumers (like front-end apps or other systems)?
Multiply that by number of years you’re going to maintain that (∞) and the rate of adding new features… Looks really depressing. Our beautifully designed “API spec” quickly becomes a pile of unmaintainable mess. Is there a better way to do it?
As you probably know, I’m a big fan of Akka. Akka Cluster is a great low-level mechanism for building reliable distributed systems. It’s shipped with powerful abstractions like Sharding and Singleton.
If you want to start using it you should solve cluster bootstrapping first. Almost every tutorial on the internet (including the official one) tells you to use seed nodes. It looks something like this:
1 2 3 4
but wait… Hardcoding nodes manually? Now when we have Continuous Delivery, Immutable Infrastructure, tools like CloudFormation and Terraform, and of course Containers?!
Well, Akka Cluster also provides programmatic API for bootstrapping:
So, instead of defining seed nodes manually we’re going to use service discovery with Consul to register all nodes after startup and use provided API to create a cluster programmatically. Let’s do it!
This week is my last week at Bench.
RSS is not dead. At least not for me :) I use NewsBlur to track and read 50+ various feeds – tech, travel, personal blogs. Today I want to share a list of software engineering blogs that I find very helpful and keep in my list for a long time.
At Bench we’re convinced that GitHub should be a central place for everything project-related: codebase, documentation, tasks. That’s why we don’t use any specific Project Management software, but instead we try to use GitHub.
Obviously GitHub has a very limited set of features: issues, labels, milestones. But, surprisingly, it’s good enough foundation that can be used by other services, for example Waffle.io.
Waffle gives you Kanban-style dashboard for managing your tasks. It has two-way synchronization with GitHub, so every change in GitHub is propagated to Waffle in near real-time and vice versa. Waffle also uses labels to organize issues in columns, which makes everything easier from the GitHub side.
Still, there are lots of problems if you want to use GitHub & Waffle for your Scrum process. That’s why I’ve been working on syrup, CLI tool for Scrum. Readme has lots of details describing Waffle problems and suggested workflow to overcome them. It’s published as npm module, so it’s really easy to install.
From technical point of view it’s a very simple Node.js/ES6 app (using Babel) that mostly uses GitHub API for fetching data.
PS: currently I investigate ZenHub as a Waffle & Syrup replacement. It solves the same problems and brings even more features, like built-in epics and burndown charts. At the same time, Waffle is completely free even for private repositories (and ZenHub is not). Syrup still can be useful for ZenHub though, you can find more details in Readme.
I’m not a Postgres expert, but I’ve been using it for about 6 months as an Event Store database. At Bench we’ve built our own eventing system on top of ActiveMQ, Camel and Akka and we use Postgres to persist every single Domain Event.
Our event schema is very flexible and currently represented in JSON. We chose Postgres for persistence, because of the great JSON support. As you probably know, Postgres 9.4 introduced JSONB type, which is an advanced JSON type that supports indexing. Obviously, you should index all your key fields, but it can be tricky. Let me share what we’ve discovered.
Today I participated in Polyglotconf 3rd year in a row. This time I was prepared though, I wanted to talk about microservices and different advantages and disadvantages you can have if you use messaging as your main internal communication protocol. Also, it makes perfect sense for me to use Actors to build the actual microservices and I tried to explain why.
It seems like this topic is quite popular nowadays and I got the biggest auditorium as well as dozens and dozens of interested people.
A few months ago I finished a huge refactoring of a Java/Scala project. It took 2 weeks and only 2 engineers to actually implement all the changes, make sure it worked and deploy. Surprisingly, deployment was really smooth, we didn’t encounter any major issues.
I think the reason why it went so good was statically typed language + amazing IDE support for that. I can’t imagine doing similar refactoring in Ruby/Python/Node, for example.