Keep FreeBSD up to date with subversion

The freebsd ports tree is quite big and sometimes you need just few packages. You can do that with subversion sparse checkouts.

pkg_add -r subversion

Checkout only immediate top level. The list of svn mirrors is here.

svn checkout --depth=immediates \
    http://svn0.eu.freebsd.org/ports/head /usr/ports

Update tree on as needed basis:

cd /usr/ports
# common
svn up --set-depth=infinity Mk Templates Tools/scripts
# portmaster
svn up ports-mgmt/portmaster ports-mgmt/dialog4ports 
# python
svn up lang/python lang/python2 lang/python27 \
    devel/gettext converters/libiconv
# mercurial
svn up devel/mercurial
# python development
svn up devel/py-distribute py-setuptools \
    devel/py-virtualenv
# vim
svn up editors/vim
# subversion
svn up devel/subversion devel/libtool devel/apr1 \
    databases/db42 databases/gdbm databases/sqlite3 \
    textproc/expat2 www/serf

Consider configure /etc/make.conf as advised here and install packages:

make install clean -sC /usr/ports/ports-mgmt/portmaster
portmaster lang/python27 devel/mercurial \
    devel/py-virtualenv editors/vim \
    devel/subversion

The above ports require only 12Mb in /usr/ports and next time ports update takes few seconds.

Convenient Remote Access with SSH Config

If you are working with a lot of remote ssh hosts it becomes hard to remember all that host specific information: username, ip address, identity file, non-standard port or local/remote port forwarding. ssh_config to rescue. Here is a sample to give you an idea (file ~/.ssh/config):

Compression yes
IdentityFile ~/.ssh/id_rsa
LogLevel ERROR
Port 22

Host h1
    HostName 192.168.91.57
    User master
    IdentityFile ~/.ssh/h1.pem

Host db1
    HostName usca45d1.example.com
    User pg
    LocalForward 5432 127.0.0.1:5432

The above configuration let me access those hosts simply by name, e.g.:

ssh h1
scp schema.sql db1:~/

How to manage Git or Mercurial repositories

Managing version control repositories can be a challenge in multi-user environment especially when simplification of user collaboration is your goal. There are usually two primary concerns while considering enterprise deployment for version control repositories: access control and safety of your data. Both are not directly addressed by version control itself, thus a sort of security facade is necessary.

wheezy web: Actors

The application design of wheezy.web application consists of several actors, each playing its unifying role. Actors are grouped into packages, e.g. models, repository, service, web, content, tests, etc. These packages (or layers) shape a subsystem.

The diagram below visualizes relations between actors, boundaries between packages, subsystems and application, giving a better picture of whole:

The sequence diagram explains request processing and interaction between actors:

You can download a pdf copy here.

Thoughts on SQL vs ORM

The question of persistence implementation arise often. I found repository pattern very valuable due to separation of concerns, mediate between domain model and data source (mock, file, database, web service, etc). The database data source is somewhat specific since you can proceed with SQL functions or ORM. Here are some thoughts why you might prefer SQL functions over ORM in your next project: