DEV Community: Andrew Ackerman

Beginner's guide to the Devise gem.

Andrew Ackerman — Mon, 26 Aug 2019 21:18:31 +0000

Recently I've been working on a Rails app to track work-out progress.

As you read in the title, this post is about using the Devise Gem, and I'll be working through using it at it's simplest form, to create a resource that I wished I'd had when I first tried it out.

The Devise Gem is users for User Authentication, It creates sign-up and sign-in forms, it also can be used to create user accounts for privacy. (I'm sure it can do more things, but this is how I'm using it. )

So as with all other gems, you'll need to install in the usual way by adding to your Gemfile, gem 'Devise' Then run bundle install in your terminal. After you've done that, you'll need to run the generator. rails generate devise:install.
That command installs an initializer that will print a lot of instructions, the only one we need to focus on right now is adding a default URL for the Devise Mailer. You can use the suggested one for the sake of this application.

Next, we need to create our Devise model, you can name it anything, (e.g. User, Admin, Member or Staff) depending on your purpose. I'll be using "User", thus I'll run in my terminal, rails generate devise user, following that up with rails db:migrate.

The first action you should take is to ensure that your Rails routes are configured for Devise, which is done by adding the following to your config/routes.rb file,

devise_for :stages
root to: "stages#index"
# "stages" can be replaced by whatever you name your controller, it's just what I needed to name my controller.

This will create all the necessary routes for authentication of your application, and then lead to the main index page.

In order to make your parts of your application unavailable to people without an account, go into their controllers and before your methods begin, add the following helper,

before_action :authenticate_user!

Something to be aware of, is to make sure that your helper matches your Devise model (User, Admin, etc.)

The three most important helpers for Devise are as follows,

user_signed_in?
# I used this to show the user’s email address in the top Navigation bar, and depending on their status to show “Log In” or “Log Out” options.
user_session
# Used to create the Log In occurrence, which remains until I’m logged out, in which case it destroys that session.
current_user
#This is used here to display the User's email in the navigation bar.

<% if user_signed_in? %>
    <%= current_user.email %>
    <ul class="dropdown-menu" role="menu">
              <li><%= link_to 'Profile', edit_user_registration_path %></li>
              <li><%= link_to 'Log out', destroy_user_session_path, method: :delete %></li>
<% else %>
          <li><%= link_to 'Log In', new_user_session_path %></li>
          <li><%= link_to 'Sign Up', new_user_registration_path %></li>
<% end %>

The current_user helper is also used in my controllers, stopping the user from accessing and editing any other user's data.

def new
    @stage = current_user.stages.new
  end

  def create
    @stage = current_user.stages.new(allowed_params)
    if @stage.save
      redirect_to stages_path
    else
      render 'new'
    end
  end

  def edit
    @stage = current_user.stages.find(params[:id])
  end

  def update
    @stage = current_user.stages.find(params[:id])
    if @stage.update_attributes(allowed_params)
      redirect_to stages_path
    else
      render 'edit'
    end
  end

  def destroy
    @stage = current_user.stages.find(params[:id])
    @stage.destroy
    redirect_to stages_path
  end

As you can see, every method in my Stages controller has to be authenticated through the Devise Gem's current_user helper.

Another useful aspect of Devise is that running $ rails generate devise:views users will create all the necessary views for signing up, logging in, password changes and account changes. As an example, here's what Devise creates for a sign-up page,

<h2>Sign up</h2>

<%= form_for(resource, as: resource_name, url: registration_path(resource_name)) do |f| %>
  <%= render "devise/shared/error_messages", resource: resource %>

  <div class="field">
    <%= f.label :email %><br />
    <%= f.email_field :email, autofocus: true, autocomplete: "email" %>
  </div>

  <div class="field">
    <%= f.label :password %>
    <% if @minimum_password_length %>
    <em>(<%= @minimum_password_length %> characters minimum)</em>
    <% end %><br />
    <%= f.password_field :password, autocomplete: "new-password" %>
  </div>

  <div class="field">
    <%= f.label :password_confirmation %><br />
    <%= f.password_field :password_confirmation, autocomplete: "new-password" %>
  </div>

  <div class="actions">
    <%= f.submit "Sign up" %>
  </div>
<% end %>

<%= render "devise/shared/links" %>

As you can see, there's a lot of work already done for you, which means you only have to blend it into the style of whatever you're creating.

