The biggest problem with the spaces vs tabs debate is that editor presentation is still tightly coupled to file persistence. Imagine an abstraction layer created so that developers might choose to see what they wished, yet have files saved in a standard format it might negate some of the issues people have.

That sounds like a really complex solution to a kind of non-problem.

This is great. I wonder if there's a way to package it up for an e-reader, or as a PDF?

This is a great move. Unfortunately it's still in Microsoft Word format and there's no license associated with it. Would love to see this somewhere like GitHub, where it could be forked and changed by others.

I'm guessing it's in Word format because most procurement departments use (and expect a Word document) for terms. But I very much agree, that it'd be great to have it on GitHub for collaboration. I'd even suggest this tool (http://ben.balter.com/2015/02/06/word-diff/) my colleague (@benbalter) made to collaborate on Word docs using GitHub.

That looks good. We're doing something a little more at Documize -- see my comment above.

This +1 There is s huge need for open source documents and ease of collaboration.

I'd like to give this a go, but I don't have a twitter account. How do you see this working for those developers without a social media presence?

We've been using Twitter auth for all of our apps at @makeshiftHQ just out of convenience; some rely on it for core functionality more than others.

In the case of HireMyFriend we put in Twitter auth as a precursor to building a 'secretly DM your friends' feature that hasn't shipped yet.

That said - with an app based around your anonymity but the social presence of your friends & professional contacts I think this would work well for a developer without a social media presence. We'll consider adding email/password sign up in the coming weeks — I'm sure you appreciate how busy launches are :)

Have you considered integrating with LinkedIn as well?

As a complete tangent I'm presently looking for jobs literally on the other side of the world, in a country where I know nobody (so I guess I'm not your target market?). The site used most often there is SEEK. On their own I doubt services like yours would integrate with SEEK or similar smaller international jobs sites. However I'd love to see some kind of social networking standard take off where once you've integrated with say LinkedIn, integrating with someone like SEEK would literally be as simple as swapping a couple of API keys. It'd be even better if the integration could be bidirectional. That is, SEEK could decide to integrate with HMF or vice-versa and whatever features would just "magically" show up on both sites so long as both approved the integration.

Shit, that's kind of like a meta-friend request. "Hey there! My social network wants to be friends with your social network!" Weird.

Tread carefully friends, there's dogma here [1].

I obviously can't answer for the author, but in my own endeavors I've used social auth as a quick fix and said "eh, if it takes off I'll go back and do it right." Chances are the subsegment of his market without a social presence is small.

Authentication and marketing are big hairy problems, especially for people embarking upon small side projects. Social auth can help with both with remarkably small effort on the dev's part.

Edit: Also if you'd really like to give it a shot, having a twitter account doesn't require you to use said twitter account.

Edit 2: Changed tone - "whether you like it or not" is way too confrontational of a phrase to use there - I apologize if I sounded like I was attacking.

1: There seems to be a social auth holy war going on. Your comment was respectful, so please don't think I mean you when I say this, but there's too damn many people saying the equivalent of "OHHH you shitbag! I hate the Facebook/Twitter/other! Why would you force me to have that in order to have your service?" The truth is that it wasn't meant as a personal slight - your opinions just fell on the wrong side of an early-stage tradeoff.

That's really helpful, thanks :)

Techcrunched: http://techcrunch.com/2013/04/01/steam-gauge-gauges-the-size...

You could read all the responses into a Queue-type structure and then populate the database in the background.

Unfortunately, if you're using an Intel-based Mac, the Mac versions of applications are limited to Power-PC machines.

Just this week I was looking for a better solution that would back up my RDS database to S3. I'm currently using mysqldump, but the RDS instance size has grown extremely large and so, it has become unwieldly. Hopefully this will help with that.

It might not be appropriate for you, but a good way to handle MySQL backups is to maintain a mirror. This has the added benefit of being available as a fail-over and as a secondary instance where you can run reports or test long-running queries on current data without the risk of taking prod down.

> It might not be appropriate for you, but a good way to handle MySQL backups is to maintain a mirror.

    DELETE * FROM business_critical_data; WHERE obsolete = true;

You were saying? :D

You can run your daily/hourly backups on the mirror and not impact performance on your main database.

Right. But the grandparent comment was suggestive of the possibility that he or she wanted the mirror to fulfil multiple roles, including being the backup.

The mirror is to run the backups on, not the backup itself.

CHANGE MASTER TO MASTER_DELAY = 3600;

Your slave will always be 5 minutes behind the master. You were saying?

If this is your tactic, I'd think the binary log would be the winning way to rollback a bad delete.

Well, with a functional mirror to run manual queries against, you wouldn't be running the risk of running such a query on your prod DB anyway. But yeah, you still need a dump.

There's lots of disaster reports that start with "shouldn't" and "normally we wouldn't" :)

http://www.taobackup.com/

Thanks, I've already tried that. My main issue is EBS performance when writing the dump file to disk. The backups themselves don't impact on database performace much, but writing up to 20 Gigs of a dump file to an EBS disk on a nightly basis is extremely slow. Maybe this Data Pipeline service will help bypass that.

Have you tried piping the dump directly to a compression tool? We use pbzip2 for our dumps which works great if you have some CPU power to spare. The largest was around 8 Gigs uncompressed, but the total size of the plain text dumps is over 20 Gigs. Hardly an issue for EBS that way. Did kill the DB for a few minutes several times before using cstream to cap the dump bw.

Have you set up Provisioned IOPS for the volume?

If you've seen the movie, I'd highly recommend "Moneyball" the book too. It goes into a lot of great detail that the movie doesn't deal with.