jrudolph

I'm using it in production as the backing data-store for a web app. There are a few very nice things about it:

  - ACID Transactions on multiple documents + queries by ID
  - BASE (eventually consistent) map reduce indexes
  - Great client libraries: Unit of Work pattern, optional client-side caching
  - extremely productive, no ORM required due to document model, unit testing support via In-Memory DB, JSON.NET serialization, support for polymorphic object graphs etc.
  - very powerful indexing (we use map reduce, spatial + multi-facets) + fast querying
  - Integrated RavenDB 3.x management studio based on HTML5 and generally solid to work with
  - safe defaults, I have never lost data with it (heard some bad things about Mongo in that regard though)

However, there are clearly some gotchas where in trying to save you from shooting your foot off, RavenDB will occasionally shoot off your leg instead. Upside is, these are well-documented and usually caught if you test with realistic or production workloads:

  - RavenDB will by default throw an exception after more than 30 queries per session to warn you about SELECT N+1 issues
  - No unlimited result sets (will silently cap at 128 unless limits explicitly specified). You can use streaming to fetch _all_ documents if you really need it but this is explicit
  - BASE Indexes require some thought in your UX/UI to handle properly

Those are the most common issues I've heard about. Once you know them, they are easily caught in code review. I've run into a few issues though. Defining indexes using LINQ works great in 95% of cases, but those 5% of cases where it doesn't are a PITA to debug. Some of those I ran into were caused by bugs, other times I failed to understand correctly how certain things worked correctly. With all issues I've had, the team has always been super responsive and fast to turn out a fix or offer advice on how to do it correctly, even though I wasn't paying for a support contract. All they need to get going is a minimum reproduction (e.g. unit test) they can work off and a mail to the RavenDB mailing list.

Would I use it again? Yes, definitely. I've heard good things about 4.0's performance though I expect it will be quite a while before it's stable. And they've been working on a new client library that should help prevent the common "beginner mistakes" above a little better.

Silly amounts of magic? Ever looked at a Java Spring project?!

Thanks for the fast response and sharing this story! Will definitely take it for a spin soon.

I have to admit this looks nice. Anyone knows about the history of this project and the direction where it's headed? Not that vmware was on my radar so far for steering a successful open source project in this space.

locust.io is pretty sweet, performs well and allows you to do custom scripting in python

@runesoerensen: any plans to offer linux /.net core instances in AppHarbor (my favourite way to host .net apps by far!)?

The biggest problem in rowing is that you look towards the back that you can't possibly know exactly when you'll cross the finish line. And you're so tunnelled after even 200m of racing (very narrow field of vision, due to unbelievable exhaustion + pain, with the nagging though of 1800m still to go...) that you can't count the buoys either to make out the distance to the finish line. For most of the races I had in my active career, I can barely remember the final 500m of a race. You're just concentrating on every single stroke and trying to squeeze the maximum out of your body. Trying to "rush" to finish line is absolutely impossible.

Sums it up perfectly. I might steal that quote :-)

The olympic marathon swimming was indeed mean. In any case, it's up to the sports organisations to determine what the rules are and what the rules should be. I don't say it's wrong what we're doing in rowing. In fact, using a photofinish with a minimum resolution of 1/100th of a second is an easy and pragmatic solution.

But it's not necessarily the way things have to be forever. My main concern is that it pretends to offer a precise measurement of relative performance when in fact it cannot because we can't guarantee a similarly precise alignment at the start. Or at least the rules don't ask for it (accuracy of alignment + precision of its measurement is not prescribed in the in the FISA rules of racing).

I might be too late to add this, but Rowing in Motion (my product) actually helps rowers analyze this using a smartphone's integrated accelerometer + gps. We can even live transmit the data to a coach following behind in the motorboat and overlay it (in realtime on the GPU) onto video footage captured from the camera.

See this video for a demo of the result https://www.youtube.com/watch?v=RdVSk3mA9Wk

And this article for an explanation of how the boat's acceleration pattern relates to rowing technique: https://www.rowinginmotion.com/optimize-your-rowing-stroke-w...

And this for an explanation of the math behind it (i.e. why certain acceleration patterns are more efficient than others and optimum technique will make you go faster): https://www.rowinginmotion.com/drag-efficiency-rowing/

Needless to say biomechanic analysis on smartphones is a ton of fun :-D

Thanks, fixed!

Wow, didn't expect one of my rowing related articles to ever appear on HN. Thanks for posting, hope you found it interesting.

Also interesting if you like this: "Why There Are So Many Ties in Swimming", https://news.ycombinator.com/item?id=12282326

Is it just me or does anyone else think that many of the startups from Day 1 and Day 2 are well beyond the "seed" stage that YC claims to target? I get that YC is a perfect program to prepare a company for raising significant investment, so it makes perfect sense for the startups to join even at a later stage. Also derisks YCs investment on the standard terms (i.e. 7% of a later-stage company for 120k$ is a better deal than 7% for 120k$ at an entirely unproven company).

Example: Ohmygreen claims it's a logistics company (which implies CapEx unless they rent, which eats margins) and already has 800k MRR. Doesn't quite fit my definition of "seed" stage.

Fantastic analysis. One important question not covered in the article: how are lanes assigend in swimming? In rowing we have a qualification system that is geared to have the best crews start in the middle two of the 6 lanes, then going further out. For all I know about fluid dynamics, swimming in the outer lanes should have a disadvantage (swimming close to the pools boundary adds drag).

Quite like the idea, it's similar in concept to massive-js http://massive-js.readthedocs.io/en/latest/

Haven't used it in production yet but I have used RavenDB successfully for quite some time. Anyone aware of similar efforts to make PostgreSQL usable as a DocumentDB from other languages? It's an intriguing concept as it allows combining document+relational data models in a single database.

This App is a side-project of mine as I was looking for a simple App that would allow me to visually track a handful of things that I want to improve on (e.g. my current 10 rep. max in the Gym for various exercise). Looked at a lot of other Apps for that purpose out there but found none I really liked, wanted something that:

- is as simple to use as possible

- allows me to record a value in <10s without jumping through a lot of hoops

- is not pestering me with Push Notifications

Details: Native Objective-C App, spent ~18hrs total including design, submitting to App Store etc. Uses https://github.com/Boris-Em/BEMSimpleLineGraph for charting and flat csv files as database (exportable too!).

Inspired by Nathan Barry's Commit App for iOS which I really like.