1. iTunes
2. Adobe Photoshop
3. Adobe Premiere

So long as these three pieces of software are unavailable for Linux, I have no option but to make a pact with Redmond’s finest. Sure, I could also choose to go the OS X route, but while that option is cheaper than Windows, the hardware to run it is expensive and is likely to be obsolete before my trusty, upgradable, PC which also runs Ubuntu Linux.

So this week, I took the plunge and bought Windows 7 Home Premium Upgrade as my XP installation has gradually been slowing down and the annual rebuild was due. Windows 7 has had overwhelmingly positive press – perhaps a consequence of releasing the slow, poorly supported and infuriating-to-use Vista previously. This time, it is reported that there is a return to the stability of Windows XP while bringing improved boot and shutdown timings and a whole array of UI improvements (which I openly admit I am a sucker for – hence my devotion to Ubuntu’s Compiz window management and Gnome Do’s Docky functionality.)

Before I talk about how the Windows 7 installation went, a quick word about my three reasons for adopting Windows. Many Linux advocates will suggest alternatives to iTunes, Photoshop and Premiere. While Songbird and the Gimp are without a doubt excellent developments, Songbird does not support iPhone syncing and the Gimp does not have the community and support that the Adobe products offer. (Nor, frankly, does it have the usability or reliability in my experience.)

So, Windows 7 it was. The box arrived (looking intriguingly smaller and neater than the Microsoft marketing images – how did they do that?) with a 32-bit and 64-bit DVD inside. I can see no reason to go 64-bit yet (with its diminished software support) unless I am looking to run a system with >4Gb RAM. I’m not. Even given Premiere Pro’s system demands, RAM is not an issue for me, and my current 2Gb does me fine. The 32-bit disk started booting; some of that promised eye-candy was already on display and then… what’s this… it appears to have stalled. No disk activity, the mouse pointer (which I can still move) is the only think on the wallpaper, but it’s spinning-circle (egg-timer replacement) has disappeared and it seems nothing is happening. Now I know that at this point in a OS install, drivers are being loaded and hardware is being detected – sometimes a lengthy process. So I give it a minute or two. Then give up and try booting again. Same result. A quick google suggests it may be some USB devices so I disconnect printers, webcams etc. Same result. Further research suggests it could be BIOS settings, so I tweak those. Same result.

Then I read an article suggesting another unlikely solution: patience. I give this ago. 5 minutes and 20 seconds’ worth of patience in fact. At which point the installation continues without apology. Having learnt the divine skill of patience, the rest of the installation went smoothly (though there was a need to “keep the faith” at various points during the install.) After not much more than 30 minutes, the PC booted into Windows 7 is record time and I’m liking what I see. Subsequent software installation has been effortless and the system continues to run well. I chose to move from Symantec antivirus to the free AVG offering, and for firewall, I’ve taken on Comodo instead of ZoneAlarm or Windows 7’s own blockers.

Finally, it was necessary to deal with Windows’ unforgiving abuse of the Master Boot Record by replacing it with something that will acknowledge the fact that I have Linux running on another partition. To do this, I followed these steps (which were new to me as I’m not so familiar with grub2).

I work for MediaTel Group and my focus is primarily on developing data analytics tools for the UK media industry. Among other uses, our products are used by media agencies to make advertising buy decisions. Our strengths are the data and customer service, not just the software. The product, in its web-based guise, has existed for nearly 10 years and in that time has travelled through some technology changes (starting as a ColdFusion site; now a PHP/Zend Framework system) and many functional overhauls. With a product of this age and heritage, it is perhaps not surprising that we currently have 412 tickets open in our internal Bugzilla issue tracker – a mixture of bug reports and enhancement requests.

All tickets have been raised by us. Not our customers. Sure, some tickets were instigated by customers (following discussion with our customer service or sales staff) but no MediaTel customer has ever been given a ticket number with which to refer back to their report, nor a formal SLA to set their expectation on delivery. As MediaTel staff work hard to replicate, fix, test and deploy changes, the customer has no way of getting an update on the progress of the issue other than to call up or be contacted by our teams.

