This week I gave a talk at Vancouver Amazon Web Services User Group meetup about AWS Elastic Beanstalk:
- Introduction to the service
- Some implementation details
- Tooling we’ve built at Bench
- And lots of comments about my experience of using it
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.
Software development teams naturally have leaders. I see two types of leaders: team leads and technical leads.
Team leads care about projects, tasks, velocity and related things and usually have titles like Team Lead, Project Manager or Technical Project Manager. They can be programmers and know how to code, but their main focus is planning projects and organizing processes.
Today I want to talk about technical leads. You’ll probably call them Engineering Lead or Lead Engineer. Their role is not always clear, sometime they can lead a team and participate in the project management activities, but keep the focus on coding and delivering products. Sometimes they can have a specialization on some specific area or domain, like Lead Back-end Engineer or similar. But they have something in common.
Recently I’ve been asked by a coworker who wants to move to the technical leadership – “what do I need to improve”? I wasn’t ready to answer, because I didn’t have a clear picture what technical leaders do, precisely :) I started to think and reflect more and I think I have pretty good understanding now.
Software engineers have clear goals: making individual contributions and delivering products/features.
Technical leaders care about opposite: empowering a team, making sure a team uses best practices like pair programming or writes good tests, invests into documentation and tooling, cares a lot about reliable architecture and clear codebase, you name it. Goal of a technical lead is to make sure that everyone in a team contributes as much as they can and constantly push efficiency and quality of work for the whole team forward.
Again, it’s not about being “the guy”, it’s about thinking of team contributions more than yours.
Software engineers like to discuss different aspects of their craft: elegant solutions, performance benchmarks, semantics of programming languages, the shortest webapp implementation with a favourite framework, etc. We like to argue why language X is better than Y and why framework A is faster/simpler/better to use than B.
Something that we don’t usually discuss is complexity. The important thing to realize: we can’t remove it. We can try to hide it, yes. But any relatively big system has complexity in some form, on some level.
As an example, let’s take a look at popular Sinatra-inspired web frameworks: Flask, Express, etc. It’s really simple to create a small webapp or RESTful API. Very simple. So simple that the whole implementation fits on one screen. But still, they hide complexity. Try to run them on multi-core and multi-node cluster efficiently and reliably. That should be relatively “easy” to do, until your application has a state or you discover that not everything is thread-safe. Fun stuff. Distributed systems are hard.
Ok, how about the other side now. Toolkits like Erlang/OTP or Scala/Akka are considered to be complex and suited for building distributed systems. They move complexity to a different edge, so bootstrapping takes much more time, but “hard” problems are actually easier to solve. Cluster Singleton or Cluster Sharding? Yep, it’s there!
The same concept applies to programming languages. Everything has pros and cons. Complexity should always be an additional dimension that we should take into consideration, discuss it and plan accordingly.
Nowadays you can find lots of “must-read” lists about software engineering in general, as well as specific topic or language. All these years I had an impression that some parts are missing from the big picture, especially for the beginners. Yes, it’s important to know your current language of choice in depth, or be an expert in some tool or technology. But you probably also feel that some common knowledge exists, that is between “Hello World” / MVC tutorials and books covering specific topics. I was lucky to find one of such books a while ago and recently I have found another one.
Last few months at Bench Accounting I’ve been working on an eventing system for our microservices stack. We outgrown our legacy system and had new requirements: new messaging app! So it was clear that we need something more flexible, robust and nicer to work with.
The new eventing system was finished a couple of weeks ago and it has been running in production for a while. This week I gave a talk at Vancouver Scala meetup about the high-level overview of the system, implementation details and some challenges we faced.