Monday, October 27, 2008

Applets are not running on Internet Explorer 7.0

I think there was an issue with applets on Internet Explorer 7.0. When I tried to run some applets on my windows 2003 server (SP2) box with IE 7.0 and JDK 1.5 version I could not able to load applets on my browser. I tried in almost all known ways by enabling applets through browser setting Tools -->Advanced and from java console (control panel --> java console --> Advanced) but no luck finally I thought to uninstall the java and reinstall it again and did the same but still no luck so finally I have installed lower version of Internet Explorer version 6.0 and it started working...
I think IE 7.0 has some issues still. But IE 7.0 has got some pros and cons as per my limited usage experience...

Pros:
  • Rich look and feel
  • Tabbed browsing
  • Implemented Add-on concept as Mozilla Firefox had.
Cons:
  • Though you enable Add-ons still browser through you message that you have not enabled add-on facility which really frustrates.
  • As I told Applet issue.
  • When we say Add-on user will easily sense that MicroSoft is trying to follow Mozilla's style of providing add-on's.
Fix for this issue

It started working by doing this way uninstall IE 7.0 and JDK 1.5 and then start reinstalling IE 7.0 and then install JDK 1.5. This will solve applet issue.

Thursday, August 14, 2008

Error Reporting through E-Mail using Log4j (SMTPAppender Class)

This could be one of the cool thing if you get an intimation through an email when ever your application is facing the problem in production or test environments apart from this you get log file as well so we can decrees the turn around time some what in fixing and issue and making your environment up. A few months back I have implemented the same thing for one of our production application and I have used log4j for logging and emailing the log file when ever log file get populated with error level messages.
In log4j api we have one class called SMTPAppender which will email us our log file when ever log file is populated with error level message. Just needs to configure log4j properties file with all SMTP server details.

Note: Make sure that you should have mail.jar and activation.jar files in your class path.

log4j.properties:

log4j.rootLogger=INFO, filer ,SMTPTest
log4j.appender.filer=org.apache.log4j.RollingFileAppender
log4j.appender.filer.layout=org.apache.log4j.PatternLayout
log4j.appender.filer.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %-5p [%t] %c{2} - %m%n
log4j.appender.filer.File=C:\\COMSProduction.log
log4j.appender.filer.MaxFileSize=1000KB
log4j.appender.filer.MaxBackupIndex=4

#####################
#SMTP appender properties#
#####################

log4j.appender.SMTPTest=org.apache.log4j.net.SMTPAppender
log4j.appender.SMTPTest.Threshold=Error
log4j.appender.SMTPTest.BufferSize=512
log4j.appender.SMTPTest.layout=org.apache.log4j.PatternLayout
log4j.appender.SMTPTest.layout.ConversionPattern=%d %-4r [%t] %-5p (%c:%L)%x - %m%n
log4j.appender.SMTPTest.SMTPHost= smpt.youcompany.com
log4j.appender.SMTPTest.To= me@who.com
log4j.appender.SMTPTest.From= me@who.com,user@who.com
log4j.appender.SMTPTest.Subject=COMSProductionLog - <>

EmailSender.java - Load properties and configure SMTP properties with log4j.
------------------

import org.apache.log4j.Category;
import org.apache.log4j.PatternLayout;
import org.apache.log4j.PropertyConfigurator;
import org.apache.log4j.net.SMTPAppender;

import java.io.InputStream;
import java.util.Properties;

/**
* Created by IntelliJ IDEA.
* User: sirishg
* Date: Apr 5, 2007
* Time: 4:38:45 PM
* To change this template use File | Settings | File Templates.
*/

/**
* This class is responsible to email your application log file to SupportEngineers/Developers when ever application is caught with errors.
* I am using SMPTAppender(from apache log4j) to do this job.
*/

