Ah, that’s my fault, deploying a fix to that incorrect branch reference now!
Don’t worry, I have worked with a lot of companies improving their docs and developer experience, it’s all coming, and improving, but these things can take as long as (and are as complex as) the code sometimes.
I have worked with distributed systems before, but am a newbie to the C# world, so everything has been getting a real beginners eye, don’t you worry.
Hold on there and keep contributing ideas and issues 
Chris
Dear Chris,
That sounds great - it is really needed and crucial for the future of ES, I'd say.
Best
Hoegge
This is how Elasticsearch advises
https://www.elastic.co/guide/en/elasticsearch/reference/5.5/file-descriptors.html
SonarQube:
https://docs.sonarqube.org/display/SONARqube71/Requirements
So my point again - maybe not automate, but document.
Hi Chris W,
There are a couple of breaks in the EventStore Docs navigation:
The .NET API / “Code documentation” link no longer works. This is a very recent break.
Projections / “Getting Started” is also broken, failing to reach “https://eventstore.org/docs/projections/getting-started.md” and redirecting to the homepage instead.
Thanks,
Raith
Just took a look at the documentation again. E.g. the documentation of user defined projections is just a single page, a bullet list with a single example and no real explanation on how to do. This simply not good enough. It is half the functionality of eventstore (1) store+stream events, 2) project) - and then only a single page describes it.
/Hoegge
and you / they didn’t even bother annotating the example with comments / explanations
I don’t feel that 1/2 of the EventStore functionality is internal projections. In fact, we use ES in production for years and we barely use internal projections, except the standard ones. I see how internal projections can be useful, but I won’t call it the game changer or the most important feature of the product. I agree that more documentation would be nice, but it is not that extreme.
Whatever your feelings and usage on projections. We have a blog series and several additions to that section of the documentation coming soon, so keep your eyes open
Sounds great. Thanks. Looking forward to it.
/Hoegge
One area where I find the documentation lacking is tcp client behaviour. There are a lot of moving parts, and it’s not clear at all how they interact. I’ve used EventStore in production since 2011, and I still struggle with some behaviours. Working on some reliability issues right now, and it looks like a CatchupSubscription comes back up after a ConnectionClose, but a Persistent Subscribtion does not. There might very well be a good reason for this, but as a consumer of the api it’s not clear at all…
The documentation describes all the options, but not how they interact.
Is this something that documentation or examples would help more with?
I would be very interested in seeing a real-world, robust, example application. With proper error handling, batched projections, resilience etc.
/Peter
Agree. Also, if Greg do classes, where people learn to use ES, such examples could also be used in the documentation.
/Hoegge
I used EventStore as the source of truth for most of the sample code in my book “Hands-on Domain-Driven Design with .NET Core”, so there’s quite a lot of working code that uses EventStore, publicly available, with a decent amount of text explaining what is going on and why.
Well, that’s production. Unless there’s a production OSS app that uses ES, I can’t see any way of getting such an example. Neither I can really see such examples for many other decent tools, databases and frameworks. For example, there’s no real-world robust application that uses MongoDB C# driver, although MongoDB adoption is way higher.
So, this issue was possible to fix and it is finally done, great stuff
On Centos 7, Ubuntu 16.04 and 18.04, LimitNOFILE has been added to the systemd service file with a default value of 32768. This parameter controls the maximum number of file descriptors (including sockets!) open by the eventstored process. For small and medium-sized databases, 32768 is a reasonable value but the value needs to be increased for large databases with several thousand chunk files or many client connections.
To increase the value to 65536 for example, we recommend adding a systemd unit file override by following these steps. These settings will survive Event Store upgrades.
$ sudo systemctl edit eventstore.service
Add the following lines and save:
[Service]
LimitNOFILE=65536
Reload systemctl daemon and restart the eventstore service:
sudo systemctl daemon-reload
sudo systemctl restart eventstore.service
It’s 2020 and, in my opinion, the documentation is still largely lacking. There is no documentation for gRCP clients except the .net one and you have to switch between server documentation, client documentation and blog post to get an accurate description of projections. Multiple links are also dead and the TCP documentation doesn’t seem to exist anymore. I really like the concept of eventStore but the bar of entry really too high because it’s poorly documented.
It’s also a bit “concerning” that they’ve paid courses to learn eventStore on the website when the documentation is really hard to go through.
Thanks for the feedback! If you’d be so kind and point to the broken links more specifically, we’d be happy to fix those.
Concerning paid courses - none of those teach people how to use EventStoreDB and focus more on Event Sourcing and how to do it right. We don’t really think that’s something for the documentation as the documentation is about the product, not about the concept. As you can find very little about the concept of JSON (document) databases in MongoDB docs. Event Sourcing topic goes way beyond what the documentation has to cover, but we are making effort to provide some decent content in the resources and articles section of our website.
As for gRPC clients, all of them, except the .NET one, are still in the early stage of development. As the API is highly likely to change, the effort of writing the documentation for those clients is tedious and of questionable value at this moment. As soon as we stabilise the API, we will definitely pick up the pace on documenting all the clients we have.
I was recently given a technical test to do that heavily involved EventStore for a FinTech, after a lot of hunting around I came to the conclusion that even with 20 years of development experience the lack of documentation or examples of how to use EventStore meant I wasn’t able to complete the test.
Despite this I am still hunting around trying to find some code that’ll give me an understanding of how a EventStore project should be structured. Seriously guys, I’m not expecting to be led by the hand through every facet of the product but at least some example to get me off to the races would be helpful.
Dave, I’m sorry that you were not able to get enough support or guidance from our side.
I can assure that docs and learning materials are our top priority, we understand that we’re in the position where we need to improve on that quickly.
Could you share what would be the highest priority to get you started? I’m planning to deliver Event Store samples version on my repository https://github.com/oskardudycz/EventSourcing.NetCore. Would that help?