How to Setup SVN Server on Windows

http://svnrating.com/how-to-setup-svn-server-on-windows/

Read More

To deploy grails WAR file on your local computer

You need following :

-tomcat (i used ->apache-tomcat-7.0.42)

So here are the steps you need to follow::

1. In config.groovy change your setting on production environment

             production {
                                grails.logging.jul.usebridge = true
                                grails.serverURL = "http://localhost:8080/pms"

                              }

2. In dataSource.groovy comment all you have in production environment and copy all from development environment and paste to production environment.

             

3. Now you have to create war file . look at this screenshot

4. After WAR file is build copy the file from target  folder and paste it to

                                        C:\tomcat\apache-tomcat-7.0.42\webapps

5. Now go to cmd prompt and go to bin of apche tomcat server.

                          -> bin / catalina.bat run

6. This will run your application . now go to browser and browse 

                            localhost:8080/applicationName

Simple !!! isn't it :) 

.

Read More

Hard things

You have to do the hard things. 

• You have to make the call you’re afraid to make.
• You have to get up earlier than you want to get up.
• You have to give more than you get in return right away.
• You have to care more about others than they care about you.
• You have to fight when you are already injured, bloody, and sore.
• You have to feel unsure and insecure when playing it safe seems smarter.
• You have to lead when no one else is following you yet.
• You have to invest in yourself even though no one else is.
• You have to look like a fool while you’re looking for answers you don’t have.
• You have to grind out the details when it’s easier to shrug them off.
• You have to deliver results when making excuses is an option.
• You have to search for your own explanations even when you’re told to accept the “facts.”
• You have to make mistakes and look like an idiot.
• You have to try and fail and try again.
• You have to run faster even though you’re out of breath.
• You have to be kind to people who have been cruel to you.
• You have to meet deadlines that are unreasonable and deliver results that are unparalleled.
• You have to be accountable for your actions even when things go wrong.
• You have to keep moving towards where you want to be no matter what’s in front of you.

You have to do the hard things. The things that no one else is doing. The things that scare you. The things that make you wonder how much longer you can hold on.

Those are the things that define you. Those are the things that make the difference between living a life of mediocrity or outrageous success.

The hard things are the easiest things to avoid. To excuse away. To pretend like they don’t apply to you.

The simple truth about how ordinary people accomplish outrageous feats of success is that they do the hard things that smarter, wealthier, more qualified people don’t have the courage — or desperation — to do.

Do the hard things. You might be surprised at how amazing you really are.

Read more: http://danwaldschmidt.com/2014/01/attitude/hard-things#ixzz32SUry9rN

Read More

Nurse reveals the top 5 regrets people make on their deathbed

For many years I worked in palliative care. My patients were those who had gone home to die. Some incredibly special times were shared. I was with them for the last three to twelve weeks of their lives. People grow a lot when they are faced with their own mortality.

I learnt never to underestimate someone’s capacity for growth. Some changes were phenomenal. Each experienced a variety of emotions, as expected, denial, fear, anger, remorse, more denial and eventually acceptance. Every single patient found their peace before they departed though, every one of them.

When questioned about any regrets they had or anything they would do differently, common themes surfaced again and again. Here are the most common five:

1. I wish I’d had the courage to live a life true to myself, not the life others expected of me.
This was the most common regret of all. When people realize that their life is almost over and look back clearly on it, it is easy to see how many dreams have gone unfulfilled. Most people had not honoured even a half of their dreams and had to die knowing that it was due to choices they had made, or not made.

It is very important to try and honour at least some of your dreams along the way. From the moment that you lose your health, it is too late. Health brings a freedom very few realise, until they no longer have it.

2. I wish I didn’t work so hard.
This came from every male patient that I nursed. They missed their children’s youth and their partner’s companionship. Women also spoke of this regret. But as most were from an older generation, many of the female patients had not been breadwinners. All of the men I nursed deeply regretted spending so much of their lives on the treadmill of a work existence.

