Monday, 30 April 2012

A "Hello, World" from File by Chef

First there was "Hello, World", Chef-style. Then again with attributes. Now to complete this short trilogy, we add some File interaction into the mix, deploying a text file in a step-by-step style...

Friday, 27 April 2012

A "Hello, World" with Attributes from Chef

Following on from the , this post continues to explore Chef from a development perspective. parameterise scripts. Let's introduce an attribute...

Wednesday, 25 April 2012

Google Web Fonts: Open Source Goodness

Intuitive and easy to use, altogether fontastic!

Meteor JS

Here at Hedtek we are all passionate about technology, always eager to try out something new: Like playing with a new web framework that has just been released, or even experimenting to see whether it's possible to have 4 different displays on a single Ubuntu machine (more about this in a later post).

Last week we decided to do a short on , the framework that has gained a lot of popularity over the last few weeks. Some results of this spike are reported here.

PhantomJS On Ubuntu

is a web stack with but . These qualities are useful more widely but today I'm interested in for a website in , and . Time to make PhantomJS 1.5.0 run on (11.10)...

PhantomJS avoids make, autoconf et al, preferring to roll their own build system. So it's best to grab a binary and follow the installation instructions. For x86 and x86_64 grab the appropriate dynamic build. For other platforms, pick a different tool...

And here's how it went...

Saturday, 21 April 2012

Performance at load of a Rails front end and DSpace implemented repository

We present a report that results from work commissioned by Jorum, an Open Educational Resources Repository built on DSpace.


We measured performance of a combination of a Ruby on Rails front end, a modified DSpace REST API, and an instance of DSpace. Measurements were performed over a University intranet segment using ApacheBench.


The report that contains a very comprehensive set of performance graphs for different kinds of accesses at different load levels. 


Download the report.

Friday, 20 April 2012

Compiled asset woes

3.1 introduced the , which is a great addition but can cause some unfortunate issues.
One that has recently been an issue for us is a cascade of behaviours that individually are all perfectly reasonable but, when combined, leave you with major headaches.

When you compile your assets with you get (as expected) your files, in compiled, minified form in the folder public/assets.

Files in public/assets are served in preference to anything produced by the Rails stack (they shadow your controllers). Perfect behaviour for caching, disabling certain routes, etc. and makes sure you are familiar with how things would act with a web server in front of Rails.

In development mode, Rails will serve all your javascript files separately, while precompiled only the manifest files will be present. So in development, you may have several (or even dozens) of files, while in production you only have one. Again, fantastic behaviour for caching, reducing requests and a whole host of other things.

In combination with precompiled assets though, it's disastrous. Your top level file (assets/application.js) in development is pretty much empty, but compiled contains all or almost all of your application's javascript. If the compiled version gets served in development then all your javascript is sent to the browser twice... and this is almost certainly going to break things.

If you're lucky and you have a light javascript application, the most you may notice is some effects not working correctly, maybe you'll investigate briefly on production and see it works fine, put it down as a development machine problem (or you'll solve the problem and never think about it again until it happens again).

On a heavy javascript application with a lot of javascript running in the browser, chances are your entire application will simply not work. If you aren't aware of the cascade of issues, this can take a long time to solve.

If you're running automated tests against everything (using tools like capybara-webkit or poltergeist) then the situation is slightly changed. In the test environment, Rails doesn't serve separate assets in a single file. But the file will still be served from public/assets in preference to the Rails stack, so your tests will run against the last version you precompiled. Again, this can be very confusing and even if you're aware of the previous behaviour it can take you a while to work out why tests that run fine on one machine (with no precompiled assets) don't work on another (where you precompiled assets last week for a demo and haven't cleaned them out).

Is there a solution? Yes, there's a very simple one. Simply configure Rails to serve your assets from a different location depending on environment.

Add the line to config/environments/development.rb file and a similar one to config/environments/test.rb
and the problem is now gone and you can compile assets on any machine without fear of causing issues if you forget to clean them up.

Thursday, 19 April 2012

HTML5 Local Storage

HTML5 brings developers lots of shiny new toys, varying in maturity and adoption. I'm happy to report that local storage — a stash of data persisted locally by the browser — now works wonderfully well on Mozilla Firefox 11 and Google Chrome 18.

Or at least as well as could be expected...

Some important consequences follow from the specification. In particular, local storage is sandboxed by domain — or more precisely [scheme, host, port] origin. Any script from the same origin shares the same local storage.

If you seek a secure local data stash for an authenticated user, local storage is not the API you're looking for...

Wednesday, 18 April 2012

Ruby On Gentoo with RVM

is my favoured but sometimes it takes time to learn to love its quirks. Last week, I found a tweak is needed to develop on using and . Here's how...

With a shiny new user and a shiny new .rvmrc after cd (into the directory) I see

==============================================================================
= NOTICE                                                                     
==============================================================================
= RVM has encountered a new or modified .rvmrc file in the current directory =
= This is a shell script and therefore may contain any shell commands.       =
=                                                                            =
= Examine the contents of this file carefully to be sure the contents are    =
= safe before trusting it! ( Choose v[iew] below to view the contents )      =
==============================================================================
Do you wish to trust this .rvmrc file? (/home/hedtek/space/.rvmrc)
y[es], n[o], v[iew], c[ancel]> y 

Trying to install bundler then fails with

$ gem install bundler
/home/hedtek/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/
  site_ruby/1.9.1/rubygems/custom_require.rb:36:
  in `require': cannot load such file -- auto_gem (LoadError)
 from /home/hedtek/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/
  site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'

Turns out that the Gentoo defaults don't play well with rails development. Easy to fix by an unset when starting a development session:

$ unset RUBYOPT

Once this has been done, all is good:

$ gem install bundler
Fetching: bundler-1.1.3.gem (100%)
Successfully installed bundler-1.1.3
1 gem installed
Installing ri documentation for bundler-1.1.3...
unable to convert "\xC3" to UTF-8 in conversion from ASCII-8BIT 
to UTF-8 to US-ASCII for lib/bundler/vendor/thor/invocation.rb, skipping
Installing RDoc documentation for bundler-1.1.3...
unable to convert "\xC3" to UTF-8 in conversion 
from ASCII-8BIT to UTF-8 to US-ASCII 
for lib/bundler/vendor/thor/invocation.rb, skipping

Thanks to this post for setting me on the right road...

Monday, 16 April 2012

Brief Foray into HTML5 File APIs

Recently, using , I needed to . I couldn't find an easy way to do this within the library. Instead I used the to read the file in and simply send the file contents as part of the payload.

It turns out this is quite easy to do, although a bit verbose. You need to:
  1. Create a FileReader.
  2. Set an event handler for the onload event.
  3. Pass the file(s) you want to read to the appropriate reading method.
For a canned solution, this view for  will allow you to bind an attribute to the content of a file specified in a file field:

MyApp.Views.file = Ember.View.extend                             
  tagName: 'input'                                     
  attributeBindings: ['type', 'id']                     
  type: 'file' 
                           
  change: (e)->       
    view = this                                
    reader = new FileReader()                                         
    reader.onload = (e)->             
      view.set('file', e.target.result)                    
    reader.readAsText(e.target.files[0]) 

This can then be invoked in a template as follows:

{{view MyApp.Views.file fileBinding="SomeModel.attribute" }}

I expect this approach to be unsuitable for extremely large files as it will read the entire file into memory and transmit it as part of the payload rather than as a file upload, for some value of extremely large...