Epigrams on Programming

Just for fun :) http://pu.inf.uni-tuebingen.de/users/klaeren/epigrams.html

My favorite quotes:

"Whenever two programmers meet to criticize their programs, both are silent."

"Every program has (at least) two purposes: the one for which it was written and another for which it wasn't."

Invaluable lessons from Jeff Bezos

If you are an entrepreneur or want to be one or work in a startup or a big company and want to learn from one of the best entrepreneur in the world, you should read this awesome blog about lessons to learn from Jeff Bezos, founder and CEO of Amazon.

Here is the two-pager on that blog, in case you don't want to read the entire blog.

1. Be Stubborn and Flexible 

According to Bezos, good entrepreneurs must be stubborn and flexible. When referring to Amazon, Bezos says, “We are stubborn on vision. We are flexible on details.”

2. Stick with Two Pizzas teams
When teams grow larger, they have a tendency to become less efficient. This inefficiency reduces the output of the team and leads to waste. So keep teams small and let them test.

3. Never Stop Experimenting
An awesome quote from Bezos:

“If you double the number of experiments you do per year you’re going to double your inventiveness.”

4. Be Willing to Invent

5. Think Long Term
Once, when asked about Amazon’s revenue growth, Bezos couldn’t even remember the exact growth percentage, something rare for a CEO. When asked why he didn’t know, he said:

“I’m thinking a few years out. I’ve already forgotten those numbers.”

6. Tie Experimentation, Willingness to Invent, and Innovation All Together
At his talk in November 2012 at the re: Invent conference, Bezos explains how:

Innovation = Experimentation + Willingness to Invent

“Now there are a couple of other things that are essential for innovation and invention that are not as fun. One of them is you have to have a willingness to fail. You have to have a willingness to be misunderstood for long periods of time. If you do something in a new way, and I don’t care what it is, people are initially going to misunderstand it relative to the traditional way..."

“.. So it’s okay though if you have a willingness to be misunderstood for long periods of time, if you have a willingness to fail, then what you can do is you can ramp up your rate of experimentation. So successful invention is inventions that customers care about. It’s actually relatively easy to invent new things that customers don’t care about..."

7. Present and Discuss Memoranda, not Slide Shows
“The traditional kind of corporate meeting is somebody gets up in the front of the room and presents…some kind of slide show. In our view…you get very little information that way, you get bullet points. It’s easy for the presenter but difficult for the audience. And so, instead, what we do is all of our meetings are structured around a 6-page narrative memo. And when you have to write your ideas out in complete sentences and complete paragraphs, it forces a deeper clarity of thinking.”

8. Obsess About Customers
“Focusing on the customer makes a company more resilient.”

At Amazon, there is a common line of thinking:
“Start with the customer and work backwards.“

9. Base Your Strategy on Things That Won’t Change
Bezos at re: Invent, November 2012:

“I very frequently get the question: ‘what’s going to change in the next 10 years?’ And that is a very interesting question; it’s a very common one. I almost never get the question: ‘what’s not going to change in the next 10 years?’ And I submit to you that that second question is actually the more important of the two – because you can build a business strategy around the things that are stable in time….in our retail business, we know that customers want low prices and I know that’s going to be true 10 years from now..."

10. Identify and Remove Risk
According to Bezos, the best entrepreneurs don’t like risk and work to identify it and remove it in the early days of a business. He says:

“Good entrepreneurs don’t like risk; they seek to reduce risk…Starting a company is already risky, and then you systematically eliminate risk step by step in those early days….you kind of need to systematically identify risk and then as the company gets bigger and more robust, you can start taking risks again but in those early days a lot of it is about ‘okay I have a good idea, how do we reduce risk?’”

11. Get Started Now to Avoid Regret LaterWhen Bezos was thinking about building Amazon, he had to decide whether to start the company or keep his good job on Wall Street. He created a framework to use for making the decision that he calls a Regret Minimization Framework. It helped him realize he didn’t want to not do it and regret it later. This fear of regret is one of the key reasons why he decided to go ahead and start Amazon.

12. Bezos Gives Entrepreneurs AdviceAt his talk at re: Invent, he gave some direct advice to all entrepreneurs:

1) “Never chase the hot thing….you need to position yourself and wait for the wave. And the way you do that is you pick something you’re passionate about. That’s the number one piece of advice that I’d give to someone that wants to start a company or start a new endeavor inside of a bigger company. Make sure it’s something you’re interested in, something you’re passionate about. Missionaries build better products…I’d take a missionary over a mercenary any day. Mercenaries want to flip the company and get rich, missionaries want to build a great product or service – and one of those paradoxes is usually the missionaries end up making more money anyway…..pick something you’re passionate about.”

2) “Start with the customer and work backwards. Those two things, passion and customer centricity, will take you an awful long way.”

TDD is not all about writing tests first

TDD's mantra:

In words:

• Add a failing test
• Write code to pass the test
• Refactor

If you want to get a firm grip on this awesome methodology, read this book by Kent Beck.

However, TDD is not just about writing your tests first or to increase your code's test coverage. These are just the add-ons that you get for free when you use TDD. The mantra behind using TDD is to improve your design, to think from a consumer point of view who is going to use your components or APIs. These consumers can be anyone, it could be you, your team mates, other teams or general public.

Then, you may ask how can writing tests first allows you to better design your interfaces? Good question. Lets think about it in this way. Why we write software? One possible answer is to create some applications that does few useful things that wouldn't have been possible or too tedious to do manually. Its creates something with some intent that someone can use it. So two things that pop out: intent and use. I think that TDD allows you to get these two things right, the intent and use, while creating software. Again you may ask, still how writing a test helps you to get these two things right? Good question again.

