OSBridge 2010

Portland’s OpenSourceBridge just finished up its second annual conference, and although I had to leave early I just wanted to join the chorus of rave reviewers who claim it was even better this year than last. I dunno how much of it was luck and how much was planning, but it sure felt like the whole event was sprinkled with serendipity. The Portland Art Museum venue was not as inhumanely huge (or air-conditioned!) as the convention center and it was surprisingly pleasant to be surrounded by art, there was a farmer’s market just outside on Wednesday with yummy food stalls, and attendance was mysteriously the perfect size.

There’s no point in hating on OSCON or any other large conference for having become the victims of their own success… but that doesn’t mean I enjoy the corporate gigantism aspect. As always Rasmus put his finger on it when he noted that OSCON is now so huge that you can’t process much except dealing with the people you already know — so the big dogs just end up drinking beer with the other big dogs. OSBridge had a spirit that was much closer to the OSCON of years ago — everyone was just so open and relaxed and genuinely interested in sharing. Corporate interest was minimal, amounting to little more than Facebook sponsoring a bar-hop… in fact, one happy-hour event was open-bar only for the first $250 worth of drinkies! 🙂

I suspect that there’s a little bit of development-cycle luck involved in the era of good feeling too. All the excitement this year was around new datastores and server-side JavaScript engines… which maybe haven’t yet reached the stage where people feel compelled to champion one product at the expense of another. In the years where the new hotness is a programming language or toolkit, things can be more prickly or at least awkward if you don’t happen to be personally interested in the hot thing of the moment. Also, the inevitable demise of MySQL under Oracle seems to have resolved a lot of ambivalence and freed a bunch of people to wholeheartedly pour their energy into alternatives. And finally the extremely low cost of OSBridge — $300! — meant that people could kind of relax and follow their true bliss, instead of feeling like they had to justify some big conference fee by learning stuff relevant to their enterprise.

I don’t want to make it sound like a candy-coated paradise, cause that is not Troutgirl’s style :). It wouldn’t be Open Source without big egos, small social skills, and the dude in the Utilikilt standing around holding a pole with a parrot puppet impaled on it. Also Portland in early June seems to alternate between rain and humidity, unlike Portland in early August where every balmy evening invites an outing to an al fresco beergarden. To be fair, hotels and restaurants were bizarrely cheap and not very crowded in the “shoulder season” before the festivals of summer.

Lots of other OSBridge-lovers have mentioned the other unique aspects of this con — the perfect blend of proposed talks and unconference, the relatively large number of female speakers, the utter lack of vendors (I think Mozilla sent a dude to give away stickers, but that’s it) — but I just wanted to give one last shout-out to the volunteer army that puts on the conference. Selena, Christie, everyone who stayed up all night to man the 24-hour hacker lounge — I really appreciate all the hard work you put in, and I heard so many raves about the conference from others too. Thanks for giving us a space to revive our faith in what Open Source should be all about.

Learning Python

I took a 3-hour tutorial on basic Python at OSCON this year, partly to see what it was like from the perspective of a neophyte because I’ve been teaching a lot of newbies to code lately. Plus I just like Python, potentially I could come to love Python… which doesn’t of course mean that I don’t have some issues and puzzlements about that community.

I have to say I can’t approve of the way Python is taught, which is invariably feature-based rather than task-based. Our instructor did the typical Python thing, which is to start babbling on about lists-tuples-dicts, demonstrate slices, move on to closures, deliver a little lecture on OOP, and finally try to explain the whole Python 3 thing. That’s all very very cool, but let me put it this way: think of a case from your entire career in which you needed to use a tuple as the key to a dictionary item. Ops Boy came up with one (geocoding), but that’s not exactly a daily task for most programmers. I happen to believe that the vast majority of humans — particularly women — learn faster if given concrete, task-based instruction with a goodly amount of repetition using realistic examples from meaningful domains.

I think this focus on “cool rather than useful features of Python” generally comes out of what I see as their biggest weakness as a community: lack of focus, exacerbated by small size. Check out the Python.org statement of what Python is good at: everything from humongous web frameworks to scientific programming to games to new ideas in sockets. PHP, in contrast, knew from Day One what it wanted to be the best at when it grew up, and generally PHP teaching tends to be quite concrete and task-based. From what I’ve seen of Perl culture, it’s even more about getting shit done without regard for adorable flourishes. I get the feeling that there’s an awfully large body of knowledge that 100% of PHP users will want to know; but for Python there might be 5 disparate topics, each of which is beloved by 20% of the community. It’s hard to grow the entire team like that.

At this juncture you probably want to point out that Java has a universal focus with seemingly more projects and libraries than there are grains of sand on the beach… but they are also probably the biggest community of all time, with massive corporate resources behind them. Pythons, if you’ll permit me a gross generalization albeit one based on personal experience, tend to be proud individualists who have difficulty accomodating the herdthink that is a necessary part of organizing resources at scale. Under those circumstances, it’s difficult to grow a community big enough to be great at so many things; and it’s disastrous to follow Java’s path towards imperial overstretch. I’ve also come to believe that PHP was lucky in never having a single Benevolent Dictator type, but instead having multiple leaders who were good at different things and had different interests.

It’s possible that deep down Pythons don’t care about being popular — and that would be cool if it were true. But it would be a shame if they actually want to be understood and loved, and just can’t explain themselves to newbies. I can only reiterate that task-based rather than feature-based thinking is the way to go. If you can’t explain the 10 things that everyone will want to do with Python rather than another programming language, and the 10 questions everyone will have about Python, then you probably have a bigger problem than just a lack of publicity.

Perl fugit

I am worried about something I never thought I would have to worry about: that the Perl hackers of the world might be fading away.

When I first started out in the business, everyone knew Perl because that’s pretty much all there was for making websites with; plus Perl was already pre-eminent in the operations space. You could use Perl for grungy sysadmin chores, whip out necessary tools like Bugzilla, and produce elaborate all-singing all-dancing public CGI scripts too… there was really no downside. It was so ubiquitous in the mid-90’s that we used to joke that when industrial society finally broke down, its very last gasp would be the final running of some Perl cronjob somewhere. Après Perl, le déluge.

But I think now people are having to specialize much earlier in their careers. Young devs don’t necessarily see the same bet-hedging value to learning Perl — heck, I’m sort of convinced young webdevs these days don’t see much point to learning anything about systems and their administration (whippersnappers, grump). Probably the young pups of today see much more value in Ruby on Rails than Perl. Today learning Perl is a CHOICE, and that choice is to definitely go down the ops/tools path rather than the public-facing dev path… like shell scripting, I guess.

Since every web operation of any size is ultimately held together under the covers by Perl scripts and duct tape, I’m wondering what it means for the industry to see the pool of junior Perl initiates shrink rather dramatically. Perhaps in 10 years Ruby will be the grungy sysadmin tool of choice?

OSCON06 recap

[I wrote this July 25th 2006, but didn’t remember to post till today.] Last year the big story at OSCON was enterprise software (yawn), but this year to my joy it looks like the story is going to be a renaissance of webdev tools. For a long time there was very little innovative new web development happening, thus there was little demand for new tools… but beginning around 18 months ago, it seems like there’s been an explosion of energy going into cool testing ideas.

I’ve been focusing on testing tools this year, because I’m desperately concerned with how to test a site with a DHTML frontend and a PHP backend. I’ve already seen two awesome tutorials about Apache-Test (now with more PHP love!) and Selenium. I’m so in love with both of them, even though in some ways they don’t quite fit my needs yet. Apache-Test is very “Perl”, and maybe more concerned with making things easy for the tool-maker rather than the actual site-developer. Selenium IDE, through no fault of its own, is incompatible with a major Dojo trope called dojo.event.connect(). Frustrating!

They say there’s going to be 3000 people at OSCON this year, up from 2000 last year. A lot of the juice of the conference seems to be coming from the JavaScript and Ruby tracks… in contrast, the Perl and Python crowd seems bogged down in their everlasting Parrot issues. Generally the sessions seem very practical to normal professional engineers (and engineering managers!), with much less of the “Now we’re going to make a helicopter with nothing but a GPS unit, some duct tape, and Perl!” vibe.

