Chris Oliver

Ah! I got you. I would actually move things up and create a CS class that wraps the entire answer and then delegates down. Take a look at this.

class DWiz.Answer
  constructor: (@answer) ->
    @answerList = new DWiz.AnswerList @answer.find("[data-behavior='answers-list']")
    @comments   = new DWiz.CommentList @answer.find("[data-behavior='comments']")
    @comment    = new DWiz.Comment @answer.find("[data-behavior='comment']")
    @new_comment_link = @answer.find("[data-behavior='new-comment-link']")

    @setEvents()

  setEvents: =>
    @answer.on 'click', "[data-behavior='show-comments']", (e) => @answerList.toggleCommentsAndSetFocus(e, @answer, false)
    @answer.on 'click', "[data-behavior='new-comment-link']", (e) => @answerList.toggleCommentsAndSetFocus(e, @answer, true)

class DWiz.AnswerList
  constructor: (@answerList) ->
    @setEvents()

  toggleCommentsAndSetFocus: (e, answer, setFocus) =>
    answer.commentList.toggleComments()
    answer.comment.toggleComment()

    if setFocus
      answer.comment.setFocus(answer.offset().top)

$(document).on "page:change", (e) ->
  #answerButtons = $.map $("[data-behavior='new-answer-btn']"), (item, i) -> new DWiz.NewAnswerBtn(item)
  #answersList = new DWiz.AnswerList $("[data-behavior='answers-list']")
  @answers = $.map $("[data-behavior='answers']"), (item, i) -> new DWiz.Answer(item)

It really doesn't need the "AnswerList" class anymore unless you plan on doing more complex things with it. You could simply move that method up to the Answer class. I kind of like having them separated because it shows much more clearly who handles what.

The giveaway for this refactoring was that you were doing parentsUntil you got to the answer. That meant to me that you should actually have the CS class accept the answer instead, and then you could create references to all the children and they could talk to each other much more nicely. Anytime you catch yourself doing "find" outside the constructor, you can usually pull those back up to the constructor and reference them later.

Does that make more sense?

Hey Roy, Would you mind sharing what CS you've got right now? I can probably give you better pointers with that and show how I'd probably refactor it. That might make things easier.

The main reason why this is happening is because anytime the page updates, you're adding another listener to the existing items too.

What you'll actually need to do is scope your click event to the parent with jQuery. Here's a better description of how to do that: http://stackoverflow.com/a/8752376/277994

This way you won't be applying the click event to every individual item, but to the parent and then detecting the click on any of the children (which allows you to automatically target the newly added html).

It actually includes bundler, assets, and migrations in one. https://github.com/capistra...

Welcome to the gotcha that is has_and_belongs_to_many :) It's not really designed to do this. However! You can just swap the association out with as has_many through and it will work just the same:

# This might not exactly map to the same database table name, so may need to either tweak the name of this model or rename your database table
class CaseStudySite < ActiveRecord::Base
  belongs_to :case_study
  belongs_to :site

  # Here you can just set this up so that it's automatically sorted every time
  default_scope ->{ order(position: :asc) }
end

And then your other models can reference this:

class Site
  has_many :case_study_sites
  has_many :case_studies, through: :case_study_sites
end

Do the reverse of this for the CaseStudy model and that'll give you access to everything.

Now that you've got a model representing the join table, you can have full access to it and adjust the positions as you like.

Awesome! I haven't heard back from them yet, so maybe it was a little downtime on their end yesterday.

I'll ping Wistia and see if they have an idea why that's happening. Worst case I imagine I can re-upload it.

Hmm, I tried downloading too and it keeps cutting short. It should be almost 600MB. Not sure what's wrong. Does the video fully load for you?

I still need to walk through deploying this to production, but you should be able to use Puma just fine in production.

Yes it is. Not sure why it's not opening for you but, here's a Youtube link https://youtu.be/VvuPsXQwRrQ

Octobuild sounds like an awesome idea! I hadn't heard of it. Thanks for sharing that!

Also awesome start to the USDS project! It looks great so far. Nice and simple. :)

You can probably create a validation for it somehow. You'd need something to read the video in Ruby and check the length. Ideally people are uploading the same format of video all the time so you can do that easily.

This is a pretty awesome site to learn about it, also they have a bunch of links to screencasts: http://betterspecs.org/#scr...

You should be able to just upload them! Just make sure you don't include any validations that force images or styles that try to resize them. You'll just want to have raw uploads in that case. That's really all you need to do.

That would be the Turbolinks progress bar. It gives you a sense of progress since the site is using Turbolinks and the browser doesn't actually show progress when pages are loading. You can find out some more about it here: https://github.com/rails/turbolinks#progress-bar

I'm just storing the wistia video ID in Rails and then embedding the videos.

The one thing I might think of is that you want to make sure you're using ERb asset_url helper appropriately to reference your images. If you're using those through CSS, you can use the "asset-url" helper in your CSS. The urls that are used in production have different URLs than in development so you have to use these helpers.

It's basically designed to be simpler rather than customizable, but you can take the PDF code that's in the gem and adapt it easily to add your own header and footer. Take a look at this code: https://github.com/excid3/r...

Thanks for the kind words Felipe! I really appreciate it. :) Really glad you like the gem and the architecture of it! I think the videos turned out to be really fantastic documentation that I never planned. :)

You can update your config when you setup Omniauth, you can specify your scope there. There are a lot of options for this, so just look up the available scopes for facebook to get the full list.

config.omniauth :facebook, "APP_ID", "APP_SECRET", scope: 'email', info_fields: 'email, name'