need of a web based message board

[Fairlight]

This public service announcement was brought to you by Brian K. White:
> > I don't get caught up in the "web 2.0" buzzword scene.  There -are- some
> 
> Who cares what it's called? You're talking to a guy who still writes all his 
> cgi in ksh, still hasn't learned javascript or perl, played with php for the 
> first time for one teeny cgi just a few days ago. Yeah I'm all about the 
> buzzwords.

I care, actually.  I wasn't accusing you of falling into that category, I'm
just saying up-front that I'm exceedingly wary of anything labeled "[insert
buzzword] 2.0".  There's been Web 2.0, Business 2.0 (CNN/Money), and a host
of others.  Hype, all of it.

I've come to an uneasy truce with Flash.  I like it for some things.  It
can be useful--where necessary or extremely desirable.  If I felt like
bending over for Adobe, I'd probably get MX--right after After Effects.  I
can't justify either, though.  But as with Flash, I'm seeing valid uses for
some of the technology as more than an over-hyped technological orgy of
self-aggrandizement.  But there's still a LOT of bloat out there.  :(

> The point was to make the assertion that for the user interface, the most 
> important feature is short development cycle, and to determin the framework 
> that best serves that assertion.

I disagree with that assertion, even.  Technically speaking, native C
binaries are near as fast as fastcgi, mod_perl, et al.  I was just reading
up on that again this morning.  And I didn't buy his argument about
recompiling.  I used to do all my CGI in C before I migrated to perl; given
proper makefiles, only what's changed is recompiled, and on today's
systems, even C++ compiles relatively quickly.  I'd call the compiling
issue a red herring, having lived it.

> He provided the theory and some examples to support that assertion, but
> even so I guess it could still be argued.  That part wasn't a proof, just
> a set of facts and observations and a conclusion.

Fair enough.

> I guess you could also argue his proof of which framework best serves that 
> assertion, by claiming the hello world app isn't representative of a larger 
> app.

I would indeed argue that.

> Whaddya want? The video is already 400 megs. 

Only because he's either ignorant or incompetent enough with video to use
the wrong codec for the job.  I transcoded to H.264 and left the audio
alone and dropped it from 378MB to 289MB--just by switching to a superior
codec, no less.  I could have gotten it lower if I'd dinked more, without
noticeable quality loss.

> He's trying to make a certain critcal point and deliver it in a way      
> that harried, overworked, too busy, information overloaded, people       
> can ingest, so a simple paper which could say the same thing in a few    
> K just doesn't do the same job. Thats why there even are are these       
> things called "presentations" even though the technically more efficient 
> written word has existed for thousands of years. As a presentation, it   
> can't get much bigger or take much longer even if there wasn't any tech  
> issue of file size.                                                      

And I think he could have illustrated his point better within the same time
or less.  He wasted an -awful- lot of valuable demo time on the intro
material and lots of needless word flashing.  Actually, all that word
displaying bloats the video size, so it should be held in reserve for when
it's truly needed.  More screen cap, less yap yap would have served him
better, IMHO.  As with real design work--more content, less glitz.
Polished does not have to mean bloated.

> As a presentation, I think it does it's job perfectly, which is merely
> to present the assertion. You are now free to investigate it further by
> more efficient and more thorough means. If you look at the presentation
> and say "This doesn't prove that I should drop everything and switch from
> christianity to plone." Then I think you missed the point.

There are too many missed points between A and Z to actually take his point
to heart.  The aforementioned arguable point about it not being
representative of a larger app is indeed a biggie.  The ratios might not
even remain constant depending on the tasks involved, as different
languages have better/worse implementations for dealing with different
functionality.  What held true for display might reverse in bi-directional,
complex work.

Having failed to adequately prove his points due to bad choices, it doesn't
really do much as a presentation--at least for me.  YMMV, and obviously
does.

mark->
-- 
No matter what your problems, modern medicine can help!
http://members.iglou.com/fairlite/fixital/