Assigned status

Why do bugtracking systems even have the “Assigned” or “Accepted” status? It seems like an unnecessary step to me, and I never use it personally. If I don’t think the bug should be mine, I simply dump it on some other sucker reassign it to a more appropriate team member; otherwise it’s just “New” or “Open” until I get around to fixing it.

Meanwhile, there are statuses that I think would actually be helpful that you never see. Like how about “Sent to QA for confirmation”? Or “Sent to staging server”? Or “Sent to live site for final regression”? I think all of those would let you track exactly where on the assembly line that bug was at the moment.

Misunderstanding engineering truisms

I must confess to a sick fascination with the spectacle that results when a non-technical person parrots engineers’ truisms. Most of the time, in my experience, s/he ends up misunderstanding it so completely that s/he undercuts or even entirely reverses the meaning of the phrase.

For instance, I’ve often heard engineers say “A good engineer is a good engineer regardless of programming language”. Usually this is shorthand for a longer statement like, “Jerry prefers Java, but after a few months of working in a mostly-PHP environment, he wrote a standalone ad server in the most beautifully-structured object-oriented PHP I ever saw.” Note that this statement doesn’t at all preclude the notion that Jerry still prefers Java, or that his PHP is extremely Java-esque, or that unlike many PHP projects his server had no UI component, or anything else that negates the ingrained habits of mind, practice, and specialization that come with being the devotee of any particular programming language. All it means is that with the proper motivation, it’s not unrealistic to expect most engineers to be able to produce code similar in scope to that which they’ve written before in alternate programming languages within a short period of time.

To my wide-eyed delight, however, I have heard non-engineers use this phrase to mean something much more like, “A senior C++ engineer will be better than a PHP engineer for getting a new website up and running because a C++ engineer is a better engineer.” Leaving aside the question of whether a C++ engineer is actually more of an engineer than a LAMP dude, I’ll just ask: if you were going to hire a salesperson to sell networking equipment, would you go for one who had sold networking equipment before? or would you rather have someone who had sold a similar-priced item like cars?

Some more of my favorite misused quasi-engineerisms:

* Invoking Brooks’s Law as an excuse to overwork engineers to the point of near-death.

* Asserting that “the most productive engineer is 100X more productive than the average engineer” to avoid disciplining a jerk.

* Excusing a very slow pace of development on a website because “more time spent on architecture now will save time later”.

I don’t mean to be overly harsh on non-engineers who need to work with engineers, because they are in a difficult and often paranoia-inducing situation. But I sort of figure that people who can misunderstand engineering truisms so badly are not coming at it in the correct spirit of humility and desire to learn… in my experience, they just want a shortcut to understanding by reducing a lot of delicate practice into a bumper sticker.

And by the way, in this situation I tend to encourage rather than discourage the speaker’s misconceptions so they’ll fail faster. You can’t make them understand anyway, so we might as well have some fun while being yammered at.

Dist upgrades gone wrong

So I had decided to upgrade my Ubuntu distro to Breezy Badger as a last-ditch effort to improve my wifi problems before taking the lappy into the shop. Unfortunately, a dist-upgrade is kind of an all-or-nothing proposition. If the smallest thing goes wrong in the middle, all kinds of stuff will potentially end up not configured properly; I think this may be particularly true with Ubuntu, because they have these distro-wide metapackages (e.g. ubuntu-desktop). There’s a particularly sickening feeling you get at the moment you realize that neither your X server nor your network interfaces work any more… so you’ll be burning an ISO to re-do your distro upgrade. Read the Breezy upgrade notes first and save yourself a lot of pain and a trip to Fry’s for CD-RWs. Do as I say, not as I did!

But as Sterling pointed out in the midst of the crisis, the great thing about Linux is that it makes you feel utterly moronic for hours — and then when you finally figure out how to do things, you get to feel smart for a minute. It’s not just an operating system — it’s an emotional journey!