Wednesday, October 24, 2012
Monday, October 22, 2012
Friday, October 19, 2012
Sunday, October 14, 2012
Deploying is a big part of the lives of most GitHub employees. We don't have a release manager and there are no set weekly deploys. Developers and designers are responsible for shipping new stuff themselves as soon as it's ready. This means that deploying needs to be as smooth and safe a process as possible.
The best system we've found so far to provide this flexibility is to have people deploy branches. Changes never get merged to master until they have been verified to work in production from a branch. This means that master is always stable; a safe point that we can roll back to if there's a problem.
Friday, October 12, 2012
Wednesday, October 10, 2012
Tumblr for iOS: Uses a JSON API and Mustache templates like a mobile site would, but does template evaluation on the native side, with the UIWebView just being used to render the resulting HTML. This makes the absence of a JIT less critical.
See also this SXSW panel.
Update on 12/7/2012: Tumblr appears to have changed to being purely native.
iPhone app that automatically keeps track of your commute and helps you detect patterns. Using geo-fencing, it could keep track of when you leave your designed home/work spots, and then do a continuous GPS track along the way. Once data is gathered, it could be visualized (e.g. by day of week, or by departure time), displayed on a map to show alternate route rates (e.g. Grant Road vs. 85) and with enough smarts, turned into a (local) push notification that tells you which way to go today.
Commute Tracker gets pretty close to this (it's automatic), but it's buggy (I had a 1 second commute), tracks too much (I want to exclude days where I make a grocery store detour) and is on the ugly side. Daily Commute is prettier, but it's too manual, requiring commutes to be started and stopped.
Build a Stream Spigot tool for filtering of feeds. Unlike Feed Rinse or Yahoo! Pipes, it wouldn't involve taking a feed URL, giving it to the tool, and getting a filtered URL to subscribe to in return. Instead, it would work by connecting to your Google Reader account and then marking matching items as read, so that they don't show up (if using new items only view).
This would have the advantage of not having to re-subscribe when deciding to filter something, benefiting from the regular crawl speed (vs. filtered feed URLs generally having only one subscriber and thus being in the slow crawl bucket) and having item metadata be preserved (though that matters less now that likes and shares are gone).
The filtering could either be done periodically, or for feeds that are PubSubHubbub-enabled, it could be triggered by PSHB pings. It does mean that there is a window during which items that should be filtered our are visible, but the filtering is likely to be cheap enough (get items since the last check, apply a read tag) that it can be done quite frequently.
In addition to the read tag, a "filtered" state tag should also be applied to the items, so that these items can be differentiated during subsequent API calls.
Wednesday, October 3, 2012
To make the Chrome Apps edit-reload cycle faster (especially when there's a build/compilation step), a helper extension could be written. It could reload the app using the management API. More importantly, it could have a custom hook to trigger the re-build/compile step before reloading the app. This could be as simple as an HTTP request to a local server, or something fancier with native messaging once that's available. This could all be triggered via a keyboard command using the commands API.