Chris Oliver

You'd have to look at Shrine's code for that, but if it doesn't support it yet, I'm sure it'd be very easy to add since it appears to simply be an additional header to add to requests. That would be a great open source contribution if it doesn't support it already!

PutObjectAcl lets you change the ACL of an object in S3. This may not be required, but it's useful if you want to change permissions on files ever like making them public or private. http://docs.aws.amazon.com/...

That's fantastic to hear! You might like the latest episode on fixing the Paranoia gem as I dove into the gem itself and ActiveRecord's counter caching to figure out how to fix counter caches when you're doing soft deletes. Neither of those I have seen the internals of before and it was fun to go in and figure out how they worked to go fix them. :)

Let's encrypt should write logs somewhere, or you could tack on a little bash snippet have it output top your own log file too and write the last timestamp it ran.

1. I'm not quite sure what you're asking on this one. Rephrase and try me again? :P
2. You'd have to index them combined, so you'd make a "name" attribute that was those concatenated and then search on that instead of the separate fields.

You can render any partial you want, Rails just provides a lot of helpful shortcuts when you pass in ActiveRecord objects. Here we're rendering one called app/views/posts/_likes.html.erb. Since this is being rendered inside a Post view, it looks in the posts folder for the partial file although you could specify any folder you wanted.

You have to create that partial, it's not one that will be autogenerated for you, and we do this for organization of your code. You can reuse that partial in other places if you want and it will output the same HTML.

All the final code you can find here: https://github.com/gorails-screencasts/gorails-24-liking-posts

Since this is an administrative thing, you could explicitly pass in the user id like this: masquerade_path(@user.id) which should always put the numerical ID in, or you could take a look at overriding the masquerade query to use the friendly.find that is required for friendly_id lookups. I'd probably just pass in the ID explicitly since it's only accessible to admins.

And you can make sure this is accessible only for admins by doing this if you're using CanCan or putting your own before_action in the overridden controller to authorize for only admins: https://github.com/oivoodoo...

I don't think I mentioned authorizing that url in the episode like I should have. That's an important piece!

That's a great question. I don't see any need for authentication.

I mean, worst case if someone started abusing your API, you could do some simple checking to make sure the requests came from your mobile app by verifying a user agent header specific to your app. If your API runs on SSL, then those headers should be encrypted so that no one could sniff that user agent to apply to their own requests. Same sort of thing could be done by doing a basic auth requirement for your app and hardcoding the password inside the app. Those are both probably findable if someone disassembling the app, but you'd really just want to prevent any basic abuse if that ever became a problem. Rack-attack's a useful gem to prevent too many requests from hosts as well that could be useful to keep in mind.

Most of this is all unlikely to be needed and you could roll out changes for this stuff later on too if it became a problem. Probably not something you really need to worry about too much, just like you don't worry that much about it when you're building a public website until abuse becomes a problem.

And since there's no real need to have accounts, storing preferences on the device makes perfect sense. There is a unique device ID for each phone, so you could send that over to be the identifier for storing preferences server-side if you really did need to restore preferences after a reinstall.

Well, your search in the navbar implies that it's a global search, not just for the category you're viewing. You can do searches across the different models and combine the results (maybe show the current category results first). You can see an example of this on Facebook with the global search bar, yet different categories of results (pages, people, businesses, etc).

That would definitely make for a good episode and I've wanted to do this for GoRails sometime soon anyways to search both episodes and the forum.

This is awesome. I haven't extended sprockets myself before and that looks like it turned out rather nicely. I'm impressed! :D

Hey Stephen!

Rails doesn't have anything built-in to support this kind of feature. It doesn't make many decisions on how you should handle the frontend for you which makes sense since it's a backend framework more or less.

As far as what you've got, I'd say it's definitely not bad. There are some improvements you could make by having it become more dynamically created.

For example, you could store a Hash of all the data in Javascript or somewhere in the HTML and load that up into the JS. Once you had the data in an object in JS, you can then dynamically create the select options and everything from there. An example of that would look something like this: http://stackoverflow.com/a/6601129/277994 Yours would need to be a little more complex because you have different groups of data to show, but the concept is similar.

You can imagine having an object in JS that looks like this full of data (you could structure this any way you wanted):

var regions = {
  "us": {
      "name": "United States",
        "states": [
          "ca": {
              "name": "California",
                "cities": {
                  "losangeles": "Los Angeles",
                    "sanfrancisco": "San Francisco"
        }
          }
        ]
    }
}

And if you had all the data like this, you could then grab out portions of it to fill out your fields. Such as you could gather all the name values of the top level regions to populate the region select. Once a region was selected, you could grab the states from it and populate the state/province level from there and so on.

It would require a lot of work to change, so don't feel like you need to clean it up right away. You can always improve this code later once it's working.

Check out https://github.com/rbenv/rb...

This lets you write a .rbenv-vars file in your rails app directory and set environment variables separately outside of your Rails app.

I'm using this for the new Rails hosting service I'm working on and it works wonderfully for separating environment variables out for each app.

Hey Nicolas,

That's great then. If you don't have any forms or anything for now, just cache it all and don't care about it.

You can add Javascript and an endpoint for the CSRF token later on when you add the contact form in the footer which you'll probably want to submit with AJAX anyways. It'd make perfect sense to just add in a csrf endpoint to retrieve the token and submit it in that case.

That's one of the easier solutions for caching since you don't have too much dynamic content and that'll make your life a whole lot simpler. :)

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...