A recent discussion on the YAPC::NA blog reminded me of the importance of having a code of conduct for conferences. I wrote about this previously in the context of creating a policy for my animal rights group. Now that the issue’s come up with YAPC, I’m thinking about what the ideal policy for a conference should look like. I do sympathize with people who don’t like these policies, and think they should be as short as possible.
When I first saw Google Plus circles, I thought this was a great idea. On Facebook, I have a bunch of “friends”, most of whom are people I talk to only rarely, some of whom I haven’t spoken to in years. With Google Plus, I can categorize these “friends” into different circles. How awesome is that? Most of the people I’ve had contact with on Plus are people I know through programming, so I made a “Geeks” circle and started filling it in.
I’d like to offer my Intro to Moose class at the Pittsburgh Perl Workshop this coming October, but we’re not sure if there’s enough interest to justify it. If you think you’d like to take the class, please put your name on the Moose Class wiki page for PPW. This isn’t a binding commitment, but don’t sign up just cause you’re vaguely considering it. Some recent feedback about the class …
Way back when, the Perl (1, 2, 3, 4, 5) core was defined as “whatever Larry Wall says it is”. Since the advent of the Perl 6 project, Larry has spent less and less time on Perl 5, and he hasn’t been an active participant on the perl5-porters list for years. Absent Larry, I think the Perl 5 core would benefit from an explicit set of principles. I don’t get to decide what those principles are, but I have some suggestions.
I recently released new distribution on CPAN called Courriel. The word “courriel” is the official French word for email. I chose it because the Mail and Email namespaces are already very crowded, and there’s really no good namespaces left there. This gets to the why. Courriel is a distribution for processing and creating modern email. What’s modern? In ye olde dayes of RFC822 email, an email was a bunch of headers followed by a message for the recipient.
I recently started using flymake-mode in emacs, which does a “make on the fly” for the buffer you’re currently editing. For Perl, that basically means checking the code by running perl -c on it. If it sees any errors or warnings, it highlights this in the buffer. This is pretty handy for catching typos, although I’ve seen some weird false positive. Anyway, it’s a great tool, except that it does its checking by creating a file in the same directory as the one you’re editing.
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.
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.
Many of the ideas in this post actually come from my friend Unny Nambudiripad, but Unny doesn’t blog, so I’ll have to write this up for him. The other day I was talking with Unny and Lisa Kimball about a nonprofit Lisa had looked at. She was disturbed because they’d spent their entire budget on salary. Unny and I didn’t think that was a problem, and Unny had a very good take on how to evaluate a nonprofit organization’s donation worthiness.
Since I’m looking for work these days, I’ve been doing a lot of interviewing. An interview is a potential employer’s chance to learn more about me, but it’s just as important that I learn about them. I think in an ideal interview, I spend at least as much time asking questions as answering. Over the years, I’ve created a standard list of questions that I want answered. What do you like best about working there?