♪ 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.
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.
People want many things from software, and those desires are often contradictory. There’s a constant back and forth about what people want from CPAN modules, in particular. It seems like we have the same arguments year after year. I think talking about priorities before talking about why something is good or bad is crucial. So what are these priorities? How do they work together? Which ones are contradictory? Which ones are most important to you, and when do the priorities shift?
I enjoy reading a good epic fantasy from time to time. Sure, it’s a well-worn genre, but I like a big story, and if it’s well-written, it can be fun. I just finished re-reading Tad Williams' Memory, Sorrow, and Thorn trilogy (for the first time since it was published 20 years ago). It was enjoyable, despite a bunch of cliche bits. But it got me thinking about how ridiculous many fantasy worlds are when you look a little deeper.
I’m still stuck on the whole problem of the requirement that URIs for REST APIs be discoverable, not documented. It’s not so much that making them discoverable is hard, it’s that making them discoverable makes them useless for some (common) purposes. When I last wrote about REST, I got taken to task and even called a traitor (ok, I didn’t take that very seriously ;) Aristotle Pagaltzis (and Matt Trout via IRC) told me to take a look at AtomPub.