A tiny piece of principle of development to add to your list

So far we have a few useful principles to follow during web and generally software development. Everyone remembers the DRY, KISS and all that. Let me add my own little gem to the list. It's called MY and focuses on modern or old source control. It's so obvious that I'm sure you already aware of it. So here it goes:

MY: Merge Yours!

Basically it means that if you collaborate in a process, you the developer is responsible for other people's work; you have to respect others work, no matters how a piece of junk is that. So when you start working on someone else's code, first merge yours. Merge your code with poor Jane or John Doe's stuff before you push. Obvious no? Then do it.

Its all about respect, no coding required.

I'd like to invent an other nice principle abbreviated ASS so I'd wear a T with "KISS MY DRY ASS" on it.


CSS is simply great - Steal the best ideas and solutions

This will be quick. My favorite designer recently rewamped his site, Stuff and Nonsense. I spotted a few obvious things that you can steal from the CSS but just realized a good UX idea over there. If you click a link on that site, a small effect happens emulating a button press. I think it can be useful on slow sites as an immediate after-click feedback to the user: "Hold on, we are working on your request".

Here is the code:

Beautiful huh?

CSS is simply great - Adding more power to the user with a few lines of code

I'm playing with a very plain user interface, a form where you can set some data about planning your next trip with your friends. I'm just playing ok? The form contains a few text input elements, selects and a textarea. Nothing special.

But recently I've seen a new CSS framework (will give you a link when I find her again, sorry) where all the textual input controls were styled so pointing to a label, a checkbox or even a text input fires the pointer device's cursor and style it to cursor: pointer. Hey its dumb, I thought at the first view. But hey, why not? I can do a click (and a number of things) on those elements so why not set a pointer style that calls your attention. Its just cool and gives more UX goodness to your forms.

But there is more. (Cos I'm an unstoppable style robot ninja? No. I have a little time to think cos I'm on vacation.) I think its an other good thing if you set the cursor's state to cursor:text after you clicked on a textual control so you can get a visual feedback eg. "Hey I'm a text control, type something into my belly".

Before I give you an example I want to warn you: THIS CODE WILL NOT WORK IN EVERY BROWSER! But in my opinion YOU CAN GIVE A SHIT ABOUT THAT!

Here is an example:


Interview with Ola Bini

I always wanted to interview people that I admire for great ideas and code. Here comes one with Ola Bini. For those who live under a frogs butt Ola Bini is a JRuby developer at ThoughtWorks Studios. He is working on an exciting new language, Ioke. The interview is originally made for the Hungarian developer community site, Weblabor, but I keep this as reference. So here it goes, unedited, juicy :)

JH: As far as I know you have no formal education in computer science. How do you see the advantages and/or drawbacks of this?

Ola Bini: No, I dropped out of high school, so no formal education at all. There are both pros and cons, of course. The good side is that I've gotten lots of work experience during these years. I haven't felt that I actually needed the education. I've been able to pick those things up by reading a lot and so on. But right now I'm at a stage with my own language and so on where I feel it might have been useful to know more about how to navigate academia to find out what I need and so on.

The big negative is that I have no papers on the knowledge I have. Starting out, it's probably not a good career choice, but now I've managed to do enough things that I don't need the papers as proof anymore.

I would say that the world of blogging and open source makes it possible for people to show that they are good without going through education - but it's definitely not a route I would recommend to anyone.

JH: What is your daily job? Is it related to your programming passions?

Ola Bini: Yes. Nominally I'm a consultant, and I do a bit of consulting around JRuby and so on. I've also been on pure delivery projects in different technologies (I'm pretty much effective in both Java, .NET and Ruby).

But most of the time I actually get to spend it on doing things related to my passions. Working on JRuby itself is part of my job, and so is speaking at conferences. Ioke is not really something that ThoughtWorks benefits directly from, but indirectly there are some benefits to allowing me to work on that too. I also spend some time with Language Workbenches (such as Intentional).

Currently, the main goal I'm working towards is a Swedish ThoughtWorks office, and I'm really doing anything necessary to make that possible.

JH: You tend to describe yourself as a "language geek". Could you please share us your experiences with the languages you use(d) and fond of? And a related question: Do you like learning (or even invent) natural languages as well or formal ones only?

Ola Bini: Yes, I'm a language geek, but mostly in terms of programming languages. (Programming languages aren't necessarily formal languages, btw). I'm not very good at natural languages, restricting myself to Swedish and English, but I am interested in natural languages at the meta level - so I read books about that subject.

When it comes to programming languages, I enjoy learning new ones. But I've dipped my toes in most of the larger ones, and many smaller ones too. That is what pushed me in the direction of creating my own language.

JH: What is your recommendation to start to learn a programming language from zero, especially Ruby?

Ola Bini: Well. It is really trite, but it depends on who you are. The best general advice I would say is to just do something in the language (a real project, nothing toy). Of course, that isn't necessary for everyone either. I learn very well from reading, for example. But do stuff in the language. Adopt it as your general scripting language for a few weeks, for example. It will be painful at first, but you will be forced to learn quickly how to actually achieve things.

