• Antipatterns: Subclassing Struct Instances in Ruby

    Using plain Ruby objects to encompass specific domain concepts is a great way to address model bloat in Rails applications. I recently worked on a medium-sized Rails app that made effective use of this notion, but did it through subclassing instances of Ruby's Struct class. This makes for nicely succinct code, but introduces some insidious problems that are likely to creep up later.

    Read more »
  • Where I Got Stuck Using IEx.pry in Elixir

    Today I started messing with Phoenix - a web framework for Elixir - and got to a point where I wanted to inspect the environment around which a chunk of code was running in an EEx template, but ran into a bit of a wall. Following the example in the documentation for IEx.pry, my controller read thusly:

    Read more »
  • The String Calculator Kata In Elixir, Plus Elixir First Impressions

    TL;DR - The String Calculator kata was fun to write in Elixir, and at first glance, the language feels like what I'd want a fully-functional version of Ruby to be, and the ecosystem is very developer-friendly. Exciting!!!

    Since Elixir hit 1.0 a few weeks ago, I've been getting more and more antsy to dive in and write something with it. Since the String Calculator kata is my go-to for almost any contrived programming activity, I had an easy place to begin. After a false start earlier this week, I decided to really dive in today. You can read through the result here.

    My first impressions of the language and ecosystem are nothing less than glowing.

    Read more »
  • Helping To Reason About Recursion

    Recursion can be a scary topic. On the surface, it requires you to keep more of a mental stack trace around to try and understand what a recursive function is doing. For example, what is the state of the function input on iteration one? Then on iteration two? What about iteration 8311?

    In reality, most of the time we don't even really have to care about this mental stack trace. It is actually way simpler than that.

    Read more »
  • Design Like You're Gonna Play It Live

    Have you ever listened to a song that sounds like it was recorded in one take? With all the musicians present in the same room when it was recorded? When I know about them, those are my favorite kinds of recordings. There's 'chemistry' in the music that you don't get out of the more patchwork quilt-style recordings - those where the hard solo is tracked after the rhythm section is done, complex haromonies are captured apart from drum and bass, etc. I call music recorded in this way "airbrush music". It's perfect in every way. Tempo, articulation and synchronoziation are all right on the mark, but sometimes it's a little too good.

    In addition to production quality, you find musicians achieving things in the studio that just aren't possible live. For example, if you've got a band made up of a guitarist, a bassist, and a drummer, and you hear a solo overlaying rhythm guitars, you can expect one of two things live: there'll be a guest guitarist present or the song will omit one of the parts altogether.

    How does this translate to design?

    When designing for the web, it's easy to design like you're in a recording studio. You take some liberties - add some spice to what are usually native browser controls, fudge with the kerning to get things to line up - and what you end up with is a super-polished, very attractive design that is expensive and difficult (or impossible) to execute in a live scenario.

    Read more »
  • Fast UI Development in Large Rails Codebases

    I've spent the past year working on a product running on a relatively large Rails codebase, spending about half my time on the back-end and half in the UI layer. As the codebase has grown in size on the back-end, I've noticed an increasingly prevalent source of frustration in my day-to-day: slow request times when writing code for the UI.

    But slow Rails should be a thing of the past. What's up?

    With this particular codebase, we're using Require.js for a large part of our JS functionality. In production, the associated scripts are being compiled into a single file via R.js, but in development, Require.js will make a request for each script in your require directive. Unless you're running Rails behind Apache or Nginx (or some other reverse-proxy), Rails is being asked to serve all asset requests the browser issues, including assets. In our case, without completely realizing it ended up asking Rails for a lot of stuff. Based on this, it would stand to reason that if we're asking too much of a single Rails process, adding processes might help the problem, right?

    Read more »

subscribe via RSS