pie

Oscar resells MagnaCare insurance, and they're not even the only ones on the NY exchange to do it. I wish they'd actually do something different in the insurance market, but Oscar is more of the same.

It's also worth checking out The Silver Searcher: https://github.com/ggreer/the_silver_searcher

Another useful tool for working with spreadsheets in Javascript is SheetJS: https://github.com/SheetJS/js-xlsx

For a hackable, open source collaborative framework, check out Mozilla's TogetherJS: https://togetherjs.com/

Judging by the chart on the site, it looks like each client polls the original model on the server, and infers changes by diffing it against the client's current copy.

The readme says it works with any "persistent backend such as a REST API or socket connection".

It looks like it tries to be backend-agnostic, and do the sync work on the client side.

I've talked with the Scratch team and I believe they went with Flash to serve the many schools with low-end machines and older browsers.

Yup, I've actually read all those papers, and then some. I think OT is often misunderstood and poorly documented, and really needs a solid go-to library. (Along with clear, accessible documentation.)

ShareJS and "Operational-Transformation" (used by Firepad) are decent, but in my opinion aren't general enough and may even have some algorithmic flaws.

And yes, it's time this was solved, and it wasn't necessary to re-implement the basics for every collaborative project.

Yes, and Wave is probably the most accurate open source picture of what Google is using for Docs: http://incubator.apache.org/wave/

OT works naturally with linear data structures, but is tougher to use correctly with more complex data, which Mozilla seems to have here with Towtruck.

I'm excited to see what approach they choose!

I am very curious to see what happens with this issue: https://github.com/mozilla/towtruck/issues/5

Given Mozilla's profile and resources, maybe they'll come up with a novel solution!

No approach to technology architecture is a "silver bullet," especially with a stack spread across client and server.

I always find myself returning to the "boring, old-fashioned" way of doing things (like server-side processing or relational databases) and these do indeed seem like the best choices for many applications.

But I don't see how this calls client-side MVC into question, except that perhaps it's considered as a default choice too often.

While looking beyond a pg_dump-style approach to backup/recovery, I was considering https://github.com/heroku/WAL-E and discovered Barman. It's also open source, and looks like a strong contender.

Susy (http://susy.oddbird.net) is another well-designed option for semantic grids that's been around for awhile.

Looks like this uses themes from over here: http://bootswatch.com/

LaunchRock page.

And sadly, the article "Why You Should Never Pay For Online Dating" bashing match.com was taken down right after the acquisition.

Very interesting use of statistics by these guys.

There seems to be a mirror here http://interestingreads.posterous.com/why-you-should-never-p...

Better than what? This doesn't mention any of the other asset management tools out there.

This really ought to include a basic structure for routing, as described in the docs: http://emberjs.com/guides/outlets/

Or maybe not - routing in Ember has changed a lot, even over the last week.

Not trying to knock your article - just wanted to clarify the title, that it's more of a personal "things I learned" than an intro for beginners.

I agree that the Ember docs are pretty weak and missing some key pieces that one might miss when starting out.

This is about the author trying to get started with Ember, and doesn't offer anything in the way of helpful guidance for new users.

Check out http://emberjs.com/ or http://emberjs.tumblr.com/ for more info.

I know - but having developed an OT library and read the ShareJS code thoroughly, I think there MAY be 2 edge cases where conflict resolution is not symmetrical for some data types. Or I could be totally wrong.

As I mentioned, I hope to contribute tests to show that everything's peachy. Not trying to talk trash about this great library.

See also: Google Wave, open-sourced as Apache Wave.

http://incubator.apache.org/wave/

The architecture for Wave is really difficult to get a handle on, though.

Relative ease of use is a major benefit of ShareJS, though I can't fully vouch for its algorithmic correctness. I've been meaning to contribute some additional tests to the project.

This appears to be a wrapper for PyQt4's QTWebKit.

http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/q...

This is a long post, but a fascinating dive into the business of music. Here we have facts, hard numbers, more-questionable numbers, anecdotes, experiments, and some rambling hyperbole from an industry veteran. I have rarely seen this kind of detail in discussions of online music.

Thanks - I've been digging around through the data binding internals of these JS libs and I had indeed forgotten about Angular.

I'm comparing details on deferred updates and ease of integrating an OT-type collaboration layer. Derby's already starting to head this way and appears very promising, but I think there are subtle issues both in ShareJS and Derby's implementation. I'm curious how collaboration would work on some of these other libraries, and Angular seems to be thoughtfully architected, if somewhat large.

I'd be curious to hear any takes on how other similar JS frameworks focused on "live" data binding (particularly Ember, also Knockout) stack up to these two newer players. Clearly Derby and Meteor strive to be more complete end-to-end solutions, but it's my understanding that this (generally speaking, and more long-term) is specifically a goal of Ember as well.

Also, the concurrency models of all the JS frameworks of this nature appear to be pretty immature at first glance. Derby is starting to attach parts of ShareJS, but I don't see much else that looks particularly promising in other frameworks. I'm not sure that you can "partially" implement OT (or mix-and-match parts of different solutions), which perplexes me about some of the code I've seen in the area, even in ShareJS.

I find it a little strange that this post mentions Expresso but not its successor Mocha, which appears to have been started about the same time as Whiskey.

Anyway, this looks like a valuable contribution, and it's always good to see more well-supported tools in the Node ecosystem.

Right - I'm finding that this behavior (or something related to identification) makes it finnicky to update title/tags, and changes I make in the browser don't always seem to apply, even after resetting the connection.

If I edit a URL, stashmarks doesn't reflect the change in the UI, at least when the original is still pending download. Looks like it's actually changed internally.

Also, I can't delete (or edit) a bookmark in stashmarks that I no longer have saved in my browser. Recreating it and deleting that does nothing, even when logged out and then in.

Hope these critiques are helpful.

Clearly, these are all edge cases, and overall your service is impressive.

Right - but I am curious about how Stashmarks handles conflict resolution, if it does. I naively assume it simply de-dupes URLs, meaning unexpected things could happen with multiple Chromes that aren't running sync or have updates queued while working offline. Please correct me if I'm wrong.

(I also agree with the comment below that it's an edge case for most users, especially Chrome sync users.)

Great job. Looks like you're getting hammered with traffic right now, but I'm curious how this holds up with a few synchronized instances of Chrome.