By simplifying your lifestyle and making conscious choices along the way, it is possible to not need the income that you think you do. And by creating more space in your life, you become happier and more open to new opportunities, ones more suited to your new lifestyle.

3. I wish I’d had the courage to express my feelings.
Many people suppressed their feelings in order to keep peace with others. As a result, they settled for a mediocre existence and never became who they were truly capable of becoming. Manydeveloped illnesses relating to the bitterness and resentment they carried as a result.

We cannot control the reactions of others. However, although people may initially react when you change the way you are by speaking honestly, in the end it raises the relationship to a whole new and healthier level. Either that or it releases the unhealthy relationship from your life. Either way,you win.

4. I wish I had stayed in touch with my friends.
Often they would not truly realise the full benefits of old friends until their dying weeks and it was not always possible to track them down. Many had become so caught up in their own lives that they had let golden friendships slip by over the years. There were many deep regrets about not giving friendships the time and effort that they deserved. Everyone misses their friends when they are dying.

It is common for anyone in a busy lifestyle to let friendships slip. But when you are faced with your approaching death, the physical details of life fall away. People do want to get their financial affairs in order if possible. But it is not money or status that holds the true importance for them. They want to get things in order more for the benefit of those they love. Usually though, they are too ill and weary to ever manage this task. It is all comes down to love and relationships in the end. That is all that remains in the final weeks, love and relationships.

5. I wish that I had let myself be happier.
This is a surprisingly common one. Many did not realise until the end that happiness is a choice. They had stayed stuck in old patterns and habits. The so-called ‘comfort’ of familiarity overflowed into their emotions, as well as their physical lives. Fear of change had them pretending to others, and to their selves, that they were content. When deep within, they longed to laugh properly and have silliness in their life again. When you are on your deathbed, what  others think of you is a long way from your mind. How wonderful to be able to let go and smile again, long before you are dying.

Life is a choice. It is YOUR life. Choose consciously, choose wisely, choose honestly. Choose happiness

from :: http://worldobserveronline.com/

Read More

How to Create a Desktop Shortcut to a Website

Creating desktop shortcuts to a websites is useful. When you double-click the icon from your desktop it automatically launches the browser and opens the site. It will open the website in the browser you used when creating the shortcut.

3 Simple Steps to Create a Shortcut to a Website

The following steps will guide you through the process of creating a desktop shortcut to a website using Firefox, Chrome or Internet Explorer (IE).

1) Resize your Web browser so you can see the browser and your desktop in the same screen.

2) Left click the icon located to the left side of the address bar. This is where you see the full URL to the website.

3) Continue to hold down the mouse button and drag the icon to your desktop. This creates the shortcut.

After creating the shortcut you can right-click on the icon and select Rename to edit the text description.

Read More

MySQL COALESCE() function

MySQL COALESCE() function returns the first non-NULL value of a list, or NULL if there are no non-NULL values.

MySQL Version : 5.6

Syntax

COALESCE(value1,value2,value3,...)

The above syntax is equivalent to the following IF-THEN-ELSE statement

  IF value1 is not NULL THEN
     result = value1;
  ELSIF value2 is not NULL THEN
     result = value2;
  ELSIF value3 is not NULL THEN
     result = value3;
  ELSE
     result = NULL;
  END IF; 

- See more at: http://www.w3resource.com/mysql/comparision-functions-and-operators/coalesce-function.php#sthash.mgOL7uGR.dpuf

Read More

Grails allow null for double not working

Primitive double type variable itself can neither be null nor be blank(blank:true is for String only). It has nothing to do with Grails. Use java.lang.Double instead:


use 

java.lang.Double days

instead of 

double days

Read More

TRUNCATE TABLE Syntax

So you need to empty the table use the following command

TRUNCATE TABLE empties a table completely. Logically, this is equivalent to a DELETE statement that deletes all rows, but there are practical differences under some circumstances

TRUNCATE  tbl_name

