Category Archives: Twitter Clone

So, after part 6 we have demonstrated that we can implement real time updates to users, without needing them to refresh their web page. We’re going to need to implement some controls on this, so that we aren’t firing updates out into the ether without anyone there to listen for them, but we will do that in a minute.

First, we’re going to need to use that message the browser receives to update the web page, rather than just firing an alert message with the details. There are a number of ways of doing this, but probably the best is to start using a specialist front end technology.

Handlebars.js gives us a templating system that we can use to simply update web pages by parsing JSON and updating HTML templates with the values. We can use the power of Rails’ asset packaging system to declare these templates in advance, in a ready-to-use precompiled format. This also means that when in production, our users will simply be downloading 1 JS file (“application.js”) which will have all of the functionality that they could need in it, which is ideal.

To make this application into a full client-side app, then we would ideally use a JS MVC framework such as Backbone.js or Spine.js, or even something more full-featured such as ExtJS or SproutCore. However that is a little beyond the scope of this tutorial, but we may revisit this later on.

Making it look nicer

So far it all looks really rather boring, so we’ll use a CSS framework to make things a little more interesting. Twitter have just released Bootstrap, an open source framework which is fantastic and simple to use, so we’ll use that code to improve the look of our application. If we incorporate this now, before we start writing the templates, we won’t have to re-do the job later on.

In application.css change the require lines to read as follows:

We have changed the require tree line to “require user” because we don’t want to include all of the scaffolding CSS that Rails generates for us. Create a new file “app/assets/stylesheets/users.css.scss” – and if you want to override any styles, put them in there. Then create a file called “app/assets/stylesheets/bootstrap.css” and copy the contents of this file into it.

We now need to copy the JS (needed to give us some great features with the framework) and then we can start building our templates. Copy all of the JS files from here into “app/assets/bootstrapjs” and then add the following two lines to “app/assets/javascripts/application.js” above the line saying “//= require_tree . “:

Finally, we need to update our application’s layout to use the features that Bootstrap gives us. This is going to be a major change of the file “app/views/layouts/application.html.erb”, so I have provided the code for you in this gist file here – simply copy and paste it into your application.html.erb file. Some of our formatting will have been broken with this, but we can deal with that later. Now we are going to edit “app/views/dashboard/index.html.erb” to reflect the change of layout:

Finally, update “app/views/posts/_post.html.erb” to be:

If we fire up the server now, we should see something like the following:

Which looks rather more professional, don’t you think? OK, lets start implementing Handlebars, so we can hook up the realtime functionality.

Handlebars and Mustaches

Handlebars is an extension of the Mustache templating language, which is hugely powerful, and very easy to use. If you have ever used the Liquid Templating Language in ruby, then the basic syntax is a little similar – you print out variables by enclosing them in curly-brackets – {{ variable }}.

To make our life easier, we are going to install a new gem “handlebars_assets”. We need to add this to our Gemfile, in the “group :assets do” section:

Now run “bundle” to add the gem, and we can start building our templates. We need to tell the asset packager where the template files are located, and that we will be using handlebars. Add the following lines to “app/assets/javascript/application.js”, above the line that says “//= require_tree .”:

Now we are ready to start building the templates. To do this, we will create a new folder in “app/assets” called “templates”, and then create our template files in there. Convention is that Handlebars files have a “.hbs” suffix, and because we want to compile them for speed, we also add “.jst”, so files are “filename.jst.hbs”. The location for each of the following files is in the comment at the top, so create the following:

Before we create any more, we’ll put this in action and show how it works. Open up “app/views/layouts/application.html.erb” again, and change this method:

To this:

Ok, let’s restart the server, and open up a console window – and like last time use the console to create a new post and see if it updates our web browser. So, with your browser open and displaying the app home page, type the following into a rails console (keep the app in sight) and see if it updates:

You should see that you’ve got the new post appearing at the top of your list. Perfect. In the next installment, we will improve the UI of the app a little more, and speed up the interface by incorporating more Handlebars to make things faster, as well as start building an API!

If you need the source code from this episode, check my Github – http://github.com/jgwmaxwell, this episode is in branch “part7”.

