Showing posts with label software. Show all posts
Showing posts with label software. Show all posts

Friday, October 14, 2011

Goodbye dmr

Like so many others in the world of software, I was greatly saddened yesterday by the news of Dennis Ritchie's death. We have lost a great contributor to our world and a really fine man. I first read K&R in 1980—a free copy included with my first Unix licence—and it changed my life. The book and the C language both shared many virtues which are so widely-known that I won't repeat that story now.

My first direct connection with dmr was an email he wrote to me back in the days of Usenet, something he avoided. But somebody had alerted him to a piece I had written and he thought it would be good to disabuse me of a misunderstanding. His email to me was as clear and spare as the book and his tone was perfect—polite, respectful, generous and kind. Naturally, I corrected my error in the forum where I had first written.

A couple of years later, after K&R2 had been published, I pontificated about the correct way to do something in C and was shouted down by people who were conversant with the new edition—a book I owned but had not read carefully at that time. I said K&R was wrong if they disagreed with me, expecting to find that those people had mis-read the book. Subsequent research revealed to me that K&R did put things differently from my understanding. So I wrote to Dennis and asked him to help out. Initially he said he thought the book was right. But when I wrote back with a detailed explanation for my belief, he promptly replied that I was right and the book was wrong. This resulted in an extra item in the still short errata for K&R2. What impressed me most in that exchange of email was that dmr never acted as if he had all the answers, but was ready to listen carefully to anybody who had something to say. I have tried to learn that from him.

Later I had the opportunity to meet him in person at a conference where he gave a keynote about an early release of Plan 9. He wore his hat with a propeller on top and gave a great talk. In person, dmr is just as nice as I had expected from my other interactions with him. We had occasion to correspond about C and its directions several times after that and I'm very grateful for his thoughtful and amusing emails.

Although this is really about Dennis, it seems wrong not to also mention his collaborator on K&R. I never met Brian in person, but have had email correspondence with him too. He showed the same wonderful manner of communication as did Dennis. I think of them both as mentors.

So, thank you, Dennis Ritchie. You have made a powerful and admirable mark upon our world.

Tuesday, August 23, 2011

Test Driven Freedom

Like most programmers, I've been writing bits of test code all my life; but I've never embraced Test-driven development (TDD). There are many reasons, but probably the principal ones were an expectation that TDD would slow me down and a belief that my existing methods worked fine—at least in the context in which I have worked for the past few decades.

Circumstances change and one of the changes facing me is that I appear to have spare cycles that could be applied to some free software development. Finding myself ready to begin creation of a new utility—for myself, but with wider usefulness likely—I thought I'd devote a day to experimenting with TDD. It has been an interesting experience.

Yes, it did slow me down, mainly because I was getting used to a completely new way of writing code and, to a lesser extent, because I was writing more code than I would have in the past. It will take me some time to get up to speed with TDD, but I can envisage a time when I could expect to travel at about the same speed as I'm used to. I take that as a positive lesson from today's experiment.

The more interesting discovery, for me, was something that I had not thought about at all, although it should have been obvious from the reading I had done. The process of small discrete steps (write a little test, watch it fail, write a little code to make it pass, refactor, repeat) keeps things in a state where the usual interruptions are much less of an issue. My usual way of working involves holding a substantial mass of code in mind at any time and interruptions are a real killer. I can usually arrange for blocks of uninterrupted time, but that's not always possible.

Today, while I was at my least amenable to interruptions because I was learning something new, it just so happened that my spouse needed to interrupt me several times. Each time I was able to turn away from what I was doing and resume fifteen or thirty or more minutes later without any stress—the small step that was interrupted turned out to be easy to resume without any difficulty. That alone seems like a reason to keep going with TDD for a few months to see if it can become part of my approach.

And, to return to the original issue, provision of a full unit test suite should make it much easier for other people to take the code and adapt it for their own purposes.

Friday, July 29, 2011

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.

Friday, July 8, 2011

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.

Thursday, November 25, 2010

A Solaris Puzzle

I wrote about issues installing an operating system on some new hardware a few days ago. Since then I've done more exploring. A subsequent attempt to install Ubuntu 10.10 on the same box was a success, right up to the part where you reboot from the newly-installed system. That was a total failure and required power cycling to escape.

Then, several restarts later (due to my lack of speed on the DEL key), I managed to get at the BIOS. I decided to start from scratch, and loaded the safe defaults. Then I went through and tweaked it carefully (and very conservatively). After that, it booted fine. To be sure of this, I rebooted it (both warm and cold) about 30 times. All good. Then I left it to its own devices with a bunch of stuff running for a couple of days. Still good.

Then I tried again to install my Solaris-11 system, hoping that it would work on the new setup. No joy at all. The installer crashed, several times, in exactly the same place as before (i.e., long before getting close to actually installing anything). I really wanted to be able to use ZFS, which I think is a wonderful file system, but it seems impossible for me to install Solaris on any reasonably up to date hardware that I have available. I think I'm over this now and will wait for some other operating system that I can bear to use offering native ZFS.

Tuesday, November 16, 2010

Easy Does It

Back in the present today, for a look at some software that I was wrestling with yesterday. I often whine about issues with free software that is hard to use or configure or that crashes messily. But it's rare for me to complain about commercial software. I'd hate people to think that was because commercial software is better when the real reason is simply that I avoid using commercial software as far as possible. But yesterday I spent some time with three of Atlassian's products (for which I have the cheap Starter Licenses).

Why? There are times when friends tell me I should use the Atlassian software rather than wasting my time with less-capable or otherwise deficient free software and I finally thought I'd combine two things by contributing a few dollars to the charity that Atlassian supports and trying out their software.

I downloaded Confluence, Jira and GreenHopper and installed Confluence first on a bare Ubuntu box. Along the way, I carefully followed every step of the instructions, including installation of additional software packages that were required. I configured a brand new MySQL installation as instructed. Then I started Confluence and began to step through its config screens per the instructions. Somewhere along the way, I encountered an error with an insane diagnostic.

Always willing to assign blame to myself in the first instance, I blew away the entire installation and began again. Again, I was meticulous about following the instructions. Again I got the same error.

I mention my following the instructions because this is a big deal for me. I'm one of those sad people who reads the owner's manual for a new car or a new mouse from cover to cover before using it, even though there is virtually no chance that I'll learn anything from my reading. But I am confident in my ability to follow written instructions perfectly. When I can't get a piece of software to work after carefully following the instructions, the problem is with the software. The instructions are part of the software, which is why I say the problem is with the software.

I'm sure I could probably get somebody at Atlassian to step me through the setup for Confluence, but I'm not interested in doing that. I've learnt all I need to know. That means that I won't use any of the Atlassian products, nor will I suggest that other people try them. I'm really documenting this here so I can point to it any time somebody suggests Confluence or Jira to me in the future.

Wednesday, August 25, 2010

Giving Chrome Another Chance

Back in February, I reported my intention to try Chrome as a replacement for Firefox. A week later, although most parts of the experiment went well, I reported that Chrome was useless for printing in Australia (or anywhere that uses A4 paper).

That was a blow, but I hoped that Google—despite their complete contempt for bug reports from their users—might one day rectify this issue. Naturally, when they did fix it, they did not announce that in any place that was useful to me and so I discovered the fix by accident. If I was cynical, I might even think they had fixed it by accident. But I won’t go there.

At any rate, now that Chrome appears to be able to do almost all the things I need, I’m going to drop Firefox again and see if I can manage with just Chrome. That’s where I’ll find out if “almost all” might really be “all”—if Chrome can manage with 12 windows and 180 tabs open, which is what I currently have going on this desktop. In fact, if it’s at least only half as clunky and slow as Firefox, that will be wonderful.

Saturday, August 14, 2010

Is Oracle the new SCO?

I avoided Java for many years, partly because I thought it was a failure in language design and partly because I found Sun's tight control disconcerting. I avoided Solaris because of Sun's tight control and because there were plenty of satisfactory alternatives.

When OpenSolaris appeared, I began to experiment with it. It still felt risky, but operating systems are much easier to change than the languages you use to create software with, so the risks seemed acceptable. When Sun made moves to open Java up, I began to consider using it or, more likely, other languages that built on the JVM.

Then Sun fell in a hole and I put things on hold. I had some hopes for a takeover by IBM, based on my belief that that they might continue the Sun stuff of interest in a way I could live with. That might have been unduly optimistic, but is now irrelevant. IBM went away and Oracle stepped in. Oracle is not a company I have ever admired in any way and it is run by a man I find even less admirable than Bill Gates. But many analysts, who claimed to have better sources of information than I have, seemed to think that Oracle would probably continue with OpenSolaris and would certainly nurture Java.

Now it appears that OpenSolaris is dead. And Larry Ellison has decided to tackle Google over Java. I have no idea how that will unfold. I do know that Google have the money to withstand a legal challenge. I'd like to see Oracle do a SCO and collapse under the legal mess, although I fear that they might survive. I am certainly going to avoid OpenSolaris and Java for the next few months or years. I'm also starting to think about alternatives to OpenOffice. I'd love big Oracle customers to announce that they are going to walk away from Oracle because they can't rely on Oracle's ability to survive.

At least database technology is pretty much a solved problem and alternatives to Oracle exist and others can be created. So it will be possible for people to drop the Oracle database money pit. Getting everybody to walk away from their Java investments will be much harder, but I'd like to see people considering that too. At least I have nothing to lose, having no investment in either Java or Oracle. But I will be cheering for anybody who helps to cut the ground from under Oracle.

Friday, July 16, 2010

In Which I Yield to Powerful Forces

As long ago as it was possible, I began running my own mail servers. Over the years, I employed a variety of software and hardware and for the past decade or more I've had to run antispam software as well. I did it partly to avoid the alternatives (which were pretty unsatisfactory in the early days) and partly to understand the process in case clients needed help with their mail servers.

