sjs

It turns out that Python is the language of choice on the OLPC, both for implementing applications and exposing to the users. There is a view source key available. I think Python is a great choice.

I’ve been using Ruby almost exclusively for over a year but the last week I’ve been doing a personal project in Python using Storm (which is pretty nice btw) and urwid. I’m remembering why I liked Python when I first learned it a few years ago. It may not be as elegant as Ruby, conceptually, but it sure is fun to code in. It really is executable pseudo-code for the most part.

I’m tripping up by typing obj.setattr^W^Wsetattr(obj and def self.foo^W^Wfoo(self but other than that I haven’t had trouble switching back into Python. I enjoy omitting end statements. I enjoy Python’s lack of curly braces, apart from literal dicts. I hate the fact that in Emacs, in python-mode, indent-region only seems to piss me off (or indent-* really, anything except TAB). I really like list comprehensions.

The two languages are so similar that at a glance you may think there are only shallow differences between the languages. People are always busy arguing about the boring things that every language can do (web frameworks anyone?) while ignoring the interesting differences between the languages and their corresponding ecosystems.

Python has more libraries available as it’s the more popular language. The nature of software written in the languages is different though as the languages themselves are quite different.

Ruby has some Perl-ish features that make it a good sysadmin scripting language, hence we see nice tools such as Capistrano and god written in Ruby and used by projects written in other languages.

Python is faster than Ruby so it is open to classes of software that would be cumbersome in Ruby. Source control, for example. You can write a slow SCM in Python though, as Bazaar demonstrates. You could probably write a passable one in Ruby as well. If it didn’t quite perform well enough right now it should fare better in a year’s time.

I still think that my overall joy is greater when using Ruby, but if Ruby isn’t the right tool for the job I’ll probably look to Python next (unless some feature of the problem indicates something else would be more appropriate). The reason I chose Python for my current project is because of libs like urwid and I needed an excuse to try out Storm and brush up on my Python. ;-)

While coding just now I had a small epiphany about Ruby. Though Ruby is highly dynamic and compiled at runtime, that doesn’t preclude one catching some mistakes at compile time. I’m not talking about mere syntax errors or anything either. The only proviso to catching mistakes at compile time is that you must have a decent chunk of code executed during compilation. One benefit of Ruby’s blurring of compile time and runtime is that you can run real code at compile time. This is largely how metaprogramming tricks are pulled off elegantly and with ease in projects such as Rails.

Sure you won’t get all the benefits of a strictly and/or statically typed compiler, but you can get some of them. If you have a library that makes substantial use of executing code at compile time then the mere act of loading your library causes your code to run, thus it compiles. If you require your lib and get true back then you know the code that bootstraps the runtime code is at least partially correct.

Compile time is runtime. Runtime is compile time. Just because you have to run the code to compile it doesn’t mean you can’t catch a good chunk of compiler errors before you send out your code. Tests will always be there for the rest of your mistakes, but if you can pull work into compile time then Ruby’s compiler can augment your regular testing practices.

I admit that this is of limited use most of the time, but let it not be said that you can’t catch any errors with your compiler just because you have to run your code to compile it. With Ruby the more meta you get the more the compiler rewards you.

[Of course this is true of languages such as Common Lisp too, which make available the full programming language at compile time. I just happened to be using Ruby when I realized this.]

I cannot wait to try out RushCheck. It is QuickCheck for Ruby. I don’t have experience with QuickCheck or anything but it’s clear to see how this helps you make certain your code is robust.

I was using Amarok’s global keyboard shortcuts to control the volume of my music via the keyboard but I wanted to control the system volume as well. A quick script later and now I can control both, and thanks to libnotify I get some feedback on what happened. It’s not as pretty as OS X’s volume control or Growl but it’ll certainly do.

↓ Download volume.rb

I save this as ~/bin/volume and call it thusly: volume + and volume -. I bind Alt-+ and Alt—to those in my fluxbox config. If you don’t have a preferred key binding program I recommend trying xbindkeys. apt-get install, emerge, paludis -i, or rpm -i as needed.

Some cool Ruby and [the former on] Rails things are springing up and I haven’t written much about the two Rs lately, though I work with them daily.

Rails on Rules

My friend Jim Roepcke is researching and implementing a plugin/framework designed to work with Rails called Rails on Rules. His inspiration is the rule system from WebObjects’ Direct to Web. He posted a good example for me, but this baby isn’t just for template/view logic. If some of the Rails conventions were specified in a default set of rules which the developer could further customize then you basically have a nice way of doing things that you would otherwise code by hand. I think it would be a boon for the ActiveScaffold project. We’re meeting up to talk about this soon and I’ll have more to say after then, but it sounds pretty cool.

Sake Bomb!

I’ve noticed a trend among some recent posts about Rake: the authors keep talking about booze. Are we nothing but a bunch of booze hounds?! Well one can hope. There’s some motivation to learn more about a tool, having more time to drink after work. This week Chris Wanstrath dropped a Sake Bomb on the Ruby community. Like piston, sake is something you can just pick up and use instantly. Interestingly the different pronunciations of rake and sake help me from confusing the two on the command line… so far.

Secure Associations (for Rails)

Jordan McKible released the secure_associations plugin. It lets you protect your models’ *_id attributes from mass-assignment via belongs_to_protected and has_many_protected. It’s a mild enhancement, but an enhancement nonetheless. This is useful to enough people that it should be in Rails proper.

Regular expressions and strings with embedded objects

taw taught me a new technique for simplifying regular expressions by transforming the text in a reversible manner. In one example he replaced literal strings in SQL – which are easily parsed via a regex – with what he calls embedded objects. They’re just tokens to identify the temporarily removed strings, but the important thing is that they don’t interfere with the regexes that operate on the other parts of the SQL, which would have been very difficult to get right with the strings inside it. If I made it sound complicated just read the post, he explains it well.

If you believe anything Steve Yegge says then that last regex trick may come in handy for Q&D parsing in any language, be it Ruby, NBL, or whataver.

If you drink the Rails koolaid you may have read the notorious single layer of cleverness post by DHH. [5th post on the archive page] In a nutshell he states that it’s better to have a single point of cleverness when it comes to business logic. The reasons for this include staying agile, staying in Ruby all the time, and being able to switch the back-end DB at any time. Put the logic in ActiveRecord and use the DB as a dumb data store, that is the Rails way. It’s simple. It works. You don’t need to be a DBA to be a Rails developer.

Stephen created a Rails plugin called dependent-raise which imitates a foreign key constraint inside of Rails. I want to try this out because I believe that data integrity is fairly important, but it’s really starting to make me think about this single point of cleverness idea.

Are we not reinventing the wheel by employing methods such as this in our code? Capable DBs already do this sort of thing for us. I don’t necessarily think it’s bad to implement this sort of thing, but I think it’s a symptom of NIH syndrome. Instead of reinventing this kind of thing why don’t we embrace the DB as a semi-intelligent data store? The work has been done all we have to do is exploit it via Rails.

There are a few reasons that the Rails folks choose not to do so but perhaps some of them could be worked around. Adapting your solution as you progress and realise that things aren’t exactly as you thought they were… I believe the word for that sort of thing is agility.

Database agnosticism

From SQLite to Oracle, just configure the connection, migrate, and run your app on any database. One of the biggest Rails myths that is backed by the Rails team themselves. It takes a fair amount of work to ensure that any significant app is fully agnostic. Sure you can develop on SQLite and deploy on MySQL without much trouble but there are significant diffirences between RDBMSs that will manifest themselves if you create an app that’s more than a toy. Oh, you used finder_sql? Sorry but chances are your app is no longer DB agnostic. FAIL.

Solution: Drop the lie. Tell people the truth. Theoretically, theory and practice are the same; in practice they are not. Be honest that it’s possible to be DB-agnostic but can be a challenge. Under no circumstances should we shun something useful in the name of claiming to be DB-agnostic.

Staying agile

If we start making use of FK constraints then we’ll have to make changes to both our DB and our code. This makes change more time-consuming and error-prone which means change is less likely to happen. This goes against the grain of an agile methodology. Or does it?

Solution: Rails should use the features of the DB to keep data intact and fall back on an AR-only solution only if the DB doesn’t support the operation. There doesn’t need to be any duplication in logic rules either. If Rails could recognise a FK constraint that cascades on delete it could set up the has_many :foos, :dependent => :destroy relation for us. In fact I only see our code becoming DRYer (maybe even too DRY[1]).

Staying in Ruby

Using the DB from within Ruby is a solved problem. I don’t see why this couldn’t be extended to handle more of the DB as well. Use Ruby, but use it intelligently by embracing outside tools to get the job done.

Many relationships could be derived from constraints as people have pointed out before. There are benefits to using the features of a decent RDBMS, and in some cases I think that we might be losing by not making use of them. I am not saying we should move everything to the DB, I am saying that we should exploit the implemented and debugged capabilities of our RDBMSs the best we can while practicing the agile methods we know and love, all from within Ruby.

[1] I make liberal use of annotate_models as it is.

I wanted a method analogous to Prototype’s pluck and invoke in Rails for building lists for options_for_select. Yes, I know about options_from_collection_for_select.

I wanted something more general that I can use anywhere – not just in Rails – so I wrote one. In a second I’ll introduce Enumerable#pluck, but first we need some other methods to help implement it nicely.

First you need Symbol#to_proc, which shouldn’t need an introduction. If you’re using Rails you have this already.

1
2
3
4
5
6
7
8
9
10
11

class Symbol
  # Turns a symbol into a proc.
  #
  # Example:
  #   # The same as people.map { |p| p.birthdate }
  #   people.map(&:birthdate)
  #
  def to_proc
    Proc.new {|thing, *args| thing.send(self, *args)}
  end
end

Next we define String#to_proc, which is nearly identical to the Array#to_proc method I previously wrote about.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class String
  # Turns a string into a proc.
  #
  # Example:
  #   # The same as people.map { |p| p.birthdate.year }
  #   people.map(&'birthdate.year')
  #
  def to_proc
    Proc.new do |*args|
      split('.').inject(args.shift) do |thing, msg|
        thing = thing.send(msg.to_sym, *args)
      end
    end
  end
end

Finally there’s Enumerable#to_proc which returns a proc that passes its parameter through each of its members and collects their results. It’s easier to explain by example.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

module Enumerable
  # Effectively treats itself as a list of transformations, and returns a proc
  # which maps values to a list of the results of applying each transformation
  # in that list to the value.
  #
  # Example:
  #   # The same as people.map { |p| [p.birthdate, p.email] }
  #   people.map(&[:birthdate, :email])
  #
  def to_proc
    @procs ||= map(&:to_proc)
    Proc.new do |thing, *args|
      @procs.map do |proc|
        proc.call(thing, *args)
      end
    end
  end
end

Here’s the cool part, Enumerable#pluck for Ruby in all its glory.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

module Enumerable
  # Use this to pluck values from objects, especially useful for ActiveRecord models.
  # This is analogous to Prototype's Enumerable.pluck method but more powerful.
  #
  # You can pluck values simply, like so:
  #   >> people.pluck(:last_name)  #=> ['Samhuri', 'Jones', ...]
  #
  # But with Symbol#to_proc defined this is effectively the same as:
  #   >> people.map(&:last_name)   #=> ['Samhuri', 'Jones', ...]
  #
  # Where pluck's power becomes evident is when you want to do something like:
  #   >> people.pluck(:name, :address, :phone)
  #        #=> [['Johnny Canuck', '123 Maple Lane', '416-555-124'], ...]
  #
  # Instead of:
  #   >> people.map { |p| [p.name, p.address, p.phone] }
  #
  #   # map each person to: [person.country.code, person.id]
  #   >> people.pluck('country.code', :id)
  #        #=> [['US', 1], ['CA', 2], ...]
  #
  def pluck(*args)
    # Thanks to Symbol#to_proc, Enumerable#to_proc and String#to_proc this Just Works(tm)
    map(&args)
  end
end

I wrote another version without using the various #to_proc methods so as to work with a standard Ruby while only patching 1 module.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

module Enumerable
  # A version of pluck which doesn't require any to_proc methods.
  def pluck(*args)
    procs = args.map do |msgs|
      # always operate on lists of messages
      if String === msgs
        msgs = msgs.split('.').map {|a| a.to_sym} # allow 'country.code'
      elsif !(Enumerable === msgs)
        msgs = [msgs]
      end
      Proc.new do |orig|
        msgs.inject(orig) { |thing, msg| thing = thing.send(msg) }
      end
    end
    
    if procs.size == 1
      map(&procs.first)
    else
      map do |thing|
        procs.map { |proc| proc.call(thing) }
      end
    end
  end
end

It’s just icing on the cake considering Ruby’s convenient block syntax, but there it is. Do with it what you will. You can change or extend any of these to support drilling down into hashes quite easily too.

Update #1: Fixed a potential performance issue in Enumerable#to_proc by saving the results of to_proc in @procs.

Suddenly I feel the urge to try out Solaris for i386 again. Last time I gave it a shot was when it was first released, and all I ever got out of the CD was a white screen. It’s been 2-3 years since then and it should be well-tested. I’ll try to install it into a VM first using the ISO and potentially save myself a CD. (I don’t even think I have blank CDs lying around anymore, only DVDs.)

The culprit.

By now many Ruby programmers are familiar with the magic that is Symbol#to_proc.

If you haven’t seen anything such as youngest = people.map(&:age).min yet here’s a quick explanation of the syntax.

• Ruby calls to_proc on the block parameter if it is not already a Proc. (coercion)
• Since a symbol is a message, Symbol#to_proc simply constructs a block that sends self (the symbol) to the first block parameter.
• The code above is equivalent to youngest = people.map { |p| p.age }.min
• The few characters saved are significant if you are sufficiently lazy, or if you frequently chain short blocks like that together.

This is a great way to clean up your code, and the brevity will have you groaning when you have to type out something such as: birth_years = people.map { |p| p.birthdate.year }

But there is a simple way to make that shorter using a trick similar to Symbol#to_proc. To me it seems logical that if map(&:sym) sends :sym to each element of the enumerable object, then an array of symbols should chain the calls together on each element of the enumerable.

If you’ve looked at the implementation of Symbol#to_proc in Rails then this should look familiar as it’s nearly the same code.

1
2
3
4
5
6
7
8
9
10
11

module ArrayExtensions
  # Turns an array of symbols into a simple proc, which is especially useful for enumerations. Examples:
  #
  #   # The same as people.map { |p| p.birthdate.year }
  #   people.map(&[:birthdate, :year])
  def to_proc
    Proc.new do |*args|
      self.inject(args.shift) { |obj, msg| obj = obj.__send__(msg, *args) }
    end
  end
end

This makes the following code valid, and equivalent to the previous example using birth_years.

birth_years = people.map(&[:birthdate, :year])

You can use strings, like so: birth_years = people.map(&%w[birthdate year]), but I don’t dig the &% part of it. To each their own.

Then all that needs to be done is load the extension. I’m doing all this in the context of Rails so I’m setting this up in my environment.rb.

Array.send(:include, ArrayExtensions)

If you work with Rails then you may be familiar with the dynamic attribute-based finder methods in ActiveRecord::Base. They are class methods used such as User.find_or_initialize_by_name(‘sjs’) or User.find_or_initialize_by_name_and_password(‘sjs’, ‘insanely secure password’). There is also a find_or_create_by_… version.

If you want to do this for many attributes it gets old very, very quickly. This should just accept a hash of attributes like the other ActiveRecord methods we’re used to. 3 methods later and the problem is solved, read on…

Last summer I did some reading about Haskell and read some intros on using it. I never got into it though as I was busy working and learning other things at the time. Today I was reminded about Haskell and decided to really put an effort into learning the basics and coding a few small programs.

Classes in Haskell are very interesting, and fairly different from classes I’m used to in Ruby or Java. One feature about them that struck me as particularly cool is that you can define methods in terms of each other, and if the minimum requirements are met then the others are automatically defined in terms of the provided methods. It’s genius I tell you, but my explanation is lacking so check the linked Wikibook at the beginning of this paragraph to grasp what I’m talking about. When you get back the rest of this should make sense…

The date & time extensions provided by Rails are convenient but they don’t provide anything when it comes to relative dates using weekday names, for example. I’ve been frustrated writing weekday arithmetic so I went in search of something easier. What I found was Chronic!

It’s true. I’m sitting here coding in PHP using the Zend Framework and all I can think about is how much nicer Rails is, or how much easier it is to do [x] in Ruby. It’s not that the Zend Framework is bad or anything, it’s quite nice, but you just can’t match Ruby’s expressiveness in a language like PHP. Add the amazing convenience Rails builds on top of Ruby and that’s a really hard combo to compete with.

I’m a Rails newbie and eager to learn. I welcome any suggestions or criticism you have. You can direct them to my inbox or leave me a comment below.

I finally set myself up with a blog. I mailed my dad the address and mentioned that it was running Typo, which is written in Ruby on Rails. The fact that it is written in Rails was a big factor in my decision. I am currently reading Agile Web Development With Rails and it will be great to use Typo as a learning tool, since I will be modifying my blog anyways regardless of what language it’s written in.

Clearly Rails made an impression on me somehow or I wouldn’t be investing this time on it. But my dad asked me a very good question:

Rails? What is so special about it? I looked at your page and it looks pretty normal to me. I miss the point of this new Rails technique for web development.

It’s unlikely that he was surprised at my lengthy response, but I was. I have been known to write him long messages on topics that interest me. However, I’ve only been learning Rails for two weeks or so. Could I possibly have so much to say about it already? Apparently I do.