Java Diary

Setting up emacs with Slime on a windows machine

2012-01-28T13:03:00.000-08:00

For learning Lisp, initially I thought I would get by using LispWorks IDE, which is free for personal use or the other option is CormanLisp. But both aren't free software.LispWorks for professional use costs a thousand dollars a year, Corman I think is 250$. Also, note that LispWorks personal version IDE is not compatible with Slime. In any case, if you distribute any softwar built using Lispworks IDE, you need to pay them for the right to distribute your code. Not that I am in any danger of doing that (hardly write any code), but anyway, if I am trying out some new language, might as well go the full hog, and use the tools used by the vast majority of people.

Software required:

1. emacs: an editor, maybe much more than a plain editor. Comes with binary, used the one for 32 bit windows in my case.
2. Slime: extension for lisp over emacs. only needs to be copied, no installation.
3. Lisp: any implementation of Lisp. Grab any free implementation of Common Lisp. I decided to use Steel Bank Common Lisp, (which is a very weird name btw). SBCL installation will create a new environment variable called SBCL_HOME and add the same variable to the Path.

Tricky part:
After installation of emacs, C:\Documents and Settings\aman\Application Data\.emacs.d kind of folder is created. Now, ideally emacs uses a file called .emacs for configuration, and this file can run into thousands of lines for the hard core developers. This file was not present in the .emacs.d folder, but can be added manually in the Application Data folder. For setting up emacs to use our lisp implementation and the slime extension, here's the minimum content of .emacs file:

(setq inferior-lisp-program "sbcl") ; your Lisp system
(add-to-list 'load-path "I:/slime-~1/slime-~1/") ; your SLIME directory
(require 'slime)
(slime-setup)

Here load path goes till the directory that contains slime.el.
Note that the slime directory must contain windows short file name. The actual path was I:\slime-current\slime-2012-01-25, which got converted. If you don't put the path in the correct short format, emacs will complain. Lots of funny behaviour with the paths, so please watch out.
I posted this because the slime user manual was not so helpful in setting the inferior lisp program property.
I learnt the correct settings from http://lists.common-lisp.net/pipermail/slime-devel/2008-May/007331.html after wasting a lot of time.

UVa 531 - Compromise

2011-11-12T11:47:00.000-08:00

Here's my solution to the variation of longest common subsequence problem mentioned at Uva problem 531 called Compromise.
It is still too long for my liking, and I don't exactly follow the complete steps of submitting the solution to the online judge. When working with Java, I tend to get a lot of timeout errors. That put me off so much that now I only try to solve the problem to my liking, and if I am satisfied with the algorithm, I can live without getting formal approval from the judge.

<code>

package uva;

public class Compromise
{
char[][] res;
int[][] dp;
static String[] pattern1;
static String[] pattern2;

public static void main(String[] args)
{
String string1 = "die einkommen der landwirte sind fuer die abgeordneten ein buch mit sieben siegeln um dem abzuhelfen muessen dringend"
+ " alle subventionsgesetze verbessert werden";

String string2 = "die steuern auf vermoegen und einkommen sollten nach meinung der abgeordneten nachdruecklich erhoben werden dazu muessen"
+ " die kontrollbefugnisse der finanzbehoerden dringend verbessert werden";

pattern1 = string1.split(" ");
pattern2 = string2.split(" ");

new Compromise().compromise(pattern1, pattern2);
}

private void compromise(String[] pattern1, String[] pattern2)
{
dp = new int[pattern1.length + 1][pattern2.length + 1];
res = new char[pattern1.length + 1][pattern2.length + 1];
for (int i = 1; i <= pattern1.length; i++)
dp[i][0] = 0;
for (int j = 0; j <= pattern2.length; j++)
dp[0][j] = 0;

// First write the solution for characters only.
for (int i = 1; i <= pattern1.length; i++)
for (int j = 1; j <= pattern2.length; j++)
{
if (pattern1[i - 1].equals(pattern2[j - 1]))
{
dp[i][j] = dp[i - 1][j - 1] + 1;
res[i][j] = 'D'; // from top left, means diagonal
} else if (dp[i - 1][j] >= dp[i][j - 1])
{
dp[i][j] = dp[i - 1][j];
res[i][j] = 'T'; // from top
} else
{
dp[i][j] = dp[i][j - 1];
res[i][j] = 'L'; // from left
}
}
System.out.println("Final matrix is: ");
printIntMatrix(dp);
System.out.println("Result is: ");
printCharMatrix(res);
printCommonSequence(pattern1.length, pattern2.length);
System.out.println("\nLength is "
+ dp[pattern1.length][pattern2.length]);
}

private void printIntMatrix(int[][] matrix)
{
for (int i = 0; i <= pattern1.length; i++)
{
for (int j = 0; j < pattern2.length; j++)
{
System.out.print(" " + matrix[i][j]);
}
System.out.println();
}
}

private void printCharMatrix(char[][] matrix)
{
for (int i = 0; i <= pattern1.length; i++)
{
for (int j = 0; j < pattern2.length; j++)
{
System.out.print(" " + matrix[i][j]);
}
System.out.println();
}
}

void printCommonSequence(int i, int j)
{
if(i<1 || j<1)
return;
// now output the longest set of words.
if (res[i][j] == 'D')
{
printCommonSequence(i - 1, j - 1);
System.out.print(pattern1[i - 1] + " ");
} else if (res[i][j] == 'L')
{
printCommonSequence(i, j - 1);
} else if (res[i][j] == 'T')
{
printCommonSequence(i - 1, j);
}
}
}

</code>

Random thoughts...

2011-05-31T13:02:00.000-07:00

I have been thinking about programming in general and all the buzz in our sotware engineering field. I've been influenced by Paul Graham's articles on the importance of thinking in the functional way, and ever since then, a lot of those things that seemed unrelated, now look like they have a common thread running through them, which is:

"Functional languages are more important than what we give them credit for. All of the buzz is really stuff we would take for granted if more of us were using functional languages. And functional languages are more accommodating of what the best practices recommend we do."

I'm still working my way through "On LISP" from Paul Graham, so my opinions may change once I finish it and have a better idea about what it means to program in LISP. The universal acclaim that the most powerful language "LISP" seems to be getting is only fuelling my desire to learn it quickly.

Domain Driven Design:

Using the "domain specific language" is a widely acknowledged virtue. When I ask myself if Java or .NET truly support the ability to write code that can be readily understood by a domain expert, the answer is no. All we can do is choose the function names to reflect the domain task, there is no possibility to change the language's syntax to help deal with domain complexity.

True DDD will only be achieved when some sort of macro support is allowed, something that allows you to refine the language's syntax to better represent the domain. At least, people would not get too excited about for-each loops. I understand quite well that DDD has got more to it than code, it is also about analysis, but surely ease of representation in code is an important factor.

Domain Specific Languages:

Again, people who frequent the DDD conferences seem to have been talking about domain specific languages a lot lately. As we try to solve problems within a domain, we'll see lots of new frameworks come up, each dealing with some aspects of that domain. To give an example, Spring has Acegi security that tries to ease the task of web application security. There are specific frameworks for e-commerce. Some investment banks maintain their own languages that perhaps help them deal beter with the finance domain.

The power of domain specific terminologies is only set to increase as software engineers mount an offensive on domain complexity. So, it is important for a programming language to be malleable, and adapt to the domain, and functional languages do just that.

Object Oriented Design and Design Patterns:

Moving on to object oriented design and design patterns. I was a pattern freak for about one and a half years. I have to admit that, at heart, design patterns are only about code organization. I accept the significance of design patterns, but now it seems to me that "object oriented gymnastics" might be a better phrase used to describe all that. Yes, they help in writing code that is maintainable and easing code extension, and a developer who understands design patterns is less likely to write shitty code, but are design patterns all that important?

To take an example, we can now use Dependency injection containers to just declare that a class is a singleton (Make sure you know why singletons are evil.) or prototype, for example in Spring core.

There should be inbuild support in a language for repetitive thigs, and we should not wait for frameworks to provide what is lacking in the language. Most progress, if you really break it down, is being able to remove duplication. The present languages do not provide anything that can make design patterns easier to use, which is why sometimes we depend on frameoworks to provide design pattern support, but they too can help us only to an extent.

If only functions were first class objects in the mainstream languages, many of the patterns would just vanish into thin air.
There are articles which argue that design patterns might be a "language smell", indicating that the language lacks something it should have had support for.

Another interesting comment (read it somewhere on c2 wiki) was that some people find the UML as lacking enough representational power. I wouldn't be surprised if an alternative to UML comes up within the next 10 years. It does make me wonder about what techniques people in the functional world use to design their applications. So far, it seems that they favour "bottom up" design/development together with "top down". The language evolves to provide you building blocks for "bottom up", as compared to "top down" where we build elaborate designs and then set about creating them.

Other functional features:

When we notice the evolution of the current languages: the introduction of lambda functions in .NET or at least lame attempts to recreate them with complier tricks and the "coming soon" inclusion of closures in java, it is clear that we are migrating towards functional languages.

Test Driven Development:

Since functions are the focus of development in functional languages, writing simple functions and testing them should come easy and naturally in the functional world.

Another statement that struck me was the LISP world advice to program by wishful thinking. The SICP (Structure and Interpretation of computer programs) book mentions that you should first write the function call API as you would wish it to look. This exact statement is the first step in test driven development.

Other factors:

What I discussed above are purely technical factors, but economical advantages of using a less powerful language and techniques is something that cannot be underestimated. Most code shops will drag their feet, and not accept change unless the change is standardised. The service industry in India and other developing countries is never going to embrace change unless the client recommends it, so I'm not hopeful of the functional languages gaining even a toehold in this corner of the world.

Conclusion?

For now, this post should ideally stay without any conclusion, because with time I will gain more insight into where all of this is headed. Still, for the java world if I had to pick, the winner will be some language that has functional features and can also run on the JVM, since languages that run on JVMs do not freak managers out. With time, all the development techniques and best practices, that are headers in this article, will be taken for granted, and maybe we'll improve on all that as well. But it is clear to me now, that languages have a role to play in helping you embrace and move towards better development. And choosing the most powerful languages is important if we are to get there.

Spring's ResourceBundleViewResolver

2010-11-20T11:43:00.000-08:00

In a web application, jsp pages could be placed in a folder hierarchy. You could have a public folder that contains corresponding pages, or maybe a user folder. For such a structure, Spring's ResourceBundleViewResolver seems more useful than InternalResourceViewResolver.

The internal resource view resolver needs a hardcoded prefix, which means that your controllers must provide the folder prefix in the code.

So, if the controller wants to point to the jsp at WEB-INF/jsp/public/page1.jsp, the controller will need:

ModelAndView mv = new ModelAndView();

mv.setViewName("public/page1");

For this purpose, the ResourceBundleViewResolver seems a better approach.

<bean class="org.springframework.web.servlet.view.ResourceBundleViewResolver">
<property name="basename" value="views" />
</bean>
The base name implies that Spring should look for a file called views.properties somewhere on the classpath, and that this file should contain entries like:

page1.(class)=org.springframework.web.servlet.view.JstlView

page1.url=/WEB-INF/jsp/public/page1.jsp

Now, the controller just needs to say:

mv.setViewName("page1");

BTW, if you are working on Spring 3.0 onwards, don't forget to put brackets around the "class" in the property file. As per a comment at:

http://forum.springsource.org/archive/index.php/t-77942.html

"This is supposed to indicate that you can't use get/set pair to set the class. What is normally specified as an attribute on the bean element needs to be enclosed in a ()"

On integrating Spring Security ( formerly Acegi) with a Spring application

2010-11-05T15:01:00.000-07:00

Had a tough time as I tried integrating spring security with a simple spring application. It is only beginning to dawn on me now, that Spring is one vast framework. Struts feels like a walk in the park as compared to Spring and all its extra modules. But to be fair, Spring offers much more.

Now I understand that "convention over configuration" is useful only if the developer knows exactly what is going on. This ideology advocates leaving a lot of things unsaid, so if you don't configure everything, lots of components in your system will take on their default values, mostly inspired by the Ruby people. Good for a quick start to your project, but be prepared to go on a google hunt if you want precise control. Isn't it wonderful that now it is possible to have a running application without knowing how half of those things work? Simple example: if you want to use spring security out of the box, then the database tables for user needs to have specific names for all the columns, and the front end form elements need to have exact names like j_id, which is not so well documented. And for the simple default case, all this will work even though you don't know what's going on inside.

Coming to what went wrong today...

First, I added a security-context.xml file to my spring application setup. Now, the spring security authentication manager takes an authentication provider, which in turn needs a user service. I missed those user definitions, and of course I didn't know that.

So, what error message do i get on the server:

SEVERE: Error listenerStart

Nov 5, 2010 7:48:25 PM org.apache.catalina.core.StandardContext start

SEVERE: Context [/stackoverflow] startup failed due to previous errors

Hmm.. something wrong with the logging, no detailed log messages. Need to fix that first.

Two hours later, I stumble upon a blog post that says that Log4jconfigListener internally resets a property webapp.root. (log4jconfigListener is a spring specific listener that looks for a log4j property file in a specified place, and simplifies your logging support.) Also, we learn that Tomcat maintains system wide properties, so each application should keep its own version of this property.

http://blog.richeton.com/2010/06/22/how-to-solve-error-listenerstart-error-with-spring-log4j-and-tomcat/

Great, we put in a new context parameter in the web.xml file for this, called webAppRootKey.

Also, the order of listeners in the web.xml can have some consequences. So, the log4jconfigListener needs to come before the other spring listener, contextloaderlistener.

Now the logging was pretty well setup, still saw no log messages.

Another hour later:

http://forum.springsource.org/showthread.php?t=27967

Someone posts there on the spring forum:

"I often think about adding little bits of information as I learn more. Then after a while the information seems trivial - obviously since I've learned it and I can no longer remember the key fact that is needed to pass on. However, this is one I have to pass on. Maybe most of you already know this but I;m sure some won't!"

Thank you so much.

I attached the source of the spring jars to the project in eclipse, put a breakpoint in the contextloaderlistener as advised by the post. Now, I deployed the application from the Tomcat manager console. (Configuring the tomcat admin console is definitely useful.) The step return followed by a look in the variables window gave me a simple message:

"You must supply user definitions, either with child elements or a properties file (using the 'properties' attribute)"

which is a very accurate message, it took me about 2 minutes to correct this. Just goes to show that in application development, finding the problem is the hard part that requires skill. Resolving it is often easy.

A great sample Spring application

2010-07-27T11:09:00.000-07:00

For people who are in the process of learning about the spring framework, as applied to web applications, thought I should share this useful link...

http://stsmedia.net/spring-finance-part-1-introduction-architecture/

This covers Spring MVC, integration with DOJO, Acegi Security, Spring support for REST, and much more. This is a demo application that is just right for learning: not too much domain, covers all the layers right from the user interface where Stefan Schmidt (the author of the sample application, spring finance manager, in question) demonstrates the use of DOJO, to the use of domain driven approach with the services and repositories. Best of all, its configuration is completely annotation based, which in my opinion is so much better (read easier) than the verbose xml.

There are even some unit tests, but that's only for the service layer. These unit tests are not comprehensive enough. Again, I'm not quite sure if the service layer is the best place for all the tests, I would have preferred some for the controllers as well, but then I'm a beginner at test driven apps, and this is just a demo application. The only valid criticism of this app would be that it attempts to pack way too much new spring stuff into the code. The later explanations could also have been a little more detailed. Still, great job.

Getting deeper into DDD

2010-07-11T12:43:00.000-07:00

Practical information on Domain driven design seems hard to come by. The DDD bible is technology agnostic and other books on the topic are meant for .NET audiences. Even these books are not exactly easy reading.

To learn about one view of DDD, I have consolidated some information from Udi Dahan's blog. All of the following content is actually his writing or response to his readers, in a more digestible format. For a detailed explanation, you can always refer to his original articles.

From http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/

Aggregate roots should *not* be created. Always get an entity.

Don’t add any objects to the session or unit of work explicitly – rather, have some other already persistent domain entity create the new entity and add it to a collection property.

Don’t go saving entities in your service layer – let the domain model manage its own state. The domain model doesn’t need any references to repositories, services, units of work, or anything else to manage its state.

Almost every activity that results in the creation of an entity or storing of additional information can be traced to a transition from a previous business state. In any transition, the previous state is the aggregate root.

An aggregate root depends on the use case. An object can be an aggregate root in one use case, but not in another.

If your service layer is newing up some entity and saving it – that entity isn’t an aggregate root *in that use case*. Aggregate roots aren’t a structural property of the domain model.

Domain objects need to maintain their *business validity*. Not accepting dates before today falls under that definition. Strings less than 50 characters in length does not.

Rarely should entities actually be technically deleted, if ever. The better option is to change some kind of status on the entity.

Harness the technique of fetching strategies to get the best performance out of your domain model by representing your use cases as interfaces on the domain model

How do you unit test the code that depends on the ORM? Do you abstract it?

The only code that depends on the ORM is the service layer. The domain model doesn’t depend on anything other than itself – and it’s the thing you’ll be unit testing.

It makes sense to test the domain model, of course, but it also makes sense to test the service layer to make sure it is orchestrating things correctly, no?

The service layer shouldn’t orchestrate – after getting a domain object or two, it calls a single method on one of them, that’s it.

From http://www.udidahan.com/2009/01/26/altnet-ddd-podcast/

One way of getting rid of multiple constructors is by making use of the repository to create methods for the various cases. But analyzing further, what’s going on here we understand that, say, the way the order is created is dependent upon who the user is. It looks like user, or customer, is our aggregate root. Thus, rather than our service layer calling a method on the repository, we first get the user object by id, then create the order.

Having polymorphic aggregate roots is very useful and broadly applicable.

The dependency inversion principle doesn’t provide much value within a domain model. Domain model objects are designed to collaborate with each other intensely in their implementation of business rules. They should not be talking to anything else outside the domain, thus there is no need for DI in there.

Separating a system into bounded contexts simplifies the code greatly. The understanding that accepting an order and fulfilling an order require different logic, different data, and thus, different domain model objects is DDD at its finest.

Often, the best way to extend a system is “around the edges” by adding an additional bounded context. Domain objects are free of this concern.

The repository interface is part of the domain, however the implementations are infrastructure concerns. Still, objects in the domain model don't need access to repositories.

Some JUnit trouble in eclipse

2010-06-27T04:24:00.000-07:00

Got a cryptic "Ambiguous method" compilation error at the following line of code when using JUnit in eclipse. Here expectedChairPriceWithIncrease is a double while product.getPrice() returns a Double. The static imports were all there.

assertEquals(expectedChairPriceWithIncrease, product.getPrice());

With JUnit 4.3, the above line passed just fine, but ran into problems with JUnit4.4.

http://junit.sourceforge.net/doc/ReleaseNotes4.4.html calls it a fix for a bug.

"assertEquals now compares all Numbers using their native implementation of equals. This assertion, which passed in 4.3, will now fail:

assertEquals(new Integer(1), new Long(1));

Non-integer Numbers (Floats, Doubles, BigDecimals, etc), which were compared incorrectly in 4.3, are now fixed."

On Spring

2010-06-26T11:47:00.000-07:00

I recently attended a 3 day training on the Spring framework. The instructor observed that Spring basics include the Inversion of control container and aspect oriented features of Spring. He also covered the use of Spring in the data access layer and for transaction management. He noted that Spring's transaction management supports nested transactions that EJB does not. So, EJB still lacks something that Spring offers.

He also explained that Spring is perhaps the only framework that has utility in almost all layers of a web application as it extends from the presentation tier to the integration tier. All other enterprise java frameworks target one layer and that increases the investments required to learn the complete set.

I think one major feature that he failed to mention is the support for mocks that Spring provides. The creators of Spring clearly mention that they value testability. Take for instance a simple web application I was trying to create just now. Without Spring's support for testing, I would have to start Tomcat, deploy the application and then see if it worked or not. With Spring, the package "org.springframework.mock" provides me all the support I need, so I can create a test and work with servlets without an application server.

The training did not include Spring MVC, which is the equivalent of Struts, so that was a little disappointing. He also made only a passing reference to WebFlow. Another concern is that we couldn't get much hands on practice at the training, since the feature set of Spring is huge, so it was always a little rush-rush. Still, I would conside it time well spent.

On learning practical TDD

2010-05-09T10:43:00.000-07:00

If I had to sum up my last two years of experience as a developer, I would say using dependency injection to write code that can be easily tested would be the most important thing I've learned. And the single most important site that kicked it off for me would be the one from Misko Hevery, where he teaches how to write code that is easily testable. (If you haven't read all his articles and seen all his videos, please do so. It will change the way you look at code.)

The next logical step is to adopt Test Driven Development, or Test Driven Design. This is about letting the test cases drive the design of your software. The benefits of TDD are well documented, it's been proclaimed as the best way to build software. (Well, it isn't appropriate for all kinds of software, like implementing algorithms. Refer wikipedia for criticism of TDD.)