Happily, I am now without clients. And the alternatives might not be so bad. But I am stubborn, so I decided to solve my most recent problem by setting up some new software on a VM in the USA. The problem I was solving was the increasing unreliability of my ADSL connection—not through any fault of my excellent ISP, but because Telstra appears to have a policy of letting the copper infrastructure decay sufficiently that any successor won't be at all glad to be saddled with it. At any rate, there have been no spare pairs in my street since we got the last pair five years ago. Since then, we've had line faults after every heavy rain and it takes between three and seven days to fix things, where "fix" means find the wet joint, dry it out, patch it up and say "she'll be right now mate."

So I looked at all-in-one solutions for email, in the mistaken belief that there would be something out there that I could more or less just drop into place on a VM, do a bit of DNS magic and sit back happily. I looked at Horde, Zimbra, Zarafa, Courier and a couple of others whose names escape me now. They probably are all capable of doing the job, but all require a great deal of dedicated setup and they look as though they need a fair bit of care and feeding once they are operational. None of them looked like what I wanted and I started thinking that if these were the answer to my question, I must have asked the wrong question.

So I considered Google. I've had a bunch of gmail accounts ever since it was launched. I don't particularly like it, although that's mainly just me. And, for various reasons which I can't talk about here, plain gmail accounts don't work for much of the email I have to provide. But Google Apps offer a bit more than just gmail, so I thought I'd spend a little bit of time investigating. I gave myself a maximum of one day to complete this and in fact needed much less. I now have all email addressed to my 11 operational domains going to Google Apps accounts for me and my wife. Nobody has to change the email addresses they use, and the outgoing email looks as though it still comes from where it always did.

And Google's antispam stuff is awesome. So far, we've had a few thousand emails arrive and every spam has been caught without a single false positive. It's so good that I'm going to stop checking the spam folders now. This is so simple that it's a total no-brainer for me. The only possible downside is storing our email with Google, but that is easy to fix via their nice API that allows you to download it all for storage wherever you like.

Well, the other possible downside is that my wife might spit the dummy when she returns from seven weeks in Europe on Monday and discovers that she is not using exmh any more. But it will be too late and I hope it won't end in tears. At least she has been using one of the ordinary gmail accounts every day while she's been away, so she is familiar with how it works.

Wednesday, June 30, 2010

Programming Languages

People who know me will be aware that I've been exploring the suitability of various programming languages for some software that I want to work on. Abetted by my ADHD/Aspie brain, this has been a bit like Alice falling down the rabbit hole into a world of weirdness. As the weeks go by, my collection of potential languages has grown much faster than my ability to do any of the evaluation that I was planning.

For the record, the list now consists of x86 Assembly Language, C, Python, Lua, Scheme/Racket, Common Lisp, Clojure, Erlang, Haskell and Javascript (in no particular order). And, if Clojure is involved, that would also mean learning Java—something I have assiduously avoided for the last 15 years. The more I add to this crazy pile, the more sure I am that I must be missing the perfect answer, even though the sane bits of my mind know that there is no perfect answer. Of course, the longer I amuse myself in this pseudo-analysis, the longer I am safe from having to put any work in on any of the real projects on my list.

It would be nice to be able to say that this insight has freed me from analysis paralysis and that I'm just going to start on something. After all, I am good at telling other people that any decision is better than no decision and that even a wrong decision can be easily fixed once it's clear that it was wrong. I'm less capable of listening to my own good advice. However, it has occurred to me that I could just decide on one step right here and now. So, for no reason other than that it's the language I know least about, I'm going to do some work with Clojure over the next week or two to see if it's a real candidate or not. The others can wait.

Friday, June 18, 2010

Constant Improvements

A couple of days ago, I wrote about a customer service failure at FooBar Motors. I did not identify the company because they generally do a pretty good job of looking after their customers and that's why I keep buying cars from them and why I keep getting those cars serviced by them. The thing I was getting at is that, even when the culture is to provide great service, it's not always easy to get all the details right.

That brings me to my domain—software. We creators of software probably make more painful hoops for our customers to jump through than even the worst car dealership. And, in some ways, we have much less of an excuse: software is infinitely malleable, so we just have to fix it when it's hard to use. But we don't always know that it's hard to use. When we test it, we're kind to it and treat it the way we meant it to be treated. When it resists us, we understand it well enough to gently persuade it to go where we want. When it tells us lies, we don't feel too concerned because we understand why it lied. Besides, it's our baby and we don't like to be told that our baby is ugly, so we resort to that ever-reliable solution—denial.

And of course software is difficult to test. There are so many ways to get where you think you want to go that it's almost certain that a user will find pathways that we neither intended nor perhaps even noticed and which we certainly did not get right. Lots of people have written papers and books and given presentations about the business of software testing and I'm not going to try to push any particular approach on you today. But I think it's really important for all of us who create software to recognize that we are far from getting the testing right and that it's something that we must pay better attention to in the future.