California Dreams

Have you ever been looking for a colleague, printer, or just about any resource in an office and being frustrated there was no map showing you where to go? I have good news for you. I just released Solu, which is a “Self-service Office resource Locator and Updater”. Or “cubicle finder”. Or whatever you want to call it.

This project started as a perfect example of “scratch your own itch”. I was doing some research on how to do REST with Python, and remembered jj recommended Werkzeug at some point, so I took a look. Around the same time I was chatting with our new admin, and noticed the office blueprints on the IT cubicle wall. This lead the two us discussing how nice it would be if there was a map to help us new people around. I ended up saying I could program such a system in 20 hours.

So I ended doing a bit more than research, and studied Werkzeug and jQuery. And although it wasn’t strictly necessary I also spent quite a bit of time researching how to make an easy to deploy package of the application, and how to make it easy to try it out. In the end I spent almost exactly 20 hours on the first version, but I realized I could have done it in about half the time had I used Pylons, mostly because I already knew Pylons and also because the things were I struggled with Werkzeug were already provided by Pylons, or easily integrated into Pylons. After the initial version I’ve spent another 20 hours to fix bugs, write tests, and in general getting it to a stage I felt good to release. Even still it is missing some pieces I know how to do in Pylons, but still don’t know for sure how to deal with them in Werkzeug.

Since I developed this application partially on SpikeSource time, it was nice of them to let me Open Source it to everyone’s benefit.

Some of the things I really enjoyed about Werkzeug include:

• Interactive Python debugger in the browser
• Small enough to make the ramp up period quick
• Good documentation
• Enough features to provide almost everything I needed
• Easy to swap template system from Jinja to Mako (since I didn’t want to spend the time to learn Jinja too)
• Writing tests was easy
• Easy to work with Unicode
• Great tutorial which fit my needs almost perfectly

Some of the things I found frustrating about Werkzeug:

• No builtin mechanism to load application options from a file
• No help to package the application
• No cross-site request forgery (CSRF) protection out of the box
• No internationalization/localization (i18n/l10n) support out of the box
• No samples or recommendations on how to pass application and options to views and templates
• No samples or recommendations on how to implement sessions

In the end I used ConfigObj to load the options from an ini file. This was a little trickier than I thought at first because I wanted the manage script to work so that I could run with Werkzeug’s server while testing, but I also wanted to retain WSGI deployment possibility. Packaging took some extra reading about setuptools. CSRF is still a little open, although I got pointers to zine.utils.forms and also found werkzeug.contrib.sessions which should make it possible in the way I was thinking about it. I don’t see CSRF as a huge issue at this point, though, given the data this application handles. I also got some pointers on how to implement get_app() function to get the application object from anywhere, so getting the options stored in the app became easy. I still have some open questions about localization, but those might go away once I actually try to do that.

There are some obvious improvements to Solu, like fixing the CSRF issues, i18n/l10n, multiple and resizeable maps, dealing with errors in a more user-friendly way, and overall making it pretty. I could see someone wanting to pull the information from company LDAP database or some such, and hooking this up with general employee database.

Since I spent so much time making it easy to see what the application is about by providing a website with screenshots, a demo site, easy installation and instructions on how to run your own application, I am interested in hearing how I did.

I have been reminiscing about the programming language I have used as a student, as a software engineer, and hobbyist. The list is actually surprisingly long, come to think of it. I think it serves as a useful reminder for students interested in working as a programmer that you are very unlikely to be able to go through your career with skills in just a handful of languages, less alone one. I am also purposefully skipping languages that can not be considered full-fledged programming languages. I am also lumping all variations of a language as one language, more or less. Here’s the list of languages I can remember writing at least one line of code in, roughly in the order that I started using them:

Basic

I started with Basic on a friend’s Commodore Vic 20, and then on my own Commodore 64. I used some Basic version on PCs, Visual Basic in a student project and later in small Microsoft Access projects at work.

Pascal *

I used Pascal in high school, where it was taught as an optional class, and programmed a simple game with it.

Fortran *

My university was big on mathematical information processing, and given that I also started as a physics major, the university saw fit to teach me Fortran. I can’t remember ever using it for anything outside those classes, though. I came pretty close when I was working on NIMBUS, which was an online multiobjective optimization package researched and developed at University of Jyväskylä.

C

The first language taught in the first computer science class. I have used it both professionally and personally and still continue to use it today although not very often.

