Tatsächlich ist der Quellcodeeditor nur ein Bestandteil von vielen, die die Integrierte Entwicklungsumgebung (“IDE”) eines Entwicklers ausmachen: Damit der Quellcode überhaupt ausgeführt werden kann, muss er kompiliert werden. Bisweilen muss ein Entwickler während der Ausführung des Programms an bestimmten Stellen den Ausführungsfluss Schritt-für-Schritt  überwachen (“debuggen”), wozu die Anwendung in den Arbeitsspeicher geladen werden muss.

Der Quelltext bewegt sich auch nicht im luftleeren Raum: Anwendungen werden in Projekte und Bibliotheken aufgeteilt, häufig handelt es sich um einige hunderte bis tausende Dateien, die gemeinsam kompiliert und in den Arbeitsspeicher geladen werden müssen. Allein das Lesen der Quelltexte und das Erstellen der Kompilate kann bei mittelgroßen Anwendungen mehrere Minuten, bei größeren sogar viele Stunden andauern.

Auch wenn IDEs inkrementelles Kompilieren ermöglichen, wird des öfteren ein “Build” (alle Kompilate und dazugehörige Dateien) wieder gelöscht und vollständig neu erstellt.Zudem sind Softwareanwendungen im Unternehmensumfeld verteilt und kommunizieren mit Datenbanken, anderen Systemen und/oder der im Unternehmen eingesetzten Middleware.

Normalerweise ist der Entwickler bestrebt, auf seinem Rechner die Bedingungen, unter denen seine Anwendung später ausgeführt werden soll, en miniature nachzubilden: Auf diese Weise ist er unabhängig von Wartezeiten und kann ggf. auch offline (z.B. im Zug) arbeiten.

Was deshalb wirklich entscheidend für einen Entwicklerrechner?

Die Leistung:

Ein Softwareentwickler benötigt ein für seine Ansprüche äußerst leistungsfähiges System, was sich insbesondere auf

a) die Festplatte
b) den Hauptspeicher
c) die CPU und
d) Grafikkarte + Display bezieht.

Die Festplatte ist deshalb so wichtig, weil zum Erstellen von “Builds” oft tausende Dateien gelesen und geschrieben werden. Normalerweise liegt in langsamen Festplatten der Schwachpunkt von Entwicklersystemen (abgesehen von Virenscanner, die die Buildverzeichnisse überwachen). Sinnvoll können hier Solid State Discs (flash-basiert) oder RAID-Systeme (RAID 0 oder 0+1, aber nicht 5) mit SATA oder SAS sein, die den Datendurchsatz erhöhen.

Der Hauptspeicher muss sehr großzügig dimensioniert sein: Zur Zeit sollte ein Rechner für die Anwendungsentwicklung verteilter Systeme über mindestens 8 GByte Hauptspeicher verfügen, besser wäre gleich das Doppelte (einige Notebook-Workstations bieten mittlerweile 16 GByte an).

Softwareseitig bedingt dies den Einsatz von 64-Bit-Betriebssystemen.Wird mit virtuellen Maschinen gearbeitet (was immer mehr zunimmt), ist ein Mehrprozessor- wenigstens ein Multicoresystem sinnvoll. Um die Fülle an Informationen einer IDE wie Eclipse, Netbeans oder Qt auf einen Bildschirm zu bekommen, empfiehlt sich zudem ein hochauflösendes Display und eine entsprechende Grafikkarte.

Wie separat dargelegt, macht sich eine Leistungssteigerung bei Entwicklerrechnern schnell bezahlt. Um Entscheidern (und nach besserer Hardware strebenden Entwicklern) eine objektivere Entscheidungsgrundlage an die Hand zu geben, würde ich mir einen Benchmark wünschen, der

a) die Leistungsfähigkeit eines Systems hinsichtlich der o.a. Kriterien für einen Entwicklerrechner misst,
b) kostenlos verfügbar,
c) plattformunabhängig und
d) einfach bedienbar ist.

Ein Benchmark der mit Referenzprojekten arbeitet, der gängige IDEs startet, auf denen kleine, mittelgroße und große Referenzprojekte mit der IDE erstellt werden, wobei dies noch mit parallel laufenden Middlewareservern kombiniert werden sollte.

Falls jemandem ein solcher Benchmark bekannt ist, wäre ich dankbar für einen Hinweis ()! Interessenten, die ein derartiges Projekt auf die Beine stellen möchten, können mich gerne ansprechen.

