Sample vimrc file

The vimrc file contains optional runtime configuration settings to initialize Vim when it starts. On Unix based systems, the file is named .vimrc

Here is a sample .vimrc file I use.

"set smarttab       " When on, a in front of a line inserts blanks according to shiftwidth
set showmode        " Show the current mode
set showcmd         " display incomplete commands
set showmatch       " show matching braces,
set hlsearch        " highlight searches
"set title          " show title in console title bar
set laststatus=2    " always show status line
set ic              " case insensitive search : use set noic to turn it off

set nocompatible    " This setting prevents vim from emulating the original vi's bugs and limitations.

set autoindent
set smartindent
"   The first setting tells vim to use autoindent (that is, use the current line's indent level to set the indent level of new lines). The second makes vim attempt to intelligently guess the indent level of any new line based on the previous line, assuming the source file is in a C-like language. Combined, they are very useful in writing well-formatted source code.

set tabstop=2
set shiftwidth=2
"  The first setting sets up 2-space tabs, and the second tells vi to use 2 spaces when text is indented (auto or with the manual indent adjustmenters.)

set showmatch
"    This setting will cause the cursor to very briefly jump to a brace/parenthese/bracket's match whenever you type a closing or opening brace/parenthese/bracket. I've had almost no mismatched-punctuation errors since I started using this setting.

set vb t_vb=
"This setting prevents vi from making its annoying beeps when a command doesn't work. Instead, it briefly flashes the screen -- much less annoying.

set ruler
"    This setting ensures that each window contains a statusline that displays the current cursor position.


set incsearch
"    With this nifty option, vim will search for text as you enter it. For instance, if you type /bob to search for bob, vi will go to the first b after you type the b, to the first bo after you type the o, and so on. It makes searching much faster, since if you pay attention you never have to enter more than the minimum number of characters to find your target location. Make sure that you press Enter to accept the match after vim finds the location you want.

"set virtualedit=all
"    By default, vim doesn't let the cursor stray beyond the defined text. This setting allows the cursor to freely roam anywhere it likes in command mode. It feels weird at first but is quite useful.


set tags=/tags,./tags
set showfulltag         " Get function usage help automatically

