A developer’s guide to upgrading to OS X Mavericks

I’ll admit I liked the sound of free with the latest release of OS X Mavericks.  What I didn’t like was thinking about the headache from my last upgrade of the OS.  Hopefully this will numb the pain.  I use homebrew to manage my system packages, so if you don’t, you might as well stop reading this and light your computer on fire for having to deal with all the conflicting installs you’ve done.

Re-install/Upgrade X-Code

Open up App Store and search for XCode… then wait an hour while it installs

Install command-line tools for X-Code

Just for fun, the command line tools for XCode have been removed from the Download section of the UI… so you have to run:

xcode-select --install

Update Homebrew

I just imagine that there is a Tsunami of updates for pretty much all packages. First I updated homebrew itself:

cd /usr/local/Cellar
git reset --hard
git pull
cd ~

Now that homebrew is the latest and greatest, I updated my brews

brew update

I also checked to make sure homebrew wasn’t missing anything, and turns out I had to install some packages it listed:

brew missing

You’ll also want to check on the health of your brews, and fix anything it suggests:

brew doctor

Upgrade GCC, Because Apple’s Sucks

brew install apple-gcc42


Several libraries and gems we use depend on Java. Luckily Apple makes this nice and easy to install *sarcasm*. After scouring the web, I found a nice packaged installer: http://support.apple.com/kb/DL1572?viewlocale=en_US.

Re-Install X11

In order to get our automated test suite working, we need QT working, and for that we need X11. Installing the latest release worked for me. Just visit: http://xquartz.macosforge.org/landing/ and download and install the latest release. At the time of this writing, 2.7.4 worked for me. Once that is installed, I upgraded QT:

brew upgrade qt


I upgraded my RVM to the latest release just in case they fixed things for Mavericks:

rvm get head


After upgrading to Mavericks, my previously installed Postgres was having some serious issues. I had to re-install it in order to get it working with my rails apps. First thing I had to do was remove the existing postgres:

brew uninstall postgresql postgresql92

Before you re-install, make sure you uninstall all your existing pg gems so that it can use the new sources in the next step:

gem uninstall pg

Now install postgres (I’m using 9.2 as it’s what is needed for a project I’m on).

brew install postgresql92

I had to manually link the startup scripts:

ln -sfv /usr/local/opt/postgresql92/*.plist ~/Library/LaunchAgents

Now install the pg gem again

gem install pg

Gem Cleanup

After all that, there was just one gem that needed an update (probably due to the QT updates). If you run into issues with any of your gems, just try updating them or uninstalling/reinstalling. For me it was just:

gem update capybara-webkit

After ALL of that I was good to go with minimal issues. Hope this helped.

Even Expert Rubyists Can be Fooled by Misleading Heredoc Syntax.

What do you expect the following code to produce?

If you’re familiar with Ruby’s Heredoc syntax you’ll recognize this syntax as an easy way to capture a string of arbitrary length, but when you execute the file above, you’ll see the syntax is invalid.

Why is this?

Well, as it turns out, ruby doesn’t see this as a heredoc at all. Instead, it sees it as string.«(EOF) which is invalid because EOF is undefined.

That’s pretty confusing and it’s easy for expert coders to miss in a code review.

Since constants in the global context will evaluate, what if we had another innocent looking file included in the project somewhere?

Sure, that’s a little strange looking, but a file like that isn’t beyond the realm of possibility in a large project. What happens if that file somehow found its way into the project?

Suddenly, the invalid syntax from the first file becomes valid with a new and very dangerous meaning. This is subtle enough that it could present a real threat against your projects, especially if its a large project in constant flux.

Keep your eyes peeled for things like this. This one would be very easy to overlook.

Log All Calls To Instance Methods Of A Ruby Class

We came across a situation where we lost track of the timing of execution of certain pieces of code.  To help us debug, we wanted to log every time the methods of a particular class were called, but without junking up the existing methods with repetitive calls to the logger.

We created this handy module to save us some time, and keep things clean. Here’s our Rails compatible method logger, which could be used to wrap all instance methods of a class with other code if desired:

Use this to log all calls to instance methods of a class to the log.  Just include it at the top of your class like so:

Then the next time you call any function in your class like so:

Then you will see a nice output in your log:

12 signs that your developers are doing it wrong

Image Source: http://www.halolz.com/2008/04/15/doing-it-wrong/

Quality can be a difficult thing to judge in software development. It takes time to get things right. But just because it takes a while to get things done, it doesn’t mean things are being done correctly.

Here are some signs that your software development practices are going in the wrong direction:

  1. You’re afraid to ask for upgrades because you aren’t sure what’s going to break.
  2. Upgrades to your application bring new problems.
  3. Upgrades to your application bring back old problems.
  4. When using your application, there are “scary” parts that seem to cause problems, every time they’re used.
  5. You have special instructions that must be followed to work around issues that won’t go away.
  6. Bug fixes seem more like bug “movers”, with every fix bringing new bugs.
  7. You need to use Internet Explorer for everything to work correctly.
  8. New features seem to make the application worse, not better.
  9. When new features are added, you’re always the first to find bugs.
  10. If you have a bug tracking system, there are more bugs to fix than there are new features to build. And that never seems to change.
  11. Your application relies on an external library that just released a sweet new feature, but you can’t take advantage of it because you can’t update to use it.
  12. Simple changes that used to be easy and quick are taking longer and longer for the team to complete.

If these sound like problems you deal with on an almost daily basis, maybe it’s time for you work with a team that builds software that just works. Fill out our client worksheet to start the process of fixing these problems for the last time.

Developing with subdomains just got a lot easier: *.lacolhost.com

source: http://developer-faq.blogspot.com/2011/07/access-localhost-from-android-sdk.html

It’s a pain working with applications where subdomains are used to identify accounts or other information. Generally, it involves hacking your /etc/hosts file with a list of specific subdomains.

We don’t really like doing that.

So we bought lacolhost.com and setup a wildcard to resolve to It’s up and running and you can rely on it for your development now and for as long into the future as we can.

So the next time you need to test pinkfluffyunicorns.myapp.com in development, don’t mess with your hosts file, just go to pinkfluffyunicorns.lacolhost.com to hit your development environment and make sure it works.




Creating accurate software estimates

The Cone of Uncertainty. Credit: Construx (http://www.construx.com/Page.aspx?cid=1648)

One of the largest challenges, if not the largest challenge we face in our business almost every day is the answer to the question, “How much work do you think it will take to build it?”. 

Part of this problem is the high cost of solving unknown problems. Software is unique from virtually all other trades in the world. When a specific problem is solved, the cost of solving the same problem again approaches zero. This allows for incredible progress on solved problems, and in relative terms, frustratingly slow progress on new problems. Sometimes, even the solved problems, when approached slightly differently, turn into new problems that need to be solved.

Another issue that compounds the difficultly of estimation is the large number of unknowns in any software project. Even the most fully formed spec cannot uncover the complications that are discovered only once construction of a software project begins. So not only do you not know the difficulty of solving known problems, you can easily expect a certain number of unknown problems to be discovered during the course of development.

So how do we create an estimate that encompasses both the solutions to problems we know of and solutions to problems that we have not yet discovered?

Set expectations

The very first thing we do when we begin a new relationship with a client is try to set some expectations for our work. It’s important to make sure we get off on the right foot, so we communicate the following right away:

  1. We will always be honest with you.
  2. There is much we still don’t know about your software project.
  3. Development is as much about discovery as it is about implementation.

We consider this to be one of the most important parts of our relationship with our clients. Setting expectations early and often is a key ingredient of good software.

Discover the unknown

When we’re ready to create an estimate, the next step is to break down the requirements into small pieces. Within each piece, we can identify the features that we know contain unknowns and use experience to take a guess at where other potential unknowns may be hiding.

For example, if our customer wanted to create a blog system similar to the one powering this site, we may break it down into the parts we can identify: Posts, Tags, Authors, etc. Posts have a title, a date when posted and so on. Experience tells us that creating a Post can be done easily, but Tags can be much more difficult depending on the requirements.

As a part of the estimate, implementation questions will arise. This is to be expected. Our job at this stage is simply to identify what we know we don’t know.

Build on what we know

At the core of every estimate is the effort we know will be required. From the work we’ve done in the stage above, we can identify the things we know how to do. These are the things we understand well and use as the absolute bottom for our estimate. 

By using the knowns as the baseline for our estimate, we can also identify where an estimate hasn’t been correctly specified. If there’s a feature where we can identify no part as known, then we need to go back to our customer to get a little more detail, until we can find a way to understand it better. We aren’t looking to understand everything, but we need to understand the types of problems we need to solve to have any hope of an accurate estimate.

Continuing our above example, we know it’s simple to add an arbitrary number of attributes to a Post: Creation date, Published date, Content body, etc. These make it easy for us to establish a minimum for effort required, so we can be sure we’re never committing less time than is possible.

Get Fuzzy

With the base numbers above, we can start to add a guess for the effort required on the unknowns. We like to use a best case and worst case scenario to define the limits on the estimate. We’ve been in this business long enough to know that even problems that look difficult can have a simple solution. (And yes, sometimes the problems that appear simple can be incredibly difficult.)

The knowns from above define the absolute baseline for the work required. We know that no matter what we estimate for the unknowns here, we can never go below the time we know a feature will take.

Our initial estimates tend to have a very wide range between the best-case and worst-case scenarios. We want to make sure that at the top end that we’ll be able solve all problems we’ve identified in addition to the ones we haven’t found. At the same time we  want to be optimistic that we could find simple ways to solve some of the problems. It’s not unusual for the spread between best and worse case estimates for any large feature to be several weeks in length (depending on the size of the project).

Anticipate Change

After all of the work above, we have a pretty good idea of the ranges for what it will take to solve the particular problem we’re presented with. While there are things we won’t understand, we usually do a pretty good job of figuring out the parts of the project that need clarification and can base on top of that.

However, most times even this isn’t enough. When a customer asks “How much will it take to build it?”, generally the idea they present to us isn’t fully formed, even if it appears to be so. We can provide an estimate for the requirements we’re given, but we know that once the customer gets to actually use the software, their needs generally have a habit of changing.

Changes are beyond the scope of the estimate we provide, but in reality, the true purpose of an estimate is to set expectations between two parties. By clearly communicating our estimate process and working closely with our customers to identify the unknown parts of software project, together we can discover the solution that “just works” to solve their problem.

For further reading on this, here’s a list of articles we recommend:

Build the right stuff

Source: http://osocio.org/message/nothing_replaces_water/

Let’s say you have an idea for the next killer app. You have this great idea to build an application that will let people find local hot dog stands and purchase hot dogs from their computer or mobile devices. You plan to allow people to specify condiments, time to pick up their hot dogs and leave a name and photo so the owners can get to know their customers. Being a big fan of the hot dog stands yourself, this sounds like an excellent idea for an application, and it probably is.

After many meetings and a long development and testing process with us, you’re ready to launch. You’ve invested many thousands of dollars to build every feature you have in mind and launch the application fully-featured on day one, your name and photo feature being one of the core aspects of the application. Your application is live and all you have to do is sit back and wait for the money to roll in.

If only it were that easy.

Unfortunately, it’s not up to you to decide what the market wants. Great applications are built through trial and error and are not born without flaws. Every great application or website you can think of has been built based on user feedback and testing to discover what works on a large scale.

What if you discover, instead of spending thousands and thousands of dollars to develop the name, photo and online ordering features of your hot dog stand app, that your users really only care about finding out where the hot dog stands are located? Imagine how those thousands could have been put to better use developing features you know users will love, or better yet, kept and not spent?

When we start a project, we instantly look to identify the core idea of the website or application. We try to convince our customers to build to this core idea first and launch quickly. Known as the Minimum Viable Product (MVP), it lets our customers get into the feedback cycle as quickly as possible, so they can identify what it is that works and be smart about building the right application at the right time.

Hello World!

Source: http://www.flickr.com/photos/oskay/472097903/

We’re a small team of passionate developers. We enjoy building software that works well, which means using restraint to keep our featuresets small and sharp. We’ve learned quite a bit through our years of working with Ruby on Rails and we’re excited to finally have a place to share all that we’ve learned. Stay tuned for more!