Ben's posterous

Someone's autoresponder left a blog comment here:

https://github.com/twitter/twi...
https://github.com/twitter/twi...

Now, how do they make sure the libraries work properly across languages? By conformance testing. The test data is in a separate repo with only a README and some yaml data files. The conformance repo has its own branches and tags so a new spec can be released and implementations can catch up independently.

https://github.com/twitter/twi...

This makes it easier to separate content from presentation by making it so API providers can provide raw content and programmers can have both raw content and presentable content. They get the raw content by downloading it and get the presentable content by using the library. It makes it more secure because the developer using the API only has to trust an open source library to provide safe HTML, not the API itself. Finally, the "tests" feel like a RESTful API in that they're just data and not code or even instructions.

What it does:

• Provides a Ruby API for indexing and querying search terms for AutoComplete widgets.
• Provides a rack app (implemented with Sinatra) for querying

How it works:

• There are two redis stores maintained by Soulmate: one for building the index of search terms and one for caching queries.
• Soulmate also keeps a reference to a third redis store, which contains the data being indexed. The id stored in the index is used by the server to output the data. The client can then use the data to present a nice representation of each result within the AutoComplete widget.

More info:

• github: https://github.com/seatgeek/soulmate/
• blog post: http://seatgeek.com/blog/dev/announcing-soulmate-a-redis-backed-service-for-fast-autocompleting

Why would I want to use old twitter?!! Maybe because the new twitter has glitches, like the glitch in the layout for the "Switch to Old Twitter" link? :p

Higher order programming FTW.

http://github.com/documentcloud

Sent from my iPhone (used the Rage Faces app in the App Store to add the image to this email)

I'm a terminology buff. I think that there are not nearly enough words for features of software applications. This is evidenced by programmers saying to each other, "it's like a wiki", and people hearing CouchDB has revisions and assuming it has versioning like wikis do. So I'd like to introduce a couple of terms I recently became familiar with:

• Outliners back in the 80s had a hoist command, that changes the root node to an internal node.
• Wikipedia has anchors and a TOC generated for its headings, so a section can be linked to. Some call this Deep Linking.

I experimented with these things a bit. Here's what I did:

• I took data from three wikipedia articles to make an outline of MSAs within regions and states. I then showed the Florida node as if it had been hoisted.
• I was going to do some HTML processing to show how a github page could have links for headers like Wikipedia does, in its Markdown pages. I saw that the Python markdown library has a TOC feature, and used that instead.

These examples are in my hdl repo on github. The combining of the three Wikipedia articles was a bit of work, with my naive approach.

I'm very interested in outlining and organization of text, and have built a tiny, incomplete wiki and a tiny, incomplete outliner. I've also been playing with CouchOne pages and Cloudant's JSON editor. If these things pique your curiosity, I'd love to chat with you.

To learn about building CouchApps I recommend checking these out:

• evently, a client-side JavaScript framework that puts JSON containing javascript functions, selectors, markdown, and more into motion. Very slick, but needs more people working on it.
• CouchOne pages, a wiki engine written as a CouchApp
• couchapp, the python app builder and uploader
• node.couchapp.js, an alternative to couchapp that reduces the number of files needed for a couchapp. Unfortunately the script is also couchapp which makes it not-so-convenient to install alongside couchapp. (I renamed it ncouchapp and rebuilt it.)
• the default CouchApp, which is pretty small except for the vendor/ directory and has a long-polling status example. (Like twitter.) Like CouchOne pages, it uses evently heavily.
• the app inside backbone-couchdb

Here are some experiments I'd like to try, or to see someone else take a crack at:

• A python service that finds couchdb pages with a "src" but not a "highlighted" property, that runs pygments on "src" and stuffs it back into "highlighted". It could use the _changes feed, or a webhook could call into google app engine. Lots of possibilities. :)
• Build evently in evently. Evently widgets are JSON containing JavaScript, while evently itself is a JavaScript file. This might require additional evently functionality and help take it to the next stage. :)
• Evently plugins, including a compatibility layer that can be taken out. This way, bits of evently could be used in CouchDB show and list functions without much code.
• Testing for couchapps.
• Creating two non-design documents, one for the couchapp and one for vendor files, and combining them into a design document. This would make it easier to share couchapp source.
• Pretty printing of couchapp source, with syntax highlighting.
• A web-based development environment for couchapps, like Heroku Garden.