Ryan Tomayko

Optimizing Optimizing HTML —

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).

Doing It Wrong —

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.

Things UNIX can do atomically —

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.

The Maximal Usage Doctrine for Open Source —

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.

Rack 1.1 released —

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.

Do It Now —

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.

ASCII Table - The Pronunciation Guide —

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.”

/dev/fort —

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:

Highcharts - Interactive JavaScript charts for your webpage —

Nice looking pure JS charting library:

I’ve been seeing more and more of these charting libs lately and they all look great.

Node.js For My Tiny Ruby Brain: Keeping Promises —

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.

WTF - Haml —

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.

How would you serve 100,000 simultaneous comet requests with Node? —

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.

In praise of git’s index —

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.

Introducing: Readability 1.5 —

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.

HANDY ONE-LINERS FOR RUBY —

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.

Sinatra 1.0 FAQ —

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.

Book Review: Coders at Work —

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.

HipHop for PHP: Move Fast —

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.

Sayre's Law —

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.

A rant about PHP compilers in general and HipHop in particular —

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.

Performance Retrospective in PEP 3146 -- Merging Unladen Swallow into CPython —

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.

How do we kick our synchronous addiction? —

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.

The fighting's been fun and all, but it's time to shut up and get along —

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%.

How to upgrade plugins to Rails 3.0 —

Using Rack::Cache as an example. Nice!

A Hidden Cost of Javascript —

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.

Scott Chacon on The Geek Talk —

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.

What really happens when you navigate to a URL —

“The facebook server responds with a permanent redirect”

My take on the GitHub process —

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.

Garbage Collection Slides from LA Ruby Conference —

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.

Hot swapping binaries —

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 will exec. 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, execl preserves these. As an added benefit, the program gets the exact same process ID.

Boom. Nice.

Twitter / OpenSource —

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.

philc's vimium —

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.

Running Processes —

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.

Node.js, redis, and resque —

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.

CDN Catalog —

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.

How Software Engineers and Designers Can Increase Their Focus —

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.

Introducing GitHub Compare View —

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.

Smack a Ho.st —

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.

gem-man(1) -- view a gem's man page —

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.

alandipert's ncsa-mosaic —

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.

Annotated CoffeeScript Grammar —

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.

docco —

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.

man what —

Chris Wanstrath makes the case for UNIX man pages and tours through a bunch of tools for creating, finding, and reading them.

man.cx —

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.

Never trust a programmer who says he knows C++ —

Classic.

Mac OS X SSD tweaks —

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.

Sweet Justice —

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.

Named Gem Environments and Bundler —

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.

Staying the hell out of insert mode —

Ctrl-C goes to normal mode when in insert mode. Amazing.

A Note About Git Commit Messages —

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.

Higher Order Mustache —

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.

Introducing Jake: A Build Tool for JavaScript —

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.

Heroku Ships Experimental Node.js Support —

Boom. It looks like long running connections aren’t completely baked yet but this is really promising.

unix-jun72 —

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.

HTTP Status Code Drinking Game —

Use this to get kicked out of the party.

Re-Reader: A stripped-down re-style of Google Reader by John Holdun —

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.

Check out these HTML5 demos —

A bunch of animated gifs are worth a thousand words.

Always ship trunk —

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.

bcat -- pipe to browser utility —

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.

pocco —

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…”

Building Filesystems the Way You Build Web Apps —

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.

It’s Faster Because It’s C —

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.

Beej's Guide to Unix IPC —

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.

3 shell scripts: Kill weasel words, avoid the passive, eliminate duplicates —

I can’t think of anything I like better than the intersection of writing and shell hacking.

Your Code Sucks —

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.

Pull Requests 2.0 —

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.