Text

· · to read

The emacs eshell is an interactive shell for entering commands written in elisp. I like it because it feels like a normal emacs buffer and I can easily move around and copy and paste, without switching to a copy mode. It loses many of the features of bash, but when I need them I can use bash, inside or outside of emacs.

I had a hard time figuring out how to set the path it uses when I type commands, though. I wound up finding a way that worked for me by reading the source of the which function and then the code of eshell-search-path, which the which function uses to find executables in the path.

The variable is eshell-path-env and it’s a colon-separated list of directories. I needed to add my nodebrew directory to it, and I did so by adding the following to ~/.emacs.d/init.el:

(setq eshell-path-env (concat "/Users/bat/.nodebrew/current/bin" ":" eshell-path-env))

I’m not sure that this is the best answer, but it took me a while to find and answer that worked so I thought I’d share it.

Text

· · to read

XML/HTML are centered around elements. An element is something that has an opening tag and a closing tag, or simply has a single self-closing tag (The slash before the closing angle bracket is required in XML and XHTML but not HTML). For example, this has six elements:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Hello, world.</title>
  </head>
  <body>
    <p>Hello, world.</p>
  </body>
</html>

In this example each tag name is only used once. The elements are (by order of first appearance) html, head, meta, title, body, p. The DOCTYPE definition is special and is not considered to be an HTML or XML element. The charset part of this document is an attribute.

What does element mean in JSON? Something a bit different. An XML element is a compound data type. A JSON element is part of a compound data type.

If you look at the white box on the right part of json.org detailing the grammar, you can see that it has names for items in JSON’s compound data types, objects and arrays. An item in an object is called a pair, and an item in an array is called an element.

It helps when building APIs for processing data formats to have names for things. The terminology for XML is used in XML tools, and has made them easier to understand. For instance, the jQuery API docs use the terms element and attribute heavily.

I think the JSON community should adopt the terms pair and element and use them more frequently, to enhance understanding of the data. It’s useful to talk about a pair rather than a key and a value, because when you add something to a JavaScript object that’s what your adding. You aren’t adding just a value. A JavaScript array can include multiple copies of the same value, so when you’re removing a single occurrence of a value, it makes more sense to say you’re removing an element than removing a value.

JSON has been popular for years now, in many vital technology communities, but it is still lacking in processing support compared to XML. I think clear terminology is one thing that XML has right, and indeed the JSON spec has clear terminology. What’s lacking is widespread use of the terminology.

Text

· · to read

Here’s a copy of the email I sent to the CouchDB users mailing list:

I made a couple of npm (node.js) modules for editing CouchDB design documents that involves fewer files than python CouchApp, but like python CouchApp supports two-way sync. The function source is left intact when converting between JavaScript source and JSON. The JavaScript source version just shows it in an embedded function expression, which makes it syntax highlightable.

http://benatkin.com/2012/09/04/js2json-and-json2js/
https://github.com/benatkin/js2json
https://github.com/benatkin/json2js

Here’s a quick example. If I stick this in books.js:

module.exports = {
  "views": {
    "author": {
      "map": function(doc) {
        if (doc.type == 'book')
          emit(doc.author, null);
      }
    },
    "title": {
      "map": function(doc) {
        if (doc.type == 'book')
          emit(doc.title, null);
      }
    }
  }
}

…and run this (after npm install json2js js2json):

var js2json = require('js2json');
var json2js = require('json2js');
var fs = require('fs');

var jsSource = fs.readFileSync('books.js', 'utf8');
var jsonValue = js2json.convert(jsSource);
fs.writeFileSync('books.json', JSON.stringify(jsonValue, null, 2) + "\n");
var jsSourceFromJson = json2js.convert(jsonValue);
fs.writeFileSync('books-from-json.js', jsSourceFromJson + "\n");

…I get the following in books.json:

{
  "views": {
    "author": {
      "map": "function(doc) {\n  if (doc.type == 'book')\n
emit(doc.author, null);\n}"
    },
    "title": {
      "map": "function(doc) {\n  if (doc.type == 'book')\n
emit(doc.title, null);\n}"
    }
  }
}

…and books-from-json.js is exactly the same as books.js.

I explain it more in my blog post (linked at the top of this message). I need to add a cli tool that syncs, a way to handle attachments, and a way to handle embedded multiline strings for it to be a full-featured design doc editor. I have much bigger plans for this, though: I want to break up CouchApps into a bunch of smaller documents! The source and tests for these two modules is programmed in the same style. I think storing functions in JSON makes CouchDB just a little bit like Smalltalk, with a much more familiar language.

Thanks for reading. Feedback welcome and appreciated.

Text

· · to read

I made a couple of small node.js modules to help me develop couchapps.

CouchApp is two things: a concept and a tool. The concept is an application that runs on CouchDB, using its API. The API has three basic components for presenting data (it has others for editing data but that isn’t covered in this post):

  • views: A view in CouchDB is a Map and optionally a Reduce function, which enables indexing JSON documents using the powerful MapReduce programming model.
  • lists: A list is a function that renders documents from a view, into an any format (commonly HTML).
  • shows: A show function renders a single document, into any format.

With these simple functions, a blog or a photo gallery can be made viewable. The URLs can get a bit awkward, but CouchDB provides a rewrites feature to solve it.

These functions go into a CouchDB design document. CouchDB is a JSON database, and a design document is a JSON document that contains functions as strings. A single design document, with attachments for CSS, which can be served directly to the web browser, can provide access to data without relying on client-side JavaScript (instead using server-side JavaScript).

The tool is a python command-line utility that maps a CouchDB design document to a directory structure. It can clone a design document directly from the database. It breaks it into a lot of little files, including a separate JavaScript file for each function.

