I Hear the Train a Comin’ – A Few Reasons Why Rails 4.0 Will Rock Your World

Photo of train. Photo by Jack Anstey on Unsplash

Rails 4 logo

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).


Debugging Ruby on Rails…as a C++ Developer – Part II

Photo of train tunnel by Florian van Duyn on Unsplash

Ruby logo

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.


Debugging Ruby on Rails…as a C++ Developer – Part I

Photo of train tunnel by Florian van Duyn on Unsplash

Ruby logo

Quick background

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.

C++, and its garbage-collected baby brother C#, are straight-forward. There is very little magic involved. If you know the language, the ASP.NET MVC platform all just kind of makes sense. It does exactly what you tell it to do. If you understand C# (and to some extent HTML and JavaScript), you’re 90% of the way to understanding ASP.NET MVC.

Ruby on Rails is different. Very different


Did you work on a Rails app? It’s extremely vulnerable. Tell someone to update it!

Photo of train tracks by Julian Hochgesang on Unsplash

Rails logoHave 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.


Faster web page requests in Rails development

Photo of hummingbird Photo by James Wainscoat on Unsplash

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 s l o w.

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.

Debug off

Until you make one simple change in development.rb: (more…)