On Wednesday 29 November 2006 00:48, Aldo Bucchi wrote: > So, eating my own dogfood, my 2 cents on the 80/20 project:
We've completed several Flex 2 projects, and some in 1.5 too, so here goes: > * iterative releases ( not monolythic ) A must. We throw screen shots at the users as soon as we can, and towards the tail of development, a working stable-ish 'beta' site. We'll also chat to them to make sure their looking at them :-) > * 4-20 services(rpc or fds), 2-4 flexdevs, 1-2 backend devs > * 10-50 screens We have similar sized projects (screens, services), with about half the team size. Initial planning, requirements etc. are gathered as a team, and then we tend to split into backend (ColdFusion) and front end teams (Flex, minimal HTML), with a defined (and evolving) API document to join them together. In this case, the front end GUI leads, because they can see that returning 'A,B,C' from one service call is going to be better than calling 3 services because A, B and C are always needed at the same time- even though the back end may see them as totally unconnected. > * Cairngorm by the book. Ditto, fairly much, we try not to use ViewLocator anymore for instance, as per the recommendation, but this can mean components get broken in two - a include'd .as file for actions, and a main .mxml for the objects in the component. Bloat in the FrontController (lots of AddCommand's) or Model (lots of properties) is a problem, but not so bad you can't just partition it up with some comments. > * Flex Builder, eclipse, subversion ( could be others, but subclipse > and familiarity make this a comfortable choice for many ) We deploy on Linux, with Linux workstations, but still use Eclipse and Subversion with the command line Flex SDK and the community ActionScript and MXML bits. One of these days I'll get the in-Eclipse Ant task working too. > * Tomcat/JRun/Jetty for local testing ( could be an app server as > well, but these are usually lighter and thus swifter when run side by > side with eclipse ) Our backends are ColdFusion, so each developer has a CF server and we share a remote database. Flex is then compiled locally and just copied to the web root. > * FDS or just RPC ( both be run from within a webserver ) We're OK with just RPC and background/user-driven refresh calls. I *think* we have just the one FDS licence for a single app. so we wont waste it unless we have to. > Ok, how would you recommend setting up dev stations for that project? > workflow? where does flex meet the backend? when? where do we unit > test the different environments? how do we package and when? etc... We're using a trimmed version of Agile - a quick email from each team member once a day saying what they did, are doing, and what's in the way. This keeps us mostly synchronised. During the day we'll announce new SVN rev's as they're committed - "r2302 adds the additional data you wanted to the return of BarService.getFoo()". The API doc is just a table with the method signatures and return types in - that's in SVN too so front end people can write to something the backend doesn't do yet, and fudge it in the ServiceDelegate or write a fake server object if needed and hopefully not have to change much when the real one comes along. This prevents hold ups from that side, though it seems the back end is finished quicker than the Flex side of things so far - this may change as we deliver more products. During the tail of the dev. process we may be cutting release tags a few times a week and pushing to the beta site, eventually all the bugs are closed off, we copy the latest tag to a branch, compile the branch, and deploy to the live site. We don't unit test our MXML GUI's because I've not had a chance to play with the tools that claim to do it. Developers write test cases for AS and CFML code as they go - most of the time it's not worth the whole test unit confabble, so you just get a single CFML or MXML page that exercises the public methods. This will catch most coding or logic errors, and allows us to retest things after refactoring. > Again, I fully support top-down mocks. It's like being able to > simulate 3d full sized houses before building them. risk killer and > keeps the user happy! Yup. I'd love to try mocking a GUI with Flex Builder right in front of a user with the next project. Might be a bit much, because they'll start asking for them just because they see the icon. Maybe screen-sharing just the design area as we talk would be good - sort of like the white boarding we do in the dev. team at the mo. Woa, that was a long post :-) -- Tom Chiverton Helping to conveniently incubate internet supply-chains **************************************************** This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. -- 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/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> 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/
