Adaptive Software Solutions

Sometime in 2005 I created a website to share practical information on software programming and design. The idea was to share practical programming tips, best practices, howtos, gotchas, etc. The material would come from what I learn writing actual code, and the medium to share it would be a blog, audio, and screencasts. I started this venture with the intention of doing something I enjoyed, and generating revenue. The website grew steadily, though very gradually. After about a year and a half I had about 27,000 page hits a month, and a few comments per post. I know it is very modest, but I believe it was at a point where it would have grown much more rapidly form there on. But due to various reasons, I was not able to dedicate enough time to working on the website, and eventually I shut it down. Even though I shut down the website sometime last year, the desire to be able to work on open source software (that has a social impact), share information, and generate revenue from it, pers...

In the previous post we saw how subclassing from a class not designed for inheritance, can be dangerous. Using composition instead of inheritance would have solved the problem. But what was the crux of the problem? Could such a trap have been avoided? Could AbstractCollection have been implemented so that such a situation would not have arisen in the first place? The real problem was the class AbstractCollection which was not designed properly for inheritance. It is a non-final class with a public method addAll(Collection c) which invokes another non-final public method add(Object o) . How should AbstractCollection have implemented add(Object o) and addAll(Collection c) to prevent such a problem? I do not know if this problem has been fixed in OpenJDK. They may have not been able to do so to maintain backwards compatibility. You can check out the sources from their website . In the next post we will discuss an idiom for preventing such a situation.  Discuss this post in the...

Yesterday, I posted about simple coding conventions. Following good coding conventions is like keeping your car keys in the same place everyday. If you always keep them in the same place, you as well as other's in your house will be able to find them easily. However, if you keep them in some random place, everyone is going to have a hrd time finding them, resulting in unproductive time. Staying with the car analogy, imagine what would happen if different cars had their brake pedal in different places. The reason why we are easily able to drive different cars with ease is because we where to find the things we need to drive the car. It's important that you follow some coding convention. It could be a homegrown convention for your company. It's ok, but, other people may have a hard time understanding your code. Not just other people, but your own developers who have recently come from other companies will also have to learn your coding conventions. To elliminate such problems...

I conducted an Open registration coding dojo in Pune, last Saturday. This was a short four hour dojo. The topic for the dojo was Dave Thomas' Kata Eight . As always we started with a discussion and design session and started coding. As we worked on the solution, several interesting learning opportunities came up: Designing for readability Using the decorators in Java's IO library Using various collection classes and understanding their performance characteristics Iterating through collections using an Iterator (we will also touch upon the Iterator design pattern) Design tradeoffs to make code faster Various coding conventions Some programming best practices Refactoring support in Eclipse Many thanks to ITVidya.com for organizing the dojo and to Pune IT Labs for hosting it.  Participants feedback showed that everyone though coding dojos offer a much better learning mechanism than traditional lectures. Everyone enjoyed the practice oriented approach. Some pe...