pixelhandler.dev

EmberConf 2015 - March 4th (day 2)

Billy Heaton 15 min read
Ember.js Conference

Closing Keynote: Chris Eppstein, 5:30 — 6:00 PM

  • @chriseppstein, maintenance of @Compass; works at LinkedIn

Storytime, Once upon a time…

  • Rails Conf in Portland years ago
  • Sass, had a few patches
  • Have you heard of SproutCore? It's gonna be hard, frameworks are hard to maintain

Ruby Sass in the JS World

  • Hasn't been fun
  • Announcing: "Eyeglass", distribute SASS extension as NPM modules for LibSass (C++ implementation of SASS compiler)
  • LibSass is much faster than Ruby Sass
  • Compass is kind of "end of life" at this point, but it's not disappearing right away
  • Eyeglass, developer preview, is not a bunch of mixins, e.g. autoprefixer; get the extensions in an let you use them in the JS world

Community is You

  • It's what makes software great
  • Be excellent to each other, how hard is it just to be nice?
  • Actually it is hard, "Turn the other cheek." - Jesus H. Christ
  • "Don't be a Sasshole." - Chris Eppstein
  • JavaScript community: You're kinda of Jerks to each other
  • "You are not your OSS contributions" - Don't take it personal
  • Know when it's time to step away from the keyboard

Conundrum

  • How to compete without being negative
  • Attack their weaknesses but ignore their strengths - bad idea.
  • Respect your competitors
  • Learn how to disagree and be disagreeable the secret of getting along

Confidence

Is knowing you don't need to engage.

Why is Ember going to Win?

  • Leadership, Us, backwords compatibility, tooling

What does "Win" Even win?

  • Find a job you love and you'll never work a day in your life
  • If you use a framework you love you'll never work a day in your live
  • Congrats you may have already one
  • If winning means being #1; the default choice, support is way harder, community? good luck
  • Being #2 is the sweet spot, people pick you because your are a good fit
  • The community you create is more awesome if your people fit
  • Focus on your strengths
  • LESS kind of collapsed under its own community
  • Don't stop learning from others but don't view it as a competition
  • Do what you do because you love it.

Physical Design: Edward Faulkner, 4:45 — 5:15 PM

A talk about UX for the end users of our app, and for us developers.

  • Abstract - (Almost) infinitely Flexible
  • Physical - Constrained by Physics

Bring in constraints to our abstract applications the represent our physical world.

  • Material design, spec - check it out, kick the tires on how it works
    • "Without breaking the rules of physics."
    • "Motion respects and reinforces the user as the prime mover"

How does this fall into Ember's broader Architecture?

Animations and motion in general, in reaction to the user's input. They live in the gaps in between what was and what becomes.

Liquid-fire

https://github.com/ef4/liquid-fire

  • Version 1.0 - Coming soon
  • Showing off some animations in the EmberConf application
  • Liquid Outlet notices what is inside and manages changes / transitions
  • A Transitions module defines your animations similar to how the router defines routes
  • Goal Create extensible animations to share animations as Ember Addons
  • Liquid Fire organizes how you setup and when you call your animation library, firing off transitions e.g. before, after with the template content already positioned absolutely
  • Velocity.js is one recommended animation library that Liquid Fire can use to define modular animation and transitions
  • The animations are just functions you can receive arguments.
  • Each transition has an old and a new element.
  • Animation have a forward and reverse path to transition to your before and after states
  • The explode animation is pretty sweet, and the fly to is great
  • Tried out re-implementing the fly-to api with Web Animations API, instead of Velocity
  • liquid-with & liquid-each - helpers for adding before and after elements when your model/properties change
  • An animation (function) can have many constraints and is triggered when all constraints match

Perhaps checkout: http://miguelcobain.github.io/ember-paper/

Minitalks: Leah Silber, 4:00 — 4:30 PM

Sorry you had to be there :) nice variety of short talks on experimenting with Ember

Building Real-time Applications With Ember: Steve Kinney, 3:00 — 3:30 PM

@stevekinney | steve@turing.io

How I chose Ember:

  • Lazy Twitter: Ember.js or Angular
  • wykatz - Ember.js, Although I'm biased ;)

A Story about Web Sockets, about user sessions, GeoLocation, 3rd party Libraries

  • What is a Web Socket? RFC 6455, Duh.

Tradition: Request and Response cycle, but the server has to wait for a request, some clients may poll the server.

  • A Web Socket is a two-way Pipe
  • Can I actually Use WebSockets? YEAH, except the Opera Mini browser.
  • Lots of libraries to give you fallbacks to long polling, e.g. Socket.io, Faye

Demo of building a chat app

  • We need a server, Ok - A Web Socket server in 14 lines of code with Node.js
  • Ember allows you to build your application and the DOM becomes a representation of your application
  • ember generate controller websocket to create a controller, setup the socket on init
    • Create (un)subscribe handler and a send method
  • Use needs to utilize the websocket controller
  • Add an action to respond to user's submitting a message to the chatroom

You share the struggles of making a better app with the community

