Nevermind - says it at the top too - I'm ready for the holiday break. Jason Merrill | E-Learning Solutions | icfconsulting.com
>>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:flashcoders- >>[EMAIL PROTECTED] On Behalf Of Merrill, Jason >>Sent: Friday, December 23, 2005 12:16 PM >>To: Flashcoders mailing list >>Subject: RE: [Flashcoders] Faster code? >> >>Ah - I guess it is. Says that WAY down the web page - not in the top >>where it says, "download". What's the best one for Windows? >> >>Jason Merrill | E-Learning Solutions | icfconsulting.com >> >> >> >> >> >> >> >> >> >> >>>>-----Original Message----- >>>>From: [EMAIL PROTECTED] [mailto:flashcoders- >>>>[EMAIL PROTECTED] On Behalf Of hank williams >>>>Sent: Friday, December 23, 2005 12:02 PM >>>>To: Flashcoders mailing list >>>>Subject: Re: [Flashcoders] Faster code? >>>> >>>>I think its a mac app. >>>> >>>>Hank >>>> >>>>On 12/23/05, Merrill, Jason <[EMAIL PROTECTED]> wrote: >>>>> I downloaded the trial, but what's a .dmg file and how do I unpack >>it in >>>>> Windows? Couldn't find any info on their site - and double-clicking >>the >>>>> file gives me an error - unrecognized file type. >>>>> >>>>> Jason Merrill | E-Learning Solutions | icfconsulting.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>-----Original Message----- >>>>> >>From: [EMAIL PROTECTED] >>[mailto:flashcoders- >>>>> >>[EMAIL PROTECTED] On Behalf Of Merrill, Jason >>>>> >>Sent: Friday, December 23, 2005 11:42 AM >>>>> >>To: Flashcoders mailing list >>>>> >>Subject: RE: [Flashcoders] Faster code? >>>>> >> >>>>> >>Thanks. >>>>> >> >>>>> >>Jason Merrill | E-Learning Solutions | icfconsulting.com >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >>>>-----Original Message----- >>>>> >>>>From: [EMAIL PROTECTED] >>[mailto:flashcoders- >>>>> >>>>[EMAIL PROTECTED] On Behalf Of Paul BH >>>>> >>>>Sent: Friday, December 23, 2005 11:31 AM >>>>> >>>>To: Flashcoders mailing list >>>>> >>>>Subject: Re: [Flashcoders] Faster code? >>>>> >>>> >>>>> >>>>this is the tool I meant - visDoc / ASDoc were these once the >>same? >>>>> >>>>cant remember... Im having a slow day... >>>>> >>>> >>>>> >>>>http://www.visiblearea.com/visdoc/ >>>>> >>>> >>>>> >>>>On 12/23/05, Merrill, Jason <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Where can I get ASDoc? Google seems pretty ignorant of it - >>at >>>>> >>least as >>>>> >>>>> a product or software tool. Or is it an internal-only product >>>>> Adobe >>>>> >>>>> uses? Or is it simply a Macromedia standardized HTML format >>for >>>>> >>help >>>>> >>>>> content? >>>>> >>>>> >>>>> >>>>> Jason Merrill | E-Learning Solutions | >>icfconsulting.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>-----Original Message----- >>>>> >>>>> >>From: [EMAIL PROTECTED] >>>>> >>[mailto:flashcoders- >>>>> >>>>> >>[EMAIL PROTECTED] On Behalf Of JesterXL >>>>> >>>>> >>Sent: Friday, December 23, 2005 10:56 AM >>>>> >>>>> >>To: Flashcoders mailing list >>>>> >>>>> >>Subject: Re: [Flashcoders] Faster code? >>>>> >>>>> >> >>>>> >>>>> >>Oh yeah definatly. Even though Natural Doc's syntax feels >>more >>>>> >>>>> >>straightforward, ASDoc definately has the most beautiful >>output >>>>> >>that >>>>> >>>>> I've >>>>> >>>>> >>seen to date. >>>>> >>>>> >> >>>>> >>>>> >>----- Original Message ----- >>>>> >>>>> >>From: "Paul BH" <[EMAIL PROTECTED]> >>>>> >>>>> >>To: "Flashcoders mailing list" >>>>> <flashcoders@chattyfig.figleaf.com> >>>>> >>>>> >>Sent: Friday, December 23, 2005 10:53 AM >>>>> >>>>> >>Subject: Re: [Flashcoders] Faster code? >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >>1) I agree, that's why back to my earlier thing, I rarely >>>>> comment >>>>> >>- >>>>> >>>>> >>what ASDoc does do however is provide a way of displaying >>things >>>>> >>like >>>>> >>>>> >>your method signature in a friendly HTML like manner, with a >>>>> handy >>>>> >>>>> >>index down the side. When I do comment, it would be to >>explain >>>>> >>some >>>>> >>>>> >>hackery, or something that wasnt obvious - within a >>function, >>>>> this >>>>> >>>>> >>wouldnt get picked up, if it was something like a paramenter >>>>> only >>>>> >>>>> >>being in an allowable range, I would comment that in a way >>that >>>>> >>ASDoc >>>>> >>>>> >>picks up... >>>>> >>>>> >> >>>>> >>>>> >>2)Hehe if I couldnt do that, it would be nirvana-esque... I >>>>> never >>>>> >>said >>>>> >>>>> >>that this document wouldnt change - the key thing here is to >>>>> make >>>>> >>sure >>>>> >>>>> >>that the change is captured in one place and one place >>alone... >>>>> ie >>>>> >>- >>>>> >>>>> >>when business changes the specification, this is reflected >>in my >>>>> >>unit >>>>> >>>>> >>tests (as they are one & the same document), and thus my >>test >>>>> >>suite >>>>> >>>>> >>know about it straight away... >>>>> >>>>> >> >>>>> >>>>> >>On 12/23/05, JesterXL <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>> 1. ASDoc just generates comments from your code. If your >>>>> code >>>>> >>>>> comments >>>>> >>>>> >>> aren't up to date, neither is your generated asdocs. >>>>> >>>>> >>> >>>>> >>>>> >>> 2. If you could coerce a client to sign a document saying >>that >>>>> >>>>> business >>>>> >>>>> >>> requirements never change... hell dude, I'm hiring you >>>>> fulltime >>>>> >>to >>>>> >>>>> work >>>>> >>>>> >>> for >>>>> >>>>> >>> me! >>>>> >>>>> >>> >>>>> >>>>> >>> >>>>> >>>>> >>> ----- Original Message ----- >>>>> >>>>> >>> From: "Paul BH" <[EMAIL PROTECTED]> >>>>> >>>>> >>> To: "Flashcoders mailing list" >>>>> >><flashcoders@chattyfig.figleaf.com> >>>>> >>>>> >>> Sent: Friday, December 23, 2005 10:31 AM >>>>> >>>>> >>> Subject: Re: [Flashcoders] Faster code? >>>>> >>>>> >>> >>>>> >>>>> >>> >>>>> >>>>> >>> I'm so glad I opened such a juicy can of worms just before >>>>> >>Christmas >>>>> >>>>> ;) >>>>> >>>>> >>> >>>>> >>>>> >>> I just want to throw one more thing into the mix before I >>>>> >>dissappear >>>>> >>>>> off >>>>> >>>>> >>> to >>>>> >>>>> >>> numb >>>>> >>>>> >>> my family reunion with hefty doses of alcohol... >>>>> >>>>> >>> >>>>> >>>>> >>> So, now I think my comments before about, erm comments >>still >>>>> >>stand. >>>>> >>>>> I >>>>> >>>>> >>> see comments differently to documentation, so I'll just >>add my >>>>> >>>>> >>> tuppence to this and retire to eat drink & be merry... >>>>> >>>>> >>> >>>>> >>>>> >>> I think some (many)? people dont document because they >>cant be >>>>> >>>>> arsed. >>>>> >>>>> >>> Why is this the case? We'll, again, I think it comes down >>to >>>>> >>>>> changing >>>>> >>>>> >>> requirements, and the fact that I hate having the same >>>>> >>information >>>>> >>>>> in >>>>> >>>>> >>> two places, as at some point one will get out of date... >>>>> >>>>> >>> >>>>> >>>>> >>> How to manage this, and at the same time make your code >>easy >>>>> to >>>>> >>>>> >>> understand? >>>>> >>>>> >>> >>>>> >>>>> >>> This is how we are approaching it / looking to approach >>it... >>>>> >>>>> >>> >>>>> >>>>> >>> 1) Documentation of individual methods within classes is >>done >>>>> >>using >>>>> >>>>> >>> ASDoc which gets triggered whenever a file gets checked >>into >>>>> >>source >>>>> >>>>> >>> control -- your documentataion is generated from your >>class >>>>> >>file, >>>>> >>>>> and >>>>> >>>>> >>> is *always* up to date with your checked in class file... >>>>> >>>>> >>> >>>>> >>>>> >>> 2) We are looking into using a thing called FIT >>>>> >>(http://fit.c2.com/) >>>>> >>>>> >>> What this does is tie in business requirements with unit >>>>> tests. >>>>> >>The >>>>> >>>>> >>> business (ie the client) basically write their >>specifications >>>>> >>(or >>>>> >>>>> are >>>>> >>>>> >>> assisted with it) in a word document. wherever a table is >>>>> >>>>> encountered, >>>>> >>>>> >>> this is interpreted by FIT as a unit test, and the test >>>>> builder >>>>> >>>>> writes >>>>> >>>>> >>> a fixture to accomodate that test... What this means is >>that >>>>> you >>>>> >>are >>>>> >>>>> >>> documenting your business logic in one place (rather than >>both >>>>> a >>>>> >>>>> specs >>>>> >>>>> >>> document and a slew of unit tests) >>>>> >>>>> >>> >>>>> >>>>> >>> For me, the underlying principle is this -- DONT REPEAT >>>>> YOURSELF >>>>> >>-- >>>>> >>>>> >>> it'll save you a whole truckload of hassles down the >>road... >>>>> >>>>> >>> >>>>> >>>>> >>> Pxx >>>>> >>>>> >>> >>>>> >>>>> >>> >>>>> >>>>> >>> >>>>> >>>>> >>> On 12/23/05, Hans Wichman <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>> > Just to those that are reading this thread and wondering >>if >>>>> >>>>> writing neat >>>>> >>>>> >>> > documented code for clients (and payed for by clients) >>is an >>>>> >>>>> illusion, >>>>> >>>>> >>> > my >>>>> >>>>> >>> > 2 >>>>> >>>>> >>> > cents: >>>>> >>>>> >>> > >>>>> >>>>> >>> > we've been working on a project (complete virtual >>learning >>>>> >>city) >>>>> >>>>> in >>>>> >>>>> >>> > flash >>>>> >>>>> >>> > in which the client didnt really know what he wanted up >>>>> front, >>>>> >>>>> which we >>>>> >>>>> >>> > tackled using a usecase-development/prototyping >>approach. >>>>> >>>>> >>> > The object oriented design was by large thought up up >>front, >>>>> >>the >>>>> >>>>> >>> > conversion >>>>> >>>>> >>> > of this design to AS2.0 was done bit by bit, using unit >>>>> >>testing >>>>> >>>>> etc. All >>>>> >>>>> >>> > the while the specs where changing and we made >>>>> >>>>> this-phase/next-phase >>>>> >>>>> >>> > choices and did a small impact analysis for most of >>them. >>>>> >>>>> >>> > During implementation most of the code was being >>documented >>>>> >>>>> already >>>>> >>>>> >>> > (during >>>>> >>>>> >>> > or upfront), not using obvious what-does-this-button-do >>>>> >>comments, >>>>> >>>>> but >>>>> >>>>> >>> > WHY-does-this-button-do-what-it-does comments. The >>internals >>>>> >>>>> workings >>>>> >>>>> >>> > may >>>>> >>>>> >>> > change, but why-it-does-what-it-does usually doesnt. The >>>>> >>client >>>>> >>>>> now >>>>> >>>>> >>> > requested ALL documentation to be delivered as a >>separate >>>>> >>product, >>>>> >>>>> most >>>>> >>>>> >>> > of >>>>> >>>>> >>> > which is already present and includes functional docs, >>>>> >>technical >>>>> >>>>> docs, >>>>> >>>>> >>> > source docs, readers, etc. >>>>> >>>>> >>> > This product will run for a number of years, currently 4 >>>>> >>virtual >>>>> >>>>> >>> > casestudies have been implemented and 50 more will be >>>>> required >>>>> >>>>> over the >>>>> >>>>> >>> > next few years (casestudy == adventure game). A number >>of >>>>> >>people >>>>> >>>>> are >>>>> >>>>> >>> > working on this project together, ussually not having a >>clue >>>>> >>what >>>>> >>>>> the >>>>> >>>>> >>> > other >>>>> >>>>> >>> > one does, they just agree on a common interface for >>example >>>>> >>>>> between >>>>> >>>>> >>> > client >>>>> >>>>> >>> > and server (which is documented by examples mostly). >>>>> >>>>> >>> > Lots of changes will probably be required, but since the >>>>> code >>>>> >>is >>>>> >>>>> >>> > modular, >>>>> >>>>> >>> > its clean (99,9%) and well documented, we can analyse >>what >>>>> has >>>>> >>to >>>>> >>>>> be >>>>> >>>>> >>> > refactored and what doesnt need to be. >>>>> >>>>> >>> > >>>>> >>>>> >>> > This is not to start up the discussion again whether or >>not >>>>> to >>>>> >>>>> document >>>>> >>>>> >>> > your code, just to tell you that almost all our clients >>(our >>>>> >>>>> company has >>>>> >>>>> >>> > about 50 ppl and a lot of clients) request a solid >>design, >>>>> >>solid >>>>> >>>>> >>> > documentation and a copy of the sourcecode. Internally >>we >>>>> are >>>>> >>all >>>>> >>>>> >>> > expected >>>>> >>>>> >>> > to have a high standard and work on increasing this >>standard >>>>> >>even >>>>> >>>>> >>> > further >>>>> >>>>> >>> > (for example by reading books such as 'code complete', >>>>> taking >>>>> >>>>> >>> > certifications, studying oo development). This is the >>same >>>>> for >>>>> >>>>> java, >>>>> >>>>> >>> > php, >>>>> >>>>> >>> > AS1, AS2, visual basic or c++ developers. >>>>> >>>>> >>> > >>>>> >>>>> >>> > Does the way we work slow us down? No. >>>>> >>>>> >>> > Does the way we work cost us clients? Nope. >>>>> >>>>> >>> > Does everything need to be documented? No ofcourse not. >>>>> >>>>> >>> > Is this approach applicable to all types of projects? >>Nope. >>>>> >>>>> >>> > Will we hire someone who is fast but does not document >>his >>>>> >>crappy >>>>> >>>>> code, >>>>> >>>>> >>> > again? We surely wont, and we know becoz we review his >>code >>>>> >>after >>>>> >>>>> each >>>>> >>>>> >>> > project. >>>>> >>>>> >>> > >>>>> >>>>> >>> > I do think lots of the arguments given here against >>>>> >>documenting >>>>> >>>>> are just >>>>> >>>>> >>> > excuses in order not to have to, or a lack of skill in >>the >>>>> oo >>>>> >>>>> design >>>>> >>>>> >>> > area. Rewriting and rewriting and rewriting (with or >>>>> without >>>>> >>>>> >>> > documentation) should make warnings bells go off in your >>>>> head, >>>>> >>>>> with or >>>>> >>>>> >>> > without someone paying for it. >>>>> >>>>> >>> > Can I do the same very cool things all the >>>>> >>>>> non-documenting-guru/hackers >>>>> >>>>> >>> > do? >>>>> >>>>> >>> > Nah unfortunately not, but thats beside the point ;). >>>>> >>>>> >>> > >>>>> >>>>> >>> > When it comes down to it, I agree you have to pragmatic >>when >>>>> >>>>> coding, not >>>>> >>>>> >>> > everything we do has to have an academic standard, but >>you >>>>> >>>>> shouldn't >>>>> >>>>> >>> > grab >>>>> >>>>> >>> > every opportunity to write crappy code with both hands >>>>> either. >>>>> >>>>> >>> > >>>>> >>>>> >>> > Just my 2 cents... >>>>> >>>>> >>> > H >>>>> >>>>> >>> > >>>>> >>>>> >>> > >>>>> >>>>> >>> > At 08:51 AM 12/23/2005, you wrote: >>>>> >>>>> >>> > >>I think it reflects the nature of flash and its >>history. >>>>> >>>>> >>> > > Not to mention the diverse skillset of its >>>>> >>developer-base. A >>>>> >>>>> lot of >>>>> >>>>> >>> > > people learned to write code in Flash, and the >>question of >>>>> >>>>> whether >>>>> >>>>> >>> > > they >>>>> >>>>> >>> > > are doing it the "right" way or not is debatable. >>>>> >>>>> >>> > > >>>>> >>>>> >>> > >>In other words, as flash becomes a real software >>>>> development >>>>> >>>>> platform, >>>>> >>>>> >>> > >>real development methodologies will become more >>important. >>>>> >>>>> >>> > > That's really what it comes down to. As you start >>>>> >>building >>>>> >>>>> >>> > > longer-term >>>>> >>>>> >>> > > projects and using standardized methodologies, these >>>>> things >>>>> >>>>> start to >>>>> >>>>> >>> > > become more important. I still do the occasional >>one-off >>>>> >>>>> animation or >>>>> >>>>> >>> > > ad, >>>>> >>>>> >>> > > but that's not where I spend the majority of my time >>these >>>>> >>days. >>>>> >>>>> >>> > > >>>>> >>>>> >>> > >ryanm >>>>> >>>>> >>> > >_______________________________________________ >>>>> >>>>> >>> > >Flashcoders mailing list >>>>> >>>>> >>> > >Flashcoders@chattyfig.figleaf.com >>>>> >>>>> >>> > >>>http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>>> >>>>> >>> > >>>>> >>>>> >>> > _______________________________________________ >>>>> >>>>> >>> > Flashcoders mailing list >>>>> >>>>> >>> > Flashcoders@chattyfig.figleaf.com >>>>> >>>>> >>> > >>http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>>> >>>>> >>> > >>>>> >>>>> >>> _______________________________________________ >>>>> >>>>> >>> Flashcoders mailing list >>>>> >>>>> >>> Flashcoders@chattyfig.figleaf.com >>>>> >>>>> >>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>>> >>>>> >>> >>>>> >>>>> >>> _______________________________________________ >>>>> >>>>> >>> Flashcoders mailing list >>>>> >>>>> >>> Flashcoders@chattyfig.figleaf.com >>>>> >>>>> >>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>>> >>>>> >>> >>>>> >>>>> >>_______________________________________________ >>>>> >>>>> >>Flashcoders mailing list >>>>> >>>>> >>Flashcoders@chattyfig.figleaf.com >>>>> >>>>> >>http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>>> >>>>> >> >>>>> >>>>> >>_______________________________________________ >>>>> >>>>> >>Flashcoders mailing list >>>>> >>>>> >>Flashcoders@chattyfig.figleaf.com >>>>> >>>>> >>http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>>> >>>>> NOTICE: >>>>> >>>>> This message is for the designated recipient only and may >>contain >>>>> >>privileged or >>>>> >>>>confidential information. If you have received it in error, >>please >>>>> >>notify the sender >>>>> >>>>immediately and delete the original. Any other use of this >>e-mail by >>>>> >>you is >>>>> >>>>prohibited. >>>>> >>>>> _______________________________________________ >>>>> >>>>> Flashcoders mailing list >>>>> >>>>> Flashcoders@chattyfig.figleaf.com >>>>> >>>>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>> >>>>Flashcoders mailing list >>>>> >>>>Flashcoders@chattyfig.figleaf.com >>>>> >>>>http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>>> >>_______________________________________________ >>>>> >>Flashcoders mailing list >>>>> >>Flashcoders@chattyfig.figleaf.com >>>>> >>http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>>> _______________________________________________ >>>>> Flashcoders mailing list >>>>> Flashcoders@chattyfig.figleaf.com >>>>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>>> >>>>_______________________________________________ >>>>Flashcoders mailing list >>>>Flashcoders@chattyfig.figleaf.com >>>>http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>_______________________________________________ >>Flashcoders mailing list >>Flashcoders@chattyfig.figleaf.com >>http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
