Dienstag, 24. Februar 2009

Namespace abgrenzen

Über eine interessante Schreibweise bin ich neulich gestoßen. Nämlich die, den Namespace für lokale Variablen innerhalb einer Methode zu begrenzen:

public void test() {

{
String s = "test";
//... tu was mit dem String
}

// String s ist hier nicht mehr im Zugriff.
}

Mit dieser Schreibweise lassen sich Variablen voneinander abgrenzen, in dem diese nur für einen bestimmten Bereich der Methode sichtbar gehalten werden. Fängt man aber mit einer funktionalen Abgrenzung innerhalb einer Methode an, scheint es mir eher angebracht, diese Bereiche, die ohnehin einen eignen Namespace erhalten, gleich in eine neue Methode auszulagern, was gleichzeitig die Chance birgt, der Methode einen sprechenden Namen zu geben und damit die Lesbarkeit zu verbessern. Außerdem erhöht man damit die Wahrscheinlichkeit, dass wer anders im Team die Methode findet und Wiederverwendet, anstelle eine eigene neu zu schreiben. Nach einigem Abwegen habe ich für mich jedenfalls entschieden, dass ich diese Schreibweise nicht mag.

Samstag, 21. Februar 2009

Apache Betwixt

In meinem vorherigen Beitrag Konfiguration für Clientanwendungen bin ich bei der Apache Betwixt Library hängen geblieben. Mit Betwixt kann man recht ordentlich Javaklassen in XML und wieder zurückwandeln. Inzwischen bin ich auch dazu gekommen Betwixt mal einzusetzen. Ansich funktioniert die wirklich gut. Was allerdings im Nachhinein praktisch gewesen währe, währe eine Unterstützung für Annotaions, um die zu behandelnden Setter/Getter zu markieren. So werden beim Wegschreiben alle Methoden behandelt, die mit get beginnen und bei der Rückwandlung finden die passenden setter Verwendung. Außnahmen gibt es keine.

Ein großes Manko ist mir allerdings noch aufgefallen. String Arrays werden zwar korrekt weggeschrieben, die Rückwandlung funktioniert jedoch wenig gut. Als Alternative bleibt also doch nur wieder ein String mit Separator, den man später auseinanderschneidet. Dafür gibt es aber auch was bequemes aus der Apache Commons Library. Zum auseinanderschneiden: StringUtils.split("Eintrag1;Eintrag2", ';') und zum Zusammenfügen: StringUtils.join(String[] {"Eintrag1", "Eintrag2"}, ';'). Klarer Nachteil, neben der zusätzlichen Schreibarbeit, dass man das Trennzeichen mit Bedacht wählen sollte. Sonst hat man bei einer Benutzereingabe plötzlich einen Eintrag mehr als gewünscht. Alles in allem nicht optimal, aber für meine Zwecke wird es wohl ausreichen. Zumindestens kann sich so recht bequem eine hierarchische Konfigurationsstruktur erstellen.

Donnerstag, 19. Februar 2009

Linktips

Mastering Eclipse V3.4, Part 3: JDT text editor tips and tricks enthält auch für den geübten Eclipse Anwender   durchaus neues. Jedenfalls kannte ich "Automatically create locals" und "Breadcrumb bar" noch nicht. Oft ist man auch so eingefahren in seinem Nutzungsverhalten, dass man Neuerungen gar nicht mehr wahr nimmt. Die "Breadcrumb bar" gibt es erst seit Eclipse 3.4. Vermutlich der Grund, warum ich die noch gar nicht wahr genommen habe. Bei uns ist Eclipse 3.2 noch das höchste der Gefühle.

Top 25 Most Dangerous Programming Errors
ist eine Zusammenstellung von Klassikern der Programmierfehlerkunst, nur neu aufgelegt. Einige gefährlichen Programmierfehler, die SANS da nennt, sind für Javaprogrammierer aber ohnehin irrellevant.

L2FProd-Common Components bietet ein paar Komponenten, die man vor allem auch aus der Windowswelt kennt. Von früher kannte ich da noch das Skin Look And Feel. Common Components ist zwar nicht neu, aber absolut empfehlenswert für GUI Schrauber. Der JDirectoryChooser ist jedenfalls eine sehr nützliche Komponente und scheint gut zu funktionieren.

Mittwoch, 18. Februar 2009

Mac Widgets for Java

Wieder einmal was für Swing Liebhaber: mac widgets stellen die OS X üblichen Komponenten auch für Java/Swing zur Verfügung. Die Komponenten wurden vollständig in Java implementiert, so das diese auch plattformunabhängig funktionieren sollten. Version 0.9.4 (17.02.09)

Promo Abbildungen:

         


Mittwoch, 11. Februar 2009

Die unliebsamsten Dinge der Softwareentwicklung

Es gibt ja Sachen, die macht kaum ein Softwareentwickler gern und werden schnell vernachlässigt oder kurzerhand weggelassen. Hier die Top 6:

1. Dokumentation - Ganz gleich ob Code- oder Benutzerdokumentation. Die Benutzerdokumentation sollte eigentlich ohnehin nicht der Entwickler machen, häufig ist dem aber so. Entsprechend sieht auch das Ergebnis aus. Gute Codedokumentation sieht man noch seltener.

2. Testen - Tests schreiben kostet Zeit und erscheint unnötig, weil es Funktioniert ja alles. Die Nützlichkeit fertiger Tests tritt erst dann zutage, wenn im laufe der Fehlerbeseitigung weitere Fehler eingearbeitet werden. Das kann zu einer sehr langwierigen Fehlerbeseitigungskette führen, die der Kunde selten gern hat. 

3. Datenschutz - Sehr unliebsam, weil stört nur den Produktivitätsprozess des Entwicklers und scheint zunächst gar nicht wichtig, weil sieht ja keiner von außen.

4. Sicherheit - Nur wenige Entwickler machen sich Gedanken um die Sicherheit ihrer Software. Auch hier bemerkt ja zunächst niemand etwas und es macht mühe sich in der laufenden Entwicklung auch darüber noch Gedanken zu machen. Rein Funktional ist die Sicherheit ja egal.

5. Usability - Eine Oberfläche wird gern mal schnell hingestrickt, damit der Anwender die supergeilen Programmfunktionen auch benutzen kann. Es reicht leider nicht aus, mal eben ein paar Icons beim Grafikdesigner anzufordern. Ein echtes Usability Konzept ist bei vielen Projektentwicklungen nicht anzutreffen.

6. Kommunikation - Besonders die mit dem Kunden ist besonders lästig. Der Entwickler ist während des gesamten Kundengesprächs damit beschäftigt dem Kunden das auszureden, was der sich vorstellt oder, was ihm der Vertrieb vorher versprochen hat. Häufig kommt der Kunde auch noch auf Punkt 1-5 zu sprechen, was es dann abzuwiegeln gilt.

Top Ausrede des Softwareentwicklers ist übrigens der Zeitdruck - den es zweifelsfrei gibt! Auf der anderen Seite kosten einige der oben genannten Punkte im nachinein noch viel mehr Zeit. Sehr empfehlenswert dazu: Extreme Programming

Technorati-Tags: , , , , , , , ,

Dienstag, 10. Februar 2009

l2fprod commons PropertySheet

Das l2fprod commons Projekt enthält unter anderem eine PropertySheet Komponente. Nach dem ich ein paar Properties eingerichtet habe, die aufzuklappen sind, fehlte mir natürlich auf Anhieb ein feature - nämlich alle Einträge direkt nach der Initialisierung aufzuklappen. Hier stellt sich dann auch mal wieder der Vorteil von Open Source heraus - die Sourcecodes sind im Lieferumfang enthalten. Ein wenig Suchen und eine kurze Methode zum PropertySheetTable hinzugefügt, und schon ist alles in Butter. Das ganze sieht dann so aus:

  public void expandAll() {
      final PropertySheetTableModel sheetModel = getSheetModel();
      int rowCount = sheetModel.getRowCount();

      for (int i = 0; i < rowCount; i++) {
          final Item item = getSheetModel().getPropertySheetElement(i);
          if(!item.isVisible() && item.hasToggle()) {
              item.toggle();
              rowCount = sheetModel.getRowCount();
          }
      }
  }


Technorati-Tags: , , ,

Arbeitsalltag Kundenwünsche

Bekomme ich heute einen Bug/Kundenwunsch für ein Projekt rein, das ich bereits seit einigen Jahren betreue. Wird die Anwendung beendet, erscheint üblicher Weise ein Beenden Dialog. Sind eingegebene Daten noch nicht gespeichert, erscheint eine Speicherabfrage, jedoch der Beenden Dialog nicht mehr. Klingt zunächst nach einem Bug. Ist aber kein Bug, sondern ein Feature, was der Kunde ausdrücklich haben wollte. Jetzt wird beim Kunden erst einmal Nachgeforscht, wer das damals entschieden hat und warum das so sein sollte. Für mich ist der Kommunikationsoverhead jedenfalls erheblich größer, als der das Flag rauszunehmen.