In a totally (by me) unexpected move, Unity 2.6 was released today and the Indie version (normally $200) was made free! Wow. I am pretty shocked. Unity Technologies is offering a refund to those of us who purchased Unity Indie and also giving discounted upgrades to Pro and iPhone versions of the app. Pretty nice deal. If you’re into game development it’s worth taking a look at and now that it’s free there’s no downside.
Category Archives: Development
Today is officially the last day I will be an IT professional. Starting tomorrow (well, really next week) I’m a full time educator and part time assistant adult hockey league director. Of course the topics that I’m teaching are IT related, specifically software engineering and graphics programming, but I won’t be doing it full time anymore. This is both refreshing and terrifying. I’ve been doing IT pretty much straight through since I got my first job at 17 helping build out a startup ISP. Now I get to change gears. Instead of tech being what pays the bills, tech gets to go back to stuff I do for fun, which I’m hoping will mean that I make progress on the many stalled projects I’ve had going for weeks/months/years. I’m not sure what career #2 is going to turn into but I’m sure tech will sill be there, hanging around as it’s been all my life.
The video of the IGF awards are up. As usual, it’s packed with amazing inide games that deserve your support. This year is rather special (for me) as the content directors are local indie developers Matt Wegner and Steve Swink of Flashbang Studios. Also, another local indie Dan Tabar won 2 awards for Cortex Command! Yay Phoenix indie game developers!
Mark DeLoura posted a very interesting article about a survey he conducted regarding licensed game engine usage. Some interesting parts are that 50% of respondants that use a scripting language are using Lua and that most people using a licensed engine would rather not be. This probably ties into the 30-ish % of respondants using a custom scripting language (the second highest value). So, scripting languages are still something you can get away with building yourself, (even though yours will probably suck), but game engines have moved off into the “don’t build here” realm. One encouraging thing was tha together, Lua + Python comprised about 65% of the scripting market, with “custom language”, (aka major suckage), and C/C++ variant clocking in at almost 30%. It’s great to see Lua doing so well but in reality I think its integration into most C++ apps is as a veneer over the C++ classes the developer wishes to expose. So in the end it can often turn into “a nicer syntax for C++ classes”. This was a multiple selection survey response so there is perhaps some overlap in the two camps but the overall usage of Lua over a C++ inspired script is encouraging and the decent showing of Python (the only general purpose language on the list) was very encouraging. No Ruby in the linup yet, but it’s still pretty raw in the embedded space so that’s not a big surprise. Hopefully 1.9 and (more likely) Rubinius will change that situation and make Ruby scripting in games a reality.
Several months ago a survey was started to find out what people are using for GUI development and what they’re looking for from the various toolkits. Well the results have been published and you can look them over for yourself. Apparently JRuby/Swing aren’t exactly taking over the GUI development landscape, although I’d like to see the results from just developers pursuing commercial applications as I believe many of the GUI toolkits (such as Shoes) simply are not usable for this use case.
It’s been a few weeks since the announcement that Rails 3 would be Merb 2. We had a discussion on our local Phoenix RUG list, my input to which is here. Then I dug around some more and read the posting by DHH.
This is not a big bang rewrite
So, Rails 3 will be Rails 2 + some unspecified but core stuff from Merb moved over. And Merb 2 will be … ? If you’re a rails developer, this is probably not big news in any way, just wait for Rails 3 to be released (or RC status) and figure out what breaks, if you intended to upgrade at all. However, if you are a Merb developer, or about ready to pick up Merb (like me) this puts you in a pretty bad spot. Do I learn Merb for all its touted benefits of lean execution and component agnosticism? Well I could, and then later this year re-learn all over when the API’s change in Rails 3. The Merb community is saying “come to Merb, it’s like getting a preview of Rails 3″.
That makes this training basically the first training focusing on the future features of Rails 3, and a great way to get ahead of the game. – Yehuda Katz
Except that this is not true. The Merb API will change when it is merged into Rails. ActiveRecord is remaining as the default ORM layer and I am positive that other Rails elements will persist. Merb will be Railsified I think as much as Rails will be Merbified. How do you withstand hundreds (thousands?) of plugin authors shouting at you to not break things. I don’t even want to imagine the compromises that will be made when all the users catch on to the idea that lots of API’s will be changing.
Unfortunately I think a clean break is the best possible solution. Merb was started because Ezra claimed it was far easier to rewrite portions of Rails than try to fix the existing code. Heck, Merb itself was rewritten from scratch recently with no apparent universe imploding effects so they’ve proven it can be done on a large code base. Yet we have the situation where DHH will not let go of Rails (his code) to make way for what he to some degree is acknowledging as a better solution. So my grand hopes of a stack that has all the marketing and acceptance of Rails but the clean implementation of Merb deflates daily. Moreso, my desire to learn Merb drops to almost zero, I might as well stick with Rails since a) I know it and can move much quicker, b) The Merb API is going to change anyway, c) I suspect we’ll end up closer to Rails than to Merb in the end, at least on the surface.
Today JotBot was released. This is, to my knowledge, the first commercial desktop Ruby application. The web world has been invaded by Ruby, Rails and the crop of post-Rails web frameworks (Merb, Ramaze, Sinatra, etc.), but the desktop world remains largely untouched by Ruby’s rising star. This post mortem explores how Ruby fares for creating desktop applications and our experiences at Happy Camper Studios in developing our first commercial product, JotBot.
Project rational and tool selection
Purpose: JotBot is a desktop-based time tracking app that uses a “pull” model. That means you don’t remember to go log your time, instead JotBot comes to you at a configurable interval and asks you for a time log. (If you want to get a feel for the app, there’s a quick tour video on the JotBot home page that shows off most of the features.)
JotBot prompt
This project was started by me, as a side project because I couldn’t find anything that did quite what I wanted. The “pull” nature of JotBot was something quite important to me as I have a bad habit of getting distracted. I was doing contract work and needed to have accurate time logs for billing. At one point I used a timer that auto-reset and was on a 15 minute interval. When the timer went off I’d go log what I had been doing for those 15 minutes. This is basically what the first version of JotBot replaced. It worked well enough that we decided to pursue a commercial version as a company.
Platform and tool selection: At the time I was doing Rails development so of course I considered doing a web app initially. What I quickly found was that I didn’t want to always have my web browser open to a certain web site. Even when I did have my browser on a given site, that web app getting my attention was severely limited by the browser. If I was on another screen (at the time I was a Windows user but I still heavily used multiple desktops), you could just forget getting anything that was going to grab my attention via the browser. So I decided it was probably best to go the desktop application route.
At the time JRuby was reaching a fairly mature and stable point. I was doing a bit of Swing work for a client and was able to leverage JRuby where possible to make the job easier. This work was proving quite fruitful so I decided to go with Swing + JRuby. This eventually lead to the Monkeybars project which grew up alongside my client work and JotBot’s development. Before I get flooded with people saying I should have gone with framework X, let me state that yes, I am familiar with Tk, GTK, wxWidgets and Fox having evaluated them all at one point and none of them solved my problems as easily as JRuby + Swing promised to. So, with those tools selected my development stack became: JRuby driving the app logic calling into Swing and other Java libraries utilizing the Netbeans GUI editor for my form layout and the Monkeybars and Rawr libraries for the primary infrastructure of the application.
What went right
Over the course of the project several aspects of our chosen development setup stood out as very positive contributors to the success of the project. In no particular order
- Running on the JVM via JRuby meant that our code “just worked” on OSX, Windows and Linux. At various times we had people working on each of these platforms contributing to the code base as well as just running the app on a daily basis. Not having to ever build a platform specific dll or so was very nice and knowing that our interpreter was very stable from platform to platform also meant that time spent chasing down platform specific bugs was very minimal.
- Easy access to very cool app bundling tools. This gave rise to the Rawr project which can produce .exe or .app files for native looking distribution. More importantly you can generate all of these from any platform (Linux, Windows, OSX). Once we had our rake tasks in place, it was a simple matter of “rake installer:win” and bam, I have a versioned installer bundle I can upload to the website. The .dmg bundler was the one exception, that uses Apple provided tools and can only be run on a Mac.
- The GUI editor that comes with Netbeans make layout very easy. Being able to see our forms and tweak them out in a rapid prototyping fashion was extremely handy. Lines of Java code we wrote or maintain by hand in JotBot: zero.
- Ability to integrate with the desktop via JDIC. We decided early on that JotBot really should be an app that lives in the “system tray”. This presented some problems for Swing as it doesn’t have this ability natively (at least pre Java 6 it didn’t). Thanks to an active Swing community this problem had been solved for us via JDIC, the Java Desktop Integration Components. Their system tray support allowed us to look native on OSX, Windows, Gnome and KDE with almost zero extra work from us.
- Monkeybars matured and made Swing fade into the background. Creating a new form and adding some event handlers became so ridiculously easy I have to think hard how I even did it before. There are still rough points here and there but for the most part, Swing is tamed and the common stuff is wickedly fast.
What went wrong
Of course the project wasn’t all sunshine and roses. We ran into several late term problems that caused not insignificant delays.
- Active Record, our original ORM choice, did not play well when the Ruby files were compiled in a jar. I plummed the depths of AR for days but was unable to even find some of the meta-added methods that were failing. I’m not an AR expert and I didn’t feel like becoming one, so we decided to switch to a less “magical” ORM system. We couldn’t use DataMapper because their core Data Objects library is written in C and I was cautioned against using the existing Java conversion. So we settled on Sequel (possibly the worst named library EVAR!). We had been using Derby with Active Record which had worked flawlessly, unfortunately Sequel doesn’t support Derby. I looked into adding support but when I found out Derby doesn’t support the limit key word, the implementation of .first became significantly more complex. Faced with the choice to do non-trivial work on Sequel or pick something that could be supported, I opted for the latter. We settled on H2, a pure-Java SQLite like solution. We did have to create an H2 adapter but it was a matter of overriding 2 or so methods and was done in an afternoon (code posted here). So we went from Active Record using Derby to Sequel using H2. Very few bugs were introduced by this changeover which was incredibly encouraging.
- The Group Layout is not the best at making your forms look native with regards to spacing. Group Layout is what the Netbeans GUI designer uses, for those not intimately familiar with this stuff. We love the GUI designer, it is incredibly valuable, but the layout system leaves a bit to be desired. We designed primarily on Macs and there most things looked fantastic, but on Windows there was often a bit too much extra space. We took pain to make sure almost everything was dynamically sized, so that there was never accidental “left over” space from a component we sized on the Mac. In the end I’m reasonably happy but I often wonder how something like MiGLayout would have fared.
- Packaging up a Ruby application in a jar file is not something most Ruby libs are prepared for. We had some path issues that took time to resolve. Things like file:// getting prepended to the path to a file in a jar file when referencing __FILE__ with or without various expand_path shennanigans. We have bits of code that correct for this, but overall it’s probably one of the most “raw” parts of JRuby in terms of cleanliness. The rest is so fantastically good, paths to files in jars and such jump out all the more. Like with the compilation of Active Record classes in a jar file, these issues came up late in the dev cycle when we were preparing our installer and bundler tasks. Some of these issues have been resovled now so I would expect the next time around for this to be less of a pain point.
Conclusion
So would I do it differently if I was starting again? I firmly believe that JRuby is the way to go for ease of packaging and disribution, not to mention for access to libraries. Swing vs SWT is sort of a contentious topic although I think in the end Swing is available in more places and has more general support and a greater variety of 3rd party components available (we used several SwingX components such as JXLayer and JXTreeTable). Monkeybars was built on Swing but could just as easily support SWT if the demand was there. Speaking of Monkeybars, the choice to build a Ruby helper layer was definately the right choice. The amount of work needed and maintainability of our code before we switched over from the initial raw Swing calls to Monkeybars compared to afterwards was striking. Getting even just a few key pieces of Monkeybars in place dramatically reduced the code we needed to write and its complexity. I highly encourage anyone doing Java integration work to take your top 2 or 3 pain points and spend a bit of time to make them just go away. I did the initial event handling registration and routing code in Monkeybars in an evening. Those 20 lines saved us hours upon hours of work and reduced our code’s complexity significantly. Small things like that can have huge impacts on your project so get them in from the beginning.
I think in the end JotBot demonstrates that doing high quality desktop applications in Ruby is viable today. There’s still lots of apps that can’t / won’t be good web apps, why shouldn’t they be written in Ruby?
EDIT (19 Jan 09) – Added link to H2 adapter code on Rawr mailing list.
A fairly comprehensive benchmark test has been run across all available (and even some pending) Ruby implementations.
JRuby continues to be the fastest 1.8 compatible implementation by quite a long way.
