Chris Oliver

If you notice the INSERT INTO statement does not include an email which means your tests probably aren't generating random email addresses for the AdminUser objects it's trying to create. You should make sure that those are being generated on your own or with something like factory_girl so that you won't have conflicting user objects in your tests. I'm pretty sure that'll solve your problem once you get that fixed up.

Whoops, I had this tab open to reply to at some point...9 days later. :P

Yeah, you'd probably need to pass the partial name in to pass over the presenters that way. I'm sure there's some way you could override some things in the presenter trick Rails into rendering the proper partial name automatically. The draper gem might be able to do that and have some insights on how to pull that off with your own implementation. I know that they have a Relation-esque collection object that might be what you'd need to add to your own implementation from scratch to do that.

Yeah, I can see going both ones. On one hand, the developer effort is easier to just generate and save the recurring events but it makes the user experience a lot tougher (how do remove them all? what if you want to edit all of them? what about just one?). And then on the other hand, it's easier for the user, but tougher on you as a developer to build the ice_cube style recurring events and query for those.

You'll probably be fine either approach you take, just remember it can always be changed and improved later on so it all depends on what business needs are most important. :D

Awesome, good luck and let us know how it goes! Only other thing I'd mention is you might want to change the name of Account to User so it's more standard for anyone working on the code later on. 🤘

Hey Orlando,

Would the Account be what the user logs into in your example?

I think that would make sense. You can then have multiple users for a single school (say several administrators) or even both parents could have separate accounts with your app.

Everyone could login through the same Account sign in form and then be redirected appropriately to the various views for parents or schools depending on their account type. That's probably the easiest experience for your users than having two separate login pages, one for parents only and another for schools only.

Ah yeah, that's a pretty complex one. I think what I would probably do is this:

1. Query for all the individual events
2. Query for all the recurring events within that range. This would match recurring events where the start date is before the end of the query and end dates of null (infinitely recurring) or end date after the beginning of the query.

Then I'd load those recurring events into ice_cube and then run the generator to create all the events for the recurring ones within your query range.

3. Then you can combine those two arrays of events into one and your view will have an accurate set of event objects to use for that query range.

Obviously, it's not as simple as the alternative of making recurring events just insert regular event records into the database. That may be good enough for your solution, or you may want truly infinite recurring events which would require you to build a bit more of a complex query system like above.

Here's the latest episode on advanced counter caching. 🙌 https://gorails.com/episode...

Depends on what you're trying to accomplish (like everything right? lol). What kind of search are you trying to pull off?

Yeah that's correct, if you're doing both you'll want to make sure any forms submitted verify authenticity token and the JWT token is the only one that should skip that. 👍

That's a great question. If you need to build decorators that work in both cases, then yes, you'd want to do one of two things:

1. Separate decorators for JSON and HTML and wrap them accordingly depending on the response type. Downside to this is more decorators.
2. Build generic decorators and leave it up to your views. Downside to this is that part of the benefit of having the link_to's and etc in the decorator is that your view can remove logic entirely. That's probably not possible if you're not able to write logic in the decorator.

That's a fun one. I would imagine you could build a validation for this that would do what you want.

Some pseudo code for you:

class Model
  has_attached_file :attachment

  validates :attachment_against_api

    def attachment_against_api
      response = API.send(attachment)
        errors.add(:attachment, response.message) if response.failure
    end
end

I thought that was the case! It didn't work for me the first time I tried it, but it could have been spring caching things or something. Thanks for sharing that. :D

CSRF tokens are generated for each user, which is why they should not be cached. The CSRF tokens are specific to each user and request so that you can determine whether or not it was the user taking this action or malicious code.

To solve this you have 3 options:

1. Don't cache the form
2. If you're fragment caching, use Javascript to include the CSRF token. See here: https://coderwall.com/p/0sctaa/forms-csrf-authenticity-token-and-fragment-caching-in-rails
3. If you're doing full-page caching, use one of these mthods: https://www.fastly.com/blog/caching-uncacheable-csrf-security

Hey Aime,

I don't believe there was much (or any?) CSS in that episode that I wrote. All the source code for that episode should be here: https://github.com/gorails-screencasts/gorails-episode-78

Atwho.js does include some CSS with the library to style the mention box: https://github.com/ichord/At.js/blob/master/src/jquery.atwho.css

Yep, shouldn't have a problem. You can always check out their GitHub if you run into issues.

Rake isn't deprecated, they just added a way for you to call it with the rails command so it's less confusing when to use rake vs rails commands. It still functions exactly the same, just simpler now. 🙌

I mean to reply last week but lost the browser tab. :)

Absolutely love these suggestions and I'm going to record a video on advanced counter caches for sure. Please keep the suggestions coming, these are all fantastic and a welcome addition to all the beginner screencasts I often get requests for.

Lots of options. Depending on how long it takes you might want to do this every 4 hours or something instead. You might want to do a live replica database for realtime backups to another server and then archive a copy of it nightly.

You're welcome! Let me know if you have any suggestions on other topics like this you'd like to hear explained. it's easy for me to take these things for granted these days so ideas for topics are always welcome!

Make sure you're not requiring the active admin css file in your application.css on accident (probably with a require_tree). Their CSS is made to be compiled separately into another file out of the box and so you don't want to include their CSS with yours. That's probably happening with a bad require or import in your application.css at the top.