Okay, fine—sort of. I have a beef with this.

Good security practice is about implementing layers of security, and this flies in the face of that. If certain other vulnerabilities are present, the most obvious one being HTTP response splitting, then CSRF is once again possible. Any vulnerability that could allow custom headers to be inserted in a CSRF request now makes them possible because the authenticity token is bypassed by a custom header.

In my opinion, if a site has data worth protecting with an anti-CSRF authenticity token, there’s no reason not to use it for all requests that can alter that data. Doing the bare minimum is what I call Just-Barely-Enough Security.

Note that Rails 3.0 handles CSRF protection differently (within Rack), and I have not examined it; the above comments apply only to Rails 2.x.

So it turns out that Rails is not the only web framework out there where the CSRF protection was in the just-barely-enough category. I have also been working on a Django 1.1 project recently, and in doing so I have found another category of just-barely-enough security (fixed in Django 1.2). Django 1.1 generates the authenticity token in a somewhat weak manner, but it is not weak enough that it is exploitable by itself. The weakness is that the authenticity token is the MD5 hash of a site-wide secret concatenated by the session ID (in contrast, Rails 2.3 and Django 1.2 generate a completely random token for each session). Because of how MD5 hashes are computed, an attacker could potentially learn the state of the MD5 computation up to the point of hashing the site-wide secret and himself compute any authenticity token given a session ID without further consulting the Django server. However, this is not an issue by default because Django’s session fixation protection prevents it from responding with session IDs that it did not generate, so the attacker cannot build up the necessary information to perform the attack. But if something were to be configured wrong on the Django server and a session fixation attack were to be possible, then the attacker would have more avenues for exploitation than just using session fixation on the victim directly.

Even worse would be a situation where the session fixation issue was found and repaired, but not before an attacker gleaned the necessary information to generate authenticity tokens for the site. The site administrator would think he closed the security hole, but his site may still be exploitable based on previously leaked information. That would be rather unfortunate.

Honestly, at first I found it a little frustrating. There I was spending half my time watching someone else implement some stuff, and my brain simultaneously stuck elsewhere solving world hunger while trying to be “helpful” to that other guy with me. It took a few weeks before the benefits really started dawning on me and also to appreciate the contribution I make when not the guy with the keyboard. I think many people have recounted much of what is great about pair programming, but the one that I have not heard that really makes me giddy is that your partner prevents you from being lazy.

In particular, I do not mean that your partner prevents you from using things like email as a distraction from getting stuff done (another benefit that others have recounted). Instead I mean that when you are racing to complete a programming task and you encounter a decision to: (1) hack it and jam something in place quickly, or (2) Doing It Right but burn up extra time doing so. Without a partner you typically choose #1 while lamenting that you did not choose #2. You add to your technical debt and bad karma and you are ridden with guilt; it is a double whammy!

With a partner, what happens instead is that you suggest #1 to your partner, but regardless of whether your partner can discern whether #1 is Doing It Right he can see your hesitation and draws your thoughts out of you about #2. Before you know it, he is excited to see you through to Doing It Right! Your heart leaps in joy and later, when you go home for the day, you smile just a little more when your sweetheart asks, “how was work today, honey?”

Here are the highlights of the pros:

• It is written in Rails, which is a platform I know well and therefore can extend rather easily.
• The site can be split into multiple sections, each of which can be its own blog and have its own RSS feed, or which can be a single page.
• Themes! Mephisto can be themed, and it is easy to write new ones using one or more of several template languages.
• It allows multiple layouts to allow for different looks for each section of the site.
• Articles can be formatted in with Textile, Markdown, or just plain HTML. I was able to integrate TinyMCE without much trouble as well.

But there are also the cons:

• The current version is 0.8. That is not quite 1.0, and I wager that the reason it is not at 1.0 is related to the various little bugs that I have found.
• Sometimes Mephisto will select the wrong layout for a page and it is difficult to figure out why. Fortunately, these situations are limited to “Preview this Post” and the “permanent links” to articles that represent pages that normally do not get linked to.
• Mephisto has plugins and themes, but it is difficult to find useful plugins and more than a small number of publicly available themes.

I think Mephisto is a better platform than Radiant at this point, and in my opinion it gives Rails a reasonably usable blogging platform. Before committing more time to it, however, I think I will take a look at the much touted Drupal. I have been meaning to take a look at it anyway.

But Cosine, you might say, Paul developed Arc so that the language would have nifty breakthrough features unlike any ever seen before to make code more concise! Without the base language support for these features, Ruby will not beat Arc at its own game!

Well, someone has already written a library (it should be reformatted properly into one, anyway) in response to the Arc Challenge that implements part of the Arc standard library, exposing for Ruby any language features in Arc that Paul was trying to showcase in the Arc Challenge.

Paul, please give us a challenge that shows a fundamental language design difference rather than displaying a gap in the presently available libraries. I know you are a smart cookie, so you must be hiding something up that sleeve.

Actually, I can think of one advantage Arc has over Ruby. Arc is Lisp whereas Ruby is not, and following from that Arc has macros while Ruby has ugly workarounds to fake macro writing. But everyone already knows that. Hmmm, maybe what we really want to do is have all our Ruby gems and Rails made available for Arc? Arc on Rails, anyone? I think that would be pleasant.

<statement><personal><timeframe><someday><subject>I</subject><action how="at">look</action><object><name>ruby</name><modifier type="on">rails</modifier></object></someday></timeframe></personal></statement>

Why wait? Get out there and get started with Rails today!

irb(main):001:0> a = [1, 2, 3, 4, 5]
=> [1, 2, 3, 4, 5]
irb(main):002:0> a[1..-1]
=> [2, 3, 4, 5]
irb(main):003:0> a[1..a.size]
=> [2, 3, 4, 5]
irb(main):004:0> a[1...-1]
=> [2, 3, 4]

Now we just saw first hand some of how we manipulate Arrays in Ruby. But what if we are curious about what else we can do with an Array? It would be really nice if we could quickly get a list of methods available for my Array. Oh, but we can! Every Ruby object has a methods method that returns an Array populated with the names all the messages it responds to.

irb(main):005:0> a.methods
=> ["select", "[]=", "inspect", "compact", "<<", "&", "clone",
"method", ... (over 100 other methods) ..., "unshift",
"sort_by", "to_yaml_properties", "fill", "max", "is_a?",
"uniq!", "[]"]

Oh, that is a lot of methods! My version of Ruby/irb returned 128 methods for the object, and they are hard to read all mixed up like that. Good thing we can sort them, too:

irb(main):006:0> a.methods.sort
=> ["&", "*", "+", "-", "<<", "<=>", "==", "===", ... (over 100
other methods) ..., "uniq", "uniq!", "unshift", "untaint",
"values_at", "yaml_initialize", "zip", "|"]

By scanning the methods available to an object you can get an idea of what you can do with it before you even look at proper documentation (which you want to have handy, too). Using the methods method from irb is also a fast way to recall the name of a method if you forget it and your text editor or IDE does not help you figure it out. I sometimes just try out methods unknown to me just to see what happens, and then I check the documentation shortly thereafter to ensure I understand it.

The most important aspect of irb that enabled me to learn Ruby and keep up with changes in the language was the ability to vet out short bits of code before putting them into a program. For example, if I need to ensure a complicated regular expression will match what I want it to, I can do the initial testing in irb. Then those tests done in irb that supply confidence that the regular expression is correct are copied into the unit tests. Here is a simple example to illustrate the idea:

irb(main):007:0> 'foo bar baz' =~ /\<bar\>/
=> nil

Oops! I expected an Integer result, which would denote there was a match. However, I forgot I was working in Ruby instead of an old version of grep, and the notations denoting a word boundary in regular expressions are different between the two. It is easily fixed:

irb(main):008:0> 'foo bar baz' =~ /\bbar\b/
=> 4

One other trick I employ in irb is to get a list of currently loaded classes, at least as defined at the top level (i.e. a class within a class or module, like Net::HTTP, will not show up, but Net will and then one could drill down from there). This can be done because every class can be identified by a constant value, and a list of these constants can be obtained from the Object class using the constants class method:

irb(main):009:0> Object.constants.sort
=> ["ARGF", "ARGV", "ArgumentError", "Array", "BasicSocket",
"Bignum", "Binding", "Buffering", ... (over 100 other entries)
..., "UNIXserver", "UNIXsocket", "URI", "UnboundMethod",
"VERSION", "YAML", "ZeroDivisionError", "Zlib"]

Not all of the entries returned are classes (e.g. ARGF and ARGV), but it does not hurt to know about the other defined constants, too.

With irb at my disposal learning Ruby was a snap, and it was very fun. If you have not yet had the pleasure of learning Ruby then perhaps irb can make your journey more fun, too. Let me know if you try it out!

irb(main):001:0> 1465 + 1723
=> 3188

Simple addition is not too exciting, but that’s just the beginning. When Ruby is at your fingertips, the sky is the limit (limited by your imagination, of course). You can sum up a whole list of numbers quickly:

irb(main):002:0> [1, 2, 3, 4, 5, 6].inject(0) { |x, y| x + y }
=> 21

Use variables to store values or add to them:

irb(main):003:0> a = 515
=> 515
irb(main):004:0> a += 23
=> 538

Or perhaps you need a special function to crunch your numbers today? Just define it, possibly as an instance method for the Array or Integer classes, and then have a blast with it:

irb(main):005:0> class Array
irb(main):006:1>   def sum_of_squares
irb(main):007:2>     inject(0) { |s, x| s + x * x }
irb(main):008:2>   end
irb(main):009:1> end
=> nil
irb(main):010:0> [1, 2, 3, 4, 5, 6].sum_of_squares
=> 91

Take advantage of some mathematical constants! They are available, too, using the Ruby constants shown below.

irb(main):011:0> Math::PI
=> 3.14159265358979
irb(main):012:0> Math::E
=> 2.71828182845905

Finally, there is just one thing to note. If you are doing division and want a decimal point in your results then you need to make sure you are using at least one floating point precision number in your statement (otherwise the result is an integer dividend):

irb(main):013:0> 2352.0 / 17
=> 138.352941176471
irb(main):014:0> 2352 / 17
=> 138

Using irb as a desktop calculator is really just scratching the surface of what one can do, but I think it is a rather cool application of it. If you have never used irb, or even Ruby, go ahead and give it a try! I hope you find it just as useful as I do.

let D=1; while (( D <= 31 )); do
  DD=$(printf "%02d" $D)
  for M in server-01 server-02 server-03 ; do
    gzip -cd $M/weblog.200708$DD.gz | \\
        perl -anle 'print "'$M' $F[0] $F[3]"
            if $F[0] =~ /^10\.1\.2\.[34]$/'
  done
  let D=D+1
done > ~/log_report

There are a few things I want to point out about this mini-script:

1. Iteration is performed on an index value ($D), tested using Kornshell’s double parentheses syntax, and incremented using a let statement.
2. It makes use of a Perl one-liner to rearrange the data on each line and only print that data that is relevant to the task at hand.
3. I send the output of the entire thing to a file by redirecting it after the final “done” statement.

None of these things is really a big deal to me anymore, but I have noticed many people do not think or know you can do these things. I think that if you do realize it then you can come up with some more powerful mini-scripts from your command line.

I noted before that I use the Z shell, a Bourne compatible shell. While the above mini-script will not work in the Bourne shell itself, it should also work in the Kornshell and the Bourne Again shell, though your mileage may vary.

Incrementing an Index

The generic script code for iterating over an increasing numeric index is:

let I=0; while (( I < 10 )); do
  ... your code here ...
  let I=I+1
done

If your shell is a traditional Bourne shell that does not support let-statements and double parentheses notation, then you may do this:

I=0; while [ $I -lt 10 ]; do
  ... your code here ...
  I=`echo $I + 1 | bc`
done

If you have a small set of numbers to iterate over then it is often still faster to just type them all out in a for-statement, but that stops being true when you have a large set of numbers.

Invoking Perl and/or Ruby

This technique should not be alien to someone that writes shell scripts. Even if you never thought to invoke Perl and/or Ruby in your scripts, you have probably used sed and awk. In the above example I could have used awk instead of Perl, but Perl seemed like a better choice at the time. Ruby and Perl have flags that help them be more useful on the command line, and in fact they can both become more powerful replacements for sed and awk. Some flags are:

-n: I call this the awk-mode flag. It causes both Ruby and Perl to loop on each line of the input, putting that line of input into $_.

-p: I call this the sed-mode flag. It causes both Ruby and Perl to loop on each line of input like -n, but also prints the value of $_ at the end of the loop (presumibly you have modified it).

-a: This is often used with -n, though it could also be used with -p. As each line of input is read, it is split and the resulting array stored in @F (Perl) or $F (Ruby). I used this feature in the above mini-script to limit which fields are output to the report I generated.

-l: This flag causes lines output to be terminated with a newline. It also causes lines of data input via -n and -p to be auto-chomped.

-e: The most important flag for one-liners! This causes Perl and Ruby to take their commands from the argument given after -e. It may be specified multiple times to issue more code from the command line.

-i: If you want to edit a file in-place you can use this flag to tell Perl or Ruby to edit each file of input instead of leaving those files untouched. You can also opt to provide an extension to be used for a backup of the input. Note that because of the syntax for the optional extension use, you should check the man page for usage.

Redirecting Output

You can redirect output from any part of a script. Most people focus on redirection of individual commands, but that causes one to have to keep appending data to an output file. One does not need to do that! Just redirect your output after the “done” and you will capture all of the output from all of the commands inside the loop. Spiffy, eh?

class Shape
  module CurvySides
    # ... code supporting curvy sides here ...
  end

  module StraightSides
    # ... code supporting straight sides here ...
  end

  include CurvySides, StraightSides
