Responses to people who insist on using Tumblr

Lazy devops config recoverability with mercurial

makingwoome:

At Woome we often suddenly create a new set of key information, such as a regularly changing nginx config. We use mercurial extensively, so the typical next step at this point initialise a repo for the data set and check everything in. As a team we’ve trained ourselves to check in changes to most admin data sets automatically, with a ticket number in the comment, so this is very nearly self documenting change tracking with easy rollback.

Now, that gives us good change accountability and recoverability however it does tend to leave us with mercurial repos littered around the infrastucture slowly becoming more and more important. What we now do is auto-locate these repos and publish them to a central box for hgweb access presenting us with a rapid bare-os recovering in the case of hardware failure. 

Read More

This sounds similar to our workflow at DevStructure, only we use Blueprint and Blueprint I/O to automate things a little harder. I’d love to hear what you think about these tools, Woome engineers.

(Source: makingwoome)

A note on OpenClip

cowsandmilk:

marco:

Using this, an app can read any saved authentication information in any other apps — for example, an app could steal your Flickr API key from any other apps that you’ve trusted with access to your Flickr account. Or an arbitrary app could read saved passwords from a password-manager app.

I don’t think it would be possible for another app to steal your app’s access to Flickr.  Your secret key would be hardcoded in your app and short of some magic crawling through the binary, noone could send a message as you, even if they had your api key (easy to get for an app as it’s clear text in your POST/GET) and they pulled the user auth_token out of your app’s data directory.  (Hopefully Richard will correct me if I’m wrong about this).

As for a password manager app, God help you if your password manager is storing stuff in plain text.  OnePasswd sure doesn’t.  And if the iPhone has Keychain, noone with a brain should.  In fact, if the iPhone has Keychain, hopefully your app accessing Flickr put the user auth_token in there.

Richard Crowley: man strings
David Hall: I knew there had to be a way to do that
Richard Crowley: however
Richard Crowley: run strings on the flickr uploadr’s binary
Richard Crowley: and you’ll find no api secret
Richard Crowley: Richard 1, strings 0
Richard Crowley: char secret[16]; secret[0] = ‘7’; secret[1] = ‘a’; …..
Richard Crowley: strings works by dumping the .text segment from elf binaries
Richard Crowley: so doing the character-by-character thing effectively hides it from anything that isn’t actually executing your code
Richard Crowley: you could certainly still get uploadr’s secret via gdb or some other debugger
David Hall: alright, well, that still is nice to know you can make it annoying for people to get it
Richard Crowley: yessir

cowsandmilk:

marco:

Nice people at Slicehost.

AMEN!

Alas, they’re not Wash U kids. Still rockin’ service, though.

halle:

with dr. sanjay gupta and lance armstrong

I’m very jealous Halle got to meet Lance Armstrong.  I’m watching the Tour de France right now, actually.

halle:

with dr. sanjay gupta and lance armstrong

I’m very jealous Halle got to meet Lance Armstrong. I’m watching the Tour de France right now, actually.

The UUID vs. the Integer

cowsandmilk:

In the world of distributed systems, integer indexes are left behind in favor of UUIDs.  Since there’s no shared counters between two unconnected systems, this is a great solution.

I think that the UUID in general is better than integers though for indexing a relational database for a couple reasons:

  • There are millions of pages on the internet about autoincrementing of database indexes and Postgres serial vs. MySQL auto_increment and a whole bunch of balogna about how to get your index.  If you just create a UUID in your app and use it, you avoid all that bull.
  • Security is much improved.  I mean this in two ways.  There is the classical incrementing of numbers to get to the next blog entry or photo album or whatever that is supposed to be private.  UUIDs have long been used here.  But let’s say you have a permissions to user table.  And someone figures out a sql injection that lets them put in their userid and a permission id into the table.  If your permissions are indexed on a UUID, they’re just stabbing in the dark trying to get a valid, useful permission.  They’ll probably need to do enough stabbing that you’ll notice the attack and shut them off.  (This assumes the sql injection doesn’t let them read from the permissions table).
It might not be traditional, it might have implications on the speed of joins (number comparison vs. string comparison? well, they should just be a bunch of bytes, so no big difference? well, the string is probably many more bytes…), database size, and other performance issues, but I think it’s well worth it.

The speed thing isn’t really an issue since you’d probably store the data in a fixed-width binary format which will be plenty fast. The issue is disk use. 128-bit UUIDs will mean more disks and very quickly more servers. Ted wrote a bit about this the other day. (Pay no attention to the base64 distraction at the end.)

The culture of free, seductive as it is, is destructive to everyone involved. Everyone is undercutting everyone, until nobody is making a profit. At best, the winner is the group that can survive off of (usually meager) ad revenues.

Matt Maroon: Bubble 2.0 (via marco)

My fear is the destruction of software innovation as I’ve written about before. (via kyleshank)

The important place for innovation in an increasingly ad-driven web is in increasing the signal-to-noise ratio. I think services that bring in direct revenues are the ideal but the second-best are those services that use advertising and markets to enhance experiences rather than exploit members.

kyleshank:

Whats wrong with the beer we got?  It drank pretty good don’t it.

Watch from 5:20 in.  This is an actual session from the Alabama state House on the alcohol content of beers.

Danville, Kentucky went moist* in 2004 and it was quite a fight. The Baptists came out in force against it but we beat them back with our economics stick.

* “moist” in this case means that restaurants that seat more than 100 people and make at least 70% of their revenue from food sales can serve beer, wine and liquor. One restaurant was nearly pressured out of business because of its “bar-like atmosphere” though it was meeting those numbers easily.

kyleshank:

Feeling the new Coldplay.

Myself, I’m rather obsessed with the title track.  It’s embarrassing — I have a feeling my neighbors have heard it on repeat.

kyleshank:

Feeling the new Coldplay.

Myself, I’m rather obsessed with the title track. It’s embarrassing — I have a feeling my neighbors have heard it on repeat.