While developing a tool for easy handling of translation processes, we had to take care for the right encoding of our property files: Translation agencies need UTF-8 and java needs ascii with escaped unicode sequences. Thats easy if we use the native2ascii ant task, but it might be nicer if we could use an appropriate java class. But obviously there’s only the exe-tool and the ant-task. Anybody knows why?
Another strange thing is, that the java IO methods don’t support unicode escaped ascii. But we don’t worry, just rely on the Properties.store method – apart from encoding it also handles escaping of key characters ([#!] for comments and [:=] as delimiters). Very comfortable. Except one thing: property files will be unsorted. As you can imagine, checking the changes made by the tool gets a pain, because standard diff can’t find the changes in such scrambled files. >> more…
Having the pleasure to review the code of developer applicants, I receive solutions for the Bowling Game in langauges I never heard of (or haven’t seen for a long time, like good old Basic). Currently I try to decipher something written with PowerBuilder. Looks a bit like Visual Basic, but my Mac’s text editor isn’t able to do more code highlighting than painting Strings in pink. Luckily the author gave a hint, that there is only one function which contains all the logic. But this still leaves me with 150 lines of unhighlighted code in a language I don’t know… guess this might take a while. >> more…
Before each release the support guys click through the whole application (following a smoke test script) to prevent that new bugs sneak in. However, sometimes they don’t manage to find all of them. No wonder since humans just tend to make mistakes when doing such stupefying, reoccuring work. Apart from that, the procedure is awfully time consuming – eight days of development require two days of testing.
That’s why we decided to enhance our suite of acceptance tests. Now we use exactly those two days support needs for testing to write new Fitnesse tests. We first created a list of all parts of the smoke test which were not already covered by automated tests. Each pair of developers picks one of the tests, implements it and then the interaction design girls look over it to ensure its quality. That way we already implemented 2/3 of the missing tests. As a side effect we improve old Fitnesse tests we find while searching for “inspiration” for the new ones.
Because Fitnesse tests are run on our continuous build server after each commit, new bugs are found before the smoke test even starts.
And that pays off: In the last three iterations only one small mistake made it into the release! Customers and support love our improved Fitnesse.
Even after one year of writing Fitnesse tests I keep forgetting the keywords to check for empty or erroneous results and how to get/set fitnesse variables. So finally, here’s a short list to look them up:
blank: checks for empty strings
null: checks for null
error: checks whether any kind of exception occured
Set symbol to the result of getFun():
| value | =getFun() |
| 3 | symbol |
Set param to the value of symbol:
| param= | setFun() |
| symbol | true |
In many companies, developers are hired by line managers and HR people. But that’s like having no musicians sitting on the panel at an audition. HR people just don’t have the skills to detect real developers. Steve Hanov visualized the difference very nicely in his blog post.
>> more…
