ScriptBlogger

Passend zum heutigen 29. Februar. Eine Funktion die prüft, ob ein gegebenes Jahr ein Schaltjahr ist.

/**
 * Check if a given year is a leap year
 */
function leapYear($year)
{
    $r = $year % 400;
    if ($r === 0) {
        return true;
    }
    
    $r = $year % 100;
    if ($r === 0) {
        return false;
    }
    
    $r = $year % 4;
    if ($r === 0) {
        return true;
    }
    
    return false;
}

Quelle der Berechnung: Wikipedia

Nachtrag: Der Aufruf der PHP-Funktion date() mit dem Parameterwert 'L' tut es auch. Siehe auch die Kommentare.

In einer Mailingliste hat sich kürzlich eine Diskussion darum entsponnen, wie man sich für den Fall absichert, dass der Entwickler eines laufenden Projektes vor einen Bus läuft. Oder weniger dramatisch gesprochen, wie geht es weiter, wenn der Auftragnehmer ausfällt.

Irritierender Weise wurde die Wichtigkeit von Frameworks hervorgehoben. Was für ein Unfug. Ich finde es erstaunlich, dass man von der Frage, wie man den Ausfall eines Auftragnehmers absichern kann, zum Thema Frameworks kommt. Frameworks sind in diesem Fall eine technische Nebensächlichkeit. Ob das Projekt mit einem Framework gebaut wurde oder nicht, spielt nicht einmal ansatzweise eine Rolle.

Auch die Einarbeitung in ein Projekt kam zur Sprache. Das könne bei großen Projekten schon mehrere Tage bis Wochen dauern, ließ man wissen. Ich frage mich echt, was das für Leute sind. Wer wirklich meint, er müsse sich alle zigtausend Dateien eines Projekts ansehen, der kann das gern in seiner Freizeit machen. Um mit der Arbeit an einem Projekt zu beginnen, ist es aber nutzlos und absolute Zeitverschwendung. Gerade bei größeren Projekten wird nicht einmal der ursprüngliche Entwickler den Überblick über den kompletten Code haben. Dasselbe gilt, wenn ein Entwickler-Team an einem Projekt arbeitet. Da wird der Einzelne auch nur seinen eigenen Code kennen.

Viel wichtiger sind andere Punkte. Wie zum Beispiel gute Dokumentation und die Verfügbarkeit der Quelldateien. Jeder fähige und erfahrene Entwickler wird damit etwas anfangen können.

Mein Tipp an alle diejenigen, die Befürchtungen dieser Art haben:

1. Besprecht das Thema mit dem Auftragnehmer
2. Lasst euch die Quelldateien aushändigen
3. Drängt darauf, dass das Projekt dokumentiert wird

Und sollte der Ernstfall eintreten, dann sucht ihr einfach einen neuen Entwickler. Die Kriterien dafür sind dieselben, wie bei der ursprünglichen Vergabe des Projektes.

1. Kann der Auftragnehmer Referenzen vorweisen
2. Je höher der Stundensatz, desto zahlreicher die Referenzen
3. Die Referenzen sollten im Umfang dem Projekt ähneln, das der Entwickler übernehmen soll
4. Kann der Auftragnehmer Kapazitäten zusichern

Es gibt sicherlich noch weitere Punkte. Vielleicht fällt ja jemandem noch etwas ein.

In der aktuellen brand eins stellt der Autor des Artikels "Gute Frage: Warum soll das Netz eigentlich "neutral" sein?" die Netzneutralität in Frage. Er vergleicht darin das Internet mit einem Paketdienst. Wer seine Daten schneller haben möchte, der soll, wie bei Paketdiensten, Expresszuschlag zahlen.

Außerdem hält der Autor es für unfair, dass Power-User genauso viel (beziehungsweise wenig) zahlen, wie normale Nutzer. Nach seiner Meinung sollten Nutzer von Websites wie Netflix oder YouTube für das höhere Aufkommen an Datenvolumen auch mehr bezahlen.

1. Power-User

Die Probleme mit den Power-Usern sind von den Netzbetreibern selbst verursacht. Wer Flatrate-Tarife anbietet, muss  damit rechnen, dass es Kunden gibt, die diese Tarife auch ausreizen. Wenn ich bei T-Online eine Flatrate mit unbegrenztem Daten-Volumen buche, dann erwarte ich auch, dass ich unbegrenztes Datenvolumen erhalte. Wenn das für T-Online wirtschaftlich von Nachteil ist, dann muss T-Online die Flatrate-Tarife abschaffen. Wie das geht, kann man bei mobilen Netzbetreibern beobachten, die fast ausschließlich Volumentarife anbieten. Dass diese Flatrates genannt werden, ändert daran nichts.

