Does anyone use a printer for personal use at all? My only requirement for one is when printing out paperwork that I must sign physically and then scan back and email/upload.
Don’t like the quiet scare you, we’re still alive! Come check out our new streamlined look and workflows http://enactivity.com/
Enactivity has reached the stage in development where more and more Javascript is coming into play to create richer user experiences. A key engineering problem in this case is keeping those scripts organized, both in development (being able to just find the correct file or line to work on) and for the users (having code load in the correct order, in a single chunk to reduce load times, etc.). Yii our platform of choice, lacks a good solution.
What Do We Want?
- A process/script/extension that will combine Javascript files into a single file based on specific instructions (
combine *.jswon’t work, as there are dependency issues` - A Javascript minifier
- Command-line support for deploying (we’re a simple people)
Good to Haves
- Ease of minification and non-minification
- Ease of updating required files (the process of adding or removing new scripts should be obvious for new developers)
Enter Sprockets the Rails 3.* solution for maintaining asset files. Sprockets has a growing (grown even?) reputation due to its integration into Rails over other popular solutions like (Jammit)[http://documentcloud.github.com/jammit/], so I thought I would take a few hours to understand what it offered.
Working with Sprockets
Set up for Sprockets is fairly simple. It’s a ruby gem, with installation being (ruby installation required):
gem install sprockets
In each javascript file, use special //= comment blocks to specify the required dependancies for the files, for instance, any JQuery plugins would probably have the first line of
//= jquery
or perhaps
//= vendors/jquery/jquery
to follow the nested structure of vender folders. It works (from a basic view) like PHP’s require_once and loads the appropriate file once and generates and error of the file is not found.
So far so good. I quite like this style of dependency declarations and it saves me from writing a massive configuration file to maintain. My application javascript file, application.js, looked like:
//= require jquery.js
//= require modernizr.js
//= require AjaxButton.js
//= require DropDown.js
//= require SmoothScroll.js
//= require TargetHeaderFix.js
// Ajax beautification
$(document).ajaxStart(function() {
$('body').addClass('ajax-loading');
});
$(document).ajaxStop(function() {
$('body').removeClass('ajax-loading');
});
And produces an appropriate application-e7d846da60ad79a168cf024c5d1f154e.js file with the required javascript merged in.
However
That -e7d846da60ad79a168cf024c5d1f154e.js was an odd side-effect, as I need a <script type="text/javascript" src="/js/application.js"></script> block to map to the file.
This made me look deeper into the expected behavior of Sprockets and realize that it’s not only a combination/minification tool but also a assets server. It’s designed to sit on a localhost port and deliver the generated application file on enactivity.com/js/application.js requests.
…and that’s fine for some, but not what I was looking for. Yii (and most PHP frameworks) doesn’t have so many moving parts, mostly the Apache or Nginx webserver and MySQL database. Every additional server requires an additional tracking mechanism, and a Javascript delivery failure could be a very subtle but crushing bug for users to encounter.
TL;DR
Sprockets is cool, but uses its own deployment server.
Possible alternatives
- DocumentCloud’s (Jammit)[http://documentcloud.github.com/jammit/]
- Steve Clay’s (Minify)[https://github.com/mrclay/minify] (which has it’s own Yii extension too)
What are other people’s experiences with the JS minification problem?
Integrating UX into an agile process. Still don’t know how I feel about a ‘Sprint 0’ as it seems like a early waterfall setup.
From: http://www.uie.com/brainsparks/2012/02/17/anders-ramsay-designing-with-agile/
We begin with a love story—from a man who unwittingly fell in love with a chatbot on an online dating site. Then, we encounter a robot therapist whose inventor became so unnerved by its success that he pulled the plug. And we talk to the man who coded Cleverbot, a software program that learns from every new line of conversation it receives…and that’s chatting with more than 3 million humans each month. Then, five intrepid kids help us test a hypothesis about a toy designed to push our buttons, and play on our human empathy. And we meet a robot built to be so sentient that its creators hope it will one day have a consciousness, and a life, all its own.


