Everybody has suffered through the tedious process of account registration and email confirmation. You want to join a cool new site your friend told you about. But before you can do anything you have to click a stupid link in what otherwise is the worlds most useless email. The entire process hinges on an email that’s only value is a link that reads “Click me”.
Confirmation emails have one goal: make sure the recipient clicks the “verify your email address” link. These emails do not provide the recipient with any useful information about the site or places they should visit. This is by design – its imperative that the user clicks the verify your account link; but there’s a better solution. For years sites have employed tracking pixels, a 1×1 pixel image, to record information, such as open rates, to the servers. This same technology could be used for email verification.
The email would contain tracking pixel, but instead of tracking information the email would verify the recipients email address. Text-only email recipients would still require an authentication link. And it would not be a bad idea to include the old boring “Verify Account” link for email clients that don’t load images by default. Either way, the verification email could be redesigned for user engagement rather than the singular goal of verify an email.
Using the tracking pixel to handle email authentication will change the way new users are first introduced to the site. Where users were once greeted with a “verify account” link, they can now see trending articles, essential new features, or other essential site information.
Today my friend emailed me a link to an article on TheVerge. Unfortunately my friend had been browsing on his smart phone and linked the mobile specific URL. When I opened the article on my iMac I was greeted with a 450×300 pixel image stretched to over 400% its natural width. For a less painful user experience TheVerge should redirect users using non mobile devices to the standard site.
If you’re looking for an easy to use server-side browser detection library I highly recommend Jon Ursenbach’s MobileESP fork.
I played tennis in college. This meant that there was between a two and a half to three hour long block each day that I spent at tennis practice. The week before finals was always a dead week, the sports teams were not allowed to hold practice. I’d come home from my 2 o’clock class, the one before my practice, and sit around for 3 hours wondering what normal people do with this 3 hour period.
For the better part of the last three and a half years of my life I’ve spent anywhere between 3 to 4 hours a day commuting to and from work. The earliest I get home is 8pm. Today, to celebrate 4th of July, we were allowed to leave earlier from work. As I talked to my wife at 7:30pm, after having mowed the lawn and done other chores, I caught myself wondering again. What do normal people do with all this time after work?
I’ve tried several times to learn RoR. I can get around Ruby in a haphazard manner. I’ve even written a few small RoR sites. But there was so much happening behind the scenes, under the hood, that I never felt happy with my knowledge and understanding of what was going on. Today while listening to @funkatron‘s EngineYard podcast, he mentioned that there was a ruby/erlang dev on their team. The dev found the code base much easier to parse and understand after switching from a full stack framework to Slim Framework .
People often post on user boards – “I want to learn php which framework should I use?”. If you’re going about learning a language by using a framework written in that language – stay away from full stack frameworks. You’ll have a much enjoyable time using a simpler more “declarative” framework.
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.
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.
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:
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 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.
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
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.
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!
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.