I meant to write about this book when I first read it last year but I never got around to it and I’m happy that I finally got a chance after my second read this past Christmas break.

First of all, I never read a book twice and the fact that I read this one twice and enjoyed it both times is saying something. It has a ton of useful information and tips for any software developer but if I have to summarize, this book establishes three important points:

1. What does it mean for some piece of code to be clean?

The author establishes what it means for some piece of code to be clean. He shows snippets of code that work equally well but one is impossible to understand while other is much more intuitive and easy to follow, hence more maintainable. He explains why short functions, fewer arguments are better. He answers questions like why and how should you comment, how you should organize your code and why one is better than the other, why dependency injection is good, and so much more. Even if you don’t agree with everything he says, he makes you much more aware about your code and that’s invaluable by itself.

2. Why should you care about and spend time writing clean code?

You’d be surprised how many software developers think that just because some piece of code works, their job is done. They don’t see value in spending time to write clean code. For them, “cosmetic changes” are not really beneficial, code that works is good enough because they forget that they write code for others to understand. Thankfully, the author provides quite a few arguments to show why clean code matters, why code that just works is not good enough, and why “cosmetic changes” are not only beneficial but also necessary.

3. How can you write clean code?

Once you know what clean code means and the value of clean code, the author establishes some rules and guidelines to create clean and maintainable code all the time. He has a set of rules that he outlines in the last chapter as reference. Even though I don’t agree with all of them, it’s good to think about them and come up with your own versions. He goes through a real example and refactors it into clean maintainable code where you can see the benefits.

As software craftsmen, we all have a responsibility to write clean, maintainable, consistent code and this book makes you aware of your code like no other book I’ve read so far, a must-read book for anyone involved in software development.

Build on what you already know

I worked on a number of diverse client and server side features in 2011 and I was pleased to see that lessons I outlined in 2010 were very useful in keeping me focused and guiding me in the right direction throughout the year. For example, I was tasked with implementing a JavaScript/HTML5 client library for Data Services but the problem was that I didn’t really know JavaScript all that well. I tackled that by allocating enough time for research and prototype and in the end, we ended up with a great performing JavaScript library using Google Closure. Another example is specs. I made sure the specs of features I worked on were up to date all the time and in the end, I was pleased to see our documentation and QA teams had almost no questions for me about the features because everything was outlined in detail in the specs.

I know this sounds obvious but wisdom accumulates over time and learning new things should not come at the expense of forgetting what you already know. Keep good lessons around and keep building on them to get better at what you do.

Don’t get attached

2011 has definitely been an interesting and challenging year with Adobe’s announcement on Flash mobile, Flex/BlazeDS going to Apache and re-orgs. In the re-org, I got assigned to a new group with a new technology stack, so it’s been quite a learning experience and adjustment for me towards the end of the year. Announcements about Flash mobile and Flex definitely made a lot of people think about their choice of technology in their organizations/projects including myself.

One big lesson I learned is to never get attached to a particular technology or group. Technologies come and go and even though one might be better in something than others, no technology is better in everything, so it’s not wise to invest a lot of time in one technology at the expense of ignoring the rest because when the day comes for that technology to become obsolete (and it will happen), you don’t want to feel abandoned or lost. Similarly, you might be working on the most interesting project ever with the smartest people around but don’t let the daily grind fool you into thinking that you’ll do this forever. It’s always wise to think and plan for the next step in your career.

Treat tests as part of the product

Most of the times, “product” is thought to be what gets shipped to the customer but I think this is a mistake in software craftsmanship. What gets shipped to the customer is a small portion of what actually is needed to build something shippable. Without unit tests, integration tests, performance tests, documentation, build scripts, etc. it’s impossible to ship anything decent. By not treating these as part of the product, we often let them be at a lower standard than the actual product and that’s a mistake because tests eventually start rotting and that makes the actual product harder and harder to change and maintain. I suggest that we give tests the same amount of attention, dedication and time by considering them as part of the product and you’ll be surprised if you do.

One example is my Java client SDK. In 2011, I wrote a Java client SDK but this time instead of writing a few unit tests and handing it over to QA, I wrote a fully automated unit test suite that tested every single functionality of the SDK. It took time and effort to cover everything and make sure it runs fast and consistently but in the end, it paid off big time. Shortly after Java client SDK, we decided to work on an Android client SDK, then JavaScript/HTML5 client SDK, then Objective-C client SDK and we simply ported these tests to respective languages. Throughout the process, we ran into issues and it was extremely useful to have a fully automated, fast testing readily available for the whole team, developers and QA. If something needs to change in any of the clients now, we make the change with no fear because we know that there are solid unit tests behind us to make sure everything still works. Investing in testing pays off in ways that you can’t even anticipate so why not treat them as part of the product?

Just do it

I wanted to work on a side project and I spent a lot of time in 2011 to read on different technology blogs about different technology stacks, different RIA frameworks, different servers, different mobile development platforms etc. in order to find the right fit for my project. In the end, I learned a lot but I didn’t have anything tangible until late in the year when I actually started working on the project. Reading on things is definitely useful but it’s not as rewarding as actually building something. After I started to actually build my project, I realized that I’m learning more and I actually felt like I was doing something more tangible and useful, I was solving a real problem rather than reading up. So, my plan for 2012 is to read less, do more, and get more side projects finished because in the end, shipping quality software that solves something useful in some way is what matters.

Happy and prosperous 2012!

I’ve recently finished reading Richard Dawkins’ The Greatest Show On Earth book. It’s a book about evolution and I think everyone interested in evolution (either for or against) should read this book. Even if you don’t believe in the idea of evolution, the wealth and detail of scientific information he provides are well worth the read.

One thing that struck me about this book is that Richard Dawkins provided “unintelligent design” as evidence for evolution. He pointed out some major biological design flaws in various animals to conclude that an intelligent designer could not have designed those animals with those major imperfections. Therefore, somewhat random yet adaptable process must have produced that animal with those imperfections and made that animal survive up until today. The argument is very convincing and I don’t want to provide all the details to spoil the book for you, so go and read the book if you’re interested.

Now back to software development. I’ve worked at a number of companies and projects by now and in every project I worked on, I always came to the point where I questioned the design of the software in some shape or form. “Why did he design it this way?”, “Why is it so unnecessarily complex?”, or “This is so stupid” are some remarks that crossed my mind at one point. While some of these are valid concerns, they miss two crucial points.

First, there’s never a single designer in software development. In every project, there’s a bunch of developers and one or a few architects agreeing on a framework on how to solve a problem. But at the end of the day, what’s agreed is just a framework or a guideline, and it’s up to the individual developers to reflect that agreement into code. That can vary greatly from developer to developer and when one developer leaves the project, another developer with a different experience picks it up. So, every piece of code you look at will be influenced by an architect, implemented by one or a few developers, and tested by a quality engineer to further shape its design. There’s not a single designer that you can really blame.

Second, software development is not perfect. In Math, there are facts and there are proofs to support those facts. Even though there’s some flexibility involved in writing the proof, most of the times, the process is quite strict, you either have an agreed proof for something or not. Same goes with civil engineering. Your bridge either does its job of moving people from one side or another or not. There’s no middle ground. However, in software development, there’s quite a bit of middle ground. Two pieces of software that might work the same way can be implemented on totally different platforms in totally different ways. The digital nature of software development makes it very flexible but with that flexibility comes imperfections. An inexperienced or careless developer could easily make something work in an imperfect/non-optimal way and you end up with systems where things work ok but they are not perfect in the same sense as a mathematical proof is perfect. You end up with imperfect software that work just like you have imperfect biological organisms that survived up until today.

After reading this book, I found it quite useful to remind myself that software is very much like an evolving organism. There’s no single designer, there are imperfections but at the end of the day, it just works. So, instead of questioning the imperfections, blaming the non-existant single designer, and trying to upgrade every single piece of code to its theoretical perfection, I learned to embrace software for what it is today and add survival value for its next generation.

If you want to run the application yourself, here’s the zip file with the Java classes I mentioned in the video.

If you want to run the HTML/JavaScript chat sample, put Chat.html next to Chat.swf along with dataservices-client.js that’s under resources/client-sdk/javascript folder of DataServices installation.

If you want to run the sample yourself, here is the productRO.html file that I talked about in the video. Copy it where productRO.swf is along with dataservices-samples.js provided in resouces/client-sdks/javascript folder of DataServices installation.

1. Start the bundled Tomcat: From the terminal, go to “tomcat/bin” directory under where DataServices is installed and type “catalina.sh run” or “catalina.bat run” on Windows. After a few seconds, you should see something like this on console:

[Data Services] [WARN]  ******* Data Services Beta Expires on Dec 15, 2011 *******
Nov 3, 2011 9:07:54 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 37026 ms

2. Start the bundled HSQLDB: Go to “sampledb” folder and type “startdb.sh” or “startdb.bat” on Windows. After a few seconds, you should see something like this:

[Server@9d04653]: 2011-11-04 06:10:15.000 HSQLDB server 1.8.0 is online
[Server@9d04653]: To close normally, connect and execute SHUTDOWN SQL
[Server@9d04653]: From command line, use [Ctrl]+[C] to abort abruptly

3. Hit the landing page at http://localhost:8400/dataservices-samples/ and you should see the landing page:

That’s it! There are bunch of new and old samples. I encourage you to play with the “HTML5/JS, iOS, Android Client SDKs” samples, they are pretty cool!

In the next post, I’ll walk you through a Flex Remoting sample and then we will convert that sample to HTML/JavaScript utilizing our new JavaScript Client SDK.

The default setting in Android is to sync to all your Gmail contacts under “My Contacts”. This is a little annoying because anyone you ever emailed in Gmail gets added to “My Contacts” and I don’t like to sync all of those contacts to my phone. Since I don’t use Gmail, this wasn’t a big problem for me, so when I got my first Android device, I added my contacts that I phone regularly under Gmail manually and I had them all synced up nicely with my Android devices. So far so good.

The problem is that when you add someone to your circle in Google+, it also gets saved under “My Contacts” in Gmail contacts. I think it gets saved under “Other Contacts” but nevertheless, by default, you’ll get these contacts synced to your Android phone and that’s what happened to me. When I saw these Google+ contacts on my phone, I deleted them, thinking that I’m just deleting contact entries from my Gmail but actually I was effectively removing them from my Google+ circles. The other weird thing is that even though these Google+ contacts were under “Other Contacts” in Gmail, I couldn’t see them separately from “My Contacts” on my Android phone, so there was no way to not sync to these contacts.

So what did I do? First, I separated my contacts that I phone frequently under “My Phone Contacts” under “My Contacts”. That way, this list is separate from any other junk that might be added to “My Contacts” later. Then, I added people back to my circles and they in turn got added to “Other Contacts”. Finally, I changed my Android phone settings to only sync to “My Phone Contacts” and voila. I got my phone contacts on my phone and people stayed in my Google+ circles.

Everything is good now but I wish Google paid a little bit more attention to the workflow between Gmail, Google+, and Android. I think it’s weird that I can remove people from my Google+ circle by removing them from my Gmail contacts. To me, Google+ and Gmail are separate things. Anyway, in case you run into something similar, hopefully this post will provide you some understanding.