Seit Web 2.0 und AJAX sollte sich eigentlich herumgesprochen haben, dass JavaScript mehr kann als nur nervige Meldungen mittels alert(); auszugeben oder ein bisschen in Formularen herumzupfuschen.
Aber was auf Chrome Experiments gezeigt wird, ist schon allererste Kajüte.
(via Golem)
Eigentlich finde ich den Editor UltraEdit gar nicht so übel. Allerdings dauert das Durchsuchen von vielen Dateien nach einem bestimmten String doch einigermaßen lange.
Angenehm schnell (und einfach) geht es mit der Powershell:
Natürlich kann man auch Unterverzeichnisse durchsuchen und nur bestimmte Dateitypen dabei berücksichtigen:
Am Freitag hatte ich noch ein JavaScript-Problem, das ich leider nicht mehr lösen konnte. Das Problem trat im Zusammenspiel der Multibox (einer Lightbox für verschiedene Inhalte auf MooTools-Basis) mit einem per AJAX geladenen Link auf. Multibox erweitert alle Links mit einer bestimmten CSS-Klasse durch ein onClick-Event, das ein Overlay über die Seite legt, in dem der verlinkte Inhalt angezeigt wird. Dies ist eigentlich auch eine ganz smarte Lösung, denn so erhalten Nutzer, die kein JavaScript (aktiviert) haben, den Inhalt als normalen Link. Allerdings wird mein Link zum Inhalt dynamisch per AJAX geladen. Daher hat das Multibox-Skript gar keine Chance, diesen Link onDOMReady zu kennen.
Mein Lösungsansatz war, einfach in der Verarbeitung des AJAX-Ergebnisses per JavaScript ein neues a-Element zu erstellen und in dem ohnehin schon auf der Seite vorhandenen Multibox-Element hinzuzufügen. Der Ansatz funktioniert auch tadellos im Firefox - leider nicht im Internet Explorer (Object doesn’t support this property or method).
Wenigstens wusste ich schon, an welcher Stelle der Fehler lag. Daher konnte ich das Problem (vereinfacht) nachstellen und heute auch aufspüren: Die von MooTools bereitgestellten Methoden setProperty und getProperty funktionieren im Internet Explorer nur bei Elementen, die bereits im ursprünglich an den Browser ausgelieferten HTML vorhanden sind, nicht bei nachträglich hinzugefügten Elementen.
Nehmen wir folgende (einfache) HTML-Seite:
Wenn ich nun schon motiviert bin, mich mit der PowerShell auseinander zu setzen, will ich natürlich auch gleich weiter machen. Aber es ist wie so oft, wenn man etwas neues lernt - auch wenn die einführenden Beispiele einleuchtend und einfach sind, hat man sie nach einem langen Arbeitstag schon wieder zum Teil vergessen.
Da ich mich kenne, weiß ich, dass ich viel besser lerne, wenn ich die Übung nicht nur mache sondern auch dokumentiere. Dazu werde ich nun einfach das Blog verwenden 
Weiterlesen »
Wie gesagt beschäftige ich mich gerade wenn etwas Zeit ist mit der Windows PowerShell. Einen ganz schönen Einsteiger-Workshop gibt es von Frank Koch, den ich gerade durcharbeite. Ein erstes kleines Skript ist dabei auch schon heraus gekommen - eine HTML-Seite mit den Windows-Services, sortiert nach Status (stopped oder running) und entsprechend dem Status farblich hinterlegt:
[UPDATE: Da das Syntax-Highlighting leider die Darstellung im Internet Explorer versaut, habe ich das kleine Skript erstmal entfernt. Wer sich dafür interessiert, findet es in dem Workshop von Frank Koch]
Sicherlich noch nicht die Monster-Anwendung, aber ich finde es schon ziemlich cool - und bin sehr gespannt, was die PowerShell noch so alles kann.
Um mittels NaturalDocs automatisch eine Dokumentation zu erstellen, muss auf der Kommandozeile eine ganze Latte an Argumenten übergeben werden: Das Verzeichnis, in dem der zu dokumentierende Quelltext steht, das Ausgabeverzeichnis für die Doku und ein Verzeichnis für die Konfiguration. Praktisch sieht ein Aufruf von NaturalDocs bei mir ungefähr so aus:
F:\Software\NaturalDoc\NaturalDocs.bat -i c:\xampp\htdocs\meinProjekt -o HTML c:\xampp\htdocs\meinProjekt\_dokumentation\output -p c:\xampp\htdocs\meinProjekt\_dokumentation\config -cs UTF-8
So einen Aufruf automatisiert man doch. Also mal schnell eine kleine .bat-Datei geschrieben - und dabei festgestellt, dass ich a) die Syntax gar nicht mehr drauf habe (unter DOS habe ich regelmäßig Batch-Dateien geschrieben) und b) die guten alten .bat-Dateien sowas von beschränkt sind…
Daher habe ich mir die Windows PowerShell 1.0 herunter geladen. Startet man die PowerShell, sieht sie auf den ersten Blick genau so aus, wie die gute alte cmd.exe in blau. Aber davon darf man sich nicht täuschen lassen - das Teil ist mächtig. Richtig mächtig.
Die integrierte Skriptsprache hat erstmal alle Basics an Bord - arithmetische Operationen, reguläre Ausdrücke, Schleifen, Fallunterscheidungen, … Wem das nicht reicht, kann immer noch analog zu WSH-Skripten sämtliche COM- und ActiveX-Objekte nutzen. Und wenn man dort an die Grenzen stößt - es stehen auch alle Klassen und Funktionen des .NET-Frameworks zur Verfügung. Es dürfte sich eigentlich keine Automatisierung finden, die nicht mittels Windows PowerShell gelöst werden könnte.
Ich werde mich jedenfalls mal so richtig intensiv mit der Shell beschäftigen. Ergebnisse hier
Heute habe ich mich mal auf die Suche nach einem Software-Dokumentationswerkzeug gemacht, das aus Quellcodekommentaren automatisch eine Dokumentation erstellt. Da ich verschiedene Sprachen zum Entwickeln verwende (angefangen beim guten alten PHP bis hin zu den ersten Gehversuchen in C#) wäre ein Tool, das verschiedene Programmiersprachen unterstützt, sehr willkommen.
Gefunden habe ich zwei Kandidaten: Doxygen und Natural Docs. Hängen geblieben bin ich bei Natural Docs, das auf die sonst üblichen, von JavaDoc bekannten Dokumentationsdirektiven (@author etc) verzichtet und eher auf “natürliche” Sprache setzt:
Mal schauen, wie es sich in der Praxis schlägt 
Am Samstag lag die Jubiläumsausgabe der c’t im Briefkasten - mit dabei eine DVD mit 86 Vollversionen und 39 Spezialversionen. Ein Programm erregte meine besondere Aufmerksamkeit - Basic4PPC, ein BASIC-Dialekt inklusive IDE für Windows Mobile Handys.
Schon länger haben wir das Problem, dass es keinen brauchbaren Wecker für Win Mobile Smartphones gibt. Die eingebaute Erinnerung ist zwar ganz nett, aber auf drei Einträge und eine Auswahl von System-Sounds beschränkt. Die Applikation meiner Frau (Name vergessen [der Applikation, nicht von Simone!], sorry) spielt zwar ein frei wählbares Musikstück ab, ist jedoch Shareware. Also klingelt jeden Mittwoch und Donnerstag um 23 Uhr das Handy, um uns an Harald Schmidt zu erinnern. Ebenfalls nicht das Wahre.
Eigentlich kann es doch nicht so schwer sein, einen Wecker selbst zu schreiben… denkste!
Erster Ansatz war, das Programm einfach unter .NET selbst zu schreiben. Immerhin ist beruflich C# die Sprache der Wahl. Doch sowohl mit Visual C# Express als auch mit #Develop brachten mich an den Rand der Verzweiflung - wollte es mir doch einfach nicht gelingen, das .NET Compact Framework als Ziel-Framework zu bestimmen.
In der Hoffnung, dass ich mit Basic4PPC einfacher eine Mobilapplikation zum Laufen bringe, habe ich mir das Programm installiert. Der Einstieg ist wirklich einfach und schnell zu schaffen - Basic sei dank. Wie praktisch - es gibt sogar im Hardware-Objekt eine Methode “RunAppAtTime”. Die führt ein Programm zu einem bestimmten Datum aus. Perfekt für einen Wecker, mag man meinen. Der Haken: es funktioniert nicht. Zumindest nicht auf meinem HTC Touch Vodafone VPA Touch.
Also muss ich wohl doch schauen, dass ich mit C# voran komme. Zumal mir die Performance der Basic4PPC-Applikation ohnehin nicht sonderlich gut erschien. Zum Glück hat ein Kollege schon Erfahrung mit .NET Compact. Muss ich den mal anhauen.