Ben Poweski's Weblog

For the most part Ruby has fantastic APIs. While there is an occasional wart here and there (I”m speaking to you DateTime). In general, it doesn’t suck. The OpenSSL bindings for Ruby are no exception.

Bob, meet Alice

To begin our cultural learnings of OpenSSL and Ruby, let’s take a look at source repository for the interpreter. In the samples directory are some nice examples how the bindings work. It seems that some of the original code examples were never migrated from the RubyPKI project, but thats ok, you can still access them here.

The OpenSSL Digest Class

One of the most common things you’ll most likely need is to create a digest of a string of data. We can do this using by instantiating a Digest class then invoking the hexdigest method.

irb(main):001:0> require 'openssl'
=> true
irb(main):002:0> @sha1 = OpenSSL::Digest::SHA1.new("fooooo")
=> 58c00efa9bed725721b29f4b5f7864f0f191cad5
irb(main):003:0> @sha1.hexdigest
=> "58c00efa9bed725721b29f4b5f7864f0f191cad5"
irb(main):005:0>

Simple enough. But what is the deal with ‘digest’ versus ‘openssl/digest’? According to the ‘digest’ module is only used for backwards compatibility, so use the openssl version when possible.

Available Digest Algorithms

According to the source, the Digest algorithms available are dependent upon the version of OpenSSL compiled with Ruby.

module OpenSSL
  class Digest

    alg = %w(DSS DSS1 MD2 MD4 MD5 MDC2 RIPEMD160 SHA SHA1)
    if OPENSSL_VERSION_NUMBER > 0x00908000
      alg += %w(SHA224 SHA256 SHA384 SHA512)
    end
    ...

Why? I admit, at first glance the idea of developing a highly usable Ajax web application using the Google Web Toolkit is intriguing. Java, after all, is our modern day COBOL. We get IDE support, have countless vendors to point fingers at and can bury grown men using the Java selection alone at our local B&N.

What does this have to do with Google Web Toolkit? Probably not a whole lot, but Google did ditch a powerful dynamic language (JavaScript) in exchange for a statically typed language (Java). They have built some fantastic software using it…but I agree with Justin, when I say, they’ve pushed it too far with this one.

• Debugging JavaScript errors in Java proves to be an interesting exercise.
• While we get out of the box widgets….all of my GWT apps look like they’re made in Google, complete with the kindergarten color scheme. Your mileage may vary.
• HTML, CSS and Javascript are relegated to bottom feeders of the view. No longer do we have separation of content and style, but a munge of both.

Something about this whole framework doesn’t feel right. But damn, some of their applications are neat.

As web application developers all too often HTML and CSS markup are the bastard, unmaintained children of our projects. We take the time to refactor our Ruby, Java and Python code but when it comes to cleaning up the HTML markup, we somehow manage to find excuses to ignore it. We love to praise DRYing up our code, but for HTML….it never seems to become a reality.

Case 1: Google Registration HTML

The following snippet was taken from the URL https://www.google.com/accounts/Login.

  <table width="100%" border="0" cellpadding="2" cellspacing="0">
  <tr>
  <td colspan="2"><img width="1" height="2" alt="" /></td>
  </tr>
  <tr>
  <td valign="top" width="1%">
  <a href='https://www.google.com/accounts/'>
  <img src='https://www.google.com/accounts/googleaccountslogo.gif'
       border="0"
       align="left"
       alt="Google" />
  </img>

  </a>
  </td>
  <td valign="top">
  <table width="100%" border="0" cellpadding="0" cellspacing="0">
  <tr>
  <td colspan="2"><img width="1" height="15" alt="" /></td>
  </tr>
  <tr bgcolor="#3366cc">
  <td><img height="1" width="1" alt="" /></td>

  </tr>
  <tr bgcolor="#e5ecf9">
  <td style="padding-left: 4px; padding-bottom:3px; padding-top:2px; font-family:arial,sans-serif;">
  <b>Google Accounts</b>
  </td>

While there is no DOCTYPE declaration for this page, one can assume the intentions were to render on as many browsers as possible in the most consistent manner. One technique is to forgo all of our fancy new (well newer) approaches and use the oldest subset of HTML available. Font tags and all. Unfortunately, all of the nasty HTML tricks we resorted to in the late 90’s also apply. The point of this is not to bash on Google, but show how we can improve this code and not repeat ourselves.

How can we improve this?

1. We can start by setting a root class for the table. This will be the point in which we apply relative style rules.

2. Since the CSS rule background-color doesn’t work as expected, we’ll need to use a descendant selector on the td elements.

3. Move the the HTML attributes to a CSS declaration.

