Tracking the Books

I need to find a replacement for Goodreads, because I hate using it.

Its UI is terrible. It looks like something I would’ve designed back in high school, and I’m a color-blind back-end developer that wouldn’t know a good font choice if there was only one to pick.

The performance of the site is terrible. Searching for books takes too long, and (and!) if you type too much of the book’s title into the search bar, the one you want will go whizzing by, replaced by books that are nothing like the one you’re looking for.

Even when you finally do locate the exact book you want to add to one of your shelves, if you later want to, say, find a list of all the books you’ve read this past year (as I tried to do back in January), you’ll find that Goodreads does not fill in the date every time you mark a book as read. I think somewhere between a quarter and a third of all the books on my “read” shelf have no dates attached to them, so they end up in a jumble at the bottom of the list, no rhyme or reason to them.

But what choice do I have? I have a few hundred books in hard copy in my house. Another two hundred or so scattered across various ebook formats: Kindle (follies of youth), Nook (ditto), Kobo (simply the best), and iBooks (don’t judge me). All of which I need to keep track of, if only to keep myself from buying a book I already own. Goodreads, for all its flaws, at least lets me do that.

I suppose as a developer I’m supposed to build my own solution. And I’ve thought about it; I could write an importer to take the xml junk Goodreads’ api barfs out, clean it up, and then shove it into a text search engine (probably Elasticsearch) for easy retrieval later.

But that’s a fair-sized project, and if I can, I’d rather take advantage of someone else’s work (and pay them for it, gladly).

So: Are there other, better, apps out there for tracking a personal library? If you use one, which one, and why?

If Doorknobs Were Software

If we designed doorknobs the way we design software, each one would come with a user manual.

They wouldn’t be guaranteed to work. You could spend hundreds of dollars on a new doorknob, only to find the handle doesn’t turn, and the manufacturer doesn’t offer a warranty.

Your doorknob would have options for direction of turn, speed of opening, and click sound, but not shape or color.

Most doorknobs would be sold without locks. You could get a knob with a lock, but it would be $10,000.

Each door in your house would need a different doorknob, depending on what year it was built. Doors from 1994 would need completely different knobs than 1993 doors. Sometimes you’d be able to put a 1995 knob in a 1993 door, but not always.

Modern doorknobs — made only for modern doors — would understand some voice commands, like “What time is it?” and “When did you last close?” But only from one person in the house, and the commands for opening and shutting would be different depending on which knob you bought and which door you installed it in. Most of these voice doorknobs wouldn’t have handles, at all.

Some people would lay awake at night, wondering if our doorknobs were getting too smart, and would one day rise up and kill everyone.

Seven More Languages in Seven Weeks: Elm

Between the move and the election and the holidays, took me a long time to finish this chapter.

But I’m glad I did, because Elm is — dare I say — fun?

The error messages are fantastic. The syntax feels like Haskell without being as obtuse.  Even the package management system just feels nice.

A sign of how much I liked working in Elm: the examples for Day Two and Three of the book were written for Elm 0.14, using a concept called signals. Unfortunately, signals were completely removed in Elm 0.17 (!). So to get the book examples working in Elm 0.18, I had to basically rebuild them. Which meant spending a lot of time with the (admittedly great) Elm tutorial and trial-and-erroring things until they worked again.

None of which I minded because, well, Elm is a great language to work in.

Here’s the results of my efforts:

And here’s what I learned:

