Perl: July 2009 Archives

Every so often I see a blog post or a comment that is along the lines of "Don't use X, it has too many dependencies, use Y instead, it doesn't depend on anything." I've touched on this subject before, but in different ways. I've seen this subject crop up again recently and think it warrants another look.

This time it was oriented towards Rails and Catalyst, but I've seen it on other projects as well. The question behind the above statement is somewhat deceiving. It seems to be: 'Do I choose a system that has lots of dependencies, or one that has only a few (or none)?' Well, when you put it like that, it seems like a no brainer... but it is, in reality, a trick question.

Sometimes in a weak moment we ho our code out for bread, butter and tight deadlines. In this flurry, we may have missed a step in the object memory cleanup dance¹. When one thinks they may have sprung an object memory leak, they can turn to the aid of Devel::LeakGuard::Object. It builds upon the admirable Devel::Leak::Object by providing more control over the leak report.

That's being said let's get down and dirty with an example.

or... when we only need a bicycle wheel, sometimes we need to re-invent our wheel slightly to get the job done.

Recently I ran into a situation where a client had a queue system that placed requests into queue files to be processed on another system. Until now, these queue files were created on one machine and network-copied to the processing server. This required a lot of server setup and left a lot of pieces to easily break. It also gave no clear way to log the submission to the queue.

To solve this problem and to make it more easily to integrate, we decided to accept the queue submission via http. We could implement it to take care of these queue files and add some logging and sanity to their current situation. The idea would be to handle a request, validate the submission, log the status and then write the given request to the queue directory.

Seems simple right?

So, I've decided to work on a book for those looking to learn programming. It will focus on learning how to program, using Perl as the example language. This, in my opinion, is an area that is sorely lacking in recent years. I am in discussions with a publisher and it is looking quite likely that it will become a nice hard-copy book. Regardless, though, I will be placing it on the Catalyzed wiki.

What I've realized in starting this process is that it is actually very difficult to figure out what to cover. Once you have been programming for awhile, it tends to infect your brain. It actually modifies your thought processes and you forget what you didn't know when you started.

I'm hoping to accomplish a lot of things with this book, but there are two main items which I think are most important. First, I want to introduce the subject of programming and Perl clearly to those coming to either subject for the first time. Second, I want to teach all the little things that make Perl programming an enjoyable experience, the little things that let you really be productive in Perl.

I've got quite a bit of the book's contents worked out... but I have a question for all you Perl programmers out there... What, beyond the basics of all programming, should I be sure to cover?

What do you think every Perl programmer should know? What things help you on a daily basis and keep you working in Perl over other languages? What aspects of working in Perl do you think are most important and/or most different from other languages? What bit of Perl did you learn late and wish you knew much earlier in your Perl programming career?

Here's your chance to share your knowledge with the next generation of Perl programmers (I am ambitious, what can I say?) .. Share your thoughts in the comments!

Recently, there's been a distinction between a "developer" and a "programmer". Forgive me, I'm not citing the source as I don't feel digging around in Google for a while would help make this point any better, but I read an article stating that "Developers take pre-fabricated items and glue them together, as fast as they can, doing as little programming as necessary, where programmers convert caffeine into code; they live for the sheer idea of programming".

While this holds a good deal of truth, I have my own take on it....

The Simplex method was developed in 1947² by George Dantzig when programs referred to (military) strategies. It is a method for finding an optimal solution to a certain problem type called a Linear Program (LP). An optimal solution to an LP does not always exists, but when it does the Simplex method can find it³. This little scrap of a paper introduces an implementation of the Simplex algorithm using Perl. We will use an example to drive the plot.

When you ask someone in the community about the biggest advantage of using Perl 5, you most often get the answer “CPAN.” At least I have, and I have been agreeing with this point for a long time. Some even call perl a “platform to run CPAN on.” We, in the community itself, have little or no problem locating a module for a specific task that fits our needs. Either we already know a module, or we know a project and use what they use, or we are on a mailing list or IRC channel with people that we trust to give us a pointer. Even the fact that we know about specific tools is a big advantage.

To us, the diversity of CPAN is a clear win. We have no problems (but gain some huge possibilities) with CPAN holding old modules, modules that try to be complete, modules that try to be small, modules that try to be clever, and modules that try to be flexible side by side. We are happy to have the choice because we know how to make it.

But what’s a win here for us, is a big hurdle for newcomers and those that don’t have the time/resources to be part of the community. They have no idea about what to choose for which purposes.

I wanted to write a post giving some clues about where to look for modules, and how to decide which one suits your task for quite some time now. So, here it is.

The big buzz nowadays in the web-application hosting world is cloud servers. Cloud servers are virtual machines that can be deployed quickly and easily by the customer without intervention by the hosting company. They tend to live in very large data centers on clusters of hardware with specialized software designed to automatically manage the allocation, de-allocation and scaling of virtual machines.

The big player in the Cloud computing space is Amazon's Elastic Compute Cloud, or EC2. I've done a lot of work with hosting web applications on EC2 cloud servers and I find them to be extremely convenient and functional, especially compared to physical machines. They are, however, on the whole more expensive and require some specialized knowledge to manage effectively.

There is a relative newcomer to the cloud serving space, Mosso from Rackspace. Mosso's offering is quite similar to EC2, though the prices tend to be slightly cheaper.

There is very little in the way of direct comparison between EC2 and Mosso's Cloud servers and while the information about each is available, it takes some digging to get the real scoop.

In todays article, we will dig into both Amazon's EC2 and Mosso's Cloud-Servers with an eye toward the differences that will really matter to you as you try to decide which virtual server cluster upon which to deploy your Perl or Catalyst application.

So, it is still a bit of work to setup Reaction applications. The Tutorial walks you through it, but that’s still many lines of code and many places to introduce errors.

What I came up with last week is a module called ReactionX-Jumpstart, that comes with a reaction-jumpstart script that works similar to what Catalyst provides with its catalyst.pl.

It is nowhere near complete, it lacks many things and doesn’t even create the application’s scripts yet, but this is just a matter of time and decision making.

Now, let’s see what it can do.