Saturday, December 22, 2007

Life is like that

... was driving my bike from somewhere to nowhere, frankly, was trying to keep my head empty, a deliberate attempt to forget everything and simply enjoy the breeze gushing against my nostrils, while I was racing past trucks... here was this one, freshly painted in green.. with all the paraphernalia that a truck might have.. I must admit the owner had a taste (here, I would also like to admit my liking for these mechanical beasts - the bigger the better)... I slowed down to read the punchline that he might have written at the back of it... and there it was 'कभी सर्दी तो कभी गर्मी ये तो दुनिया के नज़ारे हैं, प्यास तो उन्हें भी लगती है जो दरिया के किनारे हैं.' ... and in that instant I slowed down to feel the beauty of the hills around me... life is fun.

Wednesday, November 28, 2007

Developing Telecom Class Software

... there is lot more to be learnt to create highly available systems, the first atempt today took me to http://www.sun.com/blueprints/1100/HAFund.pdf which gave head start into high availability fundamentals related with the hardware and software, associated concepts of reliability and serviceability and some statistics ! that would help us quanify the results... that brought another question to my mind what does it takes to create a highly available J2EE application (read )... more to follow...

Monday, October 1, 2007

Another year is about to pass...

Acck - chooooooooooooo !.. sneeze.. finally winters are here, bringing with it the long endless nights, the lethargy, the dullness... chances are you won't like my statements, chances are I won't like them either when I read them later... may be I should sleep now !

Tomorrow onwards, I need to get up early and do some jogging and physical exercises, to counter the negativity in me...

Saturday, September 29, 2007

Come On India - Dikha do !!

India's strong rupee

... these are new sets of challenges before us, now that we 'exporters' are facing an uphill task to complete, it is important to note that 'cheap' is out and need for 'quality' is in, some years back I read a writeup where the writer stressed the need for correction in our 'Incredible India' campaign from 'cheap' to 'cost-effective' and our associated mind-sets.

... now that we are trusted for our services, we need to be innovative and create value added services, and more importantly, we need to come up with more 'products' in place... to truly become a power to reckon with...

... and I truly second the writer when he says - '... an enviable problem to solve'

Friday, September 28, 2007

Opinion: Is it a disease or a symptom ?

... referring to this article, I have mixed reactions to share... may be I truly understand the concerns of NASSCOM when they rubbish the health minister's views towards the unhealthy work culture at IT/ITES work place, fearing increased government control or may be this can potentially scare away the investors or may be this can give voice to feelings of those who go through the grind everyday or may be we are not too sure of the real intent of the minister.... what if he is really concerned about the state of affair ? what if he is pointing towards a symptom of a bigger problem ahead...

frankly speaking, i strongly believe that government must work like an operating system, that runs the 'system' while hiding most of the underlying complexities... and based on the 'user-settings' can take control quartine it or point to a potential problem to enable 'user' to take an informed decision.


I would not like to start the usual 'yada-yada' of he great Indian Heritage of disciplined life... but isn't it high time we truly take note of minister's statement and try bringing some discipline in our lives... Cheers for a healthy India :)

Wednesday, September 26, 2007

XML: Cornucopia

... well you see, I discussed in one of my previous post that certifications play an important role in giving structure to your study, they establish a common minimum program to be covered... little did I know that when one is going to study XML it can get tough even though you have an agenda in place. In the absence of any one-stop-key-to-success-guide books available in the market, it is difficult. I could now feel what exactly the phrase 'xml-hell' would mean for people who swear by it :))

The verbosity of XML content has it's own woes... there seems to 'too-much' of information available everywhere... Call it my XML cornucopia ... one neat resource for study...

Sunday, September 23, 2007

XML: Design and Architecture

http://www.ibm.com/developerworks/xml/library/x-eleatt.html

When to use elements versus attributes ?

Any one who has worked with XML will very well know how difficult it becomes to answer this question and in the absence of any clear guidelines the whole information modelling exercise may get wrong. The above article provides a head start towards that end.

In some cases the answer is pretty unambiguous:
  • If the information in question could be itself marked up with elements, put it in an element.
  • If the information is suitable for attribute form, but could end up as multiple attributes of the same name on the same element, use child elements instead.
  • If the information is required to be in a standard DTD-like attribute type such as ID, IDREF, or ENTITY, use an attribute.
  • If the information should not be normalized for white space, use elements. (XML processors normalize attributes in ways that can change the raw text of the attribute value.)
