Skip to content

programming

Let's kickstart the end of 2025

Revival or returning to writting

Initially, this blog was created over 6 years ago, a bit before COVID at a time I thought would be great to share fresh ideas I had. I was building a BI application with open source software and learning the ropes on some infrastructure as code.

Then, I was also perhaps a bit lacking in quite a lot of area in IT, but I had a sharp mind for programming. Now I have learnt a bit more but I am STILL lacking in quite of lot of area in IT, data processing; governance, security... Well nobody's perfect.

The issue is that over the past 2 years, AI and LLMs are everywhere, suggesting code to programmers, compiling notes, being talked as the new frontier in technology and a revolution. There is something to learn in that space and maybe this is the place where I'll start to write.

A page is turning at the end of this year, and I am reviving this blog for that. Let's see how far I can take it.

A tale of 2 tables

There are 2 types of users of table:

  1. One that quickly look at it to find its information and move on
  2. One that works extensively with the table

While most UI guides online recommend a lean design, without the clutter of a big table with numbers, I will explain how to design a simple html table for power users.

A. Who ? Why ?

If you want to design applications for:

  • accountants
  • meteorologist
  • or anybody needing to look at a lot of number

They will need to have all of them in front. That means that you need to think about how to display efficiently and nicely a table with a lot of data.

At that point, nice UI and neat presentation are not on the agenda, when you work 8 hours on tables and data, you need to be efficient and not to scroll endlessly to access what you want or worse, have to constantly filter all the data you are interested in.

This example of RefactoringUI is for me a bit too reductive, and can apply to quick view of your website or limited data interactions. Notice the increase in size of the table too:

refactoringUI table

This to me, is a perfect table for a website that doesn't require a lot of interactions with tables. Think of something like a reservation for a hotel or booking your flight tickets. But not for spending time on it.

B. FiveThirtyEight ft. Michael Jordan

Usually you will find big tables on specialised platform and enterprise software. However I found that https://fivethirtyeight.com/ has actually done the best job in terms of table design ! And for a a news outlet.

Here is an example from their website, which does a good job at big tables, look at cropped example in a Michael Jordan's article : Why Michael Jordan Was The Best

FiveThirtyEight Jordan

While here we are looking at a table of a news website, we can derive a good idea to build our own tables. This is enough for making something readable and with a lot of information.

Let's dive into our interpretation.

C. Do you want to build a table ?

I will expand from the FiveThirtyEight example and show my interpretation of a good table.

One of the few good features to display a lot of data is to merely... Have a smaller cells and letters, so I would recommend to reduce the font size of the table (use the rem unit to scale them depending on the size of your website font size):

table {
    /*Some other properties...*/
    font-size: 0.7rem;
}

In general I like the idea of having the head of the table as uppercase words and maybe slightly bigger to make them stick out better, so nothing too complicated, we can just style the head of the table with this:

th {
    /*Some other properties...*/
    font-size: .8rem;
    text-transform: uppercase;
}

To top it, here, nothing too fancy, just a hover with a slight alpha layer on the table rows. We want something to be applied only to the body of the table and have neat table rows. And voila:

tbody>tr::hover {
    background-color: rgba(155,155,155,.2);
}

And here is our table:

Date Open High Low Close Adj Close Volume
2020-03-19 19900 20393 18834 19853 19853 239922
2020-03-20 19583 20882 18825 19875 19875 285733
2020-03-22 18504 18507 18086 18238 18238 204991
2020-03-23 18230 19804 18088 18745 18745 119535345
2020-03-24 18987 20943 18925 20511 20511 106863898
2020-03-25 20446 21892 20279 21100 21100 130872632
2020-03-26 20998 22545 20510 22492 22492 123364604
2020-03-27 22123 22321 21316 21410 21410 98666789
2020-03-29 20926 21244 20778 21213 21213 711107
2020-03-30 21350 22250 21153 22196 22196 82143599
2020-03-31 22204 22386 21470 21502 21502 66006634
2020-04-01 21397 21423 20648 20932 20932 82218631
2020-04-02 21030 21374 20500 21160 21160 97616148
2020-04-03 21044 21331 20740 20928 20928 63241057
2020-04-06 21647 22663 21620 22555 22555 96739993
2020-04-07 22496 23477 22300 22488 22488 274505
2020-04-08 22498 23426 22337 23417 23417 98632961
2020-04-09 23267 23889 23020 23676 23676 110699818
2020-04-12 23839 23911 23108 23331 23331 816363
2020-04-13 23295 23609 22968 23368 23368 66333180
2020-04-14 23621 23967 23534 23843 23843 75910145
2020-04-15 23757 23809 23103 23211 23211 81277443
2020-04-16 23265 24327 23079 24157 24157 94173258
2020-04-17 24239 24305 23701 24151 24151 105186538
2020-04-19 23944 24028 23917 23970 23970 284615
2020-04-20 24143 24167 23441 23530 23530 87221700
2020-04-21 23273 23433 22814 22999 22999 111731192
2020-04-23 23315 23772 23233 23282 23282 78882561
2020-04-24 23246 23460 23166 23416 23416 9038285

