1. Wait for the ‘Aha’ moment
Don’t rush in a solution. Wait and analyze the problem. Most problems are test of analytical skills and not of maths skills. If solution can be obtained by pen and paper, then its not really a test of the brain skills.

2. Logical Deductions
Always follow through with deductions on the problem set with ur logical choice. In other words think clearly that if  we make a choice, how does it affect the entire problem set. This is the KEY to most problems.

3. Consider Small/Large Data sets
Always run your solutions through a small and a large sample set to be confident of your solutions. Most weak designs will crack with large data sets

4. Patience
Patience is important and perseverance to find a solution to the challenge is crucial.

5. Arrogance for knowledge is Evil
Arrogance for ones knowledge can bring geniuses down.  When you have a superiority complex, think of your role models. That should humble you down.

Lastly, remember the ‘The Alchemist”. If you really want something, the universe conspires in helping you get it.

http://eagain.net/articles/git-for-computer-scientists/

Git is distributed SCM of the future. GIT, an amazing and very smart implementation of basic computer science concepts….

The official gmailblog forums says no way to bulk forward chat logs. Looked around for options(greasemonkey, etc) but no luck.

But Finally found a way out.

Check out http://libgmail.sourceforge.net/. It allows to log in to ur gmail and export selected folders and mails and EVEN chat logs.

Steps

- Create Gmail folder for chat messages and add a gmail filter to copy all message logs in that gmail folder
- Setup python.
- Setup mechanize( use easy-install)
- Setup libgmail
- Run  archive.py

and Voila!!!..all mails/chat are exported in .mbox for backup…Sweettttt..:)

Another resource for some great sketches and drawings is http://hikingartist.com/. Very creative and innovative way of expressing thoughts.

http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html?page=1

Brian Goetz talks about how the Double Check Locking can be broken down due to the way the Java compiler persists variables to memory and the interaction between threads.

http://www.ibm.com/developerworks/library/j-threads3.html

Is a very good introduction of ThreadLocal variables. As the name suggests, these variables are local to each thread.

Some key points from his clean code articles:

• The longer the scope of a function, the shorter its name should be. Functions that are called locally from a few nearby places should have long descriptive names, and the longest function names should be given to those functions that are called from just one place.
  • Functions in small scopes should have long and precise names.
  • You should not have to read the body of a function to know what it does. It’s name should tell you.
  • The more complex the behavior of a function, the more generic its name, and the more sub functions should be extracted from it.
• C1: Inappropriate Information
  It is inappropriate for a comment to hold information better held in a different kind of system such as your source code control system, your issue tracking system, or any other record-keeping system.  Change histories, for example, just clutter up source files with volumes of historical and uninteresting text.  In general, meta-data such as authors, last-modified-date, SPR number, and so on should not appear in comments.  Comments should be reserved for technical notes about the code and design.
• C2: Obsolete Comment
  A comment that has gotten old, irrelevant, and incorrect is obsolete.  Comments get old quickly.  It is best not to write a comment that will become obsolete.  If you find an obsolete comment, it is best to update it or get rid of it as quickly as possible.  Obsolete comments tend to migrate away from the code they once described.  They become floating islands of irrelevance and misdirection in the code.  
•  C3: Redundant Comments
  A comment is redundant if it describes something that adequately describes itself.
• C4: Poorly Written Comment
  A comment worth writing is worth writing well. If you are going to write a comment, take the time to make sure it is the best comment you can write. Choose your words carefully. Use correct grammar and punctuation. Don’t ramble. Don’t state the obvious. Be brief.

• C5: Commented-Out Code
  Commented-out code is an abomination.
  When you see commented-out code, delete it! Don’t worry; the source code control system still remembers it. If anyone really needs it, he or she can go back and check out a previous version. Don’t suffer commented-out code to survive.

   

Check out his articles on http://www.informit.com/authors/bio.aspx?a=361a5e70-f1e2-432b-9928-b30b4742ae80