PDX.pm meeting notes

Jeff (aka @duckyd) gave a presentation about CPAN Awesomeness at last night’s pdx.pm.

Slides are on github!  Your homework is to find them. :)  Here are some highlights.

There are over 16K modules on the CPAN as of 11 Oct 2009.  Wow.

Jeff’s recommended changes from the default cpan shell configuration:
– auto_commit 1
– prerequisites_policy follow
– build_requires_install_policy yes
– prefer_installer MB (Module::Build)
– change your make_install_make_command and mbuild_install_mbuild_command to include your sudo command.

—

Spend 10 minutes & give something back to CPAN every time you install a module:  Simply set up CPAN::Reporter!

Recommendations:
– make sure that you set cc_author to ‘no’.  (In the latest version, that’s the default.)
– set it to prompt you to edit/send the report if the tests fail.  This way you can judge if the failure is due to your own
boneheadedness.
– you can set the transport value to a file to run reports without sending them.
– for help:  perldoc CPAN::Reporter::Config

For automatic continuous testing, set up CPAN::Reporter::Smoker.  (Doesn’t actually install anything, justs runs tests.)

Recommendations:
– don’t run it as root;  you are the canary in the coal mine.
– create a dedicated user that has essentially no privs on your machine.
– run it on a separate Perl install (core modules only).
– this is a cool place to use that RAND option for prefer_installer in CPAN.

—

Another cool tip that I REALLY DIG because I have systems with multiple perls & users associated with them:
Set your shebang line to:

#!/usr/bin/env perl

pdx.pm code sprint #1

Hacking on 5.10.1 was the plan…that happened for a couple of us. :)

Duke proposed a PDX.pm sprint to work on 5.10.1:
“I think if everyone learns how to

a) get a copy of the perl git repo
b) keep it in sync
c) run the perl test suite, including running a single test at a time
d) submit a small documentation patch

then we will have a great start.”

This is perfect for a first sprint: “small, solve-able tasks” that will get everyone up & running, plus have the potential to actually be productive.

Your first code sprint with a new group of people is like the first day on the job…except nobody realizes that we’re each FNGs*. It can take some time to figure out how to work together.

It’s really great if people get the stuff that’s going to take time from the code sprint out of the way beforehand. For example, cloning the perl5 git repo (step a):

:::=>git clone git://perl5.git.perl.org/perl.git

(Took me 13 minutes.)

Duke suggested some advance reading as well – how to use the repo (cd perl; perldoc pod/perlrepository.pod) (you will need to install perl-doc if you don’t have it; it was not installed on ubuntu.)

This Week in Geekville.

This week at PDX.pm, chromatic gave an excellent talk about “how not to fail”.  There was quite a bit of discussion of Godzilla attacks and the calculus thereof, which I don’t think I can adequately capture.  “You had to be there”.  Anyway, on to my notes!

The keys:
– Recognize points of failure before the actual failure occurs.  The idea being to prevent the failure.
– Perform root cause analysis.  Your biggest problem may not be the most annoying, obvious, or easiest to solve.
– Do the simplest, fastest thing you can do to ease the problem.  You’re conducting an experiment to see if it has any effect on the problem.

Some examples of places you can get hung up:
– Waiting for a decision from someone else.  That someone else could be you.  Self-awareness is critical.
– Waiting for someone else to do something.  This is usually a sign of a technical bottleneck, such as a complicated process.  “The only person who can ____ is too _____.” (The blanks on this slide had my hopes up for madlibs.)
– Becoming demotivated (which is a word I thought only I used) by tedious or annoying tasks.  (Or people.)  Get rid of the annoying thing.  (Please obey all local laws.)  Motivational tip:  leave something to do tomorrow!  That way you start the day on a high note.  [I do this all the time – in fact, I keep a list on hiveminder of “instant gratification projects” – things I can do in 15 or 30 minutes – and any time I’m frustrated & need to feel like I’ve accomplished something, I do one of those.]
– Lacking direction.  Try creating a one-sentence problem statement.

Time-based releases force you to get your release process under control – and maybe even automated!  It gets you in to a rhythm.  (My rhythm, since it’s just me and I don’t really have “releases”, is to have “Refactoring Fridays”.)

