My Love Affiar with Chrome

Forgive me father for I have sinned. It's been quite some time since my last confession during which I have committed the sin of "Browser Adultery".

It all started out quite innocently a little over a year ago when I read about a young and pretty Browser named Chrome. Reading through the blogs and magazine reviews she appeared to be the ultimate and sexiest browser, wanted by almost every man and woman alike. Who couldn't fall in love with those tight curves and straight lines. Her father, Google, claimed that she was the fastest, lightest and most stable browser on the market at the time and attempted to pawn her off on all those window folk. During this time, however, she was mainly a dream to me since I don't run Windows.

As the months passed her father opened her up to the world of Linux that I live in. Resisting temptation and not wanting to let go of my darling FireFox, I held back preferring to read about her and view her pictures instead. However, slowly, one by one, my friends succumbed to her and it was only inevitable that I would too.

We began flirtations a few months ago; I'd try and bring her into my computer only to have her refuse to install and work for numerous and varied reasons. In retrospect I should have realized this as being a sign of immaturity, but I persisted. Finally about two weeks ago I managed to get a build of Chrome that installed and worked on my computer. It was love at first sight. She was quick, sexy and flirtatious with all of her extensions. Pushing her buttons and tweaking her settings were pure joy, leaving me breathless and wanting more. Every website I viewed jumped right out almost instantly; The Internet as whole seemed faster when compared to my browser of 9 years. Now, I know FireFox will be getting face lifts and features found in Chrome, however, I had it all now so why wait.

Every time we played she'd ask for my commitment to make her my default browser. Finally, in a daze I agreed. Soon after, her dark side began to show. The first signs were of greed with excessive memory consumption, even with a reduced number of tabs. Like the boyfriend in denial, I started to blame myself; Removing and disabling extensions that were nice to haves and so on. I even went as far as giving her space by shutting her down after every session.

But alas all this was in vein as she eventually succumbed to failure; Chrome has a feature that's supposed to isolate a tab and extension from others. This allows for secure separation, however, in my case under Linux, this did not work as advertised. Instead imagine to my surprise when I discovered that all my open tabs failed and displayed the "I'm sick" icon. In disbelief I proceeded, ignoring what happened, thinking that this was a mere one off situation. Soon enough, however, things got worst. Periodically she'd fail and crash altogether, however, unlike FireFox where tabs can be restored upon restart from a crash, I'd loose all my open tabs and end up having to scour through my browser history to work out what I had open at the time. A pain to say the least!

Finally today, after two weeks, I'd had enough. I'd gone through councilling using Google to find out what might be wrong, to no avail. Then finally when I was using FireFox on my work computer it struck me that I had some 20 odd tabs open, reasonable memory consumption and not a single crash in the week the browser had been running without a restart. I'd opened my eyes to see Chrome for who she truly was; An immature browser that still has some growing up to do. Today I annulled Chrome by removing her from my computer. I've gone back to FireFox; My old faithful; My saviour from the dark days of IE.

Who knows we may have another fling in the future as Chrome matures. But for now I'll stick with the one that whilst not as pretty and sexy as Chrome, "just works". The short fling we had opened my eyes to what's truly possible and I breathlessly await to experience this kind of joy again in the future, perhaps with FireFox this time or maybe even Chrome again.

MySQL: What next ?

Unless you've been living under a rock, in the technology world, you would have no doubt heard that Oracle has recently acquired Sun Microsystems and all the buzz following the announcement. The announcement was a greater shock for us MySQL customers, especially given the fact that it was officially announce on the morning of the MySQL Conference in Santa Clara, from where I'm currently writing this blog. The news sent waves of awe through all us MySQL customer; Most of whom have migrated away from Oracle due to it's insanely (relatively speaking) costs of licensing.

Sun's official stance on the matter is that "This is a fantastic day for Sun's customers, developers, partners and employees across the globe", naturally! - Heck I'd say that if I was being paid ~7.4 billion. Now I'm sure that for some divisions within Sun this news is a breath of fresh air, however, I can assure you that the musings from MySQL customers in general is no where near as pleasant. Most of this revolves around the unknown; What will Oracle do with MySQL; A product that competes directly with it's flagship product ?

