Infectious Learning

Nobody likes captchas, spammers find them annoying and users find them obnoxious. But it’s an easy way to separate out the spammers from the users. There have long been many alternative solutions to the common captcha, and they all have their own issues.

One solution is to show the user an easy math problem: 2 + three =. While this is easier for the user, a quick Google search will give the spammer the answer.

Today I saw another alternative for captchas in Hasin’s blog post Time to put those FUCKING captchas to an end. His alternative captcha theory is to show you an easily identified object, a tree or statue, and have you say what it is. Spammer’s solution: run the image through Google’s photo search. The third example, where the picture asks “There are two ___” and then shows two squares and three triangles, did stump Google. But this image would not be difficult to parse and answer.

The current captcha system is painful, tedious, and can be comical at times, but it does knock off a majority of the spammers.

This week will focus on formatting the rails app to be more user friendly. If this is your first time to this site, please see the first post on making your owns rails blog. Before we start with this weeks topics I made some basic CSS and formatting changes that can be seen here. Currently the blog displays dates in RFC format and only shows the authors email. This week you’ll use Rails I8ln tools to build custom date formatting. We’ll also extend Devise, allowing users to login with a user name.

Custom Date Formatting

There are two main theories to Date Formatting. Building a time_format initializer or adding date formats to your locales file. Since date formats differ between regions it makes sense to place these formats in your locales file.

Open up config/locales/en.yml, app/view/posts/show.html.erb, and app/view/posts/index.html.erb and make these changes. In locales file, the format named “default” will be used if no format is specified. In the view file, those are L’s that have been added prior to the dates. L is a default rails helper method for localize and will apply the localization for that data in our case a timestamp. You can add as many differing formats as you’d like. You can call these by using the following code

<%= l Time.now, :format => :awesome %>

A cheat sheet of all ruby date formats can be found here. If you would like more information on locale files, Ruby on Rails has a good guide on it.

Usernames

Adding usernames is a breeze with Devise. The first step to is create a migration to add the column.
$rails g migration addUsernameToUser username:string
Open up the generated migration and make these changes then run the migration.
Since we plan to allow users to login using their username we’ve made it a unique key, the database will not allow more than 1 User to have the same username. Now that the column is created, modify the User model to allow editing and validation of username. We will also make sure that Devise is validating data in the forms. You can see the changes here, user.rb

Now that our model and database are set to handle usernames, we have to make sure our views can handle them. To do this we need to extend the default Devise views. Run the following commands and then edit the files as seen here.
$ rails generate devise:views
For more information about this as well as how to let user recover their passwords using username or email please see the Devise wiki.
Now that we can edit, login and register with usernames, lets display them on our page. Edit post show and post index templates as seen here.

Check in next week were we will add comments to the posts.

This will cover how to use Devise as your user authentication system. In previous posts I’ve used AuthLogic which is a good solution, I just find Devise simpler to use and implement. This will extend from my article Rails 3 Blog Tutorial. I’d highly suggest going through that tutorial, or you can run these commands.

git clone git@github.com:baileylo/blog.git
git checkout -b blogCreated 0ba92371c2998caf362827987a82050708e9cd25


First add devise to your gemfile, gem “Devise”. Then run the follow commands:

$ bundle install
$ rails generate devise:install

This will install the Devise gem and set up the Devise modules. You will be prompted for 3 steps:

Do step 1, step 2 and 3 should already be done. Once you have completed these steps run:

$ rails generate devise user

Open up your user model(app/models/users.rb). You will see a comment at the top listing possible devise modules. You can add and remove these as you wish. For this tutorial we’ll only use: database_authenticatable, registerable, recoverable, rememberable, trackable. Save the changes, and run:

$ rake db:migrate
Now if you run “rake routes” you will see a series of /users/ routes setup automatically by Devise. Open up your application template, app/views/layout/application.html.erb and add the following code:

diff

Restart your rails server, and then reload your page. You should see in the top right Login and Register links. Feel free to create an account and play around with Devise’s built in authentication and user validation.

Now we need to associate a specific author with a specific post. To do this will use another migration:

$ rails generate migrate addUserIdToPosts user_id:integer
$ rake db:migrate


Rails migration generator will automatically read the migration name and realize that we’re adding the UserId column To the Posts table. Now we need to make the relationships between the models in ruby. Open up the user model(app/models/user.rb) and add “has_many :posts” within the class definition. Now open the posts model (app/models/post.rb) and add “belongs_to :user” within the class definition.
diff

So far now we’ve created user authentication system and added user to a post. Open your posts controller (app/controllers/posts_controller.rb) and add the following line at the top of your class, but inside the class definition
before_filter :authenticate_user!, nly => [:edit, :update, :destroy, :create, :new]
This will apply Devise’s built in function authenticate_user! When the actions edit, update, create, new, and destroy are called. It will effectively require the user to be logged in to access these actions.

Prior to a post being saved, we’re going to want to set the “poster” to be the user who is currently signed in. Devise provides the current_user helper which allows you access to the logged in user’s User object. Change the “create” action in the posts controller to look like this.

@post = Post.new(params[:post])
@post.user = current_user

diff

This will assign the currently logged in user as the user for the post. Lets clean up the views a little big. Change your posts index.html.erb and show.html.erb files to look like this, app/views/posts/.
diff

You may be getting error that reads: “undefined method `email’ for nil:NilClass“. These blogs were posted prior to having added the user migration. You can add an if statement to skip the user data when a Post doesn’t have a related User Object. But lets make a migration, run the following command
$ rails g migration insertUserInAllPosts

Open up the generated migration, and make the following changes . We named the migration “insertUserInAllPosts”, the name is up to you. It is nice to have descriptive names for migrations; in the future you will waste less time figuring out what the migration does if it has a good name.
diff

You may have noticed that we have removed the links to edit posts for other users, but they can still edit posts if they go directly to the url. To fix this we’ll use another “before_filter”. Open up the posts controller, app/controllers/post_controller.rb, and make the following changes:
diff

Now you have a full authorized blog. Come back next week to see user customizations.

This tutorial will cover the creation of a personal blog using Ruby on Rails 3. This tutorial assumes that you have Sqlite3, and Rails gem installed. There will be other applications used but their installation is explained as is needed.

The Blog:
First lets create our rails application and come up with some basic starting blocks for our blog.
$ rails new blog
$ cd blog
$ rails generate scaffold post title:string body:text
$ rake db:migrate
$ rails -s

The first two commands create the base rails framework. The next command is where you see a lot of the benefit of using ruby on rails. It automatically created the migration files, model files, controller files, and view files for our new database object called “Post”.
Migrations are how rails tracks schema changes in your database. You can migrate the database up to a latest migration or roll down to a previous migration. Rake db:migrate is the command to make the schema changes for the latest migration. Rails -s creates a simple webbrick server; this server is good for development, but not production.

You should now be able to goto localhost:3000 where you will be greeted by a friend rails page. Of course you probably don’t want your users to see this page so remove public/index.html.erb and add a new route, ‘root :to => “posts#show” to your configs.rb, seen here.

Once you reload your homepage you should see the friendly rails scaffolding. Feel free to create your first post!

Setting Up Authors on Your Blog

Title: I’m Posting every day in 2011!

I’ve decided I want to blog more. Rather than just thinking about doing it, I’m starting right now. I will be posting on this blog once a day / once a week for all of 2011.

I know it won’t be easy, but it might be fun, inspiring, awesome and wonderful. Therefore I’m promising to make use of The DailyPost, and the community of other bloggers with similiar goals, to help me along the way, including asking for help when I need it and encouraging others when I can.

If you already read my blog, I hope you’ll encourage me with comments and likes, and good will along the way.

Signed,

While reading a blog post the other day about the benefits of lazy loading, I took a look at one of my own code bases and thought about how it could benefit from lazy loading. A majority of tables in the database where had their own specific class file, some classes were group in the same file. Other classes were grouped in subfolders. All of these separate files were in one directory models, which was included on every page load. This ended up being some 150 different files and 10 megabytes of parsed code. This definitely seemed like an area for improvement.
Given the mangled naming structure using a naming schema was immediately ruled out of consideration. I next thought about creating a map, the downside to this was map maintenance. I hate having to do stuff in 3 places, add the table to the database, create the php file, and then add it to the map. I thought there must be an easier way to do this, and there was scripted model map generation.
Since my code base could was already completely able to load every model with out a problem there were three things left to do.

1. Load the code base and figure out which classes were default to php and which were my own.
2. Figure out what file each class was declared in
3. Store the data to a flat file for later reading.

1. Figuring Out Whose Class It Is:

To figure out which classes were mind and which were natively part of php is a rather simple task using the get_declared_classes() function I was able to determine which classes were native to php. After completely loading the code base, I ran the function again. The difference of the initial run and the second run is my defined classes.

2. Where Was It Declared:

To figure out where each class is declared you use PHP reflection.

Now ini_cofig_data is a hash of classname => absolute/path/to/class.php

3. How To Store It:

Incase you couldn’t guess I used an ini file. PHP has native ini parsing to array (parse_ini_file) so the read is extremely simple. The write ends up being rather simple as well.

Writing __autoload:

The autoload function is very straight forward, it takes 1 parameter the name of the class to load. We must look this up from are ini array and load it. The code could look like this:

There is a bit of hack to get model_object global, but you can add it as an attribute to your framework that is returned via a static call? Just don’t read the file every time

Now after I create a new model, I simply rerun the script and I’m good to go.

Ruby on Rails offers a couple different standardized date formats which can be really helpful. I’m personally a huge fan of :db, I hate looking it up all the time. But you may be wondering how to create a custom date format. Easy enough, open and create a new file(edit if you already have it) config/initializers/time_formats.rb.
In this file we’ll keep all of our custom date formats.
Add the following code:

Time::DATE_FORMATS[:slashy_format] = "%m/%d/%Y"
DATE::DATE_FORMATS[:slashy_format] = "%m/%d/%Y"
Restart your server and there you have it.
This format can accessed via
@something.date.to_formatted_s(:slasy_format)

There’s not really much else to it.

This is how to create a model relationship in Ruby on Rails where one model, message, has two foreign keys to another model, user. The sql tables are defined below, and is given the solution in Ruby and how to retrieve the values.


create table `user`(
    `id` INT(10) PRIMARY KEY,
    `name` VARCHAR(25)
);
create table `message` (
    `id` INT(10) PRIMARY KEY,
    `author_user_id` INT(10),
    `recipient_user_id` INT(10),
    `subject` VARCHAR(250)
);


To create the correct ORM relations use the following ruby code:

class Message < ActiveRecord::Base
    belongs_to :author, :class_name => "User", :foreign_key => "author_user_id"
    belongs_to :recipient, :class_name => "User", :foreign_key => "recipient_user_id"
end


With the above code you can access user data via

<%= @message.author.name %>

This tutorial will go over the basic steps to create a forums app. The forums will extend from my previous blog post about integrating Rails 3 with AuthLogic. If you are new to rails I’d high recommend reading it, otherwise continue. First download the source code from the AuthLogic App and move the code to more logically named directory for this project.


$ mkdir forums
$ git init
$ git clone git://github.com/baileylo/login_app.git forums
$ cd forums
$ rake db:migrate
$ rails -s


Feel free to verify that everything is working, you should be able to register and login at /users.

The Backend

Rails has reserved “thread” has a model name so this will create a weird model name but the other two model names are straight forward: Board, Conversation, Comment.

Board is a set of boards, groupings of conversations. Conversation, probably more commonly referred to as “Thread”, is list of Comments made by users. In our forum we’ll keep it simple, A Board will contain only a name and an id, a Conversation will belong to a board. A Conversation will have a title and a creating user. Comments will have only a body a posting user and a reference to the conversation they belong to.


$ rails g scaffold board id:integer title:string
$ rails g scaffold conversation id:integer title:string board_id:integer user_id:integer
$ rails g scaffold comment id:integer user_id:integer conversation_id:integer body:text


This created all the controllers, views, models, and migration files needed. Open up the three migration files created, and edit them to look as follows.

These changes add indexes to our Conversations and Comments tables. These will add a much needed performance boost when querying the database. They also added size limitations to board.title and conversation.title of 50 characters.

Now create the database tables by running:


$ rake db:migrate


Some Quick Backend Additions

Feel free to browse around the site, you’ll notice all the forms work correctly, but none of the objects are linked together. To tell active record that these models are linked we must edit the Model Classes.
Open up your newly created model classes and edit them to look like this:

In this we see two very important ideas. We’ve added form validation as well as ORM hooks that define relationships between our models. In board.rb and conversation.rb we added has_many :conversations and has_many :comments, respectively, this informs Rails these are 1 to many relationships. You can see the rails docs for has_many here. This makes the relationship from one conversation to many comments. In conversation.rb and comments.rb you can see the belongs_to function, this function tells rails that these objects belong to another specific object, you can see the docs for belongs_to here.
validates_presence_of is called when a save, update, or create are called on an object. This function makes sure that there is data stored in these member variables. We specified that conversation.title and comment.body must be required, we don’t want any empty posts. Board.title was purposefully skipped, it is not for general use.

If you navigate to your conversations page: http://localhost:3000/conversations and try to create a message, not including a title, you will get a nice error saying that it is a required field. You will how ever notice that you can make this field as long as you like even though we specified it should only be 50 characters long. Lets fix this, add the following line of code to your conversation.rb file:


validates_length_of :title, :maximum=>50


If you try again you will see an error message stating that the “the input must be less than 50 characters”.

If you’ve created any data, you may want to clean it up now, it may cause problems later in this demonstration.

Routes!

Now that we have the backend in order, lets create the routes needed to use this message board. Open up your config/routes.rb file and change it to look like this:

Delete your public/index.html file, it’s no longer needed.

Now localhost:3000/ will display a list of your Boards, instead of the rails information page.

In your console type:


$ rake routes


This is a list of every url that your app can handle, the most important are the top few. We’ve now created a url hierarchy. All of a conversations will be listed by /boards/:board_id/conversations/:id.

Jumping into the view

Our site looks okay, but lets try and spiff it up a bit. Open up your views/layouts/index.html and change it to look like:

Create a new file in public/stylesheets called style.css and copy this style sheet, http://gist.github.com/627780

.

At localhost:3000 you should be greeted by a much friendlier page:

If you haven’t created a board yet, feel free to create one now using the “Create Board” Link at the bottom of the page. You can put in you own ID if you want, if you leave it blank rails will auto increment the id.

Lets fix up that homepage a bit and make it look slightly more professional. Open up views/boards/index.html, and change it to look like this:

Now that our landing page looks decent, lets see what happens when we view our message board:

Not what anybody envisions a messageboard to be looking like, lets make some quick cosmetic changes before moving into the controller. Open up app/views/boards/show.html.erb and make it the following changes:

As you can see here we added a “Post New Message” link, the url function did not come out of thin air, if you run rake routes again. You’ll see there is a path named “new_board_conversation”, you can use any of those as a url by appending _url or _path to them.

If you click on the link to post new message you’ll get “No Routes Matches” error. We’ll fix that in a minute, but first lets make some adjustments to our conversation controller, open up app/controllers/conversation.rb and make the follow changes:

We added a private function that tries to load a Board off a passed in parameter. This function will be called on any page that goes through this controller.

Modify AuthLogic

If you have tried to login you may have noticed that we skipped a step. The login, logout, and register functions are not exactly tied to our application. To fix this we need to correct links in the views and redirect the controllers. While we’re doing this it will be a good time to remove functions that the app won’t be using. Open up app/controllers/users_controller.rb and edit it to look like so:

In this controller we added a function is_user. This function determines if the user is logged in and they are the correct user to be viewing specific pages. We also changed redirect urls to the site homepage and removed a lot of unused code. Now lets update our User View: We’ll have to change the links on all the pages as well as display less confidential information on the Profile page.

Now we just have to fix the Login view and the login/logout controller. These files need to have some cosmetic changes and fix issues with redirects open up app/views/user_sessions/new.html.erb and app/controllers/user_sessions_controller.rb and edit them to look like the following:

Now we just changed all the automatic form rerouting to point to our default homepage, added some basic styling, and changed the links in the site to point to more logical places. Lets create some content

Creating a New Post

There are four parts to our new posts: author, board, title, body. Author will be determined by the user_session, board will be determine through the URL, what our form needs to get from the user is title and body. We must modify the Conversation controller to create a Comment object which we can use in the view.
Open up app/controllers/conversation.rb and modify create and new functions to look like this:

The build function was automatically created when we used has_many :comments in the model, it creates an unsaved object using default values. In the create function we’ve added the board and author variable assignment, we also check to see if the user is logged in before we save.

if current_user && @conversation.save

We create @comment in both places for simplicity. Both of these function use the same view, create if there is an error and new by default, thus we need the same variables in scope. In the create function we pass in params[:comment] to build, this will build a Comment object with any data passed in the comment parameter.

Now lets setup our views, change app/views/conversations/index.html.erb, app/views/conversations/_form.html.erb to look like this:

The changes to new.html.erb are fairy straight forward. We added an id to the h1 tag, and changed the link to display the name of the current table and link to the current table. We modified_form.html.erb pretty heavily, we removed alot of the input fields that will be assigned in the controller. We also modified the error printing at the top to include any errors from @comment. fields_for works like form_for but does not create a new form tag. This allows us to create fields that are related to other objects.

Lets create our first post. When you’re done it should look something like this:

[img new_post.jpg]

Viewing Our Post

You may be wondering where your posts are? Clearly they’re in the database but they’re not showing up in our view. Lets fix that, open up app/views/boards/show.html.erb

We display all the conversations in that board along with some basic meta data. Most of this code is rather straight forward, the link to uses one of the routes that can be easily found using $ rake routes . We use the find function which was also provided when we used has_many. We subtract one for the number of replies so that we do not count the post it self. But all in all this view is as straight forward as they come.

Now lets work on the message view itself. Open up app/views/conversation/show.html.erb and edit to look like this:

Once again nothing to exciting happening here, the more astute of you may have realized we created a url function that we don’t currently have mapped. Lets create that route, add


get '/boards/:board_id/conversations/:id/reply' => "conversations#reply", :as => :reply_board_conversation
post '/boards/:board_id/conversations/:id/reply' => "conversations#save_reply", :as => :reply_board_conversation


This will create two different url matches, one for GET requests and one for POST, one when the page is called and one when the form is submitted.
Lets got and create the reply and save_reply functions in the conversation controller, they should look fairly similar to the new and create functions, or like these:

Once again here nothing is too revolutionary. reply handles the page load. It creates a @conversation and @comment for use in the view to generate forms. The @conversation is loaded from the url, as is a @board. @comment is empty. save_reply handles POST requests, so form submissions. It verifies that the user is logged in and that the parent conversation exists. It then creates the comment from the conversation, assigns the user, and assigns the values passed in from the form. It saves the data and redirects the user to the board overview with a friendly reminder.

Reply function uses reply.html.erb as it’s view, since that hasn’t been created yet lets do that now. Create another file as well _reply_form.html.erb. They should look like this:

There is nothing we haven’t seen before in these files by themselves. Reply.html.erb includes _reply_form.html.erb you can tell this by the render statement, ‘reply_form’ is prepended with ‘_’ so you know it’s not a controller view. _reply_form.html.erb uses the same action as we saw to generate the url to this page, and only has a text area input field.

Feel free to try it now out now. The complete forum/message board should be working. If you have any questions feel free to leave a comment or view the working code base on my GitHub For Rails boards

To run the rails webbrick server on a different por use the follow command:
rails s --port=3030
This will run the server on port 3030. To find a full list of options use the follow command
rails s --help