Neuigkeiten zu OASIS-SVN ...

... und Nachrichten aus den Bereichen Access- und Delphi-Entwicklung

Neuer Assistent ...

Die Integration von TortoiseGit und TortoiseHG ist mittlerweile recht gut gelungen und wird inzwischen auch häufig eingesetzt.

Eine Sache ist aber bei der Integration irgendwie unter den Tisch gefallen: Der Assistent wurde nie so richtig mit den neuen Systemen ausgetestet. Auch die Beta-Tester hatten den wohl irgendwie nicht auf dem Schirm. Warum auch? Als inzwischen gestandene Profis in Sachen Quellcodeverwaltung benötigt man den ja auch so gut wie nie. Entwickler sind halt wie immer nur sehr schlechte Tester.

Da der bisherige Assistent nun mittlerweile auch etwas in die Jahre gekommen ist, habe ich beschlossen hier mal grundlegend zu renovieren.
Die Komponenten von Developer-Express bieten dazu auch gleich das richtige Steuerelement an, so dass der neue Assistent dann auch in einem modernen, frischen und professionellen Look daherkommt.

Das Design ist soweit fertig, nun geht's an Feinarbeit in Sachen Funktionalität und an die Lokalisierung ... 

Warum eigentlich Delphi?

Mit schöner Regelmäßigkeit werde ich auf Konferenzen und Events gefragt, mit welcher Sprache OASIS entwickelt wird. Wenn ich dann antworte, dass ich mit Delphi entwickle, ernte ich oft fragende Blicke, Stirnrunzeln und Verwunderung.

Warum denn ausgerechnet Delphi und nicht C#, C++ oder VB.Net?

Die Antwort ist eigentlich reichlich trivial: Weil ich's kann :-) Nein, nun mal im Ernst: Natürlich ist der Hauptgrund, dass ich Delphi im Gegensatz zu den anderen genannten Sprachen einfach besser beherrsche. Das schreibt sich fast so leicht runter wie VBA ... ganz einfach weil ich beide Sprachen fast täglich verwende.

Aber es gibt noch einen weiteren - für mich persönlich ganz wichtigen - Grund: Ich hasse sämtliche Arten von Laufzeitumgebung. Einer der Gründe, warum ich beispielsweise von Java überhaupt nichts halte. Als Entwickler habe ich keinen Einfluss darauf, welche Version der Java-Runtime auf dem Zielrechner installiert ist.

C# und alle anderen Sprachen aus dem .Net-Umfeld haben prinzipiell den gleichen Nachteil, denn das .Net-Framework ist ja nichts anderes als eine Laufzeitumgebung. Und wenn ich gegen eine bestimmte Version des Framework entwickle und die auf dem Zielrechner nicht installiert ist, muss der Anwender das nachholen.

Und sowohl bei der Java-Runtime als auch beim .Net-Framework kommt das Problem mit den Updates hinzu, auf die ich keinen Einfluss habe. Vor allem bei Java habe ich es bereits des Öfteren erlebt, dass eine Anwendung nach einem Update der Laufzeitumgebung plötzlich den Dienst verweigert.

Weiterlesen

Neue Features ab Version 3.0.15

Mit der kommenden Version 3.0.15 werden neue Features veröffentlicht:

  • Die Filterung der einzelnen Listen im Im- und Exportdialog wird künftig beim Schließen des Dialogs gespeichert und beim erneuten Öffnen wiederhergestellt.
  • Für die automatischen Updates lässt sich einstellen, ob ggf. nur eine Meldung erfolgen soll.

Außerdem wurden natürlich einige kleinere Fehler und Unschönheiten beseitigt.
So wird die Liste der Tabellen nun auch direkt beim Öffnen des Exportdialogs sauber gezeichnet .. das sah in der Vergangenheit manchmal etwas unschön aus.

 

Clean Code

Seit einiger Zeit bin ich ein großer Fan der Clean-Code-Prinzipien.

Auch wenn man - besonders als Access-Entwickler - nicht wirklich alle Prinzipien und Praktiken beherzigen und umsetzen kann, verhilft das Ganze dem eigenen Code doch zu einem erheblichen Gewinn in Sachen Lesbarkeit, Erweiterbarkeit und Wartbarkeit.

Wie oft hat man schon Stunden mit dem Studium von Code zugebracht und bei sich gedacht "welcher Vollpfosten hat das nun schon wieder verbrochen" ... nur um dann irgendwann festzustellen: Das war eigener Code, den man in einem Anfall von geistiger Umnachtung eingehackt hat.

Weiterlesen

OASIS-SVN 3.0

Lange ... naja, eigentlich seeeehr lange ... habe ich mich mit der Integration weiterer Versionsverwaltungen zusätzlich zu Subversion beschäftigt.

Die ersten Versuche mit abgeleiteten Klassen schienen zunächst vielversprechend, führten aber aufgrund einiger Programmierfehler zu seltsamen Verhaltensweisen und Fehlern.
Reichlich frustriert wurden sämtliche Änderungen wieder zurückgenommen - wie praktisch, wenn man seinen Code unter Quellcodeverwaltung hat.

Da Anwender aber immer wieder den Wunsch geäußert haben, neben Subversion auch z.B. Git zu unterstützen, wurde ein neuer Versuch gestartet.
Dieses Mal wurden die nötigen Methoden als Interface deklariert, welches die einzelnen Systemklassen dann implementieren.
Das funktionierte soweit ganz gut ... nur dumm, dass dafür ein eigener Branch in der Quellcodeverwaltung angelegt war und dieser sich im Laufe der Zeit so weit von der eigentlichen Entwicklung weg entwickelt hatte, dass ein Merge so gut wie unmöglich war.

Weiterlesen