Netuality

Until now, I've always had a certain respect for Sybase database.
Based on their history, I thought that the product is a sort of MS SQL
without the glitzy features - think Las Vegas without the lights, the cowboy boots and Eiffel Tower. Which gives: huge crowds of fat tourists in tall, dull buildings. But you always have Celine Dion, right ?*

Wrong ! Sybase ASE is a large, enormous, huge piece of steaming …
ummm … code. Ok, ok, I'm a bit over-reacting. In fact, Sybase is a
very good database - if you are still living in the 90s and the only
Linux flavour that you are able to manage is RedHat ASE. Otherwise,
it's a huge … you know.

Let's not talk about the extreme fragility of this … this product.
You never know when it crashes on you without any specific reason.
Sometimes, it's the bad weather. Crash. Restart. Sometimes, you
flushed twice. Crash. Restart. And maybe, yes maybe, you spent more
than 12 minutes in your lunch break. Crash.

Let's just talk about the JDBC drivers - latest version, downloaded
from the site in a temporary moment of insanity. Man, this is cutting
edge. The sharpest cutting edge you'll ever find - the more advanced
JDBC drivers bar none ! Excepting of course the fact that these
classes were compiled in that memorable day of 6 January 2002 [the day
when the last Sybase JDBC drivers were compiled]. But, don't let such
obscure details ruining your enthusiasm. Just download and use them
and you'll be amazed at their unique features - it's the only JDBC
driver which manages to put down DbVisualizer in different and
innovative ways. I'm restarting the poor thing (dbvis) at least 2 or 3
times per day, when working with Sybase.

Also, as a little quasi-undocumented tip, the letter d from
jconn2d.jar does not mean development [drivers] as some of you would be
inclined to think. In fact, it means debug which is the
abbreviation for put me in production poor lousy bastard and I'll
start spewing reams of useless messages through all the logging APIs
known by man and a few yet to be discovered, therefore instantly
slowing down to a crawl your puny little software.

Ermmm … well, all this nice introduction just to humbly confess that
we do have a couple of them Sybase licences floating around here and
some of our production databases are on Sybase ASE. While I can assure
you that this is going to change at least on the web backend, it's
also true that the beast must be alive in order to keep our company up
and running. And, that's part of my job.

Which is of course very strange for an IT management job. But then again:
when your sole DBA is overwhelmed by a horde of Sybase-specific tasks
(like for instance the log configured to truncate at a specific
threshold which naturally [for Sybase] does not truncate, suddenly
throwing all the users into log suspend in the middle of the peak
production time) - you have to enter into the damn kitchen and do some
cooking !

My endeavour was to perform simple data mining in order to migrate
some reports from a legacy system [no, you don't really want to know
what system]. Due to my limited time, starting a mildly complex Java
reporting project was out of the question, so a scripting language was
the natural choice. Python being the first option - unfortunately,
finding a working Sybase driver for Python is a challenge in itself.
But, thank God for Jython and zxJDBC ! In just a few minutes I was
wiring the tables for reporting. Here's a fake code snippet which lists the 'orders' with amounts < 1000, and you can't go any simpler:

from com.ziclix.python.sql import zxJDBC 

conn = zxJDBC.connect("jdbc:sybase:Tds:myserver.mydomain.com:4110/mydb",\
	"user","pass","com.sybase.jdbc2.jdbc.SybDriver")
cursor = conn.cursor() 

cursor.execute("select count(orderid) from orders")
nb_orders=cursor.fetchone()[0]
print '%.0f total orders ...'%(nb_orders,)

cursor.execute("select orderid, amount from orders where amount <1000")
oids=cursor.fetchall()
for o in oids:
	print 'Order %.0f for amount %.2f'%(o[0],o[1])

cursor.close()
conn.close()

Easy as pie. And once you got one down, you got'em all. For instance,
yesterday evening I wrote in about an hour a small Jython script which
exports some data. The same export process (running about an order of
magnitude slower) needed previously a couple days of development in
FoxPro. Ah, FoxPro - very juicy subject, but I'll keep it for my next
horror story. Until then, don't forget, when you have a monster to
tame and no time at all: try Jython !

*Let's suppose for a very brief instant that having Celine Dion at a certain location is a positive thing.

Comments(0)

In order to read Allen Holub's new book, you'll certainly need some programming skills (Java, OOP and patterns to be more specific). On the back of the book, there's specified 'Intermediate to Advanced'. It certainly depends on what you mean by 'Intermediate'… because the book is not exactly a light read. But then again, we don't expect that from Allen Holub. We want interesting, insightful books from him, and 'Holub on Patterns' falls nicely into that cathegory. However, some 'intermediates' should prepare themselves for a harsh ride.

The volume is structured in 4 chapters. The first one contains some 'preliminaries'. Meaning : short explanations about why OOP is still incorrectly used, design patterns are not fully understood, plus a bonus of controversial statements like 'getters and setters are evil' and 'Swing is an over-engineered piece of junk' [well, maybe not exactly these words]. As a direct consequence of reading this chapter, the 'intermediates' will start banging their heads on the closest wall available : “My code sucks ! I swear I'll never blindly copy/paste again !”.

In the second chapter things really start to heat up. Allen explains why 'extends is evil' and interfaces are not evil. In case we needed an example of fragile-base-class problem, here we go with some MFC bashing (usual stuff). The chapter focuses also on some creational patterns such as Factory and (at great lenghts) Singleton. I especially liked the cool explanations of how to shut down a Singleton.

The third chapter discusses an [overly complex, on purpose] implementation of the 'Game of Life'. Between huge chunks of code (a bit much for my taste) scattered throughout the chapter, the author explains all the implementation choices: from Visitor to Flyweight. Some 60% of the GoF patterns are encountered in this chapter's code.

The fourth and last chapter contains 'production code', as the author declares. It's a small in-memory database, with and embedded SQL interpreter and a JDBC driver. Very solid example, but it'll probably scare away a few 'intermediates'.

It all ends with an Appendix containing a great 'Design-Pattern Quick Reference', presenting the most used patterns in a very pragmatic format. Each pattern is explained via a diagram, some Java code snippets, its motivation, pros and cons, and a very original 'Often Confused With' paragraph.

Unlike all the other pattern books you've read before, this is not a reference. It's a real programming book that you'll have to read from cover to cover. You'll also need solid programming skills in order to understand the last two chapters (and especially the last one).

My gripes:

• too much code. Probably more than 1/3 of the pages are just printed code.
• typos. There is a slightly disturbing amount of typos in the book, even in some code snippets [like for instance 'Sting' instead of 'String'].

However, these problems should not scare away any potential readers. Because of its original pragmatic approach, 'Holub on Patterns' is surely in the Top 10 Java books for 2005.

Comments(0)

A mini-review

The book already has stellar ratings on Amazon, JavaRanch and other select places, and after reading a few chapters, the only thing I can do is add this post on the praise list.

Why only a few chapters ? Well, you see, this is not exactly the type of book that you read from cover to cover, it's in fact a 720-pages solid collection of JUnit best practices, the most comprehensive you'll ever found in organized, written form. Until now, I have found precise answers to all my JUnit questions.

The book is organized in three big sections weighting some 200-250 pages each. The first one ('The building blocks') is hugely useful if you are a JUnit newbie or even an absolute beginner. It's a detailed introduction to everything you'll need to know in order to start using JUnit: basics, usage in mainstream IDEs, testing patterns, managing test suites, test data and troobleshooting advice. Even seasoned programmers will find useful pieces of advice. I especially liked the 5th chapter ('Working with test data') : an exhaustive description of all the possible ways of organizing your test data. To be honest, it's one of the few chapters from the first section, that I've really read.

The second part ('Testing J2EE') covers testing of XML, JDBC, EJB, web components (JSP, servlets, Velocity templates, out-of-container testing & such) and J2EE applications (security and again some webapp testing - pageflow, broken links, Struts navigation). I can't really pronounce upon this section since I've read only a few subchapters (DBUnit and some related JDBC testing, as well as a few pages from the web testing chapter). But every piece of advice I've got was rock solid.

