[VMware ESX SDK tutorial] First Step: Generating the JARs for use with the Java Client.

For all these examples, VMware VI SDK 2.0/2.5 is assumed to be installed. Basically, version 2.5 provides some extra features for which you may check the relevant SDK manual.

As mentioned in the first post about using VMware APIs to perform operations on the ESX Server, the ESX 3.0, 3.5 and 3i services are basically exposed as a web service defined in in one WSDL file – vim.wsdl (all names are suffixed with “25″ for the VI SDK 2.5 version). This file contains the format and definition of the services provided by the ESX Server. In order to use these services from a Java client, we need to first generate the stubs from the WSDL file, compile those generated files and then bundle those classes into a JAR. These steps are demonstrated as follows:

1. Generate the stubs from the WSDL file.

> java -Xms256M -Xmx256M -classpath “./;./lib/axis.jar;./lib/axis-ant.jar;./lib/commons-discovery-0.2.jar;./lib/commons-logging.jar;./lib/jaxrpc.jar;./lib/log4j.jar;./lib/saaj.jar;./lib/wsdl4j-1.5.1.jar;./lib/vim.jar;./lib/javamail-2002-08-28.jar;./lib/activation.jar;” org.apache.axis.wsdl.WSDL2Java -w -O-1 -Nurn:vimService=com.vmware.vim -Nurn:vim2=com.vmware.vim -o. “./vim.wsdl“

Note: Here, the current directory is assumed to be the one where the WSDL file resides. As can be seen by the notation, ‘lib’ is a sub-directory where all the requisite JAR files (for the generation of the VI SDK specific jar(s)) reside. Also note the use of the open source Apache Axis Client used to convert the WSDL definition into Java classes, specifically the WSDL2Java class. This is unbelievably convenient if one desires to generate the latest JARs instead of relying on the pre-generated JAR files in the VI SDK.

2. Compile the stubs into classes:

> javac -J-Xmx128M -classpath “./;./lib/axis.jar;./lib/axis-ant.jar;./lib/commons-discovery-0.2.jar;./lib/commons-logging.jar;./lib/jaxrpc.jar;./lib/log4j.jar;./lib/saaj.jar;./lib/wsdl4j-1.5.1.jar;./lib/vim.jar;./lib/javamail-2002-08-28.jar;./lib/activation.jar;” com\vmware\vim\*.java

Note: The package structure can be clearly seen in the command above – com.vmware.vim. This is the general package structure for the VI SDK API classes.

3. Generate the vim.jar (or vim25.jar) file:

> jar cf ./vim.jar com\vmware\vim\*.class

Note: This bundles all the required class files into a convenient vim.jar file. The most important point to note here is that even after generating the vim.jar (or vim25.jar depending on whether you are using the VI SDK version 2.0 or 2.5), all these JARs are still required to be in the classpath of the application:

axis.jar, axis-ant.jar, commons-discovery-0.2.jar, commons-logging.jar, jaxrpc.jar, log4j.jar, saaj.jar, wsdl4j-1.5.1.jar, javamail-2002-08-28.jar

So there you go – these three simple steps (which can be automated in a simple script) are all you need to get your hands on the tools to start hacking on your ESX Server.

In the next tutorial, we’ll take our first baby steps into actual usage of the APIs and a bit of theoretical explanation is also in the offing.

Peace!

Hasta la manana

I meant tomorrow.

Back from blogging break

Phew! It seems like ages now when I take a look at my last post. I had laid out a pretty comprehensive charter for the VMware ESX Server operations tutorial series and yet due to unforeseen circumstances, I had to lay low for a while. To cut to the chase, I will complete the entire series in one fell swoop starting tomorrow. I just need to get my bearings right and fulfill my promise before leaving on a trans-Himalayan trek . Have fun and thanks for the patience!

Respect.

A programmatic approach to VMware solutions: Part 1

This is the first of a series of planned blogs pertaining to the use of the VMware SDK APIs to seamlessly exploit VMware ESX Server services programmatically.
This is the result of the experience that I have gained by working on a live project to provide VMware support to an existing Java-based enterprise software product.
An early disclaimer is highly in order: All these examples are idiomatic and do not relate to the actual code used in the aformentioned product. Phew! Now that we have got that out of our chest, let’s proceed onto the meat of the matter directly.

The roadmap of this tutorials series is roughly sketched out as follows:

Part 1 – Introduction to VMware and definition of the scope of the tutorial.

