Sunday, 6 November 2011

Bits of Code #2 - Ordering records through index page with AJAX (powered by jQuery) in a Rails 3.1 App

In one of the projects that I worked in I had to make it possible for users to easily change the order in which the records of a table would appear in their index page. I knew that there were a few gems out there that could handle this for me, but I thought that it was such a simple functionality that it was probably not a strong enough reason to add another dependency to the project; so I went about building it.

In this example I've added this functionality to a Product model. I started by creating a migration to add the column that would keep the order between products, I decided to call this column sort_index.

Then I added a few methods to the Product model. Some methods to check the position of a product, others to move the product up and down in the 'ranking' of products, and a before_create callback to set the initial sort_index of each new product. Note that the upper position in my implementation is the position with sort_index equal to 0, so moving a product up is actually reducing its sort_index by 1.

These methods were tested with RSpec (might not be 100% coverage, let me know if that is the case). I've moved the RSpec file to the end of the post because is quite a long file.

Having these methods working I implemented the functionality and the interface to allow the users to actually change the ordering of the products.

Created the necessary routes.

Created the controller methods.

Followed by the views. The index page.

Which calls the _ordering partial

And then the js views to process the result of the requests. To move down.

And to move up.

If you need to use this in more than one model you can move some bits into a Module and then include the Module where necessary. I haven't had the need to do it. But if I do, I'll probably do a post about it.

Hope these bits of code are useful for you some day, I've already used in two projects. If you find any issues or have any suggestions to improve this code please let me know.

And now for the RSpec file:

Friday, 4 November 2011

Bits of Code - Nested Attributes

Yesterday I had the need to implement a form with some nested attributes and so I did what I often do: I went back to a previous project and copy&pasted the necessary code and then changed it to match the new project's needs.

While I was doing this I thought that it would be useful to get this, and other bits of code in a place that I can easily refer to, instead of having to remember in which project I've used what. This is the reasoning behind this post.

Bare in mind that this is not a post about life changing bits of code, but rather bits of code that I need now and then and that are easier to just copy&paste&edit than to have to rewrite from scratch. Some of these bits can be easily found in different websites, but having them here will make my life easier than having to search again. I'll make sure I'll refer to the websites that I've used.

So these first bits of code are meant to build a form with nested attributes.

Imagine that you have a model named Content that has many Attachments and when you are adding or editing a content, you want to be able to manage that content's attachments. This allows you to easily do it.

This code uses Rails accepts_nested_attributes_for and then it manages the different attachments with javascript methods (using jQuery framework), allowing you to add, remove and edit them accordingly.

The Content model:



The Attachment model (notice the accepts_nested_attributes_for method):



The ApplicationHelper, with the methods used in the views:


Part of the Content form view (notice the use of the method fields_for, and the helper method link_to_add_fields):


The attachment_fields partial (notice the use of the helper method link_to_remove_field):


And the javascript methods (notice that if the position of the elements in the attachment_fields partial changes this code might need to be updated):


 These bits of code are based on (or were copied from):

Tuesday, 20 September 2011

Asset Pipeline and Upgrading to Rails 3.1

One of the main changes in Rails 3.1 is the Asset Pipeline, which is, in the words of the Rails guide:
"The asset pipeline provides a framework to concatenate and minify or compress JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
Prior to Rails 3.1 these features were added through third-party Ruby libraries such as Jammit and Sprockets. Rails 3.1 is integrated with Sprockets through ActionPack which depends on the sprockets gem, by default.
By having this as a core feature of Rails, all developers can benefit from the power of having their assets pre-processed, compressed and minified by one central library, Sprockets. This is part of Rails’ “Fast by default” strategy as outlined by DHH in his 2011 keynote at Railsconf."
This looks like a really nice addition to Rails, and I look forward to enjoy its benefits. Unfortunately so far it has only brought me a slight feeling of pain, maybe because I have not started any Rails 3.1 application from scratch, but have only tried it by upgrading existing Apps from Rails 3.0 (or even from Rails 2.3.5) to Rails 3.1.