C++

The second language taught in the university. C++ was my main programming language from 1996 to 2003 both professionally and personally. I rarely write C++ these days.

Perl

I learned Perl on my own when I created an online exam enrollment system for my university. I was too lazy to walk from the computer science lab on the first floor to the third floor where the exam enrollment drop box was so I decided to write the system for my faculty Perl was my main scripting language until 2003.

shell

I have used mostly tcsh and bash shells, and while I originally just wrote little custom .bashrc etc. files, shell scripting has since become if not daily, at least a weekly occurrence.

Assembly *

We had one class at the university that many people dreaded, and that was the class where you had to learn a little bit of Assembly language. I have never had the need to write Assembly since then, but it would have been useful being able to read it occasionally. This is one language I might actually need to invest some time in the future, I think.

Javascript

I learned this on my own to add some dynamic content on my web pages. I was among the first 10 people in my university to have homepages, and I actually ended up giving some advice to the staff member(s) who were running the webservers. I have since used it on many websites.

LPC

I learned LPC on my own after I became one of the coders for Regenesis, a BSX-MUD. Regenesis was probably among the first graphical networked games, a precursor to MMORPGs.

SQL

Learned in school, used a little bit at work, but I definitely need to get better at it.

Prolog *

Learned while I was an exchange student at the University of Kent at Canterbury. It was a fascinating language, but I could not wrap my head around how to actually use it (I did badly in my assignments).

Lisp

I have only used the lisp in Emacs and XEmacs to modify some of the beavior of (X)Emacs. Another language that I might need to invest some more into.

Mathematica

I had a summer job while I was studing at the university to program questions with answer checking for an online intro math class for the Tampere Technical University. I am still blown away by how they had hooked up Mathematica to the web server backend. Haven’t used it since.

Tcl

When Bugzilla was first shipped, it contained a little bit of Tcl that I had to modify when installing Bugzilla for Citec.

XSLT

Not sure if I should call this a programming language, but Wikipedia lists some other XML languages so what the heck. Mostly dealt with XSLT when an engineer in my group was working on adding P3P support to Netscape and Mozilla browsers.

Python

My first touch with Python was actually before 2000 when a fellow student raved about it, but as soon as I heard about forced indentation, I walked away (bad experience with Fortran…) Too bad. I wonder how things would have turned out if I had stayed and drank the coolaid then. Next touch was at Netscape, when a colleague raved about it. I actually ended up modifying a little Python program - flawfinder - while at Netscape. But it wasn’t until I started at OSAF back in 2003 when I really had to start using Python. I guess I fell in love with the language in the first two weeks

Java

I did my first Java programming by fixing two bugs in the PyDev plugin to Eclipse. When Google Android came out I created Caltroid to learn about the API and Java.

Groovy

At SpikeSource I decided to base my work on Hyperic, where the UI plugins can be written in Groovy.

PHP

When I started experimenting with ads, there was one case where the ad code was provided in PHP, but I wanted to alternate between two different ad sources, so I had to learn enough PHP to do that. Quite likely I will need to learn more, as I am thinking about creating a theme for my blog since I can’t seem to find a theme that I like. Incidentally, if you know of nice 2 or 3 column liquid or fluid layout Wordpress themes where the main content is on the left, let me know…

* Used only in school.

I listed 20 languages above. A little more than half were required as part of doing my day job. And this does not even list languages that I have had to read but not write, or configuration mini-languages, or XML languages (apart from XSLT), … I don’t expect to stop learning new programming languages any time soon.

Update: I forgot HyperTalk, which I used a little bit on my Macintosh SE/30. I learned it around the same time I learned Fortran and C.

I finally decided to sit down and fix some annoyances in my Caltrain schedule applications written in Python and Javascript. I added the ability to filter trains that don’t stop at either your departure or destination stations. For the Python version I also added the ability to install the package simply with easy_install caltrain. Even nicer, when you have setuptools installed (as you do when using easy_install), the installer will place a script named caltrain in your $PATH, which makes it a snap to launch the application. The magic part in setup.py for the script is simply:

    setup_args["entry_points"] = {
        "gui_scripts": [
            "caltrain = caltrain:gui",
        ]
    }

where the line "caltrain = caltrain:gui" means that the script will be named caltrain, and it will call the calltrain.gui function (caltrain is the module).

I also finally made a proper page describing the project. Much nicer than needing to find the last post on this blog about the topic.

I noticed Caltrain has a page listing mobile applications. I wonder what it would take to get them to include my little apps there. I quite prefer the UI in my applications to all the others (except for the PalmOS version). This is what the latest Javascript version looks like:

Online Caltrain Schedule Application for Windows Mobile in Javascript

A colleague pointed out to me that what I am trying to do with battle canvas might still be too complicated and I could simply make do with a scaled image background and drag and drop divs over it. It doesn’t quite tickle the excitement about trying something completely new to me, but on the other hand this is the tried and true method of working on the web today.

Using scaled images and dragging divs has the benefit of getting advantage of libraries (for example, jQuery’s draggable works just fine), but it seems like it will also result in fighting tedious CSS differences between browsers, and things outside the canvas being able to affect the battle canvas by accident.

Nevertheless, I created the (simplest yet) battle canvas in the series using a PNG background and jQuery UI to implement draggable area effect and hero square: Battle Canvas PNG.

I might have fallen victim to the Golden Hammer. After pondering about the drag and drop of canvas elements, I realized there is an older technology that might be suitable for my purposes as well: SVG. It is just about as easy to make SVG battle canvas as it is to make one based on the canvas tag. I think SVG is a bit more promising because it provides structure and as such you would think providing drag and drop manipulation would be easier, perhaps already done.

I started to experiment by building the SVG canvas using jQuery and the jQuery SVG plugin. Static grid, hero box and transparent area effect were no problems.

Then I found out jQuery supports drag and drop in the jQuery UI. Unfortunately this didn’t work; trying to call draggable() on an SVG element gets you an exception because the code assumes HTML DOM (I think, I didn’t look too closely).

Then I decided I’d try it the same way I did with canvas. Apart from an issue trying to figure out the container’s offsets (hardcoded for now, might not be correct with other browsers but should be able to work this out), the drag and drop works. What is better about the SVG compared to the canvas tag is that I can set the mousedown handler on the area effect rectangle object itself without needing hit testing to see if I started a drag. Possibly the drag could also be done using SVG animation or by erasing and redrawing the dragged object instead of erasing and redrawing everything.

You can see the current effort at SVG Battle Canvas.

After doing some more research I did actually find three virtual tabletops that work in the browser: Flash-based Battle Map, RPGtonight and AjaxVTT. The last one seems to be a dead project. There seem to be at least one more Flash based application in development that might provide VT functionality. Battle Map is just what the name says, a bare bones map for putting some markers on. RPGtonight looks to be a pretty full featured VT. I found these from Battlegrounds, which offers lots of links to computer aided table top role playing. As far as I can tell, none of them use the canvas tag.

I have never done anything with the canvas tag myself, so I started doing a little research. To start with, I created a little canvas with a grid, put a marker on it and placed a draggable area effect on it. The canvas API is pretty limited, consisting of basically just drawing functions. It is nice that it offers support for alpha blending, which makes it trivial to draw the area effect in my sample. Drag and drop required doing hit testing and erasing and redrawing everything on movement. Would be nice to get a library to do this kind of thing.

Mozilla offers a great canvas tutorial, and the WHATWG spec has the details. I got the idea for the drag and drop from this blog.

Here’s the beginnings of my Battle Canvas.

I recently installed the Firebug extension, and I must say I am impressed. I have used the predecessors of it (DOM Inspector) but Firebug combines several related tools (LiveHTTPHeaders, Venkman and Web Developer) and improves on them, making a seamless super tool for web developers.

Good job, Joe!

After I had released CaltrainPy 0.2 I started thinking about making a web version. I now have CaltrainJS 0.2 running. Ironically it seems to work OK everywhere except where I most want it to work: Internet Explorer Mobile. The Javascript and CSS support in that browser leaves much to be desired.

There are some refinements I could do for other browsers, like putting the schedule in a scrollable box so that the header would stay in place, but I put that work on hold until I get it working in IE Mobile. (I did have the scrollable area working reasonably well in Firefox.)

Update: I resorted to using innerHTML to (re)write the complete table on each update, since modifying a table dynamically in IE Mobile does not seem to be possible. Marked it CaltrainJS 0.2.1.

Update 2: I just released 0.3 to update to the March 3, 2008 schedules, and fixed the AM/PM bugs.