July 19, 2005
July Sydney Python Meetup
Don't forget that the July meetup of the Sydney Python group is on this Thursday. The venue once again is the James Squire Brewhouse and the fun starts at 6:30pm.
Posted by Andy Todd at 11:49 AM | Comments (1)
Using the Oracle Thin JDBC Driver from Jython
I've got precisely one piece of code to write for my current project. Luckily for me I can write it in Jython. This means I need to learn it. Step 1 is connecting to our Oracle database. Because the server the code will work on already has the JDBC drivers installed I can just call them from my Jython code. Looking around the web I couldn't find any sample code though, other than this example in proper Java. So here's my version, using Jython 2.1;
from oracle.jdbc.driver import OracleDriver
from java.sql import DriverManager
def connect(un, pw, sid, host, port):
driver = OracleDriver()
DriverManager.registerDriver(driver)
connection = "jdbc:oracle:thin:@%s:%s:%s" % (host, port, sid)
conn = DriverManager.getConnection(connection, un, pw)
return conn
def doStuff(conn):
stmt = conn.createStatement()
rset = stmt.executeQuery("SELECT banner FROM sys.v_$version")
while (rset.next()):
print rset.getString(1)
stmt.close()
if __name__ == "__main__":
un = 'scott'
pw = 'tiger'
sid = 'orcl'
host = 'localhost'
port = '1521'
conn = connect(un, pw, sid, host, port)
doStuff(conn)
Posted by Andy Todd at 11:32 AM | Comments (3)
July 12, 2005
On the Ubiquity of Excel
Excel is great. It is, as Joel Spolsky keeps telling us, the king of spreadsheets. And I agree with him.
As a matter of course I don't use it at all at home, as I don't have any licenses for office. I do use it at work though, but as with any tool I make sure to use it only where it's applicable.
Like all good software, it gets used in situations where it really shouldn't. The main reason for this in Excel's case is that it's a great way to store semi-structured information. Lists of things are hard to maintain in Word (most people's other weapon of choice) and with Excel you get sorting and filtering thrown in for free. Of course this is the tip of the iceberg. Because Excel doesn't scale well or easily adapt to changing requirements.
There are a couple of cases in point on my current project.
The system test bug (issue/opportunity) list is being maintained in an Excel spreadsheet by the test manager. This is bad in a couple of ways. Only one person can practically look at or amend it at once so there is little or no access control, meaning that anyone can be the 'one' person that edits the spreadsheet at any time. Because it's in Excel there is no version history.
Luckily they have "solved" the last two problems by mandating that anyone who changes the bug list in any way has to save a new copy with a filename that includes today's date and their initials. Can anyone else see the drawbacks in this approach? I did ask, just to be awkward you understand, what date a certain issue was last updated. Surprisingly enough it took an awfully long time to find out.
The other problem this raises is when the requirements change. Initially the test manager just thought he would like to know which issues were open and which closed. It very quickly became apparent that it would be useful to know which problems were being tackled by a developer, which were waiting for re-test and which weren't bugs so much as change requests. So another column was added to the worksheet, but because it was just another Excel column there was no rhyme or reason to the values that ended up in it and it manifestly failed to serve it's purpose of being able to group issues in a like state.
The other major failing of this particular spreadsheet, and it's in the implementation not the tool used, is that they don't link issues to the particular versions of source code that have been changed to resolve them.
Needless to say I didn't want to include my team in this use of inappropriate technology. We're using Subversion for version control and I convinced a colleague to install Trac on the same machine. I'm using it's ticketing feature to log and manage all of our system testing issues. It's not perfect, although the features coming in versions 0.9 and 1.0 will get it very, very close, but it's a chauffeur driven limousine compared to the unicycle that is the Excel solution.
Our other major use of spreadsheets on the project is in the data entry system. We have some obstensibly straight forward data entry requirements, which involve quite large volumes of data. So we've produced some rather nice spreadsheets which download basic information from Oracle, allow the user to add pages and pages of detail and then upload it back into the database.
At first glance this requirement just screams spreadsheet. Until you start adding some very stringent data integrity and validation rules. Then things start to get a bit scary. Because we end up replicating large parts of the (quite complex) data entry screens provided as part of the packaged application.
The problem here is that Excel doesn't lend itself to tied down data entry. It's strength is that worksheets are free form and allow you to specify your own formulas and manipulate information as necessary. In an ideal world we would provide a template and then convert the worksheet to a comma seperated file which would be extensively validated as it's uploaded.
Sadly the other requirement which mandates the use of Excel in this circumstance is that the data (including all of it's complex validation rules) need to be available to users who aren't connected to the network. So we're stuck with developing a standalone .EXE or giving them a spreadsheet.
So whilst we've produced an enormous amount of code that replicates standard functionality with all of the risks that entails. But given the skill set we have in the team I don't see a viable alternative. Any suggestions?
Posted by Andy Todd at 10:14 PM | Comments (2)
July 01, 2005
Python Cookbook
I've recently finished reading the first edition of the Python Cookbook, just after the second edition has been published. I'd actually bought this book when it first came out, but it has been sitting in my to read pile for over two years. In my defence a fair portion of that time was because we were in another country and it was in storage.
In summary it's a great book, indispensible to have around when you are actually doing any Python programming.
The book is a collection of programming recipes, collected from people who use Python in a variety of situations and for varied purposes. It therefore reflects the best practices of the community garnered from many years of experience. The key to a book of this nature is good editing, selecting and weaving the best contributions from a number of different authors into a series of coherent chapters. Luckily messrs Martelli and Ascher have done a sterling job here.
Nothing jars, and reading each chapter you could be forgiven for thinking they were written by the same author.
My test for technical books of this nature is whether they make me think and then want to try out the ideas they are discussing. At least once in each chapter I found myself reaching for the keyboard to try out a command or a technique. I'm sure this book will be a valuable companion whilst I'm knocking out my half cooked code.
If I had to point out a deficiency it would be in the User Interface chapter. The samples there seemed to be a little disjointed and flitted around what is admittedly a very large topic. I would perhaps have concentrated on showing the same implementation in each of the different GUI toolkits, highlighting their different approaches, or possibly left any mention of GUI techniques out at all.
I'm sure that the 2nd edition will be even more valuable as it's been extensively re-written to take into account improvements in the language and libraries and to cover more topics. I just have to save my pennies to buy a copy.
Posted by Andy Todd at 01:17 PM | Comments (0)