Hier ein Kreuzworträtsel, dass zum Beispiel verwendet werden kann, um die Bewerberanzahl bei einer WG-Besichtigung zu reduzieren 😉. Das Kreuzworträtsel wurde mit dem Python-Kreuzworträtselgenerator genxword erzeugt. Viel Spaß beim Rätseln! Download als .pdf hier.
This blog is supposed to be a collection of random, unrelated, little ideas, thoughts, and discoveries, which I assume to be helpful to a negligible part of the world's population and wish to share out of pure altruism. If posts appear really weird, maybe you have the wrong kind of humor. Many of the posts are science/technology related. If you are opposed to that, stop reading here! Comments, criticism, corrections, amendments, questions are always welcome.
2016-11-16
2016-10-21
Simple Experiment on Git Scalability
Have you ever experienced big git repositories growing slow? I was curious to learn more about the scalability of git and ran the following simple experiment:
In a script I made 300 commits and in every commit I added one file with random data to the repository. Moreover, I randomly changed one of the existing files. Then I checked out the old commits in a non-consecutive order. The time for every git operation (git status, git add, git checkout) was measured and is visualized in the following plots. The time required for git commit is negligible in comparison to the other operations and it is therefore omitted in the plots. The size of the file that was added to the repository in every commit was varied in different runs of the experiment (80 chars x 100 lines, 80 chars x 1000 lines, 80 chars x 10,000 lines). The times presented for git checkout are averaged over the times required for the checkouts of all the individual commits.
The experiment was run in a ramdisk in order to decrease the time required for the overall experiment. I assume that the measured times presented here are higher by a constant factor (~10) for git use with a hard disk.
In the first run of the experiment with 'small' files (80 chars x 100 lines) the operations git status, git add and git checkout seem to scale very linear with the number of commits.
In the second run of the experiment with 'medium' file sizes (80 chars x 1000 lines) more noise on the times required for git add and git status is observed, which make it a bit hard to identify an overall trend. Interestingly, the time required for git add and git status seem to scale constantly for 'large' file sizes (80 chars x 10,000 lines). The average time required for git checkout seems to scale very linearly in all three runs of the experiment with the number of commits in the repository.
In the second (third) run of the experiment the file size is increased by a factor of 10 (100). As can be observed from the plots, this increases the general times measured for git checkout, but only by a factor of ~3 (~6).
The Python scripts that were used for the experiment can be downloaded here. Git version 2.7.4 was used for the experiment.
In a script I made 300 commits and in every commit I added one file with random data to the repository. Moreover, I randomly changed one of the existing files. Then I checked out the old commits in a non-consecutive order. The time for every git operation (git status, git add, git checkout) was measured and is visualized in the following plots. The time required for git commit is negligible in comparison to the other operations and it is therefore omitted in the plots. The size of the file that was added to the repository in every commit was varied in different runs of the experiment (80 chars x 100 lines, 80 chars x 1000 lines, 80 chars x 10,000 lines). The times presented for git checkout are averaged over the times required for the checkouts of all the individual commits.
1. File with 80 chars x 100 lines added to the repository in every commit. |
2. File with 80 chars x 1000 lines added to the repository in every commit. |
3. File with 80 chars x 10,000 lines added to the repository in every commit. |
In the first run of the experiment with 'small' files (80 chars x 100 lines) the operations git status, git add and git checkout seem to scale very linear with the number of commits.
In the second run of the experiment with 'medium' file sizes (80 chars x 1000 lines) more noise on the times required for git add and git status is observed, which make it a bit hard to identify an overall trend. Interestingly, the time required for git add and git status seem to scale constantly for 'large' file sizes (80 chars x 10,000 lines). The average time required for git checkout seems to scale very linearly in all three runs of the experiment with the number of commits in the repository.
In the second (third) run of the experiment the file size is increased by a factor of 10 (100). As can be observed from the plots, this increases the general times measured for git checkout, but only by a factor of ~3 (~6).
The Python scripts that were used for the experiment can be downloaded here. Git version 2.7.4 was used for the experiment.
2016-09-17
Installing Maps on a Garmin Etrex 30
I use a Garmin Etrex 30 for outdoor navigation and Geocaching. Amazingly detailed maps can be downloaded as compatible Garmin images on this Openstreetmap website.
I have found the USB connection of the Etrex 30 to be a bit shaky. The Garmin image files can be quite large (~Gigabytes). Copying the files can take some time and it also gets stuck occasionally. If a corrupt Garmin image is written to the device, it will not be recognized on it.
A simple way to alleviate this problem is by using rsync for the synchronization. It will still take quite some time, but rsync makes sure that the images are copied correctly. Here is an example how to use rsync:
rsync --progress gmapsupp_germany.img /media/path_to_my/GARMIN_micro_sd/Garmin/
I have found the USB connection of the Etrex 30 to be a bit shaky. The Garmin image files can be quite large (~Gigabytes). Copying the files can take some time and it also gets stuck occasionally. If a corrupt Garmin image is written to the device, it will not be recognized on it.
A simple way to alleviate this problem is by using rsync for the synchronization. It will still take quite some time, but rsync makes sure that the images are copied correctly. Here is an example how to use rsync:
rsync --progress gmapsupp_germany.img /media/path_to_my/GARMIN_micro_sd/Garmin/
2016-01-31
Simple Backup Script
Here is a simple backup script using Duplicity:
#!/bin/bash #install duplicity: #sudo apt-get install duplicity #sudo apt-get install python-pip #sudo pip install paramiko export PASSPHRASE=MYSECRETPASSPHRASE duplicity --num-retries 20 /home/myHomeDir sftp://USERNAME@MYSERVER//home/myHomeDir/duplicity unset PASSPHRASE #amend the following to your crontab for regular backups at 3.am (issuing 'crontab -e') #0 3 * * * /path/to/script/duplicity_backup.sh
2015-09-06
QR codes for wireless lan access
Do you share your wireless lan with friends and family and still want to maintain a policy of frequently changing your wireless lan password? They might find it tedious to type a new password into their mobile devices on every visit.
A way to make this more convenient is to use a QR Code, which can be scanned to make a device connect to your wireless lan automatically. This actually works for many mobile devices, especially Android smartphones.
A simple Python script that can be used to create such a QR code can be downloaded here. It requires qrencode and Imagemagick. An Android QR code reader, which I have found useful is Barcode Scanner.
The script generates a printable pdf that looks like the following:
A way to make this more convenient is to use a QR Code, which can be scanned to make a device connect to your wireless lan automatically. This actually works for many mobile devices, especially Android smartphones.
A simple Python script that can be used to create such a QR code can be downloaded here. It requires qrencode and Imagemagick. An Android QR code reader, which I have found useful is Barcode Scanner.
The script generates a printable pdf that looks like the following:
2015-07-10
Find the shortest path to lift-off!
Can you solve the riddle (pdf version here). The sha256sum of the solution is 38700dfad5711976e2f7aeab31013f04aed8c83118a1ef892f6d23bdfe94460. Good Luck!
2015-05-29
Legible Plots with Matplotlib and LibreOffice
Have you ever struggled presenting scientific plots in LibreOffice? A lot of the time the fonts come out too small or it can happen that thin lines disappear in scaled figures. Often plots are not originally created to be shown on slides. A pragmatic solution to create more legible plots with Matplotlib for LibreOffice slides is to take the dimensions that a plot should have on the final slide into account when creating the plot.
LibreOffice offers 12 standard layouts, as can be seen below:
Not all of these layouts are suitable to present plots, but for those who are, the dimensions of the layout boxes should be taken into account to create legible plots. E.g. in Matplotlib this can be accomplished with the following command:
matplotlib.rc('figure', figsize= [width,height])
Moreover, it is advantageous to modify some other style options to make a plot more legible. Some style options which I found helpful in the past are the following:
matplotlib.rc('lines', linewidth=4.0) #thick lines
matplotlib.rc('font', size=18) #big font
matplotlib.rcParams.update({'font.sans-serif': 'Liberation Sans'}) #adjust font w/ slide font
In my opinion .png is one of the few trustworthy output formats for plots. Generally producing plots in vector formats (e.g. .svg) would be nicer, but at least I have experienced these being rendered incorrectly (LibreOffice 4.3.6.2 was used at the time of this writing).
An example slide with these style options applied is shown below:
The full script that was used to create the sample plots can be downloaded here. It can also be used to create sample plots for the other LibreOffice layouts.
LibreOffice offers 12 standard layouts, as can be seen below:
Not all of these layouts are suitable to present plots, but for those who are, the dimensions of the layout boxes should be taken into account to create legible plots. E.g. in Matplotlib this can be accomplished with the following command:
matplotlib.rc('figure', figsize= [width,height])
Moreover, it is advantageous to modify some other style options to make a plot more legible. Some style options which I found helpful in the past are the following:
matplotlib.rc('lines', linewidth=4.0) #thick lines
matplotlib.rc('font', size=18) #big font
matplotlib.rcParams.update({'font.sans-serif': 'Liberation Sans'}) #adjust font w/ slide font
In my opinion .png is one of the few trustworthy output formats for plots. Generally producing plots in vector formats (e.g. .svg) would be nicer, but at least I have experienced these being rendered incorrectly (LibreOffice 4.3.6.2 was used at the time of this writing).
An example slide with these style options applied is shown below:
Subscribe to:
Posts (Atom)