Ayende @ Rahien

Oren Eini aka Ayende Rahien CEO of Hibernating Rhinos LTD, which develops RavenDB, a NoSQL Open Source Document Database.

You can reach me by:

oren@ravendb.net

+972 52-548-6969

Posts: 7,059 | Comments: 49,783

filter by tags archive
time to read 2 min | 342 words

One of the hardest things we have to do it to get people who aren’t familiar with RavenDB acclimatize to it. This onboarding process is typically done by doing something tangential to RavenDB, which allows the new guys to learn RavenDB while doing something useful.

Past examples of this is the demo website for RavenDB, Python Client for RavenDB, internal tools, etc. In the case of Iftah, this meant going into an Open Source project, and add support for RavenDB.

This serves several purposes:

  • It means that Iftah needed to learn how to effectively use RavenDB, and how to do that in the context of a real world problem, instead of dummy invented one.
  • We get to have the Quartz.NET integration in the end. We even have a Nuget package for it, to make things easier all around.

If you don't know what Quartz.NET is…

… a full-featured, open source job scheduling system that can be used from smallest apps to large scale enterprise systems.

And was precisely what he did, which means that you can head to Quartz.NET with RavenDB, setup a couple of configuration options, and you'll have this:

image

This make it much nicer to look at what is going on, understand the various jobs, schedulers and triggers, and work with them. The fact that we can put pretty much all of it in once place means that we can have this:

image

Instead of this:

image

It also means that complex jobs, which require non trivial state (JobDataMap) have much easier time, because they don't need to try to shove all of that into the relational model, they can just store the state as is in RavenDB as JSON values.

time to read 2 min | 266 words

One of the hardest things we have to do it to get people who aren’t familiar with RavenDB acclimatize to it. This onboarding process is typically done by doing something tangential to RavenDB, which allows the new guys to learn RavenDB while doing something useful.

Past examples of this is the demo website for RavenDB, internal tools, etc. In the case of Idan, since he had an extensive Python background, we decided to give him as the intro task the job of writing a RavenDB client API in Python. This has several advantages:

  • Instead of shifting rapidly from the environment he knows and is familiar with, we get a much gentler curve.
  • In order to actually implement it, he would have to become very familiar with the guts of RavenDB and how it actually works. Obviously that would be mostly on the client, but you can’t really do that without also understanding what the server is doing.
  • We end up with a usable Python client.

So, without further ado, let me show you how this looks like:

And the result is:

image

Which is pretty nice. The Python client API can handle most CRUD scenarios, including full support for replication, failover, dynamic queries, etc.

It isn’t the complete client, like we have for .NET or JVM, but it should do for most needs, and as usual, pull requests are welcome.

There is still a bit of work remaining (documentation, deployment, etc), but this is ready to take for a spin.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. Webinar recording (9):
    27 Aug 2020 - The App that Guarantees You're Going Out This Saturday Night
  2. Podcast (3):
    17 Aug 2020 - #SoLeadSaturday with Oren Eini
  3. RavenDB Webinar (3):
    01 Jun 2020 - Polymorphism at Scale
  4. Talk (5):
    23 Apr 2020 - Advanced indexing with RavenDB
  5. Challenge (57):
    21 Apr 2020 - Generate matching shard id–answer
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats