Penfold's Journal http://use.perl.org/~Penfold/journal/ Penfold's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:29:42+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 Penfold's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~Penfold/journal/ The Rails-is-a-Ghetto rant http://use.perl.org/~Penfold/journal/35307?from=rss The <a href="http://zedshaw.com/rants/rails_is_a_ghetto.html">infamous Zed Rails Rant</a> was drawn to my attention a few days ago.<br> <br>Makes interesting reading, and I have to say I don't grok enough about the Rails community and names mentioned to be fully clear about the details of his issues, but there were a couple of interesting remarks that drew my attention:<dl> <dt>'The MBA attitude is best summarized in this statement, &#8220;I demand all of your creativity, yet trust none of your judgment.&#8221;'</dt><dd>Made me wince rather - been there, done that, worked for people who wouldn't take 'no, this is technically impossible/bad net ettiquette/stupid/can't be done robustly in the timescale you want' for an answer.</dd><dt>"...Ruby on Rails means stay on the Rails. There is an established best practice way to build web applications with Rails and that&#8217;s the entire point of the system."</dt><dd>This definitely caught my eye. Perl has TWTOWTDI writ large through it, and it is, I am really very sure, a major reason we're getting no love from outside the community in the web framework arena. Despite the fact there's a number of damn fine web frameworks out there. Rails wins by being<nobr> <wbr></nobr>/the/ Ruby web framework, having a set of established best practices so any monkey with half a brain and some coding skills can produce the goods, having an aggressive hype machine and being able to deliver the promised hype. (Yes, you can take issue with that last, if you like<nobr> <wbr></nobr>:) but the fact remains there<nobr> <wbr></nobr>/are/ some damn good websites made with Rails.)</dd></dl> Penfold 2008-01-06T18:18:43+00:00 journal 21st Century Perl (part 1) http://use.perl.org/~Penfold/journal/35160?from=rss So, here we are: blank slate, new project. The only stipulations from on high are an API to code to, which mandates Perl (good job, really, as that's why we're all here, I hope). In a nutshell, I have to duplicate the essential methods of a certain sprawling God Object, but talking to someplace different. Fortunately, in this context, 'essential' means mostly the ones it originally was designed to provide, not the subsequent decade of accumulated cruft. <p> I was, when I started this blog, not... wholly enlightened. I knew there was a place I and my Perl needed to be, and I was aware that there seemed to be a lot of people in the same boat, some searching for that place, some dismissing Perl because it didn't seem to be in that place. If you're coming to this blog from the enlightened perspective I started out searching for, none of this should be all that new, really: it isn't rocket science, and it certainly is possible in Perl, just as it is in any other modern programming language. So, let's begin... </p><p><nobr> <wbr></nobr>...with Unit Tests. </p><p> One of the 'scales falling from my eyes' moments I had at $PreviousJob (involving Java and the like, for those for whom it's been so long they can't remember previous posts here) was in the realm of unit testing and the whole Test Driven Development philosophy. The decree came from On High (small company, so only one level up), "Thou shalt write unit tests." </p><p> I groaned. " What am I? QA?" </p><p> I had to figure out the answer for that one myself, but when I did, it was a Road to Damascus moment, a real 'holy shit, of course' leap. And it's this: 21st Century Perl Revelation # 1: </p><p> <em>We all write unit tests </em>anyway<em>.</em> </p><p> <em>We just don't necessarily </em>call<em> them unit tests or treat them like it. </em> </p><p>Think about it. You write a new piece of code, and then you satisfy yourself it works. First off, by the simple things like 'is it actually syntactically correct Perl', and then you start writing little command-line Perl one and two liners to invoke the code in various ways and see if and how it breaks. It does, so we move on. And a little while later, something makes us refactor the code, and we go back and we write <em>more</em> little command-line Perl one and two liners to make sure it still works. </p><p> Those are unit tests. Except that if you're like I was, you never kept the little Perl one liners from one iteration to the next. </p><p> Behold, <code>Test::More</code> and all its red-headed stepchildren. </p><p> Your repeated invocations of <code>perl -cw My::New::Module</code>? </p><p> <code> use Test::More plan_tests =&gt; 1; <br> use_ok(qw/My::New::Module/); </code> </p><p>Glory Hallelujah, a unit test. And blow me, if it isn't even less typing: <code>prove -v t/*.t</code>, or even <code>make test</code>. Praise the Lord, I have <em>seen</em> the light! The first step on the road to salvation. </p><p> Look at that code for that method you just put in the <code>sub {}</code> declaration for. Ask yourself, <em>how would I check if this works?</em> What is my little Perl one or two liner going to look like? Define "works" for your method, for your module. Write some tests that encapsulate that definition of "works" <em>before you even finish coding the module. </em>Save them under useful names in t/. Run them, <em>every time you change your code.</em> </p><p> Testify, brother.</p> Penfold 2007-12-20T07:34:15+00:00 journal sleep(24*60*60*rand(200)); post(); # once more http://use.perl.org/~Penfold/journal/35159?from=rss <p>Amid groans, no doubt, I&#8217;m back.</p><p>Part of the problem with this blog, from my point of view, is I actually have too much I want to get off my chest, and just when I start thinking I have my ducks in a row, along comes another concept or idea (or even module) that makes me re-evaluate the things I believe and want to put forward.</p><p>For the first time in a while, my job here at Big Purple Towers in London hasn&#8217;t been about maintaining a 10-year old monolith of a Perl app (really, you don&#8217;t wanna know&#8230; it&#8217;s scary. The 14,000 line God Object is particularly whimper-inducing), but instead writing some brand new, standalone code to make bits of that behemoth talk to something else.</p><p>Time to put my money where my mouth is.</p> Penfold 2007-12-20T07:28:43+00:00 journal A question... http://use.perl.org/~Penfold/journal/33288?from=rss ...for my scant collection of readers. <p> What makes a good or bad <a href="http://jobs.perl.org/">Perl job advert</a>? What key words or phrases get you going, above and beyond the response 'yes I know how to do that'?</p> Penfold 2007-05-16T08:13:17+00:00 journal Performance Tests http://use.perl.org/~Penfold/journal/33287?from=rss Every now and then, it rears its head on one or other IRC channel. Someone trots out one of a number of web sites that purports to compare like with like, hammering the crap out of various implementations of a web app in Rails, various Perl frameworks and not-frameworks, J2EE, PHP, etc etc, and attempts to draw meaningful conclusions from the results. <p> Setting aside, for the moment, <a href="http://perlcast.com/2007/04/08/brian-d-foy-on-benchmarking/">brian d. foy's tongue-in-cheek demolition of benchmarking as a valid tool</a>, what do we learn from these? </p><p> Actually, mostly, we learn that a single instance of almost any web app written in just about any language on semi-decent hardware, pounded on by JMeter, ab or whatever will cough up well over 100 hits/second without actually breaking into much of a sweat. </p><p> Let's stop right there for our first remedial maths class, OK? </p><p> 100 hits/second. </p><p> That's 6,000 hits a minute. 360,000 hits an hour. </p><p> <strong>Eight point six million </strong>hits a day. And change. </p><p> And that's page views - c'mon, you don't serve your static images out of of your webapp framework. That's a dickens of a lot of traffic. To give you an idea, CricInfo.com's record month while I was there was a quarter of a billion page views... that's about 8.3 million a day on <em>the biggest single-sport website on the net.</em> </p><p> You're expecting that amount of traffic? Paying for the bandwidth is going to be a much bigger worry than whether your web app framework can cope. </p><p> Stick an ad on every page, from Y!, Google, whoever. A week's traffic, tops, and you can afford another server. Hell, you can afford two and a load-balancer. And quite frankly, your rate-determining step is almost certainly NOT how fast your underlying development framework can generate the pages, but how well-written your code and your DB are, how cacheable the pages are, how big they are, and how laggy your average client is. One missing database index can turn a 0.02s query into a 3s query. </p><p> Get over it, folks.</p> Penfold 2007-05-16T07:40:09+00:00 journal sleep(24*60*60*rand(200)); post(); http://use.perl.org/~Penfold/journal/33286?from=rss OK - back now<nobr> <wbr></nobr>:) The management would like to apologise for the silence from this corner for 2007 to date - this has been mostly due to having way too much on my plate. Things have now settled down a bit, and my morning commute time seems to be available for blogging again, so, here we go. <p> Before we move back to looking at Perl in the enterprise, I'd like to take a look at a recent O'Reilly OnLamp posting, on the subject of <a href="http://www.oreillynet.com/onlamp/blog/2007/05/the_perl_job_market_blues.html">the Perl job market</a> here in London. The thread of the argument, and one which I'm seeing here working for Yahoo!, is that we're seeing fewer, and poorer, candidates applying for Perl jobs than in the past. He lists a number of explicit and implicit reasons, but I'm going to go out a little bit on a limb here, and flag a couple of my own reasons to do with the <em>perception</em> of Perl, a subject near and dear to the core of this blog. Implicit, I think, in the post, though it isn't actually said, is that it's looking at 'enterprise' level Perl jobs: things for big apps for big sites and companies. </p><p> I'm not going to go so far as to say Perl is actually dying as a language: you can't claim a language that holds up any number of the biggest sites on the 'net, and is pretty much a <em>lingua franca</em> among sysadmin and CGI programmers is going the way of the dodo. But as I've said several times before, it seems to me to be suffering from a perception issue, to do with the way it's marketed, and how its culture's evolved and is presented. </p><p> Marketing? Sure. Where's the glossy, media-friendly, Web 2.0-looking (you <em>know</em> what I mean - big, bold sans serif fonts and gradient-filled boxes in darkened primary colours) site that sells Perl as a solution? <a href="http://rubyonrails.com/">Ruby on Rails</a> has one, that's been shoved in our faces with the growing rise of Rails as a rapid enterprise web development framework. And Perl's better than Rails[1] - it's more mature, better supported, has a vast library of excellent modules to handle just about any feature you could want to throw at it (too many, perhaps!). It just isn't sexy, and it's hard to sell it as such. </p><p> Perl <em>has</em> MVC frameworks[2] - it has, if anything, <a href="http://www.oreillynet.com/onlamp/blog/2006/05/mvc_frameworks_in_perl.html">too many of them</a>. The barrier to entry, though, is two-fold - first off, they are, by their very nature, that bit harder to assimilate than good old CGI.pm, which scares off the Perl scripters. Secondly, Perl's reputation scares off the suits. </p><p> What do we need to do, then? </p><p> Actually, I think it's twofold: </p><ul> <li>the <a href="http://www.oreillynet.com/onlamp/blog/2007/05/free_perl_training_in_london.html">BBC's free Perl training</a> is a great idea, but as I've banged on before, we need to teach Perl folks to program properly, and understand OO concepts and good design patterns - that's, to a degree, independent of language, but Perl's history drags it down. And hell, if that means we have to throw away TWTOWDTI and aggressively promote something like <a href="http://www.oreillynet.com/onlamp/blog/2007/05/free_perl_training_in_london.html">Moose</a> as The One Way to do OO in Perl, let's do it. With tutorials, examples, the works.</li><li>we need to sell Perl as MVC framework. Hard, slick, polished, finding all the good things that make Perl the right way to do it.</li></ul><p>[1] Yes. Controversial statement. But if I didn't believe it, I'd a) not be writing this blog, and b) have learned to program in Ruby by now.<nobr> <wbr></nobr>:) [2] More later. Oh my God, yes.</p> Penfold 2007-05-16T07:38:54+00:00 journal Sometimes you wonder if it's worth the effort... http://use.perl.org/~Penfold/journal/31707?from=rss <p>So... last night, one of the job agencies I fed my CV to, who knows I've actually accepted a position elsewhere, scattershot a plea for a 6 month PHP contract to a large list of people.</p><p>I dropped back a mostly polite note pointing out that this wasn't perhaps very smart. The reply:</p><p>"Unfortunatly you are included in the same file as PHP, along with every other perl developer."</p><p>Houston, we have a perception problem.</p> Penfold 2006-11-24T09:18:06+00:00 journal "OO Perl" http://use.perl.org/~Penfold/journal/31702?from=rss A couple of people on the <strong> <a href="http://use.perl.org/">use Perl;</a> </strong> version of this blog picked up on my use of 'OO Perl' as a term, and were less than complimentary about the language's OO features. I'm not here to defend that: however, it set me thinking about why I used that term, and whether it was what I actually meant. <p> It was, at least in part, prompted by my job search (more on that later, I promise). Look down <a href="http://jobs.perl.org/">jobs.perl.org</a>, and you'll find that most of the well-paying jobs mention, in some roundabout way, LAMP or a variant thereof, and stipulate 'OO Perl'. The fact that I had 'OO Perl' (and legitimately so) on my CV (resum&#233; for you transPondials) was welcomed with open arms by several recruiters who absolutely couldn't wait to get my details to their clients. </p><p> I think, in the end, this goes back to some of the comments I made about the Swiss Army Chainsaw, specifically, the distinction between Perl scripters and Perl programmers. How do you tell if someone's the latter, if their CV just says 'Perl'? </p><p> I don't think 'OO Perl' necessarily has to mean, literally, Perl in the Perl5 "<em>bless {};</em>" way. What the recruiters are trying to say, I'm pretty sure, is 'someone who treats Perl like a high-level programming language'. 'OO Perl' is, if you like, a <a href="http://en.wikipedia.org.uk/wiki/Shibboleth">shibboleth</a>, to find the programmers amid the scripters, since a scripter's response will be either 'huh?' or 'no, that's scary'. (Joking a little, but you get the point.) It isn't, by any means, a perfect test, but it seems to me that if someone both uses OO Perl, and <em>consciously</em> self-identifies as doing so, they fall on the 'programmer' side of the divide. </p><p> And of course the problem, both for the recruiters and for our definition of LAMP++, is that Perl the language doesn't mandate it. Any more, actually, than Java the language does. You can quite happily write little Java ten-liners to do some mundane task that mangles a file, and never consciously touch an OO feature of the language. You can write really bad Java just as much as you can really bad Perl. </p><p> But... and here's the kicker... The frameworks that most Java enterprise projects are written in pretty much <em>do</em> mandate an OO approach, and what my Uni lecturers would call 'good software engineering principles'. And that means that folks raised in that environment have it as a similar shibboleth to 'OO Perl' to prove their credentials in the Java world. Now sure, once you start using Class::DBI, Rose::DB or DBIx::Class for your DBI abstraction layer, or a goodly number of the popular CPAN modules, you're at least required to talk to them in an OO way. But there's nothing to stop your actual application code being a Big Ball Of Mud, a God Object, or any number of other anti-pattern horrors. </p><p> Which reminds me. I should talk about Design Patterns.</p> Penfold 2006-11-23T14:29:52+00:00 journal This blog http://use.perl.org/~Penfold/journal/31701?from=rss <p>By way of explanation: this blog is simultaneously posted (now I've caught up) here and on <a href="http://perlent.blogspot.com/">Blogger</a>.</p><p>It's to some extent a documentation of a long thought process, and even now, I'm finding myself reposting things here that I've since thought about and revised my opinions on.</p><p>As to where it's headed? I'm not exactly sure, but I can see a light of some sort at the end of the tunnel, and I don't think it's an oncoming train!</p> Penfold 2006-11-23T09:40:49+00:00 journal So, what IS 'enterprise'? http://use.perl.org/~Penfold/journal/31700?from=rss <p>Time to bite the bullet, I guess. What do we mean by 'enterprise'?<br> <br>Consulting the Oracle, more formally known as Wikipedia, we find, in the <a href="http://en.wikipedia.org/wiki/Enterprise_software">Enterprise software</a> entry:</p><p><div class="quote"><p>Enterprise application software is application software that performs business functions such as accounting, production scheduling, customer information tracking, bank account maintenance, and the like. It is almost always hosted on servers, and is used by multiple employees of the same organisation. <strong>It can also be any software application hosted on a server which simultaneously provides services to a large number of users, typically over a computer network.</strong> This definition contrasts the more common single-user software applications which run on the user's own local computer, and serve only one user at a time.</p></div><p>Actually, y'know? That's not bad. The first half is the 'traditional' definition of 'enterprise', perhaps, but I want to zoom in on the bolded sentence: "<em>It can be any software application hosted on a server which simultaneously provides services to a large number of users, typically over a computer network.</em>". The main reason I'm aiming for that is that it then covers not only internal CMS's, publishing applications and the like, but also end-user facing systems (such as, for example, Amazon or Flickr).<br> <br>Let's take that second sentence as our prototype definition, and dissect it to see what it implies. I'm very aware that I'm reaching, just a touch, with some of this, but it's a very good jumping off point to allow us to reach a definition of 'enterprise'.</p><dl> <dt>"...software application..."</dt><dd>It may seem odd to pick this one out, but bear with me. Implicit in this is the concept that it's something you can point at and say "this was built to do X". In and of itself, that's perhaps not much, but what follows on from this is: <em>its functionality is well defined</em>, and from there, it's a very short leap to saying <em>it is designed using good software engineering principles</em>.</dd><dt>"... hosted on a server..."</dt><dd>Instantly this implies <em>it has a client/server architecture</em> of some sort. Maybe its true that most of such applications will have a web browser as their client, but let's not assume that: a mail server is just as clearly an enterprise application.</dd><dt>"...simultaneously provides services... "</dt><dd>I dunno about you, but to me that screams a requirement that <em>the software is thread and transaction safe</em> - no one user's changes should be able to overwrite another's.</dd><dt>"... to a large number of users..."</dt><dd>Following on from thread and transaction safety, that adds to our requirements the obvious one that <em>it must be scalable</em>.</dd><dt>"... over a computer network..."</dt><dd>Again, a little bit of a stretch, but that phrase should ring alarm bells in any sysadmin's head. <em>It should be secure against unauthorised use.</em> </dd></dl><p>How's that?</p> Penfold 2006-11-23T09:33:29+00:00 journal LAMP++? http://use.perl.org/~Penfold/journal/31691?from=rss <p>Writing the previous post raised a number of thoughts while traversing the London Underground, which will keep me going in blog entries for a while, I think.<br> <br>So... LAMP.<br> <br>Linux, Apache, MySQL, and Perl (or PHP, but I kind of promised myself this blog would be mostly PHP-free.<nobr> <wbr></nobr>:) ). As characterised by O'Reilly's excellent OnLAMP section, in fact, which is recommended reading, and a champion of the cause.<br> <br>Is this Enterprise Perl?<br> <br>Interesting question. I think the answer is, sort of: it's its skeleton. It's the bones on which you can build an enterprise-level application in Perl. (Which reminds me - we still need to define exactly what we mean by that troublesome term 'enterprise', don't we?) But it doesn't actually define anything. A single CGI that uses the HTML generation methods and talks raw DBI to MySQL is as much LAMP as a fully OO MVC-style web application written in TT2 and DBIx::Class.<br> <br>It clearly can work, though: Yahoo's internal CMS is written in Perl, so's IMDB, Amazon's publishing system, the entirety of CricInfo (trust me, I designed it - it's a TT2 fronted MVC web app, or at least it was when I left)... all these can be pointed at as examples of LAMP-done-well, and cover four of the biggest sites on the web (even CricInfo - a quarter of a billion page views a month on a single sport site). OK, so the 'L' occasionally stands for FreeBSD, but we'll draw a view over that - the spirit of the 'L' is 'Unix or Unix-alike on x86 commodity hardware', and we can let Yahoo off, just as we can excuse the folks who use Postgres. But there's really more to these than LAMP, or at least, we hope there is.<br> <br>What we're looking at, from an enterprise point of view, is something I'm going to call LAMP++. I'm sure, with a bit of work, we might be able to come up with a better acronym, but by analogy with C++, LAMP++ is actually not that far off the mark. The '++' means we're talking adding, or rather mandating, an OO approach to Perl (including an OO DBI abstraction layer), some form of templating, be it TT2, Mason or whatever, and some form of Apache-embedded Perl interpreter (mod_perl). We're looking for Perl programmers, not scripters, and we'd probably really like test-driven development, too. We're taking as our bible not the Llama and the Camel, but <a href="http://www.amazon.co.uk/gp/redirect.html?ie=UTF8&amp;location=http%3A%2F%2Fwww.amazon.co.uk%2FPerl-Best-Practices-Damian-Conway%2Fdp%2F0596001738%2Fsr%3D8-1%2Fqid%3D1164054246%3Fie%3DUTF8%26s%3Dbooks&amp;tag=theperlenterp-21&amp;linkCode=ur2&amp;camp=1634&amp;creative=6738">Perl Best Practices</a> and <a href="http://www.amazon.co.uk/gp/redirect.html?ie=UTF8&amp;location=http%3A%2F%2Fwww.amazon.co.uk%2FIntermediate-Perl-Randal-L-Schwartz%2Fdp%2F0596102062%2Fsr%3D11-1%2Fqid%3D1164054391&amp;tag=theperlenterp-21&amp;linkCode=ur2&amp;camp=1634&amp;creative=6738">Intermediate Perl</a>, and to guide our philosophy we keep handy <a href="http://www.amazon.co.uk/gp/redirect.html?ie=UTF8&amp;location=http%3A%2F%2Fwww.amazon.co.uk%2FPerl-Testing-Developers-Ian-Langworth%2Fdp%2F0596100922&amp;tag=theperlenterp-21&amp;linkCode=ur2&amp;camp=1634&amp;creative=6738">Perl Testing: A Developer's Notebook</a>, and <a href="http://www.perldesignpatterns.org/">Perl Design Patterns</a>.<br> <br>LAMP++. It's got legs, I reckon. More anon.</p> Penfold 2006-11-22T11:26:10+00:00 journal The downside of the Swiss Army Chainsaw http://use.perl.org/~Penfold/journal/31690?from=rss <p>One of the accusations often levelled at Perl is that it looks like line noise. My standard defence against this is to pull out a piece of my code, which tends to be written in a clear, OO-style borrowing heavily from Perl Best Practices, with, god forbid, comments, as a counter example, which does tend to shut people up, usually with some grudging remark about 'yeah, OK, but it doesn't all look like that'.</p><p>And sadly, that's true. It doesn't. Even some of my code doesn't - if I throw together a one or two liner to do some sysadmin task, odds are it'll make copious use of $_, m// and temporary hashes with single character names, and look like one of my cats jumped on the keyboard at an inopportune moment.</p><p>Why?</p><p>Because Perl lends itself to both styles. It is, in truth, the Swiss Army chainsaw of programming languages, capable of emulating sed, awk, grep and a host of Unix command line tools, as well as C++ and Java, a place where the Perl 3-ish language constructs and innumerable clever command line flags meet the Perl 5 OO syntactic sugar that'll evolve into Perl 6 (of which more in a later post).</p><p>Some of the problem, at least, lies in its accessibility. It doesn't take much to learn the basics, and I've seen some pretty ghastly things done in the name of Perl by folks who don't know any better. At one of my former jobs, my most common complaint about some of our new hires was that they were great Perl scripters, but very few of them knew the first thing about being Perl programmers. To quote an article I found while researching this blog, there are too many people out there still writing Perl 3, treating the language like awk-with-added-cool.</p><p>If you go a-hunting for Perl resources on the net, you'll find a disturbing number of things like guestbook and article management scripts written by well-meaning people, in a very Perl 3-ish style, some of whom may even, if you're lucky, have heard of CGI.pm, but almost certainly haven't come across CPAN. Now, admittedly, you could make the case that a lot of these are targetted at folks who have a hosting account with no support for extra Perl modules. It is, though, a sizeable part of the problem - the whole perception issue of Perl being a grubby little language for doing dirty little jobs dirt cheap in a dark alley.</p><p>I put it to you, in fact, that the very title of the Camel book, "Programming Perl", is a lie. It doesn't teach you to program. It teaches you to write better Perl scripts.</p> Penfold 2006-11-22T10:49:10+00:00 journal TMTOWTDI http://use.perl.org/~Penfold/journal/31689?from=rss <p>It's clear from watching $CurrentEmployer's recruitment, that if you're in search of Java Enterprise developers, it's not only easy to find a whole boatload from which to pick, but a trained monkey can go play buzzword bingo on their CVs to reduce it down to the half dozen key acronyms that get you what you want: Java, J2EE, EJB, Tomcat, JSP, JSTL. For a bonus, add on Eclipse, Hibernate, XML and its children, UML and the like, and you can pretty much come up with a short list of candidates who you know will have the skills you need to develop in a Java Enterprise environment. And more to the point, it'll be very similar to the environment they came from and are used to. And the list won't actually be that short.</p><p>Switch to Perl, and... well. For Java read Perl. Easy enough. For J2EE read... Um. Let's skip that one. For EJB... uh, moving right along. For Tomcat, we have mod_perl + Apache: that's fair enough. For JSP? Template Toolkit, or Mason, or Embperl, or... a whole list. For Eclipse...? How many people actually use an IDE with Perl? For Hibernate, we have Class::DBI, or DBIx::Class, or several other layers of varying depths of abstraction.</p><p>And there's one of the problems: that great virtue of Perl, that There's More Than One Way To Do It, comes and bites us - not everyone who holds their hand up and claims to have developed using Perl-in-the-Enterprise has anything like the same set of core knowledges. Going back to J2EE - there's that 400 page document that defines it, and the big driving force that's behind it, Sun, centralising the definition of what is and isn't part of J2EE.</p><p>We don't have that in Perl: take a look at the rich diversity of CPAN, the archive that almost defines 'TMTOWDTI'. It's great - given a task you can pretty much bet the project that you'll be able to find a module to do it. Except... to take an entirely random example simply because it cropped up today: I wanted to populate our user DB with GUIDs. It seems likely that there should be a module in CPAN to do it, right? So let's look.</p><p>Hallelujah! There is!</p><p>Without looking at all hard, in fact, there are three. One's dependant on another, and the third seems to be completely standalone.</p><p>And nowhere is there a standard, a definition, a set of guidelines, that says "use this one, 'cause it's the best" or even "use this one because we know what we're talking about and we say so."</p><p>To be fair, there are now a bunch of modules that ship with the core Perl distribution that are the approved way to do various basic Perl tasks, and without which Perl pretty much won't do anything useful. There are also modules that have reached the status of being the de facto standard for a task: CGI and LWP::UserAgent are two obvious candidates.</p><p>But there are also cases where there are many, many modules: consider the Date:: sprawl for one, the vast array of things with Template in the name, the various DBI abstraction layers, the countless bean-like Class::* modules... And there's no finger pointing at us to say 'this one'. Sure, we can define a corporate standard that says we're going to use Date::Simple, Class::DBI and TT2, and that's fine for us. But the next guy may decide to use Date::Manip, DBIx::Class and Mason, and architect his app a completely different way. There is no standard.</p><p>Of course, the obvious question is 'does this matter?' And I'm going to leave that for a later post.</p> Penfold 2006-11-22T08:54:56+00:00 journal What IS 'Enterprise'? http://use.perl.org/~Penfold/journal/31688?from=rss <p>After a particularly brain-numbing hour attempting to persuade a development build of our main web site's Perl back end (on Debian) to actually run on a co-located RedHat Enterprise License server, I wondered aloud, with a degree of frustration, "So what the heck does 'Enterprise' mean, anyway?"</p><p>Our sysadmin, who is prone, like all of his ilk, to disparage any and all instances of rampant abuse of buzzwords, offered that it meant, among other things, 'very very slow, uses XML unecessarily, and comes with a default configuration that's no use to man nor beast'.</p><p>Mischievously (for reasons perhaps to be explained in a later blog entry), I suggested that that could be summed up in the four letters 'J2EE'.</p><p>One of my Java-savvy colleagues (in fact, all my colleagues here are Java-savvy) opined that that wasn't exactly fair, and that 'J2EE' wasn't really anything more than shorthand for 'go read this 400 page document on The Right Way To Do Things'.</p><p>Interesting.</p><p>I'm in the minority here at $CurrentEmployer, since I<nobr> <wbr></nobr>/am/ the token Perl developer. But this, and a whole load of other things, have got me wondering. Why isn't there a 'Perl Enterprise Edition'? Maybe there is, and I'm missing it? What would it be, anyway? Perhaps the question is, where's that mysterious 400 page document that tells us what it is?</p> Penfold 2006-11-22T08:44:57+00:00 journal