Monday, February 26, 2007

Something about try... catch...finally

The screencast below explains using finally with try..catch. Click on the 'Start' button to start playing the movie.

Thursday, February 22, 2007

Understanding the Java Exception heirarchy

In the previous section, we learned how to use custom exceptions. We also created a custom exception by subclassing java.lang.Exception. Let us now understand the Java exception hierarchy in greater detail.

Play the audio to listen to an explanation of the java Exception class hierarchy.

Understanding java.lang.error

The video below shows how the JVM can throw an Error for an irrecoverable problem. Click on the 'Start' button to start playing the movie.

Understanding RuntimeException

The video below explains runtime exceptions. Click on the 'Start' button to start playing the movie.

Friday, February 16, 2007

Google group for Adaptive Learning Online

I have just created a Google group for this blog.

We can use it to discuss individual posts, or other things related to software design, programming best practices and models of continuous learning for software professionals. 

I look forward to having interesting and invigorating conversations that lead to learning and benefit one and all.

Note: This text was originally posted on my previous blog at

Coding dojo - Dictionary

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 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 people found the exercise a bit simple and said they would prefer to deal with more complex topics like "web based development" and "Enterprise Java". Some participants would have prefered a greater time duration.

Thanks to all the participants for your feedback. I will try and incorporate your suggestions in forthcoming dojo sessions. 

Please stay tuned if you would like to participate in the  next open dojo. I will announce it here as soon as soon as the date is finalized.

Note: This text was originally posted on my earlier blog at
Here are the comments from the original post

AUTHOR: Freeman Murray
DATE: 05/15/2007 05:12:55 AM
This is great !! When is the next one ?
DATE: 05/15/2007 06:01:16 AM
Hello Freeman,

Thanks for your comment and interest in the coing dojo. I do plan to have an open registration dojo again, but have not yet been able to set a date.

I will announce it on this website as soon as I am able to schedule it.


Wednesday, February 14, 2007

Custom Exceptions

Till now we have seen why we need Exceptions and how to manage code that could throw Exceptions. We still have not learned how to throw our own Exceptions. Let us first understand the code below.

01 public class DocToPdfConverter {
02   public void convert(String src, String des) {
03     Document doc = readDoc(src);
04     writePdf(doc, des);
05   }
07   private Document readDoc(String srcPath) {
08   //read the source file and verify format
09   //if format is incorrect then throw an Exception
10   }
12   private void writePdf(Document doc, String des) {
13     //convert the document into pdf
14   }
15 }


01 public class DocToPdfConverter {
02   public void convert(String src, String des) {
03     Document doc = null;
04     try {
05       Document doc = readDoc(src);
06       writePdf(doc, des);
07     } catch(InvalidFormatException ife) {
08     //print error msg for user
09     } catch(IOException ioe) {
10     //print error msg for user
11     }
12   }
14   private Document readDoc(String srcPath) throws InvalidFormatException, IOException {
15     if(!verifyFormat(srcPath)) {
16       throw new InvalidFormatException("The file " + srcPath + "is not a valid word file");
17     }
18     Document document = convertDocToOM(srcPath);
19     return document;
20   }
22   private void writePdf(Document doc, String des) {
23     //convert the document into pdf
24   }
26   private Document convertDocToOM(String srcPath) {
27     //code
28   }
29 }


1 public class InvalidFormatException extends Exception {
2   public InvalidFormatException() {
3     super();
4   }
6   public InvalidFormatException(String msg) {
7     super(msg);
8     }
9 }


Notes: This text was originally posted on my previous blog at

Sunday, February 11, 2007

Sharpen your programming skills

Dave Thomas the author of “The Pragmatic Programmer” says:

How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes practicing; applying the theory over and over again, using feedback to get better every time.

How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and hours every day, practicing.

But in the software industry we take developers trained in the theory and throw them straight in to the deep-end, working on a project. It’s like taking a group of fit kids and telling them that they have four quarters to beat the Redskins (hey, we manage by objectives, right?). In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.

Laurent Bossavit says:

If I want to learn Judo, I will enroll at the nearest dojo, and show up for one hour every week for the next two years, at the end of which I may opt for a more assiduous course of study to progress in the art. Years of further training might be rewarded with a black belt, which is merely the sign of ascent to a different stage of learning. No master ever stops learning. If I want to learn object programming... my employer will pack me off to a three-day Java course picked from this year's issue of a big training firm's catalog. Nuts to that – acquiring coding skills is not an “instant gratification” process. This workshop proposes to discover a way of teaching and learning programming in a more appropriate manner, respecting the depth and subtlety of the craft.

What do they have in common? Both emphasize the importance of practicing the art of programming. Dave Thomas pioneered the concept of coding katas. In his own words:

Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer. I add a new kata every week or so. Invest some time in your craft and try them.

Dave Thomas' code katas were originally intended as individual exercises that a developer does by himself or herself. Even though these exercises are very useful for individual learning, Laurent Bossavit proposed a similar form for groups, which he called coding dojos. Laurent's dojos are extremely popular in Paris. Even Uncle Bob (Bob Martin) has written good things about them.

I have personally conducted dojos for corporates as well as students, and have found them to have immense potential for transfer of knowledge. I normally do them for groups of 4 – 16 participants.