We might end up with something like the following:

 
.registration_table { width: 100%; border: none; }
.registration_table td { background-color: #e5ecf9; }
.registration_table tr.odd td { background-color: #3366cc; }

 <table class="registration_table" cellpadding="0" cellspacing="0">
  <tr>
  <td colspan="2"><img width="1" height="15" alt="" /></td>
  </tr>
  <tr class="odd">
  <td><img height="1" width="1" alt="" /></td>
  </tr>
  <tr>
  <td style="padding-left: 4px; padding-bottom:3px; padding-top:2px; font-family:arial,sans-serif;">
  <b>Google Accounts</b>
  </td>

While this isn’t perfect it provides us fewer points of modification if we wanted to do something like…change a color or reuse this style in a common file.

Case 2: Google Registration CSS

A similar situation exits in the CSS style rules for this page. Here we see redundant blocks of rule content. The font declarations font-family, font-size, and font-weight are repeated for the style rules: .gaia.sub.el, .gaia.sub.pl and .gaia.sub.rpl.

  .gaia.sub.el { font-family: arial, sans-serif; font-size: smaller; font-weight: bold;}
  .gaia.sub.pl { font-family: arial, sans-serif; font-size: smaller; font-weight: bold; }
  .gaia.sub.rpl { font-family: arial, sans-serif; font-size: smaller; font-weight: bold; }
  .gaia.sub.es { font-family: arial, sans-serif; font-size: smaller; font-style: italic; }
  .gaia.sub.seex { font-family: arial, sans-serif; font-size: smaller; color: #6f6f6f; }
  .gaia.sub.pc { font-family: arial,sans-serif; font-size: smaller; color: #6f6f6f; }

We could improve this by using a comma delimited declaration such as:

  .gaia.sub.el,
  .gaia.sub.pl, 
  .gaia.sub.rpl  { font-family: arial, sans-serif; font-size: smaller; font-weight: bold;}

The point is illustrate that HTML and CSS are code too! They suffer from many of the same issues that our application code bases suffer from…and can utilize the same techniques.

A co-worker of mine was writing a little script to parse an excel file that contained various network addresses and run various test cases against it. He was stumped on the algorithm how to decoded excel headers to specific indexes. While at first glance this looks like a simple problem, it ended up being more difficult than we thought. My co-worker approached the problem using a procedural approach, this ended up yielding a few nasty loops…far from elegant. The end result ended up being rather easy once the approach was modified to use recursion.

My Solution

require 'test/unit'

def to_excel(i)
  case i
  when 0
    return ''
  when 1..26
    return ('A'..'Z').to_a.at(i - 1)
  else
    q, r = (i - 1).div(26), (i - 1) % 26
    return "#{to_excel(q)}#{to_excel(r + 1)}"
  end
end

class ExcelNumberSeriesTest < Test::Unit::TestCase
  def test_simple
    assert_equal 'A', to_excel(1)
    assert_equal '', to_excel(0)
    assert_equal 'Z', to_excel(26)
  end

  def test_doubles
    assert_equal 'AA', to_excel(27)
    assert_equal 'AB', to_excel(28)
    assert_equal 'AZ', to_excel(52)
  end
end

It’s amazing when a hard-drive can fail on a Linux host and the operating system still runs.

To accompany my recent Mac Pro purchase, I’ve been looking for a large format LCD display. I’m tired of my dual 19” setup, two screens are far less usable than 1 large one. While the AAPL screens are undoubtedly expensive, people usually compare AAPLs to oranges while giving cost figures.

All LCD screens are NOT created equal

The modern LCD screen is manufactured using 3 primary technologies:

• TN Film (Twisted Nematic + Film)
• MVA &t; PVA (Patterned Vertical Alignment)
• IPS (In Plane Switching)

So what is the big deal? It is all about trade-offs.

TN Film

TN Film LCD panels are the cheapest panels around. Look at any sub $400 24” LCD and you’re likely to find a TN Film panel inside. On the negative side, viewing angles are usually subpar when compared to the other LCD technologies. Usually about 10 degrees worse than an S-PVA panel. These panels have worse color presentation, often they only have 6-bit color depths versus 8-bit color. Many TN Film panels exhibit a purple hue throughout. On the positive side they have the best refresh ratings, often in the in 2-5ms range.

Common TN Film panels include:

• Any Samsung with a B in the model number (Samsung 245BW)
• Any Dell with an E at the beginning (E248WFP)
• ViewSonic Optiquest Series Q241wb

So far we can see TN film is less than desireable for anyone doing a significant amount of design work or if you’re a color snob (such as myself).

MVA and S-PVA

MVA (Multi-Domain Vertical Alignment) and S-PVA (Patterned Vertical Alignment) panels present a significant bump in quality over TN Film panels for a modest increase in price. In my opinion you should avoid TN Film and find an MVA or S-PVA panel. They offer an increase in brightness and viewing angle in exchange for a slightly higher screen latency.

Common MVA and S-PVA panels include:

• Samsung T series (245T, 305T)
• Dell 2407WFP
• BenQ FP241W

IPS

IPS is king when it comes to color representation. IPS panels exhibit true 8-bit color depth at the expense of latency, cost and contrast. If you are a fanatic about the color of your screen then IPS is the only way to go, unless you want to revert back to your old CRT.

Common PPS panels:

• Apple Cinema Displays
• Dell 3007WFP, 3008WFP

All it all, unless you absolutely must have the perfect color representation on your screen S-PVA or MVA is the way to go. Many of these panels can be had for near $450 price points. Be cautious when researching a screen, many times manufacturers will stop producing models that use the better S-PVA screens and replace them with the cheaper TN FIlm panels. This has happened with many models such as the Acer AL2416WBsd.

The irony of Rake is that Ruby really doesn’t need it. This is not to say it isn’t useful to Ruby projects, quite the contrary. Where Rake shines is in building software for applications that require byte code and object code, such as Java or C centric projects.

One such language requiring byte code compilation is Erlang. The design of the runtime environment used by Erlang should be familiar to most Java or C# developers. Erlang uses a byte code compiler (erlc) and various application meta-data files (.app, .rel, .config). For my development work I use Erlide, the Eclipse based Erlang IDE. The standard project layout for an application created in Erlide is:

• project
  • ebin
  • include
  • src

When creating a Rake file for Erlang projects, I ran into a few problems with compiling the source into the separate ebin directory. Namely, dependencies where not being constructed as desired yielding a full rebuild every time I ran the build script! In the following example I dynamically create the file rules so that the bytecode (.beam) files will only be recompiled if the source (.erl) file is changed.

require 'rake'
require 'rake/clean'

CLEAN.include(['ebin/*.beam', '*.dump'])
SRC = FileList['src/**/*.erl']
BEAM = []

SRC.each do |fn|
  BEAM << dest = File.join('ebin', File.basename(fn).ext('beam'))
  file dest do
    sh "erlc -o ebin #{fn}" 
  end
end

namespace :erlang do
  desc "staring ermail" 
    task :run => [:compile] do
      sh("erl -noshell -pa ebin -s my_mod start")
    end

  desc "run tests" 
  task :test => BEAM do
    sh("erl -noshell -s test_my_mod test -s init stop")
  end
end

task :default => [:compile]
task :start => ['erlang:run']
task :compile => BEAM

Forgive me, as this will most likely spark deep seeded hatred from those forced to navigate the deep dark world of Java development. I have managed to break free from it for sometime now, enjoying my Ruby bliss of block passing and metaclasses. Just when I thought I was out, they pull me back in. They, being work. Why can’t we all develop with a language so pointed and terse.

The Java Version

StringBuffer subType = new StringBuffer();
for (String token : tokens) {
  // pretty print the tag
  char[] c = token.replaceAll("flag", "").toCharArray();

  // make first char upper case
  if (c.length > 0)
    c[0] = Character.toUpperCase(c[0]);
  subType.append(c);
}

The Prettier, More Compact, Ruby Version

tokens.collect {|t| t.sub(/flag/, '').capitalize }.join

I can hear the snide remarks right now…save them. There are plenty more examples where that came from.

Capistrano 2, the fantastic sequel to the already superb Rails deployment framework, is an excellent solution to the otherwise mundane task of deploying Java applications.

Network security restrictions prohibit me from using the typically SCM -> Production server configuration. Next, I ran into a few problems uploading Jar files using the put command. Luckily Alex Gorbatchev, posted an example of how to use SFTP within a Capistrano deployment recipe.

I used his idea and adapted my rails recipe using SFTP deployment.

namespace :deploy do                
  task :update_code do
    on_rollback { run "rm -rf #{release_path}" }
    run "mkdir #{release_path}" 
    files = Dir.glob('lib/*.jar') + Dir.glob('dist/*.jar')
    execute_on_servers(options) do |servers|
      servers.each do |server|
        files.each do |path|
          logger.info "uploading #{File.basename(path)} to #{server}"  
          sftp = sessions[server].sftp  
          sftp.connect unless sftp.state == :open  
          sftp.put_file path, File.join(current_path, File.basename(path))  
          logger.debug "done uploading #{File.basename(path)} to #{server}"  
        end
      end
    end    
    finalize_update
  end
end