Fingertips

A quick note on dependencies in Ruby on Rails projects

Fri, 11 Jan 2013 11:46:24 +0100

In response to the latest Ruby on Rails security announcement we upgraded all of our clients’ Rails projects in less than 36 hours. On average it took around 30 minutes to upgrade a project from checkout to deployment.

On Twitter we mentioned our ‘minimal dependency policy’ in projects as being one of the reasons we could move so quickly. We got some questions about what that means exactly.

First off it’s important to note that this policy is not something we’ve printed on a sign and hung on the wall. It’s just one of practices that’s part of the culture at Fingertips.

It’s surprisingly easy to follow; when you work on a new feature and want to add a dependency you ask yourself if you really need it.

Please note that in this context, a dependency can be an external library, a piece of code you copy from another project into `lib/`, or even requiring something from the standard library.

Second guess yourself. Do I really, really need this?
Will this solve my problem? Does the library I want to use fit my problem really well or am I better off writing 20 lines of code myself? For example: pull in Devise or use HTTP basic authentication.
Should I use this particular library? Sometimes using another library allows you to drop one you were using for another feature. For example: use OpenSSL for both certificate signing and random token generation and drop Mongoid::Token.
Check if the new dependency has dependencies itself and weigh it against the benefit of using it. For example: use Net/HTTP for that one HTTP call instead of depending on HTTParty.

Minimal dependency is not just about the number of libraries you use, but also about the total amount of code you pull into your project. Less code means less bugs.

It will also give you less trouble with interdependencies when you try to upgrade. For example: Rails needs Rack 1.4, but Resque requires Sinatra and Sinatra doesn’t run on anything newer than Rack 1.3.

Finally, less dependencies makes long-term maintenance easier because there is less that can go wrong when it’s time to upgrade to a new major version of Rails. For example: if you depend on will_paginate in your Rails 2.3 project, you’ll need to use a newer version for Rails 3.2 which has a slightly different API.

Boss guide to installing Ruby on Rails

Fri, 28 Sep 2012 16:34:54 +0200

Every once in a while my boss asks me for help getting a Rails project running on his shiny new MacBook Pro. I’ve made him this guide to make sure he won’t waste my time again. It might come in handy for your boss too.

Please note that we assume the machine is running a clean install of Mac OS X Mountain Lion (10.8).

Install Xcode

Launch the App Store and use it to install Xcode. Start Xcode and follow the directions to complete the installation. Then choose Preferences from the Xcode menu and click the Downloads tab. Install the Command Line Tools.

The Download tab in Xcode's Preferences.

Grab something to drink and watch your favorite YouTube video. We’ll have to wait for this to download before we can continue.

Install Ruby

First, enter this command in the Terminal to make sure the default Xcode location is set:

sudo xcode-select --switch /Applications/Xcode.app

We’re going to use rbenv to compile and manage Ruby versions. Even when you’re planning to use a single version of Ruby, this is still the easiest way to set it up. The rbenv instructions suggest we use Homebrew, so we’ll get that first:

ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"
brew tap homebrew/dupes
brew install apple-gcc42

brew install git rbenv rbenv-gemset ruby-build
echo 'eval "$(rbenv init -)"' >> ~/.bash_profile

Now quit and then open your Terminal again to make sure your bash profile gets reloaded. For this example we’re going to install Ruby 1.9.3:

rbenv install -list
rbenv install 1.9.3-p194
rbenv rehash

Get your Rails app running

It’s reasonable to assume your Rails app runs at least version 3 and that you’re using Bundler for dependency management. The rbenv gemsets feature allows us to isolate a set of gems specifically for our project. We start by configuring the Ruby version and the name of the gemset for this application (replace “[project-name]” with the directory name of your Rails project):

cd [project-name]
echo "[project-name]" > .rbenv-gemsets
echo "1.9.3-p194" > .rbenv-version

Now make sure everything worked and is in the right place:

which gem

This should return /Users/[your-username]/.rbenv/shims/gem. We’re ready to install the dependencies for your Rails app:

gem install bundler
rbenv rehash
hash -r
bundle install

Troubleshooting compilation problems

Compilation might fail when one of the dependencies is using Quartz (i.e. ImageMagick) and the X11 directory isn’t in the library load path. The easiest way to fix this is with a symlink:

ln -s /opt/X11 /usr/X11

Reader questions

Javier Vázquez from Zürich, Switserland would like us to explain how to install PostgreSQL.

The easiest way is to install Postgres.app. You can download it from postgresapp.com. After that you configure it in config/database.yml like so:


development:
  adapter: postgresql
  encoding: unicode
  database: [project-name]_development
  min_messages: warning
test:
  adapter: postgresql
  encoding: unicode
  database: [project-name]_test
  min_messages: warning

Example database configuration.

Don't forget to replace [project-name] with your project name.

How to add Notification Center support to your website or app

Fri, 27 Jul 2012 20:07:58 +0200

Originally introduced last year in iOS 5, Notification Center is one of the more useful new features in OS X Mountain Lion. What’s really nice is that the ability to show notification banners isn’t limited to native applications; both Safari and Chrome allow websites to show alerts in Notification Center as well.

This is a quick and straightforward guide to adding Notification Center support to your website or web app.

Step 1: Request permission

Your web app can’t show notifications unless the user has explicitly granted it permission to do so. In Safari, permission is requested using a modal sheet dialog, while Chrome displays a banner at the top of the page.

Safari and Chrome requesting permission.

In Safari, users can manage notification permissions in the Notifications Preferences tab:

In Safari, the Notifications Preferences are easy to find.

In Chrome, users have to click “Show advanced settings…”, click the “Content Settings…” button under “Privacy”, scroll down to “Notifications” and then click the “Manage exceptions…” button:

In Chrome, not so much.

There are a few security-related limitation you need to keep in mind when you’re implementing this process:

You can only request permission as the result of a direct user interaction such as clicking a link or a button.
Once you’ve requested permission to show notifications and the user has either allowed or denied, there’s no way you can request permission again. The user can however change or remove the notification setting for your site in the browser preferences.

One other thing to keep in mind is that Safari does not first require permission when it’s showing a HTML file opened from disk. So, make sure you’re testing on a local webserver during development.

The first to do is detect whether notification support is available:

if ('webkitNotifications' in window) {
  // Notification support is available
}

Then, call webkitNotifications.checkPermission() to get your current permission status. The result will be 0 when the user has already granted you permission to show notifications earlier, 1 when you haven’t yet requested permission, and 2 when the user has denied permission.

Only when the permission check returns a 1 should you show an interface element for the user to enable notifications. Call webkitNotifications.requestPermission() when this interface element has been activated. Requesting permission is asynchronous, so you’ll need to include a callback to handle the result.

$('#request button').on('click', function() {
    webkitNotifications.requestPermission(function() { 
      if (webkitNotifications.checkPermission() == 0) {
        // Your user granted you permission to show notifications
      }
    }) 
  })

Step 2: Show notifications

When you have permission (webkitNotifications.checkPermission() should return 0), you can create a notification object with a title and a body:

var notification = webkitNotifications.createNotification(null, 'Hi there', 'I’m notifying you about something that happened just now.');

You probably want to add a callback handler for when the user activates the notification (you can also set handlers for display, close, and error events):

notification.onclick = function() { 
  // Show the item you notified your user about
}

And finally, you can show the notification with:

notification.show()

We’re currently consulting on Charm. Adding support for Notification Center took a little over an hour total.

That’s pretty much all there is to it. For more information, see the original Chromium draft specifications, but note that specifying your own icon image and the HTML notification type is not supported on Mountain Lion.

Demo

Here’s a simple but complete Notification Center demo:

Sorry, this demo only works in Safari or Chrome running on OS X Mountain Lion for now.

View the source of this page to see how the demo is implemented.

Functional View and Controller testing with RubyMotion

Tue, 17 Jul 2012 13:55:37 +0200

Eloy Durán, our lead Mac OS X and iOS engineer, recently wrapped up a consulting project for RubyMotion, a toolchain that lets you develop native iPhone and iPad applications using the Ruby programming language.

As part of this project he designed and developed a functional testing layer that allows RubyMotion developers to define integration test scenarios for their views and controller code using a very high-level domain specific language.

To help RubyMotion developers get started with this new feature, we also produced the following video which introduces the new feature and shows RubyMotion developers how to use it.

