The 8 Free Things Every Site Should Do

Rule #1: If you have a site, you want more traffic.

Rule #2: You don't have enough money to buy as much traffic as you need.

Rule #3: You've already made your site as compelling as you know how to.

So, what now? Read on for the (free) details.

1. Register with technorati

It helps track blog posts and site changes

It's free and it only takes a few minutes.

Technorati

You might need your tech person to hold your hand on this one.

2. Become a Digger

Digg is a site that lets the mob find the good stuff

Not only is contributing to the community a good idea, but it pays off in traffic back to your best stuff.

Digg

Once something you do gets "Dugg", be sure to link to that on your site, so that others can Digg it as well.

3. Build a Squidoo lens

Every blog, every organization needs one

A lens (you're reading one) is an organized directory that makes it easy for people to find your good stuff. It's free and you should have one... it will bring you credibility and traffic.

Squidoo

Or you can click the button on the top right that says "build a lens".

4. Get your team to spread the word

It's not a top down world any more, folks

It only takes a dozen or two people to post something to Reddit or other social news sites to get a lot of attention to your work. Stop worrying about getting listed in the New York Times and start talking to your friends instead.

Reddit

It's like Digg, but different. Great stuff rises to the surface, so make something great.

5. Issue a press release

But only if you have something to say

Press releases aren't just for reporters. News readers (like Google News) read the press releases for the good stuff. So if you've got stuff, issue it as press release.

PRLeap

There are plenty of other services... some that are even worth paying for.

6. Get a sister site for testing

When the IT folks complain too much

Most big organizations have a 'frozen' site. No testing, no little experiments, no landing pages. You don't have to fight them. Just get some low-cost or free hosting and experiment with some pages that come BEFORE your firewall.

GoDaddy

Not free, but close. So, you could build a page here with a different domain, run some Google ads to put traffic to that page and see if you can convert some of that traffic into clicks to your site. You won't know if you don't try, and this is cheap enough that you can try.

7. Google Analytics

You won't know what's working unless you measure

Google analytics

Useful and addictive and free.

8. Don't be boring

If it's so obvious, why are you ignoring it

Every single one of the hundreds of millions of web surfers has billions of choices. And they're not choosing you. Why? Well it could be that they don't know about you. But it's way more likely that they don't care.

Purple Cow

You have no right to traffic. If you're lucky, you earn some.

You'll earn it when you do something daring, interesting, useful, provocative, free, compelling, emotional or urgent.

Hurry.

12 Steps to Better Code

Have you ever heard of SEMA? It's a fairly esoteric system for measuring how good a software team is. No, wait! Don't follow that link! It will take you about six years just to understand that stuff. So I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go to medical school.


The Joel Test

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?



The neat thing about The Joel Test is that it's easy to get a quick yes or no to each question. You don't have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each "yes" answer. The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.

Of course, these are not the only factors that determine success or failure: in particular, if you have a great software team working on a product that nobody wants, well, people aren't going to want it. And it's possible to imagine a team of "gunslingers" that doesn't do any of this stuff that still manages to produce incredible software that changes the world. But, all else being equal, if you get these 12 things right, you'll have a disciplined team that can consistently deliver.

1. Do you use source control?
I've used commercial source control packages, and I've used CVS, which is free, and let me tell you, CVS is fine. But if you don't have source control, you're going to stress out trying to get programmers to work together. Programmers have no way to know what other people did. Mistakes can't be rolled back easily. The other neat thing about source control systems is that the source code itself is checked out on every programmer's hard drive -- I've never heard of a project using source control that lost a lot of code.

2. Can you make a build in one step?
By this I mean: how many steps does it take to make a shipping build from the latest source snapshot? On good teams, there's a single script you can run that does a full checkout from scratch, rebuilds every line of code, makes the EXEs, in all their various versions, languages, and #ifdef combinations, creates the installation package, and creates the final media -- CDROM layout, download website, whatever.

If the process takes any more than one step, it is prone to errors. And when you get closer to shipping, you want to have a very fast cycle of fixing the "last" bug, making the final EXEs, etc. If it takes 20 steps to compile the code, run the installation builder, etc., you're going to go crazy and you're going to make silly mistakes.

For this very reason, the last company I worked at switched from WISE to InstallShield: we required that the installation process be able to run, from a script, automatically, overnight, using the NT scheduler, and WISE couldn't run from the scheduler overnight, so we threw it out. (The kind folks at WISE assure me that their latest version does support nightly builds.)

3. Do you make daily builds?
When you're using source control, sometimes one programmer accidentally checks in something that breaks the build. For example, they've added a new source file, and everything compiles fine on their machine, but they forgot to add the source file to the code repository. So they lock their machine and go home, oblivious and happy. But nobody else can work, so they have to go home too, unhappy.

Breaking the build is so bad (and so common) that it helps to make daily builds, to insure that no breakage goes unnoticed. On large teams, one good way to insure that breakages are fixed right away is to do the daily build every afternoon at, say, lunchtime. Everyone does as many checkins as possible before lunch. When they come back, the build is done. If it worked, great! Everybody checks out the latest version of the source and goes on working. If the build failed, you fix it, but everybody can keep on working with the pre-build, unbroken version of the source.

On the Excel team we had a rule that whoever broke the build, as their "punishment", was responsible for babysitting the builds until someone else broke it. This was a good incentive not to break the build, and a good way to rotate everyone through the build process so that everyone learned how it worked.

Read more about daily builds in my article Daily Builds are Your Friend.

4. Do you have a bug database?
I don't care what you say. If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Lots of programmers think they can hold the bug list in their heads. Nonsense. I can't remember more than two or three bugs at a time, and the next morning, or in the rush of shipping, they are forgotten. You absolutely have to keep track of bugs formally.

Bug databases can be complicated or simple. A minimal useful bug database must include the following data for every bug:

* complete steps to reproduce the bug
* expected behavior
* observed (buggy) behavior
* who it's assigned to
* whether it has been fixed or not

If the complexity of bug tracking software is the only thing stopping you from tracking your bugs, just make a simple 5 column table with these crucial fields and start using it.

For more on bug tracking, read Painless Bug Tracking.

5. Do you fix bugs before writing new code?
The very first version of Microsoft Word for Windows was considered a "death march" project. It took forever. It kept slipping. The whole team was working ridiculous hours, the project was delayed again, and again, and again, and the stress was incredible. When the dang thing finally shipped, years late, Microsoft sent the whole team off to Cancun for a vacation, then sat down for some serious soul-searching.

What they realized was that the project managers had been so insistent on keeping to the "schedule" that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote "return 12;" and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as "infinite defects methodology".

To correct the problem, Microsoft universally adopted something called a "zero defects methodology". Many of the programmers in the company giggled, since it sounded like management thought they could reduce the bug count by executive fiat. Actually, "zero defects" meant that at any given time, the highest priority is to eliminate bugs before writing any new code. Here's why.

In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.

For example, when you make a typo or syntax error that the compiler catches, fixing it is basically trivial.

When you have a bug in your code that you see the first time you try to run it, you will be able to fix it in no time at all, because all the code is still fresh in your mind.

If you find a bug in some code that you wrote a few days ago, it will take you a while to hunt it down, but when you reread the code you wrote, you'll remember everything and you'll be able to fix the bug in a reasonable amount of time.

But if you find a bug in code that you wrote a few months ago, you'll probably have forgotten a lot of things about that code, and it's much harder to fix. By that time you may be fixing somebody else's code, and they may be in Aruba on vacation, in which case, fixing the bug is like science: you have to be slow, methodical, and meticulous, and you can't be sure how long it will take to discover the cure.

And if you find a bug in code that has already shipped, you're going to incur incredible expense getting it fixed.

That's one reason to fix bugs right away: because it takes less time. There's another reason, which relates to the fact that it's easier to predict how long it will take to write new code than to fix an existing bug. For example, if I asked you to predict how long it would take to write the code to sort a list, you could give me a pretty good estimate. But if I asked you how to predict how long it would take to fix that bug where your code doesn't work if Internet Explorer 5.5 is installed, you can't even guess, because you don't know (by definition) what's causing the bug. It could take 3 days to track it down, or it could take 2 minutes.

What this means is that if you have a schedule with a lot of bugs remaining to be fixed, the schedule is unreliable. But if you've fixed all the known bugs, and all that's left is new code, then your schedule will be stunningly more accurate.

Another great thing about keeping the bug count at zero is that you can respond much faster to competition. Some programmers think of this as keeping the product ready to ship at all times. Then if your competitor introduces a killer new feature that is stealing your customers, you can implement just that feature and ship on the spot, without having to fix a large number of accumulated bugs.

6. Do you have an up-to-date schedule?
Which brings us to schedules. If your code is at all important to the business, there are lots of reasons why it's important to the business to know when the code is going to be done. Programmers are notoriously crabby about making schedules. "It will be done when it's done!" they scream at the business people.

Unfortunately, that just doesn't cut it. There are too many planning decisions that the business needs to make well in advance of shipping the code: demos, trade shows, advertising, etc. And the only way to do this is to have a schedule, and to keep it up to date.

The other crucial thing about having a schedule is that it forces you to decide what features you are going to do, and then it forces you to pick the least important features and cut them rather than slipping into featuritis (a.k.a. scope creep).

Keeping schedules does not have to be hard. Read my article Painless Software Schedules, which describes a simple way to make great schedules.

7. Do you have a spec?
Writing specs is like flossing: everybody agrees that it's a good thing, but nobody does it.

I'm not sure why this is, but it's probably because most programmers hate writing documents. As a result, when teams consisting solely of programmers attack a problem, they prefer to express their solution in code, rather than in documents. They would much rather dive in and write code than produce a spec first.

At the design stage, when you discover problems, you can fix them easily by editing a few lines of text. Once the code is written, the cost of fixing problems is dramatically higher, both emotionally (people hate to throw away code) and in terms of time, so there's resistance to actually fixing the problems. Software that wasn't built from a spec usually winds up badly designed and the schedule gets out of control. This seems to have been the problem at Netscape, where the first four versions grew into such a mess that management stupidly decided to throw out the code and start over. And then they made this mistake all over again with Mozilla, creating a monster that spun out of control and took several years to get to alpha stage.

My pet theory is that this problem can be fixed by teaching programmers to be less reluctant writers by sending them off to take an intensive course in writing. Another solution is to hire smart program managers who produce the written spec. In either case, you should enforce the simple rule "no code without spec".

Learn all about writing specs by reading my 4-part series.

8. Do programmers have quiet working conditions?
There are extensively documented productivity gains provided by giving knowledge workers space, quiet, and privacy. The classic software management book Peopleware documents these productivity benefits extensively.

Here's the trouble. We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

The trouble is, getting into "the zone" is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity. Sometimes, if you're tired or have already done a lot of creative work that day, you just can't get into the zone and you spend the rest of your work day fiddling around, reading the web, playing Tetris.

The other trouble is that it's so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers -- especially interruptions by coworkers -- all knock you out of the zone. If a coworker asks you a question, causing a 1 minute interruption, but this knocks you out of the zone badly enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble. If you're in a noisy bullpen environment like the type that caffeinated dotcoms love to create, with marketing guys screaming on the phone next to programmers, your productivity will plunge as knowledge workers get interrupted time after time and never get into the zone.

With programmers, it's especially hard. Productivity depends on being able to juggle a lot of little details in short term memory all at once. Any kind of interruption can cause these details to come crashing down. When you resume work, you can't remember any of the details (like local variable names you were using, or where you were up to in implementing that search algorithm) and you have to keep looking these things up, which slows you down a lot until you get back up to speed.

Here's the simple algebra. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity. For this example, lets put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).

Now let's move them into separate offices with walls and doors. Now when Mutt can't remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff. Ahhh!

9. Do you use the best tools money can buy?
Writing code in a compiled language is one of the last things that still can't be done instantly on a garden variety home computer. If your compilation process takes more than a few seconds, getting the latest and greatest computer is going to save you time. If compiling takes even 15 seconds, programmers will get bored while the compiler runs and switch over to reading The Onion, which will suck them in and kill hours of productivity.

Debugging GUI code with a single monitor system is painful if not impossible. If you're writing GUI code, two monitors will make things much easier.

Most programmers eventually have to manipulate bitmaps for icons or toolbars, and most programmers don't have a good bitmap editor available. Trying to use Microsoft Paint to manipulate bitmaps is a joke, but that's what most programmers have to do.

At my last job, the system administrator kept sending me automated spam complaining that I was using more than ... get this ... 220 megabytes of hard drive space on the server. I pointed out that given the price of hard drives these days, the cost of this space was significantly less than the cost of the toilet paper I used. Spending even 10 minutes cleaning up my directory would be a fabulous waste of productivity.

Top notch development teams don't torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.

To add to all this... programmers are easily bribed by giving them the coolest, latest stuff. This is a far cheaper way to get them to work for you than actually paying competitive salaries!

10. Do you have testers?
If your team doesn't have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you're wasting money by having $100/hour programmers do work that can be done by $30/hour testers. Skimping on testers is such an outrageous false economy that I'm simply blown away that more people don't recognize it.

Read Top Five (Wrong) Reasons You Don't Have Testers, an article I wrote about this subject.

11. Do new candidates write code during their interview?
Would you hire a magician without asking them to show you some magic tricks? Of course not.

Would you hire a caterer for your wedding without tasting their food? I doubt it. (Unless it's Aunt Marge, and she would hate you forever if you didn't let her make her "famous" chopped liver cake).

Yet, every day, programmers are hired on the basis of an impressive resumé or because the interviewer enjoyed chatting with them. Or they are asked trivia questions ("what's the difference between CreateDialog() and DialogBox()?") which could be answered by looking at the documentation. You don't care if they have memorized thousands of trivia about programming, you care if they are able to produce code. Or, even worse, they are asked "AHA!" questions: the kind of questions that seem easy when you know the answer, but if you don't know the answer, they are impossible.

Please, just stop doing this. Do whatever you want during interviews, but make the candidate write some code. (For more advice, read my Guerrilla Guide to Interviewing.)

12. Do you do hallway usability testing?
A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.

Good user interface design is not as hard as you would think, and it's crucial if you want customers to love and buy your product. You can read my free online book on UI design, a short primer for programmers.

But the most important thing about user interfaces is that if you show your program to a handful of people, (in fact, five or six is enough) you will quickly discover the biggest problems people are having. Read Jakob Nielsen's article explaining why. Even if your UI design skills are lacking, as long as you force yourself to do hallway usability tests, which cost nothing, your UI will be much, much better.

Four Ways To Use The Joel Test

1. Rate your own software organization, and tell me how it rates, so I can gossip.
2. If you're the manager of a programming team, use this as a checklist to make sure your team is working as well as possible. When you start rating a 12, you can leave your programmers alone and focus full time on keeping the business people from bothering them.
3. If you're trying to decide whether to take a programming job, ask your prospective employer how they rate on this test. If it's too low, make sure that you'll have the authority to fix these things. Otherwise you're going to be frustrated and unproductive.
4. If you're an investor doing due diligence to judge the value of a programming team, or if your software company is considering merging with another, this test can provide a quick rule of thumb.

10 Tips for Being a Better Office Professional

1. Do not discuss your salary/wage with your coworkers.

I can’t tell you how many times I’ve seen people do this. There is essentially zero good that can come out of this. One way or another somebody’s feelings are going to be hurt. It can cause a lot of strife between people and it’s even a terminable offense in most workplaces.

The only people that you could share your salary with are the following:

• Spouse or signifigant other if you live together or otherwise share a budget.
• Parents (with the understanding that it is strictly confidential, no telling their golf buddies, AA group or Joey your 4th cousin twice removed.)
• Your accountant.
• That’s it.

2. Perception is reality.

No matter how unfair it is, no matter how illogical it can be, it is the absolute 100% truth. People don’t have time in the workplace to ferret out the whole story. If you’re seen as a slacker, you’re a slacker. If you’re seen as a hothead, you’re a hothead.

Work hard to cultivate the perception you think you should have and protect it once it is achieved. That means you may have to work harder/faster/better than the other guy or gal if you’ve already been branded.

Along the same lines, be careful who you hang out with at work. It’s very easy to be pigeonholed with a group if you frequently go on breaks with, lunch with or otherwise hangout with people who act less that professionally (or proficiently) in the workplace.

3. Be honest with your coworkers, but not too honest.

If this job is just a stepping stone towards bigger and better things, don’t share that with the 20 year lifer that you just met at the office. I was guilty of this at my first professional job. I think back on that and realize what a jerk I must have sounded like.

Hopes and dreams are great, but try to keep conversations with your coworkers light, at least in the early going before you really know them.

4. Choose your battles wisely.

No you will not quit if they switch from Arrowhead bottled water to Sparkletts. Get a grip.

Some battles are worth fighting, others are small potatoes. Think of it this way. Every day that you work and do an acceptable job you earn a certain number of points. As you spend more time at the job you accrue these points until you can cash them in for several purposes.

One of those purposes is in the eternal battle to impose your will on others. Whether it’s a raise or more donuts on Friday. If you’re constantly spending your points you’re going to find yourself fresh out when something REALLY important comes along like… say… layoffs.

You always want to have a cache of points to turn in when you need them.

5. Nobody likes a whiner.

This goes hand in hand with choosing your battles. If you are constantly whining about things then you will actually lose points without getting anything for them besides irritated coworkers. If your chair is uncomfortable, go swipe one from somewhere else, or politely ask the office manager about maybe getting a new one.

If you can’t get whatever ails you resolved quickly and in a polite non-whiny manner, try to learn to live with it or fix it yourself.

6. Don’t get shitfaced at happy hour or the holiday party.

Wooo open bar! Hold on there partner. While it’s ok to have a cocktail or two while you’re at a company function, don’t get obliterated.

I’ve seen more than my share of otherwise normal folks completely crash and burn due to their allowing their cup to runneth over.

Take it easy, have fun, but remember that come Monday morning, yes they will remember if you act like an idiot while plastered. Minus points.

7. Get it in writing.

Email is one of the single greatest inventions ever in corporate accountability.

If there is ever a doubt in your mind about what you’ve been tasked to do, get it in writing. Sometimes people make judgement calls on the fly when they’re pressed for time. More often than not, when they are proven to have made the incorrect call, they will turn to you and ask you why you did that (idiot!). So having their instructions in black and white will save your ass a hundred times over the course of your career.

Get it in writing. Plus points if you catch the office bully with his pants down using this technique.

8. This isn’t high school or college A) debating.