Part 2 – The VMware ESX server service exposed as a web-service, brief discussion of the WSDL file, generation of the required JAR files for the Java client.

Part 3 – Introductory code samples – logging on to the VMware ESX server, connecting and verification of session.

Part 4 - In depth discussion of Raw LUNs and VMFS disks and their applications in industry. Technical differences and varied approach in code.

Part 5 - In depth discussion of the VMware ESX Server SDK.

Part 6 - Continued discussion on the VMware ESX Server SDK.

Part 7 - Concluding session on the VMware ESX Server SDK.

Part 8 – Operations on the Virtual Machine -code samples.

Part 9 - Operations on the ESX Server (Host) – code samples.

Part 10 – Operations using the VMware SDK APIs specifically for the Storage domain – code samples.

Part 11 – Threading, concurrency and gotchas while using integrating the VMware programs with existing products.

Alright, so that is pretty much the road ahead. More sessions can be charted out based on feedback. Any specific operations can be discussed in-depth in future blogs.

Introduction to VMware:

VMware is a virtualization software which basically comes in two flavors – desktop and enterprise. In this tutorial series, I will be dealing with the enterprise server solution – VMware ESX Server and how to write programs to access the services provided by the server, which can be integrated with enterprise solutions. I will be using Java as the client language throughout this tutorial. This is not a series where the internal details/ performance statistics et cetera will be discussed, as also the relative merits of VMware with respect to other virtualization software. Those topics will be, at best, touched upon and skimmed through. Now there are enough resources to implement client programs to avail of the services exposed by the VMware ESX server but not nearly enough resources which show how to actually go beyond writing mere scripts and actually create enterprise ready VMware solutions. More details can be availed on the VMware site or better still, on Wikipedia.

As I have mentioned already, I will not be delving too deeply in the specifications of the ESX Server. Such information is widely available (though the VMware site documentation, in my most humble opinion, sucks!) on the Internet.

That’s all for part 1. The next session is shortly forthcoming. Till then, peace!

William Reardon’s rant against Scribd – justified? I think not.

Hilarious. Ludicrous. Ridiculous. Nefarious.

Four words that came to mind when I chanced to read the comments section of this blog. I had posted a comment on it around a month back. It is William Reardon’s (I have no idea who he is) allegedly technical blog and this particular one was one denigrating and denouncing Scribd. I was amazed at the bilious and vicious wording of the blog (maybe he was pissed off at something?) and more than that, the lack of any justification for his rant irked me tremendously. I promptly stated the fact that the site did indeed provide a way to store files as PDFs (which the author had vehemently denied) and also that it was quite a pointless blog. What happened next is there for all to see in the comments section. One thing is for sure – whatever respect I could have had for the author was quickly dissipated within the first two paragraphs. I guess the author had forgotten that noblesse oblige applies to all. Even programmers.

Goof-off Day

That is right. Today is officially ‘Goof-Off Day’ for me. The title may be slightly misleading in that it implies a deliberate attempt at mooching off a fine wednesday work day. In fact, if it were indeed a story right out of The Daily Wtf, it would definitely be so. However, I reiterate (at pain of sounding redundant but it’s just the goofing-off potion at work) that it is a natural progression of events.  Now onto a more serious discussion of this phenomenon.

In every workplace, but especially in an industry placing so much emphasis on “thinking”, it is inevitable that every so often, even the most assiduous mind-worker has to take a break. No compulsion, no rebellion, no coercion. Our industry is characterized by periodic variations of extreme stess and complete leisure (with a general slope of gradations in between of course but not so pronouncedly as the two end-points). For a complete and statistics-backed analysis of such matters pertinent to Software Management, what better resource to point to than Peopleware. I first came across this title when I was reading through the interesting (but not so useful – my opinion strictly!) book called Smart and Gets Things Done: Joel Spolsky’s Concise Guide to Finding the Best Technical Talent . He had highly recommended this book but the title of the book put me off initially. It reminded me of those weird and untractable academic Software Engineering books from my college days. I hated them. I positively despised, abhorred and reviled them. In hindsight, my revulsion seems to be justified as I am yet to see one positive use of anything mentioned in those fat books. The one and only Software Engineering I would recommend is The Mythical Man Month. And now, Peopleware. You had better go read that book. Now.  Afore you get mired in this goofy business! As I was saying (pray, indeed this is a day for digressions!) every software engineer inevitably finds that he needs a day now and then to just plain do anything but his main work. It can be anything - chatting, surfing, going to the gym, dozing off in the dorm, writing blogs (as I am doing right now!), catching up on news, handling personal calls (which I am definitely not doing right now), going out for a stroll, playing some football (that’s soccer for you Uncle Sam), planning for the evening ahead, meditating or just plain staying in stasis like a zombie (nothing different from the status quo for some). To demonstrate what I mean, let me recount the activities that I have engaged in today - in strictly chronological order:

1. Reached office… made my favorite cup of stomach-burning black coffee… glanced at the headlines.

2. Logged onto system… checked mails for half-an-hour… checked calendar for any meetings.

3. Switched on GTalk, Jabber, MSN Messenger… most folks are green! (how ironical in some ways)

4. Turned JBuilder on… stared at the code that I had been hacking yesterday… closed it immediately.

5. Started two chat boxes… reddit, the daily wtf, new.google.com and youTube… looks promising!

6. Some snide remarks in reddit… messaging some ’special’ ladies… complaining about the A.C.

7. Discussed Wimbledon with a friend…tried an archery MS-Excel game…tried turning JBuilder on…again.

8. Ran yesterday’s code…crashed the JVM… end of line for JBuilder for today… cleared teammate’s doubts.

9. Called up a few friends…planned for the evening…got to beat the traffic early.

10. Reminisced on the mysteries of life…no answers…forget it… let me go for a nice stroll.

11. Lunch done… cannot work now! …listen to cranium-cracking music for a while (read: an hour).

12. Too tired to work…coffee downstairs with a friend across the floor…the usual banter.

13.  Seems like I’m goofing off major today…well, maybe I deserve it!…hey, I could write a blog on that!

And here I am – eating ten minutes of your time to compensate for the day that I have mooched off… and enjoyed! Tom and Timothy (of Peopleware fame) would certainly approve! The fact is that it is inevitable that one has to just do anything but that which brings in the moolah at the end of the month. In some ways it clears up the head, refreshes the spirit and also it is healthy to take a break on official time! Try it out… works wonders… and the fact is, if you tell me that you do not mooch off at all – I’ll show you a horse that can bark in German!

So folks, how do you goof off your day?

Does this pass for a workplace? No, seriously!

I may be going out on a limb here folks but bear with me – the situation lends itself to such a treatment. As a disclaimer, all proprietary and personal pointers have been duly elided to protect the privacy of the parties involved. This should not be misconstrued as a mere rant. It is not. This should be viewed as the exasperated response of a technologist who’s had it with these pseudo-managerial passive-aggressive type weirdos who shamelessly flaunt their lack of tact and the distasteful overindulgence in wannabe corporate-speak but which ultimately strangulates them in a pile of meaningless rhetoric and makes them appear like a PHB fanboi. It is. Trust me.

I believe a bit of information about the parties involved would be highly useful. Let’s start with me. I am a technologist (ain’t that classy-sounding?) who loves to code and who believes undue processes only hamper the simple, beautiful and elegant flow of the whole software cycle. Not that I am against all processes – I’ll gladly eschew them till I take reins as a manager myself (in a “proper” management-oriented company, not any software company). Call me ‘z0ltan’. Then there is this colleague who does programming because it is part of the job. Duh! Moreover, she fancies herself as a future manager par excellence (well, in the spite department she is already there!) and thereby has more faux pas than Dilbert’s boss on a bad hair day. Oh, by the way, she has ‘over’ three years experience more than I do (gosh!). Let’s just refer to her as ‘Wannabe’. That brings us to the third and youngest actor – a fresh, impressionable and totally stubborn ‘n00b’. That sounds fine. Finally, there’s ‘Gandalf’, the venerable and highly experienced technical lead. There you go, onto the play itself!

Title: Wherefore thy aggression whilst I prefer thy passion?
( A play in three parts )

Act I, Scene 1 – The n00b asks for information. Innocent enough.

From: n00b
Sent: Thursday, June 26, 2008 9:01 AM
To: z0ltan
Cc: Gandalf);n00b
Subject: Regarding VMWare GUI

Hi ,Can you please share the %%%%%%%%%%% Server related files that you have created (specific to VMware support)? It might be needed in developing some parts of the GUI.

Eg: I see a need for files like ############## (the one similar to @@@@@@@@@@@@@@@ ) etc.

Thanks,

n00b

Act I, Scene 2 – z0ltan responds with the requested information.

