[ insert super-cool blog title here…]

With the recent release of Mono Develop 1.0, moving a bunch of my personal C# projects from my laptop with Windows XP to my living-room Apple iMac (Mac OS X) suddenly seemed like a very good idea. Mono is as you all know an open implementation of the Microsoft .Net framework.

With a new job soon coming up, its time to brush of some of the C# sample code I´we written, and have easy access to a sandbox where I can explore more aspects of C# and .Net. Its been all about Ruby for more than six months now. The previous .Net project I participated in had its peak around a year ago. And in June this year, I have a new job, with a different company. I am really looking forward to digging into what appears to be a very interesting application domain, a large-scale .Net API and applications in the Oil & Gas industry. Anyhow, this post is about MonoDevelop, and not my new job…

The Mono installer took care of the whole installation, no hick-ups with X, Gtk+ or anything else (Mono is a very Gnome centric project?!?) Mono installs nicely under /Library/Frameworks/Mono.framework and the MonoDevelop and MoMA (migration assistant) applications are OS X Application icons, dropped in the applications folder. Then simply create a default C# console application to test the installation, and we are done!

Next step will be to run the MoMA application, the Mono Migration Assistant, on my projects. To be continued…

GUT’s - Good Unit Tests. Yes, I think I like it!

The background of the debate is whether or not unit-test is considered GOOD if is written prior or post to the implementation of functionality it tests. Alistair Cookburn has some valuable input in the debate, go read his entry in the link I provided to catch up on the subject.

Regarding my own unit-test’s; I sometimes find that writing tests prior to implementing the class/function to test, leaves me with a different architecture/design then what I would have if I created the test after the class/function. Design and software architecture is more or less imposed on us from the circumstances that we develop under. Hence, unit-test can or can not impose a certain design on the classes and functions we create. Sometimes the design imposed from unit-test’s is a good thing, and sometimes its not. Sometimes a test-application approach is a good way of evolving a good design, not a unit -test. This issue requires Pragmatism! What is the potential value of Good Unit Tests?:

1. Is it the road towards the unit-test (TDD or any other formal design paradigm)?
2. Is it the the final unit-test itself that has potential value?

My vote goes to the second, but not without acknowledging the first.

GUT’s is a term missing in the vocabulary, that says something about unit-tests and their quality without emphasizing too much on the design paradigm used to get to the final result.

I have spent considerable time implementing a data-abstraction layer based on ActiveRecord for a web application I am creating. And now I have finally decided to abandon ActiveRecord. The library itself is a mess to work with. The over-simplified approach to a “web application” that Ruby On Rails seem to have is reflected in ActiveRecord. The same goes for the ActiveResource library. The magic stuff behind the curtains makes it incredibly difficult to create a fit-for-purpose architecture for my particular web-app. Which by the way is not the standard blog/wiki/cms/shopping-cart illusion of a web-app that Rails apparently is based on.

A web application framework should be about supporting the needs of that web application. Not try to push it into a model that is a compromise based on the average of common web application, and maybe not what YOUR particular web application really needs. The “create {insert your application of choice} in 15 minutes” is not a valid argument.

Anyway, I spent some time trying to implement the Og object-relational mapper from the Nitro project. Its by far better with regards to design, flexibility and source-code layout. Despite its severe lack of documentation, I still prefer it to ActiveRecord. Actually, comparing the two might no be fair; they take a different approach to the object-relational phenomena, where Og is more about Object -> Relational mapping than ActiveRecord, which is more about Columns & Attributes. ‘Nuff said, you have to make up your own opinion related to the kind of web-app you are writing.

Apart from spending time on implementing, and managing a mess of gems and libraries, it’s sad to say that the average libraries in the sphere around Ruby are at their best inconsistent. The gems them selves are somewhat a pain in the ass; matching Ruby gems with the Debian package management has resulted in a number of conflicts on my Ubuntu machine. This little notice from the Debian community comes to mind.

Don’t get me wrong on the Ruby side of this rant; Ruby is a beautiful language. The eco-system around it is quite ok to interact with. It’s the quality of libraries and packages coming from that eco system that has a long way to go to reach maturity. In the mean time, I’ll keep hammering the Og package and see where I go from here.

Instead of upgrading to Ubuntu 7.10, I decided to go with Xubuntu 7.10 for my VMWare Workstation 6.0 virtual Linux development environment. Xubuntu is lighter and faster than Ubuntu, using less of it’s host’s system resources. Still it provides the necessary eye-candy required to run Firefox, Emacs, NetBeans 6.0 and a terminal window. The big difference is the Xfce desktop environment:

“Xfce is a lightweight desktop environment for various *NIX systems. Designed for productivity, it loads and executes applications fast, while conserving system resources.” - Olivier Fourdan, creator of Xfce

There’s a significant increase in overall desktop performance while running inside a VMWare Workstation 6.0. Ubuntu 7.04 was running OK performance-wise,.. but xubuntu is even closer seamless virtualization of the linux desktop.

On December 25th, a development release of Ruby 1.9.0 was released. The new release is has a number of features and enhancements which will boost ruby further more into mainstream enterprise software systems.

According to Dave Thomas, this release is a rough-in-the-edges development release. He suggests setting up a separate 1.9 sandbox, isolated from the stable 1.6. I am preparing a new virtual machine for 1.9 on which I can test my code-base and prepare for the transition.

Dave is working on a 3rd revision of the Pic Axe, which targets the 1.9 release. This is a book I really am looking forward to. I had such a good time reading the second revision of this book; my expectations are sky-high.

I have spent some time evaluating ORM’s for my sand-box project, ‘rWMLS’, a Ruby implementation of a WITSML Server. ORM’s are in general quite interesting due to increase in productivity, the abstraction of Domain Logic from the Database, and the (not allways?) helpful effect it can have on formalizing the design of the DAL (Data Access Layer) through more or less established patterns.

The current state of data back-end in rWMLS is native Ruby objects initiated from a set of unit-tests. In other words; it has no real data back-end. As development is slowly moving ahead, time has come to implement a Data Access Layer with a storage persistence solution. I started this out by implementing a simple home-made SQLite interface. This approach has served me fine for some time, and has been an interesting learning experience.

Then, I made an (un-blogged) decision to move my rWMLS server implementation away from the SOAP interface as described in the WITSML API, and go for a RESTful implementation. (ROA - Resource Oriented Architecture might be a better definition.) I got introduced to the idea in 2005 when I first met Hugh Winkler who spent a considerable amount of time tutoring me on what the web is really all about. He has a proposal for a RESTful WITSML approach, and a suggestion for a formal API which I have been using as a guideline.

The REST model made me re-think some of the internal software architecture as a response to structure all accessible information entities in the server as a URL resource. Suddenly the architecture got a much more clear and obvious layout - with a lot more structure to it than it had before. I don’t really know if this is a result of the REST model itself, or simply just me iterating the design one more time . . . ? Anyhow . . .

Structure can easily be defined as rules, and rules can easily be implemented in a programming language.

There are a few good candidates for ORM’s in the Ruby sphere, Sequel, OG and ActiveRecord ++. Martin Fowler’s design pattern ‘Active Record‘ is a very appealing concept, and the ActiceRecord Ruby implementation by DHH is said to be quite good, despite the fact that ActiveRecord is a very RubyOnRails centric project. So, this is where I am at right now:

• Evaluating ActiveRecord and creating a WITSML –> REST –> AR mapping
• Evaluating the ActiveRecord::Migration feature to possibly generate schema definitions for the ORM to operate on.

To ORM or not to ORM is not a question anymore.

Then, the mighty Python is always lurking in the background. SQL Alchemy is the most interesting ORM I have seen so far…

My VMWare Workstation 6.0 Ubuntu virtual machine failed today, after being used almost every day for over 6 months.

By accident I closed the lid on my Dell/XP Laptop, and forgot to turn the host OS of properly. The laptop ran out of battery power, and an open VMWare Workstation virtual machine crashed upon me. No matter how I tried to reboot or manually kill all vmw* processes, the vm wouldn’t turn back on. I took a look into the file-system of the vm, and found a catalog named your-vm-name.vmx.lck . Inside the catalog there’s a LOCK (*.lck) file with a lock from the most recently started session. This file is supposed to be deleted when the vm is suspended or powered of. The abnormally terminated VMWare session failed to delete the lock file. Manually deleting any remaining lock files solves the problem with the vm that wouldn’t start.

So, I have a simple solution to a simple problem, and I have a successful milestone: six months++ extensive use and just one failure. I can only salute my previous post (which was a long time ago; I am not a very reliable blogger, am I?). The VMWare Workstation 6.0 is a great product for my kind of use;

• I have a job that requires an array of Windows tools
• my passion for computer technology and software development is in the Linux sphere…

The perfect tool; no more dual booting - I can have the best of both worlds available at all times.

So, when corporate meetings drag out and get tedious, its soo easy to start a virtual machine with my favourite linux distro and pull up a ready-to-go Ruby development environment...

