Parent: 2015 / 02
Prev: While working also thinking
Next: Git remotes push URL

Pills

2015/2/4

Tags: [ Ideas ]

Have domain-specific configuration files

As a shell user, you don't want to type in the paths to the correct directory all the times. Yeah, you have shell history with CTLR + R, but sometimes it may get tedious. Especially when many commands look the same, or when you do something else than working with the same machine.

My suggestion: have a per-domain file to source instead. For instance, my work-related file is named work.source. Whenever I open a shell for working purposes I simply source work.source (or . work.source). The file defines a bunch of environment variables pointing at filesystem locations, shortcuts, aliases and shell functions.

Learn about Unicode

I stumbled into this nice article. Short, to the point, worth reading. If you think that Unicode is dark magic, this will clear your mind about it.

Update:

During my Lounge Hacking session I've improved Backport with Unicode support, although still partially implemented. It's not that difficult, once you got the principles!

Cook it into abstraction

A lot of problems I'm currently facing at work boil down to (failure in) determining things which cannot be determined from raw data. Usually the code which tries to do this is bad. This is surprisingly similar to the problem everyone has with Unicode (just to stay on the topic of the previous point).

Examples:

• There's no raw text. There's (text + encoding);

• There's no raw number. There's (number + measure unit);

• There's no raw tuple with anonymous fields. There's python's collections.namedtuple;

• There's no raw \n (or \r\n, if you come from wastelands abroad). There's newline: Python's os.linesep or std::endl in C++.

• There's no raw filename and directory + '/' + file. There's Java's File class and new File(new File(directory), file). Or Python's os.path.join if you are lucky enough to avoid Java.

Functional languages are extremely good at this, because this makes pattern matching much easier: people finish in using it extensively. And this is also probably why perl (and others) have got the $ in front of variables: you can identify it as a variable by the context on the fly. It's like having a label.

This is how semantics should be defined.

I think a good programmer should avoid using raw data, and always try to have some semantic label along with it. I should think of a counter example to determine if in some cases it's better to rely on raw data.

The Unix shell is not a good counter-example. Indeed it's all about piping strings, but if program A speaks UTF-8 and program B speaks ISO-8859-15 your A | B is going to pipe some headache to you. Unless your shell is guessing it and putting an implicit filter in front of it.

So, a program should be like a well-defended castle. People (data) flow in and is recognized (decoded) frisked (sanitized) and given with a title (labeled).

Lounge hacking: Docker

Tonight I took the chance to learn (well, let's say get in touch with) Docker.

I was quite happy in realizing how the container principle fits and improves certain ideas I had in past (like using a chroot jail for certain purposes).

Interestingly I could use it for shielding my personal data (my GPG keys, SSH keys, Keyrings, ...et al) from stuff I need but I don't trust at all. First of all: Skype. So far I kept that shady one in another user, so it doesn't access my stuff. I know it would if it could. I was thinking of putting some SELinux restrictions on it, but this seems to be an even better alternative.