Chris Oliver

You can definitely strip out the commas or periods when the user submits the data if you want by overriding the setter methods. That would let any value be submitted and cleaned up before storing it in the model.

def population=(value)
  super(value.gsub(/[.,]/, '')
end

Something like that should do the trick.

Since it's just formatting, it's usually best if that just happens on the client side. That becomes even more useful in other languages that might use a period as thousands separators instead of commas. They can change their locale and the backend data would not have to change for that. Plus, the backend doesn't have to worry about modifying the formatting, just validating it.

Either way will probably work fine though.

Fake form fields can accomplish what you want.

You can use formatting in the visible form field, but convert to the number in a hidden field. The visible field is not given a name field which means the browser does not submit them to the server.

The hidden field will be what's submitted to the server. You'll use some Javascript to make sure the field continues formatting as the user changes the value.

This is how date selectors that use a Javascript calendar popup work a lot of times. Same for credit card fields. 👍

Make sense?

Rails has several helpers for numbers.

number_with_delimiter(population) # outputs 422,334
number_with_precision
number_to_currency

All part of the NumberHelper: https://api.rubyonrails.org/classes/ActionView/Helpers/NumberHelper.html

Numbers should always be saved without formatting in the database and then you'll use a helper like the above to format it.

Hey Marlon!

We're using the acts_as_tenant gem in JumpstartRails.com for row-level multitenancy. It works pretty well and will automatically set your tenant ID when querying and saving records. You end up building your app like a regular app that way which is nice.

I wouldn't recommend Apartment anymore because it's not row-level tenancy. It's far more common to see row-level being used.

It's not intended to be a full WYSIWYG which is what you're after. I know several people like using https://imperavi.com Article and Redactor and they're really well made.

He loves running around and being noise when I'm trying to record. 😺

I would say, don't think of it as folders on S3 or the file server. Use database records to group and organize them in your app. They don't have to exactly mirror the files on disk.

Julian Rubisch put together a gem that makes this easy: https://github.com/julianrubisch/futurism

💪 This is awesome Nate! This is a great opportunity if anyone's interested in getting a bit of experience working with a team.

I said that and decided to look at the Pay gem and think I figured it out.

The Rakefile in that gem loads the Rakefile from the dummy app. That makes total sense.

APP_RAKEFILE = File.expand_path("test/dummy/Rakefile", __dir__)

I need to figure out what's up with the Rake tasks, but I've had to go cd test/dummy && rails db:schema:load to get it to load the db tasks for testing.

I'm pretty sure it's something small that's missing, but I haven't had a chance to look yet. If you figure out what's missing with the Rakefile, send me a PR! 😜

If you read the logs, you'll see it crashed while loading secrets.

/home/deploy/bane/shared/bundle/ruby/2.6.0/gems/railties-5.1.6/lib/rails/secrets.rb:24:in `parse'

So my guess is that you're missing secrets on your server or they're empty or not formatted correctly.

Yeah, we'll do DMs. 👍

They'll be very similar to before. Basically just a chatroom with a direct message flag like we did previously.

And glad it's been so helpful! This is the community I wish I had a long time ago, so that's great to hear!

Yeah, you'd want to change your DNS to point to the new IP once the site is ready. Before you do that, you can change the TTL down to the lowest time so your DNS records will only be cached for the minimum time making the new IP change happen quick.

With your database on another server, you won't have to migrate that so it should be a lot easier then. 👍 You can actually run both copies of the app at the same time and make sure they can connect to the db and then change the DNS as the final step.

You'll also want to make sure any SSL certs are copied over. Forgot about that too.

If you spun up a new server and deployed the app to it with Capistrano, really the only thing you'd need to move over are any file uploads and the database. You can dump the postgres database then upload and import it on the new machine. Same with the files. That would be really all there is to it.

@oomis, take a look at the Pundit episode. Since I wrote this, I've used the Pundit gem for authorization over CanCanCan. It's less confusing to me. https://gorails.com/episodes/authorization-with-pundit

Hey Stephen!

The way I do it in JumpstartRails.com is we have a single User everyone logs in as and they have multiple Accounts they're associated with.

Each account could have a type of Coach, Client, etc and they switch between them with a session cookie. When they switch, we use current_account to load the account and we could use that to determine if they should see Coach or Client views.

Yep, that's the built-in way. Sounds like your code doing the validation is strict about what type of object it is (a Hash) and that's the part that's not very Ruby-ish.

Ah, well you can always cast it to a hash with to_hash