langreiter.com plain, simple: comments-2002-03-10

LANGREITER.COM plain, simple

START

INDEX

Sonntag, 10. März 2002

Es scheint vollbracht.

2002-03-10-mozDone

Mit Flash MX werden wohl so manche Karten neu gemischt werden ... soll der Schritt zu der Rich-Client-Plattform aber gelingen, so wird Macromedia nicht umhinkommen, den Developer-Support auf ein mittlerweile wohl übliches Niveau (MSDN etc.) zu heben — sich nur auf Grassroots-Efforts zu verlassen wird in Zukunft definitiv nicht mehr reichen.

www.devx.com/webdev/reviews/FlashMX/ib030402-1.asp

2002-03-10-fMXPlatform

"Whilst writing the EJB modules for our [create JGenerator] product, we started punting an email back and forth containing all the issues we had with EJB. And there were many. Before we knew it we ended up with 101 howlers." [ Ø EIGENHEADS • ]

"37. Development is very slow. For example, the development cycle is tens of minutes, rather than seconds, simply to change a small value in a JSP. This is a huge project killer. Increased development time hardly helps with 'Internet time' projects."

Das ist wahrscheinlich mein Hauptkritikpunkt — ein Environment mag nicht sehr konsistent, von mir aus riesig (IDEA cuts through anyway) und nicht besonders gut spezifiziert sein — mit alldem wird man zur Not fertig, ständig im Sumpf zu waten macht aber jeden Spass am Entwickeln zunichte. JSPs as such sind schon schlimm genug, müssen dank Änderungen in dahinterliegenden Klassen Kontexte reinitialisiert oder gar Server neugestartet werden, jedes Mal den Weg Repackaging und Redeployment zu gehen macht Bottom-Up-Entwicklung schliesslich völlig unmöglich.

"[C]ode generation is an increasingly important aspect of EJB design and development as it removes the drudgery of churning out endless beans to the same design pattern."

Wird erst Code Generation notwendig, um effizient arbeiten zu können, kann man sich sicher sein, dass die Abstraktionen eines Systems die richtigen nicht sind. EJB scheint für Code-Monkey-Armeen und Offshore-Shops gedacht zu sein, für smarte Entwickler nur bedingt.

"You can only abstract from the concrete, yet Sun engineers again and again try to abstract from their imaginings, guessing what might be cool, or pure, as opposed to what people need. What's the point of writing software to meet future needs if it won't even meet your current ones?"

2002-03-10-101damnEjbs

"[T]he [create Delphi Component Model] was used as the starting point for [create JavaBeans] as Sun and Borland collaborated on its development."

2002-03-10-beanOrigins

gavin 8276 days AGO
When I think of EJBs, I think of Richard P. Gabriel's book, Patterns of Software. He asks, "What is quality software?" and provides a nice list of guidelines. A few favorites:
- If I look at any small part of it, I can see what is going on--I don't need to refer to other parts to understand what something is doing; this tells me that the abstractions make sense for themselves--they are whole.
- If I look at any large part in overview, I can see what is going on--I don't need to see all the details to get it.
- I am not afraid of it, I will remember it.

funzel 8276 days AGO
Die 101 EJB Damnations sind zum grossen Teil Mist, weil sie die Ansichten der Entwickler wiederspiegeln, nicht aber die Ziele von EJBs. Das Hauptproblem ist, dass Leute EJBs fuer viel zu kleine Aufgabe verwenden, wo sie nie und nimmer noetig waeren.

Schlichtweg falsch sind andere Liegen. Wir haben zZ mit etwa 500 EJB/Servlet Klassen einen turn around auf schlechter Hardware (+ mehrere Entwickler gleichzeitig) von ca 60sec, ein bisschen zu lang fuer meinen Geschmack, aber weit von den
"tens of minutes" weg. Servlet deployen geht noch schneller.

Mein einziges wirkliches Problem mit EJB ist, dass die "concerns" eines beans nicht ausreichend getrennt wurden. Aspektweise haette man Distributed Objects, Persistency, Transactions, Security etc. auseinandernehmen koennen und dann in der Anwendung zusammenweben koennen, anstatt alles monolithisch in ein Bean zu stecken.

Ein Absatz der eigentlich alles ueber die Autoren erklaert:
"40. Many sites do not need EJB complexity, yet people use EJB for the sake of fashion, or getting skills on their CV. Too many people are happy to sacrifice the future of their company/project, in order to get 'sexy' skills."

Was hat das mit SUN und mit EJBs zu tun ?

Please log in (you may want to register first) to post comments!