Wednesday, May 30, 2007

Tracing algorithms

Before we understand what tracing algorithms are, we must first understand the meaning of the phrase “root set of references”. Essentially the root set of references are those references that are always accessible to an executing Java program. They constitute local variables, method arguments, class variables, and instance variables.

When triggered, tracing algorithms mark all objects on the heap that can be traced from the root set of references. These are objects that are directly or indirectly referenced by the root set. Let's consider these to be live objects. This forms the mark phase of the tracing algorithm. The mark phase is followed by a sweep phase, in which all objects that were not marked in the mark phase are garbage collected. Because of it's two phases, this type of tracing algorithm is also known as “mark and sweep” algorithm.


  • Can detect and handle cycles


  • The heap is fragmented, ater the sweep phase.

Having a fragmented heap will prevent us from making optimum use of the heap memory. To eliminate this problem, the mark and sweep algorithm has been modified into a compacting algorithm. We will discuss compacting algorithms in the next post.

Discuss this post in the learning forum.

Commercial Links

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

Sunday, May 27, 2007

Reference counting algorithms

Early JVM's used reference counting to determine objects no longer in use. In reference counting, an objects reference count is initially set to one when it is instantiated and it's reference is assigned to a variable. Every time a reference of that object is assigned to another variable, the count is incremented by one. When a variable holding the reference goes out of scope, the count of the object is decremented by one. An object is eligible for garbage collection when it's reference count becomes zero.

Let's see how reference counting algorithms work, with a simple animation.

Right click in the region below and select 'play' to start the animation.


  • It is very simple to implement.

  • The JVM does not need to be paused when the garbage collector is running.


  • There is an extra overhead since the reference count of objects needs to be updated very often.

  • Cannot detect cycles.

A cycle is formed when two objects point to each other. Even if both these objects are not used anywhere else, they will not be garbage collected since their reference count is one.

Some of the disadvantages of reference counting algorithms are handled by tracing algorithms.

Discuss this post in the learning forum.

Commercial Links

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

Thursday, May 24, 2007

Garbage collection in Java

I am starting a series of posts on the Java garbage collector and various garbage collection algorithms. Over the 10 days or so, we will examine the Java garbage collector and garbage collection algorithms. Let's begin with a brief introduction.

An executing program occupies memory. Memory is taken as new objects are created. This memory should be returned when these objects are no longer needed. If it is not, then the computer will soon run out of resources, forcing the program to a halt. In C++ we have to explicitly return an object's memory back to the system when the object is destroyed. This is also the source for many bugs in C++. Buggy code that does not return memory can very soon exhaust system resources. To eliminate such errors, and make your program more robust, Java has adopted the philosophy of automatic memory reclamation. The JVM determines when an object is no longer needed (Eg: after the variable goes out of scope), and automatically reclaims memory occupied by that object. Objects no longer needed are known as 'garbage', because; well that is what we call things we no longer need, right? Hence reclamation of un-needed heap (Java objects are always created on the heap) memory is known as garbage collection in Java.

The JVM runs the garbage collector as a background thread, which constantly monitors the heap. The exact mechanism of reclaiming memory is JVM specific. The Java Language Specification (JLS) does not mandate any particular mechanism for garbage collection, hence it is implemented by the JVM creator.

There are several well known garbage collection algorithms that are implemented by modern JVM's. Each has pros and cons in terms of memory usage and performance. Some of these algorithms are:

  • Reference counting algorithms

  • Tracing algorithms

  • Compacting algorithms

  • Copying algorithms

  • Generational algorithms

  • Adaptive algorithms

In the next post we will discuss "Reference counting algorithms"

Discuss this post in the learning forum.

Commercial Links

Tuesday, May 22, 2007

Garbage collection example

A Java program can request the underlying JVM to perform garbage collection by calling the gc() method of the System class.

Note that System.gc() is a request to the underlying JVM. Garbage collection may not always happen. Hence we cannot depend on this method, however we can use it to optimize performance, with the understanding that it may not work as desired on all JVM's.


Study the program shown below. It ilustrates how we can invoke the garbage collector from a Java program.

01 /** This program creates instances of Bag objects in a loop which will run 100000 times.
02  * Whenever the program is in a loop that is a multiple of 1000, it requests the JVM
03  * to start the garbage collector. We will see that the JVM may not always fulfill the
04  * request.
05  */
06 public class GarbageCollectionDemo {
07   public static void main(String args[]) {
08     //loop 10000 times
09     for(int i=0;i<10000;i++) {
10       //if this loop is a multiple of 1000, then request for garbage collection
11       if(i%1000 == 0) {
12         System.out.println("Requesting for garbage collection");
13         System.gc();
14       }
15       System.out.println("Creating bag " + i);
16       Bag b = new Bag(String.valueOf(i));
17     }
18   }
19 }
21 /** A placeholder object that is created in GarbageCollectionDemo
22  *
23  */
24 class Bag {
25   private String id;
26   public Bag(String id) {
27 = id;
28   }
30   /**We override the finalize method and put a print statement
31    * which will tell us when the object was garbage collected.
32    */
33   public void finalize() {
34     System.out.println("Garbage collecting bag " + id);
35   }
36 }

Here is the output of the program. Since the output was very large, I have truncated most parts (which have been shown as dots ...). As is shown, we request for garbage collection after creating 999 objects [line 11]. The JVM complies and garbage collects all unused objects. Also note that the garbage collector again starts reclaiming objects on line 32, even though the program has not specifically asked for it to do so. It may have done so either because it ran short of resources (but that seems unlikely because the garbage collector had just freed resources some time back), or it was run in the normal course of the garbage collection algorithm (this seems more likely).

Now this JVM is really well behaved, it fulfills all our garbage collection requests, but do not take this behavior for granted. All JVM's may not be as well mannered.

02 Requesting for garbage collection
03 Creating bag 0
04 Creating bag 1
05 Creating bag 2
06 Creating bag 3
07 Creating bag 4
08 Creating bag 5
09 ...
10 Creating bag 999
11 Requesting for garbage collection
12 Garbage collecting bag 999
13 Garbage collecting bag 998
14 Garbage collecting bag 997
15 Garbage collecting bag 996
16 Garbage collecting bag 995
17 ...
18 Garbage collecting bag 5
19 Garbage collecting bag 4
20 Garbage collecting bag 3
21 Garbage collecting bag 2
22 Garbage collecting bag 1
23 Garbage collecting bag 0
24 Creating bag 1000
25 Creating bag 1001
26 Creating bag 1002
27 Creating bag 1003
28 ...
29 Creating bag 1452
30 Creating bag 1453
31 Creating bag 1454
32 Garbage collecting bag 1454
33 Garbage collecting bag 1001
34 ...
35 Garbage collecting bag 1228
36 Garbage collecting bag 1226
37 Garbage collecting bag 1227
38 Creating bag 1455
39 Creating bag 1456
40 ...
41 Creating bag 1998
42 Creating bag 1999
43 Requesting for garbage collection
44 Garbage collecting bag 1999
45 Garbage collecting bag 1998
46 ...
47 Garbage collecting bag 1456
48 Garbage collecting bag 1455
49 Creating bag 2000
50 ...
51 Creating bag 2813
52 Creating bag 2814
53 Garbage collecting bag 2814
54 Garbage collecting bag 2000
55 Garbage collecting bag 2813
56 ...
57 Garbage collecting bag 2413
58 Garbage collecting bag 2401
59 ...
60 Garbage collecting bag 2407
61 Creating bag 2815
62 Creating bag 2816
63 Creating bag 2817
64 ...
65 ...
66 ...
67 Creating bag 9872
68 ...
69 Creating bag 9999

Adaptive algorithms

Adaptive algorithms do not use any fixed algorithm for garbage collection. They monitor the heap and choose an algorithm that is most effective for the current usage pattern. Such algorithms may also divide the heap into sub heaps and use a different algorithm for every sub heap, depending on the usage.

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

Generational algorithms


Generational algorithms make use of a property found in most Java programs. Several studies have revealed a pattern in the way objects are used. It has been found that objects that get created early in program execution usually live longer than objects that get created later. It is usually the youngest objects that are garbage collected first.


