I’ve been working with kneath on this pretty much since the day we started at GitHub almost a year ago. Not full time but whenever we could steal time away from other projects. We’re both stoked to have finally shipped it.

I wrapped the original blog post draft with this sentence:
Pull requests elevate the collaborative aspects of development to creative works in their own right. We can’t wait to see where you take them!
We ended up striking it — a little too floaty for a product/feature announcement. I believe every word of it, though.
Story of my career; superbly told. I still hate on code, but now I take it as a sign that there’s probably something interesting I don’t understand.
I can’t think of anything I like better than the intersection of writing and shell hacking.
A gentle introduction to the world of UNIX IPC. Covers fork, signals, pipes, FIFOs, file locking, POSIX message queues, semaphores, shared memory segments, memory mapped files, UNIX sockets. Not a ton of depth, but that’s okay – you can read all of it in about 15 minutes and have a good feel for the pros and cons of all the different types of IPC.
Check out Beej’s Guide to Network Programming and Beej’s Quick Guide to GDB too.
That argument debunked for most real world applications.
I liked the way different types of boundedness were presented:
- I/O-bound. Completing a unit of work earlier just means waiting longer for the next block/message.
- Memory-bound. Completing a unit of work earlier just means more time spent thrashing the virtual-memory system.
- Synchronization-bound (i.e. non-parallel). Completing a unit of work earlier just means waiting longer for another thread to release a lock or signal an event – and for the subsequent context switch.
- Algorithm-bound. There’s plenty of other work to do, and the program can get to it immediately, but it’s wasted work because a better algorithm would have avoided it altogether.
As much as I agree with the thrust of the article, C programs really are faster in real life, but I think it’s because people who program in C are more likely to be familiar with common performance problems and tradeoffs. It’s hard not to be at that level.
Interesting concept. Layer the routing guts found in modern web frameworks over Linux’s FUSE userland filesystem stuff and you get a nice model for developing custom filesystems.
The small example (~30 LOC) shows how to build a simple GitHub filesystem, which gives you this:
opus:~ broder$ ./githubfs /mnt/githubfs
opus:~ broder$ ls /mnt/githubfs
opus:~ broder$ ls /mnt/githubfs/ebroder
anygit githubfs pyhesiodfs python-simplestar
auto-aklog ibtsocs python-github2 python-zephyr
bluechips libhesiod python-hesiod
debmarshal ponyexpress python-moira
debothena pyafs python-routefs
opus:~ broder$ ls /mnt/githubfs
ebroder
Pretty awesome.
Python version of Docco, the quick-and-dirty, hundred-line-long, literate-programming-style documentation generator:
8888888b.
888 Y88b
888 888
888 d88P .d88b. .d8888b .d8888b .d88b.
8888888P" d88""88b d88P" d88P" d88""88b
888 888 888 888 888 888 888
888 Y88..88P Y88b. Y88b. Y88..88P
888 "Y88P" "Y8888P "Y8888P "Y88P"
All together, we have Docco, Rocco, shocco, and now Pocco. Jeremy observes, “It’s a whole little adorable family of midget programs now…”
I’m pleased to announce the first public release of a small project I’ve been working on: bcat is a command line utility that streams text or HTML input to a web browser. Input is unbuffered and displayed progressively as it’s read from standard input, so bcat works great with programs that generate output over longish periods of time like build tools, tail(1), etc. It’s also useful for previewing HTML output when working on Markdown, Textile, AsciiDoc, Ronn, DocBook, etc. source files.
The plan is to bring as many of TextMate’s excellent HTML output capabilities as is feasible to the shell and to editors like vim or Emacs.
Paul Hammond’s recent Velocity talk on managing different code-paths for beta features, A/B testing, staff-only features, etc. in web apps. I’ve been interested in tools and techniques for doing percentage-based feature deploys for a long time. This is the first time I’ve seen someone talk about it in any detail.
A bunch of animated gifs are worth a thousand words.
Minimalist Google Reader theme with a focus on typography and removal of administrative debris. I just now installed it and passed quickly through my feeds but that’s all it took. This thing is gorgeous:

All sidebar and other navigation is completely gone, so be sure to hit ? (or i? with Vimium installed) for a list of keyboard shortcuts.
Use this to get kicked out of the party.
I love stuff like this:
The unix-jun72 project has scanned in a printout of 1st Edition UNIX from June 1972, and restored it to an incomplete but running system. Userland binaries and a C compiler have been recovered from other surviving DECtapes.
There’s also a mirror on GitHub.
Boom. It looks like long running connections aren’t completely baked yet but this is really promising.
Looks great. Really glad to see file tasks, too. Code is here. I’m dying for a real JavaScript project so I can start playing with all the great looking stuff these guys are putting out.
Mustache is my favorite template language by far. By far. This is a great example of why. It solves every problem simply and elegantly, or it doesn’t solve it all. Here’s the syntax in its entirety. In his post, Chris talks about how adding very simple lambda support solved the cache block problem. It’s just as suitable as solution for embedding Markdown in templates.
Great advice for commit message formatting. It’s absolutely vital that the first line not exceed 65 characters (50 is suggested and good practice). Browsing around github.com, I see a ton of commits with an entire paragraph on the first line and it drives me crazy. This destroys git log, tig, git format-patch, and a lot of other commands that use the first line as a short message — even git pull shows it when the HEAD moves.
Ctrl-C goes to normal mode when in insert mode. Amazing.
Yehuda lays out some of the history and rationale behind Rubygems’s multi-package-version design and also takes a look at how a few recent tools (Bundler, Rip, rvm, etc.) are using different approaches to develop concepts around multiple “environments”.
I’ve never been a fan of Rubygems multi-versioned, directory-per-package approach to organizing packages. There’s a few different reasons, but mostly it forces a lot of unnecessary complexity into runtime that could (I think) be handled more simply at install time. I do like the convenience of installing a bunch of packages into a single Rubygems environment without having to think about it, but those benefits are outweighed by the subtle differences in runtime behavior, some of which can be extremely annoying (e.g., “already activated” errors). I’d rather be aware of and be forced to deal with those issues at install time. It’s great to see so much experimentation on new tools and alternative approaches.
New JavaScript based text justification library looks promising. The default HTML/CSS text justification built into every browser has always sucked, due mostly to lack of word hyphenation.
One of the places I’d really like to have good justification is in Ronn’s HTML based man pages. It uses text-align: justify currently, but I’ve been considering making it non-justified because it’s so horribly bad. Compare it to the proper justified / hyphenated text generated by groff when viewing manpages in a terminal. It’s night and day.
Great set of tips for eking out disk performance on MacOS X, like disabling last access time tracking. These are just as useful in non-SSD configs.
This is probably the nicest manpage site I’ve come across:

I haven’t heard of it. They imported 98,660 manpages from all available Debian packages plus some from other sources. The type is clean. URLs are short and sweet. Manual sections are presented in a nice TOC on the left. They have some other novel features like comments on each manpage.
I planned to do something very similar. I even registered mancutter.org. A great number of manpages are distributed under a liberal license. I wanted to throw up a nice and simple site and then ship a tool anyone could run to bomb roff up to the server for all manpages on a machine. You should be able to gather all Linux and BSD manpages fairly quickly with such a system. Or, you could push up a specific set of manpages so project maintainers could publish directly to the site. I might still but man.cx is a huge chunk of what I was looking for.
Chris Wanstrath makes the case for UNIX man pages and tours through a bunch of tools for creating, finding, and reading them.
Okay, this is the project used to generate the previously linked CoffeeScript documentation. It’s a “quick-and-dirty, hundred-line-long, literate-programming-style documentation generator.” It pulls out comments, applies markdown, and then runs the code through pygments for syntax highlighting.
Beautiful.
I don’t believe I’ve ever seen code annotated like this before:
It’s perfect.
The HTML is <table> based. Each segment is an anchored <tr> with the left cell holding the annotations and the right cell holding the code. I’d probably flip them around but the overall effect is wonderful.
The sources for NCSA Mosaic v2.7 — one the first graphical web browsers (1993) and certainly the one that led to the World Wide Web as we know it — can now be found on GitHub.
You can even run it on a modern Linux. Here’s what the GitHub homepage looks like:

The team that built NCSA Mosaic (Marc Andreessen et al) would go on to create Mosaic Communications Corp., which eventually became Netscape Communications Corp., which open sourced the Mozilla browser, leading to Firefox.
I wonder if any of the original NCSA Mosaic code still exists in any form at mozilla.org.
The Mosaic Wikipedia entry has a thorough history.
Perfect. This was a huge piece missing from Ron and I had no clue how to address it. Chris’s gem extension adds a gem man command that brings up the man page for any gem and works with any gem that includes normal roff man pages.
Tim Pope registered smackaho.st and pointed the wildcard at 127.0.0.1 so you don’t have to futz around in /etc/hosts every time you want another local hostname.
try visiting dontmakeme.smackaho.st:3000
Brilliant.
It’s a commit list (git log --online --reverse <start>..<end>), a rolled up diff + diffstat (git diff --stat <start>...<end>), and commit comments all on one page. Here it is in action showing all changes between the Sinatra 0.9.4 and 1.0.a releases:
Dogfood never tasted so good. We’ve been incrementally using and developing and using and developing this thing for a few months now. It’s become a core part of our code review process. I’m extremely happy with how it turned out.
Finally, a How To Be Productive system I can get behind:
Q: Favorite web or mobile apps for getting focused?
A: I don’t use apps to get focused. Playing around with productivity apps is just another way to procrastinate. You become more productive by getting into the habit of doing actual work regularly, not by constantly thinking about how you can get more work done.
I don’t even use a to-do app. If something is important, I’ll remember it. If I have an idea I’m afraid I might forget, I set a reminder in my calendar on a date when I know I’ll have time to work on it. On that date, I’ll either work on it, discard it, or reschedule it.
Don’t miss Lukas’s definitive tip for massive increasing productivity and intelligence at the end. It’s money in the bank.
We should be doing more of this:
If you’re building a modern website then you’ll be needing some javascript libraries and css.
Rather than hosting these common libraries on your own server, you should Use a Content Delivery Network. Lucky for you Google, Microsoft and Yahoo host a range of popular javascript and css which you can directly link to for free. This saves your bandwidth and speeds up your website load time.
The great thing about the shared CDN approach is that the resources are cached once and reused across all sites, often without even making a validation request.
I’d seen the JavaScript libraries before but I’d never considered using this approach with CSS. The YUI CSS reset is a perfect example of where a shared CDN provides the most benefit. If every site that employed the basic CSS reset used this URL, it would effectively be baked into the browser with no overhead after the first request.
Interesting use of node.js as a sort of HTTP reverse proxy. It uses redis based queues to communicate with backends instead of establishing a direct socket connection and doing HTTP:
This spike uses node to put messages into a (redis) queue. Ruby background workers read from the queue, process the requests, and respond on a different queue. When node receives the response from the background worker, it sends the response back to the waiting user.
I assume this adds a not insignificant amount of latency to each request but would also make possible a bunch of long-running connection features. For example, the response (or portions of the response) could be delivered from separate worker processes. This style of architecture, where the client connection isn’t tied to backend web process, looks promising. The nginx_http_push_module is another example that gives the same types of benefits.
Dustin Sallings lays out a nice list of simple, non-pid-polling process supervision techniques available on various Unix and Linux environments. Great reference. I’m pretty sure the /etc/inittab respawn directive is one of the most underrated utilities in Linux server environments.
Life altering Chrome extension that adds vi keybindings. It’s not quite as intense as Firefox’s Vimperator but that’s a good thing IMO. You get some really interesting stuff in addition to the obvious h, j, k, and l movement keys and find commands:
gg scroll to top
G scroll to bottom
f activate link hints mode
F activate link hints mode to open in new tab
r reload
gf view source
zi zoom in
zo zoom out
i enter insert mode -- commands ignored until you hit esc to exit
y copy current url to the clipboard
ba, H back in history
fw, fo, L forward in history
J, gT go one tab left
K, gt go one tab right
t new tab
d close tab
u restore closed tab
Feels great in practice. Sold.
Big list of open source projects Twitter developers contribute to. I really like the way this page presents things. It would be really cool if every user on GitHub automatically had a page like this somewhere.
The technique in a nutshell:
The basic idea of what’s going to happen is that we will create a pair of pipes and then
fork(). The child process will hold the pipe that does the writing and the parent the one that does the reading. Now, the parent willexec. This is a bit odd. Normally when you fork, then exec, it’s the child process which does the exec. However, here we really want the new version of the program to have access to all of the old file descriptors. Luckily,execlpreserves these. As an added benefit, the program gets the exact same process ID.
Boom. Nice.
Looks like Aman and Joe knocked one out of the park with this presentation on Ruby’s GC:

I wish RailsLab or PeepCode or somebody would team up with those guys and do a series of screencasts. You can learn a ton just by watching over their shoulder while they work.
I’ve received a lot of positive feedback on this blog post length comment left on Rafe’s recent post about GitHub’s process, or lack thereof. In it, I try to address some of the common objections people have when they hear how things work inside GitHub.
“The facebook server responds with a permanent redirect”
Working with Scott is such a huge honor. I don’t even have words to describe it, really. He’s a class act. You get a glimpse of it in this interview.
He even lets loose some GitHub secrets:
At GitHub we don’t have a project tracker or todo list – we just all work on whatever is most interesting to us. No standup meetings, burndown charts or points to assign. No chickens or pigs. It’s sort of the open source software style of business – everyone itches their own scratch. Inexplicably, it works really well and keeps everyone engaged, new features appearing quickly and bugs fixed rather fast. No managers, directors, PMs or departments – and it’s the most agile, focused and efficient team I’ve ever worked with. Maybe we should write a book about it.
Do whatever you want. Do it now. Don’t fuck around.
Interesting set of results from a series of JavaScript parse and load benchmarks on Safari, Chrome, Firefox, and Opera presented with pretty graphs and tables. I’m convinced browser-side JavaScript profiling and optimization—including this kind of parse+load and GC profiling—is going to occupy more and more of my time in the future.
Using Rack::Cache as an example. Nice!
Benjamin Pollack — one of the guys that helped build Fog Creek’s Mercurial based source control system, Kiln — pleads for Git and Hg folks to stop bickering over stupid shit and team up to go after the massive number of Subversion/CVS holdouts.
I can confirm one of his points:
It’s easy, in the yin/yang of Hacker News and proggit, to forget that most developers are not even aware of what DVCSes are or what they do. Yeah. Sounds crazy, I know, but trust me on this.
This is true. My second day on the job at GitHub was spent at the Zend PHP conference. Maybe 10% of the people we talked to had any awareness of DVCS at all, and a big chunk of that 10% hadn’t used DVCS seriously on a project. This was six months ago.
For most popular programming language communities, I’d put the percentage of developers that really understand DVCS under 1%.
Eric Florenzano asks why modern web frameworks insist on a synchronous programming model and gives some answers with possible alternatives. The article is dead on, IMO, but I’m not sold on his conclusion:
We need to look at these alternative implementations like coroutines and lightweight processes, so that we can make asynchronous programming as easy as synchronous programming.
For Ruby, this is all about making Fiber robust and widely available. There was a time when I too thought this would solve all problems by hiding the underlying async model but retaining its benefits. That’s the dream. I don’t believe in it anymore. Having experimented with such an approach on a small team, I’m fairly confident that everybody working on an event-based/async program needs to understand the underlying model or blocking code will inevitably be introduced and destroy everything. And once everyone’s comfy with async, you’ll find that the sync façade is annoying and unhelpful. Embrace it.
Shame:
Our initial goal for Unladen Swallow was a 5x performance improvement over CPython 2.6. We did not hit that, nor to put it bluntly, even come close. Why did the project not hit that goal, and can an LLVM-based JIT ever hit that goal?
Here’s the performance comparison itself. Most gains were under 1.5x and memory usage grew significantly in every benchmark. Startup time also suffered.
As mentioned in the Performance Retrospective, they had to divert a lot of energy from performance work to fixing LLVM bugs and axe grinding on debugging/profiling tools. I have my fingers crossed that they can pull off the 5x gains in the next round. Let’s hope so, I’d demand at least that much to justify this:
In order to use LLVM, Unladen Swallow has introduced C++ into the core CPython tree and build process.
Slipperyest of slopes.
Paul Bigger, author of the phc PHP compiler, explains why Facebook’s HipHop is interesting and why the translator/compiler technique might be a better design than a JIT or something more… elaborate. Good article all around, even if you don’t care about PHP.
There’s some salt in there too:
I’m also slightly annoyed that people all of a sudden care about PHP compilers. I worked on one for 4 years and I could not convince anyone to give a shit. But now that its got the Facebook logo on it, all of a sudden PHP compilers are the greatest thing ever. Bah.
Lesson in marketing. Merit is not conducive to mass appeal.
More general version of Parkinson’s Law of Triviality (AKA “bike shedding”):
“In any dispute the intensity of feeling is inversely proportional to the value of the stakes at issue.”
Via this HN comment thread discussing the tendency of both Ruby and Python hackers tend to favor their chosen language with vehemence.
Wow, okay, so it translates PHP into C++ and then compiles it with gcc. That’s… interesting. Here’s what’s more interesting, if you ask me:
We are proud to say that at this point, we are serving over 90% of [Facebook’s] Web traffic using HipHop, all only six months after deployment.
That’s pretty damn fast, and super impressive if true. I can’t imagine the amount of infrastructure that would need touching for this kind of transition. You have to work with the backend devs and the sysadmins and pretty much everyone. That’s no small feat at a company the size of Facebook. Kudos.
A quote from Brad Fitzpatrick:
I find that is the best way to start a conversation. If you get on a mailing list and you are like ‘hey I want to add feature X’ the maintainer is probably going to be like: ‘ Oh fuck, I am so busy, go away, I hate feature X’. But if you come to them and you are like ‘I want to add feature X. I was thinking something like the attached patch’ which is totally wrong but you say, ‘But I think its totally wrong. I am thinking the right way might be to do X’ which is some more complex way, generally they will be like ‘Holly crap, they tried and look, they totally did it the wrong way. Maybe that pains the maintainer. They are like ‘ Oh man, I can’t believe they went through all that effort to do it. Its so easy to do the right thing,’ and then they reply.
This is the secret to being productive when contributing to open source. It’s very rare that you should approach a mailing list without a patch of some kind.
We pushed out a Sinatra 1.0 pre-release. The FAQ includes some info on what the 1.0 release means and how to prepare for it.
Nice list of Ruby one-liners when working at the shell. e.g., emulating nl(1):
# number each line of a file (left justified).
$ ruby -ne 'printf("%-6s%s", $., $_)' < file.txt
# number each line of a file (right justified).
$ ruby -ne 'printf("%6s%s", $., $_)' < file.txt
# number each line of a file, only print non-blank lines
$ ruby -e 'while gets; end; puts $.' < file.txt
Unlike some other things, the -p and -e switches are something I’ve always been glad ruby adopted from perl.
The Arc90 guys have a nice little Readability update. Two new styles with beautiful Typekit faces and more size and margin options.
This is cool too:
Beyond the “wow, this makes reading so much easier” comments is a whole slew of emails from the elderly, people with vision or cognitive difficulties and users that rely on screen readers. It’s incredibly gratifying to see Readability make a difference for so many people.
For the record, I’m rocking the Athelas style (type info) with Large type and Medium margins.
Aristotle explains how he uses git’s index and how it makes git unique among VCSs. I’ve raved about git’s index before in The Thing About Git. It’s great.
Simon Willison throws down a C100K problem for node.js. That’s a tough order for a single machine. To get even close, you’re going to need lots of system tuning way down below node.js.
I love this so much:
… one way or another it seems I need something called EMACS.. WTF..!!!!! I dare you to install it and see how many WTFsss you will say…. it’s like some text editor that is so smart that you dont use the mouse dont even use the cursor keys..if you want to go back one character you hit control then B!!! Brilliant!!! two random keys instead of one with an arrow!!!! WWWTTTFFFF!! ok I might not need this crap…. lost a day learning to use the Rubik cube of text editors.
It’s easy to pfft and blow off this kind of … criticism, but if you can look past the make believe grammar and punctuation you really do get a sense for how hard it is for newbies to wrap their heads around even very basic set of tools needed to build things on the web. Maybe what we do is just hard and complex and there’s nothing we can do to make it simpler. I’m just always surprised when I get to peek through someone else’s eyes and see just how fucked up everything must seem.
Rick documents his progress a week into node.js. Nice look at some of the basic concepts underlying the system, like async everywhere and promises.
Nice looking pure JS charting library:

I’ve been seeing more and more of these charting libs lately and they all look great.
A master plan:
Imagine a place of no distractions, no IM, no Twitter — in fact, no internet. Within, a group of a dozen or more developers, designers, thinkers and doers. And a lot of a food.
Now imagine that place is a fort.
They’re serious:

ASCII punctuation characters and their various pronunciations. e.g., the entry for Exclamation point (!) lists:
exclamation (mark), (ex)clam, excl, wow, hey, boing, bang, shout, yell, shriek, pling, factorial, ball-bat, smash, cuss, store, potion (NetHack), not (UNIX) ©, dammit (UNIX)
That last one has a footnote: “as in ‘quit, dammit!’ while exiting vi and hoping one hasn’t clobbered a file too badly.”
Nice. The todo / email / information “management system” I’ve been using for a while has a name now:
This doesn’t just apply to email, of course — it works for any todo list. But only if you say no to reordering, prioritizing, estimating deadlines, and doing the most important things first. Forget all that. Do it now.
Seriously. All that productivity snake oil is destroying your productivity. Being productive at managing productivity is not the same as being productive.
Lots of needed fixes and some new features in this release, including new Config, ETag, Sendfile, and Logger middlewares, Carl and Yehuda’s rackup to Rack::Server conversion, multipart fixes, and a bunch of optimizations by Eric Wong.
Huge props to Josh Peek for putting his head down man'ing the patch queue on this one.
I like the way Yehuda first lays out his motivations and goals as an open source developer and then evaluates the MIT/BSD vs. GPL licenses based on those goals. That’s how you pick a license. No one can tell you why you write a given piece of free / open source software, so no one can really tell you how it should be licensed.
Like Yehuda, I tend to lean heavily toward MIT/BSD style licenses these days but I can imagine situations where the copyleft stipulations included in the GPL would be extremely important to me.
Insanely useful when you’re trying to avoid thread and process synchronization primitives — mutexes, flock, etc. — in concurrent code, which should basically be always. Rack::Cache’s file stores use some of these techniques to allow multiple backends to work against the same filesystem without file locks or a separate central writing process.
Tim Bray on the state of Enterprise tech:
This is unacceptable. The Fortune 1,000 are bleeding money and missing huge opportunities to excel and compete. I’m not going to say that these are low-hanging fruit, because if it were easy to bridge this gap, it’d have been bridged. But the gap is so big, the rewards are so huge, that it’s time for some serious bridge-building investment. I don’t know what my future is right now, but this seems by far the most important thing for my profession to be working on.
That’s what led me to start (the now defunct) lesscode.org almost five years ago. Things actually seem to have come a long way since then, when the idea of using open source, dynamic languages, or web protocols would get you laughed out of the room. That’s not the case anymore.
I’ve given up the idea that advocacy can have an impact, though. Everyone has something to pitch The Enterprise. You get lost in the noise. Useful tech wins eventually.
Oh neat. You can drop the type='text/javascript' from your <script> tags, type='text/css' from your <style> (and/or <link rel='stylesheet'>) tags and the browsers won’t care. Also, in 2010, <b> and <i> are cooler than <strong> and <em>, and trailing slashes on self closing tags are lame.
Personally, I like these little tricks for making HTML more human readable but I can’t believe people are actually doing stuff like this in an attempt to compress HTML to gain network/browser efficiencies. I dare someone to actually benchmark those optimizations. Cutting your sucky EULA page in half and trimming away all that shit in your header/sidebar would be much more productive (but still barely worthwhile).
Tips for Ruby project maintainers on increasing the changes of getting your stuffs packaged for Debian. Most are just good sense. Use setup.rb, don’t explicitly require rubygems in your libraries and tests, use the most portable shebang (#!/usr/bin/env ruby), and provide a man page. Ron can help with that last one.
Nice to see Narwhal, Jack, CommonJS, and node.js getting some love on ReadWriteWeb. Javascript on the server is breaking out.
defunkt’s hub is a command line utility that adds GitHub knowledge to git. Sweet. It expands GitHub repository references so you can do stuff like: git clone defunkt/gist, git remote add bmizerany, etc.
I’ve released a tool for authoring UNIX manual pages using a markdown-ish source format:
Ron is a humane text format and toolchain for creating UNIX man pages, and things that appear as man pages from a distance. Use it to build and install standard UNIX roff man pages or to generate nicely formatted HTML manual pages for the web.
It still needs some work but can produce useful output for both roff and HTML. The sources are on GitHub.
Google’s shipping official beta builds of Chrome for Mac and Linux. I’ve been using Chromium for a few months now and it’s definitely become my favorite browser. It needs a flash blocking extension and an ad blocker. I’m using userscripts for both but they’re a little janky.
In comments related to the recent shutdown of Favrd:
I’ve spent the past year or so reading and writing and doing my level best to chip away at 40 years of belief in the logical fallacy that one’s identity meaning – self-worth, self-image, whatever you want to call it – can accurately be measured in the thoughts of others. Much as you and I may enjoy being encouraged through recognition and praise and dislike being saddened by rejection or indifference (god knows we’re taught to right from the outset by caregivers: good boy, pretty picture, heckuva job Brownie), deriving personal value from these transactions in the absence of a well-formed internal frame of reference through which you can decide on your own what does and doesn’t work, and subsequently accept the opinions of others as feedback, is just plain faulty thinking, of the sort that makes otherwise capable, centred people all loopy and weird.
Disco.
Tobi’s log tail and grep app is precisely what I’ve wanted on every single syslog machine I’ve ever had to deal with. And the code has some great examples of using EventMachine features to do real async HTTP stuff.
Murray Gell-Mann’s (quarks, Nobel prize winner, peer to Feynman at Caltech) TEDtalk from 2007 on the relationship between beauty (simplicity) and truth in science and mathematics:
What is especially striking is that in fundamental physics a beautiful or elegant theory is more likely to be right than a theory that is inelegant.
He goes on to give a bunch of anecdotes that show this playing out over and over during the development of particle physics.
Nobody ever believes me when I tell them the Beastie Boys toured with Madonna in 1984-85. Here’s a great set of super high-res press clippings to prove it:
Why isn’t everybody this cool?:
Bill Adler was the director of publicity for Def Jam in the 80s. He allowed me to photocopy his press file on the Beastie Boys from the time when they opened for Madonna.
This is presently the topic of great discussion in the GitHub campfire.
ry’s talk from JSConf.eu. The leading paragraph says it all:
Node.js might be the most exciting single piece of software in the current JavaScript universe. Ryan received standing ovations for his talk and he really deserved it!
Wow. JavaScript is pretty damn big universe right now.
Perfect name.
This email exchange is quite possibly the funniest thing I’ve ever read on the web. Here’s a tiny piece:
Actually, you were asking me to design a logotype which would have taken me a few hours and fifteen years experience. For free. With pie charts. Usually when people don’t ask me to design them a logo, pie charts or website, I, in return, do not ask them to paint my apartment, drive me to the airport, represent me in court or whatever it is they do for a living. Unfortunately though, as your business model consists entirely of “Facebook is cool, I am going to make a website just like that”, this non exchange of free services has no foundation as you offer nothing of which I wont ask for.
It’s just pages and pages of that.
Thank you @mojombo.
UPDATE: @SimonEdhouse responds
UPDATE: zing
I agree. I played with it for a couple days and now I can’t shut up about it. That’s basically all I talked about at RubyConf :)
Chromium runs GreaseMonkey user scripts, apparently. It also says here that “script edits are picked up [from the file system] automatically; just refresh the page to see the changes,”
which is something that annoyed me with Firefox’s GM Addon — the files were buried, crazily named, and you had to use that janky addon manager bullshit to make/reload changes. What is that? A directory full of user scripts (now ~/.js on my system) is a perfectly simple setup. Combine that with right-now reloading and I might actually be able to develop these things when I need them.
Anyway, this AdSweep thing is what led me to investigate; looks pretty reliable if you can get through the GM setup.
I’ve released a bertrpc library for node.js. If you haven’t play with node yet, set aside a night and dig in. Hacking async server-side stuff in JavaScript is every bit as awesome as I’d hoped: easy to install, good docs, fast VM, clean and simple event idioms. I’m impressed.
Tim Pease’s unit test runner and reporter is sexy and has some really interesting features I’ve never considered when running unit tests. Here’s a piece of the README:
To use the solo runner.
turn --solo -Ilib test/
This will run all tests in the test/
directory in a separate process.
Likewise for the cross runner.
turn --cross -Ilib test/
This will run every pairing of tests
in a separate process.
Now that’s interesting. I’d love to have something like GNU Make’s -j option when running unit tests.
Jacob Kaplan-Moss:
It’s really tempting to use an auto-documentation tool like Javadoc or RDoc for reference material.
Don’t.
Auto-generated documentation is almost worthless. At best it’s a slightly improved version of simply browsing through the source, but most of the time it’s easier just to read the source than to navigate the bullshit that these autodoc tools produce. About the only thing auto-generated documentation is good for is filling printed pages when contracts dictate delivery of a certain number of pages of documentation. I feel a particularly deep form of rage every time I click on a “documentation” link and see auto-generated documentation.
Hate that shit.
You know what I want? Man pages. For everything. Wouldn’t it be cool if you didn’t have to write roff?
I recently started a repository for my dotfiles, shell environment, vim config, and utility scripts. As of right now, I’m about 25% through all of the stuff in my $HOME — it should all fill in shortly.
From the apparently just published, Coders at Work (Apress, 2009), Brad Fitzpatrick Talks About Programming:
In practice, nothing works. There are all these beautiful abstractions that are backed by shit. The implementations of libraries that look like they could be beautiful are shit. And so if you’re the one responsible for the cost of buying servers, or reliability – if you’re on call for pages – it helps to actually know what’s going on under the covers and not trust everyone else’s library, and code, and interfaces. (…)
They should have titled the book, “In Practice, Nothing Works”. Anyway, you can grab the — ick — PDF ebook for $20 on Apress.
Really excited to see Chris release the shiny new Redis-based work queue that’s been running GitHub for the past couple of months:
It boils down to this: GitHub is a warzone. We are constantly overloaded and rely very, very heavily on our queue. If it’s backed up, we need to know why. We need to know if we can fix it. We need workers to not get stuck and we need to know when they are stuck. We need to see what the queue is doing. We need to see what jobs have failed. We need stats: how long are workers living, how many jobs are they processing, how many jobs have been processed total, how many errors have there been, are errors being repeated, did a deploy introduce a new one?
I’m still getting my feet wet with the jobs system but I can’t wait to get my hands dirty in the guts of this thing.
I’ve dumped MacPorts for pkgsrc. This quick tutorial helped me get going and this package browser is awesome.
Not sure how I never heard of this program before:
dtachis a tiny program that emulates the detach feature of screen, allowing you to run a program in an environment that is protected from the controlling terminal and attach to it later.dtachdoes not keep track of the contents of the screen, and thus works best with programs that know how to redraw themselves.dtachdoes not, however, have the other features of screen, such as its support of multiple terminals or its terminal emulation support. This makes dtach extremely tiny compared to screen, making it more easily audited for bugs and security holes, and also allows it to fit in environments where space is limited, such as on rescue disks.
GitHub has rake tasks that use dtach to manage redis and maybe some other things.
In honor of the greatest xkcd ever, this is Primer in its entirety. It really is that fucked up.
Need more rdebug?
I sometimes forget how useful a debugger is for coming up to speed on a new codebase. This bare-bones HOWTO on rdebug was everything I needed and nothing I didn’t.
Nice little self-contained perl script that shows a basic memcached top display for a list of servers.
$ curl http://memcache-top.googlecode.com/files/memcache-top-v0.6 >
~/bin/memcache-top
$ chmod +x ~/bin/memcache-top
$ memcache-top --sleep 1 --instances memcache1,memcache2,memcache3
That gives you this:

Nifty.
It’s definitely misconfigured in one way or the other as evidenced by the fact that it sucks and has sucked consistently for over a year.
Gemcutter will become rubygems.org and Rubyforge will eventually go away entirely:
So, what does this mean for RubyForge? The Ruby-specific functionality and data will be moved into RubyGems.org, and the parts that other hosting sites (GitHub, Google Code, SourceForge) can do better will be pruned away. Migration paths for those projects will be provided, we’re not throwing any switches without warning. RubyGems.org will not be gaining any “bloat” from rewritten RubyForge features.
Wow. Congrats to @qrush and the Rubyforge team for pulling this off so quickly. Also, it’s pretty cool to see Heroku hosting a major/official piece of Ruby community infrastructure.
This is pretty rad. You can do web searches and whatnot without leaving a command line style interface but you can also do stuff like read news feeds. Check it:

I’d love to settle into this kind of workflow but these shell interfaces always have one thing or another wrong with them. Maybe this is The One. We’ll see.
Good article. The comments are even better:
reading this article reminds me countless time I have looked at the clock and the second hand it not moving and then it starts, I am sure this takes longer than a second
That’s always freaked me out. I’ve mentioned it once or twice but people just think I’m crazy so I don’t bring it up anymore. This guy, Frank, explains the phenomenon:
In more ‘joe sixpack’-terms. After you move your eyes fast, they are unable to collect information for a fraction of a second. When the eyes comes back ‘online’ the brain collects motion-information for an equal fraction of a second, and extrapolates the information backwards to create what things should have looked like and fills this fabricated visual information into your memory. Since the needle (or digit) didn’t move while the brain was collecting info for the extrapolation, it won’t be able to predict that it moved in the past either.
Crazy. I knew something was going on.
Cloud computing at its best.
Turns out
tig, the ncurses front-end to git,
is all kinds of customizable. Quick tip: set the author-width
to 5 or less and author names are abbreviated to initials:
$ cat <<E > ~/.tigrc
set show-date = no
set author-width=3
E
$ tig
RT harmful specs - disable them
KN [defunkt/master] I shine the shoes around here
CW don't let daemon serving ruin the public / private flow
CW ensure the listeners are notified, just in case
CW add "open sourced" event
CW Turns out we're still stuck on 1.0
CW let's try this again
CW allow overriding of the queue during job creation
Boom.
Simon Willison on using Redis with the Python REPL to get complex shit done quick. Insightful piece, as always.