I have to admit I haven’t been dealing with the “machine meditation” idea I used to play with rather often back then, on Flickr, before it eventually became a place not that much fun to be anymore. At the moment, one or the other ’round here (?) might have noticed, the frequency of picture posts on this page has somewhat decreased, as well… which is to a certain degree due to the fact that my day-job projects these days are (fortunately…) pretty challenging, leaving little time for much else… and, to some degree, it’s also due to the fact that I am sort of unhappy with the tools at hand… I do not really want to completely move to a platform like Flickr again, for obvious reasons. Same way, however, I do not mainly and only want to post images as Manu (@calacirya.de) does, so I stopped using / maintaining my PixelPost installation a while ago, same as I didn’t want to run two different installations / tools anymore… just to end up learning that wordpress, though generally capable of doing so, still has a bunch of disadvantages being (ab?)used as a photoblog engine. Oh well… whatever. I’d better stop ranting and enjoy the music…

I have just recently sort of fallen in love with the visual appearance of urban lighting, with the “contrast”(?) of dark concrete/steel facilities, rusty installments to spread clear, clean, warm light. Does it look warmer at night when you don’t see the rust and the dirt?

… so in the end it took me a while to, finally, deal with “stupid summer dreams”, their latest output released earlier this year, more in-depth. And, actually (not surprisingly?), Botany Bay once again managed to be “better” than on their previous outputs. Much to my interest, they manage to excel in something I didn’t expect to be difficult, a while ago. Now, while the internet is overflowing with interesting experimental, intellectually challenging music, creating acoustic art seems not that much of a problem anymore compared to the idea of making deep, intense, demanding music which still is in accessible, melodic, in some way even “pop” in the best meaning of that term. Right this is what Botany Bay are really great at: The former twopiece which, by now, seems to have grown into a collective of inspired and active musicians, made “stupid summer dreams” an album which one can easily listen to, an album not really disturbing and, in some way, an album that seems to suit a summer day indeed… And yet, taking a closer look (listen), the music seems more dark, dense, intense than Botany Bay appeared to be ever before. Not too much different in general style, somewhere in between Pink Floyds “Division Bell”, Queensryches “Promised Land”, Alphavilles “Prostitute”, Airlocks “Symptomatic” and a whole bunch of other inspirations, “stupid summer dreams” generally seems a little more “trip-hop” than ever before, and, reading titles like “keep breathing”, “nineteen years later” or “take cover” (or the album subtitle “…an epilogue”), eventually also way more melancholic than ever.

Balancing between pop, rock, between reminiscences of soundtracks Angelo Badalamenti used to make for David Lynch movies and popular musicals (both in “take cover”), Botany Bays “stupid summer dreams” is something I like to think of as “music noir” – maybe a collection of tracks, of music made from images of dreams and visions guiding an imaginary main actor in an imaginary movie through a strange and thoughtful night, ending up knowing that it’s still some hours for the new day to rise. Overally, “stupid summer dreams” is an exceptionally strong musical performance, done by musicians who definitely know what they’re doing, and, in many respects, way better than anything wearing the “pop” label on the mainstream market these days. As the album is freely available on jamendo.com (CC-licensed), checking it out definitely is worth it… maybe buying the “physical” CD that comes with a visually very appealing cover inlay, too. :) Great album, for sure making one look forward to all the things to come in the world of Botany Bay.

Getting the tools ready

Given the fact that I’m on Ubuntu 10.04 beta on my everyday working notebook, though, running “Microsoft” .NET was not an option. Fortunately, there’s Mono, an open source / software libre project aiming to provide a compatible, portable implementation of .NET for platforms not supported by Microsoft (which is any platform other than Windows, actually). In my Ubuntu installation, as well as in most other GNU/Linux distributions out there these days, one is just a few moments of package manager interaction away from having Mono installed; I personally did so in a rather rude way – by installing MonoDevelop, an open-source IDE for Mono / C#, which subsequently pulls in most of the relevant core mono packages as dependencies. A few dozens of megabytes of package downloading later, things are there, set up and ready to go. So far, so good.

Solving a real-world problem, part 1: integration client

