Ext.ux.form.field.InputRadio - specify radio input value at Runtime

Here's form widget i thought could be useful, it is a subclass of standard extjs4 radio class with the extension that it has a inputbox next to the label where the user can type the value that is to be its submit value and thus it disregards the 'inputValue' config supplied for standard radio button. Thus can be used in a  radiogroup along with normal radio buttons(static values) to have an option of a dynamic(user entered) value as a possible value.

This is a very rough first cut and work in progress and i intend to put it on GitHub shortly , till the js file and an example html can be obtained here , please  put both the files within your extjs4 directory and run. Comments, views , improvements are greatly welcome. Let me know if this is useful to anyone and in what scenarios has this been used.
Update 03/12/2011 - Have hosted the project in Github here, with some enhancements, like support for binding of data loaded to a form through setValues or loadRecord functions. Suggestions, forks most welcome.

searches all over the place...

Am working on very enterprisey javaee stack nowadays with ejb3/jpa/hibernate on jboss and all that jazz!! also started reading martin fowler's "Patterns of Enterprise Application Architechture" book and that got me thinking ... I might trampling over all your delicate, squishy layering but this is what i see , i see my Session Beans(SLSB) loaded with finders of all shape and hues and it keeps on growing and a lot of it is to satisfy UI . UI needs to show refer something from someplace , so it needs to query the entity table with a particular combination of parameters/constraints and the tons of codes from the UI through the SLSB and back again with all bells and whistles in between to make it run 1 query.
Will not it be just nice if we could just write a SQL query directly from UI (picture that i am writing and executing a SQL query directly from my extjs code and get response as json). Here anyways UI dictates its needs both in terms of the data columns it needs and criteria on which it needs the query.
  I might be downright stupid to think this way , from the hallowed Domain Model design pattern etc. , that i am going to find out sooner than later but this at the moment makes a lot of empirical sense.
In my earlier workplace i have caught some glimpse of RESTful apis , of how UI independently evolve around a backend that represents a set of Resources and services on them interfaced through json-on-HTTP.
This dilemma could not be new , just that i arrived late and am hunting for the name , can one of you point me to the right direction
Some kind of fluent language in which UI can talk to the backend to ask for data and services but the interaction should not be chunky as we see in standard practice i.e in terms of specific api calls , but rather a grammer based something like SQL, you know what i mean ?

is this code Clean ? or is it my mind .....

I just completed reading chapter 15 of the famous CleanCode book by @unclebobmartin but  there is something that makes me feel uneasy.

    The chapter was illustrating the process of refactoring an existing class from the junit framework , the final draft was really inspiring and beautiful. But my problem is the way that class is designed on a whole , to draw a simple comparison , consider a class for adding 2 numbers , let us call Adder such that 1> Adder myAdder = new Adder(3,2); 2> int sum = myAdder.add();  
    Please excuse me if the above example looks too naive but the point i am trying to make here is why should i write a stateful class which is immutable anyways and utility is to expose behaviour for which it acts only on its initialized state .  
    The only justification for such construction are the standard type wrappers e.g String, Integer ..et al. But to write a such a class with the intention of using it as a general utility doesn't make sense to me or am i missing something here, please share ur thhoughts on this.  
    This particular construct is very recurrent in the examples of that book and makes me curious at its apparent incongruence with everything that book stands for and hence i think  should discover the logic

Thoughtworks interview - the dark side

"Hello, This is Manisha, from HR at Thoughtworks ...".My heart leapt to my throat but i was ready. Fate had written this script for me and i have rehearsed it well and finally this was my big moment under the arc-light. The entry was true to the script, "How/what do you know about thoughtworks ??","how good are u at OOP/design pattern ? .. etc". Then she explained about the coding assignments , code has to be written for any of the 2 (famous) problems viz. the mars rover problem or the sales tax problem and had to be submitted in 2 days time.
The next 2 days (it was a weekend) were among the happiest and most intense of my life, i had written code for the mars rover problem some time back as a practise , it was time to pull that code out and take a long hard look at it. I had lived the last 4 years of my professional life preparing,in every thing i did big or small , in every line of code i wrote , in every bit i thought about design , in my beliefs and readings , conciously or subconciously , for these 2 days.I had to give it my absolute best but nothing seemed to be matching up to the moment , finally i was done on the Sunday night , uploaded the code and mailed the HR. The intensity of the 2 days finally gave way to the string of expectation.

