rvm is great, but I still sometimes lose track of which Ruby version I’m currently using. As a little reminder, I put the Ruby version in my shell prompt, like this:
PS1="\u `ruby -v | grep -e "[0-9]\.[0-9]\.[0-9]" -o` \w"
Works nicely.
rvm is great, but I still sometimes lose track of which Ruby version I’m currently using. As a little reminder, I put the Ruby version in my shell prompt, like this:
PS1="\u `ruby -v | grep -e "[0-9]\.[0-9]\.[0-9]" -o` \w"
Works nicely.
Short note to myself and whom it my concern. If you try to sudo gem install mysql on a Debian system and it responds, after some working, with:
Building native extensions. This could take a while...
ERROR: Error installing mysql:
ERROR: Failed to build gem native extension.
(...)
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details. You may need configuration options.
(...)
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/mysql-2.7 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/mysql-2.7/gem_make.out
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.
I’m currently updating a not-so-small application from Rails 2.0.2 to 2.2.2 and it seems that about every other plugin is not compatible with the new version, because one or the other method was removed, and I have to update them as well. Not such a big problem, if a compatible version exists, but takes quite some time, and I don’t understand that I have to go through this hassle (and other hassles) about everytime I update to a new Rails version. I don’t remember having this kind of trouble when I was working in Java Land. Can somebody explain?
Dear fellow Ruby developers, please kick the habit of catching and rethrowing exceptions, thus ridding your users of the expeptions’ stack traces. Recently I had to patch the source code of an ActiveRecord adapter as well as the underlying DBI implementation in order to find out where one particular exception was originating from. This makes debugging code really a hassle. I haven’t had this kind of problem in Java since nested exceptions.
One of the very nice features of Mac OS X ist the ability of almost every reasonable application to receive AppleEvents, which makes the whole OS-app-bundle highly scriptable. Normally, Apple recommends that the scripting is done using a malevolent, programmer-unfirndly language named “AppleScript”. But there are alternatives, e.g. using Ruby together with the rb-appscript library.
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:
app = app(‘Aperture’)
puts app.projects
app.get(app.projects).each { |project|
name = app.get(project.name)
if name =~ /^\d\d\.\d\d.\d\d\d\d$/
day = name[0, 2]
month = name[3, 2]
year = name[6, 4]
app.projects[name].name.set(year+"_"+month+"_"+day)
end
}
This is just a note to all who, like me, wonder why the heck ActiveRecord’s quote method in model classes doesn’t work anymore in Rails 2.x: quote seemingly has been replaced by quote_value, though this is not listed on the deprecation page. So if you get an error that says undefined method `quote’ for your model class, replace the calls to quote by quote_value.
Currently, I am in the nice situation to decide for myself with which framework I will build a demonstration portal. So, as I want to profit from the fast-paced development processes (at least the Ruby aficionados say so) and the lightweightiness of Rails, I decided to go the Rail(s)Way.
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]
I am currently enjoying the discovery of Ruby as a language for blazingly fast scripting database tasks. Like e.g. converting database records on the fly. The ActiveRecord module is a great help in that.
In the recent weeks, both of my co-bloggers told me independently of each other about Groovy, the new hipster language which brings the scripting goodness of dynamic languages like Ruby and Smalltalk to the JVM Sweet JVM, so I finally couldn’t resist but take a look at it. To be honest, I didn’t like its Java-like syntax from the beginning, with all the parentheses, lowerCamelCaseIdentifiers and such, but that was just because I prefer Ruby’s very lean syntax. Its concepts are very close to Ruby (modification of objects and classes at runtime, blocks/closures, etc.) and of course it integrates well with the Java platform and its rich libraries, since this is the purpose for which it was created, to add a scripting facility to the Java platform. Groovy scripts are compiled into bytecode before execution and thus run on a normal JVM.
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.
A while ago, Mike Clark wrote two blog postings on how to learn Ruby by writing tests (#1, #2). He explains that he wrote a test for each bit he learned about the language, over the years collecting a set of more than 200 tests which act as his personal knowledge base on the Ruby language:
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.