smerritt

Agreed, especially about simplejson. I work on a project that uses simplejson, and it leads to ugly type checking all over the place because you never know what your JSON string got turned into. For example:

https://github.com/openstack/swift/blob/39c1362a4f5a7df75730...

and https://github.com/openstack/swift/blob/39c1362a4f5a7df75730...

and https://github.com/openstack/swift/blob/39c1362a4f5a7df75730...

and many more just like those.

The worst part is the bugs that appear or disappear depending on whether simplejson's speedups module is in use or not.

I'd love for them to do that, but there's a couple of problems that they'd have to overcome first.

First: Slackbot. This is a Slack-run bot that's in every channel; team owners can customize it to do various things, like scan messages for keywords and give out canned responses. Even if Slack adopted some variant of encrypted chat, each message would still need to be readable by Slackbot, so Slack would still have the means to collect every message.

Second: channel history. When I join a channel, I can see the messages in that channel from before I joined. This means that Slack (the server) must be able to give me those historical messages. In an encrypted group chat, the messages are encrypted only with the keys of the participants at that time, which means newcomers can't read them.

I'm sure there are other features in conflict with end-to-end encryption, too; these are just off the top of my head.

Any limits on the number of metrics or metrics/s?

Given a sufficiently large monitor, it's fine. I (Emacs user) routinely pair with a Vim-using coworker; we just put Emacs on one half of the screen and Vim on the other.

The only thing you need after that is for both editors to automatically refresh when a file changes on disk. With Emacs, you can get that with "(global-auto-revert-mode 1)" in your init.el. You can make Vim auto-refresh too, though I'm not sure how.

Probably the best way to get started is to grab an Emacs 24 pretest and use technomancy's Emacs Starter Kit: https://github.com/technomancy/emacs-starter-kit

Emacs 24 gives you a solid package manager, and the starter kit gives you a good solid spot to build on.

From there, install the packages you want. If you want haskell-mode, just M-x package-install [return] haskell-mode. Get the full package list with M-x package-list-packages.

Absolutely true. The RAID controller would randomly lose drives and the driver for it would randomly cause kernel panics. We tried different firmwares and different kernels and made some progress, but never really got it stable under load.

However, that's the risk you run with single points of failure. Put all your data on one big box, and any failure in your RAID hardware, RAID firmware, RAID drivers, network drivers, kernel, RAM, OS, et cetera will take down the big box and thus take down anything relying on it.

The lesson I learned wasn't to make a super-robust single system, it was to have enough redundancy to stay up when something inevitably fails.

We had something similar but smaller (~8 TB) at a place I worked, and it was a nightmare. Migrating from that to S3 was one of the best things to happen to that project.

Being a single big box, it had a bunch of single points of failure, and boy did they fail; we probably had 5-10 hours per month of downtime due to the photo server falling over (flaky RAID controller firmware, mostly).

Also, since the big box was expensive, we only had one in production. There was code for taking a newly-uploaded photo and copying it over to the photo server that only executed in production, which meant the only way to functionally test it was to ship it and hope.

We switched to S3 about a year ago with different buckets for prod, staging, and dev; the production-only code paths went away, and there hasn't been any photo-related downtime since. Definitely worth it.

I voted for option #3; I recently tried to work with a technical recruiting agency, and based on my experience, I don't plan on ever doing it again. They were a bunch of email-phobic telephone-happy people who just flung every job in their database at me regardless of what I told them I wanted. A simple keyword-matching algorithm would have been an improvement.

The long version:

It started with a phone call one day; I was very discontented at my (then) job, and I'd contacted a couple of companies on my own already. I got a cold call from a recruiter, and instead of my usual please-go-away response, I decided to see how working with a recruiter might be. I'm already job-hunting; what's the worst that can happen? So, I asked this person (call them Alice) to please email me over some information about jobs they knew about that fit my skill set, and then I hung up.

The next day, instead of an email with jobs in it, I got an email from Alice asking to set up another phone call. I wasn't too happy about this, since I worked in a small, open-plan office and there was no place to make a quick phone call without being overheard, and I didn't want to open that can of worms with my (then) boss. I explained this, but Alice insisted on a phone call, and I caved in.

A few days later, I phoned Alice from a nearby coffee shop (for privacy from my boss). We went over my resume, which was online already; we talked about what kind of jobs I wanted, which I had said before in an email; and Alice said she'd forward my resume on to her colleagues.

