Maintaining old software on new OS Like many other companies, we need to maintain our software for a long period of time. Usually, a version lasts several years (we have had some versions in production for more than 10 years now). While we update our coding environment for new versions, we still need to be able to build and debug those older branches. This can become a problem when our new default system introduces a new tool version (e.

In the virtual world, hardware may feel abstract, nonetheless software still depends on physical infrastructure consuming resources where waste can take place. Let’s look at datacenters, where the physical location is based on the price of electricity, then you have to keep them cool, placing data center underwater is one solution being explored. There is also the high energy consumption of crypto mining but let’s focus on a simpler example, that app on your phone that consumes a lot of battery or memory with no apparent reason which ends up being removed by the annoyed user.

At Intersec we aim to provide the best user experience in our geo-oriented applications, where users need to understand a live situation at a glance and make the best decisions, based on accurate map data. The way to achieve this goal often relies on providing just the right amount of contextual information and actions, keeping everything as simple as possible. Users of Intersec products need to understand the geographic context:

The WordPress years This blog was originally hosted using WordPress, the famous CMS. It was quite an active site at the beginning, with a post every 2 months on average. But then, the contribution rate dropped, and the blog began to be only used to relate the results of our yearly hackathon. As the site was a bit deserted, we forgot to update it, which is quite a fatal mistake when dealing with a WordPress site…

On the 23rd and 24th of January, an internal hackathon took place at Intersec. Our team “Laws of the Universe” took part in this hackathon, with the ambition of “testing” kepler.gl, an open-source solution of geodata viz and analysis. More precisely, what we meant by “test” was a twofold objective: See if we could build nice viz based on the type of data commonly processed by our solutions Ideally, integrate them directly in our products, to demonstrate the feasibility of an industrialized solution based on this technology To be honest, before the hackathon, our knowledge of kepler.

Objective In our products, we use a home-made technology called QRRD (for Quick Round Robin Database) to store monitoring metrics (system CPU/memory monitoring, incoming event flows, …). QRRD (which is written in C) was actively developed between 2009 and 2013, but we have not been investing in it since, so it has not evolved anymore. And even if this is a really great technology (especially in terms of scaling and performances), it has the following drawbacks:

At Intersec, we aim at maintaining a consistent style throughout all the code, depending on the programming language. For example, the C codebase is the most consistent, with our coding rules being enforced on code review. This enforcement, however, can lead to significant time loss and frustrations when patches must be repushed to be adapted to specific rules. In the past, there has been several attempts at configuring auto-formatting tools. They were never fully satisfactory because several of our coding rules did not fit into the limited configuration options of these tools.

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.