And yet we are very strong procedurally within the organisation and use a variety of tools as part of our daily customer service and development workflows to ensure that internally we have excellent information about the state of a bug fix or feature implementation. We have a home-grown web-based CRM system and Bugzilla – which is integrated with our Subversion source code control system and a deployment process to ensure we know what code (and thus which bug fixes etc.) have been deployed to what environments and when.

We’re brimming with information and it seems just a small step to take to share that information with our clients and solicit their bug reports and feature requests directly. I suspect that some might recoil at the thought of revealing to our clients that we have hundreds of known bugs in our software – some of which we have known about for more than three years. Why own up? Some might consider it a backward step to rely on impersonal web-based tools to communicate updates rather than a more personal phone call or an email from a real person. There may be concerns about the amount of time it would take to manage all the new communication from customers.  Or that customers would be bombarded with too much confusing – sometimes technical – information.  But here is what I think:

1. Our product exists in order to help our customers go about their business. For MediaTel, making sales and retaining clients has got to be made easier if the product does what they need it to do and does it well. Let’s make it easy for those clients to tell us what they want and need. Let them tell us how important a particular software change is to them. They can still pick up the phone to us, but having a direct route into our systems gives them more control and provides greater transparency;  it gives us more accurate (and more) information.
2. A desire to be honest with customers is key.  If they ask for something and we don’t have the resources to do it, let’s tell them.  If they ask for something but it is contrary to our product strategy, or more customers are asking for the opposite, let’s tell them.  I have faith that our customers understand these realities. For this reason, I would not shy away from publishing our internal priority for a particular issue alongside the priority attributed by the client.
3. If customers can raise their own tickets and view updates to those tickets, a natural extension of this is being able to view the tickets raised by other customers. By this means, they should be able to vote up or vote down a particular change. If they see a ticket that we are struggling to replicate, they may be able to share some insight. By doing this, we are beginning to create a community from our customers. This may lead to greater consensus on what our customer-base wants, and so enable us to focus our efforts where they will please the greatest number of customers most.
4. One challenge is to identify the right tools for the job. A shrink-wrapped Bugzilla deployment is not going to fit the bill. We need a simple UI for our customers who will not wish the job of sharing information with us to be onerous. We do not wish customers to to have to grapple with the differences between “severity”, “priority” and “importance”. We need the ability to keep some updates and comments to ourselves (not because we wish to hide information, but because we do not want developers to become inefficient – or, worse, tongue-tied – as they consider how the wording of a comment might be perceived by a customer.)  We need to ensure that when a customer raises an issue, they are not repeating the details of a ticket that has already been raised.  (stackoverflow.com does an excellent job of this.)  When browsing a list of issues, we need to allow them to filter that list so that they are not overwhelmed.

Opening our ticket database to customers is not a move towards abandoning other forms of customer service or product management. But it is another tool to help us show how we value our customers and ensure we are directing our efforts where our customers most need them.  It should not lead to us having to take on more work but, rather, it should ensure that the work we do is always to the benefit of our customers and will therefore encourage both customer-retention and sales.

If you want a flamey discussion of the relative merits of F-Spot and Picasa (and gThumb, digiKam etc.), see this thread.

It was once the case that things just worked on a Mac (and even Windows) but were an unreasonable struggle with Ubuntu.  Wireless networking.  Display settings (especially dual-head display settings.)  VPN connections.  But having followed Ubuntu on the desktop for three years, I think it’s finally got there.  It is a real contender for running your desktop PC.

With the “compiz” window manager, beautiful display effects and functionality (similar to Mac’s Exposé) are possible with almost no setup required.  That coupled with the “Docky” theme for the gnome-do application, give you a user interface that is – well, not original, no – but a firm challenge to that provided by Apple (and latterly Microsoft.)

But, as a geek, it is not just the eye-candy which swings things in Ubuntu’s favour.  Mac OS X is of course just BSD Linux underneath.  To put things crudely though, it is like having a version of Linux which has a strange directory layout and a restrictive software package manager.  Couple that with the fact that the Ubuntu community is stronger for developers, and you have a more compelling proposition from the free option.

And if you really want it, you can get Apple’s keyboard, mouse and screen to complete your look!

Installation of Koala is quick and easy – and boot-up times are way ahead of anything that Windows offers.  I urge you to try it out.

What doesn’t it do?  Well, you won’t get Photoshop running effectively in Koala.  Poeple will talk about virtual machines or about using open-source alternatives such as Gimp – but these are not viable options for serious users.  Likewise Premiere Pro for your video editing is not an option.  The most frustrating omission which perhaps affects the greatest numbers of potential defectors is the lack of iTunes.  A great open-source alternative, Songbird, has it all… except for viable support for iPod and iPhone devices.  If you can live with these omissions, I believe you’ve got a new (free) friend.  Well, operating system of choice.

I’m a developer and the following is a guide to some of the setup I perform after the base installation: to get a desktop system up and running to my liking.  Excuse the apt-get syntax; it doesn’t matter how many different GUI package managers they throw at me… I’ll still find it easier to install software via the command line – but the GUIs are, (I’m told!) good if this looks alien to you:

# essential to get video working (e.g. YouTube)
apt-get install ubuntu-restricted-extras

# to connect to my work VPN
apt-get install network-manager-pptp

# to allow SSH connections to my machine from others
apt-get install openssh-server

# to help customise the GRUB boot loader
apt-get install startup-manager

# to enable outbound mail via a smarthost and command line mailing
apt-get install mailx nullmailer

# to enable a multiple-account mail notification icon in the panel
apt-get install mail-notification

# gives you an OS X-style dock
apt-get install compizconfig-settings-manager gnome-do

# controversial, perhaps, but pidgin beats empathy for (non audio/video) instant messaging
apt-get install pidgin pidgin-otr

# controversial again, but until Evolution sorts out its HTML rendering, Thunderbird wins
apt-get install thunderbird

For development purposes (I am primarily a LAMP developer), I recommend:

apt-get install apache2 php5 mysql-server subversion
# And a bunch of php5 extensions - too many to list here

# to support the installation of Netbeans, SQuirreL and DBWrench
apt-get install sun-java6-jre

# to support integration with MySQL and SQL Server
apt-get install libjtds-java libmysql-java

# I'm a geek; this beats any other editor I know
apt-get install vim

For Nvidia graphics card users who want dual screen capabilities, I found that a simple install of the following gave me a GUI tool on the menus in order to set this up in seconds:

apt-get install nvidia-xconfig nvidia-settings

Enjoy.

My initial reaction to the use of stored procedures was hesitant.  I work in a small company with no dedicated database programmers and a relatively small team of PHP experts. Due to this balance alone, I consider a greater reliance of stored procedures to be a risk.  But there is one very good reason to think the move may not be so risky after all: it takes load off the network – which might also result in a net performance gain.

But my initial wariness still stands – and continues for all the projects for which I’ve considered stored procedures recently.  The following disadvantages overwhelm that performance gain:

• Language: the extended SQL language used in stored procedures is relatively immature and doesn’t lend itself to certain complex logic.
• Tools: development tools for MySQL stored procedures (including debugging aids) are very limited.
• Server load: increased processing on the database server is more difficult to accommodate (database servers are more difficult to scale than Apache/PHP web servers, for example.)
• Deployment headaches: it can be hard enough to keep database and application code in sync without causing even a blip of downtime.  Introducing stored procedures introduces another element which needs careful management.  It’s not rocket science, but it’s just more to think about – and more to go wrong.
• Portability is limited (DB2 has a similar language to that used by MySQL, but otherwise, you’re pretty much stuck if you want to move to another database platform.)  That said, it’s not exactly an everyday occurrence, is it?
• Performance(!): the performance gain you may expect from stored procedures might often be a myth anyway. Stored procedure code executes slowly when compared with many application programming languages – so the benefits of reduced network traffic might soon be eaten into.

So, for the time being, while we have the skills to focus development of business logic in PHP, that’s just what we’ll do.

Each release of Ubuntu just gets more and more, well, grown-up.  When I started using Ubuntu on the desktop, it was a brave man who would upgrade when a new release became available rather than install from scratch (and keep your fingers crossed with drivers.)  But things have improved significantly – even on hardware which is new and typically less well supported (see my Eee PC 701 setup guide later in this article.)

