Horst Herb wrote: > There seem to be some misconceptions regarding RoR > If we are going to seriously discuss which development platform to use, we > have to stop spreading unfunded FUD first
Hoy! Just because I have pointed out that there are viable alternatives to RoR and that it might be wise to consider the selection in a careful and deliberate fashion does not mean that I have been spreading unfounded FUD (fear, uncertainty, doubt) about RoR. I mentioned that in the opinion of some people I trust, who do not have any axes to grind or barrows to push, and who do development of sophisticated data-intensive Web app development for a living, 40 or 50 hours per week, that it *is* worth evaluating alternatives to RoR, because none of these Web app development frameworks are perfect, all are evolving rapidly and all have strengths and weaknesses. > 1.) RoR does *not* constrain in any way. > This myth probably came up from RoR's "scaffolding" feature - sort of a web > application generator. It creates you a working starting point which you can > either modify to your heart's content or replace completely. You can mix and > match any valid HTML, ruby and Javascript code. I know for sure because I > just did in my Addressbook experiment. > > 2.) RoR's object-relational layer does not constrain in any way either - you > still can use whatever SQL statements you want directly, any time. Just > pointless doing so. Again, I know from doing. I won't trying arguing with you Horst because you have clearly made your mind up. If others are convinced by Horst's advocacy for RoR, and if you need to start coding this week, then go for it and we all look forward to seeing the results - I'm sure that both the pace of progress and the results will be impressive (and I'm not being glib in saying that). > We know by now what we want I think: a practice / EHR software package that > will run on anybody's platform of choice, installable without any hassles, > with good performance, slick and responsive user interface, easy to maintain > and update No argument with that. > Our experience so far with desktop apps and UI toolkits was that at least > installation and deployment will be a major headache. > Some parts (e.g. WYSIWYG text processing) have been found wanting with the > available toolkits, and using 3rd party external software just adds more > trouble to the installation/maintenance/updating headache No argument with that either. > The argument against web interfaces has become obsolete since web apps like > gmail have demonstrated that it can be done (and how it is done) - and they > would even provide the missing widgets (TinyMCE or FCKEditor are good enough > to type referral letters etc. and allow even progress notes with pictures > integrated into the text) Yup, agree, particularly when running on the practice LAN (can be a bit slow on some Internet connections, but as ADSL2 etc rolls out, even that objection fades, and even with existing ADSL pseudo-broadband they are not that slow). > Development tool documentation has been another headache in previous > attempts - while Python documentation as such is excellent, this is not the > case for the 3rd party libraries we used. Yup. > RoR is as good as Python in this aspect - the copious free online > documentation is complemented by fantastic books available (eg "Pragmatic > Programmers" series, and the usual excellent quality publications from > O'Reilly's or Mannig or APress - why, there is even a "Ruby on Rails for > Dummies" available now. That in itself is already an indicator to take it > serious - or, Tim: have you seen any O'Reilly (or similar) books on > Turbogears or Django? A Django book is in the works - see http://www.djangoproject.com/weblog/2006/feb/24/book/ and http://www.amazon.com/Pro-Django-Development-Done-Right/dp/1590597257/ref=pd_sxp_grid_pt_0_0/002-5885541-4228018?ie=UTF8 - although not yet shipping, but about to, I gather. Turbogears book: http://www.blueskyonmars.com/2006/06/09/rapid-web-applications-with-turbogears-book-cover/ and on Amazon: http://www.amazon.com/gp/explorer/0132433885/2/ref=pd_lpo_ase/002-5885541-4228018? - also not yet shipping, but soon. But for all theses frameworks, the online docs and tutorials are just as important, and these seem to be already quite good for both Django and Turbogears. Likewise the online communities. I can't say if they are as good as the equivalents for RoR, but I merely point out that they are also viable alternatives with respect to support and documentation. > Other issues I noted when comparing Ruby and Python: > - Regular expressions are easier and more intuitive to use in Ruby - and > we'll > need lots and lots of them (and other forms of text processing) to let an EHR > system do what we want it to do (= making our lives easier) > - Ruby is better integrated into the net: starting with the "gem" online > code / module repository, svn integration etc: this will make software > maintenance much easier without having to reinvent the wheel OK. Does Ruby have a really high quality implementation on the .NET/Mono framework? How about Trolltech QT bindings? I ask because Windows is here to stay and no matter how slick Web apps can be made, the ability to create GUI front-ends still seems desirable to me, and it would seem to be better if the one base programming language can be used throughout so that common business logic modules can be shared between GUi and Web interfaces etc. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
