I started again with the real edition. The major change is that it is now focused on Worker Bees rather than Wildabeast’s.
So far I have made it to the testing chapter at the end of part one.
It appears that the samples have not been updated to match the latest code.
The testing techniques are really good. Given that variables are immutable then test fixtures really are reusable. The context part of ExUnit is very clear.
I understand delaying the tests to keep the book to a reasonable length, but event a single character typo can break functionality and be hard to fix later. I had misspelt the key on a lookup and though that the tests were broken.
I have made some more progress on this project and we are now down to 60 errors per day from the previous thousand. Given that we are integrating with other a hundred system this is more acceptable. Once a breakthrough was made to clear the highest frequency problem, the rest were fixed easily.
A lot of the existing log messages lacked context. They typically included what method was being used and the stacktrace. What was missing was enough information to recreate the problem.
My previous claim about not using a debugger no longer stands. I was forced to use this to identify paths through some code that had not been developed via TDD (it had some acceptance tests but the details were obscured). We are still removing the old Betamax tests – these consisted of recordings of a production run that are replayed. This is a good start, but is painful to adapt.
Most agile teams following some form of Scrum hold a daily standup.
Typically this is held in the morning at a time when the whole team can be in. I have also heard of end of day standups. These work better for teams that work remotly across timezones.
There are several forms of this meeting.
The basic is the three questions:
– What did you do yesterday
– What are you going to do today
– Any blockers
Another that I prefer is to walk the project board from right to left. Duscuss all cards that are not yet done. This will ensure that the board is upto date plus can show when someone is working off the plan.
I have also worked on a team that held two standups a day. A full one in the morning and a second quick version after lunch to cover changes.
This is a more advanced example of using grapviz to build a wardley map.
This is a wardley map generated from Graphviz.
It’s not a very good map, as it’s not trying to solve a real problem. This is mostly to see if I can use graphviz to display this.
The next example is more realistic.
Cup of tea wardley map
This is one of Simon Wardley’s simple examples where a tea shop has built a custom kettle. It’s a great example of demonstrating that you are possibly doing something wrong in an obvious manner.
Wardley Map visualisation of a set of software products.
This includes the dot file for the above diagram.
The idea of the value stream is to show the dependencies from the visible to the invisible. The horizontal axis has the custom items on the left and the commodity ones on the right.
// ==UserScript== // @name New Userscript // @namespace http://tampermonkey.net/ // @version 0.1 // @description try to take over the world! // @author You // @match https://codurance.com/about-us/our-people/ // @grant none // ==/UserScript== (function() { ‘use strict’; // Your code here... })();
Now replace // Your code here… with:
$(‘div.u-heading-v2-3–bottom h2’).text( ‘The Team (‘ + $(‘div.g-max-width-800’).length + ‘)’ );
Save this and view the page.
This will when you revisit the page change the label to include a count of how many people we have.
This is a great way to make small changes to a website that you don’t control.
If you want to allow other people to use an updateable script then you can publish the script on a public url and use the settings tab to record where it comes from.
This technique is great for customising third party websites that don’t quite do what you want them to. You can even add javascript dependencies into the page if you want to use them.
I was just thinking about the most frequently used commands that I use on my main development machine. It did not take me long to work out how to automate this process. My history has the last 10000 commands: