You brought this upon yourselves

[Apache to leave the JCP]

When Sun was around, it was the ugly duckling. No one liked it despite all the things it did for the community. Being the largest open Source contributor was not enough for the bullying community. Sun tried and tried haplessly to do what it can to please everyone and yet, a lot of people were unhappy. Sure, Sun was not perfect, it was the ugly duckling after all, but, for what Sun had done it did not deserve the treatment it received. Every one hated Sun and pounded Sun to pulp since it is ugly and ugly duckling deserved our outmost hatred.

And one fine day, Sun finally died. The people cheered and toasted its death. Unknown to them that Sun was now replaced by a GIANT with an I-don't-give-a-crap-what-the-community-wants-since-I've-never-do-and-yet-I'm-still-filthy-rich attitude. Blazzing the country side with its fist, smacking all that were protected by Sun before.

Alas, the community wept but they wept too late. Sun, the gentle giant is dead. if only they would have liked Sun a bit better it would probably still be around. If only ...

My take on MOSC 2010

Just like I said in my lightning talk, this is not a rant, a fault-finding or a bitching piece. This is a sincere advice from a friend to the community.

Now, with an opening like that you can already guess I'm not going to say anything nice :). But you are wrong, there are some nice things about MOSC 2010. The talks were quite good. We have everything from mobile to server to desktop stuff. Things are practical and "actionable" and rarely we have philosophical talk. Which is good.

Food is another area worth praising. Food was never ending. On the first day, just when I thought they were serving lunch in the lobby I was suprised to know that what was served was not really lunch (well, at least not for the speakers and the business attendees). The real lunch was at the hotel's buffet. Unfortunately I was too full for the buffet ... (BTW, just between us, it takes a lot to make me full)

Now we talk about the bad stuff.

First, there was too much marketechture (did I spell that rght?) going around. The Microsoft keynote paid lips service to PHP and Java (by mentioning them once each).
Now Microsoft was there last year too, but last year we have Google, Mozilla and the now defunct Sun Microsystem to balance that out somewhat. Plus, we really put Microsoft in their place last year. You can really feel fear in their eyes. This year it was different. Sure, Microsoft's presence was not felt as much but you can see that they are grining from ear to ear. All that they fear is gone. They have the "community" eating from their hands. They feel their victory already. So much so, their keynote does not even bother to "suck up" to geeks like last year. At least last year, the apps created during the competition is open sourced. Now this year? I have no idea, it says that those apps are open sourced in the first place, where can i get it? I can't find it on the official competition page [http://conf.oss.my/mtc/].


Secondly, where the f*cking hell is Oracle? You know, Oracle, the company who bought the largest contributor to open source... yeah that Oracle. Why can't MDeC bring them to the table? Sure Oracle stuffs are mostly boring but they do have a few open source gems. Things like EclipseLink implementing the new JPA 2, or... they could talk about, oh i dunno... MySQL maybe? Now that they own it. I mean, gosh, a debate between Colin Charles and some Oracle "consultant" would be really cool to watch. Heck, I'm sure we can find a bookie or two easily in the crowd now that the World Cup is on :) ... my bet is on Colin KO-ing the Oracle consultant by round 2... any takers?). Or JSF 2/ MyFaces / Trinidad (is that out yet?). And since we're all about cloud, what about a talk on BerkeleyDB, one of the first key-value DB out there.

Tons of stuff from Oracle and MDeC could not even get them to come... heck, not even a booth. Now some of you might notice and shout "MDeC is no longer the organizer of MOSC you dolt!", well they are not and yet they bring Microsoft with them (yeah, sure, I'm sure it's OSDC who brings Microsoft in). They could bring Microsoft but not Oracle? Who's the dolt now.

And last but not least, where are the freakin' shouting and raving geeks we saw last year? Did they all decided to drop PHP/Phyton/Java and decided to go to the dark side? Or did all of them somehow got married (what has marriage got to do with this?). Somehow, someway, MOSC is being invaded by soulless business types who will clap everytime they hear a hype word ... you know like "cloud" ... clap clap clap.
Don't get me wrong, we need these soulless people because they are the one who pay the most >:) but last year, their effect are being countered by the geeks coming to the conference too. This time, it's just them and no geeks. So they can do all the freakin clapping they want. It's unbelievable.