Download from Vimeo

This is one of the advantages of hiring us; not only do we offer outstanding design and high quality development work, we’re also able to produce compelling content to educate your existing customers about new features, and to help you promote your product to potential new customers.

A conversation with Thomas Fuchs about working with us

Wed, 06 Jun 2012 15:45:40 +0200

On our rather lengthy sales page, a few clients share what it’s like to work with us. These stories were done by Kelly Parkinson of Copylicious. We’d ask the client and she would schedule a phone call to talk about their experiences, have everything typed up, and then edit it down.

The conversation she had with Thomas Fuchs was done over instant messaging. I recently came across the transcript and noticed that it contained a lot of interesting stuff that didn’t make it into the final story. Even though it’s almost a year old I’d like to share it here to, well, make it easier for you to decide whether or not you should hire us.

Here’s the full interview:

So you and Amy know a lot of developers. Why did you choose to work with Fingertips in particular?

Well, besides that we know them personally, they’re really awesome. They have an almost anal attention to detail.

I would think that everyone in that line of work would have an almost anal attention to detail. Is that not actually the case?

No. Most design and most code is actually pretty bad.

Is it that most people don’t know what they’re doing, or that they don’t put much thought into it?

Most consultants are just in it for the money and don’t really like the work they’re doing.

Fingertips is different, as you can tell by them making their own products and doing open source projects to scratch itches. I’d place them in the upper 1% percentile of development and design shops. Plus, they’re not pretentious or artsy-fartsy.

Follow-up question: If you didn’t know each other, what signs would you look for, secret signs that “these guys get it?”

So what I like most is that all of them can get to the technical nitty-gritty details and have insanely in-depth knowledge.

They release a ton of open source software; that is actually highly polished (which is very rare for open source). It’s just stuff they needed for development and decided to share, but in a polished way.

They write amazingly detailed and well-reasoned tests when writing code, even for the OSS stuff they do. And they share their knowledge with blog posts etc.

Most companies don’t do any of these things, and Fingertips are just 3 people. I think this shows just how dedicated they are to create amazing software.

So if you could put a value on tons of in-depth knowledge combined with being insanely anal about details, and you took the project they’ve helped you with, what range of numbers would you come up with? So, for example, if you didn’t have them, how much more would you have spent? How much more can you earn?

That’s hard to say. The main thing is that I don’t need to explain stuff in the last detail and they still come up with a perfect solution. And then it turns out to be really robust as well, requiring little or no changes or bugfixes later. They’re also quite fast, which helps.

Are you able to say what that project was?

Sure, they implemented the freelancer feature for freckle. This feature might look easy on the outside, but it required a complete overhaul of our permissions structure and new features in the API. So it basically touched all really important guts of the app.

And they where able to pull it off really easily, without any hand-holding, not only the technical solution but also including the UI design.

Will this save you from cancellations of people who needed a team but didn’t consider themselves a team, so they didn’t want to upgrade?

Yes, this was one of the most requested features in Freckle. Definitely gives us and edge.

How much time would it have taken you to develop it yourself? Given your current workload etc.

Forever. :)

We really have better things to do, like coming up with new applications.

Right, and you seem pretty entrepreneurial, like you want to keep moving, and maybe it’s not the best use of your time to keep making improvements to the stuff you’ve already built.

If you were starting Freckle from scratch today, do you think you would have involved them? Or in what ways do you think you could see them becoming involved?

No, because we wouldn’t have had the money. We will however hire them to implement a specific complex component for our next product, Charm. Because they are so great with the details and knowledgeable, they’ll implement a very important part of our backend for us there too.

If you could dream up the ideal client for Fingertips, what would that be like? What would be their situation, at what point would they say, “okay, we definitely need to bring Fingertips in right now?”

They’d have some software product where they have a really difficult problem (either technical or with the UI) and/or want to be on the cutting edge technology-wise (like with all the fancy new HTML5 web stuff or native iOS development).

And they want someone who’s really into this stuff but at the same time is serious about business and is not fooling around.

At what stage in development is that? Is it already partly built, or is it just a gleam in their eye?

That depends, I think. I guess it can be at any stage. It’s certainly good that we hired them for the freelancer feature, because we now have a super-solid base for permissions in freckle.

