You can easily fix this by typing the following into your command line:

defaults -currentHost write -globalDomain AppleFontSmoothing -int 2

 

You can try int 1 to 3 (to play with various levels of font smoothing, I found 2 to work best for me).  To remove the setting just open the Appearance app (inside the Control Panel) and at the bottom you’ll see LCD font smoothing with a [-] inside, click it off and back on and it’ll show up as an [x] (and you’ll be back to where you started).

You may have to quit and restart your application before you see the effect.  I tested it out using my terminal application since that’s something I use quite a lot and not having nice smooth fonts in it makes me cry. 

Below are two screen shots to demonstrate the difference.  Notice how the first image shows 3 columns of text, while the second only two.  This is because in the first screen shot (with no font-smoothing) the fonts take up just a few pixels less space, as smoothing adds a few pixels to each font to fill them out so they’re more readable on an LCD screen.

Before tweaking fonts appear incomplete and with fuzzy edges.

The screenshot below matches what I normally see on my montior’s laptop. Fonts are bold and character are filled out fully (no fuzzy edges, offsets or bleeding).

After tweaking the fonts are properly smoothed on my external monitor.

Faster Test Suites

Nick Gauthier gave an impressive talk on reducing the execution time of a test suite.  The original suite took over 15 minutes to run.  Using factory_girl, shoulda and paperclip, he strongly recommended empty DB testing (no fixtures, all tests setup and tear down their objects/records), and the use of “no side-effect” test blocks.

Switching to the use of fast_context the execution time was brought down to 5 minutes.  Using perf_tools he found that calls to ImageMagic (from Paperclip) were calling out to the shell, taking a lot of time.  So he mocked those calls and brought it down to 3 minutes.

Using Hydra to do multi-core (concurrent) testing he brought execution time down to 1 minute.

Hydra is easy to set-up (no sockets or daemons to configure).  Just add a Rake task and configuration yml and you’re ready to use it.

When you run Test::Unit the Rails environment is loaded 4 times!!  Cucumber loads the environment twice.  RSpec and Hydra load it just once.

Further tweaking EXT4 journal_data_writeback and atime (access time) on the file system he got testing down to just 50 seconds.  Using Ruby Enterprise Edition (with the tmalloc) and more tweaks (this time to the Ruby _HEAP and _GC settings) he had tests running in 18 seconds.  A 4417% increase in performance!!

Check the comments below for a link to Nick’s presentation slides.  He’s been kind enough to provide the link!

Searchability

Luigi Montanez gave an insightful presentation on SEO.  He doesn’t believe that you have to be an “expert” in SEO.  You simply need to have good content and Google (or Bing) will handle the rest.  There are some things you can do though to make sure you don’t sabotage your pages when crawlers visit them.

Make sure you have a sitemap.xml (sitemaps.org) and a robots.txt (robotstxt.org).  These help crawlers know what to pay attention to and what to ignore.  Make sure you use either a www or non-www domain.  If you have both choose one and redirect to it.  You don’t want to have the site indexed under both.

When redirecting make sure you use 302 and 301 appropriately.  302 is for a temporary redirect, and Google/Bing will not index the page it’s redirected to.  Use 301 instead, if your intention is to have the page permanently moved.  Be cautious too because many web frameworks will use a 302 by default, instead of a 301.

Do not change your content by region, nor require cookies for someone to view content.  Also page titles are very important.  Always follow the “Page Title | Site Title” style (or you can replace | with a – or some other delimiter, just be consistent).

In your URLs dashes (-) are word separators, underscores (_) are not!  Make sure you are using dashes in your URLs!!  Take advantage of meta tagging, and Google Webmaster Tools.

Takeaway:

• Think like a searcher (search engine: crawler, index, rank)
• Optimize your title tags (they are the most important thing)
• Use Google Webmaster Tools (it provides valuable insight)

Components

Nick Sutterer gave a cool demonstration of Cells and Apotomo.  They allow you to create stateful widgets in your Rails views.

Padrino

Joshua Hull gave a talk on Padrino, another web framework built on top of Sinatra.  It takes a minimalist style approach (take what you need).  It’s light-weight and fast.  It has all the basic stuff you’d expect of  web framework including a simple mailer.

// in Java with import java.util.*; (so we can use the sort method)
String names[] = {"Nicholas", "Calvin", "Tank", "Karen", "Amanda"};
Arrays.sort(names);
System.out.println("The names sorted:");
for (int dex = 0; dex < names.length; dex++) {
    System.out.println(dex + ":" + names[dex]);
}

