Ups and downs
Posted on Thu 30 January 2014 in misc
Tuesday was not the greatest day, but at least each setback resulted in a triumph...
First, the periodical proposal for schema.org--that I have poured a good couple of months of effort into--took a step closer to reality when Dan Brickley announced on the public-vocabs list that he had created a test build that incorporated the RDFS that I had written up. Excitement rapidly turned to horror, though, as I realized that I had made a classic copy/paste error, in which I had changed the displayed name of the domainIncludes value but had not changed the actual URI... Long story short, the test build looked nothing like what the schemabibex group had agreed on, and I was terribly embarrassed.
Luckily, after I fixed the RDFS, Dan was able to put together a revised test build later that day that actually reflected our intentions. So that can continue moving forward...
Second, our Evergreen instance started acting up rather badly. All of the connections to the database server were being gobbled up, and we were scrambling to figure out why. While I'm on sabbatical I'm not really supposed to be involved in the day-to-day operations, but when a core service stops running it's okay for research to wait for a little bit... Eventually I tracked down a fix for a potential denial of service problem ( Search result rendering can crush the system) that hadn't been merged into our production system (the fix came out after the start of my sabbatical), and shortly after I put that into production we were back up and running.
Third, after the Evergreen problem was resolved, Bill Dueber pinged me innocently on IRC. He had run into a problem with File_MARC; when serializing MARC as MARC-in-JSON format, fields with a subfield $0 were getting trashed. Data corrupting bugs are one of the most serious classes of bugs for any package maintainer, so I jumped on this problem too... After a little bit of analysis, I figured out that PHP's type coercion for integer-like keys when creating arrays and its json_encode() implementation were combining to ruin the MARC-in-JSON serialization in this one particular case. Faced with rewriting the entire serialization logic, I did what any (in)sane programmer would and ended up running a regex against the result of json_encode() to turn the array-ified subfield $0 back into a key/value pair. File_MARC 1.1.1 is now available at your nearest PEAR mirror...