This can be a lot of files, when there is one file for each function. Here is the CouchOne pages wiki CouchApp. It has a lot of views.

Mikeal Rogers had perhaps the first solution to this problem: node.couchapp.js. It runs on node.js and allows programmatic building of a design document, and puts functions in strings to prepare the JSON using Function.toString(). This loses the python CouchApp’s advantage of being able to go back and forth from file to CouchDB without losing anything.

I wanted something that could sync back and forth and is more like the original JSON than python’s CouchApp. To make it usable, I need functions shown across multiple lines with syntax highlighting. My hack was to convert the JavaScript to JSON. With CommonJS I can convert JSON to JavaScript easily, just by adding module.exports = to the front of the file. I can then replace the function strings with the direct value of the strings. To go from JavaScript to JSON I need to get the original function source. With JavaScript’s fn.toString(), where fn is a function, I get the source without the comments. I want the comments. It also isn’t indented properly. With Esprima I wrote code to extract the raw function source and fix up the indentation. Examples of this are in the READMEs of the two projects, json2js and js2json.

The projects below are still in early development and barely tested, but I’m putting them to use right now, by finally putting one of my fancy domain names to good use. ;) In the meantime, if this interests you, please check them out and give me feedback.

Repositoryjson2js
Ownerbenatkin
Repositoryjs2json
Ownerbenatkin
Text

· · to read

I read The Pleasure Trap earlier this year, and was amazed at what its authors have to say about the dangers of modern food. It’s very hard to avoid unhealthy food. I wanted to get to know the authors a bit better so I searched YouTube and found this excellent hour-long video about the Dietary Pleasure Trap. It’s worth a watch if you’d like to eat better, help someone you know to eat better, or just understand why so many people are overweight. The book goes into it much more deeply and in my opinion is well worth the time it takes to read.

Text
· · to read

Avoid describing your code as automatically doing something. If you need to do multiple things at once, separate it out into a convenience function or method. Finally, make it easy to call each step explicitly. Please don’t put the orchestration code, that calls code that interacts with the outside world, into a constructor. This makes the code less flexible and harder to test. Instead, use the constructor to set up the internal state.

Text

· · to read

Update: @twitinsin points out that it’s still useful in the console for quickly declaring multiple variables.

I developed the habit of always using var when I write JavaScript long ago. At some point I got in the habit of typing var even when I’m using a JavaScript console in node or in a browser. After examining the issues I’ve decided to break that habit.

I think I got in the habit of this because I came to appreciate explicit variable declaration, and decided to gladly pay the tax. The four extra characters, including the space, isn’t bad. But it doesn’t serve a useful purpose in short console sessions. Without var, it’s still valid JavaScript, that will run in node.js and in any browser. It won’t pass JSHint and JSLint, which is why it should always be added before delivering code.

If this gets me to be just a little quicker to fire up a REPL (a more generic term which includes the JavaScript console), it will be an improvement.

Text

· · to read

I have an Apple Bluetooth keyboard and touchpad for my MacBook Pro that I keep in my upstairs bedroom at home. I leave it on all the time. When I’m at home, my MBP automatically connects to it, and disables the touchpad on my MBP. This would be useful if I was only using a bluetooth TouchPad and was using the MBP keyboard, as I could use the MBP keyboard without worrying about accidentally touching the TouchPad on the wrist rest on my MBP. With my external keyboard the disabling of the MBP TouchPad isn’t all that useful, but I still like it, except for one minor issue.

The issue is when I come home and decide to use my MBP on the dining room table, or the couch downstairs. Bluetooth works across that distance. When I did this I had to go upstairs and either grab my bluetooth keyboard and touchpad or turn them off. I wasn’t able to turn off bluetooth on my computer because I can’t use my MBP’s TouchPad to click the Bluetooth icon in the OS X Menu Bar, when the bluetooth TouchPad is enabled and the MBP’s TouchPad is disabled.

I no longer have this problem, since I found a way I can disable the bluetooth with my keyboard. All I have to do is install blueutil, which I can do with homebrew.

brew install blueutil   # install it
blueutil power 0        # turn bluetooth off

Once I turn bluetooth off, my MBP’s TouchPad becomes enabled, and I can start using it!

Repositoryblueutil
Ownertoy
Text

· · to read

A while ago I got systematic about organizing the files on my computer. It started with a ~/github directory that mirrors the structure of GitHub itself. If I’ve cloned visionmedia’s commander.js, I know I can find it in ~/github/visionmedia/commander.js. This has helped make things easy to remember. Since then I’ve added an archive directory, a src directory (which contains most of my code), and a projects directory (which contains the code I’m currently working on. A few days ago I added an apps directory.

What does my ~/apps directory contain? It contains credentials and configuration for web apps, which I don’t want to store in my code repositories. For the fluxnote project I’m developing, it contains a script to set my environment variables to mirror what I require on Heroku:

export GITHUB_CLIENT_ID=7f2264d71eb1dfbc2611
export GITHUB_CLIENT_SECRET=copied_and_pasted_from_github
export SESSION_SECRET=a_long_hard_to_guess_session_secret
export GITHUB_USERNAME=benatkin
export COUCH_URL=https://therystillonleamoldescle:hahahahaha@bat.cloudant.com/fluxnote/

(Side note: Cloudant has clever auto-generated usernames. The username and GitHub Client ID are real; the secrets and password are not.)

If I run source ~/apps/fluxnote/config, the environment variables from the above script are loaded into my shell. Then I can run npm start to start my server. (After I add my Procfile I’ll also be able to run it with foreman start.)

I like it, because I have my credentials in one place, that I know not to give to anybody (and that would be hard to steal because I use full drive encryption).