I’m the only Google hit for “encapsulecurity”.

I said at the end of my sort-of review of Effective Java that a few things bugged me while reading it, not about the book, but about Java itself. These aren’t totally well-formed in my head, so I’m going to try to write them down in an attempt to get them to make sense. This may or may not work. Stay with me here.

I’m going to flick through the book to refresh my memory of stuff, so my thoughts will roughly follow the same order as the book, if you want to follow along.

Ah, here we go. A recommendation from chapter 2 (and the first itemised piece of advice in the book).

Item 1: Consider static factory methods instead of constructors

The gist of this is that constructors have some drawbacks. To name a few: they don’t have descriptive names; they always create a new object, where you might want to reuse an existing one; and they’re forced to return an object of that class, where you might want to use a subclass. Wrapping it in a static factory method gives you control over these things, and by making the constructor private or protected you can make the factory method the primary way for an API user to get a new object.

So, good advice. But there’s a little guy in the back of my head (you know the guy) who starts whispering little subversive things at points like this. He’s always yammering on about something, so it’s usually easy to ignore him, and I wasn’t really listening to him when I was only up to chapter 2… but by the time I was halfway through the book he’d said sensible things enough times in a row that I sort of started paying attention. Anyway, here’s what he said here:

Shouldn’t a language feature called a constructor support the ways that someone might want to construct an object? Why are we being advised to work around it?

Now, look, there are plenty flaws in that argument – the advice is that you consider using it where appropriate, not that constructors are always bad; and nowhere is it written that a language feature has to be usable from anywhere in its raw form for it to be useful. So the little guy hasn’t scored any points yet.

But keep this in mind. Later on (if I stay interested enough in the topic to keep writing about it) we’ll come back to why the little guy’s point was deeper than I realised at the time.

Okay, moving on. The next Item is about using an intermediate builder object when there are a lot of constructor parameters, especially if some of them are optional. There’s a comment in this section that I want to quote because it sort of sums up what my poorly-structured rant is about, albeit bluntly, and from a slightly different direction.

The Builder pattern simulates named optional parameters as found in Ada and Python.

And, I’ll add, most Lisp dialects, C#, Scala and, of all things, Visual Basic. Oh, and recent versions of Fortran. (Cheers to Rosetta Code. Also: there are recent versions of Fortran?) I’m not arguing with Bloch here – it’s good advice for writing Java – but if you have to write boilerplate to simulate what other languages give you for free, it might be a hint that the programmer is doing work that really lies in the bailiwick of the compiler.

I’ve clocked slightly more hours writing Java than Python, but the Python hours are more recent. Reading this made me think about closing the book and swearing allegiance to Python. (Apart from the performance problems and lack of type safety. Oh, and I wasn’t reading it with the intent of converting. I was just trying to stay up to date. Seriously. Guido, I’d never leave you.)

I’ll leave it there – only two Items into the book – but to give you an idea of where the rant is heading, here’s a short talk by Rob Pike about Go.

Our family is breaking with our old everyone-buys-a-gift-for-everyone tradition this year and doing Kris Kringle instead. There’s a bit of kerfuffle about how to select names and get word out to everyone; I mentioned to wifey that the cleanest way would be to write a short program to shuffle the names and send each person a private email. This probably isn’t going to happen at this stage, but I might suggest it for next year. (Should go down well.)

In the meantime, it got me thinking about how to deal with people drawing their own name, which anecdotally seems to happen at least once without fail. I brute-forced some statistics, and the probability of someone not drawing their own name in any given run seems to approach e^-1:

 1:        0 of        1 = zero
 2:        1 of        2 = 1 in 2.000000000000
 3:        2 of        6 = 1 in 3.000000000000
 4:        9 of       24 = 1 in 2.666666666667
 5:       44 of      120 = 1 in 2.727272727273
 6:      265 of      720 = 1 in 2.716981132075
 7:     1854 of     5040 = 1 in 2.718446601942
 8:    14833 of    40320 = 1 in 2.718263331760
 9:   133496 of   362880 = 1 in 2.718283693893
10:  1334961 of  3628800 = 1 in 2.718281657666

In other words, there’s about a 63% chance that at least one person will pick their own name and have to redraw. (There’s a 1/n chance that it’ll be the last person, which really screws things up.)

One way to avoid this if we end up doing it programmatically – other than re-shuffling until it works – is to shuffle the list of names, then assign everyone to buy a gift for the person after them in the (cyclic) list. This guarantees nobody getting their own name (for n > 1), and also has the property that there are no disjoint sets of people – everyone is in one cycle, rather than, say, two people buying for each other, or some number of larger cycles.

That seems more festive somehow. Also, it’s an actual advantage of doing it the geek way, since I can’t think of a way of doing it manually; which means I might actually be able to convince everyone that it’s a good idea.

…

Okay, here’s how you’d do to do it manually. Shuffle some playing cards, one for each person. Everyone takes a card, remembers it (without showing anyone), and writes their name on the back. Take the cards back, shuffle them again, and lay them out in a circle, face up. Everyone goes out of the room. One at a time, each person comes into the room (with nobody else watching), finds their own card, picks up the card clockwise from it and reads the name on the back.

Of course, my way prevents cheating.

Unix, stop messing with my head.

davemc@slarti:~$ which [
/usr/bin/[


Stop it. Seriously.

Okay, so [ is a command. A program. An executable. Not some syntactic massage oil applied by the shell's if and while and such (although the man page hints that in some shells it may well be).

And it has most of the same behaviour as test... that, at least, makes sense. Except that [ expects a ] as its final argument, while test doesn’t.

Huh. Cool.

I just needed to share that, a couple of hours ago, I finally worked out why SSH was slow to connect inside my home network. This has been nagging me for… well, years, probably. It’s one of those problems that I didn’t run into too often, and it only caused about five seconds of inconvenience each time, so it never really passed the threshold of dealing with it. Except today, for some reason.

It turns out that my server (running Ubuntu 9.10) was doing a reverse DNS lookup every time, presumably out of some effort to log the domain name of the machine trying to connect to it. The forum discussion that pointed in this direction is here; below is an outline of what I did to fix it and/or should do to fix it more elegantly, in case anyone’s interested.

Short-term solution: edit /etc/ssh/sshd_config on the server and add the line:

UseDNS no

…so that it doesn’t bother with the lookup. Then restart the SSH daemon:

sudo /etc/init.d/ssh restart

Medium-term solution: add /etc/hosts entries on the server for each computer in the house. Also, get the router to assign them static IPs. (I should probably do this anyway; I’ve just been lazy about it.)

Long-term solution: find out whether my router can work as a DNS server, or, failing that, run one on the Ubuntu box.

…is the sound my head made when reading this post about lazy error handling in Java. You see, functional programming and Java are completely disjoint sets of neurons in my head. Seeing Java code formatted like Lisp and doing lazy evaluation… requires some rerouting.

And when the post finished with:

But there’s more to come, as Thrower has higher aspirations still. It’s not just a functor. It’s a monad.

Okay, look, I followed a link into the middle of this. I really should start somewhere earlier. I wonder if there’s a Lambda Calculus for Dummies?

Or The Complete Idiot’s Guide to Forcing Programming Methodologies into Languages that Go Out of their Way Not to Support Them?

Previous version: 10 hours.

With the latest improvement: 33 seconds.

The Java sudoku solver is coming along nicely. There are still a few obvious things missing; in particular there’s a simple strategy that should speed up solving quite a bit. (Which I won’t try to explain here.)

After that’s done, there’s a plan in the back of my mind to make it multi-threaded, or possibly even distributed. I’m not sure about the best place to split it up yet… For solving a puzzle that’s known to have one solution, or towards the end of generating a puzzle where only a few of the branches are valid, splitting up the brute force tasks should be fairly useful; but for choosing a value for the first cell of an empty puzzle, every branch has a valid solution, so having multiple threads exploring all of them is pointless. The most profitable time to split up the task would be early enough that the available branches are deep, and will take a while for each of the threads to explore; but late enough that only one of them is expected to be valid.

The interesting question is whether it’s possible to recognise that point.

Anyway, here’s a result from the current version. The 4×4 (er, 16×16) puzzle below took just over ten hours to generate.