This week, I was tasked with gathering and analyzing some data at my job. The task involved generating a couple of thousand data-points and examining their spread. The first part was easy, and accomplished in a couple of hours. What happened next was interesting though.

My script to gather/generate the data was written in python, so by the end of each run I had a large data structure in memory with all the results in. After printing some random samples to make sure the data was all in the correct ranges, I considered how to analyze it. A graph seemed the obvious choice and for my particular data-set an x/y scatter plot would be very useful. This decided, I went looking for a way of drawing such a thing.

My thoughts immediately went to finding a python library that would render the chart for me. After asking around a couple of my fellow developers I took a look at matplotlib and was very impressed. It seemed to offer a huge range of different graph and chart types, along with a whole host of rendering options. I say ’seemed’, because I never actually used it. I realized that there was a much simpler solution to my problem.

Excel!

Excel, the spreadsheet software I was taught to use way back when I was 13 and not touched since. Technically, it’s all the things I dislike about software: bloated, over-engineered and closed-source. However, it does draw some pretty good charts with minimal work. Five minutes after realizing this, I had a thoroughly understandable representation of my data without writing a single extra line of code. Who’d have thought?

Could matplotlib have made the same chart? Of course. It probably would have had more colours, been in 3D and made you tea when you got up in the morning. On the downside, I didn’t really need any of those things, and it would have taken a whole afternoon, if not longer.

Similarly, I could have used an open-source solution such as OpenOffice or something lightweight like Google Docs. Excel just happened to be the most convenient option as it was already installed on my laptop at work.

The lesson I drew from this is that even though I can do some pretty cool things, I don’t always have to. Sometimes, existing solutions perform a task well enough and much faster to boot.

Firstly, what kinds of activities were Apple showing off in the keynote? Let’s see:

• Reading a book
• Watching a film
• Answering/Writing email
• Browsing the web
• Playing a video game
• Listening to music

With the exception of the last item, I don’t think I’d want to combine any of those two tasks, especially on the same device. Who watches a movie while they’re trying to read a book? Even if I do want to switch between two such activities – Look up the name of an actor in the movie I’m watching for example – I’d have to pause/save/bookmark my movie/game/page in order to do so. Even if I could keep my movie playing while I did a search on the web, I wouldn’t want to: I’d miss some of the action!

Music is an exception that should be addressed, and indeed already has. Like the iPhone, you can play music ‘in the background’ while you do other things. Problem solved! The same can be said for services that need notification; Mail, Twitter, etc. Can all notify you that a message has arrived without interrupting the current task.

The iPad is definitely not for everyone, but anyone who is on the fence shouldn’t be too concerned by the lack of multi-tasking. When you’re buried in your favourite book or watching the climactic scene of a movie you won’t care.

The good news is that I’ve made considerable progress over the last six weeks overhauling the back-end to make it easier to maintain and expand. I’ve also learned a lot more about relational databases in the process, which is good for me if not the plugin users.

The bad news is that this process isn’t finished yet, so it’ll be a little while longer before there is a new version available. I hope that anyone out there who is waiting for a new release isn’t too disappointed.

• Python
• Google App Engine
• Google Protocol Buffers
• Google DataStore
• Amazon’s SimpleDB
• Django templates
• Git

Feeling that my skillset was stagnating was one of the reasons that I left my last job, so being exposed to so many new ideas and methods is perfect. That’s all I have to say on the matter right now, but I’m sure I’ll have updates over the next weeks and months on any cool stuff that I do while I’m there.

In terms of functionality, I’ve updated the API requests to grab all the tickets for a project, instead of just the first ‘page’:

Still, not to worry. To avoid confusion and general awkwardness, I’m going to change the name of the app to Limelight. I’m pretty sure that there are no existing apps in the same domain with that name. Pretty sure. Not 100%. So if there are any app developers out there developing a Lighthouse app called Limelight… I’m sorry in advance. Hopefully I’ll be ok this time though.

I’m going to release a new version of the app with the changed name in the next couple of days.

Lighthouse is a lightweight hosted bug-tracker produced by entp. It’s advertised as “Beautifully Simple Issue Tracking”.

Lighthouse Keeper is a small AIR app produced by me. It allows you to export Lighthouse ticket info to a csv file.

