Thursday 28th April, 2016
James merged some of his PRs that had been reviewed while he was away:
- PR 2391 - Restore indexable_content behaviour for outcome nodes
- PR 2400 - Avoid double render error if exception raised after render
- PR 2408 - Introduce on_response blocks to set attributes on calculator
Fixing auto-correctable Rubocop violations
Having merged PR 2418 (Use auto generated Rubocop config), James started fixing some of the violations that Rubocop can correct automatically.
Ensuring flows can be visualised
- PR 2457 - Add test to ensure all flows are visualisable. This was prompted by some work to refactor benefit-cap-calculator. The refactoring changes broke the visualisation for this Smart Answer. We’ve previously tried quite hard to ensure the visualisations continue to work when we’ve been making changes, so the fact that they broke without a test failing didn’t feel quite right.
Update Worldwide organisation data
- PR 2458 - Update worldwide location organisation data. Having merged PR 2448 (Avoid fixtures in WorldwideOrganisation tests), I’m now able to update the organisation fixture data without causing any tests to fail. This will make it easier to run a full set of regression tests for marriage-abroad.
I spent some time reviewing PR 2452 - Refactor Benefit cap calculator (Making benefit rates and type configurable). James and I tend to review PRs by going through each commit and leaving comments. Unfortunately, this doesn’t seem to fit with GitHub’s interface and the PR ended up with lots of “comments on outdated diffs” which was a bit of a shame.
Marriage-abroad changes for ceremonies in Sweden
I reviewed PR 2453 - Content changes for opposite and same sex (Sweden). The regression test artefacts came in handy during this review as I was able to see that some outcomes had inadvertently changed. This isn’t entirely surprising given how (unnecessarily) complicated the marriage-abroad logic is, despite our efforts to improve it.
I also created a new PR to illustrate an alternative approach to this PR. It felt like a relatively useful thing to do given that I’m currently remote and can’t easily pair on the code.
I continued working on DRYing up page titles for marriage-abroad outcomes. This work seems to be exposing some inconsistencies in the current implementation that I intend to dig into further.
I started trying to catch up with the backlog of week notes. I’m overdue to write notes for weeks 374 to 377! I started writing but got a bit overwhelmed by the idea of writing four weeks worth and struggled to make any real progress.
Salary and dividend amounts for 2016/17
We have an annual Harmonia task that prompts us to review our salary and dividend amounts for the coming tax year. I spent all too long trying to get my head round the new dividend tax rules. They’re really not that complicated so I’m not entirely sure why I found it quite so hard.
When working on this task last year (see Accountancy in week 325), James created a spreadsheet to model the rules. I knew I wanted to modify this to handle the new rules but kept getting distracted by creating different implementations (in spreadsheets and Ruby). Although it felt like a waste at the time, one of the alternative spreadsheet implementations helped me spot a problem with my changes in the main spreadsheet. The Ruby version was definitely just a (fun) waste of time though :-)
James continued to investigate us preparing our annual accounts and has contacted a few accountants to find out whether they’d be willing to check a set of accounts that we’ve prepared.
We were recently contacted by someone who’s both working with, and in the process of setting up, a cooperative. He’s keen to get digital coops working together which sounds right up our street. James has arranged to meet him soon to find out more.
We have to pay HMRC quarterly. Although chosen by Harmonia, I’d neglected to get to this task on time and so James kindly did it on my behalf. Thanks, James!
Safely in our hands for another year!