If you have a Perl-related news item you'd like to share, you may post it in the Perl Newssection.
Please try to avoid duplicating news; but pointers (with summaries) to important stories on other sites are acceptable here.
Carl Mäsak's upcoming workshop is for anyone who knows at least a little Perl (5 or 6) and wants to see, learn or discuss best practice basics regarding coding simplicity, readability, or elegance in Perl (5 or 6).
This workshop is designed to deliver benefits for all, but should be especially suitable for Perl 5 programmers wishing to spend a few hours comparing and contrasting it with Perl 6.
I'm one of a dozen or so who have signed up already. Hope to see some more monks there!
For the record, I've been programming in Perl 5 for around 15 years, so I'm a bit biased. Having said that, I really like Perl. Don't listen to the naysayers, and don't think that its age is somehow an indicator of its shelf live. The best way to look at Perl is to see it in comparison to other languages:
PHP - PHP is a pretty good web programming language; don't get me wrong. But, it's only a web programming language. Even web applications need their cronjobs to do clean up processes, and you have to do some strange stuff to make that happen. Never mind having to write a quick script for UNIX administrator or parsing a text file. Plus, PHP doesn't have CPAN.
Ruby - The language is too new and "script kiddie" for my tastes. The only thing I hear about Ruby is Ruby on Rails. Perl has Catalyst and Dancer (as MVC frameworks), which are damn fine MVCs, but it's not the cornerstone of the language. You're not going to find "Ruby" as a requirement in job offers any time soon (if ever). Plus, Ruby doesn't have CPAN.
Python - In the words of Larry Wall, Python is just snake oil. Python cares about whitespace and the last language I used that cared about whitespace was BASIC. Also, like BASIC, it's was essentially designed to be a easy-to-use beginner's language. Finally, no CPAN here.
Java - Java is a problem child language. The concept was to have this virtual machine that runs on any platform, but because of the huge popularity of the language in college courses, you see Java applications every where that they shouldn't be. For example, in-house server-based web applications shouldn't exist. It's a single server with specs they define and it gets wrapped in a separate VM with a limited memory footprint. Java is bloated, and they don't have CPAN.
C# - I've actually have been using this language quite a bit now, and I've seemed to have formed a love/hate relationship with it. Being able to overload methods with different parameters is cool and fun. But, if you want a language that will bitch at your every line of code about type casting, then C# is for you. My god, it wants you to put explicit casting EVERYWHERE! Making classes are fun, but you suddenly realize that you're spending more time making classes to make the damn language just WORK than actually writing real code.
Also, C# doesn't have...okay, it has .NET, which is really good and extensive. However, I still like CPAN better because you can still write your own modules and complain at the author about a bug or design flaw. And they are all free. Plus, Perl is working towards Perl.NET in the future, so we may be designing Windows applications before long.
Perl is a great language that has:
Regular Expressions - If it's one thing that Perl can do well, it's text manipulation. Yes, many languages have regular expressions, but Perl has damn near invented them, and there's a reason why grep has a "Perl Regular Expression" mode, or why Oracle has a section on "Perl-influenced Extensions in Oracle Regular Expressions". It's built-in and doesn't require any modules.
Flexibility - You have three basic variable types: Scalars, Arrays, and Hashes. That's it. That's all you need. You don't have a int, byte, string, or any of that crap. Perl figures it out just fine. And you can use references all you want without fear of memory leaks or cause the whole PC to crash. The language just works.
Portability - Perl works great on the web. It works great in UNIX. It even works pretty well in Windows. It's not pigeon-holed to a single function. It's a jack-of-all-trades, but also a master of (mostly) everything.
It's easy to do a lot with a little code - Give me a 1K blank file and I can write all kinds of things with that space. Even a Perl one-liner is great to add into a command line pipe.
CPAN - I cannot stress how good it is to find just about anything you need for anything. What is "anything"? Well, how about DB modules for every database or thing you could imagine, ranging from Oracle to iPod to CSV to Adabas to Yaswi? How about several fully featured web servers? How about a Excel file reader, or a SNMP module, or a module that reads comments for debug lines, or modules that help you program faster? A project that I'm doing right now is writing a dynamic Terraria map generator, augmenting from an existing module called Games::RolePlay::MapGen. .NET would never have something like that.
Plus, it's a breeze to install any module via CPAN. Get it from Debian. Install it from CPAN directly. It does as good a job as apt-get in resolving dependencies. I have no problem telling my sysadmin to install X module from CPAN, since it's just a simple one-liner command.
Yes, it has its flaws, and yes, I'm biased towards it, but you've probably already heard the negatives too many times. They don't outweigh the positives, not by a long shot.
brian d foy has been experimenting with crowd-funding for open source projects, so I approached him about running a campaign for Pinto. I made a short video and we launched the campaign on Crowdtilt (which happens to be Perl shop). I'd really appreciate if you could help spread the word!
Pinto is a robust application for creating and managing custom repositories of Perl modules. You can use any combination of CPAN modules and private modules. And the repository works seamlessly with installer clients like cpan and cpanm.
When you build up your system from a Pinto repository, you'll get exactly the modules you want and the versions you want -- every time. Pinto also has some novel tools for helping you manage upgrades to your dependencies
The funds of the Crowdtilt campaign will be used to enhance Pinto to fetch specific versions of CPAN modules (without you having to know which distribution they came from). That will make is easy to build up a repository that contains all the modules needed for your legacy environment.
In this post I want to share my chef cookbook called cpan.
Chef is the modern platform for deploy automation and configuration.
One of chef great feature - one may create custom recipes to deploy/configure
specific applications, written on any languages. When I first met with chef,
I had already had some experience on deploying perl applications. I used standard build cycle:
So the idea of integrating perl application install come into my mind in natural way.
With cpan cookbook one may do standard perl build/test/install idioms using chef.
Here I am putting some use cases, just to give some sense of what it is. If you like it, you
may learn more on http://community.opscode.com/cookbooks/cpan.
Cpan cookbook use cases
Installing application, distributed with tar-ball. Let's say you have already fetch and store tar-ball with
others chef resources (the following code is self-explanatory). So you may easily install it into given install base:
execute 'cd /tmp/ && tar -xzf app.tag.gz'
cpan_client 'my application' do
I'll be doing a live webcast about Pinto with Randal Schwartz for FLOSS Weekly. Tune in to http://live.twit.tv next Wednesday, March 27 at 08:30 (Pacific Time) to the see the show. Your can send in your questions in real-time via the #twitlive channel on irc.twit.tv. See you then!
Pinto is a robust tool for creating custom CPAN-like repositories of Perl modules. You can fill your repository with any combination of private and public modules, and then build/test/install them using the standard tools (e.g. cpan, cpanm, cpanp). Since you control the repository, you'll get exactly the same modules every time. Pinto also has some novel tools for tracking and managing changes, so you can upgrade modules with confidence and control.
Often when deploying application one may face the risk of divergence between testing and production environment.
Even though you have a stage servers `like production one', it'd be reasonable to check distributive in
production environment before release is happened. I would call it `early` testing. Yes, of course, some
subtle bugs will arise only in runtime phase, and unit test cannot cover it all, I say here about
prerequisite unmet issues. In perl world unit tests and prerequisites checks are executed in standart way. One follows standard procedure, when installing things.
I put here
example for Module::Build based project, but with ExtUtils::MakeMaker it's almost the same:
perl Build.PL # check dependencies and generate build file
./Build test # run unit tests
The cut off for submitting talks for YAPC::NA in Austin was supposed to be the 15th, but we’re moving the deadline to the end of this month. I've posted a link in reddit; maybe others can spread this news in forums, channels, mailing lists, etc. frequented by folk you'd like to see giving talks at YAPC. Thanks!
The Salt Lake Perl Mongers has been rebooted. We intend to hold monthly meetings, or occasional "emergency social meets" for those times when the monthly meeting doesn't come together. If you're in the Salt Lake area, join our mailing list and get involved.
The mailing list subscription page is available here. Once we've organized our first event I'll make one more announcement here in the Perl News section.
Perl Mongers groups get together for presentations and discussions about Perl and Perl-related topics. There's usually a social component as well. Perl Mongers is a great way to get to know the local Perl community, as well as to learn and share ideas. Over the past couple of years I've found the PM groups that I've participated in (Los Angeles, and Thousand Oaks) to not only be excellent resources, but also a lot of fun.
The Salt Lake Perl Mongers group seems to be arousing a lot of local interest. Please join us if you're in the area!
Jenkins - is well known continues integration server. One of it's great features - one may extend it by writing custom plug-ins. Recently I have created one plug-in to build and make distributive of perl applications.
It implements standard build scheme:
cd to source directory
install dependencies from source directory into local directory
and optionally create distributive from source directory
Other features are:
find 'tagged' directory with maximum version number ( implementing install from subversion tags )
applying different patches ( install other cpan modules )