Apprentiship blog

Advent of code and ticket creation

December 03, 2018

Continuing from last Friday, project logfind has been completed. It took three attempts to get the core functionality working, first i started with unit testing, but unit testing was time consuming so I opted for using assert statements and writing functionality to add in a CHANGELOG file. I got further with that method but restarted as a rewrite was more viable than refactoring. So I made use of the debugging macros from learn c the hard way along with a new CHANGELOG file and some of the code that I written during the previous attempt, but improved to avoid previous pit falls. The debugging macros where surprisingly helpful, as when the program read from configuration one line at a time, but also included the trailing newline character at the end ‘\n’ which caused issues when trying to open the file named in configuration file so README.md was being interpreted as README.md\n.

CHANGELOG

  • It should error if no search strings are provide.
  • It can tell which arguments to use
  • it can tell how many matches are required
  • it can print out a file
  • it will print out a file when conditions are met
  • It can preform an and search by default
  • It can preform an or search when given an -o flag
  • it can search a hard coded file for matches
  • It should open a file in the current directory named .logfind
  • it can search the files named in .logfind

BDD

So with that out of the way I managed to free up some time for other activities today, to start with we did a kaka, coincidentally the challenge was to parse a CHANGELOG file and return the version number, the tasks yet to be complete. We always write tests before code when doing katas, usually in the format of it('Should ...[test description]' but today we used a slightly different description format where we defined the sort of behaviour we wanted instead describing the test… so the description took a format similar to it('WHEN an Empty string is GIVEN THEN the version number is 0'). This is a similar pattern that I’ve observed in used in user stories and acceptance tests, apparently the phrasing of the description and the content is called Behaviour Driven Development [B.D.D] and the core concept is to describe how a piece of code should behave under certain conditions.

Making more tickets and maybe less mess

So my last tracking board on jira became an unruly mess and difficult to do simple things like the addition of a new column and/or delete something. So I’ve switched over to Microsoft planner as it was recommended by one of the people at the service desks as. That being said I still have to move the tasks from my jira board over with out making the same mess as before. One feature that I found quite helpful is the ability to make check boxes in tasks that I can use a reference for creating a new ticket.

A treat

So with project logfind out of the way earlier than expected, I had time to do some pairing with Masha. Wondering what to do we came across https://adventofcode.com/ as there he been about the activity in and around the office / slack. We worked through the first problem using TDD and a some of the WHEN THEN descriptors mentioned before, then second problem on the other hand was much more tricky. We got the criteria for the tests from the website, the criteria required some looping… (potentially infinite looping) which was unavoidable during the second test and the site we used for writing and testing on crashed (due to an offset by one bug) and every thing had to be deleted from the cache in order to use the site again. Eventually both problems solved :)


Written by Marc McIntosh Find him on github