Freitag, 23. Juni 2017

Delphi hat einen Fehler...?

(Oder wie verbringe ich einen halben Tag mit Fehlannahmen...)

Klar, nicht nur einen, aber so ist das eben mit Software...


Da es keine fehlerfreie Software gibt, kann man diese Frage getrost mit ja beantworten. Aber wie suchen "wir" den Fehler?

Natürlich am besten mit Unit-Tests... Aber UI? OK...Ein anderes Thema

Workflow:

<F9> Testen -> Exception

Exception position ist nicht im eigenen Source, sondern tief in der RTL. Auch noch in einen Assembler-Teil.

OK - Kann nur die Liste nicht initialisiert sein...

Also Breakpoint setzen und nochmal...
<F9> Testen -> Debugger hält brav am Breakpoint an...

FListe in die Watchvariablen übernehmen... Nöö geht nicht... Und dann fängt es an falsch zu laufen...

1. Fehlannahme : OMG, Die IDE kann schon wieder eine Variable nicht anzeigen...

also fix ne lokale Variable "LListe" und mit der arbeiten...

<F9> Testen -> Debugger hält brav am Breakpoint an...
<F7>, <F7>,<F7> - Prima alles richtig... <F7> FListe := LListe;
Bang - Exception;

OK - Logger anwerfen... Geht ja dank FDK mit einer Zeile...

Das Log sieht gut aus... Oberflächlich betrachten... Alles wird schön erzeugt.... Alles Prima!

Aber:
<F9> Testen -> Debugger hält brav am Breakpoint an...
<F7>, <F7>,<F7> - Prima alles richtig... <F7> FListe := LListe;
Bang - Exception;

2. Fehlannahme : Shit, ich Idiot, greife von einem Thread aus auf eine Liste in der Klasse zu...

FListe ist kein Object, aber

kein Thema Uses Delphiprofi.FDK.Classes;

Class -> Class(TClassWithSync) // Erzeugt eine FSync : TObject für einen TMonitor...

TMonitor.Enter(FSync);
try
  FListe := LListe;
finally
  TMonitor.Exit(FSync);
end;

Jetzt aber....Breakpoint auf die Zuweisung...

<F9> Testen - Exception... What... Der ist gar nicht bis zum BreakPoint gekommen... Nochmal durch steppen...

<F9> Testen - <F7>, <F7>,<F7> - Prima alles richtig... <F7> TMonitor.Enter(FSync) - Bang...
Exception...

Das gibt es doch gar nicht, ich bin doch lokal in der Klasse wieso kann er nicht auf FSync zugreifen...

3. Fehlannahme : Ich habe einen Fehler in 10.2 gefunden... Ich kann aus einem Thread nicht mehr auf private Felder eine einer Klasse zugreifen...(Kaum zu glauben, ist aber so {nicht})

Also das Ganze mit 10.1

<F9> usw... Bang... gleicher Fehler...

Das ist jetzt aber doof... Also schnell den Browser mit dem "System Dashboard" wieder zu machen...

OK.. Dann mal ohne Thread...

Ups... Jetzt geht es... Wieso das den?

Also wieder mit Thread - Am Thread kann es auf keinen Fall liegen, das mache ich immer so... erstmal ein Paar Logeinträge mehr erzeugen...

<F9> Log... Bla, Bla Bla... TMainViewModel.BeforeDestruction - WTF... Wer war das.... Ist doch kein Interface... Also kein Problem mit dem REFCount... Hätte ich doch besser mein MVVM-Framework genommen, aber nein für so einen kleine App...

Breakpoint setzen...
 
Wird von der MainView aufgerufen mit FreeAndNIL(FViewModel) aber wieso?

Wer lesen kann ist klar im Vorteil... Finde den Fehler...

procedure TFormMain.FormDeactivate(Sender: TObject);
begin
  FreeAndNIL(FViewModel);
end;

Das kommt davon, wenn man auf die schnelle mit der IDE etwas zusammen klicken will... Einfach eine Zeile zu hoch im Objektinspektor....

procedure TFormMain.FormDestroy(Sender: TObject);
begin
  FreeAndNIL(FViewModel);
end;

Wäre besser gewesen...

Ohne den gelernten Workflow -> Ich sehe meinen Fehler nicht - muss am Delphi liegen... Was leider hin und wieder mal vor kommt... Wäre das nicht passiert...

Logisch - und um es richtig zu stellen...
Natürlich geht es jetzt auch mit 10.2 und aus dem Thread...

Kaum macht man es richtig, schon funktioniert es...

Mittwoch, 14. Juni 2017

Schulungs- & Consulting-Termine 2017

Die Nachfrage bezüglich Consulting vor Ort und andere "Programmierhilfen" steigt momentan fast Täglich - was mich sehr freut!

Hierbei geht es von kurzer Hilfe per Skype & TeamViewer bis zu mehrtägigen Schulungen oder Programmieraufträgen.

Vielleicht liegt es an der neue Delphi-Version oder an den kommenden Veränderungen. (iOS 11)

Ich würde daher im 3. oder 4. Quartal - bei einer entsprechenden Teilnehmeranzahl - jeweils eine mehrtägige Schulung anbieten.


Selbstverständlich - wie man es von Mir mittlerweile erwartet - dreht es sich hierbei um Firemonkey.

Aber was ist mit der VCL?


Sourcecode welcher "für" VCL geschrieben ist, wird in der Regel nicht Plattform unabhängig sein, Sourcecode der jedoch für "FMX" geschrieben ist, kann normalerweise ohne Veränderungen auch für VCL-Programme compiliert werden.


Daher braucht man bei non-UI Dingen eigentlich keinen Unterschied machen... Um soliden, testbaren Sourcecode zu schreiben braucht man eigentlich nur folgendes Handwerkszeug: Linken gegen Interfaces, untereinander nicht verlinkte Units und Unittest...


daher:


Die Themen sind die üblichen Verdächtigen:
- Designpattern
- Interfaces
- Unit-Test.
- Threading
- REST / JSON


Darüber hinaus wird immer wieder gefragt:
- Wie mache ich was?
- Mache ich das eigentlich richtig?
- Geht das nicht einfacher?
- MVVM oder Klick-aufs-Form


Frei nach dem Motto: "Usen ist schneller als coden" erhält jeder Teilnehmer mein FDK.




Termine und der Veranstaltungsort stehen noch nicht fest, aber bei Interesse bitte unbedingt vorab schon mal eine E-Mail an mich schreiben mit dem Betreff "Schulungstermine"

Montag, 22. Mai 2017

Hype Driven Development.

Wer kennt das nicht? Man(n) kommt von einer Tagung oder hat ein cooles YouTube Video gesehen. Dann passiert es - Das muss ich auch machen...
 
Gut oder schlecht... (Wenn man einige Blogs zu diesem Thema liest ist die Meinung: eher schlecht)
 
Klar kann man noch mit Delphi 7 mit dem Sprachumfang von UCSD-Pascal programmieren. Eigentlich spricht da nix gegen, oder?
 
Hey, die Programme laufen und machen das, was die Kunden wünschen - also alles bestens, oder? Viele betreiben so die eigene Firma und verdienen ihr Geld... Also kann es ja nicht schlecht sein!
 
Aber sollte man nicht hin und wieder über den Tellerrand schauen? Der Satz: "Wir haben das doch immer so gemacht.", wird oft benutzt.
 
Eigentlich sind doch Programme nie fertig. Es immer mal ein neues Feature eingefügt oder eine Funktionalität verbessert. I.d.R. alles single-Thread, Main-Thread...
 
Ist das Programm überhaupt noch wartbar? Sollte man mal das Layout überarbeiten, vielleicht das Menü auf Ribbon umstellen oder eine Datenbank verwenden? Die Geschwindigkeit mit Threads verbessern?
 
Vielleicht hilft ein Hype den Sprung zu schaffen... Klar gibt es dann immer eine Lernkurve, aber ist das den so tragisch? Den alten Kopf mal wieder auf "Klassenarbeit steht an", Niveau bringen... 
 
Oft habe ich bei Schulungen oder Tagungen diese Sätze gehört:
 
  • Interfaces - Ja hab ich schon mal gehört, nutzen wir aber nicht.
  • Threads - ja das macht bei uns der Peter, aber der ist seit 4 Wochen krank, wenn der wieder da ist, Frag ich Ihn mal.
  • Factory's - brauche ich nicht, es geht auch so.
  • Dependency Injection - Du immer mit Deinem neumodischen Zeug.
  • Unit Tests - Wollten wir auch mal machen, steht ganz oben auf meiner Liste, aber ich bin bisher nicht dazu gekommen mir das mal an zu sehen.
  • Generics - Hab ich schon mal gehört, das ist doch das Ding mit den spitzen Klammer, oder? Ich nehme für sowas immer einen Pointer.
  • Git/Mercurial - Ist mir zu kompliziert ich zippe meinen Source einfach zusammen.
  • MVVM - Brauch ich nicht, ich kopiere den Source von einem Form in das nächste. Ich will ja auch beim Debuggen sehen, was passiert wenn ich den Button-Klicke.
  • JSON - Hab ich noch nie gebraucht, was macht man damit?


Vielleicht wäre hier ein bisschen Hype-Driven-Development angesagt...


Aber warum das Ganze? Wofür soll ich getrennte testbare Units programmieren, wenn ich sowieso keine Unit-Test mache? Sicherlich kann man sich "zu Tode entkoppeln". Ab wann ist zuviel des Guten eigentlich zuviel?

Mit MVVM, Factories  und nur gegen Interfaces linken, kann schnell zu einer Sucht werden und die IDE findet bei einem Klick auf die Variable immer nur die Factory oder das Interface, leider NIE die gerade aktuelle Implementierung. Was macht ein Klick auf den Button? Das steht da leider nur dann richtig lesbar, wenn man seine Proceduren wirklich gut benennt. Aber auch dann muss man erstmal die entsprechende Unit (ViewModel) finden, die in dieser Implementierung für diese Plattform verwendet wird.
Eine Interfacevariable wir immer nur mit dem Typen und der Adresse angezeigt - ich sehe im Debugger nicht die Belegung. (Vielleicht mal einen Visualizer programmieren?)
Einfacher wird es nicht und wenn man(n) dann noch unstrukturiert auf neue Techniken  los geht - dann ist man(n) schnell in einer Falle die alles noch viel schlimmer macht, als es vorher schon war.

Wäre das der Moment auf meine Schulungs- und Consultingangebote hin zu weisen?

Also doch nicht jeden Hype mit machen, aber sich die "neuen" Techniken rauspicken, die eine bessere Source-Code-Übersicht, besseres Laufzeitverhalten oder höhere Kundenzufriedenheit ermöglichen!


Ich muss nicht jeden Hype mitmachen - nur die Guten...

 
 

Donnerstag, 27. April 2017

FDK - Early-Bird

Die Stunden für eine Early-Bird-Bestellung des FDK's sind angebrochen.


Wer also noch die 100,- € sparen möchte, sollte jetzt das Angebot noch nutzen.


Ab den 01.05.2017 gilt der volle Preis...

Datenschutzerklärung

Datenschutz

Die Betreiber dieser Seiten nehmen den Schutz Ihrer persönlichen Daten sehr ernst. Wir behandeln Ihre personenbezogenen Daten vertraulich und entsprechend der gesetzlichen Datenschutzvorschriften sowie dieser Datenschutzerklärung.
Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder E-Mail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.
Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.

Kommentarfunktion auf dieser Webseite

Wenn Sie uns per Kontaktformular Anfragen zukommen lassen, werden Ihre Angaben aus dem Anfrageformular inklusive der von Ihnen dort angegebenen Kontaktdaten zwecks Bearbeitung der Anfrage und für den Fall von Anschlussfragen bei uns gespeichert. Diese Daten geben wir nicht ohne Ihre Einwilligung weiter.

SSL-Verschlüsselung

Diese Seite nutzt aus Gründen der Sicherheit und zum Schutz der Übertragung vertraulicher Inhalte, wie zum Beispiel der Anfragen, die Sie an uns als Seitenbetreiber senden, eine SSL-Verschlüsselung. Eine verschlüsselte Verbindung erkennen Sie daran, dass die Adresszeile des Browsers von "http://" auf "https://" wechselt und an dem Schloss-Symbol in Ihrer Browserzeile.
Wenn die SSL Verschlüsselung aktiviert ist, können die Daten, die Sie an uns übermitteln, nicht von Dritten mitgelesen werden.