Academic debates about random crap are fantastic fun in a scholastic setting. Nobody wants to debate arbitrary minutiae in the office, especially your boss.

9. This isn’t high school or college B) over the top.

While it may have been fun to be the over the top bombastic “willing to do anything to get a rise out of someone” kind of person back in school, this does NOT fly in the workplace.

Yes, it was jolly good fun to tease people and make people uncomfortable back in the day, but not any more when your livelihood hangs in the balance. This goes for discussing politics and religion as well. It’s just not a good idea.

10. Smile, today’s the first day of the rest of your career!

A positive attitude can have a great affect on your interpersonal relations at work and your career in general. Bosses and coworkers are a lot more forgiving if you can take a beating and still keep a bit of cheer about yourself.

Remember, it’s just work, don’t take it too seriously.

Being a Genius Is Due to Hard Work, Not High IQ

Enlarge picture

Do they call you dumb, a**hole, sucker, idiot and so on?

It does not matter, one day you could be (might become) a genius.

A roundup of IQ studies from Cambridge University Press, shows that being a genius means 99 % hard work. "There are international chess masters that have below-average IQs," said author Dr. K. Anders Ericsson, a professor of psychology at Florida State University in Tallahassee.

"Basically, there is no indication that people with higher IQ are able to reach the top faster. We are finding people who meet the criteria for being skilled surgeons, chess masters, athletes or magicians. Once you start looking at what makes them successful, IQ doesn't make any difference."

