Last Wednesday, I spent all day setting up an ajax call for a portion of the project my Flatiron team is currently working on (check it out here!). It was a difficult process, piecing all the different elements together, but I did learn quite a bit. So today, I’m going to show you how to make an ajax call in a rails app using our example.

A quick summary of the problem: one feature of our project is a show page for all the different politicians currently in office in the US senate and house. We wanted to pull in recent New York Times articles to display on their show page, however because our app had to make multiple api requests to the NYTimes server (up to 50) and do some more filtering on our end after we received the data, each politician’s show page was taking an excruciatingly long time to load (up to 20 seconds). Rather than have the user wait that long before a page loads, we wanted the page to load immediately, then make an ajax call to fetch the articles, persist them to our database, then display them on the page.

Let’s back up for a bit, what exactly is ajax? It’s a tool that allows you to make requests to a web server without the need to refresh your page. It’s how things like infinite scrolling work. Once you reach a certain point in the page, an ajax call is triggered, it makes a request to get more data and load it on the page. You can see how this might come in handy.

Back to our problem, we have a method defined in our model called get_articles which made the api request and handled any post processing on our end, it was this method that took too long to run. Originally, we were calling it in the show action of our politician controller. Line 4 below:

1
2
3
4
5
6
7
8

def show
  @politician = Politician.find(params[:id])
  if @politician.nytimes_articles.empty?
    @articles = @politician.get_articles
  else
    @articles = @politician.nytimes_articles
  end
end

Now because this method took anywhere between 5 and 20 seconds to run, once you clicked the link to go to a show page, you would have to wait that long before the page loaded. Because no one wants to wait that long for a page to load, let’s look at what we had to do to set up the NYTimes ajax call.

First, let’s separate the api request from the show action, and make a separate action in the same controller called times_articles to move that code into, so now our controller looks like this:

1
2
3
4
5
6
7
8
9
10
11
12

def show
  @politician = Politician.find(params[:id])
end

def times_articles
  @politician = Politician.find(params[:politician_id])
  if @politician.nytimes_articles.empty?
    @articles = @politician.get_articles
  else
    @articles = @politician.nytimes_articles
  end
end

Then we need to add a nested route in our routes.rb file, one which will run the new action we just created:

1
2
3

resources :politicians, only: [:show] do
  get "/times_articles" => 'politicians#times_articles'
end

So for each polititian, this creates a route called times_articles: /politicians/:politician_id/times_articles. When the ajax call hits this route, it will run the times_articles controller action

Next we need some place to actually house the ajax call. So we create a .js file in app/assets/javascript, in our case, we called it politician.js to stick with our naming convention since that is what our model/controller/migration was called. If you haven’t required tree in your application.js file, then you’ll need to make sure to require the new file in there. This javascript code will load on every page, but if you look at the way it was set up (line 2 below), the code only executes on politician show pages.

1
2
3
4
5
6
7
8
9
10
11
12

$(document).on("page:change", function(){
   if($('body').is('#politicians.show')){
    var politician_id = $(".politician_id").attr('id')

    $.ajax({
      url: '/politicians/' + politician_id + '/times_articles',
      dataType: "script",
      type: "GET"
    });

    }
})

This code is making an ajax call to the url we’ve specified, which will hit our new controller action. You also have to specify the type of request, in this case a get request, and the type of data you are expecting back, here “script” is telling the ajax call to be expecting javascript back, after which it will execute the javascript. But before this code can sucessfully execute, there are are few more things we need to set up.

Since our ajax call is requesting javascript, we need to add a few lines of code into our times_articles action that will specify what to do when someone requests javascript.

1
2
3
4
5
6
7
8
9
10
11
12
13

def times_articles
  @politician = Politician.find(params[:politician_id])
  if @politician.nytimes_articles.empty?
    @articles = @politician.get_articles
  else
    @articles = @politician.nytimes_articles
  end

  respond_to do |format|
    format.html {render action: "show"}
    format.js
  end
end

Basically, the respond_to block is saying if someone requests javascript (in this case the “someone” is our ajax call), do the default action (because of rails magic, the default action is to look for a .js.erb file in the views directory with the same name as the action: times_articles.js.erb). If for some reason html is requested, for example if someone typed the times_article path into their browser, it would just load the show page.

So let’s create that file which our controller is looking for: times_articles.js.erb, our specific file contained the following code:

1
2
3
4
5

$('#articles img').hide();

