Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Penfold (7457)

Penfold
  (email not shown publicly)
http://perlent.blogspot.com/
AOL IM: fleetfootmike (Add Buddy, Send Message)
Yahoo! ID: tuxservers (Add User, Send Message)

Perl developer for Yahoo! UK, previously for MindCandy Design and CricInfo.com - guitarist, photographer, writer.
+ -

  21st Century Perl (part 1) on 2007.12.20 2:34 Penfold

Submitted by Penfold on 2007.12.20 2:34
User Journal
Penfold writes "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.

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...

...with Unit Tests.

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."

I groaned. " What am I? QA?"

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:

We all write unit tests anyway.

We just don't necessarily call them unit tests or treat them like it.

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 more little command-line Perl one and two liners to make sure it still works.

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.

Behold, Test::More and all its red-headed stepchildren.

Your repeated invocations of perl -cw My::New::Module?

use Test::More plan_tests => 1;
use_ok(qw/My::New::Module/);

Glory Hallelujah, a unit test. And blow me, if it isn't even less typing: prove -v t/*.t, or even make test. Praise the Lord, I have seen the light! The first step on the road to salvation.

Look at that code for that method you just put in the sub {} declaration for. Ask yourself, how would I check if this works? 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" before you even finish coding the module. Save them under useful names in t/. Run them, every time you change your code.

Testify, brother.

"
Read More 0 comments

+ -

  Journal: 21st Century Perl (part 1) on 2007.12.20 2:34

Journal by Penfold on 2007.12.20 2:34
User Journal
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.

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...

...with Unit Tests.

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."

I groaned. " What am I? QA?"

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:

We all write unit tests anyway.

We just don't necessarily call them unit tests or treat them like it.

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 more little command-line Perl one and two liners to make sure it still works.

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.

Behold, Test::More and all its red-headed stepchildren.

Your repeated invocations of perl -cw My::New::Module?

use Test::More plan_tests => 1;
use_ok(qw/My::New::Module/);

Glory Hallelujah, a unit test. And blow me, if it isn't even less typing: prove -v t/*.t, or even make test. Praise the Lord, I have seen the light! The first step on the road to salvation.

Look at that code for that method you just put in the sub {} declaration for. Ask yourself, how would I check if this works? 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" before you even finish coding the module. Save them under useful names in t/. Run them, every time you change your code.

Testify, brother.

Read More 2 comments
Comments: 2
+ -

  sleep(24*60*60*rand(200)); post(); # once moreAmid on 2007.12.20 2:28 Penfold

Submitted by Penfold on 2007.12.20 2:28
User Journal
Penfold writes "Amid groans, no doubt, I’m back.

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.

For the first time in a while, my job here at Big Purple Towers in London hasn’t been about maintaining a 10-year old monolith of a Perl app (really, you don’t wanna know… it’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.

Time to put my money where my mouth is."
Read More 0 comments

+ -

  Journal: sleep(24*60*60*rand(200)); post(); # once more on 2007.12.20 2:28

Journal by Penfold on 2007.12.20 2:28
User Journal

Amid groans, no doubt, I’m back.

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.

For the first time in a while, my job here at Big Purple Towers in London hasn’t been about maintaining a 10-year old monolith of a Perl app (really, you don’t wanna know… it’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.

Time to put my money where my mouth is.

Read More 0 comments

+ -

  A question... on 2007.05.16 3:13 Penfold

Submitted by Penfold on 2007.05.16 3:13
User Journal
Penfold writes "...for my scant collection of readers.

What makes a good or bad Perl job advert? What key words or phrases get you going, above and beyond the response 'yes I know how to do that'?

"
Read More 0 comments

+ -

  Journal: A question... on 2007.05.16 3:13

Journal by Penfold on 2007.05.16 3:13
User Journal
...for my scant collection of readers.

What makes a good or bad Perl job advert? What key words or phrases get you going, above and beyond the response 'yes I know how to do that'?

Read More 9 comments
Comments: 9
+ -

  sleep(24*60*60*rand(200)); post(); on 2007.05.16 2:38 Penfold

Submitted by Penfold on 2007.05.16 2:38
User Journal
Penfold writes "OK - back now :) 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.

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 the Perl job market 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 perception 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.

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 lingua franca 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.

Marketing? Sure. Where's the glossy, media-friendly, Web 2.0-looking (you know what I mean - big, bold sans serif fonts and gradient-filled boxes in darkened primary colours) site that sells Perl as a solution? Ruby on Rails 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.

Perl has MVC frameworks[2] - it has, if anything, too many of them. 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.

What do we need to do, then?

Actually, I think it's twofold:

  • the BBC's free Perl training 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 Moose as The One Way to do OO in Perl, let's do it. With tutorials, examples, the works.
  • 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.
[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. :) [2] More later. Oh my God, yes."
Read More 0 comments

+ -

  Journal: sleep(24*60*60*rand(200)); post(); on 2007.05.16 2:38

Journal by Penfold on 2007.05.16 2:38
User Journal
OK - back now :) 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.

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 the Perl job market 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 perception 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.

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 lingua franca 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.

Marketing? Sure. Where's the glossy, media-friendly, Web 2.0-looking (you know what I mean - big, bold sans serif fonts and gradient-filled boxes in darkened primary colours) site that sells Perl as a solution? Ruby on Rails 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.

Perl has MVC frameworks[2] - it has, if anything, too many of them. 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.

What do we need to do, then?

Actually, I think it's twofold:

  • the BBC's free Perl training 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 Moose as The One Way to do OO in Perl, let's do it. With tutorials, examples, the works.
  • 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.
[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. :) [2] More later. Oh my God, yes.
Read More 2 comments
Comments: 2