Writing multi-threaded and concurrent programs is not easy, not even in Java. Even senior developers, including myself, make mistakes while writing concurrent Java applications. This is also one of the trickiest area of Java programming language, where misconceptions outnumbers concepts. Considering amount of misconception an average Java programmers has about multi-threading and concurrency, I thought to start a new series about common multi-threading mistakes done by Java programmers; what is better way to learn from common real word mistakes. Learning from mistakes has another name Experience, but if you only learn from your mistakes then there is only limited things you can learn, but if you learn from other peoples mistake, you can learn much more in short span of time. Have you ever thought, Why writing multi-threaded code is difficult? IMHO, primarily reason for this is that it multi-threading makes it hard for a code to speak for itself. Programmer read code sequentially to understand how it's executed, but it is only correct if one and only one thread is executing it. That's why Single threaded code are easy to read and debug. As soon as two threads comes into picture, It become very difficult to make prediction about how your code behave, especially in the absent of any synchronization rules e.g. rules enforced by Java Memory Model. Without JMM you can not make correct prediction about your code in a multi-threaded environment, because it's possible for one thread to stop at arbitrary point and another thread at different point. Situation becomes even more tricky if those threads are sharing data between them e.g. in form of objects, a poorly written multi-threaded program can cause deadlock, race condition and responsiveness issues, which will prevent a Java application to fulfil it's promise. I hope, in this series we can learn from each other's mistake and take a step forward on writing correct multi-threaded application in Java.
Monday, September 22, 2014
Friday, September 19, 2014
One of the most common task in any Linux is creating directories, and most of us spend a lot of time creating complex directory structure in UNIX. I am sure you know about mkdir command, we have been using this command in almost every operating system e..g DOS, Windows, Linux, OS/2, Solaris or many other *NIX operating system. It is one of the basic command but as important as find, grep or chmod. mkdir stands for "make directory" and this command is literally used to create directories. Suppose, you need to create a directory tree like /opt/software/java/app/config, how are you going to create these directories? One by one right? Well, yes you can use mkdir and command to create these directories one by one as shown in below example :
Wednesday, September 17, 2014
Conducting Interview is not cheap and costs both time and money to a company. It take a lot of time to find the right candidate for a job from 100s resume you receive from consultants and agents. They will always tell you that this guy is a Java Guru, this one is SQL Expert and next one is the full stack developer you are looking for. If you have trust them blindly and invite all of them for face-to-face interview, you are going to be disappointed. One of the first thing you should do is to filter candidates who claims to have certain skills e.g. SQL but doesn't have them, the faster you can weed out those candidates the cheaper will be the hiring process. A phone screening interview is just for that purpose, it doesn't cost you much and also suitable for candidate, as they don't have to take off and come down to your office. It's flexible for both the parties. When I phone interview someone, I spent fist few minutes to listen them and then I go for my list of weed out programming question to see if candidate is good enough to spend another 30 to 40 minutes. They have saved a lot of time, where I found out that candidate having words like "Strong knowledge of Java", "Exceptional in SQL" and "Programming gurus" fail to answer these simple questions. If you are a candidate and gone through couple of interviews, you might have noticed that almost all interviewers make up their minds in the first 10 minutes. The rest of the interview gives them reasons supporting said decision, but not all is lost. If you ever feel that you have messed up with your chance, try coming of some really good answers on rest of questions, if you can impress interviewer to an extent that encourage you to go deep, you may be able to change his initial decision. To get some feedback and improve upon my method, I have decided to share my list of weed out programming questions (don't bother about sharing questions, I have many similar questions on my secret question bank and you can create them easily as well). I have chosen one or two question from common programming skill set e.g. Java, SQL, XML, Programming, Coding, OOPS, Multi-threading and UNIX. I am looking forward to know what you guys do, what do you ask to check same skill set before calling candidates for face to face interviews. Comment if you agree or disagree.