public class EmailSender {
public static Category log = org.apache.log4j.Category.getInstance(EmailSender.class.getName());

public static void postEmail() {

Properties properties = null;
try {
properties = new Properties();
InputStream inStream = LogManager.class.getResourceAsStream("log4j.properties");
properties.load(inStream);

log.info("Trying to load log4j.properties file!!");
PropertyConfigurator.configure(properties);
log.info("Successfuly loaded the property file!!");
} catch (Exception e) {
log.error("OOPS...log4j.property file has not loaded!!");
e.printStackTrace();
}

/**
* Call SMTPAppender and set all required fields to that. you can set directly from here or you can load parameters from you log4j.properties.
* I prefer to load from log4j.properties hence you will get the chance to change perameters dynamically with out recomiling your code.
*/
try {
log.info("Invoking the SMTPAppender class");
SMTPAppender emailAppender = new SMTPAppender();
if (properties != null) {
emailAppender.setSMTPHost(properties.getProperty("log4j.appender.SMTPTest.SMTPHost"));
emailAppender.setFrom(properties.getProperty("log4j.appender.SMTPTest.From"));
emailAppender.setTo(properties.getProperty("log4j.appender.SMTPTest.To"));
emailAppender.setSubject(properties.getProperty("log4j.appender.SMTPTest.Subject"));
}
emailAppender.setLayout(new PatternLayout());
emailAppender.activateOptions();
log.addAppender(emailAppender);
} catch (Exception e) {
log.error("got an error in SMTPAppender, the errors are::" + e.getStackTrace());
e.printStackTrace();
}
}
}

PostEmailTest.java
-- Small test and try to do some mistake and put an error entry into log file now see you will get an email with your log file.
public class PostEmailTest {
public static void main(String[] args) throws Exception {
LogManager manager = new LogManager();
Logger log = manager.getLogger(PostEmailTest.class);
String str = "Sirish";
if (str.equals("SIRISH")) {
log.info("both strings are equal....");
} else {
log.error("Strings are not equal....!");
/**
* Finally we rached to what we are looking for. now we got one error entry into log file and this is the time to email log file to
* SupporEngineer so invoke EmailSender class and send .log file.
*/
EmailSender.postEmail();
}
}
}

Tuesday, August 5, 2008

Why Managers Fail

Good one...
http://managementcraft.typepad.com/management_craft/2008/06/why-managers-fa.html

JUnit testing tips

As we used to write our JUnit test cases for all Story cards we develop, well we follow TDD (Test Driven Development). Here are the rules we follow for our JUnit testcase as part of our TDD...
  • Never break others test case.
  • Don't update any database values as part of your JUnit testing. (But we can read DB values if required.)
  • Test your business logic no need to test java or other API's as they are well tested.
  • Try to avoid Mock Objects usage. (I think some times this mock objects will cause problems when you debug your test case - I am not quite sure to give any instance but I think so)
  • And he used to tell one more thing Clean first before committing something back to repository.
  • Ensure your JUnit test is passing on cruise control. Some time JUnit will pass locally when it actually running along with Cruise Control test beds it fails so need to ensure till you get positive build results other wise need to fix again.

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 ....

Friday, June 6, 2008

Making a career out of writing software?

If it's not what you love, don't do it.

I've worked with many programmers during my career. Without a doubt, the only ones who are any good at it are those who see writing code as art, a creative process. I know it's an obvious lesson, but it's really important. If you want to make lots of money and retire early, don't start by writing software; learn about business and start a company instead. I've run into so many poor programmers, in both senses of the word, who got into the field because they "wanted to be the next Bill Gates." Bill Gates didn't get rich by programming, he got very rich by being very good at running a company. I've had to fix code created by these people and it isn't pretty. Eventually they usually move into management where they might have a chance to find their true calling.

Learn the architecture of the machine

Many programmers, especially those who write for virtual machines such as Java or the .NET CLI, think that low-level machine architecture and processor instructions don't matter anymore. That's still not true, and I don't believe it ever will be. Someone who understands what the machine is really doing underneath all the modern layers of glop such as virtual machines, garbage collection algorithms, network and threading abstractions, will always be able to solve problems better than someone who lets the compiler or the "execution environment" they're using make all the decisions for them. These days the effects of processor caches and memory bandwidth mean that it's even more important to understand the lower levels of computer architecture than it used to be in order to be a good programmer. The good news is that modern tools like the amazing free software tool "valgrind" can emulate an entire processor in software and make understanding what is going on at each line of code as simple as looking at a visualization of execution time. Using resources efficiently matters when you're dealing with modern clusters containing thousands of machines.

Reputation is important