Tatsächlich ist das Schreiben von Quellcode nur die Spitze des Eisbergs: Auf dem Entwicklerrechner wird dieser Quellcode nicht nur zu ausführbarer Software gemacht, sondern häufig eine vollständige Simulation der Unternehmensanwendungen ausgeführt, in deren Umgebung die Software verwendet werden soll. Also Datenbanken, Webserver, E-Mail-Server etc. etc.

Für den Entwicklerrechner bedeutet dies, dass er um ein Vielfaches leistungsfähiger sein muss als die Rechner, die man zur Erfüllung von Büroaufgaben verwendet.

Im Gegensatz zu Joel Spolsky statten viele Unternehmen ihre Softwareentwickler aber mit billiger Standardbürohardware aus. Meist muss schon die Aufrüstung des Arbeitsspeichers gesondert beantragt werden.

Was bedeutet das für die Entwickler? Vor allem müssen sie längere Wartezeiten in Kauf nehmen: Beim Kompilieren, beim Debuggen und Testen ihrer Anwendungen sowie beim Starten der IDE.

Was bedeutet das für die Unternehmen? Berechnen wir das einmal an einem Beispiel (aus meiner Praxis):

Die Entwickler eines größeren Finanzdienstleisters arbeiten mit Eclipse, die Anwendung wird in der Programmiersprache Java erstellt und ist in 10 voneinander abhängige Projekte (genauer: Maven-Module) gegliedert. Insgesamt handelt es sich um über viertausend Dateien, die kompiliert werden müssen (zuzügl. einiger Konfigurationsdateien).

Der durchschnittliche Rechner der Entwickler benötigt für das Erstellen eines Builds eine knappe halbe Stunde (mit Virenscanner über zweieinhalb Stunden).

In dieser Zeit können die Entwickler zumindest nicht programmieren, häufig nicht einmal mehr E-Mails lesen, weshalb der Arbeitsalltag so ausgerichtet ist, dass vollständige Builds zum einen vermieden und zum anderen auf den Morgen (Rechnerstart – Zeit für einen Kaffee) und die Mittagspause verlegt werden.

Im Team wird verteilt gearbeitet und regelmäßig integriert (d.h., Entwickler, die an Modul A arbeiten, stellen ihre Änderungen zur Verfügung, Entwickler, die an Modul B arbeiten, holen sich die aktualisierten Quelltexte von der Versionsverwaltung, was häufiger zur Folge hat, dass ein vollständiges Build erzeugt werden muss), wodurch zwei vollständige Builds am Tag die Regel sind.

Gehen wir vorsichtig von einem Durchschnittsgehalt von 60 T EUR für einen Entwickler mit mehr als sechs Jahren Berufserfahrung aus, ergeben sich folgende Kosten (Berechnungsgrundlage 223 Arbeitstage: 365 Kalendertage abzügl. Wochenenden (104 Tage), Feiertage (8 Tage) und Urlaub (30 Tage), 40-Stundenwoche):

Stundensatz
60.000 / 223 / 8 = 33,62 EUR

Auf zwei Builds zu je einer knappen halben Stunde am Tag bezogen bedeutete dies im ungünstigsten Fall (die Entwickler warten einfach nur, während das Build erstellt wird und sind ansonsten nicht weiter produktiv) jährliche Kosten von

223 x 33,62 EUR = 7.497,26 EUR pro Entwickler und

16 x 7.497,26 EUR = 119.956,16 EUR für das aus sechzehn Personen bestehende Team.

Die Verdopplung des Arbeitsspeichers und der Einbau schnellerer Festplatten bewirkte, dass ein vollständiges Build in gut 15 Minuten erstellt werden konnte.

Vergleicht man die Kosten für die Aufrüstung pro PC (450,- EUR für die Hardware, etwa 150,- EUR Personalkosten [Einbau durch Supporttechniker, Procurement] ) sieht man sofort, dass sich selbst bei einem geringeren Produktivitätsausfall als 100 % eine Investition in bessere Hardware schnell amortisiert:

Ersparnis rein rechnerisch:
119.956,16 EUR / 2* = 59978,08 EUR abzüglich 9.600,- EUR Hardwarekosten = 50.378,08 EUR

*Halbierung der Kompilierzeit

