Wednesday, 15 October 2008

Preparing for the Sun Certified Java Programmer 5.0 (SCX310-055) exam

... proves in most cases to be no mean task even for experienced programmers. This is because experienced programmers tend to think that their experience would guarantee their success.

This is where exam simulators come in. Exam simulators serve as an eye opener. One such simulator is the prepkit from uCertify.

The prep kit is straightforward to download and install. And even without paying, one may access a trial version with limited features so the user can have a foretaste and know whether to pay or not. But then this decision becomes a no-brainer when one considers all the features the prepkit offers; 487 questions, structured and grouped into progressive practice tests, results of which can be analysed based on the exam objectives and so on.

One problem many prepkits have though is that they give the user a false sense of preparedness by providing relatively easy questions (compared to the exam). On the other end of the spectrum, there are others that throw otherwise fully prepared candidates into a state of panic and inconfidence with outrightly difficult questions. As an SCJP myself, I can say that there is an obvious effort in the uCertify prepkit to avoid both extremes. I am also impressed by the subsequent result analysis, explanations for answers and options and study tools like flash cards for memory, articles, study tips and notes and tools for customized tests.


Is there anything wrong with the uCertify prepkit or it is perfect, a gift from the gods, perhaps? The one thing I can say is that the first screen encountered is crowded with many possible options to click from but even that is necessary to be able to meet the needs of a wider range of users at different levels of preparedness.

My advice will be to take a deep breathe and work slowly from the top to the bottom and success on the SCJP 5.0 exam is almost guaranteed barring the little chance that you fall asleep during the exam thanks to over-confidence, 3 weeks of re-caffeinated coffee and consequent insomnia.

Friday, 28 September 2007

These Environment Variables

One of the first problems I had with Java was adding the /bin of the Java SDK to my path variable. My problem with that was that all the books I read just stated it that way without explaining how. Now, I know I look back and laugh but some newbies out there aren’t laughing so this entry will be about doing just that and a little.

When you call commands like javac, and java from command prompt, it checks a certain environment variable for the path to the actual executables you are trying to call. This variable is called the “path” and can be accessed by right-clicking on the “My Computer” from the start menu of windows machines, selecting “properties” from the context menu, selecting the “Advanced” tab from the window that pops up and clicking on the “Environment Variables” button around the bottom of that tab in Windows XP. In Vista, its slightly different; when you right click “My Computer” and select properties, a window pops up. To the right of that window, click on “Advanced System Settings” and another window pops up from which you can select the “Advanced” tab. From then on, both operating systems are similar.

On the last pop up window (after clicking on the “Environment Variables” button), there are two list boxes. Scroll through the one below and select the “Path” entry. Click on “Edit” just below that list box and two text boxes will appear. Click within the one marked “Variable value” to deselect the line (It appears selected by default) so that you can append to rather than erase the variable. Get to the end of the line, add a semi-colon and type the location of the bin folder where the Java SDK was installed. Better still, navigate to the location in your windows explorer and copy and paste the location from your address bar. On my computer, its something like “C:\Program Files\Java\jdk1.6.0_01\bin” cos I’m using the 1.6 version of the SDK. For versions 1.4 and below, it may be something like “C:\ jdk***\bin”. Click “OK”s till all windows disappear.

Setting Classpath is similar. The only difference is that there’s usually no variable called classpath (except if you or a program has added one before). The first thing to do is to check for one in the same place you checked for “Path”. If you find one, add the new classpath (a.k.a location of a class referenced in your program) the same way you added a new entry to the path variable. If there is no classpath variable yet, instead of clicking “Edit”, click on “New”. The same set of boxes will pop up and this time they will be empty. In the box marked “Variable name” type CLASSPATH and in the one marked “Variable value”, type the classpath location(s) each separated by a semi-colon.

There’s a way to set classpath at runtime as arguments passed to the Java interpreter in the Java command but I don’t know it yet.

When building certain programs, you might have to set a JAVA_HOME variable as well. Same procedure as classpath. And the location of this should be the installation folder of the SDK (not the bin, but one level above it), in my case, “C:\Program Files\Java\jdk1.6.0_01”.

When using an IDE like Netbeans (and you’ll eventually have to use one), you won’t need all this.

C’est finite, all ye budding Java developers. I started down this road myself some 12…months ago and can’t believe how far I’ve travelled. You can do it too. Don’t give up. I’m open and willing to answer all questions about anything that starts with J.

Friday, 17 August 2007

Migrating a postgreSQL database as a plain-text file

There was this postgreSQL database on a remote machine which I had to reconstruct on my local machine, the database structure and content was dumped as a .sql and I had to reconstruct from the .sql. I tried running the query file from pgAdmin's query tool but to no avail, it simply didn't work; no effect no error messages. I later found a solution which I describe below:

A database could be dumped in 2 ways; as an archive which can be restored from pgAdmin using the pg_restore tool or as a plain-text file like the .sql I had. To restore from plain-text files, one has to use psql command-line tool. For those of you using WinXP pro sp2 and installed your postgreSQL like me, here's how to do it:

Go to Start menu> All programs> PostgreSQl and select psql to 'postgres'

It starts up a command-line window already connected to a default database. If thats the database you want to run the queries on, fine. Else you would have to change the database by typing:

\c name_of_database

then you will have to change directory to the directory where your .sql resides using

\cd name_of_directory
all \ in the directory name should be typed as / cos psql is UNIX-based and would confuse windows' \ for commands. also try and ensure that file and directory names conform to 8.3 filename format. Mine did; I don't know if it will work if yours don't

finally execute the commands by typing

\i name_of_file

if you have any problems with the above procedure, let me know.