YES. Everybody deserves this. As a manager, I try extremely hard to make sure this happens.

The way I think of it is this. On the day you are fired, when you get called in a room, if I ask you, "why do you think you're here?", you'd reply: "I think I'm getting fired". Because I want us to have had so many conversations about it, and been so direct, that the actual firing is incredibly unsurprising.

I think any manager owes this to their employees, as a matter of basic human decency.

The new fire fast mentality being pushed is not for performance though. It is you are a rockstar at X, but now we need X+1, you're fired. Basically companies are starting to treat full time employees as contract employees without paying the increased contract rates.

Exactly my point, and I'm ok with that if they're up front about it and they give me some lead time on when X+1 is happening.

Personally I'd prefer a place where I could do X and X+1 so it'd be a bit of a negative in choosing where to go, but I can live with it. OTOH I'd be extremely pissed if I walked in one day and was told "we think you're awesome, but you don't konw X+1 so see ya later"

The problem is, these companies are being run by people who can't tell the difference between X and X/10, let alone X and X+1.

But they think they can because they got VC money and they are high on their own fumes.

Fire fast if someone is clearly not a right fit, but "Fast" should be after giving them plenty of warning.

Absolutely agree, it's just that it doesn't always happen. I tell every new boss that I'll be completely upfront w/ them regarding my thoughts on how things are going, if I'm thinking of jumping ship, etc - but in return I expect them to do the same.

Ideally both sides are on the same page at any point of time as to what the situation is.

Wow. I would never say I was going to jump ship until I had my plans set out. In the past I've given 6 weeks notice when it was asked for but I just wouldn't put myself in a situation where they might fire me before I fund my next gig.

There's a difference between saying "I'm jumping ship" and "I'm thinking about looking around in the next few months". The former is implying it's definitely going to happen, the latter is saying that it's a fungible situation.

I'd like to think (and try to only work for) people would be professional enough on both sides to realize that not everyone (either side) is going to be happy 100% of the time but a) both sides can work on it to make it better and b) if it doesn't work out, try to be supportive of each other so that both come out stronger overall.

It still sounds sketchy to me. Threatening to leave is giving your employer an ultimatum. Personally, I think the rational response to this is to placate you, find your replacement, then fire you. If you actually have issues with your work environment, you should address those head on without the threat of leaving the company.

What rebelidealist said. In the talk, I try to be pretty clear about what kinds of data are a good case for this kind of storage and what aren't. (In short? Data you only ever retrieve for a single row at a time, and that you never query on. Also, you really need to store it in a separate table that's 1-1 with the main table, or all you've really done is bloated the original table and made things worse.)

My own experience is that there's actually more data than you'd expect that can fit into this model. On the other hand, I am absolutely not pushing this as a panacea: if you don't really know what you're doing, tossing JSON in a RDBMS is probably a really, really bad idea. After all, that's part of the talk -- to discuss when it's a good idea and when it isn't.

(I personally think the low-card tables part of the talk -- http://github.com/ageweke/low_card_tables -- is the most interesting idea.)

Thanks for posting this. For what it's worth, I'm the author of this talk and the one pictured in the video.

I'm flattered it's getting so much attention (I like having my ideas spread!), although there's one thing that confuses me. I've never heard of Hakka Labs, nor did I post the talk, video, or my bio on their site (although their treatment sure looks like I did) -- as far as I can tell, they grabbed it from the site of the SFRails Meetup at which I gave it and posted it online. I'm grateful for the exposure, but some notification or clear notice that I'm not affiliated with Hakka Labs (whatever/whoever they are) would have been nice.

Hi Andrew, I'm the founder of Hakka Labs. We had permission from the SFRails meetup orgs to record/post the talk, but I honestly apologize if this was unknown to you. We don't consider this 'our' content in any way, and we're happy to make it freely available for the benefit of engineers everywhere.

Thanks so much for replying. My concern wasn't about permission -- I'm far from protective of my talk; hey, more distribution is great! -- so much as it was the appearance of the site. (And even the video -- you overlaid your logo on every frame of the video.)

To me, http://www.hakkalabs.co/ looks a great deal like a blog. When I see a blog -- particularly with a name and photo of the author on an article -- I naturally assume that author either created that content specifically for that blog, or authorized/contributed that content specifically to that blog. If that's not the case, I think the blog needs to make it very clear that they are republishing content taken from elsewhere, without the author's knowledge. There's nothing wrong with that (assuming you have permission); it's just about making it clear that that is what's actually happening.

(Underneath, it's about the perception that I am somehow "contributing to" or "endorsing" Hakka Labs by posting content I created there. I'm not saying anything bad about Hakka Labs at all -- I simply don't know enough to judge either way! -- but IMHO it's not cool to create that perception without the author's knowledge. It'd be like a startup GitHub clone suddenly hosting my open-source code under an 'ageweke' account with my name and photo: while they absolutely have every right to do that according to the licenses involved, it gives the perception that I'm a user of their site and uploaded my code there...when, in fact, I've never heard of them before.)

Anyway, don't want to derail this technical discussion any further; feel free to reach out to me directly over email if you want to chat about anything else. You certainly have my email address. ;)

It's not Django, but I've built something quite similar for Rails, and have really loved using it. The combination of RDBMS stability and the flexibility of schemaless content is really powerful -- it is (IMHO) the best of both worlds.

Would love to hear people's experience with this kind of setup (no matter what software you're using)...I think it's a very interesting, and useful, direction to go, especially for new projects where you may not want the overhead of multiple storage systems.

https://github.com/ageweke/flex_columns

I'm more than happy to answer any questions about this gem. It was built as the result of ~2+ years using Mixpanel intensely with Rails, seeing the scaling challenges that result, and then tackling them. I'd love to help anybody else make their Mixpanel implementation better, too. (And, no -- no affiliation with Mixpanel whatsoever beyond being a happy client.)

Just wanted to say that this looks awesome; I'm going to try it out right now and will definitely be in touch.

Nice! Thanks for turning me on to that -- I've been looking for something like that.

I actually think they're pretty different problems. WebServerUid is about uniquely identifying a single browser over hours, days, months, or years, while X-Trace is about tracking a single request over its (hopefully) single-second-at-most lifecycle -- but they're both really useful, and I'm glad you posted that link.

I'm the author of this gem -- more than happy to help out with it.

The problem it solves is small but important, and this is now the third company at which I've solved it...so I'm sure there are more folks out there dealing with this same issue. ;)

This is cool, thanks for building this.

Besides analytics, seems like this could help SaaS products that want to offer a trial or demo without ever creating an account up front–just spin up an account on the fly with the uid. If they actually signup, marge their real info.

I'll definitely be trying this out.

Sure thing -- I built it because I needed it, but I'm really happy to be able to share it, too.

You definitely could use this for trial/demo accounts, too. You'd want to think carefully about abuse prevention, I suspect, but in the right circumstances it could be a really lightweight way to handle this.

And now you never need to solve it again! :)

This is a good technique to know. I feel like that cookie should be HTTP only though. It looks like nginx doesn't support that out of the box.

Really good point. Even better, I'd really like these cookies to be digitally signed (like Rails' session cookies are by default), so that they're unforgeable.

Seems like it wouldn't be too terribly hard to add to nginx...hmm... ;)

They should be secure random strings, no need to sign.

BTW, rails signed session cookies are terrible from a security perspective. Thank god Github has moved away from them.

What, in particular, is problematic about them? Do you mean their particular implementation, the fact that they aren't also encrypted, or the general "password equivalent in a cookie" concept overall?

Yeah, the one ring to rule them all problem. One bad employee, or one of the many rails zero-day issues, potentially compromises the site indefinitely for all eternity.

Nice, Steve! Always good to see validation of the idea in both directions. :)