<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Code and Life &#187; rails</title>
	<atom:link href="http://codeandlife.com/tags/rails/feed/" rel="self" type="application/rss+xml" />
	<link>http://codeandlife.com</link>
	<description>Tech and other visions from the liquid crystal tower</description>
	<lastBuildDate>Tue, 14 Jul 2009 07:47:54 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.1</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Rails template caching intricasies</title>
		<link>http://codeandlife.com/2008/04/20/rails-template-caching-intricasies/</link>
		<comments>http://codeandlife.com/2008/04/20/rails-template-caching-intricasies/#comments</comments>
		<pubDate>Sun, 20 Apr 2008 12:38:20 +0000</pubDate>
		<dc:creator>jokkebk</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[caching]]></category>
		<category><![CDATA[rails]]></category>
		<category><![CDATA[template caching]]></category>
		<category><![CDATA[troubleshooting]]></category>

		<guid isPermaLink="false">http://codeandlife.com/2008/04/20/rails-template-caching-intricasies/</guid>
		<description><![CDATA[You just have to love coding. I mean, unless you don&#8217;t, you&#8217;re not likely to put up with two hours of nearly useless debugging, when you realize your WeBRICK or Mongrel development environment do not work as it should. That&#8217;s exactly what I just did, and in order to help others, I&#8217;ll give you the [...]]]></description>
			<content:encoded><![CDATA[<p>You just have to love coding. I mean, unless you don&#8217;t, you&#8217;re not likely to put up with two hours of nearly useless debugging, when you realize your WeBRICK or Mongrel development environment do not work as it should. That&#8217;s exactly what I just did, and in order to help others, I&#8217;ll give you the details so you can get some decent results when Googling.</p>
<p><strong>The problem:</strong> I wanted to do some quick template prototyping. Hitting my WebFaction rails development environment, I started to make changes to a page template, update it, make changes, etc. Only this time no changes were shown after initial load! Only a server restart would make the changes visible. WTF. This isn&#8217;t how the development environment should work at all!</p>
<p><span id="more-12"></span></p>
<p><strong>The googling:</strong> After some carefully selected phrases in Google, a few things soon became apparent:</p>
<ol>
<li>No-one else seems to have encountered the problem and have a solution</li>
<li>Rails documentation on production/development configuration is nonexistent</li>
<li>Multiple how-tos existed how to enable caching, but not for disabling it</li>
</ol>
<p>I tried to add the following configuration directives to config/environment/development.rb:</p>
<ul>
<li><code>config.cache_classes = false</code> (actually, this was there already)</li>
<li><code>config.action_view.cache_template_extensions = false</code> (ditto)</li>
<li><code>config.action_view.cache_template_loading = false</code> (this directive was in the production, but not in development, dunno why)</li>
</ul>
<p>None of this stuff worked. Switching to WeBRICK from Mongrel didn&#8217;t work. However, cache_classes directive seemed to make changes to controllers visible, but view changes were still invisible until a server restart.</p>
<p><strong>The revelation:</strong> Finally, after little more than one hour of trial-and-error, I finally found the vast amount of documentation available on template caching on Rails. For those who haven&#8217;t yet found it from <a href="http://api.rubyonrails.org/">Rails API</a>, it is located under <code>ActionView::Base</code>. I will reproduce it here to highlight the detail in which template caching and its configuration directives are explained:</p>
<blockquote><p>By default, Rails will compile each template to a method in order to render it. When you alter a template, Rails will check the file‘s modification time and recompile it.</p></blockquote>
<p>Now I had sufficient information to reach the solution. For some odd reason, my combination of Notepad++, WinSCP and WebFaction server setup caused the timestamp of saved template file to be one hour off. This caused Rails to conclude, that no changes had been made since last compiling the template (oh, they would be noticed after <em>waiting for one hour</em>, but who wants to wait one hour after every change?).</p>
<p><strong>The solution:</strong> This was a stupid problem, but the solution evaded me for too long because of scarce (and hard to find) documentation on template caching mechanism. A simple <code>touch</code> command after changes now does the trick. A hack, but it works well enough.</p>
]]></content:encoded>
			<wfw:commentRss>http://codeandlife.com/2008/04/20/rails-template-caching-intricasies/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Django &#8211; next stop after Ruby on Rails?</title>
		<link>http://codeandlife.com/2008/02/05/django-next-stop-after-ruby-on-rails/</link>
		<comments>http://codeandlife.com/2008/02/05/django-next-stop-after-ruby-on-rails/#comments</comments>
		<pubDate>Tue, 05 Feb 2008 19:47:10 +0000</pubDate>
		<dc:creator>jokkebk</dc:creator>
				<category><![CDATA[Coding]]></category>
		<category><![CDATA[django]]></category>
		<category><![CDATA[python]]></category>
		<category><![CDATA[rails]]></category>
		<category><![CDATA[ruby on rails]]></category>

		<guid isPermaLink="false">http://codeandlife.com/2008/02/05/django-next-stop-after-ruby-on-rails/</guid>
		<description><![CDATA[Having done web development on several platforms (Perl+CGI, ASP.NET and PHP), I was introduced to Ruby on Rails about two years ago, and it was love on first sight. The separation of code and layout was a bliss after PHP require statements (and vaguely similar to ASP.NET, by the way), and database abstraction was on [...]]]></description>
			<content:encoded><![CDATA[<p>Having done web development on several platforms (Perl+CGI, ASP.NET and PHP), I was introduced to <a href="http://www.rubyonrails.com">Ruby on Rails</a> about two years ago, and it was love on first sight. The separation of code and layout was a bliss after PHP require statements (and vaguely similar to ASP.NET, by the way), and database abstraction was on a wholly different level.</p>
<p>And, you don&#8217;t need semicolons after statements in ruby, just how sexy is that? What more can a man need (write a comment, if you disagree :).</p>
<p>Now Rails does have some annoyances, like painful configuration for multiple applications running on a same server. If someone actually likes writing Lighttpd rules and making special provisions for it in routes.rb, again, let me know. It also seems that in some cases, all the abstraction and &#8220;there is a really clever hack to do this with just one line of code&#8221; -mentality has taken over good sense, which for me has meant that my &#8220;Rails 0.9&#8243; skillset has been mostly deprecated, and replaced with layers upon layers of new stuff I should be continuously keeping up with.</p>
<p>Now a recent Slashdot article (the one linking the page-long rant from Mongrel developer) had some positive comments related to <a href="http://www.djangoproject.com">Django</a>, and I decided to check it out. And guess what? It just <strong>rules</strong>.<br />
<span id="more-11"></span><br />
Now if you like your trusted PHP or like to roll on with Rails, wherever they take you, please don&#8217;t read further. But for those adventurous who don&#8217;t think using indentation to format blocks is a bad idea (Python developers obviously didn&#8217;t, and Django is a Python framework), I think there are several lovable features in Django, when compared to Rails. These are, of course, my personal opinions, speaking as a person who has developed a fairly complex Rails project (a personal budgeting app) over two years of time:</p>
<ul>
<li>Creating a new Django project means only four new files, and application inside that project is three more. You read that right: <strong>seven files</strong>. Talk about knowing what does what, when an empty Rails app is <strong>over 3400 files</strong>. You read that right too. Of course Django has libraries and templates elsewhere, but I do like them being outside of my personal project.</li>
<li>Instead of scaffolding, Django has opted for admin generation, which I personally slightly prefer, as it often goes that any pages facing outside customers need heavy customization anyways.</li>
<li>Database structures are created from Django definitions. This is DRY at its best. This also means, that any necessary length constraints are already there when you start making your forms. Of course Django won&#8217;t overwrite your existing tables, which generally gives about the same leverage as Rails does with its database conventions, which you have to follow if you want Rails to play ball. With this feature, you can totally skip the &#8220;now lets write the SQL&#8221;-part of creating new applications.</li>
<li>Powerful templating system. In Rails you mark where you content should go in the page using layouts, but you don&#8217;t get any more levels than that. Django, instead, starts with a root template, which defines a set of blocks, which you can then overwrite (or not) by inheriting the template. And inheritance can go multiple levels, so you get same kind of benefits as you get when abstracting classes in object-oriented paradigms &#8211; you only override the parts you want to change, and recycle the rest.</li>
<li>Very good documentation. Just point your browser to <a href="http://www.djangoproject.com/documentation/overview/">Django overview</a> and you&#8217;ll probably understand. It&#8217;s smartly written, and covers things you need, without the need of Googling too much.</li>
</ul>
<p>And of course with Django, you get to write some kick-ass Python code, without any braces or endif annoyances, just beatiful, indented code. And I&#8217;d expect the Python libraries to be as extensive, or probably even more so than Ruby&#8217;s. I haven&#8217;t done testing to see whether Python&#8217;s habit of compiling stuff into byte-code speeds things up when compared to Ruby, but I don&#8217;t think Django would lose to Rails much when speed is compared.</p>
<p>Now that I got you convinced to check Django out, I do have some quibbles with it, which I think need to be resolved to make me abandon Rails completely:</p>
<ul>
<li>No real API documentation. You have pretty good &#8220;how to use&#8221; documentation for everything, but I&#8217;d like to see the details if necessary, please.</li>
<li>Mod_python may leak memory and need restarting from time to time. This is not a nice things. Also, you need to have a separate server handling all non-Python data, as Django is quite slow at serving those images and other stuff you need for your web page.</li>
<li>Rigid templating language. I understand you shouldn&#8217;t put too much logic in your views, but not being able to use operators in templates is <strong>annoying</strong>. Example: there are only &#8220;if bool&#8221; and &#8220;ifequal var1 var2&#8243; statements, no &#8220;if size < 6", or anything like that. I also don't know how much performance hit occurs because of templating.</li>
</ul>
<p>That&#8217;s it for today, time to do some actual coding. In my next post, I&#8217;m going to forget Rails and Django for a while, and discuss solutions for those cases where you cannot use the shining light of these solutions, and have to rely on plain old LAMP to survive.</p>
]]></content:encoded>
			<wfw:commentRss>http://codeandlife.com/2008/02/05/django-next-stop-after-ruby-on-rails/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Nice hosting for Django and Rails nuts</title>
		<link>http://codeandlife.com/2008/01/15/nice-hosting-for-django-and-rails-nuts/</link>
		<comments>http://codeandlife.com/2008/01/15/nice-hosting-for-django-and-rails-nuts/#comments</comments>
		<pubDate>Tue, 15 Jan 2008 20:17:14 +0000</pubDate>
		<dc:creator>jokkebk</dc:creator>
				<category><![CDATA[Coding]]></category>
		<category><![CDATA[Web tips]]></category>
		<category><![CDATA[django]]></category>
		<category><![CDATA[hosting]]></category>
		<category><![CDATA[rails]]></category>
		<category><![CDATA[realmenhosttheirownserver]]></category>
		<category><![CDATA[webfaction]]></category>

		<guid isPermaLink="false">http://codeandlife.com/2008/01/15/nice-hosting-for-django-and-rails-nuts/</guid>
		<description><![CDATA[Just thought to post a brief and shamelessly positive note on my current hosting provider, WebFaction. It was actually their one-click WordPress installation procedure that got me playing around with blogging, which then lead to founding this blog. I ran into it when searching for suitable site to host Django-powered software, which lead me to [...]]]></description>
			<content:encoded><![CDATA[<p>Just thought to post a brief and shamelessly positive note on my current hosting provider, <a href="http://www.webfaction.com?affiliate=jokkebk">WebFaction</a>. It was actually their one-click WordPress installation procedure that got me playing around with blogging, which then lead to founding this blog. I ran into it when searching for suitable site to host Django-powered software, which lead me to this comparison of <a href="http://www.statopia.com/corporate/blog/2007/aug/05/PopularDjangoHostingService/">Django-friendly web hosts</a>.</p>
<p>Now this probably wouldn&#8217;t be worth noting otherwise, but WebFaction is the only provider so far (leave a comment if you find others), that fulfilled all my stringent requirements for a hosting provider:</p>
<ol>
<li>Support for PHP, Ruby on Rails and Django (this alone is hard without virtual servers)</li>
<li>Support for MySQL <strong>and</strong> PostgreSQL (to suit the daily mood)</li>
<li>No arbitary limits on subdomains and domains within plans (it&#8217;s not like they cost anything to the provider)</li>
<li>Starting cost must be below $10 a month (I&#8217;d rather scale up when I actually have traffic, not beforehand)</li>
</ol>
<p><span id="more-7"></span><br />
Suffice to say, requirement for recent web platforms (Rails, Django) combined with relative freedom and low cost are almost impossible to find. Having said that, a brief look on <a href="http://www.webfaction.com/services/">what WebFaction was offering</a> did convince me to finally abandon the real-men-host-their-own-servers -approach, which had been causing me a headache lately (DSL line and a Linux box in the living room isn&#8217;t just meant for 24/7 services, if you know what I mean). In addition to my personal requirements, this provider sported additional, and in some points even exceptional benefits:</p>
<ul>
<li><strong>Unlimited</strong> domains and subdomains (I did say it already, did I?), e-mail addresses, mailboxes, and databases (yep, you heard it right)</li>
<li>Full shell access with SSH and SFTP</li>
<li>One-click installers for a dozen of most popular applications (most Python web frameworks, Rails, WordPress and others), which actually make what they are supposed to do</li>
<li>Database sizes count towards disc quota (instead of the outrageous &#8220;10MB per database&#8221; restrictions on many cheap hosting providers)</li>
</ul>
<p>Overall, the configurability and lack of any severe limitations on applications make the shared hosting plans feel much like a virtual server, without the hassle related to installing everything yourself. However, I do have some minor nags (its not a perfect world):</p>
<ul>
<li>The 60MB memory limit on the cheapest plan (this doesn&#8217;t count Apache running PHP and database servers, only Mongrel, the Apache running mod_python and the like) means that several Django/Rails instances cannot coexist (unless they are very, very basic). This can be fixed with Plan B, though. :)</li>
<li>Shell connection could be more responsive (it could also be that Finland is too far away from Texas, who knows)</li>
<li>Putting Rails behind HTTPS (they have one-click configuration option for that, too) caused a problem with redirects (which continue to point to http:// -addresses, making them not to work). Solutions do exist for this, but&#8230;</li>
</ul>
<p>Now that I&#8217;ve introduced the basic hardware powering this Blog, I may devote some posts detailing some of the forays I&#8217;ve made so far after settling with a hosting provider. But that is a story for another day.</p>
<p>As a disclaimer, aside from the hosting plan, I have no connection with WebFaction, I was just delighted enough of their service (and responsiveness of the staff, as I had a minor problem with my account setup in the start) to share this information. I do probably receive credits or something if you put me (jokkebk) as a referrer when you sign up, but that is actually your problem, not mine. :)</p>
]]></content:encoded>
			<wfw:commentRss>http://codeandlife.com/2008/01/15/nice-hosting-for-django-and-rails-nuts/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
