Wednesday, July 30, 2008

Friday, July 25, 2008

Execute .sql script file using java

A few days back I tried to execute our database scripts file using java in a plain way but I am not sure how good it is? but I am done with my work with no known issues but still I'm thinking is that right way to parse entair .sql file and pass the each line to JDBC API and ask JDBC API to execute that line of SQL? Here it is the method I used...

public boolean executeDBScripts(String aSQLScriptFilePath, Statement stmt) throws
IOException,SQLException {
boolean isScriptExecuted = false;
try {
BufferedReader in = new BufferedReader(new FileReader(aSQLScriptFilePath));
String str;StringBuffer sb = new StringBuffer();
while ((str = in.readLine()) != null) {
sb.append(str + "\n ");
}
in.close();
stmt.executeUpdate(sb.toString());
isScriptExecuted = true;
} catch (Exception e) {
System.err.println("Failed to Execute" + aSQLScriptFilePath +". The error is"+ e.getMessage));
}
return isScriptExecuted;
}

How Hard Could It Be?: Five Easy Ways to Fail...

As useal I was surffing net and I found a very good article a must read one by Joel Spolsky is the co-founder and CEO of Fog Creek Software. Here it goes...

http://www.inc.com/magazine/20071101/how-hard-could-it-be-five-easy-ways-to-fail.html?partner=fogcreek

How ever I copied to here as it moves off

A huge number of technology projects go wrong. This is news to no one. Whether you run a software company with a number of ongoing development efforts or you have a nontech company that hires consultants here and there to provide systems integration, chances are you've bumped up against this problem. Delays, blown budgets, and outright failures are so common in the software world, in fact, that it's hardly newsworthy when a project is years late and millions over budget.
In 2003, for example, I flew out to Los Angeles for one of those conferences that Microsoft (NASDAQ:MSFT) occasionally puts on for software developers. At the event, Microsoft made a lot of exciting announcements about some of the revolutionary new features coming out soon in the next version of Windows. Looking back at my notes, I see that one of the important new features was something called WinFS. I'll spare you the boring details, but basically WinFS proposed to combine the file system features of your operating system (storing files and folders on a hard drive) with database features (where you store individual data records for easy search and retrieval) into one big unholy file-and-database mishmash.
This was quite an ambitious undertaking. WinFS was in technical terms approximately the equivalent of rearranging the nation's transportation system to accommodate flying cars. Yes, it would put airlines out of business, and yes, every garage would need to be widened a bit to accommodate cars with wings, but hey, we oughta be able to deliver this in a year or so. Two years, tops.
Three years passed. A manager at Microsoft named Quentin Clark announced on his blog that WinFS simply could not be delivered on time, and that it was holding up the launch of Microsoft's latest operating system. So it was going to be delayed and shipped, maybe, as a feature in a future database--meaning that it was not going to combine the database and the file system, which was the only thing that made it interesting. So how can you tell when one of your technology projects is destined to be another WinFS? Here's my five-step guide to ensure software failure:
Mistake No. 1: Start with a mediocre team of developers.

Designing software is hard, and unfortunately, a lot of the people who call themselves programmers can't really do it. But even though a bad team of developers tends to be the No. 1 cause of software project failures, you'd never know it from reading official postmortems. In all fields, from software to logistics to customer service, people are too nice to talk about their co-workers' lack of competence. You'll never hear anyone say "the team was just not smart enough or talented enough to pull this off." Why hurt their feelings? The simple fact is that if the people on a given project team aren't very good at what they do, they're going to come into work every day and yet--behold!--the software won't get created. And don't worry too much about HR standing in your way of hiring a bunch of duds. In most cases, I assure you they will do nothing to prevent you from hiring untalented people.

Mistake No. 2: Set weekly milestones.

Say you're remodeling your kitchen. That guy you hired to do the work has done a lot of kitchens before, and can estimate the cost of the job without having detailed blueprints. But software developers are building things that they've never built before. If they had, they'd just sell you another copy of the CD-ROM. So rough estimates are impossible. They need to draw up detailed plans before they start writing code. Whether you're the customer or the developers' manager, your job is to make sure they come up with that blueprint. When you ask developers for one, however, many of them will respond by creating a schedule that breaks pieces of the process into weeks. This may seem perfectly reasonable, but it's not. If you let a software team submit a schedule with big chunky estimates of time (by big I mean more than two days of work), you can be almost certain that they're not considering every detail that needs to be implemented, and those details will add up to a huge delay.

