How to optionally kill a child and capture status if not killed

How could killing a child ever be optional? It’s illegal! It’s disgusting!

We must not tolerate these criminals in our midst any longer. Now is the time to put an end to that vicious disease called Perl.

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:

Everything after the first sentence vanishes in the distance where no-one will ever read it.

First I thought that such a plugin would need (or could at least profit from) sem***ic web technologies (no dirty words on this blog, please), but it probably wouldn’t. All we need is a global registry that maps package names to the URLs of the web interfaces of the respective source repositories. (Maybe Google Code Search could be such a repository, but its results are often pretty bad.) The plugin would also have to include a reasonably good Java parser, and maybe a heuristic to distinguish betweeen Java and non-Java text.

Why would I want such a thing? Well, I often have to dig through the code of some open source library in order to understand a bug, or just to figure out what I can do with it, and how, because the documentation is incomplete or wrong. Usually I create an Eclipse project and import the code from the source repository, but that’s quite a lot of overhead if I just need to browse the code for ten minutes or so. On the other hand, digging through source code on web pages, without the help of links between the pages, is just a nuisance.

And wouldn’t it just be so cool to have one of the most important features of an IDE as a browser plugin, enhanced by the power of the world wide web?

P.S.: Or maybe I don’t want a browser plugin – maybe I just want Google to put some more effort into Code Search? Come on, guys, you’ve got all it takes – the global repository, the parsers, the heuristics…

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]

More detailed reviews of programming fonts over at Coding Horror.

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.