geweke

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.

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. ;)

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.

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.)

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?

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.

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.

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... ;)

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. ;)

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