I've read in its entirety the third part ('More JUnit techniques'). Under this bland title you'll find a group of not-so-common JUnit info such as usage of GSBase addon (funny that I wasn't aware that such a useful addon exists). There's also an intriguing 'Odds and ends' chapter containing some interesting recipes (here's a good one for the QA-freaks like me : 'verify that your test classes adhere to basic syntax rules of JUnit' - sure, why not ?).

Something that I've really missed is a chapter dedicated to mock objects recipes. Yes, there is a quick explanation in the first section - and a reference to Easy Mock or some other mocking API pops now and then in different chapters - there's even an essay about mocking at the end of the book. But the main mock objects dish isn't there. I would've also loved to see some automated GUI-testing recipes (Abbot, Marathon & related tools). But then again, it's a >700-pages book so I'm probably asking too much.

To conclude, 'JUnit Recipes' is the best JUnit book I've ever came into contact with and it supercedes on my list 'JUnit in Action'. Which, interesting enough, was published by the same Manning almost a year ago. Can't have too many good JUnit books, don't they ?

Comments(0)

… then a software team is like an aquarium.

“Programming is Gardening, not Engineering” says Andy Hunt (of Pragmatic Programmer fame) in one of his well-known Artima conversations.

Inspired by such an interesting ‘organical’ comparison, it’s my metaphor of a software team which behaves quite like an aquarium. I assume not all my blog readers are aquaria hobbists, so let me explain:

• Permanent monitoring and adjusting. Left alone and unsupervised, an aquarium apparently manages to ’survive’ by itself. However, subtle changes in water chemistry will slowly start to build up. Interesting fact is that fishes seem to cope well with these changes - until a certain balance is reached and they get sick and eventually die. In my experience, the threshold is rather thin, one day everything seems ok and the next day it’s a major disaster. The effort necessary to clean up the situation is significantly bigger than the effort spared by not taking care of the aquarium. The parallel here is quite obvious : you can’t manage what you can’t measure, you can’t control what you can’t manage. Software metrics, code reviews, frequent releases, testing and feedback, these practices are vital if you want a ‘healthy’ project and a ‘living’ team. Otherwise, beware, the inflexion point might be just a few days away*.
• However, changes must be done gradually. Supposing that a major shift in water parameters was detected, taking immediate and radical measures will generally worsen the situation (unless the catastrophy is already there). It is highly recommended to distribute the change over a reasonable period of time and generally never try to influence two major water parameters at the same time (Ph and Gh for instance). Explanation: all these parameters are interconnected in intricate ways, by changing one you’ll automatically influence the others. By changing two or more, the outcome is hard to predict and might open the path to a disaster. There’s a nice parallel here. A major change in methodology with sudden introduction of multiple new/modified development practices, will only make the team unstable. Even if, globally speaking, the change is a highly beneficial one. ‘Good things come to those who wait’ … and measure … and change … and wait … and measure … and change …
• A beautiful aquarium is a visible one. Transparent glass, lights and everything. You wouldn’t feed and keep your fishes if they were living in a black box and you are afraid to look inside it ?

*Of course [and fortunately], the developers do not get sick because of a reeking team/project, they simply leave.

Comments(0)

Tomorrow is my last day here as a Senior … whatever. I've done a lot of Java development (Eclipse plugins, SWT/JFace, various components for our proprietary framework) and even some DB work (Sap/Oracle/PostgreSQL migration, benchmarking, testing), spiced with a little bit of API design and a healthy dose of documentation writing. It was a great year with lots of stuff to learn, but it's time to move on towards greater challenges. I'm going back to the web business (this time not under the risky startup umbrella, but with an established company) and back to a managerial position ! Working a full year 100% on a development contract has surely taught me a thing or two about how effective management must be done. I really needed such an experience, because as a young professional (back in 1998) I became very quickly (maybe too quickly) a project manager.

The funny stuff is that I'm going to manage a C# team which is bigger than the Java team. I'm familiar with .Net notions and burning some midnight oil with VisualStudio Express, but there is a serious culture shock of coming from Java/Eclipse development environment. Although C# as a language is very neat and there are some cool MSFT APIs down there, I have the strange sensation of things being terribly awkward. Hope I won't be swallowed by the Dark Side [ugly grin].

If there's any 'actual future former' coworker reading this blog : THANK YOU ! and keep up the good work.

Comments(0)