Vocabularies in Software Development

Changing root password in LDAP

/etc/init.d/ldap stop
/usr/sbin/slappasswd
# Enter passwords
# output should be something like
{SSHA} aslfjlasdjflsadfjlsfjlasldfjsalk
# Edit /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{1\}hdb.ldif
# Add/Modify
olcRootPW: {SSHA} aslfjlasdjflsadfjlsfjlasldfjsalk
# Save
/etc/init.d/ldap start

Print week number with date

date +V -d YYYY-MM-DD

Clone hard-drive with ddrescue

1. Insert hard-drive as slave
2. Boot with sysresccd
3. Create partition table on new disc with gparted
4. ddrescue -d /dev/sda /dev/sdb /tmp/ddrescue.log
5. Shutdown
6. Make new disc primary, with  jumpers or cables
   
7. Remove CD
8. Reboot

Revert multiple changes in working directory

svn status | grep -v "?" | awk '{ print $2 }' | xargs svn revert $1

Three + 1 most important rules for code readability

Keeping your code readable is a key element of productive programing. Depending on which language you write your code in there are specific rules. E.g. SUN published in 1999 Code Conventions for the JavaTM Programming Language also IBM published a series of articles back in 2001 on perl programming, The road to better programming. Google has about 40 milion more hits on programming guidelines.

Most of us write code in at least three or four languages which could result in many coding styles to follow. Refactoring code is a way to really learn what counts for readability and what doesn’t. I found myself following couple of rules refactoring both my own and others code, making it more readable. I’d repeatedly do this

1. Group variable declarations at beginning of block
2. One statement / line
3. New line spacing between blocks of code

When reading the code you can then skip the declaration part, usually nothing interesting happens there. The short one line statements and new line separated blocks of code are way easily read and understood.

Don’t forget the +1 rule

Have fun!

Source control and commit messages

Using Trac and Subversion for source control.

• When something changes – see the Timeline
• What changed within file[s] – see the Changeset
• What is the issue – read the Ticket description

So what’s left for the commit message? well this is what I think

“One sentence; describing your action in relation to the Ticket description.”

Let’s break it down

“One sentence” – means that you should keep your changes really small. If you feel the need to write more than one sentence. Split the commit into two.

“describe your action in relation to the Ticket description” – this one is important; only say which part of the described issue you have addressed. Unless the ticket is design or refactoring related one, no reference to code changes should be made. This information is already available in the changeset.

Prepend log with sed

#!/bin/sh
LOGFILE=/var/log/latestfirst.log

prepend()
{
  line=$1
  sed -i "1i $line" $LOGFILE
}

prepend "a"
prepend "b"
prepend "c"

Print UID of logged in user

id -u

svn undo revision 100

# Revert changes to working directory
svn merge -r 100:99 http://path/to/svn/trunk .
# Commit changes
svn commit -m "Undoing revision 100"