I was pairing with a coworker the other day, and we ran into an issue that we have started to encounter more and more since we started to break up our monolithic Rails app into microservices. The problem is complex and requires some background, but the solution, I think, is elegant and simple.
This is part two of a two-part tutorial. If you haven’t already, get up to speed on part one. In the last part, we took a look at getting a Rails app set up with Backbone.js, and introduced some of the modular concepts behind Backbone: models, collections, and views. In this part, we’ll dig in further to templating, as well ashandling user input with Backbone’s
Event module. Finally, we’ll refactor our app and improve the user experience.
Let’s get started.
Editor’s note: This tutorial assumes a basic comfortability with basic Rails concepts, as well as running tasks on the command line. An understanding of jQuery is helpful, and while CoffeeScript knowledge isn’t absolutely mandatory, not having a strong aversion to it would be beneficial. This is part one of the tutorial. You can find part two here.
I know I’m late to the party, but I’ve been digging into Backbone.js lately, and I’ve run across a few things that have really tripped me up because I didn’t understand the framework well enough.
In looking at the documentation on listening to events, for example, you find that
listenTo does the following: “Tell an object to listen to a particular event on an other object.” Let’s take a look at an example.
Because all of my programming was confined to the two languages I was most comfortable with (and the fact that I didn’t study computer science in college), there were aspects of programming that I had absolutely no concept of. For example, I had been reading a lot of what Steve Klabnik has been writing on the Rust language, and I was immediately out of my element when he started talking about concepts such as pointers, a concept it seems is immediately familiar to programmers of C++. This is to say nothing of manual memory management or other close-to-the-metal concepts.
In light of all this, I decided to begin the foray into a new language in the hopes of broadening my perspective. Continue reading…
Getting Ember set up with Jasmine and Rails 4 is tricky. I’ve done the hard part and set up a skeleton Rails app that contains a passing Ember model test as a starting point for your apps. Feel free to fork the repo and start a project if you want to use Jasmine to test your Ember app. For more detail about how to get it working, and a pretty thorough run through of some high- and low-level Ember concepts, read on.
I’d like to offer Nicole Sullivan a public apology for dismissing her work. But first, a bit of back story.
I’ve finally gotten around to putting my recent talk on Triaging Rails Issues on my speakerdeck page. The slides are extremely terse, though, and it will probably be easier to follow by watching the video of my talk, embedded here. (Thanks to Dave...Continue reading…
I often find myself wondering why so many of the Ruby native string and array methods have aliases. For example, with string methods, we have
succ, which are equivalent; they both return the next alphanumeric character. Like so:
1.9.3p194 :024 > string = "a" => "a" 1.9.3p194 :025 > string.next => "b" 1.9.3p194 :026 > string => "a" 1.9.3p194 :027 > string.succ => "b"
So why do we need both? Continue reading…
At work, we’ve been moving away from Cucumber tests for the past number of months, in favor of the more robust Capybara and rspec paring. Given that I’m a relative novice in Rails test-driven development, the supposed brittleness of Cucumber tests wasn’t immediately clear to me, so I did some digging, and came up with a few posts that talk about the pitfalls of the “imperative” style of step writing for user stories. Continue reading…