Jacob Montgomery

Ah sweet, glad that was it! Anytime! :)

Hey Neil,

Any reason you can't just do a if ?

if @runner.interests.squish.nil? 
  "#{@runner.first_name.capitalize} has no interests"
else
 "Your runner is called #{@runner.first_name.capitalize}. #{@runner.first_name.capitalize}’s first run to you will be on #{format_date(@pairing.first_visit_date)} at #{@pairing.usual_visit_time}. #{@runner.first_name.capitalize}   #{@runner.first_name.capitalize} likes #{@runner.interests.squish}"
end

What @Szilard said is correct - your controllers / views could care less how your models are structured. You just need to know how to query the model from the controller to grab the results you want. They're not that tightly knit.

So in this case, User.first.projects would list all the first users projects, Project.first.users would list all the users associated with the first project. You can call these from any view/controller.

As another thought - you might actually be up against the value, not placeholder - if my previous suggestion doesn't make a difference, you should be able to change the above to update the input value instead of placeholder... ie

$('#input_field_1').val("Text for tasks show view");

Again, this is very hacky and I wouldn't suggest it long term - but if you just need it to work for the time being, it should be alright.

Some great lists going so far! I'm probably pretty close to what @shakycode listens to on most occasions.

Pandora is my DJ - I have a few stations that I cycle through depending on my mood or what I'm working on. I tend to go through some weird phases, everything from old school gangster rap to Sleeping with sirens crab core haha.

I'm going to attempt to share the stations, but no clue if this will really work as expected:

Trifonic
Piano Guys
Caravan Palace
FC Kahuna
Squarepusher
Parov Stelar

Could you share how you tried to impliment it? In my minds eye, the implimentation would be rather hacky, but would work if you need a quick fix that you can later come back and improve as you have time.

something like this should work:

<%= content_for :footer_js do %>
  <script>
    <% if params[:controller] == 'projects' && params[:action] == 'show' %>
      $('#input_field_1').attr("placeholder", "Placeholder text for projects show view");
    <% elsif params[:controller] == 'tasks' && params[:action] == 'show' %>
      $('#input_field_1').attr("placeholder", "Placeholder text for tasks show view");
    <% end %>
  </script>    
<% end %>

You would then need to have a <%= yield :footer_js %> placed at the bottom of your main layout.

Oh, and you would need to place the content_for snippet above into the form partial that you call for your views.

I'd have to tinker with the code to see what I could come up with... but if you just want a quick fix, you could always use jquery to replace the placeholder based on whatever controller / action / view you want...

$('#your_text_field').attr("placeholder", "Whatever you want based on this controller / action / view");

If you rolled your own authentication then really you're just about the only one that could answer that since it depends on how you implimented it and store the user session.

The best I can surmise, the point of the snippet is that the typical current_user object provided by devise isn't available due to channels not being able to access the current session (see notes) - so in order to check the current_user, we have to go directly to the warden middleware and snag the user object.

The WebSocket server doesn't have access to the session, but it has access to the cookies. This can be used when you need to handle authentication.

You may be able to do something with this method using cookies: http://www.rubytutorial.io/actioncable-devise-authentication/

Check out:
https://github.com/hassox/warden/wiki/Overview

http://stackoverflow.com/questions/32401697/how-does-warden-get-the-current-user-from-the-rack-session

https://github.com/hassox/warden/blob/master/lib/warden/proxy.rb#L184

https://github.com/plataformatec/devise/blob/master/lib/devise/controllers/helpers.rb#L37

Sweet, I'm glad that really was the issue!

I've done that countless times, imagemagick gets me everytime!!

Unless I'm just reading it wrong, the error is just that, you don't have cmake installed...

ERROR: CMake is required to build Rugged.

sudo apt-get install cmake

http://stackoverflow.com/questions/27472234/an-error-occurred-while-installing-rugged

If you do have cmake, check the end of your error log, it says:

To see why this extension failed to compile, please check the mkmf.log which can be found here:
/var/app/ondeck/vendor/bundle/extensions/x86_64-linux/2.3.0-static/rugged-0.25.0b10/mkmf.log