Things I like about Intrepid over previous versions:

1. Network Manager just seems to work.  The OpenVPN support just works.  It all just feels less flaky.  And when I plug my mobile phone in, it took about 10 seconds to setup a 3G connection through it.  All very plug-and-play.
2. Fonts: System > Preferences > Appearance > Fonts > Subpixel smoothing (LCDs) looks nicer than ever before.
3. The combination of Nautilus’s Tree organiser and it’s new Compact View really makes this a usable file manager.  At last.
4. Dual screen support seems much improved.  Two machines which I had trouble with in the past (one with an NVidea card) now work with a second monitor without having to wrestle with the xorg.conf.  What I’ll do with those cold winter evenings now, I don’t know.

One of my laptops is an Asus Eee PC 701.  Under Gutsy and Hardy, a number of tweaks were essential to get basic functions to work (wireless and sound in particular).  With the impending release of Intrepid, things go much more smoothly, and while a few tweaks are necessary, it’s almost plain-sailing.

Here are the steps I have taken to install Intrepid on my Eee PC 701:

1. Download the ISO and install from USB (using the ub8convert2.exe tool)
2. Get wireless working. Go to System > Administration > Hardware Drivers and deactivate the Atheros driver and reboot.  UPDATE! If that doesn’t work, it’s because the ath5k driver has been removed from Intrepid (on 28 October) – by the time you read this, it may be back.  If not, visit this bug report and you have the steps necessary to get back online.
3. Get up-to-date (especially as this is a beta currently.)  Keep an eye out for the update-manager icon in the top right of your panel and take suggested upgrades.  It may well suggest a “Partial Distribution Upgrade” as this is a pre-release version. Do it.
4. Shutdown doesn’t power-off.  To fix, add the following line to the end of the /etc/default/halt script:

rmmod snd-hda-intel

5. Sound doesn’t work out of the box.  To fix, create a new file (or append to the existing file) /etc/modprobe.d/snd-hda-intel:

options snd_hda_intel power_save=10 power_save_controller=Y

6. Turn on the microphone. Right click the volume icon (top-right) and choose Open Volume Control.  Then raise the e-mic control to the top.
7. Use the Riceeey script to achieve the following. You’ll need to edit the script down to size just to achieve this.  I haven’t tested whether the “overclocking” (which is really a “don’t underclock”) feature works.
   • allow windows to be moved above the top of the screen (by holding Alt while dragging)
   • set toolbar style to just show icons and set fonts to size 8 (to give you more space)
   • set Alt-F11 as the key for running apps full-screen
8. Get the hotkeys working:
   

wget http://www.informatik.uni-bremen.de/~elmurato/901/Ubuntu_ACPI_scripts-EeePC_901_1000.tar.gz
or
http://www.informatik.uni-bremen.de/~elmurato/EeePC/Ubuntu_ACPI_scripts-EeePC_900A_901_1000.tar.gz
tar -xfvz Ubuntu_ACPI_scripts-EeePC_901_1000.tar.gz
cd Ubuntu_ACPI_scripts-EeePC_901_1000/
chmod +x install.sh
sudo ./install.sh

Good luck – do tell me how you get on.  Thanks to devgru and Psychocats.

Subversion is different. It takes a different approach to any other source code control system I know. It uses lightweight ‘copy’ operations to achieve tagging and branching. It’s intuitive. If you didn’t have source code control and you had a code base that you wanted to keep as “version 1″, you’d most likely take a copy of the directory and call the new directory “version 1″. Well that’s tagging in svn.

But, like I say, this is all well-documented.

Bugzilla is a bug-tracking system. I hate the word “bug-tracking”. (I’m not very fond of the word “bug” at all!) But it’s a misnomer to label it a bug-tracking system because it tracks any sort task – typically a programming task. Frequently, it tracks the tasks involved in developing new products and new features. Not just bug-fixes. So I prefer task-tracker.

Bugzilla is a perl-based open-source task-tracker. It’s been around for years and with each release (especially the recent 3.x stream, which introduces custom fields, at last) it gets better and better, It’s basic. It lets you record a bunch of information relating to a task. A summary. The priority of the task. Who is interested in getting updates. The status.

10 years ago, when working at Thomson Datastream, we used Paradox to keep track of our tasks. It was implemented as a form-based database. Bugzilla is no different. Each task has an ID and associated with that ID are the fields.

It has some nifty additional features to facilitate workflow. When a “bug” is updated (don’t get me started on how wrong the grammar and accuracy of that phrase is), interested parties are emailed to be told what’s changed. It has a flexible reporting system. It has some basic project management facilities, such as task estimate and time tracking. But it’s still essentially just a bunch of fields in a database.

I often hear people confusing source code control with task-tracking. They are very different. One is concerned with the lines of code being written and managing the history of changes. The other is concerned (typically) with recording and managing the programming tasks.

And in any semi-mature development environment, both are needed. Especially where a team is working together. But even as a one-man team, I’d recommend the use of both.

That doesn’t sound too controversial, but it is. And here’s why. When a developer checks some code into svn, that change is given a unique “revision number”. The coder can provide a description of their change when they commit. And svn supports “hook scripts” which easily allow it to be configured to send emails when code is committed (or tags created or branches merged, etc.) And so the argument often goes: why bother with a task-tracking system too, when I’m getting most of the functionality with just Subversion?

The problem is this. Programmers are concerned with the nuts and bolts of development. Their change descriptions are likely to read, “Change the user array to be an array of objects instead of id’s”, or “Add new sort function”, or “Implement new View module for the admin n Controller”. But a project/product/commercial manager – or, perhaps much more prescient, a customer or prospect – is likely to think in terms of high level features or changes: “Improve performance of adding a new user to the system”; “Tracks should be sorted by ignoring the word ‘the’”; “New blue-themed look Admin screens”.

It’s not just the descriptions – that would be easily resolved. But more difficult to overcome is the granularity. A single feature (e.g. “Allow a user’s account to be disabled”) might involve multiple code commits. Perhaps by a number of different developers or designers. So now your developer has a number of lower-level changes and descriptions which are all part of a single piece of work as far as management or customers are concerned. And while one of those more granular changes may be concerned complete by a single programmer, the project manager knows that it’s not until all the associated pieces of work are complete that the task is really complete,

So it’s become an issue of communicating the right information to the right audience. And I don’t think you can ignore either your developers nor your managers and customers.

You need both source code control and you need effective task-tracking.

This has been the case for as long as I can remember (from those heady days of Paradox and Digital CMS, through proprietary databases and CVS, to Bugzilla and svn.) But despite there clearly being a role for both systems, and despite the prevalence of such systems, integration of the two is another matter. Getting Bugzilla to talk to svn and vice versa is not trivial. And there is certainly no inherent capability in either product.

There are “workaround” solutions to this – for example, getting developers to commit code changes for a single task in one single commit operation. Or get developers to keep track of the revision numbers associated with their issues. But these are largely impractical (or force a suboptimum development process on the team) or are labour intensive and subject to human error.

There are tools which can facilitate these tasks – such as trac (of which I have almost no experience but hear many good things – but am not convinced it meets all of the requirements.) I’d welcome more feedback on trac and tools which might help tackle the problems I’ve outlined above.

But ultimately I think to solve the twin needs of task tracking with Bugzilla and source code control with svn, it is necessary to choose between implementing some glue between the two or accepting some increase overhead (and risk) in manually running both in parallel.

# download the Google calendar ical file through the private URL
wget -c -N http://www.google.com/calendar/ical/yourname%40gmail.com/public/basic.ics

# copy it to the iPod
cp basic.ics /media/your-ipod-name/Calendars/google.ics
rm basic.ics

Now configure Ubuntu so that this script is run whenever you plug your iPod in. Add the following line to /etc/udev/rules.d/80-programs.rules:

KERNEL=="sdc1", RUN+="/path/to/your/script.sh"

(Replace sdc1 with the appropriate device name, which you can find out by typing “df”.)