I had lived through the first act of the script and now was the time to watch the sand and wait for the call for the second act if there is to be any, what was dischordant though was that the HR did not acknowledge my submission, this was pure bad manners at the mildest but i decided to flow with the dominant mood of the moment. A little subplot here though was a consultant from Wenger and Watson, who spoke glib and claimed to have got me the call , though i had uploaded my resume on Thoughtworks career site www.thoughtworker.com the day before i got the call, i thought it won't hurt me if they too have their bit of fun out of this.

From expectation to apprehension to despair to acceptance , i watched the sand to trickle out when almost after 2 weeks, there was another call. The consultant called to tell that i have made it for their face-to-face rounds .Fate had longer plans.Once again HR was cold. I demanded atleast a mail acknoledgement of this from the HR . I was told to take the day off as it is going to be a day long affair . I had some idea of what that might be like from the 36,921 results of google search for "Thoughtworks interview".

So there was I ,all prepped up in their office at the appointed time . I went to the front desk asking for the HR and they requested me to wait , a wait that was uncustomarily almost annoyingly long. I chose to look away from this ominous start. The HR finally showed up , explained me the process. The first bout was to be a written aptitude round of about 12 flowchart based questions in 3 or 4 flavours , this was to last for 1 hr 15 mins. The set was doable but requires absolute and intense concentration. Good warming up. After this was that part of the day i was looking forward to, a person came in with my code opened in his laptop. I was to pair with him for an assignment he had . This was joyful, the person was an absolute treat to talk to, we discussed about the problem and i explained how i was planning to attack the problem, he presented his opinions and i talked out my approach as i was driving, he seemed to be satisfied with the proceedings. It was lunch time by then and the solution had been fleshed out to quite a detail, did not have to finish the full coding though as he said it was good enough and we broke for lunch. So far the script was gud and i thought i was one up.

Post lunch came the part that was hard to chew and gave me heart burn . There came 2 uninterested looking guys for my first tech interview with a copy of my resume, scanned it in detail about the technologies i had used in different projects, then hard pressed to have to ask a question started with db representation of a graph ,they obviously had no direction in mind and it was a grapple match. This could have been an easy deja vu except for the fact it isn't , something was seriously wrong here because in the thoughtworks i fantasized about nobody talks like this. Ultimately this round was over and i was tasting chalk and sawdust in my mouth. Then came another gentleman, an agile coach and a thorough thoughtworker and it was another delightful talk about clean code, Uncle bob, joshua bloch, my views on software craftsmanship, joshua bloch , the kinda stuff that makes everything else worth it and makes feel life good. The script was back.

After this they wanted to make sure i was not suffering from Alzheimer's 50 aptitude questions in 12 min and a personality test. Ohh and one more thing , their power backup sucked and i was on more than a few occasions left in dark, once again i chose to look the other way. It was 5 and i could feel individual tissue in my head . Overall it was a good day and when i assumed that it was done for the day , was the shocker , a sick looking person from the hr came with a paper saying , that i did not do well in the aptitude test , i got only 35 out of 50 correct (70% whoa!! they were greedy) so i have to re take the test, my head hurt , i was stoical , i wanted to go home see Mom, i wrote the test wished them well and came out.

It was a good day but not perfect and what was niggling was a little thorn somewhere, something was not right. Counting on all their body languages i would say i would have made it , but the Final act is what made fate Fate.

*The Final Act*

This was the final week of notice with my then employer and my other suitors :) were getting restless, i have held them up all in bay all i needed was 1 word from thoughtworks and i would leave it all and come. I requested them before i left that day that they have to get back to me with their final words in max. 3 to 4 days under the circumstances.
3 days went off , deafening silence , i pinged HR several times and by now i had given up on positive civil behaviour from this particular HR, not a single line in a mail was what amazed me , i knew it was thoughtworks and i had stars in my eye all right but this was pure arrogance that i have not seen in any other company that i came across so far in my professional life. The word finally came, from the consultant , "you did not make it".

This story would not have been written if it finished in the line above. As you have guessed it did nto finish there, a call came just when i had finished picking up the pieces , the call came . The consultant greeted me and told that i had actually made it but there was no vacancy(1) for the Bangalore office , hence my options were Chennai and Gurgaon !!.
A shock and a thud , i am recently married , my wife works in bangalore, right now relocation is difficult for me , this was the most cruel,sick joke from a company like TW when they have 2 offices in bangalore and AFAIK serves customers outside of India!!, this was more bizarre then i could have ever expected , she spiced things up from the really juicy:-
" the sex ratio in their bangalore office is pathetic (2), so they have suddenly decided to let only females in their bangalore office , (for all ye moron) males Chennai is the option " to the more lame duck " They have suddenly decided to recruit architects at bangalore with 9+ yrs(3) of exp, since you don't fit the bill got Chennai". To top it all was the conspiracy theory " we just probed the HR(mythical animal in thoughtworks)on this and she told your grades in interview were not good enough for Bangalore hence Chennai".
This was rape of something i absolutely adored, worshipped hence to put things in perspective the following points :-

