Oh no, hourly smoke test failures in my inbox today! Looks like I put some bad HTML on work’s website’s home page, and every hour one of the automated tests, via Test::HTML::Lint, told me once an hour that
# HTML::Lint errors for http://devserver.example.com/
# (72:53) <a> at (61:53) is never closed
Well, phooey, it’s a PHP-driven website, so I can’t open index.php and check lines 72 and 61. I can use GET, installed with LWP, to fetch the website and save the source:
$ GET http://devserver.example.com/ > foo.html
$ vim foo.html +61
but since I’m a Perl programmer, I want to be as lazy as possible by using the tools at my disposal. In this case, it’s ack, and ack has the --line option to display ranges of lines instead of results of a regex. (Thanks to Torsten Blix for implementing this!)
$ GET http://devserver.example.com/ | ack --lines=61-72
So much nicer that way!
and look at it in an editor, but how much easier to not have to do that.
There is no project so small, so trivial, that it is not worth you putting it into a Subversion repository. If it’s worth your time to work on it, it’s worth saving. Putting it in Subversion is a matter of a few statements, and you don’t have to do any big fancy-shmancy server setup.
Let’s assume you’re working on Linux/Unix, and you have svn installed, which is pretty standard these days. Say you’re working on a game called bongo, and you’ve just been keeping it in ~/bongo. Do this:
# Create the Subversion repo
$ mkdir /svn
# Create the bongo repo
$ svnadmin create /svn/bongo
# Import bongo into its project
$ cd ~/bongo
$ svn import file:///svn/bongo -m'First import of bongo into Subversion'
# Move the original bongo directory out of the way,
# in case something goes wrong
$ mv ~/bongo ~/bongo-original
# Check out bongo from Subversion
svn co file:///svn/bongo
At this point, you’ll have a checked-out version of bongo in ~/bongo, and you can make commits against it.
Ricardo Signes points out that Git makes it even easier.
# Go to the bongo directory
$ cd ~/bongo
# Import bongo
$ git init
With Git, everything is put in your ~/.git directory, and you don’t have to check out anything from the project.
Whatever route you choose, version control is so simple these days there’s just no excuse not to do it. Your programming life will never be the same.
When you’re releasing a module, please show a sample use or the output somewhere in the documentation so that people like me who are interested in your module can have some idea of what it looks like and how I’d use it.
I take for example this new distro, pfacter, which purports to “Collect and display facts about the system.” Sounds great, but how do I use it? I see a little program. Can I see some sample output? Please? There’s nothing in the README or any kind of synopsis that shows it.
Of course, I don’t mean to pick on this one distro. It’s just the one that disappointed me just now and made me post this. It’s something that has always frustrated me, especially as I try to find cool new modules to mention here or over in Mechanix.
(No need to point out that I haven’t do this for ack myself. It’s on my todo. 🙂 )
Ha ha, trick question, there is no “best” templating system except for the one that’s best for your project.
Vince Veselosky has a roundup of Perl templating systems where he examines everything….
… from the Swiss Army Chainsaw of Template Toolkit, through HTML::Mason and Text::Template down to the ever-tempting “variables interpolated in a here-doc” method….
Read on for a comparison of the major template systems in Perl, and my recommendations of which systems fit which circumstances.
It’s a fine introduction to the various systems, and probably worth pointing to from the Perl 5 wiki, if not reproducing it there entirely.
Adam Kennedy has written a very thoughtful article on problems he sees coming up in Perl 6 called
“The relationship between a language and its toolchain, and why Perl 6 scares the hell out of me.” It’s well worth reading even if you’re not following Perl 6 that much.
I’m amazed at how David Landgren manages to summarize the p5p traffic, especially this week. Last week’s summary is 19K of text covering everything from what happens when you bit shift infinity, to what features people want in Perl 5.12, to outdated Test::Harness components.
a post in the Beautiful Code blog, Simon Wistow created Acme::Numbers, which lets you do cleverness like this:
print two.hundred."n"; # prints 200
print forty.two."n"; # prints 42
print zero.point.zero.five."n"; # prints 0.05
print four.pounds.fifty.five."n"; # prints "4.55"
print four.pounds.fifty.pence."n"; # prints "4.50"
print four.dollars.fifty.cents."n"; # prints "4.55"
You probably wouldn’t want to do this in production code, but like the best of Damian Conway’s not-useful-but-thought-provoking modules, it may spark some ideas that you can apply to more useful situations. If nothing else, the source is a fine lesson in overloading and method importing.
Adam Kennedy is thinking about the future of Strawberry Perl.
In line with my attitude that the main Strawberry “product” should be conservative, reliable and predictable (I’m going with a rough analogy to Firefox product-wise) I’ve been thinking a little about how the release tempo should look.
My current thinking for Strawberry Perl is to do quarterly releases, with a tentative schedule of releases in January/April/July/October and aiming at being available for download before the second Monday of the month.
In addition, he’s asking for your ideas on features to include in the April 2008 release.
The other day I posted a link to an article by Ted Neward called “Can Dynamic Languages Scale?” I thought it was interesting to see that an outsider saw the potential in Parrot, even though it’s not at 1.0 yet. As an afterthought, I lamented that he made a dig at Perl at the end, smiley face or not. I meant it to have the same sort of gravity as saying “Aw, shoot, it’s raining out.” I didn’t care that he didn’t like Perl, but that he had to take a swipe. It certainly wasn’t a big deal.
Apparently his article caused a minor uproar. Neward posted a followup called “So I Don’t Like Perl. Sue Me” in response to the Perl folks arguing with his taste in languages. He shouldn’t have had to do that.
I don’t get Radiohead. It’s all ponderous and aimless. I also don’t get Phish, Peter Gabriel and/or Genesis, Yo La Tengo or Tori Amos. But so what? It’s personal taste. I don’t like Java, either, although I haven’t written any in the past 10 years. You know why I don’t like Java? It just doesn’t look like it’s any fun. I’m sure people can explain to me why Java is great, but it won’t change my mind. And it doesn’t need to.
If you really want someone to love Perl, you’ll have to show him, not tell him. Show him great code, great projects. Show the doubters that Perl can do amazing things. Action, not words. And if he still doesn’t get it, that’s OK.
Ted Neward has written an article on the problems of scaling up projects based on dynamic languages:
While a dynamic language will usually take some kind of performance and memory hit when running on top of VMs that were designed for statically-typed languages, work on the DLR and the MLVM, as well as enhancements to the underlying platform that will be more beneficial to these dynamic language scenarios, will reduce that. Parrot may change that in time, but right now it sits at a 0.5 release and doesn’t seem to be making huge inroads into reaching a 1.0 release that will be attractive to anyone outside of the “bleeding-edge” crowd.
Alas, he has to end with “Perl just sucks, period.” Even as we work forward with Parrot and Perl 6, the continued public perception of Perl doesn’t change. 🙁