My last post, ‘RubyGems fails on Cygwin‘ refers to the fact that I cannot maintain a linux environment as my primarily OS; I am stuck in a job where I depend on Outlook, a crappy MS Access database legacy application, Visio, Altova XML Spy, Mindreef SOAP Scope and MS Visual Studio. So, emulating the most important part of a linux workstation, the shell (Bash happens to be favorite..) could easily be done with Cygwin. But its not a replacement for the real thing…I have had various Linux distro’s running as VMWare GSX virtual machines for a while, but there has always been issues preventing me from going virtual full time. Until now.

The latest beta of VMWare Workstation 6.0 is awesome! Performance is noticeable improved over the freely available VMWare GSX Server. Sure, it’ll cost money when it’s finally released, but I am seriously considering it as my main environment.

The computer I use is a Dell Lattitude D620, (Dual Core, 2Gb RAM). XP does a decent job running the VMWare Workstation with 1Gb RAM; and the Dual Core processor finally was worth it(?), it appears to balance the load from the virtual machine quite well.

Ubuntu 7.04 is now easier than ever to install; it now supports the proprietary NVida graphics card with the odd 900×1440 resolution out of the box; no 915resoultion drivers to tweak. Even the VMWare Tools installed flawlessly, and the drivers provided by VMWare does a good job on my Ubuntu 7.04.

Cygwin brings the Power of Unix to the Windows arena. With the recent emergence of E Text Editor for Windows, hacking Ruby on Windows suddenly seems like a good idea.

A really annoying bug seem to appear when you install Ruby in Cygwin; Ruby fails when you try to invoke it on a *.rb file. (It works fine when you do a ‘ruby -v’, though). It appears to have the environment variable RUBYOPT=rubygems preset, regardles of RubyGems not being installed. Trying to install RubyGems will possibly return this error:

ruby: no such file to load — ubygems (LoadError)

A workaround to this problem is simply to unset the rubyopt variable:

unset RUBYOPT

Now, go ahead and install RubyGems,.. problem solved.

The inevitable Linux community battle between the KDE or Gnome desktops has occupied my mind for a while,… again.

My conclusion is that it’s all about the application’s. Which in my case currently are F-Spot for photo management, Banshee for my mp3/ogg’s, Gaim as messenger, GVim for programming & editing files and Gimp as my digital darkroom. And my desktop of choice is … Gnome!

Why? Most of thee app’s are Gnome/GTK based, and are by default integrated in the Ubuntu default Gnome based distro. The desktop behaves nicely, without to much overhead, without consuming to much resources.

Another thing that adds on my enthusiasm for Gnome is the Mono take up in the Gnome community which has been awesome! I am a .Net developer and I like the .Net framework and the C# language a lot. And being a Linux geek, I am very happy to see the incredible speed which some really significant .Net Mono app’s has proven themselves to be real killer app’s.

The next application that potentially will be added to my stack of favorites is Gsvn, a Subversion client for the Linux/Gnome environment, implemented in Mono. It’s a fairly young application, but what I have seen so far promises a lot.

A programming language is a tool, at least when being pragmatic about it… But, the attributes of a tool tend to impact the way a piece of labor performed by a tool. At least for me it does (which probably tells more about me than the tool I am referring to?)

One of the things about Ruby I like the most, are its iterators. They are amazing, and I use them as often as I can, wherever I can!

objects.each do | object |

if object.id == id

object.do_something

In my sandbox I play a lot with a XML based CMS server API (WITSML). I have a bunch of domain objects (derived from XSD’s) which I do CRUD’s and other typical CMS stuff with. So, in my Ruby code I manage arrays of objects with these neat iterators. And it works great.

Now, while playing around with Python recently, I find its Dictionaries just as as appealing as the Ruby Iterators. Yes, these are two different things; and they both have equivalents in both languages and whom am I to compare them? Its like comparing a strong double-sided adhesive tape with a nail-gun? Anyhow, I ended up rewriting some of the Ruby stuff (implemented as the snippet above) with Python Dictionaries:

objects[id].do_something

Having (and wanting to use) the nice features of Ruby Iterators available, I ended up with my objects in arrays, on which I can spin my iterators and do all sorts of neat little things with blocks and lambdas and such. And now, given the very appealing Python Dictionaries, I ended up managing my objects in Hash tables, using the objects Id as a immutable key. A change in design that probably should have been there in the first place? And a change in design that easily could have been implemented in Ruby as well, since Ruby actually has a very complete set of Hash table tools….

Lessons learned? The book: ‘The Pragmatic Programmer: From Journeyman to Master‘ is persistent about its rule about learning a new programming paradigm every year. New perspectives, new ideas, new ways of doing the same thing… Next year I’ll might rewrite the whole thing in … Scheme maybe? Or maybe as a DocBook based REST server implemented in Perl and XSLT?