1. TWI interviewed me for the purpose of an opening with Bangalore office. They never communicated with me that this was for any other location.

2. the HR adamantly and inspite of my several endeavours just REFUSES to communicate (Manisha Naik). There is absolutely no clarity or transparency about their entire process.

3. They take inordinately long time at least by Indian standard where till middle level positions have notice period of 1 month most companies closes the hiring process with offer rollout typically within 2 weeks , they go on for 2 months or dont care/give a damn.

4. Apparently, they use services of hiring agencies like Wenger and Watson, but these people give out all sorts of info that are misleading to say the least , as evident in 3 stories they told me . These explanations/stories which i take to be actually sourced at TWI point to darker malady.

5. **Thoughtworks apparently follows an internal grading system whereby in India the best people are in Bangalore , and the 2nd grade people are at Chennai or Gurgaon** , the implications are grave so anybody accepting an offer from TWI for Chennai or Gurgaon is going to be a 2nd grade citizen in TW with obvious implications on salary, career prospects. This also mean that the software/solutions developed by TWI Chennai and Bangalore office are only 2nd grade as are its people.

As a desperate effort to bring in closure on the event i told the cosultant that i may consider Chennai, and based onthis surety from me she arranged for a further round of interview :) , this time it was GM of chennai branch Mr. Ketan (HajarNiwas ??) and i explained him my position regarding shifting base . He was courteous, apologies for HR's callousness and promised that the HR will get back to me shortly to provide a closure on this. As expected the HR never called back , but the consultant called to say my candidature has been dropped.

It is difficult to see your heroes die and tragic to see them raped this way, my cupboard is empty. It will take sometime for me to figure out what is there for me to do now , but i am glad that i will not have to bear this again.

View from the other side ... how do u like their company ??

Recently i came across this talk bye Joseph Nye on power equation , which led me into thinking how closely this maps to that most favourite grouse of ours(techies) viz. work culture at our places of work. An ideal place of work should be based on the 3 principles of a) Compassion b) Passion and their natural consequence c) Innovation.
a) Compassion - is at the root of it all. It is the love , respect and care that transforms a business relation(employer - employee) into something of greater value. Respect to the techies for their expertise, the value that they bring to the organization. It is obviously more than another department in the organization that just provides a utility at some cost. As Joseph Nye points out , there are 3 ways of having your will done i. By Coercion, threats etc. ii. By enticing the other person or iii. By making the other person want what you want . The first 2 constitute what is known as hard-power where as the last one make up that has come to be known as soft-power. This brings us to the next principle of Passion.
b) Passion - Programming is as much a mode of expression , as much a creative discipline as writing or painting is and as in other disciplines it requires passion and complete immersion of its practioners to produce the excellent work. Every shop that does "tech" must acknowledge this fact and should actively promote that culture and conversation in its DNA that addresses and nurtures this urge in its employees. In this context , these artists are the most valuable "asset" to the company and the trick is in aligning the companies goals and the creative fulfillment that the "artists" seek. The symbiosis is fulfilled in the acts of compassion for the employer that goes beyond the business relation and works for nurturing the talents of its employees beyond its immediate need and the employee that goes beyond his call of duty to bring value. It could be something anything from "20% project" , organizing a "friday tech talks" or any of such initiatives. No organization is small or big enuf for any of such initiatives.
Another manifestation of respect and compassion is by the way of involvement where the company seeks and promotes the views of its technical assets across the functions , creative as they are , the ideas that might be brought to table can only have positive spin-offs for the company.
Bottom line is unlike any other job this profession is not a business transaction at the end of the day where one renders some service for a price. There is a human side to this and a very valuable yet intangible transaction that needs to be settled as much as the tangible one , only difference being here the currency is of compassion and passion.

new trends in data modelling...

