Gray Soft

30
JUL
2006
PStore Meets YAML

I love the PStore standard library. It's a very graceful interface to get some fairly robust serialized mini-database handling in just a few lines. With it you get:
1. Transactions with commit and rollbacks (automatic on exception).
2. File locking, shared and exclusive.
3. Multiprocessing safety.
PStore does even more, including some file mode checking and MD5 hashing to avoid unneeded writes, but the above are the major selling points for me.

Now, if I had to level any one complaint at PStore, it would be that because it uses Marshal under the hood it doesn't create files you can easily browse or tweak by hand. (Marshal is a feature, don't get me wrong. It's fast, which is very helpful.) Sometimes though I want PStore protection with the YAML file format.

I'm embarrassed to admit that I use to use a hack for this:
```
require "pstore"
require "yaml"
class PStore; Marshal = YAML; end
```
That just redefines the Marshal constant in a scope that should only alter PStore. The library only uses dump() and load() and those methods work the same with Marshal and YAML.
Read more…
In: The Standard Library | Tags: Hidden Features | 2 Comments
29
JUL
2006

YARV Looking Promising, James's C is Not

I participated in the ICFP programming contest last weekend with a group of friends. We had a great time with the event and learned a ton. I thought I should share two interesting insights with others that might appreciate them.

First, YARV looks very promising for some general speed increases in Ruby. If you are not familiar with YARV, that's the virtual machine that will run Ruby 1.9. During the contest, we ran into some performance issues with our Ruby solution and after we had optimized all we could think of, we decided to try running our entry on the experimental YARV VM to see if it was faster there. Good news: it was a lot faster.

Please do not take these numbers as anything more than very non-scientific observations, but we did notice a huge speed increase on YARV. We were reliably waiting around 15 minutes for one section of our program to run on Ruby 1.8.4, but when we introduced YARV the same section generally ran in just under seven minutes. You heard me right there, it was over twice as fast. I think that's very promising news for the future of Ruby.
Read more…

In: Language Comparisons | Tags: Performance | 1 Comment
16
JUL
2006
String Has Other Methods Besides =~/match() and sub()

Ask anyone who knows me and they will tell you I'm a huge fan of regular expressions. I use them all the time and my FasterCSV library is a regular expression powered parser. However, even I know they are not for everything, and lately I keep running into almost comical examples of misuse. Here are some of my favorites.

First, we have:
```
str =~ /=/
```
That snippet is like calling for a military escort (the regular expression engine) to see you safely to the grocery store down the block. That's fun, but probably overkill. In this case, a call to include?() will do the trick:
```
str.include?("=")
```
That may be more like riding your bike to the grocery store, but it gets the job done and is a bit faster to boot.

Funny example number two. I've seen this before:
```
str =~ /\Aquit\Z/
```
Again, the regular expression engine appreciates the love, but you really just want ==:
```
str == "quit"
```
Even for some of the fancier stuff, you don't need a full blown regular expression. For example, this:
Read more…
In: Early Steps | Tags: Hidden Features | 3 Comments

8

JUL
2006

The Books are Wrong About Logger

I've read several books that introduced the standard Logger library and they all agree on one thing: you can't customize the output. That's so last version in thinking! Behold…

Here's a trivial Logger script, showing basic functionality:

#!/usr/bin/env ruby -w

require "logger"

def expensive_error_report
  sleep 3  # Heavy Computation Simulation (patent pending)
  "YOU BROKE IT!"
end

log       = Logger.new(STDOUT)
log.level = Logger::INFO  # set out output level above the DEBUG default

log.debug("We're not in the verbose debug mode.")
log.info("We do see informative logs though.")
if log.error?  # check that this will be printed, before waste time
  log.error(expensive_error_report)
end

If you run that you will see:

I, [2006-07-08T11:17:19.531943 #340]  INFO -- : We do see informative logs though.
E, [2006-07-08T11:17:22.532424 #340] ERROR -- : YOU BROKE IT!

Now everyone has always known you can format the date and time display using a strftime() compatible pattern:

#!/usr/bin/env ruby -w

require "logger"

def expensive_error_report
  sleep 3
  "YOU BROKE IT!"
end

log                 = Logger.new(STDOUT)
log.level           = Logger::INFO
log.datetime_format = "%Y-%m-%d %H:%M "  # simplify time output

log.debug("We're not in the verbose debug mode.")
log.info("We do see informative logs though.")
if log.error?
  log.error(expensive_error_report)
end

21

MAR
2006

The Why and How of Iterators

A friend of mine has been asking some general questions about iterators in private emails we have traded. I wanted to put some of my answers here, in case they appeal to a wider audience.

Why do we have iterators?

First, let's invent a little data to play with:

>> Name = Struct.new(:first, :last)
=> Name
>> names = [ Name.new("James", "Gray"),
?>           Name.new("Dana", "Gray"),
?>           Name.new("Caleb", "Nordloh"),
?>           Name.new("Tina", "Nordloh") ]
=> [#<struct Name first="James", last="Gray">,
    #<struct Name first="Dana", last="Gray">,
    #<struct Name first="Caleb", last="Nordloh">,
    #<struct Name first="Tina", last="Nordloh">]

Now let's assume we want to print some names. We can use the each() iterator for that, no index:

>> names.each { |name| puts "#{name.last}, #{name.first}" }
Gray, James
Gray, Dana
Nordloh, Caleb
Nordloh, Tina
=> [#<struct Name first="James", last="Gray">,
    #<struct Name first="Dana", last="Gray">,
    #<struct Name first="Caleb", last="Nordloh">,
    #<struct Name first="Tina", last="Nordloh">]

10

MAR
2006

Java a Bit on the Wordy Side

I was helping a friend of mine with a Java problem yesterday and couldn't help but notice this totally normal (for Java) file in his project:

import java.io.Serializable;

public class Contact implements Serializable
{
   private String firstName;
   private String lastName;
   private String email;
   private String phone;

   public Contact()
   {
       this("", "", "", ""); // call four-argument constructor
   } // end no-argument Contact constructor

   // initialize a record
   public Contact(String first, String last, String eml, String phn)
   {
       setFirstName(first);
       setLastName(last);
       setEmail(eml);
       setPhone(phn);
   } // end four-argument Contact constructor

   // set first name
   public void setFirstName(String first)
   {
      firstName = first;
   } // end method setFirstName

   // get first name
   public String getFirstName()
   {
      return firstName;
   } // end method getFirstName

   // set last name
   public void setLastName(String last)
   {
      lastName = last;
   } // end method setLastName

   // get last name
   public String getLastName()
   {
      return lastName;
   } // end method getLastName

   // set email address
   public void setEmail(String eml)
   {
      email = eml;
   } // end method setEmail

   // get email address
   public String getEmail()
   {
      return email;
   } // end method getEmail

   // set phone number
   public void setPhone(String phn)
   {
      phone = phn;
   } // end method setPhone

   // get phone
   public String getPhone()
   {
      return phone;
   } // end method getPhone
} // end class Contacts