brian's blog

Entries in "JavaScript"

A Web-Based Presentation System for Case

If you saw the new EECS department bounty system, you may have noticed the bounty for a web-based presentation system. This is now a work-in-progress by yours truly.

The goal is to let Case people generate slideshows through the web with Case-themed templates, mostly for use on the plasma displays in the EECS department (well, the displays that will be in Glennan). Another use could be by faculty in place of PowerPoint (so it should have familiar features such as transitions).

You may have seen those displays in the fishbowl last year showing pictures and such. Apparently these are a pain to administer because they are connected by a wireless connection and thus are not easy to connect to via Remote Desktop. So when they are rebooted or PowerPoint closes somehow, getting the slideshow back up and running can be a real hassle. Having them in kiosk mode in a web browser will allow them to easily refresh if anything goes wrong, and will also let them grab updated content. This is how the plasma displays around campus show their (I think Flash-based) slideshows.

There are two such tools on which to base such a system: S5 and Slidy. If you've ever viewed a text-based presentation online, it was probably with S5. This is the first time I have heard of Slidy, but it actually looks a lot better to me. Every time I've encountered S5 in the wild, the JavaScript has eventually completely messed up the text sizing and positioning, making everything unreadable.

There are existing services that combine web presentation systems with editing and sharing, such as S5 Presents and SoapBX. SoapBX is not open source while S5 Presents is GPL licensed and in Ruby. I would have no problem with using S5 Presents, but apparently it has gone unmaintained for almost two years, and Simon was disappointed when he looked into configuring it to run under a real web server.

Tonight I decided to see what actually using S5 is like, so I customized the default theme to resemble the Case PowerPoint template found on the Case branding page. So here is my Case-themed S5 presentation. It's pretty incomplete and doesn't match exactly, but it's close (and anyway, the goal is to make it look good, not match exactly—their PowerPoint template could use some work).

When I first considered this bounty, I thought "hmm, web-based, which web framework will I use?" One of the major goals is to be easily maintainable once I leave, so something popular or at least very easy would be the best choice. Which best fits this description? Django? TurboGears? web.py? I've never really considered the maintainability of any of these, since usually I can choose whichever I like at the moment.

After a bit of talking with Chris, we determined that any server-side code at all isn't even really needed. The only thing it would be used for is to display view and edit pages for the presentations and to store them. The first two can be done with static HTML and JavaScript, while the third can be used by POSTing with AJAX to some location. For example, we could POST presentations to the EECS department's new DokuWiki-powered site with the appropriate permissions. Since S5 and Slidy presentations are just HTML, the wiki page itself would be the presentation outline, and the slideshow viewer could just grab the markup from there. Or we could use AJAX to upload the presentation via WebDAV to the author's Filer account.

Since there would be heavy JavaScript usage regardless of the selected framework, the author would need to be fluent in it anyway. So why not a pure JavaScript solution, given the possibilities above? This is what I'll be looking into for the next few weeks. The code will soon live at opensource.case.edu/projects/present.

If anyone has experience with S5 or Slidy and would like to share their opinions, please do (even if it's just which system you like more).

Making dp.SyntaxHighlighter for Python Not Suck

I've always wanted syntax highlighting for my Python code on the web. The geopy site, for example, is made much more readable with syntax-highlighted code. However, it's all done statically by using KDevelop's HTML Export feature.

The other night I decided to finally try out dp.SyntaxHighlighter, a JavaScript syntax highlighter. But unfortunately I discovered that its Python support is actually pretty ugly. Its Python example page isn't even valid Python! Type declarations? Not only that, but the test page demonstrates its parsing failures—the comment within a string is highlighted as a comment, not a string.

So I made some modifications. You can see the modified test page here. If you want to use it, check out my modified shBrushPython.js and my python.css, which you can modify to change the colors.

I took out all the highlighting of the builtins, exceptions, types, and modules. In practice I don't think that's very useful. The purpose of syntax highlighting is to make code clearer, not to classify every little token and make it look like a rainbow.

One thing I was not able to do was highlight class names and function names where they are defined without also highlighting the "def" and "class" keywords. I think this makes things look a lot nicer (as you can see in the highlighted geocoders.py code), but unfortunately JavaScript does not support lookbehind assertions, so I don't think it's possible without modifying dp.SyntaxHighlighter a bunch.

I also really like having operators highlighted (see here again), but that slowed it down considerably. Uncomment that line in shBrushPython.js if you want it.

Enjoy.

JavaScript Contour Mapping: Still Seems Feasible

A few posts ago I talked about generic contour plotting for Google Maps using only JavaScript.

After some more work and research into contouring algorithms, it still seems like a reasonable idea.

Instead of gridding the irregularly spaced points (crime locations in my case) I learned that many contouring algorithms instead use Delaunay triangulation. So I implemented incremental triangulation in JavaScript and the result seems fast enough (note: still needs Firefox or Adobe SVG). On my (older) computer it gets unreasonably slow around a few hundred points, but this is more than I expect to render at a time anyway (consider that the Crimes in 2006 page only has about 60 unique locations).

The next step is to modify the algorithm to use Constrained Delaunay or Ruppert's Refined Delaunay.

After that, it's just a matter of interpolating the crime density (so that levels in between high and low densities are created if they don't exist), smoothing the polygons, and drawing & coloring them with SVG.