Mistake No. 3: Negotiate the deadline.

What's worse than accepting a schedule that breaks down a software project by the week? Demanding that a team commit to completing its work much sooner than forecast. In my experience, most developers are optimists and will take your cue and engage in split-the-difference bargaining. You'll have a nice, agreed-upon schedule that you'll never stick to.
Think of it in these terms: Mama walruses deliver their calves at the end of a 15- to 16-month pregnancy. You might ask the mother to commit to 15 months and she might say, "No problem!" Or you might say, "Fifteen months? Are you crazy? We need this in eight months!" Of course, haggling like this can't possibly make things happen any faster, and even if you get the walrus to agree to an eight-month timetable, I'll let you in on a little secret: It'll never happen. You can have a schedule that says 11 months, but you'll still ship in 15 months, because that is how long it takes to make a baby walrus. Sixteen, sometimes.

Mistake No. 4: Divide tasks equitably.

Here's a great way to torpedo any project. Make a list of all the work people have to do, and then reassign things to different people to balance the project. If Mary has too much work, give some of her tasks to John. This sounds completely sensible, so you won't be challenged.
But I promise you, in the long run it's sure to cause problems. That's because when one developer steps in to replace another, it's reasonable to assume that the new one will work at about one-tenth the speed. John's going to have to spend untold hours figuring out all the things that Mary already knows about her area of code. And John can't fix Mary's bugs as fast as Mary can because Mary knows where all the hidden traps are.

Mistake No. 5: Work till midnight.

Let's say a project should take six months at 40 hours a week to complete. If you told everybody to work 60 hours a week, you could finish the development in four months flat. The software team might even embrace this challenge because it will make them look like heroes ("How great is that Walrus team? They're here every weekend!"). This should work, right? Guess again. There's a whole body of literature establishing that working more hours doesn't produce software any faster. Edward Yourdon, the software entrepreneur and author, dubbed this kind of project the "death march."
Software development takes immense intellectual effort. Even the best programmers can rarely sustain that level of effort for more than a few hours a day. Beyond that, they need to rest their brains a bit, which is why they always seem to be surfing the Internet or playing games when you barge in on them.
Compelling them to spend even more hours sitting in front of a computer won't really translate into more output--or if it does, it will be the wrong kind of output. When their brains are completely fried, software developers are almost certainly going to do more damage than good, writing unusable code and introducing bugs galore. And if you do ban the Internet and multiplayer games to force them to keep writing code past their natural bedtimes, well, they'll probably start quitting on you. Running a death march is not the only way to make a project late and a budget buster. But it is a surefire way to do so.
If these are all the ways you can go wrong, how can you ensure that a project actually goes right? First, you have to hire superstars. At Fog Creek, we tend to review about 400 candidates for every full-time hire, because the best developers can be 10 times as productive as the merely excellent developers.
Second, demand fine-grained time estimates from the developers. Yes, it's difficult for developers to predict how long it will take to build a new application. That's why they need to create a reliable blueprint before every project.
Once you have that schedule in hand, don't try to push up the deadline. If the project can't be completed in what you consider to be a reasonable amount of time, the answer is not to negotiate a better-sounding schedule. The answer is to get more resources, move back your ship date, or remove features.
As a project gets going, you'll at times be tempted to reassign work. But reassign it with care. It takes a long time for new developers to get up to speed on someone else's code. I think it's good to rotate developers through different jobs so that you don't have any irreplaceable individuals, but I do this cautiously and build an extra three weeks into the schedule for the incoming developer who's learning the new code, and an extra week for the outgoing developer who is teaching the code to the new person.
Finally, encourage your staff to work a sane 40 hours per week. Seriously. Except for occasional, very short bursts of activity to meet a deadline, we at Fog Creek work eight-hour days. In the technology world, it's better to view a big project as a marathon, and not a sprint.

Thursday, July 17, 2008

Not the User's Fault from Jono at Mozilla Labs

I found this on Internet worth to read it...I think Author is from Mozilla Labs.
These things I believe. These things I believe about software development and user-interface design.

1. Why write code?
Software is for humans, not for computers.
Software is only as good as the improvement it makes to a human being’s life.
Are we making someone’s job easier? Letting them have more fun? Helping them learn?
Helping them keep in touch with friends and family?
Are we making the world a better place?
2. What do people want?
Most people do not want a computer.
They don’t even want software.
For us software developers, this is a painful truth.
If people don’t want a computer, why do they use one?
* Email — for writing to other people.
* Instant messaging — for talking to other people.
* The web browser — for reading what other people have written.
* Word processing — for writing something you’re going to print out and show to other people.
* Graphics — for creating artwork. To show to other people.
* Presentation — for communicating your brilliant plan. To other people.
* Games — especially games that you can play online. With other people.
* Social networking websites — Enough said.
The computer is merely an intermediary. A poor and frustrating one. It is a necessary evil that people put up with in order to get what they want.
What they want is a better way to talk to each other.
3. Why does software succeed or fail?
We software developers, being not exactly social creatures by nature, must work extra hard to understand the social impact our software will have. If the social effect is not what people want, the software goes unused.
We software developers, being not exactly average users, must work extra hard to understand how average users will relate to our software. We see the trees, they see the forest.
We software developers have often been confused and frustrated when a clearly superior technology fails, while a clearly inferior technology spreads like wildfire and takes over the world.
We were surprised because we want each technology to be judged only by its cleverness, its raw power, the cleanliness of its architecture, the purity of its ideas. We were blind to the user experience, to what each technology meant in the bigger picture of a person’s life.
To the people buying and using the “clearly inferior” technology, exactly the opposite was true.
To the user, the interface is the product.
4. Why is there not more Linux on the desktop?
For open source software to take over the world, we’re going to have to do a lot better at user interfaces than we have been doing.
How do I know?
Open source has already taken over the invisible parts of the world: the servers, the infrastructure, the things users need not touch directly.
Mozilla, the most user-experience-focused of open-source companies, has the most adoption by end-users.
People say things to me like, “Linux is only free if the value of my time is zero.”
These are not coincidences.
At one time, the way of open-source software development was thought impossible. But the techniques were invented. The way became possible; then it became successful. Now the techniques are becoming widely known.
The way to make open-source UI design successful is still unclear. We must invent the techniques.
5. Are users dumb?
User interface design is not about dumbing things down for the poor stupid user.
We software developers, understanding the software as we do, find it easy to look down upon those who lack our understanding.
This is wrong.
Users aren’t dumb. They just have better things to do with their lives than memorizing the internal data model of our screwy software.
When software is hard to use, don’t make excuses for it. Improve it.
When a user makes a mistake, don’t blame the user. Ask how the software misled them. Then fix it.
The user’s time is more valuable than ours. Respect it.
Good UI design is humble.
6. Is UI design marketing?
User interface design is not marketing.
Software developers loathe marketing, so if they think that UI design is marketing, then they will loathe UI design.
The qualities of software that make for a good advertisement or computer-store demo are not the same qualities that make software usable and pleasant to work with long-term, day-in day-out. Often these qualities are opposites.
A shopper may choose the microwave with more buttons, because it seems “more powerful”. However, the shopper will soon find out that it does the same thing as any other microwave, you just have to spend longer figuring out which button to push.
It is easy to fool people into buying something that is against their own best interest.
Don’t do that.
7. What is the task of the UI designer?
Let us talk about that microwave some more.
The microwave with the most buttons may be most popular, but it is not the best microwave.
The best microwave has no buttons at all.
It doesn’t need any buttons because it already knows how long you want your food cooked and how hot. You never need to set the clock, either: it’s just always right.
The no-button microwave may not be reachable, but like a guiding star it shows us the direction we should travel.
Users do not know what interface they want. Users do not know what features they want.
Users know the tasks they want to do, and the problems they have.
We learn more by watching the user work than by asking the user.
The job of the UI designer is to provide what the users need, not what the users say they need.
It is to make tasks easier, not to provide features.
8. Where is the science?
User interface design can be approached scientifically. But usually isn’t.
Until we observe people using our software for real, our design is guesswork and superstition.
These things can be measured and given numbers:
* What program features are being used most frequently, and least.
* The number of mouse/keyboard interactions required to perform a task.
* The time it takes a user to figure out how to do a task.
* Rates of error.
* How quickly task-completion-time and error-frequency decrease as a user gains experience.
An interface’s efficiency and learnability are empirically determinable quantities.
They are not matters of opinion.
Every user is different, but that’s why we have statistical methods.
The science of design can tell us that interface foo is X% more efficient than interface bar, but bar is Y% more learnable than foo.
Choosing between foo and bar — that’s where the science ends and the art begins.
9. Is change good or bad?
Change has a cost. Change disrupts the user’s habits. Change forces the user to learn something new.
Sometimes the new UI is so much better than the old one that the change is worth the cost.
Sometimes it isn’t.
The trick is knowing when change is worth it.
10. What is the evil of the bad interface?
It is a sin to waste the user’s time, break the user’s train of thought, or lose the user’s work.
Bad user interfaces do all three. Frequently.
Most interfaces are bad.
I do not use the word “sin” lightly.
Because of bad user interfaces, an action taken based on a reasonable assumption or out of habit often results in broken trains of thought, wasted time, and lost work. This is called “user error”, but it isn’t. It is programmer or designer error.
When we blame the user, we teach them that technology is perfect and that the errors are their own. Because technology is hard to use, we are teaching a generation to be afraid of technology. We are teaching a generation to believe in their own stupidity. This is a sin, too.
It’s not the user’s fault.

