Mykola, What are your alternatives to flex??
On 11/27/05, Jason Weiss <[EMAIL PROTECTED]> wrote: > Steven, > > 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. > To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > ________________________________ > -- ::::: Aldo Bucchi ::::: mobile (56) 8 429 8300 ------------------------ Yahoo! Groups Sponsor --------------------~--> Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/nhFolB/TM --------------------------------------------------------------------~-> -- 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 <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
