ORM oder doch lieber eine Schichttrennung?

Schichttrennung?

Mit der ersten Windows-Delphi Version fingen alle an "RAD" zu programmieren...

Formular -> Möglichst viele Komponenten visuell oder auch nicht aufs Form klicken und dann immer an den "richtigen" Stellen einen Doppelklick und den Code rein... GGf. noch im OI Verbindungen von Komponente A nach Komponente B herstellen.

<F9> - No errors - ship it...

Plötzlich kommen "die Leute" mit so neumodischem Zeug wie Unittest's oder MVVM...

Also alles wieder aufdröseln und doch trennen...

Nachdem man das alles umgesetzt hat steuern "die Anderen" wieder dagegen und "erfinden" Visual-Live-Bindings also nix im Code, sondern wieder im Formular... OK - muss man ja nicht machen...

Eigentlich ist man mit sich und seinem Source-Code im Reinen.

Da ist die View, eine andere Unit ist das ViewModel, eine dritte Unit hält das DatenModel und die Datenzugriffskomponente, aber ggf. ist das auch eine weitere Unit... Vielleicht hat man für den Datenzugriff auch ein Interface genommen um überhaupt nicht gegen eine physikalische Datenbank zu linken. Good Job! Im Kreis stellen und auf die Schulter klopfen.

 

Jetzt kommt die erste Änderung.

 

Die Änderung passiert als ersten auf der Datenbankebene. Warum? Eine andere Software braucht noch ein Feld... OK... Meine Software muss das ja nicht unterstützen, oder doch? Naja, zu mindestens sollten meine Zugriffe das Feld nicht ändern oder löschen und ggf. bei einem neuen Datensatz initialisieren. Fein - meiner REST-Schnittstelle ist das egal... Darum soll sich der Server kümmern. Aber im Netz muss ich schnell meine Tabellen-Definition anpassen. Fertig... Der Rest meiner Software ist unberührt. Zum Glück muss ich nicht in 30 Formularen etwas anklicken, den die Formulare sind doof und wissen sowie so nix da von. (Gut das man beim erstellen der App's für iOS, Android und Windows daran gedacht hat, und sowie so alles per CRUD/REST/JSON implementiert hat).

 

Anpassung: Eine Unit-Datenbankdefinition und in der INSERT INTO noch das Feld initialisieren. (Wenn überhaupt nötig)

 

Bleiben wir mal bei der Datenbank definition (Um zurück zum Titel zu kommen).

 

Sollte die Datenschicht - also die Unit die einen Datensatz im Speicher hält auch verantwortlich sein für den Zugriff auf die Datenbank?

 

Momentan mache ich es so...:

 

Unit "Person.Model.pas" hat den Person-Record (also eigentlich eine Factory die ein Interface auf eine Class zurück gibt, die die Daten hält.)

Dann gibt es die Datenbank.Define.pas hier stehen die Definitionen aller Datenbanken/Tabellen, die ich in der App verwenden. Will ich die Datenbank ändern gibt es eine Unit und für die eigentlichen Daten, jeweils eine...

 

Jetzt kommen die Leute auf die Bühne die Attribute lieben und sagen: Warum soll ich das trennen, ich kann doch per Attribut in meinem DatenModel direkt angeben wie die Daten gespeichert werden sollen.. Also eigentlich genau wie bei REST/JSON hier kann ich ja z.B. wie in SuperObjects oder bei DUnitX direkt "alles" angeben...

 

Klar, hier gibt es schon fertige Packages die sowas können... Also das RAD neu erfinden?

 

Ich habe zu ORM noch eine geteilte Meinung. Deswegen habe ich auf dem letzten Delphi-Meetup die gleiche Frage gestellt... Und 10 verschiede Meinungen gehört... (Ich möchte sagen alle genannten Argument hatten ihre Berechtigung)

 

Vielleicht bilde ich mir eine Meinung, wenn ich "sowas" selber mal implementiere... Schließlich habe ich ja auch meine eigene JSON, REST Komponente, meinen eigenen XML Reader/Writer meine eigene Tethering Komponente geschrieben.

 

Also - kommt auf die Liste:

 

#Todo, #FDK, #ORM

 

Ich baue mal meinen Fluidcreator für Datenbankdefinitionen um... Mal sehen wie sich das im Source anfühlt...

FMX & Styles

FMX und Styles

OK, ein Stylebook auf ein Formular zu klicken ist ja nun kein Problem und dann?

Es gibt Leute, die haben sich extra ein Android-Handy gekauft, weil Ihnen das iOS zu "bund" oder was auch immer war... (oder auch anders herum).

Jetzt nimmt man einen Style - und alles sieht anders aus. Verärgert man damit seine Nutzer?

Für einen CI-Style sprechen sicherlich genau so viele Argumente, wie für einen nativen Plattform-Style.

Aber ist es den so einfach einen Style für alle Plattformen zu verwenden? Eigentlich schon...

Wäre da nicht das Problem, dass die mitgelieferten Styles - Handmade - sind. Daher sind die Grafiken leider nicht deckungsgleich. Bedeutet?

Alle Angaben der Regionen aus dehnen die einzelnen Style-Elemente herausgenommen werden sind unterschiedlich. Also muss man die für alle Plattformen anpassen?

Ich muss zugeben ich habe noch nicht alle Einzelheiten aller Plattformen verglichen - weil es hier pro Plattform noch Besonderheiten gibt... Als der Teil ist noch WIP.

Aber mein Ansatz war folgender:

Ich erzeuge über den Bitmap Style-Designer alle Default-Styles und speichere mir die Bezeichnungen:

AndroidL Light
[ANDROID][ANDROIDL][LIGHTSTYLE][DEFINEFONTSTYLES]
iOS7Alternate
[IOS][IOSALTERNATE][IOS7][DEFINEFONTSTYLES]
Windows 10 Modern
[MSWINDOWS][MODERN][DEFINEFONTS][DEFINEFONTSTYLES]

Dann nehme ich den Windows 10 Modern Default Style als Basis. Alle Plattformen nähern sich sowieso diesem Style... ;-)

