Direkt zum Hauptbereich

Posts

MVC mit System.Messaging

In der Vergangenheit hatte ich, beim Einsatz vom MVC Pattern immer eine eigene Implementation des Observer Pattern um Nachrichten vom Model ans View zu schicken. Hierbei handelte es sich um ein einfaches Record welches nur Text verschicken konnte. Das View musste deswegen auch immer das Model, bzw. das Interface des Model kennen um Daten für Aktualisierung zu haben. Dies widerspricht meiner Meinung nach, dem Prinzip von Clean Code "Separation of Concerns" und koppelt das View ans Model. Um dem entgegen zu wirken, experimentierte ich mit den Board-Mitteln Delphi, aus dem Namespace System.Messaging . Im View hänge ich mich an den DefaultManager der Klasse TMessageManager . procedure TFormShowMessage.FormCreate(Sender: TObject); begin FSubscriptionId := TMessageManager.DefaultManager.SubscribeToMessage(TMessage , procedure(const Sender: TObject; const AMessage: TMessage) begin Memo1.Lines.Add((AMessage as TMessage ).Value); end); end; Das Model schickt ...
Letzte Posts

Delphi mit Facebook per OAuth2 verbinden

Als ich mich das erste mal mit OAuth2 zur Autorisierung beschäftigte, begann ich mit der RESTDemo.exe von Delphi zu experimentieren. Dies hat aber nicht so einfach funktioniert wie ich dachte. Also beschreibe ich hier mal mein Vorgehen wie ich mich mit Facebook Autorisieren kann. Die Vorarbeit liegt nicht unbedingt auf Seite Delphi, sondern genauso auf der Seite Facebook. Registrierung Facebook Als erstes muss man seine APP auf  https://developers.facebook.com/apps  registrieren. Als nächstes, geht man auf Einstellungen - Allgemeines und holt sich die "App-ID", in Delphi "Client-ID" und "Client-Secret", bzw. "App-Geheimcode". Beides ist später für die Url nötig. Wichtig in dem Zusammenhang, als "App Domain" "localhost" einzutragen. Um den Status der App auf Live zu stellen ist von Seite Facebook ein Links zur Datenschutzrichtlinie erforderlich. Hatte hierfür die Url meines Arbeitgebers eingetragen. Um die App Live zu s...

Nachtrag zum JSON Serialisierer ab Embarcadero Tokio 10.2

In einer meiner letzten Blogeinträge, sprach ich über meine Erfahrungen zu dem noch nicht so ganz vollständig dokumentierten JSON Serialisierer ab Tokio, hier nachzulesen unter Neuer JSOJN Serialisierer ab Tokyo Bis jetzt hat er mir wertvolle Dienste erwiesen. Er ist ein Serialisierer wie man ihn sich wünscht bzw. kennt. Durch Unittests konnte ich diverse Möglichkeiten austesten. Zum Beispiel wollte ich nicht nur ein dynamisches TArray<T> als Liste exportieren, sondern auch eine TList<T>. Bei der TList<T> wurden aber immer alle Felder ins JSON geschrieben welche ich gar nicht brauchte. Natürlich gäbe es die Möglichkeit einer Ableitung und diese mit Attributen zu versehen aber wieso was neues erfinden. Eine andere aber meiner Meinung nach unschöne, ist das konvertieren einer TList<T> ToArray, ginge auch aber... Wie man nur einen Teil der vordefinierten Typen serialisieren kann! In diesem Fall kommt man um ein bisschen Code nicht herum, aber man kann mit TJso...

Wie setzte ich Mocking Frameworks ein um meine Logik zu Testen?

Allgemein Bisher hatte ich zum Mocken meist das  Delphi-Mocks Framework  verwendet, was in den meisten Fällen ausreichte. In dem Post zeige ich, wie man das Mocking von Spring4D verwendet. Der Grund für diesen Post ist, dass es immer noch genügend Programmierer gibt welche noch nie oder viel zu selten Tests schreiben oder einsetzen. Viele reden darüber und erzählen, dass sie "natürlich" Testen. Aber ohne automatische Tests kann man die Qualität sowie einen sauberen Code nicht gewährleisten. TDD (test driven development) hat seine Schattenseiten, aber für jemand der sich nie richtig mit Clean Code, SOLID oder ähnlichem beschäftigt hat, hilft es die Prinzipien einfacher einzuhalten. In jeder Programmiersprache kann ein sauber Code geschrieben werden. Langfristig ist ein schneller, aber unsauberer Code, teurer als einmalig einen sauberen Code zu schreiben. Diese Einsicht ist meiner Erfahrung nach, leider noch nicht bei allen Programmierern angekommen. Tests dienen dazu, da...

Einsatz von Delphi Detours Library

Hooking einer "protected" Methode. Vor kurzem stand ich vor dem Problem eine function zu überschreiben welche zum einen als protected deklariert ist, zum anderen nicht virtual war. Ich konnte also, nicht einfach eine abgeleitete Klasse schreiben. Der erste Gedanke fiel auf  Delphi Detours Library von Mahdi Safsafi, zu finden unter  https://github.com/MahdiSafsafi/delphi-detours-library Das Framework ist erste Wahl bei Tests und div. Tricksereien. Im folgenden Beispiel, sieht man wie die Methode TAzureBlobService.XMsDate gehookt wird. XMsDate ist ein protected Member von TAzureService. Zum Testen wollte ich den Result mit einem eigenen String überschreiben. Nötig für die Methode ListContainer der TAzureBlobService Klasse. ... uses DDetours, ... TMyBlobService = class(TAzureBlobService) public function InterceptXMsDate: string; function ListContainers(): TArray ; overload; end; ... { TMyBlobService } function TMyBlobService.InterceptXMsD...

Neuer JSON Serialisierer ab Embarcadero Tokio 10.2

Seit Embarcadero Tokyo 10.2 veröffentlicht hat, steht uns Entwicklern ein neuer sehr gut zu gebrauchender JSON Marshaller zur Verfügung. Leider ist die Dokumentation dürftig. Das schöne ist aber, das Embarcadero sich ziemlich an gängige Verfahren hält. So konnte ich z.B. sehr einfach herausfinden was TJsonCustomCreationConverter<T> macht, nachdem ich C# Beispiele analysierte. Da es leider keine offizielle Dokumentation zum TJsonSerializer gibt, beruhen meine Beispiele auf Versuch und Irrtum. Es gibt 3 Namespaces, welche relevant sind. Zum einen "System.JSON.Serializers", für den eigentlichen Serialisierer und die Klassenattribute, zum anderen "System.JSON.Converters", für eigene Konverter und zuletzt "System.JSON.Types", für z.B. Datumsformate oder Formatierungen. TJsonSerializer Ist die wichtigste Klasse, sie ist implementiert im Namespace System.JSON.Serializers. Diese Klasse ist dafür zuständig, ein Objekt in JSON (Serialisierung) zu formati...

Printer tests best practice...

Software ist heute einfacher zu entwickeln, nichts desto trotz steigt die Komplexität der heutzutage entwickelten Software. Dadurch steigt auch die Anzahl möglicher Fehler. Es ist jedoch nahezu unmöglich sämtliche Ausnahmefälle abzudecken. Deshalb ist kontinuierliches Testen der Software meiner Meinung nach, ein wichtiger und notwendiger Bestandteil jeder der Softwareentwicklung. Allzu oft wird heute noch, dies missachtet. Viel wird vermeintlich schnell behoben, was sich später bitterlich rächt. Einer dieser schnell schnell Punkt, ist das anpassen von Reports. In der Realität erlebe ich oft, das zu Reports meist gar keine automatischen Test existieren. Meist mit der Begründung, das geht nicht oder es existieren ja sowieso keine automatischen Tests. Vielleicht kommt noch, das testet dann der Kunde. Sucht man nach passenden antworten wie man Ergebnisse von Reports testen kann, kommt "Verwende Unittests". Das ist richtig, man sollte die gesamten vorlagerten Klassen mit...