Alternative Linkage
Apologies for the lack of my interesting links post on Friday. Be advised this post is not going to be about software engineering in any way, Fear not I am going to have a post written for tomorrow and it will be about software engineering! The image below is the explanation as to why I did not get time to get the links post ready in time on Friday or have today’s post written either.

Our new wire haired Dachshund puppies Isla (left) and Morag (right) on our sofa.
We received two wire haired Dachshund puppies from our breeder on Thursday evening and I have taken Friday and today (Monday) off work to help settle them into their new home. I knew that two puppies were going to be a lot of work but I had still foolishly thought I’d be able to grab some time to write a post on Friday!
The good news is they are settling in now, with the last big adjustment to come tomorrow when they come to EA with me tomorrow. Having the puppies at work with me should be great for their socialisation and also means they don’t have to be left at home alone all day. I have a large dalmatian sized crate/cage under my desk at work for the pups: as there is two of them I thought I’d try the largest cage that would fit underneath my side desk. The crate has three purposes: to help the pups feel more secure in their ‘den’, to prevent them wondering off (its a big building) and to keep them away from all the tasty wires under my desk.
As this post is kind of a replacement for the missing links post on Friday here are some dog related links:
After much searching for breeders of standard (size) wire haired Dachshund breeders in British Columbia, we finally settle on Estelle E. Laponder as our breeder. And eight weeks and two puppies later I would heartily recommend Estelle to anyone in BC that is looking for Standard Wire Haired Dachshund or Beagle puppies. She has been helpful, patient and cares for all the dogs in her cares deeply for all the dogs in her care.
I stumbled across this blog when I was looking for advice about getting one puppy or two and they were helpful enough to give both email advice and write a post about it to involve the blog community! This is an excellent blog if you are at all interested in Dachshunds.
I stumbled across Jen’s book about her dog training technique know as “Amichien Bonding” over five years ago. I did not own a dog at the time I bought the book: only two cats and a horse. It was the forward by Monty Roberts that convinced me to buy the book. For those of you who have not heard of Monty Roberts he is also know as the ‘Horse Whisperer’ and is a pioneer in humane horse training and handling. As someone who has worked with and owned a horse I was already a big fan of Monty’s work, so when I read his forward in her book that he thought Jen was his K9 equivalent I had to buy her book.
The guilt of not programming
I am a team leader of a small team of programmers, we are specialists inside a large central team of specialists.
One of the things I struggle with the most in the adjustment to being a lead programmer is dealing with the guilt of not programming when doing lead tasks like planning, design documents and meetings. I think this guilt has been brought about from years of working as a programmer where you are assessed primarily on the quality of your programming output. One day you find yourself groomed for a lead position and then finally working day to day as a team leader where your programming output, while still highly valued, is now just a part of your overall responsibilities and worth.
I find myself setting out to do some planning, designing or performance reviews and then, when I log into my workstation that morning, I suddenly find my code editor open and the compiler/linker chugging away happily. In fact I even find myself on those (mercifully rare) days of endless meetings snatching a quick programming fix during my lunch break: prototyping some idea or tweaking something. Programming because I can.
Perhaps it is my loathing of Microsoft Word: the program that will not leave my text where I want it, that thinks that it knows best about layout, and with it’s undo button that never actually seems to completely undo whatever auto formatting abomination just took place. Or maybe the overly complex document templates that seem to have many duplicate or redundant sections are the deterrent? The lack of examples of good documents is also worrisome as it is hard to know what exactly is wanted: the specification is never as detailed as a program feature. Or perhaps all of the above?
I exaggerate slightly, mostly to amuse myself.
I am still mainly a programmer, yet doing those not-programming tasks does seem hard, part of me resists this non-programming even if it is only something I have to do some of the time. I think I will have to start planning them out as tasks as I would a programming task in sprints, perhaps even to go as far as breaking these non programming tasks down further into sub-tasks. Hunting down good examples of plans and design documents to give me an idea of what good looks like will also help.
How did you overcome your guilt/resistance to non-programming tasks?
Web Analytics for the Win!
When I first started this blog I had the blog on a sub-domain of the main domain: blog.endlesslycurious.com and at the actual index page of www.endlesslycurious.com I had a splash screen, which was an image of a Wordle word cloud I had generated using the dictionary definitions of ‘endlessly and ‘curious’. I can’t remember why I decided to use a splash screen, I think it was just that I thought word clouds were that smart looking. I used this set-up as I prefer having each of the main modules of a site assigned their own sub-domains as it makes it easy for me to remember the URL. I have always thought that sub-domains e.g. blog.endlesslycurious.com look nicer than www.endlesslycurious.com/blog/ for signifying a different section of a site. The following is the original splash screen that used to greet anyone who went directly to domain index.
At the start of 2009 I decided to remove the splash screen and move the blog off of it’s sub-domain and into the main domain root. I mostly did this based on the information I was seeing in Google Analytics: which was telling me that my current site had a bounce rate between 75-99%. The bounce rate is the percentage of users who leave the site after viewing only a single page: they bounce off the content/pages without viewing more. Such a high bounce rate I discovered was cause for concern as it meant visitors were seeing the splash screen and deciding to leave the site without viewing anything more. Google Analytics also highlighted the main culprit which was my splash screen: so it had to go!
Since the start of 2009 I have had my blog as the index for the domain (see above image), since implementing this I have noticed a fairly dramatic decrease in my average bounce rate. This is one of the many reason why I would recommend Google Analytics to anyone developing their own site as its free to use and has many useful and powerful tools to help analyse and investigate how users experience and find your site. The following is a graph from the Google Analytics showing my bounce rate from mid November 2008 to mid January 2009, you can quite clearly see where I removed the splash screen at the start of January.

