Phoenix Is Not Rails

I have been following the Elixir community and the Phoenix framework in particular. I feel a certain familiarity between Ruby and Elixir, and Rails and Phoenix. Chris McCord, the creator of Phoenix writes, a thoughtful post on the differences, and more importantly why they matter. Sometimes, differences in Software Engineering can be esthetic only (e.g. plural vs singular database table names); Not so with these. He makes compelling arguments on the technical choices made in Phoenix.

How To Charge For Open Source

Mike Perham, the creator and maintainer of Sidekiq, explains how to go about making a business out of Open Source Software. Uncharacteristically for the internet, the comments for this post are actually very interesting, as are the links. For a more in-depth conversation into the same topic, hear (or read the transcript) of Mike’s guest appearance at the Ruby Rogues Podcast

What Is SemVer

SemVer, short for Semantic Versioning, is a convention for software version numbering. I have been using it very successfully at work with for internal gems and bundler pessimistic locking (~> operator). In this post Richard Schneeman, explains the practical aspects of choosing a release number, including security releases.

Last Saturday (11/14/2015) I attended my first code retreat, hosted by the kind folks at Pluralsight. The event was part of the Global Day of Code Retreat. 144 cities participated in the event, and for the first time San Diego was one of them.

Global Day of Code Retreat: A day to celebrate passion and software craftsmanship

The retreat is a one-day exercise in honing the craft of programming. It started with a short introduction and then we were asked to pair with someone for the first exercise: Conway’s Game Of Life. The exercise is specifically chosen because the domain is simple enough to understand within a couple of minutes, by implementing it is usually not trivial. We were not given any rules, except to use Test-Drive Development (TDD) throughout the day. Language choice and design was left up to each pair. After 45 minutes, we switched pairs and deleted our code. That is right: We deleted our code.

Why delete the code? Because the exercises are about learning, not about shipping working code. It’s supposed to be in contrast to what we do at work every day, where we create artifacts that are production ready and ship them.

For each rotation, there was usually some extra restriction added or removed. The day was very intense and interesting. I paired with a Cobol programmer, with no TDD experience, looking to come back to programming after a hiatus. A .NET code school student, and another very experienced .NET developer. In a mob-programming session, we tried starting a project in Javascript, then Java and failed in each case because we didn’t know how to get the test framework setup and ended up switching to Ruby, mainly because I know how to start a project with TDD baked in (bundle gem game_of_life). I had a chance to pair with an experienced javascript programmer, that was interested in ruby and with a gentleman that was an expert in both TDD and .NET. It was great seeing different approaches to the same problem come up. For example, I assumed that all solutions would require some sort of data structure to keep track of the state of each cell in each generation. However, several different people suggested using a set, to only keep track of live cell. Those solutions ended up being very elegant.

In each exercise, I learned something interesting. I learned that it’s easy to take for granted the shared understanding and context that you have with your team around what “clean” code looks like, what to test, how to structure test and even what type of tests there are (ie. unit, functional, integration, etc). I learned that there are many people that are just now getting acquainted with TDD and extreme programming. I learned that pair programming forces you to be explicit about what you are doing and be convincing about the path forward, since you pair needs to agree. I learned that if you are willing to listen, you can learn new things from everyone and anyone.

Speed up with Materialized Views on PostgreSQL and Rails

Materialized views are a way to cache the result of expensive database computations, right on the database. Used in the right manner, they can make speed up performance significantly. As with any other caching mechanism, there exists some caveats about invalidating the cache when underlying data changes. This guide shows how to leverage this database feature in a Rails app. Clear and to the point.

Debugging a Memory Leak on Heroku

Richard Schneeman writes another insightful post on how to make Ruby applications better. In this case, he talks about how to identify memory leaks (as opposed to memory bloat) and different techniques to mitigate memory leaks. Plenty of good techniques discussed.

What Would Feynman Do?

One of my favorite books, is Surely You’re Joking, Mr. Feynman!, by Nobel-prize winning physicist Richard Feynman, a collection of anecdotes from his life, in which is unique way of viewing the world and whimsical approach to problem solving is highlighted. This blog post imagines Mr. Feynman at a job interview, where he is asked to solve a “later-thinking” puzzle. It’s hilarious. If you enjoyed it, don’t hesitate to read the book.

Communication: how to be a better software developer

Targeted to software developers trying to level up, this articles has great tips on how to be a better communicator and why it’s important. The advice resonates with me. Really, every one can benefit from being better at people, no?

Yesterday, I had the pleasure and privilege of presenting at LA RubyConf 2015. The conference was great. The presentation slides for my talk, Practical Unix for Ruby and Rails is now available.

It is powered by the awesome Remark.js, which has awesome features, like presenter mode that shows you notes next to each slide. Hit [P] to see my notes for the slides.

Update: Confreaks has posted the video of the talk

How We Ended Up With Microservices

Phil Calçado writes a detailed post on the non-technical side of why Soundcloud moved away from a monolithic Rails app, in favor of a microservices architecture. Main reason: productivity. They were able to reduce their time-to-launch of new features from 66 days to 16 days.

A Gentle Introduction To Actor-based Concurrency

Originally published 2 years ago, Practicing Ruby provides a great explanation of what the Actor model looks like in Ruby. He solves the Dinning Philosophers Problem with bare ruby, the with Celluloid and then shows a simple implementation of actors in ruby would look like. Great read.

Implementing Worker Threads in Rails

Did you know that when a process is forked in ruby, only the main thread is copied and all other threads are dead? Neither did I, until I ran into it recently. Solving threading issues is very hard. This post has great techniques on how to use threads in Rails, even if using forking servers.