I haven't updated about Veure in a while and though this post isn't really about Veure, per se, I'll use some code from it to illustrate a "thin controller."

There's a lot of confusion about the thin controller/fat model advice which gets passed around. In fact, I've seen some developers get upset about the idea, claiming that it's the model which should be as thin as possible. I'll explain what's really going on and give some real-world examples, using code from Veure.

Back in 2001 I was working for a company who had a client who was in a serious bind: the maker of their point of sale (POS) system suddenly jacked up the license fee to the point where our client would go out of business. They needed a new POS in 21 days.

We grabbed an open source POS system and identified all of the features it was missing that our client would need. Then it was 21 days of overtime and no days off. Back in the days of use.perl.org, I blogged about this hell almost every day. It was also, interestingly, the first project I wrote software tests for. The other main dev on the project was teaching me how Perl's testing tools worked and as the days went on, I found myself incredibly proud of seeing all of those tests pass and catching bugs I would not have otherwise caught.

Then disaster struck: we tried to actually run the software instead of just testing it. The Tk panels would appear, and then instantly crash again. Adding some debugging code showed that we had a bit of a mess because we unit tested the code. The different parts of the software were isolated in our testing. The individual bits worked fine, but they had no idea of how to talk to one another.

Passing bad data around is an incredibly common source of bugs. In Perl 6, this is not only easy to avoid, but the tools to do so are also far more powerful than most mainstream languages.

What follows is drawn from my Perl 6 for Mere Mortals talk.

Different people have different workflows with git. Mine is pretty simple.

1. Branch from master
2. Hack, hack, hack,
3. git stash; git checkout master; git pull --ff-only; git checkout $branch; git rebase master; git stash pop
4. Goto step 2 until done

That step 3 is pretty damned annoying. I try to keep branches short-lived, but I often rebase onto master to ensure a clean merge. Thus, I wrote git-refresh. It does step 3 for me. However, my git-fu is sorely lacking (and my bash scripting ain't great either), so suggestions for improving this code are welcome.

#!/bin/bash

# vim: filetype=sh

prog=$(basename $0)
branch=$(git rev-parse --abbrev-ref HEAD)

if [ "$branch" == "master" ]; then
  echo Already on master. Exiting.
  exit 0
fi

need_to_stash=$(git status --porcelain|grep -v '^??')
if [[ $need_to_stash ]]; then
  git stash save "stashed by $prog"
fi
git checkout master
git fetch -p
git pull --ff-only
git checkout $branch

if [[ $(git rebase master) ]]; then
  if [[ $need_to_stash ]]; then
    git stash pop
  fi
else
  echo git rebase failed.
  if [[ $need_to_stash ]]; then
    echo You have changes stashed by $prog
  fi
fi

By now you've heard the announcement that the Perl 6 team is cautiously hopeful that Perl 6.0.0 will be released this year. There are three things they need to finish:

• The Great List Refactor (which should improve performance)
• Native Shaped Arrays (tell Perl 6 that you only have 10 elements and you'll get an exception if you add more)
• Normalized Form Graphemes (solves some issues with combining characters in Unicode, such as the little-known "tapeworm operator" "\x{1F4A9}\x{0327}")

With those, Perl 6 will truly be born. Of course, it will need better documentation, tooling support, better modules, and so on.

From what I can see, Perl 6 actually has a chance to take off and there's one delightful little feature that I want to talk about.