robconery's comments

OP here - many NoSQL/document DBs will trade off write acks for eventual consistency. I really liked their approach to pushing toward durability by default - that in particular was the thing that impressed me, which I should have been more clear about.

I think experience is one thing I'm not short of.

Nope - been at this for 24 or so years now. I wish I was an "underclassman" again - everything was quite fun back then... which I suppose is the point of the post which sort of sailed over your head :).

The feedburner feed was spelled wrong (fedburner)... that was sorta dumb of me, sorry!

Yikes! Fixing - wow that's not good...

OP here... I should say that I wrote this post rather late with a glass of wine in my hand and perhaps didn't use all the exact words to convey my point clearly. But let me address your points.

"Thinking too much" seems to have hit a button for you; sorry about that. I do think this is a pretty common thing: The Paradox of Choice. That's sort of what I am feeling as I know quite a few languages and frameworks, and it's difficult for me to stop diddling over "what should I use" and just write it.

I've spent my career creating things - I haven't created a language yet and to be honest I don't think I have the ability to do so. Not sure what that has to do with my point, but OK.

Also - thank you for the new Twitter bio. You've motivated me to be a better person. I shall never forget you Mr. 5-day old HN account...

You, on the other hand, are amazing.

The entire post is satire. Guess you missed that.

The post is satire of sorts, although in the course of writing it I found such a common cause with Yehuda it was crazy. His pain learning Vim was my pain learning Ember. And the payoff is just as fun (to me at least).

Read this post here: http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...

And hopefully you'll see the genesis of the post.

OP here - this post is almost a year old and I don't know why it got pushed to HN again. It's taken a year :) but I think I've come to finally understand Ember... and I very much like it.

Yep - hi Trek :). I don't know how this got pushed to HN again but there will be a followup. I'm wondering if it's coincidental :)

In 2001 - 2008 there was no ASP.NET "WEBFORMS". We had VS, CodeBehind, and Server Components - that was the world I lived in.

Yes, Alt.NET came along in 2009 or so and managed to do some good things, not soon enough really and all the silly flame wars actually did more harm than anything.

They were lost in that nothing I did with ASP.NET (not MVC) has translated to what I'm doing today. No patterns, no habits, no tooling, nothing. COBOL/FORTRAN are languages and I'm not sure they correlate here - but maybe top-down design ripples still? :):). I learned a lot in Pascal - mostly how to comment things :)

No worries - good comment :). What I meant by "all-in" shouldn't be taken as "in total". In other words: in all the projects I worked on, only ONE TIME did I get to use MySQL. I installed Ubuntu once for fun - but when it came to work and what I did for work - it was MS all the way down.

These were choices made by my contracts and my employers. What you're saying is valid: I could have pushed to use another system or platform. I can do this now - but back then it was not nearly as easy to just pick up and learn the intricacies of different platforms. You might disagree, it's sort of subjective - but installing PHP/MySQL was a complicated affair if you're not familiar.

Finally - the whole premise of the post was the very question itself: "Did I do the right thing?". I was questioning, and I had to make a choice. I constantly did (and still do) that.

That's a given, and it's what I did. It's not the time that's in question, it's the choice of what to learn.

Every choice you make impacts you today. What you learned in high school, college, and at your first few jobs all shape who you are and what you know. If I wouldn't have spent those years in ASP.NET. I know programming, have the same skill set as you pretty much (no Python). I would have loved to be increasing my Ruby/JS skills during the "lost years" doing ASP.NET.

OP here - I've made quite a few choices but this (as mentioned) was a pivotal one - and yes I wonder if I did the right thing. The MS ecosystem is very insular, so once you go down that road you're "all in" - so the choice wasn't a casual one at all.

True - but the backend analytics system can be Excel :) which it often is. In fact in my "two person startup" (that was alive happily for 5 years) this is exactly what I did :). I do take your point, however. I still think it's wise to not have an admin backend that runs rollups on your live system (which we've all done).

Completely agree here. Your live transactional system needs to export reportable data - this can come in the form of a DB backup/download (which I've done many times) so you can run queries locally or by pushing CSVs using a cron job.

You can use a SQL query for this or a simple map/reduce - either way my argument is to focus on transactional design that works best for your system - don't conflate reporting needs with your live system (i.e. BA queries).

One thing that could likely get you fired rather quickly is running analytics on your live transactional system. Yes, your business needs to make decisions based on data, this is not terribly new. To think that you only have one data store is a bit short-sighted.

Many businesses (including startups) have moved to using document stores for high read environments and scraping nightly drops to their backend analytics systems. This is smart - you don't want to run summing/aggregation on a live transactional system for (hopefully) obvious reasons.

EDIT: it's also worth noting that map/reduce is typically much more powerful when aggregating large datasets. When trying to run analytics on top of a transactional system, developers like Ray here would end up with multiple joins and groupings - all of which slow everything down. Map/reduce certainly isn't perfect, but the author dismisses it as difficult witchcraft when, in practice, parallel execution of MR queries can greatly decrease resources and time to information.

I sort of think we've moved beyond this discussion.