<% @articles.each do |article| %>
$('#articles').append("<div id='indiv-article' class='col-xs-4'> <%= j link_to article.headline, article.url, class: @politician.party %> </div>");
<% end %>

What it is doing is hiding an img tag (in our case a loading animation) and adding links for each article to the DOM in the section that has an id of ‘articles’. This code is the “script” which the ajax call is expecting back, which it will then execute.

Let’s summarize, what we have set up does the following:

1. The javascript in politicians.js runs when we are on a politician show page and the ajax call is made.
2. The ajax call hits the times_articles url, making a get request for javascript, which then runs the respective controller action
3. The controller action runs the method to make the api requests to the NYTimes server, persists that data to the database, then looks for a file called times_articles.js.erb to return to the ajax call
4. The code in times_article.js.erb is returned to the ajax call and executed, hiding certain html elements and adding new ones into the DOM, reflecting in your browser without the page reloading.

Snazzy, eh?

Ahh, those days when you have a brilliant (or not so brilliant) idea and want to make a cool app. You set up Heroku so other people can use it, make some api requests to start gathering data, and eagerly start coding, right? …More like, you realize Facebook requires you to apply for permission if you want to use anything more than the barebones data they give you default access to (a process which they say can take up to 14 business days)…so that app you wanted to build overnight turns into a woeful blog post about what little you’ve been able to accomplish thus far, which is this, and only this: (UPDATE: I built the app with twitter!) http://your-vocabulary-sucks.herokuapp.com/

What I wanted to do was pull all of a user’s Facebook posts and tally up their most commonly used words to see not only how sophisticated their vocabulary is, but maybe how egotistical they are, how angry, and other such nonsense. Maybe chart that information using Chart.js or some other cool library. Now we’ll never know, at least until Facebook approves my application that is.

Okay, let’s get started with Heroku, shall we? First if you don’t already have an account, sign up here: https://dashboard.heroku.com/apps

Additionally, you need a web app in order to deploy to Heroku, so if you don’t have one, you can do a quick rails new and set up an index.html.erb page so there’s something to display. Keep in mind that Heroku uses postgres, but creating a new rails app by default gives you sqlite3 in your gemfile. Instead, you should install postgres on your computer and run

1

rails new [appname] --database=postgresql

that way you’re running the same database system in development and production. If you don’t have this set up correctly, you will get an error deploying to heroku or when you try to view your app locally, or both.

Also make sure your project is a git repository and you’ve been pushing all your changes to github (just to be safe), you’ll also be using git to push to Heroku. Once you have a Heroku account you need to install their toolbelt, after which you can login in your terminal by typing

1

heroku login

You’ll be prompted for your credentials which hopefully you remember. Then in order to create a Heroku app, you can run

1

heroku create [optional name]

If you don’t pass it a name, Heroku will automatically generally something silly like limitless-peak-5480, which is actually pretty snazzy if that’s what you’re into. If you accidentally forget to pass in a name, don’t worry! You can change the name using

1

heroku apps:rename [newname]

To deploy code, simply run

1

git push heroku master

and you’re golden. If the push works but your Heroku app isn’t working for some reason you can type

1

heroku logs

for a more detailed view of what exactly is happening to help you debug. That’s all I have today, hopefully I’ll get the right Facebook api permissions soon so I can actually do a more interesting post!

Today, we will cover two ways in which your website can be compromised as well as some precautions you can take to avoid them. I should add a disclaimer that these are pretty amateur mistakes (ones which a new programmer such as myself could easily make), but they are easily avoidable and hopefully this post will help you better understand how they work rather than just knowing how to prevent them.

First is sql injections. Most applications, especially if they involve users and passwords will be backed up by a database to store all that information. With malicious sql injections, people can completely destroy your tables or steal users’ passwords. It goes something like this.

1
2
3
4
5
6
7
8
9

def so_much_bunny
  sql = <<-SQL
    SELECT *
    FROM bunnies
    WHERE bunnies.name = "#{name}"
  SQL

  DB.execute(sql)
end

Now if your name variable were set to, lets say “Marvin”, that’s fine and dandy, you would get back a row matching the bunny Marvin. But a less than ethical programmer might set name = “ OR 1 – which would run sql code that looked something like this

1
2
3
4
5
6
7
8
9

def so_much_bunny
  sql = <<-SQL
    SELECT *
    FROM bunnies
    WHERE bunnies.name = "" OR 1 -- "
  SQL

  DB.execute(sql)
end

What happens is the “OR 1” returns true and everything else after is commented out due to the double dash. So you would get back all the records in the table bunnies because your where statement has essentially been changed to “WHERE true” instead of actually needing a bunny’s name and returning only the row where it finds a match. Not very secure, eh?

