Sept. 19, 2018, 9:57 a.m.
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
Dec. 30, 2015, 5:01 p.m.
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 .
Jan. 22, 2015, 4:12 p.m.
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:
# 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
Oct. 8, 2014, 8:42 a.m.
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
Sept. 28, 2014, 8:41 p.m.
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 https://github.com/noah-de/ORIGINAL_REPOSITORY.git $ 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.