It’s nice to see other peoples names in a Jitsi room. Here’s how you can do this.
These are some insights I had today, posted as Tweets:
And last, but certainly not least Miroslava Nikolova made me (re?) post a message on a piece of cardboard that circled around at the Agile Testing Days 2009.
I think it is still valid and covers the spirit of this very conference and the attitude of everyone taking part so well.
Here’s the plain text (and if you know who’s the original author, I would really like to know who they are):
We are a community of professionals. We are dedicated of our own continuing education and take responsibility for our careers. We support each other in learning and advancing our craft. We certify ourselves.
— Unknown author(s?) at the Agile Testing Days 2009
I thank everyone who made this day so great!
In many situations, especially when testing, I like to see the log file content (or other system output) on one of my open command line windows.
Most of the time
tail -f <log-file-name>
is just fine. However, sometimes I like to have more control of what displayed. In these cases, I use less (https://en.wikipedia.org/wiki/Less_(Unix)):
less +F <log-file-name>
is more convenient (and powerful): I can navigate the whole file, search for specific content.
Note, that while tail uses a lower-case ‘-f’ to follow the file as it’s being written to, less uses an uppercase ‘+F’.
Update (2022-02-04): Fixed it: less uses ‘+F’ (plus upper-case F) as the command line argument, not ‘-F’.
If you do it in a weird way, you may be wrong.
If they do it in a weird way, they may be right.
In the previous blog post I have described how to use GraphViz to describe a graph in a textual format and then generate an image from that.
This time, let’s do one more step and add some code so that the image gets generated automatically when the text file is updated.
For my project I use Guard, a Ruby gem that watches file system changes, and allows to define various reactions. Running unit tests whenever a file is saved is one example.
For my case, I let it generate a new image file, when a GraphViz file is saved. First of all, I installed the needed Ruby gems:
gem install guard guard-shell
With that in place, here’s the Guardfile I use to generate the images:
guard 'shell' do
watch(/(.*\.gv)$/) { | m |
dot_file = m[1]
png_file = "#{File.basename(dot_file, '.*')}.png"
command = "dot -Tpng -Gdpi=300 -o#{png_file} #{dot_file} ＆＆ open #{png_file}"
puts command
puts `#{command}`
}
end
Note: In the code above I had to revert to enter ＆ (0xff06) instead of & (0x26) in order to prevent the syntax highlighting feature from turing a & into `&`… 🤷♂️
The part watch(/(.*.gv)$/) invokes the following code block when a file that matches the given regular expression changes. I am interested in files that match ‘*.gv’ in the directory that the Guardfile is stored in.
The line dot_file = m[1] extracts the file name from the parameter passed into the block, and uses it to create a _new_ file name for the image file that is going to be created.
Then the shell command is put together, logged, and finally called.
| Component of the command | What it is/does |
dot | The command name that translates the gv file into a PNG image |
-Tpng | Set the output format to ‘png’ |
-Gdpi=300 | Set the resolution to 300 dpi (gives a good resolution for printing) |
-o#{png_file} | Set the file name for the png file |
#{dot_file} | The name of the input file |
&& open #{png_file} | This appends another shell command to open the image file. (I use this on my Mac to automatically (re-) open the file whenever it’s regenerated.) |
In case you would like to experiment with this, I created https://github.com/s2k/autogen_images_for_graphviz/ as a starting point, including an example GraphViz file.
In one of my projects we were faced with a high number of execution paths the system could take. While this is normal and, in fact, expected for all systems these days, in this particular project it was obvious even for the users of the system. The software accepts (interactive) input and then demands more information, as needed in the specific context. There were numerous paths through a network of decisions to get to the point where the final result could be presented to the user.
This is basically describing layers of decisions, leading to various outcomes. To get an overview of the decision tree, I created a diagram using an app (OmniGraffle in this case). The result for one real tree (with abstracted labels) is this:
This isn’t trivial, but it doesn’t look too hard. But then, there are 9 different paths thought the graph. The following image shows each path in one colour:
That’s not as simple anymore. Also note, that the attribute is sometimes updated, leading to different result types (res1 for attribute == 0, res2 for all other cases). It was tedious to create these images to help me see the paths — and fiddling the the arrow to make it look reasonably good, was extra work. To deal with more cases I wanted another approach.
I remembered a tool I had used in a similar situation: GraphViz. It’s the combination of a text format (a graph describing language) and programs to turn this into a graphical representation: images.
Here’s the textual representation of the graph above:
digraph {
size="40";
bgcolor="transparent";
node [fontsize=9, shape=rectangle, style="rounded", color=black];
edge [fontsize=7, fontcolor=red arrowhead=onormal];
D1[ label = "Decision 1\nattribute = 0" ];
D2[ label = "Decision 2" ];
D3[ label = "Decision 3" ];
D4[ label = "Decision 4" ];
R1[ label = "Res 1 | Res 2\ndepending on attribute" ];
R2[ label = "Res 1 | Res 2\ndepending on attribute" ];
R3[ label = "Res 1 | Res 2\ndepending on attribute" ];
D1 -> D2 [label = "Yes"];
D2 -> D3 [label = "Yes\nattribute += 1"];
D2 -> D3 [label = "No"];
D3 -> R1 [label = "≤x times"];
D3 -> D4 [label = ">x times"];
D4 -> R2[label = "<Y units\nattribute += 1"];
D4 -> R3[label = "≤Y units"];
}
I find it easy to see which node there are, and how the node connect. Here is the command I used to generate a PNG file:
dot -Tpng -Gdpi=300 -o decisions.png decisions.dotdot is one of the layout programs that comes with GraphViz. With -Ddpi=300 I’ve set the resolution to 300 dpi (to generate a file with a higher resolution than the default). The resulting image file log like this:
dotWhile the positioning of the edge labels is not perfect, it happened automatically, as the whole layout of the image. I didn’t have to move things, I could set the styles for all nodes & edges in one place, so that they are guaranteed to look consistent.
In the cases when I used this approach, I could generate the graph description automatically from a (more or less) formal description. In these cases, I could avoid mistakes by ‘hand-drawing’ the graph entirely (well, having tests for the generator code in place… 🙂).
I’m really excited that the Agile Testing Days accepted me as a speaker again. This year I’ll offer two workshops, one of them at two times.
“Get The Most Out Of This Conference” is meant for newcomers to conferences in general. If you haven’t attended a conference before, this is for you. The plan is to have the first one on Monday afternoon (9th, Nov. 2020), and then to have the second go right after the morning keynote on Tuesday morning (10th, Nov. 2020). There’s a teaser video available at vimeo.
“Let’s Start Learning Elixir — Together” is the second workshop. It’s two hours of looking into a functional programming language, getting started to learning it. This is scheduled for Wednesday morning. For the Elixir workshop there’s a teaser video, too.
