I like Android for a couple of reasons. The first is that it slots into the Google Apps ecosystem that I built much of my online life around prior to getting an Android phone — an excellent Gmail app for starters, but also my use of calendaring has improved significantly since getting my ADP1.
The second is that it’s Open Source. This means that (provided you have a suitable handset), it’s possible to obtain or write your own custom firmware which lets the phone do more than what its manufacturer intended. This, for me at least means running later versions of Android well past the support of the manufacturer.
This is a delayed post which is likely to show up as I’m several kilometres above New Zealand. The next few posts may/may not be delayed.
Nothing particularly fixed as far as food is concerned. I’ll eat whatever I can find (that I’d actually like to eat). Drinks, however, are a different story.
Firstly, I’m a second-rate coffee snob. I’ll only drink arabica-type beans, usually as a caffe latte, however, if circumstances dictate, I’ll have a plunger coffee au lait. If I have coffee out, it’s only acceptable if it’s better than the typical coffee that I have at home. This means I don’t drink that much coffee out.
Preferred soft drinks include a rotation between coke and lemonade, which is what usually powers me through a day’s coding/writing.
As it turns out, probably about 90% of the coding that I do these days is in the form of nifty hacks. This is particularly because in research the impetus is not necessarily to have code that is reusable in a lot of situations, but rather to try out an idea quickly and then throw the code .
For example, just today, I needed a couple of images to put into my research poster for the conference I’m presenting at in a couple of days’ time. This involved drawing some rectangles over photos were faces had been detected by some other software. Basically, by having sufficient data in a format I had documented (in the form of other code) this was easy to extract. There are countless other things in my Honours thesis which looks somewhat like this — lots of experiments done with a tiny bit of Python code tying other big packages together.
The hacks that I’m proudest of are the ones which provide me with sufficient useful output that I can reuse their results, and not necessarily the code.
 Obviously, no code should ever be thrown away. When I say ‘throw away’, I mean something more along the lines of ‘ceasing maintainence’. This is because you can never know when a piece of code you’ve already written could be useful.
When Jethro proposed this topic, he was probably thinking of computer programs. I’m going left-field. My greatest application to date was my application to become an intern at Google.
I applied for my internship in July of 2009, and heard nothing back from them until late October; I finally got accepted in late November, just a week out from when I was due to start. Despite the difficulties involved with moving away from home, to a completely different state at two week’s notice, the experience of living in Sydney and working daily with some of the most brilliant and driven geeks I’ve ever met was one that’s affected me greatly.
Being an intern at Google taught me a lot of things. Firstly it gave me exposure to being a part of a larger team of developers — there’s a very strong culture of discussion and peer review within that company, and learning to both get my own code reviewed, and justify decisions I’d made to people who are smarter than me was quite an important learning experience. Secondly I got an opportunity to learn how coding works in a large distributed environment such as Google’s. Neither of those experiences I’d have had elsewhere, and it’s definitely put me in better stead.
Getting an opportunity to learn and apply programming techniques to an interesting problem, and getting to meet all manner of interesting people was a fantastic experience. And I wouldn’t gave got there if it weren’t for making an application.
I have three things that I usually do with my day-to-day life:
First up, I’m an eternal student (or at least, I usually am). Unusually, this semester’s been spent not studying anything for the first time in most of my life; though I intend to take up a Ph.D. candidature from next year. I’ll probably be studying in the field of machine learning, since that’s what my Honours thesis focused on, and I seem to enjoy it somewhat.
Other than that, I’m an itinerant tutor at the University of Tasmania. I taught computer graphics programming (OpenGL et all) this semester, and machine learning the semester before that. I love having the opportunity to help people learn how to do things, and it’s great fun trying to convey some of my own knowledge to people who want to receive it. On the other hand, I hate having to deal with people who either don’t have the skill set to be taking the units which I teach, or people who don’t want to learn — marking assignments from people who don’t have a clue, or otherwise don’t care is a nightmare.
I also accept short-term contract coding whenever I can be bothered. The most unusual thing I’ve done in that respect is implementing a piece of installation art for a roller derby match. That was bizarre
This invariably changes, depending on what work I can be bothered doing at the time, so what I’ve said now probably won’t be the case in six months time.
Python. Need you have asked?
I use Python because it’s expressive, contains enough functionality out of the box to solve most substantial coding problems I have quickly; for everything else, there’s a fantastic array of libraries and frameworks for doing everything from image manipulation to statistical analysis. As a researcher, Python is an invaluable tool, and that’s why I use it.
Right, so for those of you who missed my announcement a couple of weeks ago, I’m taking part in the 30 Days of Geek blogging challenge throughout November. This is the first of those posts.
So this first of those posts. So, why do I consider myself a geek? I could list any number of stereotypical character traits, which I do see quite obviously in myself, but instead I’m going to go with just the one which sums up the most important issues nicely: Unhealthy obsession.
Let me explain. As I see it, the most important path to geekery is having a knowledge and understanding of a topic that exceeds that of other people you know. It tends to help if there is more than one such topic of which one has such a mastery.
I’ll start with the obvious first topic: I have an unhealthy obsession with computers. I learnt to program for the first time when I was 11 (MS QuickBasic 4.5 if I recall correctly) and I had a fascination for playing with settings on my family’s first Win98 machine (which resulted in doing a format/restore three times in the first six months of its ownership). Such tinkering left me in good stead for learning Linux a few years later: on the machine I had at the time, getting anything to work at all required hours browsing forums to find people with similar problems. Further to that, I could take the knowledge of how to solve these sorts of problems in Linux and apply them to new situations, frequently in an unrelated area of my system. I don’t think I’d have got anywhere near as far as I did without the unhealthy obsession with Linux I had at the time — this enabled me to spend weeks (when I had schoolwork to go on with) with a not-entirely-working computer, but fixing its problems.
So that’s probably the answer you expected to see. But it’s not just being good with computers that makes me a geek. This unhealthy obsession applies in other areas of interest. For example, I’m a keen follower of the Formula 1 motor racing series . Whilst other people are content with just watching the races as they pop around, I spend ages learning the details which apply to each race — if I’ve a game where I can drive around a circuit to learn its layout I’ll do so. I’ll read Wikipedia so I can find out why people frequently crash at a given point on a track; and then I can relate the knowledge I’ve learnt from reading and gaming to the commentary of the race — which in turn feeds into a greater understanding of the race, which feeds into further learning about the event. Without the unhealthy obsession which comes with being a geek, I doubt I’d have the same level of interest (nor enjoyment) that I have.
So there, two examples of applied geekery, and how they relate to the my preferred reason for being a geek.
Up next, more in-depth questions. If I remember.
 Shock horror! I follow sports! Sorry if you think this disqualifies me.