From: z0ltan
Sent: Thursday, June 26, 2008 9:10 AM
To: n00b
Cc: Gandalf, n00b
Subject: RE: Regarding VMWare GUI

Hi n00b,I have added over 30 files in my private view to date. If you could be more specific as to which files/ method information you require, it would be more convenient. As far as I am aware, the !!!!!!!!!!!!!!!!!! file is the one which is definitely required by GUI. Please to specify any other files you might require.

Regards,

z0ltan

Act I, Scene 3 – n00b responds.

From: n00b
Sent: Thursday, June 26, 2008 9:59 AM
To: z0ltan
Cc: Gandalf, n00b
Subject: RE: Regarding VMWare GUI

Thank you for the quick response. I will get back to you if I figure out the need for any other file(s).Regards,

n00b.

Act II, Scene 1 – Wannabe jumps into the fray

From:n00b
Sent: Thursday, June 26, 2008 4:04 PM
To: n00b; z0ltan
Cc: Gandalf)
Subject: RE: Regarding VMWare GUI

z0ltan,

I would request you to share the list of files you have added. Usually the Server & GUI team work together to have a holistic view of the feature. Instead of the GUI team asking the Server team on request basis, it’ll be helpful to us if you can let us know the list of files you have added in the Server. Since n00b is develping the GUI for the first time, it’ll help her to a great extent.

Also in future we request you to keep us updated through mails on the status of the server development especially if you deliver some feature ( like CLUI for VMWare ), make any deisgn changes, update any files used by GUI etc.

- Wannabe

Act II, Scene 2 – z0ltan responds to passive-aggressive thrust by Wannabe in similar satiro-sarcastic tone.

From: z0ltan
Sent: Thursday, June 26, 2008 4:28 PM
To:n00b; n00b
Cc: Gandalf)
Subject: RE: Regarding VMWare GUI

Hi Wannabe,I fully appreciate the point that you have raised. However I do believe such a holistic approach will work only when the pertinent persons sit together and update one another about their progress/ concerns.

As far as I can recall we had decided in the previous meeting that we would have regular scheduled meetings but that did not seem to materialize. I am open to anyone scheduling the meetings.

I believe that is the best way to really garner updates on the feature. I do believe it is incumbent upon each of the feature implementers to partake of this responsibility.

I am not very much aware of the GUI requirements and thus I have been sharing all the information that have been requested of me. The number of files that have been added/ modified as well as checked out is quite considerable as well the amount of time available and as such does make constant communication on the modifications/ additions feasible. I do believe that exact requirements of the GUI are best known to the GUI folks. Discussing these in the aforementioned meetings would be the optimal way in my opinion. About the other points that you mention, I am always available to help not only in understanding of the feature itself but also on other aspects like design, feasibility of implementations et al. No one need feel constrained to approach me. As I have already mentioned, this whole feature is quite time-consuming because of the nature of the feature itself. I am sure we all appreciate that the RSM architecture does not lend itself to easy integration. Till such time as the code is stabilized enough, I cannot really commit myself to the changes that have been made. I do hope you appreciate this fact.

As far as the current state of changes is concerned, I will send the whole list of modified files/ new files by tomorrow. I hope that helps.

Regards,

z0ltan

Act III, Scene 1 – Gandalf jumps in and shows real tact in dissoluting the tension with a simple, direct approach.

Thanks everyone for sharing your views. I see a communication gap here. Let us fix this issue here itself.If you remember, we used to work on the common branch and with that we never had any issues. I think n00b can adapt to that. Since z0ltan is still developing it may not be very stable.But she can proceed with her work and if there are any issues we can fix it.

If this approach is not working we can discuss and decide how we can proceed.

Thanks

Gandalf

Closing comments:

The interesting part is this – If I look back now and read through this blog and compare my emotional response to the one I had when the incident occurred first, I am amazed at the difference that I see in my own judgements. At this moment, I would not consider the situation as horribly messed up as I had felt at that time. One reason is the passage of time and the change in conditions. Apart from this, for the reader, the context might be lost to a great extent. So before anyone goes “Oh! This is no big deal! Just a simple exchange of formal intra-team communication”, I would like to put things in perspective. Here we go:

Imagine yourself being given a considerable amount of responsibility in the upcoming release of the product. Say that responsibility is supporting your product on the VMware Enterprise Server platform. To have an even rummier time, consider that your product is not exactly amenable to conglomerating with such drastically different architectural models. Also assume that you have given prior notice to the team on the amount of effort and time it will entail (safely downplayed by the technical lead as well as management). Being the young, restless and bring-it-on kind of programmer (after all, the second youngest in the whole team!) you take up the challenge and work your backside off for a couple of months and ultimately prove through a POC (Proof of Concept) that the whole shenanigan will work after all (one reason why the technical lead did not take up the task himself was because he was certain it was not feasible!), you are faced with the task of integrating your code with the team product. Again, in a Dilbert-esque fashion, your estimation of the coding and testing effort is downplayed by the whole senior players in the team. Worst of all, you have to depend on the GUI (Graphical User Interface) team (read Wannabe, n00b) who are loathe to start work on it until the last minute. Again consider that Wannabe brings up her own confabulated Design best-practise (’The Business Logic (Server) should decree the structure of the GUI(frontend)’) whereas even to a relatively new programmer like me (perhaps I need to be grateful that it is so?) it should be the GUI driving the design of the Server. The unkindest cut of all is that Wannabe is someone who, while I am hardpressed to take even a day off, barely makes it to office twice a week. Twice. No questions asked, no reasons given. Need I say anymore than this – scroll up and read the whole play again and if does not make any sense to you, probably you should not be reading beyond this line anyway!

Respect!

The true raconteur and I ain’t talking about Feynman!

Feynman has often been described as a raconteur and I am sure he deserves that epithet without me justifying it or otherwise. The reason he was called so was because of his extremely direct manner of explaining, in the simplest of terms, some of the most complex concepts of advanced physics. His video lecture series was one of those myriad events which further reinforced his stature as a clear-headed genius. Now, that is not as trivial as it may seem at first. In my opinion, and arguably in an objective sense as well, the true measure of genuine understanding of any subject is the ability to express it without equivocation or self-doubt. No doubt eloquence, directness of approach and pithiness are characteristics which are often innate (and cultivable to a great extent through practice) but these attributes notwithstanding, the skill to present the matter at hand in a fluid and intelligible manner – caressing the topic with the confidence and prowess of a professional and actually putting forth all the salient points without diluting the content, is true raconteurism. Feynman was adept at that but recently I discovered another genius who actually surpasses him in this regard. Come forth, Joshua Bloch!

To the true technologist, Joshua Bloch requires no further introduction. He is the master and creator of the Java Collections framework (which is one of the finest components of the Java platform), the java.lang.Math package, the ‘assert’ mechanism (amongst others) and indeed has gone on to greater stature and achivements as Principal Engineer (with special emphasis on being the Java guru in-house) at Google. I had heard of him before through his publications such as Effective Java, Java Puzzlers and Concurrency in Java and yet had never had the inclination (call it laziness if you will) to actually read past the titles. The thought that came to my mind was “Yet another Java book… how many of these darned things am I supposed to read before I actually master this constantly mutating platform?”. This bring to mind another powerful concept that made sense to me long after I had been exposed to it. It is called the ‘Paradox of choice’. The video is available here. It is an excellent talk by Barry Schwartz. Quite non-technical but I feel it has begun to be more pertinent to this industry than any other (and will only continue to be more so!). As it so happened, one lazy afternoon when I was casually browsing through some Google Techtalks online, I came across this rather innocuous sounding title – “How to design a good API and why it matters”. It would be a whole six months before I would watch that video!

When I finished watching that hour of pure technological operatic genius, my first reaction was that of dejection. Yes, dejection at seeing the video end so soon! The whole hour had gone off so smoothly and everything in the meantime just made such clear sense that it was nothing short of amazing. I had been deeply engrossed in some major coding work in my current project and wished that I had seen this video two months back! Uncannily though, I discovered, to my own smug contentment, that I had already followed most of the principles that were enunciated in the talk. Some of the pertinent points that he puts forth are as follows and struck me as particularly useful are as follows:

1. Whenever in doubt, leave it out!

This makes perfect sense. As he says, every programmer who develops at least a module is an
API developer because the methods and the public components of his module form the contract
for any clients that actually use his module. This maxim follows the logic that a component can
be added to an API later on, but can never be removed without breaking
existing functionality.This also implies that any ‘doubtful’ functionality can always be harnessed
on later.

2. The ideal size for a method paramater list is three or lesser. If there are more, split
them and/or use helper classes

