The task

This hackathon subject is actually the continuation of work started in a previous hackathon under the name “Help me Please”: a system of interactive tours that guide the user through our products. Our solutions offer a large variety of possibilities, and proposing guidance would unlock their full potential to the end user.

Several conclusions were drawn from the “Help Me Please” experience:

• From a user point of view, such tours are typically shown during first launch, which could be, but not always is, the perfect time to bug the user with a long tutorial. Another issue that derives from this is that, once completed or ignored, there is no way to come back to such a guide. “Help me Please” actually solved this problem by presenting a list of scenarios where the user could restart any tutorial from a list. However, we wondered if there were still ways to better integrate the tutorial, our standard documentation and, perhaps, other formats of guidance.

  Read more →

Our original goal for this hackathon this year was to speed up the web builds.

But, as you will see, this year is special, and we have not tackled one, but two subjects in the same hackathon!

Speed up web builds using esbuild

Before the hackathon, our web build system was basically composed of webpack , with ts-loader to transpile TypeScript into JavaScript, fork-ts-checker-webpack-plugin to enable TypeScript type checking, and eslint for additional static analysis.

At Intersec we love hiring new talents, especially new C developers who can reinforce our teams.

And of course the candidates have to face a technical challenge so that we can assess their technical skills.

This is a typical step in the recruitment process that can become very time consuming for the reviewers and stressful for the candidates. Pimp My Recruitment is an initiative to help automatize this whole process, both for the candidate and the reviewer.

Showing new features on a demo platform painlessly

Today’s method

Currently, when we want to show the upcoming version of a product or new features for a demo, if these features are not already fully available on the code repository, and so existing in a packaged version of the product, it’s a bit painful.

We have to create a dedicated demo platform, by compiling the specific product locally, building packages and installing them manually on a dedicated Virtual Machine.

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.g. a new compiler version that will introduce new build errors).

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.gl was no more advanced than “Wow, this looks nice!” when browsing their website. Thankfully, our dream team was composed of two geodatascientists and two full stack developers, so we had all in hand to make it a success!

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: