bemurphy

> The surgeon's office later told her that he belonged to two different medical groups. One was in Morgan's husband's health plan network, the other wasn't.

I got this one, it was mindblowing. For ER work, they'd bill through one practice, for scheduled appointments, another.

I got balance billed for $11k. My father, who worked in employee benefits for over 30 years, couldn't even figure out what was up at first. Then they filed to send me to collections because I kept refusing to pay (note, I'm in California and this billing is illegal for life-threatening emergency visits matching the situation I was in). Finally, the insurance company stepped in and covered me, but we were only able to achieve this because my family knew people personally at the insurer.

All kinds of messed up.

I'm with you on option 4. I used to spot a movie I wanted to see, and then see it. Now I want to see a movie, and then pick the movie to see. I can't think of too many products I've experienced such a behavioral shift from.

I'd change the title too and drop "moviegoing habits" to simply "habits". I'm probably out on average 2 nights more a week than I used to be. I'll stop on the way home from standing appointments to grab dinner and a movie, just to wait out traffic. I don't think I'd ever done this before in my life.

If I owned a restaurant near a theater, I'd figure out how to be a Moviepass affiliate, in a heartbeat. Assuming they can survive, of course.

I think I've used this one as well for about 7 or 8 years. I can recall an accidental untie exactly once. It's also fantastic because it makes for a much more symmetric, shapely knot.

Two immediate I can think of:

1) You don't have to add new .dev hosts to /etc/hosts repeatedly. Once you're setup, all .dev is local

2) /etc/hosts doesn't support wildcards, so dnsmasq is great with apps that have many or randomized subdomains.

Interesting question, I can point out a few interesting differences I know of. Take note, I have more experience with Couch and its ilk than MongoDB, but I know some of Mongo's feature set.

tl;dr: You'd probably see the most difference with how a) the data is distributed and replicated and b) how you query data.

CouchDB (as of the 1.5 release) offers master-master (including offline) replication. It does not offer sharding. Cloudant's BigCouch does implement a dynamo-like distribution system for data that is slated for CouchDB 2.x iirc. Mongo on the other hand does support sharding via mongos, and you can build replica sets within each shard. It does not as far as I know support master-master. This is probably the biggest data-distribution difference between the two.

MongoDB support a more SQL-like ad hoc querying system, so you could query for drink recipes with 3 or less ingredients that have vodka in them, for instance. You'd still need indexes on the data you are querying for performance.

CouchDB queries are facilitated via javascript or erlang map reduce views, which serve as indexes you craft. An additional 'secondary-index' like query facility is to use a lucene plugin and define searchable data. Cloudant has this baked into their offering, and their employees maintain the plugin on github (https://github.com/rnewson/couchdb-lucene)

MongoDB has the ability to do things like append a value to a document array. In Couch, you'd likely read the entire document, append to the array in your app, and put the document back on Couch. It does have an update functionality that can sometimes isolate things more than this, but I haven't seen it used as much. Mongo can also do things like increment counters, while Couch cannot (though CouchBase can).

There's a host of other differences. Mongo has a much broader API, while CouchDB takes a more simple http verb like approach (get, put and delete see the heaviest use). Depending on your situation, one might be a better fit, or you might simply grok one more than the other.

As far as why Mongo gets used more often, I think the closer-to-SQL ad-hoc queries made more sense to people transitioning from stores like MySQL. The CouchDB view/map-reduce stuff is a bit more of a mindset shift (see the View Collation wiki entry for an example of this at http://wiki.apache.org/couchdb/View_collation). CouchDB was also taken hits for being slower than Mongo, but I suspect it was the map-reduce stuff that really steered some folks the other way.

I think something like a Rumble favors having the kitchen sink. You wanna be 'go go go, install a gem for that don't mess around' and work on your domain code exclusively.

Some people would argue the same for 'real' apps but, I don't like dealing with 140+ gems 2 years later. I think it's the old upfront-productivity-optimization vs. long term maintainability issue many people run into these days.

Yeah that freaked me out too. I'm not super familiar with mongoose either so at the time I couldn't figure out how to leave them out of serialization always. I could do it for one-off calls but there should be a way to generally whitelist I'd think.

Thanks for sharing this. I've been getting into express lately and this boilerplate is a little leaner for the reading.

It also just informed me of the app.param api in express. I had no idea.

Maybe benchmark it yourself? I think something is amiss, it should easily 'hello, world' at 2x higher rate than Rails. Poked around the setup a little a while back but nothing jumped out.

Hunches: it's either going through webrick or not running with RACK_ENV production

It's really unclear, but I think it's a loose reference to an older hack that involves patching javascript's Array to steal data when parsing JSON. The references to 'old array' and 'new array' in the screenshot seem to be the tipoff. This is my best guess at least.

See http://flask.pocoo.org/docs/security/#json-security for info. Most modern browsers don't let you patch Array like this anymore.

Also, that's more a csrf issue so, I could be totally wrong.

This is a bit tangent to your question, but, I think you can still run with ng-click if you deploy Content Security Policy, whereas onclicks will be banned.

One big difference would be encapsulation.

With mixins (sometimes called Concerns), you have a shared state between the module and the class including it.

With a real class, you have your own space and (probably) don't have to deal with state and method collisions.

Pros/cons to each surely, and a lot is a matter of taste at that.

Minor correction (mostly because, I think the code is kinda interesting), Sinatra does something close to this. It actually uses the __END__ tag for its inline templates, but then internally it splits the file itself in two and then parses the latter portion:

https://github.com/sinatra/sinatra/blob/master/lib/sinatra/b...

I suspect the reason it does so is for the point the author of the article makes briefly: "And it only exists for the first ruby file to be invoked by the interpreter."