• CORS woes on Heroku

    ,

    After spending the past 4 hours attempting to solve what boiled down to a rather simple problem, I figure I’d better blog about it to save someone else the time and effort.

    If you’ve been leveraging Passenger’s new –nginx-config-template command line option to add CORS headers to static assets served from a Rails app hosted on Heroku, and the CORS headers recently disappeared under mysterious circumstances… read on.

    I’ve been using the method described here to add CORS headers to custom fonts served from a Heroku-hosted Rails app that’s proxied by Nginx which handles serving static files. I recently updated to Rails 4.2.2 and suddenly, my custom fonts (.woff and .woff2 files) no longer had CORS headers on them.

    After the aforementioned hours spent scratching my head, I discovered that the latest version of the sprockets gem is generating asset digests that are 64 chars in length, where previously they had been 32. Nginx’s default regexp for identifying requests for static assets assumes the digest will be 32 chars long, like so:

    # Rails asset pipeline support.
    location ~ "^/assets/.+-[0-9a-f]{32}\..+" {
      error_page 490 = @static_asset;
      error_page 491 = @dynamic_request;
      recursive_error_pages on;</code>
    
      if (-f $request_filename) {
        return 490;
      }
      if (!-f $request_filename) {
        return 491;
      }
    }
    

    Changing the regexp to recognize digests that are 64 chars in length immediately solved the problem:

    location ~ "^/assets/.+-[0-9a-f]{64}\..+" {
       ...
    }
    

    I had to laugh after something so stupid and silly cost me a good chunk of my Saturday to debug. But at least it’s working now. My statically served custom fonts have the correct CORS headers and Chrome and Firefox are happy again.


Need help?

I’m an independent software developer available for consulting, contract work, or training. Contact me if you’re interested.


  • Pair programming showdown at BarCampRDU

    BarCampRDU 2008 came and went. It was quite enjoyable. There wasn’t as much grub as last year, but I thought the topics were more interesting.

    I gave a talk on pair programming during the afternoon. It really became more of a group discussion, which was exactly what I was hoping for. Some attendees have requested the slides so I’ve attached them to this post as a PDF.

    The slides have been edited somewhat. I gave this same presentation at Agile ITX last month and it was an hour and a half long. I had to cut out a few things for BarCamp. But the central ideas are still there.

  • Picking values from Ruby hashes

    Want to pick a certain set of key/value pairs from a Ruby hash? You might do this:

    hash = {:foo => "bar", :bar => "baz", :baz => "boo"}
    hash.select { |k,v| [:foo, :bar].include?(k) }
    
    # returns [[:foo, "bar"], [:bar, "baz"]]
    

    Kind of messy. We can do better by reopening the Hash class this way:

    class Hash
      def pick(*values)
        select { |k,v| values.include?(k) }
      end
    end
    

    Now our selection works like this:

    hash = {:foo => "bar", :bar => "baz", :baz => "boo"}
    hash.pick(:foo, :bar)
    
    # returns [[:foo, "bar"], [:bar, "baz"]]
    

    Ruby is a wonderful language. This is one small example of how having access to existing classes can be incredibly powerful. With this power comes great responsibility. Wield your power wisely.

  • Speaking at Agile ITX next weekend

    I’ll be speaking at the Agile ITX conference in Reston, Virginia on June 27th. My presentation is titled Pragmatic Pair Programming and is based on the many diverse pairing experiences I’ve had over the past six years. Mention pair programming in any crowd of programmers and you’ll get two responses: adoration or outright hatred. Why is pairing so controversial? Does it have any tangible benefits? That’s what we’ll be exploring together. Agile ITX is shaping up to be a great conference with many top-notch presentations. I’m excited about getting the chance to participate. Hope to see you there.

  • Nomadic programming (part 1)

    I’m a freelance software developer which means I generally work from home unless a client needs me to be on-site. I don’t mind being alone to a certain extent, but after a few straight weeks it can get pretty lonely.

    Recently, I’ve started doing what I’ve termed “nomadic programming.” Namely, spending the day roaming between various wi-fi hotspots instead of working from home. This has worked really well for me. So well, in fact, that I think the concept needs to start spreading.

    Now I realize there are many freelancers out there who already do something similar to what I’m describing. I think it’s worth “formalizing” the process, though, by laying out the pros and cons of nomadic programming, and then giving some advice on how to actually go about doing it.

    nomad [noh-mad]: (1) a member of a people or tribe that has no permanent abode but moves about from place to place, usually seasonally and often following a traditional route or circuit according to the state of the pasturage or food supply. (2) any wanderer; itinerant.

    Why be a nomad? Why not stay at home? While staying at home has its benefits, here are some reasons why a nomadic lifestyle might be a better fit for you:

    • It zaps loneliness. Let’s face it, being at home by yourself isn’t the most exciting of propositions. Many of us have families and that helps a lot with the loneliness factor. For those of us who don’t, getting out into an environment with other people can defeat that pervasive sense that we are the only person left on earth. (Anyone who has seen “I Am Legend” will know what I’m talking about.)
    • It increases focus. This may seem counter-intuitive at first glance, but let me explain. When I’m at home, the temptation is to wander over to the kitchen for a snack, pop in a DVD, or conveniently set aside my work to get to those chores I’ve been meaning to do. The primary reason this happens is because my surroundings are familiar. It can be hard to focus on work at home because we’re used to doing so many other things there… relaxing with the family, mowing the lawn, picking up after the kids, sleeping, etc. If you’re anything like me, you have a natural tendency to procrastinate and substitute household activities for billable work. Nomadic programming kills this temptation. It places us in an entirely new environment with a new set of stimulations. It snaps us out of “being at home” mode. We can’t very well be tempted to grab a spot on the couch and turn on the TV when our home is several miles away. I’ve found that placing myself in fresh environments every so often greatly increases my ability to focus on the task at hand.
    • It boosts productivity. Hand in hand with focus goes productivity. I get so much more done in a new environment than I do at home. I’m not completely sure why this is yet, but part of it probably has to do with the way our minds work. When we get used to routine, time passes more slowly. We get bored. We get distracted. In a new environment, our minds have to be alert to take in the new stimulation that’s being provided. This alertness yields greater productivity gains. On Monday this week, I spent three hours in the morning coding by myself. I then spent three hours during the afternoon coding with a friend at Bruegger’s. I was twice as productive during the afternoon as I was during the morning. This isn’t because I’m not a morning person. It’s because being away from home and interacting with a good friend yanked my mind out of the routine it had slipped into, and the code flowed more freely as a result.
    • It’s a great way to network. With the aid of new location-aware tools (which we’ll cover shortly), nomadic programming is a fantastic way to meet new people that you otherwise wouldn’t have been exposed too. Let’s face it, the only people we interact with at the local user groups are other programmers just like ourselves. Contrast this with the coffee shop or the park. There is potential to run into a fellow entrepreneur, an insurance salesman, an airline pilot, a night stocker from the grocery story, the guy or gal who delivers our mail, etc. Exposure to a whole new set of people becomes not just possible, but likely. This is, again, an area where routine can work against us. If we get used to being around the same set of people all the time, it has the potential to kill not only our networking skills, but also our chances of meeting people that will stimulate our minds in ways that would not otherwise be possible. We shouldn’t just be learning from fellow geeks, folks. We should be branching out and learning from all sorts of people. Nomadic programming enables this kind of networking to occur naturally.
    • It’s just plain fun! Spending your morning sipping a latte, making a new friend, then choosing to migrate over to Panera together to grab lunch and share ideas can be downright enjoyable. It’s not all about cranking out the code to meet the deadline, folks. If your work is never fun, you’re in the wrong career. Being a nomad can make programming fun again.

    These are just a few of the many positive aspects of nomadic programming. What about the downsides, though? It can’t all be a stroll through the flower bed, can it? No, it can’t. There are some bees waiting to sting us:

    • It can be time consuming. Being a nomad requires travel time between the different places you visit. Depending on how far you travel, this can eat up time that could otherwise be used for billable work.
    • It can be expensive. Many places that offer free wi-fi right now are businesses that expect to turn a profit, and rightly so. It’s not ethical to take advantage of a work location without making it worthwhile for the people providing that location. This means that when you visit a coffee shop, you should order something (preferably something other than water). Add small dining costs like this to the gas you blew getting here and the expense can begin adding up.
    • It can distract from more important things. For those of us with families, it can be easy to get carried away with being a nomad and start routinely staying out quite late. Midnight coffee shops don’t help here. It’s very tempting to just keep working, especially if you’re having good, productive interaction with fellow nomads. This can quickly begin eating away at the time you should be spending with your family. It can be equally tempting to start skipping out on home chores, responsibilities at church, etc.

    While the downsides to being a nomad are real, they can definitely be managed. Wi-fi is getting fairly common, even in more rural areas, so travel time can often be limited. Expenses can be kept down by ordering cheaper items and putting in an extra hour of billable work to make up for what you’ve spent. Distraction is a harder nut to crack, but it can definitely be overcome with a dose of self discipline and some verbal accountability to your family and friends.

    When balanced against the advantages, it’s clear that nomadic programming is a good thing overall. So once we decide the benefits are worth it, how do we actually go about being a nomad? There are a few simple, easy guidelines to follow and several tools that can make the process easier and more fun. We’ll find out what to do (and just as importantly, what not to do) in my next post.

    In the meantime, drop a comment and let us know if you’re doing nomadic programming.