I asked another young professor whether one could use “I” and she said “Only if you want to sound like an arrogant bastard”, and observed that only old people with established reputations can get away with it.
- Make finally a uniform and nice vim/bspwm/… keybinding system.
- Learn vim formally, all movements and everything, and get rid of my “vim antipatterns”
- I should create additional vim maps for a better way to access other registers. I should create at least one more p/y/yy/d/dd commandd set for them and keep them separatee from the main ones.
- Or just let vim have it’s own copy/paste registers and make pasting the OS ones a special case
- Formalize my Sprint reviews.
- Three works a week of PI – how do I actually keep track of this? I need an infrastructure.
- Remember that Eisenhower Matrix is a thing and that it used to help me quite a lot before.
- I should formalize all the checklists I created for myself and use them.
- Look into Energy Management vs Time management
- How to design APIs is a nice description of things to keep in mind.
- documenting apis, also this
- examples of well-desgined REST APIs on HN.
A Python config file is excellent. qutebrowser/configuring.asciidoc at master · qutebrowser/qutebrowser · GitHub For now this, then we’ll see:Read more...
Resizing/converting/… a video with ffmpeg
ffmpeg -i input.mkv -s 640x480 -c:a copy output.mp4
Using I/we/passive in a Bachelor’s thesis
No easy answer, but I liked here the joke “In your particular case, an inclusive we could be used to recognize the nematodes collaboration :) – Dr. belisarius May 10 ‘11 at 13:01”
“I’ve come up with a set of rules that describe our reactions to technologies: 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3. Anything invented after you’re thirty-five is against the natural order of things.” — Douglas AdamsRead more...
Scratchpad with the DTB in bspwm
If it starts appearing on the wrong monitor, I can drag it to the right one, and its location will be remembered.Read more...
There are two sorts of comments - “What” comments and “Why” comments.
“What” comments tell you what the code is doing. In a lot of cases, depending on the language, the need for these can be reduced by writing clear code. This is much easier in, say, Python than Assembly. Even in Python though, sometimes you can be doing something a bit subtle where a 2 line comment can clear things up. These comments aren’t irreplaceable because with a bit of reading and work, you have all the information to work out what is happening.
“Why” comments are much more important - telling the reader WHY the code is doing whatever it is that it’s doing. The ‘trim()’ comment referenced in the article is a great example of a Why comment - all the reading around the code wouldn’t give you an explanation (although sometimes git blame will).
Many ‘what’ comments are superfluous, almost no ‘why’ comments are - they are the collective memory of design decisions that otherwise lives in people’s heads. (HN)
Technical writing errors
3 shell scripts to improve your writing, or “My Ph.D. advisor rewrote himself in bash.” is an excellent description of typical errors in technical writing. One of the pages I see that make me want to archive everything linked here and on the Link Wiki just in case it disappears. Also,
In that sense, peer reviewers are the guardians of the scientific community’s most limited resource: our collective attention span.
Firefox Vimium switch to tab N
Added the following to the Vimium settings, now I can switch to tab N by pressing the respective number on the keyboard:Read more...
LSD and installing fonts in st and urxvtRead more...
Bash dtb create.sh script
Updated the script to create a markdown dtb file to the following:Read more...
After another small pause, here comes another längliches post!Read more...