Simon

Mai 202011
 

Was ist das und wofür könnte es verwendet werden?

Vielleicht… ein WLAN-Stecker?
2011520221035.jpg

Posted from WordPress for Windows Phone

 Posted by at 21:12
Apr 302011
 

Welche mächtige Höllenmaschine soll hiermit bedient werden? Ein nuklearer Taschenrechner? Ein rotes Telefon?
Ziffernblock als Fahrstuhlsteuerung

Nein, es ist nur ein Fahrstuhl mit Universal-Schnittstelle. Soll wohl den Aufwand sparen, ein spezielles, anwendungsbezogenes, angemessenes, benutzerfreundliches Bedienelement anzufertigen.
Zur Strafe muss dafür noch eine zusätzliche Anleitung daneben.
Anleitung zur Fahrstuhlsteuerung

Und der Benutzer? Hasst beides, 3 Tastendrücke für 1x in den Keller fahren und vorher noch die Anleitung lesen.

Apr 212011
 

Wie kürzlich erst gesagt gibt’s etliche Möglichkeiten, das INPC zu handhaben. Ich habe jetzt einen neuen Favoriten:
T4 Code Snippets

Vorteile: Der Code muss nicht manuell geschrieben werden, kann auch zentral refactored werden, ist aber schon zur Compilezeit vorhanden und auch sichtbar. UND: die Properties inkl. Boilerplate-Code landen in einem eigenen CodeFile und verwässern nicht den Teil, wo die komplexeren Sachen passieren.
Ach ja, und noch einer: Die Snippets liegen im Projekt, damit auch im CVS und sind immer für das ganze Team sichtbar und verfügbar, auch bei abweichender IDE-Config.

Nachteil: Evtl. minimal längere Compilezeit, spezielle Templates, z.,b. um die Zusatzfeatures des NotifyPropertyWeaver nachzubilden muss man erst noch erstellen.

Außerdem sehr schick: die verkürzte Grid!Syntax für Row-/ColumnDefinition.

Und für die T4-Snippets gibt es sicher noch weitere gute Anwendungen. Z.B. Standardvalidierung mit IDataErrorInfo, Pflichtfelder, Min/Max-Grenzen etc.

Apr 152011
 

WPF-DataBinding rocks! Schön ist auch, dass es sowohl mit den (relativ neuen) DependencyProperties als auch mit den guten alten CLR-Properties (POCOs = Plain old CLR-Objects) gut harmoniert, wenn man denn INotifyPropertyChanged aus dem ComponentModel implementiert.
Das ist auch nicht schwierig, sorgt aber immer wieder für Diskussionen, wenn es darum geht, wie man am besten MagicStrings (PropertyNamen) vermeidet, blöde Copy/Paste-Fehler verhindert (z.B. BackupFieldName statt PropertyName in den EventArgs), ob man Reflection einsetzt (Expressions statt MagicString, Performance-Hit?) usw.
Eine Muster-Implementierung, aber was noch viel wertvoller ist, eine Diskussion verschiedener Ansätze findet sich im OpenSource-Project CompositeExtensions.

Vermutlich jedes GUI-Framework  bietet mindestens einen Lösungsansatz dafür.
Heute habe ich noch einen weiteren gefunden: den NotifyPropertyWeaver.