I first tried to upgrade to Rails 3.1 before the final release. It was a day to try new things at work and I had decided to upgrade an app from Rails 2.3.10 to Rails 3.1.rc1, and from Ruby 1.8.7 to Ruby 1.9.2. I started by upgrading the Ruby version, which wasn't an issue. Just had to recompile the gems I was using with the new version of Ruby and it all worked quite well.

Then I upgraded the Rails version to 3.0 by following Ryan Bates' Railscasts on the subject, and by using the Rails upgrade plugin. This took a bit longer as the application is relatively big, and quite a few things changed from Rails 2.3.x to Rails 3.0. I also had to add bundler as I was not using it before, but in the end I managed to do it.

Next step was upgrading to Rails 3.1. I thought it would be a challenge but it turned up to be quite simple... except for the Asset Pipeline. At that time not even the guide that I link to in the top was available, or at least I didn't find it, and I struggled to get my javascripts and css stylesheets to work. As the day was coming to an end I stopped there and haven't gone back to it since.

This week I had another go at upgrading an App to Rails 3.1. This time the application was in Rails 3.0.x, and once again everything went smoothly except for the Asset Pipeline.

My issue, I have found out, was related with the way I was using the application.js and application.css files. These files are used by Sprockets, the library that powers the Asset Pipeline, to know which js and css files are required by the application, they are named manifest files. In the different guides and documentation the examples of these files were something like:

So, in a noob action, I thought that the require_tree . directive would be enough to have all my javascript/css files properly included in the application. It turns out that, that, is not true. As some of my javascript files are dependent on other files my application was not working as expected, I needed to declare them in order in the manifest file for Sprockets to place them in order in the generated application.js file, and for the application to work.

I know this was probably my fault, but all the examples looked so tidy, and I didn't see any warning to be aware of this, that I was truly believing that Sprockets would make it all work. Like if it was magic!

Fortunately now I think that I got the hang of it and hopefully will be able to enjoy the power of the Asset Pipeline and of Rails 3.1.

For reference here are my manifest files, and they are not as tidy... If you know of a way to make them look better please let me know:


-----------------
Post-post: It seems that the guides state "For some assets (like CSS) the compiled order is important. You can specify individual files and they are compiled in the order specified:"... Guess another lesson is to try and read everything that is written in the Guides. :D Thanks to Décio to have pointed this out. =)

Tuesday, 16 August 2011

I must not forget what I've read #1

It might be lame to make a post with links to other people's text, and maybe that's Google+, Facebook, Twitter and GooglReader's job, but I just thought that it might be useful (at least to me) to keep track of some of the articles that I've read. For future reference or simply to spread the word. =)

* Vendor everything still applies: This strategy for using bundler and manage gems in a Rails project has been really useful for me, and has saved me plenty of time in deployment, and project sharing.

* A successful git branching model: Git is amazing and this branching model has been the one that has made more sense to me and which I have been using more often. The article also helped me understand Git better.

* Performance Testing Rails Applications - How To?: Looking forward to use this on my applications. Have a few in need of performance improvements.

* Dev Checks – Improving code quality by getting developers to look at each other’s work: I find it really interesting to learn how other people improve their programming skills and their code quality. I believe that showing our code to others will help us improve it, and don't worry if something embarrassing comes up... it's part of the fun. ;)

* Rails Best Practices 68: Annotate your models: I've been following this best practice in every project, this is really useful and saves loads of time when trying to figure out what's inside a model!

Tuesday, 19 July 2011

Backing Up a Brightbox DB Server

I've just finished setting up the backups for one of our Brightbox database servers, and I thought it might be interesting to share how are we doing them.

As we work a lot with Ruby we decided to use two gems: Backup and Whenever; to manage the backups.

Backup allows us to easily define which database to backup, where to store the backups, if we want the backup to be compressed and which type of notification should be used.

Whenever allows us to manage our server's Cron tasks with ease, allowing us to write the necessary tasks in Ruby.

For this server we decided to compress our backups with Gzip, to transfer them to Amazon S3 and to use email as our notification system. So our system was setup like this:

ruby 1.8.7
gem backup, 3.0.16
gem whenever, 0.6.8
gem mail, 2.2.19
gem fog, 0.7.2 #to handle the S3 storage


We are using Ruby 1.8.7 because it the default in the server and we didn't feel the need to change it.

After having all the necessary tools installed we created the config files. We want to backup our databases daily, monthly and yearly, so we need three backup files. Unfortunately the Backup gem doesn't seem to handle multiple databases in the same config file, so we created three files for each database.



The configuration is very straightforward. You just need to add the details of your database, the details of the S3 storage and of the mail notifications.

After having created the config files we created the schedule.rb file for the whenever gem.



Note that for the cron job to be able to execute the backup command we need to set the environment variable PATH. In the following lines the gem will go through the existing database names and add a line in crontab to execute each of the type of backups (daily, monthly and yearly).

To add these tasks to cron we just need to run:

whenever -w "[a_name]".

And by running the following command we can see the crontab list:
crontab -l

Which might look something like:



So this is how we are backing up this database server. How are you backing up yours?

If you have any questions, or suggestions about this please let me know in the comments. =)

##Edit:
I just realised that I forgot to mention the Server details:
Operating System: Ubuntu 8.04 LTS
Database Server: PostgreSQL 9.0

Friday, 17 June 2011

Why You - Don't Debug in Production

Some time ago there was a very heated discussion about CoffeeScript in a Rails' Commit @ Github. Yesterday a friend of mine brought to my attention an interesting issue also @Github.

The issue referred to a command that was ran during installation and that, in Linux machines, would delete the /usr directory... which is not very nice since:
"This directory contains user applications and a variety of other things for them, like their source codes, and pictures, docs, or config files they use. /usr is the largest directory on a Linux system, and some people like to have it on a separate partition."

The issue was promptly fixed but the joke was on, and many many comments are being made on the commit page.

Funny enough one of those comments "mentions" my blog in some way with this image:


And I couldn't miss the chance to prove the point of my blogs' title.

I feel sorry for MrMEEE, everyone does mistakes. But maybe this way he'll get more people to help him with his app.

Thursday, 26 May 2011

Choosing the best way #1

Yesterday I was building a method to populate my chart, with Ruby on Rails, and was trying to think of the best way to get the array of years and the array of series to my view. Both would be obtained from a set of 'arrangements' associated with the current user.


I didn't want a messy controller so most of the action would happen in the model. Still I was not sure if I should have two instance variables (one array for the years and an hash for the series) or only one (an hash with information about the years and the series). So I defined three ways to do this and asked for opinions from my colleagues to help me decide.



The first alternative would need two methods in the model. The second one and the third would need only one method. But the third way could make it a bit confusing, some said.

I ended up going for the second alternative, but I must say that the third one also attracted me for it's use of that interesting ruby functionality (returning multiple results from a method).

Which one would you choose? A completely different way to do this?

Wednesday, 25 May 2011

Javascript Charts

One of our latest projects is focused mainly in data visualization, with both maps and charts. In the past day and a half I have been implementing a chart that was designed by the guys at Vizzuality.

The chart is an area chart that shows four or five series of figures over a number of years and it has some particular characteristics that make it blend in with the whole design of the application.

Desired chart

I started by using Google Charts API and managed to get really close to what I wanted, but unfortunately I didn't manage to find some options that I needed. Like for instance hiding the marker on specific points of the chart, or moving the y axis labels to the interior of the chart, and some other small things.

Google Charts atempt

Maybe it was my fault, but as I didn't really want to spend too much time looking for those options I ended up trying out Highcharts, that had mentioned by one of my colleagues when we first started looking into this project.

It was with much relief that by looking into their documentation and examples I found the exact options that I needed. In a few hours I managed to draw a chart like the one in the Vizzuality designs! And after a short while I managed to have our sample data being displayed in the chart.

Achieved result

It was really nice to achieve this goal and I was very pleased with Highcharts. "Unfortunately" it has a drawback, it's not free... except for non profit organizations like ours. =)

Anyway if you don't want to have to pay or use Highcharts I think that Google Charts is pretty good as well and as easy to use.

Maybe there are other options out there, care to recommend some?

PS: First post is here! Hurray!=)