Look at the diagram below. The blue area in the diagram is a typical distribution for the lifetimes of objects. The X axis represents the bytes allocated by the JVM, and the Y axis represents the number of surviving bytes (live objects). The sharp peak at the left represents objects that can be reclaimed (i.e., have "died") shortly after being allocated. Iterator objects, for example, are often alive for the duration of a single loop.


If you notice, the distribution stretches out to the the right. This is because some objects live longer. Typically these are objects that have been created when the program started, and they live for the duration of the program. The lump observed after the first drop represents those objects that are created for some intermediate process. Some applications have very different looking distributions, but a surprisingly large number possess this general shape. The diagram above shows that most objects have a very short life span. Generational algorithms take advantage of this fact to optimize garbage collection in the JVM.


Generational algorithms divide the heap into several sub heaps. As objects get created, they are put in the sub heap that represents the youngest generation. When this area becomes full, the garbage collector is run and all unused objects in that sub heap get garbage collected. Objects that survive a few garbage collection attempts are promoted to a sub heap representing an older generation. The garbage collector runs most frequently in the younger heaps. Each progressively older generation of objects get garbage collected less often.

Generational algorithms are very efficient because they make use of certain well known properties of Java programs. Sun's Hotspot VM uses a modified form of generational algorithms. However, please note that this algorithm will not work efficiently with programs that make non-standard use of memory. We may configure the algorithm to work appropriately with such programs if we understand their memory usage well. If not, it is best to keep the default implementation.


Discuss this post in the learning forum.

Subscribe to this blog's feed


Commercial Links


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

Copying algorithms

Copying algorithms are tracing algorithms that divide the heap into multiple regions; one object region in which objects are created, and one or more free space regions [which are ignored, ie. objects are never created in these regions]. When the object space becomes full, all live objects are moved to the free space. Now the free space becomes the object space, and the old object space becomes the free space. Since objects are placed contiguously in the new region, holes [fragments] are not formed.

The most commonly used copying algorithm is known as stop and copy, which uses one object region and one free space region. When the object region becomes full, the [Java] program is paused until live objects are copied into the free space. The program is restarted after the copying phase.

Copying algorithms have an advantage over compacting algorithms in that the address of object references does not change when the objects are moved.

Discuss this post in the learning forum.


Commercial Links


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

Deciding what to log

In this section we will discuss what to log and the various levels at which we can generate log statements.

Even though I have mentioned that we should generate log statements when control enters and exits a method, this is a rather controversial point. Especially generating log statements on exiting; because a method could have multiple exit routes. What do you think? I would say, if in doubt - do NOT generate logs when exiting a method. Logs that show control has entered a method do have value in my personal opinion, however you can leave those out as well if you do not see much value in them.

Let me first draw your attention to the output from last page.

0 [main] DEBUG LoggerTest - Entering main
453 [main] DEBUG LoggerTest - Exiting main

What is DEBUG? As I have explained, we should log several events from our program as it executes. But all events are not equally important. Hence, Log4J supports six levels for logging, where each level is appropriate for a certain type of log statement. The levels are (starting from the most severe) FATAL, ERROR, WARN, INFO, DEBUG, and TRACE. Log4J also allows us to dynamically (through a configuration file) filter logs below a certain level. This way we can generate logs only for events that have a priority of WARN or higher and turn on the lower levels when there is a problem, due to which we want to see all the generated log statements.

This tutorial on JBoss does a very good job of explaining logging conventions in JBoss. I have excerpted the part that explains different logging levels below.