It is widely believed that the best way to learn TDD, is to pair with someone who already does it. But where does that leave people in non-agile companies? The whole point of this post is to share my experience on how I'm going about learning this agile technique.

Step 1 would be to go through the classic by Kent Beck, "Test Driven Development: By Example". This book teaches the absolute basic techniques that help a developer think in TDD terms. Kent goes step by step, refactoring at each step, even sharing with us his thoughts on why he thinks a particular refactoring is required. Please note that knowledge of refactoring techniques is another requirement for TDD. To put it simply, refactoring is the disciplined process of removing duplication from your code, and improving its structure.

But the problems that Kent solves in his book, is in the context of a maintenance project. If you were to start with a new project, trying to apply TDD, this wouldn't be enough, since, it seems that Kent is working with a project that is already covered with a test case harness.

Another book, Growing Object-Oriented Software, Guided by Tests, by Steve Freeman and Nat Pryce, takes us further and applies TDD in the real world. I'm still going through this book, but its already helping.. for instance we learn that a real TDD process begins with an acceptance test. This makes sense as it forces us to set up the infrastructure in the first iteration of the project, surprises if any will be encountered early on, giving more time to tackle them. More on this when I'm done with this book.

The book by Jimmy Nilsson, Applying Domain Driven Design And Patterns, looks at these techniques from the .NET perspective. The fun part is where he tries to mix up DDD with TDD. The way he goes about his sample problem, tells us that there is a lot of to and fro when using TDD. We take a step, another, and see a problem or sense a code smell, and then we start backing up from the steps we just took. Also, he, kind of, blasts the notion that there is no upfront design when applying TDD. There is some design, but we don't spend too much time thinking about it, so it isn't the big upfront design that was seen in the classic waterfall. The point is not to invest too much time in the design because surprises are inevitable.

For those who like live action, Brett Schuchert from Object Mentor, has posted videos that demonstrate TDD in both java and C#.

Learning the difference between mock objects and stubs, and practicing Mocking techniques with at least one good mocking framework ( The current favorite that is getting coverage in many blogs is Mockito but it still doesn't have a lot many users, the previous one was Easymock, and has better documentation and will be easier to use since many books show how to use it).

As of now, I'm hitting the stage where I can write some tests and the code, but the tests seem to be a burden because every time the code changes, making the tests confirm to the changed code become a nightmare. I know that brittle tests is a big problem, test code should actually be the easy part, and it probably implies that the code is not easy to use and has smells... the warning here is : don't go applying the test first approach in the workplace right away... spend some time practicing TDD before applying it at the place where you work, because it can take a lot of time, everytime you are stuck, it will be hard to get help in a non agile firm.

Shortcuts anyone??

2010-04-17T06:08:00.000-07:00

"Which IDE do you use?" Eclipse

"So, can you program without a mouse?"

This question from a veteran programmer set me thinking whether I was making the best use of my IDE... I was not. So, I was advised to unplug my mouse and get going without it, an old school approach.

After a couple of weeks of using Eclipse mostly from the keyboard (No, I didn't throw the mouse away), here's my list of favourites:

Ctrl+F6, Ctrl+F7, Ctrl+F8 : to manoeuvre the different windows, views and perspectives.

Ctrl+1, Ctrl+2 : to provide context sensitive help, could be promoting a variable to the instance level, creating a new class, and a whole lot of other things. This one's indispensable. I expect this to be even more useful when driving code the TDD way.

Ctrl+T: to see the type hierarchy. Very handy when traversing code that has interfaces and abstract classes.

Alt+Shift+R: Renames, one of the refactoring menu options.

Alt+BackArrow, Alt+ForwardArrow: the last location where we edited.

Ctrl+ PageUp, Ctrl+PageDown: Tab through the open code windows.

Ctrl+E: helps select and open files when traversing the open files in the editor.

Alt+Shift+N: to show the menu that lets you create anything new, be it a project, package or class.

Ctrl+Shift+O: organize imports.

Some of the less important shortcuts are:

Alt+Enter: for the project properties. Handy when you want to, say change the jar files that eclipse puts on the class path for a project.

Ctrl+Shift+R: opening a resource, but I don't use this too often, I prefer Ctrl+E.

Ctrl+W: closes a editor file. This works in web browsers (like chrome and firefox) as well, where it closes a tab.

I took this a step further, could I browse without a mouse?

Press F7, and step into the caret browsing mode. Then you can browse the web in the text mode. To open a hyperlink in a separate tab, use Ctrl+Enter. This works at least for firefox.

Its amazing the time these shortcuts save. But more important is the fact that they let you think about the problem at hand, you think about the code in the file and not about how to get to it.

On testable code and TDD

2010-03-18T11:40:00.000-07:00

Ok, so I haven't blogged in a while...
But I think I've learnt a few things over this period. For a while, I think I was enamoured with writing testable code, and I took it too far. So much so that today when I look at my code, there are mostly dependencies being injected through the constructor everywhere.
Well, isn't that a good thing, you might ask?
Not necessarily. Such code tends to get defined by its static struture if you approach all your development this way. Unless we look at behavior more than overall structure, we will not get the right abstractions in place. When designing classes, the question to be asked is this: which classes does this class need to talk to?
Identifying abstractions followed by collaborations seems to be the most dificult part when designing OO software.

Another idea that I have been trying to learn is that of TDD.
Writing tests is not enough. Till now, all my efforts were towards refactoring existing code, to make it more flexible. By injecting dependencies and defining test versions of the same classes, I thought I would be able to crack the design issue everywhere, and I was way off target.
Again, I was not exactly on the mark when injecting dependencies either. Till now I had no idea of the mocking frameworks that people use to ease their unit testing efforts. I need to look into the differences between state verification and behaviour verification.
Apparently, the right way to go about writing code is in the exact reverse of what I have been doing till now : you write your tests first, and then the code follows. The rationale behind this approach called TDD, is that if the tests are written first, you only write enough code to makes your tests pass, thus staying away from the "big design upfront", which may or may not materialise, and more importantly which will perhaps not be required. The test code will be considered your specification. If the client asks for a feature, then you must have a test for it. Looking at in reverse, everytime you get a bug reported, step one must be to write a test that can reproduce the bug. Only then do you work to fix it.
Tests are also considered as doumentation. Some TDD practitioners will even refuse to look at your documentation, the first thing they look at is your test suite. Their logic: documents may lie because developers don't often keep them up to date, tests are the real deal.
They follow the RED-GREEN-REFACTOR cycle. Write a failing test case, write enough to make that test case pass. And then refactor like crazy. The aim of refactoring must be removal of duplication. And trust me, Kent Beck's book (Test Driven Development by Example) will surprise you on the topic of identifying duplication when taking small steps.

I still don't understand what they call "interface discovery", this is what makes TDD an approach to design, and not just a process that ensures your test cases get written. Another area that is fuzzy to me: how much of design is required before you can start TDD? Do you approach the screen with a blank mind, taking it from there? Or do you think a few things out before you start tapping away?

On writing testable code

2009-10-11T11:33:00.000-07:00

Came across this wonderful blog on how to write testable code, by Misko Hevery.

He argues that code needs to be written keeping testability in mind, and that testing tools or similar frameworks can't help write test cases if the code is not testable.

Here are some observations drawn from his blog and the net in general, on what kind of code makes test cases easy to write:

Collaborators of a class must not access external resources(files, db, network).

So many designs are full of “objects that instantiate other objects or retrieve objects from globally accessible locations. These programming practices, when left unchecked, lead to highly coupled designs that are difficult to test.

Static methods are impossible to mock in java.

Static methods are like using classes purely as namespaces

Avoid inline object instantiation.

Replace Conditional with Polymorphism: You have a conditional that chooses different behavior depending on the type of an object. Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract.

If you check same condition in multiple places, choose polymorphism.

Polymorphism over conditionals.

Composition over inheritance.

Singletons lead to memory leaks, because singletons stay in memory, and as long as some other class maintains a reference to a singleton that cannot be garbage collected.

Scattered getInstance calls are not indicators of good design.

Does calling a method from within the same class violate the principle of isolation?

Argument? Because the methods are tightly coupled and it is no longer possible to test

the calling method without also testing the called method. (Not too sure.)

Need to separate the file system interactions from within the code. This way, tests run faster.

Production code: no new's, no nulls, only null objects.

Unit Testing code: lots of new's, lots of nulls.

The startup code of the application, initialization code needs to be based on the API, so there should be no global state. The order of initialization should have dependencies.

If there are too many dependencies, it means the class design is wrong.

Service locators cause a law of demeter violation.

Stuff you normally do in constructors should be done in Factories.

Work like reading database, accessing files should be done in the factories.

When you find a bug, write more tests for those areas in which the bug occurred.

Stubbing a method is all about replacing the method with code that returns a specified result (or perhaps raises a specified exception).

Mocking a method is all about asserting that a method has been called (perhaps with particular parameters).

Using properties in switch statement cases

2009-10-06T13:28:00.000-07:00

An interesting link here:

http://stackoverflow.com/questions/1229169/using-properties-in-switch-statement-cases

This discussion concludes that in a switch, there is no way to assign a case statement with a value from a property file. That's because the case statement has to be known at compile time, while the property file can only be read at run time.

So, you can only replace the switch with an if else block. Seems like there is no other way out.

On Filters and Static classes

2009-10-04T11:10:00.000-07:00

I came across a useful illustration of the Filter design pattern:

http://www.erik-rasmussen.com/blog/2008/01/18/the-filter-pattern-java-conditional-abstraction-with-iterables/

And here's a discussion on the differences between singletons and static classes:

http://www.javaworld.com/javaqa/2000-12/03-qa-1221-singleton.html

The point is that static methods cannot be overriden and so static class is more of a utility. This means that a static class doesn't allow you the usual benefits of OOP.

Unable to find a javac compiler

2009-09-22T14:29:00.000-07:00

I faced this problem while writing an ant file in eclipse:

Unable to find a javac compiler;com.sun.tools.javac.Main is not on the classpath.Perhaps JAVA_HOME does not point to the JDK.It is currently set to "C:\Program Files\Java\jre1.5.0_21"

The problem is that by default Eclipse uses some JRE and gives this error when I try to write a compile target which needs a JDK and not the JRE.

<target name="compile" description="Compile Java sources" >
<javac srcdir="${project.src}" destdir="${project.build}" >

</javac>
</target>

So, you either force the JAVA_HOME to point to the JDK and not the JRE, orthe solution in my case was to find out the JRE which is being used (it mentions that path)in the console window itself. Then, copy the tools.jar from the JDK/lib to the JRE/lib/ext/

And that fixed it.

OO Design Heuristics

2009-09-13T13:33:00.000-07:00

Last week, I went looking for informal guidelines, on what makes a good class design. These are called heuristics, and when you are done designing your classes it can help you decide if you've done a decent enough job or not.
Some of these are from "Object-Oriented Design Heuristics by Arthur J. Riel", while others are from Allen Holub.

Unused properties in a class:
If your object is being used with some property that has no value or has nulls very often, it could mean that this object is doing more than its share.
Make a class diagram, change one property and ask yourself which other classes are going to be affected. Follow the ripples, and you follow the problems.
Most of the methods defined on a class should be using most of the data members most of the time. (This is all about cohesion)
On the God Class:
- A single class drives the application, all other classes are dumb data holders. Do not create god classes/objects in your system. Be very suspicious of a class whose name contains “Driver”, “Manager”, “System”, or “Subsystem.
- Beware of classes that have many accessor methods defined in their public interface. Having many implies that related data and behavior are not being kept in one place.
- Beware of classes that have too much noncommunicating behavior, that is, methods that operate on a proper subset of the data members of a class. God classes often exhibit much non-communicating behavior.
- The god class tends to have a lot of getter Calls.
- Consider a typical procedural "god" class, which collects the information that it needs to do some piece of work from other objects. The god-class implementation is littered with "get" calls. What if the object that already has the data does the work, though? That is, what if you moved the code that does real work from the god class to the place where the data is stored? The accessor calls disappear, and the code is simplified."
Classes should not contain more objects than a developer can fit in shortterm memory
Most common mistake
– Using multiple inheritance in place of containment.
A class must know what it contains, but should never know who contains it.
The maintainability of a program is inversely proportional to the amount of data that flows between objects.
Classes that directly model the system at the domain level, sometimes called business objects, hardly ever need accessors or mutators.
To pass information around, use the following two rules of thumb: Pass around objects (ideally in terms of the interfaces they implement) rather than raw data, and use a "push" model, not a "pull" model.
Base classes are fragile:
Change to the base class may affect the derived class. Some people call this the fragile base class problem. This may be one of the drawbacks of using inheritance. If you find yourself overriding everything, you should really be implementing an interface, not extending a base class." The Gangof-Four Design Patterns book is, in fact, largely about replacing implementation inheritance (extends) with interface inheritance (implements).
Any use of operators like (instanceof in Java) would indicate programming to concrete types and you can think how the instanceof check can be get rid of.
When a developer says "I need to make this piece of data public", they should ask themselves "What is it that I'm trying to so with the data and why doesn't the class perform that operation for me?"
Procedural applications break an application down according to function which then share data structures. While it is easy to see which functions access which data structures, it is difficult to go the other way, to see which data structures are used by which functions. The problem: a change to a data structure may have unintended consequences because the developer was not aware of all the dependencies on the data structure.
It should be illegal for a derived class to override a base class method with a NOP method, that is, a method that does nothing.
Subclasses should not use directly data of superclasses.
All data in a base class should be private, i.e. do not use protected data.
The OO-design process is centered on use cases: stand-alone tasks performed by an end user that have some useful outcome. "Logging On" isn't a use case because there's no outcome that's useful in the problem domain. "Drawing a Paycheck" is a use case.
The notion of emergence is critical to OO thinking. You design (and build) around use-case scenarios, and you don't design for every possible scenario. Nonetheless, scenarios that you hadn't thought of are handled by the program.

On Subversion: Relocate

2009-09-06T11:11:00.000-07:00

Last week, the url of of our source code repository got changed, from http to https.
That's when discovered the SVN relocate command that repoints your local working copy to a new url. Other develoeprs had not heard of this one, but since it is a useful SVN command, I thought I'd mention it here.

SaxParse Exception: Invalid byte 2 of 4 byte UTF-8 sequence

2009-08-26T11:55:00.000-07:00

Some time back, I was trying to pass on an xml file from a .NET application (PDA based, on Compact Framework) to a java web service, and I faced this curious problem:
When the web service would try to parse it, the xml file would throw a SAXParseException on the server.

To compound the situation, I could not seem to reproduce this exception, but the client, if she used the same .NET application long enough, would report the problem sooner or later.
Now, how do you solve this problem you can't reproduce?
Common sense dictates that an xml file should have its encoding specified in the root tag,

I did not specify the encoding, and trusted the underlying OS to do the right thing.

I asked the client to pass the xml file to me. The file was all pretty and well formed. No garbage anwhere. I tried uplaoding this file to the web serviec from my side, it worked. The client tried the same and it failed again. Was something happening while the file was being passed on to me, maybe some format change when the file was copied from the PDA device's file system to her desktop?

This sparked a search to understand what encoding is all about. An important realization: all unicode characters are not represented
in 2 bytes, some of them can go upto 6 bytes, and something of this sort was happening because not all characters are stored in 4 bytes (the size of the file would have hinted us if this was the cause), and the one that gave us the error was obviously being interpreted as taking up 4 bytes. That the character was even being thought of as a 4 byte sequence, should have alarmed us since most common characters are represented in 2 bytes. Look at Joel's article on Unicodes ( at Joel on Software).

Did it have something to do with the different OSes, Windows and Linux have different default file encoding formats?

And then I fell into "analysis paralysis" trap. We changed the file encoding in a text editor. We even opened a hex editor and tried to figure if the file was getting corrupted at a particular position, and it seemed like some rogue bits were getting inserted in between in the middle of the file. All the information would get shifted, and from that point on the file would be all gibberish. The network could not be the problem since the client was reproducing this problem fairly regularly by now. Nothing actionable so far. End of Day 3, still no clues.

Finally, I looked at how the xml file was being written to, and found a constrcutor that takes a encoding as a parameter.

[C#] public XmlTextWriter(Stream, Encoding);

I figured that if the file is being written to with a particular encoding format, then the OS should override its default if any.
Since the web service was expecting a utf-8, I decided on this format to be mentioned in the constructor. (I also tried changing the encoding to utf-16, and yes the file size did double.)

Another suspect was the byte order marker or BOM which is often present at the beginning of an xml file. However, we found that the chances of a BOM occurring in the middle of a file are low, and the SaxParser is intelligent enough to ignore it even if it were to occur.

So, we tried to give it a go. With the encoding as the only change and with nothing else as a probable cause, we went ahead and deployed the application again.

The exception hasn't recurred since. :)

Random Java

2009-08-03T11:39:00.000-07:00

It's always good to have the convenience of the Java libraries on your side, and I'm learning how to use them to make my code cleaner.

Here's a simple one, which I came across lately:
java.util.Math has a max function, and the java docs say:

public static int max(int a, int b)

"Returns the greater of two int values. That is, the result is the argument closer to the value of Integer.MAX_VALUE. If the arguments have the same value, the result is that same value. "

if(a>b)
a=b;

can be replaced with

a=Math.max(a,b);

which is much more readable.

And take this one:

Converting a string with a value from 0 to 9, like "5", into an integer is best done by
str.charAt(index) - '0'

And here's an obscure String function, intern()

"A pool of strings, initially empty, is maintained privately by the class String.

When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned. Otherwise, this String object is added to the pool and a reference to this String object is returned.

It follows that for any two strings s and t, s.intern() == t.intern() is true if and only if s.equals(t) is true.

All literal strings and string-valued constant expressions are interned."

The Longest Common Subsequence, SVN and media files

2009-08-03T11:20:00.000-07:00

Here's a sample question from one of my friend's phone interview with a major technical online giant ( if you browse the internet, then you've heard their name)

You've got a fairly big audio file (why audio?), and somebody takes a copy of that file, and makes a small change in that file. (I guess you can always open a media file with a text editor.) So, how do you detect exactly what changes were made between the original and the new modified copy of that file?

One year later as I started using subversion(SVN), the repository for our source code, I saw a feature called diff, which can let you compare the checked-in version of your source with your working copy.

Wondering how SVN did this, I came across the Longest common subsequence algorithm.
A standard dynamic programming approach is used to implement this algorithm, which also has applications in genetics.

On Code refactoring

2009-07-05T13:06:00.000-07:00

There are times when a not so well designed application makes you wonder if rewriting it would be easier than maintaining it. Resist the temptation. Such a situation calls for a refactoring, and not a rewrite, because whatever code you have, ugly as it may be, atleast "works". Throwing away so many hours of developer work-time isn't a good idea. Also, the business aspects(read as your manager) would never allow you to go in for such a major overhaul.

A part of my last two weeks was spent on code refactoring. When I started off, my aim was to arrive at a particular final design. It doesn't work that way. Code refactoring proceeds step-by-step, eliminating one code smell at a time. As you go on, you might see an opportunity to apply a particular design pattern, and then you can do that. But make sure that the application is stable at all times. One-change-at-a-time seems to be the best way to go about it. And some quick testing is a good way to ensure that nothing has broken.

Code refactoring also gives you an opportunity to look at the code you wrote, and how it fits with the application. I had made some mistakes in mixing implementation details with the algorithm code, and my muddled thinking was obvious to me from the poor names that I had used all around. Here's an example:

int GetPosIndex(PosDim p)

Based on this function's return value, I would decide whether the position was full or empty(-1 for full, otherwise full with the return value pointing to the Positions' index in the datastructure).
I could change it to

bool IsPositionEmpty(PosDim positionInstance)

If these methods belong to a class Container, then

containerInstance.IsPositionEmpty(positionInstance)

makes for more readable code than

containerInstance.GetPosIndex(positionInstance)

Another option is to write

containerInstance.GetPositionStatus(positionInstance)

but then you will have to take different actions based on the return values.
This may seem trivial, but can help catch logical errors in the code. Your code should be as close as possible to the English you speak, for easy and fast maintenance.

Another area that concerns me is the null check. For example,
Consider a finite state machine, with all its events, states, transitions and actions specified as an xml file. Based on the user's input, the FSM should make transitions from one state to another.
The basic control flow goes as follows:

event=GetEvent();
lastState=getStateFromStateStack();
transition=lastState.getTransition(event);
action=transition.getAction();

Now what happens if there is no event detected corresponding to a particular user input?
What happens if event, as returned from GetEvent is null, and the same null checking logic begins to infest your code?

event=GetEvent();
lastState=getStateFromStateStack();
if(lastState!=null && event!=null)
transition=lastState.getTransition(event);
if(transition!=null)
action=transition.getAction();

This looks ugly. An NPE(null pointer exception) is waiting to happen somewhere down the line. So what so we do about this?

There are the following approaches to solve this problem:
Return a default object, with an attribute that other code can use to know your object is in a usable state or not.
Or throw a CustomException if the situation demands it.
But don't be afraid to return a null if it makes sense, for instance a Hashtable, if it finds nothing matching your key, must return null, no other way out.

In the above case, I created a new event "noEvent" which would be returned if no event was found. Then I configured the FSM so that on detecting this event, the transition returned would be of "ErrorTransition" type, and the action could then be an "ErrorAction", as per the FSM's configuration.
But what happens if
transition=lastState.getTransition(event);
returns null, because the FSM did not know which transition to make from our present state on encountering an event? This is more of an FSM configuration problem. Our poor FSM can't make a well informed decision now. So, we should throw a gentle message to the user informing him that the FSM couldn't find a transition.

This reminds me of an interesting comment I read on CodeProject, as part of an article on "Exception Handling Best Practices in .NET by Daniel Turini".

"External data is not reliable. It must be extensively checked. It doesn't matter if the data is coming from the registry, database, from a disk, from a socket, from a file you just wrote or from the keyboard. All external data should be checked and only then you can rely on it. All too often I see programs that trust configuration files because the programmer never thought that someone would edit the file and corrupt it."

Another mistake I noticed was the file writing class, which would first delete the output file, and then write it. Here are the same author's comments that woke me up to this problem:
"When you're saving data, situations can happen:
* Not enough security privileges
* The device isn't there
* There's not enough space
* The device has a physical fault
That's why compression programs create a temporary file and rename it after they're done, instead of changing the original one: if the disk (or even the software) fails for some reason, you won't lose your original data."

Also, there's the exception handling, that I still haven't refactored.
Here's a tip I that caught my eye:

"Don't clear the stack trace when re-throwing an exception
The wrong way:
try
{
// Some code that throws an exception
}
catch (Exception ex)
{
// some code that handles the exception
throw ex;
}

Why is this wrong? Because, when you examine the stack trace, the point of the exception will be the line of the "throw ex;", hiding the real error location.
try
{
// Some code that throws an exception
}
catch (Exception ex)
{
// some code that handles the exception
throw;
}

What has changed? Instead of "throw ex;", which will throw a new exception and clear the stack trace, we have simply "throw;". If you don't specify the exception, the throw statement will simply rethrow the very same exception the catch statement caught. This will keep your stack trace intact, but still allows you to put code in your catch blocks."

More on this when my refactoring is completed.

On Object Oriented Design

2009-06-16T09:35:00.001-07:00

I thought I knew object oriented programming (OOP)... I was so wrong!
Well, at least now I know that this is not something everybody gets. It takes a number of "aha" moments, full of blazing insight, before you can think in terms of objects.

Back in college, OOP, at least to me, was always about creating a small programs where the ideas of

Objects/classes
Information hiding (encapsulation),
Inheritance,
Interfaces and
Polymorphism could be demonstrated.

Design patterns were absolutely unheard of.
However, the true power of OOP is only realized when you apply it in a project of some size, with many people working in tandem on the same entities.
So, how do you know if your code is perfectly object oriented or just pretending to be? I've observed the following indicators of good OO code:

Easily maintainable/modifiable: If you had to make an extension to the existing features, how long would you take? If you can't instinctively name all the classes where some more code is required in this situation, it probably isn't OO.
Extensive use of Design Patterns: It is difficult to get the object communication strategies right without the right theoretical and practical background. So, you will see design patterns applied in good OO code. Fluency in this area, they say, comes with experience.
Too many special cases: If the code has comments explaining why a special hack had to be included to take care of a use case that was later added to the requirements, it means that the class design is faulty, and the designers should have put more thought into their work.
Lengthy class methods: This is one indicator that your methods are doing too much, and therefore not exactly what they are expected to.
Many statics floating around
Using UML: If you find yourself referring to the UML diagram too frequently, when the diagrams are not overly complex, chances are that the code is not very well designed. Coding tends to happen much more naturally when the designed classes reflect the domain accurately.
Programming to an interface

When designing a new application, I used to start off with the database, which is actually an implementation detail. Now I'm beginning to realize that step 1 is always object oriented design, and it is important because decisions taken at this stage will come back to haunt you later if you do not pay enough attention.

On .NET Compact Framework

2009-06-14T00:11:00.000-07:00

This is a warning!
Just because you are a Java developer doesn't mean you can steer clear of other technologies. I got a taste of this when I was asked to work on a compact framework application in January 2009. .NET CF is a stripped down version of its desktop equivalent, meant for handheld devices like PDAs and Smartphones.
Since I am no stranger to CF ( my final year project had a module on the PDA), I was at home, well aware of CF quirks and shortcomings.
Was it fun? Initially, yes. But as you keep going on, you come to know it limitations, and that is irritating. And even though the guys at Microsoft Forums try to help you out, creating a CF application with a snazzy enough GUI is still difficult.

Since application designers need to have some idea of what's possible with CF, and what might stretch the device, here are my random thoughts:

Do not mistake a PDA for a desktop machine. Its computing abilities are limited.Take a look at how CF manages its memory and you'll know what I'm talking about. Read http://blogs.msdn.com/stevenpr/archive/2005/12/12/502908.aspx The interesting part? "The .Net Compact Framework CLR manages the memory in the per-process 32 MB virtual address space on behalf of the developer." This just means that 32 MB is all you've got, and there is now way to increase the memory available to your application. (Believe me, I tried. I naively thought that increasing the RAM available to the emulator will somehow magically grant my application more space to play around, it didn't.) What does this mean? In my case the PDA application was downloading lots of information(MBs) from a web service in xml format, but would get an out of memory exception when trying to parse the xml. So, we had to strip the xml down to the barest, remove redundant information and trim down the tag names.
Plan in advance if you want a striking GUI. The controls in the toolbox are just not good looking enough, and sometimes lack inbuilt functionality. For instance, a common requirement is a customized datagrid, with columns having checkboxes, combos and what-nots. In my case, we wanted a column of icons. For the sample app on how to implement a customized datagrid, look for the Compact Framework team blog, posts by Ilya Tumanov. I'm still struggling with the GUI. You've people used to the iPhones and Mac GUI's, so you cant just give them an app that seems developed for people from the last decade. I've heard of a technique called Alpha Blending that promises to improve the look substantially, but haven't found the time to experiment yet.
Work with the latest tools. The latest CF version is 3.5 which is only available with VS 2008. The last version was 2.0 on VS 2005. But where the CF 3.5 really takes off is the presence of a testing framework for mobile devices. Check out the "How do I videos for Mobile devices." Also available are the PowerToys, which help you with monitoring your device's performance in terms of memory. I've used the Remote Performance Monitor also. If you want a good free profiler for mobile apps that works on on CF 2.0 also, try the EQATEC profiler for .NET apps, but its limited to letting you know the time taken by your function calls, nothing about the memory. There's also a tool around, called the Hopper, which checks your application's responsiveness to random clicks, something the CF team at Microsoft used internally and have now released for all of us. Another ramdom tip: VS 2008 supports 2.0 apps, and an application can be upgraded from 2.0 to 3.5 easily, but once you upgrade from 2.0 to 3.5, you can't just "downgrade" back to 2.0, so make a backup.
P/Invoke. These are system level calls which you'll need if you want to interact with device, say play a sound or simulate a keyboard click. Some things still need you to talk to the device directly. Take a tutorial on P/Invokes, it'll come in handy.
OpenNetCF. These guys have a bunch of dll's, called SmartDeviceFramework, ready to provide you some extra functionality. When Microsoft disappoints, this is the place to search for answers.

Log4j

2008-12-30T09:25:00.001-08:00

Apache's Log4j is a popular tracing API, and is particularly useful for logging code behavior.

There are 3 main classes involved : Logger, Appender and Layout.
Loggers:
Have a named hierarchy, with the RootLogger at the base.
Use the following static calls to get a logger.
public static Logger getRootLogger();
public static Logger getLogger(String name);
Every Logger may have a level, defined is the class log4j.Level.
TRACE,DEBUG,INFO,WARN,ERROR and FATAL.
and if unassigned it will inherit a level.
loggerObject.setLevel(Level.WARN);
loggerObject.warn("Your msg");
loggerObject.debug("Your msg");
(Check if ALL and OFF are also valid levels.)
A message is enabled according to its level compared with the logger's level.

Appender:
This is to redirect your log messages towards a destination, which can be say a FileAppender, ConsoleAppender, or an SMTPAppender for mailing.

Layout:
Every Appender needs to have an associated Layout, which is for formatting your output.

Configuration:
The logger's configuration can be done either through a properties file, or the more preferred and used XML file.

The apache Log4j's home page specified mirrors seems to be down, so try downloading the 2.3MB jar from somewhere else.
Take a look around, this background should be enough.

Advanced features:
How to optimize these logging statements so that the logging overhead is reduced.

The Beginning

2008-12-29T09:46:00.000-08:00

For a newbie in the Java world, it does take some time to actually get a hang of the numerous acronyms that the pros freely use, and the difference between what you know and what you need to know is enormous.

Based on my 6 months experience, here's a random list of what I think is considered "common knowledge" in professional circles, and in-depth of knowledge of which is the real syllabus for anyone moderately serious.

Exception Handling, Threading,
Serialization, File Handling, Reflection Classes.
Ant scripting, Network Programming,
Working with databases,
Design Patterns.
ORM tools like Hibernate, JUnit,
JVM and its working, Dynamically loading classes.
JSP, JavaBeans.
Some JavaScript, AJAX, working with XML.

System side skills, Shell scripting, speed at the command-line, and familiarity with the Linux structure.
Oracle, MySql.
Functional programming.

The list is obviously incomplete and much needs to be added, but this is a good place to start.

Post 1

2008-11-29T02:32:00.000-08:00

This blog is supposed to record what I'm learning.
Everytime I find something new or useful, that helps me become a better programmer, I promise to post it here.
This will include Java code snippets, information on productivity enhancing tools, and in general stuff that we tend to learn only after taking a few knocks.

I hope this comes useful to other people...