Toxic Elephant

Gem for memory_test_fix

Posted by matijs Sun, 27 Jun 2010 21:10:00 GMT

In some of my Rails projects, I have been a contented user of the memory_test_fix plugin. However, I rather dislike the use of Rails plugins, because I find updating them later on rather difficult, and I don’t like including external libraries in my own source tree (hence, I don’t like the practice of vendoring gems much either). When the concept of ‘gem plugins’ was introduced, I created a fork on github and created the necessary files to build the plugin as a gem, and have Rails properly load it.

Somehow I never got around to seeing if all this actually worked. However, recently I revisited an old project that I never quite finished, updated it to Rails 2.3.8, and decided to try replacing the memory_test_fix plugin code it included with a simple call to config.gem. It worked fine.

After incorporating a patch to allow the use of in-memory databases for any environment (use for development and production is of course not recommended), the gem is now at version 0.1.3, and has been pushed to gemcutter.

From the README:

Install the gem:

gem install memory_test_fix

In your config/environments.rb, use:

config.gem 'memory_test_fix'

In your database.yml, use:

test:
  adapter: sqlite3
  database: ":memory:"

It runs much faster!

This makes me the official maintainer of this gem, which may not be ideal in the long run, since I’m not really the main author of this code. Feel free to ask me for access or to contact me to discuss other options.

Posted in software | Tags gem, memory_test_fix, plugin, rails, ruby | no comments | no trackbacks

Creating My Own URL Shortener

Posted by matijs Sun, 11 Apr 2010 12:22:00 GMT

Because URL shortening services can go away at any time, I decided to install my own. In the spirit of your-own-dogfood, and to make hacking it as enjoyable as possible, it had to be in Ruby (this ruled out YOURLS, which otherwise does exactly what I want). There are tons of URL shortening projects in Ruby on GitHub. Unfortunately, they all lacked one feature: password protection for the adding of URLs. In the end, I picked a nice simple one and changed it to my liking. The result can be found in my fork of turl.

Why is this safer than using one of the existing services? The reason tr.im went under is that they couldn't make it pay for itself, and there was a lot of abuse from spammers. Both problems are absent for my own service: I don't need to make any money off of it, and I'm the only one who can create new short URLs.

Some observations on developing this software:

• For a small project like this, putting everything in one file is very, very nice. Ramaze allows you to do this (as do other frameworks), Ruby on Rails does not. I wonder how seamless the transition is if your project starts small like this and then gradually becomes big enough that you need to split it into different files.

• Ramaze's documentation needs some love. Everything is documented well in principle, but with the split-off of the innate library, it took me ages to find the documentation for the a method and friends.

• I really like the idea of [Sequel][sq]::Model where you define the table schema right in the model. I'm not sure how or how well it works with migrations, but for a small project like this, it's nice and clean.

• Ramaze could use some more options for session storage. In particular, something file-based shouldn't be too much to ask for. I'm using the LocalMemCache option, and keep having to log in.

I really like Ramaze, and am eager to try Sinatra. I have been ignoring these more light-weight frameworks for far too long.

Posted in software, web | Tags ramaze, ruby, shorten | no comments | no trackbacks

The Arc Challenge

Posted by matijs Sun, 17 Feb 2008 21:14:00 GMT

Hm, so Arc is here, and Paul Graham gives the Arc challenge. The answer in Arc is short indeed. First, let’s see an answer in Rails (loading a framework is allowed according to the challenge), with said_controller.rb:

class SaidController < ApplicationController
  def index; end
  def click; session[:it] = params['what']; end
  def show; end
end

and some templates, for the first page, index.html.erb:

<% form_tag '/said/click' do %>
  <%= text_field_tag 'what' %>
  <%= submit_tag %>
<% end %>

second page, click.html.erb:

<%= link_to 'click here', {:action => 'show'} %>

third page, show.html.erb:

You said <%= session[:it] %>

The Rails answer may be a little longer (although by how much is hard to say due to the different syntax — is end a token?), but it not a case of the same but longer.

First, the Rails version is in temporal order, the Arc version is not. Perhaps there’s a way of reading the Arc version that makes this order natural, but right now, it looks confusing.

But the most striking difference is that it is based on a completely different philosophy of how web applications should be developed. The Arc answer is great if you want a web application based on continuations. The Rails answer is what you would use if you want to use REST.

I’m definitely in the REST camp, which makes this example meaningless as a demonstration of Arc. It shows me that Arc can be used to write a short program that does something I don’t want to do.

The ultimate question of course is whether brevity (in terms of number of tokens, not characters) is the single best metric for language power.

Update: Someone wrote a Ruby version that is about as short as the Arc version, uses the same paradigm, and is in temporal order:

def said
  aform(input("foo"), submit) {
    w_link("click here") {
      "you said: #{arg :foo}"}}
end

Posted in software | Tags arc, continuations, design, language, rest, ruby | 2 comments | no trackbacks

Undressed Ruby

Posted by matijs Sun, 14 Oct 2007 12:14:00 GMT

In Ruby, there is really no compile time. There is parse time, and then there is run time. All class and method definitions are done at run time.

  class Foo
    def bar
      puts "Zoo!"
    end
  end

