<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Why I don&#8217;t deploy on Ruby on Rails</title>
	<atom:link href="http://blog.realmofzod.com/2008/04/21/why-i-dont-deploy-on-ruby-on-rails/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.realmofzod.com/2008/04/21/why-i-dont-deploy-on-ruby-on-rails/</link>
	<description>Programming and Technology</description>
	<lastBuildDate>Fri, 03 Sep 2010 21:37:05 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: brandon</title>
		<link>http://blog.realmofzod.com/2008/04/21/why-i-dont-deploy-on-ruby-on-rails/comment-page-1/#comment-9</link>
		<dc:creator>brandon</dc:creator>
		<pubDate>Tue, 22 Apr 2008 01:57:23 +0000</pubDate>
		<guid isPermaLink="false">http://blog.realmofzod.com/?p=10#comment-9</guid>
		<description>I&#039;m thrilled to see someone from Zend chime in... I agree with you completely. In my experience with Zend so far I have found it to be more flexible in that you don&#039;t sacrifice the ability to for convenience which has burned me more than once on rails. Thanks for the perspective.</description>
		<content:encoded><![CDATA[<p>I&#8217;m thrilled to see someone from Zend chime in&#8230; I agree with you completely. In my experience with Zend so far I have found it to be more flexible in that you don&#8217;t sacrifice the ability to for convenience which has burned me more than once on rails. Thanks for the perspective.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wil Sinclair</title>
		<link>http://blog.realmofzod.com/2008/04/21/why-i-dont-deploy-on-ruby-on-rails/comment-page-1/#comment-8</link>
		<dc:creator>Wil Sinclair</dc:creator>
		<pubDate>Mon, 21 Apr 2008 17:49:57 +0000</pubDate>
		<guid isPermaLink="false">http://blog.realmofzod.com/?p=10#comment-8</guid>
		<description>Very interesting perspective. I came across Derek&#039;s article a while back. While I have heard about scalability concerns from several users of Rails (I prototyped with it for about 6 months, but never ran a production site on it myself), I have to mention that we hope there are other reasons to use Zend Framework for high-load, enterprise-oriented site/apps. For example, a lot of the cool features for which Rails has become the poster child- such as scaffolding and other features that rely heavily on convention- are really attractive to developers because they make the first few days of working with a framework easy. I don&#039;t know of a single developer who likes having to go back to the manual every few seconds to do the next step. Rails simplifies this by heavy use of CoC and DRY. *But* the first few days is only a small fraction of a typical developer&#039;s relationship with his/her framework of choice. With that in mind, we plan to work up to such features in ZF, but *never* at the expense of power and flexibility- which are much more likely to affect your *long term* experience with a framework in our opinion.
Rails is an elegant framework that works well for many sites; I think we&#039;ve gotten about as much consensus on that as we can ever expect in the web dev community. It&#039;s when your requirements fall outside of those Rails was designed to simplify that a lot of the RoR shine starts to wear off. ZF is designed to work with your requirements- whatever they are. We have a will continue to build on top of our existing abstractions to bring more out-of-the-box functionality and facilitate common use cases; if our top abstraction layer doesn&#039;t work for you, ZF is designed so that you can punch through that abstraction and find the layer that supports your requirements as well as any framework could be expected to. In a way, we see ZF as the &#039;no worry&#039; framework. It wears it&#039;s (current) limitations on its sleeves- you don&#039;t have to worry about scaling or excessive complexity of design for unique requirements beyond the concerns that you&#039;d have in your tried and true PHP platform.
This is a hard position to hold to. Until we have the time to implement Rails&#039; features without relying on conventions entirely, our shortcomings are put front and center: in the first hour of a developer&#039;s experience with ZF. But we believe it&#039;s the right strategy for our users in the long run. In any case, I just wanted to add that extra perspective from an extremely biased person. :)

,Wil</description>
		<content:encoded><![CDATA[<p>Very interesting perspective. I came across Derek&#8217;s article a while back. While I have heard about scalability concerns from several users of Rails (I prototyped with it for about 6 months, but never ran a production site on it myself), I have to mention that we hope there are other reasons to use Zend Framework for high-load, enterprise-oriented site/apps. For example, a lot of the cool features for which Rails has become the poster child- such as scaffolding and other features that rely heavily on convention- are really attractive to developers because they make the first few days of working with a framework easy. I don&#8217;t know of a single developer who likes having to go back to the manual every few seconds to do the next step. Rails simplifies this by heavy use of CoC and DRY. *But* the first few days is only a small fraction of a typical developer&#8217;s relationship with his/her framework of choice. With that in mind, we plan to work up to such features in ZF, but *never* at the expense of power and flexibility- which are much more likely to affect your *long term* experience with a framework in our opinion.<br />
Rails is an elegant framework that works well for many sites; I think we&#8217;ve gotten about as much consensus on that as we can ever expect in the web dev community. It&#8217;s when your requirements fall outside of those Rails was designed to simplify that a lot of the RoR shine starts to wear off. ZF is designed to work with your requirements- whatever they are. We have a will continue to build on top of our existing abstractions to bring more out-of-the-box functionality and facilitate common use cases; if our top abstraction layer doesn&#8217;t work for you, ZF is designed so that you can punch through that abstraction and find the layer that supports your requirements as well as any framework could be expected to. In a way, we see ZF as the &#8216;no worry&#8217; framework. It wears it&#8217;s (current) limitations on its sleeves- you don&#8217;t have to worry about scaling or excessive complexity of design for unique requirements beyond the concerns that you&#8217;d have in your tried and true PHP platform.<br />
This is a hard position to hold to. Until we have the time to implement Rails&#8217; features without relying on conventions entirely, our shortcomings are put front and center: in the first hour of a developer&#8217;s experience with ZF. But we believe it&#8217;s the right strategy for our users in the long run. In any case, I just wanted to add that extra perspective from an extremely biased person. :)</p>
<p>,Wil</p>
]]></content:encoded>
	</item>
</channel>
</rss>
