Working on the Moose and Class::MOP API documentation recently has once again reinforced the importance of writing documentation. Writing docs hugely improves your APIs. Conversely, not writing docs makes it much easier to write really bad APIs. I’m hoping that going forward, all new Moose and Class::MOP work will require API docs for all public APIs. This will help us catch bad designs before they’re released. Here’s some code smells I think docs help catch …

I’m just inches away from declaring the grant done. Last week, I released new versions of Class::MOP and Moose which feature (mostly) complete API docs. I say mostly because some things are intentionally being left undocumented for now. These are methods with public names (no leading underscore) that I think should be made private, or in a few cases entire classes with really weird APIs that need some rethinking. I think the API docs are done enough to satisfy the grant requirements.

I’ve felt for a while like my current position isn’t a good fit for me. Basically, the way they do development is kind of 1995-centric, and I don’t have any power to change it. I find this very draining. Talking to a friend, he also pointed out that my current job is very isolating. I work from home, and my projects are basically all solo. When I worked at Socialtext, everyone was remote, and so everyone chatted on IRC.

I was listening to Massive Attack’s Mezzanine today and I happened to notice that I was missing a track in Rhythmbox. I bought this CD ages ago, and it’s been in my MP3 library for a long time, so it’s funny that I just noticed this. I went back to my old home-made MP3 server thingy and looked for the track, but it was missing there too. Now, I could’ve gone downstairs and looked at my dusty shelves of CDs, found the CD (eventually), and ripped it.

♪ 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.

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.

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.

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.

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 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.