Jay Kuri: May 2009 Archives

I came across this the other day, and since it pre-dates the Ironman competition, I wanted to pass it on. Dave Rolsky came up with some interesting comments about software and the documentation process.

You know how it has been said that a good way to judge the quality of your writing is to read it aloud? Dave points out that the same thing applies for your code. When you force yourself to describe how your system / code works, you will notice inconsistencies and problems that you otherwise might not notice.

I have found this to be very true and the first commenter has a point as well. When I am designing new software from scratch, I always start with a legal pad and a nice free-flowing pen, and draw diagrams and write down ideas for how the different pieces fit together. I find that while I can write code without this step, the code I produce having done this is far superior in quality and cohesiveness.

Thanks Dave, for sharing that wisdom.

English is an interesting language. It has lots of rules, and over 170,000 words in common usage. That seems like a lot, until you realize that there are even more concepts that are described using multiple words. Those words are arranged and rearranged to create millions upon millions of books.

One of the things I find most interesting about English is that it's a very idiomatic language. There are many phrases that, if you pick them apart into their individual words, do not carry the same meaning as when they are used together. "In her element," "red herring," and "chip on your shoulder," are just a few examples.

These idioms allow you to deliver a significant amount of meaning in a small number of words. It's a conceptual shortcut. It's natural for people to want to communicate as much information in as small a space as possible because most of the time, there is more to communicate than there is time to communicate it.

In that respect, programming is very similar. We can think far faster than we can generate code. Therefore the less we have to write, the more meaning and function we can deliver per line, the more we'll be able to accomplish.

In the Perl world, this value is commonly referred to as DRY or Don't Repeat Yourself. The concept behind DRY is that we all know that there are activities our programs must do over and over, but that doesn't mean that we should have to write them over and over. Also in the Perl world, there is a temple for this worship of this value. It's called CPAN.

Everyone knows that you can write web tools using Perl and CGI. Most folks know that there are web frameworks for Perl such as Catalyst that allow you to create large and complex web applications relatively easily.

Today I have a question for all you Perlers out there. What options does a Perl developer have if they need to develop a small amount of interactive code for a web site and they don't want to go all in for a complete web framework?

So if you are in need of only a handful of interactive responses for your site, or you work in an office with a CPAN hostile admin who balks at the dependency chains on some of the larger frameworks, what choices do you have?

Are there any options that are a bit better than CGI, but not quite as complex as a whole web framework? I know mod_perlite is on the horizon somewhere, but is there anything that you have heard of or are using now?

Sound off in the comments!

Ok. So you've heard of Reaction. You've read a blog post or two about it. You've even taken a crack at reading the fine manual, but you still don't quite get it. Don't feel bad. I was in the same boat as you.

The manual does a fine job of explaining how Reaction works. It does a pretty good job of telling you how to build bits of Reaction code. It doesn't really explain what Reaction is for and why you should care.

I spent some time discussing this with one of the folks who wrote the majority of the Reaction documentation. My questions were all over the place but they boiled down to one thing: 'Why do I care?' I finally had the 'AH HA!' moment about 2 hours in to the discussion.

Reaction provides a way for you to easily plug-in features into your Catalyst app with minimal effort. It allows you to build new features in a distributable way that allows for per-app customization while maintaining a clean base set of code.

Reaction takes DRY (Don't Repeat Yourself) to the next level. DRY usually applies on a per-application basis. Features built using Reaction become mobile between applications and even distributable via CPAN. The best part is you can still customize them without editing the distributed code.

That's why Reaction is interesting. It gives Catalyst authors a way to share their features with each other, and across their own projects.

Perl is quite different to languages such as Java and Python. It is an open language with relatively few pre-defined ways to do things. This is one of the greatest strengths of the Perl language. It allows the language to evolve over time. It allows the language to change and to adjust to new methodologies and concepts without a gutting of the core language.

One of the core values of Perl is TIMTOWTDI, or "There Is More Than One Way To Do It." This too is different from other languages whose 'how to do it' is often defined by large commercial organizations or 'language elites' who decide the course of the language. Today we will look into TIMTOWTDI and explore some of it's effects, both good and bad.

I've said before that Perl has a very active community. There are hundreds of people in each of the Perl related IRC groups I frequent. There are thousands of people on the mailing lists and more who frequent places like use.perl and perlmonks. There are several hundred modules uploaded to CPAN every month. Each one of those uploads usually involved the work of several people working together to improve those modules.

Having spent the last decade in the Perl community, I can tell you that it is composed of a lot of very smart people. It is generally open and accepting of new people and can be a very lively and rewarding group to be a part of.

That said not everyone finds it to be that way. At least once a week someone will join one of the Perl related IRC channels I frequent and within a few minutes will get what amounts to an 'ok, you can go away now.' This happens on forums and mailing lists as well. So if the Perl community is as lively and accepting as I claim, what's the deal?