I believe that's all I'm going to cover in this post without running the risk of going against my opening statement of blogging about Devise in "it's simplest form". Hopefully this helps someone else understand this incredible useful gem!

If you have any suggestions for other simple ways to use it that are beginner-friendly, please comment them down below!

Solving Issues in PostgreSQL. (Lessons in Debugging)

Andrew Ackerman — Thu, 22 Aug 2019 23:41:35 +0000

Last week I had the joy of spilling water on my computer, which turned it off rather quickly. Thankfully I was able to get it into an Apple Store and they dried it out and the biggest loss was the screen, meaning I have to have it eternally plugged into a monitor now, but it could have been far worse. Once I was back into work, I got ready to begin, opened my terminal, and tried running my Rails app, only to have this issue appear:

Started GET "/" for ::1 at 2019-08-21 09:15:43 -0700
could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
 excluded from capture: DSN not set

PG::ConnectionBad (could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
):

As PG is an abbreviation for Postgres, My first thought is that there’s an issue with how PostgreSQL (my database) is working, so after a quick trip to Stack Overflow to relearn Postgres commands I thought I’d try the ol’ “Have you tried turning it off and on again?” So I restarted PostgreSQL, like so,

$brew services restart postgresql
Stopping `postgresql`... (might take a while)
==> Successfully stopped `postgresql` (label: homebrew.mxcl.postgresql)
==> Successfully started `postgresql` (label: homebrew.mxcl.postgresql)

Unfortunately, this did not work, And I was greeted with the same error. I headed back to Stack Overflow and tried the first rwo pages of results, all to no avail. So I decided then to seek help from my employer, (@andrewculver ) and he reminded me of a previous PostgreSQL issue I had encountered, in which PostgreSQL creates a postmaster.pid file, which doesn't get dealt with when a computer experiences a hard shutdown, which in turn stops PostgreSQL from running again, because it believes it's already running. Thus the postmaster.pid file needs to be deleted in order for PostgreSQL to get up and running again, So we did the following,

Run brew info postgresql. You should see a reference to pg_ctl -D >/usr/local/var/postgres start. Don’t run that, You just want to confirm that the path is /usr/local/var/postgres. Actually do this:

Run cd /usr/local/var/postgres

Run ls You should see a postmaster.pid file.

Run rm ./postmaster.pid. You shouldn’t have any trouble deleting this file, but if you do, run sudo rm ./postmaster.pid.

Run brew services start postgresql.

While this may have helped the previous issue I'd had before, unfortunately, the same error message appeared, so it was time to do some deeper digging.

The Solution

Firstly we made our way into cd /usr/local/var/log/, once inside, we listed the contents like so.

$ ls
postgres.log    redis.log

Next wanted to check some of the recent log entries without displaying everything, so used tail to print out the last 10 lines.

$ tail ./postgres.log 
  Reason: image not found
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.63.dylib
  Referenced from: /usr/local/opt/postgresql/bin/postgres
  Reason: image not found
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.63.dylib
  Referenced from: /usr/local/opt/postgresql/bin/postgres
  Reason: image not found
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.63.dylib
  Referenced from: /usr/local/opt/postgresql/bin/postgres
  Reason: image not found

Finally we saw our issue! The postmaster.pid wasn't the issue, but instead a dynamic library for Unicode and globalization called icu4c, which was affecting our PostgreSQL processes. So, using Homebrew we uninstalled postgresql and reinstalled icu4c:

$ brew uninstall postgresql
Uninstalling /usr/local/Cellar/postgresql/11.2... (3,186 files, 35.4MB)
$ brew install icu4c
Updating Homebrew...

#I'm not going to past all the output because it goes on forever, but icu4c is reinstalled!

Finally, we installed PostgreSQL and restarted it's processes:

$ brew install postgresql
==> Installing dependencies for postgresql: openssl and readline
==> Installing postgresql dependency: openssl
==> Downloading https://homebrew.bintray.com/bottles/openssl-1.0.2s.mojave.bottle.tar.gz
==> Downloading from https://akamai.bintray.com/c4/c4a762d719c2be74ac686f1aafabb32f3c5d5ff3a98935c4925a1ddb9c750ee1?__gda__=exp=1566501434~hmac=b709fcc5ffd01de96a07acdb294be279
######################################################################## 100.0%

