Archive for the 'Programming' Category

Playing around with XSLT

Published on January 19, 2009 in Hacking and Programming. 0 Comments Tags: , , , , , .

I recently wanted to have a view of twitter with friends organized into groups the way TweetDeck has it (or at least I suppose it’s the way it has it, as it doesn’t work on linux). So I thought it was a cool project to learn some XSLT. XSLT is basically an XML language for turning an XML document into something else, which can also be XML. As that was exactly what i wanted to do, using the language that was written specifically for that purpose (like a DSL) should make the task very easy and fast. The files to be transformed by the XSL file would be the raw twitter feed and a groups file in which I’d specify the groups that I wanted to display. The XSL would create an XHTML document with the tweets organized into groups depending on the person they came from. It was really fast and the result was mostly what I wanted. I’ve posted the code on github.

If you want to use it you need to create an xml folder and create in there a file named current.xml with the XML from twitter that you want to organize and groups.xml with the following structure:

<groups>
  <group name="Test">
    <user>username</user>
  </group>
</groups>

One group entry per group and one user entry per user in group. That should be it, if you browse to the index.xml file in the main directory you should then get a visualisation of the grouped tweets along with a row in the top of the document with buttons that toggle each group (with some jquery hiding goodness and some quick css):

Also in the repo are merge, count and “id of the first tweet” xsl files that I used to do a simple batch script that updates the feed (using curl and Xalan to fetch 200 updates at a time until there are no more updates to fetch merging it all in the current.xml). It is all very raw and quickly put together at the moment, but in the future I might add more features and make it into a client. However, I hope this might help someone to get into XSLT. I found it to be very interesting and quite powerful and look forward to using it in the future.

Opening up the borders
(or, how I learned to stop worrying and love the FFI)

Published on December 18, 2008 in Programming. 2 Comments Tags: , , , , , .

I thought I’d write about something that I feel people are a bit too scared of doing, which is binding a foreign library into their favourite language. We all have our own strange favourite language in which programming comes out more naturally, faster and more correctly. However, I sometimes found myself hitting bumps when I wanted to use a certain awesome library that is programmed in a different language, and usually compiled to native binary libraries.

The usual approach is to search for bindings existing for the language, and usually there will already have been someone who made the bindings, neatly packaged them and released them for you to use. The problem occurs when there are no such bindings available, which happens more frequently for less mainstream languages (like my beloved Common Lisp). Sometimes there are some incomplete bindings that someone posted, which don’t cover all the cases. However bindings are fairly easy to do, even though they are not that easy to structure properly.

In fact, invoking and getting values back is the easier part, usually you just use some built-in construct to invoke the native procedure, and the FFI takes care of the low-level bindings, and sometimes even memory management. However, in order to feel like it is part of the language, we have to build the proper abstractions around the native calls that make it feel idiomatic. For instance, in the case of Haskell, care has to be taken to properly handle side effects, and create a pure, referentially transparent haskell function.

To make it easier, for the direct bindings one can use wrapper generators like swig. These usually consume a header file and produce a language file full of the direct wrappings of the native functions. Then, using these functions one can use the higher-level features of the language and encapsulate it in the way that we feel a library for that purpose in the target language must be like. In the end, we end up with a library that feels natural in the target language and as long as we took the relevant precautions, has all the characteristics of the language that we love.

That is all. So, next time you find yourself thinking “why doesn’t <language here> have bindings for <library here>? <other language here> has them!” don’t ignore the possibility of building the bindings. It is not as hard as it looks (and way more fun than it sounds!), and if you get them completely right and idiomatic you can even help people by publishing them.