Tips that especially apply to FOSS projects, where just about everyone is a volunteer:
– Make it easy for people to get involved
– Encourage discussion
– If someone new has contributed something, but it’s not quite up to snuff, tell them (nicely) how they could improve next time

This week in geekville.

PDX.pm! Held at FreeGeek. 16 attendees this week. A couple of new people.
—
Announcements:
– Call for shirt designs – must be in sometime in the next month.
– Barcamp is coming up.
– Something about Summer of Code? ;)

The “Say Your Name Game” topic tonight was to answer one of two questions:
– Where are the younger perl users?
– What can *you* do in 20 minutes a day (or two hours a week) to get Perl 6 out the door?

The general consensus on the younger users question is that Perl needs to be “cooler”. Programming games was a popular suggestion on how to change Perl’s image a bit; Wil suggested “more sex”.
Naturally the “20 minutes a day” question resulted in a lot of riffs on “rock hard abs”. Which eventually became “rock hard Parrot”.
—
Meeting:
Serious projector issues, as seems to happen every 3rd or 4th meeting. Selena upped the ante from “whiteboard with a non-dry-erase marker” to “VNC with all laptop-bearing attendees.”

IM IN UR DATABASE, Selena Deckelmann (a talk about procedural languages in PostgreSQL)

(This will be short because I want to be lazy & just link to her slides.)

A procedural language (such as PL/PgSQL, PL/Perl, PL/Python) is basically the expansion set for the SQL toy – you can create functions that do fun things like date calculations (what I usually use it for) or loop over a set of data. Essentially, you are letting the database do what it’s good at (handle data).

The first example we looked at was PL/LOLCODE. Mainly because it’s (currently) a very simple example, and fun. (Fun is the theme here.) You can only return one row at a time with PL/LOLCODE right now though. Selena suggests reading the docs; Joshua Tolley is doing an excellent job of documenting what he’s doing and this would be a valuable manual for anyone else who wants to write a procedural language for PostgreSQL.

Then we moved on to PL/PgSQL. Same basic format (CREATE function, RETURN, double-dollar quoting etc), but much more robust, of course.

This week in geekville.

PDX.pm = 21 attendees, SRO.

Announcements:
– Call for shirt designs – we didn’t have shirts last year. I hope there’s enough interest for Josh to get women’s sized shirts again.
– We need speakers for upcoming meetings. (I almost got pegged for March. This got me to thinking of what could I possibly talk about at the Perl meeting…)
– PDXPUG‘s next meeting will be Extreme Database Makeover featuring RT.
– This week’s lottery numbers: 6 15 21 32 7

Schwern‘s “Skimmable Code” talk started out with defining “lexical encapsulation”, a term I was curious about because I’d googled it before the meeting and the 3rd result was the meeting announcement; there wasn’t a really clear definition available. So: lexical scope refers to the scope of a block of code, and encapsulation means nothing leaks out (or in). Lexical encapsulation means that you can read all the code on the screen (a single screen, we’ll get to that in a moment) & know what it does, without having to look at the rest of the code to figure out what & where some variables are/do/come from.

This brings us to the concept of “skimmability” – how much of the code do you need to understand to do what you need to do (refactor, tweak, add new functionality). Can you get in, fix it, & get out without mucking up something else? You want small, self-contained blocks of code that will fit on a single screen.

Example of something bad: a global var in a subroutine – you have no idea where else it is used or what it does without reading the entire code. (Note to – I have the mother lode of “Pathological Code Base.” Let me know next time you need some examples. :) )

Tips:
– Andy Lester’s ‘ack’ is very useful for searches through multiple modules.
– Fun way to check your code blocks: pull the block out, run the compiler against it. That will tell you what needs to be passed in & out.
– version control comments: why you did it. What you did will be visible in the diff.
– enhance skimmability by using vertical whitespace; different things should be separated, similar things grouped.

My notes end here, as I had to leave early.

eta: Here’s something else I found that is relevant to this discussion:
Andy Lester – The world’s two worst variable names

Things I need to look into:
– Devel::Cover
– can I set cvs to ignore whitespace