TRUNCATE TABLE empties a table completely. Logically, this is equivalent to a DELETE statement that deletes all rows, but there are practical differences under some circumstances.

Read More

String index out of range: 0

String index out of range: 0

if this is your error , you are trying to fetch that value that is not present. you should confirm the length of the variable or array with .length()

The problem occurs when line is empty (e.g. ""). Then it doesn't have a character at index 0, hence your error.

Read More

How to upload large database in phpmyadmin with cmd prompt

To import large file in phpmyadmin . keep  that sql file in

C:\xampp\mysql\bin

or where your mysql bin is located.

and go to cmd prompt and do as in following picture

Read More

MySQL - Operand should contain 1 column(s)

Yeah i got this problem in a query. and searched for it in google. here is what i got :

this is a example in the internet ::


wrong query:

UPDATE ADRESSEN
SET EMAIL = 0
WHERE ID = (SELECT ID, COUNT(ID) AS COUNTER
FROM EIGENSCHAFTEN WHERE Kategorie = "BOUNCE" 
GROUP BY ID
HAVING COUNTER = 1)

The issue is your inner query is returning two columns. Modify query like

UPDATE ADRESSEN
SET EMAIL = 0
WHERE ID = (SELECT ID
FROM EIGENSCHAFTEN WHERE Kategorie = "BOUNCE" 
GROUP BY ID
HAVING COUNT(ID) = 1)



This should work.

I have one more suggestion, are you sure that your inner query will always return one row? If you want EMAIL to be set with value 0 for multiple IDs returned by inner query I would recommend you use "IN" instead of "=".

Read More

Cannot find plugin descriptor in plugin directory in Grails

1. Go to 'C:\Documents and Settings\jpalmer\.grails\1.2.2\projects\' and delete the 'cgug' folder


or 

2. Install the plugin whose descriptor is not found :) ------(bad trick)

Read More

Grails redirect not working / Grails action is rendering but not reloading

I got a problem where action would not redirect to another action with following code:


redirect(controller: "book", action: "list")


then i used following code in Javascript file to redirect to new page

function holidaydelete(a){
        var sId = a
        var yearr = $('#daa'+sId+'_year').val()
        var month = $('#daa'+sId+'_month').val()
        var day = $('#daa'+sId+'_day').val()
        var date = yearr +"-"+ month +"-"+ day

    
 ${remoteFunction(controller: "att", action: "deleteHolidayDate", update: "", params:'{date: date, sId: sId}')}
//to redirect       
 var current = window.location.href;
        var toSplit = 'pms/';
        var splitLocation = current.split(toSplit)
        var newLocationToLoad = splitLocation[0]+toSplit+'att/holidayDate';
        window.location.href = newLocationToLoad

    }


this may be helpful to you !!!

Read More

The Joel Test: 12 Steps to Better Code

The Joel Test: 12 Steps to Better Code

by Joel Spolsky

Wednesday, August 09, 2000

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 Do you use source control? Can you make a build in one step? Do you make daily builds? Do you have a bug database? Do you fix bugs before writing new code? Do you have an up-to-date schedule? Do you have a spec? Do programmers have quiet working conditions? Do you use the best tools money can buy? Do you have testers? Do new candidates write code during their interview? Do you do hallway usability testing?

The neat thing about The Joel Test is that it's easy to get a quick yesor 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 beforewriting 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 topredict 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'scausing 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 intofeaturitis (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 takean 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 -- especiallyinterruptions 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 myGuerrilla 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. ReadJakob 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.

Have you been wondering about Distributed Version Control? It has been a huge productivity boon for us, so I wrote Hg Init, a Mercurial tutorial—check it out!

Next:

Wasting Money on Cats

 

Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies. 

About the author. 

I’m Joel Spolsky, co-founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make Trello, insanely simple project management, FogBugz, an enlightened bug tracker designed to help great teams develop brilliant software, and Kiln, which simplifiessource control. I’m also the co-founder and CEO of Stack Exchange.More about me.

Read More