« November 2005 | Main | January 2006 »
December 18, 2005
All I want for Christmas is Oracle Lite
My current project runs against Oracle in production. And like many projects, we use a lightweight database for our local development and builds - in our case HSQLDB. Using HSQLDB gives us a very quick, generic SQL compliant JDBC-enabled RDBMS against which we can run our integration tests without the complication of having either a local Oracle install or an Oracle instance with individual developer schemas running on a common server. HSQLDB is deployed as a single JAR and is perfectly suitable for our development database needs.
However, the requirement to target another database in production is one that cannot be ignored and must be designed for from the get-go. Even using Hibernate to isolate our code from the exact database against which the code is to be deployed still requires some amount of deployment configuration to allow seamless builds for each database. At the very least, connection details (i.e., user credentials, URL, JDBC driver) need to be swapped between environments, possibly also any seed data for the database tests should non-standard SQL be unavoidable.
Given this, my preference would be to have a lightweight version of Oracle that I can use with the same level of ease as HSQLDB. A single small install would be ideal. No need for grid support, content management, data warehousing, clustering, blah, blah, blah. Just something I can point my usual Oracle JDBC driver at and which will support the standard Oracle SQL syntax plus transactional semantics.
How much would I expect to pay? Nothing - Oracle could just make it part of their full-blown server with an unlimited seat license.
Mind you, I'm not holding my breath on this one.
Note: Oracle do provide a "Lite" version of their database for mobile computing, but ready of the documentation states that it requires a full-blown version of Oracle for synchronization purposes.
Posted by Andy Marks at 11:38 AM | Comments (3)
December 03, 2005
The paradox of the TW code review
ThoughtWorks in Australia is undergoing a fairly aggressive recruiting program at the moment. We're looking for people at all levels of experience, from graduate to PM. A key component of the TW recruitment process is the Code Review, a mandatory step for all people looking for a technical career at ThoughtWorks. In short, the candidate is given a choice of technical problems, a period of a couple of days to complete and submit a solution, and then the recruitment process is continued or terminated based on a review of the submission.
Now although none of the review problems are intended to be technically challenging, many candidates fall at this hurdle based on the quality of their submission alone. I don't think I'm giving the game away by saying that the intention of the code review is to ensure people are at least capable of completing an assigned task in a reasonable period of time, and that their general level of development skills (at least what is apparent through perusal of their submission) is of a level sufficiently high to consider continuing the recruitment process.
But the twist in the tail of the code review is how people interpret the seemingly hidden requirements for submitting code to a company like ThoughtWorks. Most candidates have done the minimum amount of research to know that TW is a company happily-disposed to Agile development in some form, particularly biaised towards XP. And based on research into Agile/XP methods, many are also aware of the Do the simplest thing that could possibly work mantra...
So, as a potential ThoughtWorker working on a code review, how do you reconcile the orthogonal desires of impressing the mystery reviewer with your coding "chops", whilst at the same time paying heed to a core TW cultural value of simplicity at all costs? Which is more important? Pour the entire contents of the GoF into your code to amaze us with your pattern mastery? Or eschew all such adornments and submit a code so simple it is almost Zen-like in it's brevity?
Not surprisingly, there is no correct answer. We've had successful and unsuccessful applications with code reviews from both ends of the spectrum. From the candidates perspective, having the courage of your convictions (whichever approach you've taken) is required. And from an interview perspective, interesting questions can often be asked on how to refactor the submitted solution to a simpler or more "complex" design.
Possibly the worst solution is to not be aware of the paradox at all, which would show a lack of research into the values of the potential employer.
Posted by Andy Marks at 10:49 AM | Comments (4)