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

Recurring patterns in applications

I was just doodling around the architecture of my latest project when I suddenly realize that I have done the same thing over and over again for every project. I'm sure anyone of you who has successfully delivered more than ,say ,5 projects would realize that there is a pattern to almost 80-90% of stuff out there.

I started to scribble some of the recurring patterns I have seen again and again in many projects. I'm putting it here and am very greatful if anyone could add more to this. Now to verify what I'm saying is in fact recurring, I'm going to examine the presense of these patterns in three different context a) A social network ala facebook b) A workflow application c) A content management system (CMS)

1) All system must have Users

a) Social network : Yes
b) Workflow app: Yes
c) CMS: Yes

2) Users live in a Context (for example, roles, location etc.)
a) Social network: Yes. Two very obvious context: logged in logged out.
b) Workflow app: Definately yes. Swimlanes (roles) can be considered context
c) CMS: Yes. There are plain old users, there are admins, there uploaders, there are downloaders etc.

3) Given a User and a Context, there are a few Lists of Items.
a) Social network: YES. When you log in to facebook or twitter there is a list of entries/microblog
b) Workflow app: YES, you would have a list of tasks (either done, pending, kiv, delegated etc.
etc.)
c) CMS: YES. You would have a list of contents

4) An Item can contain either basic data: texts, numbers, links, images, videos, file attachments or links to other Items
a) Social network: Yes. You have all the classic types of data but also replies and "retwitts" etc.
b) Workflow app: Yes, you would have tasks descriptions and attachments for example. If the item is delegated, you will also see the delegated items
c) CMS: Yes. You will see the content and if you have "folders", you can have links to other data.

5) An item is aware of whom (Users) and how (Contexts) it should be accessed
a) Social network: Yes, only users and probably their friends could access certain photos for example
b) Workflow app: It is obvious with swimlanes, certain users canonly access certain data. What is more interesting is that certain users can access part of an item while others can only access other parts (think of government forms where you have "For Office Use Only" part)
c) CMS: Yes, folders have rights much like a Unix file system.

6) A User could be in a Relationship with N other Users. We call this relationship Contact.
a) Social network: Yes, obviously
b) Workflow app: Yes. In most workflow applications I've seen, Contacts are amed 'Supervisors', 'Subordinate' or 'Team member'.
c) CMS: You can certainly share content with other people. Not formally a Contact but still uses the same principles.

7) User should be able to log in to the system and eventually log out
a,b,c) Yes, obviously

8) A user can create Item and make it accessible to other Users (either from within his Contact or not)
a,b,c) Yes, obviously. This puts the responsibility of creating an Item on the User's hand.

9) User who creates an Item is responsible for the lifecycle (CRUD) of that Item
a,b,c) Yes, obviously

10) User who has access to an Item should be able to Read and optionally Update an Item
a,b,c) Yes, obviously

11) A system should be able to listen to the lifecycle of Items. User defined filters could be defined at each lifecycle action.
a) Social network: Yes. This is similar to Facebook email alerts when people reply to your post. The reply can be considered an Item, creating a reply is an event listened to by the system.
b) Workflow app: Yes. At every stage of a workflow, a filter can be triggered (I think Adempiere works this way to update its account database).
c) CMS: Yes. Again, email alerts can be sent when items are uploaded/created/deleted

12) There are 2 types of lifecycle action 1) Rules: To validate the lifecycle action
a) Social network: Yes. An email alert should only be sent if the new item created is a response to an existing item.
b) Workflow app: Yes. A rule is always attached to every "decision path" (the exclusive choice pattern) in a workflow.
c) CMS: Yes. A rule for example that states when a non-empty forlder cannot be deleted. Or a content viewed by another user cannot be deleted.

13) Type 2) Events that could trigger lifecycle actions on other objects.
a) Social network: Yes, adding a Contact (I.E. adding another person into your Contact) triggers an event that will add you to the contact of that other person. (I add u as friend implies, you will also add me as a friend).
b) Workflow app: Yes, for example in Adempiere, a workflow that creates an Invoice triggers the modification of Account.
c) CMS: Yes. Recursively deleting a non empty forlder might delete all its contents.

14) Users can do CRUD lifecycle on their Contacts. These actions will also generate Events.
a,b,c) Yes, obviously. You can always delete and add new people to your contact.


Now why are these patterns important? Well imagine now I've created a bare bone application (call it a framework if you will) and imagine that I want to create a Social Network. All I have to do is customised that "framework" and within a short time, tada~ a social network. I have only to define what is Item in my application context (which is social network), what is a User, what Events need to be generated and what Rules need to be triggred and I'm done. Someone else might define Items as Account, Activity, Invoice, Inventory etc. They might define Events as CreditToAccount and DebitFromAccount etc. and define Rules such as "When Inventory is low, start Procument process" and bam!, the framework is now an ERP.

Now let us take this further, what if this framework define not just bare bone stuff but also things like open persistence policy (which allows you to connect your app to any database), a well thought out GUI, a caching mechanism out of the box, a clustering facility , a reporting and BI facility and some security enhancement here and there. Suddenly, I can focus on creating my latest shiny new social network or create my own ERP focusing mainly on what the application should do rather than all the nitty gritty stuff like scalability.

Of course, what is defined here is probably incomplete at best and naive at worst. There are overlaps I'm sure (like Rules and Context could be the same thing). If you do have other stuff to add, please do enlighten me. (Or if you think certain things are just superflous). Maybe creating this framework could be my next big FOSS project :)

Weld DI and Glassfish Example

Last Thursday I gave a presentation to a few Experian staffs on Weld DI. You can find the presentation here:

http://www.scribd.com/doc/24005727/Look-Ma-No-XML

Examples can be found here:

http://www.freedrive.com/member/viewfolder/250059