So, we have the barebones of our application up and running, but it wouldn’t be much good if you had to constantly refresh the page to see what people are talking about. When I create a post, I want anybody who I mention to know that I’ve mentioned them immediately, and if I am searching for a topic, then I want any new messages about that topic to be delivered to me immediately. We will set up the ability to do this in two stages – first we will look at mentions “@username” in a post, and then we will look at searches. Live feeding the @users. Detecting @user tags Delivering the message Improving the application Ok, so we need a system for detecting the tags in the posts as they are submitted. To do this, we are going to open up our Post model again, and make some changes. Read more…

Well, whilst writing the next installment of the tutorial, the very latest version of Ruby on Rails was announced, with a ton of awesome new features. I’ll try and introduce them to you through the rest of this tutorial, but as of now, we are moving the code to Rails 3.2. The easiest way to convert over and do this is going to be: Either: go to http://github.com/jgwmaxwell/chatter-tutorial download the code from the download tab unzip the directory and enter it with a terminal prompt “git checkout rails32” you’re ready to go Or clone the repo and check out the rails32 branch. I look forward to seeing you in the new, shiny, speedy world of Rails 3.2….

Planning Followers So far we have built an application which allows users to sign up and create posts, and given it a very useful facility to be able to pluck the tags out of those posts and process them outside of the main request process, which will help our application to scale nicely. Now it’s time to actually give it some significant functionality and create the “following” system so your users can choose whose updates they want to see. We want users to be able to follow anyone, but one user following another doesn’t mean that the second user will automatically follow the first back. In order to do this, we need our User model to have a relationship to itself, but because we need to control this relationship more than the one between Posts and Tags, we are going to use a slightly different system than ActiveRecord gives us. Read more…

Designing the Tags So far we have an application which allows us to create users, login, and create/destroy posts – which is really the core functionality of an application like this. The difference between the basic functionality and an application which can actually be used is in the details. Twitter allows you to denote that you are referring to a specific topic by using a “hashtag” – a #, followed by some alphanumeric characters. For example #bostonredsox or #1966. In order to do this, we need to store this data somewhere. This is where using a traditional schema-based DB causes us some problems, as we have to define our fields in advance – if we allow a post 1 tag, then this is not an issue – we can create a field for it in the database, but if we allow n number of tags, then we have a problem. Read more…

Planning the Post Model So, we have a working authentication system after Part 2, but that doesn’t really do very much – it’s time to flesh it out with some features. Since we are building a micro-blogging application, like Twitter, the primary part of the application are going to be the “chirps”, or posts that each user contributes. Let’s describe how a post will look: body – the post will need some text [type Text] user_id – the post will belong to the user that wrote it [type Integer] reply_to_id – the id of the post that this one is in reply to (if any) [type Integer] At its most basic, a post could exist with just those two features. Rails is kind enough to provide two additional features for us as well: created_at – the date + time that the post was created updated_at – the date + time Read more…

Back to Introduction So, now that we have a working Rails application, we can start to flesh it out with some of the functionality that we need. Like any microblogging idea, we need to have user accounts, for people to log in and use. To obtain that functionality, we could roll our own, but the go-to solution for Rails at the moment is a gem called Devise. This gives us lots of advanced functionality such as “remember me”, password resetting, brute force hacking protection and more. So, to add this, open up your Gemfile and add the following line: Then, in a terminal (in your base folder for the application) run: This installs any new gems that you add to your Gemfile and gets them ready for use. Now we have Devise installed, we can use some functions that it gives us. So, this generator has created an initializer for Read more…

Outline This is the start of a series of tutorials, looking at how to build a “Twitter” style of microblogging application. We will have a look at some basics, such as creating users, following/followed. Then we will also look at things such as mentions “@user”, and hashtags “#topic” – and then hook it all together into a live application using push to update users on the service. If there is enough demand, then I’ll also look at publishing a tutorial showing you how to hook this together into a mobile application as well. Whilst it goes against developer morals, I’m going to skip any kind of TDD or BDD in this tutorial – I’m looking to show how easily great functionality can be created, rather than design a sound battle hardened application. Technologies There are a number of ways that we can approach building an application like this, and a Read more…