# in Ruby
names = %w(Nicholas Calvin Tank Karen Amanda)
names.sort.each_with_index { |x, idx| puts "#{idx}:#{x}" }

0:Amanda
1:Calvin
2:Karen
3:Nicholas
4:Tank

Both produce the same output, but Ruby handles Array and enumeration a lot better imho. The code is simpler and you don’t have to deal with silly for loops or include any special utility libraries.

Real Software Engineering

Glenn Vanderburg gave a great opening talk about software engineering.  he said software engineering doesn’t work.  He explores the roots of the idea of “software engineering” all the back to the first NATO Software Engineering Conference on the subject.  At the conference they described best practices as:

1. A software system is best designed if tests are interlaced with the software as it’s developed, rather than at the end.
2. Creates a simulation which matches the requirements, contains the control which organizes the design of the system.
3. Through successive repetitions of testing and design, the model ultimately becomes the software system itself.

Sound familiar?  He then talks about what went wrong, how did we start with what sounds like Agile and ended up with waterfall.  He talked about how the creator of waterfall process (Winston W. Royce) actually was trying to express he didn’t feel it worked.  His paper was so poorly written though that people (paying attention mostly to the fancy diagrams, and not the text) believed he was in favor of it.

Cost is *always* an object, and engineering is about what you can do with a dollar vs. what a “bumbler” can do with two.  Mathematical models are not supposed to be about correctness, but about saving on costs.  In traditional engineering you create models because it’s expensive to use up materials, labor, etc.  In software these things are extremely cheap and expendable, so mathematical models are less important.

Engineering is a science AND art.  It involves designing AND making, with cost AND elegance balanced.

Don’t build software as if it were bridges.  The source code *is* the design!  Customers are not paying for the source code.  It is the design of the software system.  Programs themselves are the models.  The customer in the end desires working software.

How to Build Awesome Teams

The guys from Hashrocket talked about their hiring process and what they felt made for great teams, core ideas:

• Hiring
• Transparency
• Community
• Methodology
• Environment

They frown on:

• Micro-management
• Penny pinching (they still budget)
• Death marches
• Meetings (daily stand-up, monthly mission control)
• Hierarchy
• Future-proofing

When they hire candidates they look for people who are smart and get things done.  They look for individuals who like to communicate, participate and contribute back to the community.  They need to be a cultural fit.  They look at their online presence, see what they’re Twittering about, review their work on GitHub (code, commit hygiene, etc).  They also require a candidate to subject themselves to a week long interview, where they pair program and go to after-hours with the team.

Keynote: Tom Preston-Werner (GitHub)

Today everyone can start a business on their computer.  What you need though is an idea.

• go to user groups (learn about people’s problems)
• drink (seriously, it makes you honest)
• find people you can work with (co-founders)
• build something you love (that inspires you)
• look for untapped potential (who are the early adopters, and how awesome can it become?)
• keep your day job (not having time is a poor excuse)
• fight entropy (keep it simple, and get stuff done)
• ship it (or you might as well not exist) [ship it squirrel]
• charge money (investors only care about money, not your company, so make customers your investors)
• have fun! (“drink-ups” where drinking is sponsored)
• never give it up (it’s going to be hard, don’t let fear hold you back)

If you want to have a $100,000 a year salary, you just need to get about 500 subscriptions at $12/mo (with a few premium or mid-level price options).  It’s totally realistic and in your grasp.  Don’t be afraid of not knowing something … people just like you started out with just an idea.

Getting and Configuring VIM

You can compile your own version of VIM (this is recommended) to make sure you have all the features and you can include Ruby Interpreter support by using [you can use CURL  or even just a ftp or web browser to get the archive, you may also need to run the make install as sudo unless you are already root]:

mkdir src
cd src
wget ftp://ftp.vim.org/pub/vim/unix/vim-7.3.tar.bz2
./configure --with-features=huge --enable-cscope --enable-rubyinterp
make
make install

Unless you’re on a wimpy system you’ll want to do nothing less than huge.  This will install vim and related files to /usr/local/bin (unless you specified otherwise when configuring).

Additional Information

PeepCode has some great videos on how to use VIM, for sale.  You can also a find some good ones on YouTube that are free, but your time/mileage may vary.

Tim Pope also maintains a great collection of VIM plugins that are useful for Ruby/Rails developers.

