Forem: Mickaël A

Drawing 3D lines in Mapbox with the threebox plugin

Mickaël A — Tue, 18 Jun 2024 05:33:22 +0000

Recently, I encountered a use case where I needed to draw a line in 3D space over a map layout. This line represents the track of a local flight, which is far more engaging to view and explore in 3D than in 2D, as it allows for a better appreciation of the elevation changes.

I used Mapbox for my online map, given its popularity and its use in the Strava application, which I frequently use.

Mapbox offers a convenient method for displaying GeoJSON data files on a map, as detailed in this Mapbox documentation page.

Setting up the scene with Mapbox

I work within a PHP Symfony application and use the NPM package manager. To integrate Mapbox, I installed the mapbox-gl library using the command npm i mapbox-gl.

I also created a Mapbox account and token (help page here, token page here) to use in my code.

Here is how the basic map creation looks in my project:



var mapboxgl = require('mapbox-gl/dist/mapbox-gl.js');

mapboxgl.accessToken = 'pk....' // your full token here
var map = new mapboxgl.Map({
    container: 'map',  // the HTML element where the maps load
    style: 'mapbox://styles/mapbox/outdoors-v12', // the Mapbox style of the map
    center: [6.1229882, 43.24953278], // starting position [lng, lat]
    zoom: 9,
});

For a more detailed setup of your first map in your project, you can refer to this page: Display a map on a web page.

Adding 3D terrain

Since I want to enjoy my map in 3D, adding terrain visualization is essential. This feature is not enabled by default. In Mapbox terminology, this involves using a raster-dem layer. You can find an example of this setup here.

In my context, the code looks like this:



const exaggeration=1.5;

// Add terrain source
map.addSource('mapbox-dem', {
    'type': 'raster-dem',
    'url': 'mapbox://mapbox.mapbox-terrain-dem-v1',
    'tileSize': 512,
    'maxzoom': 14
});
// add the DEM source as a terrain layer with exaggerated height
map.setTerrain({ 'source': 'mapbox-dem', 'exaggeration': exaggeration });

As you can see, it's very close to the sample. Now, when I ctrl+click and move my mouse, I can see the elevation. The exaggeration constant helps to dramatize the terrain a bit, allowing for better appreciation of the relief.

Adding my GeoJSON track to the map

As I mentioned earlier, Mapbox provides a convenient way to add GeoJSON data to my map, which is documented here. In my case, the GeoJSON data is derived from processing a GPX file on the backend. I have my GeoJSON file stored on disk.

Here is how I load and display the GeoJSON data on the map:



map.on("load", () => {
    map.addSource("air-track", {
        type: "geojson",
        data: geojson,  // geojson contains the path to my local geojson file
    });

    map.addLayer({
        id: "air-track-line",
        type: "line",
        source: "air-track",
        paint: {
            "line-color": "#dd0000", // red
            "line-width": 4,
        },
    });
}

This is enough to display something like this:

Make this line 3D

Here we are pushing beyond the capabilities of Mapbox. Unfortunately, Mapbox's 3D capabilities with GeoJSON have limitations. It's important to note that my GeoJSON data includes elevation information, as per standard. Here is a sample of my data:



"geometry": {
  "type": "MultiLineString",
  "coordinates": [
    [
      [
        6.12827066,  // lat
        43.24983118, // lng
        76.7122,     // elevation
        "2024-02-29T09:10:14Z"  // time (not used)
      ],
      [
        6.12817452,
        43.24956302,
        81.7742,
        "2024-02-29T09:10:20Z"
      ],
      [
        6.12814958,
        43.24928749,
        80.3541,
        "2024-02-29T09:10:29Z"
      ],

...

In various discussions and Stack Overflow issues, some workarounds have been suggested, but they don't fully meet my requirements.

The flexibility I need can be achieved by importing a Mapbox plugin called threebox, which is a combination of three.js and Mapbox.

Adding threebox to the equation

I installed Threebox and connected it to my map:



// Creating tb related to my Mapbox map
const tb = (window.tb = new Threebox(
    map,  // my mapbox map
    map.getCanvas().getContext('webgl'),
    {
        defaultLights: true
    }
));

// On load, add a custom layer
map.on("load", () => {
    ...

    map.addLayer({
        id: 'custom_layer',
        type: 'custom',
        render: function(gl, matrix){
            tb.update();
        }
    })

})

This is how it works: a new custom layer is added to the scene, allowing us to draw specific shapes in the 3D space of Mapbox. The Threebox plugin is featured in this Mapbox documentation page.

Initially, I was hesitant to delve into more complex tools, but after overcoming some integration challenges, using it turned out to be quite straightforward.

Drawing in 3D

To add a line to the scene, you can use the convenient tb.line() function. It supports the elevation parameter out of the box.



const line_segment = tb.line({
    geometry: [
        [lat1, lng1, elevation1],
        [lat2, lng2, elevation2],
    ],
    color: '#dd0000',
    width: 4,
    opacity: 1
});
tb.add(line_segment);

This would create a line and add it to the scene.

Drawing the GeoJSON data

To connect Threebox with the data needed to draw, the challenge lies in retrieving GeoJSON features from the scene. While Mapbox provides a querySourceFeatures method to fetch features from a source, I didn't manage to use it properly. My array of the features was empty, no matter what. I opted for a disk load, as my data is on a file accessible from this script.



map.on('sourcedata', (e) => {
    if (e.sourceId !== "air-track" && !e.isSourceLoaded) {
        return;
    }

    const data = fetch(geojson).then(function(res) {
        const jres = res.json().then(function(res) {
            const coords = res.features[0].geometry.coordinates[0];
            draw3dLine(coords);
        });
    });
})

I am listening for the sourcedata event. If the event's sourceId matches air-track (which is the source ID I used in map.addSource() above), I then load the GeoJSON data from the file and store the coordinates. Here's an approach to achieve this:



function draw3dLine(coords) {
    let i;
    for (i = 0; i < coords.length; i++) {
        if (i === 0) continue;

        // Draw the segment in space
        const line_segment = tb.line({
            geometry: [
                [coords[i][0], coords[i][1], coords[i][2] * exaggeration],
                [coords[i - 1][0], coords[i - 1][1], coords[i - 1][2] * exaggeration],
            ],
            color: '#dd0000',
            width: 4,
            opacity: 1
        });
        tb.add(line_segment);
    }
}

Note that I reused the exaggeration constant here as I exaggerated the relief. Without it, the proportions would not be respected and the line could cross the terrain.

The core logic is implemented in that function. For each pair of coordinates in the source, it draws a line in space, resulting in something like this:

I found it a bit difficult to appreciate the track, so I added a vertical line after each 3D segment. Each of these lines has coordinates identical to the last segment point, set at elevation zero (lat, lng).



// Draw the vertical line at the end of the segment
const line_vertical = tb.line({
    geometry: [
        [coords[i - 1][0], coords[i - 1][1], coords[i - 1][2] * exaggeration],
        [coords[i - 1][0], coords[i - 1][1], coords[i - 1][0]]
    ],
    color: '#dd0000',
    width: 1,
    opacity: .5
})
tb.add(line_vertical);

Which draws as:

Displaying a shadow

I retained the GeoJSON track feature provided by Mapbox to maintain the visible line on the ground. I simply reduced its width to 1 and changed the color to dark gray, creating the impression of a shadow.



map.addSource("air-track", {
    type: "geojson",
    data: geojson,
});

map.addLayer({
    id: "air-track-line",
    type: "line",
    source: "air-track",
    paint: {
        "line-color": "#111111", // dark gray
        "line-width": 1,         // thin width
    },
});

Conclusion

It took me more time to find the right tools to solve my problem than to actually code the algorithm itself. In the context of my Symfony project, it also took some time to integrate GeoJSON, Mapbox, and threebox altogether.

I'm very enthusiastic about the result, and I'm sharing it here because there wasn't an obvious way to do so on the web.

A Metric for Technical Debt

Mickaël A — Thu, 22 Sep 2022 08:55:36 +0000

Technical debt is a prominent topic for any company running code as its main asset. However, unlike many other part of the company, there is often no clear metric about it.

And there is a good reason for that: it's complicated.

At Vialma, I need to measure it in order to be able to evaluate our debt, to track it, and to pay it back!

Main features of the metric

The metric I came up with is compound. It is hard to list and understand everything involved in technical debt. However, some features are more obvious than others. I focused on them.

Technologies versions. I met a company that were working on Django 1.*. That's debt. I consider here web server versions (apache, nginx, ...), language version (Python, PHP, ...) or framework version (React, Symfony, ...). In this metric, I compare the current version of our technology with the latest version on the market, and count the number of days elapsed since the release of that version.
Tests. The code can be ugly... but if it's tested, at least we know it is doing what we expect out of it. A code without tests is very likely to become an important debt to the company.
Dependencies. The technical debt of a highly dependent code will grow very fast. It is easier and faster to code with many dependencies at first, however much harder to maintain it. I include dependencies in my metric.

About the metric value

The metric above is 5.48. It does not mean much by itself, what is of first interest to me is how it is progressing from one month to the other.

It will naturally grow, since the elapsed days of latest technologies continuously grow. Decisions to merge projects, bootstrap new technologies, waiting too long for refactoring or avoiding tests will now have an impact on the metric. It's exactly what I wanted!

Why managing technical debt is important?

It is not always obvious to business or product owners. I like to remind the importance of technical debt control on the business this way:

Development time: a clean, maintained code makes any new development faster, whatever the experience of the developer. This can be counter-intuitive to some developers when you think of the time you need to code and maintain tests, but it truly is!
Stack attractiveness: it is hard to hire PHP developers already... It is MUCH harder if you are running Symfony 3 on PHP 5...
Maintenance time: you can't safely move from version X to X+1 if your code is untested and unstable. What happens too often is that migration is never planned ("we didn't have time"!)

Conclusion

Technical Debt is not a bogeyman in the company any more. It is a controlled variable behind a transparent, simple metric, like any other important business matter.

I would like to add more features to this metric later, like the number of developers per project, code coverage (instead of lines of test code), security issues detected by Snyk or a similar tool, or the number of errors raised in production with Sentry or Kibana for example.

Maybe for a version 2 of the metric!

8 unexpected tips for remote workers

Mickaël A — Sat, 29 Jan 2022 08:26:10 +0000

As a manager of a team of 8 developers and working in a full-remote company across the globe, I share here a list of simple yet useful tips to make remote work more efficient.

👤Use profile pictures

In all the tools you're using, use a picture of you as a profile picture. Do not leave a default one or do not use unrelated content. It helps the team members know each other and remembering that we are all humans after all...

🖼️Post personal photos of things you are doing out of work. Show your pets, family members, how your surroundings look like, outdoor activities... It might seem weird at first, but it is very appreciated and commented. Use appropriate channels and the right frequency (once a week?).

⌨️Learn to type fast

Written communication is so omnipresent in remote teams that fast-typers deal better with team work. Expressing ideas will be a lot easier if you can type fast. If it's not your case, don't despair and use train regularly with tools like kebr.

🙌Use emojis

They seem unprofessional at first, but they are a premium artefact to have rich remote conversation. Sometimes an emoji is just what you need to react to an assertion. Remote teams use emojis as a second, and subtle, language.

📹Use your video in all meetings, at least for the first and the last minutes. Every meeting is an opportunity to connect to others and show how you look today. We all need this to work together! People deactivating it are suddenly more distant and can alter a team spirit after a while.

⏰Be punctual

Respect scrupulously meeting end and start times. It is frustrating to wait for someone in front of a screen. Being on time is more respectful and more efficient than ever.

📅Reduce the default meeting length

Remote meetings are more energy-consuming than their physical counterpart. They can be more frustrating as well. Use 20 or 30 minutes as the default duration. 40 minutes for long meeting and 1 hour for exceptionally long meetings.

🌴Expose your break times

Personal and professional spheres are more porous than ever. Indicate in your calendar your availability zones and make clear when you won't be working (beginning and end of a regular day, breaks, focus times...). This will reduce your stress and liberate a lot of positive energy.

Happy remote work! 🎉

Dealing with Code Legacy

Mickaël A — Mon, 11 Oct 2021 18:43:50 +0000

Code legacy is an inevitable topic in software, that can create a lot of frustration : "We must rewrite this part because it's too poorly coded and unmaintainable, but we don't have time!"

The problem is generally that the actual deciders undervalue the issue or don't see it at all. Imagine the lobby of the main building being cluttered by a pile of trash, growing every day... Would the boss allow time to clean it?

Cleaning existing code is called refactoring. During refactoring, developers rearrange the code in a nice way so that it is more readable, more maintainable, and often more performant as well.

Refactoring should be a common word in any software-related business or product. It's a normal activity. It is like washing your hands in a hospital or watering the plants in a flower shop. As a CTO, I request at least 20 % per week to dedicate to it.

I consider 3 levels of refactoring:

On-the-fly. The refactoring is tiny and related to another task (or card or ticket depending on the terminology). It is done while coding that task, potentially inflating the estimation of that card.
Refactoring task. The refactoring has been identified in a previous work and been exposed to the management team. It is extracted as another task, estimated and planned like any other task. That fits well in the 20% quota.
Refactoring projects. Sometimes the refactoring will impact many different sections of the code. It cannot be isolated as a task so it becomes a project. Like any other project in the company, it will be divided into tasks, estimated and scheduled accordingly in the 20% or more if it meets more directly product expectations.

Refactoring projects

Refactoring projects are the riskiest because they compete with regular project in terms of time and effort. In short, they will probably need more than the 20% quota and mobilise management for a while. At first, many tasks will create no visible and cost money. That's why it is important to compartmentalized them as much as possible, reduce the scope and sensitize product and business deciders of the long-term outcomes.

The situation is critical because without refactoring any new development will actually increase the technical debt: more unexpected bugs, harder-to-maintain code, more desperation, less attractiveness for the developers. It has to be done.

This needs tech leadership. If the important refactoring do not occur because "we don't have time", then it's a tech management issue. Sometimes developers can use the "time" argument as an excuse. It's worth digging: the refactoring could be delayed (it can wait a few more months/years), is smaller than we though (or bigger!), developers just don't have the right coding practices or are not skilled enough to maintain an old and big code stack. In all of these cases a great deal of attention is required by the tech management.

"The big rewrite"

The big rewrite consists in rewriting entire part of the business' code. It sometimes sounds like the best option, especially to (junior?) developers. "If only this was coded like this since the beginning...".

It's a trap!

It is extremely rare that TBR is the right solution. Even "hopeless" situations can be turned into smaller projects, from basic code rearranging to re-architecturing. Then little by little the code will be refactored, without interrupting the business and losing enormous amount of time & money which is usually the case with TBR.

That is only possible with a higher-level technical analysis, typically done by the CTO with the help of developers, a very good organization and an excellent communication:

what is included and excluded for each step
what has been done after each iteration
how difficult the current step is and how to restructure next steps.
...

The tunnelling effect is dangerous here and must be monitored carefully.

Code legacy is also good

I would like to conclude on a positive note : code legacy is also a good sign. It means an organization has built something and used it for the business, most likely with limited time and resource. Identifying code debt means a progress in coding expectations and business strategy as a whole.

The legacy defines who we are as an organization, what we have been through, what decisions were good or bad. One who reads the legacy will learn a lot about the business past and present.

My experience with Dual Boot Windows/Linux

Mickaël A — Sun, 22 Nov 2020 16:08:04 +0000

I bought a laptop one year ago, and decided to run it with a dual boot, after using mine on Ubuntu for years.

Linux (still) has trouble with my hardware

It's quite a constant with Linux distributions, and has always been a struggle in all experiences I had. In my case, my laptop is a Dell XPS with an IPS OLED Infinity HD screen. I love this screen (on Windows) but on Linux, it is sucking all my battery and its brightness cannot be adjusted from my keyboard keys.

The first time I used my Linux with this screen without my energy cable plugged in, I lasted only 1 hour and was quite in trouble to continue working that day! After hours to try to fix the problem, my best option was to reduce the brightness (with a specific software, method 2 here), which actually saves a lot of energy.

Small hiccups with Linux

Some little annoying things still happen on my Ubuntu. It may seems nothing at first, but after a while it is quite annoying. Some of them include:

Some software can't deal with that superb resolution of my screen and displays text in a very very very small font, making it unusable. Usually there is a way to make them bigger (in the settings), but it's something I never have on Windows.
When my Firefox requests a restart (new version I presume), it never restart when I click on the Restart button. The OS didn't get the instruction properly.
I can't pin all software in my navigation bar. Again, there is probably a way to do so, but I didn't find it yet...
The shared links in Slack does not open in my already opened Firefox, but in a subprocess of Slack. It is annoying because then my credentials are not maintained (it's like a new private browsing), which makes it very annoying for work.
At some point Slack was flickering and was not usable at all. I had to use it on a browser tab instead.
When I reboot my machine from Linux, and expects the dual boot menu to appears, it does not. I have to shut it down, and then start it from scratch (pressing the Power button). The first time I was really scared that my dual boot set up failed!
Some software really take too much resources (RAM), like Chrome or Zoom. Which is really annoying knowing that I bought a new laptop partly to solve this issue... Now, when I have a Zoom call, I reboot on Windows.

You make think these are small, and that in most cases I "just have to do this and that". My whole point here is that I don't have to do it on Windows. Everything is working out of the box.

My Windows OS is very efficient

So far I don't have much to complain about my Windows OS. I know the reasons, and the tight partnership Microsoft deals with manufacturers. In the case of my laptop and in particular the screen, it makes a huge difference in my daily experience.

For coding, Linux is far more better

Every time I am entering a coding session, I reboot on Linux. Things are smoother, much more integrated, and I am much faster. On Windows, I use Git for Windows but I hate the terminal (I should try to change it...). And I didn't set up the Linux WSL thing, which seems promising in my case.

In particular, Docker is far more useable on Linux than Windows. I expected that because of the core idea of the technology the experience would be the same on any OS, but not at all (so far). I think the main problem is the file system on which Docker technology heavily relies.

My screen is so beautiful...

... on Windows. I see the drivers are updated frequently. When it comes to watch a long video or a film, I always use Windows, which makes my experience amazing. On Linux, it's... flickering! Videos apart, my screen is amazing on both OSes :)

Dual boot is the ideal solution for me

I don't regret this choice at all, and in my case it's probably the best choice I could come up with. I did not try many Linux distributions as I was suggested to, I just stick with Ubuntu. Maybe another distribution would perfectly match my hardware (I hardly doubt it, though).

Also, something important is that booting either on Windows or Linux is super quick (a bit longer from Linux as I explained above). If there is a Windows update, I can totally delay that to the next time I boot on Windows. It is not impacting my Linux booting time at all.

A shared partition

I create an NTFS partition that is both r/w on Linux and Windows to share most of my personal data. It works fine and has been a good option so far. I happened that because of Windows sleep mode I was not able to write on that partition under Linux, but I could fix it disabling fast startup.

Conclusion

My job is a lot of code related stuff without coding, and I manage it on Windows. Windows became my main OS because of this. However, for personal projects and integrated development session, I don't lose time with Windows and switch to Linux.

From programmer to CTO. A journey

Mickaël A — Sun, 15 Nov 2020 16:15:53 +0000

Not so long ago, I was a developer. I worked for various companies as an employee, and more recently as an independent programmer. In one of my contracts, I found the stack very scattered, reflecting long months and even years of tech inconsistency, yet on solid technological choices. I shared this observation with my client, and suggested him to hire a CTO. He or she would refactor the current architecture and avoid the same mistake to happen again.

He asked me to jump in that role.

I said "yes".

My career slightly started to shift. Here are some important take-aways I wish I had known before.

It's hard work

Taking the ownership of a full tech stack is tough. I means reading a lot of ~~technical documentation~~ code, go through a lot of configuration files, git history, API calls, unused code (which I didn't know it was unused), environment creation, testing, backup-ing, playing with prod (which I didn't know was prod)... That means a lot of different technologies, in different contexts. I was happy to have 12 years of experience and being able to fluently read most of the files in there.

In the meanwhile, new code has to be released, and bugs have to be fixed. It's not like the company is stopping its activity because the CTO has to understand it all.

This amount of work was quite impressive at first, and scared me in some situations.

1. It's interesting work

I found very interesting to dive into entire projects. Mistakes were made, most of them understandable given the context (of a small startup) and good decisions were made as well. I learned from all of these situations. I started to be able to understand decisions not only from a technical perspective, but also from a business one. Bad technical decisions can be good business ones (and vice-versa?). In other terms, creating tech debt is not necessary a bad thing for the business, as long as the debt is known, documented, and at some point reimbursed!

Another interesting part is to be close to the strategic orientation of the business. In my case, the product is very tech-centered. This creates a strong dependency between business and tech. The business will go were the tech can bring it. The strategic discussions resulting from this fact are very interesting, and I was missing them while a developer. The perspective it brings is enlightening.

2. It's a lot of non-tech work

I was very frustrated at the beginning of anything that would not be related to coding. I really thought I was loosing precious time to achieve more. To a dev, meetings, HR, debates, documentation is a waste of time. For a CTO, it's the regular job. For a dev to be efficient, some people around him or her must make it possible and the CTO is one of them. Being able to estimate (roughly) and take a decision means discussions, meetings and a lot of information. I slowly accepted that and reduced dramatically the amount of code I was able to deliver, unfortunately. I don't find it a waste of time any more.

The frustrating part is to be able to know and decide without understanding the full stack perfectly.

3. The "how long will it take" question

This is always a difficult question to ask an engineer, because it depends too much on too many parameters. And this is not an practical answer to any decision-maker. To answer this question means to start building a solution, or to be more accurate to architecture it. That is when business meets tech: the way to build it depends on the business orientation, and vice-versa. Still, this question is crucial to any CEO, and answering it means to me:

knowing the current stack perfectly
creating a couple of realistic architectures (sometimes in seconds during a meeting)
saying: "it depends" 😂 And detailing the one or two good options.

The CEO knows enough of the history of the stack, the people involved and the tone of my voice to take action. At early stages, "long and difficult" or "short and easy" are good enough answers. The "quick and dirty" can occasionally be a good one, although never the one I prefer...

4. There is a lot of HR

When a developer or a contractor says he/she is leaving, that means to me: "I must find about 20 hours in the next months to handle this situation". Indeed, preparing the leave, looking for someone, checking the skills, onboarding, checking the skills again... takes a lot of my time. And this time is very fragmented. I find interesting to dig in profiles, meet new people and build a team, but the amount of work related to it is almost prohibitive.

When people are not leaving (most of the time!) I take a little time frequently to address 1-to-1 chats. It helps create a stronger relationship, especially in a full remote team like ours. At first I looked at it as a waste of time, but I now see the value and enjoy it. I am never busy enough to skip 1-to-1s with my devs.

HR includes also career consideration. Developers are not here just to execute work written on Trello cards. Their experience, personality and goals in professional life are always important. Knowing them one by one is a long process, but a necessary one. I must find the win-win situation that empowers both each individual and the company. Accurately knowing one team's skills at one time is also a precious information for business orientation.

Having such responsibility of team is something I did not expect this way.

5. Every day is very different

I really miss my long hours of development and building of a cool feature, or even refactoring! On the other hand, my days are very different from one to the other. Having to interact with the CEO, the Product Owner, the Project Manager, the testers and the developers during a single week is enriching. They all have skills that nurture me. It also requires very strong organizational skills.

Considering the relatively small size of my team, I must perform additional tech tasks that nobody else would do. Not because they lack the skills, but because we pay them for something else. For instance, I am the main DevOps and the one who pushes to prod every week, and I am the one architecturing new product-wide features.

6. This is a humble journey

I think that any of the devs in our team could do my job. I can barely do theirs now. Gathering information and talking to people did not seem like a real skill to me... It is. There are many situations where I just "don't know". I say it humbly when it happens, and I understand my job is often to "know" in a reasonable time (ASAP). This instability is very scary at first, and more than once I trembled to estimate, push to prod, or meet with an important person. Confidence is growing in me.

I really enjoy the journey so far, and I really think it was a good time for me to embark. Joining a "small project getting bigger" was a relevant situation for me to become a CTO.

Optimizing Slack communications

Mickaël A — Sat, 17 Oct 2020 13:17:09 +0000

You've probably noticed it, Slack has become an omnipresent tool in the corporate work place. For people like me, on a computer for the past two decades, it's just another chatting application in the work place: useful and invasive. It's probably more useful than any app from the previous generations, though. And definitely more invasive.

Use threads

Slack is beeping so often that when one comes back to read what's up, threads will help digging into conversations (and referencing them) and skip the useless ones.

Don't just ask "Hey, how are you?"

Most professional conversations are asynchronous. It means the other person is not on Slack waiting for your message. If you want to ask something, do so in your first message (you can still say "Hey, how are you?" in the same message) and if you need an attention for a conversation just say it like: "Hey how are you? Do you have some minutes for me (on Slack) to sort something out?".

Never use `@here` or `@channel`

I never found a good use of these mentions. In an actual workplace that would be standing up, call everyone out loud and gather them in the same meeting room and then ask your dramatic question: "where is the document titled Best Practices?". It is very rare that emergencies actually impact everyone in a channel, and I believe true emergencies as rare as well.

Just target people one by one. A channel is already a place to warn every one at once, all of them will see your message anyway, that is why they belong to the channel.

Configure your Slack

You can read How I Configure Slack for Productivity and Sanity on DEV.

Group your messages into one

It is annoying to receive 10 messages because you're slacking out loud. There is a cool feature that allows you to edit previous messages. Rather than piling up on new information one line after the other, just edit the previous message (up + e) and add new lines in it. When your conversation partner will come back from the toilets he/she will see one notification, not twenty eight.

Don't say `Thank You` or `OK` on old conversations. Use emojis

Emojis is a cool feature, because it is carrying information in a fun, discreet and efficient way. If someone said something cool one hour ago, don't come back from your lunch typing "OK". It will reactivate the conversation, while the sender is on to something else, and completely forgot about this. Reading an "OK" notification will disturb him/her bringing very little information. It's good to know you've read it and approved by reacting with an emoji.

Do not organize meetings on Slack

Asking for time availabilities is boring and useless. Shared calendars offer this feature. Use it! Ask me on Slack when I'm available and I will probably answer you: "Check my calendar".

Don't mention people in the `#random` channel

This channel and similar ones are for fun, relaxed and non-important information. Do not disturb people in these channels. Mention them without the @ so maybe later they will see it and react to it. Or not. It's fine. It's just #random.

Use emails

I read that the whole point of Slack is to suppress email. I disapprove. Emails are still useful especially for longer asynchronous conversations. If you expect the receiver to take time and to think before answering you, spare him/her some time from Slack and send an email. It is implicitly accepted that Slack is used for quicker interactions, and not all professional interactions need a quick answer.

Do not over-communicate

It is true that remote work needs more communication. Nevertheless, one needs to spare others' time and do not constantly share everything on Slack, all day long (you can use Tweeter for that). Subtly, things will slow down and let your team focus on a more important thing: work.

All that said, I am happy to use Slack rather than Skype, Messenger or ICQ to chat with friends or colleagues. It is an amazing product with a lot of great features. It is just too easy to let practices drifting away and spend too much time on Slack.

Happy slacking!

Using PHP xdebug in a Docker with Netbeans

Mickaël A — Sun, 04 Oct 2020 15:38:11 +0000

There are quite some guides around to connect xdebug-docker to PHPStorm, or xdebug to netbeans... but not a lot regarding xdebug-docker and netbeans. After struggling I managed to find a way. Here is how.

Configuring docker

The Docker image must have xdebug installed. I use the following lines to do so:

FROM php:7.4-cli
[...]

RUN pecl channel-update pecl.php.net && pecl install xdebug-2.8.1 \
    && docker-php-ext-enable xdebug

Running the image

After building you docker image (above is just an extract, you may need many other things for your project), here is how I run it. And here is where I struggled most...

docker run \
  --name=project_name \
  -v /home/me/dev/project/xdebug.ini:/usr/local/etc/php/conf.d/xdebug.ini \
  -v /home/me/dev/project:/home/me/dev/project \
  --rm \
  --env XDEBUG_CONFIG=\"idekey=my-ide-key\" \
  --network=host \
  -ti my-docker-img bash

The first -v option is copying a local xdebug.ini file inside the docker, at a location it will be read by PHP. From my image inherited from FROM php:7.4-cli, I know the folder /usr/local/etc/php/conf.d/xdebug.ini will do.

This is a flexible way to play with parameters in your docker PHP config. Expect this will not work from the first time...

In my case this xdebug.ini file contains:

xdebug.remote_enable=on
xdebug.remote_autostart=off
xdebug.remote_host=127.0.0.1
xdebug.remote_log="/tmp/xdebug.log"
xdebug.idekey="my-ide-key"
xdebug.remote_port=9123

These are the required minimal configuration. I highly suggest to use a remote_log parameter, because if it fails, it's where you'll have valuable data.

The idekey will be used in Netbeans as well as the remote port.

The line -v /home/me/dev/project:/home/me/dev/project is also very important. Your project file names and directories inside your container must be the same as your host architecture. If not, Netbeans will stop but will be unable to show you the actual line.

The line --env XDEBUG_CONFIG=\"idekey=my-ide-key\" is kind of duplicate of the xdebug.ini configuration xdebug.idekey="my-ide-key"... This parameter needs (also?) to be an environment variable, so don't forget it.

The line --network=host is also very important. It means that the xdebug.remote_host=127.0.0.1 will also be the host IP. Otherwise, xdebug will be stuck inside your docker and unable to talk to the Host, where Netbeans sits.

In your docker, check your xdebug parameters are properly set by using the command php -i | grep xdebug. You will see such an output, reflecting your configuration (and the configuration used the next time you use the php command):

...
xdebug.remote_enable => On => On
xdebug.remote_handler => dbgp => dbgp
xdebug.remote_host => 127.0.0.1 => 127.0.0.1
xdebug.remote_log => /tmp/xdebug.log => /tmp/xdebug.log
xdebug.remote_log_level => 7 => 7
xdebug.remote_mode => req => req
...

If it looks OK, carry on, otherwise fix your config first.

Configuring Netbeans

This is the easier part. Go to Tools | Options | PHP | Debugging.

Make these parameters match the xdebug.ini config in your docker, as visible on the picture (fields Debugger Port and Session ID)

Launching your debugging session

In Netbeans, click on the following icon (or ctrl+F5):

Place a breakpoint somewhere in your application, as early as possible (or use the Stop at first line option provided by Netbeans, as visible in the screenshot above).

breakpoint (red square) set at line 63 here

In your docker launch a PHP command, like php bin/phpunit.

The command will stop, and Netbeans will be stop at the required line. BINGO!

The debugger stopped here (green arrow)

Basic debugger use

The most useful commands to me are the following one (step into, go to next instruction etc.)

And the Variables and Call Stack panels. You can display them from the Window | Debugging menu if they don't show up automatically.

Troubleshooting

Make sure your configuration is active

php -i | grep xdebug is a good start. If you don't run your project with the php command, be sure (by displaying a phpinfo() for example) that the xdebug.ini is applied, e.g. in a place which is considered by your PHP executable.

Read the logs

If you copied my documentation, there should be a logging file, inside your docker, at the location: /tmp/xdebug.log. Read that!

Check the xdebug.ini parameters match the Netbeans ones.

I am sure you checked it 10 times but who knows...

Forem: Mickaël A

Drawing 3D lines in Mapbox with the threebox plugin

Setting up the scene with Mapbox

Adding 3D terrain

Adding my GeoJSON track to the map

Make this line 3D

Adding threebox to the equation

Drawing in 3D

Drawing the GeoJSON data

Displaying a shadow

Conclusion

A Metric for Technical Debt

Main features of the metric

About the metric value

Why managing technical debt is important?

Conclusion

8 unexpected tips for remote workers

Dealing with Code Legacy

Refactoring projects

"The big rewrite"

Code legacy is also good

My experience with Dual Boot Windows/Linux

Linux (still) has trouble with my hardware

Small hiccups with Linux

My Windows OS is very efficient

For coding, Linux is far more better

My screen is so beautiful...

Dual boot is the ideal solution for me

A shared partition

Conclusion

From programmer to CTO. A journey

It's hard work

1. It's interesting work

2. It's a lot of non-tech work

3. The "how long will it take" question

4. There is a lot of HR

5. Every day is very different

6. This is a humble journey

Optimizing Slack communications

Use threads

Don't just ask "Hey, how are you?"

Never use @here or @channel

Configure your Slack

Group your messages into one

Don't say Thank You or OK on old conversations. Use emojis

Do not organize meetings on Slack

Don't mention people in the #random channel

Use emails

Do not over-communicate

Using PHP xdebug in a Docker with Netbeans

Configuring docker

Running the image

Configuring Netbeans

Launching your debugging session

Basic debugger use

Troubleshooting

Make sure your configuration is active

Read the logs

Check the xdebug.ini parameters match the Netbeans ones.

Never use `@here` or `@channel`

Don't say `Thank You` or `OK` on old conversations. Use emojis

Don't mention people in the `#random` channel