Delphi-Tage 2016 Thema meiner Vorträge!

Das Thema meiner diesjährigen Vorträge auf den Delphi Tagen lautet:

1. Vortrag zusammen mit Olaf Monien

Effektives Multithreading – Die einfache Welt des TTask.Run und was kommt danach?

2. Vortrag

Zusammenklicken oder Programmieren?
Die Vorteile von dynamisch erzeugen Komponenten anhand von Firemonkey Beispielen!

Es wird sicherlich wieder eine interessante Veranstaltung.

FDK - Feature Matrix

Vorab unsere Feature Matrix*.

Was sich genau dahinter "versteckt" folgt in Kürze... *) Diese Zusammenstellung ist auch noch nicht endgültig.

Lite-Version

Delphiprofi.FDK.AnyFactory
Delphiprofi.FDK.Config
Delphiprofi.FDK.Console
Delphiprofi.FDK.Events
Delphiprofi.FDK.Exceptions
Delphiprofi.FDK.FireDAC
Delphiprofi.FDK.FluidCreator
Delphiprofi.FDK.FMXHelpers
Delphiprofi.FDK.Helpers
Delphiprofi.FDK.IdleWorker
Delphiprofi.FDK.IFDEF
Delphiprofi.FDK.IO
Delphiprofi.FDK.KeyValue
Delphiprofi.FDK.Logging.ConsoleLogger
Delphiprofi.FDK.Logging.DebugLogger
Delphiprofi.FDK.Logging.FileLogger
Delphiprofi.FDK.Logging.LogFilter
Delphiprofi.FDK.Logging
Delphiprofi.FDK.MainApplication
Delphiprofi.FDK.Messages
Delphiprofi.FDK.Observer
Delphiprofi.FDK.Pattern
Delphiprofi.FDK.Pattern.Internals
Delphiprofi.FDK.Platform.Utils
Delphiprofi.FDK.Resources
Delphiprofi.FDK.StringConsts
Delphiprofi.FDK.Types
Delphiprofi.FDK.Utils

Full-Version
(zusätzlich zur Lite-Version)

Delphiprofi.FDK.AnyConverter
Delphiprofi.FDK.BackgroundWorker
Delphiprofi.FDK.CallByIDFactory
Delphiprofi.FDK.Compressing
Delphiprofi.FDK.Compressing.ZLib
Delphiprofi.FDK.Converters
Delphiprofi.FDK.Crypting
Delphiprofi.FDK.DataView
Delphiprofi.FDK.DTOWithVersion
Delphiprofi.FDK.Enumerables
Delphiprofi.FDK.EventBus
Delphiprofi.FDK.Fmx.Enumerables
Delphiprofi.FDK.Generics.BlockingCollections
Delphiprofi.FDK.Generics.Collections
Delphiprofi.FDK.HeartbeatWorker
Delphiprofi.FDK.Json
Delphiprofi.FDK.MulticastEvents
Delphiprofi.FDK.Push
Delphiprofi.FDK.Specifications.Dates
Delphiprofi.FDK.Specifications
Delphiprofi.FDK.Specifications.Strings
Delphiprofi.FDK.Stateless
Delphiprofi.FDK.Streams.Hashing
Delphiprofi.FDK.Streams
Delphiprofi.FDK.Tethering
Delphiprofi.FDK.Tethering.Queue
Delphiprofi.FDK.Tethering.TransferObjects
Delphiprofi.FDK.TextLayoutHelper
Delphiprofi.FDK.Threading.AsyncTasks
Delphiprofi.FDK.Threading
Delphiprofi.FDK.Threading.Pipeline
Delphiprofi.FDK.TimeOutWorker
Delphiprofi.FDK.TreeViewWalker
Delphiprofi.FDK.Vcl.Enumerables
Delphiprofi.FDK.Winapi.Windows

Dies Zusammenstellung entspricht der Version 1.0 weitere Units sind in der Queue!

Fortschritt im FDK

Zwischenstand des FDK's

Für alle die sehnsüchtig das Release des FDK's erwarten, hier ein kleiner Zwischenstand.

 

Die Inline-Docu ist fast fertig.

Die Beginners-Docu ist fast fertig.

 

Die Funktionalitäten der Lite-Version sind bis auf 2 Units fertig.

Die Funktionalitäten der Full-Version braucht noch ein bisschen refactoring.

 

Es fehlt noch:

- Erstellung der Installationspakete

- Einrichtung Bugtracker

 

Wir hoffen jedoch bis zu / auf den Delphi-Tagen / die Lite-Version rausgeben zu können.

Rest folgt dann schnellstmöglich...

 

* so ist der Plan....

 

 

Delphi-Tage 2016 in Köln

Selbstverständlich bin ich auf den Delphi Tage 2016 auch wieder als Speaker dabei.

Die Delphi-Tage werden jedoch nicht mehr von den drei Delphi-Foren organisiert. Auch Embarcadero hat sich nicht an der Organisation beteiligt.

