Sometimes you want to separate old files (for example older than 30 days) into separate subdirectory to make navigation easier. Using Linux tools it’s pretty easy task:
mkdir -p OLD; find . -maxdepth 1 -mtime +30 -exec mv \{\} OLD \;
Explanation:
- mkdir -p OLD: create OLD subdirectory if not exists
- -maxdepth 1: search only one level under current working directory
- -mtime +30: find only files that are older than 30 days
- -exec …. \;: for every file/directory found execute the following command
- \{\}: will be replaced by filename
Above command will move all old files/subdirectories into OLD subdirectory.
Web2Py is a full-stack Python web framework that can be compared to Django, but is easier to learn due to convention-over-explicit-statement preference. In this article I’ll check how static verification techniques developed by me for many different environments (JSP, Django templates, TAL, …) can be applied for web2py environment.
Static verification means locating simple bugs without running application thus very high (>95%) testing coverage (and high related cost) is not required. Instead with trying to cover by tests every possible screen/workflow/code line/… we can scan all codebase and search for some constraints. Most of them (based on my experience) are static – do not depend on runtime data thus can be effectively checked without running an application.
(more…)
If you used to Debian you probably know that “dpkg-reconfigure locales” brings you locale selection tool. It’s not the case for Ubuntu. How to replace Debian’s behavior? Read below:
# grep pl_PL.UTF-8 /usr/share/i18n/SUPPORTED > /var/lib/locales/supported.d/local
# dpkg-reconfigure locales
Generating locales...
pl_PL.UTF-8... done
Generation complete.
Above example show how to add pl_PL.UTF-8 locale.
Recently I forgot to add #reviewthis directive for modifications of codebase that belongs to team A. And a subtle bug was introduced that way. Ops! I agreed earlier that all changes done to moduleB should be passed to a reviewer that will do peer review for that particular change. What a shame 
(We are using excellent GitHub’s review mechanism, BTW).
How to avoid that situation in a future? Should I rely on my memory? Is it possible for a human to track so many small rules manually? My intuition tells me that enforcement of those small ruleset should be automated.
GIT allows you to specify so called “commit hooks” that can validate many stages of GIT workflow. I’ll use simplest local verification of commit message, first the rule in plain text:
If you are changing moduleB you should notify developerC about this change
(more…)