In order to, in our environment, make a legacy (and highly proprietary) document management platform behave well and communicate bidirectionally with other applications / platforms around, we ended up hand-crafting a small “middleware” structure to get this job done. Well, “middleware” is quite an exaggeration for something which basically is HTTP-POST along with a data transfer encoding resembling a lite, stripped-down version of JSON. It’s a pretty bare-bone and rather archaic kind of approach, but then again, it works, it is easy to handle even in this very DMS platform (written in an obscure language in which a more-or-less working TCP socket implementation is the best you probably can get for such a task), and it is a way to easily link many different platforms without having to worry too much about whether or not this approach is supported in the target platform (actually, even unix-shell and netcat eventually would do here… :) ). So doing a few proof-of-concept implementations on top of various languages / frameworks is a good excuse to try the same using C# / .NET. First things first, the easier thing: Building a client posting some data structure via HTTP and dumping the response recieved to STDOUT… Firing up MonoDevelop, if one is used to a Java IDE it takes some time getting acquainted to things, but then again, world’s not all too different here. Creating an initial runnable class is simple, core syntax just slightly different to what one’s used in Java.

So now how to deal with the client side of HTTP? Fortunately, there’s documentation at hand: Along with Mono, there comes “monodoc” which allows for easily browsing pre-installed Mono documentation, mainly of course API reference. monodoc offers a rather good search facility so figuring out that System.Net.WebRequest is what I need. Adding to that, there’s a vast load of documentation available as part of the Microsoft Developers Network (MSDN) library, which, in this special case, offers an almost fool-proof step-by-step guide on how to resolve exactly the kind of problem I need. So overally, getting the C# client to talk to both the DMS and the Java server side of our integration structure took about ten minutes, including figuring out how to, in C#, convert a String object into a byte array. Not bad, and pretty intuitive given the documentation and a good deal of Java experience at hand.

Solving a real-world problem, part 2: integration server

So far, so good – running the client code from within MonoDevelop, or even from the command line, wasn’t a job too tough (even though it feels strange running a .exe file in a GNU/Linux environment… :) ). Now, however, for the server part of things. Given quite a range of servlet containers or application servers (we use Glassfish and apache tomcat for our internal purposes) at hand, a Java developer has quite a concise kind of environment in which to expose HTTP(-POST) services: Extend javax.servlet.http.HttpServlet, override the doPost method, add your code, package a .war file, deploy things to your application server – done. The good thing about Java EE, in my opinion, is that this general workflow does always apply, no matter which application server, development environment, … you are running. But how to do that in Mono/.NET?

So far, I haven’t come across the idea of something like a “generic .NET application server”, akin to what an application server in Java EE is. However, I quickly found out about ASP.NET and mono-xsp(2) server, which I installed using my package management. Fine. Reading the tutorial was rather straightforward, now for some code.

