You cited that you know of teams of 30+ developers using Cairngorm on projects today, implying that there are multiple Flex projects with these characteristics. I was curious if those projects have resulted in production (released) software, and if the companies could be publicly cited?
My experience in the Java/J2EE world was miserable when teams bloomed beyond 10, 12 people. In fact, I can’t think of a single multi-million dollar Java project with
over a dozen people that succeeded, as measured strictly by software that was done close to on time, close to on-budget, close to meeting expected business functionality and finally, absolutely meeting the companies expected ROI prior to starting the project looking back. Literally every project that I was on that had under a dozen developers met these metrics. In fact, one project in particular had 8 engineers on it, and it meet managements goals, and then it exceeded them substantially to the tune of 8 figures. Yes, <flame bait>, my position is that too many developers means too many hands in the cookie jar, if you will, and a project destined to fail regardless of tools or technology or methodology.
I’m very conflicted by your positioning in this response, and that’s why I’m asking you if you can remove the veil on these clients you reference. The terms “agile practices” and 30+ developers are paradoxical, wouldn’t you agree? Agile, by definition, is about developing software in short iterations of 1 to 4 weeks. 9 women can’t have a baby in 1 month, no matter what they try. Likewise, I can’t imagine the project management nightmare of having 30 developers crank out iterations in 1 to 4 weeks. Agile development promotes face to face communication over written documents. That must be one helluva meeting room to have 30 developers ~LOL~. Agile development contends that customers and engineers work together in a single workspace, some refer to it as the “bullpen” though we always preferred the term Bat Cave! 30 engineers plus customers in one space doing 1 to 4 week iterations? Perhaps these folks are doing pair programming (!) so there are really only 15 engineers on the project ~LOL~.
I’m not looking to pick a fight with this post, but merely inquiring about the feasibility for you and your team to publish white papers that back these positions up. Until then, I’m afraid I’ll have to treat these positions as suspect because they are counter-intuitive and go against every bit of my experience and likely the experiences of other seasoned J2EE developers.
On a slightly different topic, the Core J2EE patterns— the book with the Sun logo splashed all over its cover— **mostly** documents “patterns” (used extremely loosely because I content that the only real patterns were those introduced by the classic GoF book) that were often fixes or work-arounds for missing functionality in the J2EE spec and/or container design flaws. This isn’t meant to belittle the engineers that worked on the related J2EE specs, but merely that you have to start somewhere and there were gaps along the way— the core J2EE patterns helped plug the proverbial holes.
To recap, I’d be very interested in seeing you and the former iteration::two team deliver white papers that discuss this environment in particular you have repeatedly cited now in a number of posts- large projects with dozens of developers using agile methodologies and J2EE-adapted patterns (with or without Cairngorm- my inquiry isn’t about Cairngorm per se) in a Flex environment. In particular, I’d hope that these papers would cite metrics that our community could agree on— metrics like those I cited earlier— so that proper conclusions can be reached based on fact, not supposition or unproven statements.
Until papers are published with legitimate metrics that depict success demonstrated by what I view as a counter-intuitive position, I feel compelled to cast doubt upon your claims, to both the FlexCoders community and to my Flex prospects and clients.
Best,
Jason
__________
Jason Weiss
Cynergy Systems, Inc.
Macromedia Flex Alliance Partner
http://www.cynergysystems.com
Email: jasonDOTweissATcynergysystemsDOTcom__nospam
Office: 866-CYNERGY
On 11/27/05 4:20 PM, "Steven Webster" <[EMAIL PROTECTED]> wrote:
Mykola,
> Totally agree but EJB was also first technology for
> enterprise development in Java and it worth us to be blind
> for a 5 years. EJB was the same overcomplicated that
> Cairngorm is and as far as I understand Cairngorm uses the
> same patterns and fully inspired by J2EE.
EJB and Cairngorm have nothing in common; both are frameworks, one as
you know is a (excuse the simplification) framework for object
persistence, the other is a framework microarchitecture for RIA. That
the EJB spec is overcomplicated does not mean that Cairngorm is, just
because both can be called "frameworks" or both have reference to J2EE.
Cairngorm does borrow heavily from the body of work that was performed
with Core J2EE Patterns; however, it is not applying J2EE to Flex, it is
recognising that many of the patterns that the Core J2EE pattern
catalogue included, are patterns that can be applicable to RIA
development with Flex (MXML and ActionScript). Note I say *can* be
applied to RIA, not *must* be applied to RIA. There are many ways to
skin a cat.
Apologies to cat lovers. Insert annoying animal of your choice.
> do not repeat previous mistakes. You do not need to get
> things that complex like thy are now with Commands
> FrontControllers and other stuff.
I think that's quite a bold statement. Perhaps you do not need them,
and I absolutely agree that many many projects do not need Commands,
Front Controllers or "other stuff". However, I have worked on and with
several projects that *have* benefited from these patterns and the
architecture that the collaboration of these patterns introduced.
Was this solution the *only* way we could have addressed the problems we
faced ? Of course not ... There are as many different ways of doing
these things as there are talented architects and developers that are
now working with the technology.
If you have your own framework that works for you, and if it addresses
the problems that you face in your design, then you're correct not to
use Cairngorm. Many other developers have done the same as you, and
their implementations are not the worse for it.
However, let's also accept that a great number of developers *have*
benefited greatly from frameworks such as Cairngorm or ARP, have felt
that these frameworks have introduced simplicity where complexity
previously existed.
These people do not think Cairngorm (or whatever other framework) is
bad. Nor will they assert that the framework you are using instead is
bad.
Let's not continue this thread on the assertion that there will be one
ultimately better than all the rest way of building all RIA upon Flex.
> Now I have a kind of
> framework that is much easier than Cairngorm and I'll try to
> share it with the community when it will pass internal
> sainity testing in our team (now guys are happy but lets wait
> more serious testing).
I look forward to seeing it, and hope that it can be presented not as
"better than Cairngorm" or "simpler than Cairngorm" but simply
"different to Cairngorm". In understanding what you tried to achieve
with your approach, rather than what you don't like about other
approaches, I think we'll all learn a lot more, no ?
> >> - No kickstart examples like Appfuse in Java
> >Hopefully time wil bring them. Flex2 will drive a radically
> larger community.
> It is a huge problem cause when you need team development you
> need unittesting, framework, build strategy etc. And I'm sure
> that every team create it from scratch now. The idea is to
> publish some approach and evolve it to support and show best
> practices on it.
Just to be clear, I know of teams of 30+ developers who are developing
Flex applications based upon Cairngorm, who are actively embracing
unit-testing, continuous integration, refactoring, and all manner of
other agile practices.
Certainly, the same team that brought you Cairngorm initially, has a
great deal of experience in delivering projects using Agile methods,
particuarly XP, with both Java, ActionScript 1.0, ActionScript 2.0 and
most recently Flex 2 and ActionScript 3.0. The technology, and the
choice of architectures upon the technology, have never impinged (any
more than AWT, Swing, J2ME, JSP and _javascript_, etc have) upon our
ability to deliver using agile methodologies.
I guess the challenge here, is that many of these teams are immersed in
product development, and can't always invest the time necessary to put
these best-practices such as how to do asynchronous testing, out to the
community as whitepapers/blog entries, etc, quickly as people would
like.
However; I'd challenge the *need* to do asynchronous testing, if you're
refactoring correctly. You can "design for test", and think carefully
in Cairngorm about how you implement your Command classes, to make them
more testable. I know of teams who do asynchronous testing with mock
object strategies, however I have never found the overhead of those
approaches to justify the test-complexity.
I don't believe in testing remote object calls for instance; if I can
test everything up to the point a remote-object cal is made on the
client, *and* I can Junit test the implementation of the service on the
server, then I gain little utility from testing the RemoteObject tag
itself.
Similarly, by refactoring "business objects" out of Command classes - be
they shopping carts, loan calculators, or whatever - one can improve the
testability of applications built upon Cairngorm, without having to
bother about asynchronous testing.
In summary; I'm loathe to let comments like "Cairngorm doesn't allow
agile development" go past, as it's simply not true - there are a number
of agile development teams that I'm aware with, that are building
applications on Cairngorm, as well as other bespoke architectures.
Cairngorm doesn't introduce any complexity over and above the Flex
framework, that reduces the ability to unit-test, perform test-driven
development and run a continuous integration server.
> Just like appfuse does in Java community. I
> guess we have to create our own appfuse Spring + Hibernate +
> Flex, maybe also Spring + Hibernate + Laszlo to have fully
> open source alternative.
Again, Cairngorm won't get in the way of you achieving this, nor will
Flex.
I know also of Flex projects that are built upon Hibernate (we've built
some), as well as Flex projects hitting a server-side tier built upon
the Spring framework.
> I managed to write unitests for our approach but it was very
> hard and if your approach evolves test need to be greatly
> changed not like it is with the sync calls.
I can't wait to see how you get on with Flex 2 Data Services....you'll
be pleased I'm sure.
Mykola, the challenges you're facing are challenges a number of J2EE
developers have successfully faced in the past few years; I think you'll
find that there are people out there who - in-between delivering their
own projects - will have useful information for you to share. Perhaps
framing some questions around how people have achieved some of the
challenges you face, rather than saying they're overly complex or can't
be achieved, will yield some success for you ?
I look forward to seeing what framework you extract from your current
project work. I'm sure it'll complement the current of body of
knowledge greatly, and we'll all benefit.
In the meantime, the iteration::two team that are now Macromedia
Consulting in EMEA, will strive to deliver whitepapers, articles and
further blog entries on some of these issues such as unit-testing and
test-driven development of Flex applications, of continuous integration,
and all manner of other lessons learned as we've worked with Flex
partners and customers.
Bear with us ... These things take time to pull together.
Best wishes,
Steven
--
Steven Webster
Practice Director (Rich Internet Applications)
Macromedia Consulting EMEA
Office: + 44 (0) 131 338 6108
Mobile: +44 (0) 7917 428 947
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
Web site design development <http://groups.yahoo.com/gads?t=ms&k=Web+site+design+development&w1=Web+site+design+development&w2=Computer+software+development&w3=Software+design+and+development&w4=Macromedia+flex&w5=Software+development+best+practice&c=5&s=166&.sig=L-4QTvxB_quFDtMyhrQa> Computer software development <http://groups.yahoo.com/gads?t=ms&k=Computer+software+development&w1=Web+site+design+development&w2=Computer+software+development&w3=Software+design+and+development&w4=Macromedia+flex&w5=Software+development+best+practice&c=5&s=166&.sig=lvQjSRfQDfWudJSe1l> Software design and development <http://groups.yahoo.com/gads?t=ms&k=Software+design+and+development&w1=Web+site+design+development&w2=Computer+software+development&w3=Software+design+and+development&w4=Macromedia+flex&w5=Software+development+best+practice&c=5&s=166&.sig=1pMBCdo3DsJbuU9A>
Macromedia flex <http://groups.yahoo.com/gads?t=ms&k=Macromedia+flex&w1=Web+site+design+development&w2=Computer+software+development&w3=Software+design+and+development&w4=Macromedia+flex&w5=Software+development+best+practice&c=5&s=166&.sig=OO6nPIrz7_EpZI36cYzBjw> Software development best practice <http://groups.yahoo.com/gads?t=ms&k=Software+development+best+practice&w1=Web+site+design+development&w2=Computer+software+development&w3=Software+design+and+development&w4=Macromedia+flex&w5=Software+development+best+practice&c=5&s=166&.sig=f89quyyulIDsn>
YAHOO! GROUPS LINKS
- Visit your group "flexcoders <http://groups.yahoo.com/group/flexcoders> " on the web.
- To unsubscribe from this group, send an email to:
- [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
YAHOO! GROUPS LINKS
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
