Nice review of logging frameworks for Java.

This is why we jump out of our skin every time you tap us on the shoulder.

Lots of people confuse “test first methodologies” with TDD, it is very common to listen comments like “TDD is just about writing your tests first”, which are completely wrong, these kind of affirmations are not describing TDD at all, they are talking about test first development.

Not too long ago Google announced their new experimental, open source, system language which was said to be a mix of Python and C called Go. Immediately the internet super highway’s lights lit up and the news spread like wild fire. Comments came from all over and besides the news that another language with the same name already existed, the enthusiasm did not let up. Writing the odd ‘Hello Go’ program or dabbling with the syntax is all well and good but, until you sit down and write something a tad more useful, you do not really get to know whether a new language holds any promise. I learned about a Twitter client written in Go and asked it’s author Dmitry Chestnykh to share his experience.

After RubyConf 2006, I realized that Ruby was not on the right track for me. I went searching for a new language. I've been a JVM guy since '96, so finding a language that was as on the JVM was a plus for me. I was looking for a statically typed language with high performance, but with the syntactic economy of Ruby. I bounced around a couple of language listing sites and found Scala. Three years ago, I fell in total love with Scala. That love continues today. What is Scala to me?

When I am not coding I am reading about code. Here is a short list of memerable programming quotes I read over the past year about the science and art of software development. Over this last year, my interest and reading habits have been related to software development, team leadership, and entrepreneurship and this quotes reflects those topics.

Gerrit, a Git-based system for managing code review, is helping to spread the popular distributed revision control system into Android-using companies, many of which have heavy quality assurance, management, and legal processes around software. HTC, Qualcomm, TI, Sony Ericsson, and Android originator Google are all running Gerrit, project leader Shawn Pearce said in a talk at the October 2009 GitTogether event, hosted at Google in Mountain View. The Gerrit story starts with the progressive escape of an in-house Google process and tool. Google requires code review for any change to company code or configuration files; there are a few exceptions, but those are subject to review after deployment. The code review process started out using lots of email, but for the past several years it has been automated. When Guido van Rossum, creator of the Python language, began working at Google in 2005, he started developing a tool, in Python naturally, to coordinate code reviews. The result, called Mondrian, lets users view the proposed change as a side-by-side comparison, and participate in comment threads attached anywhere in the code under review. An overview page shows a to-do list of incoming changes to review and reviewers' comments. Van Rossum presented Mondrian at a public talk in 2006.

This is a detailed post explaining the reasons high groth of Orkut in India and why Facebook has now started gaining share in India. A must read for any one remotely interest in social networking.

Those of you who've seen me speak on Java 7 at various conferences have heard me lament (in a small way) the fact that Sun decided last year (Dec 2008) to forgo the idea of including closures in the Java language. Imagine my surprise, then, to check my Twitter feed and discover that, to everyone's surprise, closures are back in as a consideration for the Java7 release.

As humans we seem to have an innate desire for structure in our lives. Structure permeates through our societies; it’s found within our families, education systems, governments, etc. I suppose it’s no surprise then that we also seek to force structure upon the work that we, as software developers, do. The problem is the work we do isn’t structured. It is not deterministic. There is no grand blue print, process, nor methodology that we can follow to pay dirt. We live in a chaotic and complex world that is itself continuously changing and adapting. Software product development is a creative activity taking place in the midst of that complex and adaptive world. So doesn’t it make sense that we, as software developers, might benefit from admitting that we are indeed doing creative, unstructured, adaptive work? I sure think so!

I recently survived a massive lay-off at work. The experience marked me so I decided to write about it for the cathartic effect. When I graduated from Software Engineering, I was ready to take on the world. I noticed a job posting for a Python job and was intrigued by it. I like playing around with dynamic interpreted languages and thought this might be a good place for me to work. The interview went extremely well and we had a pleasant discussion about software architecture. The team lead and senior programmer who interviewed me were enthusiastic, friendly and had a compelling vision of their software system. One detail they revealed was that they had built it to load all objects into memory. This sounded like a horrible idea to me, I told them they might have trouble scaling this architecture. They reassured me that this wasn't a problem as the system ran smoothly. The interview went so well that I was offered a position the following morning.

Before we talk about Cloud, I want to quickly review where SOA came from. Most of us who started our IT careers in the 80s and 90s will clearly remember the pre-web Enterprise environment. Of course, so will everyone else - because that legacy is still with us. The typical systems were monolithic, complex applications that were completely self-reliant. Any interfacing with other systems was done through batch dumps. Applications grew and grew and grew into monsters because the only option was to enlarge the application - inter-application connectivity was too complex and unreliable to envisage.

Of the new languages that are emerging these days, no two are as interesting as Scala and Clojure. Both claim to be functional and geared for concurrency, one is a Lisp the other a Curly braces language. On paper, they stack fairly well against each other, so let’s investigate how well they are suited for business.

I’ve always been distrustful by default with the “main way of thinking”. Which doesn’t mean that I systematically reject the opinion of the majority. But given the strong tendency of human beings towards laziness and our natural tendency to sheep-like behaviour, the faster something gets popular, the more I question it.

A good discussion about the deployment problems developer face with python apps independent of the target platform.

I've been travelling, at three conferences in three weeks. At some point during these weeks, a few people asked me, "What's the difference between a technical lead and a first line manager?" Given their job descriptions, which include helping people manage their careers, seems to me that the answer is $10,000-$20,000. That is, the technical lead was being paid less, but doing the same work as a manager.

You’ve worked hard looking for a freelance project. Finally, it looks like all of your hard work is about to pay off. Someone offers you a freelancing gig. Now it’s time to breathe a huge sigh of relief and dig into the project. Right?