As we do every year, we participated again this year at FOSDEM, the largest conference on free and open source software in Europe. Apart from having really nice conversations and grabbing many stickers 🙂 , we attended many very inspiring talks this year, too.
The Mozilla DevRoom was very crowded this year too, and for sure we couldn’t miss it. All the talks were very interesting, but today I want to relate what piqued me the most.
The speaker presented how this tool can be used not only for unit testing, but also for creating automatic procedures to be run on a browser, simplifying your daily routine on the internet. We will definitely have to try it out in our development cycle!
Language localization at Mozilla occurs in a tight loop between development and the involvement of a localizer. This talk was based on the process to be followed when localizing the Firefox desktop application and the main Android projects by the Mozilla contributors community. To help follow the localization workflow, they developed a tool called Pontoon.
Pontoon is an open source localization server that given a Git repository, fetches all the translation strings from the code. It then provides a web interface where localizers can translate the original in all other supported languages. The translations are then submitted to the moderators who can decide to approve, decline or change the translations. After the translations have been approved, Pontoon automatically syncs the Git repository with the updated translations.
It would be interesting to try to adopt this solution for NetEye 4 as well so that we can improve our translation workflow. Furthermore it might also be useful for integrating the community of NetEye 4 users who want to help to improve the product they use daily.
Olena Bulyginas’ talk about “The real cost of not doing user research” was a tough pill to swallow, as she outlined exactly what many of my own/favorite open source projects get wrong. Most prominently when things go crazy as a product is adopted by an exponential number of persons, the investment of time and energy in new features must be planned thoroughly, and is best based on data and facts.
My takeaway here was not to fear doing the research wrong, but to fear NOT DOING any research in the first place, and to then blindly invest resources in features that possibly only a small percentage of users need.
A more technical talk from the French Google employee Paul Masurel about his personal ‘toy’ search engine competitor to Lucene, ‘Tantivy‘, underlined the power and expressiveness of the Rust Programming Language.
He briefly went into how Rust allowed him to both rely on the guarantees the language provides, but also explicitly exploit the low level speed gains of, for example, SIMD instructions.
The main part of the talk gave a high level overview on how to build a trie-based inverted index, which conceptually is close to how both Lucene and Tantivy work internally. He concluded by giving a brief introduction to the data structures backing the project, scaling it down to understandable chunks.
All in all, Tantivy is a highly interesting project for both NetEye and EriZone, and I can see it giving advantage both through our software projects, as well as through an Elasticsearch competitor such as Toshi.
Elasticsearch is a powerful distributed search and analytics engine built on Apache Lucene, and has become very popular in recent years for its ability to provide scalable and near-real-time search, horizontal scaling and replication.
As an Elasticsearch user, have you ever wondered how large an impact a query on the Elastic cluster has on performance?
The Elastic Stack already provides some mechanisms to do query profiling (e.g., the Kibana profiler), but what if I have an application in which users can run queries, and I want to know the impact of each of them before actually executing the query? In an interesting talk at FOSDEM we discovered ESCOVA, an Elasticsearch query compiler and verifier.
An Elasticsearch query is first transformed into a Lucene abstract syntax tree before actually being executed. ESCOVA applies static cost analysis directly on the tree nodes and reconstructs the full cost of the query by traversing the tree. Thus an application that equips ESCOVA as profiler can decide for itself whether to execute a query or not.