Mention Rails, and you will often believe you are debating White Castle burgers. You either love or hate it with little room for anything in between. DHH created a framework where you generally have to play by his rules and if you disagree with those rules, you might become frustrated or a bit disgruntled while working in the framework.
Whether you are comfortable working within DHH’s framework or not, the fact is that the train is moving and it includes new features that will improve your apps as the version matures. Developers using Rails will cringe at points similar to what we felt with the introduction of the asset pipeline. Even tonight, as I write this post, I have had a moment of asset pipeline cringing. Hating the change… or as DHH puts it, the “progress”…
However, there are numerous advantages to using Rails and the newest installment will build on and create new features that will make development easier, more secure, and more fun (at least we hope in the long run).
The intent of this article is to approach development and debugging of Ruby on Rails applications from the perspetive of a C++ developer. In Part I I discussed some of the fundamental differences between Ruby on Rails and C++ development.
I started a simple "blog with comments" example to step through and showed how to use the ruby console to debug the model and what some of the exception messages returned to the view are telling us.
Where are the exceptions?
While we know the model is right (we debugged it already) sometimes there is no exception information being displayed. Where do we turn then? In this part of the article I am going to expand on our example and go deeper into what to look for there are no meaningful exception messages.
If you already know why C++ and Ruby on Rails are fundamentally different and just want to see the example, you can skip to The Example.
I’ve been developing software for many years but, for the most part, have stayed in the C++ world. I made the transition to web applications development with C# ASP.NET MVC applications, which I felt is a fairly easy transition. Adjusting to the MVC design pattern took a little change in thinking but it’s not a terribly difficult pattern to understand. It’s been a few years now and I am quite comfortable in that world.
Have you ever worked on a Rails app? That app is vulnerable to a new crop of exploits discovered in the waning days of 2012. Rails 3.2.11 (and 2.3, 3.0, and 3.1 releases) patches those flaws, but until someone runs gem update or bundle , an attacker can execute arbitrary code on that machine.
Patrick McKenzie’s excellent blog post inspired this commentary. Read on for a reiteration of his suggestions.
Nobody likes waiting for a web page to load. Pity, then, the Ruby on Rails developer, proud of the the development platform’s famous efficiency of code, combating the slanderous claims of a slow production environment, and then condemned to watch the browser bar spinning and spinning for the 500th time during today’s coding session. Because Rails requests in the default development environment are slow.
Why? By default, every web page request is verifying and recompiling every referenced asset — every Coffeescript, Sass, and Less file. Ajax requests with responses that don’t include the application layout (and its application.js and application.css manifest file burdens), are delightfully zippy, but loading a simple home page? Over and over throughout the course of the day? Goodbye delight and efficiency.
Until you make one simple change in development.rb: (more…)