Dann noch Icon suchen/erzeugen/von freien Quellen laden... Leider gibt es keine Size/Position-Hilfe im Styledesigner. Außerdem wollte ich auf keinen Fall die Icons in 4 Auflösungen per Hand zusammenklöppeln... Hierfür also schnell ein kleines Programm geschrieben, dass die Icons in immer gleichbleibender Reihenfolge laden und in die PNG's speichern kann. Und die Auflösung 1.0 noch mit einem Grid versehen. So fällt das "rechteckziehen" leichter.

Dann noch das SpeedButton-Style-Object im Style oft genug kopieren und alles zuweisen...

Und schon hat man seinen Style - der auf allen Plattformen funktioniert.

Die richtigen Größen der Elemente erzeugt mein FDK, hierum brauchte ich mich also nicht kümmern. Fertig sieht es dann so aus...

Es gibt im FDK noch eine Funktion die aus jeder Grafik, einen klickbaren Button mit Schatten und Pushdown-Animation machen kann. Somit hat man die Option entweder den Button nativ zu verwenden (Toolbar, oben) oder als Klickdown-Button (Leiste unten) besonders klasse finde ich den Effekt bei transparenten PNG's.

 

Die fertige App sieht das auf allen Plattformen so aus: Ok, die Schatten sind ein Style-Bruch und werden in der Store-Version wahrscheinlich noch rausfliegen.

 

 

So einfach kann es gehen - und ich habe hierfür nur eine Woche gebraucht. ;-)

 

Warum eine Woche? Bis alles so gepasst hat wie ich es mir vorstelle und das ganze zusammenklicken mit der Maus im Bitmap-Style-Designer war halt einfach viel Arbeit. Nochmal mache ich das so nicht. Nächster Schritt ist ein Style-Creator der diese unnötigen arbeiten automatisch macht... (Ich habe mich ja auf Button beschränkt) Hätte ich die anderen Elemente auch noch erzeugen/ändern müssen wäre es wahrscheinlich ein Monat geworden. Das FMX-Style-Format ist ja so ähnlich wie DFM/FMX/TXT aber ich hatte einfach noch keine Zeit hierfür eine Routine zu schreiben... Ich hoffe noch an den Source für den Bitmap-Style-Designer zu kommen und einfach diese Software zu erweitern... Anfrage läuft. 

 

Wie gesagt WIP...

 



In das MVP Programm aufgenommen...

In das MVP Programm aufgenommen...

Meine Bemühungen Delphi und Firemonkey weiter zu bringen sind wohl nicht unbemerkt geblieben,

daher freue ich mich, dass ich heute als

 