The example that he provides (of a Win32 API call to draw a simple window) in the video says it
all. I found this principle very useful (in retrospect) when I was designing my modules (I will
have a series of blogs on that very soon) and was often in a bit of a quandary about the exact
scope of my utility methods. The requirements at that point of time were pretty
much solidified and yet the use-cases were not yet finalized. So it was more of a trade-off
between usability and genericity which leads us straight to the next
point.

3. If the API makes everyone equally happy and leaves everyone equally unsatisfied,
it’s done its job

It’s always a tight balance when designing an API – whether to make it extremely powerful (and
invariably for a select group of stakeholders) or to make it powerful enough (and
thus for the majority of the stakeholders). The latter is always preferred irrespective of the
scope of the applicability of the API. The case which is moot in this regard is the VMware API -
generic enough to be almost bloated and yet powerful enough to be used by any client. More
on the VMware APIs in upcoming weeks.

4. Exception handling is not just an escape mechanism but a means of controlling
the system flow

Now this is one part of the talk where Joshua could not allocate any time at all. Considering
that the whole hour-long talk was filled with absolutely no pauses and no wastage of time, this
goes to show how the topic deserved more time than the standard hour allocated for Google
Techtalks. Nonetheless, in my current project, this was the hardest nut to crack. Exception
handling is an even finer balancing act than the design of the contract of the modules (i.e., the
methods) as there is a huge state-space of possible control flow/ processing paths. The sad
truth is that this is often the part which is most often neglected. I, however tried to have a
fairly robust and generic mechanism whereby there was a Exception class
with a corresponding ERROR code interface, which was placed in a common module so as
to allow clients to access and throw specific error codes. The level of granularity is still being
refined as I find more use-cases and corner-cases. In my opinionated opinion, the design
of the exception handling mechanism is the true measure of good or bad design.

5. Document! Document! Document!

Joshua recommends documenting every class (what an instance of it represents), every method
(this forms the contract of the class after all!), every parameter and return type (mentioning the
types and units of the parameters). How important this is can be estimated by this
example – In my current project, I have over 400, 000 lines of Java code modularized into a
dozen projects and hundreds of packages and sub-modules. The real eye-opener is that there is
absolutely no documentation whatsover. Okay, that sounded harsh. Let me rephrase it thus -
There is not a single line of useful documentation. If it were not for my considerable
intellectual gifts and a generally consistent design, it would be impossible to decipher the whole
mish-mash much less augment the functionality!

6. Watch the video paisan!

In closing, I could go on about how profound my experience was watching this video and I could ramble on about about the merits of the whole experience (gosh, it’s almost sounding like I had a technological seance… which wouldn’t be far from the truth! ) but this post has already gone on too long and I am tired! Just kidding… I am busy in my epiphanic reading of ‘Effective Java’, ‘Java Puzzlers’ and ‘Concurrent Programming in Java’. Peace!

This is indeed worthy of thedailywtf.com

So here I am, victorious at last after two agonizing days of waging battle against what seems trivial in hindsight (and is indeed trivial in truth!). Two whole days of flirting with a simple logically illogical mess created by, surprisingly, not SQL but by my official tool and favorite punch-bag, Java!

This just goes to show that the more banal the bug, the more anguish and torment that it causes! In the end, the problem turned out to be so ridiculously obvious (again, in hindsight) that I wonder if this indeed even wtwtf! … Well, I cannot recover those two days of wasted effort (well, actually partially wasted as I did a lot of bypassing around it and could well afford to, since I am working on a huge feature for my product) but I can  at least try and salvage some honor from this humbling experience. Here is the code snippet (redacted for reasons twofold – proprietary software and ease of reading. The spirit of the mind-numbingly irksome bug still remains) :

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.sql.DriverManager;

public class StructuredQuirkyLanguage {

	public static final String VMSERVER_TABLE_NAME = "VMServer";
	public static final int VMSERVER_ID = 0;
	public static final int ENCRYPTED_CREDENTIALS = 1;
	public static final String[] vmServerColNames = { "id",
			"encrypted_credentials" };

