integrating eclipse with jboss and svn

While this seems to be a trivial task for web developers working with eclipse IDE and Jboss Application Server on their development environment, there are a couple of traps I keep stubling upon. The first one is generating a war file with an empty lib directory. This happens to me with eclipse Galileo and jboss 5.1. While I refuse to upgrade both my IDE and jboss version and ultimetaly resolve the problem, I found the answer on this thread.

The thread basically proposes to change the Java output folder in your jboss server screen, close the project, reopen it, change again the Java output folder and finally redeploy the project. This solves the problem in a non-quick but for sure dirty way.

Just to add up to that thread, I noticed that the problem occured more often after I start my laptop, open eclipse and publish my project to the server. If on the other hand I start my laptop, start jboss via eclipse and then do whatever (write some code, publish it to jboss, restart the server, redeploy my project, etc) it all works as it supposed to be!

The second issue is more of a personal mental glitch rather than a real issue. It has to do with eclipse and svn locking of files. There are times where I synchronize with the repository and want to update my projects. But instead of clicking "override and update" I click "override and commit". I do not want to make other developers angry, so I quickly hit the "Cancel" button. This has the effect of locking the chosen file, not for other users but for me!

I read some threads on how to resolve this, but what worked for me is the following:

1. Close eclipse
2. Go to your workspace, one directory above the directory that contains the locked resource.
3. Rename the directory that contains your locked resource to to xxx_old
4. Take an update
5. Open eclipse and check whether its all good. If yes, delete the xxx_old dir

Thats it!

Everything is a query these days - Part 1

So you have an IT problem and you are desperate to solve it. You get some sort of error description and trying to figure out what the error is all about. Or you get a phonecall from an angry customer complaining that your application has malfunctioned. What do you do? The answer is so easy. You google it!

Today I had an issue of duplicate records in a database. My team is in beta testing right now and the application owners found out that in a particular User Interface fetchedduplicate records. In the words of IT that either means some undefined code break somewhere in the application (bad scenario) or duplicate entries in the database (good scenario). After some searching I figured out that it was the latter, i.e. duplicate row entries in a reference tables. A mysql table.

So how did I solve this trivial problem? I simply typed "duplicate row entries in mysql". And the answer was magically there:

1. Duplicate Record Detection

From a vast variety of queries, these were the simpler for a mysql database:

SELECT name

FROM emp_t

GROUP BY name

HAVING COUNT(*) > 1

Assuming here that you do not allow duplicate entries of the name column in your database.

So I performed the searches and found out the duplicate records in question. Of course the next step is to delete these records. How do I do that?

2. Duplicate Record Deletion

The funny thing here is that you do not even have to figure out the mechanics behind the fancy deletion query. All you need is a tmp table just to perform a test prior to deleting the actual duplicate records from your "production db". Easy:

CREATE TABLE emp_tmp

AS SELECT * FROM emp;

The actual delete query may be the following:

DELETE

FROM (

        SELECT t1.name, t1.id

        FROM (

                SELECT name

                FROM emp_tmp

                GROUP BY name

                HAVING COUNT(name)>1

        ) AS t0 

              INNER JOIN emp_tmp t1 

                  ON t0.name = t1.name

) AS t2 

        INNER JOIN

            emp_tmp t3 

                ON t3.name = t2.name

WHERE t2.id < t3.id;

For an sql primer this looks like a tough job. But remember its all about googling, someone else has done that for you!All you need to do is check whether the above query meets your needs, i.e. deletes duplicate records from your target table. After you make sure it works with the temporary table you created, go ahead and try it on the actual table!

Another point here is why and how duplicate records got inside in the first place. This is lack of design for sure. Duplicate records mean that someone should have put a unique integrity constraint in the fields now considered duplicate. But didn't. So get your designs right before the coding begins!

Hello World

The first program you are taught in virtually all programming languages is how to print "Hello World" in standard console. I am not going to deviate from this principle, my first article will be named after this infamous programming principle. So you get the idea. This is a blog about IT, Computer Science and Software Engineering.

Me?I am just a guy trying to write quality code. Code that gets the job done. I am lucky enough to have to deal with all sorts of programming languages almost on a daily basis. Today is C (segmentation fault, go figure). Tommorow is Java (another null pointer exception, what is wrong here?).Some other time is PL/SQL, perl, bash, little xsl, just a touch of javascript. You get the idea. 

Most of the times, after I finished typing a program, no matter how large or small, it just does not work as indented. It needs more testing. But then something gets into the way of my testing. I test one thing, and I realize I just broke the code of another module. Frustration comes quickly, followed by fear and anxiety. I am not going to deliver the module on time. What will my manager think? Or my module has malfunctioned doing nasty things. What will my customer think? What will my customer say to my manager? It is a vicious circle that all programmers have to live with.

So how can we make our lives just a bit better? By controlling our fear over IT. Acknowledging the fact that when we deal with IT, matters will most definitely go wrong at some point. But there is no reason to panic over it! No reason to be afraid that the end of the world is near, just because your program has malfunctioned to the point of -you think- no return. Most of the times, the answer to your problem is right there, staring you in the face.

This blog will serve as my personal diary of fear over IT. I want to document all the times I panicked for not been able to find the solution over an IT problem. In the years to come, I want to read these stories and laugh over my frustrations and failures. I am sure that this will make me not just a better programmer, but a better individual.

Feel free to read, laugh, empathize, comment and share your stories.