aufgenommen wurde.

 

 

The MVP-Directory is updated (05.04.17)



 

Vortrag zu FMX in Holland

Ich freue mich auf den Event in Holland zu dem mich Bob Swart eingeladen hat.

Hier bietet sich nicht nur die Gelegenheit wieder mal einen FMX Vortrag zu halten, sondern auch mein FDK vorzustellen.

Es ist schön zu sehen, dass meine Aktivitäten über die Grenzen hinaus Anklang finden...

Для моих русских читателей.

Привет мои русские друзья!

Моя статистика говорит, что многие из русскоязычных стран посещают мой блог меня. Может быть, я хочу контакт, который говорит на немецком или английском и помочь мне с переводом моих текстов.

спасибо

Google-Translated...

Erste Schritte in den Internationalen Markt!

Erste Schritte in den internationalen Markt!

OK, klar man programmiert seit 35 Jahren - nur für den deutschen Markt... Also hat man sich auch nie darüber Gedanken machen müssen was es den da sonst noch so gibt...

1. Entscheidung

Mal alles auf Englisch machen. OK Schulenglisch ist vorhanden sollte erst mal mit den Kenntnissen aus der Programmierung ausreichen. Vielleicht nicht, aber man wird sehen...

Documentation und online Hilfe erledigt.

2. Entscheidung

Fehlermeldungen sollten für den User anpassbar sein. Auch kein Thema. Alle Texte einmal in diverse Sprachen übersetzen, die Routine die die Fehlertexte aufbereitet angepasst. Kleines Tool für das erzeugen der Übersetzungen und packen als Resource. Kein Problem. Jeder kann noch eine Textdatei in den Programm Pfad legen "de-de.txt" oder so... Und schon geht auch das. Das gilt auch für Sprachen die man nicht kann. Google Translate liefert vielleicht kein optimales Ergebnis aber man wird es verstehen... Nativ-Speaker können das ja noch anpassen und die bessere Übersetzung hier einreichen... (Klar, mit dem richtigen Budget könnte man das professioneller machen).

3. Entscheidung

Die Software soll sich an das Länder-ID des Windows-Systems anpassen. Auch kein Thema... Normalerweise wäre das richtig... Oder?

 

Leider kann man das nicht pauschal sagen... Besonders nicht, wenn die Software mit einem deutschen Server kommuniziert. Der könnte es zwar auch anders, aber liefert erstmal ein Datum in "seinem" Format... "dd.nn.yyyy hh:mm:ss".

Wenn die "schlaue" Software aber ein TDateTime.TryParse ohne eine Länderkennung macht... Nimmt diese Funktion das Format gemäß Ländereinstellung... Und das ist bei einem us-Windows leider anders...

Klar könnte der Server das Datum "direkt" richtig liefern, wenn er die Länderkennung des Zielsystems auswerten würde... Aber das hat "Man(n)" ja noch nie gebraucht...

FDK - RELEASE - DAY

FDK - RELEASE - DAY

Die Auslieferung des FDK hat begonnen.

Es hat ein bisschen länger gedauert als erwartet, aber das soll die Freude nicht schmälern.

Die gute Nachricht lautet : Bis zum 30.04.2017 gilt noch der Early-Bird-Preis von 299,- €

Momentan gibt es "nur" die Voll-Version in der Source-Code Distribution. Für andere Versionen hat sich bisher keiner Interessiert, daher erstmal nur diese.

Eine Demo-Version ist auch Planung, aber das kann noch ein bisschen dauern, daher habe ich den Early-Bird Zeitraum nochmal verlängert.

Mein eigener Installer löst direkt mehrere Aufgaben.

• Die Installation / De-Installation
• Pflege- und Änderbarkeit der Kundendaten (Adresse, Telefon usw.)
• Online-Shop - Inkl. Rechnungslegung
• Neukunden-Registrierung

Das Setup Programm steht ab SOFORT zum download bereit unter: http://www.delphiprofi.de/FDK/FDKSetup.zip

 

Alle die bereits eine FDK-Early-Bird-Version bestellt haben, sollten bereits im E-MAIL-Postfach eine entsprechende Nachricht mit den Zugangsdaten finden.

 

Das gilt auch für die Entwickler, die auf den Delphitagen 2016 eine Version gewonnen haben. Leider fehlt mir von einem noch die EMAIL, also bitte melden! 

