You are here

Home › Archive

April 2009

Why I'm Moving Away From Perl

6 April 2009 - 2:28pm — Chris Ess

When doing system scripting, I historically tend to settle on Perl. This is a habit I am trying to break.

Perl is quick and dirty and gets the job done. And the scripts I've written in Perl certainly look like it. I looked at a Perl script I wrote about six years ago and... I have no idea what it's doing! I'm sure I could figure it out if I spent a few minutes going through it (including blank lines, it's only 125 lines long) but that's beyond the point. I am reminded of this joke comparing Perl and Python.

I have some Python scripts already in use. Perl's object model is painful to me and I have a hard time making use of it. So where I've decided to use objects because it makes more sense that way, I have used Python. And I find that the scripts using Python have a little more readability when read in the future. (To verify this, I looked at a script I wrote over seven years ago.)

The vast amount of existing scripts in Perl require me to continue to use it in the near term. However, as I touch the scripts less and less, the less I remember about them and, therefore, the higher the cost if I need to make changes to them for any reason. And since I would like to minimize the amount of time spent trying to reunderstand code, I think moving away from Perl makes the most sense.

What I haven't decided on is what language to use in the future. This will require further testing and gaining more experience with other languages in doing the sort of tasks I use Perl for. However, I will eventually have that experience so Perl's days are numbered.

Perl
Python

Whither Scala?

8 April 2009 - 9:40am — Chris Ess

It's April and that means that I should look at the new programming language for the year soon. Thus far, my leading candidates for the next one were all functional languages (in particular, Erlang, Haskell, or Scheme). Then, yesterday, through Slashdot, I read this interview with the Twitter team discussing replacing some of their Ruby backend stuff with Scala.

I'd heard of Scala before. Some time ago I ran across Ricky Clarkson's post explaining what (0/:l)(_+_) means. (For those of you who don't want to read the post, the Ruby equivalent is something like l.inject( 0 ) { |x,y| x + y }.) A little poking around lead me to David Pollak's post comparing Ruby on Rails to his Scala-based Lift framework. (However, it's been over a year since then and I think that Rails has made some improvements but I have no hard data or anything really beyond my respect for the Rails developers since I think they're pretty smart people.)

I have been going through the online tour of Scala periodically and some of the features look interesting. The major issues I have currently are the use of the JVM and the typing overhead of static typing but both are minor. It definitely has allure.

As I think about it more, I am not sure that Scala is the correct way to approach functional programming for the first time. In his comparison of Scala and Erlang, Yariv Sadan calls Scala "an OO/FP hybrid." This certainly seems to be true. And while being a hybrid is not necessarily a bad thing, it may not be conducive to properly learning functional programming. It's like learning to swim for the first time. If you're in the shallow area of the pool, learning to properly swim isn't that big a deal because, if something goes wrong, you can find the bottom of the pool and stand up. If you're in the deep end of the pool, you'd better know how to swim or find a way to get out of the deep end real fast.

The proper thing to do then might be to learn a proper functional language (Erlang, Haskell, and Scheme all have their fair share of proponents) and use those in their own right for a while. And then, next year, having some of that understanding and practice, come back and look at Scala and see how to merge OO with FP using Scala.

Scala

Haskell, It Is

10 April 2009 - 5:19pm — Chris Ess

I've decided that I will start functional programming with Haskell. I've delved deep enough into the Learn You a Haskell for Great Good! tutorial to really turn back. In comparison, the available "starting" Erlang documentation seems daunting.

It also helps that Real World Haskell, published by O'Reilly, has gotten rave reviews and won the 2008 Jolt Product Excellence Award. (Why this isn't on O'Reilly's product page for the book, I don't know.) Remember what I wrote about books?

This is not to say I've written off the other languages I was looking at. Erlang, Scheme, and Scala are definitely leaders for the next language. In fact, before starting with Haskell, I want to take a short detour and read The Little Schemer first. I've heard good things about the book and since I'm about to delve into functional programming, I want to read it. The worst thing that can happen is it turns out to be a waste of time and I'm sure it won't be.

(Edit: I just noticed that the title of this article was incorrect. This has been corrected. Sorry for the issues.)

Scala
Haskell

Changes Because of Piston 2.0

17 April 2009 - 9:52am — Chris Ess

As mentioned elsewhere, I maintain the local copy of this site through a combination of subversion and Piston. Sometime in the past couple months, version 2.0.1 (and now version 2.0.2) of Piston was released and, when I updated my local Ruby gems, ended up upgrading.

Piston 2 allows for the ability to use Piston with Git as well as subversion. This requires significant changes to the backend. So in order to use Piston 2 with existing Piston-managed copies, you must first upgrade those copies to use Piston 2's new format. This can be done with piston upgrade.

Piston 1 stores all of its backend information as properties within subversion. Piston 2 instead saves it to a special file, called .piston.yml, since properties are not available with Git. To use this with a public site, access to .piston.yml should be blocked. This can be done with this directive:

RedirectMatch 404 /\\.piston.yml$

After doing all of this, I encountered a bug with Piston. Every time I tried to update a Piston-managed directory, I got an error like:

/usr/lib/ruby/gems/1.8/gems/piston-2.0.2/lib/piston/svn/revision.rb:30:in `check
out_to': Did not get the revision I wanted to checkout.  Subversion checked out
280, I wanted 280 (Piston::Svn::Revision::InvalidRevision)

280 is equal to 280, isn't it?

I'm not sure why this behavior would manifest. I did not see anything on it. I suspect it may be an issue with the upgrade process. A simple, hacky solution was to change line 29 from:

          elsif revision != $1.to_i then

to:

          elsif revision.to_i != $1.to_i then

(I haven't filed a bug report on this but I will shortly.)

After doing this, Piston ran normally as expected and I could install the pending updates for the Drupal modules.

Version Control

Verizon Data Breach Investigations Report 2009

29 April 2009 - 5:55pm — Chris Ess

Via Dr. Anton Chukavin's post, I found the 2009 Verizon Business Data Breach Investigations Report. The document is a fascinating read to get an idea of the state of things last year. Chances are that this year will build on last year.

The targeting of financial institutions by organized crime entities is surprising to me and yet not surprising. Based on the behavior of would-be fraud perpetrators I have observed, there are a lot of credit card numbers out in the wild with little rhyme or reason to them. Compromising a financial institution or a merchant account provider, e.g. Heartland, would be an easy way to get credit card numbers into the open. However, the interest in account numbers and PINs is more disturbing and provides less recourse for the victim. This trend can be seen even in the US where ATM skimmers are becoming more prevalent.

The major thing I come away from the report with is: The big fish have a lot more to be worried about in the past. But that doesn't mean the small fish are safe in the water.

Security