Removing accidental commitments

It happens. Hopefully not very often, but accidental commits do happen in GIT.

They are rare enough that we can completely forget how to handle them. So, let's make a little note here of what was just done:

There were only 2 files being intensely revised, so let's make a backup copy of the most recent work:

$ cp file1 ~/safe/
$ cp file2 ~/safe/

reviewing the recent commits we can see where the mistake was made:

$ git log --oneline

the last state before the bad commit was a46e701, so we reset our local repo:

$ git reset --hard a46e701

finally, we push the changes to the remote branch:

$ git push origin HEAD:some_branch --force

and history has been erased!

copy the files back to the working directory and continue coding as if nothing had ever happened!

Now to tidy up our local copy:

$ git checkout some_branch
$ git reset --hard origin/some_branch

Errors, Faults, Defects and Failures

The terms and their associated definitions are not consistently used in my workplace, although I am trying to change that. After reading chapter 2, I began to use the terms as defined in the book [Burnstein], and people have been slightly caught off guard. I find it annoying that practically every software inadequacy is labeled ‘bug’, and the only alternative that I have heard (with less frequency) is ‘runtime error’. However, based on the textbook definitions, it should just be called a 'software failure’, since the definition implies that it occurs at runtime.

Similar to using the terms ‘sedan', ‘coup’ or ‘station wagon’ instead of ‘vehicle’; the notion of categorization allow us to speak with precision. Failures are the end result of errors. Faults (or defects) are errors that may (or may not be) manifested as failures. The linguistic specificity allows for thinking about verification with greater precision.

Consider the following example: a software product halts abruptly when a certain action is invoked under certain circumstances. If a team were limited to only describing it as a ‘bug’ that caused the 'runtime error’, then they would set out to find the bug and fix it: problem solved. However, with these three terms (Error, Fault & Failure) in their repertoire, they could say: “This unfortunate failure was caused by a mis-informed requirement, let’s find and eradicate the defect and then correct the business requirement that was the root cause". Having a broader vocabulary enables more robust reasoning and allows for a more complete solution.

Furthermore, these are loaded terms: 'Error' doesn't simply connote a problem, it tells us the problem came from a programmer's misunderstanding. Likewise, 'Failure' indicates that the deficiency has made it's way into code and that inhibits the software product from performing.

Conclusion: these terms are not common in my workplace, but we could work more efficiently if they were in common use.

Burnstein, I. (2003), Practical Software Testing: A Process-Oriented Approach (Springer Professional Computing), Springer .

Denyhosts instructions (updated)

Steve Jenkins did a fine write up on the subject of denyhosts in 2010.

Here are a few notes about the command sequence that is needed now:

Install denyhosts:

# yum install denyhosts

Don't lock yourself out:

# vim  /var/lib/denyhosts/allowed-hosts

Enable the service:

# systemctl enable denyhosts.service

Start the service:

# systemctl start  denyhosts.service

Verify that it is started:

# systemctl status denyhosts

Watch it in action:

# tail -f /var/log/denyhosts

Selenium problems?

Any time Selenium is not acting as I would expect (with Django functional/acceptance tests), it is usually a simple fix. Browsers update, and Selenium needs to keep up:

$ pip install -U selenium

Revisting Android Development

I recently had the opportunity to return to Android application development (after a break of almost 4 years) with some new friends while studying the software development process. Android development was not the focus of this exercise, the application was merely one of the artifacts produced.


I had completely forgotten how verbose Java is! However, I was very glad to see that JUnit is around to keep the testing goat happy... No, wait. The testing goat is from Python.

Anyways, it's fun to stay up to speed with different languages and frameworks - especially when you don't have to re-learn it all from scratch on your own.

Here are a few things that I found to be handy while I was working:

$ rm -rf ~/.android/avd/emulatorNameIWantToDelete.*

or however you might feel comfortable navigating to a hidden directory and deleting something. It came in handy when I had a virtual device that always thought it was still running.

$ git remote add upstream
$ git fetch upstream
$ git checkout master
$ git merge upstream/master

This was mostly from the github docs, which are excellent.

The handy type check that is available to us in Python is a little more verbose in Java:


Today I was asked why I ended all my lines with semi-colons - ehh... I have been writing Java.

Next Page