You can find an example in React and css at this repo: blog-posts.

You can browse the table, identify easily the rows and have plenty of data to display to your users. I think it is a great addition to the components a website could have, and especially if you design something for data savvy people.

I will expand soon on how to add interactivity with the table like pagination and filtering with react-table.

Both tables should exist, though you should strive for understanding what is beneficial to your user. Are they quickly looking for information or looking for deeper knowledge or investigating a situation ?

On breaking stuff

When I tried skateboarding one of the very first time, I heard this: when you fall, you have to to get back on the board as quickly as possible even for a few seconds. Then you can rush to the hospital. Else you will never get back on a board ever again.

Truth or not, to me this is very similar in software development.

"It works on my machine"

A classic developer quote, the code works on your machine but not in production or elsewhere. Recently, one of my builds failed while the day before it was running seamlessly.

I am using React JS, and all of a sudden the production was not working.

After updating some dependencies to new ones, i.e. Material UI from 3 to 4. This resulted in me trying things with WebPack, managing some little improvements and finally making a working development environment, BUT the production was never working and the console was displaying a:

Uncaught TypeError: Cannot read property 'call' of undefined at __webpack_require__

Something was just not working anymore, what it was, I had no idea.

I looked at documentation and StackOverflow questions, GitHub bug issues and couldn’t find the problem. Growing more anxious by the day, the development environment was working fine, sure, but the production was never working. And even some potential fix were not working. How on Earth was I going to solve that situation. I had some docker containers backed up to keep an old production working but couldn't use any newer front end builds.

Break the dev

Until came the idea of instead of fixing the prod, to just break the dev. Okay maybe it is something that many people found beforehand, but to me this sounded like a strange revolution and I didn’t know how to do it properly.

In programming, debugging is a bit like a detective work, to try to find the culprit of “who killed the program”. And just as detective work, you have proofs, but sometime they aren’t like a smoking gun and you just can try catch what is wrong.

And to break the development environment, you have to find all the switches that work in production and all the little things that make it behave the same way. Trying to find what is hijacking your production.

webpack optimisation

webpack is a formidable tool when you work in web development to be honest, I see all sort of bashing of it around the web, but god, when you get it, it is good and a bliss.

To put it simple, with webpack you can use the latest shiny tools of JavaScript and other languages and for the web and translate that to "older" JavaScript and to make it run on older and different browsers than the one you tested all on it.

Anyway, wepback has a bunch of settings that are set by default differently between production and development, and one of them is the optimisation part. Even when left out blank, some elements are going to be different between development and production.

In your module.exports, the list of the following parameters are different between prod and dev, this is the production parameters values:

optimization: {
    minimize: true,
    namedModules: true,
    namedChunks: true,
    removeAvailableModules: true,
    flagIncludedChunks: true,
    occurrenceOrder: false,
    usedExports: true,
    concatenateModules: true,
    sideEffects: true
}

And their equivalent in development:

optimization: {
    minimize: false,
    namedModules: false,
    namedChunks: false,
    removeAvailableModules: false,
    flagIncludedChunks: false,
    occurrenceOrder: true,
    usedExports: false,
    concatenateModules: false,
    sideEffects: false
}

So the there are 2 solutions possible here for solving the issue:

  1. Put everything like the development and make the production work (it works yes)
  2. Try out each elements to break the development

The first option is fine, but will result in huge builds, and is really not a good solution for a long term use.

The second solution is the best way to try things out and solve the issue at hand. What I did was taking all the development variable and progressively switch them to their opposite value until, well, the development would break.

It did, sideEffects: true was in fact causing an issue and using sideEffects: false was a solution. I wrote a quick StackOverflow answer on that issue, and I might expand on some more webpack specifities in the future.

After breaking the development I only had to switch back everything to their normal values except the sideEffects and let the optimisation do its work.

Conclusion

Breaking the development and getting it back on its feet made it much easier to handle future production break which I had subsequently. To solve problems, sometime it is better not to give up, to break, and try to get back on track after it broke.

That is not to mean that breaking your environment with webpack is equivalent to breaking your wrist while attempting a kickflip, but more that breaking the wrist made other fall more bearable once you rode your board, and breaking your setup will make you feel better about writing code again if you keep on trying.

PS: If you use containers, make a backup of previous versions so you can at least spin back an old build meanwhile, nothing is more sad than having no back up.