Ruby on Rails Love-In

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ruby on Rails Love-In

«‹›178 »

Pardot: Jul 25, 2001

enraged_camel posted:

I've been wrestling with Mercury Editor. Finally got it to work in my development environment, but when I pushed it to Heroku I ran into a problem that I struggled with all day today. I have the write-up here. Anyone have thoughts?

The lovely thing is that Mercury's developer seems to have stopped working on it. Which is a shame, since it's pretty awesome. I haven't found anything that integrates so seamlessly with Rails.

Are you running locally with `bundle exec rails s` ? If not your local could be pulling in dependencies outside of your gemfile, which the slug compiler wouldn't know to include.

# ? Apr 18, 2014 15:17

Adbot: ADBOT LOVES YOU

# ? Jun 4, 2024 11:39

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

KoRMaK posted:

"Hash.key(:my_key)" is not the same as :Hash.key?(:my_key)"

Question-mark methods should usually be called without parentheses; it's nicer visually, helps them stand out, and you don't typically chain booleans:

Ruby code:

params.key(some_value)

params.key? some_key

Also, in my experience, if you're looking up a hash key from its value, you're probably doing something wrong.

# ? Apr 18, 2014 15:21

KoRMaK: Jul 31, 2012

Putting simple Logger output messages inside of gems has revealed so much understanding to me and I can't beleive I didn't think to do this sooner. I the reason why I haven't felt comfortable doing it sooner is because I wasn't sure where the folder was and didn't care, and something about the gems folder being sacred and shouldn't be edited.

I've spent all yesterday, some of last night, and this morning debugging CanCan to learn more about why it works the way it does. It has been very enlightening. Just gotta remember to pull my logger messages out and any changes when I'm done. ~~Would a bundle install reset changed gems' files and nuke my changes?~~ Nope, but a gem install -gem_name- will.

KoRMaK fucked around with this message at 15:28 on Apr 18, 2014

# ? Apr 18, 2014 15:24

Slow News Day: Jul 4, 2007

atastypie posted:

We went through the exact same thing with Mercury editor. We gave up on it and switched to CK Editor using inline mode, and it has been great. Transition wasn't very difficult. We added an internal policy against using gems/libraries with less than 10 contributors on github because we've been burned a few times by solo projects like Mercury editor.

I'll give that a shot, thanks.

Pardot posted:

Are you running locally with `bundle exec rails s` ? If not your local could be pulling in dependencies outside of your gemfile, which the slug compiler wouldn't know to include.

I'm doing 'rails s', yeah.

I think I'm going to try putting jquery-1.7.js directly into the asset/javascripts folder and see if it works that way.

# ? Apr 18, 2014 16:44

Slow News Day: Jul 4, 2007

EDIT: I figured it out. Under initializers/ckeditor.rb, the bottom-most commented-out line allows customizing the ckeditor asset path. Changing that to http://s3.amazonaws.com/bucketname/ckeditor_assets" and restarting the server did the trick.

I ended up ripping out Mercury Editor from my project and replacing it with CKEditor as per atastypie's suggestion. The transition was indeed quite seamless, and I was pleasantly surprised by how "plug-and-play" it is.

I'm having only one minor issue with it now. When it stores file attachments on Amazon S3, it seems to be including the root path of my application. So the file paths look like this:

pre:

http://s3.amazonaws.com/bucketname/Users/myusername/LocalProjects/RailsProjects/appname/public/ckeditor...

The part after bucketname is how I have the files organized on my Macbook. I cannot for the life of me figure out how to make it "bucketname/ckeditor_assets/public" instead. I went to picture.rb and saw this:

code:

has_attached_file :data,
		  :url => "ckeditor_assets/public/attachments/:id/:style.:basename.:extension",
		  :path => "rails_root/ckeditor_assets/public/attachments/:id/:style.:basename.:extension"

