Adventures in blogging 📝


I like the idea of shared learning and working together as a team, and in a way that’s independent of employment.

The desire for independence takes a couple forms:

  1. Minimizing loss of work due to employment boundaries. For example, learning documented on an internal blog may be lost when changing roles.
  2. Maximizing opportunities that would otherwise be constrained by company goals. For example, exploring professional growth areas that may never be a company priority.

Prakhar pointed me at Nathan Marz’s post on blogging, which provides excellent motivation specific to blogging.

Megha shared her experience at Write/Speak/Code, which recommends professional writing as an essential aspect of career development. I like Write/Speak/Code’s recommendation to seek feedback from trusted sources. Inline comments and explicit comment permission, like in Google Docs, would be ideal.

(Write/Speak/Code also brought Open Source Misfeasance to my awareness 👍 esp the slide “open source is like being an adult – it seems magical until you realize nobody knows what the hell they’re doing.” 🙂

I’m inspired by the meta-knowledge community on Github.

A New Yorker article on Jonathan Ledgard mentions he “carried two notebooks—red for his reporting notes, blue for thoughts and observations to use in fiction…”

I’ve heard Netflix has a strong culture of writing ideas down and seeking feedback. For example: “The bigger a decision, the more extensive the dissent/assent gathering should be, usually in an open shared document.”

Current approach

A simple note app (currently Google Keep) to capture and access thoughts with minimal fuss.

WordPress for blog hosting. It feels relatively old-school, but it’s stable, feature-rich and has a large community. Signal v Noise, Joel Spolsky and Bill Gates use it, so I’m in good company. A few features I appreciate in particular:

  • Full-text search, which is especially useful for finding and updating posts
  • Navigation by tag and category
  • A convenient native app
  • Easy navigation from viewing to editing
  • Basic stats and “likes” aren’t the reason I’m writing, but are reassuring

Regarding categories vs tags, the former is like a sub-blog, eg differentiating code tutorials from movie reviews, while the latter is more specific and plugs into WordPress’ topic subscriptions, facilitating discovery. (Twitter’s accounts vs hashtags is a cleaner version of this distinction.) Tag clouds and naive sorting can be noisy, so curate a list of featured tags using a menu.

Facilitate timely responses to comments by disabling those that are more than X days old.

Use Latex for math equations.

Completely separate professional from personal content, to facilitate content usage at work.

Alternatives explored

  • Medium is clean and modern, but the monetization strategy of charging readers seems relatively high-friction, and it doesn’t have multi-account support
  • is clean, and has a sustainable business model and an interesting tie-in to content federation, but it’s missing comments, search, etc
  • Github Pages is simple, but relatively inconvenient for frequent content management
  • Forestry CMS to manage Github Pages is an improvement, but I still want for search, comments, etc
  • Siteleaf is good, but doesn’t provide preview in free mode, and renames files according to date front-matter (after import)
  • I tried in the past, but saving content was flaky
  • jekyll-admin seems interesting if/when it’s supported by Github Pages

Notes from Kyle Neath’s presentation at Twitter on 5/31

  • Slides
  • hashbang urls
    • are a kludgy workaround for lack of history api. Since history api is coming, they have no future. Since urls are forever, especially w/ tweets being stored in the lib of congress, use of hashbangs results in permanent support for a temporary condition.
    • break pre-existing url fragment behavior
    • result in confusing routing logic
  • “responsive web design” is adapting to client and seeming responsive to user input
    • page load isn’t just a benchmark; a page is only “loaded” when the user can scroll, read text, and click links
  • well-designed urls provide a command-line-like interface for web apps
  • all web assets should have a url, i.e., navigation should not allow access to a resource that cannot then be accessed directly via a url
  • native elements should behave as the user expects
    • do not modify common key combos, e.g., shift + click
    • take advantage of the back button, tabs, links, etc
  • responsiveness is as much about performance as perception
    • wait ~500ms before showing loader image; showing loaders immediately can actually make the page seem slower
  • ssl
    • is required now that there are common, easy ways to sniff credentials
    • a new ssl handshake is very slow, and required for each domain
    • use http keep-alive to reuse ssl connections
    • multiple parallel requests to a new domain will each have to perform a handshake; instead, complete one fast request, and then reuse the connection for subsequent parallel requests
    • github optimized its backend to 40ms latency before realizing that the ssl handshake takes 500ms
      • a case of perception > performance
      • favor science over theory, i.e., test time-to-usable in multiple regions instead of just running perf tests on components
    • templates
    • use something simple, e.g., mustache
    • avoid rendering on client and server; pick one
    • kneath prefers server-side
    • for server-side rendering, passing html back as one value in a json object allows for passing data back in other keys
  • html 5 history api
  • allows for much richer state management. See github’s new issues dashboard

steps for merging changes from a remote clone of a git repo

I’m a fan of github, but I don’t know how to apply changes made to a clone of my repo, usually announced via a pull request. The goal of this post, then, is to define these steps. Note: the steps below pulled in the changes as desired, but also auto-committed them despite the —no-commit flag, so these steps need refinement.


  • a git repo named origin
  • committer has issued a pull request. For this example, I’ll use a committer named FooBaz


  1. add commiter’s repo as a remote
    • copy clone url for pull requester’s repo, eg git://
    • define remote repo: git remote add FooBaz git://
    • view list of remotes as sanity check: git remote show
  2. pull in FooBaz’s changes:
    • run: git pull --no-commit FooBaz master
    • note: this actually committed the changes for me 😐
  3. push changes to origin repo: git push origin master