One solution to this problem is never using string interpolation. You can sanitize the data by using parameters and passing them in like so:

1
2
3
4
5
6
7
8
9

def so_much_bunny
  sql = <<-SQL
    SELECT *
    FROM bunnies
    WHERE bunnies.name = ?
  SQL

  DB.execute(sql, name)
end

This will escape any special characters, so if someone tried to pass in “ OR 1 –, the quote would get escaped and treated like a part of the string rather than a closing of the name query.

In rails, the correct form would look something like this

1

Bunny.where("name = ?", params[:name])

Moving on, our second point of discussion is mass assignment in rails. Mass assignment is extremely useful as it allows you to create a new instance of a class and populate all it’s fields by just passing in a hash. So instead of doing this:

1
2
3
4
5
6

@bunny = Bunny.new
@bunny.name = "Margaret"
@bunny.status = "Happy"
@bunny.weight = "Heavy"
@bunny.color = "Brown"
@bunny.age = 2

you can just pass in a hash called bunny_params that holds all the information

1

@bunny = Bunny.new(bunny_params)

Unfortunately, with mass assignment, it’s possible to have a user change an attribute you don’t want them to touch. Let’s say we had an attribute “free_bunnies” that was set to a default boolean of false, and we don’t want users to willy nilly have the ability to free all the bunnies. Using mass assignment with no limitations, they very well can.

For example, if you had a form to create bunnies, that contained fields for name, status, weight, etc, but not a field for free_bunnies since you don’t want the user changing it, it would look something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<%= form_for(@bunny) do |f| %>
  <div class="field">
      <%= f.label :name %><br>
      <%= f.text_field :name %>
    </div>
    <div class="field">
      <%= f.label :status %><br>
      <%= f.text_field :status %>
    </div>
    <div class="field">
      <%= f.label :weight %><br>
      <%= f.text_field :weight %>
    </div>
<% end %>

without any limitations, the user can change the form easily in their browser to pass free_bunnies to params instead of name and set the value to true and it would be passed through when creating a new bunny. So the original html would look like this

1

<input type="text" name="bunny[name]" id="bunny_name">

and the fanagled one would look like this

1

<input type="text" name="bunny[free_bunnies]" id="bunny_free_bunnies">

The solution here, or at least one solution, is something called strong parameters. Essentially, you have to whitelist the attributes you want to allow, otherwise they will get passed into the params hash but will be “kicked out” and not allowed when you create your new object and you’ll get an error saying “Unpermitted parameters: x, y, z”.

Back in Rails 3, you used to have to require a strong params gem, but now in the current version of Rails it’s built in. When you generate a scaffold (for bunnies in this case) with the associated fields, you will automatically get some lines that look like this

1
2
3
4

# Never trust parameters from the scary internet, only allow the white list through.
def bunny_params
  params.require(:bunny).permit(:name, :status, :weight, :color, :age)
end

By default all of the fields will be permitted, you will have to set what you will or won’t allow, and that’s that!

Now, I’m still no expert in the nefarious ways which people can use code, so enlighten me! What are the worst things you can think of to do if someone failed to account for malicious sql injections or accidentally whitelisted a param that they didn’t mean to?

Today, rather than an educational presentation, I wanted to have an open dialogue about abstraction when we write code. What is it? Why is it great? Is it ever bad?

First of all, what exactly is abstraction? I would define it as the removal of details so that whatever thing it is we’re abstracting moves farther and farther away from the literal representation of itself. Abstraction is wonderful for programmers because it allows us to create dynamic code that can be used and reused again without having to actually type out every line each time. The best way for me to describe it would be with some examples.

Let’s take this series of methods from a lab we did in class the other day:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

def build_artists_index
  FileUtils.mkdir_p(rendered_path + "/artists")

  template = File.read("./app/views/artists/index.html.erb")
  page = ERB.new(template).result(binding)
  File.write("#{rendered_path}/artists/index.html", page)
end

def build_genres_index
  FileUtils.mkdir_p(rendered_path + "/genres")

  template = File.read("./app/views/genres/index.html.erb")
  page = ERB.new(template).result(binding)
  File.write("#{rendered_path}/genres/index.html", page)
end

def build_songs_index
  FileUtils.mkdir_p(rendered_path + "/songs")

  template = File.read("./app/views/songs/index.html.erb")
  page = ERB.new(template).result(binding)
  File.write("#{rendered_path}/songs/index.html", page)