FATAL - Use the FATAL level priority for events that indicate a critical service failure. If a service issues a FATAL error it is completely unable to service requests of any kind.
ERROR - Use the ERROR level priority for events that indicate a disruption in a request or the ability to service a request. A service should have some capacity to continue to service requests in the presence of ERRORs.
WARN - Use the WARN level priority for events that may indicate a non-critical service error. Resumable errors, or minor breaches in request expectations fall into this category. The distinction between WARN and ERROR may be hard to discern and so its up to the developer to judge. The simplest criterion is would this failure result in a user support call. If it would use ERROR. If it would not use WARN.
INFO - Use the INFO level priority for service life-cycle events and other crucial related information. Looking at the INFO messages for a given service category should tell you exactly what state the service is in.
DEBUG - Use the DEBUG level priority for log messages that convey extra information regarding life-cycle events. Developer or in depth information required for support is the basis for this priority. The important point is that when the DEBUG level priority is enabled, the JBoss server log should not grow proportionally with the number of server requests. Looking at the DEBUG and INFO messages for a given service category should tell you exactly what state the service is in, as well as what server resources it is using: ports, interfaces, log files, etc.
TRACE - Use TRACE the level priority for log messages that are directly associated with activity that corresponds requests. Further, such messages should not be submitted to a Logger unless the Logger category priority threshold indicates that the message will be rendered. Use the Logger.isTraceEnabled() method to determine if the category priority threshold is enabled. The point of the TRACE priority is to allow for deep probing of the JBoss server behavior when necessary. When the TRACE level priority is enabled, you can expect the number of messages in the JBoss server log to grow at least a x N, where N is the number of requests received by the server, a some constant. The server log may well grow as power of N depending on the request-handling layer being traced.

Discuss this post in the learning forum.

Commercial Links

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

Friday, May 18, 2007

Log4j's configuration file

Log4J configuration file

# Set root logger level to DEBUG and its only appender to A1.
log4j.rootLogger=DEBUG, A1

# A1 is set to be a ConsoleAppender.

# A1 uses PatternLayout.
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c - %m%n


