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'?
[composed and posted with ecto]
Wednesday, 16 May 2007
A question...
...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'?
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'?
Performance Tests
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.
Setting aside, for the moment, brian d. foy's tongue-in-cheek demolition of benchmarking as a valid tool, what do we learn from these?
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.
Let's stop right there for our first remedial maths class, OK?
100 hits/second.
That's 6,000 hits a minute. 360,000 hits an hour.
Eight point six million hits a day. And change.
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 the biggest single-sport website on the net.
You're expecting that amount of traffic? Man, do you have delusions of grandeur! Paying for the bandwidth is going to be a much bigger worry than whether your web app framework can cope.
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.
Get over it, folks.
Setting aside, for the moment, brian d. foy's tongue-in-cheek demolition of benchmarking as a valid tool, what do we learn from these?
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.
Let's stop right there for our first remedial maths class, OK?
100 hits/second.
That's 6,000 hits a minute. 360,000 hits an hour.
Eight point six million hits a day. And change.
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 the biggest single-sport website on the net.
You're expecting that amount of traffic? Man, do you have delusions of grandeur! Paying for the bandwidth is going to be a much bigger worry than whether your web app framework can cope.
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.
Get over it, folks.
[composed and posted with ecto]
Technorati Tags: enterprise, performance, perl
sleep(24*60*60*rand(200)); post();
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:
[2] More later. Oh my God, yes.
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.
[2] More later. Oh my God, yes.
[composed and posted with ecto]
Technorati Tags: enterprise, jobs, perl
Subscribe to:
Posts (Atom)