Tag: programming

Ruby OpenGL, Kororaa Xgl

Last night at StlRuby.org the question came up of how to contruct GUIs with Ruby. I mentioned that I think there is a lot to be gained by using the high performance graphics hardware APIs, which are mostly used for games, in business applications. This of course is not all that remarkable, since Java Swing has used DirectX for drawing for the last several years, and Windows “Vista” will use it for most of Windows itself. I’ll discuss this idea more in a later post; I’m investigating it here for a couple of Oasis Digital projects. On my list of tools to experiment with is Ruby + OpenGL; there is a RubyGarden page about it and another page here, unfortunately in Japanese. I found a ruby-talk post which indicates that it works quite well.

John McClenning pointed out Kororaa Xgl, a project which modified an X server to draw with the OpenGL API; there is a LiveCD of the Kororaa Linux distribution for trying this out. I’m downloading it now the torrent. Novell is also a sponsor of this effort.

(A plug: uTorrent is the best BitTorrent client I’ve seen so far: it is small, clean, featureful, usable, robust, ad-free, and free.)

To Wrap, or Not To Wrap (Jemmy)

Yesterday I mentioned a talk by Mike Feathers about API design.  One of the topic of API wrapping, which we do frequently here at Oasis Digital, for a variety of reasons.

By coincidence, today the question came up of whether we should wrap the API of Jemmy, a Swing GUI testing tool.  Our natural inclination is to wrap.  But there are oppossing forces as well.  Here’s where I ended up:

  • The Jemmy API is large, and thus tedious to wrap.  (Which might be a good reason to wrap it…)
  • We haven’t used Jemmy much yet, so we don’t have any real idea what subset of its API we will use.
  • We haven’t done much GUI test automation yet, so we have little reason to think we know much about API design for that.
  • There are developers “out there” who know how to use Jemmy. Perhaps we will hire one, and benefit from them already knowing how it works.
  • Thus, we should start out using Jemmy as-is.
  • Once we have a moderate body of code (enough to understand out use, but not so much that revamping it would be burdensome), review this decision and decide whether to wrap it.

Michael Feathers at XPSTL

This evening at XPSTL, Michael Feathers (blog) (book) was in from out of town (and from around the world) and gave a talk on API design. He’s been thinking a lot about API design recently, driven by issues that come up with working with legacy code, which talks to lots of APIs, to cajole it in to a more testable state. I think there is a lot to say (maybe a book’s worth?), and a lot of what has been said elsewhere turns out to yield APIs that are unduly difficult to build testable code with.

What we end up doing here, and a thing that Michael says is not at all unusual, is to “wrap” most APIs with some application code, to enable:

  • a simplified way to call the external component / API, more suited to our needs
  • easy testing, as we can design our wrapper to make it trivial to substitute a test/mock implementation
  • a buffer from future changes in the external component / API
  • easier migration to alternate implementation of the same underlying services

Our wrappers tend to be “flatter” and simpler than the underlying APIs we wrap. For example, most of our use of Hibernate is behind a class we call DataSession, which represents the connection/session, transactions (it encodes our policies on how to use transactions) and many named methods for query operations (thus we avoid scattering HQL or SQL around the project).

Also, we had a big crowd at XPSTL – the room was packed.

Sutter Concurrency Talk – We Need Better Languages

I’ve seen lots of links to Herb Sutter‘s talk at PARC on concurrency. This is a great talk – I found it a little tough to make it through his paper on the topic, while the talk is a joy to experience, information-dense yet approachable. Some thoughts and notes:

  • There weren’t very many people in the audience – I’d have loved to fill one of those empty chairs.
  • He mentioned OO being invented decades ago… passed on the opportunity to mention that much of it happened right there at PARC.
  • I looked at Erlang some months ago after Joel Reymont described his experienced with it.  Erlang is worth looking at again, in depth.
  • For those of us who make a living by staying on the front slope of the adoption curve, the time is now (or past…) to build systems that run as a large number of separate threads of execution, to learn to build and use abstractions over concurrency, to run operations on a clusters of multi-CPU, multi-core PCs, etc.
  • We need to use languages that let us build new abstractions and new kinds of abstraction.  With such a language, if I wanted something like Herb’s “once {}” construct on slide 17, I could add it.

Weiqi pointed out Herb’s double-checked-locking comments.  I did in fact know that DCL was broken and is now fixed… but have generally sworn off its use anyway.  Life is too short to worry about whether we’re sure the right JVM will be used for each block of code we write.

One nit I have to pick is that the PARC site offers only an “mms://” streaming link for the video… I worked for me this time, but in general I’ve had far better results with plain old HTTP downloads and local playback, particularly if I’m not able to watch all in one sititng.

The J2EE / Rails / TurboGears / etc. Video

Lots of people are linking to this excellent video (presentation and screencast) by Sean Kelly at JPL (380 megabyte, 30+ minutes, worth it):

http://oodt.jpl.nasa.gov/better-web-app.mov

Watch it all the way through. Wow.

It’s a little over-the-top in its J2EE example; but the disparity is still stark… and near to my heart as we have a time tracking web application in development.

But I think he stopped short of a fundamental point: that the benefits of dynamic languages, XML-free convention over configuration, fast turnaround, etc. are not specific to GUIs or web applications; he experienced them there and showed them there, but as far as I can tell the same issues and benefits apply equally to the non-GUI tiers of a system.

Sea change in Web vs. Desktop Development

In the late 1990s, I rushed in to web-app development with a million other developers, following the demand. At the time I accepted that it took more work to get a web app working than a desktop app, using the tools of the era.

But looking at Ruby / Rails and TurboGears:

http://www.turbogears.org/preview/docs/tutorials/eajaxtg/paper.html

It strikes me that it is now *less work and less code* to get the functionality shown here working in a web app w/AJAX, than it would be to get it working in a rich client with Swing or in a multi-tier application in Delphi. The idea above that desktop client apps are less work than web apps, is no longer true. We are now paying a penalty when we choose to create non-web-apps.