Rader on Rails

Dispatches from my web development journey.

Verbal Math in Ruby

Came across an interesting code challenge on Code Wars a while back. It involved defining methods in a way to be able to type mathematical operations verbally, i.e. one plus one which would return 2.

I pondered over this for a while, and on a flight back from San Francisco came up with a neat solution and even learned a couple interesting things about metaprogramming.

I started with defining one. I know that I’ll want to potentially pass an argument to one. If I don’t have an argument, I’ll just want to return the integer 1. Simple enough. I can just give my method definition argument a default value of nil, check whether I have an operator, and if I don’t, simply return the integer 1:

1
2
3
4
5
6
7
def one(operator_method = nil)
  if operator_method
    # as yet undefined code
  else
    1
  end
end

Ok, so what should happen when I get an operator? I decided to find a way to implement plus.

A Shopping Cart for Your Web App

This was posted on the DevShop blog on July 25

If you’re looking to build an e-commerce web application, there is no shortage of tools you can use, from Spree to Shopify. However, it’s not too difficult to build your own – which is something we were tasked with over the past week.

In this post, I’ll cover creating a shopping cart that will keep track of products and their quantity and allow users to remove items.

Having read Agile Web Development with Rails 4, I decided to use that book’s shopping cart implementation. I’d encourage you to go through the book, especially if you’re new to Ruby on Rails, but I’ll give you an outline of everything required to make a robust shopping cart for your web application.

At least four models are necessary for an e-commerce site: Products, Carts, Orders and Ordered Items (which is a join table between products and orders and products and carts).

Dynamic Styles Made Easy in Rails

This was posted on the DevShop blog on July 7th.

While I definitely consider myself more of a backend developer, I’ve been lucky that my job pushes me to get more comfortable with front-end implementation. I learned a pretty neat and simple trick the other day for dynamic data visualization that I felt was worth sharing.

One of our projects, Daily Poll, sends users – you guessed it – a daily poll via text message. The questions, for now, are yes/no questions, and we were tasked with displaying the results on the homepage as a colorful bar chart.

We need the heights of each chart to be representative of the percentage of votes. How could one get this to be dynamic?

One way to accomplish this is with inline styling. Inline styling is generally frowned upon, but it makes this really easy.

_question.html.haml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
.yes-section-container
  .yes-people-box
    .yes-people{ :style => "height: #{100 - poll.yes_percent }%;"}
      %h2 YES!
      = image_tag("cheering_blue.png")
  .yes-graph
    .yes-box{:style => "height: #{box_height(poll.yes_count, poll.vote_count)}px;"}
      %span= number_to_percentage(poll.yes_percent, precision: 0)

.no-section-container
  .no-people-box
    .no-people{ :style => "height: #{100 - poll.no_percent }%;"}
      %h2 NO!
      = image_tag("cheering_red.png")
  .no-graph
    .no-box{:style => "height: #{box_height(poll.no_count, poll.vote_count)}px;"}
      %span= number_to_percentage(poll.no_percent, precision: 0)

You’ll notice inside the inline styling for the yes and no boxes, we call a helper method box_height, which handles generating the heights we need. We pass poll.yes_count or poll.no_count (methods we’ve defined in the Poll model) along with the total number of votes (poll.vote_count).

Skinny Out Your Controllers With Inherited Resources

After building Rails apps for some time, you eventually find yourself writing a lot of the same RESTful controller code over and over again. Some resources just require simple CRUD operations that follow similar patterns across apps. I’ve found myself copying and pasting code for CRUD operations from previous apps into new ones, making minor adjustments, so that I could get things up and running quickly. Thankfully though, there’s a better way: the inherited resources gem.

Inherited resources handles the common CRUD actions you’ve written a hundred times, and it’s quite easy to customize to your needs.

To get started, just add the inherited resources gem to your gemfile and run bundle install.

Now let’s say we’ve got a Reddit-like forum application that has users, and users can make posts and comment on posts. Using inherited resources, you can set up your posts controller like this:

1
2
3
4
5
6
7
8
class PostsController < InheritedResources::Base

  private

    def post_params
      params.require(:post).permit(:title, :content)
    end
end

That’s it. Provided you declared resources :posts in your routes file, the seven RESTful controller actions (index, new, create, show, edit, update and delete) are defined behind the scenes by inheriting from InheritedResources::Base. Pretty nifty – a controller that would normally be at least 80 lines of code is reduced to just six!

My First App Deploy to DigitalOcean (Be Aware of Secrets.yml)

I’ve developed a lot of respect for dev ops over the last couple days. In my beginning developer days, I was, of course, introduced to Heroku, as their platform makes it incredibly easy to deploy your app online. While Heroku is great, if you’ve got an application that sees a lot of traffic and requires a few worker dynos, you’ll be surprised at how quickly the price jumps from free to less affordable.

At DevShop, we use DigitalOcean, a more developer-friendly and less expensive choice for deploying your web app.

Deploying to DigitalOcean is a little more involved than what I’m used to. While the process gets quicker the more you do it, there are about 40 unique steps involved.

I’ve been battling with an internal server error over the past couple days while trying to deploy my first app to Digital Ocean, and it turned out the bug was very simple fix that had to do with a new addition to Rails: the secrets.yml file.