Rail Baron payout finder

I found the data in an excel file here. Then I had to save it as a csv. Then I converted that to json. Then I did some manual clean up. It was a lot faster than typing it all in by hand though!

What next? I’d like to dabble with writing iPhone apps and this seems like a fun first app for that. The second least enjoyable aspect of playing the game is rolling for destinations. It would be fun to just shake the iPhone and it’ll choose a city for you and tell you how much money the route is worth. The players can just concentrate on the more enjoyable strategic parts of the game.

Extending the base functionality: big difference

Perhaps the biggest difference between Dojo and jQuery is the philosophy they took towards extending the base functionality. jQuery itself is best compared to Dojo base. If you want additional functionality, it’s available in user-created plugins which you download and include via script tag. In Dojo, you would find a module for this in dijit or dojox and include it with dojo.require.

Do you prefer extensions that have been planned out centrally to work together? Are you ok with having just one “official” way to do things with some configuration options? Would you rather just include the needed module and skip the process of searching for a plugin? Use Dojo.

Do you want to have the biggest number of options possible for the functionality you need? Don’t mind having to search around a little bit and compare plugins in exchange for finding one customized to exactly what you want? Use jQuery.

Dependency management

Dojo does really well here. There’s an “official way” to manage dependencies which is nicely supported by the library. You put your custom code in it’s own folder which becomes a namespace for your code. Create classes in separate files in the folder with dojo.declare and a dojo.provide statement. Just dojo.require them where you want to use them. The jQuery way is to… use the script tag? You can organize files containing the code however you want. I’ve only been using jQuery for a very short period of time, but I’d guess there are some “best practices” for organizing code that make this less of a problem when working with others.

Conclusion

The things that make Dojo great for writing complex applications are no help when trying to do simple enhancements. jQuery just makes these things incredibly easy. Just include the library, a plugin or two, and one file with your own code. I think in the future I may be using both depending on what sort of problem I need to solve.

I’m looking forward to starting a new job at Geeknet working on Sourceforge soon. I’ll be shifting my JavaScript writing to jQuery and getting back to working with TurboGears on the back end. I’m going to miss everyone at LogicBlox and hope them the best.

I presented on JavaScript builds. My talk explained what a JavaScript build is, why you might want to make one, and how to implement a build process. I used Dojo’s build tools to describe how a build should work and also discussed the Closure compiler. Slides are at the bottom.

The other presentation was on Cappucino which looked great, though I’m not so sure I want to learn Objective-J if that’s all I can use it for. Sure it’s like Objective-C, but how well do the skills translate if I invest time in learning Objective-J and Cappucino disappears? Other than that concern, the demos look great. I was a little bummed that Atlas is still quite buggy and apparently no where near ready for prime time.

I faced an irritating situation last year in a project I was working on. I was creating a screen that pulled in a very large set of data from the database then did various calculations on the data based on input in a form. The results were shown in several grids and a flash chart all on the same page. These exact same calculations also needed to be run to generate a PDF on the server. I didn’t want to go back to the server for the calculation because the amount of data that needed to go back and forth was very large. At the same time, I didn’t want to write and maintain a piece of code that involved 30+ math operations in both JavaScript and Python.

So I discovered Pyjamas!

A little background: the Pyjamas project was started to be the Python answer to GWT. It’s a framework that allows you to define an entire UI in Python which is then converted to JavaScript and HTML. What I found though was that it’s possible to use the Python to JavaScript converter in the project to compile your own Python to JavaScript even if you don’t need the UI framework Pyjamas provides. This was a perfect solution to my problem!

Unfortunately, Pyjamas was still in its infancy at that time, so I had to use a much stripped down subset of Python to get it to build JavaScript successfully. Once I figured out the tricks, it was a great way to avoid a painful round trip to the server and yet also avoid maintaining the same logic in two languages.

Fast forward to today. The Pyjamas project has a greatly improved Python to JavaScript compiler. You can now import multiple modules through the usual Python import functionality. The painful things I had to do before (like not use the dict constructor!) are no longer necessary. There’s even a way to include external JavaScript files from Python for use in your final generated script.

How do I use this?

It looks like at this very moment (mid-November 2009) the compiler inside of Pyjamas is in the process of being broken out into a module called pyjampiler that makes it a little easier to use it independently of the larger project. This is currently getting moved into the main code, so look for it inside of the next release. For now you can download it from the link above. Playing around with pyjampiler is this easy:

pyjampiler.py --output=my_javascript.js --entry=my_python

Really! Your python imports will be followed, converted, and linked together. You’ll get JavaScript that behaves like your Python.

Tips for success

As cool as this is, there are some limits. You can’t import whatever you like from the Python standard library. The JavaScript generated is going to be much more verbose than something you would have written yourself. You’ll need to include a helper .js file which is not one of the frameworks you’re already using (supposedly it’ll play nice).

I think this technique is best limited to functionality like I described in the beginning of this post. I implemented my logic as a function that took in two dicts and returned another dict of results. The only thing handled by the piece that was converted was the arithmetic required to drive the calculator. I wrote JavaScript to handle the DOM manipulations required to display the results on the client and Python to turn the results into a PDF on the server.

What do you think? Is this a reasonable way to avoid maintaining the same logic in two places? Have a better solution?

<div style="position: relative; height: 100px; width: 100px; border: 1px solid #000">
    <div style="position: absolute; right: 0; top: 0;">X</div>
    <div style="position: absolute; left: 20px; bottom: 20px;">Y</div>
</div>

And here it is in action:

This is incredibly useful. Try it out for things like positioning text in tabs or putting a close button in the corner of a div.

function(source, nodes, copy, target){
        if(source.node==this.top_node || target.node==this.top_node){
            var childNodes = dojo.query('#' + this.top_node.id + ' > .custom-control');
            var newOrder = dojo.map(childNodes, function(childNode){
                return childNode.id;
            });
            console.debug(newOrder)
        }
    }

Unfortunately, I came across some annoying behavior. If the source node is located before the target node in the DOM, the onDndDrop event is firing on it before the move actually takes place! My function to calculate what controls are in each Source is therefore getting incorrect results and says the moved control exists in both the source and target Sources. The solution was to add an additional filter for the nodes:

function(source, nodes, copy, target){
        var isSource = source.node==this.top_node;
        var isTarget = target.node==this.top_node;
        if(isSource || isTarget){
            var childNodes = dojo.query('#' + this.top_node.id + ' > .custom-control');
            var newOrder = dojo.map(childNodes, function(childNode){
                return childNode.id;
            });
            // make sure that if the node should be moved out of the Source it really is gone
            // sometimes dojo calls this code for the Source before the node has ACTUALLY been moved
            if(isSource && source.node != target.node){
                newOrder = dojo.filter(newOrder, function(childName){
                    return !dojo.filter(nodes, function(movedNode){
                        return movedNode.id == childName;
                    }).length;
                });
            }
            console.debug(newOrder)
        }
    }

As a side note, it works as expected if the target node is before the source in the DOM. I wouldn’t mind this behavior if it was at least consistent.

If only! Sure, you can use a hash to get a similar effect, but why not just add that in? JavaScript is getting more and more like Python every day anyway…

dojo.connect(myElement, "onclick", myObj, "handler");

One would expect it to be similar for a dijit like:

dojo.connect(myDijit, "onclick", myObj, "handler");

But that didn’t work. Why not? Because the dijit event names are camel-case:

dojo.connect(myDijit, "onClick", myObj, "handler");

Why not standardize them to match the equivalent DOM event names with lowercase spellings?

Unfortunately, I feel like the Prototype world has not kept up with the times. Well, perhaps that’s a miss-statement. Prototype is still just what it started out as: a base to build upon. Scriptaculous still provides animation and a few widgets. Meanwhile, the other frameworks have become much more full-featured. The widgets provided by Dojo, YUI, or ext.js are far beyond the ones offered by Scriptaculous. Writing something complex? Package management would help a lot. What about some base CSS to get started on my project with (or even better, themes)?

I will still be using Prototype for smaller projects. I think it’s great if you just want to toss in a dash of JavaScript flare and would like to use some nice helpers. But, I’m done writing big applications with Prototype/scriptaculous. It’s time to learn something new!

I’ve done a quick review of the options out there, and I’ve decided to pick up Dojo next. Ext.js needs to be licensed for commercial projects. What if the cost is too much for a project I’m working on? YUI looks excellent, but somehow it feels less organized. In fact, I plan on playing around with YUI a bit too for comparison.