(Aufs Jahr bezogen wird somit eine Aufrüstung rentabel, sobald die festgestellte Produktivitätseinbuße bei über 8% liegt, was in jedem Fall gegeben ist.).

Weiterhin ist interessant, dass dieselben Rechner auch allen extenen Beratern zur Verfügung gestellt wurden. Deren Stundensatz lag dabei weitaus höher, wodurch sich die Investition noch schneller amortisierte.

Positive Seiteneffekte des Einsatzes leistungsfähigerer Entwicklerrechner sind zudem verbessertes Time-To-Market (offensichtlich) sowie ein besseres Betriebsklima (lange Buildzeiten frustrieren Entwickler, schnelle Rechner hingegen erfreuen sie).

Vielen Probleme damit führten dazu, standardmäßig Disable Workspace Resolution und Disable Nested Modules zu wählen.

Das macht aber das Debuggen schwierig: Beim Debuggen möchte man beim Debuggen direkt in den Quellcode der mit der Startanwendung verbundenen Modulprojekte springen.

Defaultmäßig ist das nicht möglich, vielmehr wird die .class-Datei im Editor angezeigt. Hier hilft auch nicht, den Ort des Source-Codes in den Maven-Abhängigkeiten manuell mitzuteilen.

Verlinkte Quellordner (siehe linked resources) helfen hier nicht.

Lösung
In den Debug-Einstellungen als Quellordner die Modulprojekte angeben über Debug->Open Debug Dialog->Source.

Tip
Wenns beim Debuggen von WTP-Projekten dennoch nicht funktioniert, daran denken, den Server im Debug-Modus zu starten

Im Vergleich zu den großen kommerziellen Java-Konferenzen (in Deutschland die JAX, US-international die Java One) nimmt sich die berlin.jar bescheiden aus:

Alle Besucher (zumindest, die mit denen ich sprach) wurden von Ralph Bergmann persönlich begrüßt.

Nett.

Jedenfalls etwas ganz anderes als die spektakulären Bühnenbegrüßungen von Sebastian Meyen, der ansonsten auf der JAX stets recht arrogant/gestresst agiert, wenn man sich nicht durch Anzug oder Speaker-T-Shirt ausweisen kann.

An zwei Tagen werden Samstags vier Vorträge in fünf Tracks angeboten, am Sonntag drei. Daneben können Samstags noch Workshops besucht werden (v.a. Eclipse RCP und Tomcat 6).

Die Konferenz findet – naheliegend – in den Räumen der FHTW Berlin in der Treskowallee statt. Menschen von der User Group und offenbar auch Studenten (?) unterstützen die Veranstaltung, ein einem Gang sind drei Stände aufgebaut.

Essen wird an Grill und Suppenküche ausgegeben, leider alles nicht ganz mit den Veranstaltungszeiten koordiniert. Für die erste Veranstaltung dieser Art, zudem nichtkommerziell, ist das akzeptabel.

Was macht aber eine Konferenz wertvoll? Natürlich die mobile Massage in der Relax-Lounge! Mögen manche sagen. Andere finden eher die Qualität der Vorträge entscheidend. Hier braucht sich die berlin.jar nicht zu verstecken: Von Oliver Böhm über Peter Roßbach (!Tomcat Workshop!) zu Eberhard Wolff sind viele Größen der deutschen Java-Community vertreten. Die Qualität der von mir besuchten Vorträge braucht sich zumindest hinter denen der Vorträge auf der JAX nicht zu verstecken.

Alles in allem eine lohnende Veranstaltung, für den lächerlich niedrigen Eintrittspreis (15,- EUR im Vorverkauf, Verköstigung inklusive) bekommt im Vergleich zu den kommerziellen Veranstaltungen ein Vielfaches als Gegenwert.

Dieses Angebot nutzten am ersten Tag nach meiner Einschätzung (Mittagessen und "Abendparty") mehr als 100, aber sicherlich weniger als 250 Teilnehmer, davon etwa 3% Frauen (leider nicht eine einzige Vortragende, sehr schade, dass Angelika Langer nicht anwesend war).

Hochachtung verdient Ralph Bergmann und seinen Helfern für den Einsatz, der weitaus mehr von einer Begeisterung für die Technologie spricht als von reinem Profilierungsdrang. Dazu wurde zuviel gelächelt.

Softwareentwicklung mit agilen Methoden, Java EE (JEE), J2EE, Java2EE, Java, Ruby, Linux, JSF, Spring, Hibernate, SCALA, JBoss Seam, Maven, Apache Software Foundation, Eclipse, Eclipse RCP, NetBeans, Rules Engines, Middleware, SOA, BPM, ITIL, TOGAF, Zachman, Lean Management, IT-Strategie, Neue Musik, Klassische Musik, Musizieren, Klavier, Klarinette, Literatur (speziell Lyrik), Literatur, Bildende Künste, Kunst, Kulturgeschichte, Kunstgeschichte, Berlin, London, Venedig, Paris, Florenz, Rechtsinformatik, Italien, Großbritannien, English Literature, English Verse. Werke u.a. folgender Personen: Fowler, Tiepolo, Eisenstein, Braudel, Schnitzler, Ligeti, Knuth, Pushkin, Satie, Bellini, Monteverdi, Adams, Veronese, Shelley, Brecht, Dowson, Brahms, Montaigne, Schumann, Kubrick, Rameau, Bartok, Huizinga, Mahler, v. Bingen, Lenau, Frisch, Lenz, Olbrisch, Brunelleschi, Lichtenberg, Turner, Günther, Trakl, Scelsi, Redon, Streeruwitz, Flaubert, Friedell, Naso, Wilde, Bernhard, Erasmus, Gernhardt, Klimt, Palladio, Rückert, Härtling, Flaccus, v.d. Weyden, Balthus, Reynaldo Hahn, Caroll, Borodin, Verlaine, Mörike, Schobert, Villon, Greenaway, Heym, Thelen, Watteau, Abschatz, Jelinek, Bach (4x), Huysmans, Schiele, Ravel, Walser, V. Klemperer, Augustinus, Kling, Mann (2x), Gombrich, Stroustrup, Auster, Brüder Limburg, Franck, Purcell, Fellini, Truffaut, Hofmannsthal, Pollock, Schubert, Bresdins, Ariès/Duby, Bulgakow, Lenz, Proust, Neruda, de Beauvoir, Brouwer, Fragonard, Degas, Kurtag, Zelenka, Pepys, Rimbaud, Giorgione, Bachmann, Vian, Wilder, Wilmot/Rochester, Brinkmann, Callot, Opitz, Couperin, Ockeghem, Giacometti, Celan, Klinger, Catull, Sterne. Laufen, Laufsport, Joggen, Marathon.

Diese hatte ich schon vor längerer Zeit einmal zusammengekramt, um einer schmerzhaft Geliebten zu erkennen zu geben, ich wäre der richtige für sie, allein meiner Interessen wegen. (Magisches Denken, Zaubersprüche der Kindheit, nur transzendiert.).

Tatsächlich erkannte ich nach einer Weile, dass diese Frau sich weder für mich noch für wenigstens 10% der aufgeführten “Inhalte” hinter den Namen interessierte.

Wär mir letzteres wiederum von Anfang an bekannt gewesen, hätte ich gar nicht damit begonnen, ihr nichtvorhandene Gemeinsamkeiten zu unterstellen (Gegengeschlechtlichkeit ist ja wirklich keine Gemeinsamkeit.).

Und auch kein ernsthaftes Interesse für sie entwickelt.

Das wirft bei mir die Frage auf, ob es nicht irgendeinen Social-Web-Dienst gibt, bei dem man solche Informationen nicht hinterlegen kann, um eine “Interest Map” zu erstellen, die man dann mit der anderer Nutzer vergleichen kann. Auf diese Weise könnte man eine Sozial-DNA erstellen, und Menschen finden, die ähnliche Interessen haben / Ziele verfolgen.

Am besten noch mobil die Sozial-DNA gegeneinander abgleichen können. Und das noch für berufliche Profile und private. Und eine “Heat Map”, die anzeigt, wo sich im Raum die Leute befinden, mit denen man zumindest die Interessen teilt. Etc. Etc. (z.B. mit sozioökonomischen und politischen Kriterien).

Datenschutz wäre da ein noch sensibleres Thema als bei den gängigen “Social Tools”. Mir erschiene so etwas jedenfalls sinnvoller als die ganzen “Legacy DNA” Startups wie Navigenics etc., die einem alles und nichts zu der eigenen DNA mitteilen. Die Möglichkeit, die “Social DNA” (die keinen Status ausdrückt, sondern mikroindividuelle Differenzierung) verändern zu können, ist hier entscheidend: Jeder Mensch hat ja die Möglichkeit, sein Profil zu verändern. Ggf. sollte man sogar von vornherein angeben können, in welche Richtung man sich entwickeln möchte, was man nicht kennt, aber kennen möchte etc.