They challenge our criteria on evaluating the persons' potential by their IQ. “Instead of selecting children into an elite school based on IQ test, we might speak instead of expertise, talent or even greatness," said Ericsson.

"Examine closely even the most extreme examples - Mozart, Newton, Einstein, Stravinsky - and you find more hard-won mastery than gift. Geniuses are made, not born", the British journalist David Dobbs pointed out.

One research tracking adult graduates of New York City's Hunter College Elementary School, where an admission criterion was an IQ of at least 130, revealed that most of the graduates bore average lives, and very few scored on the top. "There were no superstars, no Pulitzer Prize or MacArthur Award winners, and only one or two familiar names," said lead researcher Rena Subotnik, a psychologist with the American Psychological Association.

The Cambridge analysis points the three keys to success: hard work, persistence and a solid upbringing.

And all the people who got international fame had invariably worked with a high level mentor. "Ability doesn't seem to have anything to do with it. You need to accumulate your experience. Perfect practice makes perfect. If you're out playing tennis and you miss an overhand volley, the game will go on. The next time the identical situation happens, you're not going to be more successful. In order to improve, you need a special training environment where a mentor will give you appropriate shots," said Erricsson.

Ericsson shows that genius status is achieved when one puts in five times extra work and 10 years of effort more than average people do. "A lot of people think (that) highly talented people can become good at anything rapidly. But what this study says(suggests) is that nobody has been able to rise without having practiced(practised) for 10 years. In [classical] music right now, it takes more than 15-20 years before they start winning in competitions", said Ericsson.

