New release of Bit Viewer, the small Windows programs that offer easy conversion between Decimal, Hexadecimal and binary. This new release treats blank strings in the input-boxes as value zero.
The program is released under GPL2 and source code as well as executable can be downloaded from the Bit Viewer project page.
I’m constantly amazed at how bad programmers are when it comes to designing good logging and reporting utilities. Hopefully your tool support input from stdin and allows for writing logs or interactions to stdout. If you haven’t gotten that right, I’m not sure what you are doing.
But when it comes to report- and logging-formats many programmers go astray.
All logs and reports should be generated in a structured unambiguous format that is easily parsed. If you want human readable, write an adapter that converts from the structured format to human readably.
$> mytool | mytooltohumanreadableconverter
Why bother with that, why not just generate output the way you want it right away? Here is why! You will most likely find other uses than just reading it off the console. If you have a structured format, it becomes easy to write adapters that can convert to pdf, doc, or other not only human readable but also human usable formats.
To use an example: output from tools such as a unit-test framework.
You run the tool in console and the output looks great. It is easy to read as a human and everything is fine. What if you want to run your test on your CI-build-server, such as Jenkins? You want to aggregate hundreds of test runs, collect statistics over time? Parsing the human readable output can be a nightmare. What about running the tests from within an IDE –such as Eclipse?
With a structured format, it is easy to write an adapter that converts the output to single-line, structured text that is easy to write an error-parser using the generic one provided in Eclipse. With not much effort you can see the errors highlighted in the source code –with correct meta-data about the error. If the human readable output contains line-breaks, not uncommon to make an entry easy to read for humans, it becomes very difficult for the Eclipse generic error parser to find all the information in a cohesive way.
The options become endless. But if you go the route of human readable, it becomes close to impossible to do anything else than just human readable –in that specific setting.
The same can be said about program output to standard out. Imaging the output to be structured, than parsed and converted to human readable. All of a sudden it becomes very simple to write interactive programs that can talk to other programs using the stdin – stdout interface. You can write an adapter and connect it to a socket. All of a sudden you have a program that works remote, and across platforms.
Using stdin and stdout to allow piping information is not enough. Structured output and input makes your program more versatile and makes it much easier to fit into a full tool-chain or other grander settings.
I recently started doing a lot of low level programming in C. I wrote a small desktop application to help with conversions between hexadecimal, decimal and binary formats. It also allows for some simple visualization of the bit-pattern. The program is released under GPL2 and source code as well as executable can be downloaded from the Bit Viewer project page.
“A small part of me dies on every release”
A colleague wrote the above statement on the white board in the war-room today after working close to half a day with an internal release of source code meant for the other dev-teams working on the same project. When it takes almost four hours to do an internal release, a manual process that often goes wrong and has to be mended or redone, then it is something terribly wrong with the procedure.
Any new feature should be developed on a separate feature branch. Once the code is in place, it compiles, all unit- and function-tests pass, no lint warnings, no doxygen warnings, no code duplication and the code is peer reviewed; then you merge back to main/trunk. The merge should be close to trivial since the application you are writing are well partitioned, abide to the SOLID principles. (especially to OCP – open closed principle**) and each feature is small and distinctive enough so that you finish within a few days.
We do all that, or pretty close to it. The problem is not our coding practice –at least not in this instance. The problem is the version control system and the release process. I’m too embarrassed about the actual system in place so I won’t go into details. Lets just conclude that it is awful.
If your release process is any more complicated than a merge, than you are doing something wrong.
** If you are not familiar with the SOLID-principles or specifically the Open Closed Principle, please read this blog-post. Also stay tuned; future posts will discuss the individual principles behind the acronym.
A second release has been made, available on the project web page.
Password Generator project page
A couple of years back I forgot my password to one of my True Crypt volumes. I remembered approximately what the password was but couldn’t figure out the exact one. In order to help me brute-force my way into the encrypted volume, I wrote a small program to generate all possible combinations from what I remembered about the password.
I have now finally gotten around to publish the source code and binaries. It is released under GPL2, so please enjoy.
Whenever I find myself with a code design that doesn’t work for me; it might be that the code is hard to test; or it require large rewrites for small changes in functionality; or it simple doesn’t feel right; I most often find that I have deviated from the fundamentals of good code design. As long as I remember the basics, I’m mostly okay.
Robert C. Martin, perhaps better known as Uncle Bob, has popularized a set of design principles through his acronym of acronyms – SOLID. In this technical talk, Martin explains the two first principles hidden in the acronym; Single Responsibility Principle (SRP) and Open-Closed Principle (OCP).
[infoq.com] – The Principles of Agile Design
If you haven’t heard about the SOLID principles before, this is a must see. Even experiences developers can benefit from this talk. It is never wrong to brush up on the fundamentals by recapping the basics of good code design.
By default, SVN does not allow you to change commit messages. To enable that some times good some times bad feature, create a file named pre-revprop-change.bat and place it in the /repos/hooks folder of your svn central repo installation.
@ECHO OFF
:: Set all parameters. Even though most are not used, in case you want to add
:: changes that allow, for example, editing of the author or addition of log messages.
set repository=%1
set revision=%2
set userName=%3
set propertyName=%4
set action=%5
:: Only allow the log message to be changed, but not author, etc.
if /I not “%propertyName%” == “svn:log” goto ERROR_PROPNAME
:: Only allow modification of a log message, not addition or deletion.
if /I not “%action%” == “M” goto ERROR_ACTION
:: Make sure that the new svn:log message is not empty.
set bIsEmpty=true
for /f “tokens=*” %%g in (‘find /V “”‘) do (
set bIsEmpty=false
)
if “%bIsEmpty%” == “true” goto ERROR_EMPTY
goto :eof
:ERROR_EMPTY
echo Empty svn:log messages are not allowed. >&2
goto ERROR_EXIT
:ERROR_PROPNAME
echo Only changes to svn:log messages are allowed. >&2
goto ERROR_EXIT
:ERROR_ACTION
echo Only modifications to svn:log revision properties are allowed. >&2
goto ERROR_EXIT
:ERROR_EXIT
exit /b 1