Rails 3.2 was released earlier today and it provides a variety of new features including: Active Reload, Faster Dev Mode, Tagged Logger and, of coarse, Active Record Store. When Active Record store was released I was a bit curious as to how it works since I only saw the same example on every blog out there and the example itself just wasn’t doing it for me. Therefore this article will briefly explain how to use Active Record Store and how the contents of are stored in the database.

Last Updated

This article was first published on January 20th 2012 and was last updated on January 20th 2012.

Active Record Store

Active Record Store is used for storing additional attributes within a database record without the need to have to create additional attributes (columns in the database table) to store these values. The contents of these “additional attributes” are stored within the scope of an existing attribute and as serialized as a JSON object. Once fetched, they’re unserialized and used as regular attributes. Here’s the basic code for using Active Record Store:

Active Record Store is a great idea for when you need to store optional data into a database record. One thing to keep in mind, however, is this does go against the 1st rule of normalization. This database storage method also makes database searching of the record unpractical when a search is issued on the storage column.

More about Rails 3.2

Some of the other things I noticed about 3.2 was that the development mode is alot faster. Rails startup and migration creation are much faster. Routes also load and parse faster. Other features such as Explain Queries, Compression of Page Cached Files and Tagged Logging are among the many new features provided by rails.

Some Street Cred

Here are some more links to follow up on Rails 3.2

1. http://weblog.rubyonrails.org/2012/1/20/rails-3-2-0-faster-dev-mode-routing-explain-queries-tagged-logger-store
2. http://guides.rubyonrails.org/3_2_release_notes.html

Rails offers an effective caching solution for caching pages using page_caching. This stores the entire output of a request into a publicly accessible file which is then picked up by the web server first before the request is made to Rails. The Rails default method to set the path of the is something that doesn’t take the locale nor the subdomain into consideration. So if you have a subdomain that is bound to the same Rails server, then the page caching will not append any of that to the name of the cached page file. This blog article will explain how to change this behaviour.

Last Updated

This page was last updated on December 29th 2011 and was first published on December 29th 2011

How (where) Rails stores its page cached files

The page that Rails (up to and including its latest version Rails 3.1) stores its page caches are in /public folder of the project root. This configuration can be configured within the application.rb file by setting the following configuration:

config.action_controller.page_cache_directory = Rails.root.to_s + "/public"

When a caches_page directive is set within a controller for a particular action then the page caching sets up the path of the URL to be the path of the cache file. This can be changed within some function overriding.

How to override it

In your app/controllers/application_controller.rb set the following code to change the way that the file is written. Here is the default:

Now lets imagine if you were to include the locale into the mix:

And we can also include the subdomain. Lets imagine that www is the default locale … English (en) and anything else is non-www. The only issue is that the page_cache_path method is a class-level method (static) so the request object won’t be recognized by the class method. We’ll need to add a class variable as a before filter:

Configuring your HTTP Server

So far I’ve only done this with NGINX. What needs to be done is to configure your NGINX server to recognize that the page cached file is there before it fires up the Rails request. Here is my configuration file:

It will take alot of trial and error with getting NGINX to fully recognize your page cached files. Therefore, its better to install NGINX locally and change the HOSTS configuration a proper domain to point on your computer and perfect it that way. Keep in mind that NGINX does not allow AND and OR pre-conditions or nested if statements so you’ll need to use concatenation and variable checking to get something complex to work.

MooTools offers an elegant solution to dealing with messy, unusable JavaScript code that is used to build simple, disposable UI effects and elements, that should normally be abstracted from your application code, with the use of a library called Behavior.js. The library contains two main tools: Behaviour which is used for mapping layout elements to classes (plugins) and Delegator which is used to relate the options identified in HTML elements to predefined, reusable filters (subroutines).

This article will go through the steps involved with getting this awesome plugin working with your application.

Last Updated

This page was last updated on December 24rd 2011 and was first published on December 23rd 2011

In a Nutshell

Behavior scans the page looking for any elements that contain the data-behavior attribute and then it will fire the assigned filter for any of the class(es) defined within the attribute value. This is what it looks like:

In this example, Behavior will scan the page (once the Behavior.attach() method is fired) and then look for any elements that match the selector (data-behavior=”Tip”) and then will append the options fetched from data-tip-options and built the api variable from that. It is up to you as to how you wish to instantiate the plugin (or perform a series of operations).

Delegator is pretty similar. It too looks for an attribute selector (data-trigger=”..”) and applies the associated options to the function call. The function call is registered with the Delegator:

The code is here pretty straightforward and it follows the flow of the Behavior example.

How to set this up

First you’ll need to clone the Git repository or download the source. Next extract all the files into a folder accessible within your web application. Include the following files (in the following order):

1. ./Source/Element.Data.js
2. ./Source/BehaviorAPI.js
3. ./Source/Behavior.js
4. ./Source/Behavior.Startup.js
5. ./Source/Delegator.js

Next, define the filters that you want for your behavior operations with the following code:

Then register the Delegator events for the items that you wish to apply delegation operations on:

Once all the filters and delegation callbacks have been created, now any HTML element that contains the data-behavior or data-trigger attributes that match a behavior filter or delegation registration function will be ready. They won’t fire automatically, so you’ll need to define a run method:

Anything else?

Not so much. This toolkit is really sweet. Once you start using it you’ll see how the majority of your page or element class-specific code will trim itself down. The UI interactivity can be fully abstracted from the application core. I will blog more and more about this later on once I start to use the library within my own projects.

The other day I decided on embedding Github Gist code snippets into yearofmoo instead of regular home-grown code blockquote areas. Gist is awesome, but the standard Javascript embeds do not work with a pure ajax website (like this one). So the only way to get them to work was todo some voodoo JavaScript and then … voila … Gistex was born.

Last Updated

This page was last updated on December 18th 2011 and was first published on December 18th 2011

Gistex?

Yes Gistex. It loads a Github Gist snippet, creates the HTML and pastes it into the DOM element that you wish to apply it to. This is great for AJAX applications and lazy loading. It is also supported in all browers and is NOT dependent on any JavaScript framework. The Gistex class is very simple, and provides support for numerous callbacks and options.

Where can I get it?

Gistex is hosted here on yearofmoo.

Click here to view the documentation and demos.

]]> http://yearofmoo.com/2011/12/use-gistex-to-load-up-github-gist-snippets/feed/ 0 http://yearofmoo.com/2011/10/current-state-of-onhashchange-and-html5-history/ http://yearofmoo.com/2011/10/current-state-of-onhashchange-and-html5-history/#comments Mon, 24 Oct 2011 14:46:13 +0000 matsko http://yearofmoo.com/?p=742 How widely supported are these URL changing techniques in modern browsers?

The onhashchange event is a popular event and has been widely looked into by yearofmoo. The MooTools-onhashchange plugin offered by yearofmoo takes care of this task effectively. The onhashchange event can be used in combination with a hash-prefixed URL token, known as a hashbang, to effectively inform search engines of indexed ajax content.

The HTML5 history API is only offered by modern browsers and offers more features than the onhashchange event. The only issue is that not all browsers fully support it yet since it is a new HTML5 JavaScript API. In addition, unlike with the onhashchange event, there is no way to emulate or hack non-supporting browsers to offer popstate support.

But how widely supported are the two features?

Last Updated

This page was last updated on Oct 24th 2011 and was first published on Oct 24th 2011

The onhashchange event vs the History API

HTML5 history is by far more extensive, user-friendly and profound than the onhashchange event (in regards to dynamic URL changing). The page fragment (or hash tag) of a URL was designed for in page anchoring and not for page to page addressing (which is what the history API does). So how do each of these two compare? Here are some comparsions:

Browser Support

The onhashchange event is widely supported by all browsers (other than IE6 and IE7). As of now, no extra code is required to handle the event for modern browsers. IE6 and IE7 are so far phased out now that they should not be supported for new web apps … so why offer the onhashchange event for them? The history API, however, is not yet fully supported by all browsers until IE10 fully hits the scene.

Here is a complete matrix of which browsers support which:

What should I use?

