Daniel Martin

In my previous post, I said I was working on a version of my old killfile script as a chrome extension.

Well, that's now happened! And I have it as both a firefox and a chrome extension. (Same source, mostly.) I still need to go through and clean out the list of supported sites, but note that in addition to the sites it supports directly, it also supports any site that uses disqus through an iframe. (Like rawstory.com, wired.com, and many, many others; sadly, Shakesville uses disqus in a different manner that I can't handle yet)

1. Killfile for chrome


2. Killfile for firefox

The chrome extension can also be found by going to the chrome webstore and searching for it; the firefox addon can't be found by going to the main page and searching because firefox has a review process for addons that's really slow. It might be reviewed by Christmas.

On chrome, your killfile list is shared across all your devices if you sign into chrome and do the chrome sync thing. On firefox, it's strictly local.

The full source is on github.

So here's a bit of a geeky post, but not so terribly geeky that I'm hiding the bulk behind a cut link.

"true" and "false" are simple concepts, right? Different programming languages seem to have hugely different ideas of what they are:

In C, 0 is false, any other integer is true, and the coercion rules make a null pointer false, and any other pointer true. Anything else is a compile error.

C++ follows (inherits?) the C rule, and adds true and false as things that are true and false.

In shell, 0 is a true exit value; any other exit value is false. Inside [ ], empty strings are false and other strings (such as "0" or "1") are true.

In Python, 0, 0.0, -0.0, False, None, the empty string, empty tuples, lists, and dicts are all false. Anything else (such as the string '0') is true. (A note on 0.0 vs -0.0: they're both == according to python, and both false, but print differently. One can be turned into the other by multiplying by -1)

In Perl, 0, the empty string, and undef are false, and since evaluation as a boolean imposes scalar context, an empty array or hash variable is also false. Anything else (including arrayref or hashref values to empty structures) is true. Note that because perl helpfully autoconverts like a $SOME_NOUN_HERE, the string "0" and 0.0 are to perl identical to 0, and therefore false. (hence the Perl idiom "0 but true") A full discussion of the quirks of perl around various representations of zero could probably fill a small book, but I'll note that other consequences are that the expression -0 is true, but -0.0 is false.

In Ruby, false and nil are false, anything else (including 0, the empty string, and an empty Array or Hash) is true.

In Javascript, 0, null, undefined, the empty string, false and NaN are false. Anything else (such as an empty Array, or empty Object) is true.

In Java, (since the autoboxing introduced in Java 1.5) true and Boolean.TRUE are true, false and Boolean.FALSE are false, ((Boolean) null) is a runtime exception, and anything else is a compile error.

In Haskell, True is true, False is false, and anything else is a compile error.

Google Go behaves like Java 1.4 or Haskell - true is true, false is false and anything else is a compile error.

Scala appears to behave the same way - true is true and false is false. Anything else (including an instance of RichBoolean, or of java.lang.Boolean) is a compile error.

In Common Lisp, nil, aka the empty list, is false. Anything else - including 0, the empty string or empty vectors of other types - is true.

Yeah, yeah, haven't posted in ages, etc.

As those few of you who still have me on your friends' lists probably know, I work for Google.

As the rest of you may know, Google's a fantastic employer and many, many more people than we can hire want to work here. In fact, many more people with good resumes want in than would be practical to interview in person. Hence the phone screen, wherein a Google engineer calls you up and assesses whether you should be brought in for an interview.

I do about one phone screen/week, on average.

Sometimes my interviewees manage to seriously annoy me. As a public service, here's how to avoid doing that. Note that many interviewees who did not annoy me still didn't end up with in-person interviews, but that no one who did annoy me did. This is basically a guide for how to avoid totally bombing - if you want a guide for how to actually succeed at a Google interview, look elsewhere.

This applies only to people being interviewed for a technical position (i.e., Software Engineer or Site Reliability Engineer). Not knowing everything on this list does not make you a bad person, nor will I be pissed off at meeting you if you don't know everything on this list. It does mean, though, that you are not ready to phone screen at google for an SWE position.
( Cut for friends pages )

From the quiz solution summary on http://rubyquiz.com/quiz122.html: (ellipses in the original)

You have shown me the light and it tells me... Daniel Martin is crazy. I'll leave it to him to explain his own solution, as punishment for the time it took me to puzzle it out. I had to print that Array inside of the inject() call during each iteration to see how it built up the answer.

Update: I did in fact accept my punishment and post an explanation of my twisted implementation of the Luhn algorithm.

Update: Sorry; anonymous comments aren't shown on this entry any more. Three spam deletions is my limit.

And now for something totally geeky. Of interest only to those programmers whose programming interests encompass both java generics and functional languages that tend to represent lists as singly linked lists most of the time. This is just kind of wandering about, with no coherent theme or conclusion to the post.
( (Haskell-style lists in java, with generic type safeness) )

Update: figured out a better way to do append in the ? extends E model.

I wrote this in Notepad on the train, but hadn't had a chance to post it until now - it's been a bit of a hectic day:

So last night, for reasons that may be apparent if you read jmartin2's journal, I had several hours during which I could just wander around Marlton, and perhaps not too surprisingly I found myself walking around the big Barnes and Noble that's at the corner of Rts. 70 and 73.

And, as often happens, wandering around that big bookstore made me sad. I've been trying to express why, but big bookstores like a Borders or a Barnes and Noble have that effect on me. The same thing does not happen in little stores like the several used-and-antique bookstores we sometimes visit in Bordentown, even on those occasions when I don't find anything to buy.
( Looking at math books )

Then, having thoroughly depressed myself in the mathematics section, I wander a few shelves over to the computers section.
( "Computers" )

So we have some code that loads data from one place to another place, and I'm trying to figure out why when this code flags an error, it appears that the bad data is still getting loaded, and I discover this:

> grep -n haveError read.cpp
211:            int haveError = 0;
228:                    haveError = 1;

It's awfully hard for a variable that's never checked to affect program execution...

What I've been programming on like mad these past few days is SMML - St. Mary's Music Library. At least search now works, even if I don't have the log-in-so-you-can-comment bit working yet.

Background:
Jennifer's been cataloging the assorted sheet music that has accumulated in the chior room at our church on a scrounged computer (built mostly out of bits of machine I've cast off, plus a donated old vga monitor from work and a yard-sale dot matrix printer) using an old package called dbman and lynx.

