Results tagged “perl” from Appleseed Blog

My last post contained Perl source code that adhered to the rules of iambic pentameter. An inverse bit of hackery may be seen in these Perlish poetry generators by Nick Montfort. Both programs are 256 bytes in size.

Sample output from the second one:

the sits

chit
of skin spits a kit
skit twins ban
a twin & bill
kin skins kill
fill
a spill chits a pit
shill
sill twills twill
skit

It's been a while since I have some across any new attempts at Perl poetry, so I was delighted to discover this stanza of iambic pentameter code by my friend jadelennox, written as part of Blank Verse Blog Week. The longer version by damned_colonial in the post's comments is great, too.

My friend and colleague Andy Turner just posted some interesting graphs that measure changes in the CPAN's activity rates over the last decade or so. (CPAN being Perl's distributed, internet-based archive of code libraries and other stuff, and approximately 51 percent of what makes Perl my favorite programming language.)

I'm interested to see that the number of new users started to drop off a few years ago, but the activity of existing users has been increasing so much that the archive's overall activity continues to trend upwards.

If I had to guess a single reason for this, it'd involve the community getting better over the last several years at corralling many hackers together into large, frequently updated projects, which then get stored in the CPAN under a single username (as that's a limitation of the system). I think, for example, of DBIx::Class's recent ascendency, and clear community dominance, over the thousand SQL-abstraction modules that came before it. So you have fewer instances of people creating new CPAN author accounts just to upload their own wheel-reinventions.

I recently had a phone conversation with a recruiter who, after we established that I wasn't interested in a permanent position anywhere, confessed to me that she was having a great deal of frustration trying to find people with my skillset and level of experience who were looking for a new career.

To her - and to y'all - I say: Visit jobs.perl.org, and consider posting a want-ad there. In the few years the site's been up, it's quickly become the center of job-posting in the world of Perl expertise. Almost every client I've worked with independently or via Appleseed I met after they posted a job description on that site.

Having apparently mislaid my print copy, I was surprised and delighted to just now find that Google Books has the full text of many pages from Damian Conway's Perl Best Practices online. Edit: Gah, I just realized that it's not the full text; many pages are arbitrarily withheld, and marked as such. My praise for the book still stands, however.

Those who have worked with me over the last couple of years have been subjected to my occasionally holding up this book as improving the way I wrote software faster and more profoundly than any other single influence. It not only made me a better Perl hacker, but changed the way I approach any software project, regardless of the programming languages it may happen to use. I cannot recommend this book strongly enough to my fellow professional Perl people, and suggest that even those who primarily work in other languages have a look.

Now, if you'll excuse me, I have some well-documented and robustly tested exception objects to throw...

And now a bit of Developer's Notebook-ery.

I have lately been learning the ropes of XNA Studio, Microsoft's free-beer framework for game development. It's especially helpful for those interested in creating software for the XBox 360 game console.

After spending some time doodling the basic class structures needed for the particular project I have in mind, it was time for me to write some tests. Since reading Damian Conway's excellent Perl Best Practices, I've been a devotee of test-driven development: a software-creation work cycle where the programmers write tests for their code even before they write they code being tested.

So you start with a bunch of tests that all fail, and you know your job is done when, however many work-hours later, they all pass. And then you keep those tests handy, so that they'll bark at you if any new code-change you introduce causes older code to break. This is all very good stuff, and I can't imagine working any other way, now.

But while I know all about writing tests in Perl on Unix, I knew next to nothing doing it with C# on Windows. A friend pointed me at NUnit, a Windows-programming port of a popular unit-testing framework from the Java world. Well, great, sez I; sounds perfect. But getting it to actually work for me was a chore. Here is what eventually worked for me.

1. Installed Testdriven.Net, which includes two full versions of NUnit (among a bunch of other testing frameworks).
2. In my copy of Visual C# 2005 Express Edition (a free-beer IDE that Microsoft recommends for XNA development), created a minimal test-using project based on this code snippet from the XNA forums.
3. Manually added a reference to nunit.framework.dll to the project, as per that same post. Used NUnit's v2.2 framework, not v2.4.
4. Launched the v2.2 NUnit's GUI testing application, and had it open the .dll file that the project's build process had created.

I found that trying this with the v2.4 NUnit stuff resulted in a dialog box full of verbiage that I'm currently too Windows-ignorant to grok, but there clearly seemed to be some kind of version mismatch afoot. I got the same message when I tried installing the latest version of NUnit directly. And I haven't been able to get Testdriven.Net itself working - it's supposed to integrate with Visual Studio itself. I am led to understand, though, that the fact I'm using Express versus a commercial edition may be an obstacle here.

I'm curious if things would have been easier if I were using Visual C# 2008 Express, instead of the 2005 version. But, it all works well enough for the nonce.