I would like to try Adobes products, because:

• It's the easiest to use RIA platform for developer.
• The browser runtime(Flash Player) works much better than competition. In fact for years without big problems. In contrast yesterday the Java6u13-VM didn't start while entering a site with an applet, although the VM is stable enough for BIG, BIG servers.
• Mature runtimes are available for all platforms. (Windows, Mac, Solaris, Linux, 64bitLinux!). Valid for Java, too. But not for MS GreyShadow.

However there are some major problems for me:

• There is no Flex Builder for Linux. End of story :)
• It's a proprietary plattform. No standards that I'm aware of and closed runtime software. That hinders innovation. It's a pain for developers in the long run to work with a black box. Think about the Java VM. Nowadays we like to run Scala, Ruby, Python, and Clojure on it. It can run directly on a virtualization hypervisor (JRockit). It runs in little different flavours on small mobile devices (Android). If there is a problem, we can check the code.
• Who needs an open source SDK if the runtime is closed?

I will have a look when
Adobe releases a Flex Builder for Linux
and?/or?
Adobe opens the sources/standardizes the VM.


Update: Someone else has the same opinion: Mike Slinn: Flash Builder, Linux and Winning the RIA War

Best Quotes for me from "Secrects fo the Rock Star Programmers: Riding the IT Crest" by Ed Burns.

Kosuke Kawaguchi
"...the way I get myself motivated is by having users."

Herb Schildt
"All systems of knowledge are hierachical. They all have entry points, and they all have logical patterns of flow that allow you to move from one concept to another. In other words, systems of knowledge can be thought of as having a tree structure. To learn something, you must simply move from branch to branch, node to node. The troube is that sometimes it's not easy to see the structure. This is where a good teacher comes in. A good theater organizes the topic so that it reflects its hierachical structure."

Floyd Marinescu
"...I think we'll go through a phase of domain-specific languages first, where the language itself is a rising abstraction, before we eventually get to the point where we're actually using model tools. It could be 10 to 15 years out"

"If your heart's not in it, then it's time for a change. I've been in situations where I was making more money than I knew what to do with, but I just wasn't happy there. I couldn't motivate myself. Once I switched my job, I was quite the happiest and it was worth making less money to have a better life."

Andy Hunt
"The best place to look for where a bug might be is quite near the last one you found"

A lot of people say, "What's the best thing I can do to enhance my code?" and I say, "Take a big magnet to the hard drive".


Dave Thomas
''My opinion is that everything from high performance financial processing to computer games can actually be expressed fairly elegantly as CRUD programming``

''The major challenge for an innovation ... is to keep the idea alive until the opportunity becomes available"

''So the key thing for a new technology is to find a ninche where it can grow and where people will pay for it. The it can be a healty, stable business.

"If you need complicated tools, then perhaps the technologies you're using are the wrong ones.''

require 'java'
require '/opt/qtjambi/qtjambi-4.4.3_01.jar'
require '/opt/qtjambi/qtjambi-linux32-gcc-4.4.3_01.jar'

module Gui
include_package "com.trolltech.qt.gui"
end

app = Gui::QApplication.new([""].to_java(:String))
button = Gui::QPushButton.new("Hello")
button.show
button.clicked.connect(app, "aboutQt()")
Gui::QApplication.exec

Der schöne J2EE Standard. EJB2 mit XDoclet-Generierung erzeugt einfach zuviel Code. Generierter Code ist mir unsympathisch. EJB3 ist ein wahrer Segen in dieser Hinsicht. Lass es Frühling werden. Enterprise-Features schön und gut, aber sie sollen nicht die Implementierung der eigentlichen Logik soo mühsam machen.

Swing
Schaut grauslich aus (sogar mir Java6/JGoodies) und ist trotz bester Absicht auch grauslich zum Programmieren. Na gut, mit Java als Sprache auch nicht so leicht realisierbar.

JSF
Sehr mühsam um eine paar HTML-Seiten zu erstellen.

• JSP-Seite = HTML + JSP-Tags
• BackingBean = Java-Klassen
• JSF und Servlet Konfigurationen=XML

Gleich 3 Sachen auf einmal. Nur leider ohne Schokolade und auf die Spannung, ob es funktioniert kann ich verzichten. Ok, spielen kann man damit.

Log4J war die erste Bibliothek, die ich sofort in mein Herz geschlossen habe. Einfach die Bibliothek in den Classpath geben und verwenden. Die Loglevels sind fast selbsterklärend, das Ausgabeformat und das Ziel kann nachher noch nach Belieben geändert werden und für die Entwicklungszeit gibt es auch eine vernünftige Standardkonfiguration.

Inzwischen gibt es mehrere Alternativen wie z. B. java.util.logging.
Anstelle von den klar verständlichen Logleveln gibt es aber
FINE, FINER, FINEST, INFO, WARNING, SEVERE und auch noch CONFIG? Einfach alles auf Console ausgeben scheint auch nicht via Einzeiler machbar zu sein.
Das Ausgabeformat richtig anzupassen, habe ich mich glücklicherweise noch nicht beschäftigen müssen. Log4j ist auf jeden Fall sehr flexibel und gern benutzt, auch wenn die Konfiguration mittels Datei im Classpath Kopfzerbrechen bereiten kann.

Ich mag J2EE Application Server nicht :(

Spring Dynamic Modules for OSGI Service Platforms ist cool. Damit läßt sich sehr einfach eine serviceorientierte Architektur innerhalb eines OSGI Container in einer Java Virtual Machine aufbauen.

Einfach eine Spring Bean schreiben und als OSGI Service veröffentlichen mittels XML Datei
/META-INF/spring/bundle-context.xml

< bean name="ExportedBean" class="export.ExportBean" / >
< osgi:service id="osgiExportedService" ref="ExportedBean" interface="service.MyService" / >

Die Verwendung ist ebenfalls sehr einfach. In der selben Datei (natürlich in anderem Bundle) diesen Code einfügen:

< osgi:reference id="osgiImportedService" interface="service.MyService" / >
< bean name="UsingServiceBean" class="import.ImportBean">
< property name="service" ref="osgiImportedService" / >
< /bean>

Schon wird das Service über die Methode setService(service.MyService) in die Bean injeziert.
Wenn alles so einfach wäre. Der Web-Extender-Mechanismus für WAR Projekte macht mir das schon mehr Kopfzerbrechen.

Niemals e.printStackTrace() verwenden, sondern immer einen Logger verwenden. Derzeit ist wohl Simple Logging Fascade for Java am besten dafür geeignet.
Niemals direkt Texte ausgeben. Immer auf Internationalisierung mittels ResourceBundles achten.

Anforderungen an moderne Software-Entwicklung:

Sourcecode-Management: Subversion. Update: 2009 -> eindeuting Git :)
Build-Tool:Maven
Verwendung eines InversionOfControl-Containers: Ohne solchen ist Code einfach schwer testbar. Natürlich mit dem Spring Framework oder auch Guice
Verwendung eines Komponentensystem: OSGI. Equinox, wenn ein Eclipse-Subprojekt integriert wird.
ContinousIntegration: Ein Build sollte zumindest täglich durchgeführt werden. Vielleicht Hudson? Habe ich noch nicht verwendet.
IssueTracker braucht es irgendwann auch. Muss es Bugzilla sein oder doch eher Trac? Auf jeden Fall sollte es einen Mylyn-Connector geben.

Nice to have:
Agile Entwicklung mit PairProgramming und TestFirst-Ansatz.