Up to Main Index                               Up to Journal for May, 2017

                      JOURNAL FOR MONDAY 29TH MAY, 2017
______________________________________________________________________________

SUBJECT: Returning to a disarray of changes
   DATE: Mon 29 May 21:47:54 BST 2017

Bank holiday Monday. I finally get a little time to work on WolfMUD and what
do I find? My Go workspace is in disarray with half completed ideas, patches
and other changes. After not having time to touch WolfMUD in nearly four weeks
I’ve no idea where I was at.

You might ask how can that be, what with me using git and all. Typically it’ll
go something like this: Start work on A, find a bug in B, to fix B need to
work on C. Before you know what’s happened you have changes for A, B and C all
mingled together as unstaged changes. In this case I’d want C finished and
working with B that works with A before committing C, B and A in that order.

Normally this isn’t an issue, until you don’t touch the code for a while.

So what to do? Apart from trying to work out what I was doing, salvage what I
can and discard everything else. But moving forwards?

I do use stashes a lot. As I do use them a lot stashing A to work on B, then
stashing B to work on C doesn’t really work well for me. Usually I end up with
something like stash A, work on B, random pushes and pops, push B, work on C,
more pushes and pops, commit C, pop B… B go!? Oh shi…! :(

What I ideally need is two stashes. A working stash for A, B, C and a general
stash for random pushing and popping. I guess I could use a temporary branch
for the commits and then cherry pick the commits onto my ‘real’ branch, but
that seems just as messy and error prone as stashes.

While sorting out my own mess did I come across anything interesting? I found
a change that now checks the error returned by chmod when creating player
account files. There is a change which really drops the old Server.Debug
setting from the data/config.wrj file. There is also the addition of the cave
zone in data/zinara_caves.wrj from where I was porting the newbie zone over
from the Java version. There is also an incomplete implementation of
behaviours I was playing with.

While things are quiet this evening I think I’ll clean up my Go workspace,
make some commits and then I really need to look at writing tests again.

*sigh*

I know tests need to be written, I know their value, I know I shouldn’t have
left it until so much code was already written. The trouble is I tend to think
with a keyboard and exercise the working code incrementally for testing[1].

At the moment I’m using four main references for inspiration with testing:


  ∙ The Go website and blog articles: https://golang.org
  ∙ The Go source code
  ∙ The Go programming language by Alan A. A. Donovan & Brian W. Kernighan
      ISBN-13: 978-0-13-419044-0 Book Website: https://www.gopl.io
  ∙ The Art of Software Testing by Glenford J. Myers ISBN-13: 978-0471043287


The first book “The Go programming language” I have on Google play books. The
second book “The Art of Software Testing” I’ve had for ages, is a 1st edition
hardback from 1979 and was really expensive. Even the latest edition new is
expensive, hardback 3rd edition on Amazon.co.uk is £108 for it’s 256 pages!
However it is the classic work on software testing. Would I go out and buy it
today? Maybe used, but not new at that price.

Enough wittering on, got programming and reading to do!

--
Diddymus

  [1] This stems from working for companies where you have 10 minutes to do 30
      minutes work that should have been delivered an hour ago!


  Up to Main Index                               Up to Journal for May, 2017