The days of starting at Google,IBM after college and working there in obscurity until you retire are long gone. Any modern programmer will move between many companies in his or her career. It is very important to be able to show your next employer what you have done, and what you are able to do in a team. Free software/open source is the ideal way of doing this. It's not just a better way of producing software, it's actually better for the reputation of the people creating it. One of the first things to do when evaluating someone is to look for samples of their code out there on the Internet. If you work on proprietary software you can't show anyone anything, and real code speaks louder than any list of projects you claim to have worked on.

The network really is the computer

There are now no interesting non-networked applications. Standalone computers are devices for watching stored video or listening to music, usually on airplanes. People doing offline email are simply working in an extreme case of a network disconnect, a rather large network latency if you will. The Internet has become the real computing environment of the next century and all programming will become network programming. This is a more challenging environment than programmers have been used to, with connection, latency and concurrency problems making our work much more interesting than it used to be on the standalone DOS box. All entertainment and communications such as television, radio and the telephone network will move onto the Internet. Poor Sun Microsystems were 20 years too early with their "the network is the computer" slogan, but they will eventually be proven right.

The community is more important than your employer

Are corporations fundamentally amoral? If they can make more money by outsourcing your job to India or China, or recycling employees into fertilizer for the rose garden at corporate headquarters, will they do it? I once had to listen to several high-level executives (for a previous company that shall remain nameless) waiting for the private corporate jet complain how inefficient it was that the country was run by democratically elected politicians as "they just didn't understand business."
Corporations are great places to work when things are going well, and I enjoy the perks as well as the next employee, but I'm very careful even in my optimism to not make the mistake of thinking this is the way things will always stay. In the free software/open source community, the people you're collaborating with and creating code with are the people you can really depend on. While you might not get on with all of them personally, they share your common goal of making sure that the code is the greatest, most beautiful work of art that all of you can create together. Smart corporations, at least the ones you'd want to work for, hire from that pool of people, and even though individual corporations may stumble and fall, if you're part of our community you should be able to successfully manage your career between the occasional stormy periods of corporate upheaval.
If you come from a coal mining area as I do, you can't finish a piece like this without paying homage to Merle Travis's wonderful song about really having to work for a living. No matter how much complaining we do, at least we're not "workin' for the man" :-).

Advice to Young Programmers

(This is the summary of speech Given by Alex Stepenov (Principal Scientist, Adobe Systems) at Adobe India on 30 Nov 2004. )

1. Study , Study and Study

- Never ever think that you have acquired all or most of the knowledge which exists in the world. Almost everybody in US at age of 14 and everybody in India at age of 24 starts thinking that he has acquired all the wisdom and knowledge that he needs. This should be strictly avoided.

- You should be habituated to studies...exactly in the same way as you are habituated to brushing teeth and taking bath every morning. The habit of study must become a ‘part of your blood’. And the study should be from both the areas: CS, since it is your profession, and something from non-CS...Something which doesnot relate to your work. This would expand your knowledge in other field too. A regular study, everyday, is extremely essential. It doesnot matter whether you study of 20 minutes of 2 hours, but consistency is a must.

- You should always study basics and fundamentals. There is no point in going for advanced topics. When I was at the age of 24, I wanted to do PhD in program verification, though I was not able to understand anything from that. The basic reason was that my fundamental concepts were not clear. Studying ‘Algebraic Geometry’ is useless if you donot understand basics in Algebra and Geometry. Also, you should always go back and re-read and re-iterate over the fundamental concepts.
What is the exact definition of ‘fundamental’? The stuff which is around for a while and which forms basic part of the concepts can be regarded as more fundamental. Of course, everybody understands what a fundamental means.

- Here are few books which I would strongly recommend that every CS professional should read and understand.

i. "Structure and Interpretation of Computer Programs" by Albenson and Sussman
I personally donot like the material present in this book and I do have some objections about it but this is the best book I have ever seen which explains all the concepts in programming in a clear and excellent way.
This book is available online at http://mitpress.mit.edu/sicp/