2. Facebook und Youtube

Wer Web-Server betreibt, zahlt automatisch für das Datenvolumen. Im Falle von Facebook, Google und Youtube dürfte das einer der größeren Posten auf der Rechnung sein. Online-Firmen fragen sich also zu Recht, warum sie noch einmal für eine Leistung bezahlen sollen, für die bereits Geld geflossen ist. Dass Netzbetreiber von Online-Firmen Geld für die Durchleitung der Daten verlangen, ist einfach nur dreist. Für diese Leistung wurde nämlich bereits bezahlt. Siehe Punkt 1.

3. Netflix und World of Warcraft

Kunden der Netzbetreiber zahlen für ihren Internetzugang. Kunden von Netflix etc. zahlen für die angebotenen Inhalte. Warum sollen sie noch einmal extra zahlen, nur weil die Netzbetreiber mehr Kapazitäten (siehe Punkt 1 und Flatrates) verkaufen, als sie tatsächlich haben?

4. Netzneutralität

Ich spiele keine Online-Games. Ich nutzen eher selten Youtube. Ich nutze Facebook gar nicht. Und ich könnte und würde es mir leisten, mehr Geld für die Internetverbindung auszugeben, sollte das notwendig sein. Weniger finanziell leistungsfähige Mitmenschen müssten aber mit dem Vorlieb nehmen, was die Netzbetreiber ihnen am Ende zugestehen. Und das wird, wie oftmals bei Basistarifen, nicht besonders viel sein. Ist das gerecht?

Dass man es als unfair empfinden mag, selbst genauso viel für den Internetzugang zahlen zu müssen, wie jemand, der das Zigfache an Datenvolumen herunterlädt, ist kein Problem der Netzneutralität. Es ist ein Problem der Gestaltung der Tarife durch die Netzbetreiber. Genauso gut könnte man sich über Vieltelefonierer oder Massen-SMS-Schreiber aufregen.

Einer unserer Kurz-URL-Dienste wurde in der letzten Woche zum Verteilen von Schad-Software missbraucht. Dank zahlreicher Hinweise wurde die URL zügig deaktiviert. Anschließende Aufrufe liefen damit glücklicherweise ins Leere.

Leider klicken zu viele Nutzer auf derartige Links in E-Mails. Bis zum 19. Februar waren das über 8.000 Leute.

Dem gegenüber stehen knapp 250 Leute, die die URL in Suchmaschinen eingegeben haben und so auf unseren Artikel aufmerksam wurden. Und eine handvoll Leute hat sogar E-Mails geschrieben oder angerufen.

Wenn man als Software-Entwickler seine Kunden berät, muss man denen manchmal auch Funktionen ausreden. Natürlich könnten wir dem Kunden jeden Wunsch von den Augen ablesen und jede geforderte Funktionalität einbauen, ohne den Sinn zu hinterfragen. Aber, was soll das? Wir sehen uns als Partner des Kunden. Kunden kaufen bei uns nicht nur Code, sondern auch Beratung.

Das resultiert dann darin, dass wir bei Anfragen nach Änderungen oder Erweiterungen, die uns eher obskur vorkommen, noch einmal nachfragen:

Können wir gern machen. Kommt das denn so häufig vor, dass es sich lohnt, das zu automatisieren?

Darauf dann der Kunde:

Sie haben recht. Lohnt sich nicht, zu automatisieren.

Wer denkt, uns wäre hier ein Auftrag durch die Lappen gegangen, denkt erschreckend kurzfristig. Uns jedenfalls hat diese Praxis nur Pluspunkte gebracht. Wir werden mit neuen Aufträgen nur so zugeschüttet. Fast ausschließlich von langjährigen Kunden.

Beim Vergleich von Zeichenketten, gibt es vielerlei Feinheiten. Heute geht es um '0:0' gegen '00:00'. Welcher der beiden Werte ist größer?

Die Antwort lautet: Der erste Wert.

<?php

echo '0:0' > '00:00';

Ergibt als Ergebnis 1 (bzw. true).

MySQL sieht das genauso:

SELECT '0:0' > '00';

Das Ergebnis ist hier ebenfalls 1.

Relevant wird das beim Vergleich von zwei Datumswerten.

'2012-02-20 0:0:0' > '2012-02-20 00:00:00'

So ist zum Beispiel auch folgender Vergleich als Ergebnis true:

'2012-02-20 0:0:0' > '2012-02-20 09:59:59'

Unsere Bußgeldrechner-App startete unter Android 2.1 nicht. Leider gab es auch keine Fehlermeldung oder Exception in Logcat zu sehen. Stundenlanges herumprobieren hat dann folgendes zu Tage gebracht.

<bitmap
xmlns:android="http://schemas.android.com/apk/res/android"
android:src="@drawable/top"
android:tileMode="clamp"
android:dither="true"
/>

Die rot markierte Zeile war für das Abstürzen der App kurz nach dem Start verantwortlich. Der Wert clamp im Attribut tileMode zeichnet übrigens die Randfarbe in X- und Y-Richtung weiter. Mit folgendem Code ersetzt, funktioniert die App auch unter Android 2.1.

<bitmap
xmlns:android="http://schemas.android.com/apk/res/android"
android:src="@drawable/top"
android:tileMode="disabled"
android:gravity="top|left"
android:dither="true"
/>

Das Wichtigste gleich vorweg. Strato erlaubt es nicht, Dateien mit der Endung .html als PHP-Dateien parsen zu lassen. Wer PHP-Code in seinen .html-Dateien ausführen möchte, muss die Dateien in .php-Dateien umbenennen.

Problematisch wird das beim Thema Suchmaschinenoptimierung. Einfach mal alle Dateinamen ändern kann sich nachteilig auf das Ranking auswirken.

Die Lösung ist mod_rewrite. Mit einer einfachen Anweisung in der .htaccess werden alle .html-Dateien im Hintergrund in .php-Dateien umgeschrieben:

RewriteEngine on
RewriteRule ^(.*).html$ $1.php

Damit können alle Links zu .html-Dateien gleich bleiben, obwohl alle Dateien in .php-Dateien umbenannt wurden.

Seit gestern schreiben uns Leute oder rufen uns an und wollen wissen, warum wir denen eine Rechnung schicken. Erhalten haben die Leute folgende E-Mail:

Ihre Rechnung fuer diesen Monat finden Sie unter dem folgenden Link

http://kleinerlink.de/88

Rechnung-Nummer: 13439030

Der Betrag ist innerhalb von 5 Tagen auf unserem Konto zu überweisen.

kleinerlink.de ist eine unserer Kurz-URL-Domains. Der (umgehend von uns deaktivierte) Link führte zu einem Download einer .exe. Vermutlich ein Trojaner oder ein Virus.

Für den Fall, dass das nicht klar sein sollte: Wir verschicken keine Spam-/Phishing/-Schadprogramm-E-Mails und wir verteilen auch keine Schadprogramme.

Wichtiger Nachtrag

Sollten Sie die E-Mail erhalten haben, bitte klicken Sie auf keinen Fall auf den Link. Führen Sie bitte auch auf keinen Fall die zum Herunterladen angebotene Datei aus. Es handelt sich um keine echte Rechnung. Und auf keinen Fall wurde die E-Mail von uns an Sie versendet.

Was für ein Mist. Heute fährt wieder jemand einen DOS gegen unseren Kurz-URL-Server. Die Angriffe werden jetzt erst einmal geblockt und der Server ist auch wieder gut erreichbar. Hoffen wir, dass es so bleibt.

Letztens schrieb ich, dass wir MDB2 durch eine Eigenentwicklung ersetzt haben. Die Entscheidung beruhte einzig allein auf der Tatsache, dass es mit MDB2 in Verbindung mit bestimmten MySQL-Versionen auf einigen Servern Probleme gab.

Heute offenbarte sich ein weiterer Vorteil. Bei unserem Terminplaner hat sich die Script-Laufzeit um 200ms verringert. B-)

In den letzten Wochen haben wir für einen Kunden Änderungen an seinem Shop-System vorgenommen. Änderungen ist eigentlich das falsche Wort. Fehlerkorrekturen trifft es eher.

Der Kunde setzt eine kommerzielle Version von XT-Commerce ein, das von dem Anbieter stark modifiziert wurde und unter einem eigenen Namen vertrieben wird. Selten hat man einen so dramatisch schlechten Haufen Code gesehen. Nun ist Optik ja nicht alles und nicht jeder steht auf sauber programmierten Code. Hauptsache es funktioniert.

