ExtJS inheritance strategy

I've been struggling for quite some time to come up with a strategy for writing ExtJS code so that no matter what kind of class I'm extending everything looks the same. Today I've finally ended up with what I wanted :). In this case I'm working with Ext 2.0.2 but it should apply without any changes to all versions of this wonderful library.

Challenges

I've set a goal to be as follows:

1. Instances will have proper class names and not some generated names
2. Declarations will present themselves in the code exactly the same way regardless of the base type
3. The code will look understandable

The template

First we need a namespace so that the global one doesn't get polluted:

Then we need to define the constructor (this will give the actual name for the class later on:

And finally we'll implement some public methods:

This way the actual class is "Namespace.ClassName" and not some wierdo, public methods are cleanly separated and default configuration is in one place.

As a bonus this pattern works for every single class - no matter if it is a component (GridPanel, Window) or not (ie. Store)

I hope this will make someone's coding adventure a little bit less messy :)


Have a nice day!

IBM download manager

This post is just to make a stand against corporations like IBM that think we're so stupid and ugly we can't download and run a simple exe from the net.

Well, guess what: we can! Stop the damn reinforcement to give you all the personal information you don't need! It's against everything - not just the European data privacy laws.

And above all: come on guys! Do you really feel it is necessary these days to force the user to use a Java-based download agent? Ain't it simpler to finally enable HTTP resume on your server? Or can't you do that?


What a damn shame that the big ones can't keep up...

Grails, documentation and images

A quick tip of the day:

if you're creating a Grails project and want to provide documentation for it it might stand a chance you'll need to include images in that documentation. Unfortunately the official documentation is very sparse in this regard showing you only the syntax for including external images. As it turns out it is possible to have images that come specifically with the docs. All you need is to specify

grails.doc.images = new File("src/docs/images")

and then include them in the docs as usual but without a URL

!my-image.png!

Thanks to Lauro Becker for that hint!

Grails, Bootstrap and a pile of crap

Today we're going to pick on a good idea gone bad. The good idea being the ability to kickstart a Grails application with Bootstrap from Twitter. What's gone wrong is the actual implementation. But let's start from the beginning.

Create a new application

grails create-app example

You've seen this over and over again, right? Nothing new here. Let's install the kickstart-with-bootstrap plugin. For that in Grails 2 we'll modify the grails-app/conf/BuildConfig.groovy's plugins file like this:

plugins {
    runtime ":hibernate:$grailsVersion"
    runtime ":jquery:1.7.1"
    runtime ":resources:1.1.5"

    build ":tomcat:$grailsVersion"

    compile ":kickstart-with-bootstrap:0.5"
}

Easy enough. Let's compile the application first (grails compile) for the build system to fetch all the plugins and do its other bits. After that we'll execute grails kickstart-with-bootstrap (the one that just came about with the kickstart-with-bootstrap plugin), answer all questions positive and we're done. At this point you can create a domain class and a controller but that's not really the point of this blog. The point here is to pick on the way the master kickstart layout looks like.

The good part

Well... the appearance is really great! But let's face it: it's so because Bootstrap looks great. It has all the usual stuff, the top bar, nicely looking fonts, the layout is floating. That's all nice and dandy...

The ughly

Let's open the newly created grails-app/views/layouts/kickstart.gsp. Here are a few points I'd like to make:

<%--  <div class="container">--%>

What for the love of god was going through the author's mind to leave commented out code in official release? And believe me this is not a single place. There are actually 21 of those!

But that's as long as purity goes - let's try to find something scarier:

   <g:if test="${ params.controller != null
      && params.controller != ''
      && params.controller != 'home'
      && params.controller != 'login'
   }">

I mean what the heck is this?! We're in a reusable layout! Ok, you might think I'm bitching about one place in the layout... Well actually no. There is more:

class="${ params.action == "list" ? 'active' : '' }"
class="${ params.action == "create" ? 'active' : '' }"

So a list should be shown, right? Or maybe we're actually creating an entity... Hm,... What was going through the author's mind at this point???

Does it by any chance belong in a reusable layout?!

Summary

I personally think that such a plugin is a blessing for someone that starts a new project now and then. The original Bootstrap plugin just doesn't cut it. But for the love of God do it right! By providing such a half-done tool to others you're actually doing more harm than good.

I'd love to get in touch with the original author to straighten things out. I love the idea of having a plugin that supplies a set of scaffolding templates and a layout to get me started with a nice look and feel quickly. Never mind the fact that it doesn't use the resources plugin. I actually like it. But it needs to be done the proper way, the way it is reusable!

Hosting Git like a professional - Gitorious!

I've been struggling over the past months to find a way to install Gitorious on my private network to have the same kind of power in hosting repositories as GitHub or BitBucket. For sure Gitorious is not as powerful as those guys but it is more than enough for in-house development.

And tada! Here it is: the automated process of installing Gitorious on a fresh Ubuntu or Debian machine.

Here are the main components being installed:

1. Ruby 1.8.7 - enterprise edition
2. MySQL 5.1
3. Stomp server
4. Apache HTTP server with Passenger module
5. Lots of supporting utilities
6. Last but not least: The Gitorious application.

The procedure to install using this script is as follows:

