http://www.chromium.org/chromium-os/developer-information-fo...

Just have an ssh-able desktop/VM somewhere with emacs, install https://chrome.google.com/webstore/detail/secure-shell/pnhec..., and set the font to Source Code Pro (font instructions are in http://git.chromium.org/gitweb/?p=chromiumos/platform/assets...)

I'm linking to the Amazon page, but IIRC the book is old enough to be in the public domain and there is a free text version somewhere.

http://www.amazon.com/Operators-Things-Inner-Life-Schizophre...

http://mixergy.com/tom-preston-werner-github-interview/

(search for 'which metrics') to skip to the pricing part).

Money quote: "That’s like buying a car based on how much it weighs. It’s irrelevant."

I may be biased since GitHub does a lot to foster the developer community in my area (I nabbed a sweet contracting gig at one of their drinkups), but I'm perfectly happy with their pricing.

The basic process is:

1. git rebase -i, and change a commit to 'edit' 2. git reset HEAD^, this 'undoes' the commit and leaves the changes in your directory as if you had written the code but hadn't committed it yet 3. git status 4. git add -p, this lets you add commits to your file a chunk at a time. first, add all the commits as a part of commit one. skip the parts you want for commit two. 5. git commit (do not do git commit -a here) and write the message for your first commit 6. now your working directory will be all the changes for commit two. git commit -a if you want all of them 7. git rebase --continue

This page[1] has a more concise answer, but leaves out the git commit -p part.

Note that if you mess up in rebase-land, you can always git rebase --abort. If you come out of the rebase and everything looks lost ('oh god I lost my data!'), use git reflog and pull up the hash of where you were before. Your data is still there.

Another note: if your commits are already separate, you can use rebase to selectively squash and reorder them. Read the manual on git rebase -i, if you rearrange commits and only squash some I think you'll get what I'm talking about.

[1] http://stackoverflow.com/questions/6217156/how-to-break-a-pr...

In general, your commits should be the smallest atomic operation that makes sense. When people talk about 'clean history,' they're talking about working in the awesome workflow git provides:

1. Write half-written broken code. 2. Fix that code up. 3. Add some more onto that. 4. Fix a typo! 5. Forgot to update the README.

Now, you could push that to master, but then the main master is littered with commit messages like 'oops' and 'typo.' Instead, you can rebase 5-1 onto the latest master, squash them together, and have one 'nice' commit that only has the cleaned up final changes.

This is one of the most powerful things about git: in a private repo, you can commit all kinds of garbage and half-written stuff without caring. When you want to make your stuff public, rebase and squash, then send it out. Be careful though! Only rebase your own private branches, or you're gonna have a bad time™.

Well, no, you're just writing the locks yourself in an ad-hoc way. Every time you have a callback calling another callback, you have a lock and all the race condition/deadlock issues associated with that. Of course, writing an application that doesn't have complicated synchronization requirements (streaming fileserver) can often require less boilerplate in an evented system. However, you run into a catch-22 here: by definition it's an application with fewer synchronization requirements, so you'd have to use fewer complicated locks in a 'heavy thread' implementation as well :).

Ultimately it's an engineering tradeoff problem, and you have to weigh lightweight node-style cooperative multitasking with the ability of a traditional thread system to better handle highly complicated scenarios.

Or you can be Russ Cox and argue that this is a false dichotomy[1] and that we should all be using CSP. I'm in that camp.

Andrew Birrell: threads.

John Ousterhout: events.

John DeTreville: no.

Rob Pike: yes.

[1] http://swtch.com/~rsc/talks/threads07/

A SAT solver[1] can automatically figure out a range of acceptable solutions for your conditions. 'I want this goal, is there a way to make that happen?' Security people love this. SMT solvers are even crazier[2] and can automatically determine solutions to linear equations or inequalities (this comes in handy when analyzing loops). Z3 has an online version at [3].

Also, if you have a lot of nasty cascaded if-statements, a K-map[4] and espresso[5] can reduce those down to a minimal set of branches. Note that fewer branches means fewer branch prediction penalties, which means faster code!

[1] http://en.wikipedia.org/wiki/Boolean_satisfiability_problem

[2] http://media.tumblr.com/tumblr_m8ywn1iesH1r6uu3b.gif

[3] http://rise4fun.com/z3/tutorial/guide

[4] http://en.wikipedia.org/wiki/Karnaugh_map

[5] http://embedded.eecs.berkeley.edu/pubs/downloads/espresso/in... and ftp://ftp.cs.man.ac.uk/pub/amulet/balsa/other-software/espresso-ab-1.0.tar.gz

Edit: and [2] would make for a great 11.5" laptop sticker

[1] http://www.3quarks.com/en/StationClock/index.html

[2] http://upload.wikimedia.org/wikipedia/en/b/b2/SBB-CFF-FFS.sv...

This is Apple. The resume will simply say 'worked at Apple Inc. developing software.'

This phrase gives me the same feeling I'd get from finding an old Thomas Bangalter track or something.

Unfortunately, once your dimensions get large it becomes difficult for humans to visualize the optimizations, which is where Espresso[2][3] comes in handy.

[1] http://en.wikipedia.org/wiki/Karnaugh_map

[2] http://embedded.eecs.berkeley.edu/pubs/downloads/espresso/in...

[3] ftp://ftp.cs.man.ac.uk/pub/amulet/balsa/other-software/espresso-ab-1.0.tar.gz