end

These are pretty much all the same method except for one part of the path so we can abstract it by creating another method which all of these methods can call, so we only have to type those four lines of code once. Like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

def gen_index(dir="")
  FileUtils.mkdir_p(rendered_path + dir)

  template = File.read("./app/views#{dir}/index.html.erb")
  page = ERB.new(template).result(binding)
  File.write("#{rendered_path}#{dir}/index.html", page)
end

def build_artists_index
  gen_index("/artists")
end

def build_genres_index
  gen_index("/genres")
end

def build_songs_index
  gen_index("/songs")
end

There are ways to abstract this further so we only have to call the method once instead of three times, but I don’t want to confuse you too much.

Another example which we (at the Flatiron School!) have been working with lately is ActiveRecord. It’s an extremely useful class which wraps up a whole bunch of methods for you (so you don’t have to write them yourself, you can simply reap their benefits by calling them) to make extracting, creating, and persisting data to a database very easy. It writes all your sql statements for you, so you can continue working blissfully with ruby.

I think it’s pretty clear how powerful abstraction can be. I helps us be more efficient, less redundant, and make beautiful code. However, something I have been pondering lately is this: is there ever a point in which we have abstracted something too much? I would say yes. Let’s look at those flowers up top. Now draw a line on a piece of paper. I’m telling you now that the line you just drew is an abstract flower. What do you think? That’s stupid isn’t it? Because it’s unrecognizable. It looks like nothing in particular, but it’s actually an abstract flower, you just can’t tell.

Now, over-abstracting code isn’t as simple as that, but if you wrote some super clever and abstract code, then look back at it a month later and have no clue how it’s actually working, I might consider it a little too abstract. That being said, I also think it depends on how experienced you and the people around you are. Take someone like me, at this point in my programming education, I need most things to be on the explicit side, but five years in, I’ll probably be writing two lines of Ruby in what takes me 50 lines to do now, but as long as I (and the people I work with) can still understand its functions, I say: abstract away.

Nine days into my programming education, I am realizing 1. I know jack shit and 2. I am certainly not as clever as I thought. So an approporiate first post would be on a topic which has been challenging me lately: Ruby classes. Let’s dive right in shall we?

When you strip Ruby down to its bare bones, I find that it consists simply of two things: objects and methods. Almost everything in ruby is an object (the number 1, the word “hello”) and methods are what you can do to those objects.

For example, you can tell ruby to reverse your name (your name being the object and reverse being the method). It would look something like this:

1
2

"Summer".reverse
=> "remmuS"

See? my name in reverse! Cool, huh? But you’re thinking, “Summer, I thought we were going to talk about classes? GIVE ME CLASSES.”

Alright, alright, no need to get all frothy-mouthed. I’m getting there.

Every object in ruby belongs to a specific class. You can check what class it is by simply calling “.class” on an object, like this:

1
2
3
4
5

"Summer".class
=> String

1.class
=> Fixnum

Man, ruby is so smart. It knows that my name in quotes is a string and the number 1 is a number, or an integer, to be more specific. So why is this important? Well, what class an object is determines what methods you can call on it. Take a look here:

1
2

1234.reverse
NoMethodError: undefined method `length' for 1234:Fixnum

1
2

"1234".reverse
=> "4321"

When you try to run reverse on an integer, ruby doesn’t know what you’re talking about. If you really wanted to get 4321, you could turn that integer into a string by adding quotes around it, then the reverse method would work. So quick recap: classes are essentially the framework behind which objects are built, and as such, they determine what methods you can use on an object. Strings have their own set of methods, integers have their own set, arrays have their own set, etc etc. Alright, take a deep breath, you with me? Just one more thing and we’re done.

You can make your own class and define the methods which the class can use. With these custom classes, you can do some pretty powerful stuff, what kind of stuff? We’ll leave that for another post. Here, I’ll provide a very simple example. Let’s make a cat class.

1
2
3
4
5
6
7
8
9
10
11

class Cat

  def initialize(name)
    @name = name
  end

  def meow
    puts "meow meow"
  end

end

To make an instance of this class (aka, an object), you do this:

1

newcat = Cat.new("Olivia")

Here we also pass this new cat object a name variable containing the name of the cat, Olivia. We can make Olivia meow by simply saying newcat.meow (which will print out “meow meow” to the screen) since we defined this meow method for the cat class.

1

newcat.meow

And that’s it for today folks. Back to the grind, and hopefully I’ll have much more to share with you soon.

“Hello, World”