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