Tim Churches wrote: > Note that the above movie is nearly a year old, and both Ruby-on-Rails > (RoR) and especially Django have matured a lot since then. > If you're looking for something a bit more recent Tim you can check out the keynotes at RubyConf 1 (http://blog.scribestudio.com/pages/rails/) from July 06. I'd suggest staying away from the Lucky Stiff and perhaps even Dave Thomas but David Heienemeier Hansson on the past, present and future of Rails is worthwhile.
You might be particularly interested in Martin Fowler's (Yes, that Martin Fowler.) address. Unfortunately his notes are not available on line but you may find them if you rummage through the trash from the downstairs bar. Fowler is in some ways typical of keynoters at a variety of conferences these days, in that he has never used Rails. He therefore talks about what he actually does know about. In his case, this is design patterns and business problems. He presupposes that Ruby's ActiveRecord is based on his ActiveRecord design pattern. He notes that design patterns can be useful for solving particular business problems but that one needs to understand that one design pattern cannot be all things to all men. He then makes some disparaging remarks about java. He charts his own progress from shell and C, to smalltalk, to java, back to smalltalk and then on to python and finally ruby. He prefers ruby to python but not by that much. He states that he likes Rails opinionated attitude. In Perl "there is more than one way to do it". In Ruby, which is loosely based on Perl, "there is only one way to do it (right)". DHH has followed this philosophy in Rails. You can do things anyway you want but Rails will point you down the path of righteousness (consistent file structure, consistent configuration, built in unit test cases, etc. etc.). You may deviate if you are so inclined but other paths will lead to damnation and the eternal torment of unmaintainable code. Fowler likes Ruby's / Rails' rapid development cycles. Development cycles used to be measured in years. His Extreme Programmers at Thoughtworks have been able to bring this down to months, weeks and now less than 10 days. Being able to implement new functions in hours under Rails changes the software programming paradigm for businesses. In the past you would get user requirements, spec out what they want, collect all the use cases, model it in UML and come back 12 months later and deliver the product. Unfortunately what was delivered turned out not to be what the customer really wanted. Why was this? Well Fowler's answer is that the customer does not really know what he wants, although he thinks he does. The solution according to Fowler is to find out what the customer thinks he wants, build it and when it does not turn out, make the minor changes necessary so it does. Agile programming as typified by Rails can allow this sort of flow. It results in a continuous conversation between the developer and the customer. The customer becomes very "engaged" in the software development process and supposedly this results in better, cheaper and faster software. I find this a fascinating concept and I wonder if it my appeal to Tony E. It would require a Ruby programmer, a customer and a cash flow. On the last requirement I am prepared to donate 10 Wednesday afternoons to fund such a project. Horst might throw in a few flaps. If we can find 10 others there may be enough to run a project for 12 months. It does presuppose that Rails is suitable for developing a GP EHR and this may turn out not be the case. David P.S. If we do go ahead, can I fund July, it's my birthday month. P.P.S. Did we ever sort out the tax deduction aspects of this sort of software development?
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
