Mat Harvard

Steve Jobs

2011-10-05T23:16:39-07:00

“Stay hungry. Stay foolish.”

Waves updated to Rails 3.1.0

2011-09-12T00:48:55-07:00

I’m sorry to the followers the repository had. I made a mistake, which ultimately the easiest solution for me was to just clean the repository and start fresh.

I spent some time today updating Waves to Rails 3.1.0. There are some deprecation warnings related to the Joint gem, but those should be fixed upon it’s next update.

The repository is available at the same URL as before.

github.com/matharvard/Waves

Ruby on Rails 3.1.0 Released

2011-08-30T21:37:32-07:00

Rails 3.1.0 is out! Check out the release notes and get hacking!

I’ve just finished upgrading this blog from RC 6 to the stable version. The asset pipeline took a little tinkering to get working, since I named my CSS files my self as opposed to using Rails’ convention of application. Otherwise it was a painless upgrade.

Contact form in Rails 3

2011-08-22T18:39:41-07:00

This is an updated version of a tutorial I originally wrote in 2008 on building a contact form with Ruby on Rails.

The goal of this tutorial is to build a form that when submitted will validate and email the data.

Prerequisites

To simplify this, I’m just using Google Apps to manage email addresses. If you have your own email server just modify the settings as needed. To get started you’ll need:

A Google Apps account, of course
Ruby on Rails 3.1.3 (gem install rails)

Configuring Rails for GMail

In an existing or new application, open config/application.rb. Insert the following snippet in the Application class.

config.action_mailer.smtp_settings = {
  :address              => "smtp.gmail.com",
  :port                 => 587,
  :domain               => "yourdomain.dev",
  :user_name            => "from@yourdomain.dev",
  :password             => "Super-Secure-Password",
  :authentication       => :plain,
  :enable_starttls_auto => true
}

config.action_mailer.default_url_options = {
  :host => "yourdomain.dev"
}

Set the value of :domain to the domain you’re using for Google Apps, and :user_name and :password to your Google Apps account credentials. In the second block replace :host with the domain where the application is reachable from. The :host option is used to ensure that all links in email templates generate full URLs.

The Message Model

To allow validation of the message, I create a model and just include ActiveModel’s validations. Allowing the model to be written just like any other Rails model.

Create the file app/models/message.rb, or with a name of your choice. Make the file look similar to the following.

class Message

  include ActiveModel::Validations
  include ActiveModel::Conversion
  extend ActiveModel::Naming

  attr_accessor :name, :email, :subject, :body

  validates :name, :email, :subject, :body, :presence => true
  validates :email, :format => { :with => %r{.+@.+\..+} }, :allow_blank => true
  
  def initialize(attributes = {})
    attributes.each do |name, value|
      send("#{name}=", value)
    end
  end

  def persisted?
    false
  end

end

This is fairly self explanatory. A message can have a subject and body, as well as the name and email address of the sender. All of the fields are required, and the email address is verified with a regular expression.

The Mailer Model and Views

Run rails g mailer NotificationsMailer. This generates app/mailers/notifications_mailer.rb.

We'll want notifications_mailer.rb to look similar to this snippet. Check out the ActionMailer API for specifics on what’s happening here.

class NotificationsMailer < ActionMailer::Base

  default :from => "noreply@youdomain.dev"
  default :to => "you@youremail.dev"

  def new_message(message)
    @message = message
    mail(:subject => "[YourWebsite.tld] #{message.subject}")
  end

end

Replace :to, :from and :subject with the address you’d like the email sent to, the address it’s being sent from (should be the one you configured the Rails application with), and the subject of the email.

Create the file app/views/notifications_mailer/new_message.text.erb.How the message looks is entirely up to you. Here’s an example of how it could be laid out.

Name: <%= @message.name %>

Email: <%= @message.email %>

Subject: <%= @message.subject %>

Body: <%= @message.body %>

The Controller and View

Run rails g controller contact and then open app/controllers/contact_controller.rb.

The controller will only need two actions: new and create.

class ContactController < ApplicationController

  def new
    @message = Message.new
  end

  def create
    @message = Message.new(params[:message])
    
    if @message.valid?
      NotificationsMailer.new_message(@message).deliver
      redirect_to(root_path, :notice => "Message was successfully sent.")
    else
      flash.now.alert = "Please fill all fields."
      render :new
    end
  end

end

To get these actions working, open up config/routes.rb and insert the following two lines.

match 'contact' => 'contact#new', :as => 'contact', :via => :get
match 'contact' => 'contact#create', :as => 'contact', :via => :post

When a GET request is made to /contact, the new action is called. When a POST request is made to /contact, the create action is called.

Create app/views/contact/new.html.erb. As with the email template, this template is entirely up to you, I'm only providing an example of what it could look like.

<%= form_for @message, :url => contact_path do |form| %>
  <fieldset class="fields">
    <div class="field">
      <%= form.label :name %>
      <%= form.text_field :name %>
    </div>
    
    <div class="field">
      <%= form.label :email %>
      <%= form.text_field :email %>
    </div>
    <div class="field">
      <%= form.label :subject %>
      <%= form.text_field :subject %>
    </div>
    
    <div class="field">
      <%= form.label :body %>
      <%= form.text_area :body %>
    </div>
  </fieldset>
  
  <fieldset class="actions">
    <%= form.submit "Send" %>
  </fieldset>
<% end %>

Try it

Start your rails server and go to /contact. Fill out the form and hit send. If everything was done correctly an email should arrive in the inbox of the address specified.

git-push with specific SSH key

2011-08-11T11:49:12-07:00

I figured this was worth a post, as I’ve never ran into this problem before. I’ve been working on setting up a server, to which I connect using RSA. The standard name for an RSA key file is id_rsa(.pub). However, as I use my ‘standard’ key elsewhere, I wanted to use a specific key for this server.

Connecting via SSH to the server with the key is as simple as adding -i /path/to/key. The problem arose when I needed to be able to push to a Git repository hosted on the server, and adding -i to git-push doesn’t work.

The solution was to add a Host directive to my ~/.ssh/config file. Then, use that Host to connect to when push’ing to the remote server.

If it doesn’t exist, create the file ~/.ssh/config. Add the following to it, editing where necessary.

Host RemoteServer
  HostName remote-server.tld
  User git
  IdentityFile ~/.ssh/remoteserver_key

Remember to reload SSH after creating this file. This example config would be the equivalent of running a command like ssh git@remote-server.tld -i ~/.ssh/remoteserver_key. You can even run ssh RemoteServer to test the connection out.

In your Git repository, add a new remote repository. Here I’ve called it origin, as the convention might have it.

git remote add origin RemoteServer:path/to/repository.git

Instead of specifying a user @ a domain, it uses the name of the Host in the SSH config. The path/to/repository.git is relative, on the average system, that will probably point to /home/git/path/to/repository.git.

Try running a git push origin master to see if it works!

Interview with 45pixels

2011-08-09T15:14:55-07:00

My friend, Robby Klein, recently interviewed me for his website, 45pixels.

(link removed temporarily)

Now with a contact form

2011-08-04T22:14:46-07:00

I wrote up a little contact form for my contact page. Now it’s easy for anyone to get in touch with me. I’ll write up a tutorial on how it’s done soon.

Exception notification for Rails 3

2011-07-31T17:20:17-07:00

Using the popular ExceptionNotification plugin has changed slightly in Rails 3. One thing to note is that the official repository has moved from the Ruby on Rails GitHub organization to Sebastian Martinez’s account. Let’s get started.

Add the gem to an applications Gemfile.

gem 'exception_notification'

Then install the actual gem with either, gem install exception_notification, or by running bundle install from the application’s root.

Open the environment configuration file for which the application requires exceptions being reported from, typically this is config/environments/production.rb. Inside the application’s configure block, place the following code, editing where necessary.

# For a full list of configurable options, see the gem's GitHub home page.
config.middleware.use ExceptionNotifier,
  :email_prefix => "[Application Name] ",
  :sender_address => %{ "Application Name" <noreply@application-name.ca> },
  :exception_recipients => %w{ recipient.1@application-name.ca }

When the application is running on production, and assuming it’s set up with an email server, it will send the proper notification when an error occurs!

Now with comments

2011-07-27T08:18:08-07:00

I’ve just launched a commenting system on my website. For now it’s quite simple: As long as the post is under two weeks old, comments will be accepted on it. Only a name and a comment is required. The email address and website fields are just there for Akismet and a link back to your site respectively.

Text field placeholder in CoffeeScript using jQuery

2011-07-21T18:28:52-07:00

The HTML5 placeholder attribute is great. Styling it, however, isn’t as great (it is possible though). I implemented my own in JavaScript. Conventions encouraged me to use jQuery and CoffeeScript. I’ll show what it looks like in both jQuery and CoffeeScript for the curious.

The Form

<form action="/posts/search/" method="get" class="search">
  <input class="placeholder" name="q" type="text" value="Search" />
</form>

In jQuery

$(function(){
  $(".search input").focus(function() {
    if(this.value === "Search") {
      this.value = "";
      this.className = "textinput";
    }
  });
  
  $(".search input").blur(function(){
    if(this.value === "") {
      this.value = "Search";
      this.className = "placeholder";
    }
  });
});

The same code in CoffeeScript

jQuery ->
  $(".search input").focus ->
    if @value == "Search"
      @value = ""
      @className = "textinput"
    
  $(".search input").blur ->
    if @value == ""
      @value = "Search"
      @className = "placeholder"

My search form on the top–right is running this exact code. It’s very simple: when the field is selected and the value is “Search”, the field is cleared and a class of textinput is set (just changes the text colour); when the field is de–selected and its value is blank, the value is reset to the default, “Search”, and the class is changed to placeholder (again, just a colour change).

Resources

For the curious, RailsCasts has an episode outlining the basics of CoffeeScript. Also, of course, is the CoffeeScript website.

My nginx config

2011-07-21T11:34:48-07:00

This post will hopefully start off a series about the internals of my website, its ‘colophon’, as it were. A little background information will help: this site runs on a Linode 512, it uses MySQL for data storage, nginx as a web server and Phusion Passenger backed by Ruby Enterprise Edition for serving Rails. While there’s more in–depth reasoning behind choosing these particular pieces of software, that’s best left for another post; to summarize, it’s what I currently like.

Time for some code. I would like to point out that I am not an expert on nginx. My configuration script may not be the most efficient, in fact it may even horribly offend anyone more learnt in the ways of nginx. When I finish the commenting system please do flame this post.

server {
  server_name www.matharvard.ca matharvard.com www.matharvard.com;

  rewrite ^ $scheme://matharvard.ca$request_uri? permanent;
}

server {
  server_name matharvard.ca;

  access_log /var/www/matharvard.ca/log/access.log;
  error_log /var/www/matharvard.ca/log/error.log error;

  root /var/www/matharvard.ca/current/public;

  location / {
    rewrite ^/(.*)/$ /$1 break;
    try_files /system/maintenance.html /cache/$uri/index.html /cache/$uri.html $uri @passenger;
  }

  location /assets {
    try_files $uri @passenger
  }

  location /admin {
    try_files $uri @passenger;
  }

  location @passenger {
    passenger_enabled on;
  }
}

The first server block is to point all requests to my preferred domain, matharvard.ca, and strip the www sub–domain.

In the second server block, it sets up the access and error logs, and sets the root of the site to the public directory of my Rails app.

The first location block is meant for the public facing side of the website. The re–write rule inside it strips any trailing slash from the URL (for caching purposes). try_files is the new alternative to the old (and discouraged) method of a series of if statements checking for the existence of files. First, it looks to see if I’ve disabled the website by uploading the maintenance page. Second, it checks to see if the user is attempting to view the index page, if they are, it serves the cached version of the page. Third, it checks to see if the page the user requested exists in the cache (this is for all pages except the index). The fourth part is for static assets, such as images or CSS files, it tries to serve those directly. Lastly, if the requested file doesn’t exist in the cache or otherwise, it sends the request to my Rails app for processing. Which in turn will probably create the cached version of the page for the next user that requests it.

The second location block allows assets to be served, from the web server or my Rails app, even if the maintenance page is up, this is because…

The third location block, for the administration panel, is accessible even if the public site is disabled. There’s no need for caching, so if the request isn’t for an asset, it’s sent straight to Rails.

Improvements

Is something wrong with it? I did a lot of searching for the ‘proper’ way to configure nginx, but I don’t claim that my code is the best in any way. Feel free to share your experience in the comments.

Tumblelog on Rails and MongoDB

2011-07-20T13:16:26-07:00

I had an idea to turn my website into a tumblelog a while back. That idea ended up taking the shape of a GitHub project called, theorangeseed. It was built with Ruby on Rails and used MySQL to store posts. I used one model, Post, to store the different post types (something I still think as clever today). I learned a few things from it, but ultimately it ended up as wasted space on my hard-drive.

Time passed and technology progressed. MongoDB was becoming a hot topic. With the introduction of MongoMapper and Mongoid ORM’s for MongoDB it became an area of interest within the Rails community. Which is where I heard about it. I wrote a few applications to get a feel for both of the ORM’s. They were more or less the same, each with its own pros and cons but mainly application specific (what I’ve found anyway).

Over the last couple months I’ve put some time into re–creating theorangeseed, this time using MongoDB. At this time I don’t have any solid plan for the future of the project. I may at some point run a website with it, but for now it’s available on GitHub, here. I named it ‘Waves’ after a trip I took last summer to visit a friend in Virgina Beach, VA. We went to see a kite boarding competition in Waves, NC. It should be straightforward to get running. The only requirement involving more than a bundle install is having MongoDB installed.

Waves allows text, links, chats, code snippets, quotes, videos and images (through GridFS) to be posted. It has a basic authentication system thanks to Clearance by Thoughtbot (with modifications to support MongoDB/MongoMapper). It’s future is un–decided but I know it could use theme support and better administrative features.

Check out Waves on GitHub

Powered by Spotify

2011-07-19T20:55:34-07:00

It doesn’t take very long to write a ‘finished’ application with a framework such as Ruby on Rails or Django (Rails being my preference right now). So I decided to just start from scratch. After choosing from too many design mock–ups to count, I settled on this simple and clean layout. It has room to grow in the future, something that I aimed for from the beginning, in the case I add more features.

50% up front, the other half later

The site isn’t complete. I built only what I needed to launch. My work and contact pages are both incomplete. The search feature is minimal. There are no comments on posts. The administration interface is mostly a wireframe and leaves a lot to be desired. These are all things I can live with.

What matters the most is that I’m able to write. I figured out over the years that I’ll never be content with my personal website. There’s always something that I want to work on, improve, or that I just plain don’t like. Given time I’ll finish off the features that are missing. It will be an on–going project.

Looking ahead

Over the next week my goal is to finish off a couple more key features. I’d like to write about the building of my website as well. I may release the source code at some point, but it’s so simple that I’m sure someone could create something of the same complexity quite easily.

For now, if any questions are raised, I’ve provided a couple of ways to contact me here.

Powered by…

No, it’s not actually powered by Spotify, though I wish it was (I actually named the application SmallWaves). I have to mention how incredible Spotify is. I’m sure I’ll have more words to say about it at a later date. For now, just go check it out!