Chris Oliver

Definitely. You can use this a bit too early and it just is more painful than anything. The example of the navigation is bad because right now, I'd rather have the if statement, but in the future as it gets way more complex, null objects would make more sense.

There's certainly a balance to find when applying this (like any pattern).

Awesome! Glad that worked. The error came from trying to install a gem into system ruby. Some people will tell you to use "sudo" to fix it, but that's not fixing the real problem which was that it was using the wrong version of Ruby.

Good rule of thumb is that you should *never* use "sudo" when working with Ruby. It's always a sign you're doing something outside of rbenv and something's configured wrong.

Fingers crossed the rest of your setup goes well!

It sounds like you aren't using the proper version of Ruby and it's trying to install in your system Ruby. Make sure you didn't miss any commands and try restarting your terminal. When you run "which ruby" you should get something like "/Users/chris/.rbenv/shims/ruby".

Most of my projects are private and I put them on Github (paying for private repos) and you could easily store them privately on Bitbucket. In either case, your Capistrano URL will securely authenticate with Github or Bitbucket using your SSH key to check out the code. It logs in using that so you don't need to use a password to clone the code on a deploy.

Always the file named Gemfile in the root of your Rails application. It's the defining list of dependencies for each Rails app. You save it in each app so that all of them can use different versions without fighting each other.

Hey,

Forms normally send a POST request and since the user is saving data, you definitely want a POST.

You'll need two routes for this, one to show the form and one to save the data after the form is submitted. I would recommend changing your controller to Links plural so you can stay with the standard naming.

get 'links/minecraft' => "links#minecraft"
post "links" => "links#create"

Then you can make your controller:

class LinksController < ApplicationController
  def minecraft
    # This is empty so the view can render the form
  end

  def create
    if current_user.update(user_params)
      redirect_to action: :minecraft, notice: "Successfully saved your Minecraft ID"
    else
      redirect_to action: :minecraft, alert: "Please input a valid ID"
    end
  end

  private

    def user_params
      params.require(:user).permit(:minecraft_uuid)
    end
end

And your form would be a normal form_for current_user using the minecraft_uuid as the field to render out.

Since you've got some code to look up the Minecraft UUID, you can add that to the model as a validation to look up and verify it. Add an error to the record if it is invalid and that will cause the update call to return false.

I'd definitely just stick with one.

Ah yeah, you're right. I have always been careful about hashes when it comes to ordering because I wasn't sure it was a requirement for the ruby implementation.

Yep, you can call the "render" method like you normally would and send it as an attachment to email or upload it to S3

You can do a SQL ORDER on the created_cat column by adding liked_posts.order(created_at: :desc) or :asc if you want ascending.

I've used At.js in the past and it has worked quite well. http://ichord.github.io/At.js/

Ah yes, that's one of those odd gotchas because it accepts two hashes where as most of these methods accept only one. It's a tag with a whole lot of options, so it kind of makes sense, but seems a bit overly complicated.

Wow so it was as simple as the missing newline character?!

Haha! Actually OSX comes with an older version of Ruby. We use that to install Homebrew so we can make installing a ruby version manager easily.

Hey Wesley,

So you said that this is a form for a new Site? A site has_many models, not many sites. Should your form be for association :sites instead?

Sounds like you didn't insTall Postgres yet. Doing that should fix yOur problem.

Woah, that sounds scary. I've never seen that before. Is it deleting records or something else?

For nested queries like that, I think you can use benefits.id as the field. This might be of some help: http://www.elastic.co/guide/en/elasticsearch/reference/1.4/mapping-nested-type.html

I think I'm following you. The before_create seems like the right place to do this for now. If you're doing this before the record is created, you'll need to reference the in-memory objects through the association.

You might have a simpler time by moving this into the ItemDetail rather than the DetailAction. You'll need some way to match the two DetailActions together based upon the part (like "electric water heater") and then you'll need to separate those two items by the action ("replace" or "maintenance")

Once you have those two DetailActions together, you can first start with the replacement sequence, generate it, and then generate the maintenance one minus the replacement schedule.

If you've got the fields for the part and the action, then you can group these based upon the part field with Ruby's group method. Then you'll just go through each group, find the replacement DetailAction, calculate the replacement sequence first, save it, and then do the same thing for the maintenance.

Does that help at all?

Since you're going to need to do different views (it seems) for the forms on each plot, you may need to create a generic controller and view that can dynamically render the form based upon which report is selected.

If you choose "scatter_plot" in the form, then the next page could render a scatter_plot.html.erb view. And you could also use this param to call a report class.

After submitting, probably having some plain ruby classes that do the logic of taking the data and producing the graph. Setting up a common API on a set of "Report" ruby classes could help a lot here. They could all have an initialize method that accepts the data from the form and parses it as necessary. You can add a render method to each class and then use that for rendering out to the view.

If you have a variable with the name of the graph, you can do graph_name.constantize to grab the Ruby constant for the class. It would help you take something like "scatter_plot" and convert it to ScatterPlot and your code can create a new instance of that class dynamically, pass in the data, and render it out. Obviously, since your reports are all going to be somewhat different, you'll need to create a good amount of these classes, but you can start extracting their shared features to a Report class they could inherit from.