I did it! I have upgraded my Ubuntu 6.06 to 6.10. And my dear computer survived the upgrade, despite all the reports about failed upgrades.

But it has been a few days in pain & agony over the upgrade… the whole thing started last Friday. I initially tried to upgrade according to the official upgrade note on ubuntuforum.org, which failed during the install. The process froze over and over again. After a reboot the system was back in 6.06 again. Then I decided to do a clean 6.10 install – format all partitions except my /home and start from a clean system. That option failed upon me – the Live CD wouldn’t start the X Server and I got impatient while looking for workarounds. So, I re-installed 6.06 and the started the 6.10 official upgrade path (one more time) from a clean 6.06 system. And this time it actually worked.

A few disappointments surfaced after the install; Python 2.5 is not included – likewise Ruby 1.8.5 is not included. Correct me if I am wrong, but I kind of figured that these (significant) changes to core Linux tools would find it’s way into the 6.10 release. (Well, Ruby might not be considered a core Linux tool, but Python sure is!). Anyway, I’ll simply add these increments myself.

This weekend I will have a go at my home-office box. The 6.06 installation has a flaw in the Gnome installation which I have had problems fixing, so I am considering a clean install. I hope the X Server will start….

My confidence in Ubuntu hasn’t actually dropped that much, but I am surprised about the way the 6.10 upgrade has been handled. And I am sure that this thing will not happen again.

I have spent 3 years with Ruby by now and enjoyed it a lot. During these years I have done quite a few neat little things with Ruby - and learned a lot from playing with it. The Ruby community is friendly, helpfull and very creative. The same goes for the language itself.
I have done a series of personal tools for extracting reports, spreadsheets and databases from XML/XSD files, I have done code generators for Ruby and C# from XML/XSD data and I have made various implementations on parts of the WITSML API. Using a dynamic and light-weight language as a modelling tool has totally changed the way I think and work as a software engineer. The next thing I want to explore with Ruby is Testing in the C# environment I work. Ruby has become one of my main tools.

So, why Python?
The past month I have looked a little at Python. I am still not really sure if I want to proceed with Python… Why it came up in the first place?

• Learn something new (a new programming concept!) every year. (ref Pragmatic Programmers)
• Python 2.5 is the ‘mature 1.0′ release for Python, where Python finally gets the enterprise status it deserves. (Personal observation, not subject to flame-wars…). The state of Ruby is not that mature, and a certain level of significant changes are likely to occur for several years, at least until the 2.0 release.
• Python seems to be the way to go with MS .Net CLR. (The company I work for is mainly a MS shop…)
• My new personal project, a “WITSML Realtime –> WellLog” mapping tool, is of such nature that I might benefit from a somewhat more mature, extensive and faster XML and SOAP toolkits compared to what’s available in Ruby.
• My current personal project has a fairly long perspective - I don’t know what (or when) the Ruby 2.0 release will bring - as opposed to Pythons more mature community.

There has been some buzz related to the future of Ruby after the RubyConf2006. Reading various blogs ( I know, they are not the infinite source of cosmic wisdom…) like this one, The Impending Ruby Fracture, nurture my idea about flirting with the mighty Python…

I attended a CSM class with Mr. Jeff Sutherland in October 2006, at JAOO in Århus. Learning SCRUM from one of the original masters was a very inspiring experience. SCRUM is no Silver Bullet, but it sure is a powerfull bullet.., which I hope to get to use in my profession as a software developer.

September 13th is the 256th day in a non-leap year. Happy Programmers Day to all of you! (… if this doesn’t make any sense to you at all, don’t bother asking. Simply keep on surfin’ …).

The goal of this pet-project is to develop a Ruby implementation of the WITSML standard.

‘Wellsite Information Transfer Standard Markup Language’

WITSML consists of a set of XSD schema’s and a SOAP based API. The standard is developed and maintained by a Special Interest Group, the SIG community, which has regular phone conferences and meet in person twice a year. The documentation that comes with the standard not very comprehensive; there’s a lot of undocumented and tacit knowledge amongst the SIG members. Another goal for rWMLS is therefore to capture some of the undocumented server behavior and make it publicly available through a open-source project.

The WITSML API has two parts; the WMLS and WMLP interfaces; rWMLS implements the WMLS part, limited to the ‘getFromStore’ and ‘updateInStore’ methods. A subset of the XSD schema’s are implemented initially:

• Well
• Wellbore
• Log
• Trajectory

The implementation is based on the Ruby language, using the soap4r standalone SOAP server, and the REXML xml library. REXML has a good DOM implementation and excellent support for XPath. As for persistence back-end I have really not decided yet.

And by the way, this is NOT a RubyOnRails project!