BaSzErr - blog:2020:10:23

2020-10-23_-_brand_new_legacy_code

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:27 +0000

2020-10-23 - brand new legacy code

this post is already couple of years due. but i think it is worth to tell this tale.

back at that time i was working in a project, that had a chance to define a brand new interface. totally from scratch. no legacy, no backward compatibility – whatever the person responsible for it will decide, will get implemented. rare occasion and a great moment in project's history.

the only real requirement was performance when sending large data blocks. so what could go wrong here? designing detached from reality when author of the specifications started to do changes without any experiments or measurements.

after initial draft (“message level”) it came down to encoding and transmitting. this was a moment in time where “optimizations” started to kick in. nevermind the details – mostly loads of pointless “what if” discussions, that had no support in any data. just a “strong feeling” that it will be better. however noting is for free. each of these “optimizations” added complexity and some extra states into (otherwise fairly straight forward) specification.

as you can imagine, it backfired within a year time window. extra steps turned out to be complex and error prone. this in turn caused endpoints to go out of sync, on random occasions. these issues were often non-reproducible, and timing related. after having agreement between two ends of the communication channel, the spec was pretty much set in stone.

the interesting part was to see that when deployed, the protocol had zero issues with performance. just for the sake of discussion we also stubbed the implementation with “naive” one – it did not even sweat! all the pain (discussion, extra implementation, countless bugs and nerves) – in vain. due to lack of proper measurements, that would support decisions to increase complexity, the team ended up with brand new legacy code that they had to maintain.

more over – planned ultimate-flexibility of the protocol failed, too. in fact the very first change in requirements that arrived blew the root concept apart. it just happened to hit the part of the protocol that author assumed will never change. to fix it even more extra states were needed, with even more potential for errors. on the other hand, the parts that were made flexible enough to accept any possible input, were never really needed exercised. both KISS principle and open-closed principle were violated here and it did not took long to see the results.

avoid over-engineering and bikeshedding. when making sth new stay focused on the problem you are solving. support your decisions with actual measurements. use prototypes / PoCs to help guide your research.

2020-10-23_-_limiting_code_line_length

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:27 +0000

2020-10-23 - limiting code line length

some time ago i came across an article / discussion if it is still reasonable to stick to 80 characters per line, when writing a source code. argument is fairly simple – 80c is a magic number, that happened to be a number of characters that one can fit on the text console in '80s and '90s, text-mode (so that you do not have to scroll). we now have 2020, full-HD or 4K wide screens. so why bother?

there is one more thing, though. when we read and need to skip to a new line, and the line is too long, we have trouble locating where the beginning of that new line is. this is no accident that newspapers are big, yet still feature multi-columns – it is just easier to read.

this is also sth that trikes my nerve about dokuwiki i use here – lines can be just too long and annoying to read. i do plan to fix it – it's one of the “it will happen one day” projects.

so shall we back to 80c? i'd say no – 80c is arbitrary and fairly low, if you try to use descriptive names. also code is not a typical text. lines are not of an equal length. very often there are lines with just braces / parenthesis. this makes lines switching significantly simpler for human brain.

my personal rule of thumb is to try to keep it below 120c. on rare occasions i allow myself to reach up to 160c. otherwise i just break lines, introduce helper functions, etc.

in fact – this is how i typically work:

i use dual screen setup: primary screen is horizontal while secondary i pivot to vertical. i edit code on secondary, so that i can benefit from seeing more context (more lines) at the expense of line lengths (which is still over 160c, thus more than enough for me). primary screen serves as a compilation output and/or documentation preview.

on top of this i use 20+ workspaces, to arrange my windows contextually. i3 tiling window manager of course, to minimize keyboard-mouse shifting.

over the years i found this setup to best suite my needs. YMMV, but please keep line lengths readable while not being 80c orthodox. there is a middle ground, that gets best out of both worlds.

2020-10-23_-_screw_it

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:27 +0000

2020-10-23 - screw it...

i'm working on a pet project. it actually already spinned off a couple more child projects. one of them i hope to cover shortly. as a part of this effort a needed to screw down one part. thread was M10. i'm always using metric screws, in couple different sizes (depending on length / strength / weight parameters): M2, M3, M5, sometimes M8… and do so for many years now. this time i needed M10, which is much bigger than i typically use, but still – the same standard. so i made a trip to the shop just to buy two nuts and washers – around 0.2EUR total. when i got home, it turned out that the nut does not match thread!

i suspected that it was not M10 but instead some imperial-rooted thread, that some1 accidentally rated as M10. but no – i checked multiple sources and all of them reported it as M10. so i did some reading and when i was finally able to “ask the right question” in the growser, it turned out that for standard metric system screws, you can have different thread pitches: coarse (“default” one, if not mentioned otherwise) and fine (that in turn can also come in a couple flavors).

the notion i was used to was eg. M10x50, which reads: M10 screw (i.e. 10mm diameter), 50mm long. this is the coarse pitch – default one. for M10 it is 1.5mm pitch, thus the full marking would be M10-1.5×50. for “fine” threads of M10 you can choose among M10-1.25 and M10-1.

“the good news about standards is that there are so many of them to choose from”

Andrew Tannenbaum

now i need to go back to the shop and look for more M10s, but with a (new measured), non-default pitch: M10-1.

2020-10-23_-_sudo_bash

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:27 +0000

2020-10-23 - sudo bash

yes – as a rule of thumb you should not make scripts SUID. same for bash and other shells. there are however times, you do know what you're doing and / or it is ok to hack a bit to make it work “here and now”.

fun fact – if you do

sudo chmod u+s /bin/bash
bash

you'll not have root. bash will detect that and drop privileges on its own.

there is however a workaround – if you're absolutely sure you know what you're doing, you can go for

bash -p

this will tell bash to ignore this safety feature and run shell SUID, as requested. so you can do this, but it has to be explicit. IMHO nice balance between staying secure by default and allowing to do crazy things, when needed.