How to you bring the web socket behaviors and support into a service? search the forums, Oh there's Services, nice.

  • ember g service websockets then refactor the controller into a service
  • Instead of extending controller, extend Ember.Object
  • websocket: Ember.inject.service()
  • For Lulz bring in Socket.io with libraries on the client and server.
  • Server app can bind to events socket.on('message')
  • In the client app subscribe to the messages and broadcast messags

Let's play

http://bit.ly/jspoll | code at: stevekinney/emberconf-chat

Building Custom Apps with Ember Cli: Brittany Storoz, 2:15 — 2:45 Pm

@brittanystoroz

What were our needs? (Firefox OS Requirements)

  • Generage and validate a manifest file
  • UI components
  • publish to the marketplace

The above use cases make for a good use case for using EMBER CLI Addon

  • Demo: an EMBER CLI application, selecting timezones and local times

Walkthrough creating an Addon to make the app a Firefox OC app

Generate the Manifest (Creating blueprints for this purpose)

  • ember generate blueprint name-of-module
  • Generates files an folders, named the blueprint after the name of her app
  • In the blueprint's directory mimic the file structure of the app, including the manifest
  • Put some files into the public directory
  • The blueprint affords using variables to generate application code that ships as your addon
  • There are hooks to utilize, e.g. postProcessTree, runs at the end of the build process, right before the app is written to the dist directory
  • You can use that hook to mutate the variables in the blueprint from a config file, e.g. update the name and the version of the application in its manifest file
  • Not only make the bower package available but also use the package, using the included hook to call app.import()

UI Components

  • FxOS UI (Gaia): Building Components, a work in progress
  • bower install gaia-components/gaia-tabs
  • Setup the components (bower dependencies) and make them available to the consuming application, which needs to know it also requires the dependencies
  • Use the blueprint's afterInstall hook to add the bower package to the app
  • In the addon create an Ember.Component (with setup and teardown logic) then tell the consuming app to use that component, so in the app directory import the addon/component-name and export, now the app can use the component, it's registered in the app's container now.
  • Also add a template for the Component, in the demo a template was needed for the clock and timezone elements in the app

Validation and publishing

  • Adding commands, need finer controller for when things happen (jobs)
  • In the lib/commands directory create the command (name, alias, run method)
  • A command to validate the manifest file, create a command and let the app know that the command can be used
  • hook includedCommands require and return the imported lib/commands
  • ember fxos:validate & ember fxos:publish does the custom work needed!
  • A property of commands is availableOptions as options hash in the method, e.g. pass in a dist target, the production marketplace, sweet
    • App created, app ID, you can see it in the marketplace

Interaction Design With Ember 2.0 And Polymer: Bryan Langslet, 1:30 — 2:00 PM

Blur the lines between native and Web to create an immersive experience.

@blangslet shared a reel of integrations between Ember and Polymer, continuous flow in an app, giving users context clarity and focus

Also showing off great demos of using Ember and Polymer together. "Demo with Pirate Music" is awesome!

  • Demo App on github: blangslet/treasure-hunt
  • Champions Web Platform nicely running inside native app built with Cordova iOS

Dream Stack

  • Ember for routing
  • Polymer layout grid, flexbox
  • Ember Components + Polymer
  • Polyfills
Ember going forward
  • Use tomorrows tech today

Web Components

  • Extend the browser itself
  • Encapsultation
  • Declarative
  • True reusability and portability
Ember vs Polymer Use Cases
  • Developer productivity
  • Conventions and developer happiness
  • Brilliant community
  • World class router
  • Polymer pushing the spec forward
Web Animations API
  • Best of both CSS and JavaScript animations
  • Run outside the main thread

The Web Platform

  • Turmoil in the Web landscape
  • Never underestimate the underdog, "Cool Runnings"
  • I'm a huge believer of the Web, everything has to be connected to the Web
  • Web Performance is on the rise, getting closer to native performance, still a ways to go, but rendering engines are getting faster
  • A lot of heavy lifting is moving to the client (JavaScript runtime)
  • Yes Native apps are fast, but what about the best tools available for the job, Web tools are getting awesome!

A Path forward, stand on the shoulders of giants, Ember, Polymer, Web Components, etc.

Ember-Flow

A shift in adding animations and transitions to Ember Apps

Growing Ember One Tomster at a Time: Jamie White, 11:30 - 12:00 PM

  • Ember London is growing 600 members on meetup.com, 2 events a month

The Tomster wasn't overly done, there are still choices to be make and things you can contribute to.

The code is a snapshot of the best ideas in our community, we're trying to create the best possible home for our idea

  • Community design and API design are the same.

Roles in the Community

  • organizer, documenteer, contributor, mentor, student, explorer, critic, etc.
  • loads of roles inside and outside the community

Community Interface

Is a README enough, How about a website

A consistent visual language build trust in your community, setting expectations across projects

Once an established visual language is set it becomes a tool for contribution, e.g. the redesign of Ember community pages (easier to find a meetup location)

Analogy

Consider promises, thing about other things while you know that asynchronicity is taken care of

Language - words stick

"Stability with out Stagnation" - terse and describes a larger idea

How about reframing the term 'hack night' to 'bring your own project' its a vocabulary that is more open to women and men.

How did a tech community become this vibrant?

design and engineering (the community that is not the software)

The Tomster, an illustration to characterize the project, developer friendliness and productivity

The Ember release cycle is inspired but the Chrome build release cycle but has no characterized illustation, (Is this for me?)

You can affordable commission and license a Tomster for your community!

Doing the right think should be easier than doing the wrong thing

  • Ambition is not normally aside the concept of Friendliness, yet you can put a Tomster face on Ambition

Aligning Ember with Web Standards: Matthew Beale: 10:45 - 11:15 AM

Ember community survey

Standards are a two-way street

Strategy for adopting new features of JavaScript

  1. provide legacy wrapper
  2. use syntax as a carrot
  3. private use can start sooner

It's not a straight to adopt pure ES Classes as some concepts still need to be supported, e.g. calling this._super

For example: Decorators

class Car {
   attr('attachThings')
}

Ember's Object Model

Process of change to Ember's primitive for Objects

  1. stable
  2. a good pattern
  3. implemented correctly
  4. implemented performantly

Three new tools…

Classes

Gotchas:

  1. new syntax
  2. super semantics change
  3. mixins
  4. setUnknownProperty
  5. merged /concat
  6. transpiler output?!

This is not the first time we had to move across standards

"Polyfill" - Remy Sharp (inspired by spackle to fill the nail holes in your wall)

  • Some things can be pollyfill'd and some new spec cannot
  • Transpile that new ES2015 code with Babel (not born to die)

Standards…

  1. are portable
  2. reflect best practices
  3. endure

Participants win!

  • Promises and ES6 modules are things the Ember picked up early

Standards Story

  • WHATWG + W3C
  • TC39 + Ecma International
  • In 2008 WHATWG given the task of creating HTML5, realized HTML would never be done
    • Moved to a new model… A Living Standard, increments over time
  • ES3 (used in IE8), then there was an attempt to create ES4 but that failed
    • So a few years later and + Web 2.0 they came up with ES5
  • Then A new giant release for ES6, instead now we have ES2015, moved from a giant hover boat approach to a sailboat, sailing into 2015, then 2016, etc.

Process for JavaScript releases

  1. Strawman
  2. Proposal (polyfills)
  3. Draft (experimental),
  4. Candidate (Compliant)
  5. Finished (Shipping)

Javascript will come out every year! (try it out early Babel as es6ro5)

Fault Tolerant UX: Dan Gebhardt, 10:00 - 10:30 AM

Links

Ember Orbit

  • EO.Store - Synchronous and Asynchronous interfaces
  • EO.Model - informs Orbit of the Schema
  • Orbit Sources DRIVE model state
  • Client-first development
  • Pluggable Sources
  • Data synchronization
  • Editing Isolation, Editing Context
  • Undo / Redo

Orbit.JS and JSON Patch

  • Transformable and Requestable interfaces
  • Synchronous Event Handling - Promise aware (async blocking, sources opt-in)
  • Non-Promise aware (non-blocking, sources opt-out of promise)
  • Connect events between Sources
  • Memory, Local Storage, JSON API, + More +
  • Orbit will be JSON API compliant, v 1.0 of JSON API tomorrow

Engineering Fault Tolerance

  • Ember provides Simple Elegant Patterns for building a Consistent UX
  • Ember Data: Consistent + Durability
  • ACID is hard: Atomic consistent Isolated Durable
  • Rethink Assumptions and Primitives
  • Disparate Sources
  • Disparate Data
  • Common Interfaces
  • Normalized Data
  • Evented Connections

Applications should try to Provide a forgiving UX, Please :)

  • Persist transient data, while still being edited, e.g. editing a comment in a code review
  • Undo and Redo, oops didn't mean to do that, e.g. Gmail can undo
  • Provide offline support, applications which are editing data in isolation, no immediate response from server is required, so your user should not be blocked from editing.
  • Asynchronous non-blocking interface, not blocked by request/response cycles from the server.

Applications MUST NOT Violate the Rules of Transactional UX, OR ELSE

  • Don't break your users' trust

Shield our users from environmental stresses that our application encounters

  • A transactional user experience, like a database has to reliable in committing data: ATOMIC
  • Atomic means "all or nothing"
  • A transaction should be consistent, it should move across all states - partials should not be come inconsistent
  • Transaction should be isolated and allow concurrent changes
  • Submit and cancel should just work, the change is isolated from the rest of the application, the change is done in isolation, separate from the canonical represtation

Fast forward to today

  • We're building complex systems and launching them into users browsers
  • Our Ember Apps allow users to navigate quickly and efficiently
  • Fault Tolerance in our environment can become stressfull - Browser wackiness
  • Plus some very optimistic users

Day tells the story around the beginning of his career working on ships.

  • Regulatory organizations must certify a ship, its controls and operational stability, etc.
  • Left that work for working on the internet in the 90s
  • Serious engineering and fault tolerance was expected on the server side
  • But the client side was much less serious.

About the Author

Billy Heaton
Billy Heaton

Software engineer with two decades of experience who favors Ruby and JavaScript to build web applications