Cultural Difference

Here's a cultural difference:

When I am doing test first programming (more formally known as test driven design), when I write code it has usually been tested.  To some degree.  With an automated test checked in.

But working with people who don't do test-first or TDD, they sometimes write gallumphing of code. And check it in.  No automated test. Possibly they may have manually tested it.  Or perhaps not.  Possibly they have no expectation that the code will work at all.

Now, what happens when I start using that code, expecting it to have been tested and to work?  If I'm lucky, it will break right away.  If unlucky, it will almost work... until a good while later I figure out that there are bugs in code that I thought was working.

Ideally, there was communication that "this code is not expected to work".  Verbally?  Comments in the code?

Automated tests are, in some ways, just a form of communication.  A form of communication that is in your face and hard to ignore.

Should you ever write code that isn't tested?  Sure, maybe: to sketch out an idea.  But it should be clearly documented as such.  Ideally automatically:  if code that you don't expect to work is executed, perhaps it should log or otherwise advertise that it is not expected to work.

I encountered a similar problem in another tool, that processed a class of input messages.  Now, in theory it should have been processing all of a class of input messages. It could tell the class of all inputs.  But for whatever reason only one particular example of that class of input messages was handled.  The rest were ignored. Silently.  No warnings.  Since I expected the tool to handle all of the class of input message, not just one particular type, it took me a while to onion peel.

Now, I did not fix the tool to handle all of the class of inpurt messages.  I just added one more instance.

But I could set it to warn:

if in class of input messages
      if example1 of this class ...
      else if example 2 of this class ...
      else
              warn:  I know I am supposed to do something for all of this class, but am not handling ...

Shredding

Moving is an opportunity to get rid of accumulated paper. Some of which needs to be shredded, against identity theft.

I have long had a home shredder. Just bought one with an automatic feeder.

But still it can be a hassle to shred a lot of mixed items. Shredder jams, plastic cards in unopened envelopes, etc.

Locally, Office Depot charges 99 cents a pound to shred.  Office Max charges 79 cents a pound to shred.

$$$, but possibly better than spending a lot of time feeding a small home shredder. And hopefully better shredding, more secure.

I can hear my auto-feeding shredder get .. not jammed, the opposite of jammed.

status files to work around version control limitations (esp. in hg)

---+ Recent status

Tue Apr 24 10:59:29 2012: XXX branch

Andy Glew creating the hg branch "XXX", for, duh, XXX related work.  I
want to push this branch to the main repository, but not merge it with
the default trunk - if for no other reason than that is a way of
getting other team members to see my code, possibly make comments, and
tell me how stupid I am.

But I don't want to place in mainline, because it is not ready.

I will try to keep these branch checkins clean.  I.e. I will edit
history to collapse some stupid checkins.  Although probably not so
much as if pushing directly to the mainline.

I am using this "status.txt" file to record branching arrangement, as
described below.

But also to work around an HG limitation: hg has an important default
label "tip", which many tools think is the tip of the main default
trunk. If you push a branch, and tip gets set to the branch, many
things break.  The only way I have found so far to avoid this is to
make a change to the trunk when pushing my branch.  This status.txt
file is a way of accomplishing that.


---+ What this is: Status files like status.txt

This file is to record status.

Why can't status be seen in the version control logs?  Well, it can,
but...

---++ Post-checkin status determination

Scenario:

You make changes.  Test Check in.  Write a log message.

So far so good.

But then you realize that something broke.  But you don't have time to
fix it right away.

If you could do a dummy checkin, with nothing except status, that
would be okay.

CVS supports this:

    cvs commit
    -f
        This option is present in CVS 1.3-s3 and later releases of
CVS. Note that this is not the standard meaning of the -f
option as defined in Common options.  Force CVS to commit a
new revision even if you haven't made any changes to the
file. If the current revision of file is 1.7, then the
following two commands are equivalent:

$ cvs commit -f file
$ cvs commit -r 1.8 file

As far as I can tell, Mercurial does not.

So I therefore add this file, status.txt.  Typically I will place a
status message, like "Tests not originally run fail" in this file, and
in the commit log.  Nice to date them

---++ Branch Status

I have used this approach also for branch status.  Sure, branch status
may be in the version control log (modulo the limitations of hg
above).  But somebody working on the main line may filter out branch
status and log messages.

Therefore, I will sometimes record branch status on a file like
status.txt (or branch-status.txt, or repo-status.txt) that I kep on
the trunk.  Stuff like "I am working on the XXX, and I fixed the
foobar bug, but I am not ready to put it on the trunk, so check out
branch-BBBB".

I.e. I sometimes use VCS to track work-in-progress, not just history.
(If that WIP takwes a while, it is both WIP and history.)

It would be nice if something like branch-status could be seen on all
branches.  Or, perhaps, consider it as a subrepo shared between
multiple branches, separate frolm the rest of the repo.  But that's
bluesky.