This is actually a continuation of the earlier post. Although i haven't got the feedbacks and the answers i was seeking , the journey continues . I came across the following enlightening post from thoughtworks about the current scenary of data modelling http://www.thoughtworks.com/articles/nosql-comparison , a great read indeed and a recommended reading to anybody interested in the topic.
Following are points i have gleaned from these and other topics :-
1. These are interesting times in history when the case for polyglot db architecture is slowly but surely breaking into the scene. The days of 1-size-fits-all solution of rdbms is over , now it is back to the future where each piece of data that an application interacts with has to be understood in context of its probable reads, writes , performance requirements, functional requirements etc. as, given the various sets of newer technologies that are maturing , there might be cases for various solutions other than rdbms .
As the article points out few of these cases are :-
i. static/lookup data (readOnly) - these are config data that are changed only at deploy times. Currently there are 2 solutions ti.e a) employed put them in .properties file and read them with java/cache them in jvm at load time or b) keep them in db if there is use case of having a configuration management software to update such data on the fly. So the data is mostly "read-only" or sometimes "mostly-read-only-rare-writes". So just to accomodate rare writes having to store them in a rdbms is an overkill.
ii. Semi-structured documents - This is a niche case , but doubt here is a universal one , how do you work with semi-structured data(undefined schema ) in a object-oriented language as java . I mean, to ask a very dumb question here , is how do u write the freaking models ?? and how do u write logic . Do u assume a schema with all possibilities ??
A related area is structured documents like xml that comes with additional facility to query. Its once again a judgement call of how much information can be left with the document itself and how much of it is to be extracted to separate db.
iii. Object store - Given the romance of ORM, where all u see are objects and by some magic they are persisted and whenever u see them u get 'em shiny objects . This is perfect if u never need to dissect the magic below by querying etc.
iv. Metadata or data that are to be heavily mined to glean information for reporting and other non-realtime requirements. The rigour of relational data here proves to be its undoing as the zillion of joins creates serious performance issues. Normalization were devised in an age where storage was expensive but given the situation today where storage comes rather cheap, its the response time that holds the key. Denormalized reporting tables is a traditional solution, and as the article describes graph db is suited for niche cases like social networking etc and i am sure there are other scenarios that can also be served by that approach.
Bottomline here is the store for such "non-realtime data " has to be segragated from the main transactional data so that these solutions can be implemented later.

This vision of future do have one caveat as i see it, the data of an application is distributed over many different systems and apart from very smart and versatile developers , you require a polished IT and deployment strategy to hold it all together.

And finally , to harness the power of these different technologies from a OO world , new paradigms are to be invented as also all these technologies have to come up with query language support/portability to survive and make it big

ORM and beyond ..

My recent work involved writing something that is resembling more and more like a ORM implementation , like a deformed and abandoned sibling to Hibernate ;) . This in an environment where bitching about everything that's wrong with ORM makes for a good intellectual conversation and where NoSql is the topless bar that we as teenagers have sneaked into , tantalizing but not sure what to make of it .
So following is a list of issues that i have hit while working here , these are not exactly eureka stuff , these are common stuff that have been solved many times over . With the disclaimer that i am a novice in this i still document them as a note to myself as go forth and look into the wilderness for answers to some of them , will much appreciate if some of the readers can point me to the direction of solutions or more questions.

1. When i am writing a ORM based persistance layer it should be enuf , after the major models have been identified , to just have 2 methods for the models i.e save(Model mdl) and get(). is tat so ??

2. What is the granularity of the domain model ?? Given any domain it is always possible to have one super-grand-model that holds everything else like a company class that has departments that has ..... so any update on any employee on any department would still result in a save(Company cmp) . This is my understanding and my feeling is something is embarassingly wrong here , so wat is wrong ??
Now to spice things up a little bit more let us throw document-oriented dbs in how does all these things tie up. Documents to model ties up nicely with wonderful things like json , Jackson etc, but when things are large like u have a zillion departments and u have to update home address of 9999th user in 78976th dept u still have to deserialize the entire elephant (company in this example) and then iterate and change and persist .
Something is obviously very wrong here and i suspect the traditional object oriented view of data is the culprit , can anybody enlighten ??

3. When modelling a relationship what factors determine navigability , i mean as normal java guy it is most convienient to be able travel to and fro from any point in hierarchy . But should we enforce some discipline there ??

4. Getting back to the example scenario of point 2 above , say there is a composition we want to model like a Department having n people associated with it and say one among the n is a departmentHead a fact that we know from his role (role is also used by our security system). But the technical pain here is whenever i read a department object with thousands of people in it , and i want to know who the head is i have to iterate through the list of 1000 to get to it. There is an urge to keep a reference of this guy directly under the Department class that saves a lot of iteration but that is duplication of information also , but still this solution can be used if this is something we do at the programming layer and change db design for it . Any thoughts.

5. In enterprise apps space where the demands scalability is limited does the noSql,commodity sever camp bring any value or they are still going to stay old school for some time.

To be continued..