Save an entire website into a single file

Most of us might have saved web pages while browsing and it might have struggled a lot in managing those pages since saving a single page will result in lots of files in the disk and the broken links. I have often see my friends trying to save some web sites by clicking each links in the page and trying to save those pages individually. But life can be made easy if you follow some painless steps while saving the web pages. I often follow these steps if I need to save a web page.

1. Use a web copier/Off line browser for saving an entire website to the disk. This will help you to browse the saved web page as if you are browsing online.
2. There are so many softwares available for this purpose, but to my experience WinHTTrack is the best one. It is a free ware and works good. (Click the link to go to the WinHTTrack download page)
3. Run the program after installing it.
4. Keep the default settings for the proxy and other things.
5. Give appropriate name to the project and click next to continue.
6. Here give the name of the website(s) you want to download in the URL box.
7. Click next, keep default settings and click finish to start copying the website.
8. When httrack finishes copying the web site you can find a file called index.html on the project folder you have chosen, double click the file to open the saved web page.
9. Now you have the web page copied on your computer and can browse it.
10. But even this could cause problems while copying it to some other drive or moving it. It also consumes large space in disk (larger than total size of all files) . This is because each page is contained of many small files. But in the disk there is term called cluster size which gives the minimum space which can be allocated for saving a file. For example if there is a file of 1KB and the cluster size is 4KB, then that file will take a minimum of 4KB on the disk and the rest of the 3KB will remain empty. But if we makes the entire file into a single one like zip archeive, then we can save a lot of space on the disk.
11. This can be made possible mainly in two ways (according to my knowledge). First one is to make it .CHM (windows compiled html help file) file or use custom packager softwares like WebSiteZip Packer which is a free EBook Compiler (Here you will also get option to password protect the output file).

Using WebSiteZip Paker

1. Download and install WebSiteZip Packer.
2. When you run it you will see something like this.
3. click the wizard button and the click next.
4. Now click the homepage button and browse to the index.html file in the project folder of the website copied using httrack.
5. Click next and select EXE format for getting a stand alone E-book.
6. Give the output file name and click next.
7. Now you can keep the default settings or make changes as you like till you reach the page below.
8. In this page check the option if you want to make the output from files which was taken from different sites.
9. Now click next, and make changes if you want and click Finish to start compiling the EBook from web site.

Using CHM makers (CHM compilers)

1. If you search the net for chm compilers or html to chm converters, the you will get so many softwares. But most of them will be sharewares or trials having limitations and expiry period.
2. Of these most the have similar interface as that of WebSiteZip Packer and can be used in a similar way.
3. One of chm builder which I found useful is Easy chm. It comes as a 30 day trial.
4. Screen shot of Easy Chm.
5. Click the new button to start the new project.
6. Then select the folder containing downloaded files as the project folder. Make sure that the "Include sub directories box is selected".
7. If the site contains files other than listed extensions the choose *.* from the dropdown menu and click ok.
8. Now click the preview tab to see the preview of the web pages.
9. The unnecessary folders like the cache created by the httrack by selecting it and clicling the 'x' button, if necessary other files can be added by clicking the '+' button.
10. When everything is over click the compile button.
11. Make changes if necessary and click the create button to create the CHM output file.

Official Google Blog: Now you can blog in Hindi

Official Google Blog: Now you can blog in Hindi

Why Is Model-View-Controller So Important?

The MVC architectural pattern is not directly related to web applications. In fact, it's quite common in Smalltalk applications, which generally have nothing to do with the Web.

As we saw in the previous section, the Model 2 approach is concerned with separating responsibilities in web applications. Allowing a JSP page to handle the responsibilities of receiving the request, executing some business logic, and then determining the next view to display can make for an unattractive JSP page, not to mention the maintenance and extensibility problems this entanglement causes. Application development and maintenance are much easier if the different components of a web application have clear and distinct responsibilities.

As an example, say you want to integrate security into your web site. Your first page, in this case, usually is a login screen that collects and validates the username and password. This page then directs the user to another screen that allows her to continue in a secure manner. However, as there is nothing to prevent the user from going directly to a page, each page (in a non-MVC world) needs to be aware of security. This can be accomplished by including a security check on every page, but that can be unwieldy, especially if there are some pages that need to be secure and some that do not. In the MVC world, the security is put inside the controller object. Because the interface to the customer is driven through the controller object, there is a single entry point and a single location for the security checks to be performed.

The MVC pattern is categorized as a design pattern in many software design books. Although there is much disagreement on the precise definition of the pattern, there are some fundamental ideas.

The MVC pattern has three key components:

Model

Responsible for the business domain state knowledge

View

Responsible for a presentation view of the business domain

Controller

Responsible for controlling the flow and state of the user input

With the MVC pattern, a form of event notification usually takes place to notify the view when some portion of the model changes. However, because a browser in a typical web application has a stateless connection, the notification from the model to the view cannot occur easily.^[2] Of course, an application could perform some type of push mechanism to push notification or data all the way to a client, but this is overkill for most web applications. A user can close the browser at any time, and generally no notification is sent to the server. A great deal of overhead is necessary to manage remote clients from the server side. This type of behavior is not necessary for typical B2C and B2B web applications.

^[2] Web applications are considered stateless because the browser doesn't maintain a constant open connection to the web server. However, a web application still may maintain session data for a user or even store data within the browser on behalf of the user.