The Funeral...

One day all the employees reached the office and they saw a big notice on the door on which it was written: "Yesterday the person who has been
hindering your growth in this company passed away. We invite you to join the funeral in the room that has been prepared in the gym".

In the beginning, they all got sad for the death of one of their colleagues, but after a while they started getting curious to know who
was that man who hindered the growth of his colleagues and the company itself. The excitement in the gym was such that security agents were
ordered to control the crowd within the room.

The more people reached the coffin, the more the excitement heated up.Everyone thought: "Who is this guy who was hindering my progress? Well, at least he died!"

One by one the thrilled employees got closer to the coffin, and when they looked inside it they suddenly became speechless. They stood nearby
the coffin, shocked and in silence, as if someone had touched the deepest part of their soul.

There was a mirror inside the coffin: everyone who looked inside it could see himself. There was also a sign next to the mirror that said:

"There is only one person who is capable to set limits to your growth: it is YOU.
You are the only person who can revolutionize your life.
You are the only person who can influence your happiness,
Your realization and your success. You are the only person who can help yourself."

Your life does not change when your boss changes, when your friends change, when your parents change, when your partner changes, when your company changes.

Your life changes when YOU change, when you go beyond your limiting beliefs, when you realize that you are the only one responsible for your life.

"The most important relationship you can have, is the one you have with yourself"

Examine yourself, watch yourself. Don't be afraid of difficulties, impossibilities and losses: be a winner, build yourself and your
reality. The world is like a mirror: it gives back to anyone the reflection of the thoughts in which one has strongly believed.

The world and your reality are like mirrors lying in a coffin, which show to any individual the death of his divine capability to imagine and create his happiness and his success.

Wednesday, July 16, 2008

One paragraph that explains LIFE!

Arthur Ashe, the legendary Wimbledon player was dying of AIDS which he got due to infected blood he received during a heart surgery in 1983.
From world over, he received letters from his fans, one of which conveyed: "Why does GOD have to select you for such a bad disease"?
To this Arthur Ashe replied:

"The world over...
50 million children start playing tennis,
5 million learn to play tennis,
500,000 learn professional tennis,
50,000 come to the circuit,
5000 reach the grand slam,
50 reach Wimbledon,
4 to semi final,
2 to the finals,

when I was holding a cup I never asked GOD 'Why me?'.And today in pain I should not be asking GOD 'Why me?' "

"Happiness keeps you Sweet, Trials keep you Strong, Sorrow keeps you Human,

Failure keeps you humble and Success keeps you glowing, but only Faith & Attitude Keeps you going...

Love

No Limits for Love.......
While a man was polishing his new car, his 4 yr old son picked stone & scratched lines on the side of the car.
In anger, the man took the child's hand & hit it many times, not realizing he was using a wrench.
At the hospital, the child lost all his fingers due to multiple fractures. When the child say his father.... with painful eyes he asked "Dad when will my fingers grow back?"
Man was so hurt and speechless. He went back to car and kicked it a lot of times.
Devastated by his own actions...... sitting in front of that car he looked at the scratches, child had written "LOVE YOU DAD". The next day that man committed suicide. . .
Anger and Love have no limits, Choose the later to have a beautiful & lovely life ....