Presentation 🤓 In recent years, there has been significant progress in the field of artificial intelligence, especially with the development of lightweight models that can run locally and provide good results. These local AIs are interesting because they ensure data confidentiality, which is a crucial factor in our work environment. As a software company, we use many digital tools to facilitate our work and collaboration among colleagues. Among these tools, we use Slack for internal communication and Redmine for project management.

Objective Text editors are essential tools for software developers. These editors provide many useful features to make developers’ lives easier and improve their productivity. There is a wide variety of text editors. Moreover, each language has its own characteristics and each company/project may decide to adopt different coding rules. For all these reasons, it is difficult to offer a configuration suitable for everyone. In this hackathon, we tried to help developers configure their text editors correctly for optimal performance.

The goal was to develop benchmarks on a few of our core technologies in lib-common, in order to: Be able to compare the performances of our custom implementations with standard implementations. Be able to add automated tests on performance (e.g. adding non-regression tests to ensure that changes which seem to be harmless do not worsen performance). Benchmark library The first step was to develop a benchmark library; the success criteria we established were the following (compared to the already existing benchmarks in our code base):

At Intersec, we love new technologies that can improve our working tasks, our code, and because it is fun! During Hackathon 0x09, I tested the possibility to use BPF for tracing and debugging our C codebase. What is BPF? In the beginning, BPF was a technology used for packet filtering 1. For example, when using the command tcpdump -i lo arp, BPF is used to filter ARP packets on the loopback interface.

During summer 2014 we organized our first hackathon. The rules are simple and are still up to date: The subjects are suggested by anyone in the company and there is no defined framework nor limit on what they can be although they often fall in the same categories, I’ll come back to that. Anyone can show interest in any of the proposed subjects and then work on it. In practice though, participants are mostly people from technical teams.

This series of articles describes some of the best realisations made by Intersec R&D team during the 2-day Hackathon that took place on the 3rd and 4th of July. The goal had been set a day or two prior to the beginning of the hackathon: we were hoping to make Gerrit better at recommending relevant reviewers for a given commit. To those who haven’t heard of it, Gerrit is a web-based code review system.

This series of articles describes some of the best realisations made by Intersec R&D team during the 2-day Hackathon that took place on the 3rd and 4th of July. Presentation of the Project As testers, we spend a lot of time working on behave, our test automation framework1. Our test framework is a great tool, but it takes a lot of time starting and initializing the product, running tests one by one.