Learning to navigate the terminal is definitely a part of learning to be a developer, so I wanted to share a few commands that have proven especially useful and important to me. Today’s post deals with
ls and mv. Note that each command can be passed “flags”, i.e. parameters.
To navigate directories: One
. indicates the current directory and
.. takes you one level higher. So
cd .. will navigate you one level up and
cd ./../.. or
cd ../.. will navigate you two levels up.
ls lists all files in the current directory, but results can be displayed in a ton of different ways using different flags.
ls -al displays results in a data table with relevant info (modification date, file name, etc.), and you can also decide how you want results sorted.
ls -t sorts results by most recently modified first, and
ls -tr sorts by most recent modified file last. You can append multiple flags:
ls -al -t returns results in a data table ordered by recently modified first.
mv is a clever move function that also accepts flags and can be used for a variety of other purposes, such as renaming directories.
mv is quite powerful, so it’s a good idea to use the flag
-i in order to ask you before deleting anything.
Let’s say I want to rename my book report from “draft.doc” to “final.doc”. I can use the
mv to move the contents of “draft.doc” into a new file automatically created called “final.doc”, automatically deleting the old file, using the following syntax:
mv draft.doc final.doc. If you specify a directory to move to, the file will move to that directory. If you specify a directory and filename to move it, the file will be moved and renamed to the new filename.
Adding a file upload feature to an app is fairly simple with the popular Carrierwave gem. And commercial file hosting is seamless as well with Amazon’s Simple Storage Service (S3), which plays very nicely with Carrierwave. I’ll cover S3 integration in a later post.
I’ve broken down the process into 3 easy steps:
1. Add a file upload field in your view and a column to your model
The first step is to implement a file upload field in a form on your app:
form_for .... do
= f.file_field :passport_picture
You need a column called “passport_picture” in your model, so generate a migration and add in that column.
We used a popular gem called Carrierwave to handle the file uploading, so let’s add it and its associated gems to the Gemfile:
gem "fog", "~> 1.3.1"
2. Make uploader classes for each file
Now we need to make an uploader class that contains uploading instructions. Our uploader will instruct Carrierwave to use the MiniMagick gem for image processing (optional):
class PassportPictureUploader < CarrierWave::Uploader::Base
process :resize_to_fill => [200, 200]
One caveat here: you need to make sure ImageMagick is installed on your computer, and this was not easy for me. You can install it using Homebrew or Rvm if you don’t have it, but google around for more specific instructions.
3. Mount the uploaders in your model
Now you need to tell your model to mount the uploader(s):
class User < ActiveRecord::Base
mount_uploader :passport_picture, PassportPictureUploader
And that’s it!
As an aside, I think this would be a good candidate to shuffle off to a background process so that the user doesn’t have to wait until the file uploads for the form to submit. I’ll talk about what I’ve learned about background processes in a later post.
Namespacing can be used to add a new actor to an application – an Admin, who has special access, for instance.
Let’s say we want to have a Users Controller that is accessible only by admins. To do this, we route requests to a Users Controller through the Admin namespace (generating a route of /admin/users/):
namespace :admin do
Rails generates a path of
/admin/users and a helper of admin_users, a path of
/admin/users/new and a helper of new_admin_user, etc.
And now we need a new Users controller that we place in the
Solution 1 – Regular Namespaced Controller
The simplest way to add in the new Admin actor is to create a new
users_controller.rb in that directory, have it inherit from the Application Controller like a regular controller, and include an appropriate before_filter defined in the ApplicationController that will ensure that a user accessing any actions from that controller is an admin:
class Admin::UsersController < ApplicationController
However, this is not the most efficient solution for larger apps where many controllers will be delegated to the Admin namespace – every controller would need to include the
before_filter :ensure_admin line, which is not very DRY.
Solution 2 – Inheriting from an AdminsController
A more efficient way to do it is by having each namespaced class inherit from a separate Admin class, which itself inherits from ApplicationController and includes the before_filter. That way every inheriting subclass will require admin authorization:
class Admin::UsersController < AdminsController
class AdminsController < ApplicationController
Namespacing can be used to add any actor with particular access – a merchant, customer, admin, guest, etc. And actors can inherit from each other in order to share privileges as well.
Now if you want to submit a model-backed form to a namespaced model, the syntax is similar to nested resources:
form_for [:admin, @user] do
Hot off the press! Aaron Sumner’s excellent book on Rspec for Rails has been updated for Rails 4 as of today, and includes up to date material on Capybara, Factorygirl and a number of other technologies. It can be downloaded as a pdf, mobi, or epub. Check it out here.
I’m now using Redis as the database component of Sidekiq, so I needed to install it on my mac. I found a great post explaining exactly where to put it on a mac, check it out – http://jasdeep.ca/2012/05/installing-redis-on-mac-os-x/.
Once you’ve configured Capybara, invoking selenium just requires that you set “js: true” explicitly after a feature / describe line (depending on whether you decide to use Capybara’s DSL or the regular Rspec syntax). Example:
feature 'User interacts with the queue', js: true do
self.use_transactional_fixtures = false after the feature/describe line (again, capybara dsl vs. rspec distinction) and before the scenario/it line.
If you want the firefox browser window to stop so that you can play with one of the pages, you can drop a <code>sleep [x seconds]</code> command anywhere in the test and the browser will wait for the specified time before continuing on its way (and then closing if it’s the end of the test).
I do most of my programming from cafes and until today I’ve faced a major annoyance – a lot of public wifis are configured to block ssh access. Unfortunately this is how I connect with Github, so I haven’t able to push any code changes while working at the cafes.
Today I found a fix for this on StackOverflow, quoting this article from Github – all you need to do is configure your computer to use port 443 for GitHub access, which is the default HTTPS port and is usually not blocked. Essentially you’re making an SSH connection over the port generally used for HTTPS.
1. Test to see whether you can make SSH connections over the HTTPS port. In the terminal, run:
$ ssh -T -p 443 email@example.com
You should get the following response:
Hi username! You’ve successfully authenticated, but GitHub does not provide shell access.
2. Open ‘~/.ssh/config’ using your text editor (I use Sublime Text 2):
3. Paste in the following:
4. Test that it works:
$ ssh -T firstname.lastname@example.org
You should get the following response:
Hi username! You’ve successfully authenticated, but GitHub does not
provide shell access.
And that’s it. Now you should be able to work with Git in public places. What I am curious about is whether there are security issues when doing this, and how to make it work for heroku as well. I guess that’ll be for a future post.
If you’re looking for a great Git workflow for adding new features to your application, check out this great guide put together one of my fellow TeaLeaf students – it includes screenshots and explanations.
Got my Rapid Prototyping with Ruby on Rails certificate in the mail today! How exciting! Always feels good to have a piece of paper that recognizes all of the many hours you spend learning something.
Last week I bought the “Everyday Rails Testing with Rspec” book by Aaron Sumner for the third Ruby on Rails course by the TeaLeaf Academy (which, by the way, is a lot of fun!). I expected testing to be a bit of a chore, but it turns out that I’m actually enjoying it.
The course introduces testing very gradually, so that in each exercise you just focus on one or two tests. It’s basically breaking up a new skill into edible chunks so that you can really focus on each chunk and process it properly until you understand it. Testing presents kind of a fun brain challenge, figuring out exactly which cases you want to test for and how to most accurately test for these cases, and at the same time it gives you a better understanding of what’s going on in your own app.