	public static void main(String args[]) {

		String tableName = VMSERVER_TABLE_NAME;
		String columnName = vmServerColNames[VMSERVER_ID];
		String updateColumnName = vmServerColNames[ENCRYPTED_CREDENTIALS];

		String encryptedCredentials = "3C8C537B6F88501F";
		String vmServerSystemIdString = "cba73408-261f-47c8-9e15-83f1c4c74598";

		encryptedCredentials = "\'" + encryptedCredentials + "\'";
		vmServerSystemIdString = "\'" + vmServerSystemIdString + "\'";

		String updateSql = "update " + tableName + " set " + columnName + " = "
				+ encryptedCredentials + " where " + updateColumnName + " = "
				+ vmServerSystemIdString + ";";
       try {
		 Class.forName("solid.jdbc.SolidDriver");
       } catch (ClassNotFoundException cnfex) {
    	   cnfex.printStackTrace();
    	   System.exit(-1);
       }

		String databaseUrl = "jdbc:solid//localhost:1315";
		String username = "dba";
		String password = "dba";

		Connection connection = null;
		PreparedStatement stmt = null;
		int numRows = 0;

		try {

			connection = DriverManager.getConnection(databaseUrl, username,
					password);
			stmt = connection.prepareStatement(updateSql);

			numRows = stmt.executeUpdate();

			if (numRows != 1) {
				throw new SQLException("Could not update the database");
			}

			connection.commit();

		} catch (SQLException sqlex) {
			sqlex.printStackTrace();
		} finally {
			if (connection != null) {
				try {
					connection.close();
				} catch (SQLException sqlex) {
					sqlex.printStackTrace();
				}
			}

		}
	}
}

So let it be known that that was the last and final humiliation of z0ltan by anything lesser than z0ltan…. well, at least till next monday!

Fist!

(Note: The real wtf could be that you could fall for the same trap! See if you can find the problem. And oh yeah, the error dump wasn’t very helpful either -
[SOLID Table Error 13037]: Illegal DOUBLE PREC constant

Happy? HOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHO

*wtwtf = worse than ‘worse than failure’!!! You saw that one coming, didn’t you?

A few tech blogs that I really like (or have liked… and maybe will like!)

I do my usual stuff at work as a programmer – snooze, code, get high on coffee, sink low on morale due to lack of a decent pool table (and maybe a pool to boot!), self-immunize against weird teammates, vilify moronic management, rant about non-functional AC and the dysfunctional personal life, get hot and cold in the face in the course of the same discussion with a colleague (kinda reminds me of that episode of “Friends”…you know, the one with Chandler (a.k.a Toby) and Bob, especially the part where he trashes his own place), muse aloud on the merits of Design Patterns without actually having an opportunity to use them anywhere at work, crib about cafeteria food, ogle at the usual suspects (a rare and fast disappearing breed), have my concentration destroyed by the blinking chat boxes (I wonder why I never resolve to logout of them?), swivel around on the perfectly unergonomic, back-sweat-inducing chairs, channel mind-numbing 120 dB music pounding through the cranium via the headphones, read proggit, download petabytes of work-unrelated software, print enough copies to supply the Yomiuri for a year, harvest enough E coli in the loo (and more in the e-cafe*) to provide my physician with a spanking new Porsche( remember that episode in “Friends” where Joey assembles a load of cartons to simulate a Porsche to impress the ladies?**), have way too much time on hand to be writing this blog in office, astutely (and dispassionately) observe my IQ take such a negative exponential drop as to make the Stock Market seem a mere candy shop, give in to the the (yes, stuttering here with Diabeticistic Excitement Reverse Palsy or DERP***) rabid urge to stop here for fear of dropping the aforementioned curve to negative… *snip*

Here are some of the blogs that I do read to ensure that I remain clinically insane and soporifically unchallenged. Pop the cervezas d00ds!

Steve Yegge

Raymond Chen

Steve Vinoski

Marc Andreessen

Joel Spolsky

Timmy z0ltan Jose

Hahahaha… gotcha! The last one is the one that should have come first! Alright… not yet!

Have fun. Or at least a muted semblance of the shaded precursor to the imaginary fabric of the bleary facade of the pale illusionary imagination of wistful fun. That a deal?
Excellent!

(*A pejorative, debasing, denigrating, derogatory, dubious, grotesque, degrading, jocular, insipid and gut-wrenchingly disappointing euphemism used for a room with chairs, tables, a water-cooler, two coffee-machines, a wash-basin and on a statistical average – four imbeciles.)
(** It seems to me that the show “Friends” has so explored the nooks and crannies and nuances of relationships that almost anything that one comes across can be connected in some way or the other with some incident that was depicted on that epic sitcom. Hmmm… nice, spanking new theory. Interesting. Wait for updates on this one.)
(*** Naaw, just messing with your mind… oops! brain… dang! neuron (?))