Bitcetera TechBlog

Eagerness

Mon, 08 Mar 2010 10:35:00 GMT

Don’t worry, this is not about greedy bankers, megalomaniac corporations nor currupt politicians – although I would love to have a simple fix for these at hand, too.

Simple Example

With eagerness I mean a simple yet important and too often unknown concept of regular expressions. Take this Ruby example, it would yield the same results in any other language such as JavaScript or even PHP:

"Hello Ruby friend".sub(/^(.*)e/,  'X')   # => "Xnd"
"Hello Ruby friend".sub(/^(.*?)e/, 'X')   # => "Xllo Ruby friend"

By default, the * quantifier is eager which means it will eat its way though the string until it hits the last subsequent e. If you want it to go no further than the first subsequent e, you have to put it in non-eager mode – and the question mark behind the * quantifier does just that.

The eagerness questionmark works behind any quantifier, but for obvious reasons makes sense only behind *, + and {n,m}.

“Fine, dude, but can we use this eagerness thing for anything real?”

Real World Examples

Yes, we can! If you are using Cucumber, chances are you find a step definition similar to the following in your code:

/^I am using rvm "([^\"]*)" with gemset "(.*)"$/

This works, but the “anything but apostrophe” construct is a little cumbersome – and utterly avoidable:

/^I am using rvm "(.*?)" with gemset "(.*?)"$/

As you see, this is both more readable as well as more consistent. (Okay, the question mark in the second group is not really necessary, but it doesn’t hurt and thing’s won’t break if you ever decide to add a third group.)

Bottom line: Eagerness may make the difference between a cumbersome and an elegant regular expression, at least if you belong to those who don’t think of the latter as a paradox. And as we’re all eager to learn, you might want to add eagerness to your regex toolbox.

If you liked this tip, you might want to take a look at the Regex in a Nutshell Cheat Sheet as well.

From ZenTest to autotest

Wed, 03 Feb 2010 16:05:18 GMT

Many people install the ZenTest suite only to get the autotest tool and thus carry around quite a bit of overhead. Yet, not any longer! Michael Grosser has released the autotest gem which contains an improved fork of only the autotest tool. (Should you ever need the full functionality of ZenTest, you can always install the zentest gem along with it.)

Following the “only happy developers do proper testing” mantra, the popular autotest-growl and autotest-fsevent gems as of version 0.2.0 released today no longer depend on ZenTest but on Michael’s autotest. Other new feature include support for more platforms and icon sets, see the CHANGELOG for the details.

If you are upgrading from versions prior to 0.2.0, you should uninstall ZenTest or things might show funky behaviour. Please refer to the README for more on this.

Inconsolata XL Font

Fri, 09 Oct 2009 16:32:23 GMT

Sound Familiar?

I’m sure you’ve heard this rap before: “You’re sleeping a third of your entire life, so you’d better get a really nice mattress.” However beaten that phrase may be, there is some truth in it. And guess what, as a software developer you might spend another nice chunk of your life in front of a code editor and Courier or Monaco just aren’t as good as it gets.

Inconsolata

Enter Inconsolata created by Raph Levien. It’s a monospaced font that reads exceptionally well even at small sizes and is equally suited for use with a code editor, the terminal or for reading non-HTML mails. However, Raph hasn’t added bold font weight yet. This is not usually a problem as many applications such as TextMate or the terminal render a fake bold if needed. Here’s a sample.

Oops, RubyMine

RubyMine on the other hand doesn’t and therefore I’ve derived a slightly bigger Inconsolata XL font which includes a rough bold variant. Just download, unpack and then move the two font files into your ~/Library/Fonts.

Downloads

Batch Update TextMate Bundles

Tue, 08 Sep 2009 11:10:57 GMT

Most bundles for TextMate are served by some form of version control system. Macromates uses Subversion for it’s official bundle repository whereas the Ruby herd relies more on Git.

Some bundles contain an update menu item and there are a few attempts out there to manage bundles altogether. However, with just a little console-fu, you can update all bundles at once:

find ~/"Library/Application Support/TextMate/Pristine Copy/Bundles" -name .git -execdir git pull --quiet \;
find ~/"Library/Application Support/TextMate/Pristine Copy/Bundles" -maxdepth 2 -name .svn -execdir svn up --quiet \;

To mimick the missing “auto-update all TextMate bundles” functionality, just put these lines in a cronjob.

Mock it Real Good

Tue, 11 Aug 2009 21:25:37 GMT

A few weeks ago I came across a blog post mentioning Balsamiq Mockups, an application to put together screen sketches, and as always my first thought was: “Do I really need a toy like that?” Now, several sketches and one presentation later, the answer is more “oh, yes” than I anticipated at first.

Paper and Pencil

Like many, I have outlined screens with some paper and a pencil until now. And I won’t mothball that pencil quite yet because it still has one huge advantage: It works in my favorite environment: on the beach. However, things tend to get messy as sketches become more numerous, complex and mature.

Therefore after the initial brainstorming, it’s a good idea to fire up an editor of sorts and morph the sketches into a state worthy of presentation. This is where Balsamiq Mockups comes into play.

It’s a graphics editor specially designed for screen sketches and comes with a set of UI elements which represent most of what you will need for an average (web) application. Additional UI elements can be downloaded and future versions might bring a larger UI library to start with. Once placed these UI elements can be tweaked, however, the variations are limited to what makes sense for that specific element. This streamlines the number of menus and buttons compared to more generic tools such as OmniGraffle or Adobe Illustrator and thus speeds up the sketching a big deal.

No False Hopes

Mock UI elements are not perfectly styled and don’t carry the look of any specific environment but resemble more what the good old pencil would have produced. This intentional lack of perfection makes it utterly useless to be pedantic and the resulting sketches don’t pretend to be anywhere close to a final product yet.

The impact of this last sentence only becomes clear once you present the sketches to non-techies such as that notorious guy from marketing or a potential user like I did a few days ago: You run next to zero risk of raising false hopes such as “wow, look at that beautiful screen, these guys are almost done with my app”. And at the same time you make it crystal clear that the sketches are just that – and most likely will see adjustments during implementation.

Need Some AIR

Only downside so far: Balsamiq Mockups runs on AIR which means you have to install Adobe stuff on your computer. This may hurt, after all, it felt so good when my Mac became an Adobe free zone many years ago. (Not entirely true after Adobe acquired Macromedia, but that’s another story.) However, after using the online trial for a while, the fun working with it outweighed my adobephobia. And AIR runs stable and does a pretty good job mimicking a native Mac OS X application.

The best way to testdrive Balsamiq Mockups is the free online version which also comes in handy if you want to send screen outlines to someone who doesn’t own the software and still would like to fiddle about your sketches. The downloadable AIR application runs on all major platforms.

Heredoc with Indent in Ruby

Thu, 02 Jul 2009 19:54:30 GMT

Heredocs come in handy when you have to deal with larger multi-line strings in the source code itself. However, it usually breaks the indents:

class Poem
  def initialize
    @text = <<END
"Faith" is a fine invention
When Gentlemen can see
But Microscopes are prudent
           In an Emergency.
(Emily Dickinson 1830-1886)
END
  end
  def recite
    puts @text
  end
end

But it wouldn’t be Ruby if there were no way to make this pretty. The minus in -END makes sure any whitespace before the end marker is ignored and the first six spaces of every line are cut when the string collected by heredoc is post processed with gsub:

class Poem
  def initialize
    @text = <<-END.gsub(/^ {6}/, '')
      "Faith" is a fine invention
      When Gentlemen can see
      But Microscopes are prudent
                 In an Emergency.
      (Emily Dickinson 1830-1886)
    END
  end
  def recite
    puts @text
  end
end

The result for both snippets is exactly the same – provided you stick to the recommended 2 spaces indent for Ruby source code:

>> Poem.new.recite
"Faith" is a fine invention
When Gentlemen can see
But Microscopes are prudent
           In an Emergency.
(Emily Dickinson 1830-1886)

Mac-friendly Autotest

Wed, 27 May 2009 09:20:51 GMT

autotest

ZenTest’s autotest is great, but it has one drawback: In order to detect whether you have modified a file, it relies on filesystem polling. In other words it constantly traverses the filesystem and thus causes a lot of CPU and harddrive load. Check this out:

$ autotest &
[1] 664
$ ps ax 664
664 s000 S+ 0:00.63 /usr/bin/ruby -ws /usr/bin/autotest
-- WAIT 1 MINUTE --
$ ps ax 664
664 s000 S+ 0:01.27 /usr/bin/ruby -ws /usr/bin/autotest
            ^^^^^^^

Eventhough you don’t do anything, the CPU clock for the autotest process keeps counting up. If you are working on a portable computer, you will notice that your battery runs out in no time. And that’s not even the worst part yet. Permanent filesystem cruising are poison for the harddrive will have an impact on it’s life expectancy on the long run.

autotest-fsevent

Enter the autotest-fsevent gem. It teaches autotest to use FSEvent instead of filesystem polling. Here’s the same test with autotest-fsevent installed:

$ autotest &
[1] 698
$ ps ax 698
698 s000 S+ 0:00.63 /usr/bin/ruby -ws /usr/bin/autotest
-- WAIT 1 MINUTE --
$ ps ax 698
698 s000 S+ 0:00.63 /usr/bin/ruby -ws /usr/bin/autotest
            ^^^^^^^

As you see the CPU clock is not counting while autotest waits for file alterations. Instead of monitoring the files itself, autotest-fsevent delegates this job to the FSEvent core service which Apple has introduced with Mac OS X 10.5. Think of FSEvent as a radio station which constantly broadcasts file alterations. It comes at no extra cost as it’s sitting right on the kernel.

Installation

First install the gem:

sudo gem install autotest-fsevent

Then add the following line after all other requires in your ~/.autotest:

require 'autotest/fsevent'

Please submit feature requests and bug reports on BitForge rather than adding a comment here.

Resources

Homepage
BitForge (Bugtracker, Forum etc)
Github

autotest-growl

ZenTest-4.0.0 comes with bundled Growl support which, however, will vanish very soon in favor of the autotest-growl gem which displays Growl notifications for RSpec, Unit::Test and Cucumber. And it comes with a cute set of colored Ruby icons which can easily be overridden by your preferred icon set.

Installation

Read the README for installation instructions as they differ whether your’re on ZenTest-4.0.0 or an upcoming version without bundled Growl support.

Please submit feature requests and bug reports on BitForge rather than adding a comment here.

References

Homepage
BitForge (Bugtracker, Forum etc)
Github

Exceptions

The only feature which hasn’t made it from the now deprecated autotest-mac gem into neither autotest-fsevent nor autotest-growl is the exception of certain paths. It’s in fact better if you set them yourself and according to your needs in ~/.autotest. Here is an example:

Autotest.add_hook :initialize do |autotest|
  %w{.git .svn .hg .DS_Store ._* vendor}.each {|exception| autotest.add_exception(exception) }
  false
end

(Sven Schwyn)

Pimp Your .autotest

Thu, 09 Apr 2009 14:24:20 GMT

This blog article is out of date, check out Mac-friendly Autotest instead.

BDD is Fun

Besides the positive impact on code quality, BDD has a fun factor of it’s own. It adds some immediate and colorful feedback to the work cycles and makes me feel like being the pilot of my code.

Setting things up is quite easy nowadays, but as many howtos out there have come to a certain age, here’s one for RSpec 1.2 and Cucumber 0.3. Test::Unit is supported as well. (This is work in progress, so please feel free to post your comments and check back as I’m going to update this post for a while.)

Requirements

This howto assumes that you are working on a Rails application and that your workstation is running Mac OS X with the latest and greatest version of Growl installed.

Installation

First install the gems necessary to work with Ruby on Rails applications:

gem install rspec rspec-rails cucumber webrat ZenTest

Webrat is optional, but you don’t want to miss it. Now define some environment variables:

echo "export AUTOFEATURE=true" >>~/.profile
echo "export RSPEC=true" >>~/.profile
source .profile

If you prefer to set these in your application, add the following lines to the top of config/environments/test.rb instead:

ENV['AUTOFEATURE'] = 'true'
ENV['RSPEC'] = 'true'

Next are the images which will be displayed in Growl notifications:

wget http://www.bitcetera.com/page_attachments/0000/0009/autotest_images.zip
unzip autotest_images.zip
mv autotest_images ~/.autotest_images

And finally create the configuration file ~/.autotest:

module Autotest::Growl

  def self.growl title, msg, img, pri=0, stick=""
    system "growlnotify -H localhost -n autotest --image #{img} -p #{pri} -m #{msg.inspect} #{title} #{stick}"
  end

  Autotest.add_hook :run_command do
    @label = File.basename(Dir.pwd).upcase
    @run_scenarios = false
    print "\n"*2 + '-'*80 + "\n"*2
    print "\e[2J\e[f"   # clear the terminal
  end

  Autotest.add_hook :ran_command do |autotest|
    gist = autotest.results.grep(/\d+\s+(example|test)s?/).map {|s| s.gsub(/(\e.*?m|\n)/, '') }.join(" / ")
    if gist == ''
      growl "#{@label} cannot run tests", '', "~/.autotest_images/ruby_grey.png"
    else
      if gist.match /[1-9]\d*\s+(failure|error)/
        growl "#{@label} fails some tests", "#{gist}", "~/.autotest_images/ruby_red.png"
      elsif gist.match /pending/
        growl "#{@label} has pending tests", "#{gist}", "~/.autotest_images/ruby_yellow.png"
        @run_scenarios = true
      else
        growl "#{@label} passes all tests", "#{gist}", "~/.autotest_images/ruby_green.png"
        @run_scenarios = true
      end
    end
  end

  # FIXME: This is a temporary workaround until Cucumber is properly integrated!
  Autotest.add_hook :waiting do |autotest|
    if @run_scenarios
      gist = autotest.results.grep(/\d+\s+(scenario|step)s?/).map {|s| s.gsub(/(\e.*?m|\n)/, '') }.join(" / ")
      if gist == ''
        growl "#{@label} cannot run scenarios", '', "~/.autotest_images/ruby_grey.png"
      else
        if gist.match /failed/
          growl "#{@label} fails some scenarios", "#{gist}", "~/.autotest_images/ruby_red.png"
        elsif gist.match /undefined/
          growl "#{@label} has undefined scenarios", "#{gist}", "~/.autotest_images/ruby_yellow.png"
        else
          growl "#{@label} passes all scenarios", "#{gist}", "~/.autotest_images/ruby_green.png"
        end
      end
    end
  end

end

Autotest.add_hook :initialize do |autotest|
    %w{.svn .hg .git vendor}.each {|exception| autotest.add_exception(exception) }
end

A few things to note here:

ZenTest does not yet really support Cucumber. However, this workaround does the trick if you use RSpec or Test::Unit as well.
The Growl message titles may be too long for some display styles, a good choice is “Music Video”.
The run_command hook clears the terminal every time before tests are ran, however, you can still scroll up to previous output. Every test run is separated with a line of dashes.
The “cannot run tests/scenarios” message is shown e.g. when you have a serious syntax error in your specs like do-end nesting typos.
The -H localhost argument is a workaround for a glitch which lets Growl 1.1.4 on Mac OS X 10.5 randomly ignore some notifications. However, it will only work if you check “System Preferences -> Growl -> Network -> Listen for incoming notifications”. (You’ll get a NSPortTimeoutException from growlnotify if you don’t do this.) Furthermore, when using this setup for the first time, you have to check “System Preferenes → Growl → Network → Allow remote application registration” as well. Once autotest is in the list of Growl applications, you can uncheck this again.

Usage

Just change into the RAILS_ROOT directory and fire up autotest:

autotest

Whenever you save a file of your Rails project, all relevant tests will be ran and you get both a Growl feedback and detailed test results in the terminal.

(Sven Schwyn)

10 Reasons why PHP is Still Better than Ruby ;-)

Tue, 07 Apr 2009 09:53:20 GMT

1. Safety

Remember Gregg and Jason in their Ruby on Rails vs PHP clips? The Rails guy goes to the beach while the PHP guy still tries to switch databases. Turns out hundreds of people die every year on beaches whereas the risk of dropping dead on your desk is next to nil. In fact, driving to work and most things you do during your spare time are far more life threatening than working on code and therefore the longer it takes, the better for your own personal safety.

2. Semicolon

Programming languages without a semicolon at the end of each line are like a fish without a bicycle. Nuff said.

3. DRY won’t Pay your Bills

Unless you’re workin on a project of your own, producing as little and maintainable code as possible will mainly DRY up your paycheck. You spend less hours copying and pasting, less hours fixing the same bug on ten different lines and less time finding bugs in the first place. But remember: Time equals cash when you’re contracted by the hour. So we should be grateful for PHP and frameworks like Zend which make it so ridiculously easy to write the most cumbersome code full of duplications.

4. Namespaces

Colliding classes which happen to have the same name can indeed become a problem, however, Ruby-style namespaces with module MyNamespace are by no means the only solution. The makers of PHP chose not to overload it’s lean syntax with such unneccessary keywords and urge coders to prefix the class name like class MyNamespace_MyClass instead.

Nevertheless, in order to satisfy those who still long for namespaces, PHP will support the namespace keyword as of the yet to be released version 5.3.

5. Goto

The presence of a goto language construct has been considered evil for decades now, yet not the keyword itself is evil but what a tiny minority of coders would use it for. In other words: Messy software developers are used as an excuse to discriminate the Methuselah of keywords.