Day One

  • haskell-inspired
  • elm-installer: damn, that was easy
  • it’s got a repl!
  • emacs mode also
  • types come back with all the values (expression results)
  • holy sh*t: “Maybe you forgot some parentheses? Or a comma?”
  • omg: “Hint: All elements should be the same type of value so that we can iterate through the list without running into unexpected values.”
  • type inferred: don’t have to explicitly declare the type of every variable
  • polymorphism via type classes
  • single-assignment, but the repl is a little looser
  • pipe syntax for if statement in book is gone in elm 0.17
  • case statement allows pattern matching
  • case statement needs the newlines, even in the repl (use `\`)
  • can build own complex data types (but not type classes)
  • case also needs indentation to work (especially if using result for assignment in the repl)
  • records: abstract types for people without beards
  • changing records: use `=` instead of `<-`: { blackQueen | color = White }
  • records look like they’re immutable now, when they weren’t before? code altering them in day one doesn’t work
  • parens around function calls are optional
  • infers types of function parameters
  • both left and right (!) function composition <| and |>
  • got map and filter based off the List type (?)
  • no special syntax for defining a function versus a regular variable, just set a name equal to the function body (with the function args before the equal sign)
  • head::tail pattern matching in function definition no longer works; elm is now stricter about requiring you to define all the possible inputs, including the empty list
  • elm is a curried language (!)
  • no reduce: foldr or foldl
  • have to paren the infix functions to use in foldr: List.foldr (*) 1 list
  • hard exercise seems to depend on elm being looser than it is; afaict, it won’t let you pass in a list of records with differing fields (type volation), nor will it let you try to access a field that isn’t there (another type violation)

Day Two

  • section is built around signals, which were removed in Elm 0.17 (!)
  • elm has actually deliberately moved away from FRP as a paradigm
  • looks like will need to completely rewrite the sample code for each one as we go…thankfully, there’s good examples in the elm docs (whew!)
  • [check gists for rewritten code]
  • module elm-lang/keyboard isn’t imported in the elm online editor by default anymore

Day Three

  • can fix the errors from loading Collage and Element into main by using toHtml method of the Collage object
  • elm-reactor will give you a hot-updated project listening on port 8000 (so, refresh web page of localhost:8000 and get updated view of what your project looks like)
  • error messages are very descriptive, can work through upgrading a project just by following along (and refreshing alot)
  • critical to getting game working: (multiple subscriptions)

Notes from Strange Loop 2015: Day Two


  • lisp
  • own vm
  • compiled using RPython tool chain
  • RPython – reduced python
    • used in PyPy project
    • has own tracing JIT
  • runs on os x, linux, ARM (!)
  • very similar to clojure, but deviates from it where he wanted to for performance reasons
  • has continuations, called stacklets
  • has an open-ended object system; deftype, etc
  • also wanted good foreign function interface (FFI) for calling C functions
  • wants to be able to do :import Math.h :refer cosine
  • ended up writing template that can be called recursively to define everything you want to import
  • writes C file using template that has everything you need and then compiles it and then uses return values with the type info, etc
  • you can actually call python from pixie, as well (if you want)
  • not ready for production yet, but a fun project and PRs welcome

History of Programming Languages for 2 Voices

  • David Nolen and Michael Bernstein
  • a programming language “mixtape”

Big Bang: The World, The Universe, and The Network in the Programming Language

  • Matthias Felleisen
  • worst thought you can have: your kids are in middle school
  • word problems in math are not interesting, they’re boring
  • can use image placement and substitution to create animations out of word problems
  • mistake to teach children programming per se. they should use programming to help their math, and math to help their programming. but no programming on its own
  • longitudinal study: understanding a function, even if you don’t do any other programming ever, means a higher income as an adult
  • can design curriculum taking kids from middle school (programming + math) to high school (scheme), college (design programs), to graduate work (folding network into the language)

eReader for Android!

They just released a version of the eReader software (formerly Palm eReader, then just eReader, now the Barnes and Noble eReader) for the Android platform.

It’s a little bit buggy: you need to wait for an entire book’s table of contents to load before reading/scrolling, else the book will get stuck partway through. Other than that, it works great on my G1. Nice to see a commercial ereader on a Linux platform. (Yes, the books still have DRM, but the format’s got some longevity behind it, and is supported on enough devices that I’m not worried about getting locked into one platform).