is basically¹:

  Foo = Class.new do
    self.define_method(:bar) do
      puts "Zoo!"
    end
  end

See, we just removed the class and def keywords from Ruby. What else? Ah yes, method calls. That’s just sending messages. In fact, you can replace any method call foo.bar with foo.send(:bar), like so²:

  Foo = Class.send(:new) do
    self.send(:define_method, :bar) do
      self.send(:puts, "Zoo!")
    end
  end

How much syntax can you remove like this? How far can Ruby be undressed? And can you come up with a macro system to put the clothes back on?

Some ingredients: Why list macros are cool, RubyToRuby.

¹ Actually, it’s not the same, since the define_method way creates a closure, so you can do like this

² Yes, I know I’m using method call syntax here. But this way I do expose the message-passing view on OO that Ruby has. If you want, you can replace it with send_message(object, method, *args), and assume Ruby defines send_message somewhere.

Posted in software | Tags macros, ruby | no comments | no trackbacks

A DSL for making SQL-like DSLs

Posted by matijs Sat, 14 Apr 2007 14:42:00 GMT

Setting the stage

Some time ago, I came across SQLDSL, a DSL for building SQL queries. The benefit of using a DSL over plain old string concatenation is that syntax is checked before the database server is hit. Unfortunately, SQLDSL does not deliver. It will happily accept

  q = Insert.into["frot"]["zop"]["blob"].values("kng").values["kgn"]

resulting in

  q.to_sql
  # => "insert into 'frot' (zop) (blob) values ('kng') values () (kgn)"

which is hardly acceptable SQL.

Posted in software | Tags dsl, metaprogramming, ruby, sql | no comments | no trackbacks

I Want Cells-GTK for Ruby

Posted by matijs Mon, 22 Jan 2007 13:21:00 GMT

For some applications, a spreadsheet is the perfect development environment. The UI is a no-brainer, while the relations between the different values is clearly visible, and changes are automatically propagated from what could be called properties to derived values.

The problem is, of course, that you’re missing out on the features a programming language could offer. Macros are basically a dead end, unless you like to solve user issues like ‘It doesn’t work because I disabled all macros.’

What I want is something that gives me this easy linking within a model and between model and UI, but from withing Ruby. It is my prefered solution to the Gnome on Rails problem.

Cells for Common Lisp promises to take care of the automatic propagation and dependencies between cells:

Cells is a mature, stable extension to CLOS that allows you to create classes, the instances of which have slots whose values are determined by a formula. Think of the slots as cells in a spreadsheet (get it?), and you’ve got the right idea. You can use any arbitrary Common Lisp expression to specify the value of a cell. The Cells system takes care of tracking dependencies among cells, and propagating values.

That seems to take care of the automatic updating of derived values. The second part is the no-brain-UI. What’s needed for that is a dead-simple way to link settable values to input widgets (text boxes, spin buttons, etc.), and to link derived cell values to labels. By dead-simple I mean that it should be done in at most one line per widget/value pair.

It seems for that part, the solution would be to use cells-gtk:

Cells transparently link GUI elements with each other and the application model to greatly simplify development of rich interfaces. Cells also automate how Lisp GUI instances drive their GTK+ counterparts.

Sounds great!

The problem (for me at least) is that this is all in Lisp, and I don’t know Lisp yet. So, I want this, but in Ruby (since that’s the language I like to use most right now). Some basic ingredients are already there: We can use blocks as formulas for the derived values, and there’s the Observable module. Also, Ruby has bindings for Gtk+.

I have some more wishes, but they’re mostly about Gtk+, so I leave those till later.

Posted in software | Tags lisp, ruby | no comments | no trackbacks

Skipping Python for Ruby

Posted by matijs Thu, 18 Jan 2007 18:59:00 GMT

Without an e writes

Well, ruby just isn’t that much better than python. If I’m going to relearn everything, why would I bother with ruby? Why not just jump straight to lisp?

I can really appreciate this argument, since it resonates with my reasons for not learning Python: I knew Perl, and was doing most of my programming in it, making nicely structured, readable, object-oriented programs. To me, Python didn’t seem like such a big step forward: It’s like a Perl with enforced readability.

And then came Ruby.

My introduction to Ruby was not through Rails, but through reading the online version of the Pickaxe Book. After reading the first chapter, I was sold. Here was a language that truly embraced object-orientation, and gave access to all kinds of interesting abstractions that I had only vaguely heard of (such as coroutines). There also was a pleasant lack of boilerplate.

So to me, Ruby is that much better than Perl, whereas Python is not. I wouldn’t know if I agree that Ruby is not that much better than Python, but at least I can understand the argument. Ruby is certainly no Lisp, although it comes close.

So what’s next? Lisp’s features certainly look appealing, giving basically the pinnacle of power of abstraction, in exchange for slightly unappealing syntax. I believe the syntax can be overcome, so my next language to learn may well be a Lisp. Which Lisp is still an open question. On the other hand, there are interesting languages like Erlang, ML and the like.

[Incidentally, Without an e is the creator of Scarlet Lambda, which is roughly a web framework written in, or at least used with, a functional style of programming in Python, with a Lisp-like syntax. Wow.]

Posted in software | Tags lisp, programming, python, ruby | no comments | no trackbacks