The Ringtail

I’ve been brushing up on my Mac OS programming skills this week, with the intention to launch an app or two on the world to see how they go.

I was in Scarborough for work on Monday so I travelled up on Sunday afternoon and stayed over. I had mentally set aside a few hours on Sunday evening to work on a sample app, thinking I could use the internet as a reference. Unfortunately there was no wireless access in the hotel, so I was hobbled by only having the core documentation to help me. Turns out this was the best thing I could have done. Without being able to ‘cheat’ and look up how to do things, I had to work harder myself to understand how the core elements fit together. The net result was that, at the end of four hours, I had an app that worked, but more importantly, I knew how it worked.

Someone recently asked me the best way to learn programming on the Mac. My answer was:

• have a clear idea of an app that you want to use (start small)
• map out the elements you need to build that app
• read the core docs to understand how the objects need to work together
• build it
• extend it by following the same process

I now realise that this was advice I had never actually taken myself. If there had been wireless internet access in that hotel on Sunday, I probably still wouldn’t. Not listening to wise advice from others is bad enough, but not listening to wise advice from yourself? Crazy!

…was that the act of blogging about my willpower at sticking with one flavour of linux for a whole year would precipitate a change. I am back using my Mac, for a chance sequence of events:

• I thought I’d lost it earlier in the year when the graphics chip died and it looked like I would have to pay £500+ to replace it. Mumble, mumble, bloody Apple, mumble, rip-off, mumble.
• In a last ditch attempt to revive it I took it to the Genius bar and was delighted to find that it’s a known issue with the graphics chip and nvidia have replaced the logic board free of charge. Hip, hip for Apple!
• Now I have a working Mac and a working Debian machine – which should I use? All questions of which I prefer, which is morally best, which is technically best, etc. aside, I decided to base it on one simple criterion – which helps me get my work done quicker?

So I am writing this from my Mac. It’s a simple fact that, for me, the Mac lets me get stuff done. Files just open, apps talk to each other far more seamlessly and I just feel like it’s working for me. Sure, I can do everything I need to on Linux, but it all takes just a little bit longer to set up, a little bit longer to get right. One example – files prepared in OpenOffice by someone else, and subsequently edited by me tend to look less-than-optimal when they get back out to Word users. I may want to write my files in emacs and use Pandoc to get them out to PDF to share, but the rest of the world wants a Word file (and not a russian-roulette ODT export, a Word Word file.

If I coded for a living it would be different, but my job requires that I have ready access to MSOffice, Flash, and mp3/iOS apps. I could find a work-around to be able to use Linux, but life is just too short.

Building the requirements

I’ve been doing some initial work on the app now and have built the basics stylesheets and database tables to let me develop the app and be able to see what I’m doing. It’s important to me to be able to see some meaningful output as I work, and the initial CSS only took half an hour or so to knock up. Plus, I find it easier to keep good HTML coding in mind if I have an output model to aim at – I know the structure of the markup I want to put out and I can change the look of it to something a bit more professional once I’ve built the basic framework of the code.

The requirements text looks like this so far:

Overview

Birding Record is a tool to help birders keep track of the birds they see, the venues they go to and the birding trips they make. The software should be as easy to use as a paper tick-list, but powerful and flexible enough to be able to analyse records in whatever way the birder needs to get the most out of their hobby.

What it is

Birding Record provides:

• as many lists as the birder needs to record the birds they see
• for non-year lists, a simple tick yes or no which records the date seen
• for year lists, a tick to record yes or no, plus a ‘first date seen’ and ‘last date seen’ field for recording migrant arrival and departure dates
• bird records provide space for notes, and for users to upload their own sound and image files for each species
• venue records let you record details for the places you go birding
• journal records let you record notes and bird counts for species seen on each trip, and these can be linked to venue records to build up a detailed record over time

What it is not

Birding Record does not provide:

• field guide notes to help identify species—the aim is for the birder to record their own notes as they go rather than to provide generic information for them
• venue information for where to see birds
• wider migration records for species (although it is hoped that, with a big enough user population, we could collate results on a central site)

My first big decision

I am stuck on how to associate bird records with the lists they appear on. For each bird I would like to be able to record a number of lists, with a simple true/false record to show if that bird should appear as ticked on that list. There appears to be two ways to do this:

• Record this value in the Bird table – nice and easy but will require a more substantial update to add new lists as I’ll need to update every record in the table
• Record these values in a separate table for the list and provide a separate table for each list with each row recording the bird id and date ticked. Makes the queries a level more complex, but would allow for recording extra data such as date last seen and count

Database good practice leads to the latter, only recording the data for birds you have seen. The extra flexibility of being able to record additional data for each tick is promising, the only downsides being slightly more convoluted queries and a bit of overhead to create the table in the first place as it will need to be created with 500-odd rows to initialise the data for each bird. This seems like a small price to pay though, so I’ll build the structure like this, at least to begin with.

I’ve been wanting to try and extend what I do with PHP development for a while. I’ve been coding in it for a while, and I think its time that I put something out for others to look at and use. I’ve been working on an application to manage tasks and projects, thinking a lot about what I need the app to do, and building a framework in which I can develop the code to deliver the functionality. This is ready to go – more on this in another post.

This is all well and good, but the process has been long and the changes very many. Not something that I could put together and write up as great example of developing and delivering software. My idea is to push through and build some of the other apps I’ve been thinking about and keeping a journal here to document my thoughts and processes. I’m doing the work in quite small chunks on the train which gives me a good amount of stuff to write up each day.

The project

The first app I’m building is a tool to help birders keep tick lists and journal entries. I’ve had a look at software available and there doesn’t seem to be anything available online, and the installable software seems to be mainly for PC (not suitable for me as a strictly Mac/Linux user). The core features need to be:

• All British birds are maintained in a database with details on names, categories and other non-changeable (or rarely-changeable) data
• lists for users to keep a record of which birds they’ve seen – life lists, year lists, garden lists, county lists, etc. – some already in place but users can add their own. Each record can be linked to dates so that the user can build up a picture over the years of migration patterns for birds in their areas of interest
• main page will show the list of birds with ticks to show which have been seen on which list
• Detailed pages for each bird will allow users to upload their own photos, notes and audio to build their own record of information for each species
• Journal allows users to record detail for individual birding trips, with links to bird species pages where applicable

These will form the basis of the design spec and screen layout, and I’ll build the architecture in such a way that I can easily extend and add features once it is all up and running.

Watch this space…

Post script: Anyone reading this who wants to have a look at my task management application and give me some feedback – please drop me a line!

I was going to reinstall ubuntu this morning. I’ve been playing about with openbox, kubuntu, ubuntu studio and others, and my system felt like it was getting a bit clogged up. Conky was showing odd behaviour on the CPU, RAM usage was high, and it generally looked like there were far too many processes running. Time to reinstall, thought I.

But no. Half an hour spent judiciously pruning software in Synaptic, and some minor config file tweaking later, and I’m back up with a lithe, almost pristine system. And with no time-consuming reinstalling and reconfiguring, not to mention the lack of stress I always get when I hit the continue button after repartitioning. Even if I know I’m all backed up and have done all I need to, I always suffer the heebie-jeebies after OK’ing that “You do know that all of your data is about to be destroyed? All of it?” dialog.

Long and short – I’m keeping on top of my game and actually quite enjoying not stressing about the system I’m using. I’ve also started to look at Linux home recording stuff ready to write and play some new songs. More on that anon.