"Eloquent JavaScript: A Modern Introduction to Programming" by Marijn Haverbeke

"Learning JavaScript: JavaScript Essentials for Modern Application Development" by Ethan Brown

"Speaking JavaScript: An In-Depth Guide for Programmers" by Dr. Axel Rauschmayer

"Learning JavaScript Data Structures and Algorithms" by Loiane Groner

"You Don't Know JS" (series) by Kyle Simpson

"Programming JavaScript Applications: Robust Web Architecure With Node, HTML5 and Modern JS Libraries" by Eric Elliott

I found this picture of my 1976 Gibson ES-175 in my 2016 photo folder. I now remember taking it to show my new guitar-playing friend Dave Green what the guitar's pickguard looks like so he could compare it to his Japanese-made ES-175 copy.

Here you see much of the guitar's body. What pegs it as a 1970s Gibson archtop electric? It has chrome pickup covers and a chrome tailpiece (as opposed to nickel, which tends to age, albeit gracefully) and "witch hat" volume and tone knobs. The nickel covers -- made famous on the rare and pricey PAF (Patent Applied For) humbuckers -- tend to age, albeit gracefully. I believe Gibson introduced the "witch hat" knobs in the late 1960s. Earlier Gibson electrics came with "top hat" or speed knobs.

You can't see it here, but the neck is made of three pieces of maple (as opposed to a single piece of mahogany on earlier models) and includes the thickened "volute" near the nut, meant to strengthen the neck at the point where many Gibson's suffer from catastrophic breaks.

All three of those things contribute to neck strength: maple instead of mahogany, laminated instead of one piece, volute instead of no volute. The volute was unpopular and eventually discontinued. It doesn't bother me. I kind of like the "feel" of knowing I'm at the end of the neck.

The bridge on this guitar, for this year of production (1976) is a bit of an anomaly. It's a compensated rosewood bridge, the kind that Gibson had been using for decades on its archtop guitars, both acoustic and electric. I call it an anomaly because one of the changes Gibson made on the 1976 ES-175 is switching from the traditional wooden bridge to a metal Tune-O-Matic like you would find on a Les Paul or ES-335.

Read the rest of this post

So you have the bigger Melita-style No. 4 paper coffee filters for 8- to 12-cup coffee makers and you need a smaller No. 2 filter for your single-cup pour-over cone filter (or 2-cup coffee maker)?

It happens more often than you think. I'm always running out of No. 2's and always have plenty of No. 4's. Mostly because Costco sells a huge pack of the larger filters.

You can just stuff the bigger paper filter into the smaller pour-over cone filter (I have both plastic and ceramic versions).

Or you can trim about an inch off of the larger filter. Use a scissors and follow the curve. It'll save you a trip to wherever coffee filters are sold and help you plow through your endless supply of No. 4's.

I am linking to these Eric Elliott articles on JavaScript programming because I don't want to forget about them.

Eric Elliott: 12 Books Every JavaScript Developer Should Read

Eric Elliott: The Software Developer’s Library: A Treasure Trove of Books for People Who Love Code

Eric Elliott: Learn to Code: 13 Tips that Could Save You Years of Effort

Eric Elliott: Native Apps are Doomed

Eric Elliott: Why Native Apps Really are Doomed: Native Apps are Doomed pt 2

I've never been a big fan of Chicago, the band. I've heard this song before and had no idea it was by them. But I really like "Does Anybody Really Know What Time It Is?"

Ode runs Perl via CGI on the server. That doesn't mean it is slow.

Turns out it is very, very fast.

I can render an index page with previews of every post (all 900+) in about 20 seconds.

My last text processing project started in Bash, which which I'm more familiar, and then took a turn toward Ruby before returning to Bash when deadlines got tight.

Now I'm thinking about the next election-results script, which won't be using XML from the state of California but instead the space-delimited ASCII from Los Angeles County. Another developer handled that task in November, but I want to take a crack at it for March 2017.

My goal is a "universal" script that can work on any results file that the county provides without requiring a lot of hacking for individual races in any given election.

In other words, I want to write once, run many times.

I could do it in Bash. Or Ruby. But I might want to try JavaScript and run it with Node on the server (or, if the election is "small" enough, client-side in the browser).

LA County data is not standard. It's not XML or JSON (though the county DOES use JSON in its own results, it does not share that data with the media).

Instead, the county uses what appears to be a home-grown data format that is arcane yet well-documented.

Each line begins with an alphanumeric code, and data fields are placed on those lines at predetermined character lengths and predetermined positions.

So a script would have to create substrings of the data from each line. I'm thinking that I'll use the script to either create XML that I would then convert, or to skip that step and create JSON directly from the county's data.

Doing it in JavaScript would be an opportunity to learn more about the language (just like it would be for Ruby if I used that language; and the jury is most definitely out).

What muddies the water considerably is the fact that my company is also following elections in San Bernardino, Riverside and Orange counties. I know that San Bernardino doesn't really provide data at all. I generally scrape their web page on Election Night. I don't know what Riverside and Orange do.

So I'm going to focus on LA County for now. Another developer wrote the front-end code for the election-results display, and all I have to do is provide the JSON. I wouldn't be opposed to writing the whole app, but for now a "smaller" bite is a more realistic one.

I'm exploring my options for coverting XML to JSON, even though I don't have any new XML coming my way.

I previously used a Ruby library and considered a different JavaScript library to do the conversion.

I just tested a different JavaScript library, enkidootech's xml2json, and that worked very well right out of the box.

Well, almost.

I tried to install it globally via npm, but my resulting JavaScript file didn't seem to be able to find it.

Then I used npm to install the package locally, and that worked. I have a node_modules directory in the same directory as my script, and it outputs JSON as expected.

I just took what enidootech offers as an example and put that in my file (which I named xml_to_json.js). I ran it with node and it worked:

// From https://github.com/enkidootech/xml2json

var parser = require('xml2json-light');
var xml = '<person><name>John Doe</name></person>';
var json = parser.xml2json(xml); 

console.log(json);

You get this:

$ node xml_to_json.js 
{ person: { name: 'John Doe' } }

Nice!

If my next script won't involve XML, what will it do? That's a question for the next entry.

CodePen: JavaScript Basics 2: Arrays and Loops http://codepen.io/jakealbaugh/post/js-basics-2-arrays-and-loops

CodePen: JavaScript Basics 1: Functions and Variables http://codepen.io/jakealbaugh/post/js-basics-1-functions-and-variables