With standard web applications, a client typically sends another request to the server to learn about any changes to the model. This is known as a "pull" approach. For example, if a user is viewing pricing information for an item and at the same time the administrator changes the price for that item, the user will not know it changed until he refreshes the page.

1.5.1 The MVC Model

Depending on the type of architecture your application uses, the model portion of the MVC pattern can take many different forms. In a two-tier application, where the web tier interacts directly with a data store such as a database, the model classes may be a set of regular Java objects. These objects may be populated manually from a ResultSet returned by a database query, or they may be instantiated and populated automatically by an object-to-relational mapping (ORM) framework such as TopLink or CocoBase.

In a more complex enterprise application (where the web tier communicates with an EJB server, for example), the model portion of the MVC pattern will be Enterprise JavaBeans. Although the EJB 2.0 specification made performance improvements through the use of local interfaces, there still can be a significant performance impact if the web tier attempts to use entity beans directly as the model portion of the application, due to the overhead of making remote calls. In many cases, JavaBeans are returned from session beans and used within the web tier. These JavaBeans, commonly referred to as data transfer objects or value objects, are used within the views to build the dynamic content.

1.5.2 The MVC View

The views within the web tier MVC pattern typically consist of HTML and JSP pages. HTML pages are used to serve static content, while JSP pages can be used to serve both static and dynamic content. Most dynamic content is generated in the web tier. However, some applications may require client-side JavaScript. This does not interfere with or infringe upon the MVC concept.

HTML and JSP are not the only choice for the view. You easily can support WML, for example, instead of HTML. Because the view is decoupled from the model, you can support multiple views, each for a different client type, using the same model components.

1.5.3 The MVC Controller

The controller portion of the web tier MVC design generally is a Java servlet. The controller in a web tier application performs the following duties:

1. Intercepts HTTP requests from a client

2. Translates each request into a specific business operation to perform

3. Either invokes the business operation itself or delegates it to a handler

4. Helps to select the next view to display to the client

5. Returns the view to the client