ii. Introduction to Computer Architecture: by Hennessy and Patterson.
How many of you have shipped the programs by writing them in assembly? A very good understanding of basics of how a computer operates is what every CS professional must have.
H&P Wrote two books on CA. I am talking about their first book, the introductory text for understanding basic aspects of how a computer works.
Even if you feel that you know whatever is written in that book, donot stop reading. It’s good to revise basics again and again.
iii. "Fundamentals of Programming" by Donald Knuth.
The core of CS is algorithms and Data structures. Every CS professional must have the 3 volumes of Knuth’s Book on programming. It really doesnot matter if you take 30 years of your life to understand what Knuth has written, what is more important is that you read atleast some part of that book everyday without fail.
iv. Introduction to Algorithms by Cormen, Leiserson and Rivest
This book should be read daily to keep your concepts fresh. This is the best book for fundamental concepts in algorithms.

2. Learn Professional Ethics

- As a CS Professional, you are morally obliged to do a good job. What this means is that you are supposed to do your job not for your manager but for yourself. This is already told in Bhagwatgeeta : Doing duties of your life.

- The direct implication of this is: never ever write a bad code. You don’t need to be fastest and run after shipping dates; rather you need to write quality code. Never write junk code. Rewrite it till it is good. Thoroughly test every piece of code that you write. Donot write codes which are "sort of allright". You might not achieve perfection, but atleast your code should be of good quality.

- Let me quote my own example in this context. You might have heard about STL, The Standard Template Library that ships in with C++ compilers. I wrote it 10 years ago, in 1994. While implementing one of the routines in the STL, namely the "search routine", I was a bit lazy and instead of writing a good linear order implementation of KMP which was

difficult to code, I wrote a best quadratic implementation. I knew that I could make the search faster by writing a linear-order implementation, but I was lazy and I did not do that. And, after 10 years of my writing STL, exactly the same implementation is still used inside STL and STL ships with an inefficient quadratic implementation of search routine even today!! You might ask me: why can’t you rewrite that? Well...I cannot, because that code is no more my property!! Further, nobody today will be interested in a standalone efficient STL ...people would prefer one which automatically ships out with the compiler itself.

- Moral is, you should have aesthetic beauty built inside you. You should "feel" uneasy on writing bad code and should be eager to rewrite the code till it becomes upto the quality. And to the judge the quality, you need to develop sense regarding which algorithms to use under what circumstances.

3. Figure out your Goals

- Always aspire doing bigger things in life

- "Viewing promotion path as your career" is a completely wrong goal. If you are really interested in studying and learning new things, never ever aspire for being a manager. Managers cannot learn and study...they have no time. "Company ladder aspiration" is not what should be important for you.

- You might feel that you want to do certain things which you cannot do till you become a manager. When you become a manager, you will soon realize that now you just cannot do anything!

- You will have a great experience as programmers. But if you care for people and love people, you will never enjoy being a manager...most good managers are reluctant managers. If you see people as people, you cannot survive at management level.

- Always aspire for professional greatness. Our profession is very beautiful because we create abstract models and implement them in reality. There is a big fun in doing that. We have a profession which allows us to do creative things and even gives nice salary for that.

- The three biggest mistakes that people usually make are aiming for money, aiming for promotion and aiming for fame. The moment you get some of these, you aspire for some more...and then there is no end. I donot mean that you shouldnot earn money, but you should understand how much

money would satisfy your needs. Bill Clinton might be the richest person in the world; he is certainly not the happiest. Our lives are far better than his.

- Find your goal, and do best in the job that you have. Understand that what is in your pocket doesnot matter...what is in your brain finally matters. Money and fame donot matter. Knowledge matters.

4. Follow your culture

I have seen the tradition that whatever junk is created in US, it rapidly spreads up in the rest of the world, and India is not an exception for this. This cultural change creates a very strong impact on everybody’s life. Habits of watching spicy Bollywood or Hollywood movies and listening to pop songs and all such stupid stuff gets very easily cultivated in people of your age...but believe me, there is nothing great in that. This all just makes you run away from your culture. And there is no wisdom in running away from your culture. Indian culture, which has great Vedas and stories like Mahabharata and Bhagwatgeeta is really great and even Donald Knuth enjoys reading that. You should understand that fundamental things in Indian culture teach you a lot and you should never forget them.

Finally, I would like to conclude by saying that it’s your life...donot waste it on stupid things...develop your tests, and start the fight.