Should I Write My Own?

I've been making an effort in recent years to look first for something that exists already that I can use, rather than choosing by default to write my own solution for tasks that can be solved with software. Sometimes that's difficult because the thing I need is very particular to some internal requirements. At other times, it's difficult because the task is an obvious and common one and a gazillion people have solved it and the task of evaluating all those solutions seems bigger than writing a new tool from scratch.

My current project is backup. This seems like one that might have been solved a few times already. And it's a task that I've solved a few times already myself. In this case, I want something that does what Dropbox advertises, except that the data needs to be encrypted on my machines so that only opaque blobs are stored in the cloud. I had a look at Spideroak, which claims to do what I want—but, the first dozen times I ran the client software, it crashed. This does not fill me with confidence for that sad day in the future when I might want to access my data. And in any case it doesn't give me the other thing I want—the ability to select the places where the data will live. I want the data to be stored in redundant, widely separated data centres, all under different control.

I've done a lot of Googling, and a ton of reading announcements and documentation for various solutions. Nothing quite does what I want, at least among the things I've so far found. But I'm thinking that a little bit of scripting, some cron jobs and some tools like rsync and/or Duplicity might just achieve what I want. At least in this day of cheap disks the job of testing out the critical restore capability is just a matter of tedium. I might have more to say about this in the future.

Face Down Baby

I just watched a young mother get her priorities completely mixed up. She was crossing a minor road using a pedestrian crossing. I was driving the only moving vehicle on that road and was approaching the crossing at walking speed as I prepared to stop for her. She focused all her attention on me.

Her baby, about two, pitched forward out of the stroller she was pushing and landed face first on the road. Mother didn't notice, although I could clearly hear his screams inside my sealed car. She kept pushing, scraping his face along the ground. She didn't even look down for a second to see why she had to struggle to push.

It was not until I beeped my horn and waved frantically at her and the baby that she noticed the problem. Then she dashed around, grabbed him by the arm and dragged him and stroller off the road. Last I saw, the baby was making his feelings about this pretty clear. I just hope she gets a few clues from today's experience.

Who Cares About Free Speech?

It seems that everybody is allowed to write a book about themselves, unless our fine government dislikes them or their message. To quote from the Overland Blog, "On 20 July 2011, the Australian government served David Hicks with a notice of their intent to restrain any funds obtained from the sale of his book, Guantanamo: My Journey, under the Commonwealth Proceeds of Crime Act."

The Overland team have written more about this and have begun a Petition in Support of David Hicks which I have signed. I urge other people who believe in freedom of speech to sign it too—regardless of your feelings about David Hicks the man.

An Unexpected Insight

Way back when I was a newish programmer, I discovered something that probably every programmer has discovered: explaining the problem you're stuck on to somebody else will often cause the penny to drop and you'll see the answer quite clearly just because you have articulated the story for the other person. It turns out that this effect is not limited to solving programming puzzles.

Just the other day, I wrote about my decision to return to Python, specifically Python 3.2+, for my next software project and I articulated some reasons for that decision. Telling my small blog audience about that was a catalyst.

Yesterday, while working on something not connected with software, I became aware that I was unhappy about something. I let that awareness sit for a couple of hours while i completed my task and then sat down in a comfy chair to reflect.

What became clear to me was that I was unhappy about the Python decision. One of the goals of my recent research into programming languages was that I felt the urge to learn a new language. Not just any new language, but a language that would introduce me to some aspect of programming that was not familiar to me. While Python 3 is a new language for a Python 1.2 programmer, it's not really a new language and doesn't involve the kind of learning I had in mind. And so, if I just focus on Python, I'll certainly be able to write some software, but I won't get the mental stretch I was looking for.

Further thought has given me a new plan. I will still learn the latest Python incarnation properly and keep up to date with it, because it seems likely that Python's ease of use, wide applicability and the excellent local Python community are all things that will make it a useful language for me to employ for quite some time. But I will continue my study of some functional languages, excluding Erlang for the reasons I gave the other day, focusing on Haskell and Clojure for the time being. One new idea that came out of my latest thinking is that it might be smarter for me to devote smaller bits of time more regularly to my study rather than trying to read several pages of a dense textbook in one sitting.

I need to keep reminding myself that one of the principal goals is for this to be enjoyable. Hopefully, this two-pronged approach that allows me the time to get comfortable with two or three languages together will produce the result I'm looking for.

Erlang Misses The Boat

There is much to like about Erlang, especially its great support for concurrency, distributed processing, hot swapping code and the functional programming model. And it's a mature language, even perhaps a bit long in the tooth. As with many languages, the available books are a mixed bag and generally not very inspiring (although often a bit too full of fanboism).

Nevertheless, I persevered with my collection of books on and off over several weeks before starting to think that it was a toss up between Erlang really being too hard to use or me being too thick to get the magic. And then I found What Sucks About Erlang by Damien Katz, somebody who actually uses the language. And I instantly recognized all the gotchas he mentioned as the same things I had been bumping up against. There's no point in repeating Damien's story, just read the original for all you need to know.

So, rather reluctantly in view of the strengths of the language, I decided that for me, for now, Erlang is not the way forward. One of my prime goals in writing software is that it should be enjoyable, and with Erlang and the kind of stuff I have in mind at present, it wouldn't be fun at all.

Back to Normal

I've neglected this blog over the past seven months, due initially to escalating family dramas and then to inertia. The dramas are not material for the blog and seem to have settled sufficiently for me to turn back to what I call normal life.

My major project this year has been to tackle some new software development and, as part of that, to learn some new stuff. That took me on a tour of interesting programming languages in the hope that I could combine a new language with my development project. In no particular order, I've looked at some Lisp languages (Scheme, Common Lisp, Clojure) and some functional languages (Erlang, Haskell). All of them appeal in some ways and not in others. I'll try to cover the salient points in subsequent posts, but the take home lesson is that I've decided to go back to an old favourite, Python, for now.

I've been writing in Python for almost twenty years, and the fact that most of my code is written for Python-1.2 is a symptom of that. I've modified it over the years to accommodate what I call gratuitous changes in the language and libraries (which the Python community have of course all considered carefully and determined to be improvements). Being fully engaged in my work, I have not participated in the Python development process in any way for many years and that has left me in an awkward position when it comes to whining about the evolution of the language.

So I've decided on two steps for the immediate future. I'm going to sit down and learn Python-3.2+ thoroughly to get up to speed with the current state of the language and I'm going to pay attention to the ongoing development of the language in order to stay current. I may even manage to contribute in some way to Python. I'll probably return to some of those other languages in a year or so, to keep my brain open to useful ideas, but I think most of my work will be with Python and C for the present.