Chris Oliver

Fetch is really great because it can throw an exception when your key is missing rather than just calling undefined methods on nil later. It's great for that but it also is a little cleaner than the "or" like you mentioned.

Check out Janus (https://github.com/carlhuda.... It's a collection of Vim plugins that give it some pretty great defaults and can save you a lot of time learning Vim at the beginning.

I wonder if maybe you need to call super() at the beginning of the initialize method so the Icalendar gets initialized properly.

Hmm, can you post the stacktrace?

Awesome! That's not too bad.

I believe you could extract this out into its own class to clean up your controller a bit:

def ics_export
  @myevents = Event.all

  respond_to do |format|
    format.html
    format.ics { render text: Ical.new(@myevents).to_ical }
   end
end

# app/models/ical.rb
class Ical < Icalendar::Calendar
  def initialize(events)
    events.each do |myevent|
      event = Icalendar::Event.new
      event.dtstart = myevent.event_date
      event.summary = myevent.name
      add_event(event)
    end
    publish
  end
end

Note that in this file you don't need to call cal. on add_event and publish since you've inherited those methods and you're inside the object. I also pulled out publish to the end so it only gets called once. I think that doesn't need to be run each loop but maybe it does.

I've always used acts_as_list and been really happy with it. https://github.com/swanandp/acts_as_list

This is awesome Jay! Thanks for posting it. I definitely did cut out some of this because I wanted to focus on Devise rather than Bootstrap. This will come in handy for a lot of people I'm sure. :)

I haven't, but it definitely looks like ri_cal hasn't been touched in several years. I'd probably have to recommend iCalendar just based on that but their documentation and API don't appear to be the cleanest.

Wish I had more information for you on it, but I haven't had to create .ics files before. Maybe that'll make for a good screencast.

The easiest way is to use a counter cache column. It can keep track of how many likes each post has and saves it on the post so that you can quickly and easily query that. There's an old Railscast on it that I'd recommend: http://railscasts.com/episo...

You could also do it with a join and a group by query, but a counter cache will let you sort the information at any time quickly.

Are you trying to create a company before they create a user on sign up?

What I do in this case is use the user registration form and do fields_for :company inside of it. That way you can't create a company without attaching it to a User. I can ask for teh company information first, but in the same form I also submit the user details which save the company and associate the user as the "Owner" of the company.

Am I following you correctly?

Looks like you can if you add the "dateext" option. More details here: http://www.thegeekstuff.com...

Great idea! I've done that in the past when I wasn't sure why it wasn't rendering and that helped a lot. :)

That's definitely an option. I prefer not to because the QUESTIONS are related to business logic regarding some type of model and the SMS class just purely contains logic on how to send an SMS. This way it's separated from other concerns and is purely on its own. You could extract this out into a library if you wanted to share it between apps for example and you wouldn't have the QUESTIONS and other dependencies.

Oh yep, you're right. It's easy to miss stuff like that when you can't actually execute the code.

Whoops, you're totally right! Thanks for the comment. That was my bad. I knew I was probably overlooking something calling it "send".

Definitely a problem when you don't have the full Rails app to test your refactorings against.

I'll be sure to cover more topics then! Feel free to email me any examples of code you'd like to see refactored and I'll see what I can do.

Check out rolify for database backed permissions. It is pretty flexible and shouldn't cause much if any downtime if you migrate from static permissions to database ones. You'd simply create the role records in the db before deploying the rolify backed cancan config so that there was no trouble.

Definitely wise to have expirations on tokens. Also you will probably want to tell your users to keep the token secret (like don't commit it into a git repo for example). There's not much way around that because any API token is going to let you access the site on behalf of a user since that's what they are designed for. Just want to make sure to educate users to protect their tokens just like they would their password.

That would do it! Sometimes the file permissions or ownership will do that. I've often accidentally run a command as sudo without realizing it would change ownership of my app files and all of a sudden Nginx can't read the Rails app anymore.

Thanks for sharing your solution! :)

That's the plan. Twitter is a bit frustrating because it doesn't give you an email so you can't create Devise users easily with it. Need to store the OAuth hash in the session so you can ask for an email first. I'll be doing an episode on that soon.

Yep! You can make the likes polymorphic if you want them to apply to more than one model. That would let you add likes to Threads and Posts. You'd build it pretty much the same way and that should do the trick.