The removal of the splash screen has improved the bounce rate considerably, this indicates a fairly dramatic improvement in user experience. As now users are deciding to stick around to read more content than a single page before leaving. The more I use Google Analytics the more I am impressed with the quantity of measurements and the quality of the application itself: it is very easy to use and manages to present complex information in an easy to understand manner. After further investigation I have discovered that Web Analytics is a fairly big thing ™, with many interesting analytics blogs and books providing more information and insight.
I have also developed some ideas for a new layout for this site and a new sidebar and I think I may test drive the experimentation options the Google Website Optimatiser provides for testing alternate site layouts simultaniousally and collecting usage information for each variation. It had been several years since I last ran a website when I started this current blog, so I am still catching up with how far free site analyse tools have come in terms of features, ease of use and quality. So far I am very impressed with the services I have tried: especially with Google’s offerings.
New: Year, Resolution, Home & URL
Happy New Year folks!
Welcome to 2009!
A New Year’s Resolution
This year I aim to post at least three times a week which should mean at least 52 x 3 = 156 posts by the end of 2009.
A New Home for Me
Apologies for the lack of posts in the last few weeks, this was due to a combination of the Christmas holidays plus moving house and then having snow for the next ten days preventing us from finishing the move! Thankfully the move is complete, although the unpacking is not (yet) but we are more or less settled into our new apartment and more importantly we are completely out of the old place.
A New URL for My Blog
You may have noticed that this blog has a new URL now, I decided to ditch the old splash screen and move the blog from blog.endlesslycurious.com to www.endlesslycurious.com. This was mostly due Google Analytics recommendation, apparently the old splash screen was causing a large number of would be readers to give up, I thought the link in the Word cloud was obivious but I guess not that obvious. I think I’ve managed to update everything that needed updated so all the links, images and RSS feeds should be working.
RSS Feeds moved
I have moved my RSS feeds to feedburner.google.com so you may have to update your bookmark in your RSS reader, although there should be redirection in place to redirect the old feed URL to the new location.
Web Development Frameworks
When I created my first website back in 1998 it was purely static HTML that I created with Adobe’s DreamWeaver application. Next I discovered dynamic websites built using php and MySQL databases, so my next few sites were all written in php and accessing a MySQL database for the content. I have to confess that these initial dynamic sites were written in the worst style possible: inline php in the HTML and spaghetti php, all things that invoke horror in other programmers.
It was not until I started helping out with RockClimbing.com for a brief period which exposed me to a large scale php project supporting many thousands of users. With its advanced language usage, separation of code, content and layout with smarty templates, advanced caching and high performance database queries (one of the developers ended up working for MySQL iirc) it was beyond anything I had seen before. All this opened my eyes to how to architect a site in php correctly and that it could be a truly elegant language to work with and I am not alone in this feeling. Then for a period of several years my personal site fell into disuse as I was distracted by work and life from doing any active web development.
This year I decided to start this blog on a new domain name and start writing about software engineering and programming. My choice of blog engine? WordPress: which is a php based blogging engine which runs with MySQL as its database. I found myself tweaking my WordPress installation almost immediately and I found it easy enough to do as php was already familiar to me. In fact I’ve been tweaking so much that I’ve now set-up a Perforce server at home so I can track, audit and keep a log of my changes. As I’ve explored the WordPress code base over the months, I’ve noticed that it is not the prettiest of code in place and again I’m not alone in noticing this.
Please don’t misunderstand me, I like WordPress a lot, it has made setting up and running this blog trivial, especially when compared with writing my own blog engine from scratch. I’m simply commenting on my perception of the quality of the underlying source code, something I think all programmers do especially with things they’ve written (although I did not write WordPress, I just modified it). It would be nice to see a code tidy up and the introduction of templates and caching to the core engine, but that is a big job to undertake and I don’t think I have the required amount of spare time to achieve it myself.
All this has got me thinking about the recent(ish) upsurge in the number of web development frameworks that are embracing things like Object Relational Mapping (ORM) and development models like the Model-View-Controller (MVC) pattern. The two programming languages that seem to be leading this charge are Python with DJango and Ruby with its Rails framework, no doubt there are other frameworks in other languages too (e.g. ASP MVC, php’s symfony framework). The increase in popularity of these frameworks with built in template engines and abstraction of content from layout and logic via MVC are making me consider setting out on the path of writing my own personal blog engine again.
Mostly writing my own blog engine is a way to learn and embrace these new technologies and concepts and also a chance to see what all the fuss is about. This would mean leaving the cosy comfort of my WordPress armchair, so most likely this experiment will become something I initially develop in a test sandbox at home until I have something that is worthy of publishing online. My decision now is what language and framework to use. Do I stick to php with Smarty and MySQL or do I try something new like Python’s Django or Ruby on Rails? Right now I’m tempted by either Python or Ruby for reasons I will talk about in a post tomorrow.