To cut things short: It turned out to be not much more complicated than building the client. Browsing the Mono documentation, and from there the MSDN articles, I quickly came across System.Web.IHttpHandler, implemented it, filled its ProcessRequest method with meaningful code (using code completion in MonoDevelop prove to be a rather good way of exploring the – at least to me – unfamiliar C#/.NET API), running stuff with xsp. Done.

Conclusions…

What to learn from this little trip?

• Well, first off, working with C#, Mono and MonoDevelop is not that much of a pain if you’re used to Java and, given at least this very use case, know what you’re about to want to do. There are tons of documentation available out there, and overally, I guess in most situations getting started with these things should be straightforward.
• As always, learning something new is a good thing, and in case of C#/.NET, I see a strong advantage in linking our existing server-sided environment with desktop-based clients – so far, Java unfortunately doesn’t do that good in terms of deep desktop integration (registering global desktop hotkeys, opening standard applications, …). Throwing in a little bit of local .NET code could ease this at the very least for Windows clients.
• I still have to see how to build a portable, self-containing application server using Mono/C#: Given the nature of .war deployment and the way application servers and JREs can be deployed, it is possible to simply make .zip file of JDK, preconfigured application server along with the applications deployed to it, unzip this file on a server machine, start the application server and have things running as desired – without the need to install additional software, configure system-wide services (apache and mod_mono?) and the like. Comparing this kind of deployment, Java EE still is way ahead of .NET/C#, Python and any other platforms I played with so far.

In the end, that’s what is left: I enjoyed my ride and liked what I saw. I still will be doing most of my work using Java, I still will enjoy working with P/Jython for most scripting things, but I figured out that, in practical use, C#/.NET/Mono is a rather smooth environment to work with, and, as pointed out, there surely are some problems I already imagine for using it… More to come.

Well, maybe it could be easier than that. “Python For Informatics: Exploring Information” is (the starting point of a growing) text book aiming at enabling people to use the Python programming language (known best for being concise, very readable, easy to get started with and, overally, being modestly friendly to starters while, at the same time, allowing one to do all eventually to be done with a programming language these days) for exploring data, learning to solve tasks “programmatically” by writing Python scripts, making use of the many smaller and bigger features this language offers. The book, written by Charles Severance, published under a Creative-Commons license and building upon the foundations of the likewise readable “Think Python: How to think like a computer scientist” offers a straightforward, concise introduction to doing basic things with Python as well as understanding a bunch of basic concepts of computer programming in general and also provides a little more material (audio recordings, slides, …) to make things more accessible to you.

Well… though I still mainly use Java for my everyday productive work, I then and now have been sort of “in admiration” of Python because of its elegance and accessibility and because of, at times, just seeming “a good language to get a job done”. Right now, also looking at the Opportunistic Developer Week held by Ubuntu GNU/Linux community at the moment, and also making heavy use of Python (and the quickly development framework), I see an interesting tendency (or, well, let’s better call it an “option”…) for the future of computing: Make end users more “productive” again. Make creating smaller (and maybe, as well, bigger?) programs as easy/difficult as using a spreadsheet and a word processor, and allow people for quickly sharing and, in a community, growing small, custom projects into larger ones eventually addressing the needs of more than just one user. This really could push forth a whole new culture of contribution and collaboration to open source or software libre which by now, all too often, just seems limited to downloading and installing stuff. And, eventually, it ultimately could end in the set of tools available being broader than ever. Not all too bad, isn’t it? :)

Anyway: One of many fields in which NetBeans these days still does excel compared to Eclipse is building graphical user interfaces using the GUI builder that comes pre-installed with every NetBeans package and even from this point of view is way ahead of the Visual Editor available to Eclipse users, in case of which even installing and getting the bits to work seems an adventure of its own. And here, we’re not even talking about RAP (based upon RWT) which is the “web alternative” and, though pretty complete (and getting better with each release), always lagging a bit behind the “desktop RCP” (based upon SWT) in terms of technology, widgets, … . However, Eclipse then again is a bit ahead from our current projects point of view: The “single sourcing” approach the RAP people are trying to push forth – the idea of having one codebase and run this both “on desktop” and “in a web browser” without too much ado – is really a good approach, well, if you need to cater for both web users who still want a good feature set and to internal users to which using a browser based interface eventually is not an option. Yes, there are quite some drawbacks about the way the Eclipse runtime environment does work and scale when deployed to an application server (in example talking about one dedicated “UIThread” per user session which definitely is not the way people think of doing server-sided Java applications… :) ), but overally, it’s more than so far you can do with Netbeans unfortunately, where you’re left with either doing a desktop (Swing based) application or a web application using some framework for this purpose (JSF, Wicket, …). Works, but one of the ideas you want to address when considering single-sourcing (having programming models as well as user interfaces as close to each other as somewhat possible for web and desktop) falls short here. There have been numerous projects trying to make Swing a web application platform too, but most of them seem discontinued, and none of them integrate well with the tooling one is used to (and enthusiastic about :) ) in NetBeans.

And, talking about e4, the next major version of Eclipse IDE/platform, the current status quo might become even more apparent: e4 comes with XWT, a technology to allow for declarative UI description using XML file definitions rather than writing code, allowing for, well, “declaration” rather than coding of user interfaces, which has a bunch of more or less obvious advantages. Not that this idea is generally all new (just consider XUL used by the Mozilla applications), but along with the “usual tooling” to be found in an IDE like Eclipse, this might turn out to be a rather impressive feature. First demonstrations, like this screencast showing the visual editor for XWT, leave one end up with expectations rather high. So let’s wait and see…

… both what Eclipse people will keep on doing related to XWT until e4 is to be released, and what Oracle is likely to do to Java technologies like Swing or maybe JavaFX. Maybe the latter one might be an interesting alternative if integrated with web and desktop environments and the appropriate tooling. I am curious to see things proceed, talking about both technologies…