A computer once referred to a human worker who would perform calculations. This was a fairly easy thing to cluster and “run” several computers in parallel. As time progressed, more and faster work was desired. Enter the electronic computer, and specifically for this talk, the Cray. As with anything, the inner workings of the Crays of old can be recreated in Perl. Just use the Cray module, no problem (if only it existed).

After the history lesson, we move into high level overviews of parallelism and pipelineing, and a note about Amdahl’s Law. This was followed up with an example for detecting prime numbers by partitioning the work.

The slide presentation was over in under 20 minutes. Instead, we’re jumping straight into code examples. Awesome.

Or so I thought. Unfortunately, he’s been interrupted by multiple people in the audience, who keep wanting to move off into tangential conversations. Eric is having difficulty bringing the talk under his own control—it’s no longer his talk, but that of the somewhat rude fellow in the front row. Neither is Eric as eloquent when he switches from a prepared talk to demonstrating and explaining real code. It’s become far more difficult to pay attention to this session, and I find myself looking at the clock to see how much time we have until the next session.

For real fun, be sure to check out Brad’s post on Schwern’s session about skimmable code.

[tags]oscon, oscon08, oscon2008, Perl, programming[/tags]

Our first speaker this morning is Keith Bergelt of the Open Invention Network, speaking about Open Invention Network and Its Role in Open Source and Linux. He’s speaking about patents and intellectual property in Open Source, the realities of it today and where he sees it going tomorrow. He’s big on the buzzwords, and this is not the right audience for it. In fact, a game of Buzzword Bingo has already broken out in the IRC channel.

In summary, “Blah blah patent blah blah buzzword blah blah we care blah blah.”

Oh wait, he droned his way to a point. One of the things the Open Invention Network does, and I should have known because I’ve seen this before, is to buy up patents and keep Open Source safe from them. At least, until their funding dries up and they turn to their patent portfolios to squeeze money out of everyone.

I seem cynical this morning. Maybe I didn’t get enough sleep. Or maybe the first keynote today is boring. The back-channel conversation on IRC is actually quite entertaining, though. I need to whip up a quick IRC log file analyzer to correlate IRC traffic to keynote speaker. Then I can use it as a tool to rate speakers.

The pain is finally over, and the program chair has caught buzzworditis from the last speaker. Next up is Peter H. Salus to speak to us about Anniversaries. I’m told by Nat Torkington that Peter is an Unix historian. He’s started off by showing us a picture of the first transistor, which is about 20cm and a bit more than that around. It’s amazing to see how far we’ve come in 60 years—how many iPhones can fit in the same volume?

Anniversaries, in this case, are major milestones in computer history. The first electronic computer; the first time-sharing system; the first Unix paper by Ritchie and Thompson; the GNU project. One of the interesting things to learn is that history repeats itself. Back in the days of ARPANET, there was an issue involving the exhaustion of address space on the network. Short-sighted problems like that would never happen today, right?

I enjoyed this keynote speech, but probably because I really enjoy history.

Next up, Supporting the Open Web with David Recordon of Six Apart. It’s not just the open nature of the software or the platform that matters, but the openness of the data. Without open data, the Open Web can’t work. Interoperability and open specifications are vital to moving forward with the technology. The Web must be accessible, not just available on one device or another.

The majority of the talk is dedicated to talking about the various organizations doing work to keep everything free and open, including the Open Source Initiative, Creative Commons, and the Apache Foundation. There are also quite a few people donating a lot of their time to help.

He’s announcing the formation of the Open Web Foundation. They don’t necessarily want to form their own foundation, but they have had little luck finding an existing one to do what they’ve asked.

The Open Web Foundation will focus on four areas: incubation, licensing, copyright, and community. Many companies, such as Google and Yahoo have already shown support for this new foundation.

Following David is Danese Cooper of the Open Source Initiative and Intel Corporation to speak about Why Whinging Doesn’t Work. A catchy title, and she introduced her talk with a funny video of a choir of Finnish women singing about all of the complaints they have (search YouTube for “complaints choir“).

She’s making a very good point. There are so few women in Open Source. Geek are often intimidated by women and women are so often objectified. It’s true, there is a huge gender imbalance in the geek community. Of all the geeks I know, I can name very few women. I’m having a daughter soon, and you know what, she’s going to learn to code.

However, the feminist angle is merely a way of personally relating to the main point of her talk. People complain. I do it, you do it, the guy sitting next to you does it. But whinging doesn’t help. Mostly, all whinging does is beget more whinging. That energy used to complain needs to be channeled into something constructive.

For seven years, Danese was the only female member of the Open Source Initiative’s board. Now 30% of the board members are female. Progress.

Finally, Nathan Torkington, former OSCON program chair and recently of He Hononga Software, Limited and his keynote, fork() && exec(): Spawning the Next Generation of Hackers. Thank goodness, this talk is not about geeks having sex.

I’ve been looking forward to this keynote for a couple of reasons. First, I’ve missed hearing Nat speak this year. Second, I’m expecting my first child in a couple of months. Not only that, two other members of my local Linux User Group are either recent or expecting fathers. Suddenly, topics involving children are much more interesting to me.

Nat recently moved his family back to New Zealand. One of the things he does now is to help teach children about computing. In his school district, the computing infrastructure was awful—and used Windows. So he got a handful of Macs and became the Bastard Operator from Hell for his kids’ school. Then he started teaching the schoolchildren. Quickly, he discovered that the teachers needed teaching as well.

One more thing he wanted to do was to teach programming. He feels it’s a very important skill. But it has to be done right. Avoid the frustration that so many of us experience with computing and programming, but something consistent, easy-to-learn, but still powerful. Nat’s introduced Scratch. The kids loved it.

Lessons learned:

• Lectures suck (you have two minutes to say what you want)
• The gender gap is not what you think (girls are smarter and more focused than boys)
• Keyboards are a challenge
• Not a lot of experience with math
• Robots are lame

So please, volunteer in schools. Perhaps remove Windows and bring the joy of Linux to their lives. Find, or create, good courseware, such as Scratch. Post it on your blog, so everyone can find it. Finally, don’t profit. Do this for the good of the children, our future generation of geeks.

With that, we’re off to the expo hall for the break.

[tags]oscon, oscon08, oscon2008[/tags]

Paul has started out by describing the world’s oldest computer in terms of modern computing.

From there, he’s providing examples of major computing and engineering failures throughout modern history. It’s amazingly entertaining. I can’t summarize it. If you’re not here, you fail. I’m just going to sit back and enjoy it.

[tags]oscon, oscon08, oscon2008, history, failure[/tags]

Today was also a very good day. I learned a lot, and had a great time doing so. While I’m already familiar with most of Perl’s best practices and the reasons for using them, there are always many things to be learned any time Damian speaks. For example, I’ve always been one to use a single method as both accessor and mutator. However, now I’ve seen a good argument to use separate methods. Granted, I could have just read the book, but who has time for that?

One thing I will recommend: try to avoid flipping the bird to your instructor, even accidentally, particularly if you’re sitting in the front row and he’s standing only six feet directly in front of you. Shortly after this incident, I had a conversation with a friend in New Zealand. He gave me an explanation of the gesture and congratulated me for executing it in such a public forum (and getting a few laughs).

Even after my faux pas, I had the distinct honour to do a bit of hacking with Damian after class. My coworker voiced a concern I’ve also had in the past: inside-out modules, in this case Contextual::Return, do not work with Data::Dumper. So what did they do? They immediately started looking for a way to make it work. Initially, I merely stood back and watched; however, I’m proud to say I did have some input into the final implementation. Essentially, we came up with the following method to make it work.


