|
superabe,
If I may, I would like
to suggest the environment I like to use. Most of the applications I have
been working with had to do very few things - database access ( read and
update), navigation and reporting. There are fun parts here and there but I like
to keep them to myself so it is not completely boring.
How would you go about
developing and maintaining ever evolving codebase with a lot of repetitve
"utility" fuctionality driven by trial and error design process? You do not
write application code till the very end. Instead you build or get automation
tools that allow you to prototype data access, navigation and reporting - and
use it in production later on.
Let me illustrate. I need to be
able to maintain customer info - let us say it is trivial "select * from
customer where id=?". I can write regular Java code to do all retieve, update,
insert and delete methods - all 500 lines of it actuall - by hand. I would also
need to create value object to hold the data and maintain that as the DB
expands. not to forget - need to create model objects coming in and out, bind,
and work through the changes with code that would be able to figure out
what user did and submit one of those methods. Do fine stuff (validation and
formatting), debug protocol with server as some undefined/null value would blow
it randomly, and have part of weekend free before the inevitable changes will
start flowing in.
Alernatively I can use Doclets
to process some comments embedded in my java interface and generate the
following :
1. All Java code
2. All synchronized value objects - java and
AS
3. Forms and grids and master details screens along
with Formatters/validators - can use to cut and paste those
Add a set of high level objects like Foms and
DataProviders that automatically keep state/track changes and have
retrieve/update API embedded, transactions, progressmeters, and othe high-level
objects you need in any app - and you can cut-and-paste your wireframes from
those resources much easier then BAs can move Visio shapes. Best thing you can
tell users "now I need to work on making it working" and take really nice
vacation.
Now the change comes - they added a field. Time to
regen - that takes care of Java and VO, You will need to cut-and-paste new field
in "prototype" - but hopefully, thats it.
OK, they want something drastic - database
driven comboboxes, expandable treeviews, you name it. Take a deep breath
and look around. DO NOT MAKE APPLICATION SPECIFIC CODE. Chances are you might
need database driven combobox somewhere else! Rather, create object that you can
use across the screens, think hard about caching, read about problems with
"prompt" and "value" properties, prepare yourself for those wireframe meetings.
Make a management decision if you want to make that generic object upfront or
you want to "hardcode" it during session and get the scope on functionality it
has to support.
It is
true that "generalized" code takes 3 times longer to write. It is also true that
on average you will be able in more then 3 occasions. The "next best"
productivity method (some call it cut and paste) is guaranteed to turn the
project in development nightmare even before it goes into maintenance.
Here is the ultimate goal for
the "perfect" maintainable application - it has to have very little code.
It has to use as much as possible of pre-tested, reviewed consistent objects
instead.
During design/wireframe stages try
to concentrate on database design, usability and identifying
objects/supporting tools.
HTH,
Anatole Tartakovsky
----- Original Message -----
Sent: Friday, November 04, 2005 9:27
PM
Subject: Re: [flexcoders] Re: Flex
prototype - production approach
Absolutely! 9 out of 10 times I'm building,
& re-factoring production code as I go.
I think the important thing to note here is the
purpose of milestones via iterations is to get a build done, working, and
testable by a real user, not just a developer. This garners relevant
feedback, the kind that promotes work to be focused on the 80% of the app that
matters. Additionally, this gives you a chance to challenge the
wireframes, the information architect's work, and/or the designers. You
constantly have proof of improvement, recognizable & documentable
milestones, and a sense of accomplishment that actually has meaning.
Working towards meeting the users' needs, and making progress doing it is a
lot more relevant to a project's success than working towards the developer
feeling comfortable with his architecture and showing progress doing it.
Just because I love my implementation of MVC in the app means jack of the app
doesn't work for the user.
Now you can see how my view of commenting code
& using tools like ASDoc is slanted; I'm too busy improving & changing
the design as I go to ever really get to the point where the app is so stale
it needs to be documented. Why spend time on it if you are possibly
going to change it? It's wasted effort.
Change? Having View's that aren't tied to
the Model and emit useful events. Having, as Steven has said in the
passed, Commands (chunks of controller code) that actually map to user cases;
they do something the user would do like "open a document", "save a record",
etc. Doing your best to use MVC & frameworks like Cairngorm and ARP
allow things to be extremely flexible. Most of my changes come from
design, not from business process, so most of the time it's pretty easy, like
moving some MXML around, or deleting it entirely and just using code.
Other times, the actual logic changes, and I have to sometimes move code
around, etc. Again, modularizing techniques keep this to a minimum;
meaning you are most of the time creating & modifying vs. destroying
what you created.
The phrase "signed off" to me sounds like the
contracting advice I see thrown around the lists. I admittingly do not
understand their pain. I recognize that they are trying to protect
themselves, as their stories of past problem jobs are telling, but I've never
had that experience. Additionally, and more telling, I've never had a
wireframe that was rock solid. While I do hate doing wireframe changes 6
weeks into a project, I'd rather be doing that then following a failed
cause.
So, to me, signing off on a wireframe sounds like
a death warrant... but I never deal with those sides of the project; my
managers, designers, or sales dudes do.
Yes, skins add considerable time, but one must
understand that a designer developing a rich app is creating, hopefully more
often than not, something extremely brandable and compelling compared to the
simplisitic nature of web page designs, which have to be created that way
to fit into the HTML/CSS paradigm. Those boundaries to design do not
exist in Flex since the sky's the limit, so it's actually time well spent;
time you couldn't do at all in HTML development. On the flipside, I've
seen web designers take weeks to get a design to work on a website... and one
I wasn't really impressed with at all. Spending 6 hours on getting a
margin to work seems a lot less valuable to me than spending 6 hours
implementing a phat PSD into PNG parts for use in skinning Flex
components.
Flex, and Flash, both are still evolving.
Although we've had years, and one can go on Google and find thousands of
components that are free, there isn't a lot of cream in the crop. QA is
a nightmare because some were written for Flash 4 before ActionScript existed,
some are AS1, and the majority are tied to FLA's in some way. A lot of
time in Flex is spend custom components for a specific job, yes. But,
it's worth it; you build up an impressive reproitoire of components in the
long run.
_javascript_ has definately got us on that front
with the options of frameworks out there, both commercial and non.
But... they are about AS1, and don't look as cool as ours!
Remember; an app can look good and not work
as well, but still sell better than one that does.
...data... hrm... tough. Usually, I've
found the backend guys I've worked with follow this pattern:
- in the beginning, they know everything, and
spell out the data model to me, and involve me in business logic discussions
to see what I can handle on the client; I in turn push as much as I can their
way
- in the middle, I work like mad, and get
feedback on how I'm doing from them, and ask questions
- I reach one of my later milestones, and am
ready for real data; at this point, I start breaking the hell out of their
back-end services. So, getting relevant data takes a few
days
- once I get the data, I recognize problems with
it (usually associated with OpenAMF; .NET and real Flash Remoting installs I
rarely have this problem) and either ask for changes that they usually
consider extremely minor, or slightly massage to what my component wants (in a
ViewHelper for example).
- at that, point, I'm finishing business logic,
wrapping things up, and in the end I'm waiting on the back-end guys to fix
bugs so I can re-test my front-end for the 50th billion time.
That's pretty much stayed true every project
involing serious back-ends. I've always tried to utilize dummy data
early on and get confirmation from the back-end guys on what I'm getting, so I
havne't run into the problem you are describing.
----- Original Message -----
Sent: Friday, November 04, 2005 8:26 PM
Subject: Re: [flexcoders] Re: Flex prototype - production
approach
Thanks for all the replies.
So the majority seem to favour approach A and iterative
development.
Question though, doesnt iterative mean you are building towards
a production app?
Meaning the prototype would constantly get refactored and eventually
become the production app.
As opposed to a protoype that is done real fast and then the production
app is started from scratch (i.e none of the code is re-used , but you gain
all the UI design, usability and input from domain experts experience from the
prototype design phase)
Also, having just been through an iterative process for a Flex
project, some questions :
How do you manage constant change in iterative development ?
Especially when you start without signed off comps/wireframes ?
Also, what about where you have very custom designs (using skins ,
transitions etc, custom display mechanisms), does that not add
extra dev time trying to do it in Flex at the prototype stage (as opposed to a
quick mockup in Flash say for e.g or a Photoshop comp)
And in the process that Dave calls LookFirst, do you ever run
into issues, where once the UI is done and decided on, the
nature of the data in the data store (as decided by the
business logicl) proves inefficient for display process. (might have been
fine using static dummy data, but when the real-life data comes along...things
prove too convoluted)
Once again thanks for all the comments.
Very useful. Just trying to get a better handle on how to plan out larger
Flex projects.
- superabe
On 11/4/05, Dave
Wolf <[EMAIL PROTECTED]>
wrote:
We
feel very strongly about this subject. We developed all
our
Flex/RIA solutions so far using a "front to back" approach.
Effectively we do what we call a Model & Design phase where we
develop
out the entire UI in Flex. In the past we would call
this "wire
framing" and would use static images to represent the
UI. Witht he
productivity of Flex we now just do it right in
Flex. We work hand in
hand with the domain experts to layout
and develop every screen in
the application. Once that is
done, in the next phase we bind static
data to the UI, implement
validations and flow and actions. Finally
using the domain
knowldge we got from the M&D the back-ends are
developed and finally
integrated into the UI.
This approach has tons of advantages but the
biggest being this. JAD
sessions are
*boring*. Business domain experts get very bored very
quickly
looking at data models, object models, functional specs etc.
Well as they
get bored, they stop caring. So when you ask "Can we
just skip
field X here" they just go "Yup". Now you do the back-end,
the
API's build out the UI without field X. Wanna guess what
happens?
Yep, they tell you X is missing and the app is flawed because of
it.
Now you have to layer fixes into three to four layers of
the
application. Add the field to the data store, add it to
the
persistance layer, add it to the API, add it to the UI,
etc.
Domain users are *a lot* more likely to stay engaged in the user
experience. Then you use those lessons learned to drive back
at the
enterprise tier.
We've coined this approach as
LookFirst(tm) and use it pretty much
religously. There are
other side benefits like the app is
demonstrable before its finished,
blah blah.
We actually sell an offering to our clients for the
M&D itself.
Includes all the screens, data model, project plan, test
plan, etc.
Its been very successful.
I would vote for a LookFirst
like front to back approach.
--
Dave Wolf
Cynergy Systems,
Inc.
Macromedia Flex Alliance Partner
http://www.cynergysystems.com
Email: [EMAIL PROTECTED]
Office:
866-CYNERGY
--- In [email protected] ,
"JesterXL" <[EMAIL PROTECTED]> wrote:
>
> Jesse Warden does A,
Darron Schall does B (I would think).
>
> I like to build stuff
quickly, ironing out the weird, diffucult
things, and just continually
kneed the mofo like dough, improving, and
releaseing working builds to
prove progress. Sometimes, you realize a
re-write is best, and
you can re-use some functions and assets, but
not much (which is why I
call it a re-write). Since Flash & Flex make
that sooo
fast, you do that about 3 times.
>
> I've done B, but that
sucks. I hate UML, as long as you have an
awesome Information
Architect, who cares; take the wireframes, and go;
then iterate when you
can show a build, and double-check your
assumptions about both the
wireframes & the implementation.
>
> To me, B works in
better in a team, and I've had success working
with others, but the
pressure at the forefront to "plan it perfectly"
seems like I'm being
setup to fail, and when the transition from
prototype to production
comes; it feels cheap because the code itself
wasn't really a prototype;
it was a planned production piece from the
get go.
>
>
Obviously, I'm leaving out all of the important factors that affect
the
above such as investment, leeway, deadlines, # team
members,
accountability, aptitude, experience, etc. but bottom line, I
dig A.
The only really big thing about A is deadline; you're
emotional
attachment to building re-usable code should be inversely
proportional
to the amount of time you have left. So, if you
have a week, don't
care about it. If you have a month,
definately. Obviously, I'm
implying scope here, but you get
the gist.
>
>
> ----- Original Message -----
> From:
superabe superabe
> To: [email protected]
>
Sent: Friday, November 04, 2005 5:19 AM
> Subject: [flexcoders] Flex
prototype - production approach
>
>
> Just curious about
what folks here on the list think / have
experienced about the prototype
based approach to RIA developemnt with
Flex.
>
> Am
evaluting a potential project that needs to be prototyped first
and
eventually built using Flex, and trying to decide what to use
for
prototyping and how much of the prototype can be re-used in the final
app.
>
> The two options I see, are :
>
> A. do a
quick prototype in Flex or Flash for the purposes of feature
gathering /
usbility. The start the production app from scratch in Flex.
>
>
B. Do a more planned out / better architected prototype in Flex ,
that
can be re-used substantially towards the production app.
>
> Am
interested to know what pros' and cons people have faced with
both
approaches.
> TIA
>
> - superabe
>
>
>
>
>
> --
> 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 Software design and
development Macromedia
flex
> Software development best
practice
>
>
>
--------------------------------------------------------------------------------
>
YAHOO! GROUPS LINKS
>
> a.. Visit your
group "flexcoders" on the web.
>
> b.. To
unsubscribe from this group, send an email
to:
> [EMAIL PROTECTED]
>
> c.. Your use of Yahoo! Groups is
subject to the Yahoo! Terms
of
Service.
>
>
>
--------------------------------------------------------------------------------
>
------------------------
Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools
to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/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/
--
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
YAHOO! GROUPS LINKS
|
