Character  Predeclared Entity
&          &
<          &lt;
>          &gt;
"          &quot;
'          &apos;

This is one of my favorite tricks.

When I make a temporary change to code, usually for testing, that I do not want to commit, I simply add a comment above the temporary code with the words DO NOT COMMIT.  When I try to commit that file, git will abort the commit and warn me:

+        //  DO NOT COMMIT
pre-commit: Blocking commit because  detect

In the root of your project, open the hidden .git folder.

Use  CMD + SHIFT + . to toggle display of hidden files if needed.

If it doesn’t exist, create a hooks subfolder.

create a file named pre-commit with the following content:

#!/bin/sh

# Check if this is the initial commit
if git rev-parse –verify HEAD >/dev/null 2>&1
then
against=HEAD
else
echo “pre-commit: About to create the first commit…”
against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

# Use git diff-index to check for @DONTCOMMITTHIS
# http://stackoverflow.com/a/7292992/3307822
# https://www.atlassian.com/git/tutorials/git-hooks/local-hooks
#
declare -a strsToLookForArr=(
“DONTCOMMITTHIS”
“DONOTCOMMIT”
“DO NOT COMMIT”
)

for str in “${strsToLookForArr[@]}”
do
if git diff-index -p -M –cached $against — | grep ‘^+’ | grep -i “$str”
then
echo “pre-commit: Blocking commit because $strToLookFor detected”
exit 1
fi
done

echo “pre-commit: clear”
exit 0

Allen Holub believes in #noestimates.

In his blog post KPIs, Velocity, and Other Destructive Metrics he offers this alternative to useless metrics tracking:

Focus on continuous process improvement, and productivity takes care of itself.

He has this to say about Velocity as a useful measurement of productivity:

velocity (average points per sprint) is not a performance metric, and using it as such is actively destructive. For one thing, the basic unit (a point) is not a measurable quantity. It’s a judgment. You can’t derive a quantitative measure from qualitative input.

Brian reposts Why Most Unit Testing is Waste by James O Coplien

Note the word “Most” in the title.  The article does seem to argue against unit tests except in certain contexts but seems to mostly describe bad unit tests.

I think there is a place for unit tests but they should not be relied on as much as they are, and they shouldn’t be mandated in all circumstances.

I believe writing and maintaining unit tests can be a much bigger effort than the code they are written to test so the return on investment may make them prohibitive when other types of testing can be sufficient for the amount of effort required.

Excerpts:

Be humble about what tests can achieve. Tests don’t improve quality: developers do.

Software engineering research has shown that the most cost-effective places to remove bugs are during the transition from analysis to design, in design itself, and in the disciplines of coding. It’s much easier to avoid putting bugs in than to take them out.

Developers should be integrating continuously and doing system testing continuously rather than focusing on their unit tests and postponing integration, even by an hour. 

For the type of mobile apps I write, with background asynchronous data fetches and event driven flow, I’ve only experienced one solution that worked well and that was a QA team that was well versed with Appium and was able to get a high level of automated regression test coverage in our Android AND iOS application.  There was only a small amount of special coding I had to add to make their job easier such as setting the contentDescription value for a custom view so the value of the view could be determined.

Update: Oct 25, 2021: Code Coverage Best Practices

CodeAcademy has a nice step by step web based tutorial on JavaScript.

…

Read More Read More