end

Actually, each concern was in a separate file:

require 'shape/curvy_sides'
require 'shape/straight_sides'

class Shape
  include CurvySides, StraightSides
end

How is that for separation? But wait, you say… what if including each concern requires a change in behavior to the same method? You cannot just define the whole method in both modules; if you ran one the other would not get to assert its behavior.

The solution lies in Ruby’s method aliasing mechanism. Each module defines its own version of the method assuming that there is another, previously defined, version of the method to be called.

class Shape
  def side_length
    0
  end

  module CurvySides
    def self.included (base)
      base.send :alias_method, :side_length_without_curvy_sides, :side_length
      base.send :alias_method, :side_length, :side_length_with_curvy_sides
    end

    def side_length_with_curvy_sides
      side_length_without_curvy_sides + (... other computation ...)
    end
  end

  module StraightSides
    def self.included (base)
      base.send :alias_method, :side_length_without_straight_sides, :side_length
      base.send :alias_method, :side_length, :side_length_with_straight_sides
    end

    def side_length_with_straight_sides
      side_length_without_straight_sides + (... other computation ...)
    end
  end

  include CurvySides, StraightSides
end

So it is not the prettiest code, but it effects the separation of programming concerns a la aspect-oriented programming. For version one of anything I write I will not be using this much, but I think that before someone publishes their work they should consider modularizing it in this way. In fact, this architecture has been a great help to me as I extend the functionality of the class myself. I am simply writing my modifications as modules that are included into the class just like its base functionality. Sometimes they augment existing methods, and I have to make the calls to #alias_method for the class, and sometimes I do not. In any case, it is fun!

I also looked at Eclipse, but it has not grown on me nearly as fast. In fact, at the risk of sounding like an Eclipse basher, I must say the interface is non-intuitive and the help files address every subject under the sun and the moon except how to make Eclipse useful. I am sure that under all that non-intuitiveness and bad documentation is an excellent product, but I will not invest that much time to find it (yet) with TextMate already paying me back handsomely for only ten minutes of my time to install it and configure my preferences. One might say this is the difference between a text editor and a full IDE—that may be true to some degree—but I think it is also the difference between a good user interface and just an interface.

I gave NetBeans a test drive as well. Let us just say that Eclipse, at least, did not get moved to my Trash and has no plans of visiting, either. I may not have learned to like Eclipse, but I also still see value in learning more about it. In a way I hope I am wrong about NetBeans, but it gets to wait a while before getting another shot.

So why did I do all this? To write code faster! I love Vim and the vi interface, but I like trying new things. I might switch back after a few months if I can find out how to obtain what I like about TextMate in Vim. Being rather extendable, Vim is capable of much more than I have demanded of it. However, the main point is that it is important to me to try out new things periodically, or else I will never learn of the coolest new things (like I did when I learned Ruby in 2001). I also periodically revisit things, such as Emacs about 18 months ago. I did not switch, but getting reacquainted with it eight years after my last time seriously using it was fun.

I like to encourage everyone to pick up new things every once in a while. Do not settle in a groove and stay there for the rest of your life. Mix things up a little! If you do not like your new adventure after a few days or weeks, you can always switch back! It is fun, and may be profitable, too. Of course, if you are the kind of person reading this, you probably already do this. Carry on!

Aristotle does not like using eval (source):

I mean, evaluating another source file every time you instantiate an object in that class? Awesome! If I had to maintain his code I’d refactor that part out of existence with a quickness!

Ovid agrees but is a bit more thoughtful and explains DSLs better than I did, except we differ in opinion regarding use of eval. Ovid’s most important point is that DSLs can also be implemented by coding your own lexer and parser instead of using eval. I did fail to mention that, but I think it lends yet more credence to my previous assertion: that Ruby has better support for DSLs than Perl. Otherwise, the Perl crowd would not be so much against using eval (on strings) instead of writing the parser.

What a pity! There are certainly instances where eval is used in a sloppy and careless manner, but proper use to facilitate DSLs transcend that. My use of eval in DSLs may not always be the best, but I am convinced eval is a useful tool that should not be so summarily dismissed because of its dirty infancy and that its bathwater got a bit grimy.

Where there is disagreement is that Rubyists often use language-powered DSLs in configuration files. The closest I have ever seen in Perl was a configuration file made up of a large number of variable assignments. The programmer simply did not want to deal with a parser to handle the hundreds of variables being assigned and all of the string variations that might be encountered, so he had them directly evaled from configuration. Is that bad programming? Maybe so in Perl terms, but one cannot ignore the benefits he realized without any loss of maintainability of his code:

• He avoided needing to invent a configuration file format. Perl defined all the syntax for him.
• He avoided needing to write a parser that would need to understand his assignments to various scalar, array, and hash values.
• He did not need to figure out how to parse strings with special characters, such as quotes, so his strings could automatically accomodate arbitrary data as needed by administrators of the application.
• He got clean handling of line breaks and multi-line statements for free.
• He could make use of already assigned values to be included into other values without having to form his own string substitution symtax.
• Comments and their syntax are included in the benefits.

You automatically win all this when your configuration file is nothing more than assignments. Ruby programmers take it farther and gain even more leverage by providing methods for use in configuration.

I have a hard time believing that an application having to provide its own code to deal with the above instead of just letting the language handle it is going to be easier to maintain, as is opined by the Perl users I quoted. I am particularly convinced of it because I have myself written programs of both categories: those that use the power of the language in a DSL and those that carry along its own parser, defining its own syntax and language. I suspect the reason many Perl enthusiasts do not agree is that they have never written a language-powered DSL in an appropriate situation. If the most vocal Perl users (and their leadership, too?) is lambasting the idea, they certainly have no small social obstacle to get around if they honestly think the language-powered DSL is the right way to go.

With language-powered DSLs I have written a simple vulnerability scanner in 75 lines of Ruby. The configuration file to check one specific vulnerability I needed checked was 30 lines. 105 lines of code to check one vulnerability is no big deal, but the program is vulnerability agnostic. The configuration file only takes a port, information on what to spew to that port, and what to expect back from the system if it is vulnerable or not vulnerable. It is already sophisticated enough to handle a multi-part conversation. I believe the Perl community’s recommended way to do this with about the same amount of code would be to have modules instead of configuration files for each vulnerability. With a DSL I do not have to mess with package overhead or making sure my @INC array will contain the directory with my vulnerability information.

I have also written a fetchmail/procmail hybrid in 512 lines of Ruby. I needed something that could log into a POP server and download my mail like fetchmail does but also review the contents of the message and make procmail-like decisions about delivery before deciding to delete or keep the message on the server (the knowing to keep or delete being the key to why I could not use fetchmail and procmail). My personal configuration file for this is about 60 lines, but there is no reason you would need more than 5 if you wanted very basic functionality. I plan to share this program in the future, and I would be happy to speed that along if enough people show interest.

What did I gain, in addition to the benefits I noted above, in my DSL for the fetchmail/procmail hybrid?

• No need to decide on how to implement if, while, and other loop constructs. Since this program has to make decisions it can make use of these constructs if the user desires to use them.
• More elegant constructs specific to the task at hand. These are methods defined that (usually) expect blocks of code that are run conditionally (and possibly multiple times) based on the needs of the application.
• Users could assign different values to a configuration directive based on what host they are running from. I found this feature useful in my personal configuration; I can have mail delivered locally if I am on my Linux host but delivered onto a network drive if I am using my Windows host. This kind of feature is technically available even when you are limited to variable assignment, but I encourage its use when appropriate.

Do not use language-powered DSLs when writing a parser is clearly superior, such as when the input cannot be trusted. You cannot give the full power of the language to untrusted input unless you want a security nightmare. As I stated above, I have written my own special use language from Ruby in order to parse code from untrusted sources. I had to handle all the issues I mentioned above: dealing with the conditional and looping constructs, parsing strings that accommodate arbitrary data (through escape sequences), handling the parsing of arithmetic operators so they can be used inline, etc. It was a full language executed inside my application. So I do know what kind of code that entails, and it is most certainly not more maintainable than using the power of the language in your DSL.

If you have been told in the past by experts that “eval is bad” then I urge you to open your mind a little. Listen to what they have to say about it—they do make some valid points about when not to use eval, but do not think it means that one should never use it. I used to be in your camp, too, but when faced (in my case directly faced) with obvious benefit after obvious benefit, I came around. I urge you to take the plunge, too.

As it turns out, Ruby includes an excellent module for parsing dates. It can handle several common formats, too! All you need to do is require ‘parsedate’ and you have access to it:

(Text in bold is what you would type.)

require 'parsedate'
user_input = ARGF.readline
seconds = Time.local(*ParseDate.parsedate(user_input)).to_i
puts seconds

% ruby parsedate_example
August 10, 2007
1186722000

If you are in a hurry, try a one-liner:

% ruby -rparsedate -nle \
      'print Time.local(*ParseDate.parsedate($_)).to_i'
August 10, 2007
1186722000
2006-09-21
1158814800
2001 sep 8
999925200

If you deal with /etc/shadow a lot you will find this useful for figuring out what today is in terms of the password last changed field by dividing the given number by 86400 (the number of seconds in each day):