This is where yum history comes to the rescue.  (If you’re using a RPM friendly flavor of Linux, like Fedora or RedHat). You can get a history of what was installed by using

$> sudo yum history

Loaded plugins: presto, refresh-packagekit
ID | Login user      | Date and time    | Action(s) | Altered
---------------------------------------------------------------
47 | System <unset>  | 2010-07-08 11:54 | Update    |   11   
46 | <nicholas>      | 2010-07-07 22:53 | Update    |    2   
45 | <nicholas>      | 2010-07-07 22:50 | Install   |   49
44 | <nicholas>      | 2010-07-03 18:52 | Install   |    8
...more

You can then find out what was installed that day and remove it:

$> sudo yum history undo 45

I am going to try and finish up my new article series on Cucumber in the next couple of weeks, that I started back a few months ago. Thank you always for the comments, seeing people comment and visiting my blog helps inspire me to write more often.

I’m also considering adding a politics tab for my ranting on current news and the like.

Ozawa Sakuro has posted a fix for this on GitHub.  You can see the original thread here, or simply follow the directions below to quickly fix it without trolling through the entire discussion:

1.  Edit lib/bundler.rb:

4: require 'bundler/rubygems-ext'  # originally 'bundler/rubygems'

2. Next rename lib/bundler/rubygems.rb to rubygems-ext.rb and then edit the file and wrap the require in a control structure as shown below:

1: unless defined? Gem
2:   require 'rubygems'
3:   require 'rubygems/specification'
4: end

I’ve tested this fix and it works with Bundler 0.9.3.  Version 0.9.4 resolves the issue (thanks for the update Christian).  In any event I hope this little nugget of information helps reduce the hair pulling.

I’m as guilty as anyone keeping a stash of Chili Fritos (a favorite here in Texas) corn chips in my desk at work. This year I’m going to try and be more conscience as to what I’m eating though. I’ve come to understand over the last part of 2009 (especially due to Michael Pollan’s book ‘In Defense of Food’ and the recession, people losing their livelihoods because of corrupt politicians and businessmen). You choice of food doesn’t only affect your health, but it affects your local economy and the livelihoods of people worldwide.

Would you eat something with the following ingredients?

Rice flour, corn, sunflower oil with natural tocopherols added, whey, 
salt, maltodextrin, cheddar and blue cheese (cured milk, salt, enzymes,
annatto extract), partially hydrogenated soybean and cottenseed oil*,
butter (cream, salt), monosodium glutamate, lactic acid, disodium
phosphate, tricalcium phosphate, citric acid, gum arabic, 
natural flavors, annatto extract. *Adds a dietary insignificant
amount of trans fat.

Eating is more than just about your health.  Food isn’t just to provide nutrients.  Food should be eaten for pleasure, community and identity.  It should engage you with the natural world and make you appreciate and respect life.

User Stories

When thinking about a Cucumber feature you will want to relate it to a user story. If you’re familiar with Agile development stories are nothing new.  For those who are not though it’s not too complicated. A story is simply an expression of value generally in the form of:  ”As {a role} I want/need {to do some function} so that {business value}.” Generally the business value is best expressed in terms of: revenue generation, revenue protection, operational efficiency (cost savings).

For the example we’ll be using this story:

As a workshop co-ordinator I need to manage contact information so I can easily reference individuals and start communications with them.

You’ll notice that this story doesn’t imply implementation.  You generally never want to imply implementation in a story.  Also you’ll notice that the story is simple and comprehensible by pretty much anyone (business user, developer, average Joe Public).

Starting a Feature File

In our Rails application we’ll want to go inside our /features folder.  Create a new file called manage_contact.feature.  At the top of the file type in the following:

Feature:  Manage Contact
  In order to easily reference individuals and start communications with them
  As a workshop co-ordinator
  I want to manage contact information

Now we have our first feature.  The next step is to define some scenarios.  Scenarios express various actions the user might take in relation to the feature.  Below are some of the scenarios we came up with for this feature (these go below your feature entry – indented to be even to the “In order, As a, I want” section).  You don’t need to, but I like listing the scenarios in order of priority, this way a developer working on the feature can just start on top and work downwards:

Scenario: View list of contacts

Scenario: Add a new contact

Scenario: Email a contact from the list

Scenario: Remove an existing contact

Scenario: Update an existing contact

Scenario: Start an IM conversation with a contact from the list

Your finished feature file should look something like this gist. In the next post we’ll start to look at building out our scenario’s with step definitions, that is define what behavior we expect to happen with each scenario we have defined.