Umgang mit durchgehenden Nummernkreisen in einem ERP-Anwendungsfall

Problem: Belege mit einem durchgehenden Nummernkreis müssen erzeugt werden. Die Reihenfolge der Erzeugung ist unbestimmt. Bereits erzeugte Belege können erneut erzeugt werden (etwa nach Korrekturen).

Man kann sich viele Methoden überlegen, um mit so einem Problem umzugehen. Man könnte weitere Annahmen treffen, z. B. die, dass Belege möglicherweise nicht verwendet werden und dadurch nach aussen hin Lücken im Nummernkreis entstehen. Eine Anforderung könnte sein, dass diese Lücken geschlossen werden müssen.

Ich habe das Problem wie folgt gelöst. Die Ausgangslage war, dass durchgehende Nummern erzeugt worden sind, die Verwendung allerdings völlig unklar war. Dadurch sind Lücken entstanden. Die Dynamik der Neuerzeugung hat es nicht zugelassen, einen konsistenten Nummernkreis zu erzeugen. Daher habe ich nun “Reservierungen” für Nummern eingeführt. Ein Beleg reserviert seine Belegnummer und wird diese immer behalten. Das Kriterium für einen “Beleg” ist ein Zeitraum und eine Entität. Dieser letzte Punkt ist wichtig – bitte immer eine Definition für einen Beleg einführen! Nur durch einen eindeutigen Schlüssel ist eine Reservierung möglich.

Posted in Uncategorized | Leave a comment

Why I don’t like the “Impl” suffix in code

A suffix is part of the name of a class. As it is part of the name, it should transfer some kind of meaning about the class’ function and its position in the application.

Sometimes, the suffix “Impl” is being used. Particularly, for situations where the class is part of some pattern, where two classes are mirroring each other, working together towards different external interfaces (for example, this could be the Factory or the Facade pattern).

I suppose that the syllable “Impl” should put emphasize on a property of the respective class. The question is, which one? One possibility might be that the class implements some critical piece of functionality.

There are two reasons why I think that the “Impl” suffix should not be used.

  • It is redundant – code should implement something, right? So why should we have to emphasize this fact?
  • It is overly generic – it does not describe any specific function or structural property of the class.

For these reasons, I think that the “Impl” suffix is useless.


Posted in Uncategorized | Leave a comment

Recording audio directly from the sound card

Some Internet radio stations do not provide mp3 streams or similar open access to their content. Flash players are being used by some of the best Internet radio stations. Audio recording is not easy just having a Flash audio stream. But you can always record the audio from the “sound card” directly (modern PCs don’t have sound cards, of course). You can record directly “from the speakers”, using Audacity.

Audacity settings

The Audacity Tutorial describes the required setup. Of course, this has the disadvantage that you cannot record an audio stream in the background, while listening to another stream.

Posted in Uncategorized | Leave a comment

Comparing .NET DateTime Objects

The .NET DateTime type has lots of issues, as has been noted many times. However, it is appealing due to its (seeming) simplicity. An important task when working with timestamps is comparing them.

It seems that when you compare two timestamps t1 and t2, you would expect that t1 == t2 is valid only if both timestamps represent the same time of day, at the same day, referring to the same time zone. For example, the timestamps 2014-10-03T14:00:00Z (which represents a UTC timestamp) and 2014-10-03T14:00+02:00 designate two different points in time. The second timestamp is representing a point in time in a time zone that has an offset of two hours to UTC (a.k.a. Zulu time, thus the Z). 14:00 in this time zone is two hours earlier than 14:00 in UTC.

Let’s consider an example. The United Kingdom is basically using UTC. Not considering daylight savings time, there is a zero-offset between local time in the UK and UTC. The time zone used in Germany has an offset of +01:00 to UTC. This means that in Germany, noon happens one hour earlier than in the UK. During daylight savings time, Germany has a two-hour offset to UTC. So, when you have a local time stamp in Germany’s time zone, it has a one- or two-hour offset to UTC. 14:00 in Germany’s time zone is not equal to 14:00 UTC.

But is this true in .NET’s DateTime?

See what happens when you compare DateTime objects:

var dt_Unspec = new DateTime(2014, 10, 3, 14, 00, 00);
var dt_Local = new DateTime(2014, 10, 3, 14, 00, 00, DateTimeKind.Local);
var dt_Utc = new DateTime(2014, 10, 3, 14, 00, 00, DateTimeKind.Utc);
Console.WriteLine(dt_Unspec == dt_Local);
Console.WriteLine(dt_Unspec == dt_Utc);
Console.WriteLine(dt_Local == dt_Utc);

The output of this code is:


According to .NET, all these DateTime objects refer to the same point in time!

This is, to say the least, somewhat unexpected. However, maybe there is some deeper reason why .NET yields that result?

First, there is this somewhat ominous variable dt_Unspec, which is created withoug giving an explicit time zone. The result is a timestamp for which the time zone is not specified. There are many situations where this makes sense in software. Sometimes, you just don’t care about the time zone, or you are not sure yet which time zone should be applied. Therefore, you can leave that information open and convert the timestamp later on. If you convert it into UTC, .NET assumes it was LocalTime and vice versa. It’s like a “quantum” time zone.

When comparing the unspecified time zone with a specified one, it makes sense to assume that both timestamps are in the same time zone. After all, the timestamp with the unspecified time zone could be in the same time zone, which would be made explicit after a conversion. From this point of view, the first two comparisons should yield True.

But if the first two comparisons yield True, it is a necesssary consequence that the third comparison also yields True. After all, what would you expect from the comparison a == b when you already know that a == c and b == c? If both a and b equal c, you would expect that also a equals b, wouldn’t you?

On the other hand, this has interesting consequences. If you convert a timestamp into a different time zone and compare the new value with the original one, they will be considered unequal:

var d1 = DateTime.Now;
var d2 = d1.ToUniversalTime();
Console.WriteLine(d1 == d2);

This yields False, as we are expecting by now. (Note that my computer is running in a time zone that has a non-zero offset to UTC. You might get different results if you are running in the UTC time zone itself or a time zone with a zero offset.)

When comparing timestamps, .NET is ignoring the time zone. And from what we have seen here, this seems logical within this framework, since it is legal to use a “unspecified” time zone in .NET.

I am quite sure that I am not the first to note this quirk of DateTime. In defense of Microsoft, coming up with a simple-to-use but universally correct date/time library is not an easy job. For business applications, DateTime might be well-suited, if you are careful. And then there are alternatives like DateTimeOffset (which I should investigate further). Java has its own problems with its date/time structures in the JDK. And of course, there is always Joda-Time and its relative Noda Time, which are better suited for complex tasks.

Posted in .NET, Software, Time | Leave a comment

Posting a HTML form with AJAX

Sometimes it is necessary to post the data from a HTML form not by using a submit request (e.g. through a submit button or a (JQuery) submit call) but by using an asynchronous request. This may come handy for example for single-page applications, or if a download is triggered by submitting the data. In the latter case, you might want to display a small dialog box telling the user that the data is being prepared for download. Hint: Handy for this job is a JQuery plugin by John Culviner.

Suppose you have a MVC controller in the backend, which expects a certain data model coming with the submit/POST request. Somehow you need to prepare the form data such that you can post it to the controller in the appropriate format. Usually, this is done automatically by the browser when you press the submit button. If we want to do the POST from JavaScript, we need to wrap the data ourselves. Fortunately, this is not so hard. We just need to build an object out of the form elements that hold user input data. A simple solution would be (using JQuery, and it is TypeScript, by the way, but the JavaScript version almost looks the same):

var form2object = (formName: string): any => {
var data = {};
var allChildren = $(document.getElementById(formName)).find("input, select");
for (var i = 0; i < allChildren.length; i++) {
var child = allChildren[i];
var c_name = $(child).attr("name");
var c_val = $(child).val();
data[c_name] = c_val;
return data;

As you can see, we select all children of the form that are either input or select elements. For each of these, we add a new property to a dynamic data object where the name attribute is being used as the property name. This is compatible with the way ASP.NET MVC does the model binding. The value of the property becomes the the value of the form element. This data object can then be used in a JQuery $.ajax(... call, for example.

Posted in ASP.NET MVC, JavaScript, Software | Leave a comment

Claims-based authentication for ASP.NET/MVC applications (Part 1)

Remember that before setting up a claims-based application, use NuGet to obtain some packages for your application (even in VS2013 with .NET 4.5.1). Look for “identitymodel” in NuGet.

Posted in .NET, Windows | Leave a comment

Canvas (HTML 5) Mouse Position

Want to know the position of the mouse pointer within your <canvas> element? Use jQuery? This code works in IE, Firefox, and Chrome:

$("#canvas_id").mousedown(function (event) {
var offset_x = event.pageX - $(this).offset().left;
var offset_y = event.pageY - $(this).offset().top;
// do something with the position

jQuery offers position() (which we don’t use) and offset() (which we use) to retrieve the position of an element relative to its enclosing element and the document, respectively. As jQuery also provides the position of the mouse relative to the document in the event.pageX properties, simple arithmentic is used to determine the offset within the element.

Want to play around with position data in mouse events? Try this:

$("#foo").mousemove(function (e) {
var pos = $(this).position();
var offset_x = e.pageX - $(this).offset().left;
var offset_y = e.pageY - $(this).offset().top;
console.log(e.pageX+","+e.pageY+" "+e.clientX+","+e.clientY+" off: "+e.offsetX+","+e.offsetY+" "","+pos.left+" "+e.layerX+","+e.layerY+" offset() "+$(this).offset().left+","+$(this).offset().top+" "+$(this).position().left+","+$(this).position().top+" offset = "+offset_x+","+offset_y);

Posted in HTML 5, JavaScript, Software | Leave a comment