% ruby -rparsedate -nle \
      'print Time.local(*ParseDate.parsedate($_)).to_i / 86400'
August 10, 2007
13735

Or do it in reverse with Time.at:

% env TZ=GMT ruby -nle 'print Time.at($_.to_i * 86400)'
13735
Fri Aug 10 00:00:00 +0000 2007

With Ruby you never need to venture far to manage your dates! Let me know if you find this useful or if you have questions about similar should-be-easy problems you encounter!

Only one way to find out! I downloaded a fresh copy of the source code for Ruby 1.8.6 and started poking around in random.c, where the function in question lives. My findings are mixed, and I have good news and bad news to report!

The good news is that if the Unix character device /dev/urandom is available then the random number generator is seeded with a value based from a read from that device. The /dev/urandom device is a “secure” pseudo-random number generator device, so the resulting random numbers are going to be pretty good. Note that you are still at the mercy of how well your operating system implements the algorithm for /dev/urandom and how that number generator gets seeded, but generally it works pretty well.

The bad news is that if /dev/urandom does not exist then your random numbers come from a podge of the current time, process id, and a sequence. That will get you a random number good enough for shuffling your deck of cards in a friendly game of Euchre, but you do not want to depend on it for your bank account’s security.

Should you use Kernel#rand on a system without /dev/urandom? That depends. How secure do you want your application to be? If there is any level of money or privacy involved, then I think you better make sure Ruby can find your /dev/urandom device. You also better verify that your operating system’s /dev/urandom algorithm is implemented well.

What if there are large amounts of money involved? All I have spoken of so far is the security of the seed to the random number generator. How good is the random number generator itself? For high security applications, does it matter how good our seed value is if we fail to use a good algorithm to crunch it?

Once again there is good news and bad news on that front. Ruby uses the Mersenne Twister random number algorithm developed in 1997 by Makoto Matsumoto. Wouldn’t you know it that a Japanese algorithm is in use in a programming language from the same islands? The bad news is that it is not an algorithm that is naturally suited for secure applications—speed of number generation is its primary focus. After being seeded the number generator will fall into a pattern. The good news is that you need to generate lots of numbers before that pattern emerges, and it turns out that it can be used in secure applications with some limitations. Please note that I am not a cryptographer, so I am gleaning this information from an external source or two. Use it at your own risk.

But before you run out and use Kernel#rand on your new banking application, heed one more note of caution. High security applications should not be depending on /dev/urandom for seeding another random number generator. If you are going to be feeding a random number generator, why not get a real random number? Systems that have /dev/urandom also have a /dev/random. This latter device generates random numbers that do not get filtered through a random number generator. Assuming your system has a good means of obtaining random bits to regurgitate to /dev/random and your application does not consume them too quickly (reads on /dev/random will block if it runs out of bits), you should seed your random number generator directly from /dev/random for your highest security applications.

Cosine, if you post yet another followup, please explain precisely what in the world you possibly mean by “better support DSLs” and perhaps even “DSL” in general.

Excellent comment, so I will. It goes somewhat to the Lisp idea that code is data, and that data are code. When everything has parentheses around it, that concept is slightly more obvious because they look identical. Here is some code:

(car mylist)

And here are some data:

'(car truck van)

So in Lisp if your list contains symbols that map to function and variable names then you can do an eval and execute your data as code. So one nice thing to do in any language that has an eval function, Perl and Ruby included, is to sometimes have “data” that are run through eval and executed to provide configuration or additional functionality:

do_stuff {
    print "hello world\n";
}

If the right context is created, the above code executes in that context (this example works for both Ruby and Perl due to their similarities), and it provides a powerful way to write small programs with extremely powerful configuration options because the whole force of the underlying programming language is available. The resulting “configuration file language” we create in this process is the DSL.

Let us see what the “hello world” example of a DSL looks like. We will use the above example as our DSL. This DSL defines a do_stuff function that will save the block of code to be executed later. This example will execute the code in the above file just once.

In Ruby (download):

class DoStuff
  def initialize
    instance_eval File.read('config')
  end

  def do_stuff (&block)
    @do_stuff = block
  end

  def run_func
    @do_stuff.call
  end
end

a = DoStuff.new
a.run_func

In Perl (download):

package DoStuff;

our $current_self = undef;

sub new {
  my ($class) = @_;
  my $self = $current_self = {};
  bless $self, $class;
  open CONFIG, "<config";
  my @config = <CONFIG>;
  close CONFIG;
  eval join('', @config);
  $current_self = undef;
  return $self;
}

sub do_stuff (&) {
  my ($func) = @_;
  $current_self->{'do_stuff'} = $func;
}

sub run_func {
  my ($self) = @_;
  &{$self->{'do_stuff'}};
}

package main;

my $a = DoStuff->new();
$a->run_func();

The reason I feel that Ruby supports this better than Perl is twofold:

1. Ruby has contextual eval statements, whereas Perl has just one eval statement that loses context (this can be seen by use of $current_self above to work around the problem); and
2. Ruby’s syntax allows for cleaner and more readable DSLs.

Addressing #2 above, if you want a function in your DSL to take arguments and a block of code, then in Ruby you have:

do_stuff(1, 2, 3) { ... #this code might be long }

In Perl the arguments go at the tail of the code (unless you make the code reference explicit):

do_stuff { ... #this code might be long } (1, 2, 3);

If you are reading code in a Perl-based DSL, by the time you get to the end of a block of code and see the arguments for the functions, you may not recall which function it is associated with (unless you bounce back and forth on those curly braces). The arguments are generally used to modify the basic functionality of the function and are easy to comprehend when at the top of the invocation:

do_stuff(:silently, :with => :things, :notify => "matz") { ... }

Anyway, certainly there are Perl enthusiasts out there that will disagree with these opinions. Maybe there is some aspect of Perl I do not understand that makes it easier than I thought in Perl, and if so I would love to know. I still have to use Perl occasionally and so any advancement of that knowledge is useful, too. And actually, even though I still find it much easier to write DSLs in Ruby than in Perl, in writing this post’s examples I discovered that writing a DSL in Perl was a lot easier than I thought it was.

Your complaint about being unable to write code the way you’re used to with Ruby when picking up Perl for a hours seemed pretty thoughtless. Of course it’s harder for you in Perl — you don’t know Perl nearly as well as you know Ruby! Claiming that this is somehow a fundamental flaw of Perl is just not right.

I meant to suggest in my previous post that the flaw was in me for no longer thinking in Perl when using Perl, though at the same time if Perl were to better support DSLs (domain specific languages) then I would have gotten a Get-Out-of-Jail-Free Card despite my mis-think. I hope that others reading this benefit from the clarification as well.

But this reply also made me think about my comparative knowledge in the two languages. Do I really know Ruby better than Perl like stated in the feedback? I do not feel like I do. I know a lot about both languages, and there are gaps in my knowledge of each language. In fact, other than those people that write Perl modules in C, I generally know as much or more about Perl than other Perl users I meet. It is a real nice language that has served me very well over the years. My problem with it is that I just do not alter my thinking to eliminate concepts alien to Perl when using it, or at least not in version one of whatever I am writing.

My knowledge of Ruby is not shallow, but it is not as deep as I would really like, either. I can write Ruby modules in C, and I have used that knowledge to embed Ruby directly into a monolithic C program in an attempt to port it slowly, release by release. However, there are constantly things that crop up in Ruby that leave me scratching my head thinking, “wow, I can do that!?” I did not know until recently that a Hash object could be given a default value other than nil. Previously, if were using a Hash of Array objects I would have done this:

def my_set (hash, key, index, object)
    if not hash.has_key? key
        hash[key] = Array.new
    end
    hash[key][index] = object
end

h = Hash.new
my_set(h, 'red', 1, 'one')
my_set(h, 'blue', 2, 'two')
p h
=> {"blue"=>[nil, nil, "two"], "red"=>[nil, "one"]}

Now I know can just define the Hash object differently to do the same thing:

h = Hash.new { |hash, key| hash[key] = Array.new }
h['red'][1] = 'one'
h['blue'][2] = 'two'
p h
=> {"blue"=>[nil, nil, "two"], "red"=>[nil, "one"]}

It is pretty simple and makes for cleaner code, but I did not know it. I must not have paid enough attention during the Hash class.

Little things like this led me to think that perhaps I know Perl better than Ruby, but I think that is probably not true anymore. There is so much to know about both languages that one can easily not be certain, but since 2004 I have not been paying nearly as much attention to Perl as I have to Ruby. Over the course of these last three years it must be inevitable that my Ruby knowledge would surpass my Perl knowledge. I think it has happened, but I would never wager a bet on when. I just do not know.

What kind of things were not so intuitive? In my program today I had a situation where some questions need to be asked of the user. I wanted to use a DSL (domain specific language) to handle the querying because I need to create about a dozen similar programs that all do things just a bit differently. To facilitate this I abstracted as much common code as possible into its own class, threw it into a Perl module file, and made it available for all the programs to use.

However, Perl is not really capable of DSLs, and trying just made the code really messy. As it stands I have something that works but will need some revision next time I update it. Instead of a clean DSL I have a strange function-passing call-back situation that makes following the code more challenging than such a small program should be. In Ruby this thought would have led to clean code, but in Perl I need to revisit the code and rework it to a pure object-oriented design, sans psuedo-DSL, to effect more maintainable code. At the same time, without being able to think in terms of the DSL will make writing the dozen or so programs that are really the point of this whole exercise more difficult.

If you want to help save me from this situation in the future, go out there and help make Ruby more mainstream. I am only stuck using Perl because it comes with everything. It comes pre-installed with almost every Unix now, and often it comes packaged again with third-party applications. Ruby should be in many of these positions. Ruby comes with Mac OS X, but not much else. Until the day I hear Ruby comes pre-installed with Solaris I know that Ruby has not yet really broken into the mainstream—what Sun includes with Solaris is a good indication of what is in mainstream use.

So come on! Let us get out there and promote Ruby! Let us bring Ruby into the mainstream and make everyone’s lives easier!

Capistrano has no facility for continuing tasks upon failure. In a large Unix environment, stuff needs to happen even if only 98% of the systems are up. What about the 2% not available? They can get the update later when they’re back. We needed a tool that can just do the work and get it done on the 98% and report on who failed. Later, when the failed systems are back online, the tool should automatically update them on the next run. Then we can go about fixing the issues causing those 2% of systems to fail and rest assured that all our changes will be pushed soon.

I intend to fill this gap. Jamis Buck, the maintainer of Capistrano, also wrote the Net::SSH module for Ruby. It is a spectacular module. With it, I plan to write an agentless tool that runs from a central server and uses SSH to log into each system for whatever task necessary. Couple it with some tools to manage users, groups, system configurations, and software installations, and a new tool to conquer the world will be born.

If you want to conquer the world with me, let me know!

I have written a similar tool before. Back when I worked at Abbott I wrote a little tool we called confmgt. I used Perl because when I started the project around 1999 or 2000 that was the best language I knew. Additionally, Perl was installed on every Research and Development Unix system in the company, so I could count on it being present. The original version ran on a central server and used rdist to push files to target hosts after performing some non-trivial logic on which files to include in and exclude from the transfer.

Eventually the tool grew and features were added, and by version 3.0 (the last major version when I left Abbott) the program used rsync by default and could be run either from central server or from the host being updated. More complicated configurations required features to include more customization in how distribution areas were laid out. Despite still being written in Perl, I was very proud of the 3.0 release of confmgt. It was a masterpiece of Perl and of programming in general. With this release other Unix administrators were no longer coming to me and asking for new features; instead they came, asked, and then left knowing how to do what they were requesting. I have rarely felt greater pride in my work.

So now I am going to repeat myself, but this time in Ruby. Instead of rsync I will use Net::SFTP. The configuration file will likely be similar to Capistrano’s so that people familiar with one can use the other easily (as it should be!). It is time to change the world.

Firstly, my recent computer research efforts have been to learn yet more about application security. I know what I know very well, but I also know when I feel a weakness in my knowledge—and I need to do more with application security to advance my knowledge there. I have all the basics now; the next step is application.

Additionally, I need to do more with Rails. I know Ruby very well, and it is absolutely the best programming language I have ever used. I have dabbled with Rails know the basics, but I need to do something useful with it so I have an ongoing Rails project to care for. Without something like that my knowledge in Rails has not broken a mediocre level, and I have fallen behind in recent advances that the Rails core team has delivered recently. An update to this very website into a Rails powered site is very likely!

In summary, the two areas I want to target my development is application security and Rails. Tune in to see what I decide to do with each of these. Drop me a line if you want to chat about it! I love talking about these subjects, so I will love to talk.

I still want to use cosine.org for some stuff, but I’m not sure how I’m going to manage it yet. It would be a good place for a technical blog, but so would cosinewave.net along with the comic. Decisions!

Right now cosine.org is all static content. That’s not ideal for a blog, where comments are nifty. So something’s going to have to give. I’d write a small Rails app for the task, but the site I’m hosting on is too low on RAM to handle even one Rails application except using the CGI gateway (slooow!).

And by the way, although I’ve been saying it out loud for five years, I’ll say it again right here: If you program and you haven’t looked at Ruby yet, you will kick yourself when you do someday and wonder why you didn’t check it out sooner. So just check it out, okay? No, just knowing Python is not sufficient. Ruby is a cut above. I’ve been saying this for five years, but I’m not good at sales. Ruby will speak for itself when you learn it, okay? Trust me!

And if I end up being a big fat liar with my pants on fire about this Ruby stuff, you probably didn’t lose much time figuring it out, did you? Oh, you haven’t looked at Ruby yet? Dammit, GO LOOK NOW!