On previous article I’ve focused mainly on cross-platform things, and for that purpose, I’ve released rake-compiler

This time, I’ll focus in attitudes instead of code, and how these affect the public image of your projects.

Attitude and project image

Again, because you’re working on a OSS, it has a public image — even if you don’t want it — so don’t be narrow-minded and say I don’t care, because you should.

Keep all your users aware of the changes

I can start this with a mea culpa¹. While working on OOS, you need to keep everyone that uses or contributes to the project aware of the changes.

Why? because a change introduced can break lot of development or production environments, not to say take away the joy of using Ruby at all!

I said mea culpa, because I neglected One-Click Installer (read ruby-talk post). I’ve released second candidate and commented the current situation why there wasn’t a new release here

Now I realize how important is keep your users up to date on what’s happening with the projects that affect their work.

Why I’m saying all this? Because the new trend is do announces on Twitter, even when you’re subscribed to the devel mailing list of the project… you need to stalk the project developers to get news.

Of course, you can avoid all this spending 4 to 8 hours a day on #IRC channels, where most of the big and compatibility breaking changes are introduced and decided.

Just to give you an examples…

Merb

Previous release of 1.0, most of the 0.9.x versions included release notes with changes. Proof is here for 0.9.5
, 0.9.6, and 0.9.7, but seems that ended there, with no announce for 1.0 (Final or release candidates). Even no changes that you can see on RubyForge.

This is something I’ve commented to the developers several times and keep poking them about it, as I commented on this blog post about something will change in new release that wasn’t announced in the mailing lists (neither users or devel one). But guess has no effect, since release announcements happens on Twitter mostly: here, here, and here

Taking in consideration all that background, no head’s up any of the releases release were announced (at least not on the mailing list I’m subscribed to), so I couldn’t test all these cross platform things beforehand.

Sqlite3-ruby

There was a pair of messages on Twitter (tweets?) requesting help on getting sqlite3-ruby project working on Windows (here and here). Again, you should be stalking that user and of course, have the time to read all these tweets.

Anyway, I left my POV in the comments of his blog here and proof of my results in my sqlite3-ruby fork here

A quick resume of this: sqlite3-ruby 1.2.4 was released, with this release notes:

This release only updates the generated C file to reflect the compatibility changes that were made to the SWIG file. Binary builds (e.g., Windows) are not affected, and need no update. In general, you will not need this update unless you are using a version of Ruby prior to 1.8.6.

The thing is that any new gem release will affect gem update, so if no binaries for Windows exist for 1.2.4, Windows users will installation errors, like the ones listed here

As I left on blog the comments, I’m not against on a developer dropping the support for a platform (humans beings are really hard to please).

I suck at release management too, as I mentioned when started this article, but a small blog post with a head’s up or quick announcement will not hurt anyone, right?

Anyway, if you want to automate the news announcement to RubyForge, take a look at this (look ma, no Hoe, Echoe or anything, just plain Ruby!).

DataMapper

DataMapper suffered from gemitis like Merb (too many gems to release each time), so verify all those moving parts on every release is time consuming.

I’ve shared my comments on this on Lighthouse and the mailing list, and also contributed back some patches for a project I currently don’t use.

My take (my conclusions)

You can agree or agree to disagree with me on this, is up to you.

I’ve spent up to 10 hours of QA per each release of One-Click Installer, because I care not to break stuff (and that’s why I do RC instead of final versions).

I came from a industry (broadcast video) were all those mistakes cost thousand of dollars per second since they play back advertisements. The systems must be running 24×7 or they loose money.

Those are not pet projects anymore, and as such they should invest time on structure instead of hacking a new cool functionality and tweet about it.

Performing a gem update hurts all, they are silently releasing stuff into Rubyforge which is the default gem repository for users. The funny thing is that I’m not talking just for Windows users, but Jruby too.

The problem is not technology or a platform limitation, is people.

People said that I’m a whiner, I just rant out loud and do nothing…

Well, when you try to something and people doesn’t care, no matter how much you do, never will be enough.

¹ Wikipedia article about mea culpa

The subtitle of these series will be how not to be dumbass while being cross-platform friendly.

With this series, I’ll like to bring what I’ve learned using a not so popular platform and how to properly interact with others, without being a dumbass, obtuse or something similar.

Hard coded paths

The year is 2008, 2009 is around the corner and I keep seeing people sharing scripts, building libraries for others (distributed as gems or recipes) still hard code paths in those.

We are not just talking about Windows with drive letters, but also these scripts break between distributions… change something from /usr/bin to /usr/local/bin and boom. I’ve seen that happen.

Never assume all the other users have your same OS distribution (hey, they could not have the same OS brand, kernel or whatever).

Was ‘which’ or ‘where’?

Trying to find something? Did you succeed? Sure? try again, but now on other distro. I found myself under some distros that lack which and instead provided something called where (couldn’t remember the distro name right now).

In my job (video broadcasting) we tend to never assume your environment, never trust on it since it could fail, and when it fails your company loose piles of money.

Until I found this issue, always relied on this functionality. When switched back to Windows, found there was no where, neither which, so I found myself in a complicated situation, my next point will add a picture for you.

Almost everything that is done with pure Ruby can be done on Windows, the few cases it couldn’t, need to be handled properly.

Like on previous example, there is no which functionality on Windows. You can rely on PATH or you can split ENV['PATH'] and perform the search in Ruby code, at the end, both do the same, right?

Wrong. Doing `which ruby`.chomp could look right, but it’s an expensive call. Every time you call it a new environment is spawned where bash/tsh/sh is executed and the output is captured. This context switch can be expensive, more if done several times in the life cycle of your application.

Maybe not clear enough:

I know, I’m such a freak when talking about performance…

Even if run it just 1 time, is more portable, don’t you think?

RUBY_PLATFORM, To regexp, or not.

Under certain circumstances, you want to exclude something for being executed under some platforms, for example: Windows.

One way to do it is ask the OS about your platform… wrong, this is like relying on OS specifics, as mentioned in previous point.

I’ve seen too many `uname -a`... in such useless ways… when they should have relied on RUBY_PLATFORM instead.

It is your friend, let me show you…

So subtle, but so simple change that just skip all the platform specific stuff if no darwin platform is found.

Another nice detail that noone cares about is that relying in system calls breaks cross-compilation.

For example, using MinGW on WINE to target Windows will be useless if you rely on system calls instead of RUBY_PLATFORM

So, play nice with others, you can do it.

Bundling platform specific files (that includes binaries).

Bundling share libraries, .so files or even .dll can turn the end-user life a nightmare. I remember a while back when some gem developers released a gem with a pre-built Makefile…

Yeah, just a Makefile, a simple text file that was not automatically regenerated during gem installation and caused lot of pain to many Linux users (since the gem was built on OSX and was pointing to wrong paths, wrong extensions for the shared libraries…)

Those files should be excluded from your repositories. Adding those warrant you that doing multi-platform gem releases will became a issue (cross-compilation and such) and also will add noise to mailing list from people asking for support since these extensions cannot be loaded by their Ruby interpreter.

Go figure something so simple can cause that amount of pain.

Disclaimer

No developer, neither Windows, Linux or OSX was injured during the creation of this post. Please use my comments for good, not for evil.

You can consider this series of articles as rant, or consider them as what they are: advice.