David Guest wrote: > 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.
No time to attend a film festival right now - I'm busy finishing real-life heavy-duty Web applications - in Python, which we know well and which we know works well. I'll have to leave the green field experimentation with Ruby to others. > 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. Sure. Of course in Python, the maxim has always been "there should be only one (obvious) way to do it". That aim is not always achieved but nevertheless, Python code written by others is very highly maintainable - I have complex Python code maintained and extended but a series of contractors of variable skill levels, and all worked out what it was supposed to do in minutes. > 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. Sure, that's Agile Development 101. And it is the only way to go - although it is still necessary to have a few preliminary workshops to draw up requirements and initial functional specs - but the key is being prepared to extend or modify those specs as you go. Note that such iterative agile development, usually paid for on a developer-hours basis, not as a fixed-price contract to deliver to a fixed specification - can be just as expensive or even costlier than traditional "waterfall" development (which involves drawing up a turgid fixed specification as a pure "thought experiment" whcih overlooks all sorts or eal-life issues and then having programmers slavishly implement that spec) because the number of agile iterations can be large, and you need a good project manager (who is good at keeping the people on the team happy as well as being very au fait with all of the problem domain and design issues as well as all the technical implementation issues). However, the value of agile development is almost always vastly better, because the end result is so much better, even if the costs are the same or slightly higher. > 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. Note that agile development is very, very demanding on the customer to be a) responsive and able to answer important, serious design questions on a *daily* or even *hourly* basis; and b) prepared to think hard about the questions, even when dog-tired. It also needs the programmer(s) to have (or develop) a good understanding of the problem domain. In doing agile-style development on various public health apps, I typically spend 15-30 mins per day on the phone with the primary full-time developer, and another hour or so looking at and commenting on (and testing to some degree) what he has done the previous day (or that same day), plus half a day once per week in front of the whiteboard to discuss and nut out design issues. All comments, issues etc are tracked in a Web-based issues/bug tracking database, linked to wiki-style design documents and notes and the SVN (Subversion) source code revisions system (we use Trac for these purposes - not perfect, but very, very functional - and written in... Python). Let's see - we are running at about 100 issue "tickets" per month - so about 5 per day - some trivial, some involving pages and pages of comments going back-and-forth, design decisions being made etc. Very important to keep a shared record of all these, else you go around in circles. Thus keeping one developer productively occupied in an agile development project takes about 20-25% of my working week. That's why I think that a team of about 5 or 6 developers is the optimal size for a single full-time project manager to oversee. Of course, if the developers are part-time, then things can run on a more relaxed interaction cycle, but agile development does imply that developer questions are answered very promptly and that design decisions are made quickly, and not by convening a committee meeting in a few weeks. > It does > presuppose that Rails is suitable for developing a GP EHR and this may > turn out not be the case. Many of us have an ear out for the sound of the whistle of the Horst Ruby-on-Rails Express, and anxiously wait its arrival on Platform 9 and 3/4. Tim C > > 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? No. Suggest that you approach Brendan Scott about it. TC _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
