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