Background

I learned about the existence of Lighthouse earlier this week at a job interview. I’ve used a couple of bug-trackers before, but Lighthouse had never appeared on my radar. The two guys interviewing me got into a spirited conversation with each other about the various pros and cons of different bug tracking solutions, but Lighthouse in particular. One of their comments was

I wish there was a way to export my tickets as a csv file.

Maybe someone will come up with something using the API.

That’s a challenge if I’ve ever heard one.

Implementation

I’m a big fan of Flash/Flex, so I set to work that evening on a small app that would grab Lighthouse projects for a given domain then allow you to perform searches on the tickets in an individual project and export the results. Fortunately, flex is designed around tasks just like this.

Lighthouse has a fairly comprehensive REST API available for developers. Using either your regular login info or a generated API key, you have access to (as far as I can tell) all of the functionality you get from the regular web interface.

Thanks to this, retrieving data from the API was achieved in less than an hour, and then the rest of the time (about 6 more hours) was spent wrangling it and tweaking the interface.

The current incarnation is still very much an experimental product, but I want to release it to let people (and prospective employers) test it out and see what they think.

Download

So, without further ado, here it is:

Lighthouse Keeper version 0.1

As always: Questions, comments, suggestions and criticism are welcomed and encouraged.

Ivan is a ‘Destroyer’. That’s the name of his class. That’s pretty awesome.  He has a dog called Boris who periodically goes back to town and sells all the loot Ivan picks up. That’s pretty awesome. Ivan’s shield is so big that it clips his shoulder-pad. That’s pretty awesome. This game has a demo available. Go try it right now!

It seems though that there is still interest in the plugin, so over the next few weeks I’m going to give it an overhaul. It’s been a long time coming, and since I first wrote the original code I’ve learned a lot about the ‘correct’ way to program web apps.

The current code is not very flexible: In order to implement the new features that are in the roadmap, I’m going to have to start again from scratch. This time I’m going to give the plugin a proper DB back-end, so that reaction text can be updated without resetting the count, and so that posts in different categories can have different reaction options (and a lot of other things, too!). This should also make it a lot easier to maintain and add further features to.

So, if you use wp-reactions, or are holding off until some of the features you want are available, rejoice! I expect to have a new version available by the end of the year.

Step 1: Find a picture of yourself.

Obviously, we’re going to need a picture to work with. The important part here is that it has to be of you. Twitter recommends this, and I understand why. An avatar should be unique, so that people can instantly recognize it and not confuse it with others. The most reliable way to do this is to use a picture of yourself. Using a picture of your favourite celebrity, comic-book character or pet might represent your interests, but you’re not the only person to have a crush on Nathan Fillion (That’s an entirely hypothetical example, btw)*. What’s more, if you change your avatar at a later date, as long as you use another picture of yourself people will still recognize who is posting. Human beings are very good at recognizing faces.

* I bet there are several thousand people running round the internet wearing Nathan Fillion’s face, but there should only be one person wearing yours. Unless you happen to be Nathan Fillion.

Step 2: Crop the image as close to your face as possible.

The thing to remember about an avatar is that it’s usually very small. In order to make sure you are as recognizable as possible, you should make your face fill as much of the avatar as possible. Note that your face is not the same as your head. Here’s an example featuring yours truely:

Look at all that extra space we got rid of! All the elements of the image that I want to display are still there: The hat, the badge, and my face. All the details are a lot easier to make out in the cropped image as it hasn’t been shrunk as much as the other one to fit in the 100×100 space available.

Step 3: Use the same avatar wherever you go.

This is less of an issue if all your avatars are pictures of you, but it’s still a good idea. Services such as Gravatar make this really easy, because it does all the hard work for you. Basically, using the same avatar (and the same username) everywhere you go on the net allows you to build up a more complete model of your personality across different services. For example, if I use the same avatar on all the different blogs I comment on, then other people who also read those same blogs will (hopefully) notice that I’m the same guy posting on all of them.

Conclusion

Avatars are our visual representatives online. I think that my best (and most honest) representative is me. I am by no means claiming that this is the be-all and end-all of avatar advice, but I do think that it’s a good starting point. If you have other ideas, or points that you think I should add, please comment!