For the grey areas the tips are:
  • Principle of 'Core Content': Data goes to elements and meta-data goes to attributes. Simply put the data elements which form part of 'your' solution domain are element, while those 'qualify' or provide more details about the core content goes to attribute.
  • Principle of Structured Information: If the information is 'extensible' make it an element, while 'atomic' tokens goes to attributes.
  • Principle of Readability: If the information is to be understood by the human readers make it an element, else create an attribute. As the writer puts it '...information tokens that are not natural language go in attributes.'
  • Principle of element/attribute binding:Use an element if you need its value to be modified by another attribute. XML establishes a very strong conceptual bond between an attribute and the element in which it appears. An attribute provides some property or modification of that particular element. Processing tools for XML tend to follow this concept and it is almost always a terrible idea to have one attribute modify another.

XML: Start here

http://www-03.ibm.com/certify/tests/edu142.shtml

The good thing about certifications is that they provide a well-defined structure. This is important to set SMART goals for oneself.

Long way to go before I sleep...

XML: The certification path

Web 2.0, Semantic Web, Service Oriented Architecture, Model Drive Architecture, Code Generation... the list looks fantastic and are sure the buzz words today. In an attempt to understand the concepts, one really needs to be adventurous, start at edges and an inter-disciplinary approach is required.

In order to tame them I have my set of tools with me, while I'm fairly comfortable with Java, I do not have much undersanding of XML concepts. I wish to fill the gap by learning XML...

Saturday, July 14, 2007

to read: The World is Flat

read more here Amazon.com: The World Is Flat: A Brief History of the Twenty-first Century: Books: Thomas L. Friedman

Friday, July 13, 2007

Agile Methodology: A first take

Agile methodology, extreme programming, test driven development go hand in hand and complement each other to help software engineers to create value for people at large and avoid the proverbial 'tar pit'.

Here, is my primer for the much appreciated methodology:
  1. Software Configuration Management: You can have nothing else in your technical environment other than a version tool and still manage the 'chaos' if you can uniquely answer Who did it? What did he do? When did he do? Why did he do that? (optional but strongly recommended.)
  2. Planning: Here it is important to understand the concept of a plan. A plan is a road map to move from point A to a point B and steps required to return back to the starting point A. The relevance of such a concept of a plan becomes easy to digest if one considers that a change in the a software artifacts is analogous to the experiment conducted in a lab, in a controlled environment. The risk involved must be controlled and if even after the best attempt the experiment fails one could always return back to the last known stable state of the system. Care must be taken that while it is fairly easy to plan to move ahead, it requires a thinking mindset to retrace back after cleaning your footprints in case some goof up happens.
  3. Unit Testing: Let's take the simplistic concept of 'unit' as the piece of code block which completes a logical set of activity to achieve a single objective and no more. While writing the test cases one must remember Pareto's 80/20 principal while writing important test cases plus the test cases which ensures that the system is performing as expected with the right set of inputs. There is no point in being over ambitious by attempting to write exhaustive test cases for a discrete system. Unit testing really shines during regression cycles, where in you can ensure that any new line of code is not breaking the existing system and can easily measure and monitor the 'ripple effect' if any. Please do not assume the being easily done is easy :)
  4. Feedback Loop: Make it short and make it fast. Doing this will help you identify the problem early and save COST. There are tools available today for continuous integration which can really help one to achieve this end.
The above is not merely a listing of my random thought about this methodology, but is an incremental set activity that one might need to undertake to completely embrace this practice from being an absolute novice.

Sunday, March 25, 2007

Need for JUnit Framework for testing:

Yes ! this was exactly the question that was there in my mind for quite some time. It is interesting to spot the difference between my thought process before and after reading JUnit literature.

Before:
- Who needs the test cases for minor methods, after all can they really be broken ?!
- I can test my units by running them repeatedly, manually.
- If need be I can write a driver program that can run my units to be put under test.
- I understand JUnit is a standard framework, but who has the time to learn a new framework - My manager doesn't want 'JUnit' test cases either.

Then I read about the thumbrules for writing test cases:
- Each unit test must run independent of the other.
- Errors must be detected and reported, effectively.
- It must be easy to identify and selectively run unit tests.

Also, that the Framework provides following infrastructure support;
- each test is loaded using a separate class-loader, that makes running and failing different cases practically independent of each other.
- registering and introspecting methods, using which one can select which tests to run in particular.
- reports all errors on a case by case basis.


After:
How can you do it with out JUnit !! :-)

Friday, February 16, 2007

Thursday, February 15, 2007

O'Reilly -- What Is Web 2.0

O'Reilly -- What Is Web 2.0

Must read for anyone who even remotely are associated with business of technology or in the technology of business.

to read:

The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How Collective Wisdom Shapes Business, Economies, Societies and Nations (Hardcover)
by James Surowiecki

read more http://www.amazon.com/Wisdom-Crowds-Collective-Economies-Societies/dp/0385503865