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...
Monday, 30 April 2012
Friday, 27 April 2012
A "Hello, World" with Attributes from Chef
Following on from the minimal Hello, World, this post continues to explore Chef from a development perspective. Attributes parameterise Chef scripts. Let's introduce an attribute...
Wednesday, 25 April 2012
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 spike on Meteor, the JS framework that has gained a lot of popularity over the last few weeks. Some results of this spike are reported here.
Last week we decided to do a short spike on Meteor, the JS framework that has gained a lot of popularity over the last few weeks. Some results of this spike are reported here.
PhantomJS On Ubuntu
PhantomJS is a web stack with JavaScript but without a user interface. These qualities are useful more widely but today I'm interested in fast integration testing for a website in EmberJS, Ruby and Rails. Time to make PhantomJS 1.5.0 run on Ubuntu Oneiric (11.10)...
PhantomJS avoids
And here's how it went...
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.
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
Rails 3.1 introduced the asset pipeline, 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
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
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.
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.rband 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...
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
Gentoo is my favoured linux but sometimes it takes time to learn to love its quirks. Last week, I found a tweak is needed to develop Ruby on Rails using RVM and Bundler. Here's how...
With a shiny new user and a shiny new
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 ember-resource, I needed to upload a file. I couldn't find an easy way to do this within the library. Instead I used the HTML5 File API to read the file in and simply send the file contents as part of the JSON payload.
It turns out this is quite easy to do, although a bit verbose. You need to:
It turns out this is quite easy to do, although a bit verbose. You need to:
- Create a FileReader.
- Set an event handler for the onload event.
- Pass the file(s) you want to read to the appropriate reading method.
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 handlebars 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...
Subscribe to:
Posts (Atom)