The dojo happens in a room with a computer and projector. We start with an explanation of the problem followed by a quick design discussion, followed by programming. The programming is done in pairs, beginning with the first pair taking a seat near the computer. The remaining participants watch what is being programmed on the projector screen. The audience is a participative audience, that is, they ask questions to the programming team and even offer alternatives. It is the responsibility of the programming team to convince the audience that the code they are writing is appropriate. During this, as a facilitator and coach, I moderate the discussions, ensuring that they enable the programming process, not detract from it. I also spark of mini discussions on design issues and make programming best practice suggestions. Along with this I also transfer relevant knowledge periodically. So, if someone is coding a List, I might take the opportunity to talk about different types of Lists in the Java collections library, and their pros and cons. Other things that may come up are various Java API's, threading, performance, programming and design best practices, and JDK 1.5 features (generics, autoboxing, and annotations). The knowledge that I can transfer depends on the dojo topic and the experience level of the participants. However there are plenty of opportunities and the information is very well received, since it is in the context of a practical example. This is the real strength of the dojo. The participants improve their programming skills, increase their knowledge of the language, of design and also learn a lot of other theory all within the context of some practical examples. Coming back to the dojo, each pair programs for 20 minutes after which another pair replaces them... and so forth for the duration of the workshop. An important aspect of the programming process, is that the programming team must speak continuously while they are programming, so everyone else understands what they are doing. I think this will also help them clarify their own thoughts and help them overcome obstacles.

Exercises can be specifically created to address particular learnings needs. Dave Thomas and Bob Martin also have some sample exercises:

Coding dojos have been conducted in other languages such as Ruby by Future Platforms. The Agile Finland group also conducts regular dojos. The fact that Dave Thomas has a dedicated blog for his katas attest to their growing popularity.

Whether it is dojos, or katas, or some other form of practice, I would like to urge every software developer to spend at least some time practicing and fine tuning their programming skills. The easiest way to get started is by yourself, but a fun way would be get together with some buddies and do a self-organizing dojo.

If you find the concept of coding dojos interesting and stay in Pune, you might want to attend the open dojo I am conducting on 17th February, Saturday, in Pune. The details and the registration page are here.

Notes: This text was originally posted on my earlier blog at

Sunday, February 04, 2007

Managing exceptions

When we call a method that can throw an Exception, handling the Exception is not the only option we have. We can also propogate the exception. The audio and code shown below explains this concept.


public class AnExceptionalDilemna {
  public static void main(String args[]) {
    AnExceptionalDilemna aed = new AnExceptionalDilemna();
    System.out.println("Hello, this is a test program to
    understand Exceptions");
    try {
      System.out.print("Please enter your name: ");
      String name = aed.getNameThroughMiddleMan();
      System.out.println("Hey "+name+" how are you doing?");
    } catch(IOException ioe) {
      System.out.println("Looks like the standard input
      stream does not like you!");

  /*Do I handle or propogate IOException?
  I do not know what to do with it...
  so I guess I will just pass the buck*/
  private String getNameThroughMiddleMan() throws IOException{
    String name = getName();
    return name;

  private String getName() throws IOException {
    BufferedReader br = new BufferedReader
    (new InputStreamReader(;


Thursday, February 01, 2007

Refactoring To Patterns

I learned design patterns when I was in grad school. Later when I started work, I used some patterns, but some were never used, and their knowledge became rusty over the years. I thought it was time to refresh my knowledge of software design patterns, sometime last year.

Back then I was enamoured with the concept of web based learning (and I still am). I was also contemplating to take my Java workshops over the Internet. So instead of just re-reading the GOF book, I thought of taking a web based course on design patterns. This way I would learn what I needed to, and also get a hands on feel of how elearning works. When I Googled elearning and design patterns, I stumbled upon Industrial Logic's online course "Refactoring to patterns". Now the concept of refactoring to patterns is'nt just about learning design patterns. It involves understanding design patterns, but also involves identifying code smells (bad code), that should be refactored to use a design pattern. I was delighted. This course would not only help me refresh design patterns but also teach me something new. I registered for it.

I found the course to be very well made. The explanation of each design pattern started with some reading suggestions, typically from the GOF book and Joshua Kerievsky's excellent book - "Refactoring to patterns". After that there was a little conversation on that design pattern. This is really good, because after reading the text, I had many questions in my mind, and they were all answered by reading the conversation (which I am presuming Joshua must have had with participants of his course). Now that the theory had sunk in, the next step was to understand some code and refactor it to use the pattern. I could verify my solution by running the tests. The interesting thing here is that the tests not only verify that the code still works properly, but also verify if the refactoring uses the design pattern correctly. These tests make many assumptions, but they are very well written and do verify the solution correctly. Once you are done you can upload the solution. The course also has screencasts for the refactoring if you need any help. Finally there are some questions to reinforce the concepts.

I still have not completed all the patterns in the course, but have had a great learning experience with the stuff that I have completed.

In time to come web based learning will provide an excellent way for people to update their knowledge at a time, place, and pace of their convinience. The ability of the Internet to serve multimedia and enable collaboration is extremely powerful. I think we are just begining to scratch the surface if this potential for educational applications. The social web and the web of participation will bring several changes to the way we teach and learn. We will see many interesting eLearning content come up in future. Also, be on the lookout for educational podcasts and screencasts.
BTW, this is NOT a sponsored/paid post! ;-)

Notes: This text was originally posted on my earlier blog at