Trotzdem kommt - so hat er es angekündigt - Marco Cantu.

Um es mit berühmten worten zu sagen: Klingt komisch, is´ aber so.

Was ändert sich? Eigentlich fast nix.

 

• Es wird wieder ein Workshop vor den Delphi Tagen geben. (Do. & Fr.)
• Es wird am Abend vor der Hauptveranstaltung einen Community-Abend geben. (Fr.)
• Es werden wieder zahlreiche Vorträge rund um Delphi gehalten. (Sa.)

Geändert hat sich meine Beteiligung. 

 

• Ich unterstütze Olaf beim Workshop.
• Ich werde zwei Vorträge halten.

Eine Veranstaltung wie die Delphi-Tage, darf einfach nicht ausfallen. Welche Gründe vorlagen, dass sich die bisherigen Organisatoren zurückgezogen haben, entzieht sich meiner Kenntnis. Spielt aber eigentlich auch keine Rolle. Für mich war es jedoch sofort klar, dass ich meine Hilfe und Beteiligung,  angeboten habe. Jeder der ein bisschen rechnen kann, wird erkennen, dass mit 35,- € pro Person, so eine Veranstaltung nicht zu finanzieren ist. In der Vergangenheit wurde ein großer Teil der Veranstaltung durch die Sponsoren bezahlt. Eine kleine Preiserhöhung auf (43,- €) wird aber jeder "verschmerzen" können.

 

Ein Bestandteil der Delphi-Tage - war schon immer - der Workshop vorher. Hier geht es weiter in die Tiefe, als es ein 60 Minuten Vortrag kann. Wie ich es hier schon in einem früheren Blogpost beschrieben habe: Fortbildung muss für jeden ernsthaften Developer ein fester Bestandteil im Terminkalender sein. Ob es sich hierbei um ein Selbststudium handelt oder die Teilnahme an einem Workshop ist erst mal zweitrangig. Den eigenen Schweinehund zu besiegen und - obwohl man schon seit Jahren programmiert - wieder die "Schulbank" zu drücken ist erst mal das Thema.

 

Seit vielen Jahren, treffen sich 6-12 Entwickler regelmäßig bei unserer Delphi-Frühstücks-Gruppe. Auch wenn sich das Kern-Team immer wieder trifft. Es gab noch kein Treffen bei dem ich und das sagen auch die anderen, nix neues gehört haben. Jedes Treffen hat ein Mosaik-Steinchen für mein Wissen gehabt...

 



Refactoring - Der "tägliche" Wahnsinn.

Wer kennt das nicht... Ein Projekt entwickelt sich immer weiter, natürlich kommt man an einen Punkt und stellt fest, XY benötige ich jetzt schon in 2 Units, 3 Units, 4 Units... Ab wann wird es Zeit daraus ein Pattern zu machen?

 

Frühzeitig? Nach Abschluss?

 

Aber was ist, wenn ich dieses Pattern mit nur kleinen Veränderungen auch in 3-5 anderen Units verwenden könnte? Soll ich lieber eine Kopie machen oder die Veränderungen mit einem Parameter steuern? Oder übergebe ich die Funktionalität lieber als interface an das Pattern? Was sieht nicht nur schick im Source-Code aus, sondern ist dann auch praktisch in der Benutzung? Fragen über Fragen.

 

Ich habe mittlerweile eine Klasse, die hat heute zum 2. Mal einen neuen Namen bekommen und die Unit habe ich zum 3. mal renamed. Natürlich nicht ohne die Documentation, das Handbuch und alle Anwendungen die daraufhin geändert werden müssen neu zu kompilieren. War das eine gute Idee?

 

Also vielleicht erstmal ein paar "Rule of Thumbs" generieren.

 

1. Je mehr Code ich vernichten kann, weil ich eine "zentrale" Routine nutze. Desto weniger Codezeilen können einen Fehler haben.
2. Wenn meine Anwendung in der Regel "nur" Basis-Routinen aufruft und diese fehlerfrei sind, um so weniger Fehler kann meine Anwendungen haben. Voraussetzung hierfür ist natürlich die Testbarkeit. Da jedoch "zentrale" Routinen einfacher zu testen sind, ist meine Anwendung einfacher zu testen.
3. Ist die Basis-Routine Threadsave, ist es einfacher meine eigenen Routinen Threadsave zu gestalten (vereinfacht ausgedrückt). // Ach wäre doch nur die VCL/RTL Threadsave.
4. Bei der Schaffung einen neuen Basis für XY erkaufe ich mir jedoch Zwangs-Verlinkungen ein!

Lohnt es sich also zu Refrakturieren?

 

Auf jeden Fall - am besten immer so schnell wie möglich, wenn ich ein Problem erkenne. Je früher ich es behebe, desto weniger Source-Code baut darauf auf.

 

"Nur das mit der Doku ist lästig, wenn ich eine habe..."