Konkreter sollte das ganze so gestaltet sein, dass für den Grunddatenbestand eine Anzahl von etwa 100 unterschiedlichen “Leads” (Schlüsselpersonen) ihre inhaltlichen, kulturellen, religiösen, sportlichen, politischen Interessen und Kenntnisse, Ziele und Vorlieben mitteilen, am besten über eine Liste von Stichwörtern wie oben dargestellt.

Diese wird dann geparst, bestehenden Schlüsselobjekten und semantisch zugeordnet. Danach erfolgt dann eine Auswertung / Neuindexierung der ermittelten Objekte durch die Nutzer. Sind die Schlüsselbobjekte zugeordnet, werden sie bewertet: Bei “Werken”, Künstlerinnen, Musikstücken (kristalline Intelligenz) vor allem nach Vorlieben (mag ich / mag nicht / mir unbekannt), bei konzeptionellen Schlüsselobjekten (fluider Intelligenz) auch nach Fähigkeit (verstehe/kann ich, verstehe/kann ich nicht / mir unbekannt).

Dieser Grunddatenbestand kann dann von anderen übernommen und weiter angepasst werden.

Das ganze mit der Möglichkeit, sich mit anderen Nutzern “zu verbinden”, von ihnen Objekte zu übernehmen und für sich selbst zu bewerten, zu suchen und sich finden zu lassen und sich eine Timeline anzeigen zu lassen, aus der man später ermitteln kann, wie sich die eigene Social DNA verändert hat.

Falls jemand einen solchen Dienst kennt, wär ich für einen Hinweis sehr dankbar

Hm, wenn das wirklich stimmen sollte, hat Adobe noch schlechtere Karten (bei mir). Wie auch Marten wusste, ist zwar Ende März eine Linux-Alpha Version erschienen, aber nur für x86er-Systeme. Kein Wunder, dass sich Sun wegen JavaFX noch freut. Wäre nur schön, wenn das a) produktionsreif und b) auch mit Eclipse-Unterstützung erschiene (sonst machts Genuitec und bindet den noch nicht vorhandenen visuellen Editor wie Matisse in MyEclipse ein).

Ein Tip: Installiert man das mittlerweile stark ausgereifte m2 Maven-Plugin von Codehaus, findet man weitere sehr nützliche Hinweise in der Eclipse-Hilfe, die den gesamten "Definite Guide" integriert, mit Suchfunktion.

Die letzten Versionen des Plugins wären eigentlich einen eigenen Eintrag wert: Es kommt jetzt mit einem schon ansprechenden POM-Editor daher, der an die Editoren für die Eclipse-RCP-Entwicklung erinnert (etc. etc. etc., WTP-Unterstützung ist im Codehaus-Wiki beschrieben), aber Achtung: Die Eclipse-Update-URL hat sich geändert zu http://m2eclipse.sonatype.org/update/ resp. http://m2eclipse.sonatype.org/update-dev !

Test umgehen

An der Kommandozeile:

In der pom.xml:

<plugins>     
<!-- ...weitere Plugins... -->
  <plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
    <skip>true</skip>
    </configuration>
  </plugin>
</plugins>

Fremdes Archiv in lokales Repository deployen

Kommt insb. vor, wenn man kommerzielle Archive, die nicht öffentlich verfügbar sind, in sein lokales Repository übernehmen möchte. Oder irgendwelche obskuren Legacy-jars, die mit Ant gebaut werden )))

Man benötigt eine rudimentäre pom-Datei, Teil-Struktur ggf. von http://www.mvnrepository.com/ holen.

Hier ein POM fürs Substance L&F:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.jvnet</groupId>
  <artifactId>substance</artifactId>
  <version>4.3.11</version>
  <packaging>jar</packaging>
  <name>Substance Look and Feel</name>
  <url>https://substance.dev.java.net/</url>
  <description>Private deplomyent, not from Sun!</description>
  <dependencies />
</project>

Jetzt an der Kommandozeile in das Verzeichnis wechseln, in dem sich jar und Dummy-POM-Datei befinden und deployen (diesmal fürs jnlp-Servlet):