""""""""""""" Highlight following in all files """"""""""""""""""""""
hi TODO ctermfg=red ctermbg=blue term=bold
syntax match TODO /TODO/



""""""""""""""""""""""""""""""""""""""""""
"        Use Cscope within Vi                        "
""""""""""""""""""""""""""""""""""""""""""" Refer http://vim.wikia.com/wiki/Cscope for more details

if has('cscope')
  set cscopetag cscopeverbose

  if has('quickfix')
    set cscopequickfix=s-,c-,d-,i-,t-,e-
  endif

  cnoreabbrev csa cs add
  cnoreabbrev csf cs find
  cnoreabbrev csk cs kill
  cnoreabbrev csr cs reset
  cnoreabbrev css cs show
  cnoreabbrev csh cs help

  command -nargs=0 Cscope cs add $VIMSRC/src/cscope.out $VIMSRC/src
endif""""""""""""""""""""""""""""""""""""""""""

""""""""""""""""""""""""""""""""""""""""""
"               Mappings                 "
""""""""""""""""""""""""""""""""""""""""""
" Keyboard mappings
map :previous  " map F1 to open previous buffer
map :next      " map F2 to open next buffer

map :setl noai nocin nosi inde= " Disabling auto indent for the current file

Steve Jobs' Speech at Stanford

Here is an interesting and inspiring Commencement address by Steve Jobs at Stanford University.
In brief, he talks about life, profession, death.  


I am honored to be with you today at your commencement from one of the finest universities in the world. I never graduated from college. Truth be told, this is the closest I've ever gotten to a college graduation. Today I want to tell you three stories from my life. That's it. No big deal. Just three stories.

The first story is about connecting the dots.

I dropped out of Reed College after the first 6 months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out?

It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: "We have an unexpected baby boy; do you want him?" They said: "Of course." My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college.

And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents' savings were being spent on my college tuition. After six months, I couldn't see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out OK. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn't interest me, and begin dropping in on the ones that looked interesting.

It wasn't all romantic. I didn't have a dorm room, so I slept on the floor in friends' rooms, I returned coke bottles for the 5¢ deposits to buy food with, and I would walk the 7 miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on. Let me give you one example:

Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn't have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can't capture, and I found it fascinating.

None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, its likely that no personal computer would have them. If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards ten years later.

Again, you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

My second story is about love and loss.

I was lucky — I found what I loved to do early in life. Woz and I started Apple in my parents garage when I was 20. We worked hard, and in 10 years Apple had grown from just the two of us in a garage into a $2 billion company with over 4000 employees. We had just released our finest creation — the Macintosh — a year earlier, and I had just turned 30. And then I got fired. How can you get fired from a company you started? Well, as Apple grew we hired someone who I thought was very talented to run the company with me, and for the first year or so things went well. But then our visions of the future began to diverge and eventually we had a falling out. When we did, our Board of Directors sided with him. So at 30 I was out. And very publicly out. What had been the focus of my entire adult life was gone, and it was devastating.

I really didn't know what to do for a few months. I felt that I had let the previous generation of entrepreneurs down - that I had dropped the baton as it was being passed to me. I met with David Packard and Bob Noyce and tried to apologize for screwing up so badly. I was a very public failure, and I even thought about running away from the valley. But something slowly began to dawn on me — I still loved what I did. The turn of events at Apple had not changed that one bit. I had been rejected, but I was still in love. And so I decided to start over.

I didn't see it then, but it turned out that getting fired from Apple was the best thing that could have ever happened to me. The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter one of the most creative periods of my life.

During the next five years, I started a company named NeXT, another company named Pixar, and fell in love with an amazing woman who would become my wife. Pixar went on to create the worlds first computer animated feature film, Toy Story, and is now the most successful animation studio in the world. In a remarkable turn of events, Apple bought NeXT, I returned to Apple, and the technology we developed at NeXT is at the heart of Apple's current renaissance. And Laurene and I have a wonderful family together.

I'm pretty sure none of this would have happened if I hadn't been fired from Apple. It was awful tasting medicine, but I guess the patient needed it. Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You've got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle.

My third story is about death.

When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you'll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.

Remembering that I'll be dead soon is the most important tool I've ever encountered to help me make the big choices in life. Because almost everything — all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.

About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn't even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor's code for prepare to die. It means to try to tell your kids everything you thought you'd have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up so that it will be as easy as possible for your family. It means to say your goodbyes.

I lived with that diagnosis all day. Later that evening I had a biopsy, where they stuck an endoscope down my throat, through my stomach and into my intestines, put a needle into my pancreas and got a few cells from the tumor. I was sedated, but my wife, who was there, told me that when they viewed the cells under a microscope the doctors started crying because it turned out to be a very rare form of pancreatic cancer that is curable with surgery. I had the surgery and I'm fine now.

This was the closest I've been to facing death, and I hope its the closest I get for a few more decades. Having lived through it, I can now say this to you with a bit more certainty than when death was a useful but purely intellectual concept:

No one wants to die. Even people who want to go to heaven don't want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life's change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.

Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma — which is living with the results of other people's thinking. Don't let the noise of others' opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.

When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960's, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.

Stewart and his team put out several issues of The Whole Earth Catalog, and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: "Stay Hungry. Stay Foolish." It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.

Stay Hungry. Stay Foolish.

Thank you all very much.




 

The Free Lunch is Over

This is an article from Herb Sutter (A software architect at Microsoft, and chair of the ISO C++ standards committee) stating the importance Of multithreaded programming paradigm that has come up to the forefront because of changes in CPU architecture.

You can access it here

97 Things Every Programmer Should Know

Get 97 short and extremely useful tips from some of the most experienced and respected practitioners in the industry.

They encourage you to stretch yourself by learning new languages, looking at problems in new ways, following specific practices, taking responsibility for your work, and becoming as good at the entire craft of programming as you possibly can.

Contributions Appearing in the Book

1. Act with Prudence by Seb Rose
2. Apply Functional Programming Principles by Edward Garson
3. Ask "What Would the User Do?" (You Are not the User) by Giles Colborne
4. Automate Your Coding Standard by Filip van Laenen
5. Beauty Is in Simplicity by Jørn Ølmheim
6. Before You Refactor by Rajith Attapattu
7. Beware the Share by Udi Dahan
8. The Boy Scout Rule by Uncle Bob
9. Check Your Code First before Looking to Blame Others by Allan Kelly
10. Choose Your Tools with Care by Giovanni Asproni
11. Code in the Language of the Domain by Dan North
12. Code Is Design by Ryan Brush
13. Code Layout Matters by Steve Freeman
14. Code Reviews by Mattias Karlsson
15. Coding with Reason by Yechiel Kimchi
16. A Comment on Comments by Cal Evans
17. Comment Only What the Code Cannot Say by Kevlin Henney
18. Continuous Learning by Clint Shank
19. Convenience Is not an -ility by Gregor Hohpe
20. Deploy Early and Often by Steve Berczuk
21. Distinguish Business Exceptions from Technical by Dan Bergh Johnsson
22. Do Lots of Deliberate Practice by Jon Jagger
23. Domain-Specific Languages by Michael Hunger
24. Don't Be Afraid to Break Things by Mike Lewis
25. Don't Be Cute with Your Test Data by Rod Begbie
26. Don't Ignore that Error! by Pete Goodliffe
27. Don't Just Learn the Language, Understand its Culture by Anders Norås
28. Don't Nail Your Program into the Upright Position by Verity Stob
29. Don't Rely on "Magic Happens Here" by AlanGriffiths
30. Don't Repeat Yourself by Steve Smith
31. Don't Touch that Code! by Cal Evans
32. Encapsulate Behavior, not Just State by Einar Landre
33. Floating-point Numbers Aren't Real by Chuck Allison
34. Fulfill Your Ambitions with Open Source by Richard Monson-Haefel
35. The Golden Rule of API Design by Michael Feathers
36. The Guru Myth by Ryan Brush
37. Hard Work Does not Pay Off by Olve Maudal
38. How to Use a Bug Tracker by Matt Doar
39. Improve Code by Removing It by Pete Goodliffe
40. Install Me by Marcus Baker
41. Inter-Process Communication Affects Application Response Time by Randy Stafford
42. Keep the Build Clean by Johannes Brodwall
43. Know How to Use Command-line Tools by Carroll Robinson
44. Know Well More than Two Programming Languages by Russel Winder
45. Know Your IDE by Heinz Kabutz
46. Know Your Limits by Greg Colvin
47. Know Your Next Commit by Dan Bergh Johnsson
48. Large Interconnected Data Belongs to a Database by Diomidis Spinellis
49. Learn Foreign Languages by Klaus Marquardt
50. Learn to Estimate by Giovanni Asproni
51. Learn to Say "Hello, World" by Thomas Guest
52. Let Your Project Speak for Itself by Daniel Lindner
53. The Linker Is not a Magical Program by Walter Bright
54. The Longevity of Interim Solutions by Klaus Marquardt
55. Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly by Scott Meyers
56. Make the Invisible More Visible by Jon Jagger
57. Message Passing Leads to Better Scalability in Parallel Systems by Russel Winder
58. A Message to the Future by Linda Rising
59. Missing Opportunities for Polymorphism by Kirk Pepperdine
60. News of the Weird: Testers Are Your Friends by Burk Hufnagel
61. One Binary by Steve Freeman
62. Only the Code Tells the Truth by Peter Sommerlad
63. Own (and Refactor) the Build by Steve Berczuk
64. Pair Program and Feel the Flow by Gudny Hauknes, Ann Katrin Gagnat, and Kari Røssland
65. Prefer Domain-Specific Types to Primitive Types by Einar Landre
66. Prevent Errors by Giles Colborne
67. The Professional Programmer by Uncle Bob
68. Put Everything Under Version Control by Diomidis Spinellis
69. Put the Mouse Down and Step Away from the Keyboard by Burk Hufnagel
70. Read Code by Karianne Berg
71. Read the Humanities by Keith Braithwaite
72. Reinvent the Wheel Often by Jason P Sage
73. Resist the Temptation of the Singleton Pattern by Sam Saariste
74. The Road to Performance Is Littered with Dirty Code Bombs by Kirk Pepperdine
75. Simplicity Comes from Reduction by Paul W. Homer
76. The Single Responsibility Principle by Uncle Bob
77. Start from Yes by Alex Miller
78. Step Back and Automate, Automate, Automate by Cay Horstmann
79. Take Advantage of Code Analysis Tools by Sarah Mount
80. Test for Required Behavior, not Incidental Behavior by Kevlin Henney
81. Test Precisely and Concretely by Kevlin Henney
82. Test While You Sleep (and over Weekends) by Rajith Attapattu
83. Testing Is the Engineering Rigor of Software Development by Neal Ford
84. Thinking in States by Niclas Nilsson
85. Two Heads Are Often Better than One by Adrian Wible
86. Two Wrongs Can Make a Right (and Are Difficult to Fix) by Allan Kelly
87. Ubuntu Coding for Your Friends by Aslam Khan
88. The Unix Tools Are Your Friends by Diomidis Spinellis
89. Use the Right Algorithm and Data Structure by JC van Winkel
90. Verbose Logging Will Disturb Your Sleep by Johannes Brodwall
91. WET Dilutes Performance Bottlenecks by Kirk Pepperdine
92. When Programmers and Testers Collaborate by Janet Gregory
93. Write Code as If You Had to Support It for the Rest of Your Life by Yuriy Zubarev
94. Write Small Functions Using Examples by Keith Braithwaite
95. Write Tests for People by Gerard Meszaros
96. You Gotta Care about the Code by Pete Goodliffe
97. Your Customers Do not Mean What They Say by Nate Jackson

Here is the link to the home page:

http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know 

Computer Geek Test

Alex Stepenov's Advice To Young Programmers

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


1. Study , Study and Study
Never ever think that you have acquired all or most of the knowledge which exists in the world. Almost everybody in US at age of 14 and everybody in India at age of 24 starts thinking that he has acquired all the wisdom and knowledge that he needs. This should be strictly avoided.
You should be habituated to studies…exactly in the same way as you are habituated to brushing teeth and taking bath every morning. The habit of study must become a part of your blood. And the study should be from both the areas: CS, since it is your profession, and something from non-CS…Something which does not relate to your work. This would expand your knowledge in other field too. A regular study, everyday, is extremely essential. It does not matter whether you study of 20 minutes of 2 hours,but consistency is a must.

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

1. Structure and Interpretation of Computer Programs by Albenson and Sussman. I personally do not like the material present in this book and I do have some objections about it but this is the best book I have ever seen which explains all the concepts in programming in a clear and excellent way. This book is available online at “http://mitpress.mit.edu/sicp/“
2. Introduction to Computer Architecture by Hennessy and Patterson. How many of you have shipped the programs by writing them in assembly? A very good understanding of basics of how a computer operates is what every CS professional must have. H&P Wrote two books on CA. I am talking about their first book, the introductory text for understanding basic aspects of how a computer works. Even if you feel that you know whatever is written in that book,do not stop reading. It’s good to revise basics again and again.
3. Fundamentals of Programming by Donald Knuth The core of CS is algorithms and Data structures. Every CS professional must have the 3 volumes of Knuth’s Book on programming. It really does not matter if you take 30 years of your life to understand what Knuth has written, what is more important is that you read at least some part of that book everyday without fail.
4. Introduction to Algorithms by Cormen, Leiserson and Rivest. This book should be read daily to keep your concepts fresh. This is the best book for fundamental concepts in algorithms.

2. Learn Professional Ethics
As a CS Professional, you are morally obliged to do a good job. What this means is that you are supposed to do your job not for your manager but for yourself. This is already told in Bhagwatgeeta : Doing duties of your life. The direct implication of this is: never ever write a bad code. You don’t need to be fastest and run after shipping dates; rather you need to write quality code. Never write junk code. Rewrite it till it is good. Thoroughly test every piece of code that you write. Do not write codes which are “sort of alright”. You might not achieve perfection, but at least your code should be of good quality.

Let me quote my own example in this context. You might have heard about STL, The Standard Template Library that ships in with C++ compilers. I wrote it 10 years ago, in 1994. While implementing one of the routines in the STL, namely the “search routine”, I was a bit lazy and instead of writing a good linear order implementation of KMP which was difficult to code, I wrote a best quadratic implementation. I knew that I could make the search faster by writing a linear-order implementation, but I was lazy and I did not do that. And, after 10 years of my writing STL, exactly the same implementation is still used inside STL and STL ships with an inefficient quadratic implementation of search routine even today!! You might ask me: why can’t you rewrite that? Well…I
cannot,because that code is no more my property!! Further, nobody today will be interested in a standalone efficient STL …people would prefer one which automatically ships out with the compiler itself.

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


3. Figure out your Goals


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

You might feel that you want to do certain things which you cannot do till you become a manager. When you become a manager, you will soon realize that now you just cannot do anything!
You will have a great experience as programmers. But if you care for people and love people, you will never enjoy being a manager…most good managers are reluctant managers. If you see people as people, you cannot survive at management level.
Always aspire for professional greatness. Our profession is very beautiful because we create abstract models and implement them in reality. There is a big fun in doing that. We have a profession which allows us to do creative things and even gives nice salary for that.

The three biggest mistakes that people usually make are aiming for money,aiming for promotion and aiming for fame. The moment you get some of these, you aspire for some more…and then there is no end. I do not mean that you should not earn money, but you should understand how much money would satisfy your needs. Bill Gates might be the richest person in the world; he is certainly not the happiest. Our lives are far better than his.

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



4. Follow your culture

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




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


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