Web mashups

Posted in Rails, Ruby by sausheong on April 30, 2006

According to Wikipedia, “A mashup is a website or web application that seamlessly combines content from more than one source into an integrated experience.” More popularly what it means is that you take content, data or query results from various Internet web applications such as Google Maps, Yahoo Flickr, etc. and put them all together into a single web application that provides a service that is not available from any of the source services. It’s a synergistic approach to building applications that uses existing applications as building blocks. Some call it web application hybrid, but I personally think it’s more than that. ‘Hybrid’ gives an impression that it’s just a sum of the individual (web applications) but I think mashups have much greater potential than being a ‘glue’ for web applications. It’s not 1 + 1 + 1 = 3, it’s more like (or should be) 1 + 1 + 1 = 10.

A typical simple mashup should be something like this :-

  1. Take the job search results from APIs (say of jobs relating to ‘Ruby on Rails’)
  2. Using the information results, map the jobs’ locations using Google Map APIs
  3. At each location, show the company that is returned, and latest news on the company using Yahoo Web Search Service

At a basic level this service is not something that is provided by any of the web applications individually (though Yahoo comes close) and this is a simplistic mashup anyway. With more advanced services being added continually on the Internet every day, we could continually enhance this in a way that might not be anticipated by the original service providers.

I used to do ‘mashups’ during my days with elipva, though at that point in time we didn’t call it that. We had the dotcom names for them then — things like portal, personalization and content aggregation, using technology like screen-scraping, iframes and such. Names seem to have changed, but the ideas have evolved but strangely persisted.

Maybe good ideas stick around? Or we never learn from our ‘failures’? I would rather be more optimistic on this. In any case, I still love a good mashup, and I still love coding them, whatever they’re called.

Over the next few weeks/months (depending on how much free time I have) I’ll try to implement the simple job search mashup I just described above, and will describe how it can be done, step-by-step. The technology used? Ruby on Rails, of course. Stick this page in a bookmark somwhere if you want to see how I do it.

CardsAsia::Payment World 2006

Posted in payment & banking by sausheong on April 26, 2006

Was at the CardsAsia today, some pretty interesting topics discussed during the conference. The exhibition was disappointing though — it was much smaller than I thought, and there were practically no terminal vendors or card vendors. Ingenico, Hypercom, Verifone etc were all missing, Gemplus, Axalto, G&D, Obethur weren’t there at all.

The conference items were an eye opener though. More in another post. In the meantime, took a snapshot of the Asian payment bootcamp session, which had Aneace as a moderator.

Nintendo DS Lite!

Posted in general by sausheong on April 23, 2006

I bought an NDS Lite (light blue) yesterday! Also bought the ‘Age of Empire: Age of Kings’ game, cost me bomb — S$410, but worth every cent! Amazing little game gadget, with touch screen, dual screen, great user interface, built-in wifi. I cannot believe how much good stuff Nintendo managed to cram into something so small!

Projectible in alpha

Posted in general, Rails, Ruby by sausheong on April 23, 2006

I’ve wrapped up on the broad strokes on Projectible, finally! This is something I’ve been doing on and off for the past few weeks. Originally a subset of Beehive’s massive set of new features, I never really thought how much real work it took to get a publicly available web application ready for even semi ‘production’ use. Real lessons learnt here on deploying a live Rails application.

Well, what is Projectible? Projectible is an online project management and publication tool, that focuses on an important feature that not many online web project management do — to publish MS Project plan files. Yes, that’s right — Projectible can take a MS Project plan you have and push it to the server, but you’ll need to use a small client application to do this. Besides this, everything else is like any other online project management and publication tool, but I believe this is a crucial feature. MS Project is used by almost everyone I know who manages a project professionally yet most people ignore this and goes on to repeat what MS Project does, online!

So how does it compete with Microsoft’s own Project Server? There isn’t any real competition though — MS Project Server is not avaiable publicly and requires someone to host and maintain it, so it’s often out of question for many except for larger enterprises. Besides MS Project Server is not easy to use or maintain (I know — I use it in Welcome), and it is a bandwidth hog — it’s deployment guide states flatly that it requires 10Mbps to run it normally. It’s not really meant for Internet use though you can do it.

How about other online project management tools like the venerable Basecamp, the original web application which Rails is extracted from? Well, Basecamp is a great tool, but it mainly focuses on basic project management features and for people who are used to MS Project the interface isn’t really that familiar. Besides, Projectible’s main focus is publication of MS Project plan files, something which Basecamp is not into.

Of course, Basecamp and other tools have been around for a while, and I’ve just started Projectible :)

Try it out at !

I’ve also moved all blogs to do with Projectible to

Evolutionary Algorithms and Genetic Programming [4]

Posted in general by sausheong on April 14, 2006

The Mechanics of Genetic Programming

Having gone through the necessary background, let’s go into the actual mechanics of how genetic programming works. The basic mechanics of GP are very similar to those of genetic algorithms (of which GP is really an offshoot). The algorithm for GP can be summarized as:

  1. Randomly generate an initial population P.
  2. Repeat the following sub-steps until an acceptable solution is found or the maximum number of generations is reached:
    • Execute each program in the population and assign it a fitness value indicating how good a solution to the problem it is.
    • Create a new population by selecting members with a bias towards the fitter programs, and then applying crossover and mutation to produce new P.
  3. The program found to give the best solution to the problem is designated as the result of this run of genetic programming.

For any particular problem it is necessary to specify the list of functions and terminals that shall be used to create the P. These in effect constitute the language to be used to solve the problem. The terminals will form the leaf nodes of each tree, since they take no arguments, and the functions will form all other nodes – having one branch for each argument they require.
So for example, lets say we are attempting to solve a problem which requires finding a boolean function that takes the input from three data lines and returns true if an even number of them are true and false otherwise (the even-3-parity rule). We might use the terminal set:

T = { A, B, C }

And the function set:

F = { AND, OR, NOT }

How do we produce the random trees in the initial population? How do we perform crossover and mutation on them later on during reproduction?


Creating random trees is easily done by a recursive process:

  1. For the root node select a random primitive from the combined set of functions and terminals.
  2. If a terminal is selected the process ends there.
  3. Otherwise for each of the functions arguments produce a random sub-tree by repeating the same process.

Figure 3 : Randomly created program trees

In practice it is necessary to set a limit on the size to which the tree can grow by only selecting from the list of terminals after reaching a certain depth. Also, since trees consisting of only a single terminal are not likely to be very interesting they are usually excluded by forcing the choice of primitive at the root of the tree to be a function.


Crossover is the random exchange of genetic material between two parents to produce a unique offspring. In GP this is easily done by selecting a random sub-tree from within each of the parent trees, and then swapping them over. For example:

Figure 4 : Recombination/Crossover

(a) and (b) are the parents. Subtree 1 and subtree 2 are the randomly selected sub-trees. After the sub-trees have been swapped (c) and (d) are the resulting children.


Mutation is random changes to the genetic material of a single individual. In GP this is again easily performed by deleting a randomly chosen sub-tree and replacing it with a newly created one. For example:

Figure 5 : Mutation

The program tree is now mutated. The original sub-tree is removed and replaced by a new subtree (which has been randomly generated) to produce the final program tree.


Get every new post delivered to your Inbox.

Join 454 other followers