33rd Degree - best place to be (EVER!!!)

Hi there folks!

I've just returned from the 33rd Degree conference and I simply need to share the positive energy I've brought home with me.

Before we start please bear in mind that the 3 days of the conference were packed with best-of-breed talks and since there's only one of me (I soooo wish this wasn't so) I was able to see only a small portion of all the great materials and performances available there. I'm sure your opinions might vary depending on what you attended :)

First of all - a fantastic surprise! I've been kind of skeptical about Dr Venkat Subramaniam which I should never ever, ever EVER have been to. This was one of the most brilliant, encouraging, humorous and inspiring talks I've ever seen on polyglot programming! Venkat, I hope you'll not forget your exercises again :) That was an absolutely brilliant metaphor to TDD. In overall it was the best source of ideas to encourage people to learn I've ever encountered! Best talk of the conference in my opinion!

Then there was the forever funny and painfully cynic Ted Neward. I just love the way he presents his ideas like a preacher in the church of St. Programmer :) He's just the one and only! Ted, great talk about the unanswerable question and believe me even if someone didn't speak Scala your talk on design patterns was still the place to be :)

There was also the best polish speaker, Sławek Sobótka with his deep-zoom like presentation about layers in CqRS architecture. Sławek: you rock! And pleeeease! Don't put the architect label on t-shirt :) Don't ever turn over to the dark side!

I must also say there was one talk that threw me completely out of balance. That was the talk by Dierk Koenig about ULC (by Canoo) framework. To give you a little bit of background here I'll tell you this: I'm usually fond of "pure" solutions. This means that mixing Flex/Flash, Silverlight or desktop Java with web development doesn't seem like a good idea to me. There's tons of stuff that you can use HTML5 for and you don't need any extras on top of the browser to make things work. That's the main reason I'm such an advocate of jQuery, its UI framework and above all the Ext JS library. Nevertheless the ULC framework by Canoo has proven itself to be a viable alternative to plain-browser design in cases where more sophisticated interoperability with client's environment is required. That includes for example interoperability with peripherals other than localStorage, sessionStorage and the other ones provided by default by HTML.
Dierk also gave a very nice and pretty advanced talk on programming in Groovy (my favorite language!). Great stuff! And very very inspiring!

Hamlet D'Arcy gave talked about ways to remove boiler plate code from your sources so that you can write more conscious code. Really good stuff, man! Thanks for the enlightenment! And thanks for bringing Groovy to the mix :) Groovy rocks!
I've also had the opportunity to exchange some thoughts with Hamlet about the applicability of the ULC toolkit. He's been extremely helpful in helping me understand the business needs this toolkit tries to address. Thanks for sharing!

If you're into the psychology kind of things then you're absolutely bound to visit Nathaniel Schutta's talk about hacking your brain. Man, that was really awesome to see so obvious and ridiculously simple ideas put into familiar context to which I could relate as a simple developer.

And last but not least: if you're into "the latest and the greatest", or in other words if you're like me striving to make your other colleagues look corny, then the talk that Jarek Pałka gave on NoSQL databases and their applicability in solving certain challenges was definitely the one to be at. Jarek is known for his specific humor and to-the-point observations he makes. This time was no different and quite frankly I've expected nothing less from this guy. Great appearance, man!

Overall this was a time very well spent. I encourage you to visit this conference next year - you'll be absolutely amazed!

I'd also like to congratulate Grzegorz Duda, the mastermind behind all of this on putting together by far the best conference ever!

Grails gotcha - controllers with same name in different packages

Well... it's tough, isn't it? You get a controller with the plugin you use and this damn controller has the same damn name as your controller. And this name is just perfect for what your controller does...

I've just found myself in this kind of situation. I asked on the Grails users group and found out only what I already knew - those damn classes have to have different names. Period.

But I'm the wild one. I need to bend software to my will. I just have to do it :D After a couple of hours of reading Grails sources and experimenting with Grails console (fricken best thing EVER!!!) I came up with this:

class BootStrap {

    def grailsApplication

    def init = { servletContext ->
        grailsApplication.getArtefactInfo("Controller").grailsClasses.each {
          it.uri2closureMap.put('/' + it.fullName, 'index')
          it.uri2closureMap.put('/' + it.fullName + '/', "index")
          it.uri2closureMap.put('/' + it.fullName + '/index', "index")
          it.uri2closureMap.put('/' + it.fullName + '/index/**', "index")
          it.configureURIsForCurrentState()
        }
    }

    def destroy = {
    }
}

With this I can use fully qualified class names in my UrlMappings.groovy!

And as usual life is good again :D

Ext JS/Core and formatting date for Grails backend - reloaded

Here's the ultimate solution for modern browsers (works in FireFox and Chrome, there's a fix for IE):

Ext.util.JSON.encodeDate = function(o) { return JSON.stringify(o); }

I feel this needs some explanation :D So here it is:

The JSON object in modern browsers is a serializer/deserializer for JSON format. It uses all the necessary stuff (like the UTC version of date methods and adds the "Z" at the end denoting that this in fact is a Zulu time).

What about Internet Explorer? Well... There's this "fix" for this browser called json2.js. You can download it at https://github.com/douglascrockford/JSON-js/raw/master/json2.js.

The beauty of this solution however lies in the fact that it's an extremely fast solution because the browser's manufacturers are in fact able to provide an optimized version of the stringify and parse methods!

Ext core, Grails and formating dates

In my previous post I've show how to provide the Grails date JSON deserializer with proper date format from Ext JS. This time we're going to look at the same problem but with a solution that also works for Ext-Core:

Ext.util.JSON.encodeDate = function(o) {
    function pad(n) {
        return n < 10 ? "0" + n : n;
    }
    return  '"' + 
        o.getUTCFullYear() + '-' + 
        pad(o.getUTCMonth() + 1) + '-' + 
        pad(o.getUTCDate()) + 'T' + 
        pad(o.getUTCHours()) + ':' + 
        pad(o.getUTCMinutes()) + ':' + 
        pad(o.getUTCSeconds()) + 'Z"';
}

This function performs much better and uses methods exposed by JavaScript's Date object instead of custom Ext JS date operations. I'd suggest this function instead of the previous one for both Ext-Core and Ext JS.

ExtJS, Grails and dates

Recently I've been made aware of a problem with interoperability between ExtJS and Grails in regards to date serialization. Here's the deal:

1. Grails expects the date to be UTC
2. Grails expects the date to end with a 'Z' (denoting that it actually is UTC)
3. ExtJS by default when parsing date thinks just concatenates the year, month, day, hour, minutes and seconds and does no other processing.

To change this behavior and make it work across different time zones right out of the box simply provide the following implementation of Ext.util.JSON.encodeDate:

Ext.util.JSON.encodeDate = function(d) {
    return d
        .add(Date.MINUTE, d.getTimezoneOffset())
        .format('"Y-m-d\\TG:H:i\\Z"');
};

That's it when it comes to passing dates from client to server. More on serializing date on the server next time!

Ext JS licensing - BE EXTRA CAREFUL!

It looks like the licensing terms for Ext JS library (as stated in an email conversation with Ted Driscoll) are for developers and for the once you bought is only. There would be nothing unusual about this but you have to understand that if a developer leaves the company then he TAKES THIS LICENSE WITH HIM and in best case scenario you're around $329 lighter if you hire a new developer.

Here's the conversation I've had with the said VP:

Me

I'd like to buy 2 ExtJS licenses for developers in my team. There is however a
question of what will happen if a developer leaves the team and someone new is
hired? Will the license stay with the team or with it move away with the developer?

Ted Driscoll

The license is assigned to a specific user, so you can not move them.  
they are not floating.  Hope this helps

Me

Does this mean that when a developer leaves the company he leaves with the
license?

Ted Driscoll

No,  but no one else can use that license.  Now having said that, if you ask
once, we will allow it, but if this happens more then one ,then we will not.
Our licenses is are per named developer

Like I said - you need to know what you're getting into. Ext JS is a fantastic library but the licensing terms are just cruel for companies willing to make software with it. Especially in today's world where developers are changing jobs often which is not only normal but also desired to attain high technical skills.

OOP and OOA - the new age

How come programmers have advanced so far in the evolution that the architects that lead the overall design have been left so far behind? How come that they teach and preach the same stuff their grandpa would (if he'd be still alive)?

It might seem like a strong opinion to you. Tough one if it does. You might be one of the architects that I mentioned above.

So what's the deal?

Let's examine two of the many OOP techniques at our disposal: Inheritance and Composition.

Inheritance (quoted after Wikipedia):

"In object-oriented programming (OOP), inheritance is a way to compartmentalize and reuse code by creating collections of attributes and behaviors called objects which can be based on previously created objects. In classical inheritance where objects are defined by classes, classes can inherit other classes. [...]
The inheritance concept was invented in 1967 for Simula."

Composition (again - from wikipedia):

"In computer science, object composition (not to be confused with function composition) is a way to combine simple objects or data types into more complex ones. Compositions are a critical building block of many basic data structures, including the tagged union, the linked list, and the binary tree, as well as the object used in object-oriented programming.
Composited (composed) objects are often referred to as having a "has a" relationship."

So it's dead simple, right? Son is his father's child but a car has wheels and eingine, right?

So please anyone tell me why the F so many enterprise-grade systems are created in a monolithic way? For haven's sake the 80's are gone, it's the year 2011!.

And don't you go about telling me that the technology isn't there yet! Oh it's there. In fact it's been there for a couple of years now. Starting with the first servlet containers!

So you'll say that creating a system that shares common security configuration (and thus uses some sort of single-sign-on feature) is not easy? Wake up, dude! It's been ready for ages!

So maybe it's the build time that's causing you to lean towards a monolithic design? Goddamn it! Is it really faster to build and deploy a 200MB War file than to build just one single part of it and dynamically restart the context?

Ok - I get it. You still need to cover your part of the deal, right?. If everything would be so dead simple you'd not be needed at all and that'd mean that you'd be without work. So who the hell would control what parts would need to emerge for the whole system to work??? Well, we (programmers) would't have to finally do your job.

All and all my point is: keep it simple and small.

PS. I hope you did get the irony :D