SawyerX, in his ongoing stream of posts regarding marketing Perl, recently blogged about project websites and suggested we all start hiring, and paying for out of our own pockets, designers to market our free offerings. I kinda wanted to smack him after reading that. I try not to comment on marketing or advocacy, etc. because I really just don’t care. I don’t care if new people use perl or what they think of it. I know it’s good and I know it works. I like my hammer, I think it’s a great hammer, and if you judge by the projects I produce, you would find that to be obvious. However, I will say that even though I consider all this marketing talk to be annoying at best, he does have a point: Our OSS code is our resume. When applying to new jobs, it is easy to list things we did on a resume, but often times we are unable to provide cold hard code to employers because our previous employer owns the rights to it or we are bound by NDAs etc. This puts us in the situation where we often find ourselves saying, “Hey Guy, you should give me a job. I’m a great architect, I’ve built some awesome buildings, many of which you have seen. I just can’t show you them, but trust me, I’m good.” That obviously sucks.

So, while I disagree with the need to throw money at designers to make pretty websites for libraries whose target audience is Perl developers who already know how to work CPAN and probably know how the rest of us roll, it’s be nice to have websites for end-user applications. You know, the kind of stuff people who don’t give a damn about the API use, whether it be from the web or the command line. Those are the people that might not know to look in CPAN / perldoc. Those are the people who don’t care about our API docs, they just want interface docs and frequent use cases illustrated. In this case, it makes perfect sense to have pretty, user-friendly websites published. IMHO, you should also have a PDF manual. But for libraries? give me a break guy. We got better things to do.

Is it just me who has to re-authenticate on every single page load, or is this a known issue? It's really annoying? I seem to keep my session fine on the front page, but the MT interface asks me to authenticate every. single. time. I change pages, whether through a GET or POST request.

Today, Ovid blogged about long-running test-suites and how to optimize them.

Yesterday, I was thinking about this same exact thing. I have a project where the compile-time hit of the collective libraries that make up the application is a little on the heavy side. I thought to myself that it would be good use something like Test::Aggregate, but I wondered if that could mean that some of my tests could be affected by a downstream dependency where the state could be changing at the class level. I don’t think it’s very probable, but it could happen and it would be a real pain to debug.

I just released a new version of Cantella::Worker and I'm really happy with the improvements. I updated Cantella::Worker::Manager::Prefork and added a couple of options to add a little more fine-grained controls to the worker processes, such as whether the workers should detach from the manager's session or not and a way to adjust the priority of worker processes. More importantly, I added the "program name" attribute and functionality and I made children automatically shut down if their manager dies, so that you never have an unsupervised worker pool. Special thanks to Rocco Caputo for his help. So, here's an example so you can see the progress made:

Yesterday and today I released to CPAN Cantella::Worker and Cantella::Worker::Role::Beanstalk. I am very happy with these two packages. They are the culmination of about a month of on-and-off playing around with different approaches to having distributed event-driven worker processes. As an added benefit, I can also run a pool of beanstalkd servers in case I need to bring one down for maintenance or I have some unexpected downtime.

I am aware of the existence of MooseX-Workers, but it didn’t ‘feel’ right for the job. Additionally, the MooseX-Workers approach of running jobs in a separate process via POE::Wheel::Run didn’t work very well for my approach. You see, in order to reserve a job from beanstalk, a connection must be open with the server. During a fork, I could either fork and keep file handles open, making sure the file-handle survived, or lose my connection and my reserved job. Additionally, the constant forking was a little too much over-head for the very simple jobs I do.

Instead of trying to make MooseX-Workers do what it wasn’t designed to, I decided to go with a preforking approach and roll my own approach. I have a manager process and n children processes. Children processes are free to work by themselves and block if they want to. Communications between the manager and worker processes happens via POSIX signals. Right now 3 commands are supported, pause (USR1), resume (USR2), shutdown (TERM & INT).

So far, the preforking manager is pretty basic, but I look forward to adding the following in the future:

• Detaching children that terminate themselves if the parent dies
• User, group, priority adjustments in the child process
• More real world examples.