I checked out a nice collection of research papers from KSL called Geometric Modelling which includes some contouring discussion. I plan to make another visit to the library this week to see if I can find anything helpful about the steps above. Googling for this stuff has been extremely helpful, but no single page has very comprehensive information, I just have to piece it together.

On the Case Forum Greg mentioned his idea for a Case geocoding service that would aggregate information from geocoding services such as Google Maps and the Case Wiki so that any Case web service could easily geocode local places (Andrew mentioned geocoding photos, for example). I think the crime log location parser fits this bill pretty nicely! The version in trunk has tons of Case-specific location parsing techniques that could save other web services a lot of work. It just needs to be put on a server that will accept strings and send back geocoded results.

More crime & mapping news to come...

Functional Programming in JavaScript: Nice But Slow?

While making those two JavaScript contour prototypes I posted yesterday, I had the chance to try out the nice functional programming tools offered by MochiKit. I love MochiKit—mostly because it's highly influenced by Python.

However, since the performance of the contour mapping code is extremely important to its feasibility, I did some profiling and was a bit surprised.

Consider this code to test membership in an array of points:

var containsPoint = function (container, element) {
    for (var i = 0; i < container.length; i++) {
        if (pointsEqual(container[i], element)) {
            return true;
        }
    }
    return false;
}

Boring, right? Now the functional equivalent:

return some(container, partial(pointsEqual, element));

some and partial come from MochiKit.Base and MochiKit.Iter, respectively.

Sadly, I profiled the functional approach at being 27 times slower than the verbose version.

Similarly, this code:

var neighbors = new Array();
for (var i = 0; i < points.length; i++) {
    var p = points[i];
    if (is_neighbor(scale, prev, p)) {
        neighbors.push(p);
    }
}

...is 3 times faster than this code:

var neighbors = filter(partial(is_neighbor, scale, prev), points);

I assume this has something to do with the functional approach being run as "pure JavaScript" while the verbose version is optimized by the implementation—like pure-Python vs. Python written to take advantage of its C implementation (the "pure" version being slower).

I think a lot of people don't profile their JavaScript code, so I'm just throwing this out there. Unless someone can point out a solution to the dramatic speed difference, I will sadly be avoiding a lot of the functional tools offered by MochiKit.

I'll be spending the next few days moving into my Village apartment.

Tomorrow: The final day of Summer of Code, I'll talk about my results.

Generic Contour Plotting for Google Maps

The other day Mike, Spiros, and I began thinking about generating SVG contour maps with JavaScript. The reason is that I want to be able to show a contour map of crime density (like this one of property crime) on the Campus Crime Mapper.

I think a way to generate generic contour maps for Google Maps in JavaScript would be extremely popular with Google Maps developers. It could be used to map temperatures, population density, precipitation, wifi coverage, and lots of other things people are using Google Maps for.

There are only a couple sites out there that have overlayed contour maps on their Google map. The best one seems to be EarthTools, which uses it to display a topographic contour map of the area. I can't tell if it uses static image tiles, SVG, or Canvas; maybe someone else can figure it out.

You're probably wondering why I want to do it all in JavaScript and SVG as opposed to rendering static tiles on the server and overlaying them. There are a few reasons:

• Using JavaScript will make it available to any Google Maps developer, regardless of their server-side tools.
• The contour shapes will only need to be calculated once for all zoom levels, since they are infinitely scalable.
• I am almost positive that the time it takes for the client to calculate and render the SVG contours will be about the same amount of time it would take to download all the custom tiles anyway (especially if they will be zooming and scrolling — hint: they will be).
• Theoretically it will allow the user to change the granularity, colorization, and other aspects of the map.

I'm not looking to generate anything insanely detailed, just something at about this detail level.

I have some proof-of-concept code online that tests finding shape contours and smoothing them with Bezier curves. You will need either Firefox 1.5 or a browser with Adove SVG enabled to view those demos (I'm considering also supporting Canvas).

Note: Those pages (and the Crime Mapper) will be down while I move into the Village.

Speaking of SVG and Canvas, I'm going to use this sweet JavaScript plotting library called plotkit to show crime statistics — check out the demo on that page!

I'm excited to see how far I can take this, but right now I've got two days left in the Summer of Code.