When you are writing a test even without the code itself, the most important thing that comes to your mind is how am I going to use this component in my system or application. This makes you think about the interfaces, the parameters, the exceptions you want this method to throw. And there you design your API.

And then the other most important thing you think about what is the intent or the purpose of the code that you are about to write. What you want this piece of code to do? That is what makes you to write your assert statements.

Yes, it could be very difficult to digest this test-first approach initially if you haven't been practicing such methodology but once you do you will see the results and it value. You will be amazed to see how easy it becomes to design your components if they are easy to test.

I have been using TDD for more than a year now and I can definitely see the difference in the way I think and develop software. Its weird but TDD makes you to not to hate writing unit tests since they are the not burdensome-after-thoughts anymore.

Then, there are so many other good things that come for free when you write your tests first. It makes you confident about refactoring existing code. I am currently working on a system at Amazon that serves million of customers and allow them to play with their apps with almost zero downtime. How can you imagine refactoring such a service where a simple mistake can either lead to doing something unintended that breaks millions' of users Appstore experience or can breaks a functionality (or Appstore client) in its entirety? We want our tests to fail first in such cases. 

Then there is code coverage. You won't believe the results of running a code coverage tool on a codebase that is written using TDD approach. It does not give you a single opportunity to make the coverage better by looking at the results and then 'hack' the tests to increase the coverage since you already get an amazing high code coverage for free!

Give it a try, its worth it.

Few useful Git commands

I have been using Git at work for last couple of years now and I must say it has helped me a lot to be more productive and pushing out more and more features instead of either waiting for code reviews or waiting for the expensive branches (as in Perforce) to get created.

I won't go into details on how Git has helped me and why I love this tool but rather will post some very useful commands that helps to get around some very tricky situations. I found these commands from various posts while looking for solutions to these problems I encountered while at work. So yes, these are not 'my' solutions but they do work.

How to get a list of un-pushed commits in git?

Assuming your remote repository is named origin and you’re dealing with the master branch:

  

  $ git log master ^origin/master

This shows what commits are in master but not in origin/master (which is the remote branch).

This same syntax can be used to see the difference between two local branches, but will show cherry-picked commits as differences which can be confusing:

   

 $ git log master ^production

Delete last commit

To soft delete the commit before head. Alternatively you can refer to the SHA-1 of the hash you want to reset to. --soft option will delete the commit but it will leave all your changed files "Changes to be committed", as git status would put it.

$ git reset --soft HEAD~1

If you want to get rid of any changes to tracked files in the working tree since the commit before head use --hard instead.

Now if you already pushed and someone pulled which is usually my case, you can't use git reset. You can however do a git revert,

  

$ git revert HEAD

This will create a new commit that reverses everything introduced by the accidental commit.

Make an existing git branch track a remote branch?

Given a branch foo and a remote upstream, as of Git 1.7.0:

$ git branch --set-upstream foo upstream/foo

That will cause Git to make local branch foo track remote branch foo from upstream.

How to undo "git commit --amend"?

Move the current head so that it's pointing at the old commit. Leave the index intact for redoing the commit

$ git reset --soft HEAD@{1}

commit the current tree using the commit details of the previous HEAD commit. 

(Note that HEAD@{1} is pointing somewhere different from the previous command. It's now pointing at the erroneously amended commit.)

$ git commit -C HEAD@{1}

Log5j vs Log4j

Log5j is a modern facade over the most heavily used logging framework Log4j that not only provides a better interface for logging but also performs better. Even though Log5j has a lot of advantages, most of the projects (even at Amazon) uses Log4j. You will find logs like this all over the code base

    

   log.info("this is the string with value " + value + " and it does stink with factor" + stinkfactor);

All those concatenations, yuck!

I found the interface of Log5j pretty awesome, specially when it allows to you log like

    

   log.info("this is the string with value %s and it does not stink",value);

But out of curiosity, I wanted to know how good its performance is. I did a simple test and found some interesting results.

Experiment Setup

Unit tests with log4j configured with a FileAppender (similar to what every production environment uses). The log level was set to INFO (hence DEBUG was disabled). In each test, logs with different types of logging statements (with/without parameters) were emitted in a loop with a 2 million count. Randomly generated numbers were used as parameters in each loop just to avoid some optimizations that could be done by compiler if you have constant strings.

Use case	Performance (test finished in msec)		Notes
	Log 4j	Log 5j
Debug log with parameters no isDebugEnabled() using String.format() to format log statement	6184	183	String.format() was used only for log4j to simulate what log5j does internally Log5j does not need String.format()
Debug log with parameters no isDebugEnabled() not using String.format()	1350	265	For log4j, logging statement like "log text" + param1 + " and other param" + random() was used.
Debug log without parameters no isDebugEnabled()	52	142
Debug log with parameters with isDebugEnabled() check for log4j	128	183	isDebugEnabled() not required for log5j
Info log with parameters using String.format()	50192	45667	String.format() was used for log4j to simulate what log5j does internally Log5j does not need String.format()
Info log with parameters not using String.format()	34202	52207	-
Info log without parameters	31684	30958

Conclusion

• Do not use String.format() with log4j, specially when that log level can be off in production (E.g. DEBUG is off in production). Its very expensive. 
• Log5j performs almost the same as Log4j even without any isLOGLEVELEnabled() (E.g. isDebugEnabled()) checks. Hence, it results in clean code without redundant log enabled checks. 
• Log5j provides a cleaner interface to log statements than Log4j (with a mess of appending variables within log text) with a small bearable overhead