April 2011 Archives

Ch-ch-ch-ch-changes

Quickly now, without too much thought about it (unless you insist), reply with the top three things you would change about Perl (the language, not the community) if you could.

NERDTree on Startup

If you use vim and you have haven't seen the excellent NERDTree plugin, you should really check it out.

I wanted NERDTree to automatically load if I start vim without arguments, so I added the following to my .vimrc:

function! StartUp()                                                                                                                                                                                         
    if 0 == argc()
        NERDTree
    end
endfunction

autocmd VimEnter * call StartUp()

Very handy. I expect I might be adding more to my StartUp function in the future.

As a side note, it installs via a Rakefile, but if you don't have Rake available, I hacked the Rakefile to make this installable via bog-standard Ruby:

require 'fileutils'                                                                                                                                                                                         
require 'find'
require 'pathname'

IGNORE = [/\.gitignore$/, /Rakefile$/]

files = `git ls-files`.split("\n")
files.reject! { |f| IGNORE.any? { |re| f.match(re) } }

vimfiles = if ENV['VIMFILES']
             ENV['VIMFILES']
           elsif RUBY_PLATFORM =~ /(win|w)32$/
             File.expand_path("~/vimfiles")
           else
             File.expand_path("~/.vim")
           end
files.each do |file|
  target_file = File.join(vimfiles, file)
  FileUtils.mkdir_p File.dirname(target_file)
  FileUtils.cp file, target_file

  puts "Installed #{file} to #{target_file}"
end

Update: fixed my thinko after Aristotle pointed it out.

The 1% Testing Solution

I recently wrote about 80% hacks and this post is closely related to that. The overall concept is "don't let the perfect be the enemy of the good".

When it comes to identifying issues in building tools, we often think of a "perfect" solution and then try to implement it. Business objects to this because they want to develop products, not test code. Developers object to the business because they want to know their code works. This tension is very difficult to resolve, so I fall back on my favorite example:

sub reciprocal {
    croak "Reciprocal of 0 is not allowed" unless $_[0];
    return 1/$_[0];
}

Right off the bat, I could see people writing two tests for that: one for zero as an argument and one for a non-zero argument. And you know what? That will get you 100% test coverage on this function and that's where the whole "know their code works" argument falls down.

The one thing you must know about the perl.beginners list

Peter Scott recently emailed the regular reminder to people that the perl.beginners list was created to be a completely flame-free environment.

This means that if someone has posted a completely RTFM question, you can point them to the answer, but that F had better be fracking silent.

See what I did there? I used an "F" word. Why? This is my fracking blog. If you don't like my "F" word, too bad. It's my fracking blog. Not yours. Mine.

Similarly, the perl.beginners mailing list is probably not yours. While some of the people responding to Peter Scott's email had perfectly valid reasons why being overly gentle isn't always a good thing, the overriding point is simple: the blog was created to be a flame-free environment. If you object to that, that's OK. However, you're probably not the list creator and thus, you don't get to make the rules.

If you don't like the rules, that's OK. If you can't play by the rules, it's not. I thought people were taught this when they were five years old, but obviously I was wrong.

2011 Perl QA Hackathon - Day 2

Different languages are suited to different things. We know this well and we remind people about it from time to time. For example, Erlang is a great language for running a massively concurrent system, but the language itself is rather slow, so it would be awful for performance-intensive procedural work.

By a similar token, there are some things for which Perl is simply not the first choice. If you want to write a rich, cross-platform GUI application, there are a number of choices, but Perl's not your best one by a longshot. I once timidly suggested that a GUI toolkit be pushed into the core to resolve this and I was shot down immediately for excellent technical reasons which nonetheless relegate us to a non-contender in this arena.

If you have an interesting idea for a Web-based application that you want to quickly prototype, PHP is an excellent choice. Many reading this blog would argue in favor of Perl because, after all, we know the "right" way of writing Web apps with proper separation of concerns and all that and PHP is, well, just ugly, right? Meanwhile, we tell people with a straight face that it's also OK to write quick and dirty hacks to get work done, so long as that quick and dirty hack isn't PHP. Everyone in the world quickly listened to us and now PHP is practically ancient history. (Why doesn't HTML have a <sarcasm/> tag?)

Meanwhile, Andy Armstrong found himself needing to process a rather large XML schema from Final Cut Pro and, since he loves Perl, figured it would be a quick and easy task. After all, plenty of languages have nice XML integration to let you quickly throw XML schemas at it, get some objects, change them, and write the XML back out.

Except Perl. (bear with me for a moment)

2011 Perl QA Hackathon - Day 1

At the Hackathon here in Amsterdam and am using this to clear out my bug queue. This is raising several of my gripes about CPAN's RT setup.

  • When I resolve a bug, there's a select list for "update type" and this select list only allows me to "reply to requestor". FAIL
  • Long, beautifully formatted pieces of code in the text areas lose their formatting on the Web page.
  • I want a "really close this ticket and don't let this person reopen it by replying" option.

There should be a new version of Test::Differences on the CPAN soonish and it's also on github. Fork at will.

If your feature request is complicated or I'm just too dumb to understand it (more common than I like to admit) and you don't a patch or tests to send me, there's a good chance it will be ignored. My bandwidth is limited enough even with patches (which I have to read, evaluate, apply, test and release).

2011 Perl QA Hackathon

So the 2011 Perl QA Hackathon is happening here in Amsterdam and sponsored in part by my employer, Booking.com (what? You want to sit by a canal here in Amsterdam, eating bitterballen, drinking Grolsch and loving life as an expat? Drop me a line because we're still hiring). This will give me a chance to catch up on a fair amount of code I've been neglecting (testing related and otherwise). Of course, I think I have a damned good excuse for not being as "present" in the community as I otherwise could be the last couple of months:

Our beautiful daughter

That being said, I still want to apply some long-neglected patches to Test::Differences and other modules.

I also have a few other ideas up my sleeve, but we'll see how much time we have.

About Ovid

user-pic Have Perl; Will Travel. Freelance Perl/Testing/Agile consultant. Photo by http://www.circle23.com/. Warning: that site is not safe for work. The photographer is a good friend of mine, though, and it's appropriate to credit his work.