Category Archives: Programming

I managed to compile ruby-mysql

I’m using MySQL Ver 14.12 Distrib 5.0.21 for Win32 (ia32), mysql-ruby 2.7.6, msys 1.0, gcc 3.4.5.

It took a bit of googling before I stumbled across this link.

This link prompted me to peek at extconf.rb. I quickly realized that the script was unable to recognize my platform. It was expecting windows to be mswin32, whereas my compiler was reporting i386-mingw32. That’s on line 3, which says:
if /mswin32/ =~ RUBY_PLATFORM

I modified it to:
if /i386-mingw32/ =~ RUBY_PLATFORM

I invoked the script using:
ruby extconf.rb –with-mysql-lib=”C:\Program Files\MySQL\MySQL Server 5.0\lib\opt” –with-mysql-include=”C:\Program Files\MySQL\MySQL Server 5.0\include”
make install

All went well, and a mysql database script on my machine worked!


Conversational Ruby

I often use Ruby to open conversations:
* It’s easy to write short, quick Ruby code that works,
* It’s readable enough even for new people,
* It’s easy enough to pick up that new people can take my code and run with it,
* It’s expressive,
* It’s fun to write code in.

Eggshell of idioms

It is hard, but rewarding, to shine light on idioms. This has been my experience.

When I introduce someone to Ruby, I usually show off Ruby’s more flashy aspects, and compare it with the equivalent in Java, C# or C. Ruby’s approach to iteration never fails to evoke a response. I also show how Ruby’s various list-friendly methods can be chained together, with powerful results. People respond well to this demo. And why not. Ruby is cool!

Then I get into classes and methods. The brevity is refreshing, of course. But Ruby doesn’t have interfaces. And much popular object oriented thought today took root in statically typed languages such as C++, C# and Java. So when I’m done showing off Ruby’s classes, my subject takes the next logical step, and asks for Ruby’s take on interfaces.

But interfaces do not have to be in every language that has classes. This is the part where I can get quite verbose. It takes me time to explain dynamic dispatch, and the absence of interfaces. Why a duck can be a bird without implementing IBird, and indeed why IBird doesn’t have to exist.

The idiom here is the way that method dispatch works in well known statically typed languages.

There is an eggshell of static typing idioms that surrounds static typing languages. It includes approaches to inheritance, interfaces, iteration. Understanding Ruby forces the enquirer to question the eggshell of idioms, and break out of it.

Emacs and Lisp

I enjoyed reading this report on Lisp | Emacs: Advanced Codemunging: A Report from the Trenches

The ideal requirement to code ratio

Requirement:code as 1:1

As a software developer, I have often fallen into the trap of trying to design a “powerful” framework that satisfies all my wants. I would often end up trying to solve food, clothing and shelter, when what I really needed was a simple templating system.

But in any software project, the requirement to code ratio must be 1:1, only as much code to satisfy the requirement as absolutely necessary.

With this sudden clarity has come resolution. Frameworkitis no more.

Read about the state of the Ruby VMs

The Impending Ruby Fracture is an interesting read on the state of the Ruby virtual machines. The comments are equally interesting, since they complete the perspective.


I’ve recently read a piece about the JSON vs XML debate on Dare Obasanjo’s blog.

From my readings, I think that many folks are missing the point about why JSON sprang up and became popular. In this I agree with Obasanjo. But I opine that the point goes deeper than the eco system. Let me recap what I understand of the history of JSON till date:

  • First, they discovered that it was easy to deserialize javascript objects in javascript.
  • The good news spread. Before long, the new format gathered enough momentum, and it was named JSON, which standard for Javascript Object Notation.
  • People thought about it, and those using XML were too blinded by it’s inertia to see any use in JSON. Hence,the JSON vs XML format debate.
  • Security conscious folks realized that the advantage of JSON brought with it security risks. So someone went ahead and built a library to parse JSON in Javascript.

And with that, JSONs advantage of deserialization is gone.

JSON is great for deserializing data received by a browser. But we must coldly consider whether serialized javascript objects will help our applications transmit data to eachother. Coldly, because the debate isn’t quite done, it’s easy to get swept into, and for now there’s no need for it.

Update: I do not mean to imply that the JSON advantage is lost. Rather, my argument is that JSONs advantage may not be universal to all platforms, and it should not be considered the default choice for any application.