A shot at photoblogging
I got myself a barcode using TALtech's free online utility. That was just an excuse for using the Photoblogging feature on Blogger, powered by Hello. You can tell its a slow evening.
Monday, June 28, 2004
I got myself a barcode using TALtech's free online utility. That was just an excuse for using the Photoblogging feature on Blogger, powered by Hello. You can tell its a slow evening.
J2SE 1.5 Varargs - A solution looking for a problem?
I have mixed feelings about the J2SE 1.5 feature of varargs. Briefly speaking, this feature provides an automated means to hide a method's acceptance of a variable number of arguments. According to Sun, "[this] facility eliminates the need for manually boxing up argument lists into an array when invoking methods that accept variable-length argument lists". Until now API designers would typically use an Object[] to accept a variable collection of arguments. With Java 1.5, a new ellipsis directive (...) is introduced. When placed after the final parameter's type, this indicates a sequence of arguments. Note: These varargs can only be used in the final argument position. See here for more information.
I have blogged previously about inconsequential language features being added to J2SE 1.5. This particular feature plays nicely into that rant. Now, let us look at a boilerplate call using the ubiquitous example of one of the
which can now be altered to
I will readily admit that this new representation is elegant, to say the least. API users are made aware that this method can take a variable sequence of arguments as its second parameter. That fact isn't hidden in javadocs; the signature itself speaks that out loud. In addition, the API tells you that the method isn't interested in traversing your array or manipulating it otherwise. It is only interested in the arguments you pass. So far, so good.
One can well make the case that limiting the varargs to one per method -- as is the case in 1.5 -- can be restrictive. In such cases, you would have to resort to the current practise of using an array. There is also the issue of backward compatibility or lack thereof. I do not anticipate seeing developers rushing to add support for varargs in code that has hitherto used concise object arrays. It gets worse when you think of overloaded methods that use varargs. It may not be easily apparent which method actually gets called. Sun -- to its credit -- does state this fact:
In that sense, the new vararg feature speaks to a very small constituency. It comes across as a solution looking for a problem. Of course, I may be missing some merits that more the experienced code cutters will recognize. I am however eager to know what they are, so please use the comment option below.
Update: I forgot to add this thread from the Java forums on "jsr 201 including varargs in public review" from Jan 25, 2004.
I have blogged previously about inconsequential language features being added to J2SE 1.5. This particular feature plays nicely into that rant. Now, let us look at a boilerplate call using the ubiquitous example of one of the
format method signatures in java.text.MessageFormat, which creates a MessageFormat with the given pattern and uses it to format the given arguments:
public static String format(String pattern, Object[] arguments);
which can now be altered to
public static String format(String pattern, Object... arguments);
I will readily admit that this new representation is elegant, to say the least. API users are made aware that this method can take a variable sequence of arguments as its second parameter. That fact isn't hidden in javadocs; the signature itself speaks that out loud. In addition, the API tells you that the method isn't interested in traversing your array or manipulating it otherwise. It is only interested in the arguments you pass. So far, so good.
One can well make the case that limiting the varargs to one per method -- as is the case in 1.5 -- can be restrictive. In such cases, you would have to resort to the current practise of using an array. There is also the issue of backward compatibility or lack thereof. I do not anticipate seeing developers rushing to add support for varargs in code that has hitherto used concise object arrays. It gets worse when you think of overloaded methods that use varargs. It may not be easily apparent which method actually gets called. Sun -- to its credit -- does state this fact:
As an API designer, you should use them sparingly, only when the benefit is truly compelling. Generally speaking, you should not overload a varargs method, or it will be difficult for programmers to figure out which overloading gets called.
In that sense, the new vararg feature speaks to a very small constituency. It comes across as a solution looking for a problem. Of course, I may be missing some merits that more the experienced code cutters will recognize. I am however eager to know what they are, so please use the comment option below.
Update: I forgot to add this thread from the Java forums on "jsr 201 including varargs in public review" from Jan 25, 2004.
Thursday, June 24, 2004
A look at two-phase commits
The two-phase commit model has been used for over two decades in governing transactions in distributed systems. New enterprise developers often have a difficult time understanding the significance of transaction boundaries and their role in distributed systems. I willingly admit I was in that position once, not too long ago. This entry aims to provide an introduction to some of these concepts to the uninitiated or the newly initiated.
It is common for enterprises to have applications that simultaneously update data in multiple databases. One can easily visualize the number of moving parts in this setup. In order to deliver on their promise of atomicity, consistency, isolation, and durability (or ACID), transactional systems must ensure data integrity and accuracy by providing some sort of synchronous locking mechanism. Transactions therefore provide the glue that ties one or more of these operations together so they occur in an atomic unit or not at all. To understand two-phase commits, one must have a clear understanding of transactions.
The term resource manager is used to signify an external data store or entity accessed by an application. An RDBMS, a JMS provider or an EIS system, are all examples of resource managers. Typically resource adapters expose the resource manager’s APIs to the J2EE server and applications running on that server. As is immediately apparent, the start and the end of a transaction constitute the milestones that determine a transaction’s boundary or demarcation. When an application begins a transaction, it creates a transaction object. It then involves the resource managers in carrying out the transaction while abiding by the ACID principle. The first call to the resource manager identifies the transaction. All subsequent calls happen under the umbrella of that transaction, until the transaction is signaled as ended. The success or failure of the transaction determines whether the updates are to be committed or rolled back.
In a system with multiple databases (or resource managers) participating in a transaction, each participant must commit or rollback based on the outcome, in unison with the others. And this rule holds even if there is a network failure encountered while connecting to one or more of the participants. Databases and other transactional systems rarely ever get a ‘works well with others’ note in their report cards. Hence there is an inherent problem of who will co-ordinate this transaction, ensuring that each participant does its part. You could go ahead write all this logic [as has been done in the past, and I suspect continues to this day] or you could use a transaction manager. Thankfully the coding habits of chimps are well known and widely documented. J2EE servers provide the Java Transaction Service (JTS) to co-ordinate transactions [surprise, surprise!] Most transaction managers use the X/Open XA protocol to communicate with multiple resource managers in a distributed system. Transaction managers are capable of transparently forwarding transaction context from one component to another as also to resource managers.
And this brings us to two-phase commits. There are two distinct stages or processes [or phases, you might add] that constitute a two-phase commit:
When I started writing this blog, I had imagined it to be my own op-ed page. I have since learnt that opinions by themselves can quickly turn boring. I selfishly hope that entries such that this will help newbie developers understand frequently thrown around acronyms and terminologies better. That’s if the gods at Google are on my side.
PS: A shout out to my buddies from Resource Adapters (RAi). The time I spent working at RAi in the Valley was the most educational contiguous 7 months ever. We did some pioneering J2EE CA stuff and had a penchant for the dramatic!
It is common for enterprises to have applications that simultaneously update data in multiple databases. One can easily visualize the number of moving parts in this setup. In order to deliver on their promise of atomicity, consistency, isolation, and durability (or ACID), transactional systems must ensure data integrity and accuracy by providing some sort of synchronous locking mechanism. Transactions therefore provide the glue that ties one or more of these operations together so they occur in an atomic unit or not at all. To understand two-phase commits, one must have a clear understanding of transactions.
The term resource manager is used to signify an external data store or entity accessed by an application. An RDBMS, a JMS provider or an EIS system, are all examples of resource managers. Typically resource adapters expose the resource manager’s APIs to the J2EE server and applications running on that server. As is immediately apparent, the start and the end of a transaction constitute the milestones that determine a transaction’s boundary or demarcation. When an application begins a transaction, it creates a transaction object. It then involves the resource managers in carrying out the transaction while abiding by the ACID principle. The first call to the resource manager identifies the transaction. All subsequent calls happen under the umbrella of that transaction, until the transaction is signaled as ended. The success or failure of the transaction determines whether the updates are to be committed or rolled back.
In a system with multiple databases (or resource managers) participating in a transaction, each participant must commit or rollback based on the outcome, in unison with the others. And this rule holds even if there is a network failure encountered while connecting to one or more of the participants. Databases and other transactional systems rarely ever get a ‘works well with others’ note in their report cards. Hence there is an inherent problem of who will co-ordinate this transaction, ensuring that each participant does its part. You could go ahead write all this logic [as has been done in the past, and I suspect continues to this day] or you could use a transaction manager. Thankfully the coding habits of chimps are well known and widely documented. J2EE servers provide the Java Transaction Service (JTS) to co-ordinate transactions [surprise, surprise!] Most transaction managers use the X/Open XA protocol to communicate with multiple resource managers in a distributed system. Transaction managers are capable of transparently forwarding transaction context from one component to another as also to resource managers.
And this brings us to two-phase commits. There are two distinct stages or processes [or phases, you might add] that constitute a two-phase commit:
- the Prepare phase where the transaction manager informs all participating databases about the transaction. At the completion of this stage, the transaction manager expects each resource manager to be ready to either commit or rollback their changes.
- Each resource manager in turn returns a success or failure indication. This is the Commit phase, where the transaction manager instructs all participants to commit the transaction. If all resource managers cannot prepare or if there is some kind of failure, the transaction manager asks all resource managers to roll back.
When I started writing this blog, I had imagined it to be my own op-ed page. I have since learnt that opinions by themselves can quickly turn boring. I selfishly hope that entries such that this will help newbie developers understand frequently thrown around acronyms and terminologies better. That’s if the gods at Google are on my side.
PS: A shout out to my buddies from Resource Adapters (RAi). The time I spent working at RAi in the Valley was the most educational contiguous 7 months ever. We did some pioneering J2EE CA stuff and had a penchant for the dramatic!
Sunday, June 20, 2004
Dropload
This is a useful tool for all those whose email providers set a limit on the message sizes. That includes you guys with the snazzy new 1GB Gmail accounts. The Dropload blurb says this: "[this] is a place for you to drop your files off and have them picked up by someone else at a later time. Recipients you specify are sent an email with instructions on how to download the file. Files are removed from the system after 48 hours, regardless if they have been picked up or not. You can upload any type of file, mp3, movies, docs, pdfs, up to 100MB each! Recipients can be anyone with an email address."
As welcome as a turd in a pool
Now this kind of stupidity must really result in people getting fired. Lots of people. Whole teams. Not in this case though. In Boing Boing, Xeni Jardin blogs about Spiderman going to Bollywood:
I strongly encourage you to follow the link to Gotham Comics above and see this idiocy for yourself. Unbelievable! First the Tobey Maguire and Kirsten Dunst sleep inducer. Now this. I wonder what Stan Lee has to say about the decline of his creation. I grew up in India and like all the other 80s kids I knew there, I too was into Spidey comics. We watched open mouthed, his every move in the weekly animation series on network television; supreme admiration written large on our faces. We spent many a boring hour at school doodling Spiderman's action sequences in the back of our notebooks. We didn't know Spiderman had a romantic side or a spiritual one. We didn't care! That's why this new avatar of Spiderman is as welcome as a turd in a swimming pool. But maybe its all about pandering. Maybe its all about the money.
Marvel Comics and Gotham Entertainment Group are introducing a new version of Spiderman regionalized for South Asian audiences. In the Indian version, Peter Parker becomes Pavitr Prabhakar; instead of fighting the Green Goblin he'll battle Rakshasa, a mythical Indian demon. He's wearing a sarong-like garment, and he has unstoppable spiritual powers of asskickage. Link. (Thanks, Robin Pen)
I strongly encourage you to follow the link to Gotham Comics above and see this idiocy for yourself. Unbelievable! First the Tobey Maguire and Kirsten Dunst sleep inducer. Now this. I wonder what Stan Lee has to say about the decline of his creation. I grew up in India and like all the other 80s kids I knew there, I too was into Spidey comics. We watched open mouthed, his every move in the weekly animation series on network television; supreme admiration written large on our faces. We spent many a boring hour at school doodling Spiderman's action sequences in the back of our notebooks. We didn't know Spiderman had a romantic side or a spiritual one. We didn't care! That's why this new avatar of Spiderman is as welcome as a turd in a swimming pool. But maybe its all about pandering. Maybe its all about the money.
Friday, June 18, 2004
How eBay uses J2EE to support 1 billion transactions a day
For all those who missed it at JavaOne, here's a link to what I think is a true J2EE success story. The eBay development team discarded a 3.3 million line C++ ISAPI DLL [how much is that in blood, sweat and tears?] to a J2EE-based solution on [hold your breath] WebSphere 4.0 [now exhale slowly]. The presentation is a great testimonial to using patterns, optimizing code and the environment and a plain old good architecture. It requires a quick and simple registration but don't let that put you off. The content is worth it.
Thursday, June 17, 2004
Cleaning up my act
This Life Assessment Quiz I came across while reading Mark Pilgrim's blog tells me I need to clean up my act. I scored an 81 which means I have 19 areas I need to work on. So I am not the 'perfection personified' I thought I was? But that's according to these guys at 'Better Me'. Okay, by now those that know me will have snorted coffee all over their keyboards. I recommend you take the quiz too although I am in no way touting it as relevant or even accurate. It's all-in-one-page, with no form submissions involved, free (as in beer) and moderately interesting. So this is how I see myself:
Physical Environment
Money
Well-being
Relationships
Well as Ashley would tell me, this blog entry's as out of place as a one legged man in a butt-kicking contest. I hope you will bear with me on that. But I'm just dying to see what Google AdSense ads accompany this entry!
Physical Environment
- My personal files, papers, and receipts are not neatly filed away.
- I do not live in the geographical location of my choice. It's been a year and a half and all those who've told me "Oh don't worry, Rhode Island will grow on you", were wrong.
- There isn't ample and healthy lighting around me. I have been told the monitor doesn't qualified as a source of lighting.
- I am tolerating some things at my work place I maybe shouldn't. But I am not the first consultant to be the chief cook and bottlewasher at his job. Nor the last.
- My work environment isn't nearly as productive and inspiring as I'd like (or as it used to be).
- I don't back up my hard drive at least monthly. But I doubt I ever will.
- My bed is not made daily.
Money
- I do not live on a weekly budget. But I don't necessarily agree that's a bad thing.
- I do not have a financial plan for the next year.
- I do not have an up-to-date will.
- My earnings are not commensurate with the effort I put into my job. No, I am not overpaid.
Well-being
- I use caffeine more often than I should. Coffee and water are my two favorite diuretics.
- I eat more sugar than I should.
- I haven't seen a dentist in 2 years. I have a very low opinion of them. To me they rate between single-celled creatures and pond scum in the overall scheme of things.
- I haven't had a physical examination in 3 years.
- Not an eye examination either.
- I don't walk or exercise enough.
Relationships
- I never tell people exactly what they can do to satisfy me. Okay that sounds wrong but that's how the statement was posed.
- I haven't told my mom I love her, in over 3 months.
Well as Ashley would tell me, this blog entry's as out of place as a one legged man in a butt-kicking contest. I hope you will bear with me on that. But I'm just dying to see what Google AdSense ads accompany this entry!
Tuesday, June 15, 2004
Is this really esoteric?
It has been two weeks of sorrow getting Ant to fulfil our product's clustered deployment on WebSphere with pre- and post- deployment customizations. That Ant doesn't support looping was but the beginning of our problems. [When I say 'our' I don't mean to come across as royalty. It just means there were more just myself working on this.] Anyway, all that is a thing of the past. Or so I hope.
I came across this on java.net this morning. Some of you regulars may have already seen this. Martin Fowler has written about DiffDebugging which is just a fancy shmancy name for finding out what recent change caused a regression problem. That something like this has been documented -- against the grain of the Agile manifesto -- doesn't suprise me all that much. What does is that java.net gave it frontpage coverage [if you can call it that. I am never sure anymore.] My question is: doesn't everybody already do this? Isn't that the logical starting point? I don't imagine initiating new team members by letting them in on our team's little secret. That's right son, 'round here we use DiffDebugging. Yes, that will be the day!
I came across this on java.net this morning. Some of you regulars may have already seen this. Martin Fowler has written about DiffDebugging which is just a fancy shmancy name for finding out what recent change caused a regression problem. That something like this has been documented -- against the grain of the Agile manifesto -- doesn't suprise me all that much. What does is that java.net gave it frontpage coverage [if you can call it that. I am never sure anymore.] My question is: doesn't everybody already do this? Isn't that the logical starting point? I don't imagine initiating new team members by letting them in on our team's little secret. That's right son, 'round here we use DiffDebugging. Yes, that will be the day!
Friday, June 04, 2004
If you give peanuts, you will get monkeys
"If you give peanuts, you will get monkeys". So goes the old HR adage. When I look at companies outsourcing jobs primarily for lowering the cost incurred from payroll, I can't help but think about that line. An opinion piece by Paul Kimmel on Developer.com presents a viewpoint on the outsourcing question. I came across this article from an entry in Andrew Kuzmin's weblog. He describes Paul's article as "[offering] some straightforward discussion and insights on this current trend, including some historical perspective, where we are now, possible outcomes, ways to protect yourself, and how international outsourcing might unfold"
Paul Kimmel also provides some reasons why outsourcing of Information Technology jobs will fail in the next few years. I don't agree with his reasons. My take on it is that the quality of life for workers in countries like China and India will steadily improve with higher wages and other benefits. That will lead to an increase in purchasing power and they will now be in a position to own things they couldn't afford only a few years ago. This will start a cycle of higher salaries and higher purchasing. In a couple decades, it is very likely that a majority of these people (not everybody in China and India, mind you, but just these people) will demand exponentially higher wages. At that time it does not make too much economic sense to move or maintain jobs there on the basis of a wage differential.
So will companies bring those jobs back to the United States? Unlikely. Just as manufacturing bases moved from Mexico to China in the 90s, so too will they move from China to elsewhere. It is disheartening that unlike the US, these countries do not have the institutions to bear the brunt of a job exodus. Although, I will concede that IT and manufacturing are two very different beasts. Countries that churn out large numbers of engineering and science graduates do have an edge. In the US, over the years, a number of checks and balances have been created to counter unexpected downturns. India and China do not have any kind of mature medical insurance (universal or otherwise) scheme for a vast majority of their populations. Nor do they have unemployments benefits for their citizens. It is in the US interest to encourage these countries to remedy the situation with a carrot-and-stick approach: "If you want our jobs, make sure your people have some recourse for when we take those jobs away." Yes, there are no free lunches.
Paul Kimmel also provides some reasons why outsourcing of Information Technology jobs will fail in the next few years. I don't agree with his reasons. My take on it is that the quality of life for workers in countries like China and India will steadily improve with higher wages and other benefits. That will lead to an increase in purchasing power and they will now be in a position to own things they couldn't afford only a few years ago. This will start a cycle of higher salaries and higher purchasing. In a couple decades, it is very likely that a majority of these people (not everybody in China and India, mind you, but just these people) will demand exponentially higher wages. At that time it does not make too much economic sense to move or maintain jobs there on the basis of a wage differential.
So will companies bring those jobs back to the United States? Unlikely. Just as manufacturing bases moved from Mexico to China in the 90s, so too will they move from China to elsewhere. It is disheartening that unlike the US, these countries do not have the institutions to bear the brunt of a job exodus. Although, I will concede that IT and manufacturing are two very different beasts. Countries that churn out large numbers of engineering and science graduates do have an edge. In the US, over the years, a number of checks and balances have been created to counter unexpected downturns. India and China do not have any kind of mature medical insurance (universal or otherwise) scheme for a vast majority of their populations. Nor do they have unemployments benefits for their citizens. It is in the US interest to encourage these countries to remedy the situation with a carrot-and-stick approach: "If you want our jobs, make sure your people have some recourse for when we take those jobs away." Yes, there are no free lunches.
