Why they do Python…

Found this nugget while reading blogs this morning: Python Experts – Why They Do Python

In the article they ask “What do you think is the most important feature of the Python language?” I’m surprised that the fact that white space is part of the language leading to more readable code was one of the strengths. When I first learned Python I hated the white space being part of the syntax. Coming from Java it seemed unnatural. But after a while it’s a wonderful thing. It makes the code easier to read, I’ve become very fond of it.

My favorite response to the question was by Tim:

It’s pragmatic nature.. It doesn’t try to be the coolest or most flexible or most ‘enterprisey’. It gives the programmer a very predictable framework in which to ply their skills. In short it doesn’t dictate or get in the way but does gently suggest that you could do better…

If you haven’t played with Python, I urge you to give it a try. It’s best to pick a project and try to do it in Python. You’ll have to do more than one because at first the frustration will annoy you, especially if you’re coming from Java. But after a bit of coding you’ll wonder why you never moved to Python a long time ago. :)

gnucash

I’m stuck on Quicken 2002 and have thus neglected using it for almost 2 years. We’ve been managing the household finances the old fashioned way by hand and with the help of online banking.

But I wanted to have a bit more control and a better “view” of where the money goes. So I tried using Quicken 2002 in a virtual instance of Windows XP running on VirtualBox. But Quicken 2002 is just a few years out of date! :) And the thought of upgrading it just pains me. So I set out to find financial software for Linux.

I started with GnuCash but I was just completely confused with how it treats categories as accounts. The whole double entry accounting just made my eyes water.

Next up I tried Moneydance. I’ve tried it before when I was using OS/2 but it was too “java-y”. Looked out of place. Well, it still looks way out of place with the ugly Metal look and feel of swing. It was easier to get started than GnuCash as it felt more Quicken-like. But I couldn’t get over how ugly the UI was. I know it shouldn’t be about looks, but it was: rm -rf /opt/moneydance.

I thought, “maybe there’s a webapp out there that does this” which led me to CheckItOut a Ruby on Rails application. CheckItOut uses Mysql to store the data and runs using Webrick. But it was a royal pain in the butt to setup. Ruby, Rails, mysql all installed great. CheckItOut even started with a small change to database.yml. But once it was running creating a new account would cause it an error. I started to try to debug it then realized, screw this if I have to debug the app I can’t trust it to keep track of my finances. So out it went.

Next up? Grisbi. It looked promising. Nice GTK look and feel, pretty decent features as well. But I had a hard time using it. I kept tripping over things. So I moved on, though I left it installed just in case.

Gnofin lost purely because it was an older GTK app. It was just too ugly to even bother. I didn’t even get to the download point.

KMyMoney2 was pretty nice. It had one of the nicer feature sets and felt pretty natural to use. I was up and running in no time. But as you probably guessed I like the GNOME look and feel, and I couldn’t get past the ugly KDE candy toy look: yum remove kmymoney2.

Last up was Kapital was one of the better looking apps, IMO. It was the closest to Quicken out of them all. But it wasn’t open source. So it never got to the download state either.

Wow, I ran out of applications. Well, I actually went back to GnuCash. I remembered what a friend told me “learn your tools”. So I decided to sit down and actually learn GnuCash. After about an hour, I got a pretty good grasp on how it works and it is really a great replacement for Quicken. It has the GNOME look and feel which I love, is open source, handles all the accounts I have, imports from OFX and QIF formats as well.

WINNER: GnuCash!

Greasemonkey

I’m late to the game as Greasemonkey has been around for quite a while. But today I decided to write my own script. I’m using the Neutronium GTK themeand bugzilla.redhat.com had white text on yellow buttons. So I wrote a script to change the colors. It’s not very pretty but it works for me.

// ==UserScript==
// @name            Bugzilla Style
// @namespace       http://zeusville.wordpress.com
// @description     Changes the color of the yellow buttons
// @include         https://bugzilla.redhat.com/*
// @include         http://bugzilla.redhat.com/*
// ==/UserScript==