JH: Beyond hype, what can be the advantages of the marriage of JVM and Ruby (or any other scripting language)?

Ola Bini: I dislike the term scripting language. Ruby is a general purpose programming language, that has several features that make it useful to use for scripting - but definitely not restricting it to that.

At this stage of programming, most language implementors don't have time to implement really good GC or threading schedulers or just in time compilers. At the end of the day, you want to have an expressive programming language that still allow you to achieve things. And you doesn't necessarily ONLY want to use that language. So the benefit of a VM like the JVM is threefold. First, it makes it possible to implement a language with much smaller resources compared to the traditional way. Secondly, it makes it possible to interoperate with other languages on the same VM, which allow true polyglot programming (meaning, using the right language for a task, and mixing them when it makes sense). Thirdly, being on an established VM gives access to a large amount of libraries that you don't have to reinvent from scratch, or write C bridges to work with.

JH: Some Ruby apps and libraries need thread safety. How did you manage, if so, this issue in JRuby?

Ola Bini: Well. The internals of JRuby is thread safe, but we still need to mimic the salient aspects of Ruby itself, which includes all the little annoying threading tricks happening. If a Ruby app or library needs thread safety, they should use the thread library - it gives access to mutexes and semaphores and so on. These work very well on JRuby - and are more necessary since JRuby has real threads.

JH: Do you see new possibilities in the future versions of JVM that might be helpful for language implementors?

Ola Bini: Yes. Definitely. JSR 292 (I'm part of the expert group) is all about making changes to the JVM that will improve the situation for alternative languages. The main changes involved in this JSR is invoke dynamic and method handles. But we're experimenting and looking at lots of other features that might or might not make it into the JVM.

So the Java platform is definitely evolving in ways that will help it fill the needs of alternative languages.

JH: How do you see the future of JRuby? What directions can it go?

Ola Bini: That's a good question. I haven't thought much about it - of course, more speed is always nice. Charles is working on a Ruby2Java compiler that will make it possible to generate static structure from Ruby classes. I also think that JRuby is an excellent choice for people that want to experiment with the Ruby language - maybe changing it in smaller ways.

JH: Do you think about GAE/J can be a good platform for people using JRuby? What do you think about GAE/J in general?

Ola Bini: Yes, GAE/J is a good platform for JRuby, and I believe that GAE/J is in general very interesting for several reasons. Seeing as it opens up the AppEngine concept to the whole ecosystem of alternative languages on the JVM, people from many different communities can come together and do interesting things on top of it.

The limitations of the platform are also totally understandable, and not very problematic once you get used to them.

JH: I understand you are the inventor and maintainer of Ioke, a new language for the JVM. What were your motivations to create "yet an other language for the JVM"?

Ola Bini: My motivation was to try out some ideas I didn't see in any other language. And Ioke is not just another language for the JVM. It runs on the CLR too, and will be ported to other platforms. Starting out on the JVM was a very pragmatic decision, based on all the things I get for free by running there.

In general, I think that the attitude against creating new languages is a problematic one. I want people to create MORE languages. Creating a language is a good thing to do, and even if no one uses it, you will learn much from doing it.

JH: Could you please introduce us the basic concepts of Ioke?

Ola Bini: That's a longer answer than there is place for here. In short, it's a prototype object oriented, dynamically strongly typed programming language. It embraces mutability and macros. The main goal of the language is to explore expressiveness without giving any regard to performance. More information can be found at http://ioke.org

JH: As of Ioke you state you prefer expressiveness over performance. What does it mean in the everyday programming practice?

Ola Bini: No, I don't state that I prefer expressiveness over performance. I state that when developing Ioke, that is the philosophy I follow. Every task is different and every task has different requirements and tradeoffs between expressiveness and performance.

Thanks for your time!


JRuby on Appengine

It was a great joy to talk about my experiments with JRuby and Google's Appengine, so I decided to share my slides here as well.


One-click Ruby Installer Needs Your Help

Just seen Luis Lavena's posting and his Pledgie fundraising.

Luis is a smart and kind Ruby hacker from South America working on a better Windows acceptance and working environment. He brought you the fresh new Ruby installer, a great Rake toolkit and a bunch of stuff that can help you guys bound to the Windows world.

Please consider to make a contribution to these projects either with some money or code.


Better Application Design

I'd like to share two excellent presentations from DjangoCon 2008 that gave me inspirations for the future (see more at Google Developers channel).

The first one is held by James Bennett a well known Python/Django hacker.

The second one is by James Tauber, master of the Pinax project.

I thought I understand OOP and modules but it seems I did not. There are other ways to make a website better. These presentations suggest that I should follow the Unix philosophy of making tiny bits of software components (do 100% that they was designed for, nothing less or more) loosely/lazily coupled instead of big chunks of stuff built on a monolithic framework.

The first drawback that came to my mind is that how can I find the weakest piece (link) of code (app) in my project. I think its a matter of source control and validation. But of course you can inject junk into a large app anyway :)

As lucky we us Python/Django coders getting hook up this philosophy so the tiny reusable apps could be coupled into some kick ass project via hooks.

Interestingly almost the same ideas wave the Ruby folks these days so there is hope.