You should feel comfortable to use both, but be sure to favour use of the history API over to the onhashchange event due to the extra features that are provided.

Any Plugins?

A useful plugin on the popstate-hashing.js plugin offered by yearofmoo. It basically sets up one event to handle the URL changing via the history API first and then via the onhashchange event second. This way, the browser and the developer need not to worry about any extra cases of what todo when changing the URL of a web page dynamically. Click here to view the popstatehashing plugin

History API + onhashchange

The nice thing is that all of the browsers that support the history API support the onhashchange event. So in a few years time, when IE10+ is very common and other IE browsers have been phased out, developers can use both the History API and the onhashchange event together for some truly awesome web page effects. Imagine if you have your top level page changes triggered by a popstate event (using the History API) and then lower level changes, such as pagination and optional, expanding areas triggered by a hash tag change (using the onhashchange event). This way, all areas of a website can be accessed directly from a URL, but your website can be better tailored to make use of more specific events with less code.

Some Links

Thanks guys! :]

• http://caniuse.com/#search=history
• http://ie.microsoft.com/testdrive/Info/ReleaseNotes/Default.html
  ]]> http://yearofmoo.com/2011/10/current-state-of-onhashchange-and-html5-history/feed/ 0 http://yearofmoo.com/2011/10/rails-page-caching-in-a-separate-directory/ http://yearofmoo.com/2011/10/rails-page-caching-in-a-separate-directory/#comments Sat, 22 Oct 2011 06:54:55 +0000 matsko http://yearofmoo.com/?p=700 How to setup Apache or NGINX to be aware of where rails stores page caches

  Rails offers a really powerful caching technique where the contents of an entire page load will be stored into a HTML file. This is incredibly useful for performance enhancements for big and small Rails apps.

  One issue, however, is that when you setup page caching into a different directory which isn’t the public folder root, then the generated HTML files won’t be picked up by Apache, Nginx, or whichever HTTP daemon you’re webserver is running since the direct path is different. Therefore, to get this to work properly, some tweaking needs to be done on the HTTP daemon so that it recognizes the caching directory path.

  The nice thing is that when the caching files are in a subfolder within the public root folder then management of the cache as a whole becomes much easier. This is explained in detail here.

  This article will quickly explain how to setup Rails and the HTTP daemon (Apache or Nginx) to properly behave with the cache change.

  Last Updated

  This blog entry was last updated on October 22nd 2011 and was first published on December 28th 2011

  What exactly is the issue?

  Apache or Nginx won’t notice if a page is cached because the URL to access that cached file is different from the actual URL that accesses the non-cached page.

  # Non-Cached
  /about/some/sub/page
  
  # When cached it will get stored in
  /cache/about/some/sub/page.html

  The path is different and caching won’t work right away so we’ll need to configure the HTTP daemon.

  So how do we fix this problem?

  Configure Rails First

  Be sure to add this to your production.rb (or application.rb) file.

  config.action_controller.page_cache_directory = Rails.root.to_s + "/public/cache/"

  Now all of your page cache files will be stored under /public/cache/PATH

  URL Rewriting does the trick

  Using mod_rewrite for apache and the built-in URL rewriting offered by NGINX, the cached directory can be recognized directly from a “non-cached” URL. The thing to keep in mind is that if a cached file does not exist then the URL rewrite will still apply itself, so its important to consider the rewrite conditions so that the http server is aware of this.

  Here are the settings (keep in mind that this is for a cached directory of /public/cache):

  Apache

  Apache always has the strangest of syntax :p

  RewriteEngine On
  
  # default root uri
  RewriteCond %{THE_REQUEST} ^(GET|HEAD)
  RewriteCond %{DOCUMENT_ROOT}/cache/index.html -f
  RewriteRule ^$ cache/index.html [QSA]
  
  # all other pages
  RewriteCond %{THE_REQUEST} ^(GET|HEAD)
  RewriteCond %{REQUEST_URI} ^([^.]+)/?$
  RewriteCond %{DOCUMENT_ROOT}/cache/%1.html -f
  RewriteRule ^([^.]+)$ cache/$1.html [QSA]

  NGINX

  NGINX is a bit more straightforward…

  # Index HTML Files
  if (-f $document_root/cache/$uri/index.html) {
      rewrite (.*) /cache/$1/index.html break;
  }
  
  # HTML Files
  if (-f $document_root/cache/$uri.html) {
      rewrite (.*) /cache/$1.html break;
  }
  
  # Catch all
  if (-f $document_root/cache/$uri) {
      rewrite (.*) /cache/$1 break;
  }

  Some streed cred’…

  Here’s some lovin’ for some of the websites that helped me put together this article.
  http://www.fngtps.com/2006/lazy-sweeping-the-rails-page-cache/
  http://rel.me/2008/01/07/nginx-conf-with-alternate-cache-dir/
  https://wincent.com/blog/rails-page-caching-vs-nginx
  http://guides.rubyonrails.org/caching_with_rails.html

  ]]> http://yearofmoo.com/2011/10/rails-page-caching-in-a-separate-directory/feed/ 2 http://yearofmoo.com/2011/09/serve-precompiled-rails-assets-from-a-static-domain/ http://yearofmoo.com/2011/09/serve-precompiled-rails-assets-from-a-static-domain/#comments Sun, 04 Sep 2011 00:07:51 +0000 matsko http://yearofmoo.com/?p=655 Precompile and deliver your Rails assets from a different domain for static content

  With the release of the Rails 3.1 Asset Pipeline, which uses Sprockets to deliver Sass and Coffeescript rendered assets, the development of properly organized assets in Rails just got much easier. Now there exist many tutorials out on the web that go into detail about how to play around with this new feature, so I’m not going to go into detail about how todo that. What I will cover is how to setup a static domain, that does not interfere with your Rails daemon, that serves these assets quickly and smoothly.

  Last Updated

  This blog entry was last updated on September 3rd 2011 and was first published on September 3rd 2011

  Why should this be considered

  The major reason why this should be considered is because Rails itself should not have to handle serving asset files regardless if they’re precompiled or not. Back with Rails 3.1 RC4 and RC5 I noticed a huge performance lag with my stylesheet and javascript files whenever they were being served in production mode. Even when they were precompiled, Rails was serving the assets for me and after trying to disable the serve static assets boolean in my production file, this was still slowing down my server. By offering a different domain (or subdomain) to serve the assets, all of the assets themselves can be managed elsewhere. Note there are also various other benefits to serving asset files from a different domain entirely (this is explained in the next section).

  Domains, Subdomains or just a different port?

  Its better to serve assets from a different domain from your www domain. I don’t mean a subdomain, but an entirely different domain. This is because when an asset is fetched from the same domain as your website, the user agent that fetches that asset will upload any cookie data that is stored for that domain and that matches that path. Since Rails stores session data in cookies by default, you can imagine how much unnecessary data is being transfered back and forth just to fetch some asset files. With subdomains, this issue is almost gone, but there could be some cookies in your website that may exist for all domains (www, subdomains and no subdomains). If you use a different port to serve assets then this issue is no different from serving it from the same port as the Rails app.

  Modern browsers will download only a certain amount of assets in parallel from a single host. This means that if use another domain with various other subdomains connected to that domain then you can download almost all your assets in parallel once the page is loaded.

  How do we set this up?

  Easy, just configure your NGINX or Apache server to serve assets from a specified directory which never changes and then configure the headers for caching and expiry to their max. Then setup capistrano to rotate the assets each time a deployment is issued.

  Step 1 – Get the domain(s)

  Whether or not you already have a static domain purchased yet, make sure that you either have a new domain or a subdomain of your primary domain ready so that both domains resolve to the same ip address.

  Step 2 – Configure your HTTP Daemon

  In this article I will only cover how to setup your NGINX + Passenger HTTP daemon:

  NGINX

  If you installed NGINX via passenger for Rails (which I hope you did) then just hop into your nginx.conf file and add the following:

  # Static Server
  server {
      listen 80;
      server_name staticdomain.com;
      root /var/www/staticdomain.com;
      location ~* \.(ico|css|js|gif|jpe?g|png)(\?[0-9]+)?$ {
          gzip_static on;
          expires max;
          add_header Cache-Control public;
          break;
      }
  }
  
  # Rails Server
  server {
      listen 80;
      server_name dynamicdomain.com;
      root /var/www/dynamicdomain.com/current/public;
      passenger_enabled on;
  }

  This way, any static files will be cached properly and no cookie data will be sent to the static files each time an asset is requested.

  Step 3 – Configure Rails

  Be sure to set the asset_host in Rails to that of the domain that you will be using in production mode. Be sure to set the following configurations in your production.rb file:

  #set the asset host
  config.action_controller.asset_host = "http://staticdomain.com"

  Step 4 – Configure Capistrano

  Lets now configure capistrano to precompile your assets just after it has updated and symlinked the code. Once the assets are precompiled, then replace the existing assets with your newly updated assets.

  task :start, :roles => :app do
      asset_path = "/var/www/staticdomain.com/" #this needs to point to where your assets are saved
      run "cd #{current_release}; rake assets:precompile" #compile the assets
      run "rm -fr #{asset_path}/*" #move the asset files to the asset_path directory
      run "mv #{current_release}/public/assets/* #{assets_link_path}" #move the asset files to the asset_path directory
      run "cd #{current_release}; rake assets:clean" #remove the existing assets
  end

  Now whenever a cap deploy command is issued, the assets are uploaded to the asset server and updated.

  Room for improvement…

  If anyone here knows of a better way to hotswap the newly uploaded asset fiels with the existing asset files without having to delete the existing asset files then that would help out a lot. The reason why I use rm -fr + mv is because the asset files within any subdirectories can only be copied over with a move operation (a copy operation will overwrite the entire directory).

  I attempted to solve this by using a symlink operation where the files are linked over to the new assets directory whenever its uploaded. This does not work because NGINX will register the direct path of a symlink whenever it is restarted (this is how passenger works by restarting the mongrel or webrick instance when a capistrano restart call is issued). If anyone knows how to get around this then please let me know in the comments below.

  ]]> http://yearofmoo.com/2011/09/serve-precompiled-rails-assets-from-a-static-domain/feed/ 1 http://yearofmoo.com/2011/09/last-minute-fix-for-rails-3-1-stable/ http://yearofmoo.com/2011/09/last-minute-fix-for-rails-3-1-stable/#comments Thu, 01 Sep 2011 16:20:33 +0000 matsko http://yearofmoo.com/?p=646 Beware of the config.assets.digest fingerprinting defaults!

  As you all might be well aware, Rails 3.1 was released yesterday (August 31st 2011) … and for those of you whom have been developing using the Rails 3.1 beta and RC versions, you may have noticed a small gotcha which occurred in the Rails production configuration that may affect your asset filenames. If you notice that your asset file names are missing a fingerprint hash, md5 token, digest, hash timestamp (or whatever you want to call it) within their filename … like application-xxxxxx.js then the reasoning behind this is because Rails 3.1 disables the config.assets.digest option by default for all environments.

  Last Updated

  This page was last updated on September 1st 2011 and was first published on September 1st 2011.

  What to do?

  The solution is simple, in your production.rb environment file, just set the following:

  config.assets.digest = true

  Turns out that this is documented in the Asset Pipeline Guide, however, since it was enabled by default in previous versions of the Rails 3.1 RC release, I figured that the problem was with my setup and not with Rails.

  Why this is important?

  Hopefully this helps. Instead of having to spend a couple of hours testing previous versions of Rails 3.1 stable, RC5 and so on, now you know better My story was that I was using a separate domain to host the precompiled assets folder so that Rails wouldn’t even get close to serving those asset files on my production server. Then I noticed that, despite the assets being successfully generated and fingerprinted during the rake assets:precompile operation, the javascript, stylesheet and asset helpers were not expanding their fingerprinted filename values. Thankfully, after hopping into the #rubyonrails IRC channel, this issue was quickly extinguished. Many thanks to the rubyonrails dev team.

  ]]> http://yearofmoo.com/2011/09/last-minute-fix-for-rails-3-1-stable/feed/ 1 http://yearofmoo.com/2011/07/mootools-asset-stylesheet-onload-event-patch/ http://yearofmoo.com/2011/07/mootools-asset-stylesheet-onload-event-patch/#comments Sun, 31 Jul 2011 02:37:51 +0000 matsko http://yearofmoo.com/?p=611 A fully working fix for the onload event on the MooTools Asset.stylesheet library

  The Asset.stylesheet library itself is a very useful library for preloading stylesheets via JavaScript. The only problem is that it does not support the onload event for all browsers. The reasoning behind this is because the onload event itself is not supported on all browsers; an older article posted on yearofmoo.com went into full detail about this problem. This blog article, however, provides the code for MooTools 1.2 and 1.3 that patches the Asset.stylesheet library to support the onload event 100% in all browsers.

  Last Updated

  This page was last updated on July 30th 2011 and was first published on July 30th 2011

  Using the yearofmoo Asset.stylesheet patch any assets loaded with Asset.stylesheet will fire the onload event normally on success and will fire the onerror event on failure. The syntax is the same, here is an example:

  new Asset.stylesheet('/path/to/some/css/file.css', {
      onerror : function() {
          alert('error file not loaded');
      },
      onload : function() {
          alert('success');
      }
  });

  To TopGoto DemosDownload

  What’s so special about this patch?

  The good thing about this patch is that it uses the existing support of the onload event which is already supported by IE and Opera.It also does not use any other external requests to emulate the event. Finally, Asset.stylesheet comes with an onerror event which works with a timeout event (so once the request is checked enough times without success, it fires the onerror event). Finally, the patch itself works for stylesheet files that are located locally (on the same domain) and externally.

  To TopGoto DemosDownload

  Demo

  Here is a working demo of the Asset.stylesheet patch for MooTools:

  To TopGoto DemosDownload

  Download

  The Asset.stylesheet can be found on github.

  To TopGoto DemosGoto Download

  Contact

  Any issues or questions can be posted on the issue tracking page found on github.

  To TopGoto DemosDownload
  ]]> http://yearofmoo.com/2011/07/mootools-asset-stylesheet-onload-event-patch/feed/ 0 http://yearofmoo.com/2011/07/element-rotation-using-fx-rotate/ http://yearofmoo.com/2011/07/element-rotation-using-fx-rotate/#comments Fri, 29 Jul 2011 03:57:46 +0000 matsko http://yearofmoo.com/?p=597 Perform quick and dirty rotations using the Fx.Rotate plugin

  Yearofmoo.com has now released the Fx.Rotate plugin which allows for cross-browser rotation using CSS3 transforms and IE filter properties. The class itself is a subclass of the super powerful MooTools Fx class which provides tons of functionality for controlled transitions and callbacks.

  Last Updated

  This page was last updated on July 28th 2011 and was first published on July 28th 2011

  Why?

  Most of the plugins for JavaScript rotation are really basic. This plugin allows for a whole bunch of stuff. Plus it also takes care of older browsers and then some :]

  Quick Example

  Here is a quick example to show how simple, yet powerful, the features that Fx.Rotate provides:

  var elm = $('element');
  
  //rotate to 180 degrees
  elm.rotate(180);
  
  //rotate from 180 to 50
  elm.rotate(180,50);
  
  //rotate from where it currently is back to -20
  elm.rotate(-20);
  
  //rotate clockwise BY 20 degrees
  elm.rotate('+20');
  
  //rotate counter clockwise by 100 degrees
  elm.rotate('-100');
  
  //bring it back to 0
  elm.normalize();
  
  //do something crazy
  var rotator = new Fx.Rotate(elm,{
      transition : 'circ:in',
      link : 'cancel'
  });
  rotator.start(200).chain(function() {
      rotator.start('-100').chain(function() {
          rotator.normalize();
      });
  });

  Full Documentation, Demos & Download

  Click here to view the documentation for the new Fx.Rotate plugin

  ]]> http://yearofmoo.com/2011/07/element-rotation-using-fx-rotate/feed/ 0