1. Make sure you do have sudo installed (on Debian you need to install it manually!!!)
2. wget the script from GitHub in raw form.
3. Edit configuration options found at the very top of the file
4. Launch bash (_NOT_ just sh!!!) with this script (bash install.sh)
5. Press enter when asked

One note: if the script seems to be hanging mid air (especially at the end of the installation where ruby interpreter is being invoked to add admin user and so on) press Enter. After pressing Enter the script will continue almost immediately.

Now this is a very basic installation of Gitorious. For example there's not Git over HTTP support available. But all the rest should be working just fine :)

Give it a shot! Give it a shot even if you don't need it :) Gitorious is an amazing piece of software and can help you out in Git administration like no other software will.

The quality of software - part four

In today's installment we're going to look at the quality of code from a broader perspective taking into account all the previous installments. I'll try to outline the difference between a good project vs a bad one, even though they both make money.

What is software quality

There is and always have been a huge gap between the end product and the code. That gap has been introduced some ages ago with tapes and cards. They didn't make any sense whatsoever to the end user as much as the code today makes no sense whatsoever to the user of your next brilliant application. Let's face it: programming is an art not everyone can do and even less people can understand (even if they are in fact doing it). So what makes up for a quality product?

There are 2 sides of the story: one is the "make it to the market ASAP" side which tends to solve the problem of competing with others. Depending on the size of the project it might seem like it is a good idea to rush developers into doing the least that'll actually work or to push in some features that'll make the customers so much happier.

The other side of it is that software is created by human beings and that in turn reveals the weakest link in the process of creation. Even though we can be extremely creative in our brilliant ideas we tend to make mistakes, tons of them. The faster you write code the less careful you are and the more bugs sneak in into the final creation...

Sure there are people that get it right the first time, always, but there's so few of them you could put them into the "exception" group for a rule that programming is a very error-prone activity.

So quality in the broader sense is something that is good for both the end user of our software as well as the agility to fix any bugs or introduce new features into the project.

I can fix any bug in the projects I wrote - and do it FAST!

That's a common misunderstanding that one can find bugs within software product they wrote. It is so because we, humans, don't stay the same for the duration of our lives. We tend to learn new things even if we don't admit it to ourselves. Let me tell you that looking at the code that I created 10 years ago scares the hell out of me! And I'm not the only one...

So even though we'd like to think that if we'd be the only ones creating the software we will at some point face the danger that our old idea was plain wrong. Due to the changes that happened to our lives we tend to think differently and curse that brain-dead monkey that wrote this stuff some years ago.

Uncle Bob says: Why did you write it?!

One should always try to be at ones best when writing code. Period. There's no excuse for writing unsustainable code - be it for private use or for the company you work in. There's no excuse to write code that will make you ask WTF every 5 moments. That'll make your life and the life of your fellow developers a living hell. And the worst part of it that it is not only you, the programmer, that will suffer from it - it's everyone in the chain starting with the guy that wrote it and ending with the programmer's worst enemy - the end user... How come? Well first of all you will curse the day you entered the project, then your architect will throw thunders at you for writing that piece of crap, then your manager will tell you that you need to go faster and cut corners and at the end of all this there is the customer that will probably go ahead and buy another solution that will not break as often as the piece of crap you and I created.

My old boss when asked about what is software quality explained it more/less like this:

The quality itself is not a goal for itself. But at the same time it is vital in order to sustain the company and the products it delivers

What it says is there's no one or the other. The world is not gray in this regard. If you make a loan in the code you'll have to pay it back in order to go further...

Summary

The summary of the whole series is quite simple: do TDD, do continuous integration, do pair programming, do code reviews, do make the querulous customer happy! They deserve it. You deserve it. You deserve to do the right thing. And if you can't do that then quit now and never look at software development again.

Grails and Ratpack

Today I've found out about the Ratpack plugin. Being a huge Sinatra fan I was quite fond of the Ratpack framework to begin with and naturally I was amazed to see it incorporated into Grails as a plugin. And it works!

Let me walk you through a very simple example of using Ratpack inside Grails.

We start by enabling the Ratpack plugin in our application. I called mine app "example" so all the URLs will be prefixed with "/example". To include the plugin you need to add it to grails-app/conf/BuildConfig.groovy like this:

With that in place we'll create a domain class to have some data to display. I'll go with the simplest possible class that represents a person grails-app/domain/Person.groovy:

Simple enough, right? Let's go an make some use of it in a Ratpack file. Create a folder grails-app/ratpack and inside of it a file called PersonRatpack.groovy:

As you can see here all we're doing is responding to the GET method on some root URL. Ratpack uses SimpleTemplateEngine from Groovy. We have to tell it where to look for templates Config.groovy:

So let's create one to display the people from database grails-app/ratpack/templates/list.html:

Simple enough, right? It almost looks like a mix of ERB and expression language from JSP. I think you'd have to ask the authors of SimpleTemplateEngine if those similarities have been made on purpose of if this syntax just seemed to be the only one that made sense...

Anyways, with all that in place we can add some people to the database in our grails-app/conf/BootStrap.groovy file like this:

And that's it! start the application, navigate to http://localhost:8080/example/ratpack and you should see the list of two people on the screen.

Needless to say you can accomplish the exact same thing using a controller and a view. The idea here however is to show you that there is life beyond the standard artifacts and that the beauty lies in diversity!

Hope this will help someone get started with this awesome piece of code!