It’s code we do

I wrote the following text almost a year ago but never released it. Reading it again today, it’s still valid and these are still my thoughts. So, i can publish it today.

Preparing some things for work, trying to find ways to happiness while working with legacy code, the title above formed in my head.

“It’s code we do!”

Delivering products is meeting expectations
If you build a house you need to trust the architect that he cares about the statics of your new build home and you need to trust the construction builder caring about the proportion of ingredients in the concrete he uses. You’re not able to check this. All you could do is hiring a specialist to check the work done for you. But then you need to trust him.

It’s dead simple. All day long we’re working as programmer to fulfill our clients wishes. Most of the time, our clients aren’t able to understand the inner quality of the product they buy. They are just happy if they can use them in the way they want. This doesn’t mean we shouldn’t care about the inner quality, because if neither the client nor we care about, noone does.

Would you buy a car produced this way? You’re not able to measure the quality of your car and the manufacturer just doesn’t care about it, because you aren’t able to check the quality of the piston rings.

“The piston rings of the last engine model don’t fit perfectly into the new one, but who cares. The customer will never tell the difference. She asked for a city car. If she never drives faster than 100 kph there will be no problem.”

We, as the architects and builders of the software our customers ask for, are the specialists our customers trust in. Even if our customer can’t tell the difference between good and bad code, they trust in us to deliver only good one.

Softdeletes mit Regeln in PostgreSQL

Es gibt immer mal wieder Gründe, gewisse Daten nicht unwiderruflich zu löschen. Manchmal ist es einfach, weil man selbst auch in der Zukunft noch wissen will, was in der Vergangenheit so los war. Es können aber auch Gesetze oder Regeln sein, die einen dazu zwingen. Da findet man dann so Sachen wie die Grundsätze der ordnungsgemässen Buchführung, die einem sinngemäss unter anderem sagen, dass man nichts löschen darf, was man einmal aufgeschrieben hat. Trotzdem kann es aber natürlich immer vorkommen, das ein Datensatz mal korrigiert werden muss, weil irgendwas falsch lief. Wenn dann mal jemand einen Datensatz erzeugt hat, der eigentlich nicht da sein sollte, will man den aber natürlich trotzdem wieder los werden, ohne mit dem Gesetz in Konflikt zu geraten. Hier kommt dann of das sogenannte “Soft Delete” ins Spiel, also die Markierung eines Datensatzes als gelöscht, statt ihn wirklich physisch zu löschen.

Am einfachsten geht das, indem man einfach ein UPDATE auf den entsprechenden Datensatz ausführt.

1
2
UPDATE TRANSACTION SET isdeleted=TRUE WHERE id=5
3

Intuitiv ist das aber nicht und noch dazu schützt es nicht vor einem voreiligen Datenbankadmin oder Programmiererkollegen, der dann doch mal mit Direktzugriff den Datensatz löscht, weil ihn jemand drum bittet und er nicht bedenkt, dass da nicht gelöscht werden sollte.

Als Alternative bietet es sich an, weiter mit dem DELETE-Statement zu arbeiten, aber statt des physischen Löschens ein Update auf den Datesatz durch eine Regel zu definieren.

1
2
CREATE RULE transaction_softdelete AS 
3
ON DELETE TO TRANSACTION DO INSTEAD
4
    UPDATE TRANSACTION SET isdeleted=TRUE WHERE id = OLD.id
5

Das allein schützt dann zwar immer noch nicht vor einem boshaften Admin, aber dem muss man dann eben mit Vertrauen oder feinerer Rechtezuweisung begegnen.

Lesetipp 1 – Load Average und so

Ich hatte heute ein paar Fragen zu Lastproblemen mit Servern und sowas zu beantworten. Auf der Suche nach vorgefertigten Texten, damit ich nicht alles selbst tippen muss und einfach an ein paar Personen Links weitergeben kann, habe ich folgendes gefunden und halte das hier mal fest:

load average – A measure of the CPU load on the system. The load average in FreeBSD is an average of the number of processes ready to run or waiting for short-term events such as disk I/O to complete, as sampled once per second over the previous one-minute interval of system operation.

aus ‘The Design and Implementation of the FreeBSD Operating System’ von Marshall Kirk McKusick und George V. Neville Neil
(Link zu Amazon)

Was soll das?

Zum wiederholten Mal versuche ich mich im Betreiben und Befüllen eines Weblogs. Ich kann nicht mit Sicherheit sagen, der wievielte Versuch das ist, aber ich hoffe das es diesmal länger dauert, bis ich wieder aufhöre. Damit das mit dem länger dauern klappt, ist es gut, wenn man am Anfang zumindest einen groben Plan hat, was man eigentlich machen will. Aus diesem Grund werde ich den groben Plan in dieser Einführung mal etwas ausführen.

Einerseits will ich natürlich wieder einen Platz haben, an dem ich Dinge kommentieren kann, die mir so auffallen. Irgendeine Nachricht, ein Buch, irgendein wie auch immer geartetes Ereignis, ein wundervolles neues Gesetz, das aus der Nähe besehen irgendwie albern oder gefährlich scheint. Sowas halt. Zusätzlich will ich dieses Weblog aber auch nutzen, um aus dem Leben eines Programmierers zu berichten und technische Texte (also Zeug das irgendwie mit Programmieren zu tun hat) zu schreiben. Es wird sich hier also der ein oder andere Codeschnipsel finden, irgendwelche Spielereien mit Programmiersprachen oder irgendwelchen Techniken, die ich einfach mal ausprobieren will.

Darüber hinaus ist nicht ausgeschlossen, das auch andere Themen hier einen Platz finden. Modetipps wirds aber ziemlich sicher nicht geben und auch das Fernsehprogramm werde ich aller Voraussicht nach nicht kommentieren.

In diesem Sinne, herzlich Willkommen. Schau mer mal…