mvn deploy:deploy-file -Dfile=jnlp-servlet-1.0.jar -DpomFile=openswing-jnlp-servlet.pom -DrepositoryId=release -Durl=http://10.45.7.7:7575/archiva/repository/internal -e

Wirksame Konfiguration anzeigen

mvn help:effective-pom (Siehe die nützlichen weiteren Features hier).

War erstellen

In pom.xml (Unterelement von <project>):

<packaging>war</packaging>

Ggf. das Maven-War-Plugin verwenden und <exclusion> für JEE-Bibliotheken.

Zum Bauen

mvn package

Build ausführen (sic)

mvn compile / mvn package

(Und den "Definite Guide" lesen, um das Konzept zu verstehen <kicher>).

JDK festlegen (zum Kopieren)

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.0.2</version>
    <configuration>
        <source>1.6</source><!-- oder 1.4 oder 1.5 etc.-->
        <target>1.6</target><!-- oder 1.4 oder 1.5 etc.-->
    </configuration>
</plugin>

(Fortsetzung folgt…)

Abhilfe schafft, über Windows->Preferences->Validation den jeweiligen Button in der Spalte Settings zu wählen und dann einen Validator-Typen zu wählen, danach ggf. noch Project->Clean.

Hinweis für Eclipse: Deselektiert man über Windows->Preferences->Validation eine Validierung komplett und sollte eine Datei bereits als invalid markiert sein, hilft, erneut Validate im Kontextmenü des Eintrags im Project-/Package-Explorer/Navigator zu wählen (geht mit Clean nicht weg).

-Djavax.xml.transform.TransformerFactory=com.icl.saxon.TransformerFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl-Dorg.xml.parsers.sax.parser=org.apache.xerces.parsers.SAXParser 

Siehe dazu auch nur Xerces als Default-Parser setzen. 

Daher wäre ein Eclipse-Plugin, etwa für DocBook-Dokumentation nützlich, wo man für <programlisting>-Tags auf einen Code-Ausschnitt verweisen könnte, den man direkt aus der "lebenden Klasse" nehmen könnte.

        <buildCommand>            <name>org.eclipse.jdt.core.javabuilder</name>            <arguments>            </arguments>        </buildCommand> 

einfügen (direkt via Eclipse, im geöffneten Projekt funktioniert). 

Über S.H.: von Struts über JSF, Spring MVC zu Grails. Erstellt Grails Podcast.

Motivation

Framework wie Rails – Convention over Configuration, DRY

Spring MVC im Hintergrund

Grails vs. Rails Benchmark – Skaliert weitaus besser als Rails. 1.0 Release im Sommer, 0.5 im Mai.

grails clean

grails update

zum Update, soll schmerzlos sein.

Benutzte Frameworks

Spring: Spring DI + Spring MVC

Hibernate

SiteMesh – Layouting

Java EE – Integration

Standalone oder Hib-Mappings f Legacy-Schemata; EJB3-Integration; vorhandene Spring-Beans können verwendet werden.

Quickstart siehe am besten hier.

ApplicationBootStrap zum Persistieren.

TL-Erzeugung. Zur Laufzeit deploybar, ebenso mit Controller + Service.

Server-Start runApp.groovy. snipplr.com

MVC in Grails

Model: Domain-Klassen etc.

class Podcast {

String title

String feedUrl

}

View: Groovy SP oder JSP; dynamic TagLibs

Controller: Grails Controller + Grails Service

Object-Relational Mapping GORM. Equals()/hashCode() werden automatisch + dynamisch erstellt.

grails create-domain-class

Mapping 1:1

class Podcast {
Author author
String title
}

Mapping 1:n

class Podcast {
def hasMany = [ episodes : Episode ]
String title
}

Mapping m:n

class Podcast {
def hasMany = [ episodes : Episode ]
String title
}

class Author
{
def hasMany = [ podcasts : Podcasts ]
}

GORM: Dynamic Finders

Podcast.findByTitle(), QBE + HQL unterstützt.

Constraints

class Podcast {
String title
String feedUrl
static constraints = {
title(size:1..50)
feedUrl(unique:true)
}
}

GORM DB Konfiguration

development/production/test

Classe Development[...]DataSource ändern. Standard: Development.

View-Technologien

Die meisten verwenden GSP wg. der Dynamic Tag Libs.

Grails Controller