I really hope, next year, we focus on "our" stuff, and real open source. We should classify the talks into 3: business, my own opensource project/projects I've contributed to and experiences. And to the academics presenting their papers. Do note that this is not a strictly academic conference. I.e. just because you can apply your artificial neural network to yet another non-existing problem doesn't mean we want to hear about it. (Actually, come to think of it, we don't). Your talk need to be special in a way and not just spew random buzzword du jour. It would be great if your stuff is open sourced, if not then it is ok, but in that case do talk more on how open source stuff is used. And open source stuff should be used fairly extensively in your project to be qualified as an MOSC talk... (btw, just because you use putty to connect to your server doesn't even make your project, even remotely, use open source "extensively"... no matter how you define "extensively").

It' a great lost that a whole bunch of geeks are not present during MOSC, citing reasons such as being busy, in between jobs and of such. (BTW, to those geeks who are present and contribute their time and energy, especially Fazli, Harris and the gang - kudos to you guys. You've done an amazing job indeed) My own experience says that being a geek the last 1 year or so was painful at best and almost destroyed me at worst. Heck, I almost did not submit a paper this year. It is unfortunate that MDeC has no one looking after the developer community. The guys who are present at MOSC (Ritz and his team - you guys are the best) are not directly responsible for community. Heck, I'm sure that they have to fight their way to get some form of "community" support from MDeC. I sincerely hope that this year's MOSC would make MDeC realize that they can do all the "transformation driving" that they want, but if the community is not following them... or worse, the community is going on a whole different direction (like, you know, down south), at one point, they won't have any passanger to drive anymore.

Agile is not an excuse to be lazy!

What if you have 9 scrum teams trying to implement a piece of software. To make things challenging, the scrum teams are supposed to work on components that are interrelated and depends on each other. Imagine scrum team A's component needs a service from a component still under development by team B? Now of course team A can just wait until team B finish their component and just sip coffee and write tech. blogs (like this one) all day long. But I'm sure the business types would be pulling their hair out (and note that they don't have that much to pull out anyway) when they hear that. Heck, they might even force you to use *gulp* CMMI processes from now on.

Another option is for team A to mock the team B's component and go to work with that. That is a better solution but here's the kicker, what do you mock?

The answer is team A and B need to sit down and properly design the boundry and contract of their components up front so that work can be done properly and team A does not need to bother team B every 3 days because they need a new service. Things could be worse if team A and B are located halfway across the world working in different time zone and whatnot.

But you see, I'm shivering here while typing this because "sit down and properly design the boundry and contract of their components up front" does not sound "agile".

Somehow, there is this meme that has been going around saying,

anything up front != agile
Bullsh*t

There are to ways of looking at this:

1) If it's not agile, who cares! I just need to get my work done! If it's not agile. I don't give a rat's *toot*

2) Agile is about easily making changes and not about "being lazy". You can design "enough" up front without making your system brittle and crack under load of changes, can't you? Sure you can. The only reason that you do not want to do it is the plain old sin of sloth. Not the agile philosophy.

It's is bad enough that when the agile movement started, some developers embraced it because they were just lazy to think through what they do and just wanted to code. And thus this meme where agile is seen as a holy war againts anything upfront, even planning, sometimes, was born. Oh we don't plan, we're agile. Bullsh*t!

Could the upfront stuff change? sure, that is what agile is all about. But team A and B might need to sit down together again maybe once in the next 2 months. But if things are not defined up front, you may have to poke that nasty evil-eyed team lead from team B for his help every 3 days. Do you really want to do that? *Now please voluntarily imagine his evil-eye... yup, not pleasing isn't it*

Things could get worse when A depends on B, B depends on C and C depends on A. This circular dependency is sooo going to kill your project if not managed properly.

So, as a conclusion: agile is good, being lazy, whatever excuse you tag it with is just evil.

What's troubling our PM

Wow, it's almost February and I have not rant nothing yet this year (yeah yeah, double negatives yada yada yada). I must be getting soft. Anyway. Here's a quick one:

PM says: We must move fast

The rest of the gov says in order to move fast you have to:

1) Fill in form A, D11 and E

2) Write a 50 page business plan (anything less will be rejected)

3) Make 10 copies of said business plan plus 3 soft copies burned to DVDs (plain CDs will be rejected) marked "Moving fast program"

4) An Excel file stating the projection of profits for the next 10 years (yeah yeah, we know you made those numbers up but we really enjoy playing with Excel)

5) Should not have a prototype - if we as much as smell the flatulence of a prototype, your proposal will be rejected

6) 6 certified-true-copies of your SPM certificate (why 6 copies... well we just made that up ). BTW, only the Ketua Kampung at which your school was situated would have the authority to certify those copies.

7) 7 copies of your IC (again, must be certified true copy - again, we made the number 7 up... wow this IS fun).

8) Satu dulang hati nyamuk

9) And don't forget, stamp duty RM 10

10) You should have never ever fail before. What? You got third place in that 'Lari dalam guni' competition at kindergarden? Next!!

Recurring patterns in application II : Streamlined object modeling to the rescue

I'm still on my quest to find basic patterns in most (if not all) software systems [read my first attempt here] when I stumbled upon Streamlined Object Modeling (SOM) by Jill Nicola, Mark Mayfield and Mike Abney. This book really blows my mind as it answers my calling with a bang! This book is really a superbly good reference book, on par with Domain Driven Design (DDD) and even the GOF book and yet it is so unknown (it was written back in 2002 - I just graduated in 2002 - and it took me all these years to find it). This must be the most underappreciated IT book ever!

The style of the book does not make it an easy read. It is full of Principles (98 of them) and a bunch of Rules (which I did not count). Also, the fact that they put the diagrams on either the top or the bottom of a page (instead of in the middle of a paragraph where you really need to see it) really seems too "academicy" to me. I guess the style could work for IEEE papers but not so much on a book.

Otherwise, the patterns shown in the book are really Earth-shattering. It echoes back some of the patterns I've suspected in my earlier post. (Which is nice since it does confirm my observation).

Some of the similarities between what I have observed and SOM patterns:

• What I call User is called Actor in SOM

• What I call Context is called Role in SOM

• What I call Event is called Transaction in SOM

• What I call Item is also called Item in SOM

• What I call Item can have links to other Item, SOM qualifies this further by stating the realtionship of type 'Container-Content', 'Group-Member', 'Assembly-Part' and 'OuterPlace-Place'

• One thing I did not capture in my patterns is the Object inheritance part (not to be confused with class inheritance)

Both my patterns and SOM agrees that Events should be fired when properties are changed.

So, why don't I just take the SOM patterns and be done with it?

Well... (oh here it comes)
One of my objective in identifying patterns is to create, at the very least, a GUI generator that will create interface based on the patterns present(instead of just CRUD). That is not so simple with SOM. For example, a SOM pattern always starts with an Actor having a Role and a bunch of Transactions are associated with the Role. This represents the subject-verb relationship in which Actor-Role represents the Subject and Transaction represents the verb. Of course, you must also have the Object part too. This is represented by Item. So, in a SOM setup, you will usually have :



Now imagine that I create (using your off-the-shelf CRUD generator) an interface for this setup, I will have a Role page, in it I have things that have happened (Transactions) and only when clicking on things that have happened that I will have a bunch of objects that I can browse. Which is a bit counter intuitive) There is no concept of direct Item ownership by a Role (or an Actor) in SOM.

Now to mediate this, I can just look at Transaction as a 'wrapper' for Item. From Role I would regard transaction as a see through object and can pierce through it like a glass to see its Items directly. But, would my typical CRUD generator support this piercing? (It does look somewhat like a master-detail setup).

Another problem with CRUD generators is that CRUD generators typically follow DDD, in which you would have DAO (or Services + Repositories in DDD parlance) and GUI codes are created for you in function of your domain model. In DDD, verbs are represented by Services and they are on a separate layer from the domain model. In SOM on the other hand, verbs are modeled as objects integrated with other objects in the domain model. To use CRUD generators with SOM would require a marriage (as if we don't have enough of that already during the last school holidays :) ) between SOM and DDD. Hmmm... how would you do that? For example, in DDD, to create an Item, you would request the repository (which is totally disassociated from your object model) to create it for you. In SOM, a Role, through a Transaction (both of which are intricately part of the domain model) might create it.


Hmm... I will investigate and update this blog again. Stay tune