/usr/portage

Die Philtrat bei Zwarwald 0

Jetzt haben wir es geschafft.

Filed under , & no comments & no trackbacks

On examples 1

One thing I’ve learned is, that one of the hardest things to create are examples. Most people do not use examples as what they are, they use it as templates. So examples have side-effects. You write an example to demonstrate how a certain component works or should be used, but you did not follow the coding style of your organization unit. Developers then going to copy your stuff and bang, your errors are repeated again and again. Or, just do it like Yahoo: add a small piece of PHP for demonstration purposes and introduce a huge security problem. Here it is. Lucky for them, they seem not to use the same code in their live example.

Filed under , , , , & one comment & no trackbacks

Kotzanfall 5

Gegen so eine Scheiße ist Rosenzüchten geradezu ein Akt der Auflehnung an sich.

Filed under & five comments & no trackbacks

Is TurboDbAdmin the new phpMyAdmin? 0

It’s not that fast because of extensive JavaScript usage, but it is exactly the thing I want. I have asked myself many times, why we developers do not use the current state of web technology for our own tools. Try it!

Filed under , , , & no comments & no trackbacks

Convenient logging with procmail 0

I like to have a procmail logfile to find possible bugs in my ~1000 lines of mail filter rules. But if you get around thousand mails a day, the logfile size becomes bigger and bigger. And I always forget to remove that logfile. So I decided to let procmail do that job. I want to have a logfile structure logs/procmail/$YEAR/$MONTH/$DAY.log and I want the logfiles to be compressed daily and I want them to be kept for one month. This is how it looks like:

PATH="/bin:/usr/bin:/usr/local/bin:/usr/sbin:$HOME/bin"
MONTH=`date +%m`
YEAR=`date +%Y`
DAY=`date +%d`
YESTERDAY=`echo $DAY-1|bc -l`
LAST_MONTH=`echo $MONTH-1|bc -l
LAST_MONTH=`test $LAST_MONTH -eq 0 && echo 12 || echo $LAST_MONTH`
RM_RESULT=`test -d "$HOME/log/procmail/$YEAR/$LAST_MONTH" && rm -rf "$HOME/log/procmail/$YEAR/$LAST_MONTH"`
MKDIR_RESULT=`mkdir -p $HOME/log/procmail/$YEAR/$MONTH`
BZIP_RESULT=`test -f "$HOME/log/procmail/$YEAR/$MONTH/$YESTERDAY.log" && bzip2 "$HOME/log/procmail/$YEAR/$MONTH/$YESTERDAY.log"`
LOGFILE="$HOME/log/procmail/$YEAR/$MONTH/$DAY.log"

Yes, I know, I could do this in a cron. But it was funny to do it in the procmailrc.

Filed under , & no comments & no trackbacks

Seven rules to create a nice tarball 0

It is pretty interesting to see how people release the actual tarballs of there free software. Some include there version controll systems metadata (I’ve once saw a release which was obviously done from the home-directory and therefore include a few private dot-dirs) and some also change tarballs silently. When you create packages for a distribution, such habits are pretty annoying and sometimes it is not possible to create sensible packages or build instructions from the official tarballs and therefore you have to recreate your custom tarball.

  1. Add the tarballs version to your tarball name

    Name your release tarball packagename-0.2.ext to make sure, every release has its unique location (yourhost.com/releases/packagename-0.2.ext). For example, Wordpress does that completely wrong (latest.tar.gz). Do not try to obfuscate the version syntax (0_2, 0-2 or something like this instead of plain simple 0.2). In a webserver directory listing your packages are sorted correctly, the chance of silently replacing tarballs by accident is much lower. Which brings me to the next point:

  2. Never replace tarballs without incrementing the version number

    »But I just changed one …«. No. »But it’s harder, because I need to recreate the checksums«. Yes, you do. »I feel embarassed, because my last release was bad«. Oh, you should, but you can’t change. I say this again and again. There is no reason – and by no means no – why you should replace a tarball you have released. If you fix a hole, just increase the minor version.

  3. Remove temporary files

    If you have a makefile, run make clean before you release or provide a whitelist of files which should be included in a tarball. Oh, and do not release binaries, I will rebuild them anyway, because I have my own toolchain, thanks. In case of web development, please add a clean config-file, I do not need to know your weak database root password. Also please remove your version controll system files.

  4. Build and execute your release once

    When you think, your tarball is done (or atleast you think), unpack the tarball on another location and build/execute your software. Make sure you did not forget a file or something like that. Yes I could pull it from your version controll system, but why should I?

  5. Create a subfolder

    Please make sure, that you have one node before your bunch of code. /test.c is wrong /mypackage/test.c is much better. Best is to include the version number in the subfolder too (/mypackage-0.2/test.c). Otherwise you will flood my filesystem, and you are not supposed to do.

  6. Provide checksums

    How could I be sure, that your tarball is an intentional release by you? First of all, to check tarballs integrity, I would like to have checksums. No, not MD5, provide multiple checksums because the ones which are widespreaded are more or less broken (SHA256 plus MD5 is ok). Please also sign your tarball or your hashes with your GnuPG-key. And yes, your key is worthless if noone signed it. A nice thing is to provide HTTPS for package downloads but that’s pretty hard for obvious reasons.

  7. Use a consistent version scheme

    If you thought out a version scheme, stick to it. It might be bad, but at least you’ve tried. When you change, please document that clearly.

Filed under , , & no comments & no trackbacks

A naive approach to mixins in PHP 3

Mixins is a known multiple inheritance concept from languages like Python or Ruby or (but in a different way in JavaScript). In Ruby you can include another class definition, in Python you extend from multiple classes and in JavaScript you use prototype to copy methods from one class to another. In PHP there is no default strategy how to reach that, but nevertheless multiple inheritance leads often to the advanced usage of the mudclump pattern, sometimes it is practically. Think on PHPUnit and its assert*()-methods. They are defined in PHPUnit_Framework_Assert. PHPUnit_Framework_TestCase is derived from the last but it would be much nicer to have the possibility here to mixin my custom assertions. For example I have a custom assertion to ensure a certain object implements a valid singleton. Currently I need to patch PHPUnit, but why should I need to?
I am currently working on a half-automized storage component, which provides helper functions for database queries (auto-generate a WHERE-clause from a filter object, create a field list out of a dependency list and stuff like that). I do not want to pollute my class hierarchy but I want to have them pluggable and I want my collegues to add their own. So here is my naive approach (only works for methods).


Continue reading "A naive approach to mixins in PHP"

Filed under , , , , & three comments & no trackbacks

On sharding 4

»A shard is a piece of broken ceramic, glass, rock (or some other hard material) and is often sharp and dangerous. Sharding is the act of creating shards. Somehow, somewhere somebody decided that what they were doing was so cool that they had to make up a new term for what people have been doing for many many years. It is partitioning… sometimes that partitioning is proper federation. You don’t need a cool name to effectively accomplish what’s been around for a long time. Moreso, you don’t need a name that implies you broke something irreparably.«
Partitioning vs. Federation vs. Sharding – Theo Schlossnagle

(Sharding is an architectural strategy to horizontally split large datasets into smaller pieces in order to guarantee scalability)

Filed under , , & four comments & no trackbacks

Vervolkter Staat 0

Zwei lesenswerte Beiträge zur Stasi 2.0 Eierei: Editorial der Bahamas 53 und Daniel Kulla in der Jungle World.

(In beiden Fällen via Classless Kulla)

Filed under , , , & no comments & no trackbacks

Umgezogen 5

Lisa und ich hausen nun in der Nießenstraße 36 in 51103 Köln. Einweihungsparty findet statt am 8. September, also nächsten Samstag.
Salz und Brot haben wir selbst, auf Salzteigtürschilder stehen wir nicht so, freuen uns aber über diese Geschenke.

Filed under , & five comments & no trackbacks