Skip to content

Instantly share code, notes, and snippets.

Nicolas uucidl

Block or report user

Report or block uucidl

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
uucidl /
Last active Nov 17, 2019
Profiling and data analysis resources


Looking at software from a different angle as done during profiling and data analysis has numerous benefits. It requires and increases our understanding of the problems being solved by the software. It exposes us to unexpected discoveries and insights. It allows us to suggest improvements.

Since there is a great element of skills involved, and it is rarely taught in Computer Science degrees, the role of practice is very important to gain the necessary skills.


Ex1: sequential processing

uucidl /
Last active Oct 24, 2019
The Problem Of UI (User Interfaces)
uucidl /
Last active Oct 24, 2019
Notes about compilation time

On the emergence of interfaces

Interfaces naturally emerge as software gets broken down into parts communicating with one another. The larger and more deliberate structures emerge from a deliberate attempt to organize the development process itself. [fn:Liskov2008] Structure often emerge directly from division of labor: as teams take on independent tasks, interfaces are established betweeen domains they become responsible for. (Conway’s Law)

Software developers are responsible for systems built out of very small atoms while ultimately performing tasks for their users of a much greater magnitude. Dijkstra showed this by computing the ratio between grains of time at the lowest and largest atoms of the system (from say, CPU instructions to a human interaction with the system) The span was already quite large by Dijkstra’s time, of about 10^9. Today this ratio would be at least above 10^12 (see grain ratios)

This large span has to be manage

uucidl /
Last active Jun 18, 2019
Language Specific Pitfalls And Things Not To Do Again


Don’t create generators with side effects:

import contextlib

def my_nice_context():

Bitwise Day 62: Indexed Arrays

Per worked 20h since Day 61.

How do we get a good story for dynamic arrays? What we called stretchy bufs (buf_... API)

Added many new intrinsics to gen_intrinsic:

  • apush, kadd, kdget, kdel
  • hget, hdel
uucidl /
Last active Jan 22, 2019

Example devices:

  • Inkbird IBT-2X


  • @ConnectTimeout: 60 seconds

  • @BatteryPollingInterval: 5 minutes

The iBBQ is a Bluetooth LE Gatt Device


Sophistication in programming languages has diminishing returns.

I treat programming language features like I treat drugs. They come with side-effects, which I want to be aware off before even thinking of putting them into use. And if in doubt, I’d rather not use them.

For an alternative take, legions of programmers write online about the features they want to have in their language. Is it based on actual experience rather than wishful thinking? Is it based on their own introspection of what’s producing defects or harming progress?

View bwdit-counter.c
#include <stdio.h>
// Shows how to iterate backwards in C. (Counter version)
int main(int argc, char** argv)
{ int c = argc; while (c--) {
printf("%s%s", argv[c], c == 0 ? "\n" : ", ");
} }

Problem Domains For Which Many Create and Publish Their Own Solution

I find that certain problems attract the creation of many solutions. We are overwhelmed with slightly similar yet incompatible and potentially incomplete solutions.

Why is that so? Which domains show this pattern?

My hypothesis is that these problems seem easy to approach from one idiosyncratic perspective while at the same time being hard to complete. Therefore no-one’s satisfied or able to judge existing solutions and end up creating yet another one.

In certain domains, incumbent solutions also may appear bloated, and therefore it’s easy to think one can do better, because the 50% solution appears leaner. Problem is, the remaining 50% is where the necessary risk mitigation, adaptation is. An example of that is the appearance of poorly made (but lean) databases in the age of NoSQL, which claimed to be leaner just because they did not discover yet all the things their historical competitors had discovered they had to do.

You can’t perform that action at this time.