The Front Controller pattern, which is part of the Java 2 Platform, Enterprise Edition (J2EE) Design Patterns (found at http://java.sun.com/blueprints/patterns/index.html), describes how a web tier controller should be implemented. Because all client requests and responses go through the controller, there is a centralized point of control for the web application. This helps when adding new functionality. Code that would normally need to be put in every JSP page can be put in the controller servlet, which processes all the requests. The controller also helps to decouple the presentation components (views) from the business operations, further aiding development.

JavaServer Pages

The first thing to understand about JavaServer Pages is that it's a natural extension to the Java Servlet technology. In fact, after some preprocessing by a translator, JSP pages end up being nothing more than Java servlets. This is a point that many beginning developers have a hard time understanding. JSP pages are text documents that have a .jsp extension and contain a combination of static HTML and XML-like tags and scriptlets. The tags and scriptlets encapsulate the logic that generates the content for the pages. The .jsp files are preprocessed and turned into .java files. At this point, a Java compiler compiles the source and creates a .class file that can be executed by a servlet container.

The translator that turns the .jsp file into a .java file takes care of the tedious work of creating a Java servlet from the JSP page. Figure 1-2 illustrates how a JSP page is translated and compiled into a servlet.

Figure 1-2. A JSP page is translated and compiled into a Java servlet

JSP technology has become an extremely popular solution for building web applications using the Java platform. JSP offers several advantages over its competitors:

· JSP is a specification, not a product. Developers are able to choose a "best of breed" approach.

· JSP pages are compiled, not interpreted, which can lead to better performance.

· JSP pages support both scripting and access to the full Java language and can be extended through the use of custom tags.

· JSP pages share the Write Once, Run Anywhere™ characteristics of Java technology.

As mentioned in the previous section, one of the limitations of using hardcoded HTML inside of servlets is the problem of separating page design and application logic programming responsibilities. This separation is easier with JSP pages, because the HTML designers are free to create web pages with whatever tools they choose (many of today's popular tools are capable of working with JSP and custom tags). When they are comfortable with the page layout, the JSP developers can insert JSP scriptlets and custom tags and save the files with a .jsp extension. That's pretty much all there is to it. When the time comes to change either the page layout or page logic, the developer modifies the JSP page as needed and allows it to be recompiled automatically.

Together, JSP pages and servlets are an attractive alternative to other types of dynamic web programming. Because both are based on the Java language, they offer platform-independence, extensibility into the enterprise, and, most importantly, ease of development.

JSP Scriptlets or Tag Libraries? Many developers believe custom tags, rather than scriptlets or expressions, should be used in JSP pages. The rationale is: · Scriptlets mix logic with presentation. · Scriptlets break the separation of roles. · Scriptlets make JSP pages difficult to read and maintain. Custom tags, on the other hand, centralize code in one place and help maintain the separation of responsibilities. They also support the concept of reuse, as the same tag can be inserted into multiple pages while the implementation resides in a single location. There also is less redundancy and potential for copy-and-paste errors with custom tags.

What Are Java Servlets?

Java servlets have become the mainstay for extending and enhancing web applications using the Java platform. They provide a component-based, platform-independent method for building web applications. Servlets don't suffer from the same performance limitations that standard CGI applications incur. Servlets are more efficient than the standard CGI threading model because they create a single heavyweight process and allow each user request to use a much more lightweight thread, which is maintained by the Java Virtual Machine (JVM), to fulfill the request. Multiple user requests can be threaded through the same instance of a servlet. A servlet is mapped to one or more uniform resource locators (URLs), and when the server receives a request to one of the servlet URLs, the service method in the servlet is invoked and it responds. Because each user request is associated with a separate thread, multiple threads or users can invoke the service method at the same time. This multithreaded nature of servlets is one of the main reasons that they are more scalable than standard CGI applications. Also, because servlets are written in Java, they are not proprietary to a platform or OS.

Another significant advantage of being written in the Java language is that servlets are able to exploit the entire suite of Java application programming interfaces (APIs), including Java DataBase Connectivity™ (JDBC) and Enterprise JavaBeans (EJB). This was one of the factors in servlets becoming part of the mainstream so quickly; there already was a rich Java library in place for them to leverage.

Servlets are not executed directly by a web server. They require a servlet container, sometimes referred to as a servlet engine, to host the servlet. This servlet container is loosely coupled to a particular instance of a web server, and together they cooperate to service requests. Figure 1-1 illustrates how a web server and servlet container cooperate to service a request from a web browser.

Figure 1-1. Processing a client request

Developers are free to choose from one of many servlet containers available to host their servlets; they are not locked into a particular vendor or platform. Servlets can be ported to any of these containers without recompiling the source code or making any changes. This leads to a "best of breed" solution for web applications—you get the best product or component for a specialized need, while at the same time avoiding the high risk normally associated with a single solution.

There are several popular servlet containers on the market. Some are standalone servlet containers that must be connected to an external web server to work, while others provide both the web server and servlet container in the same product. There are even a few that are integrated into application servers and provide much more functionality than just a servlet container. Table 1-1 lists some of the more popular servlet containers. Some of the products are commercial products and some have a small or insignificant cost to use.

Table 1-1. Popular servlet containers
Servlet container	URL
Bluestone	http://www.bluestone.com
Borland Enterprise Server	http://www.inprise.com
iPlanet Application Server	http://www.sun.com/software/iplanet/
Orbix E2A (formally iPAS)	http://www.iona.com
Jetty	http://www.mortbay.com
JRun	http://www.macromedia.com/software/jrun/
Orion Application Server	http://www.orionserver.com
Resin	http://www.caucho.com
SilverStream	http://www.silverstream.com
Apache Tomcat	http://jakarta.apache.org/tomcat/
Weblogic Application Server	http://www.bea.com
WebSphere	http://www-4.ibm.com/software/webservers/appserv/
EAServer	http://www.sybase.com

For a more complete listing of available servlet containers, visit Sun's servlet industry momentum web site at http://java.sun.com/products/servlet/industry.html.

Although servlets are great at what they do, it quickly became apparent that hardcoding HyperText Markup Language (HTML) output in a servlet as a response to a request had some serious limitations. First and foremost, it was hard to make changes to the HTML because for every change, a recompilation of the servlet had to take place.

Secondly, supporting different languages is difficult because the HTML is hardcoded. Determining the user's language, region, and optional variant and then displaying the output is not easily accomplished. Many web applications built with servlets avoid the entire issue of internationalization^[1] by having different servlets, one for each supported locale.

^[1] Internationalization is commonly referred to as "I18N" because the word begins with the letter I, ends with the letter N, and contains 18 characters in between.

Finally, because HTML was embedded within the servlet, there was a problem with responsibility. Web designers build HTML pages; they are not usually experienced with Java programming, let alone skilled at object-oriented design and programming. When you mix HTML and Java code within the servlet, it becomes hard to separate the page design and programming duties. Even when a developer has the necessary skills to perform both functions, modifications to the page layout require recompilation, which adds to development and testing time.

Servlet programming is such a broad topic that it can't be covered in great detail here. If you feel that you need more information on Java Servlet technology, a great source of material is Jason Hunter's Java Servlet Programming (O'Reilly). You can also find more information at the Sun Servlet web site (http://java.sun.com/products/servlet/index.html).

JavaServer Pages was the next step in the linear progression of developing web technologies based on the Java platform. The introduction of JSP pages, as they are commonly referred to, helped to alleviate the servlet limitations mentioned earlier and opened up many new doors for web developers.

First Look: Mozilla Thunderbird 2

New Thunderbird adds ability to tag multiple e-mail messages.

Erik Larkin, PC World

Monday, April 09, 2007 09:00 AM PDT

If you like Thunderbird 1.5, you'll love version 2, now available as a near-final release candidate. Like the new Firefox 2, Thunderbird 2 doesn't introduce any radical changes. But it does introduce inherently useful upgrades that will boost your productivity, particularly if your inbox overflows with e-mail.

The release candidate download is now available from Mozilla's site. I've been using version 2 every day since beta 2's release in January. Though the program is not yet final, I've found it stable and up to the task of handling my daily e-mail chores. Making the switch is easy: Thunderbird 2 maintains all your filters and account settings, and you shouldn't have any problem jumping right into it. Like previous versions, Thunderbird 2 has a clean and straightforward interface that makes good use of available screen space.

One of the first things I noticed: mail pop-up alerts, one of Thunderbird's new features, which list the subject and sender of newly received messages in the lower-right corner of your screen and automatically fade after a few seconds. Each pop-up provides enough information on the latest few unread messages for me to decide whether I need to interrupt what I'm doing to switch to Thunderbird and read the e-mail.

As convenient as the mail pop-ups are, the introduction of tags in Thunderbird 2 is an even bigger boon for organizing messages. Tags replace the previous versions' labels function, which allowed you to assign just one of a handful of premade labels, such as 'Personal' or 'ToDo', to each message. Now, you can create an unlimited number of tags, and you can give any e-mail multiple tags.

Creating on-the-fly tags for any new topic does wonders for managing an ever-growing inbox. For example, I track antivirus news and products, so I created a new tag called 'antivirus'. A right-click lets me assign the new tag to any e-mail, and I can then quickly view only those tagged messages. I found right-clicking faster and cleaner than the typical method of creating a new folder for all such messages and then manually adding those messages to the folder. The feature is also particularly useful when combined with saved-search folders that show all messages with a particular tag (but keep your e-mail in one inbox). In the release candidate, however, the new tags have a few rough edges. For example, I changed the name of the default 'Personal' tag to 'PCW', but a filter I migrated from Thunderbird 1.5 still assigns 'Personal' to many messages. Also, when I assign multiple tags, Thunderbird seems to randomly select which tag's color it will use for the message; it doesn't allow me to designate a dominant color.

Brand-new in this release candidate is a Gmail account preset that fills in almost everything (server name, etc.) automatically when you configure Thunderbird to read your Gmail messages. You need only provide your name (for display) and account. The default settings will leave the messages on Gmail's servers so you can read them through both Thunderbird and Gmail.

The release notes list the same functionality for a .Mac account, but (not surprisingly) I didn't see such an option in my Windows version; it may show up only in the Mac software.

Other notable tweaks to Thunderbird include better customization options for viewing folders, and find-as-you-type searches. See the release notes for a full list of changes.

Unfortunately, Mozilla doesn't seem to have significantly improved its junk-mail filters, and my inbox still has plenty of spam. Also, Thunderbird still lacks a built-in calendar; however, a terrific and easy-to-use add-on called ReminderFox adds some basic calendaring functions, such as reminders to revisit a particular e-mail by a certain time.

Though Thunderbird 2 is not yet a final release, I found that the release candidate's new features and overall stability more than warrant your making it your primary mail client.

Migrating from PHP 4 to PHP 5 >> Backward Incompatible Changes

Backward Incompatible Changes

Although most existing PHP 4 code should work without changes, you should pay attention to the following backward incompatible changes:

• There are some new reserved keywords.
• strrpos() and strripos() now use the entire string as a needle.
• Illegal use of string offsets causes E_ERROR instead of E_WARNING. An example illegal use is: $str = 'abc'; unset($str[0]);.
• array_merge() was changed to accept only arrays. If a non-array variable is passed, a E_WARNING will be thrown for every such parameter. Be careful because your code may start emitting E_WARNING out of the blue.
• PATH_TRANSLATED server variable is no longer set implicitly under Apache2 SAPI in contrast to the situation in PHP 4, where it is set to the same value as the SCRIPT_FILENAME server variable when it is not populated by Apache. This change was made to comply with the » CGI specification. Please refer to » bug #23610 for further information, and see also the $_SERVER['PATH_TRANSLATED'] description in the manual. This issue also affects PHP versions >= 4.3.2.
• The T_ML_COMMENT constant is no longer defined by the Tokenizer extension. If error_reporting is set to E_ALL, PHP will generate a notice. Although the T_ML_COMMENT was never used at all, it was defined in PHP 4. In both PHP 4 and PHP 5 // and /* */ are resolved as the T_COMMENT constant. However the PHPDoc style comments /** */, which starting PHP 5 are parsed by PHP, are recognized as T_DOC_COMMENT.
• $_SERVER should be populated with argc and argv if variables_order includes "S". If you have specifically configured your system to not create $_SERVER, then of course it shouldn't be there. The change was to always make argc and argv available in the CLI version regardless of the variables_order setting. As in, the CLI version will now always populate the global $argc and $argv variables.
• An object with no properties is no longer considered "empty".
• In some cases classes must be declared before use. It only happens if some of the new features of PHP 5 (such as interfaces) are used. Otherwise the behaviour is the old.

• get_class(), get_parent_class() and get_class_methods() now return the name of the classes/methods as they were declared (case-sensitive) which may lead to problems in older scripts that rely on the previous behaviour (the class/method name was always returned lowercased). A possible solution is to search for those functions in all your scripts and use strtolower().

  This case sensitivity change also applies to the magical predefined constants __CLASS__, __METHOD__, and __FUNCTION__. The values are returned exactly as they're declared (case-sensitive).

• ip2long() now returns FALSE when an invalid IP address is passed as argument to the function, and no longer -1.
• If there are functions defined in the included file, they can be used in the main file independent if they are before return() or after. If the file is included twice, PHP 5 issues fatal error because functions were already declared, while PHP 4 doesn't complain about it. It is recommended to use include_once() instead of checking if the file was already included and conditionally return inside the included file.
• include_once() and require_once() first normalize the path of included file on Windows so that including A.php and a.php include the file just once.

Example C.1. strrpos() and strripos() now use the entire string as a needle

var_dump(strrpos('ABCDEF','DEF')); //int(3)

var_dump(strrpos('ABCDEF','DAF')); //bool(false)
?>

Example C.2. An object with no properties is no longer considered "empty"

class test { }
$t = new test();

var_dump(empty($t)); // echo bool(false)

if ($t) {
// Will be executed
}
?>

Example C.3. In some cases classes must be declared before used


//works with no errors:
$a = new a();
class a {
}


//throws an error:
$a = new b();

interface c{
}
class b implements c {
}

?>