01 import org.apache.log4j.*;
02 public class LoggerTest {
04   static String category = LoggerTest.class.getName();
05   static Logger logger = Logger.getLogger(category);
06   static {
07     PropertyConfigurator.configure("");
08   }
10   public static void main(String args[]) {
11     logger.debug("Entering main");
12     System.out.println("Hello World");
13     try {
14       Thread.sleep(450);
15     catch(Exception e) {
16       System.out.println("caught Exception: " 
17           e.getMessage());
18     }
19     logger.debug("Exiting main");
20   }



0     [main] DEBUG LoggerTest - Entering main
453 [main] DEBUG LoggerTest - Exiting main

Discuss this post in the learning forum.

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



Commercial Links

Wednesday, May 16, 2007

Initializing Log4j


In the next post I will describe a log4j configuration file. 

Discuss this post in the learning forum.

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



Commercial Links


Thursday, May 10, 2007

Log4j an introduction

Log4J is a logging library that helps us create log statements that are way more powerful than System.out.println("...").

  • Log4J messages can be formatted with a timestamp, source, and many other things.
  • The Log4J system is initialzed using a property file, which determines the destination, and formatting of the log messages.
  • Log messages can be selectively turned on/off by modifying the property file.


Here is Log4J's documentation page. It has a very good introduction and a wiki

Discuss this post in the learning forum.

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



Commercial Links


Wednesday, May 09, 2007

Generating log statements from your application

In most software applications, control passes through complex code while users use the system. For large applications it is very important to keep track of where control is passing through in the application, if any exceptions are being thrown and what actions are being invoked by the user. Keepingtrack of these things help in maintaining an audit log and also in debugging the system if it fails at any point.

In this section we will understand why we should not use System.out.println() and we will also understand how to use a very good open source alternative called Log4J.

When you write small programs and run them, how do you keep track of where your program is passing control? How do you debug your program if it does'nt work properly? Most likely the answer is:

System.out.println("some message");

This is the most common way to debug and track a small program, but it is also a flawed approach.

  • It is cumbersome to print the source of the message.
  • It is cumbersome to print a timestamp with the message.
  • We cannot associate different levels with message.
  • We cannot direct the message to different locations.
  • We cannot selectively turn of logging based on source or level.

These factors are not very important for small assignments, but they gain a lot of importance for industrial code, which may send out thousands of log statements that are used not only for debugging, but also for auditing.

Traditionally most companies used to create their own logging libraries, which they used in their software. But this is such a waste. All companies end up making almost the same kind of library, and all of them maintain it for the same reasons.

Log4J, is an open source logging library, that helps us achieve all the above points and more. In the next few posts I will write about how to use Log4J to incorporate logging in your applications.

Even though I speak about Log4J, Java has a standards compliant logging library bundled with the JDK, and the Jakarta Commons Logging framework can call into both Log4J as well as Java Logging API's.

Discuss this post in the learning forum.

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



Commercial Links

Tuesday, May 08, 2007

Resources for coding conventions

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, it is best to follow a standard set of coding conventions that everyone follows.

Here's a link to the a document published by Sun for Java coding conventions.

Those who wish to automate the process of checking for any violations, can do so with Checkstyle


Discuss this post in the learning forum.

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



Commercial Links

Monday, May 07, 2007

Commenting your code

Comments are an integral part of any program, even though they do not contribute to the logic. Appropriate comments add to the maintainability of a software. I have heard developers complain about not remembering the logic of some code they wrote a few months back. Can you imagine how difficult it can be to understand programs written by others, when we sometimes find it hard to understand our own code. It is a nightmare to maintain programs that are not appropriately commented. Java classes should contain comments at various levels.
There are two types of comments; implementation comments and documentation comments. Implementation comments usually explain design desicisions, or a particularly intricate peice of code. If you find the need to make a lot of implementation comments, then it may signal overly complex code. Documentation comments usually describe the API of a program, they are meant for developers who are going to use your classes.
All classes, methods and variables should have comments inserted in the source code at appropriate places. Comments should follow Javadoc standards so that we can generate separate API documentation from the source files without extra effort. Remember that commenting appropriately means neither over-commenting nor under-commenting.

The screencast shown below explains how I had commented a Java program I wrote several years back. The animation will automatically start buffering. Click on the square on the right hand side in the controls to display the movie, and then the play button to start the movie.

Discuss this post in the learning forum.

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



Commercial Links

Tuesday, May 01, 2007

Online, peer-taught, outcome-based, and instructor-facilitated teaching

From some time I have been thinking of the right way to teach a programming course. Something I have noticed from the way I learn, as well as by having taught Java to college students and corporate participants, is that programming is not learned well if it is detached from practice and discussion. In fact, practice and discussion are the most important aspects of learning how to program. Here are some numbers from the National Training Laboratories, Maine, USA, that point to how retention rates differ for different learning approaches.

Research shows that discussion, practice, and teaching are the most effective ways to learn. My own learning experience also validates this finding. When I simply read about a programming technology, I might forget it in a few days, but when I practice it, the learning remains with me for longer, and when I teach something, I retain it for much longer, and even more importantly, I also grasp the fundamentals in a better way.

All of these concepts can be introduced in the classroom, but for some reason they do not work very well. Many students are shy to ask questions. The time we have for a lecture is fixed and there is a set agenda for what has to be completed in the lecture. There is also the problem of differing learning styles and speeds. Different students learn at different rates. In a classroom, the lecturer always has to be at a median rate, which is too fast for some and perhaps too slow for a few. In other words, the median is not really the best pace for a lecture. Practice is usually in the form of lab exercises. The purpose of the labs is to complement what is taught in class. This method of teaching does not prepare students to be good software developers. Perhaps this is the reason why people in the industry say that many software graduates know the syntax of programming languages, but they are'nt good programmers.

To help students become good programmers, the primary form of learning must be through lab exercises, using the classroom to discuss doubts, and clarify concepts. I am proposing that we invert the current method of lectures complemented by exercises and discussions, and make projects and discussiosn the primary vehicle for teaching, complementing them with lectures when necassary. We must teach programming in a way that supports experiential as well as discussion based learning. Putting the focus on practice, will also help students learn at a pace that is best for them. Another factor we commonly see in most classrooms is that the teaching is usually directed from the lecturer to the students. Sometimes technology changes so fast, that it is very difficult for one person to keep up with everything. Often, people who have work in the industry have dealt with different types of real world situations (especially fighting fires). This gives them a somewhat unique practical perspective, that goes beyond the textbook. Please don't get me wrong. I am NOT suggesting that a lecturer knows less than a practitioner. Not quite. Even among working professionals, each individual will not know everything. What I am suggesting is that a community of practitioners and academicians have a lot of collective wisdom together. This collective wisdom will be way more beneficial to students than the wisdom of just one person. By learning from a community of practitioners, students will learn not only the theory but also real world practical usage (along with pitfalls and best practices) of a technology.

If we are to facilitate courses the "peer taught" way, we need to create a network that engages students with highly experienced and motivated practitioners. Unfortunately, such people are sometimes very busy with deadlines, and very often live in different towns. How do we get them to mentor students? To enable such a network, we might have to move away from traditional face to face lectures. One thing I hear very often in relation to teaching is "nothing can replace face to face teaching" . Before I go ahead and offer my perspective, I would like to say that I absolutely agree with the benefits of face to face interaction in a learning environment. But I also believe that with the new breed of collaboration/social tools (VOIP, blogs, wikis, newsgroups), coupled with the participatory culture of the new generation, we can create a model of learning that is experiential, based on discussions, and involves mentors (along with the lecturer) from different places. I have very often come accross people who would love to teach, but are unable to travel to a university campus. If given the opportunity to teach online, they would gladly give it time and effort.

For such a teaching and learning model to work, we must first create the right infrastructure and some guiding principles that will help the students, lecturers, and industry mentors.

Let's tackle the infrastructure first, and make a checklist of things we need:

  • Place to publish course descriptions
  • Ability for students to enroll for a course
  • Mechanism by which groups of students can work on projects (source code versioning, bug tracking, forum)
  • A place where students can ask questions (and get answers)
  • A way for the students to log their learnings, progress on the projects, etc
  • Mechanism for real time discussions, lectures
  • A way for mentors to provide feedback (and grades... ughhh) to students
  • A calendar for announcing important dates, etc

If you think of more, please add them in the comments section. I will appreciate your feedback.

Because the course may involve mentors from different cities (or even countries), all of the above features must be web enabled. Most good learning management systems offer course definition, enrollment, grading, discussion forums, calendars, blogs, etc. In fact a good learning management system like Moodle, will take care of almost all the above requirements, leaving only source code versioning, project collaboration, and real time collaboration. For versioning, we can either install CVS/SVN internally or let the students host their projects on hosted services. For project collaboration (bug tracking, forums, etc) , we can use Bugzilla, and web based newsgroups. For real time collaboration, we can utilize the classroom for lecturers and mentors who can go to the institute physically, and web based tools like Skype and Yvew for voice and slides. A simple way to get started is, install Moodle, install CVS, install Bugzilla, install Skype, and create an account with Vyew. And offcourse give access to students and mentors to relevant systems. Even though this is really simple, I prefer an alternate configuration, which I will describe below.

I am a bit uncomfortable with the above configuration for a couple of reasons. I would rather that students keep their blogs on a public website. That way they can retain their blogs even after they graduate (this may not be appropriate for school students for safety reasons). I would also prefer to use web hosted version control as provided by Google, or Sourceforge. This is because they provide many more facilities beyond version control. They provide bug tracking, forums for discussing issues, file downloads, and document hosting. Also since these services are hosted on the web, students can make their work available to future employers for viewing online. My personal preference is to install Moodle, let students host their blogs (which will be used as their learning journals) on a service of their choice, and host projects on, or . One thing to remember before hosting projects with these or similar services is that the projects will have to be made available on an open source license.

Google also provides "Google apps for education". They provide very good collaboration features, but you will have to supplement it with a course management software. Incidentally, such a software is available as a hosted option.

As you can see, there are several options. A different combination of software will be suitable for different institutes. Also there may be several alternatives for the services I have mentioned. For example, I mentioned Vyew for synchronous slide sharing. However, there are other services like GoToMeeting, being one of them. Similarly, there are other learning management systems besides Moodle. Moodle is free, feature rich, and also simple to understand and use. I believe there are other free options, but I cannot recollect them at the moment.

Regardless of the software and services chosen, what's important is that we support collaboration that is synchronous as well as asynchronous, and make appropriate information available to all concerned in as seamless a manner as possible.

Once the infrastructure is in place, we have to define a set of guidelines to help the students and mentors. I suspect none will have taken or mentored a course offered in this mode. So it is very important to have a set of guidelines, nobody gets stuck on how to move ahead. I will talk about the guidelines in a future blog post.


  • Free blog hosting is provided by Blogger, Wordpress, and several other.
  • The Shuttleworth Foundation is also doing some interesting research on peer taught software engineering.
  • Konrad Glogowski publishes an excellent blog on learning (especially using a conversational technique of teaching with blogs in the classroom).
  • Christopher Sessum also publishes an excellent blog. He talks primarily of teacher education, and the role of new media in education.

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