{ local $Data::Dumper::Freezer = 'Contextual::Return::FREEZE';
  Dumper $return_value;
}


It’s perhaps not the most convenient way of doing the job, but it’s not bad for something that for most people is a debugging tool.

After a short break for some rolled tacos at Nico’s, it was back to the auditorium for Damian’s presentation to the Perl Mongers. As always, he had us rolling with laughter while at the same time learning quite a lot. The primary focus of the talk was the social and technical lessons learned by the core Perl 6 development team over the last seven years of the project. The lessons can be applied to any project—or in fact any group of people—be it Open Source or within a company. While useful, I was most excited by what Damian shared of Perl 6 itself. The design is amazingly clean and elegant, and I’m really looking forward to using it in my own projects. One thing that really has me excited is junctions. These look like an awesome way to develop parallel code cleanly and intuitively (at least for me).

I have one more day of class tomorrow, one I’m really looking forward to. Damian will explain to us exactly how it is he can be so productive, even while traveling. I expect to be overwhelmed with information and it will likely take me all weekend just to absorb it, and even longer to put what I learn to use. Next year I sure hope we have him back to teach us all about Vim.

I attended the first of three courses taught by Damian Conway today, Advanced Parsing with Parse::RecDescent. This was, effectively, the Parse::RecDescent tutorial as presented live by Damian. I’ve read the tutorial, and it’s quite good, but it’s hard to beat instruction from the man himself. Not having used the module on too many occasions, the course served to clarify a few concepts of the grammar used by Parse::RecDescent.

Now I see problems in a new light—for better or worse. This evening, I joined my boss to debug a problem we’ve been seeing in our compute cluster. I joked that I could just whip up a grammar to track down the problem for us. I must resist my usual urge to apply my new, shiny tool to all problems. I mean, it’s bad enough I use the Perl hammer for everything, right?

Today’s course left me with nostalgia for the compilers course I took in college. As my partner for that long ago class reminded me, it was filled with “late nights and Mountain Dew.” Ah, good times.

I have a few ideas for the future of the web site. Some of these include a wiki, a blog, a book review section, anything really. Not everything will be worth pursuing. We can have a wiki on a main Perl site; we can set up individual blogs on use Perl (or Blogger or LiveJournal or whatever). However, I think it would be nice to have a web site we can call our own.

I’m open to ideas, and I try to be receptive to comments and suggestions, either on our mailing list or sent directly to me.

[tags]perl mongers, sandiego.pm[/tags]

Since we had the auditorium available to us, one of our members was nice enough to say a few words about his business and how Perl has helped him to succeed. Much of the evening was devoted to chatting about whatever Perl-related thoughts came to mind. I floated the idea of hosting a booth at FOSSCON, but that’s still too far out to really talk seriously about it.

I’m extremely pleased with how well the venue worked out. We may not have the meeting there every month, but it’s nice to have it available so we can start adding technical meetings to our calendar.

[tags]perl, perl mongers, san diego, sandiego.pm[/tags]

Looks like Chicago.pm has thrown their hat into the ring as well.

Update: I guess the LA.pm bid never gained any traction.

[tags]oscon, oscon07, yapc, perl mongers, los angeles[/tags]

Anyway, go take the survey.

http://perlsurvey.org/

When Larry hooked up his computer to the projector, he had an IRC window open to #parrot on irc.perl.org. Yes, of course I did it. I jumped right into the channel and wrote, “hi mom.” I got a good laugh from those in the room, but I’ll probably never be welcome in that channel again.

Larry thinks it’s a bad idea to get rid of the term scripting. Perl already owns the brand when it comes to scripting. We have about the same chance of changing the branding of hacker.

“Programming is hard, let’s go scripting!”

Scripting isn’t so bad. It’s actually kind of easy; just look at all the script kiddies out there. But we can use Perl to turn all those script kiddies into real programmers. After all, Larry claims to have come to Perl in the same way.

So what’s the difference between scripting and programmers? Scripting is like profanity, you know it when you see it.

This year’s State of the Onion is about scripting, past, present, and future.

The past, essentially, is a brief history of Larry and his experience with scripting at different times of his life. More importantly, it’s about what all of these languages ar, how they and his experiences with them influenced what Perl was, is, and will be.

The present is an overview of the different ways languages can be designed. Binding, dispatch, typology, structure, and others are all different forks in the road of language design. Each fork developed for different reasons, whether it be efficiency of code or abstraction of language concepts. Follow all of these forks like some kind of Choose Your Own Adventure book, and different languages emerge. The lessons of each of these languages can be used as new ones are developed.

So I guess what Larry is trying to say is that Perl 6 looked at what every other language (including Perl 5) did right and what they did wrong, then went ahead and did everything right.

In fact, Perl 6 has taken Yogi Berra’s advice and took all of the forks. Sure, it seems confusing, but think of the power.

Okay, so what’s the future?

Perl 6.

Duh.

Seventeen talks this year, in a span that only allows sixteen. No break for us.

Vani Raja talked about YUI CSS. This appears to be some kind of Yahoo style sheet stuff for HTML. I’m not sure how this differs from any other style sheet out there, but she seems very proud of it. I’m guessing it’s just a set of pre-written styles that page designers can mix and match in their web sites. Oh, and apparently Nate is her hero.

Okay, now it’s time for “How Long Is Five Minutes?” by Schwern. He seems very concerned about how long five minutes is and how often he ruins his tea. Why is this important? Well, if you don’t know how long five minutes is and how much you can do in those five minutes, how can you know how much you can do in a half hour, an hour, a day, a week?

Schwern managed to get himself two slots of lightning talks. This second one is a very rapid combination of three talks. First up is a plug of the new Perl 5 wiki. He wants this to be the encyclopedia of Perl 5. As an aside, someone in my Perl Mongers group who already wants to have a wiki-thon at our next meeting. Next, we got to stand up a lot as he asked questions about our demographics. Apparently we in this room are not representative of the US at large. In any case, a survey of this information has been put up at perlsurvey.org. Finally, we’re supposed to blame Schwern. Larry has gone off to Perl 6, so Schwern is taking the responsibility of being the one who people can go to if they want to do something in Perl 5. In other words, we get to blame him for giving people the go ahead. (That was amazingly hard to type up in the five minutes Schwern was allotted.)

Ask Bjorn Hansen wanted to present qpsmtpd, which is something he threw together in Perl to implement features he wanted in qmail. In fact, Perl hackers can easily write plug-ins for the system, which is a pretty cool idea. It looks pretty nifty, I may take a look at it, if only to toy with it as a game.

Andy Lester talked about ack, an awesome way to grep trees of source code. He gave this talk last year, and I’ve been enamored of it every since. It even made it onto the Perl Advent calendar last year. He’s also set up Perl 101 (dot org), to help n00bs avoid asking n00b questions on IRC or on mailing lists. He needs help making it awesome. His third topic is Google Code. Use it instead of SourceForge, because it is awesome. Period.

Andy got a second slot, after being harassed by the audience on IRC and iChat, he jumped into his Perl-is-a-programming-language-not-a-scripting-language rant. A scripting language implies that it is less capable. Say program, not script! Dammit. Andy is an angry, angry man.

Rebecca, standing up in front of Programmers Anonymous, talked about the similarities between Open Source projects and non-profit organizations that use volunteer labor. When someone shows up and wants to help out an Open Source project, why not have a list of small things to be done that anyone can sink their teeth into.

Eric Wilhelm, who we may know from the Internet, talked about Test::Harness 3.0, which he’s come to recently as a way of parallelizing test code. TAP has evolved. In comes TAP::Parser (which will be used in Test::Harness 3.0… I think… I found that part hard to follow). This is apparently a five minute version of the talk Ovid will be giving at YAPC::EU. He’d like us to help improve the documentation and tests for TAP::Parser. Convenient link: testanything.org.

