Tuesday 26th April, 2016
Pablo joined the team this week. Welcome, Pablo!
Automatically detecting next nodes
James built on his work that added support for automatically detecting next nodes for a Smart Answer. The following pull requests incrementally improved the system until we were left with a single way of defining next nodes, and a single way of determining those next nodes for visualisation purposes.
PR 2368 - Use automatic next node detection in existing flows.
PR 2370 - Use automatic next node detection in benefit-cap-calculator. This was a special case because of the way we were dynamically deciding which node to show next.
PR 2374 - Make auto-detecting permitted next nodes the default behaviour.
PR 2378 - Remove
PR 2380 - Convert calls to
next_nodewithout a block into calls with a block. Simplifies code by having a single syntax for specifying next nodes.
James was on a roll this week and also made a number of smaller changes:
PR 2361 - Remove incorrect permitted next node from check-uk-visa.
PR 2364 - Split integration test for two redundancy pay flows into two tests.
PR 2385 - Remove unnecessary instance variable assignment in SmartAnswer::Question::Base.
I continued to refactor marriage-abroad. I merged a couple of pull requests that had been given the thumbs up, and opened new pull requests that continue to remove
precalculate blocks from the flow in favour of encapsulating logic in the associated calculator object:
PR 2352 - Remove Germany logic from marriage-abroad outcome_os_consular_cni.
PR 2349 - Remove Japan from marriage-abroad outcome_os_consular_cni.
PR 2382 - Remove
precalculateblocks from the “outcome_cp_consular” outcome.
PR 2387 - Remove duplicate “*_path”
precalculateblocks from three outcomes.
precalculateblocks from the “outcome_os_consular_cni” outcome. I finished making the code changes but was left with a few commit messages to tidy before creating a pull request.
Started working on consistently naming marriage-abroad outcomes in the hope that it makes it easier to work on this smart answers.
James added Rake tasks to make it easier to create week notes and week links. The discussion highlighted a difference in our approach to updating metadata on our blog posts. Codifying the logic means that this shouldn’t be a problem in future.
IR35 Tax Assurances
We forwarded our completed Working Practices Questionnaire to GDS. We were under the impression this wouldn’t be required but it’s been requested in order to “mark your assurances compliant”.
Recording client time
We’re working somewhat irregular hours at the moment. Including weekends. This makes it a little hard to fit our time in with the Fieldglass system used by GDS. After some discussion, we agreed to split our time evenly between the two of us, and between Monday to Friday. This means that the time recorded against each day in Fieldglass won’t necessarily match reality but the totals remain the same, which is the important thing. James created a spreadsheet to help us convert from our hours logged in FreeAgent to those required by Fieldglass.
James noticed that the mirror of caffeine monitor we’re hosting was down. A quick conversation with Andy McMillan and it was all back up and running.
If you have any feedback on this article, please get in touch!
Historical comments can be found here.