2,354 karma · joined August 8, 2009
Sonian provides a large-scale email archiving platform resold by several vendors you may have heard of. We run entirely on EC2, and Amazon was an investor in our Series B ($9M). We use Clojure for our backend, Rails for the frontend, and Chef to manage infrastructure (i work in the latter group). We are expanding, but the devs all know each other and we work in cross-functional teams whenever possible.
The development teams are mostly remote and use tmux/Skype to pair program. Our VP of E is looking for a Director of Development, however, and for this someone local is preferable. We're looking for someone with experience not just building reliable applications at scale but managing remote teams to do so. We have a longer formal posting ready, but it's not up yet so email me (decklin@red-bean.com) for more info.
Also, if you're a Chef expert or just an ops-and-dynamic-languages hacker who loves to learn new things, but not interested in management, please contact me too! Any location. I'd love to make the case for another devop on my team. A full posting for that is up at http://www.sonian.com/about/careers/development-operations-e....
Perks: get flown out to Boston twice a year (or if like me you're already here, Sushi Thursdays :-)), MacBook Pro or ThinkPad, good benefits.
For both positions, please contact jobs@sonian.net and let them know that I (Decklin Foster) referred you. Thanks!
I'm just explaining why I immediately left; I don't know if this happens frequently enough for you to care.
I'm not sure if the "forget whatever happened" metaphor works for me. In the "revert a revert" article above, the problem is that merging a topic branch doesn't cause the first few commits on it to be applied if those commits were already merged but then reverted -- the revert has no effect on the merge. This is precisely because every commit object, since it includes it's parent's sha1, uniquely determines a history of changes, and commits in that are in both ancestries don't get re-applied.
In Bram's example, you have the opposite problem -- two commits are semantically the same but were made independently and have different sha1s. If Linus were drawing this diagram he would label them B and B' (and so on... there's a lot). To git, B' is totally different so a merge applies the change "again". If the other person had noticed this and reset their branch to the first B, the merge would be a fast-forward.
IMHO, the Don't Do That should apply to creating those commits (by cherry-picking, or not rebasing duplicated work) rather than merging. Not because such commits are morally wrong or something like that, but because git intentionally ("the stupid content tracker") doesn't handle them well. That's the tradeoff of the nice object model.
Our git workflow at my job is pretty messy and does run into this sort of stuff. I'd love something just a little more darcs-y, like say grafting together the two branches in the second example that arrive at the same content (without having to manage a local grafts file separate from the repository), but that opens many other cans of worms that I'm sure I'm not intelligent enough to deal with.
Shameless self-promotion link, if interested: https://chrome.google.com/extensions/detail/mjafhhefmkfchamf...
Based on this misconception he draws the conclusion that the Lisp folks think the C/Unix approach is "evil", which is just silly. Maybe this is why he thinks it's a cult.
http://www.engadget.com/2011/03/02/live-from-apples-ipad-2-e...
Reddit.com HTML.: 37.6 KB Text in that HTML: 5.9 KB
(That's just what I got from copy+pasting.) The difference at issue is loading another 37.6 KB page versus loading whatever part of that 5.9 KB is the "interesting" text (i.e. probably not the header or footer) plus its links and styles and the overhead of whatever you want to stick it in (JSON, an HTML fragment, etc). The huge CSS and JS files are not reloaded every time you go to a new page.
In csh, where using "set" like this would work, you can actually put spaces around the = (go figure).
I'm not aware of () being used for quoting words in any variant of sh or csh.
The idea of implicitly giving it a pair of eyes a few inches apart kind of ruins that for me. Why fake biology if you're ever going to make a jump cut? Most of our visual grammar depends on things actual eyes can't do.
Edit: to be fair, the title of this submission is misrepresenting.
Arial, sans-serif
instead of: sans-serif
at the bottom of a stack. If I am on a platform where Arial looks OK, it should already be my default sans-serif font, right? Currently, I have Arial installed, but I've set my default sans-serif font to DejaVu Sans Mono, which (subjectively) looks better on freetype. But most sites force Arial. It seems like a cargo-cult sort of thing.This problem is worse with monospace fonts (even more subjectively, I am practically allergic to Courier New).
$ host _why.usesthis.com
_why.usesthis.com has address 74.207.245.100
odd.[Edit: Looking at darshan's post below, I understand why: host (part of the BIND distribution) uses its own resolver; everything else goes through the system facility (i.e. glibc). I still don't know how to fix it, though.]
I'd go so far as including a "meta" checkbox next to the reply button, defaulting to the parent's value, which it would be considered polite to set truthfully, but maybe that's just me.
It contains the contents of the .git directory and another copy of the .crx file, inside itself (who knows how many levels this goes down). Actual code (almost entirely jQuery and .psd "source" for the icons) looks to be ~100kb.
Authors, don't do this. git-archive is your friend.