Das FDK ist für Delphi 10.1 (2) entwickelt - läuft aber auch mit XE 10 Seattle und mit kleinen Einschränkungen auch auf  XE 8. XE 7 & 6 habe ich nicht mehr getestet.
Das Setup läuft auf Windows Vista, 7, 8 und 10.

 

 

Also viel Spass

 

und Happy Coding...

 

PS: Momentan ist die Bezahlung immer per Vorkasse andere Bezahlsysteme wie amazon-Pay oder Paypal sind in Vorbereitung.

 

Eine Kurzanleitung (PDF) für den Einstieg ist in deutscher Sprache enthalten. Alle Code-Insight Dokumentationen sind in englischer Sprache - das gilt auch für den Installer.

 

Auch wenn dieses Developer Kit für FMX entwickelt wurde, sind 90% der Units auch für das VCL-Framework zu gebrauchen.

 

Die Auslieferung der Version 1.0 umfasst neben den Demos, Sourcecode Formatter, LiveTemplates, Resourcebasierte Exception-Texte in English, Deutsch (Spanisch, Russisch, Französisch und Niederländisch nur per Google-Übersetzer), folgende Units im Source:

 

Delphi.VersionConsts.pas
Delphiprofi.FDK.AnyConverter.pas
Delphiprofi.FDK.AnyFactory.pas
Delphiprofi.FDK.AppConfig.pas
Delphiprofi.FDK.AppGlobal.pas
Delphiprofi.FDK.BackgroundWorker.pas
Delphiprofi.FDK.CallByIDFactory.pas
Delphiprofi.FDK.Classes.pas
Delphiprofi.FDK.Compressing.pas
Delphiprofi.FDK.Compressing.ZLib.pas
Delphiprofi.FDK.Config.pas
Delphiprofi.FDK.Console.pas
Delphiprofi.FDK.Converters.pas
Delphiprofi.FDK.DataView.pas
Delphiprofi.FDK.Enumerables.pas
Delphiprofi.FDK.Events.pas
Delphiprofi.FDK.Exceptions.Handler.pas
Delphiprofi.FDK.Exceptions.pas
Delphiprofi.FDK.FireDAC.pas
Delphiprofi.FDK.FluidCreator.pas
Delphiprofi.FDK.Fmx.Enumerables.pas
Delphiprofi.FDK.FMXHelpers.pas
Delphiprofi.FDK.Generics.BlockingCollections.pas
Delphiprofi.FDK.Generics.Collections.pas
Delphiprofi.FDK.HeartbeatWorker.pas
Delphiprofi.FDK.Helpers.pas
Delphiprofi.FDK.IdleWorker.pas
Delphiprofi.FDK.IFDEF.pas
Delphiprofi.FDK.IO.pas
Delphiprofi.FDK.Logging.ConsoleLogger.pas
Delphiprofi.FDK.Logging.DebugLogger.pas
Delphiprofi.FDK.Logging.FileLogger.pas
Delphiprofi.FDK.Logging.LogFilter.pas
Delphiprofi.FDK.Logging.pas
Delphiprofi.FDK.MainApplication.pas
Delphiprofi.FDK.Messages.pas
Delphiprofi.FDK.Observer.pas
Delphiprofi.FDK.Pattern.Internals.pas
Delphiprofi.FDK.Pattern.pas
Delphiprofi.FDK.Platform.Utils.pas
Delphiprofi.FDK.Queues.pas
Delphiprofi.FDK.Resource.compressed.pas
Delphiprofi.FDK.Resources.pas
Delphiprofi.FDK.Specifications.Core.pas
Delphiprofi.FDK.Specifications.Dates.pas
Delphiprofi.FDK.Specifications.pas
Delphiprofi.FDK.Specifications.Strings.pas
Delphiprofi.FDK.Stateless.pas
Delphiprofi.FDK.Streams.Hashing.pas
Delphiprofi.FDK.Streams.Internals.pas
Delphiprofi.FDK.Streams.pas
Delphiprofi.FDK.StringConsts.pas
Delphiprofi.FDK.Threading.AsyncTasks.pas
Delphiprofi.FDK.Threading.pas
Delphiprofi.FDK.Threading.Pipeline.pas
Delphiprofi.FDK.Threading.Timers.pas
Delphiprofi.FDK.TimeoutWorker.pas
Delphiprofi.FDK.TreeViewWalker.pas
Delphiprofi.FDK.Types.pas
Delphiprofi.FDK.Utils.pas
Delphiprofi.FDK.Vcl.Enumerables.pas
Delphiprofi.FDK.Winapi.Windows.pas