Generierbar (mit CRUD), wird dynamisch geladen. Immer alle CRUD-Operationen werden erstellt, DELETE kann z.B. nicht ausgeschlossen werden. Controller und Views müssen entsprechend manuell angepasst werden.

Parameter, Session, Flash-Objekte.

render()-Methode sehr mächtig – AJAX

HTTP-MEthod-Restrictions.

Dynamisches Scaffolding

im Bsp.: def scaffold= Podcast

Services

Kapselung von Business-Logik.

Buchempfehlung Getting Started with Grails (InnoQ)

]]> http://blog.gresch.de/2007/04/26/jax-2007-grails-rapid-web-application-development-sven-haiges-actionality/feed/ 0 http://blog.gresch.de/2007/04/24/jax-2007-keynote-from-eclipse-to-jazz-erich-gamma/ http://blog.gresch.de/2007/04/24/jax-2007-keynote-from-eclipse-to-jazz-erich-gamma/#comments Tue, 24 Apr 2007 17:30:54 +0000 KG http://web636.webbox122.server-home.org/wpkg/?p=173 Learning, describing, tooling "The Eclipse way".

From closed to open – not only regarding OS, but also direct interaction with the dev team.

Project gives community and vice versa. "Village Effect" create accountability without blaming others. Transparency – who does what. Continuity (?) => continuous health.

Mindmap of Eclipse practices ###get###

Organizational Patterns of Agile SW Dev / Coplien ###get###

Bugzilla Pivotgraph demo.

EPF examples. Bottom-down-and-up-collaboration;

Process/practice awareness: Instead of writing documentation help on the tool level.First products 2 b released in 2008. "Open commercial" software – seems that Jazz’ll be fully commercial (hm, maybe as commercial as EPF is considering the "RUP composer").

Jazz overview. Team first – codesharing.

KG’s summary

Finally we can see something – after a long time of waiting (since http://portal.acm.org/citation.cfm?id=965670&coll=portal&dl=ACM&CFID=21208174&CFTOKEN=43773194 I’m eager to see more) there’s a clear concept. If I understood it correctly, the tool-suite shall only be released commercially

I hope this can be understood in the sense of never giving Eclipse for free or the RUP composer… I assume, there’ll be connectors to Lotus or Rational stuff – hope this’ll be a separate commercial part.

The vision I understood was this: One can design a collaborative process within EPF and apply it to Jazz-enabled IDEs in the way that it ensures that the developers stick to the process. This would work – plain documentation not.

]]> http://blog.gresch.de/2007/04/24/jax-2007-keynote-from-eclipse-to-jazz-erich-gamma/feed/ 0 http://blog.gresch.de/2007/04/24/jax-2007-mylar-the-task-focused-ui-mik-kersten-mylar-lead/ http://blog.gresch.de/2007/04/24/jax-2007-mylar-the-task-focused-ui-mik-kersten-mylar-lead/#comments Tue, 24 Apr 2007 09:58:27 +0000 KG http://web636.webbox122.server-home.org/wpkg/?p=170 Objective/Background

Eclipse overloaded with information. E.g. Package Explorer in normal projects.
Context loss when multi-tasking. No integration with IDE workflow.

Demo