Now rather than bore you all with talk of doom and gloom, I'm going to write a different view; Hopefully one that's a little more optimitic; One revolving around the question of What should Oracle do with MySQL ?

Now please bear in mind that this is not a ramble on which database is better and whether or not MSSQL or DB2 would be a better fit. This is simply my personal view on what Oracle should do with their newly purchased MySQL asset.

Firstly, I don't think that the purchase of Sun is necessarily a bad one. Sun, ever since the hey-days of the Dot-com boom has been rather stagnant with it's product portfolio. Sure they've caused waves in the market by Open Sourcing almost all of their major product lines, but they haven't been very smart in integrating their technology portfolios into solutions and executing on them. Sun being bought out was definitely a no brainer. The Oracle purchase, for the most part will be a breath of fresh air and (hopefully) give life to a lot of Sun's cooler technologies, whilst dropping and cleaning out the crap.

So what does this mean for MySQL ? - Well my hope is that Oracle views MySQL as a complement to their flagship product rather than a direct competitor. Oracle should view MySQL as the solution for those that don't need a "enterprise grade" solution that can do anything and everything and provide a near 99.9999% uptime. Those customers that fit into this category wouldn't think twice about the licensing costs as the costs of downtime far out-way them.

On the flip side, there are those customers that are not necessarily looking for a 99.9999% uptime; For them the ROI does not justify the cost. These are the customers that generally look towards MySQL. Bottom line, most businesses that have adopted MySQL over Oracle would never have purchased Oracle to begin with; Most of them have such simple requirements that MySQL would be the perfect fit.

So what should Oracle do with MySQL ?

To begin with, from a technical direction, I'd suggest that they continue to improve on and develop MySQL; Possibly even implement their Oracle Engine as a pluggable storage engine for the Enterprise Edition as a option. This will allow them to focus Oracle on the upper tier customers. At the very least, they should continue to take the product in new and exciting directions.

From a customer perspective, I can see that Oracle would gain clear benefits by combining solutions from the various assets, both new and existing, and target them towards different tiers, based on requirements and budget. I can clearly see customers being channeled with full end-to-end "out of the box" solutions at low, medium and high tiers; Low being MySQL's domain, High being Oracle's domain and the middle being combined. Since Oracle now holds keys to an entire stack, including hardware, I can definitely see this as being huge, if executed well. Remember most businesses are not in the business of technology. Technology is a cost centre. Those that can provide complete end-to-end solutions at a low cost (including maintenance) will have the upper hand.

I'm hopeful that Oracle will be smart with their newly acquired assets. At the very least I hope that they learned lessons from their Peoplesoft fiasco and apply them in MySQL's case to keep all us customers happy, regardless of the long-term outcome.

But hey, what do I know; I'm just another "mad man" rambling. ;)

Unit-Testing Database Code

So I've just read a interesting post on my brother's blog highlighting the problems of running unit tests against databases. I'll let you read the detail, however, in summary, his thoughts on the subject basically center around two thoughts:

1. Code insert and delete statements for every row of data you need for your unit test in the setup and tear-down methods, respectively.
   The problem with this, approach is that there is a high chance of corrupting your DEV database (hopefully you are not running unit tests against QA or production!)


2. Create a test database containing the data you need to run your unit tests with.
   The problem with this solution is that it involves maintenance overhead for the test database; Making sure that it's clean prior to inserting your data and up to date with any new columns/tables/triggers/procedures/etc.

Now, based on my experience, a lot of people fall into this trap when thinking about unit testing against database data, myself included once upon a time. One day, I saw the light when I was introduced to the concept of "mock objects".

According to Wikipedia, mock objects "are simulated objects that mimic the behavior of real objects in controlled ways". So how does this this help with unit testing database code ? - Well simply put, you can replace every call to your database with a mock object, at test time, that returns the data and/or results you'd expect from your database without requiring a database. To make implementation easier, it helps if your database calls are abstracted out by either a database interface layer or a ORM tool; Most modern ORMs have either built-in support for mock objects or can be adapted to be used with mock objects.

The beauty and simplicity of this approach cannot be stated enough. When testing using mock objects one can do things in unit tests that maybe difficult and/or impossible to replicate with a real database, such as testing for timeouts, loss of database connections and bad and/or corrupt data. It also enables your unit tests to run in a environment without a database (ala build server), which can be very useful if you are doing or want to do nightly test builds.

So there you have it folks you can all sleep a little better at night knowing that you no longer have to struggle with unit testing your database code.

Building a robot - Day 2

Okay... so everyone knows that I've just started my latest project in building a robot. If you missed my first post on what motivated me and my thoughts, see here.

Last night I began working on the mechanics of the drive mechanism. After hunting through all my scrap parts for gears and motors, I finally found a set of matching gears and matching motors. My initial thoughts were to have the motor drive the gear which is directly connected to the axle. In my first attempt, I found that the axle was just a little too thin to hold the gear. I attempted to glue the gear to the axle but found that the glue doesn't work too well with steel. After more searching, I found a axle that was slightly thicker, however, it was a little too thick for the gear. No problem, I just used a hammer and hammered it in.

Which bring me to last night, where I was attempting to mount the axle, gear and motor to the chassis. My initial thoughts were to drill a hole through he chassis wall for the axle and to mount the gear and motor behind the wall, with the wheel on the opposite end. Unfortunately, as I discovered later on, this would not work as the weight of the body would force the axle to bend into the chassis as there is only one thin point on the chassis supporting the axle. To combat this problem, I decided to try and create a extension to chassis so that there would be two points of support for the axle. The gear and the gear on the motor shaft would now be on the outside, sandwiched between the chassis panel and the extension panel, with the motor sticking through the chassis panel.

Unfortunately, for me, my fabrication skills are seriously lacking; After pondering the best material for the task at hand for over an hour, I decided the best way to go was to use a strip of thin steel (an old pc slot cover) bent into a square horse shoe that would be bolted to the chassis. To me, this was great as the steel would be relatively easy to work with (being thin) and the mounting is rather simple... or so I thought. I was to discover, late in the night, that whilst the steel was thin and relatively easy to bend, it would not be easy to make into the necessary shape as the space is rather tight and I lack the proper equipment to bend the steel correctly.

So here is where I decided to leave the project and retire for the night. After a good night's rest, a thought struck me; Rather than using the steel, why not use a thin plastic such as that found on Glad brand tupperware. The plastic is thin enough so that it'd be easy to cut and bend into the necessary shape and also it's tough enough not to break easily. I guess it does pay to have a great night's sleep.

Building a robot - Day 1

So I got into robotics... again, last night. All of this came about from discussion I had with some fellow coworkers about how their kids were studying robotics in school using the Lego Mindstorms kits. All of this discussion got me thinking and so I decided to "scratch the itch" and document my successes and failures on here.

Last night I began working on the actual mechanical aspects of the robot. I have decided to keep it simple and to attempt to only use parts that I have sitting around (I have a lot of parts!) or that I can get for free (ie. I don't want to spend any money on this if I can avoid it).

After about an hour of thinking I came up with the following design; The chassis is a small plastic container that used to be a DLT tape case driven by 2 motors, one for each side driving the rear wheels. Rather than using two front wheels, the plan is to use a single caster wheel mounted in front. This should allow the robot to rotate a full 360 degrees on the same spot.

The robot will be remote controlled from my PC. The actual details behind the link have yet to be thought through, however, I do have a few thoughts in mind such as WiFi or Bluetooth (using a old discarded Pentium SBC I have laying around or by hacking a old 2ch RC I have. I figured I could "cross that bridge" when I get to it. At worst, I'll implement autonomous control using a microcontroller that can have instructions downloaded to it via a serial cable.

Rather than driving the wheels directly I decided to go with a small gear box on each wheel to help with the drive. Here in lies my first problem; Finding the right gears to attach to the axle and motor. It seems that of all the gears that I have (and I have a LOT), none of them match! - They are all of different ratios. I guess I'm just going to have to work out a way to mash various different gears to from the same ratio on either side. My other hop is to be able to scrounge for parts at my family and friends place. If anyone out there has an old VCR, DVD player or cassette deck that they don't need, please let me know.

For now, until I can find the right gears I went ahead and began working on the main body by drilling holes for the axle bearings, etc. - I hope to have some pictures up once my wife brings home our digital camera.