Well, that has a few problems. First off, dbman isn't a very functional program to begin with; secondly, we need to advertize for them if we put it up somewhere so that other people are able to search with it.

So I'm a programmer, right? So it should be a simple matter to put something like this together. I mean, it's just throwing up a database based on DBD::CSV, and writing a few pages with Mason. These choices were made because dbman stores things in a file format that DBD::CSV can use, or at least I thought it did. It turns out that DBD::CSV is a bit picky about some things.  I chose Mason because I thought it would be easy to set it up in an environment where all I can set up is a cgi script; actually, that was true, modulo having to work around the fact that the webserver's chroot contained almost no perl modules.  Plus, if it becomes possible to move to a mod_perl setup, Mason will let me do that.

So two weekends and several long nights later, the searching that shouldn't take me "more than a few hours" is up and functional. (Lots of stupid stuff I ran into along the way - including an interesting bug that vanished when I looked at it with the debugger, because the condition I set on a breakpoint caused an integer comparison to happen. perl's string<->number equivalence can get whacky) Now I need to add everything necessary to let Jennifer make changes, and then I can work on allowing other people to add annotations (maybe; we're still not certain that there's any need for this feature).  The changes bit is interesting since I have to keep three copies of the database in sync - one on cush (my home machine), one on snowplow, and one on phoenix (the machine sitting in the chior room basement).  Fortunately only one person is going to be making any changes.

The search language parser is a neat hack, if I do say so myself. I should document it sometime as an example of leveraging perl's parser to do your work for you.

While taking a break I ran across some old pictures I had taken while in Baltimore, and my lj picture needed changing.