Das Konzept ist nicht so überraschend:
Die Properties werfen keinerlei Events mehr im explizit geschriebenen (Boilerplate-)Code. Stattdessen tragen sie eine recht kompakte Konfiguration an Klassen und Properties, z.B. AOP-like über Attributes.
Diese muss man natürlich später von irgendwem noch in Code umgewandelt werden, und genau dafür gibt es dann auch wieder zahlreiche Ansätze:

  • Ein DynamicProxy könnte Property-Aufrufe abfangen und z.B. zusätzliche Aufrufe hinzufügen, Events auslösen etc. (Sehr stylischer Artikel dazu)
  • Basisklassen können die Konfiguration umsetzen. Das hat natürlich den großen Nachteil, dass man von dieser Klasse ableiten muss und keine andere Basisklasse verwenden kann.
  • Der PropertyWeaver setzt auf einen Post-Compile-Task: Nachdem der eigentliche Code (Properties werfen keine Events) kompiliert ist, bearbeitet der PropertyWeaver die generierte (IL-)Assembly nach und ergänzt sie um die Event-Aufrufe etc. Dabei sind auch komplexere Situationen möglich, wie z.B. abhängie Properties, für die auch dann ein Event geworfen werden muss, wenn sich der Wert einer bestimmten anderen Property ändert.

    Vorteil: Der generierte Code sieht quasi genau so aus wie handgeschriebener Boilerplate-Code, und ist damit auch zur Laufzeit gleichwertig. Hilfsmittel wie Reflection werden zur Laufzeit nicht benötigt, die statisch vorhandere Information wird in statischen Code umgewandelt, feine Sache. Die Nachteile des tatsächlich manuell fabrizierten Codes, nämlich die ständigen Fehlerquellen Typo und Copy/Paste sind quasi eliminiert, da der Code ja maschinell erzeugt wird. Ok, ein Restrisiko bleibt durch fehlerhafte Konfiguration, aber ein Bisschen muss man halt schon sagen was man will, wenn man’s auch kriegen möchte (Garbage In, Garbage Out).

    Leider gibt’s bei aller Eleganz dieser Lösung auch Nachteile – There ain’t no free lunch:
    Der Code wird erst Post-Compile ergänzt, er landet also nicht im Code-File in der IDE sondern nur in der erzeugten dll. Somit ist er dann auch nicht zugänglich für z.B. statische Code-Analyse (Resharper, StyleCop, etc.), und beim „Lesen“ des Codes muss man immer beachten, dass evtl. noch mehr passiert als dort steht.
    Glücklicherweise werden die zugehörigen pdb-Files ebenfalls ergänzt, Debugging funktioniert also trotzdem. Und Unit-Tests durchlaufen natürlich auch den endgültigen Code, der Post-Compile-ergänzte Teil wird also mitgetestet.

    Feb 282011
     

    Kommst du auch oft durcheinander und verwechselst gelegentlich Code, Name, Id und Referenznummer?

    Bei DHL kann das nicht passieren: Die lassen ihre Kunden nicht im dunkeln tappen sondern sagen ganz klar an, welche Angabe sie benötigen und wo du sie finden kannst:

    2011-02-28 21h38_342011-02-28 21h38_34

    Feb 232011
     

    Heute schon die int.MaxValue-Grenze übertreten? Für fast jeden kommt der Moment irgendwann, an dem int = Int32 nicht mehr ausreicht und auch ein Unsigned Int 64 knapp werden könnte. Klassische Beispiele: ewig hochgezählte Unique-IDs oder Comparer, die Strings numerisch sortieren sollen. Normalerweise kein Problem, aber es ist schwer zu garantieren, dass die Grenzen tatsächlich eingehalten werden, und wie schon der (viel zu optimistische) Murphy sagte… *kawumm*

    Still und heimlich (weil ungehyped) hat MS einen ganzen Namespace ins .NET-Framework geschmuggelt, der hier Abhilfe schafft.

    System.Numerics enthält zwei Strukturen für spezielle Berechnungen, nämlich BigInteger und Complex. BigInteger ist nicht noch ein neuer Datentyp mit noch größeren Grenzen sondern kann tatsächlich unbegrenzt große Ganzzahlen darstellen. Außerdem bietet er natürlich die wichtigsten Rechenoperationen sowie Parse- und Convert-Methoden.

    Damit ist er natürlich die ultimative Waffe für das Lösen vieler Rechenprobleme à la Project Euler, die einen bisher oft dazu gezwungen haben, mit Strings zu rechnen oder Überläufe manuell zu behandeln.

    Complex hab ich bisher noch nicht ausprobiert, genau genommen sind mir die komplexen Zahlen nach dem Studium in der Praxis nie mehr untergekommen. Vermutlich ließe sich das auch nicht mit dem K.I.S.S.-Prinzip unter einen Hut bringen ;).

    P.S.: Das soll aber jetzt kein Aufruf sein, BigIntegers als IDs zu verwenden. Für diese Zwecke gibt es bereits die wesentlich besser geeigneten GUIDs bzw. UUIDs.

    Feb 082011
     

    Tatsächlich, es klappt 🙂

    Um meinen Blog endlich vom NAS auf einen richtigen Webserver zu kriegen, musste ich jetzt den Migrationsernstfall proben. XCloner behauptet ja, er sei dafür gerüstet, also mal schau’n ob er das auch hält.

    Die automatischen Lösungen haben leider nicht so recht funktioniert, der XCloner scheint ursprünglich für Joomla gemacht zu sein, die WordPress-Migration eher ein zufälliges Abfallprodukt, zumindest lassen das einige unpassende Texte vermuten. Also musste ich doch noch die Anleitung lesen…
    Also dann, das Backup auf dem alten Server (aus dem WordPress-Backend) erstellt, zusammen mit den zwei Restore-Dateien per ftp auf den neuen Server übertragen und von dort das manuelle Restore angestoßen.

    Nur meine Atahualpa-Theme-Konfiguration musste ich nochmal separat migrieren, die war nur halb mitgekommen. Sonst alles wunderbar.

    Alle restlichen Detail-Problemchen stammten nur daher, dass ich zu knausrig für ein Business-Paket war und deshalb auf Goodies wie mod_rewrite verzichten muss, aus diesem Grund gibt es also auch leider wieder kryptische Links.

    Update: 11.02.11: Übung macht den Meister, beim nächsten Umzug vom Test-Account zum endgültigen Account hat sogar die automatische Übertragung des Backups funktioniert, aber ich rate immer noch bei einigen Pfadangaben knapp daneben und brauche 2-3 Versuche bis endlich alles dort ankommt wo es hingehört. Idiotensicherheit kann ich dem XCloner also nicht attestieren, aber immerhin, er funktioniert grundsätzlich.

     Posted by at 12:02
    Dez 082010
     

    …vielleicht eher für’s nächste Jahr interessant, obwohl der Advent ja noch ein paar Türchen bereithält:

    Ich habe eine kleine Adventskalender-Anwendung gebaut, die ich mit Fotos von meinem Kleinen an dessen Großeltern verteilt habe.

    Was man davon abgreifen kann?

    • Beispielanwendung mit MVVM (MVVM-Lite Toolkit) – Aber Achtung, an 2-3 Stellen hab ich durchaus mal die Quick’n’Dirty-Lösung bevorzugt, sollte ja schnell gehen.
    • Simple Anwendung von WPF
    • Beispiel für einen netten Installer (auch wenn er ein paar zu viele Fragen stellt)
    • Ach ja, und natürlich einen schmucken Adventskalender

    Systemvoraussetzungen:

    • .NET 4.0
    • Zum Kompilieren natürlich auch  VS2010

    Die Fotos habe ich durch Platzhalter ersetzt, aber man kann sehr einfach eigene Bilder einsetzen:
    Einfach die png-Dateien durch richtige Bilder ersetzen, bei Bedarf auch die Sounds ändern, im Release-Mode kompilieren und fertig ist der eigene Adventskalender mit Setup.

    SourceCode zum eigenen Atzventzkalender

    Aug 312010
     

    Bei meinen ersten Gehversuchen mit dem Entity Framework bin ich natürlich gleich über die erste Hürde gestolpert:
    Da ich weder mit Kanonen auf Spatzen schießen wollte, noch externe Libs=Fehlerquellen einbinden wollte, startete ich mit dem MS SQL Server in der Compact Edition. Soweit so gut, dank EF gelang die DB-Erstellung recht mühelos direkt aus VS2010 und die große Datenmodellierungsorgie konnte beginnen…
    Aus alter Gewohnheit bekam jede Tabelle eine int-Spalte ID, die via Auto-Inkrement implizit für jeden neuen Datensatz befüllt werden sollte. Zur Laufzeit, beim Versuch generierte Daten zu persistieren, dann der erste Dämpfer, dankenswerterweise mit wirklich aussagekräftiger Exception:

    „No support for server-generated keys and server-generated values“

    Was solll das? Ganz einfach: die Compact Edition streikt einfach schon bei einer so einfachen Funktion wie dem Hochzählen der ID. „Unverschämtheit“ war mein erster Gedanke, ist die Tradition brauchbarer Gratis-DBs à la MSDE etwa Vergangenheit? Wie soll ich mit einer DB arbeiten, die so rudimentär ist, dass sie nichtmal die einfachsten Funktionen beherrscht? Kurz hab ich sogar überlegt, selbst die nächste unbenutzte Int-ID zu berechnen, hatte aber eigentlich keine Lust darauf, wollte ich doch das EF nutzen, um mir eben keinen DataAccess-Layer händisch coden zu müssen. Zum Glück konnte ich diese Überlegung schnell als überflüssig beiseitelegen, denn es handelt sich wohl eher um eine strategische Entscheidung seitens MS, die Implementierung hat ja nun echt nichts mit „Rocket Surgery“ zu tun.
    Vielmehr will MS uns wohl dahin treiben, aus der Not eine Tugend zu machen, und zwar mit…
    …Tä-tätä-tää: UUIDs bzw. GUIDs.
    Beim Anlegen neuer Objekte reicht folgende Zeile, um eine absolut einzigartige ID zu erzeugen, ohne Buch zu führen, ob sie schon verwendet wurde:
    Id = Guid.NewGuid()
    Ok, sie liest sich nicht ganz so nett wie eine laufende Nummer, und danach zu sortieren ist auch recht sinnfrei, aber wir wollten ja auch eine eindeutige ID und keinen Zeitstempel und erst recht keinen DisplayName, der an die Oberfläche gelangen soll. Durch Kryptifizierung dieser ID dürften diese Verführungen damit der Vergangenheit angehören – wer einen Zeitstempel braucht, kann dafür ja eine eigene Spalte, entkoppelt von der ID-Funktionalität, spendieren und umgeht somit weitere Probleme.
    Das war übrigens auch mal Thema im permanent provozierten Streitgespräch zwischen Golo Roden und Peter Bucher.

    n/a