♪ I’m a dinosaur, somebody is digging my bones ♪ – King Crimson

I just read a great article/talk by Charles Petzold that was recently (re-)posted on reddit. He talks about how Windows IDEs have involved, and how they influence the way one programs.

Reading it, I was struck by just how ancient the way I program is. I use Emacs, a distinctly non-visual editor. When I work on GUIs, I do it using HTML and CSS, which means I edit the GUI not using a GUI, but through a text interface. Then I have a separate application (my browser) in which I view the GUI.

My GUI development process involves tweaking the GUI definition (HTML & CSS), then reloading in the browser, and back and forth. All the actual GUI behavior is separate yet again, divided between client-side code (Javascript) and server-side (a Catalyst app, these days).

This is truly an archaic way to program. Not only is my editor archaic, the very thing I’m developing is a thin client talking to a fat server. Of course, with Javascript, I can make my client a bit fatter, but this is still very much like a terminal talking to a mainframe.

But I like programming this way well enough, and it seems to produce reasonable results. There are plenty of good reasons for deploying and using thin clients, and Emacs is an immensely powerful tool. HTML and CSS suck big time, but my limited experience with “real” GUI programming suggests that’s just as painful, if not more so.

But still, I feel like I’m old and grizzled before my time. Surely I should be using a powerful new-fangled editor with powerful new-fangled libraries. Bah, kids today and their GUIs!

Occasionally, someone will pop up and say that Moose really needs a book. “X looks good, but it needs a book before I can learn it” is a common meme among programmers.

This is crazy, of course. Demanding a book before you learn something means you’ll never learn a lot of things. Book publishing is a risky proposition for many topics, and with the surfeit of good documentation on the net, it’s getting harder and harder to justify a book for any given topic. Even for books that aren’t failures, writing a book is not a good way for an author to make money.

I put a ridiculous amount of time into the Mason book, and my estimate is that I made $20 per hour (maybe less). Of course, having a book looks great on my resume, but the direct payoff is low. At this point in my career, it’d be hard to justify the effort required to produce another niche book, even assuming there was a publisher.

But the real point of this entry is to highlight just how much free documentation Moose has. A commenter on a previous post mentioned that he or she had created PDF output of the entire Moose manual. There are two versions at the link with different formatting, the shorter of which is about 58 pages. This is just the manual, not the cookbook. I imagine if the cookbook got the same treatment, we’d easily have 100+ pages of documentation. That doesn’t include the API docs, this is all stuff that might go in a book (concepts, recommendation, examples, recipes).

So please stop asking for a Moose book, and just read the one that already exists!

The latest release of Moose, 0.69, marks another completed deliverable in the Moose docs grant. For this release, I finished revising every cookbook recipe in the distro.

My goals were to generally improve the text (Stevan is wordy in hist first drafts ;), and also to make sure we are consistent in our terminology and style.

I also ended moving a fair bit of documentation from cookbook recipes over to the manual. Before the manual existed, some “general doc” pieces ended up in the cookbook for lack of a better home.

In particular, I ended up adding a fair bit of content to the Best Practices manual based on some writing that used to live in Moose::Cookbook::Style.

I’ve just recently noticed people conflating Test-Driven Development (TDD) with unit testing. Why? I’m guessing this happens because folks with the TDD bug evangelise their particular approach to testing, and they’re the loudest. See this silly blog post and the comments (particularly Giles Bowkett). Also see this blog post by Michael Feathers.

I first noticed this conflation in an IRC conversation where someone asked how to pitch unit testing to colleagues. He seemed to think this meant pitching TDD as well. The colleagues were balking as much at TDD as at unit testing, and I suggested separating the two in the pitch.

I caught the testing bug many years ago, and I try to make sure that all the new work I do is well-tested. I introduced unit testing at my previous two jobs, and it helped improve our software quite a bit. I’ve never really done TDD, and I don’t plan to any time soon.

When I’m starting new code, I like to noodle around and explore. Sometimes I sketch out APIs for the whole system, sometimes I just pick a particular chunk and go for it. Once I’ve have something solid, I start writing unit tests. This tends to go back and forth over the course of a project. I write a new class, write some tests, write some classes, write some tests, improve an existing class, write some tests.

Invariably, the tests are written to test the code I’ve just written. The only time I follow TDD is for bugs. When someone reports a bug I write a failing test first, then fix the bug. This is a good discipline, since it ensures that I understand the bug, and that I’m actually fixing it when I make a change.

I don’t have any problem with TDD if that’s your thing. The important thing as that at the end of the day you have good tests with high coverage. You also need a test for every new bug. As long as those things happen, the order is irrelevant.

I think the conflation of unit testing and TDD is unfortunate. If you’re like me, a noodler, you may reject TDD out of hand because your brain doesn’t work that way. But if that causes you to also reject unit testing, it’s a big loss.

I was at Frozen Perl this last weekend, and listening to some of the speakers inspired me to write about giving a good tech talk. I also speak at a lot of conferences, and these are tips I (try to) follow for my own talks. If you’ve seen me speak and think I did a good job, then these tips may be valuable to you. If you think I did a bad job, you can stop reading now.

I’m writing about a specific type of talk here. Most tech talks fall into the category of “here’s a thing you should know about”. That thing might be a project or tool (Moose, Perl 6, Catalyst), or maybe a technique or concept (how to reduce memory usage, unit testing). Typically these talks run between 20 and 50 minutes. If you are doing a tutorial, this advice is not for you, because a tutorial is a different beast.

My number one piece of advice is to give an overview! Speakers often fall into the trap of telling people way too much. Short talks (as opposed to classes or tutorials) are a really shitty way to teach something, but they’re a great way to introduce something. Your goal is to provide attendees with information that lets them decide whether they want to learn more.

A few more pieces of unsolicited advice:

• Introduce the project or concept. “Unit testing is about writing automated tests for each piece of your system, in isolation.” It’s funny how some folks forget that their audience may know nothing about the topic.
• As a corrolary, make sure you define (potentially) new concepts clearly – “By automated, I mean the tests themselves are programs, and can be run with a single command. You could run them from cron and report any failures via email.”
• Tell people what problems this thing solves. “Unit testing makes it easier to refactor existing code with confidence.”
• Also tell them what problems it doesn’t solve. “Unit testing alone will not ensure that your code meets user requirements.”
• Show some some details, and allude to the rest. “Here is an example of Test::More from CPAN. You can see the use of the ok() and is() functions. (explain those two). There are many more functions in Test::More, and many more useful test modules on CPAN such as Test::Exception and Test::Output.”
• Do not go into detail on every little option and feature. This seems to be an easy trap to fall into. Don’t do it. It’s incredibly boring, and you’ll never finish explaining everything in the time you have available.
• Time yourself! So many speakers get through half their slides, or get through all of them in half their time and then look dumbfounded. You don’t need a stopwatch, just look at the clock. If you’ve presented a couple times, you may notice that you tend to have an average time per slide. I’ve noticed that my own time is approximately 1 minute per slide.

Have your own advice? Write a comment or your own blog entry.

I decided to give Perl 6 a go today at the Frozen Perl Hackathon. It was a great opportunity because I had Patrick Michaud sitting across the table from me, and I was able pick his brain both about Perl and the Rakudo/Parrot issues I was seeing.

The last time I looked at Perl 6 was about 2.5 years ago, when Pugs was still active. I started working on some DateTime code, but didn’t get too far because of various missing features.

Perl 6 is a really cool language, at least the parts I’ve played with. However, I still had trouble figuring out how to do what I wanted for a couple reasons. First, there’s no up to date comprehensive user documentation. The synopses (basically the Perl 6 language spec) are readable, but not really user-level docs. Second, there’s not a huge body of existing libraries, apps, and one-liners like there is with Perl 5. Because Rakudo doesn’t yet support the full Perl 6 language, the Perl 6 code that does exist is often not coded in the most natural way.

I encountered a few barriers to getting going with Perl 6. First, there is the documentation issue. Rakudo doesn’t support all of Perl 6 yet. Because Rakudo does not yet support all of Perl 6, and because I am pretty much a Perl 6 noob, it’s very hard for me to distinguish between “not supported” and “incorrect code”. This is further compounded by the fact that Rakudo’s error reporting is very rough.

I think if I had more than a few hours to devote to this, I could probably pick it up pretty quickly. A few days hacking on Perl 6 with blead Rakudo woud give me a better idea of how to interpret Rakudo’s error messages, and a better sense of what parts of Perl 6 are actually supported.

For now I’m too busy to put the time in. I’ve got my existing Perl 5 projects, animal rights activism, and rocking Rock Band to do.

I’ll probably come back to Rakudo in a few months and try again, maybe at YAPC. I’ll be less busy then, and I expect that Rakudo will continue to advance quickly. I’m optimistic that we’ll see a Perl 6 alpha or beta in 2009, though I would be surprised to see a real 1.0 release. Of course, I’d be thrilled to be wrong!

I’m very excited to announce the first release of the new Moose::Manual documentation as part of the Moose 0.66 release. This is part of the documentation work being funded by the Moose docs grant from TPF.

One of the complaints we often hear about Moose is that the docs are not good enough, and that it’s hard to get started with it. The Manual was created to address this issue. I’m hoping that it will be a good starting point for people to understand Moose concepts and features. After reading it, you should be able to start creating Moose-based classes right away.

I also hope that people will give us feedback on the Manual. It’s still new, and I’m sure there are parts that need polish, and concepts which were left out. If there’s something you’re confused about or wish were documented, please email me or visit the Moose IRC channel and tell us.