I've been working pretty much exclusively in Java for the last few years. However, we have a subproject to do some system/application automation work that's written in Perl. It's currently a CLI tool that allows us to install/upgrade our application remotely, restart the service(s) (the app runs on Solaris), and other fun stuff.
We're not only expanding its scope, but we're giving it a nice shiny GUI shell via a website. After working for years on Perl webapps I've been out of the loop for years. That can actually be a worse position than not knowing anything, because I have outdated ideas and biases as to how things 'should' work.
And now we get to my question. It looks like people are commonly using Catalyst, CGI:Application, Jifty. Are there others? And what's the "best" one to use?
Some constraints/ideas:
Perl is supported at our company for a nifty internal testing/automation suite, some build automation, and probably under-the-radar stuff, but that's about it.
By comparison, this is a project we're not only hoping will be long-lived, but it will be deployed on servers not in our control (thus the Krang-like deployment above), and used by people (mostly IT staff) not in our control.
Will they freak out that this is a Perl app? Unknown -- what do you think? (This is IT in healthcare, FWIW.) Do we even need to tell them it's Perl (e.g., "it's a black box")? Unknown, but IMO we likely do.
Reading the recent 'perl is dying/dead' threads here [on use.perl] also makes me wonder about hiring. Hearing that quality organizations are having trouble finding competent Perl developers is disturbing, whatever the reason. For instance, take Grant Street. From what I've heard, they have a solid team that gets to work on pretty interesting stuff, not your typical CRUD tedium. You'd think with that combo they'd attract competent people like honey attracts bears. But they're always looking.
There's always an argument that you can hire someone smart and they can just "pick up" the language/platform. I think that's true if you have 6-12 months to burn. It's easy to learn a language, even Perl. It's harder and more time-consuming to learn its ecosystem -- which modules to use and not-use, idioms, approaches for common tasks, etc. It's not that these things are required to get things done, it's that the rest of the team will have to go over all of the new hire's work much more closely.
----------
[1] Wasn't there a project to extract the Krang build logic into something self-contained? The projects occupying that area of my brain are 'Smolder' (which is aimed at code coverage and reports) and 'Matchstick' (which looks to have been abandoned). Is there something else?
If you write it like a perl app from 10 years ago, they will probably freak out. If you tell someone who doesn't read source code that it is a perl app, they might freak out.
If you write it like most Catalyst devs say to, you'll probably have a well-engineered and maintainable app.
Disclaimer: I'm not a webapp developer.
Re:Will they freak out that this is a Perl app?
lachoy on 2008-12-13T14:17:37
The "freak out" comment was more about it being in Perl than the technology. I suspect that if we pitch it as a black box that does HTTP we'll be okay, but I'm a little wary -- because of inexperience, not because I don't think Perl can do what it's supposed to.
Good words about Catalyst though, thanks.
A pre-written app like webmin [1] might suffice.
But if you're writing it, I suggest starting with CGI::Application.
As for a database, I'm doubtful you will do well without one, so add BerkeleyDB [2] to the mix.
[2] http://www.oracle.com/technology/products/berkeley-db/index.html
Re:That's a big topic...
lachoy on 2008-12-13T14:20:43
Regarding no database: you can do an awful lot with the filesystem. I have a couple of reasons for wanting to ditch the database:
- Acceptance: It's another piece of technology for end-users (IT folks) to object to -- "Perl's okay, but we're an MSSQL shop!"
- Complexity: Typical ORM mismatch foo.
Good thought about BerkeleyDB though. Even though it's gained a lot of complexity you can still use it very simply.
It pretty much satisfies all of the items you require, especially if you look at the Catalyst::Plugin::ActionClass::REST (or whatever it's called) on CPAN. I've deployed sites without a database (in fact my geneology site has just a single static file as it's "Model". CGI::Application is also a fair choice, though I've never used it directly.
As for Grant Street Group. I've sent my resume into them twice and never heard from them (not even a confirmation that my email was received). I know others who have applied and have interviewed
It is actually quite easy to separate the build system from krang. I did that and use it in my projects. I have put it on google http://code.google.com/p/btfm/
Re:http://code.google.com/p/btfm/
lachoy on 2008-12-13T14:21:43
This is cool, I may use this. Thanks!
If you're looking for something with low dependencies and low learning curve, CGI::Application is definitely the way to go. You could also use something like Titanium which is pretty much just a bundle of C::A and some of it's more useful plugins.
As far as self-contained apps go, you could go the Krang, PAR or CPAN route. All of which have problems:
Krang
======
PROS - This is what I did for Smolder and it makes installation fairly simple if you know what platforms you're going to deploy to since you can prebuild binaries. BTW, I just copy-pasted the build code from krang (bin/krang_build and lib/Krang/Platform.pm) and modified for Smolder.
CONS - Several people have approached me about building packages of Smolder for various linux distributions and that's nearly impossible. Since we bundle everything together it's hard to get it to fit into their package managers. It's also pretty non-standard so some people look at it funny when they see the install process.
PAR
===
PROS - If you go with something like HTTP::Engine for the server and DBD::SQLite for database, then you have a pure Perl solution. You should be able to make a
CONS - PAR is, IMO still very magical and may have problems. Plus I've never used it
CPAN
====
PROS - With a pure-Perl approach like the one I described above for the PAR option you can make it dead simple for any Perl folks to install via the cpan shell. You don't need to self manage your dependencies (like the Krang style). It's also pretty trivial for distro packagers to make a package for their system since doing that for Perl modules is pretty standard stuff.
CONS - Non-Perl folks will probably not be happy. Especially if they don't have a working CPAN install or the machine isn't connected to the network.
Hope that helps!
Re:my scattered reply
lachoy on 2008-12-13T14:33:49
Very helpful, thanks!
Catalyst has some builtin PAR support.
Reading the recent 'perl is dying/dead' threads here [on use.perl] also makes me wonder about hiring.
They're not dead/dying but sometimes they think life stops, unless/until Perl get the best OO model, easiest deployment, best libraries and so on, and so on. They're just so demanding to their selfs.
Re:Catalyst and PAR
chromatic on 2008-12-12T19:47:00
If we can't improve Perl beyond fixing bugs, why is there even a p5p? When did Perl become the sound of the wall I'm beating my head against?
Re:Catalyst and PAR
pnu on 2008-12-12T21:23:45
I think we can/should/will (improve Perl 5), but meanwhile we must learn to live with the shortcomings it has. No language or environment is perfect. This wouldn't be a problem, unless clueless people start to believe the FUD arising from this self criticism.
I really wouldn't like to distract the focus from Perl 6 since it will be a great step forward for the whole world of programming, but there are success stories written all the time with Perl 5. Not seeing this and appreciating it alienates unaware people and future audience of Perl 6.
But I thought we agree on this, so maybe I didn't get your point? Sorry.
;-) Re:Catalyst and PAR
chromatic on 2008-12-12T21:39:25
The existence of Perl 6 is no excuse not to improve Perl 5. The fact that you can declare a class in Perl 5 with the
packagekeyword and subclass a parent withuse baseor pushing onto@ISAdoes not mean we can never add a little syntactic sugar to make that code clearer and more convenient.
If you're allowed to build things a bit from the ground up, you should play with Continuity. I've found it to be fantastic for almost direct ports from command line to web interfaces.