In today’s exciting post I describe a rather amusing series of events and the end result of it:
- In August I submitted a paper to a Computer Vision conference being held in New Zealand in November. This is entirely sensible because my honours research received a first-class grade and was in the field of computer vision.
- In September, a large earthquake occurred in the Christchurch region, causing much pandemonium amongst organisers of said conference.
- On Tuesday this week, my paper got accepted. Naturally, the conference was organised by people in Christchurch, and they were disrupted by several weeks due to the earthquake.
So the conference is on November 8 and 9 in Queenstown, New Zealand; this leaves me just over two weeks to:
- Arrange travel
- Revise the paper based upon reviewers’ comments
- Prepare a poster to present at the conference
- Get there
My friend Jethro Carr has just suggested another 30-day blogging challenge, and unlike the last one, this one doesn’t require me to be highly introspective and emotional, which I can gladly cope with :). Instead, the topic this time around is 30 days of geek.
The topics that Jethro’s suggested are:
- Day 01 – Why do you consider yourself a geek?
- Day 02 – Preferred programming language?
- Day 03 – What does your day job involve?
- Day 04 – Greatest application written to date.
- Day 05 – Quick nifty hacks you’re proud of
- Day 06 – Primary geek fuel (snacks/drinks)
- Day 07 – Preferred smartphone platform. And which do you use?
- Day 08 – Preferred method of communication with humans
- Day 09 – What OS/distribution do you run?
- Day 10 – Picture, screenshot and specifications of your primary computer.
- Day 11 – Favourite hacking environment – music, light, seating, etc
- Day 12 – What area do you want to expand your skills into?
- Day 13 – How did you become such a geek? Career? Personal interest?
- Day 14 – Favourite computer conference?
- Day 15 – Earliest geek experience
- Day 16 – First computer you’ve ever owned & your favourite ever.
- Day 17 – Post a useful HOWTO to solve a challenge you’ve come across recently.
- Day 18 – Most cringe-worthy geek moment
- Day 19 – Most hated computing environment.
- Day 20 – Where do you stand on Internet Censorship?
- Day 21 – Favourite thing & worst things about working in IT?
- Day 22 – Release some software under an open source license that you haven’t released before.
- Day 23 – Post a review of an application that you use.
- Day 24 – How do you feel about Open Source vs Proprietary software?
- Day 25 – Microsoft – friend, foe or other?
- Day 26 – Apple – friend, foe or other?
- Day 27 – Fix a bug in some open source software and commit the patch
- Day 28 – How many computers lying about the house?
- Day 29 – Looking back (at geek life), would you have done anything differently?
- Day 30 – Where do you see technology advancing in the next 20 years – and where will you fit in?
Hopefully by the end of this you’ll have a good insight into my geekiness — posts will start showing up on November 1st.
In case you’ve missed it in other channels, the linux.conf.au 2011 miniconf CFPs close on Friday October 22 (for the most part).
For my part, I’m still looking for more presentations for the Open Programming and Research & Student Innovation miniconfs. The descriptions are as follows:
Open Programming Miniconf
The LCA2011 Open Programming Miniconf helps bridge the gap between the low-level developer and the end-user by bringing the topic of tools and techniques for application development to Linux.conf.au.
We invite 25-minute talks on a wide range of topics, tools and languages with the aim of bringing together open source developers with presentations that share techniques, best practices and values amongst users of all open source programming languages.
If you know something about a topic of interest to the LCA Developer community, please read our call for presentations and submit a proposal!
To submit a proposal for the Open Programming Miniconf, you can find the CFP at http://blogs.tucs.org.au/opm/cfp
Research & Student Innovation
The FOSS in Research and Student Innovation Miniconf brings together researchers and students with an active interest in Free and Open Source Software with the broader Linux.conf.au community to highlight exciting work taking place within the often esoteric world of academia and educational institutions.
We invite 25-minute presentations on topics in two streams: “FOSS in Research”, which provides an informal outlet for those pursuing topics of interest to FOSS communities in their studies; and “Student Innovation”, which brings the perspective of the student delegation to the forefront, by allowing them to share their experiences of FOSS with the broader LCA community.
To submit a proposal, visit the CFP at http://blogs.tucs.org.au/frsi/cfp