I’ll be offering a one day Intro to Moose class at YAPC::NA 2011 in lovely Asheville, NC. To register, log in to the YAPC::NA site and then go to purchasing page. If you haven’t registered for YAPC yet, you can buy your conference ticket at the same time too.

Intro to Moose

Join us for an interactive hands-on course all about Moose, an OO system for Perl 5 that provides a simple declarative layer of “sugar” on top of a powerful, extensible meta-model.

With Moose, simple classes can be created without writing any subroutines, and complex classes can be simplified. Moose’s features include a powerful attribute declaration system, type constraints and coercions, method modifiers (“before”, “after”, and “around”), a role system (like mixins on steroids), and more. Moose also has a vibrant ecosystem of extensions as seen in the variety of MooseX:: modules on CPAN.

This course will cover Moose’s core features, dip a toe into the meta-model, and explore some of the more powerful MooseX:: modules available on CPAN.

Students are expected to bring a laptop, as you will be writing code during the class. You will also be provided with a tarball a week or so before the class is scheduled, which will contain a directory tree skeleton and test files.

Yesterday I converted all of my (many) Mercurial repos over to Git. The reason for this has very little to do with my preference. I’ve used both hg and git quite a bit over the past few years, and both are quite good. However, the (FOSS) Perl community as a whole seems to have settled on git, and people complained about having to use hg with my code.

Setting up git reminded me of why I chose hg a few years back. I really like how hg uses http as its native protocol. Setting up repo browsing and remote access is fairly trivial. In particular, you can configure remote access using standard http auth configuration. Since I already had apache running on my server, and I already knew how to use htpasswd2, this was simple.

Git, on the other hand, really prefers ssh, so I ended up setting up gitolite for access control and Gitalist. This was more work than setting up hg was.

On the plus side, gitolite is a really nice tool. It provides easy integration with git-daemon, automatic remote repo creation, and easy to manage access control. The downside of gitolite is that it’s possible to push a change to the config file that locks yourself out of gitolite! Ouch. This is probably recoverable, but I ended up just wiping my gitolite install out and trying again.

Gitalist is leaps and bounds nicer than gitweb or hgweb, both of which looks like “an app made by hackers”. Gitalist is really nice looking, and it’s a pleasure to use. However, if you’re not familiar with how Catalyst apps work, it’s probably not that simple to set up.

Overall, here’s my list of plusses and minuses for both hg and git:


  • + Gitalist and gitolite beat anything available for hg
  • - You really need something like gitolite to manage access control if you have lots of repos
  • + The gitg program is way nicer than hgk (gah, Tk)
  • - git’s UI (it’s command set, basically) can be really weird
  • + git is infinitely flexible (rebase, squash, amend, …)
  • - git is infinitely flexible (rebase, squash, amend, …)


  • + Much saner UI – I think hg is just better thought out
  • - Having two types of branches really isn’t helpful – pick one, please
  • + Hg’s help/docs is much better. The git docs seem to present things in an entirely random order, instead of helping you do learn common operations first. Compare “hg help pull” to “git help pull” some time.

Both are excellent tools, but for Perl work it’s probably best to just choose the one “everyone” is already using.