skookum @ dtv


10 May 2013

  1. Development Summary (today)
  2. Next Steps (tomorrow)
  3. Risk Factors (beyond)


*demos


development summary


We built and improved a lot over the past two weeks:

  1. Node.js architecture and idioms
  2. Front-end architecture
  3. AngularJS component library
  4. Git workflow for teams

1. node.js architecture and idioms


  • Added a makefile for ease of onboarding and setup.*
  • Replaced "one Big App" with several small apps.*
  • Built composable, reusable middleware.*
  • Separated our configuration from our code.*
  • Clustered our processes into crash-resistant workers.*
  • Extracted our state into external services.*
  • Built unit tests for our components.*
  • Built integration tests for the golden path.*
  • Added a performance profiling mechanism.*

2. front-end architecture


  • Built a flexible layout structure with jade's block, prepend, and append.*
  • Added a JSON prefetch system that provides client-side templates with data without an AJAX delay.*
  • Separated JavaScript into modules: one library module for shared components, and an application module for each non-trivial page (browseApp, guideApp, etc).

3. Angularjs component library

  • User interface, data filter, and service components.
  • Each component has a single responsibility.
  • Components are decoupled from each other.
  • Each component is individually testable.*
  • Components can be composed into each other.*
  • Components are portable and can be reused.*

4. git workflow

Based on "Github Flow."

  • Moved from an unstable master to one that is always stable, deployable, branchable.
  • Moved from merge conflicts at every pull and push to established points of conflict resolution.
  • Established feature branches for testing and backup.*
  • Established pull requests for code review and continuous integration.*

next steps


  1. Nail down the API.
  2. Expand the component library.
  3. Test client performance on mobile devices.
  4. Test server performance with heavy requests.

1. nail down the api


Right now it's mostly based on the Java services.

Consider stubbing out the front end with an ideal theoretical API... and then using node to transform the Java services into that ideal API.

A top-down approach will generally simplify front end code and minimize XHR bandwidth.

Also consider following RESTful constraints for consistency among routes (REST = nouns, Java = verbs).

2. Expand the component library


<dtv:flip>
<dtv:carousel>
<dtv:infinitegrid>
dtvModule.apiServices

<dtv:optionbar>
<dtv:filterbar>
<dtv:slidepanel>
<dtv:filterlist>

...and more...

3. test mobile performance


I anticipate lots of changes necessary for tablets and phones. The design is incredibly memory-and-GPU heavy, with dozens to hundreds of images having nested 3D and 2D transformations applied in animation cycles.

We should start testing on oddball machines (slow laptop, small screen, IE8) and mobile devices as soon as possible to spot problems early.

Our solution will likely be a mix of alternate stylesheets and adaptive component behavior for weaker clients.

4. test server performance

With a single, complex page (like Browse), we can take a good measurement of server performance.

Since node scales through the process model, performance characteristics and infrastructure requirements can be extrapolated from a real test on a small cluster.

Set config.local to realistic deployment settings
(caching on, redis sessions, etc).

Consider using stubbed Java service responses with an artificial, configurable delay to see what impact they will have on performance.

risk factors


  1. Mobile first?
  2. Testing requires discipline
  3. Don't underestimate scope

1. mobile first?


Theoretically this design is 'mobile first,' but that hasn't been my experience. It's actually uncomfortably large on a 13" Macbook Air.

It doesn't seem like we have a realistic test platform of devices to design and debug on... the vast majority of testing is on heavyweight hardware.

It's easier to move from mobile -> desktop than vice-versa. Nested modals, hover states, and target zones that do more than one thing are very painful on a touch device.

2. testing requires discipline


Right now, we have the beginnings of a unit test suite and an integration test suite.

This will be a powerful tool that grows exponentially more valuable as the project gets larger and more complex.

However, it requires discipline to maintain a test suite. In my experience, as soon as a small handful of pull requests are approved without passing tests and without added tests, the test culture is abandoned forever.

3. don't underestimate scope


The devil's in the details. There are all sorts of non-trivial details that need to be worked out, and more will appear every day:

  • client-side asset versioning for strong caching
  • dev/staging/prod modes with asset build configurations
  • pre-rendering client-side templates for crawlers
  • responsive solutions for CSS and JS
  • cross-browser and cross-device testing
  • continuous integration and seamless deployment

dtv-wrapup

By hunterloftis

Made with Slides.com

dtv-wrapup

  • 1,035

More from hunterloftis