A very interesting article by David Heinemeier Hansson Describing the greater value of system tests over granular unit tests. I’ve definitely seen some of David’s points play out in web systems more concerned about users interacting with the interface than intricate calculations. Although, for those web applications where one small bug might cause significant monetary loss, like in financial related software, seems unit tests would still be extremely relevant.
I was recently handed a front-end project at work, essentially a redesign for the carousel on our application’s home page.
Though on the surface, this project seemed straight forward, it scared me.
Why?
I like to consider myself a good back-end/server-side developer also competent in javascript/jquery. But as far as heavy duty css’ing, I can make an interface look ok, but fully realizing our designer’s mockups through CSS seemed tricky.
A side story:
When I was still living with my folks 10 or so years ago, my mom wanted to replace a storm door. I thought, “I can do this!” So on a gorgeous Saturday, without taking any measurements, I drove to the hardware store, purchased the door my mom was interested in, and proudly brought it home.
After removing the old door, I lifted the new one into the empty frame, and realized, it was not going to fit. My mother had apparently taken no measurements, and I had not bothered to verify that she’d taken measurements.
But being the resourceful person that I am, I decided to use the one tool I had available that could possibly solve my problem – a chainsaw. As carefully as possible, I used the tip of the chainsaw to chip away at one side of the frame until the opening was large enough to fit the door. It was quite a hassle, and the frame was looking pretty rough, but thankfully, the installed storm door covered my less than beautiful hack job.
This is how I felt about my front-end development work. I could certainly use my CSS chainsaw skills to ultimately get that carousel to look just right, but behind the scenes, the frame might be a mangled mess.
But that’s when our front-end developer came to my rescue. He took the chainsaw from my hands, and gave me a ruler that enabled me to size a storm door properly to the frame, or in my case, cleanly style a carousel.
An acronym for Syntactically Awesome Style Sheets, it is well named.
Its most basic and powerful feature allows a developer the ability to avoid repetitive scopes via nesting. Here’s an example:
//CSS
.wrapper { width: 100px; }
.wrapper .button { color: red; }
.wrapper .button .big { height: 100px; }
//SASS
.wrapper {
width: 100px;
.button {
color: red;
.big {
height: 100px;
}
}
}
That one trick makes styling in SASS much more pleasant than CSS. And the nice thing is that SASS is compiled into regular old, nasty CSS for you. Throw in Compass, and you now have a toolset of cross browser, pre-built reusable styling patterns at your disposal.
For instance, need a nice, horizontal list? Just include the following in your SASS file:
@import "compass/typography/lists/horizontal-list
//And to use:
ul.horizontal {
@include horizontal-list;
}
If you’re using CSS exclusively, you are missing out. And I can tell you, even if you are a primarily backend software developer, as long as you have a basic understanding of CSS, SASS/Compass should come easily to you. A one hour overview was enough to get me started, and a few fifteen minute refreshers got me through the project with a carousel that meets the design specs without hiding a very ugly frame.
If you are a rails engineer, SASS is already built in to versions 3.1 and later.
This article is not meant to be a comprehensive guide on how to install and fully implement SASS and Compass, but I hope it inspires you to look into it if you haven’t already. In my opinion, back-end developers should be as competent as possible in front-end work as well as server-side stuff. I’ve been bitten so many times by having to constantly offload front-end work to other devs. Depending on their schedule, which is often quite busy, you may have to wait a good bit for the styling to be complete before you can move on. Plus, it’s just fun being able to put together the engine and paint the frame 🙂
If you’d like a comprehensive guide on how to install SASS and Compass and use their many awesome features, I HIGHLY recommend the following book.
Pragmatic Guide to SASS by Hampton Catlin & Michael Catlin
Short enough to read in a day or to, and useful afterwards as a reference, it should pretty much get you fully up to speed.
Good luck SASS-ing!
Go – Is it A Programming Language to Consider?
I’ve been researching up and coming programming languages, and Google’s Golang (Go) language looks very interesting! As far as web development, looks like the Revel framework may have a bit more maturing to do, but as far as efficiency, Go seems to have a lot of potential! Although ruby will remain my first love, Go looks to be a worthwhile language to learn. I’m also interested to see what happens with the open source project Skynet, which marries Go with Ruby via polyglot computing (basically seamlessly utilizing multiple programming languages as needed to get a job done) for building massively distributed apps.
On April 25, 2014, Github initiated the following security patch (https://developer.github.com/changes/2014-04-25-user-content-security/).
Unfortunately, the redirect from github.com to githubusercontent.com was failing during chef provisioning for my team’s vagrant instance.
I forked rvm and updated appropriate instances of github.com to githubusercontent.com to accommodate the Github security patch.
RVM has since been updated to include these updates in version 1.25.25. The issue was closed here.
If you’re looking for an inspiring software development book with practical advice on how to become not only a better programmer, but a better employee, communicator, and overall balanced person, I highly recommend The Passionate Programmer by Chad Fowler.
As software developers, we have the unending pressure and desire to continually improve our craft, to stay ahead of the curve, and not become obsolete in an ever changing industry. Chad offers useful tips on how to improve personal productivity within one’s current place of employment, expand industry knowledge and confidence by contributing to open source software, and brand oneself by becoming a helpful member of the software development industry as a whole.
Self evaluation and incremental, daily goals empower the developer to achieve these tasks. Even those of us with an already busy schedule can daily implement small drops of Chad’s advice to the bucket of our career which will help keep each of us relevant and useful in the software development industry.
Each chapter is short and the book is laid out in such a way to make it difficult to put down. Perhaps the first non-fiction book that kept me up late reading for a few nights, I found each of the 53 tips relevant. And each chapter/tip is followed by a call to action with very do-able suggestions to help you implement the tip.
Well worth the read and I’m already am attempting to put Chad’s advice to practice!
If you need an html, xml, etc… parser for your latest Rails application, nokogiri may be the tool for you.
Allow me to introduce a real life example for which I found it quite useful.
While writing some RSpec tests today, I ran into an annoying little problem.
One of the functions I was testing was logging output to my console as I ran the tests.
Being a little OCD, all I want to see while running tests are my green dots representing my tests are passing, or the occasional red F indicating I need to look into something. I don’t want to see a boatload of other rouge info. The solution, surprisingly, took me more than a few seconds to find after Googling, so I figured I’d post this quick fix to help any others searching for a fast way to ignore console output from ruby “put” functions during RSpec tests.
If you want to provide a fast way to ignore puts in any test, add this code to the spec_helper. If it’s a one-off fix, just add it to the spec you’re in.
def ignore_puts
before do
$stdout.stub(:write)
end
end
What this is doing is just stubbing out the stdout write method, which, in layman’s terms, is overriding it to do absolutely nothing. The only caveat to note here, is that if you’re using pry to debug your tests (a practice I highly recommend), the debugging console won’t give you any contextual output. So implementing the ignore_puts is something you may want to wait to add if you think you will need to do some heavy debugging in your tests.
I ran into an interesting dilemma today with a controller spec.
I needed to verify that a post to my controller’s update method did indeed update a particular setting on an instance of one of my models. Unfortunately, the controller I was using inherited some before_filter(s) from its parent that called a method that checked for a logged in user.
But all I wanted was to make sure my model’s setting actually got changed!
It now marks one year since I began my adventures in Ruby on Rails, and what a year it has been!
I began looking into rails while walking my newly born, colicky daughter in a front pack as a way to keep her comfortable and mitigate her constant crying. My learning came mostly from Lynda classes on RoR. I often walked for hours at a time, since that was the only activity my daughter seemed comfortable doing. In some ways, it was miserable, in others, extremely rewarding.
I recently ran across an instance where I needed to pass a relatively simple OpenStruct from a view back to the controller via a GET. It was a strange situation where I needed the OpenStruct to populate some tables in the view, but upon a user submit, needed to use that same OpenStruct back in a controller action.
I found a bad way to do it.
The Ruby Railroad 