Communicate with certainty
and your Voice will be heard.

Category Archives: The Development Mechanism

Until recently I considered writing tests for my applications much like reading Dickens in high school: boring, repetitive, hard to understand, and yet for some reason a total necessity.  What’s more, I wrote tests about as frequently as I read Dickens – and I’ve never read any Dickens.  My meandering point here is that Test Driven Development (TDD) seems to be the standard of the rails community, yet I don’t know a single person who actually does it.  With that it mind, I decided to develop our last client’s application with tests written to the best of my ability.  At first I thought I was burying my productivity in the minutia of each test, but I ended up learning quite a few things, including the value of testing.


I guess the first thing to do here is to describe my tools.  To test with Rails I used RSPEC, Factory Girl, and Capybara.

RSpec is a testing tool for Ruby.  Baked into the gem is a rich command line program with detailed error reporting. The beauty of Ruby, and RSpec, is that it enables you to write human readable tests that tell a story. For instance:

it 'has a list of employees' do
employee ='John', 'Smith')
company =[student])
expect(company.employees).to include(student)

Though testing with RSPEC ensures that our models behave the way we expect, there is a serious problem with this approach: It takes forever. Testing any sort of interesting behavior not only involves extensive amounts of setup to your environment, but a tremendous amount of code to create various instances of your model. This is where Factory Girl comes in.  Factory Girl allows a tester to create factories that create multiple records for a model with some generic attributes that are able to be overridden as needed.  This means that creating a unique record is as simple as:

FactoryGirl.create(:employee, name: "Jon Snow").

My last tool in my little testing toolkit is Capybara. Where RSpec is a way to test your models, Capybara allows your application to test external behavior. In other words Capybara provides a simple way to test user stories and general behavior. Heres an example:

'When I sign in' do
visit user_sign_up_path
fill_in 'Login', :with => ''
fill_in 'Password', :with => 'whereWereTheSpiders?'
click_link 'Sign in'


So What’s The Point

When I started, I assumed that testing would help to prevent bugs. While this is likely the case, I found that using TDD did something far more valuable. By letting tests to drive the code, developers are forced to conceptualize their application before a single semi-colon is ever written. This forces developers to step through their own logic, which in my case, is full of inconsistencies and little things that I had not thought through fully…likely because I have never read Dickens.

Here are some thoughts on talks at the recent An Event Apart, in Boston.

Understanding Web Design – Jeffrey Zeldman

  • Web Design is held to the expectations of other media. Often ignoring the intrinsic strengths of web
  • Like typography, web design’s primary focus is communicating content
  • Technology is often a hangup for people, when the user and their needs should be the primary focus of designers. “Design for people, not browsers!”
  • Design is about detail
  • A great website will subtly guide the user to their desired destination

Designing Using Data – Sarah Parmenter

  • Design is no longer a differentiator. Making things look nice is common. The differentiator today is designing with purpose — answer the question ‘why?’
  • When the right metrics are studied, data offers objective and actionable feedback
  • Data should allow a team to unite behind an objective goal — such as: Increase clicks etc.
  • Customer facing advertising is most effective when honest and transparent
  • Iterative design allows you to be flexible and try new things

Responsive Design is Still Hard/Easy! Be Afraid/Don’t Worry! – Dan Mall

  • Frameworks rather than processes, mean you define a set of constraints within which a project exists, and within this you find out what you can do that’s unexpected
  • Be active within your framework and volunteer/get involved with stages of production outside of your discipline
  • Each member of a team will have divergent perspectives at the start of each project cycle, they should become convergent by the end. These are focal points
  • Rinse and repeat the cycle, getting smaller each time to increase team involvement
  • Extensive preparation should make the assembly part of the process the shortest

Screen Time – Luke Wroblewski

  • Mobile is the dominant web browser worldwide
  • Responsive design includes additional considerations than just screen size (multiple input types, variable ambient lighting etc)
  • Screen size is a poor proxy for many of these considerations (screen size does not reveal input type)
  • A user’s posture or distance from device will also affect it’s design, independent of screen size or number of pixels
  • Design for human proportions, not pixels.

Content/Communication – Kristina Halvorson

5 key points for working with a client:

  • Principles: these are internal motivators based on our better intentions. They can unify a team
  • Strategy: pinpoint your goals and provide helpful constraints with which to execute
  • Process: the process is not God, it should change and grow as needs change. Regular post mortems are encouraged
  • Roles: RACI key for each agent on the client end. Responsible. Accountable. Consulted. Informed
  • Perceptions: Translate to facilitate communication between different disciplines

UX Strategy Means Business – Jared Spool

  • Design is the rendering of intent. Both user and provider
  • Content delivery is as important as the content itself and vice versa. Great UX cannot exist without great content
  • Advertising is unhelpful for all parties involved
  • Strategic priorities in business can inform design considerations (increase revenue, reduce cost etc)
  • There are a variety of models for monetizing the web

The Long Web – Jeremy Keith

  • HTML allows for fantastic accessibility, deprecation and backward compatibility
  • New HTML specifications can be adopted early as they will be skipped over when unsupported
  • Progressive enhancement means you start with the lowest common denominator and then enhance as much as you like
  • Progressive enhancement protects the experience from unaccountable errors such as unrelated javascript errors
  • Text formats will last longer than binaries. Binaries are forever changing and becoming outdated

Responsive Design Performance Budget – Paul Irish

  • Mobile users expect their content to load faster than the desktop
  • Web growing is latency limited. The nature of requesting many small files means that a user’s experience is improved by reducing the number requests
  • UX can be greatly enhanced by prioritizing critical data and rendering early on
  • Separate the critical CSS from non-critical. Load non-critical at the end of the page. Aim for main content to load in 1 sec (< 14kb)
  • The number of higher latency users is increasing

The Chroma Zone: Engineering Color on the Web – Lea Verou

  • Colors in web browsers have many nuances and limitations
  • Hex and RGB are poor representations for human reading
  • HSL and HSLa are better although they are not perceptually uniform (we perceive 50% yellow as much lighter than 50% blue)
  • New color properties in CSS level 4 will make color coding more human readable (HWB = Hue Whiteness Blackness)
  • There is room for much more improvement in web colors

Mind the Gap: Designing in the Space Between Devices – Josh Clark

  • Designing for the space between screens. Not content but tasks. Verbs not nouns
  • The technology is available today, we just haven’t imagined the possibilities yet
  • Interfacing with machine is likely not going to change much (touch and mouse are great interfaces)
  • Physical things are beginning to have digital representations (avatars)
  • How about affecting how we interface with physical world and communicating that to our devices.
  • Software makes hardware scale, The endless possibilities

Web+: Can the Web Win the War Against Native Without Losing its Soul? – Bruce Lawson

  • Web technology has inherent strengths, despite the popularity of native apps
  • Web tech should not try to replicate — though it can learn from native. Build to the strengths of web
  • Progressive enhancement and interoperability make web accessible and global. Always accessible by everyone
  • Widgets failed as they were a poor imitation of native apps. They existed as a snapshot without the ability to update
  • W3C is built for accessibility and interoperability. This means that it is designed for low level functions. Can be complicated but powerful

How to Champion Ideas Back at Work – Scott Berkun

  • Great things are achieved in difficult circumstances
  • Success and acclaim only arrive once a project is complete
  • Charm and convincing people of your ideas is important!
  • A network increases your potential. Reach out and get advice to harness that potential
  • To enact change, start small with something you can excel at and expand from there

This post explores issues we experienced with a recent project, involving jQuery UI’s draggables and how we solved it using CSS3 translate and javascript touch events.

In the midst of full production, we discovered an issue with iPad handling the combination of jQuery UI “draggables” and high quality images (for using jQuery UI with iPad touch events).

As production had already begun, we needed a shim to would work alongside what was already built, and replace the jQuery UI functionality on iOS devices.

We performed tests, sectioning off the drag and drops from the rest of the project and realized that, even one large background image severely affected the performance of the dragging animation on iOS devices. Scale that up to a production size eLearning platform and we suffered serious memory bleeds, causing Mobile Safari to crash instantly.

We googled far and wide but could find no solution. (HTML5 drag and drop would not fit the bill as it would require rebuilding everything we had done so far.)

And so we resolved to build a jQuery plugin and were pleasantly surprised to discover this undertaking was much simpler than first anticipated. Not only that, but our solution meant that, aside from changing the script which controlled these activities, we did not have to change any of the markup already written for dozens of pages.

This blog post was a great jumping off point, it had done much of the hard work for us, showing us how to tie a touch event to a moving element. Despite being a great resource, the script animates with the “top” and “left” properties. While these work on all platforms, they use a lot of CPU power, too much for the poor iPad. And so we updated the code to use CSS3 translate. This change was light and day. iOS webkit hardware accelerates CSS translates through the GPU and the performance improvement was significant.

Next we needed to add functionality to drop a “draggable” inside a “droppable”. This was done in two steps. First we added an initialization for “droppable” elements which would calculate the coordinates of the “droppable” and store these values in the data attribute of that element. Next we added an event handler for dropping an element, which finds if the last touch event occurred inside the bounds of a “droppable”. If this is the case, then we translate the “draggable” to sit on top of the “droppable”.

Along the way we added certain functionality specific to our project such as populating an object named “dragInput”, which contains the placement of any dragged items and can then be compared against another object which holds the correct matches for a quiz style drag and drop activity.

Since integrating this into our project, I have tried to extend the plugin by adding mouse event listeners. There are limitations, such as dropping an element when the mouse escapes the bounds, despite the ‘mousedown’ event still being active. I have seen this behavior elsewhere. jQuery UI must use event listeners on the window to make up for this deficiency. Although I bemoan jQuery UI’s use of pre-CSS3 techniques, having tried to replicate the functionality with mouse events, I appreciate the depth of their project. The touch events were comparatively robust and behaved as expected.

CSS transforms are very powerful and although confusing at first glance, they give web developers exciting possibilities for creating native like experiences within browsers. By using transforms, our drag activities went from crashing the iPad to outperforming jQuery UI draggables on a desktop.

I hope this post proves helpful and I will continue to develop the plugin, as time and persistence permit.

Check out the github here.

When you started Microsoft, you had a crazy-sounding idea that someday there would be a computer on every desktop. Now, as you return to Microsoft 40 years later, we have computers not just on our desktops, but in our pockets – and everywhere else. What is the biggest surprise to you in the way this has all played out?

Well, its pretty amazing to go from a world where computers were unheard of and very complex to where theyre a tool of everyday life. That was the dream that I wanted to make come true, and in a large part its unfolded as Id expected. You can argue about advertising business models or which networking protocol would catch on or which screen sizes would be used for which things. There are less robots now than I would have guessed. Vision and speech have come a little later than I had guessed. But these are things that will probably emerge within five years, and certainly within 10 years.

via Bill Gates: The Rolling Stone Interview | Rolling Stone.

That’s how the must-read interview begins.

LORNA is 4, going on 5. I’ve never met her before, but her eyes light up when she sees me. She rushes over, blonde curls bouncing. “I’m going to sit on you!” she declares. I demur, so she climbs into the chair next to me. “I weigh forty pounds!” she exclaims.

I hand her the iPad I’m carrying and the silliness melts away in an instant. A teacher helps her load up an app, gives her a quick tutorial and she’s off, pulling at icons, stringing instructions together, building animations. Lorna is on her third day of learning to program a computer.

Lorna and her classmates, who range in age from 4 to 7, are taking part in a pilot study here at Tufts University in Medford, Massachusetts, to see how young children respond to ScratchJr, a spin-off of the Scratch programming language. Scratch was invented to teach students as young as 8 how to program using graphical blocks instead of text. Now even children who haven’t yet learned to read or write are getting in on the act.

Tools like Scratch aim to address what their developers see as a lack of computer programming instruction in schools today. The general thinking is that children are growing up surrounded by powerful machines they do not understand and teaching needs to be overhauled to prepare today’s youth for a future living and working closely with computers.

via Kindergarten coders can program before they can read by Michael Reilly – New Scientist.