mpd

Did you read the article? 1.9 will keep oldIE support, get minor updates, and be API-compatible with 2.0.

I'm honestly chuckling at the thought of Linus responding to this one in Rasmus' place.

If you need the features of an old version, use the old version. Simple as that. Don't expect the rest of the world to be stuck with dealing with backward compatibility just so you aren't inconvenienced. Upgrade, pay for support, move to another platform, or stop complaining.

For making changes on the mud itself, there was no other way to write code unless you were an admin and had direct machine access.

There are some vi-like mud editors out there, but they were always wonky when I tried them, and caused more problems than they were worth (weird screen redraws, keys stopped working randomly, etc.). That said, I believe Dead Souls mudlib[1] may ship with one now, but I haven't looked at the lib in a few years, so I can't say for sure.

[1] http://dead-souls.net/

EDIT: link to dead souls FAQ entry on this topic: http://dead-souls.net/ds-admin-faq.html#144

Yes, but even serializing data at the key level in redis to do it yourself is painful. With 2.6.0, redis provides dump[1] and restore[2] methods which will go a long way to alleviate this, but that version is still in pre-release status at the moment, and was not available at all last year when we had our issues.

[1] http://redis.io/commands/dump [2] http://redis.io/commands/restore

I'd love to know how it handles adding new shards. Migrating redis data from one shard to another has been a major pain point for us in the past, and has caused us to move away from redis for any big data needs we have where growth can't accurately be estimated.

I was a MUD coder in a past life (and sort of am still); learning ed is essential for that environment. I'm glad I learned to use it, and gladder still I don't have to use it every day.

It's great for quick fixes and one-offs, but having to engineer with it is rather unpalatable.

You're welcome to peruse the mailing list thread.

http://lists.basho.com/pipermail/riak-users_lists.basho.com/...

Yes. I should clarify that I meant 500k keys used in a single m/r job. We needed to be able to run m/r over roughly 200 million keys at the time.

I investigated using Riak for dealing with our metrics a few months ago, but with the data sizes we are dealing with, even the Riak people told us that Hadoop was likely a better solution.

Once you are dealing with more than 500k keys or so, Riak starts to fall over.

EDIT: The 500k key limit pertains to mapreduce jobs, not the overall data size.

There's some editorializing in the title here. The ban only covers two buildings, and any phone that allows them to add the monitoring they require (not just Android phones) would be acceptable.

Please update your TOS to explicitly define what 'reasonable disclosure' is. I'm a paying customer and this comes off as arbitrary.

I just signed up. Will check it out later today.

I did notice a couple of misspellings: enrol -> enroll, enrolment -> enrollment

This is only true if 'ambiguous' is synonymous with 'exactly matching my own criteria'. Usually, it isn't.

Others' opinions are a litmus test that saves me a lot of time in the long run. I simply don't have the bandwidth to go deep on everything that hits my radar.

This assumes anonymous is a unified collective, when they are really much closer to a flag of convenience.

I used osx gcc installer for a bit, but had to go back to xcode when I needed things like opengl headers, which are not otherwise available. Frustrating, for sure.

Having dealt with the Selenium and its frustrations in the past, I tend to outsource this sort of testing if at all possible. Some things can only be truly tested with eyeballs.

One tip I do have is to disable jQ animations during your test runs so you aren't having to jump through hoops in your test suite just to wait through animations -

jQuery.fx.off = true will do that.

My heuristic is developer estimate x 2 + 2 weeks for anything of substance, just based on my own experience and managing others.

Absolutely. A record of solid past work can help overshadow a poor interview (nervousness, etc.) in my eyes.

If I can see the sorts of things a candidate has worked on in the past, I can more tailor the interview and ask more engaging questions. I want to know what they're passionate enough about that they will give up free time to pursue it.

None of this is specific to Github.

The project looks dormant right now. There have been no changes in months; no release in over a year.

direct link: http://retrospectiva.org/overview

Stipple is looking for an engineer. San Francisco, local only. http://stippleit.com

We do Rails, jQuery, and TDD. Lots of Javascript. We write our own CSS (with SASS/Compass). We move quickly by exploiting the best tools we can find.

You would be the #2 engineering hire, and would work with myself and our other engineer.

Our awesome office is in South Beach, close to AT&T Park. I'll tell you the story about it when you get here.

Please send resumes or questions to mpd at stippleit.com, and include HNJOB in the subject.