Chris Oliver

Yeah that solution only really works well for whole numbers. One option would be to interact with meters, but actually store centimeters as whole numbers in the database for example.

Otherwise, you probably will want a separate model for recording each time things are taken. Then you could specify the "amount" on it, such as "6.5" so that instead of having separate records for each individual one, you'll have one record for the total amount taken at the time. You'd sum up the amount column to find out how many were taken rather than count the records like before.

I don't have time to at the moment, but might be able to next week.

Yeah, that gets pretty tricky. We had to do that at One Month and it became kind of a complicated piece of work. It was a nightly cron job that calculated the end of the month on the same schedule that Stripe would do monthly. We would look up users expiring and give them access to their next course. You also have to take into account things like extra days in months, leap years, etc. It's really not fun so if you can get by without offering the yearly plan for something like this, I'd probably recommend it.

You could also have a simple 30 day schedule for every yearly user that's a little different than the monthly users. People generally won't notice the difference and it's a lot simpler than making a perfect copy of what Stripe does yourself.

You might be able to add an association to the task like has_one :project, through: :domain to remove the domain out of it, but it's not going to make much difference. Shortening this only really moves this code somewhere else.

I'm not entirely sure I'm following. What's the domain object for? And the problem you're having is trouble rendering the task's project name? Does something like <%= @task.domain.project.name %> work?

How are you associating the tasks to the project and what code do you use to switch them between projects?

In this case, the information is just saved to the database so you could do what you want with it.

So we use public_activity to track the views and completions of each step. You can complete a step a few times, so to calculate the progress, you count the number of unique steps completed by the user and the total number of published steps in the course and divide those. That's really all there is to it! The public_activity gem makes creating the activity records pretty easy so than all you'll have to do is grab a count after that.

The Facade Pattern is a pretty simple one. In Rails the guideline is usually to only have like one instance variable that your controller sets. Reality is that often times you need several variables to render the page, so they create a little Ruby object that's nothing special like their example of Dashboard. It just has a few methods so you interact with the Dashboard instead of several different instance variables in the view.

This pattern doesn't really improve your code all that much. It more hides the complexity behind a facade (hence the name) but it significantly improves the controller code.

You can simply create an app/facades folder for this and as long as the directory loads (you may need to add it to the Rails config, can't remember), then all you'll have to do is create some basic Ruby classes that load the correct records and you're all set.

You beat me to it! Pundit's exactly the right thing for this.

Maybe, maybe not. It's definitely new but it's not much more than some basic scaffold generators right now. Nothing too special. I wouldn't use it on a client project yet, but I'd absolutely use it on personal projects.

Just Github or if you decide to release the gem publicly you can put it up in ruby gems so that you can use it like any other gem.

You could basically store a hashed password on the album and then prompt for the password. When they type in the password, run it through the same hashing algorithm (check out bcrypt) and if the hashes match, you can set a cookie letting the user view the page. This is basically how email/password logins work.

Fixed! Accidentally had the old video URL under http instead of https.

The second argument there needs to be hash I'm pretty sure. You're passing in a string, so that's probably going to mismatch the arguments it expects. Try changing that to hash and that should fix it for you!

That's a really great question. So it would obviously be fantastic if they created private gems that were only accessible to purchasing customers. That would be the easiest solution. Since it seems like you don't have that, you can do a couple things:

1. You can just drop the theme files into the vendor/assets folder and use them in your app just like if you were to do this with Bootstrap without a gem.

2. You could create a gem like I did in that video and host it in a private Git repo and reference the git repo in your Gemfile.

Personally I'd say #1 is probably the easiest if they're not providing a gem because you can easily update things. The benefit of having a gem is that you can use it in multiple applications and keep them all in sync a lot easier that way. Really up to you whichever fits you best.

Spree is one approach if you want to use something premade.

As far as keeping inventory of things like shirts, you can probably do two separate things:

1. You keep track of new additions to our inventory, maybe call them new stock or something. Record the amount of tshirts added each time you get more inventory added in stock.
2. Keep track of the orders and the quantity of shirts leaving each time.

The total "in stock" inventory will simply be summing up all the times you added new stock and subtracting the sum of all the quantity ordered. You can cache a copy of the current value in stock and update each time you add inventory or have new orders.

You can then get a history of the inventory over time in your store and what's leaving. This will be helpful for seeing and predicting how much inventory it makes sense to keep on hand and can be useful for other things as well.

Nope, but might want to check to see if you've got JS errors or conflicts with Turbolinks.

This probably depends on a lot of things. Are you getting in shipments of new items? Are the products being consumed? (sometimes this might not be the case if you're talking like inventory of trucks for example)

More details on what you're shooting for would be helpful but I'm sure we can come up with a fairly straightforward solution to it.

Well, the params in the routes are used to lookup the ID column in the tables. You're using the same params id to look up two different records which doesn't quite make sense there. I would not set the forum_post in that before_action so that you don't run into weirdness.