Ähnlich scheinen das die Entwickler der diversen Module für den XT-Commerce-Ableger zu sehen; nur mit einem kleinen Unterschied. Bei denen funktioniert der Code nicht einmal richtig. Hier ein paar Beispiele:
Ein Modul zum Benachrichtigen der Kunden, dass die Bonuspunkte bald ungültig werden und schleunigst eingelöst werden sollten, bringt ein Cron-Job-Script mit, das aber nicht als Cron-Job im eigentlichen Sinne ausgeführt werden kann, weil es nur von einem eingeloggten Administrator ausgeführt werden kann.

Ein Modul, das den Preis auf Basis von eingegebenen Gutschein-Codes und eingelösten Bonuspunkten reduzieren soll, berechnet die Umsatzsteuer falsch.

Ein Modul, dass täglich ein anderes preisreduziertes Produkt als Tagesprodukt präsentieren soll, übergibt als Preis den Wert 0,00 EUR an den Warenkorb. Das resultiert darin, dass Kunden dieses Produkt kostenlos erwerben können.

Und das ist nur die Spitze des Eisbergs. Der Kunde hat schon angekündigt, dass da noch einiges kommen wird.

Übrigens: Das Wort Modul ist im Zusammenhang von XT-Commerce eigentlich nicht das richtige Wort. Um diese "Module" zu integrieren, muss man nämlich direkt im Code der verschiedenen Script-Dateien herum pfuschen. Das bedeutet im Endeffekt dass man sich nach dem Einbau des ersten Moduls davon verabschiedet, das Shop-System jemals auf eine neuere Version aktualisieren zu können.

Finger weg, also, von XT-Commerce und seinen Derivaten. Es gibt definitiv bessere Systeme.

Da trägt man die eigenen Scripte in diverse Script-Archive ein und sieht auch, dass einige davon sogar Besucher bringen, aber folgendes Feedback ist doch immer noch das Beste:

First of all, let me congratulate on your marketing strategy - I'm coming across your script on virtually every php/booking script- related web page ;]

Ein Kunde von uns, nennen wir ihn Herrn Eichholz, setzt unsere Online-Terminvereinbarung und ein auf XT-Commerce basierendes Online-Shop-System ein. Im Shop kann man Gutscheine erwerben und dann bei der Reservierung, beziehungsweise Wahrnehmung, des Termins einlösen.

Herr Eichholz hat bislang immer nach einer Bestellung in einem Schreibprogramm den Gutschein-Code in eine Vorlage eingefügt und dann in Form einer PDF-Datei per E-Mail an seinen Kunden geschickt. Der ganze Prozess dauerte zwischen fünf und sieben Minuten pro Gutschein. Hat Herr Eichholz gemessen.

Zum Weihnachtsgeschäft nun wollte Herr Eichholz als Promotion-Maßnahme seine Gutscheine auf diversen Deal-Websites anbieten. Aus Erfahrung wusste er, dass das in mehrere Hundert Bestellungen resultieren kann. Das würde aber stundenlanges digitales Gutscheinebasteln für Herrn Eichholz bedeuten. Wertvolle Zeit, die sicherlich besser genutzt werden könnte.

Also haben wir für Herrn Eichholz ein Modul für den Terminplaner programmiert, das die Bestellungen aus dem Schop-System ausliest und dann die PDF-Gutscheine mit einem Gutschein-Code und dem Ablaufdatum erstellt und dem Kunden per E-Mail schickt.

Wenn dann der Kunde später einen Termin reserviert und den Gutschein-Code eingibt, wird der Gutschein automatisch entwertet und kann kein zweites Mal eingelöst werden.

Der Aufwand für Herrn Eichholz reduziert sich durch die Software auf zwei Klicks. Er kann die gewonnene Zeit viel sinnvoller für sein Kerngeschäft nutzen. Und Herr Eichholz kann sich sicher sein, dass jeder Gutschein nur einmal eingelöst wird.

Ein Kunde von uns ist Marktführer (oder so gut wie) in seiner Branche. In dieser Woche haben wir dem Kunden eine neue Software zur Nutzung übergeben. Das Projekt war mehrere Monate in der Mache und enthält einige technische Raffinessen.

Um den Mitbewerbern jedoch keine Einblicke in die Arbeitsweisen zu geben, wurde vereinbart, keine Screenshots oder Beschreibungstexte zu veröffentlichen. Ist zwar ein bisschen schade, aber auf jeden Fall nachvollziehbar.

Statt ausschweifender Prahlerei und Selbstlobpreisungen in Wort und Bild, wie sonst bei uns üblich, machen wir einfach mit dem Projekt weiter. Die Zeit können wir auch gut gebrauchen, denn der Kunde hat noch etliche Ideen für die Software.