Sometimes I collect material for a blog post in a file but then forget to publish it. Thankfully WordPress lets you backdate posts.
I found three old blog posts that I wrote for the static blog which I never published. Since they fit nicely with the topics here I published them under the date when I originally wrote them.
While we already published releases on JCenter, we are now in the process of getting OpenFastTrace published on Maven Central. The goal is of course to make using OFT as convenient as possible for everyone.
I am happy to see that the people from Maven Central take security seriously and do not just let anyone publish modules under any package name. They asked us to prove that we own the domain “itsallcode.org”, so that gave me the necessary kick in the butt to speed up my plan to set up a web presence for OFT outside of Github on our domain. This blog is the first part.
Today we released OpenFastTrace 1.0.0
Or criteria for this major release were
- Importers for Markdown, ReqM2, Tag format and Legacy-Tag format
- Exporter for ReqM2
- Full featured plain text report
- Basic tag filter and artifact type filter
- User guide
- Contribution guideline
Time to celebrate!
Not much time today, so just a list of “features” I’ve discovered on my shiny new Samsung M2825 printer:
- HTTP but no HTTPS (admittedly most devices do that since there is the problem of how to start the certificate chain)
- Default user / password: “admin” / “sec00000”
- No mention of open HTTP server in installation manual
- No mention in handbook
- Shipped with firmware from 2015
- Firmware update dialog does not indicate that new firmware is available
- Firmware update via file upload from PC – not convenient
- Ton of protocols switched on by default
- HTML Handbook broken (text only) after unpacking
- Firmware well-hidden on the support page (unfold and scroll down): http://www.samsung.com/de/support/model/SL-M2825ND/SEE (edit 2018-07-01: this link not available anymore)
- Password cut after 18 characters (no indication when entering new password)
- Offers to select source IP for login (probably intended to improve “security”)
Another example that “S” stands for security in IOT.
Good software tries not to surprise the user. Today I was surprised that four of the integration tests in OpenFastTrace (OFT) failed although I did not touch the code.
The failure reason given was a character encoding problem. Since I was quite sure that the problem did not occur last time I ran the test and I did not touch the code since, I knew the reason was not in our code.
I suspected that the test did not (or not only) use the test data in the resource directory, so I manually ran the test and explicityly pointed OFT to the resources. This time the test passed.
Then it started to dawn to me: the strange
.AppleDouble directories that seemed to appear out of nowhere in my home directory might be the culprit.
A quick Internet search later I realized that they were a result of sharing my home directory over my LAN with another machine. Surely enough they contained the same filenames and that OFT mistook them for input files. Since the content of those files looks binary, OFT could not read them.
I stopped sharing and search-deleted all those directories. After that everything was back to normal.
Coming back to my original point: the appearance of
.AppleDouble directories just because I shared a directory via Samba from my Linux box came as a complete surprise to me. I am grinding my teeth already because they will also be in all backups. Luckily I spotted them before I did any git commits.
Bottomline: don’t suprise your users – do exactly what they expect.
When did I test enough?
While code coverage is a good indicator, you still have to know how code coverage works. Today I was hunting a bug in a Markdown importer I wrote for OpenFastTrace. The class where the bug sits had a whooping 93.1% code coverage and part of that missing coverage was owed to the fact that the JaCoCo coverage tracer can’t mark code that throws exceptions as covered – even though there is a test case for it.
So I wrote a new issue ticket, created a fix branch and wrote a three line test case that reproduced the problem. While the test now failed as expected, the code coverage didn’t go up.
I used the Mockito mocking framework to verify that an interaction with a mocked observer happended or in my case due to the bug didn’t.
The error was hiding in a regular expression which read
Notice the asterisk in the end.
So while there are a lot test cases waiting to be written for this regular expression, code coverage won’t tell you.
You get what you measure, so be sure you understand what it is you are measuring.