When I used to work in LBi we used intensively Eclipse to develop in ActionScript with FDT plugin. In FDT at that time wasn’t possible to debug the application a la Flex, so the main support was still the old trace in the log file. When the application gets bigger, though, the traces increase and gets difficult to differentiate visually one from each other. For this reason I created an Eclipse plugin which permits to log files assigning different styles to the traces, it has been named LBi Logger and it can be downloaded here.

The plugin has been developed mainly during my working hours there and also because it is very branded, I don’t see so many possibilities for me to develop it further (since I don’t work anymore for LBi). At least, different people found it already very useful and hopefully it can still be handy for many others.

It’s an open-source project part of an ambitious initiative at LBI called LBi Useful (unfortunately almost all the initial contributors left since then).

The plugin project page is here.

Operating System

When it’s about delivering a full solution, the OS is definitely an important part. Not only because the eventual cost of the license, for instance the Windows’ one, but also for the time you will have to spend on setting it up. Linux distributions are getting incredibly complete and Ubuntu, of course, is a good example. To set it up as second boot option on my old laptop was incredibly quick, especially with the 6.10, and having it working was much faster then setting up Windows. The cool things of Linux though, is that you can have LiveCD. In very few words, is theoretically possible to put in a USB key a generic OS and our custom application so that any machine could run our software in few minutes without any need to setup, pretty amazing.

Development Environment

For this kind of stuff I used to use Processing + OpenGL, like in bb-write, and so the first tests have been developed with it.
Adding complexity to the application, the performances start struggling. Usually it shouldn’t be a Processing’s issue, since it works just as kind of wrapper to OpenGL, but since in the past (link) I noticed a remarkable decrease of performances between the 92nd revision and the 107th, I can’t exclude it.
A lower level alternative to create executable could be C++, which I used during the OpenFrameworks workshop I attended at Ars Electronica this year. If I want to stick with Linux though, I should set up an IDE to deploy in Linux and we know how odd is to switch IDE in C++. The compatibility issues that changing a compiler could generate are very painful.

Programming Language

If I want to be able to switch easily from one OS to another I definitely need a higher level programming language. Two that don’t use any Virtual Machine, and so could be very tempting for their simplicity in setting up the PC, are Python and Ruby. They are very modern languages comparing to C++ and Java, and their interpreter generates temporary the bytecode so the application can run natively on the machine.
I have been totally shocked about the simplicity on creating a standalone application that use OpenGL with Ruby. In Python instead my attempt has been a bit of a nightmare, too many libraries dependencies and only one incompatibility can increase the pain considerably. It’s very difficult to say which is better between Python and Ruby, Python has so many libraries and Ruby is getting very popular recently only because of Rails, but the simplicity on deploying gave me a clear example about the quality of the architecture behind.

So this long post was only to say that at the moment I’m investigating both on Linux and Ruby, two technologies that seem to have great future.