Es folgen noch weitere Dateien...

 

 

 

FMX und der Ärger mit den Styles...

FMX und der Ärger mit den Styles...

Hat eigentlich irgend jemand schon mal einen eigenen "premium"-Style für Windows, Android und iOS selber erzeugt?

Ich meine nicht die Farbe der Grafik geändert, sondern "so richtig"...

EMBT soll selber mit dem Bitmap-Style-Designer arbeiten? LOL... Kaum zu glauben. Das Tool ist völlig unproduktiv... (Soll nicht heißen, dass es nicht funktioniert).

Wie sind die mitgelieferten Styles erzeugt worden? Einfach mal so die Grafiken auf ein PNG positionieren und dann ALLE einzeln mit der Maus verknüpfen?

Selbstverständlich werden alle Style-Elemente total unterschiedlich für iOS, Android und Windows positioniert... Warum auch ein Schema nehmen... omg... Sorry, aber ich habe in meiner Firma keine eigene Style-Abteilung die nur den ganzen Tag mit Photoshop zaubern.

Lassen wir mal die Discussion, ob sich das Aussehen einer App auf jedem Betriebssystem unterscheiden soll, weg. Nach dem Motto: "Ich hab mir extra ein Android-Handy gekauft, weil die iOS-Apps mir zu bunt sind". Deswegen sieht die FB-App auf iOS auch genauso aus wie auf Android... (Abgesehen von der Position der Tabs)

Sonst würden die "premium"-Styles ja auch keinen Sinn machen, oder?

Also: Meine-App... Mein-Style...

Also legen wir mal los... Welche Vorlage? Interessanterweise sind die Einstellung der einzelnen Verknüpfungen auf Plattformspezifisch, aber was sind die richtigen Werte?

Also hilft nur Try und Error... (2 Tage)

OK...

1. Style ist fertig... Unnötig zu sagen, dass dieser Style auf Windows und iOS prima funktioniert, aber auf Android Anzeigefehler produziert...

Ich werde weiter berichten...

Natürlich habe ich für das ein oder andere extra ein Tool programmiert... ;-)

Ein frohes 2017!

Und schon wieder ist ein Jahr rum. Klingt komisch, is aber so...

Als ich heute eine kleine Änderung im FDK gemacht habe, habe ich "selbstverständlich" auch im Changelog die Änderung notiert und musste feststellen, der 1. Eintrag war schon im Jahr 2015...

2015 habe ich damit schon begonnen? Kaum zu glauben... Wie viel Entwicklungszeit schon in den Units steckt.

Natürlich habe ich nicht 15 Monate kontinuierlich daran gearbeitet, sondern immer dann, wenn ich eine neue Routine gebraucht habe diese - in einer allgemeinen Version - ins FDK aufgenommen. Sehr viel Zeit ist aber auch in Änderungen und Verbesserungen geflossen.

Ein kleines Fazit - nur für mich:

Das FDK zu entwickeln war die beste Entscheidung die ich seit langem getroffen habe. Jede Stunde die in die Entwicklung geflossen ist, habe ich schon mehr als doppelt bei meinen eigenen Projekten gespart...

Mein Ziel war es.

1. Wiederverwendbaren Code zu produzieren.
2. Mit Dependency Injektion und Factorys, meine Units unabhängige von einander zu erzeugen.
3. Wrapper zu verwenden, die einem die Verwendung von XY erleichtern.
4. Projekte im MVVM - Style zu programmieren.
5. Plattform unabhängig zu programmieren.
6. Threadsave zu programmieren.
7. Zeit zu sparen.

Alle diese Punkte werden erfüllt.

Ein Beispiel aus einem aktuellen Projekt (Die Unit ist nicht mal 500 Lines lang)

