Al Newkirk

10 Reasons to Never Use Perl, Ever

The title of this article is somewhat troll-bait albeit a sentiment posited by many Perl critics. Perl is an awesome and relevant programming language with a huge repository of modules, expressive syntax, and quirky semantics (which I love) and many other benefits which derive from an uncommon approach towards software development; having said that, the following are ten reason to love or hate the Perl programming language.

1. Expressiveness. It’s Multiple Choice All The Way Down.

The Perl programming language and its community are centered around the TIMTOWTDI philosphy (there’s is more than one way to do it), and it’s multiple-choice all the way down, i.e. Perl is a multi-paradigm and context-sensitive language, with support for compiler directives, and can be configured to require implicit or explicit syntax. A simple Perl 5 script feels like a superset of shell scripting. Enable the strict and warnings pragmas and Perl starts to feel like a dynamic high-level programming language. Leverage any of the many object systems available, e.g. mop, Moo, Moose, et al, and it starts feeling like you’re implementing a structured and tightly coupled architecture. What’s nice is that none of this is forced on you; you opt-in for additional features where desired. Due to the ability to scale/morph Perl into more strict, formal and powerful variants as-needed is one of the main reasons I enjoy developing with it.

Ali Anari

Lessons Learned Publishing My First CPAN Module

So you want to join the ranks of thousands of other #perl hackers and release something to the community? I just developed my first standalone Perl module at Crowdtilt called WebService::NationBuilder, and the process was actually a lot more straightforward than I thought it would be. Keep reading to find out how simple it really is to write your own module and become a published CPAN (Comprehensive Perl Archive Network) author!

PAUSE then play

Head on over to PAUSE, the Perl Authors Upload SErver and register your very own account using this form. Your account will get its own directory (mine turned out to be authors/id/A/AA/AANARI) where your uploaded distributions will be indexed and rapidly propogated across CPAN and its mirrors thanks to some of the fast rsync stuff the PAUSE workers have developed. Don’t let the old-school feel of the PAUSE site fool you, it’s a serious platform that was created by Andreas Koenig in 1995 and has been closely maintained since. For the ever curious, you can dive into the source GitHub repo here.

Matt Williams

Your First Hire Should Be a Sysadmin

From the very beginning of Crowdtilt, we envisioned an architecture where the only limitation to how fast we deployed code was the speed at which we could actually develop. Our CTO saw the value in hiring a Sysadmin to focus on this objective from day one. That’s where I come in and here’s how I’ve helped us achieve the goal…

Configuration Management

The first order of business was managing our systems at a higher level. It took very little deliberation to decide on Chef as our configuration management (CM) tool. Our prior experience, the massive collection of available application “cookbooks”, and a very active community were enough to convince us that it was the right tool.

The nice thing about integrating with a CM framework from the beginning is being able to tie in each piece of a web-stack as it becomes necessary, instead of having the monolithic task of converting an entire architecture. The very start of our app involved a Postgres database, the web app, and Nginx out front – fairly typical. We were able to utilize community Chef code for Postgres and Nginx and all of our site specific modifications were implemented in our Crowdtilt “cookbook”. We rolled our own Chef resources for app deployment and wallah – running chef-client now deploys code from our git branches. Combined with great plugins like knife-ec2, Chef is now building our Cloud servers and then configuring our software on top of them!