replicator.org ... incoherent code

If you have not recently picked up Test Driven Development (TDD), then you should stop reading here and buy the book Clean Code by Robert C. Martin (My default spoiler for new developers I meet).

Recently, a number of developers found out that TDD is not only good for test-driving your own code, but also for learning new languages and APIs.

It’s just simple. For any new API or language, create a new project, pick the latest and greatest unit testing framework and start writing unit tests until you find yourself familiar with the language and its API.

I learned about test-driving new APIs by the need to map project requirements to the exact semantics of specific APIs. APIs (especially those from the big players) are not always documented in the detail you would expect them in, and researching the various Q&A sites or putting up a question at StackOverflow involves investing a lot of time and a lot of distraction.

Often, the semantic details could be nailed down to a simple unit test and so I found that writing a unit test is mostly a better and faster way to find the hidden truth behind the often confusing semantics of APIs or languages. Moreover, the tests persist and can be useful in retrospect to find out about the rationale behind consequential design or implementation decisions. These tests may even be considered as part of the design documentation.

I think that TDL needs a lot more attention and should be used in companies and universities to propagate a more pragmatic learning approach.

If you’d like to learn more about TDL, follow these links:

Who does actually read the API documentation when it comes to setting a simple property like the one named Text in System.Windows.Forms NotifyIcon? An API that is used by hundreds of applications. Would you expect that this unsuspicious setter could throw you an exception?

You may think perhaps in some really “exceptional” situation, when there is no Shell anymore or the System is shutting down.

No, it throws an exception if the text exceeds 63 characters. Wow, imagine that a lot of tooltip notifications are built by string.Format() or just extracted from resources that may be translated to different languages.

The API designer could argue that “hey, it’s documented, and I have no idea what to do when your request can not be fulfilled”. Though I consider this argument as valid, for most applications, an exception while setting user interface elements is mostly unhandled and so crashes the application. Boom. An bomb went off, caused by an API that reflects an unexpected system or formatting limitation back into your application.

I am stating that this is a leaky abstraction. And if there is a string to set somewhere, and its property name looks unsuspicious, I’d expect the API to handle ANY string. As an application programmer, I don’t care about a system limitation or a formatting nuisance. Even when the string can not be displayed as expected, a more preferable API would append some ellipsis, truncate the text, or display the tooltip by some other means.

I personally would find the following API design decisions acceptable (in order of preference):

One important feature of dependency injection is that it does not require you to modify your classes. It works behind the curtain and wires up your object graph.

A not so quite obvious feature is that factories can be injected. Like referring to simple classes or interfaces, functions may be referred from within constructors. When called, these functions resolve objects and use all the magic of the dependency injector. Just by using conventions, the spirit and use of the dependency injector extends over the application lifetime.

In my implementation of a dependency injector, I focused strongly on constructor injection. Konstruktor only supports persistent objects per lifetime scope. When more objects of the same type need to be created, a constructor parameter of Func<T> automatically gets a factory injected that creates instances of type T (and their associated lifetime scope).

In a object graph, wiring events of dependent objects is simple. In the constructor the event source is referred, then a method is added to the event, and in IDisposable.Dispose() the method is removed from the event. The events flow from the root of the object graph down to the leaves.

But wiring events in the other direction is not so simple. There are no references available to the instances you need to receive events from. These event sources may not even exist yet. And often – architecturally required – there should be no direct dependency from the event source to the receivers.

A good example is logging.

So for Konstruktor, I experimentally implemented “convention based event wiring”. For every new object instantiated, all public events that have one delegate parameter type, can be automatically wired to a listening method that follows a very specific convention:

I think I developed a new prioritizing scheme. I don’t know if it is innovative or new at all, but for me it is really starting to work.

It is kind of simple, but just works and fixes the following problems with prioritization schemes I’ve always had:

• Too many tasks have always the highest priority, they need all to be done. It is just frustrating to look at a list of tasks that is too long.
• Proper prioritization of tasks and todo items is a lot of work and requires regular maintenance.
• Multiple prioritization levels are a pain. What is actually important in prioritization level 3 or higher? I’ve stopped at three, but even then, 3 was always the “throwaway priority” that left me with a bad feeling. More than two priority levels are confusing at best.
• Tasks not in the highest priority level won’t be done at all. Important tasks are often forgotten, just because they never reached the highest priority level.

Ok, and here for my solution. I call it “priority splitting”. The first steps are similar to any other prioritization scheme, but read through so you may get this “Aha” effect like I did:

We’ve integrated file hashes in the Safe file system.

Right now, this impacts the feature set only marginally, but over the next few weeks and before the public beta, we will use hashes to implement some new features in the synchronization engine.

The changes in the build 1911:

• We fixed a bug in the manual synchronization where the Recycle Bin option was enabled but not actually used.
• Read errors are now handled much more generously in the synchronization. For example, large files that are deleted while uploaded should not cause any errors.
• Unlinking and relinking a Folder to a Safe does not cause the contained files to be marked as conflicts anymore. This works only for files that have been uploaded beginning with build 1911. Older files will be marked, because there is no hash information available.

Based on the file hashes, a number of new features are now in preparation:

Beyond bug fixes, we are working at some minor enhancements. One of them is Recycle Bin support.

Beginning with build 1852, files that are deleted in the synchronization process may be moved to the Recycle Bin:

For new linked folders, this option is enabled by default. For existing ones, it is disabled.

And for us, the next step is to release the closed beta. Follow us on Twitter or Facebook to help us improving SharedSafe.

You need to change your monitor configuration every now and then? ScreenEstate is the right tool for you!

Click here to download it, it’s free! But be warned, it’s also BETA!

With ScreenEstate, switching monitor configurations is just simple.

You first set up a configuration by clicking the right mouse button on the Desktop and select “Screen resolution”.

Then, configure your screens and activate the new configuration.

Then, in ScreenEstate, click on the “Capture” button to save the configuration.

You should enter a descriptive name in the textbox below.

You may capture and save any number of monitor configurations to ScreenEstate.

To activate a previously stored configuration, select it in the list and press the big “Apply” button. Press ESC at any time later to switch to your previous configuration.

Go, download it! I’d really like to hear your feedback about how you use ScreenEstate.

We are starting to use our new file system tester, and immediately found and fixed two important bugs:

• When too many changes happen in a file system tree, the synchronization stopped:
  This was a subtle problem in handling a buffer overflow in the FileSystemWatcher. Now, when too many changes are happening, the internal file system tree is flushed and rescanned for the next synchronization. Not the best solution, but a safe one. An alternative would be to run a high-priority thread that retrieves all the changes in time. But even then, it can not be guaranteed that this error won’t happen anymore. So I think it is better to handle it anyways.
• Files could not be write-accessed or deleted while they were transferred:
  I knew of this problem, but never observed it in one of the test cases, but our new file system tester catched this one easily. From now on, files are uploaded in “stealth” mode.

I am glad that I was not born into a very religious family. My parents were Catholics, but visited the church only a few times a year. We never prayed together, though sometimes, my mother said she did. I never asked them, but I think their answer to the “Why” would be simple “Because everyone they know is religious”.

In my youth, my parents were pragmatic. They cared for their jobs, our housing and food. There were some political discussions every now and then, but they never questioned democracy. They had no proper education and so no high income jobs, but they never forgot how lucky they are to live in Germany.

Not the worst family to grow up.

Though I am sometimes labeling myself an introvert, growing up also means talking and interacting with other people. People who have specific perspectives and people who believe in a religious god. Interestingly, these discussions with strongly religious people stuck in my head, because I felt that there is always a point we can never find consensus.

In my experience, discussions with a religious person always ended similar to “there can be only one god”, “we can prove that other gods don’t exist” or “without a god, morality would be pointless”. And there was never a slightest chance for me to get their thinking beyond that point, where they could – at least in theory – imagine an alternate reality.

I felt this huge wall in their mind. A wall that – I assume - can only be built and cemented with years of steady external and self-energizing indoctrination. Though being large, solid and inflexible, this wall represents value. A safe monolith on which they can rely on to exist after a bad day or a tragedy.

I don’t think that a mind-based “safe haven” is a bad thing to have. I even think that it is a very important thing to ensure personal stability.

Konstruktor is growing up a little.

In revision 18, Konstruktor, supports precedence selection of constructors in the Builder:

Use the new Builder method “preferConstructor<ImplementationType>(params Type[])” to prefer a specific constructor of an implementation type.

Take a look out at these unit tests to find out more about how to configure constructor precendence by using attributes or the Builder.