However, removing rails_root from the path did not change the file upload path. It simply changed where the server is looking when uploaded images are being browsed (their thumbnails now won't show, naturally).

Am I missing something obvious?

Slow News Day fucked around with this message at 02:12 on Apr 19, 2014

# ? Apr 19, 2014 02:07

waffle enthusiast: Nov 16, 2007

Is there a good writeup anywhere on abstracting out APIs into a model/class? I've run into this twice in various projects (one rails, one stock ruby).

In my beer app, I'm trying to abstract out the brewery db client for the purposes of future-proofing against whatever API I use. Say, for example, I want to later supplant or agument BreweryDB's functionality with something else. I've got a skeleton class like so:

code:

 class BreweryDbClient < BreweryDB::Client
    def initialize
      super do |config|
        config.api_key = ENV['BREWERY_DB_API_KEY']
      end
    end
  end

And�that's it. Is this acceptable? Should I just poo poo up my controllers with references to BreweryDB::Client?

In another generic ruby app, I'm basically running into the same problem, but with the a generic REST API (Stackdriver, FWIW). I'm abstracting out the Stackdriver API into a generic class, but I'm having difficulty deciding what API calls I should turn into methods, and how. In a perfect world, I'd be writing a ruby API client that I could open source later.

Is there any preferred reading material for writing API client classes, or just generally abstracting out APIs within an application?

waffle enthusiast fucked around with this message at 03:23 on Apr 19, 2014

# ? Apr 19, 2014 03:20

Sil: Jan 4, 2007

Dangerllama posted:

Is there a good writeup anywhere on abstracting out APIs into a model/class? I've run into this twice in various projects (one rails, one stock ruby).

In my beer app, I'm trying to abstract out the brewery db client for the purposes of future-proofing against whatever API I use. Say, for example, I want to later supplant or agument BreweryDB's functionality with something else. I've got a skeleton class like so:
code:
 class BreweryDbClient < BreweryDB::Client
    def initialize
      super do |config|
        config.api_key = ENV['BREWERY_DB_API_KEY']
      end
    end
  end
And�that's it. Is this acceptable? Should I just poo poo up my controllers with references to BreweryDB::Client?

In another generic ruby app, I'm basically running into the same problem, but with the a generic REST API (Stackdriver, FWIW). I'm abstracting out the Stackdriver API into a generic class, but I'm having difficulty deciding what API calls I should turn into methods, and how. In a perfect world, I'd be writing a ruby API client that I could open source later.

Is there any preferred reading material for writing API client classes, or just generally abstracting out APIs within an application?

The point of wrapping an external API is so you only have to make changes in one place if when they change their API. As such you want to turn EVERY API call into a method. Only make API calls inside your wrapper class, and then call the wrapper class anywhere else. This is the same principle whereby you don't make SQL queries in your controllers, do that poo poo in your model. Treat APIs like DB's and build an abstraction around them.

Replace every call to BreweryDB::Client with a call to BreweryDbClient. Then fill out the methods in your wrapper class so they return the same thing. Then refactor them so they make more sense(this step is optional).

This way if BreweryDB::Client starts returning beers in z-a instead of a-z order you have to make exactly one change in your code, in BreweryDbClient#all_alphabetical(or whatever).

# ? Apr 19, 2014 07:24

prom candy: Dec 16, 2005; Only I may dance

You may want to reconsider your naming scheme here. Having BreweryDbClient and BreweryDB::Client is kind of confusing on the surface. I usually call my wrappers WhateverItIsWrapper just to be clear.

# ? Apr 19, 2014 16:59

manero: Jan 30, 2006

prom candy posted:

You may want to reconsider your naming scheme here. Having BreweryDbClient and BreweryDB::Client is kind of confusing on the surface. I usually call my wrappers WhateverItIsWrapper just to be clear.

I'd personally name it BreweryService or something.. BreweryDBService?

# ? Apr 19, 2014 17:08

waffle enthusiast: Nov 16, 2007

prom candy posted:

You may want to reconsider your naming scheme here. Having BreweryDbClient and BreweryDB::Client is kind of confusing on the surface. I usually call my wrappers WhateverItIsWrapper just to be clear.

Yeah, I kind of struggled with that. Maybe just BreweryDbService or BreweryDbWrapper something. Other than that, I presume it's OK to just calling this wrapper service using BreweryDB::Client methods though? Otherwise, I'd have to do a lot of this:

code:

def some_brewery_db_client_method
  super
end

Or would it be more appropriate to totally encapsulate the BreweryDB::Client within the BreweryDbService? So instead of:

code:

# rename to brewerydbservice
class BreweryDbService < BreweryDB::Client
  def initialize
    super do |config|
      config.api_key = ENV['BREWERY_DB_API_KEY']
    end
  end
end

I could do something like:

code:

class BreweryDbService
  def client
    @client ||= BreweryDB::Client.new do |config|
      config.api_key = ENV['BREWERY_DB_API_KEY']
    end
  end

  def find_some_beer(beer_id)
    client.find_some_beer(beer_id)
  end

  def do_something_else(brewery_id)
    client.do_something_else(brewery_id)
  end

  # etc.
end

Seems like the benefit of the second way is that it totally abstracts the BreweryDB::Client from the rest of the application, but at the cost of having to do a lot more legwork to get the BreweryDbService up and usable. Any action in BreweryDbService I wanted to do, I'd first have to create a wrapper method for it. Whereas By making BreweryDbService a child of BreweryDB::Client, I can get around most of that.

Dammit this wasn't covered in POODR :smith:

# ? Apr 19, 2014 19:18

Jaded Burnout: Jul 10, 2004

Dangerllama posted:

Seems like the benefit of the second way is that it totally abstracts the BreweryDB::Client from the rest of the application, but at the cost of having to do a lot more legwork to get the BreweryDbService up and usable. Any action in BreweryDbService I wanted to do, I'd first have to create a wrapper method for it. Whereas By making BreweryDbService a child of BreweryDB::Client, I can get around most of that.

Dammit this wasn't covered in POODR

You can start with something like SimpleDelegator. The point of the wrapper is to make sure you're calling methods on an object you own, not necessarily that you wrote the content of those methods yourself or that they're named differently. This means that if the API itself changes, you can just create/change methods in your wrapper and keep your internal API the same.

You can frankly achieve the same thing by just having a singleton method or global constant somewhere that returns an instance of BreweryDB::Client if you're happy with the internal API it provides, and later on change your method or constant to contain something custom if the API shifts.

This is generally referred to as connascence of identity.

# ? Apr 19, 2014 21:32

waffle enthusiast: Nov 16, 2007

Cool. Thanks for this. Looks like I've got a little more reading up on the decorator pattern and delegation.

# ? Apr 20, 2014 01:12

Sil: Jan 4, 2007

Freelancey question: What counts as delivering a project to a client? I'm mainly uncertain about the hosting/support side of things. Install on their box with instructions on how to fix it if something goes wrong? Setup on some cloud provider their admin is responsible for? Heroku account that they pay for?

I imagine something like a PHP deploy where all their guy needs to know is how to connect to a server and copy paste some folders is not feasible. And possibly not how php works either? I haven't found a lot of information on this topic, partly because I'm not sure how to phrase my google searches.

At the moment I've worked with a few acquaintance/family type clients and just set their apps up on my Heroku account. That being said, these are clients that I'd be on the hook for support in perpetuity anyway, who just wanted simple CRUD apps. This is not a practice I see as viable in the future and am looking for resources to learn how to do deploys/product delivery properly.

# ? Apr 20, 2014 15:38

manero: Jan 30, 2006

Sil posted:

Freelancey question: What counts as delivering a project to a client? I'm mainly uncertain about the hosting/support side of things. Install on their box with instructions on how to fix it if something goes wrong? Setup on some cloud provider their admin is responsible for? Heroku account that they pay for?

I imagine something like a PHP deploy where all their guy needs to know is how to connect to a server and copy paste some folders is not feasible. And possibly not how php works either? I haven't found a lot of information on this topic, partly because I'm not sure how to phrase my google searches.

At the moment I've worked with a few acquaintance/family type clients and just set their apps up on my Heroku account. That being said, these are clients that I'd be on the hook for support in perpetuity anyway, who just wanted simple CRUD apps. This is not a practice I see as viable in the future and am looking for resources to learn how to do deploys/product delivery properly.

I'd say, if you can get away with Heroku, stick with it. There will be less to manage compared to a VPS, and it's trivial to give other developers permission to deploy or change ownership of the heroku account, compared to a whole VPS running with user accounts, etc.

It's entirely up to what you and the client want. If you want to have a support retainer that the client agrees to, and you can bill up to X hours per month for support/whatever, that works. Otherwise, if the client wants to find someone else to manage the system, it will be relatively easy for them to find a freelancer that knows git and heroku. I'd prefer to write docs about "here's how to commit code and push to heroku to deploy", than deal with a VPS or physical server.

# ? Apr 20, 2014 15:45

prom candy: Dec 16, 2005; Only I may dance

Sil posted:

Freelancey question: What counts as delivering a project to a client? I'm mainly uncertain about the hosting/support side of things. Install on their box with instructions on how to fix it if something goes wrong? Setup on some cloud provider their admin is responsible for? Heroku account that they pay for?

I imagine something like a PHP deploy where all their guy needs to know is how to connect to a server and copy paste some folders is not feasible. And possibly not how php works either? I haven't found a lot of information on this topic, partly because I'm not sure how to phrase my google searches.

At the moment I've worked with a few acquaintance/family type clients and just set their apps up on my Heroku account. That being said, these are clients that I'd be on the hook for support in perpetuity anyway, who just wanted simple CRUD apps. This is not a practice I see as viable in the future and am looking for resources to learn how to do deploys/product delivery properly.

I think deliverables are generally outlined at the beginning of a project. At my work we generally send the final bill when the site goes live because we own the servers, but we'll bill before a preview goes up if we're deploying to a server we don't own. Never deploy code to a server you don't own (or push it to a repo that your client has access to, or deliver it as a zip file) until you've been fully paid.

# ? Apr 20, 2014 16:07

Sil: Jan 4, 2007

manero posted:

I'd say, if you can get away with Heroku, stick with it. There will be less to manage compared to a VPS, and it's trivial to give other developers permission to deploy or change ownership of the heroku account, compared to a whole VPS running with user accounts, etc.

It's entirely up to what you and the client want. If you want to have a support retainer that the client agrees to, and you can bill up to X hours per month for support/whatever, that works. Otherwise, if the client wants to find someone else to manage the system, it will be relatively easy for them to find a freelancer that knows git and heroku. I'd prefer to write docs about "here's how to commit code and push to heroku to deploy", than deal with a VPS or physical server.

How would the Heroku setup work in respect to scaling dynos, paying for them and the like? Estimate some costs/traffic with the client and have them budget that out? Have them fully in charge of the hosting account, with me just having access to it for support purposes?

I definitely wouldn't want to handle a non-free Heroku app on my own accounts and have to dick around with a customer waiting for them to transfer payments every month. Hmm, though now that I write it up I guess it depends on the costs we're talking about and the type of client.

Are there any business focused web/software freelancing resources to read?

e. Yeah, don't give them the code without getting paid is a no-brainer. I'm stuck on whether to give them the code at all. The kinds of clients I've interacted with are pretty unsophisticated and don't necessarily have IT guys. It seems that I'd have to provide a type of build+support/hosting package to others like them.

# ? Apr 20, 2014 16:12

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

Sil posted:

Freelancey question: What counts as delivering a project to a client? I'm mainly uncertain about the hosting/support side of things. Install on their box with instructions on how to fix it if something goes wrong? Setup on some cloud provider their admin is responsible for? Heroku account that they pay for?

Whatever you can put in a contract that both you and the client are willing to sign. If you don't do this, might as well start looking for full-time jobs.

Sil posted:

Are there any business focused web/software freelancing resources to read?

A friend of mine has a few: http://brennandunn.com/products/

# ? Apr 20, 2014 16:23

hmm yes: Dec 2, 2000; College Slice

My experience is that it is generally not worth the bother to try and resell hosting. It's a lot of paperwork for a marginal amount of revenue and it needlessly ties the customer to you.

Have your customers create a Heroku account and have them add their billing details to it. Then you can share access to the application with them (App --> Access) and transfer ownership (App --> Settings). This means that billing goes directly to the customer. Don't launch the site until your customers have accepted ownership. Sounds like your customers should expect to pay $45/mo or so (Basic DB with 1 Dyno) but could get away with $9 (just the basic DB) if they're ok with the site being unresponsive for a minute after a dyno spins down. This is a totally reasonable cost for the benefits that Heroku provides and cheaper than the alternatives.

You need to have some type of support package as part of your original proposal, and if you didn't then you need to have a conversation with your customers right away about it. Either a monthly retainer (ex. 10 hours/month for a minimum number of months, this is for projects that will continuously have small features added) or pre-paid maintenance packages (ex. 10 hours that never expire, this is for break/fix on projects that are static in their features). Don't set yourself up to need to bill at end of month for 45 minutes of support/maintenance work, again it's paperwork that will bog you down just like the hosting, especially when you get past your first few clients. Writing emails/phone conversations/research/thinking about your customer's application all count as billable hours and your customers need to pay for that time.

Focus on what you're good at (making the internet do things) and simplify everything else around that (hosting, billing)!

hmm yes fucked around with this message at 16:47 on Apr 20, 2014

# ? Apr 20, 2014 16:35

kayakyakr: Feb 16, 2004; Kayak is true

In the two projects I've delivered, the client has set up a digital ocean account, given me access, and I set up the servers. Then I mark the project as delivered and bill them for it. Anything after that is at my hourly rate.

I'm not too worried about being dicked around because I am litigious...

I had a third that I was hosting on my own DO account and billing for monthly, but I've now joined that little project as full partner, so I'm currently not billing that one...

# ? Apr 20, 2014 16:47

manero: Jan 30, 2006

Sil posted:

How would the Heroku setup work in respect to scaling dynos, paying for them and the like? Estimate some costs/traffic with the client and have them budget that out? Have them fully in charge of the hosting account, with me just having access to it for support purposes?

I definitely wouldn't want to handle a non-free Heroku app on my own accounts and have to dick around with a customer waiting for them to transfer payments every month. Hmm, though now that I write it up I guess it depends on the costs we're talking about and the type of client.

Definitely get them their own heroku account and have them pay for the service. You could transfer ownership of the hosting to them, and do exactly as you said, have their account grant you access to do what you need.

Sil posted:

e. Yeah, don't give them the code without getting paid is a no-brainer. I'm stuck on whether to give them the code at all. The kinds of clients I've interacted with are pretty unsophisticated and don't necessarily have IT guys. It seems that I'd have to provide a type of build+support/hosting package to others like them.

If you can get away with keeping the repo on github/bitbucket or whatever private, just do that. Again, it gets down to what was in your contract, but I generally just assume that clients will want to own the code they paid me to write. I've had the "unsophisticated" clients who have never needed access to the code, and I would end up giving access to other freelancers/contractors that would come on to help.

Sil posted:

Are there any business focused web/software freelancing resources to read?

One thing that was hugely useful for me was the Ruby Freelancer's Podcast: http://www.freelancersshow.com/

^^^^^^ Brennan Dunn's stuff looks great, too

# ? Apr 20, 2014 16:49

kayakyakr: Feb 16, 2004; Kayak is true

manero posted:

I've had the "unsophisticated" clients who have never needed access to the code, and I would end up giving access to other freelancers/contractors that would come on to help.

This has happened with me. I keep their code on my private git repo. If they wanted it, I'd package it up or at least tell them how to access it, but they haven't asked yet.

# ? Apr 20, 2014 17:50

KoRMaK: Jul 31, 2012

I have a bunch of Model names that I stored downcased in my DB. So "MyClass" is stored as "myclass" I now need to go the inverse direction, and get the model name so I can constantize it, but I kind of screwed myself because I used downcase ("myclass") instead of underscore ("my_class"). Is there a way I can still find the Model MyClass from the string "myclass" and not "my_class"?

# ? Apr 20, 2014 18:44

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

How many is "a bunch", and how varied are they? It's not an intractable string processing problem, especially if you know "success" would be "a constant of this name already exists", because that'd be easy to write tests for, so with a database dump of the current values you could home in on a solution pretty quick. The worst case would be needing a full lookup table, but even that would only be temporary. The more important thing is to change your serialization to read downcase and snake-case but write only in snake-case.

# ? Apr 20, 2014 19:05

prom candy: Dec 16, 2005; Only I may dance

kayakyakr posted:

In the two projects I've delivered, the client has set up a digital ocean account, given me access, and I set up the servers. Then I mark the project as delivered and bill them for it. Anything after that is at my hourly rate.

This is a good way to do it. You can get an image set up on your own Digital Ocean account with all your preferred software packages and deploy scripts and the like and then transfer that image to your client's account. Image transferring isn't part of the Digital Ocean control panel but support will happily do it for you when you ask. Digital Ocean has the benefit of being like 1/8th the cost for your client vs. Heroku assuming smaller low-traffic sites. Heroku is easier to scale but Digital Ocean entry price is way cheaper. Heroku free tier will be unacceptable for most clients because of the slow spin-up times.

# ? Apr 20, 2014 19:22

Jaded Burnout: Jul 10, 2004

KoRMaK posted:

I have a bunch of Model names that I stored downcased in my DB. So "MyClass" is stored as "myclass" I now need to go the inverse direction, and get the model name so I can constantize it, but I kind of screwed myself because I used downcase ("myclass") instead of underscore ("my_class"). Is there a way I can still find the Model MyClass from the string "myclass" and not "my_class"?

Just iterate through the model filenames on the filesystem and find matches in the DB, then correct the DB entries to be something more useful. Or do them by hand, surely there's not that many?

# ? Apr 20, 2014 20:47

EAT THE EGGS RICOLA: May 29, 2008

I would probably just fix this like hand unless you have a good reason not to

# ? Apr 20, 2014 20:52

KoRMaK: Jul 31, 2012

Arachnamus posted:

Just iterate through the model filenames on the filesystem and find matches in the DB, then correct the DB entries to be something more useful. Or do them by hand, surely there's not that many?

There's like 20 model names, each with guides that use them and then an arbitrary amount that rely on that. Upgrading the db stored downcased values would probably be a bad idea, regression testing would involve the whole app.

Creating a map would be good though. Since they are all ActiveRecord descendants I could do this ActiveRecord::Base.descendants or loop through the file system as suggested.

# ? Apr 20, 2014 23:06

Smol: Jun 1, 2011; Stat rosa pristina nomine, nomina nuda tenemus.

KoRMaK posted:

I have a bunch of Model names that I stored downcased in my DB. So "MyClass" is stored as "myclass" I now need to go the inverse direction, and get the model name so I can constantize it, but I kind of screwed myself because I used downcase ("myclass") instead of underscore ("my_class"). Is there a way I can still find the Model MyClass from the string "myclass" and not "my_class"?

Search for matching constants with Module.constants.

# ? Apr 21, 2014 00:34

KoRMaK: Jul 31, 2012

Smol posted:

Search for matching constants with Module.constants.

This method didn't work at first while I was working in console, then I did this

Ruby code:

Rails.application.eager_load!
ActiveRecord::Base.descendants.each{ |k| puts k }

And thought "maybe I should try smol's suggestion again" and it spit out all the constnats I was looking for. It's the eager_load! that needs to happen. The AR::Base way narrows down results and still contains what I need. Thanks err' body!

# ? Apr 21, 2014 01:28

Smol: Jun 1, 2011; Stat rosa pristina nomine, nomina nuda tenemus.

Oh yeah, I totally forgot about all the autoload crap rails does.

# ? Apr 21, 2014 03:16

KoRMaK: Jul 31, 2012

So the purpose of this was to dynamically reflect a fields requiredness to the user on forms. Our app also allows users to select any field to be required, but hadn't integrated a way to reflect the model level requirements (validates presence stuff).

Now we can reflect both to the user! Lame, but exciting. Rails is fun.

# ? Apr 21, 2014 06:11

Slow News Day: Jul 4, 2007

Newbie question...

So I have a site where user accounts can be created in two ways: by new users (sign up) and by admin users. Since the creation is handled differently in each case, I decided to split the logic into two separate functions. I have a working implementation but I'm pretty new to Rails so I don't know if it is robust and secure. I am looking for feedback on how to improve it. (Keep in mind, I completed the Rails tutorial a month ago!)

code:

class UsersController < ApplicationController

    before_action :signed_in_user, only: [:home, :edit, :update, :destroy]
    before_action :correct_user, only: [:edit, :update]
    before_action :admin_user, only: [:create_by_admin, :destroy]

    .
    .
    .

    def new
        if !signed_in?
	        @user = User.new
	        @user.confirmation_code = User.new_confirmation_code
        elsif signed_in? && current_user.admin?
            @user = User.new
            render 'new_by_admin' # basically a new.html.erb but with an "admin?" dropdown
        else
            redirect_to root_url
        end
    end

    def create
    	if signed_in?
    		redirect_to root_url
    	elsif signed_in? && current_user.admin?
    		create_by_admin
    	else
    		create_by_user
    	end
    end
    
    def create_by_user
    	@user = User.new(user_params)
    	if @user.save
    		UserMailer.confirmation_email(@user).deliver
    		flash[:success] = "Great! Now check your email for activation instructions."
    		redirect_to root_url
    	else
    		render 'new'
    	end
    end
    
    def create_by_admin
    	@user = User.new(admin_params)
    	if @user.save
    		@user.update_attributes(confirmed: true)
    		flash[:success] = "User for " + @user.name + " created."
    		redirect_to users_path
    	else
    		render 'new_by_admin'
    	end
    end

    .
    .
    .

    private
        def user_params
            params.require(:user).permit(:name, :email, :password, :password_confirmation)
        end
    
        def admin_params
    	    params.require(:user).permit(:name, :email, :password, :password_confirmation, :admin)
        end
end

Essentially, all create requests are routed to the create action, and from there sent to the appropriate method (depending on whether the requesting user is a new user or an existing user who is an admin). The differences between the methods is that new users receive an email to activate their accounts upon signup and cannot set themselves as admin, whereas admin users create accounts that are already confirmed and can set them as admin.

Is this a silly way to do it? Should I create an admin_controller that handles all administrative requests?

# ? Apr 22, 2014 06:44

Jaded Burnout: Jul 10, 2004

enraged_camel posted:

Essentially, all create requests are routed to the create action, and from there sent to the appropriate method (depending on whether the requesting user is a new user or an existing user who is an admin). The differences between the methods is that new users receive an email to activate their accounts upon signup and cannot set themselves as admin, whereas admin users create accounts that are already confirmed and can set them as admin.

Is this a silly way to do it? Should I create an admin_controller that handles all administrative requests?

So long as you're using a decent authentication mechanism (e.g. devise, etc) you should be OK just having one form/controller/action for admins and users, provided your create/update method double checks that the user is actually an admin before trusting any "special parameters" sent from the form, and don't include them in the form if they're not an admin to avoid leaking info.

Admin controllers (or admin namespaces) are good things but probably overkill for this, though by all means do it if you'd prefer the extra peace of mind. Having a single controller with two routes through it is not so good.

Jaded Burnout fucked around with this message at 13:38 on Apr 22, 2014

# ? Apr 22, 2014 13:35

A MIRACLE: Sep 17, 2007; All right. It's Saturday night; I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape... Let's rock.

This was a fun day:

# ? Apr 23, 2014 01:44

kayakyakr: Feb 16, 2004; Kayak is true

A MIRACLE posted:

This was a fun day:

ooo, how'd things hold up?

# ? Apr 23, 2014 02:13

A MIRACLE: Sep 17, 2007; All right. It's Saturday night; I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape... Let's rock.

kayakyakr posted:

ooo, how'd things hold up?

Basically someone with 6 million followers tweeted about our app and we hit 4200RPM for a while, where our normal rate is around 200-300. We're still hanging around 2500RPM.

We had timeouts for a while but things are normal now. Spun up to 60 dynos x 6 processes / dyno haha. But we had our scaling set up incorrectly and got timeouts for a while. Everything's gravy now.

# ? Apr 23, 2014 03:01

kayakyakr: Feb 16, 2004; Kayak is true

A MIRACLE posted:

Basically someone with 6 million followers tweeted about our app and we hit 4200RPM for a while, where our normal rate is around 200-300. We're still hanging around 2500RPM.

We had timeouts for a while but things are normal now. Spun up to 60 dynos x 6 processes / dyno haha. But we had our scaling set up incorrectly and got timeouts for a while. Everything's gravy now.

woof, that's a lot of dynos. your stuff fairly server-side heavy?

# ? Apr 23, 2014 03:15

A MIRACLE: Sep 17, 2007; All right. It's Saturday night; I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape... Let's rock.

kayakyakr posted:

woof, that's a lot of dynos. your stuff fairly server-side heavy?

Yep, it's a mobile app but all the crunching happens on the server.

# ? Apr 23, 2014 03:19

Pardot: Jul 25, 2001

A MIRACLE posted:

Basically someone with 6 million followers tweeted about our app and we hit 4200RPM for a while, where our normal rate is around 200-300. We're still hanging around 2500RPM.

We had timeouts for a while but things are normal now. Spun up to 60 dynos x 6 processes / dyno haha. But we had our scaling set up incorrectly and got timeouts for a while. Everything's gravy now.

I thought that graph format looked familiar. Which db plan?

# ? Apr 23, 2014 07:52

Adbot: ADBOT LOVES YOU

# ? Jun 4, 2024 11:39

A MIRACLE: Sep 17, 2007; All right. It's Saturday night; I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape... Let's rock.

Pardot posted:

I thought that graph format looked familiar. Which db plan?

Read/Write Purple, Read-only White

# ? Apr 23, 2014 16:12

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ruby on Rails Love-In

«‹›178 »