There’s probably a lot of anxiety that comes up when people are thinking of hiring someone, because you never really know what’s going to happen until you’ve worked together. If your friend/colleague was thinking of hiring Fingertips and they voiced some fears or objections, what do you think the objections would be, and what would you say in response?

I think the most common fear people have, besides technical skills, is that work will be too late, too unprofessional or over budget; or that one person doesn’t know what the other person is doing. We’ve not had a single of those issues with Fingertips.

They’re really, really good at what they do, they’re timely, professional, and punctual. They’re also the only development company that we’ve referred our clients to.

We completely trust them, and would refer them to anyone, putting our reputation at stake.

What were you able to do with your business as a result of working with Fingertips that you wouldn’t have been able to do working with another firm or developer?

I think being worry-free is the best answer to this question. Like I gave them a job to mess with the internals of our most important product, and wouldn’t even have to check twice what they’ve delivered; plus we haven’t had any issues afterwards.

I also didn’t have to explain to them everything twenty times, and what they delivered was exactly what we wanted.

You said you considered them to be in the top 1% of firms. What percentage of projects would you say has bugs afterwards, typically? Not their projects, but other projects.

Well, all software has bugs.

But there are other factors, like how cleanly code is written, how understandable it is for other developers and how we can move on and support future feature with it.

At the same time, development environments and languages are always improving, and they are on the ball with that.

For example, they know what the latest browsers can do, and how to use these features to your advantage. But they also know what’s still too experimental, and then they’d recommend against it.

How to add a Help Book to a Mac OS X Preference Pane

Tue, 05 Jun 2012 10:48:01 +0200

Normally you can register a Help Book in your Cocoa application by setting CFBundleHelpBookFolder and CFBundleHelpBookName in your Info.plist. When the application is launched the runtime automatically loads the Help Books based on this information.

When an application loads additional functionality from a plugin bundle as is the case with preference panes it doesn't automatically load Help Books from the plugin. The plugin needs to take care of this itself.

Authoring a Help Book is no different from a normal application. The developer documentation is a bit flakey here and there, in general it gives a good overview of how to do this. I assume you've succeeded in creating a Help Book and it's called MailServer.help. Make sure that it's copied over to the Resources/English.lproj/MailServer.help folder in your bundle.

Now you add our Help Book to the Info.plist as you would in a normal application.

<key>CFBundleHelpBookFolder</key>
<string>MailServer.help</string>
<key>CFBundleHelpBookName</key>
<string>Learn to use MailServer</string>

Newer versions of the Xcode plist editor show these keys as ‘Help Book directory name’ and ‘Help Book identifier’.

Note that the CFBundleHelpBookName has to match the title for the Help Book you specified in the main HTML file.

<meta name="AppleTitle" content="Learn to use MailServer">

If you want a specific part of the documentation to show up in the Help menu when the preference pane is loaded you can also define this in the Info.plist.

<key>NSPrefPaneHelpAnchors</key>
<array>
  <dict>
    <key>anchor</key>
    <string>mailserver_help_index</string>
    <key>title</key>
    <string>Learn to use MailServer</string>
  </dict>
</array>

You can define multiple anchors. They will open the Help Book near the anchor in your HTML.

<a name="mailserver_help_index"></a>

This anchor can reside anywhere in the Help Book. The Help Viewer knows where to find it using the help index you generated as part of the Help Book.

Now add the Help Book to your Xcode project as described in the documentation. If you did this properly it will show up in your application bundle in Contents/Resources.

To complete the magic summoning of the Help Books you register it with the Help Manager.

- (void) mainViewDidLoad {
  if (![[NSHelpManager sharedHelpManager] registerBooksInBundle:[self bundle]]) {
    NSLog(@"Failed to register the Help Book for MailServer.prefpane.");
  }
}

If this fails you're basically on your own. There are a few things you can try though. I've notice that both the Help daemon and the Help Viewer are rather needy when caching. Every time I changed anything to my code or to the bundle I made sure all the caches were gone and helpd was fresh.

$ sudo killall helpd
$ rm -Rf ~/Library/Caches/com.apple.help*

For a working example you can check out the Passenger Preference Pane project on GitHub.