Warning, this will be very negative, but it only applies to the last five or so videos in the series. I found them frustrating, confusing, and I felt less prepared to write a Backbone app after watching them. Wish I’d skipped them.
I wonder if some important bits have been edited out…? I coded right along with the first 10+ videos and had a great time, but I found that impossible on these last few. There were a bunch of times when Sean would pull up a Backbone view that had different contents from my view, or where my app’s behavior didn’t match his. Took forever to debug. This might be my mistake, of course, so I’m curious if others found this too.
Here are some random notes I jotted down while watching…
Advanced JSON Input and Output seems weird. Was it truncated? It was 100% unrelated to Backbone, and didn’t have much Rails content either. You might be able to replace the whole episode with one sentence spoken in this video, “we’re going to use ActiveModel::Serializer to render the json instead of JBuilder because it feels more natural and object-oriented to me.”
I promise it won’t take a week to understand this lesson!
The past few videos have been becoming increasingly poorly organized but Advanced Model and Relationships - Part 2 is a mess. It’s basically watching a skilled programmer just winging it. There’s no sense of design or planning, and a fair amount of time is spent on backtracking and bugfixing. It’s still interesting, true, but I think it’s a poor use of time for people like me who just want to learn Backbone and maybe Rails.
And, is it really best practice to implement the Backbone UI first, then go back and patch the rails model to match? That feels like cowboy coding. I understand why you’d want to do this in real life, especially if you’re prototyping something that you’ll rewrite later, but in a training video??
There’s an awful lot of dead air in these last few videos as Sean tries to figure out what’s going wrong. Don’t get me wrong – a few times is absolutely fine and lends an air of authenticity. Now, though, it’s getting extreme. I didn’t count, but it feels like 25% of the video is dead air, backtracking, or apologizing. Some editing or re-recording seems necessary.
Explanations and background have pretty much disappeared and Sean is doing the programming equivalent of reading the slides… He’s describing what he’s writing, but I can SEE what he’s writing. I want to know why he’s writing it!
A bunch of times you mention a more robust way to implement a feature. Sure, that sounds reasonable, but I’m worried that you’re mentioning it in passing while coding. Did you just now realize that you’re not implementing it correctly? Are you essentially dropping 'TODO: fix me later’s in your training video??
I feel like TDD would have helped here. Then you could just write the code to satisfy the test and future-proofing can come later.
Ultimately, yes, some of these design decisions do look a little short sighted. I understand that training videos need to take some shortcuts, but I want to hear about them up front during decision making, not as an afterthought!
Given the previous adventure with validations, the “Our validation here is apparently broken” comment at 6:10 of Advanced Backbone.js Behavior was kind of entertaining. Yep, we’ve been here! Now it’s feeling like something is really wrong with how backbone validations have been presented and I’m a little annoyed that apparently I have to figure it out on my own.
14:15 of Advanced Backbone.js Behavior: “Little bit convoluted but that’s OK”. No! No, that was very convoluted, and I’m not at all reassured. I have no idea why we just went on that adventure of writing stuff, backing it out, and writing some more. I don’t understand, what’s the lesson here?
The last half of “Advanced Backbone.js Behavior” is just a thrash fest.
Did you really change your implementation at 17:15 because you were blindsided by a bug? I can’t even follow what’s happening anymore, much less why.
You say, “there’s a little but of code that got funky. Particularly the way we’re saving todo lists and todo items could be better…” Well, that’s certainly true. But is this worth presenting? I’m getting the feeling I should unlearn the last 1/2 hour…
“I purposely made the Rails API a little convoluted…” Then, HOLY COW, mention this up front? I’m watching these videos thinking you’re demonstrating what I should be doing, trying like crazy to follow the decisions you’re making, then you tell me at the end basically what you did was intentionally weird and it probably shouldn’t be done this way. At the END?
So… The final app is unsatisfying. If this is an example of what I can do in a few hours with Backbone then I’m not real impressed. The pre-todos app was better. Sure, it was absurdly simple, but it worked and and had a decent UI.
I think I understand why it feels like you glued the todos models haphazardly onto the note model… It doesn’t seem like the feature was very well thought out.
I find it scary that adding the todos seems to have cause a surprising number of bugs and pitfalls, and produced some noticeable code churn and dead spots. I’d hoped Backbone was better at future-proofing than that. (I’m guessing it is, we just didn’t see it…)
Hm, Backbone.stickit is up to 0.8.0 (and 0.7.0 was released at the end of 2013) but backbone-stickit-rails is still at 0.6.3. It looks abandoned? I question the decision to include this gem in the training video.
So that’s that. Overall, I still liked the workshop. Stop before the Advanced videos and you’ll have a great time.