mpd

I switched back to Mutt a few months ago after trying Mail.app (filtering wasn't up to my requirements, would hang often) and Thunderbird (bloated and slow under load). It's been a champion.

urlview.sh is pretty awful, mis-parsing urls constantly for me. I then discovered extract_url.pl[1], which is much, much better.

offlineimap likes to hang randomly - mail just stops coming in and the process never stops, requiring me to remove the lockfile by hand, then kill the process. I haven't found a replacement for it, unfortunately. Definitely open to suggestions on this front.

The linked view_attachment.sh file has problems, for example, with files with multiple dots in the filename (among others). I have made a few tweaks[2] to it to make it more robust. It still has a few issues, but I've found it to work better for the most part.

msmtp is probably unnecessary nowadays if you have a typical setup. For GMail, add the lines:

  set smtp_url            = smtp://your@email.com@smtp.gmail.com:587/
  set smtp_pass           = mah_password

to .muttrc and you should be ready to go.

I also wrote a very small, crappy applescript launcher to launch an iTerm with mutt from the OSX dock[3]. It won't open a second copy if already running, but I haven't been able to figure out how to display a badge on the dock to denote unread mail. It may not be possible.

[1] http://www.memoryhole.net/~kyle/extract_url/

[2] https://github.com/xxx/dotfiles/blob/master/osx/mailcap/view...

[3] https://github.com/xxx/dotfiles/blob/master/osx/mutt/mutt-it...

Mixpanel had some downtime 2 days ago, from 22:59 until 23:23 UTC according to our error logs. It might have only been for API users, but downtime nonetheless.

It's certainly possible it was scheduled, but it's not clear where that downtime is announced if so.

It looks like you want to leave detailed logging off...

Very nice. This brought back some memories of something similar I wrote many years ago[1]. I don't even dare look at that code now :)

[1] http://freecode.com/projects/decked

In my experience, Opera gets significant usage in non-English-speaking countries. I read at one point (several years ago, so grain of salt) that 25% of Russian users were using Opera.

That said, our own traffic shows 0.80% Opera users, which puts it just above RockMelt. It's silly to actively filter them out as MySpace is doing here, but would be equally as silly (for us at least) to devote any resources to dealing with any Opera-specific issues, until the usage stats justify it.

That isn't official documentation as far as I can tell, though. I don't think I should need to read 5 chapters into a separate book for something so seemingly fundamental.

IMO, this is important enough information that it should be mentioned from the start, but it isn't in the tutorial[1], nor can I find it in the FAQ[2].

[1] http://www.mongodb.org/display/DOCS/Tutorial [2] http://docs.mongodb.org/manual/faq/

Honest question - where would someone with no Mongo experience typically discover that?

And Erlang got that from Prolog, which certainly could have taken it in turn from something even earlier.

I wish they would spend resources on being as fast as they used to be. Pushing and pulling has become slower and slower over the past couple of years.

position: fixed is quite broken on IOS[1]

[1] http://remysharp.com/2012/05/24/issues-with-position-fixed-s...

Using semicolons or not in javascript is just another holy war a la vim vs. emacs, apple vs. google, etc. You'll find people who are passionate on both sides of the fence.

What about old versions? Taking the jQuery url, and changing it to the version previous to the newest release (1.7.2), 404s on me. This is a showstopper.

http://cdnjs.cloudflare.com/ajax/libs/jquery/1.8.0/jquery-1.... - ok

http://cdnjs.cloudflare.com/ajax/libs/jquery/1.7.2/jquery-1.... - 404

I'm curious where Standard Oil would stand had it not been broken up.

Oj[1] benchmarks significantly faster, but I'm not clear if it's usable outside of a Ruby environment, as I am not aware of any non-gem distributions.

[1] http://www.ohler.com/oj/

Code maintenance isn't free. An unmaintainable codebase can easily kill a project after awhile.

I think I still prefer http://www.dailyrotation.com/ . Looks great, though.

Yeah, that's one of the first steps if a selection benchmarks slowly. I just dislike adding complexity in any form. It adds up so quickly in complex software.

It's a small difference, but these small differences version after version add up to a lot of nickels.

As I mentioned in another comment, increasing performance for ID selection (which is already much, much faster than other types) at the expense of other types makes for sexy benchmarks, but is less than stellar in the real world.

I'm seeing the same but because ID selection is already 2 orders of magnitude faster than any other type, the net win here is significantly reduced. The rich are just getting richer.

I use class selection most often, so any slowdown there is a cause of concern for me. The other slowdowns are not as big of a deal, providing it means speedups in more important places.

According to a few runs of this benchmark, a number of these tests are slower in 1.8, particularly selecting by class. That's rather off-putting. I hope it's just me.

Using Chrome 21.0.1180.57 on OSX.

Looks interesting, but I can't seem to find a list of supported browsers. Am I just blind?

thanks!

Working in, and having lived in SOMA, I'll take Burger Joint over either of those. I'd almost take McDonalds over Brick House.

Little Skillet now has a burger as well that's not bad.

Stipple went with Rails for the sole reason that we were able to iterate and release very quickly in the beginning when I was the only one coding on it, and my expertise is in Ruby and Rails.

We're now heavily Backbone-based on the frontend, however. You should use what you're most comfortable with, as being able to iterate quickly is most important at the start of a project.

As mhd says, the backend is really more important. We're using MySQL, Redis, Cassandra, and a custom Erlang/mnesia based store in ours.

(full disclosure - I'm Stipple's co-founder and CTO)

There as a similar reaction > 10 years when Hotline was released for Windows after being Mac-only for a number of years.

and XMLHttpRequest came from IE. Do you see where I'm going here?

The important metric is how much of a chunk they are to your business. You shouldn't care if some other site (or all other sites!) have significant traffic from such old browsers. Measure your traffic.

Then they will be left in the past. It's unreasonable to expect me to hold my own product back because of lazy corp IT depts.

Unless they are contributing more revenue than it takes to support them, screw them. For me at least, this is not remotely the case and I'm happy to leave them in the dust.

Unless users of oldIE versions contribute more revenue than it takes to support them (which is obviously app/site-specific), screw them. It's simple economics.