#Again, a lot more output then I'm going to post here, but it ends with these two options.

To have launchd start postgresql now and restart at login:
  brew services start postgresql
Or, if you don't want/need a background service you can just run:
  pg_ctl -D /usr/local/var/postgres start

The first option sounded like what we wanted, so we went with that.

So that's it! Andrew said that this has happened to him every few months for years, so we wanted to post something that would help anyone else who is seeing the same uninformative error message. Even if a mis-linked dynamic library isn't your specific issue, the contents of that logfile are likely to tell you what's wrong. If you need help debugging this issue, and the steps above didn't help, just post the output of your log file in the comments below! In fact, even if you understand the error message right away, please paste it in the comments anyway just so we can build a catalog of all the different reasons PostgreSQL isn't automatically restarting for different people. It might help someone else! Hopefully this helps someone else having the same issue! If you have any pointers or suggestions for other ways of solving the problem, I'd love to know!

Lessons on Rails Routing and MVC Layouts.

Andrew Ackerman — Thu, 02 May 2019 01:26:35 +0000

Since March this year, I've been in the process of learning Rails, I've been on Treehouse learning Ruby in my spare time for around 2 years so decided it was time to learn how Rails works and begin to understand it in all it's "magic", This is hopefully the first of a few blog posts to document my learning curve and give me (and others) a resource I can come back to later when I forget how things work.

A fundamental part of Rails is the MVC layout, this stands for Model, View and Controller which are the three main elements of Rails applications.

To begin, let's just create a simple app, I prefer using Postgres as I've had troubles with Gemfile dependencies for the default Sqlite3 (something else for me to learn to deal with later) so I'll specify that in my command into Terminal.

rails new demo --database=postgresql

This will create our app named "demo" in the current directory, the next thing to do is to shift into that application folder using Terminal. cd demo The general rule for order of creating a MVC layout is to follow the order of the letters, beginning with your model, moving onto your view(s) and finishing with your controller, but this isn't a hard and fast rule, just a common practice, for ease of this post, I'm going to break this rule and go MCV, but there are plenty of stackoverflow posts to show why it's more commonly done MVC. So let's begin by creating our Model

A Model defines what something is, and what abilities it has.

I'm going to create a simple food inventory, maybe for knowing how much food we have left in our cupboard.

rails generate model Food name:string size:integer

This will create the following migration file.

class CreateFoods < ActiveRecord::Migration[5.2]
  def change
    create_table :foods do |t|
      t.string :name
      t.string :size

      t.timestamps
    end
  end
end

This seems good to go for our simple application so run rake db:migrate in order to run the migration.

Now that we've created our Model, let's go ahead and generate our controller.

A Controller handles all the complex logic, rendering partials, saving things to the database and giving feedback to the user.

rails generate controller foods

Notice that the controller is labeled as a plural of the model, and there is no uppercase letters. If it is done the wrong way they may have trouble connecting to each other.

This will generate the following.

class FoodsController < ApplicationController
end

As you can see, it's not really doing anything, so we need to add some methods which we can use to modify and add to our application, like so...

class FoodsController < ApplicationController
  def index
  end

  def show
  end

  def new
  end

  def create
  end

  def edit
  end

  def update 
  end

  def destroy
  end

  private
   def allowed_params
       params.require(:food).permit(:name, :size)
   end

end

These are all the methods we would need for a typical application, and while they're empty now, we will come back and add to them in a little while. For the meantime, we need to link our Model to our Controller we do this by going into our /config/routes.rb file. and add the Rails helper method resources :foods to our list. This will create the routes necessary for our FoodsController. This could also be written long form, with each route specified.

  get "/foods", to: "foods#index"
  get "/foods/:id", to: "foods#show"
  get "/foods/new", to: "foods#new"
  post "/foods", to: "foods#create"  # usually a submitted form
  get "/foods/:id/edit", to: "foods#edit"
  put "/foods/:id", to: "foods#update" # usually a submitted form
  delete "/foods/:id", to: "foods#destroy"

This is a good time to explain Routing. Although generally you will only have resources :id there is a way to see your list of Routes. Go back to your terminal and enter rake routes. and you'll be able to see the above list.. I found it took a while for me to get used to reading the routes in that format, but it's really useful once you put some time in!

