------ art_52392_4294032.1146689596503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Kate, I don't think you understand the underlying issue in the post. It's not that Instiki doesn't work... you're right... that's not uncommon. It's WHYit does not work. The reason that Instiki doesn't work under FastCGI because the class load sequence running under FastCGI is a different sequence than the class loading sequence under WEBrick. Because the classes are loaded in a different order, some of the metaprogramming stuff that's happening done "wrong" and thus Instiki doesn't work. If a pretty uncomplex system (Instiki is not very complex) is so very fragile and subject to problems because of the order classes are loaded into the environment, this problem will just get worse in complex systems. Put another way, Ruby programs can break each other because they can change behaviors of the system and/or my classes. This makes Ruby programs unpredictable, especially in moderately complex systems. Unpredictable are not testable. Programs that are not testable cannot be put into production in environments such as insurance, financial services, etc. Thanks, David On 5/3/06, kate rhodes <masukomi / gmail.com> wrote: > > All the things you mention unit tests not handling James? That's where > Functional and Accptance tests come in. > > The fact that Instiki doesn't work under lighttpd is a poor test of if you > should recommend ruby. I would not be hard to find 10 apps in *every* > language that don't work in certain environments their creators didn't > plan > for. Time consuming yes...but not hard. > > > > > > > Do you use unit tests? > > > > > > Yes. And they work just fine for small project, but the cross-product > of > > methods that can pass parameters to other methods in other classes that > > get > > passed down the line, etc. cannot be confidently tested with unit > tests... > > especially when delegates are introduced into the mix. > > > > Unit tests are not a substitute for programmers defining the rules in > > their > > code and having a tool check/enforce those rules. > > > > > > -- > -Kate > (masukomi / gmail.com) > > -- -------- David Pollak's Ruby Playground http://dppruby.com ------ art_52392_4294032.1146689596503--