Uses
  System.Classes,
  System.SysUtils,
  System.Rtti,
  System.Generics.Defaults,
  System.Generics.Collections,
  REST.JSON,
  Delphiprofi.FDK.AnyFactory,
  Delphiprofi.FDK.FMXHelpers,
  Delphiprofi.FDK.Streams,
  Delphiprofi.FDK.Enumerables,
  Delphiprofi.FDK.Compressing.Zlib,
  Delphiprofi.FDK.REST,
  Delphiprofi.FDK.JSON,
  Delphiprofi.FDK.Utils,
  Delphiprofi.FDK.Helpers,
  Delphiprofi.FDK.Types,
  Delphiprofi.FDK.FluidCreator,
  Delphiprofi.FDK.FireDac,
  Delphiprofi.FDK.LocalWebModul,
  Delphiprofi.FDK.Messages,
  Delphiprofi.FDK.TreeviewHandler
  MyInterfaces;

Macht aber den kompletten IO zwischen lokaler Datenbank, dem REST Server und der Applikation. Hierfür habe ich KEINE EINZIGE Komponente auf ein Form geklickt.

Abgesehen von wenigen Ausnahmen, habe ich im gesamten Projekt kein einziges Konstrukt wie:

Foo := TFoo.Create;
try
  try
    // Whatever
  except
    On E : Exception
      begin
         // Whatever
      end;
  end;
finally
  FreeAndNIL(Foo);
end;

Da es zur Zeit noch kein ARC für Windows gibt, nutze ich konsequent Interfaces und Ref-Counted Objecte... Somit läuft der Code immer gleicht, egal ob mobile oder Windows/OSX Version.

Es bleibt spannend...

FDK - Setup nearly ready...

Hi!

Nun ist es soweit. Das dynamische Installationsprogramm fürs FDK ist in wenigen Tagen online.

Wie immer war "normal" zu "normal". Daher habe ich mich entschlossen, das Setup komplett neu in Firemonkey - natürlich mit dem FDK - selber zu programmieren.

Ggf. wird das Setup per Setup installiert... Oliver hatte da so eine Idee...

Warum dann ein eigenes Setup?

Ganz einfach, ich hatte keine Lust auch noch einen Webshop - Bestellformular - Registrierung  - Trailinstaller usw. für die Webseite zu programmieren... Und natürlich wollte ich kein deinstallieren / installieren Prozess  jedes mal machen müssen, daher verhält sich der Installationsprozess wie ein Update von einem Repository.

Dann wird nach dynamisch entschieden, was überhaupt - per REST - herunter geladen werden muss.

Das Ganze setzt - auf den in Zukunft noch kommenden - Zusatzmodulen:

- REST-AddOn
- MVVM-AddOn
- FDK-REST-Server

auf. Eine enorme Erleichterung, wenn man diese Dinge nicht selber (LOL) programmieren muss.

Das MVVM-AddOn nutzt auch mein eigenes NotVisual-LiveBinding, welches über die RTTI die Komponenten der Views mit den Propertys des ViewModels verbindet...

Ein ganzes Adress-Formular ans ViewModel binden? - piece of cake...

 

Alle die bereits das Early-Bird Paket bestellt haben, erhalten in den nächsten Tagen eine e-Mail mit dem Downloadlink.

 

Alle anderen können es gerne noch bestellen!

 

 

Einfach eine e-Mail mit dem Betreff : "Early-Bird" und den Kontaktdaten an Sysop@delphiprofi.de senden

FDK: Hat vielleicht den falschen Namen?

Hallo Zusammen!

Böse-Zungen behaupten FDK steht eigentlich nicht für:

Firemonkey-Development-Kit sondern für Frank's-Development-Kit.

Dem ist "natürlich" nicht so... Viele Pattern und Units kommen auch von Sir-Rufo.

Aber aus aktueller Sicht, muss ich vielleicht zugeben, dass die Namensgebung nicht schlau gewählt war, denn

90% oder sogar mehr der Routinen funktionieren
genauso für VCL-Programme.

 

Warum also Firemonkey? Ganz einfach, weil die Pattern und viele Routinen entstanden sind aus der Notwendigkeit unter FMX anders zu programmieren als unter Windows und VCL. Und das ist immer noch der Keypoint. Jede neue Routine, die es ins FDK schafft, wird so programmiert, dass Sie optimal unter FMX und den mobilen Plattformen funktioniert.

 

Also liebe VCL Programmierer - Klar ist das FDK auch etwas für Euch... Und ja, auch um Code aus alten Projekten zu refrakturieren!

 

 

Developer Experts Days in Leipzig

Hallo!

Ich freue mich auf die 2 Tage Workshop zusammen mit Olaf in Leipzig.

Wieder mal mein Lieblingsthema Interfaces, DI und Unittests...