RUG::B

Benchmarking is an important component of writing applications, gems, Ruby implementations, and everything in between. There is never a perfect formula for how to measure the performance of your code, as the requirements vary from codebase to codebase. Elastic has an entire team dedicated to measuring the performance of Elasticsearch and the clients team has worked with them to build a common benchmarking framework for itself. This talk will explore how the Elasticsearch Ruby Client is benchmarked and highlight key elements that are important for any benchmarking framework.

Let‘s have a discussion about quality.
- How do you measure it?
- How can you compare it?
- How can you achieve it?
- What‘s necessary and what makes sense to achieve it repeatably with different teams?

I will give answers (my answers) to these questions. But I hope to actually have a discussion about it. Perhaps round-table like? Who would be up for that?

Recent years have seen an uptake of "developer relationship" strategies. Tech companies are actively talking to people using (or potentially using) their technologies instead of the people buying them (usually managers). Briefly put, DevRel is a mixture of sales/marketing and headhunting.

DevRel people are also usually responsible to uphold relationships with notable figures in their target communities and foster contacts. This was definitely an improval about what was before. Now, contact is quick, personal and relaxed.

But for community workers, it also comes with a lot of issues. Plainly stated, this happens because individuals interact with individuals, but the relationship of companies to communities doesn't happen on an individual level. An overview of how DevRel is successful on the individual level, but failing communities, mostly due to structural issues of their setup themselves and how this replicates issues already present in the FOSS community.