Dariusz on Software

Maildir and mbox are two formats for storing e-mails locally. Both have strengths and disadvantages. If you want to convert all your mail from Maildir format to old, good mbox just issue the following script:

for a in .??*; do
    echo $a
    mb=${a/\./}
    for msg in $a/new/* $a/cur/*; do
        formail <$msg >>$mbs 

    done
done

You may ask: why revert to older, less flexible format? The answer is: speed (mbox is faster for many small messages).

Do you hate animated ads on web pages? Roll-out whole-page ads that hide main content? Big flash content that will slow down page loading? I do.

Simplest answers for this problem are:

• use text-only browsers (Lynx-like)
• disable JavaScript globally in your browser
• install NoScript Firefox extension

The last option is better if you sometimes need graphics and Flash/Java Script. NoSCript has cute configurable interface:

By default JavaScript / Flash are blocked for all sites (good starting setting), you can enable them by white-listing.

Very useful side-effect of NoScript (except nasty ads removal): your browsing is safer. Only selected domains (whitelisted explicitly) could execute JavaScript in your browser.

Supporting releases: It's very important to know exact version used by customer. In order to reproduce the error you have to switch to codebase used for reported release and analyse the problem.

If you have fixed release cycles it's pretty easy to embed version number on "About" page and get that information with bug report from customer. wait, but what about "continuos delivery" practices (there may be many different software versions pulled between official releases)? And what about human mistakes (one can forget to release software without version updated)?

The answer is: automation. You have to embed branch/commit ID somewhere in application (to be visible for end user). Then you can point exact software version that was installed on this particular machine.

You can find below how we retrieve branch name / commit ID with GIT/C++ environment (our Makefile fragment):

git branch -v | sed 's/no branch/no_branch/' \
    | awk '/^\*/ { print "#define APP_VERSION \"" $$2 " " $$3 "\"" }' \
    > headers/version.h

version.h file is regenerated automatically on every build (and is not stored under GIT), so it will be always filled properly. Based on this automatically generated files you can show version information in UI or insert it into logs (it depends on your application type).

GIT is a fast version control system that handles branching very efficiently and allow for most operations to be done offline (is a distributed VCS). Of course sometimes you have to exchange code with external GIT repos (maybe central storage). Being distributed forces some design decisions: local/remote branches distrinction were introduced.

Remote branch in GIT is a head that tracks branch stored on server. You shouldn't update (commit) directly that branch. You can update local branches instead then use "push" to publish changes from local branch to remote. Remote branch can be used to answer the following questions:

• is my local branch up to date regarding to server state?
• what changes (diff/log) were added to my local branch and aren't submitted (push) yet?

In order to use properly remote branches you have to create maching local branch for every remote branch. Boring and error-prone task. Let's automate it:!

git branch -a | awk \
    '/RELEASE/ { sub("remotes/origin/", "", $1); \
    print "git branch --track " $1 " origin/" $1 }' | sh

Above command imports all branches that contain string "RELEASE" (I assume we may be interested in checking release status).