Quelle: https://www.e-recht24.de


Weitere Informationen zum Datenschutz von Blogger: https://www.google.com/intl/de/policies/privacy/

Impressum

Angaben gemäß § 5 TMG:

Frank Lauter
Hostetstr. 153
52223 Stolberg (Rhld.)

Kontakt:

Telefon: 02402 / 90 55 264
Telefax: 02402 / 90 55 265
E-Mail: Frank@delphiprofi.de

Verantwortlich für den Inhalt nach § 55 Abs. 2 RStV:

Frank Lauter
Hostetstr. 153
52223 Stolberg (Rhld.)



Quelle: https://www.e-recht24.de


Weitere Informationen zum Impressum von Blogger : https://www.blogger.com/intl/de_de/impressum.html

Haftungsausschluss (Disclaimer)

Haftung für Inhalte

Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen.
Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.

Haftung für Links

Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar.
Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.

Urheberrecht

Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet.
Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.

Datenschutzerklärung

Datenschutz

Die Betreiber dieser Seiten nehmen den Schutz Ihrer persönlichen Daten sehr ernst. Wir behandeln Ihre personenbezogenen Daten vertraulich und entsprechend der gesetzlichen Datenschutzvorschriften sowie dieser Datenschutzerklärung.
Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder E-Mail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.
Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.

Kommentarfunktion auf dieser Webseite

Wenn Sie uns per Kontaktformular Anfragen zukommen lassen, werden Ihre Angaben aus dem Anfrageformular inklusive der von Ihnen dort angegebenen Kontaktdaten zwecks Bearbeitung der Anfrage und für den Fall von Anschlussfragen bei uns gespeichert. Diese Daten geben wir nicht ohne Ihre Einwilligung weiter.

SSL-Verschlüsselung

Diese Seite nutzt aus Gründen der Sicherheit und zum Schutz der Übertragung vertraulicher Inhalte, wie zum Beispiel der Anfragen, die Sie an uns als Seitenbetreiber senden, eine SSL-Verschlüsselung. Eine verschlüsselte Verbindung erkennen Sie daran, dass die Adresszeile des Browsers von "http://" auf "https://" wechselt und an dem Schloss-Symbol in Ihrer Browserzeile.
Wenn die SSL Verschlüsselung aktiviert ist, können die Daten, die Sie an uns übermitteln, nicht von Dritten mitgelesen werden.


Quelle: https://www.e-recht24.de
Plattform der EU-Kommission zur Online-Streitbeilegung: www.ec.europa.eu/consumers/odr

Dienstag, 25. April 2017

Unittest with Testinsight.

TestInsight is a unit testing IDE Plugin for Delphi from Stefan Glienke - but I think you already knew that! @Stefan:Usefull Tool!

I've used Unit-Test (the GUI-Version) for a long time, because I like to have the GUI. The console-output is of course better if you are using a batch to compile and test your application.

For my Firemonkey Development Kit, I tried DUnitX the first time, but - to be honest - Oliver has done this step. The missing GUI was always my breakpoint. :-)

One of my rules is: If I start a new Application, I try to use at least one new technique or one of the 4-Letter-Things (CRUD,REST,JSON,MVVM).  But this list was empty (for the moment). So DUnitX came back in view...

I heard about TestInsight ist the past, but never gave it a try. For my knowledge it was "only" an other GUI for the Testframework - so no need to take a look.

But one feature <F2> is the best I've seen for many years to speed up development.

Testdriven development is - not so common, I've learned on many events, talking to other developers - but I like this kind of development, especially when implementing new businesslogics.

The Feature is - Run Test on save.

Take your Projekt, add a Testprojekt to the Group, mark it as TestInsight and go on with your development. If you are ready with the Interface - we all code against Interfaces - implement all tests you what to cover. Then back to your main Application. On every Save - all tests run in background.

E.g.: Array[Index] is higher then High(Array) the Test will find it after the next save... No breaks in the development flow. Go and write Array[Index-1] - save - Success...

Next Step - run DUnitX on Android and iOS.. Should work anyway - Not tested yet.