PS1="\u `ruby -v | grep -e "[0-9]\.[0-9]\.[0-9]" -o` \w"

Works nicely.

then this should be the solution for you: First you install libmysqlclient15-dev, which generates a mysql_config file, and the install the gem using the config.

As a first try, I wrote a small hack solving the following problem:

In Aperture, I normally sort photos in folders named YYYY_MM_DD, so when I sort them by alphabet (or Aperture sorts them and I cannot change the sort order), the oldest ones show up first. Unfortunately, iPhoto imported photos from my camera in the German format DD.MM.YYYY, so the alphabetical sorting is useless.

The ruby script goes like this:

Problem is, that I have to use a legacy database in PostgreSQL where I am not allowed to tinker with the structure, but I am forced to insert data into the tables. The database was created using Hibernate, which means an overall database sequence is used to generate the unique IDs. Unfortunately my new pal ActiveRecord does not know anything about global Postgres sequences, so I had to figure out a way to use the hibernate sequence in a hack to get my unique IDs.

What I did was to use the hook before_validation_on_create in the ActiveRecord table model to create an ID. This looks like this:

[ruby]
class Term < ActiveRecord::Base
before_validation_on_create :generate_id

private
# use the hibernate sequence to generate the next id
def generate_id
self.id = Term.connection,execute(“select nextval(‘hibernate_sequence’)”).result[0][0]
end
end
[/ruby]

A crucial part for dynamic languages today (at least in my eyes) is the creation of domain-specific language, which Groovy also supports. Gant, for example, is a Groovy DSL for Ant scripts. Another example (take from the Tutorial Domain-Specific Languages in Groovy, PDF) I find very practical is a DSL for creating query criteria for Hibernate in the Grails framework (formerly known as Groovy on Rails, so its purpose should be clear):

def c = Account.createCriteria()
def results = c {
  like("holderFirstName", "Fred%")
  and {
    between("balance", 500, 1000)
    eq("branch", "London")
  }
  maxResults(10)
  order("holderLastName", "desc")
}

A good thing, but looks too java-y for my taste, I miss the feeling I get when using a Ruby DSL, such as SQL-DSL, for example:

statement = Select[:column1, 'book', 10].from[:table1, :table2].where do
  equal :column1, 99
  not_equal :column1, 100
  less_than :column2, 'foo'
  less_than_or_equal :column3, :column4
  greater_than :column1, 0
  greater_than_or_equal :column2, 'bar'
  like :column1, 'any'
  is_not_null :column1
  is_in :column1, [1,2]
  is_not_in :column2, [3, 4]
  exists 0
  not_exists 0
end

But maybe that’s just personal preference.

From a few first glance I get the impression, that Groovy is quite successful as a scripting sidekick to Java and I’m curious to learn more about it.

Through trial and error they taught me how Ruby and its rich set of libraries really work. Not surprisingly, typing in code and running it makes you remember. Indeed, writing learning tests is a fun way to poke and prod any new language or API. And with every test you write you’re investing in an executable knowledge base.

Unfortunately I never tried this myself, but I like the idea. According to him, the benefit is twofold: The tests assist in acquiring and checking knowledge (by what he calls “asking Ruby”) and act as a knowledge base that manifests itself in code (and some documentation, where needed, I’d like to add).

Yet I am a little bit skeptical about “asking Ruby”. In his second posting, he suggests to “make a guess” in a particular case where he doesn’t know the result of a method invocation ("Rick".index('t')). Maybe I’m a bit hypersensitive here, but I have some reservations when it gets to using tests to find out how things (could or should) work. I’d think it would it be better to just look it up in a reference and write the test afterwards. The main reason is that using one test case (or a few) will give you one (or few) results, from which you will have to draw conclusions and generalize—the semantics of the index method in this case. What if your conclusions are wrong for some exceptional cases? Is it possible/feasible/desirable to write tests for each and every combination of parameters for a method? Why not trying a “read first” approach?

Nevertheless, the basic idea of using test cases for playing around with a language and collecting them as a reference is a nice idea. I’ll almost certainly try this the next time want to learn something about Ruby or a different language.