Discrimination is fundamentally wrong! The makers of PHP have realized that and will will support goto as of the upcoming version 5.3 whereas for Rubyists the ruby-goto library (categorized Library/Evil) is not even available as a gem.

6. Elseif

Cascading if clauses contain at least one “else if” case, so the natural way to name this keyword is elseif – as does PHP. Ruby on the other hand uses elsif which is so much harder to remember.

7. Solid and Static Foundation

Ruby is a highly dynamic programming language which allows you to twist and tweak almost every aspect of it. Therefore all it takes is for someone to accidentially monkey patch the + method of Float and your application goes kaboom. PHP on the other hand has a rock static foundation which means array_uintersect_uassoc() does exactly what it sais, which is… well, check the documentation for that. And if you absolutely must change it’s behaviour, you can always write your own my_array_uintersect_uassoc().

8. Elegance versus Expertise

Andy Jeffries compares the following snippets in his blog post 4 Reasons why Ruby Syntax is Better than PHPs.

PHP:

$foo = array("zulu" => "1", "alpha" => "4", "golf" => "8", "bravo" => "3");  
$keys = array_keys($foo);  
sort($keys);  
$bar = array_slice($keys, 0, 3);

Ruby:

foo = {"zulu" => "1", "alpha" => "4", "golf" => "8", "bravo" => "3"}  
bar = foo.keys.sort.slice(0,3)

Admittedly, the Ruby syntax is more elegant and easier to read. However, if elegance is your aim in life, you’d better become a poet. Fact is that my granma could read and understand this piece of Ruby code whereas it takes a lot more expertise to figure what the PHP snippet is doing. Software developers should face the fact that they are paid for expertise, so making things hard to read – best coupled with poor documentation – will make you less disposable on the long run.

9. Less is More

The statistics of available extensions as of 2009-06-04:

Language	Appearance	Extensions	Ext per Year	Sources
Perl	1987	15461 distros	703 distros	CPAN
Ruby	1995	7326 gems	523 gems	Rubyforge and Github (forks not counted)
PHP	1995	749 packages	54 packages	PEAR and PECL

At first sight this seems to be bad news for PHP as it falls way behind the others with Ruby closing in on Perl. Then again in the real world with real customers it’s much easier to get a fair price for your software project if you can sell bits and pieces with: “There is no solution available out there, we’ll have to do it ourselves.”

10. Bugs are your Friends

You just have to learn how to sell them, too. Don’t believe the “half a product, not a half-ass product” stanza by the nice yet overly idealistic folks at 37signals (Getting Real, chapter 5). The real buck starts flowing once you force your customers to constantly upgrade or even contract your consulting services.

This said, PHP is the ideal choice. There are testing frameworks out there, even BDD has made it to the PHP world, but fortunately the PHP syntax is twisted enough to make the descriptions quite illegible. Compare the code samples from the two project webpages:

RSpec:

require 'bowling'

describe Bowling do
  before(:each) do
    @bowling = Bowling.new
  end

  it "should score 0 for gutter game" do
    20.times { @bowling.hit(0) }
    @bowling.score.should == 0
  end
end

PHPSpec:

require_once 'Bowling.php';

class DescribeNewBowlingGame extends PHPSpec_Context
{

    private $_bowling = null;

    public function before()
    {
        $this->_bowling = new Bowling;
    }

    public function itShouldScore0ForGutterGame()
    {
		// allow 20 throws
        for ($i=1; $i<=20; $i++) {
            $this->_bowling->hit(0);
        }
        $this->spec($this->_bowling->score)->should->equal(0);
    }

}

By working with PHP you can rest assured that 99.9% of the lines of code out there won’t come with tests and given the syntactical challanges that’s not going to change. Therefore, PHP is the perfect ecosystem for bugs to grow and continue to play an important role in selling bugfixing to customers.

(Sven Schwyn)

Easy Screencast Creation

Wed, 18 Feb 2009 13:18:30 GMT

If you’re tired of explaining the same things over and over again, then you might find this little application for Mac OS X and Windows very helpful: Jing. It allows you to create screenshots and screencasts from any area of your screen and add annotations or voice-over to it.

Once done, you can upload your image or movie either to the default provider Screencast (free within some bandwidth and diskspace boundraries), send them to a FTP server of your choice or save it locally.

Jing uses a simple interface and an original, but maybe not overly practical “sun” hotspot for invocation. However, on Mac OS X a setting exists which replaces the “sun” hotspot with a normal menu bar item.

(Sven Schwyn)