Direkt entliehen von hier und ein schönes Beispiel für PHPs Handling mit Unicode-Zeichen:
1 2 3 4 5 | <meta charset="utf8"> <?php $a = 'äa'; echo "with space: " . $a[0] . " " . $a[1] . "<br />"; //� � echo "without space: " . $a[0] . $a[1] . "<br />"; //ä |
bzw. analog dazu:
1 2 3 4 5 |
Klar: Das ä belegt 2 Byte:
1 2 3 4 |
Schon besser:
1 2 3 4 5 |
Mir war das zwar im Prinzip schon alles klar, durch so ein Beispiel wird aber nochmal deutlich, dass man die nicht-mb_* – Funktionen partout meiden sollte.
Neue Linkwelle!
Aufgabenstellung: Ich weiß, wo ich mich befinde (Lat / Long, ist ja aus den Smartphones easy herauszubekommen) und habe einen Radius in km, in dem ich POI’s mit der Open Streemap API suchen möchte.
Problem: Die OSM API bietet keine (mir bekannte) Möglichkeit, um meinen aktuellen Standort herum eine Radius-Suche in km auszuführen, sondern hätte gern eine Bounding Box angegeben, die die Ecken der Box als Geo-Koordinaten angibt – siehe hier:
1 | http://www.overpass-api.de/api/xapi?node[bbox=8.62,49.85,8.68,49.89][amenity=fast_food|pub][@meta] |
Dabei spezifiziert der Parameter bbox die Lat/Long-Koordinaten in der Reihenfolge links, oben, rechts, unten.
Dazu erstmal zum Verständnis:
Für ein Hochschulprojekt (“Ortsbezogene Freizeitgestaltung”) gilt es, die Open Streetmap API zum finden von POI’s in der Umgebung zu verwenden. In Darmstadt ist auf der OSM fast jede Parkbank kategorisiert. Also frisch ans Werk!
Wer eine einfache Variante zum String Replacement benötigt, kann entweder den Regex-Weg gehen (siehe Nachbildung der PHP-Funktion str_replace), oder einen schnuckeligen Trick anwenden:
1 | alert("Finde mich".split("Finde").join("Replace")); |
Den String zum Array am Suchwort zerlegen und dann mit dem Ersatz das Array wieder zusammenfügen. Brauchte letztens eine Quick&Dirty-Lösung, um Zahlen des Formats
1 | 600.000,54 |
in das Javascript geläufige Zahlenformat
1 | 600000.54 |
zu überführen, also Dezimalpunkte raus und Komma durch Punkt ersetzen. Gemacht habe ich es so:
1 | var num = "600.000,54".split(".").join("").split(",").join("."); |
Gewinnt sicher keinen Schönheitspreis, die innovative Verwendung von join und split gefielen mir dann aber doch zu gut ;).
Apps sind zur Zeit in aller Munde. Bekanntlich gibt es mit Android und iOS mal mindestens 2 ernst zu nehmende Plattformen, auf denen man in der Regel vertreten sein möchte. Heißt: Zwei mal dasselbe programmieren, einmal in Java und einmal in Objective C. Das muss nicht sein. Mit dem Cross Platform Framework Appcelerator Titanium wird die Entwicklung in Javascript vorgenommen – nebst Zugriff auf die Gerät-APIs wie Kamera, Beschleunigungsmesser, GPS und allem Klimbim. Nur am Rande: Titanium ist kein kleines Nebenprojekt eines gelangweilten Studenten. Ein paar Millionen Apps sind damit schon erstellt worden, u.a. auch das fies gehypte Wunderlist.
Disclaimer: Hier wird Dampf abgelassen. Tiefgründige Ergüsse sind nicht zu erwarten.
In der letzten Zeit häuft sichs: Dreiste Fehler in ausgewachsener Software. Vielleicht hatte ich auch viel Pech bei der Auswahl, tut aber nichts zur Sache. In der offiziellen Version 1.7.2. des millionenfach verwendeten Cross-Platform-Mobile-Application-Frameworks ™ Appcelerator Titanium ist auf einmal die Build-Funktion für Apps so hart kaputt, dass man ohne manuellen Eingriff in das Build-Script nichts mehr in den App-Store / Android Market bekommen wird.
Der klassische Ablauf beim Testen von Code, der eine Exception werfen soll, ist der Folgende (PHPUnit):
1 2 3 4 5 6 7 | /** * @expectedException InvalidArgumentException */ public function testException() { throw new InvalidArgumentException(); } |
Problem dabei: Wir haben nicht spezifiziert, an welcher Stelle die Exception geworfen werden soll. Außerdem können wir nicht prüfen, ob die geworfene Exception genau die erwartete oder nur igendeine war.
Jetzt lässt sich das noch aufbohren:
1 2 3 4 5 6 7 8 | /** * @expectedException InvalidArgumentException * @expectedExceptionMessage Right Message */ public function testExceptionHasRightMessage() { throw new InvalidArgumentException('Right Message'); } |
Auch damit werde ich nicht glücklich. Wenn ich jetzt z.B. mehrere Exceptions in einem Test prüfen möchte (guter Stil hin oder her) stößt man an die Grenzen diesen Ansatzes.
Etwas feingranularer ist das Handling mit der nachfolgend vorstellten Methode setExpectedException.
Hab heute in meiner favorisierten Datenbank-GUI HeidiSQL den Query Profiler entdeckt, hinter dem sich bei genauer Recherche das MySQL-Kommando SHOW PROFILE verbirgt – nur grafisch aufgehübscht.
query-profiling
Eine sinnvolle Ergänzung zu EXPLAIN – grade die temporären Tabellen oder unerwartet auffällige Sortierungen fallen hier schnell auf.
Ein geschätzter Arbeitskollege gab mir neulich den Tipp, es mal mit der von Microsoft speziell für Programmierung entwickelten Schrift Consolas zu versuchen. Ich hab einen Schriftwechsel erst als unnötig abgestempelt, war dann aber doch froh, es getan zu haben.
Meine favorisierte IDE Netbeans kommt standardmäßig mit der Schriftart Monospaced daher. Sieht so aus:
monospaced
Heruntergeladen und in Netbeans als Standardfont in Größe 14 eingestellt (12 finde ich zu klein). Resultat:
consolas
Finde ich dann doch deutlich angenehmer.