Now, I'd thought that since Alice was a recruiter, she'd forward my resume to people with open positions to fill. Not so! This recruiting agency had two parts; recruiters like Alice who went out and found candidates, and other recruiters who worked with hiring managers. Alice had just forwarded my resume to all the hiring-side recruiters. The next morning, by the time I got to work, I had emails from Bob, Carol, Dave, Edna, Fred, and George. Each email talked, in the vaguest possible terms, about "exciting opportunities" with "awesome companies". And each one wanted me to set up another damn phone call.

As if that wasn't annoying enough, four of them had also left me voicemails telling me that they'd sent me email asking to schedule phone calls. In case I'd forgotten how to read, maybe?

Bob wouldn't talk via email; I tried, but he just wouldn't do it. I told Bob that I wanted a job that let me telecommute a day or two per week; he told me that no really profitable company ever let its employees telecommute, but he'd dig around his B-list and see what he could dredge up. Gee, thanks, jerk. Strike one.

Carol also wouldn't talk via email. I told Carol that I wanted a job that let me telecommute a day or two per week; she introduced me to a hiring manager who said, in no uncertain terms, that telecommuting would never happen on his team. Strike two.

Dave would use email, but he kept sending me job after job with no relation to my skills or what I was looking for. Strike three; I'm out. The rest of them were no better anyway.

In the end, it was a big waste of time. Every job they sent me was also posted on the company in question's web site as well as Github Jobs, Craigslist, or some other job board. All the recruiters did is burn up a bunch of my cell minutes and raise my blood pressure.

(Happy ending: I wound up finding an awesome job by talking to some former coworkers of mine.)

> Does 911 work different for cell phones?

Yes, it does. Calling 911 from a cell phone connects you to a big regional call center that gets your location and transfers you to your local one, whereas calling 911 from a land line connects you to your local emergency call center immediately.

Also, calling 911 from a land line gives the dispatcher your address. Cell phones will send along your location if they can get it, but GPS doesn't work too well indoors, and tower-based location can be off by tens or hundreds of meters.

There's two flavors of monthly data cap.

I have a Linode with a data cap of 300GB per month; if I use more than that, I pay a reasonable amount ($0.15/GB) for the excess. So if I use a lot of data one month, I get a charge on my credit card, and life goes on. I'm completely comfortable with this.

A residential Comcast connection has a data cap of 250GB per month; if I use more than that, they turn off my connection and ban me for a year. So if I use a lot of data one month, I find myself abruptly and semi-permanently screwed. I am absolutely not comfortable with this since the consequences are so severe and long-lasting.

Sometimes both programmers just keep using their favorite editors.

At my last job, we had a more typical pairing setup with one machine (27" imac) in the middle of two programmers. When I paired with a non-Emacs user, we'd put Emacs on my half of the screen and their editor (usually Vim, occasionally Textmate) on their half.

The only caveat is that you have to make sure your editor will refresh files when they change on disk. That way, when your pair saves a file, your editor reflects the changes.

Textmate does this automatically; in Emacs, you may have to put

  (global-auto-revert-mode 1)

in your init.el, and there's some Vim setting you can tweak to get the same behavior.

The main downside is that you can only fit half as much code on the screen, but this can be mitigated by using a sufficiently large screen. In my experience, a 27" display is sufficiently large and a 24" is pretty good, but anything smaller starts to feel cramped.

As an Emacs user, I've never found Emacs-ish keybindings in other applications to be helpful. Take Textmate, for example. Its default keybindings are a little bit Emacs-ish, and they're just enough to lull me into a false sense of security. Control-[f,b,a,e] do what I expect, but as soon as I try to go forward a word (Meta f), the Find dialog box pops up and steals focus.

In applications that don't try to emulate Emacs, I get slapped on the wrist the first time I try an Emacs command; it's immediate feedback that "hey, bozo, this isn't Emacs".

This is the default behavior in Emacs 23.1.

Most of the time, it makes editing text easier, as one would expect. The exception is when using a keyboard macro to do something to a bunch of lines. It's common for such macros to have a form like

1) start at the beginning of the line 2) do stuff to the line 3) go to the beginning of the next line

When the navigation commands take line wrap into effect, you can wind up with a macro that gets run once on short lines, but twice on long lines.