I needed to check that the index process that populates the Solr index succeeded and didn’t die during the night, leaving an empty index.

To make things more complicated, the versions of Solr and nagios in use are probably not the latest.

The check_solr -o numdocs command doesn’t work with our Solr configuration. But the internet tells me that the Solr query http://localhost:8983/solr/select/?debug=q‌uery&q=*:* includes the size of the result set. Testing it, I found this to be true:

<response>
   <lst name="responseHeader">
      <int name="status">0</int>
      <int name="QTime">0
      <lst name="params">
         <str name="q">*:*</str>
         <str name="debug">q‌uery</str>
      </lst>
   </lst>
   <result name="response" numFound="9832" start="0">
      <doc>
...

I want to use nagios to check that that numFound is never zero (or too small). I thought I’d just be able to use a nagios regex:

check_http -H localhost -p 8983 -u "/solr/select/?debug=query&q=*:*" -lr 'numFound=\"\d{2+}"'

It didn’t work. To make a long story short, there’s regex and then there’s regex. The kind that works for nagios is:

check_http -H localhost -p 8983 -u "/solr/select/?debug=query&q=*:*" -lr 'numFound=\"[1-9][0-9][0-9]'

This guarantees at least a hundred docs are in the index.

We’ve already established that PHP compares things weirdly.

It shouldn’t surprise us that JavaScript does too.

Consider the following:

> var k=['hello'];
undefined
> (k=='hello'?'Equals':'Nope');
Equals


Now, purists will point out that that’s an “equals” operator not an “identity” operator, but I mean seriously? We’re just going to pretend that


> ['hello']=='hello'
true


I think I’ll just go and rewrite all my client side code in C now.

The Goodyear Blimp was passing overhead. It’s noisy! Since it was pretty low, I tried to take an iPhone picture. In the shot, I got a serendipitous cameo by one of the local Anna’s Hummingbirds.

Click to see bigger.

This is a known .. uh … situation, but it bit me today.

So, consider the following:
$ php --version
PHP 5.4.16 (cli) (built: Jun 23 2015 21:17:27)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
$ php -a
Interactive shell
php > $v1 = '479014103257633139480';
php > $v2 = '479014103257633139481';
php > echo ($v1==$v2?'Equal':'Not Equal');
Not Equal


Seems sane, yes? Reasonable. Kind of what you expect.

But then, consider this:

$ php --version
PHP 5.3.3 (cli) (built: Feb 9 2016 10:36:17)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
$ php -a
Interactive shell
php > $v1 = '479014103257633139480';
php > $v2 = '479014103257633139481';
php > echo ($v1==$v2?'Equal':'Not Equal');
Equal

Yeah. Let that sink in for a moment.

Some versions of PHP (before 5.4.mumble) will preëmptively convert strings to numbers before comparing them (if they contain only digits). But if the number is large enough, you may lose the precision to compare them correctly.

Wow. I mean, just … well… I dunno.

For what it’s worth, strcmp will do the right thing regardless of PHP version. But seriously. I mean. Why do I use this turdburger of a language?

Back in August, I held a fantasy dinner party. At the time, I intended to do that monthly. How weak are intentions 🙁

Well, here’s another one. This month, as a theme, it will be all people known by their nicknames.

If you were throwing a dinner party, and had a table for eight, a fantastic chef, an unlimited travel budget, and were able to invite seven guests¹, who would you invite?

While picking a good table is an impossible challenge, here’s what my second table would look like:

Who is coming to your dinner party?

¹ I’m making the assumption that the invitation would be so compelling that the guests would all attend. And I’m further limiting this thought experiment to living people.