Eclipse "empty" except of task view. Hyperlinking also to sourcecode (### – need to check).
Search view – (### try with Trac).
Search for Duplicates when submitting a bug based on stack trace.

Collaboration

Template for commit messages. Mylar-teamrule: Never write your own commit message.

### Eclipse UI for only searching and submitting. ###

Planning

Focus on work week;

Schedule

2.0 June 29th (with Europa)

Background

Decrease-of-interest model. Both direct and indirect. Landmark/Interesting/Uninteresting.

Framework

Four different APIs. Look the docs.

Integration

Xplanner-Connector. IssueZilla; Rally Software; Code Beamer; DLTK Structure Bridge (supporting );

Tasktop-Demo

Task-based work also for office work. Unfortunately focussed on MS Office (and therefor MS Windows).

Default-Browser = Eclipse;

Solution: Try to point to Xerces, e.g. by using a system var or remove suspicious jars, e.g. gnujaxp.jar from your classpath.

(Asked by a colleague today).

A better error message would be useful, must check how the behaviour is in Axis2.

1. Programm mit -XX:+HeapDumpOnOutOfMemoryError aufrufen, um eine HeapDump-Datei zu erstellen.
2. Jetzt mit jhat -J-mx768m [HeapDump-Datei, z.B. java_pid804.hprof] die Datei analysieren lassen. Wie auch bei den "integrierten" WebServices wird dabei ein interner Http-Server gestartet, der grundsätzlich auf Port 7000 lauscht.
3. Jetzt über http://localhost:7000 analysieren… OQL wird auch unterstützt.

Gefällt mit besser als das frustrierende Geraffel mit der Eclipse TPTP, auch wenn diese schönere Icons vorweisen kann. Die Lösung aus dem JDK scheint mir einfacher, stabiler und vor allem funktionaler zu sein. (Der TPTP-Agent selbst muss z.B. derzeit unter 1.4 laufen, das soll man einmal wissen).

Der Autor ist, als Spring-"Committer" neben Jürgen Höller der einzige native Deutschsprachler im Team und aufgrund seiner Autorentätigkeit beim Java-Magazin sowie seiner freundlich-intelligenten Vortragsart bei Konferenzen vorzüglich geeignet, ein Buch über Spring zu verfassen. Das Buch behandelt, dem Inhaltsverzeichnis folgend, so ziemlich alle Bereiche:

Von den Grundkonzepten (DI, AOP) über Persistenz zu JAAS, MVC bis hin zu Spring.NET. Da drängt sich einem der Eindruck auf: Das kann man unmöglich auf gut dreihundert Seiten behandeln!

Tatsächlich wird der Text sich für jemanden, der noch nicht mit Spring gearbeitet hat, so hermetisch darstellen, dass er ohne gleichzeitiges Nachvollziehen mit einem Beispielprojekt hoffnungslos verloren sein dürfte. Das stellt sich die Frage, ob vielleicht mehr Informationen über die Codebeispiele zu erhalten sind. Aber hier fangen die Probleme an:

Eberhard Wolff stellt ein Eclipse-Projekt zur Verfügung, das auf User-Libraries basiert, deren Inhalt aber nirgends erwähnt ist. Eine ant.properties-Datei, die in der einzigen Hilfestellung, LiesMich.txt, aufgeführt ist, geht fehl, da die build.xml auf einen anderen Pfad verweist als die eigentlich zu verwendende Variable xdoclet.home aus der Property-Datei. Das ist sehr lieblos gemacht und Wolff ebenso wie seinem Lektor vorzuwerfen, die offenbar gar nicht versucht haben, die Konfiguration einmal auf einem frischen System auszuprobieren.

Allein der Umstand, dass nicht erwähnt wird, mit welchem JDK (grundsätzlich eher 1.4, aber wohl auch Tiger), welcher Version von JBoss oder Tomcat oder JUnit gearbeitet wird und wie, ist einfach mangelhaft – im Arbeitsalltag wollte man nicht auf diese Weise in ein Projekt eingeführt werden. Aber da hätte man den Trost, dafür bezahlt zu werden.

Diesen Trost hat man hier nicht. Im Gegenteil.

Ich habe immer mehr den Eindruck, viele der IT-Bücher werden nur noch verfasst, um den Autoren die Möglichkeit zu geben, sich zu profilieren, nicht aber: Um Wissen weiterzugeben.

Dass es anders ginge, beweist ja gerade AppFuse von Matt Raible, das ja auf dem Buch Spring Live weitgehend basiert. Und in der Version 2 von AppFuse macht Raible auch vor, wie das aussehen kann: Einfach mit Maven sich das Projekt holen, konfigurieren – fertig! Selbst wenn Eberhard Wolff sich diese Mühe nicht machen wollte (und die Bandbreite für ein Maven Repository nicht zur Verfügung stand) – ein "Out-of-the-Box" Projekt für Eclipse wäre doch sicherlich zu erwarten gewesen, immerhin kostet Wolffs Buch 36,- EUR, das ist zu teuer, als dass man auch noch Stunden mit dem Einrichten des Beispielprojekts verbringen muss.

Oder wenigstens *.userlibraries-Dateien zum Importieren/Nachvollziehen anbieten… oder ggf. die SpringIDE erwähnen, wenn er von dieser ausgehen sollte. Dieses Buch scheint mir nur für Schulungen geeignet, in denen E. Wolff ein "Hands-On-Training" durchführt und den Anwesenden das Buch als Vademecum überreicht.

One workaround is to remove the XML jars.