Hi folks, I''m looking for advice on how to promote RoR in my workplace. Specifically, I''d like to work out a strategy for promoting development in Rails as a new alternative to our existing technology (the usual suspects... mostly Java/Oracle, .NET, PHP, and a bit of Perl here and there). Some background: I work for a fairly large state environmental agency as a web developer. Our internal and external websites are handled by the public affairs office (that''s where I work). We handle application development as far as it relates directly to public or employee information (i.e. calendars, mailing lists, document management). I do most of the new application development in public affairs, and so I''m typically the only one working on any given project. The enterprise application development (for things like financials and environmental database transactions) is handled by a team in IT. I''ve developed a couple of applications in RoR by now, and it was everything it''s supposed to be: quick, intuitive, fun... the apps are great and they''ve gotten some positive feedback. But since it''s not an officially sanctioned language/framework, I''ve decided not to pursue new development for now. However, I''ve done enough RoR development now to really believe that this is the way it should(tm) be done. I think I can develop better applications faster, with cleaner code and more features, than I can with any other environment. In fact, having gone back to PHP for now, I can already see that my code is better than it used to be... it looks about as much like Rails as I can make it. I want to make a case for officially doing some Rails development in my job. If it''s the right tool for the project, then I want it to be available to me, without wondering whether I''ll catch heat for going off the beaten path. I don''t care if the IT folks use it or not - frankly, they''re so deep in Oracle that they''ll never get out - but Rails would be perfect for a lot of my projects. I''m anticipating some skepticism here. A while back someone tried to push for ColdFusion and got shut down... obviously I think Rails is better (not to mention cheaper), but there''s definitely some conservatism going on. So, I''m appealing to the community... what are my strongest arguments here, the ones that the execs will find most compelling? Has this worked for anyone else, and if so, how? How do I get RoR to be officially adopted? Help me build my case... I''m going to take the liberty of anticipating a few of the questions they might ask me: * Will I be able to find a Rails developer when you leave? * How do I know this isn''t just a fad? * Is it secure? Stable? Fast? * Can''t you just do the same thing in PHP? * How do you know it won''t break the other stuff running on the same box? And of course, the main strengths of RoR as I see them: * Free and open-source * Less backend code means more frontend features * Code is human-readable, clean, and organized, therefore maintainable * Active community and widespread adoption * Portable and cross-platform * Built-in eye candy (hey, hearts and minds, right?) * Promotes agile programming practices * Faster development All right then... put yourself in the shoes of the public affairs director, or the head of the application development team, or a project manager - what do you need to hear to give RoR your blessing? Thanks in advance.
On Fri, Feb 10, 2006 at 09:50:30AM -0500, Tony Gambone wrote:> I''m anticipating some skepticism here. A while back someone tried to > push for ColdFusion and got shut down... obviously I think Rails is > better (not to mention cheaper), but there''s definitely some > conservatism going on. So, I''m appealing to the community... what are > my strongest arguments here, the ones that the execs will find most > compelling? Has this worked for anyone else, and if so, how? How do > I get RoR to be officially adopted? Help me build my case...There''s only one argument. "Ruby on Rails will cut overall costs and increase overall quality."> I''m going to take the liberty of anticipating a few of the questions > they might ask me: > > * Will I be able to find a Rails developer when you leave?Point out that this list gets an extremely high volume of posts every day.> * How do I know this isn''t just a fad?That''s always a possibility with things that are new. It could be, but the fundamentals are solid.> * Is it secure? Stable? Fast?So far.> * Can''t you just do the same thing in PHP?Yes, but slower, and it will be more difficult to maintain.> * How do you know it won''t break the other stuff running on the same box?There''s no reason it should, but if you''re worried about that, let''s run a test environment.> And of course, the main strengths of RoR as I see them: > > * Free and open-source > * Less backend code means more frontend features > * Code is human-readable, clean, and organized, therefore maintainable > * Active community and widespread adoption > * Portable and cross-platform > * Built-in eye candy (hey, hearts and minds, right?) > * Promotes agile programming practices > * Faster development > > All right then... put yourself in the shoes of the public affairs > director, or the head of the application development team, or a > project manager - what do you need to hear to give RoR your blessing?"It will cut some money out of my budget." All other arguments should revolve around that. -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.everylastounce.com ] [ http://www.aquick.org/blog ] ............ Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].............Wiki [ http://del.icio.us/fields ] ............. Links
On 2/10/06, Tony Gambone <tonygambone@gmail.com> wrote:> Hi folks, > > I''m looking for advice on how to promote RoR in my workplace. > Specifically, I''d like to work out a strategy for promoting > development in Rails as a new alternative to our existing technology > (the usual suspects... mostly Java/Oracle, .NET, PHP, and a bit of > Perl here and there). > > Some background: I work for a fairly large state environmental agency > as a web developer. Our internal and external websites are handled by > the public affairs office (that''s where I work). We handle > application development as far as it relates directly to public or > employee information (i.e. calendars, mailing lists, document > management). I do most of the new application development in public > affairs, and so I''m typically the only one working on any given > project. >I''ve been consulting for a large state agency in Florida for quite a few years. Java is here to stay (and has its place), but I''m about halfway through a successful campaign to avoid .NET and skip straight to Rails. We''ve got several Rails systems at the moment, all on Oracle, and quite a few systems that use Ruby for scripting or mainframe integration. Selling points that have worked for me: 1. Much easier to teach Ruby to a COBOL or Algol programmer than Java. 2. Runs on many more platforms than .NET. e.g. Linux, Solaris, AIX, IBM UNIX for z/OS (should work, but I haven''t had a reason to try it yet.) 3. Big state agencies (paradoxically) often have very tight budgets. Which would you rather have? $300,000 worth of investment in an application server package, or three expert application developers. 4. I can migrate an application from Oracle to SQL Server or PostgreSQL in 30 minutes. 5. Vastly simplified (read: cheaper) maintenance via integrated test support. 6. There are fewer books, but they are pretty much all excellent. 9 Java or .NET books out of 10 are garbage, and it takes time to find the ones that you actually want to hand around. The last stumbling block is the typical "How will we find programmers?" issue. I''ve chosen to basically ignore this one. That''s what they said about Java, and then about .NET, and now those are ''standards''.
Keith Braithwaite and Tim Joyce presented an interesting talk at XPDay in London. The trust of the argument is that you can use rails to create corporate nano apps to reduce the cost of change to the organisation. It''s an interesting argument - a real step change from what most organisations do. See for yourself http://www.keithbraithwaite.demon.co.uk/professional/ presentations/2005/xpday/AgileArchitecture.pdf I thought it was worth sharing! The business value arguments are the most compelling for me. Andy On 10 Feb 2006, at 15:37, Wilson Bilkovich wrote:> On 2/10/06, Tony Gambone <tonygambone@gmail.com> wrote: >> Hi folks, >> >> I''m looking for advice on how to promote RoR in my workplace. >> Specifically, I''d like to work out a strategy for promoting >> development in Rails as a new alternative to our existing technology >> (the usual suspects... mostly Java/Oracle, .NET, PHP, and a bit of >> Perl here and there). >> >> Some background: I work for a fairly large state environmental agency >> as a web developer. Our internal and external websites are >> handled by >> the public affairs office (that''s where I work). We handle >> application development as far as it relates directly to public or >> employee information (i.e. calendars, mailing lists, document >> management). I do most of the new application development in public >> affairs, and so I''m typically the only one working on any given >> project. >> > > I''ve been consulting for a large state agency in Florida for quite a > few years. Java is here to stay (and has its place), but I''m about > halfway through a successful campaign to avoid .NET and skip straight > to Rails. > We''ve got several Rails systems at the moment, all on Oracle, and > quite a few systems that use Ruby for scripting or mainframe > integration. > > Selling points that have worked for me: > 1. Much easier to teach Ruby to a COBOL or Algol programmer than Java. > 2. Runs on many more platforms than .NET. e.g. Linux, Solaris, AIX, > IBM UNIX for z/OS (should work, but I haven''t had a reason to try it > yet.) > 3. Big state agencies (paradoxically) often have very tight budgets. > Which would you rather have? $300,000 worth of investment in an > application server package, or three expert application developers. > 4. I can migrate an application from Oracle to SQL Server or > PostgreSQL in 30 minutes. > 5. Vastly simplified (read: cheaper) maintenance via integrated > test support. > 6. There are fewer books, but they are pretty much all excellent. 9 > Java or .NET books out of 10 are garbage, and it takes time to find > the ones that you actually want to hand around. > > The last stumbling block is the typical "How will we find > programmers?" issue. I''ve chosen to basically ignore this one. > That''s what they said about Java, and then about .NET, and now those > are ''standards''. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
To me there are a couple of aspects more to enterprise computing than scalability and stability. Rails is no doubt scalable and stable but especially enterprise integration is a big issue - for me at least. To restate Martin Fowler (http://www.eaipatterns.com/) "Enterprise integration is the task of making disparate applications work together to produce a unified set of functionality. These applications can be custom developed in house or purchased from third-party vendors. They likely run on multiple computers, which may represent multiple platforms, and may be geographically dispersed. Some of the applications may be run outside of the enterprise by business partners or customers. Other applications might not have been designed with integration in mind and are difficult to chagne. These issues and others like them make application integration complicated." I''m sure Rails can handle many things but enterprise integration issues are a difficult ball game. When it comes to integrating data and data streams from disparate sources, we will need a strong architecture for doing so. I''m thinking message queues, RPI etc. Rails is no doubt one of the strongest frameworks for web development. But what do I do when I have a CICS back end? Many enterprise environments are a collection of systems that are very old and run on exotic hardware and OS. A lot of development time is used writing web front ends for such systms. Rails is definetely there when it comes to web applications. It''s like Turbo Pascal 6 for web development (TP6 included an innovative API - Turbo Vision - for user interface development), but I don''t yet think it''s ready to apply on many problems in the enterprise domain. Kasper On Friday, February 10, 2006, at 9:50 AM, Tony Gambone wrote:>Hi folks, > >I''m looking for advice on how to promote RoR in my workplace. >Specifically, I''d like to work out a strategy for promoting >development in Rails as a new alternative to our existing technology >(the usual suspects... mostly Java/Oracle, .NET, PHP, and a bit of >Perl here and there). > >Some background: I work for a fairly large state environmental agency >as a web developer. Our internal and external websites are handled by >the public affairs office (that''s where I work). We handle >application development as far as it relates directly to public or >employee information (i.e. calendars, mailing lists, document >management). I do most of the new application development in public >affairs, and so I''m typically the only one working on any given >project. > >The enterprise application development (for things like financials and >environmental database transactions) is handled by a team in IT. > >I''ve developed a couple of applications in RoR by now, and it was >everything it''s supposed to be: quick, intuitive, fun... the apps are >great and they''ve gotten some positive feedback. But since it''s not >an officially sanctioned language/framework, I''ve decided not to >pursue new development for now. However, I''ve done enough RoR >development now to really believe that this is the way it should(tm) >be done. I think I can develop better applications faster, with >cleaner code and more features, than I can with any other environment. > In fact, having gone back to PHP for now, I can already see that my >code is better than it used to be... it looks about as much like Rails >as I can make it. > >I want to make a case for officially doing some Rails development in >my job. If it''s the right tool for the project, then I want it to be >available to me, without wondering whether I''ll catch heat for going >off the beaten path. I don''t care if the IT folks use it or not - >frankly, they''re so deep in Oracle that they''ll never get out - but >Rails would be perfect for a lot of my projects. > >I''m anticipating some skepticism here. A while back someone tried to >push for ColdFusion and got shut down... obviously I think Rails is >better (not to mention cheaper), but there''s definitely some >conservatism going on. So, I''m appealing to the community... what are >my strongest arguments here, the ones that the execs will find most >compelling? Has this worked for anyone else, and if so, how? How do >I get RoR to be officially adopted? Help me build my case... > >I''m going to take the liberty of anticipating a few of the questions >they might ask me: > > * Will I be able to find a Rails developer when you leave? > * How do I know this isn''t just a fad? > * Is it secure? Stable? Fast? > * Can''t you just do the same thing in PHP? > * How do you know it won''t break the other stuff running on the same box? > >And of course, the main strengths of RoR as I see them: > > * Free and open-source > * Less backend code means more frontend features > * Code is human-readable, clean, and organized, therefore maintainable > * Active community and widespread adoption > * Portable and cross-platform > * Built-in eye candy (hey, hearts and minds, right?) > * Promotes agile programming practices > * Faster development > >All right then... put yourself in the shoes of the public affairs >director, or the head of the application development team, or a >project manager - what do you need to hear to give RoR your blessing? > >Thanks in advance. >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-- Posted with http://DevLists.com. Sign up and save your time!
Karl Brodowsky
2006-Feb-10 20:00 UTC
Ruby, Rails and SAP (Re: [Rails] Advocating RoR in the enterprise?)
I have found some library that claims to be capable of interfacing SAP from Ruby. Is there any idea about the usefulness and stability of this? This would be some step toward enterprise integration, in certain environments. I know that the Java guys have this kind of interface actually working... Best regards, Karl
Thanks for your responses. Seems like the main dish here is cost/benefit, with a side of agility... which of course is really just cost/benefit anyway. Here''s what I''m seeing: * Rails is cheaper because it has no initial purchase cost. * Rails is cheaper because it''s easier to maintain. * Rails is cheaper because it''s easier to move it to a different platform if you need to. * Rails is cheaper because you can be up and running faster than with Java or .NET. * Rails delivers more value because you can quickly develop small applications that support your business processes. I''m lucky (as I see it) not to actually have to develop "enterprise applications" per se - I just have to develop applications in an enterprise. I''ve managed to stay pretty agile, even without Rails, because I work on my own. But I will eventually have to justify my use of Rails to people who _do_ develop enterprise applications, so I need to justify it from their perspective as well. Thanks again for your responses - I think I''ve got something to go on now. * Kasper Weibel <devlists-rubyonrails@devlists.com> [2006-02-10 18:20:12]:> To me there are a couple of aspects more to enterprise computing than > scalability and stability. Rails is no doubt scalable and stable but > especially enterprise integration is a big issue - for me at least. > > To restate Martin Fowler (http://www.eaipatterns.com/) > > "Enterprise integration is the task of making disparate applications > work together to produce a unified set of functionality. These > applications can be custom developed in house or purchased from > third-party vendors. They likely run on multiple computers, which may > represent multiple platforms, and may be geographically dispersed. Some > of the applications may be run outside of the enterprise by business > partners or customers. Other applications might not have been designed > with integration in mind and are difficult to chagne. These issues and > others like them make application integration complicated." > > I''m sure Rails can handle many things but enterprise integration issues > are a difficult ball game. When it comes to integrating data and data > streams from disparate sources, we will need a strong architecture for > doing so. I''m thinking message queues, RPI etc. > > Rails is no doubt one of the strongest frameworks for web development. > But what do I do when I have a CICS back end? Many enterprise > environments are a collection of systems that are very old and run on > exotic hardware and OS. A lot of development time is used writing web > front ends for such systms. > > Rails is definetely there when it comes to web applications. It''s like > Turbo Pascal 6 for web development (TP6 included an innovative API - > Turbo Vision - for user interface development), but I don''t yet think > it''s ready to apply on many problems in the enterprise domain. > > Kasper > > On Friday, February 10, 2006, at 9:50 AM, Tony Gambone wrote: > >Hi folks, > > > >I''m looking for advice on how to promote RoR in my workplace. > >Specifically, I''d like to work out a strategy for promoting > >development in Rails as a new alternative to our existing technology > >(the usual suspects... mostly Java/Oracle, .NET, PHP, and a bit of > >Perl here and there). > > > >Some background: I work for a fairly large state environmental agency > >as a web developer. Our internal and external websites are handled by > >the public affairs office (that''s where I work). We handle > >application development as far as it relates directly to public or > >employee information (i.e. calendars, mailing lists, document > >management). I do most of the new application development in public > >affairs, and so I''m typically the only one working on any given > >project. > > > >The enterprise application development (for things like financials and > >environmental database transactions) is handled by a team in IT. > > > >I''ve developed a couple of applications in RoR by now, and it was > >everything it''s supposed to be: quick, intuitive, fun... the apps are > >great and they''ve gotten some positive feedback. But since it''s not > >an officially sanctioned language/framework, I''ve decided not to > >pursue new development for now. However, I''ve done enough RoR > >development now to really believe that this is the way it should(tm) > >be done. I think I can develop better applications faster, with > >cleaner code and more features, than I can with any other environment. > > In fact, having gone back to PHP for now, I can already see that my > >code is better than it used to be... it looks about as much like Rails > >as I can make it. > > > >I want to make a case for officially doing some Rails development in > >my job. If it''s the right tool for the project, then I want it to be > >available to me, without wondering whether I''ll catch heat for going > >off the beaten path. I don''t care if the IT folks use it or not - > >frankly, they''re so deep in Oracle that they''ll never get out - but > >Rails would be perfect for a lot of my projects. > > > >I''m anticipating some skepticism here. A while back someone tried to > >push for ColdFusion and got shut down... obviously I think Rails is > >better (not to mention cheaper), but there''s definitely some > >conservatism going on. So, I''m appealing to the community... what are > >my strongest arguments here, the ones that the execs will find most > >compelling? Has this worked for anyone else, and if so, how? How do > >I get RoR to be officially adopted? Help me build my case... > > > >I''m going to take the liberty of anticipating a few of the questions > >they might ask me: > > > > * Will I be able to find a Rails developer when you leave? > > * How do I know this isn''t just a fad? > > * Is it secure? Stable? Fast? > > * Can''t you just do the same thing in PHP? > > * How do you know it won''t break the other stuff running on the same box? > > > >And of course, the main strengths of RoR as I see them: > > > > * Free and open-source > > * Less backend code means more frontend features > > * Code is human-readable, clean, and organized, therefore maintainable > > * Active community and widespread adoption > > * Portable and cross-platform > > * Built-in eye candy (hey, hearts and minds, right?) > > * Promotes agile programming practices > > * Faster development > > > >All right then... put yourself in the shoes of the public affairs > >director, or the head of the application development team, or a > >project manager - what do you need to hear to give RoR your blessing? > > > >Thanks in advance. > >_______________________________________________ > >Rails mailing list > >Rails@lists.rubyonrails.org > >http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > -- > Posted with http://DevLists.com. Sign up and save your time! > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 10 Feb 2006 18:20:12 -0000, Kasper Weibel <devlists-rubyonrails@devlists.com> wrote:> Rails is no doubt one of the strongest frameworks for web development. > But what do I do when I have a CICS back end? Many enterprise > environments are a collection of systems that are very old and run on > exotic hardware and OS. A lot of development time is used writing web > front ends for such systms. >Sorry to pick out just one of your points, but I''ve done this with IMS on z/OS back ends. CICS should be fairly similar (or identical, depending on the tools you have access to.) Ruby can invoke JDBC libraries for legacy data access. Ruby has bindings for ActiveMQ, which you can connect to pretty much any messaging system (such as IBM MQSeries) via an ESB. Right now there''s a bit of a gap in the emulation category; if you can afford IBM HATS or Seagull Transidiom, you can invoke those services from Ruby. If I can find the time, I intend to write a ''pure'' Ruby 3270 library, to make certain of these things easier. Obviously there are still things that are easier in Java (and probably always will be), but don''t count Ruby out of this realm without taking a serious look. What would be really, really cool would be a way to embed Ruby code into BPEL, the way you can currently with Java. I haven''t had to do much with BPEL yet, but hopefully someone will have explored this before I encounter it. :)
I don''t know... you might want to stay away from points 1 and 3. I do (near)enterprise java development and I''ve never spent a dime... and my clients have only spent money on developers. And I think there are actually less cross-platform issues with Java /right now/ than with ruby (that''ll change though). You know, thus far into my rails experience, I''d say the best thing it offers is Ruby: a statically-typed language like Java just can''t compete with a well-designed dynamically typed language like Ruby for ease of maintenance and flexibility. (For example: XMLBuilder... being able to type method calls that don''t actually exist, but the language is smart enough to just make an xml element out of that... that''s cool!) Unfortunately, this is the sort of explanation that makes management-type''s eyes glaze over, so... Well, I''d say you should pitch it for little internal apps at first. Handy little db maintenance stuff and whatnot. You can point out that it''s a great little tool to have in your developers'' toolbox... like perl but better. :-) b Tony Gambone wrote:> Thanks for your responses. Seems like the main dish here is cost/benefit, with a side of agility... which of course is really just cost/benefit anyway. Here''s what I''m seeing: > > * Rails is cheaper because it has no initial purchase cost. > * Rails is cheaper because it''s easier to maintain. > * Rails is cheaper because it''s easier to move it to a different platform if you need to. > * Rails is cheaper because you can be up and running faster than with Java or .NET. > * Rails delivers more value because you can quickly develop small applications that support your business processes. > > I''m lucky (as I see it) not to actually have to develop "enterprise applications" per se - I just have to develop applications in an enterprise. I''ve managed to stay pretty agile, even without Rails, because I work on my own. But I will eventually have to justify my use of Rails to people who _do_ develop enterprise applications, so I need to justify it from their perspective as well. > > Thanks again for your responses - I think I''ve got something to go on now. > > > * Kasper Weibel <devlists-rubyonrails@devlists.com> [2006-02-10 18:20:12]: > > >>To me there are a couple of aspects more to enterprise computing than >>scalability and stability. Rails is no doubt scalable and stable but >>especially enterprise integration is a big issue - for me at least. >> >>To restate Martin Fowler (http://www.eaipatterns.com/) >> >>"Enterprise integration is the task of making disparate applications >>work together to produce a unified set of functionality. These >>applications can be custom developed in house or purchased from >>third-party vendors. They likely run on multiple computers, which may >>represent multiple platforms, and may be geographically dispersed. Some >>of the applications may be run outside of the enterprise by business >>partners or customers. Other applications might not have been designed >>with integration in mind and are difficult to chagne. These issues and >>others like them make application integration complicated." >> >>I''m sure Rails can handle many things but enterprise integration issues >>are a difficult ball game. When it comes to integrating data and data >>streams from disparate sources, we will need a strong architecture for >>doing so. I''m thinking message queues, RPI etc. >> >>Rails is no doubt one of the strongest frameworks for web development. >>But what do I do when I have a CICS back end? Many enterprise >>environments are a collection of systems that are very old and run on >>exotic hardware and OS. A lot of development time is used writing web >>front ends for such systms. >> >>Rails is definetely there when it comes to web applications. It''s like >>Turbo Pascal 6 for web development (TP6 included an innovative API - >>Turbo Vision - for user interface development), but I don''t yet think >>it''s ready to apply on many problems in the enterprise domain. >> >>Kasper >> >>On Friday, February 10, 2006, at 9:50 AM, Tony Gambone wrote: >> >>>Hi folks, >>> >>>I''m looking for advice on how to promote RoR in my workplace. >>>Specifically, I''d like to work out a strategy for promoting >>>development in Rails as a new alternative to our existing technology >>>(the usual suspects... mostly Java/Oracle, .NET, PHP, and a bit of >>>Perl here and there). >>> >>>Some background: I work for a fairly large state environmental agency >>>as a web developer. Our internal and external websites are handled by >>>the public affairs office (that''s where I work). We handle >>>application development as far as it relates directly to public or >>>employee information (i.e. calendars, mailing lists, document >>>management). I do most of the new application development in public >>>affairs, and so I''m typically the only one working on any given >>>project. >>> >>>The enterprise application development (for things like financials and >>>environmental database transactions) is handled by a team in IT. >>> >>>I''ve developed a couple of applications in RoR by now, and it was >>>everything it''s supposed to be: quick, intuitive, fun... the apps are >>>great and they''ve gotten some positive feedback. But since it''s not >>>an officially sanctioned language/framework, I''ve decided not to >>>pursue new development for now. However, I''ve done enough RoR >>>development now to really believe that this is the way it should(tm) >>>be done. I think I can develop better applications faster, with >>>cleaner code and more features, than I can with any other environment. >>>In fact, having gone back to PHP for now, I can already see that my >>>code is better than it used to be... it looks about as much like Rails >>>as I can make it. >>> >>>I want to make a case for officially doing some Rails development in >>>my job. If it''s the right tool for the project, then I want it to be >>>available to me, without wondering whether I''ll catch heat for going >>>off the beaten path. I don''t care if the IT folks use it or not - >>>frankly, they''re so deep in Oracle that they''ll never get out - but >>>Rails would be perfect for a lot of my projects. >>> >>>I''m anticipating some skepticism here. A while back someone tried to >>>push for ColdFusion and got shut down... obviously I think Rails is >>>better (not to mention cheaper), but there''s definitely some >>>conservatism going on. So, I''m appealing to the community... what are >>>my strongest arguments here, the ones that the execs will find most >>>compelling? Has this worked for anyone else, and if so, how? How do >>>I get RoR to be officially adopted? Help me build my case... >>> >>>I''m going to take the liberty of anticipating a few of the questions >>>they might ask me: >>> >>> * Will I be able to find a Rails developer when you leave? >>> * How do I know this isn''t just a fad? >>> * Is it secure? Stable? Fast? >>> * Can''t you just do the same thing in PHP? >>> * How do you know it won''t break the other stuff running on the same box? >>> >>>And of course, the main strengths of RoR as I see them: >>> >>> * Free and open-source >>> * Less backend code means more frontend features >>> * Code is human-readable, clean, and organized, therefore maintainable >>> * Active community and widespread adoption >>> * Portable and cross-platform >>> * Built-in eye candy (hey, hearts and minds, right?) >>> * Promotes agile programming practices >>> * Faster development >>> >>>All right then... put yourself in the shoes of the public affairs >>>director, or the head of the application development team, or a >>>project manager - what do you need to hear to give RoR your blessing? >>> >>>Thanks in advance. >>>_______________________________________________ >>>Rails mailing list >>>Rails@lists.rubyonrails.org >>>http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> >> >> >>-- >>Posted with http://DevLists.com. Sign up and save your time! >>_______________________________________________ >>Rails mailing list >>Rails@lists.rubyonrails.org >>http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 10 Feb 2006 18:20:12 -0000, Kasper Weibel <devlists-rubyonrails@devlists.com> wrote:> Rails is no doubt one of the strongest frameworks for web development. > But what do I do when I have a CICS back end? Many enterprise > environments are a collection of systems that are very old and run on > exotic hardware and OS. A lot of development time is used writing web > front ends for such systms.I''m pulling a Wilson here :) I think the only reason anyone might consider this a valid point is because there haven''t been many integration projects with Rails yet. The vast majority of people using Rails are early adopters that aren''t totally chained down by beuaracracy. The beuaracracy and strict requirements generally come about because there are giant legacy systems in place, so people who don''t have those limitations probably don''t have anything to integrate in the first place. It can be done though. Ezra Zygmuntowicz''s story "From start to launch: http://yakimaherald.com" presents an excellent example. He uses a number of different legacy data sources to power the site, and developed the whole thing by himself in a few months. Java.chance => nil. Anyway the point is not to toot Ezra''s horn (though imo he deserves it), but to show that writing integrated apps with Rails is not only feasible, but perhaps more practical than using current standard technologies. The problem is that most people who have to write integrated apps aren''t even given the choice to use Rails, so it''s not very common place. I have a feeling that will change soon though. Pat
> It can be done though. Ezra Zygmuntowicz''s story "From start to > launch: http://yakimaherald.com" presents an excellent example. He > uses a number of different legacy data sources to power the site, and > developed the whole thing by himself in a few months. Java.chance => > nil.Maybe I should post the link :) http://brainspl.at/articles/2005/11/03/from-start-to-launch-http-yakimaherald-com
Just some points that might be encountered when advocating Ruby + Rails: 1. How about teaching Java-guys? I see some difficulties, because for becoming a Java-guy, you have to invest really much. Having read 30 books is not enough to be an expert... So, having invested so much, it just must not be true that there is any kind of easier way. 2. Ruby/Rails productivity is not fair. It''s just a quick and dirty kind of thing, for prototypes. 3. If you use tool xyz and really know your Java stuff, you are as productive in Java as in Ruby+Rails. 4. Pretty much the same platforms that are running Ruby would also be running Java and Perl. (But there is a huge advantage over ??oft-stuff.) 5. You can get a pretty decent open source application server package from JBoss. It''s more the cost of maintaining this beast, but you have to maintain a database anyway, so even that costs is minor. 6. Being able to migrate Ruby-on-Rails from one DB to another does not help. You can''t migrate the data so easily. (So it''s more the idea that you develop without the pain of having to maintain Oracle for the developers, but have test and production systems with Oracle. It is mandatory off course to test with the same DB-product that is used on the productive system.) 7. Being DB-independent means that you throw away a lot of cool and performance relevant features of Oracle (or of DB-product XYZ on which you specialize) 8. I don''t find it really difficult to find the good Java (or Perl or...) books. Amazon has these stars for good books and they tend to be quite useful. (But you need much more Java-books to do the same that you have achieve after having read two Ruby-Books.) 9. The issue "how to find developers" is there. I agree, it''s not really a problem. But we have to admit that Java was specifically designed as a compromise between what would be a good language and what is easy to learn for the C- and C++-guys. Ruby neglected this requirement and is not so close to the common syntax of C, C++, Java, Perl and Javascript. 10. There are much more libraries for language XYZ where XYZ is one of (Fortran, Cobol, Java, C, C++, Perl, Python, PHP) 11. There are more long term experiences of successful applications written in XYZ (take the same list) 12. It is not clear if Ruby on Rails is going to make it or if XYZ is the future. (take the same list, don''t forget Cobol and Fortran.. ;-) ) 13. This script stuff is no serious development. (-> use Java, C, C++, Cobol, Fortran and not PHP, Perl, Python, Ruby, Shell-Scripts..) I do not want to disadvocate Rails. Some of these points are even easily challenged, some are real concerns that must be weighted against the advantages. It is good to know what arguments might come, when advocating RoR. Did I miss any point? Or any language XYZ? Best regards, Karl
I can tell you how it happened here at Pearson Education (largely a Java shop with pocket of .Net), if that is of any use to you. Nineteen months ago I needed to automate some tasks against our Perforce SCM system and Tony Smith, who has written several of the various language bindings for the P4 API recommended P4Ruby. I grabbed up used copies of the old PickAxe and the Ruby Way, got to work learning the language and produced a few command line utilities that became part of our build process. When a need arose for a few simple web based reports, I turned back to Ruby, and a few months later we had an array of Ruby based tools. A year later I joined a small group (4 developers) that had been writing .Net apps. When we lost the strongest .Net developer on the team left our manager, seeing how productive one can be with Ruby and faced with bringing in a new hire, decided to focus on Ruby going forward and we posted our first position for a Rubist. I now regularly present Ruby to others in the enterprise and it is gaining ground. In fact I recently saw Ruby mentioned in a PowerPoint presentation given by one of the higher ups describing a major strategic initiative. As far as arguments and strategy go I simply 1. used Ruby whenever the language platform was not dictated and it was a good fit, 2. was sure to tell people that I found Ruby a very productive tool. Nothing more was required. In my experience, being patient and letting my productivity with Ruby do the talking has been a very effective argument. I try to do work that is fairly visible and which I am confident will create value for others in the organization. When end users are excited, people are interested in hearing the story of why it works and it makes things stick in the brain. -- John-Mason Shackelford Software Developer Pearson Educational Measurement 2510 North Dodge St. Iowa City, IA 52245 ph. 319-354-9200x6214 john-mason.shackelford@pearson.com http://pearsonedmeasurement.com
Tony, Tony Gambone wrote:> Some background: I work for a fairly large state environmental agency > as a web developer. Our internal and external websites are handled by > the public affairs office (that''s where I work). We handle > application development as far as it relates directly to public or > employee information (i.e. calendars, mailing lists, document > management). I do most of the new application development in public > affairs, and so I''m typically the only one working on any given > project. > >Coming from a large government background it really comes down to CYA (Cover Your Ass). The decision makers are conservative because no one ever got fired for using Microsoft, IBM, etc...> I''m going to take the liberty of anticipating a few of the questions > they might ask me: > > * Will I be able to find a Rails developer when you leave? >How will they be able to find a .NET or JAVA developer when you leave? The more popular a language it seems the greater the shortage of programmers for that language. There maybe 100,000 .NET developers and 250,000 Java developers and only 10,000 Ruby developers. However that is meaningless if there are 200,000 .NET jobs, 500,000 Java jobs and only 8,000 Ruby jobs. Who do you think will have a better time finding a programmer?> * How do I know this isn''t just a fad? >This is the most bunk argument out there. Simply put, how do you know that proprietary vendor will be in business tomorrow? The minute they scoff. Point them to TWO large and SIMPLE samples. 1. Peoplesoft. Ask how customers who bought $20 million in software stack are looking for 3 years of support before their product is end of life? You see there is ALWAYS a bigger fish. So today you use platform X, Y, Z what if it gets bought out and shelved? If you were around in the 80''s Borland seemed like the big tool provider. Until Microsoft entered that space. 2. RIM (Blackberry). For those of you who say no one is bigger than Microsoft so they are safe. There are these little things called patents. They can effectively render a project in a state of hostage over night. Look at what RIM is facing with a little patent dispute. If you think that Microsoft is immune they have had to deal with this at least two times in recent memory. One of the major ones was with a patent concerning MS SQL Server. Rails is immune to #1 because you have the source. If someone stops development and turns it proprietary you have the code to keep extending it. #2 you are in control of, since you have the code you can verify patent disputes without having to wait for a trial to unearth things. You can make your own decisions and do your own due diligence.> * Is it secure? Stable? Fast? >I think sufficient demos should cover stable and fast. Nothing is "secure" just by being. I think it is more indicative of how your IT group puts emphasis into development.> * Can''t you just do the same thing in PHP? >Yes and no. I can drive from Phoenix to New York, but it is not as nearly convenient or timely as flying from Phoenix to New York. Of course, a misguided skeptic might suggest that flying is much more dangerous than driving because after all people generally die when a plane crashes.> * How do you know it won''t break the other stuff running on the same box? > >Easy answer is run it on its own box. :) I sufficient box now a days is well under $2500. -- Derek Neighbors Integrum Technologies http://www.integrumtech.com "Redefining IT"
On 2/11/06, Karl Brodowsky <listen@brodowsky.com> wrote: <snip>> I do not want to disadvocate Rails. Some of these points are even > easily challenged, some are real concerns that must be weighted against > the advantages. It is good to know what arguments might come, when > advocating RoR. Did I miss any point? Or any language XYZ? >Just one. "RoR does not work with our existing emphasis on integrity in the database through appropriate use of rules, triggers and functions." The only answer to that is, "Stop using the database to enforce access, integrity, and business rules." That''s not going to fly in a lot of places. Particularly an Oracle shop. - Ian> Best regards, > > Karl > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> "RoR does not work with our existing emphasis on integrity in the > database through appropriate use of rules, triggers and functions."> The only answer to that is, "Stop using the database to enforce > access, integrity, and business rules." That''s not going to fly in a > lot of places. Particularly an Oracle shop.I''m wondering: in some apps concurrent data modifications is likely to happen. If the integrity is not guaranteed at the database level but in the code, then I probably have to use transactions. Just a survey but how many people actually use transactions in RoR applications ? cheers Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060215/cbe63755/attachment.html
> > I can tell you how it happened here at Pearson Education (largely a > Java shop with pocket of .Net), if that is of any use to you. > > Nineteen months ago I needed to automate some tasks against our > Perforce SCM system and Tony Smith, who has written several of the > various language bindings for the P4 API recommended P4Ruby. I grabbed > up used copies of the old PickAxe and the Ruby Way, got to work > learning the language and produced a few command line utilities that > became part of our build process. When a need arose for a few simple > web based reports, I turned back to Ruby, and a few months later we > had an array of Ruby based tools. A year later I joined a small group > (4 developers) that had been writing .Net apps. When we lost the > strongest .Net developer on the team left our manager, seeing how > productive one can be with Ruby and faced with bringing in a new hire, > decided to focus on Ruby going forward and we posted our first > position for a Rubist. I now regularly present Ruby to others in the > enterprise and it is gaining ground. In fact I recently saw Ruby > mentioned in a PowerPoint presentation given by one of the higher ups > describing a major strategic initiative. > > As far as arguments and strategy go I simply 1. used Ruby whenever the > language platform was not dictated and it was a good fit, 2. was sure > to tell people that I found Ruby a very productive tool. Nothing more > was required. In my experience, being patient and letting my > productivity with Ruby do the talking has been a very effective > argument. I try to do work that is fairly visible and which I am > confident will create value for others in the organization. When end > users are excited, people are interested in hearing the story of why > it works and it makes things stick in the brain.I agree wholeheartly. I''ve been doing something similar here - develop my ruby knowledge on everyday tools (scripts, builds) to realise I find it very productive (and it shows). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060215/9145883e/attachment-0001.html
Additionally in many shops these days more than one language may be workign with a database at any given time. While the idea of "enforce it int he code" is a nice one for a small development team with oen tool it makes a lot of sense to allow the database to "protect itself" and assure the integrity at that level. Soulhuntre ---------- http://www.girl2.com - my girls http://www.the-estate.com <http://www.the-estate.com/> - my legacy http://wiki.thegreybook.com <http://wiki.thegreybook.com/> - my project http://weblog.soulhuntre.com <http://weblog.soulhuntre.com/> - my thoughts -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060215/60af5f0a/attachment.html
* Ian Harding (iharding@destinydata.com) [060215 10:48]:> Just one. > > "RoR does not work with our existing emphasis on integrity in the > database through appropriate use of rules, triggers and functions." > > The only answer to that is, "Stop using the database to enforce > access, integrity, and business rules." That''s not going to fly in a > lot of places. Particularly an Oracle shop.There''s another answer, "Yes, Rails does work in that environment, it just takes a wee bit more work." We''re running Rails on Oracle and Postgres (meaning that we can deploy to either and our continuous integration system only says "success" when the app works on both platforms correctly) for our application and we have a *lot* of constraints, we have triggers, etc. We have all the auditing and permissioning and constraints headaches that come with being HIPAA/Sarbanes-Oxley/clinical trials compliant. That *requires* that you get help from the database, requires that you can''t allow people to delete or modify certain types of information (and other types will let you change but with strict audit requirements), requires that viewing certain info gets audited, etc. We had to change some things about how we use fixtures, for example, and we''re building our database by SQL scripts still (but mostly because we started before Migrations were available), but Rails works just fine in this sort of environment. Rick -- http://www.rickbradley.com MUPRN: 44 | needed attention random email haiku | to issues of IP rights in | the digital world.
On Feb 15, 2006, at 7:56 AM, Thibaut Barr?re wrote:> Just a survey but how many people actually use transactions in RoR > applications ?Raises hand! Perhaps it comes from not having started with MySQL, but instead a DB that supported transactions. -- -- Tom Mornini
>Just one. > >"RoR does not work with our existing emphasis on integrity in the >database through appropriate use of rules, triggers and functions." > >The only answer to that is, "Stop using the database to enforce >access, integrity, and business rules." That''s not going to fly in a >lot of places. Particularly an Oracle shop. > >- Ian > >This is one of the few points where I disagree with DHH, but then this is because I usually have more than one thing touching the DB. If it was only the Rails application using it, maybe then, but I intend to have other things reading and writing data from the database, so I want some more things to protect myself from the users.
* Tom Mornini (tmornini@infomania.com) [060215 12:48]:> On Feb 15, 2006, at 7:56 AM, Thibaut Barr?re wrote: > > >Just a survey but how many people actually use transactions in RoR > >applications ? > > Raises hand! > > Perhaps it comes from not having started with MySQL, but instead a DB > that supported transactions.I''ll have to raise my hand as we''re using them too -- no way around it. Rick -- http://www.rickbradley.com MUPRN: 196 | a @home address, random email haiku | and your 65.2.x.x address is well | within their control.
On Feb 15, 2006, at 10:03 AM, Grant Johnson wrote:>> The only answer to that is, "Stop using the database to enforce >> access, integrity, and business rules." That''s not going to fly in a >> lot of places. Particularly an Oracle shop. > > This is one of the few points where I disagree with DHH, but then > this is because I usually have more than one thing touching the > DB. If it was only the Rails application using it, maybe then, > but I intend to have other things reading and writing data from the > database, so I want some more things to protect myself from the users.You know, I can completely empathize, because I felt *exactly* the same way at first. However...new applications are the Rails sweet spot. We all love Rails so much that we''d like to use it all of the time, but if you think about it, Rails is at its best when you''re creating on a new application where you can follow all the conventions. So, if you''re creating a new application, and you want outside access to the data, it really makes a great deal more sense (particularly moving into the future) to provide that access via web services (pick your favorite) and Rails makes that pretty easy to provide. If you really get down to it, why in the world would anyone build a new application today predicated on the assumption that other systems will directly access the data? That, to me, is extremely bad encapsulation! We OO people preach encapsulation at code level all of the time, and then many of us (myself included!) have lately been suggesting breaking it at the application level, which is just plain wrong. -- -- Tom Mornini
> This is one of the few points where I disagree with DHH, but then this > is because I usually have more than one thing touching the DB. If it > was only the Rails application using it, maybe then, but I intend to > have other things reading and writing data from the database, so I want > some more things to protect myself from the users.Then you''re not disagreeing with me at all. I too consider clever databases a must if you integrate through the database. What I''m saying is that you don''t need to and should not desire to integrate through the database. There are a world of other integration opportunities that does not force you to get a clever database. So its more of an architectural choice (damn, didn''t that sound enterprise!). I''m saying that integration through the database is a design smell and you should avoid. IF you''re able to avoid it, then clever databases makes no sense. If your design, however, is already smelly, then do stack up on the deodorant. It might not work as well as just getting clean, but at least the stench won''t be as bad most of the time. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
> > Just a survey but how many people actually use transactions in RoR > > applications ? > > Raises hand! > > Perhaps it comes from not having started with MySQL, but instead a DB > that supported transactions.What on earth are you guys talking about?! Just by using Active Record, you''re using transactions. All state changes persisted to the database happens in a automatic transaction. And if you''re mixing two state changes that doesn''t automatically live in the same transaction, then you''re _crazy_ if you''re not using transactions. How does this have ANYTHING to do with triggers or stored procedures?! Also, MySQL has supported transactions since the 90''ies through InnoDB. Please don''t repeat urban legends as fact. Anyways, we return to your scheduled programming: How to get adoption of Rails in companies. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
LOL. DHH, that was awesome. If you''re unsure what DHH is referring to, the Active Record Basics chapter of the Agile Web Development with Rails explains it very nicely. If you haven''t read all the way through it, you''re undoubtedly missing out. Yes, you can learn through self-discovery (as I often do), but the book really does help (whereas some books just plain suck and sit there gathering dust). Anyway, thanks for the laugh DHH. :) - Rabbit On 2/15/06, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:> > > Just a survey but how many people actually use transactions in RoR > > > applications ? > > > > Raises hand! > > > > Perhaps it comes from not having started with MySQL, but instead a DB > > that supported transactions. > > What on earth are you guys talking about?! Just by using Active > Record, you''re using transactions. All state changes persisted to the > database happens in a automatic transaction. And if you''re mixing two > state changes that doesn''t automatically live in the same transaction, > then you''re _crazy_ if you''re not using transactions. > > How does this have ANYTHING to do with triggers or stored procedures?! > > Also, MySQL has supported transactions since the 90''ies through > InnoDB. Please don''t repeat urban legends as fact. > > Anyways, we return to your scheduled programming: How to get adoption > of Rails in companies. > -- > David Heinemeier Hansson > http://www.loudthinking.com -- Broadcasting Brain > http://www.basecamphq.com -- Online project management > http://www.backpackit.com -- Personal information manager > http://www.rubyonrails.com -- Web-application framework > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Karl Brodowsky
2006-Feb-15 22:00 UTC
what kind of database (Re: [Rails] Advocating RoR in the enterprise?)
In my experience enterprise data are so precious that you don''t seriously consider storing them in anything lesser than a fully equipped database like Oracle. The features of such databases that help us keep data integrity and consistency have been around for a long time and have proven to be useful and relyable. Using other mechanisms instead of relying on the database for this is making it difficult to get acceptence for enterprise applications. I would be skeptical as well. This does not make it wrong to enforce some constraints at the application level, either duplicating the constraint mechanisms of the database or have it only in the application for constraints that would require complex triggers. We do not want to duplicate the business logic. As a matter of fact it will be common that the database is read by several applications. It is not a good idea to restrict this to the rails-application. But writing might indeed be restricted. Anyway, I think it''s not the time to go for replacement of Oracle by mySQL or postgreSQL in the enterprise now. That might become an issue in a couple of years from now. But rails can be used now already. Best regards, Karl
On Feb 15, 2006, at 12:50 PM, David Heinemeier Hansson wrote:>>> Just a survey but how many people actually use transactions in RoR >>> applications ? >> >> Raises hand! >> >> Perhaps it comes from not having started with MySQL, but instead a DB >> that supported transactions. > > What on earth are you guys talking about?! Just by using Active > Record, you''re using transactions. All state changes persisted to the > database happens in a automatic transaction. And if you''re mixing two > state changes that doesn''t automatically live in the same transaction, > then you''re _crazy_ if you''re not using transactions.Yes, exactly.> How does this have ANYTHING to do with triggers or stored procedures?!Doesn''t. My response had nothing to do with triggers or stored procedures.> Also, MySQL has supported transactions since the 90''ies through > InnoDB. Please don''t repeat urban legends as fact.Down boy. :-) http://dev.mysql.com/doc/refman/4.1/en/news-3-23-34.html Changes in release 3.23.34 (10 Mar 2001) Added the INNOBASE storage engine and the BDB storage engine to the MySQL source distribution. I didn''t repeat any urban legends. I stated that I started on DBs that supported them, period. Perhaps could have been more clear by stating that I started at a time when MySQL didn''t support them. What I can tell you, without question, is that a spooky number of MySQL (and probably other DBs) backed applications in Perl, PHP, and likely Rails too, do not use transactions. You know, MySQL et. al. could have solved this themselves if they''d made InnoDB the default, and the MyISAM the option, way back in antiquity. Peace, David. Lots of people hate MySQL for bad reasons. As for me, I only hate it for good reasons. :-) -- -- Tom Mornini
> Changes in release 3.23.34 (10 Mar 2001) > Added the INNOBASE storage engine and the BDB storage engine to the > MySQL source distribution.Aight. It should have been "only supported transactions for HALF A DECADE", then.> I didn''t repeat any urban legends. I stated that I started on DBs that > supported them, period. Perhaps could have been more clear by stating > that I started at a time when MySQL didn''t support them.That would help frame the argument ;). I''m just sick and tired of hearing people babble about MySQL''s supposed lack of transactions, so any reference to that is an instant trigger (drum roll).> What I can tell you, without question, is that a spooky number of MySQL > (and probably other DBs) backed applications in Perl, PHP, and likely > Rails too, do not use transactions.How on earth does that have anything to do with MySQL? As far as I know, no database will force transactions upon you. Although, Active Record will actually force them upon you. Anything happening in a before_save is automatically wrapped in one, for example.> You know, MySQL et. al. could have solved this themselves if they''d > made InnoDB the default, and the MyISAM the option, way back in > antiquity.What does MySQL anno pre-2001 have to do with the database choices of today? So cars in 30''ies didn''t have seat belts, does that have any baring on the safety of cars today?> Peace, David. Lots of people hate MySQL for bad reasons. As for me, I > only hate it for good reasons. :-)I can take peace with your other comment in this thread:> We OO people preach encapsulation at code level all of the time, and > then many of us (myself included!) have lately been suggesting breaking > it at the application level, which is just plain wrong.Couldn''t agree more. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
>>You know, MySQL et. al. could have solved this themselves if they''d >>made InnoDB the default, and the MyISAM the option, way back in >>antiquity. > > > What does MySQL anno pre-2001 have to do with the database choices of > today? So cars in 30''ies didn''t have seat belts, does that have any > baring on the safety of cars today?Extrapolating from my own recent experiences with code I''ve seen in production that deals with people''s money, I''d bet there are hundreds, if not thousands or tens of thousands of people out there doing the same thing - driving their web apps around with no seat belts and brakes that don''t work that well. Is that Mysql''s fault? Well, no, not really, but after seeing it often enough, it leaves a bad taste in your mouth - you come to associate certain tools with a rather ramshackle, haphazard way of going about things. I''m a firm believer in worse is better, but sometimes worse leaves a big mess, and cleaning it up isn''t fun. -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/
On Feb 15, 2006, at 3:04 PM, David Heinemeier Hansson wrote:>> What I can tell you, without question, is that a spooky number of >> MySQL >> (and probably other DBs) backed applications in Perl, PHP, and likely >> Rails too, do not use transactions. > > How on earth does that have anything to do with MySQL? As far as I > know, no database will force transactions upon you. Although, Active > Record will actually force them upon you. Anything happening in a > before_save is automatically wrapped in one, for example.David, it *doesn''t* have anything to do with MySQL. You''re entire original response, as well as this paragraph, is colored by the mistaken assumption that my response had anything do with do with MySQL! I was just responding to a poll asking whether or not people used transactions. <blush> That said, it must be true that the MAJORITY of people writing apps today that store data in SQL databases learned to do so using MySQL, and probably a large portion of those did so at a time when it didn''t support transactions. Many were told by MySQL supporters that transactions really are not all that important. It''s pretty clear the MySQL community didn''t think transactions were all that important, as they weren''t added until (relatively) recently.>> You know, MySQL et. al. could have solved this themselves if they''d >> made InnoDB the default, and the MyISAM the option, way back in >> antiquity. > > What does MySQL anno pre-2001 have to do with the database choices of > today? So cars in 30''ies didn''t have seat belts, does that have any > baring on the safety of cars today?The default behavior today is still the same, isn''t it? If you just issue a SQL standard CREATE TABLE command, I''m pretty sure you end up with a MyISAM table, which doesn''t support transactions, thereby indirectly suggesting that transactions are either optional or required in fewer than half the cases. If I''m wrong about the default behavior, I apologize in advance. Since I know little about current day MySQL, it''s entirely possible, perhaps even likely, that I am wrong. This statement is included to indemnify myself against suggestions that I am spreading urban legends as fact. :-) Addtiionally, while it may have no bearing based in technical reality, it clearly does have a bearing based upon perception. Everyone on the list loves Rails, and the people in this thread are trying to move it into the Enterprise, where decisions are often made by people with little to no technical capacity who are driven to a large extent based upon their perceptions. The big question I have is not: Why are MySQL detractors so close minded? but instead: Why are MySQL supports to close minded with respect to PostgreSQL? And...I''ll answer that in advance: PERCEPTION: MySQL is faster than PostgreSQL. I''m not even sure if it''s true anymore, and frankly I don''t care for the same reason you''re sick to death of people asking whether or not Rails will scale! PostgreSQL is fast enough, stable enough, standards, compliant enough, supported enough, careful enough, featured enough, etc. to satisfy ME. What''s more, it''s been all these things since well before MySQL has had (non default) support for transactions, and both of us know that''s been MORE THAN HALF A DECADE. :-) -- -- Tom Mornini
Jean Helou
2006-Feb-16 13:09 UTC
what kind of database (Re: [Rails] Advocating RoR in the enterprise?)
<BUZZWORD WARNING>This mail is fully Buzzword 2.0 compliant, it may cause violent reactions in some and start flamewars in others. Please take with a grain of salt</BUZZWORD WARNING> On 2/15/06, Karl Brodowsky <listen@brodowsky.com> wrote:> As a matter of fact it will be common that the database is read by several > applications. It is not a good idea to restrict this to the rails-application. > But writing might indeed be restricted.If you ever have to defend it in a company how about this ? This is true for database centric architecture, but you could also consider using a Service Oriented Architecture (SOA), which is all the rage now in entreprises. Each application has its own database for which it maintains integrity. All application that want to interact with the data of a given application use service requests (be they web services or others). jean
On Wed, Feb 15, 2006 at 12:17:27PM -0800, Tom Mornini wrote: } On Feb 15, 2006, at 10:03 AM, Grant Johnson wrote: } } >>The only answer to that is, "Stop using the database to enforce } >>access, integrity, and business rules." That''s not going to fly in a } >>lot of places. Particularly an Oracle shop. } > } >This is one of the few points where I disagree with DHH, but then } >this is because I usually have more than one thing touching the } >DB. If it was only the Rails application using it, maybe then, } >but I intend to have other things reading and writing data from the } >database, so I want some more things to protect myself from the users. } } You know, I can completely empathize, because I felt *exactly* the same } way at first. } } However...new applications are the Rails sweet spot. We all love Rails } so much that we''d like to use it all of the time, but if you think about } it, Rails is at its best when you''re creating on a new application where } you can follow all the conventions. That is true... of Rails 1.0. That doesn''t mean that it isn''t worth striving for a broader sweet spot in subsequent versions. } So, if you''re creating a new application, and you want outside access to } the data, it really makes a great deal more sense (particularly moving } into the future) to provide that access via web services (pick your } favorite) and Rails makes that pretty easy to provide. Errrr... no. Web services are a good way of providing cross-domain RPC, AJAX support, and certain kinds of client-server interaction. They are a terrible means of moving large chunks of data around. When you need data throughput, you need direct database access. This does not mean permission to execute arbitrary SQL, however. } If you really get down to it, why in the world would anyone build a new } application today predicated on the assumption that other systems will } directly access the data? } } That, to me, is extremely bad encapsulation! The encapsulation comes from stored procedures (and maybe triggers). You provide access to data in very specific, very carefully controlled ways. The project I am on at work involves a huge database with thousands (millions?) of persisted objects of dozens of different types. These persisted objects can only be accessed and affected through stored procedures. Those stored procedures are actually automatically generated, so the development overhead is minimal and there is a consistent interface to manipulating any object type. This allows the thick client application, the web application, and various small tools to all retrieve and manipulate large volumes of data efficiently and safely. Of course, a Rails application (using ActiveRecord) on top of this system would be completely unworkable due to the absolute requirement that all data access uses stored procedures. This is a shortcoming of ActiveRecord, not a design flaw. } We OO people preach encapsulation at code level all of the time, and } then many of us (myself included!) have lately been suggesting breaking } it at the application level, which is just plain wrong. Object persistence, which is what ActiveRecord is all about, can be managed at various levels. Data integrity, security, and access, however, are database matters. Use the right tool for the job. The database is the right tool for data management, and stored procedures (and triggers) are the mechanism. Web services are the wrong tool for (local) data access. } -- Tom Mornini --Greg
On Feb 16, 2006, at 5:17 AM, Gregory Seidman wrote:> Errrr... no. Web services are a good way of providing cross-domain > RPC, > AJAX support, and certain kinds of client-server interaction. They > are a > terrible means of moving large chunks of data around.Who says?> When you need data throughput, you need direct database access.Again, who says? You know, when relational databases were brand new, the Cobol/ISAM folks laughed at them and said they were impractical because they were inefficient.> The encapsulation comes from stored procedures (and maybe > triggers). You > provide access to data in very specific, very carefully controlled > ways. > The project I am on at work involves a huge database with thousands > (millions?) of persisted objects of dozens of different types. These > persisted objects can only be accessed and affected through stored > procedures. Those stored procedures are actually automatically > generated, > so the development overhead is minimal and there is a consistent > interface > to manipulating any object type. This allows the thick client > application, > the web application, and various small tools to all retrieve and > manipulate > large volumes of data efficiently and safely.Yes, that''s one way to do it. It was well thought out, and no doubt is/was practical and efficient at the time.> Of course, a Rails application (using ActiveRecord) on top of this > system > would be completely unworkable due to the absolute requirement that > all > data access uses stored procedures. This is a shortcoming of > ActiveRecord, > not a design flaw.No, I certainly wouldn''t call it a design flaw. However, what you''re saying is that because it *was and is* done that way, ActiveRecord should support it. That''s pretty much identical to the Cobol/ISAM folks mentioned above. I''m willing to bet that many of them said that relational DBs *should or must* provide a means of accessing the legacy ISAM DBs that were so prevalent at the time. So...it''s possible...that history is repeating itself. Many believe that we''re about to hoist the abstraction level up a notch to web services, and it''s possible that they''re right or wrong. It may take a short time or a long time (though in general technology adoption is happening at an ever increasing rate).> } We OO people preach encapsulation at code level all of the time, and > } then many of us (myself included!) have lately been suggesting > breaking > } it at the application level, which is just plain wrong. > > Object persistence, which is what ActiveRecord is all about, can be > managed > at various levels. Data integrity, security, and access, however, are > database matters. Use the right tool for the job. The database is > the right > tool for data management, and stored procedures (and triggers) are the > mechanism. Web services are the wrong tool for (local) data access.You may be right, I may be right, we may both be wrong. I, for one, have seen too many statements of absolutely certainty fall by the wayside, particularly when they have to do with performance and effiency. By those standards, there''s zero chance that Windows/Office will ever become the enterprise standards. It''s perfectly clear that they are slow and inefficient! And...besides that...DOS/WordPerfect are the way it''s done now. :-) -- -- Tom Mornini
On 2/16/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:> Of course, a Rails application (using ActiveRecord) on top of this system > would be completely unworkable due to the absolute requirement that all > data access uses stored procedures. This is a shortcoming of ActiveRecord, > not a design flaw.It would be workable, it is just a LOT more work. I''m not that familiar with how other databases work, but with PostgreSQL, you''d just create SQL types for each model and SQL functions for each type of database access you needed, then your AR class would have methods like: class Album < ActiveRecord::Base def find_all find_by_sql("SELECT * FROM find_all_albums()") end def find_by_id(id) find_by_sql(["SELECT * FROM find_album_by_id(?)", id]) end def update_name(new_name) connection.update(sanitize_sql(["SELECT * FROM update_album_name(?,?)", id, new_name])) end end It''s possible to use Rails even with a completely locked down database, but your productivity will drop significantly. It''ll probably still be higher than doing the same thing in another framework, though.
To return briefly to the scheduled programming again... is there a good strategy to be gleaned from all this? An enterprise is going to have issues of legacy data storage, data integrity, platform buy-in, etc. Let''s say I''m not shooting for instantaneous migration to Rails for these kinds of issues. If it''s in Java, let it stay in Java. If it''s stored procedures, then maybe Rails isn''t the right tool right now. Otherwise, it''s going to be a hard-fought battle, and one that I am unlikely to win. However, as John-Mason and Thibaut pointed out, what if I quietly start developing in Ruby and Rails when it''s clearly the right tool for the job? The most successful scenario, then, would be applications that: * Do not require massive business logic * Operate on new databases, or existing simple ones * Need to be developed quickly, and * Are fairly visible, possibly even eye-poppingly awesome. That way, when an internal customer gets a great app delivered ahead of schedule, and can show it off, it builds demand for that programming model. It''ll be a lot easier to sell something once I''ve already given it some value. The downside is the knee-jerk factor - to be considered a liability for developing in "unsupported" languages, or to be told, explicitly, "no," if someone latches on to my use of RoR as a problem. If I started now, how many great apps could I deliver before someone noticed that they weren''t written in PHP? :) So what do y''all think... will it fly?
Tom Mornini wrote:> On Feb 16, 2006, at 5:17 AM, Gregory Seidman wrote: > >> Errrr... no. Web services are a good way of providing cross-domain RPC, >> AJAX support, and certain kinds of client-server interaction. They are a >> terrible means of moving large chunks of data around. > > > Who says? > >> When you need data throughput, you need direct database access. > > > Again, who says? You know, when relational databases were brand new, the > Cobol/ISAM folks laughed at them and said they were impractical because > they were inefficient. > >> The encapsulation comes from stored procedures (and maybe triggers). You >> provide access to data in very specific, very carefully controlled ways. >> The project I am on at work involves a huge database with thousands >> (millions?) of persisted objects of dozens of different types. These >> persisted objects can only be accessed and affected through stored >> procedures. Those stored procedures are actually automatically >> generated, >> so the development overhead is minimal and there is a consistent >> interface >> to manipulating any object type. This allows the thick client >> application, >> the web application, and various small tools to all retrieve and >> manipulate >> large volumes of data efficiently and safely. > > > Yes, that''s one way to do it. It was well thought out, and no doubt is/was > practical and efficient at the time. > >> Of course, a Rails application (using ActiveRecord) on top of this >> system >> would be completely unworkable due to the absolute requirement that all >> data access uses stored procedures. This is a shortcoming of >> ActiveRecord, >> not a design flaw. > > > No, I certainly wouldn''t call it a design flaw. However, what you''re > saying > is that because it *was and is* done that way, ActiveRecord should support > it. That''s pretty much identical to the Cobol/ISAM folks mentioned above. > I''m willing to bet that many of them said that relational DBs *should or > must* provide a means of accessing the legacy ISAM DBs that were so > prevalent at the time. > > So...it''s possible...that history is repeating itself. Many believe that > we''re about to hoist the abstraction level up a notch to web services, > and it''s possible that they''re right or wrong. It may take a short time > or a long time (though in general technology adoption is happening at an > ever increasing rate). > >> } We OO people preach encapsulation at code level all of the time, and >> } then many of us (myself included!) have lately been suggesting >> breaking >> } it at the application level, which is just plain wrong. >> >> Object persistence, which is what ActiveRecord is all about, can be >> managed >> at various levels. Data integrity, security, and access, however, are >> database matters. Use the right tool for the job. The database is the >> right >> tool for data management, and stored procedures (and triggers) are the >> mechanism. Web services are the wrong tool for (local) data access. >It is a very handy way to get cross platform operation without much in the way of hassles. I have a 100Mb LAN with several 800MHz computers (one serving RoR with lighttpd, FCGI and Postgresql) and it takes only a fraction over 1 second to load up a quite complex page which uses data from 4 different tables on it. That is quick enough for most business, and I am sure I could make it faster. P.S. I know I could also do the app with a custom program and it would show the same info in a small fraction of a second. But it would need to be rewritten/recompiled for each different OS/CPU. Regards Neil.> > You may be right, I may be right, we may both be wrong. > > I, for one, have seen too many statements of absolutely certainty fall by > the wayside, particularly when they have to do with performance and > effiency. > > By those standards, there''s zero chance that Windows/Office will ever > become the enterprise standards. It''s perfectly clear that they are slow > and inefficient! And...besides that...DOS/WordPerfect are the way it''s > done now. :-) >