Eric continued with a second talk. Well, he promptly ducked under the table as he mentioned Module::Build. CPAN is great, but you need to upgrade it before installing. Then there’s a huge upgrade install dance. But soon (real soon now), CPAN will go back to being a one-liner and will do everything right automagically.

Julian introduced MoveMyData.org, which isn’t coded yet. However, it’s a great idea. So many different social networking sites exist (Blogger, Flickr, etc.), and they don’t interoperate at all. This is the solution. A way of moving data between social networks and making sure it’s backed up and always under your own control, not under their control. Very cool, and something I’ve always thought should be done. It’s one of the reasons I maintain my own blogging software, in fact.

Tim Bunce gave a quick talk about DBI, as he usually does. This time it’s about DBI 2 for Perl 6. The JDBC API is a great example of what he wants to do, so he’s going to steal (that is, borrow, now that Java is Open Source) what they’ve done. He continued to give some examples of how it should work and how it would look, but then he got gonged. Good stuff, though.

Second talk by Tim, DashProfiler and lightweight code instrumentation. It seems he does a lot of web service work these days, so he spends a lot of time writing code to help him make this faster. This is an instance of Tim writing code to find out what needs to be made faster. I like this. It’s very magical (read: Perlish). Just use it and it does what it does.

Tim, take three. He condensed yesterday’s 45 minute talk about Gofer into five minutes. I attended that session, so I mostly zoned out during the lightning talk. It’s another way of optimizing the infrastructure behind web services.

Michael Potter (who introduced himself at the end) wanted to talk about Open Sourcing Message Definitions, that is to say he wants a better way of getting data exchange formats into the Open Source or standard or something. I don’t know. It was short, sweet, and to some point I didn’t get.

John Rockway stood up to teach us how to create a blog using Catalyst in 5 minutes. Of course, he used slides, instead of typing it out himself. So mere mortals probably couldn’t create a blog in only 5 minutes. I’m not entirely sure Catalyst has ever been used to create anything other than a blog. That’s my biggest problem with most web frameworks. They look like they’re only useful for the fun stuff, and it’s non-obvious how to use them for other kinds of sites. That’s a bit harsh, but there are too many frameworks for me to play with all of them to see if I can use it. Oh, and I think some of the developers of Catalyst (which was a fork of Maypole) forked it off into something else again.

John continued to plug Angerwhale, an actual blog application he wrote in Catalyst. I really didn’t pay attention. I’m not sure I like Catalyst, and I’m quite sure I don’t need to fill my head with yet another blog application. Although, it is a blog application written in Perl, so I may eat my own dog food and try it out.

Someone who didn’t identify themselves stood up to talk about SVN::Notify::Mirror. No idea what he said, as I wasn’t listening.

Last, and most certainly not least, Pudge got up to perform Perl, in a Nutshell. Of course, everyone has probably already seen this on YouTube already (and if you haven’t, why not?!), but it was awesome to see live.

Domain specific languages (DSLs) are languages designed for specific programming tasks. A couple of well-known examples of DSLs are SQL and regular expressions. However, today, Jesse is talking to us about “Englishy” DSLs, which he’s been very interested in lately. Additionally, these are DSLs that are internal to Perl. Instead of parsing a DSL and executing it, they are instead implemented by playing with Perl’s syntax and taking advantage of Perl’s parser (and having all of Perl’s features available in the DSL).

The two main goals when implementing a DSL in Perl are,

1. Does it feel good?
2. Can we actually do it?

The first big DSL is Jifty::DBI, an object-relational mapper for Jifty. For the folks at Best Practical, it was a fun learning process in tweaking Perl to look the way they wanted it to while still declaring the database schema in an intuitive, pretty way.

The Template::Declare module is flat-out awesome. I’ve seen it before, and I’ve never taken the time to play with it. How stupid have I been? Coding HTML templates in Perl is cool, and something I would happily do (I don’t really like writing HTML).

As if that weren’t enough, in comes Jifty::Dispatcher. Modelled after Mason’s (auto|d)handler files, it will manipulate web application requests and take care of dispatching processes. I really like the DSL used here. It’s very declarative, removing the infrastructure entirely, which is something I’m very interested in doing in my code right now. I must be getting old; I’m more interested in telling the computer what to do, rather than how to do it, these days.

Testing web sites is ugly, and it sucks. That’s what Test::WWW::Declare is for. It’s a beautiful module. Sessions, flows, declarative statements to define the web flow. So very awesome.

I can tell that the Best Practical folks have seen Damian Conway’s Sufficiently Advanced Technologies talk. The moral of that story is, write what you want to see, and only then figure out how to make it work in Perl.

I’m sold. As soon as I get home, I’m going to work on porting my start-up company’s web site with Jifty. Jifty is, well, absolutely nifty.

At the end, Jesse showed us his own domain specific language to define his slides. It’s awesome. I want it for my own talks.

Why build applications for the desktop? Speed. Network latency over long distances pushes the limits of people’s patience. Computers are getting so powerful, why not use those resources?

Why use Perl? Well, because it’s Perl.

Good documentation for wxPerl is difficult to find. Apparently someone needs to create a US mirror of the wiki. However, the C++ documentation is quite good.

Eric has created a few helper modules (most of which are on the CPAN) to make life for wxPerl developers a bit easier. He’d like to move more in the direction of Smalltalk, with more interaction and cleanliness between the code and the GUI. It’s still in the works.

One thing I really like is his phrase, “needs more Perlin’.” This means that something needs to be more like Perl. That is to say, it needs to keep easy things easy and make hard things possible… with a slick syntax.

I really enjoyed the video of a tae kwon do match as a real-world analog of software development. Try one technique, see the result (get hit); try another technique, see the result (get knocked down); ad infinitum.

There are three phases: preparation, modeling, and implementation. These phases are not linear in nature. One moves between phases as necessary to design the solution.

PDL was demonstrated in the modeling phase. Brad was pretty happy when one of the slides contained a web site address for information on PDL, which happened to be a web server at his job.

As he delved into the case studies, I started to zone out, so I have little to say about his examples of machine learning and Perl in action. I wanted to enjoy this session more, since I’ve often wanted to get back into using neural networks and other machine learning techniques in my code. Unfortunately, I just found it too difficult to follow his case studies. Still, I have some good pointers for packages that will help me sprinkle some machine learning goodness in my code.

I like his conclusion: “Perl excels at empowering people in all three phases of the development of a machine learning application.” Perl is awesome for rapid application development, which in turn gets solutions to people who need them faster.

New features include adverbial typing, such that class and module names can include adverbial modifiers. These specify things like author, authorities, and versions. The syntax is a bit scary, but they can be aliased.

Perl 6 now has inline comments (yay!). It’s typically Perl, too. The syntax is #{inline comment}, instead of the usual C-like syntax.

Wait, what’s this? Built-ins no longer default to using the $_ variable? How will I write confusing code now?

The zipper/yen operator has been renamed to Z. This is good for me, as I’ve never been very good at memorizing Vim’s digraphs.

The min and max operators now have infix versions. Strange at first, but it looks like it could be useful in some situations ($foo min= $bar).

Ranges are really lazy. So lazy they can be unbounded: for $i (1..*)... (to infinity and beyond!).

The power of the new file test operators demonstrate quite well how useful Perl 6 will be. It takes TIMTOWTDI to levels few Perl coders could ever have imagined.

There’s a MAIN subroutine now. It’s like we’ve stepped back 30 years to be C programmers again. The power it gives the programmer to define command line processing is very cool, though. Perl 6 will even call USAGE for you, if you’ve happened to define it.

Perl 6 has real repeat (do..while) loops now. Real, as in all the loop control statements work.

As if postfix control statements weren’t confusing enough. Now they can be nested! say $foo if $bar while $baz. Actually, I can’t tell you how many times I’ve wished for this.

Continuing the theme of parallelism, Perl 6 will make it easy to parallelize map and even do atomic locking on serial statements. I appreciate that Larry managed to change his slide to mirror what Simon Peyton Jones talked about in his keynote this morning. Very apropos.

Fixed-length arrays? Seriously, what is this, Java? Well, at least it allows you to define array bounds as “eh, whatever.” I especially like the “whatever whatevers” operator (**).

POD lists are dramatically cleaned up. Thank goodness. No more =over or =back. Nested lists! Tables! Bigger! More markup! Better! Includes! More awesome! Really! Useful! POD!

Honestly, I can’t wait to move to Perl 6. I can already see a lot of my code getting a lot shorter. Imagine, entire job control systems that fit in one screen of code!

This session is very much like other sessions I’ve attended. It’s essentially a brain dump of as many features Tim can squeeze into the alloted time as possible. It’s almost too much to follow. It’s certainly too much to take notes. Fortunately, he’s told us the slides will be available on-line.

From the description of the session, I had hoped DBD::Gofer would scratch an itch we have at work. Essentially, we need to ensure data finds its way into a database, even if the database may not be available. We have a custom solution at the moment, but it would be great if we could replace it with a packaged, maintained module. However, it appears that, while DBD::Gofer makes an excellent proxy, it wouldn’t fit our needs.

Examples have included connection pooling and load balancing, often to reduce load on the main database server. It’s apparent from the use cases that this module was developed for use by heavily trafficked web sites (its development was sponsored by Shopzilla.com). It’s design is modular, so perhaps it can be extended to do what we want. I won’t know until I’ve had a chance to look at the distribution.

Some interesting things for the future are HTTP caching and JSON, effectively turning DBI into a web service. This is cool. I can see this opening up a lot of possibilities as more applications are constructed from individual services, complete in their own right.

My first order of business was to create a public calendar for our group. Now anyone can subscribe to our calendar to find out when we’re having meetings or any special events. Not only that, using Google means less work for me.

I have much more in mind, which I’ll be sure to announce here and in my use Perl journal. Of course, I don’t intend to run this web site in the dark. I’m open to any and all suggestions. I want this to be a community effort on the part of SanDiego.pm.

Not me.

I awake with Perl in my head. Sigils, modules, and regular expressions snaking their way through my dreams. I have to climb out of bed and make my way to the computer before it’s gone. I have to prototype this code before it stops making sense. I have to commit these arcane symbols to disk before they fade away like so many other hazy, indistinct dreams.

I have to seek help.

Anyone who has attended one of Damian Conway’s seminars, tutorials, or keynotes will most likely have noticed that aikido will make an appearance once in a while. And for anyone who hasn’t, I highly recommend tracking Damian down. But not in that creepy stalker way. That’s just… creepy. Anyway, Damian knows a bit of aikido (or at least one move). He plucked a good friend of mine, Dan Risse, from the audience to demonstrate a “come-along” move. There was, as with most of Damian’s demonstrations, a good reason for this. I was wildly amused. In fact, I kind of have the itch to practice aikido again.

Sufficiently Advanced Technology is a pared down version of the API design tutorial I attended at OSCON. Memories of the Girl from Ipanema came flooding back to me.

I mentioned that Damian is in town. For the second year in a row, he will be presenting two of his courses over three days at Qualcomm. Fortunately for me, I now work for Qualcomm (I didn’t when he was here last year). I will, of course, be in attendance all three days. By the end of the week I should know much more about Perl Best Practice and Advanced Module Development Techniques.

Needless to say, I’m excited. Hopefully I won’t require psychological counselling.