A URL in a browser sends a request to our router (config/routes.rb) which will analyze the URL and find and send to matching action in matching controller, which will try to match with the view.

Now that we've seen how the model and controller work, and now that the controller is searching for a view, let's create all the necessary views.

A View is a template, something shown to the user.. most often a HTML document.

In your editor find your "app/views/foods" folder and create the file "index.html.erb", follow suite with a "show", "edit" and "new".

To begin with, let's create our "new" view. First, we need to edit our FoodsController, adding to our new method.

def new
    @food = Food.new
  end

This creates a new instance of our food Model and assigns it to the @food instance variable. Now we head over to "new.html.erb" and create our page. We just want a simple form to add a food name and size to our database..

<%= form_for @food do |f| %>

  <%= f.label :name  %> <br>
  <%= f.text_field :name %> <br>

  <%= f.label :size %> <br>
  <%= f.text_field :size %> <br>

  <%= f.submit 'Save Food Item' %>
<% end %>

Now it's time to start your server, go to http://localhost:3000/foods/new and have a look. Your form will be there, and you'll be able to add to your database, but without other routes defined yet. You can't see, edit or delete that data and trying to save the information will throw a "Template is missing" error for "foods/create" so let's add that action.

  def create
    @food = Food.new(allowed_params)

    if @food.save
      redirect_to foods_path
    else
      render 'new'
    end
  end

So this method take the instance of the food model we entered into our form and attempt to save it, if it is successful we'll be redirected to our index method (via foods_path) or if not, it will direct us back to our New form.
Because you'll be sent to our Index page, it'll be helpful if we created one now. To begin, add to your index method.

  def index
    @foods = Food.all
  end

This take all the foods from the database and lists them on our Index views page, which we need to edit to all in to do that. Add the following to your view.

<% @foods.each do |food| %>
  <p>
    Name: <%= food.name %><br>
    Size: <%= food.size %> | <%= link_to 'Edit', edit_food_path(food) %>
  </p>
<% end %>

This loops through each of your database items and places then in a separate paragraph. It's a good idea to be trying these new functions as you go in your browser to see if you run into any problems. As you can see, I've also begun my edit function on the previous code sample for the sake of saving space. It's time to give functionality to that edit button in the Controller, incase we need to update our inventory as we use items.

  def edit
    @food = Food.find(params[:id])
  end

This gives the Edit function the ability to search through the database for the correct item to edit, identified by the (params[:id])

For your view, just copy and paste from your "new.html.erb" into your "edit.html.erb" This will provide the form to Edit (with profiled fields) but if you try it out, you'll find it won't save the updated values, showing us our error is that theres no Template for our FoodsController's Update function, so it's now time to add that.

  def update
    @food = Food.find(params[:id])
    if @food.update_attributes(allowed_params)
      redirect_to foods_path
    else
      render 'new'
    end
  end

This works in a similar way to our Edit and Create Functions combined. Finding the item, updating it's attributes, and depending on whether or not it can be saved, redirects us to where we need to be.

Two routes that are useful to have on our index page are Adding an item, and deleting an item. Editing your index.html.erb file like so will adding these links.

<%= link_to 'Add Food', new_food_path %>

<% @foods.each do |food| %>
  <p>
    Name: <%= food.name %><br>
    Size: <%= food.size %> | <%= link_to 'Edit', edit_food_path(food) %> |
    <%= link_to 'Delete Item', food, method: :delete %>
  </p>
<% end %>

The Add Food link will work automatically, but your Destroy method in your FoodsController will need to be edited. It should read..

  def destroy
    @food = Food.find(params[:id])
    @food.destroy
    redirect_to foods_path
  end

After adding this, go ahead and delete one of your records, and see that it deletes it and immediately redirects us back to our foods_path which is our index page.

The final method we need to add is our Show method. We'll us this to allow us to look at each item individually. Where our name attribute is shown in index.html.erb, edit it the following way.

    Name: <%= link_to food.name, food_path(food) %><br>

This will lead up to our show method (as you can see if you use your rake routes command in terminal again) Now we need to give it a view to display in "show.html.erb"

<h1><%= @food.name %></h1>

This will display the name of a variable as a header, which has yet to be defined. All we need to do is edit our Controller's Show function to search for our item and assign it to the variable our view is wanting to display.

  def show
    @food = Food.find(params[:id])
  end

