Chris Oliver

Yeah, like Szilard said that's basically be their way of doing the multi-tenancy. They just namespace the routes with an /:account_id or something at the beginning and have all their resources inside of that so that your account id is included in every single request. Effectively the exact same thing as doing a subdomain for multitenancy but they're already using the subdomains for the various versions of Basecamp.

What I usually do is I run "rbenv install 2.4.0" and it will say hey, this version is missing so update your ruby-build version and give you instructions on how to do that. Then running the install command should succeed then.

One step at a time. ;-)

Couple things I notice off the bat:

1. You can't look up the project until it's actually been created so there is a database ID.
2. You can't create the subscription just yet either since the project hasn't been saved yet.

Here's what I would do:

 def create
    @project = Project.new(project_params)
        @project.subscriptions.new(user: current_user)

    respond_to do |format|
      if @project.save
        format.html { redirect_to @project, notice: 'Project was successfully created.' }
        format.json { render :show, status: :created, location: @project }
      else
        format.html { render :new }
        format.json { render json: @project.errors, status: :unprocessable_entity }
      end
    end
  end

This is going to build the project in memory first. Then it creates an associated Subscription record in memory as well, but inside the project. Since the two are associated in memory, this will make sure that when you save the @project the subscription also gets saved and both will get inserted into the database as long as the validations pass.

You use Imgur at all? It's pretty similar to a movie rating app since it has ratings and stuff. I was kinda thinking something like their collapsible comments and/or navigation which are a pretty good showcase for like the usefulness of a JS framework. You can't do that easily without a good amount of JS for sure.

Hmm, I'm not sure Yelp would be a great one to showcase React because really the site doesn't have that much interactivity so you wouldn't really need any frontend frameworks for it.

Something like Facebook on the otherhand has a lot of interactive widgets where it would make sense. Each post has its own dropdown menus, every chat box is independent, all kinds of various little pieces of state for each section of the site. Facebook may be too overused as an example, but I'm trying to think of something in line with that.

I guess now that I'm writing this, of course Facebook is the obvious choice because they invented it. Hah.

Absolutely. I think the main thing I need to figure out is what's a good, somewhat small real world app I can do as an example. It's always hard to come up with something that isn't contrived feeling.

Hit me with your ideas!

Computers eh? :)

First, I'd check to make sure your cable.yml defines using redis in development so that it can be shared between processes. Second, if you run redis-cli you can say subscribe notifications:4 to have the redis cli show you the messages coming across there as well.

If you send a message on the channel, then it should show up in the redis cli. If it doesn't, you've narrowed it down to probably a configuration problem there and can debug why the message doesn't make it to redis. If it does, then you'll want to debug the client side to figure out why things aren't getting relayed to the websocket as you're expecting.

It would probably be helpful to watch those because they setup the foundation for this which is kind of like a chatroom restricted to just two people. Lots of different ways you can go about it, but this is just one approach that works nicely to reuse the features of group chat.

Hey Ariff,

Haven't recorded that yet, it kinda slipped my mind. Let me get on that this week!

Lots more Vue coming, I really really enjoy using it on the frontend. It feels refreshing to work with for once.

I'm generally pretty torn on the two. Rspec is great because there are so many examples out there, but I really really dislike the DSL it adds because it obfuscates a lot. Minitest is great because it's just plain Ruby where you can refactor all your work like you regularly would.

I guess generally that leads me to suggest Rspec if you're new and Minitest if you're good at Ruby.

@Nick, I feel the same way about TDD. It doesn't add much for me which is why I generally just add tests as I need rather than doing full blown TDD.

For now, I'm just using Uservoice for this, but it isn't the best and is just in the Feedback link in the footer (https://gorails.uservoice.com/forums/259979-general). I'm definitely planning on improving this and making it part of the site in the near future.

I love the idea of showing what episodes I'll be recording for the future couple of weeks. That would be really handy I'm sure.

Jacob is exactly right. :D

And just a quick note: generally you use these url params to do filtering (like pagination) or sorting or you'd use them to turn on and off simple features like autoplaying of videos like you see on here.

Then sometimes it's nicer to have a full path dedicated to a section to designate it's importance so I'll tend to do that for things like forum categories. Rather than just saying /forum?category=rails I've got /forum/category/databases to kind of denote that it's a dedicated page.

It's late so I don't know if I'm explaining that bit well, so here's a stack overflow post that describes the same thing: http://webmasters.stackexchange.com/a/15394

Awesome! Also hadn't heard of this library before, it looks slick!

The JWT gem we use verifies the signature every time you call decode on it, so every token is verified, as well as the expirations and other features it supports. It's fine to have multiple tokens per user (one for each device for example) but because things can change you want to use expirations so they can get a more recent version of the token. There's no need to store anything server-side in the db because this is designed to be stateless.

Does that make more sense?

AMS doesn't care about your URLs, it just takes models and turns them into JSON. You can use any routes you want. Ideally for JSON:API spec, you'll want some restful routes for the objects, but it's also fine to have routes like you mentioned for ease of use. I think of routes for concepts often, it doesn't have to be specifically for a model. For example, your routes make sense because they offer up clear endpoints for different concepts for each one.

Haha crap, bad edit!

Interestingly, there isn't a stop_stream method in ActionCable, so you'd have to stop all streams at least right now. Someone has opened a PR with this but it's still pending: https://github.com/rails/ra...

For now, I guess you can either stop_all_streams and reconnect to the ones you want, or you can monkey patch in the code from that pull request. I would probably do that because it's likely to get accepted.

And to implement the disconnect, you'd just send the message from the JS to call a method in the server side channel to call the stop stream. This would look almost exactly like sending a message, you'd just pass in the name of the channel you want to remove.