Kafka for Rubyists - Part 2

This is part 2 of my post describing Kafka and how you can use it in your Ruby projects. Check out part 1 here. In part 1 we went over the basics of Kafka and how it operates as well as it’s basic architecture. In this post I am going to cover why you may want to use Kafka for your next project by describing some of it’s benefits such as durability and fault tolerance. »

Kafka for Rubyists - Part 1

If you are a frequent visitor to sites like HackerNews or Lobsters or follow new software development technologies, you may have read something about a messaging framework developed at LinkedIn called Kafka. Kafka is a very popular distributed message queue that is used as the backbone of many applications and services throughout the world. I’ve been trying to learn as much as I can about Kafka for an upcoming project at work, and so I thought I would try to write a post describing the basics of how it is used and works that will hopefully help others that are just getting started with Kafka, or at least would like to learn more about it. »

Engines Before Services

If you’ve ever worked on a poorly designed, monolithic Rails application you know how messy they can get. Fat controllers referencing models nested in folder structures three layers deep, filters used in base controllers that inherit from other base controllers, etc. Logic becomes strewn every which way because of entangled dependencies. If you change one thing you break another completely unrelated part of the system. Applications are not designed this way from the beginning. »

Wrap Your Dependencies

These days it’s almost impossible to write an application that doesn’t depend on any third party code. Ruby/Rails and Bundler make it extremely easy to include any gem from anywhere on the Internet in your application. Third party gems are a wonderful thing as they allow your application to provide new functionality without you having to write hardly any new code yourself. Less code that you have to write means that there is less code that you have to maintain and (hopefully) less potential bugs in your application. »

Are Standups The Answer?

Standup! - Ludicrous{:target=”_blank”} As a software engineer working during the ‘Agile Renaissance’, you’ve no doubt participated in or at least heard about the practice of standups. For the uninitiated, standups are a simple practice in which developers and stakeholders get together on a regular, usually daily, basis to report on their individual statuses. Each team member gets a small sliver of time to report three things: What did you do yesterday What do you plan to do today What, if anything, is blocking your progress The idea is that this practice helps improve team communication, gives stakeholders an up to date progress report on how the project is going and can also spark offline discussions on better ways to do something or help prevent duplication of effort. »