So you can check the log there to see if it gives any additional details

Haha, making it harder is the easy part - making it easy is the hard part :)

Anytime!

Here you go - trick is to remember that even though it's nested, it can still be iterated over inside another iteration... it helps to use byebug, so when I got to the part of getting the year values to display, I just placed <% byebug %> right below <% item[:years].each do |year| %> so I could then see how the objects are being presented and adjust as necessary.

<table>
  <tr>
    <th>Month</th>
    <th>2017</th>
    <th>2018</th>
    <th>2019</th>
  </tr>
  <% @array.each do |item| %>
    <tr>
      <td><%= item[:month] %></td>
      <% item[:years].each do |year| %>
        <td><%= year[1] %></td>
      <% end %>
    </tr>
  <% end %>
</table>

Ah boo, markdown isn't parsing the table - either way I think you see what I mean... lol 1 moment let me re-work with the table method in mind.

Oh wait, are you needing them to be like this:

| Month | 2017 | 2018 | 2019 |
| --- | --- | --- | --- |
| January | 20 | 100 | 300 |
| February | 30 | 40 | 80 |

Hi Premila,

In your views controller, you'll want to do something like:

def index # or whatever method you're working with
  @array = [{:month=>"January", :years=>{2017=>20, 2018=>100, 2019=>300}}, {:month=>"February",
:years=>{2017=>30, 2018=>40, 2019=>80}}]
end

then in your view, you'll do something like:

<% @array.each do |item| %>
  <ul>
    <li><%= item[:month] %> <%= item[:years] %></li>
  </ul>
<% end %>

Just to provide an alternative solution - If you're still early in the development cycle and haven't gone to production yet, you could also create a contact model that stores all the address info, then you'd only have one model to manage validations:

#models/restraunt.rb
has_one :contact, as: :contactable, dependent: :destroy

#models/location.rb
has_one :contact, as: :contactable, dependent: :destroy

#models/contact.rb
belongs_to :contactable, polymorphic: true

then your migration could be something like:

class CreateContacts < ActiveRecord::Migration
  def change
    create_table :contacts do |t|
      t.string :line_1
      t.string :line_2
      t.string :city
      t.integer :state, :default => 0
      t.string :zip
      t.string :email
      t.string :phone
      t.decimal :lat, :precision => 10, :scale => 6, :default => 0
      t.decimal :lng, :precision => 10, :scale => 6, :default => 0
      t.references :contactable, polymorphic: true, index: true

      t.timestamps null: false
    end
  end
end

If you haven't seen it already, check out the reddit "hot" algorithm

https://gist.github.com/nanosplit/db42e507c5d1d984b664868db10a3669

There's also a thread I found on reddit that talks about it and helps explain what it's doing:

https://m.reddit.com/r/math/comments/vmxvf/how_is_this_algorithm_for_the_reddit_hot_ranking/?ref=search_posts

Check out the Geocoder gem => https://github.com/alexreisner/geocoder and http://stackoverflow.com/questions/34816490/get-remote-ip-address-in-rails-model

What you'll want to do is snag the IP in the controller with something like
@request_ip = request.ip then geocode @request_ip for the country.

You can really use just about any geocoding service that can do the ip address to physical address conversion.

@amalrik - the problem isn't that the bots are submitting a form, the problem is that they're hitting a no-longer publically accessible link every few seconds which is eating up bandwidth and system resources. The only way to stop this abuse of resources is to block the request before it even hits the webapp, so the incoming request has to be blocked further up (or down?) the stack (which is what stack-attack does) or somewhere at the network layer before it even hits the server (which is what CloudFlare does)

Ouch, that distributed of an attack is a different story all together!

If frequency of random connections is an issue like you're expericing here, you can also look into 3rd party services like CloudFlare: https://www.cloudflare.com/ddos/ which can help mitigate things before they even hit your network. I've used them in the past and been overall really pleased with their performance.

Very interesting fix with rack-attack you have there, I'm going to have to look into that one, thanks for posting your solution!