Once this is done. we have all of our Routes accounted for and now we have this basic setup, it's just a case of duplicating it's ideas for more complex tasks.

I hope this was as helpful for you as it was for me writing it! I would appreciate any feedback, corrections and questions as I'm excited to keep learning and learning to teach these concepts.

Learning about Unix File Permissions

Andrew Ackerman — Mon, 01 Apr 2019 22:13:38 +0000

I've recently been tasked with testing out a small program which my employer wrote up. To be really brief about it, it is a piece of code that allows me to type in my terminal t 'sample text' and it'll save it to an intake file which I can find and manipulate in my Text Editor. It's basically a way of taking notes without having to leave Terminal, keeping me focused on whatever the task at hand happens to be.

This was going well for a short while until somehow I deleted the bin. file from my dropbox, where it's currently storing all the information. After restoring the file, as soon as I attempted to use the program again, Terminal would spit out the following:

-bash: /Users/ackerman/Dropbox/Thoughts/bin/t: Permission denied

Having never encountered this before, I began looking in all the wrong places.. I thought something was wrong with my directory, then that maybe something was wrong with the Ruby code it's written in or else I had somehow broken my dropbox.. All of my theories were soon proven wrong, but unfortunately, I didn't really know how to figure the solution out. So after trying for some time, I decided to swallow my pride and ask my employer. Thankfully he was more than willing to help me out, so I'm hoping I can pass on his knowledge to help others who may encounter this!

Every file in Unix has three different permission options:

1. Owner Permissions: This determines the actions that the Owner can perform on the file.

2. Group Permissions: This determines the actions that a member of the group who owns the file, can perform.

3. Other (world) Permissions: This shows the actions that any other user can perform on the file.

So the best way to get a handle on what we need to change is to see the what the file we're working with's permissions are set to.

Once in the directory with the correct file. run the ls -la command if the file you need to modify is hidden, or simply the or ls -l command, if it's not. This will output something similar to this:

drwxr-xr-x 4 ackerman staff 128 Feb 19 11:32 mydir -rw-r--r-- 1 ackerman staff 157 Feb 19 15:22 myfile

First thing to notice is that the first character is either a d or an - which denotes whether the file is d a Directory or - a file.The next 3 characters designate owner permissions, the three after that show the group permissions and the final three in that segment show the permission for the world/other.

Reading them is quite simple.

r: Indicates the user can read the file.

w: Indicates the user can write to the file.

x: Indicates whether the user can execute the file.

The rest of the information in the line isn't super pertinent to what I'm covering here. But for a greater understanding there are plenty of resources available if you need.

But how do I change the permissions?

In order to change permissions, you'll have use the chmod (change mode) command, followed by whichever category you wish to change access for.

a: All Users
u: The Owner user
g: The Owner Group
o: Others (Neither U, or G)

This is coupled with one or more of three different operators.

+ Adds the designated permission to a file or directory.
- Removes the permission.
= Sets the permissions.

And followed by the permission action we covered before. (r, w or x). Here are some examples of this.

chmod a+r myfile files are readable by all
chmod a-r myfile files cancels the ability for all to read the file
chmod a-rwx myfile cancels all access for all
chmod g+rw myfile files give the group read and write permission
chmod u+rwx myfile files give the owner all permissions
chmod og+rw myfile files give the world and the group read and write permission

This is all well and good for changing file_ permissions, but what about __directories? These need to be changed with a numbering system, and using it this way is called the absolute form. Each number is indicative of whom is getting permission to do what.

400 Read by owner
200 Write by owner
100 Execute by owner
040 Read by group
020 Write by group
010 Execute by group
004 Read by others
002 Write by others
001 Execute by others

In order to use them, simply add them and place them after your chmod command and the file/directory name. This isn't just for directories, and can simply be used for editing individual files. You also don't have to worry about learning all these numbers, as you can use a Permissions Calculator

In example, here's what it took to fix my problem. All I wanted to do was to make it so that the Owner could Read (400), Write (200) and Execute (100) the file, So I ran chmod 700 ./t. When I used the ls -la command after this. You can see the file has been changed to allow me as the Owner full permission to do all I needed to the file.

-rwx------@ 1 ackerman staff 63 Mar 29 09:46 t

I hope this has been of some help to anyone looking for a basic understanding of Unix Permissions. Feel free to let me know if you have any questions!