var element;
var inputs = document.getElementsByTagName('input');
for (var i = 0; i < inputs.length; i++) {
    element = inputs[i];
    if (element.type == 'text' || element.type == 'checkbox' ||
        element.type == 'radio') {

        element.style.background = "#141414";
    }
    else if (element.type == 'submit') {
        element.style.background = "#313131";
    }
}

var elements = document.getElementsByTagName('select');
for (var i = 0; i < elements.length; i++) {
    element = elements[i];
    element.style.background = "#141414";
}

elements = document.getElementsByTagName('textarea');
for (var i = 0; i < elements.length; i++) {
    element = elements[i];
    element.style.background = "#141414";
}

SOAP is dirty!

Contrary to popular belief, SOAP is dirty! When folks talk about web services they immediately think SOAP, which is unfortunate. When I think of a web service I think of system either a web site, a service running in your companies intranet, even a service running on the same machine, that I can send simple messages to and receive responses. The key is SIMPLE messages.

Yes, that’s a rather loose definition. Mail servers probably fall into that definition, but to me that’s a web service. Well not very webby but a service nonetheless. So if SOAP is dirty what else can you use to create web services? Well there’s the venerable XML-RPC which is truly simple unlike SOAP. Most people don’t use XML-RPC because it doesn’t support “objects”, but then again those are overrated too. Seriously folks, you send a message you get back a structure. You really don’t need more than a hash or an array.

Other reasons folks don’t like XML-RPC are that it lacks support for long data types (only supports integers), UTF-8 encoding (makes it hard to use for internationalization), and doesn’t have the concept of null. Those are all valid reasons, but a lot of times you don’t need that stuff in which case it’s still better to use XML-RPC rather than SOAP. The ease of development and ease of use from an api users point of view out weighs a lot of those things. XML-RPC is also trivial to understand. The specification is easy to digest: http://www.xmlrpc.com/spec. Compare that to the monstrosity of the SOAP spec. There still quite a few application that use XML-RPC as an API: smugmug.com, func, Red Hat Network, and flickr.

If the limitations of XML-RPC truly are deal breakers for you, you’re probably wondering “I guess I’ll need to use SOAP!” Well, aside from needing soap to stay clean, you can actually be SOAP free in your web services and still use longs, nulls, etc. How? Use REST.

There are two ways to implement REST services. There’s the purist way which uses the verbs of the HTTP protocol such as PUT, DELETE, POST, etc. The other more common way is to simply use the GET and POST. You supply your parameters on the URL including the method to be called and get back an XML response. A downside to REST is that the XML response is defined by the web service implementor, unlike XML-RPC or SOAP which have a defined structure. Nonetheless, REST has become very popular among web sites such as smugmug.com, amazon.com, and yahoo.com.

REST and XML-RPC are not the only alternatives to SOAP, JSON is another. JSON is commonly done as a REST web service with the exception that the response is in JSON format. Most folks assume JSON is for use with JavaScript and web applications only, but that is not true. The thing I like most about JSON + REST is I get the ease of calling by a simple URL and get a well formatted easy to read response that supports nulls, UTF-8, and longs. You get none of the scum from SOAP, none of the limitations of XML-RPC, and a well understood format unlike the typical REST response.

Ok the best way to “see” this is by looking at some code. Let’s look at XML-RPC first. Let’s assume we are calling the “smugmug.images.get” method at smugmug.com. Using an XML-RPC library for your language (java, python, perl).

client = ServerProxy("http://smugmug.com/xmlrpc")
session = client.loginWithPassword("uname", "pass")
imgdata = client.smugmug.images.get(session, image_id)
print imgdata['id']

It’s that simple. The library did the parsing for me. imgdata will most likely be a hash. The library sent over something like this:

<?xml version="1.0"?>
  <methodCall>
    <methodName>smugmug.images.get</methodName>
      <params>
        <param>
          <value><string>AXE0123</string>
        </param>
        <param>
          <value><i4>40</i4></value>
        </param>
      </params>
   </methodCall>

The server responds with something like this:

<?xml version="1.0"?>
<methodResponse>
  <array>
    <data>
      <value><i4>1404</i4></value>
      <value><i4>1504</i4></value>
      <value><i4>1</i4></value>
    </data>
  </array>
</methodResponse>

Pretty easy to read isn’t it? But as you saw in the code you didn’t have to know how to read it.

Let’s try the same thing with REST. There are no frameworks that handle REST directly as it’s just a simple HTTP GET or POST and an XML document response.
url = "http://api.smugmug.com/services/api/rest/1.2.1/"
call = url + "?method=smugmug.images.get&session=AXE0123&id=40"
response = urllib.urlopen(call).read()
# parse response XML into a dictionary
imgdata = parse(response)

In most cases you’ll probably have to write your own framework which isn’t really that hard, I did it. What gets sent out is a simple HTTP GET request to http://api.smugmug.com. What you get back is an XML document which you will need to parse.

<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="ok">
 <method>smugmug.images.get</method>
 <Images>
  <Image id="17833"/>
  <Image id="17832"/>
 </Images>
</rsp>

Yes, it’s XML but so far it’s not too bad is it? You’re probably itching to see what JSON and SOAP can do huh? Well, heeeeere’s JSON! (that’s a Johnny Carson reference for you youngins).

url = "http://api.smugmug.com/services/api/json/1.2.1/"
call = url + "?method=smugmug.images.get&session=AXE0123&id=40"
response = urllib.urlopen(call).read()
# use builtin python library simplejson to read
imgdata = simplejson.loads(response)

The nice part about this is I don’t have to parse the response because libraries like simplejson do that for me. And I can easily make the calling code generic as I did in zmugjson.py. Again, the request is nothing more than a simple HTTP GET. The response is a nice JSON object.

{
  "stat":"ok",
  "method":"smugmug.images.get",
  "Images":[
    {"id":222910058},
    {"id":222910121}
   ]
}

As you can see it is very easy to read and no nasty XML to deal with either. Best part is you could use this in an AJAX web ui with no need to create more than one API.
There you have it, nice alternatives for creating web services without using SOAP.

Oh you want to see the SOAP version of the above? hrm. smugmug was wise not to create a SOAP version of the API, but here is what it would probably look like. I’m warning you, you don’t want to see it. Ok here goes.

  import org.apache.axis.client.Call;
  import org.apache.axis.client.Service;
  import javax.xml.namespace.QName;

  public class TestClient {
    public static void main(String [] args) {
      try {
        String endpoint =
            "http://api.smugmug.com/services/api/soap/1.2.1/";

        Service service = new Service();
        Call call = (Call) service.createCall();

        call.setTargetEndpointAddress( new java.net.URL(endpoint) );
        call.setOperationName(new QName("http://soapinterop.org/", GetImagesFromSmugmug"));

        List<Integer> ret = (List<Integer>) call.invoke( new Object[] { "AXE0123", new Integer(40) } );

        System.out.println("Sent 'Hello!', got '" + ret.toString() + "'");
      } catch (Exception e) {
        System.err.println(e.toString());
      }
    }
  }

Yes, I know it’s Java and not python, but that’s another problem with SOAP. The better libraries are written for Java not python, perl, etc.

What would the SOAP request look like you ask? Probably like this:

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
   <SOAP-ENV:Body>
       <m:GetImageIds
         xmlns:m="Some-URI">
           <SessionId>AXE0123</SessionId>
           <id>40</id>
       </m:GetImageIds>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Followed by a nasty response:

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
   <SOAP-ENV:Header>
       <t:Transaction
         xmlns:t="some-URI"
         xsi:type="xsd:int" mustUnderstand="1">
           5
       </t:Transaction>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
       <m:GetImageIds
         xmlns:m="Some-URI">
           <Images>
             <Id>1404</Id>
             <Id>1504</Id>
             <Id>1</Id>
           </Images>
       </m:GetImageIds>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Seriously folks, it is truly possible to create web services and software as a service WITHOUT resorting to the evil that SOAP is. So the next time you plan on developing a web services api for your application consider XML-RPC, REST, and JSON.