It’s late and I’m walking back from the athletic complex to my car with my son, I say, ‘Nice job, buddy, you went hard,’ but my voice cracks …. I’m hoarse from yelling ‘Man up, get back, find your man, Now push it! Get your head up, see your teammates!’ as I attempt to teach a group of fourth graders how to both apply a full court press and break it … managed chaos at its best. I sit down in the front seat, and take a deep breath. Man, there is nothing like an evening of high velocity basketball after a long day of high velocity software. Only problem is tonight we lost, and I hate losing.

Den, like any other early stage startup, velocity is king. In that regard, we are much like most startups, we build business requirements fast and at the highest quality possible.

In this highly competitive field, we are here to win. If building quality software, fast, is winning, concepts like technical debt, communication bottlenecks, monolithic architectures, and analysis paralysis are losing. As I drive home, I reflect on the last four whirlwind months. So far, at Den, we have been winning, we’ve built an amazing team and tech stack and our business partners are super pleased and excited. And most importantly, we have done it really fast.

So, how have we come this far this fast in building a high quality, cross platform mobile application and scalable microservice architecture in under six months? You may be surprised, but I feel it has more to do with the softer side of the industry than it does with the technical (that’s a future article).

1. We’ve Maintained a Strong Relationship between Business and Engineering

It starts with a relationship between our business partners built on a foundation of trust and engagement. We don’t look at our relationship with business as master-servant, we see it as an equal partnership, and I see myself as a Product Owner with an engineering background. Each of our engineers are future users of our application and are therefore emotionally invested in its success.

Also, my ability as CTO to communicate clearly our technical hurdles, skill set challenges, gaps in requirements, etc. is paramount to our success. For me, it is important to communicate challenges without making excuses. Every engineering decision that is made sets off a series of consequences, both good and bad. These trades will always come with negative consequences, depending on one’s perspective. A great Tech Fellow, Sam Price from USAA once told me, “Every decision you make will be wrong.” The key is making quick yet sound decisions, living with the outcomes, and communicating the trades as best you can to maintain trust between you and business partners.

It is also important to help engineers with understanding that a quick, smart decision must be made. Agree to disagree, but commit to the task, and help all understand that the decision is not necessarily short-sighted, and there will always be some negative consequences, some unseen and some foreseen. At the end of the day, analysis paralysis is not an option.

2. We’ve Understood and Balanced ‘Short term’ and ‘Long term’ Velocity

In our discussions, we are constantly differentiating between ‘short term’ and ‘long term’ velocity. Often, in past experiences, naive business partners press for decisions entirely based on short term velocity. At Den, as we rapidly develop, and respond to dynamic business needs, we leverage our collective experience to make sound technical decisions that positively impact our long term velocity. In other words, we want to make sure that later phases are not a nightmare of correcting all of the technical debt accumulated getting to MVP. Later development then becomes slow and painful, engineers get frustrated with the mess, business gets frustrated with the speed. So, we constantly balance sound architectural decisions that will impact our long term velocity with short term velocity wins.

When discussing with our business partners, the language we use to describe those decisions matters. If we trade a 2 hour task for an 8 hour, but it saves us 40 hours down the road when we need to pivot, we have made both a sound business and technical decision.

One key challenge is having the experience to anticipate those pivot points and understand all the technical implications behind the pivots, and very few can go at this alone. Which brings me to building a team of leads that possess, or have the potential to possess, all of the mixture of hard and soft skills I am alluding to.

3. We’ve Invested in Skillz

Nothing impacts velocity more than the individual inability of the engineer to achieve tasks. This manifests itself in a blend of intelligence, experience, creativity, communication skills, passion for the product, work ethic, attention to detail, empathy for others, and the ability to suppress one’s ego for the good of the team (but, more on that later).

Stephen Curry is perhaps one of the greatest modern examples of a technician that has elevated his status in his field through precision practice, time commitment, and attention to detail. We refer to him often in metaphor. When I played college basketball, decades ago, I had some great mentors. I used to shoot thousands of jumpers on Saturday mornings with Ricky Pierce and Avery Johnson. That was my first introduction to the insane amount of time it takes to become a professional. Being great is no accident, and it doesn’t stop until you retire. As CTO, the first 6 hires on our team had to be better than myself, and they had to be equally obsessed with building great software. All in all, the collective work ethic of the Den team is more than I have ever seen in any environment I have worked in.

As a management team, we also allow time, and invest in, our engineers. We encourage the exploration of new technologies and budget for attending conferences of their choice. In our first four months alone, we have attended WWDC, Dockercon, and Gophercon.

4. We are a Team

At Den, we have built a world class ‘team,’ not a group of great individuals. We are small, yet high performing, and we like it that way. High velocity and winning have no room for egos and drama. Each time we add a new personality, there is a chance we could rock our chemistry, so, we stay highly selective.

It also doesn’t hurt that the three founding members of Den are all former Division I collegiate athletes, having had the tenants of successful teams drilled into our heads early in life. So with that as a foundation, we were very calculated in going after the right mix of talent. All of our hires were from former organizations we had worked with in the past, or came highly recommended by a trusted colleague. The outcome of choosing the right mix is what enables the blending of our collective experience and skill sets, resulting in our ability to make sound decisions as a team.

Each member of our team is truly great at and passionate about what they do, and the working environment we have created is giving them the opportunity to get even better at a rapid rate.

Stay tuned for the technical side of our velocity strategy, as I map out our decisions from building our mobile application with Ember Cordova rather than React Native, why we chose CircleCI over Codeship, Quay as a container registry, and our combination of Node.js and Go services, thoughts about our Domain driven Microservice architecture, to details about using Terraform and Kubernetes on AWS.

speak at FITC 2015 in Toronto

The culture at frog is certainly not for everyone, but for me, someone who has always been comfortable with creating my own path, it was in many ways ‘carte blanche’. The catch at frog is that, by design, you won’t be given much direction; you are expected to create and drive the direction. When I joined frog, my goals were to speak and write as much as I could while I focused on producing as high a volume of quality technical deliverables as I could for our clients. And in almost every case, while leading ‘greenfield’ projects for fortune 200 companies, I was able to stop and start over on each project building upon the momentum and experience of the previous endeavor. All of that real world learning fueled my writing and speaking. It was exhausting, in the good kind of way.

frog, a product suite and engineering team that was being challenged to scale to millions of users. I knew that their challenge would help me grow too, and fill in even more gaps.

Now, production applications weren’t new to me when I joined InVision, but in some ways startup culture and the smaller engineering team was. While in some of my previous roles, I would be responsible for a small sliver of a very large pie, here my slice would be much larger, and the red tape would be few and far between. I could recommend an approach, build it, and deploy it within three days as compared to three months or sometimes even three years.

Another interesting pivot for me was to completely walk away from the Ember community, and dive into Angular and React/Flux, as if I was disgruntled with Ember or something. On the contrary, my first 3-4 months at InVision, I spent my time retro fitting the existing application with tooling that ember-cli provides out of the box. And, as Ember 2.0 is released, my appreciation for the work that community is doing is even greater than it was before. For now, I watch from afar, as I’m not actively developing an Ember app. On the contrary, I am much closer to the Angular and React communities than I was before, which makes for a nice trade off.

I have to say that working at InVision has been an amazing experience. We are a 100% remote team using the latest and greatest of tooling to keep up with each other and our software. Our software continues to evolve as does our DevOps automation, deployment models, code quality and our architecture. Not only that, we have been working night and day to build our teams with the best and brightest talent we can find. The company has tripled in the 6 months since I have been here. It has been an amazing whirlwind of growth.

I am currently focusing on leading the Application Core team. This was the challenge I was looking for in that I needed to learn the breadth of the product suite’s codebase before I could formalize a plan for evolving the architecture for scaling, addressing performance issues and technical debt, and improving developer workflow and code hygiene. Our application core team is now around 10 engineers and testers, and we begin to see the fruits of our labor. We are still growing and searching for great talent, feel free to reach out if you are interested.

Outside of architecting and developing complex web apps during my day job at frog design, I spent a good part of 2014 finishing up Building Web Apps with Ember.js, teaching Ember.js workshops, and giving a talk entitled: “The Art and Science of Shipping of SPAs with Ember.js.”

Building Web Apps with Ember.js explains my stance for the last couple of years:

Since 2009, I have worked on numerous applications using Backbone, Angular, and Ember. But today, I often recommend Ember.js to the clients I work with. This is primarily due to the fact that the conventions support well-known web application development patterns that I have custom written or pieced together from multiple open source libraries. Here, are the high level concepts that, in my opinion, make Ember so valuable:

• Ember’s object model supports a classic and well understood, object-oriented pattern of class inheritance through extend, object initialization, getters and setters, and class monkey patching.
• Ember models, controllers, and components extend the Object class, which ensures that these objects inherit Ember’s powerful default data binding.
• The router supports complex nesting for URL-driven applications that manage application state in a conventional way that can be understood by those with web-server-routing backgrounds.
• Recently, build, workflow, and testing tools in Ember have matured and become intuitive.
• Ember’s only dependencies are on jQuery and Handlebars.js, two very wellknown and documented libraries.
• Finally, the community is vibrant, passionate, and extremely active.

What’s Next?

Most recently, I find myself moving into a new phase that mirrors the needs and concerns of the clients I interact with on a daily basis: navigating the SPA landscape and making future friendly decisions based on the complex solutions matrix that is now Ember 2.0, Angular 2.0, and current React/Flux.

My latest talk: SPA 2.0: The latest in JavaScript frameworks will address these questions:

• What does the future hold for the building of complex applications on the Web Platform in 2015? How do we manage the complex SPA landscape, and help our clients make future friendly architectural decisions?

• Will an Angular 2.0 breaking rewrite send devs running for something better? Can React/Flux community offer a complete application framework solution for complex applications? Will Ember continue to evolve into a lighter framework that can shed it’s ‘monolithic framework’ reputation?

• As the Angular and React communities adopt the Ember Router and the Ember community is inspired by React’s Virtual Dom to take advantage of it’s existing under utilized view graph, the communities are adopting the best of each other. In what other ways are the individual framework communities learning from each other?

• Will native, cross browser web components become a reality? What is the IE roadmap in regards to custom elements, HTML templates, HTML imports, and shadow DOM? Will we begin writing web components in Ember without the use of handlebars syntax?

• Will functional reactive ‘stream’ patterns become common place with better integration into frameworks, as promises did in 2014?

• With ES6 modules ( and transpiler build steps ), as practitioners can we finally lay the JS module debacle to rest? Do Isomorphic JS architectures still make this a challenge?

SPA 2.0 Topic Areas

Here, are the areas my talks will focus on in 2015:

• Framework Maturity and Stability
• Developer Ergonomics, Tooling, and Front End Ops
• View Performance and Mobile
• Async Router
• Data Binding (1-way , 2-way use cases)
• ES6 modules
• Web Components
• Community and Documentation
• Release Cycle
• Client Side Data Stores
• Services and JSON Specifications

HTML Hacks training content. If you or your company need training, give us a shout.

Here is a brief outline of the workshop:

Introducing Ember.js

Getting Started with the Starter Kit

Ember Inspector Overview

Ember Object Model

• Application
• Object Model, Inheritance, Getter and Setters, init, and .super
• Object Model – Computed Properties
• Object Model – Computed Properties w/ @each
• Object Model – Observers
• Object Model – Bindings
• Object Model – Re-Opening Classes
• Object Model – Mixins
• Object Model – Enumerables

In late April, I took my Ember.js talk to Louisville, Kentucky for the CodePaLOUsa conference.

Doc Crow’s Southern Smokehouse and Raw Bar’s BBQ and Bourbon menu. I highly recommend it for anyone in the area trying to find authentic, local fare.

During the day, I also listened to some great talks from @sireb and @robtarr.

My presentation focused on demoing the latest versions of RockNRollCall demo application, the source code for my upcoming book, OReilly’s Building Web Apps with Ember.js.

Malmö was also a pleasure to experience, and as you might imagine, the people of Sweden were very welcoming. One of the highlights for me was the speaker dinner at the Malmö City Hall, originally constructed in the Middle Ages. On a side note, I finally had a chance to meet and have dinner with Douglass Crockford, a long time inspiration and virtual mentor, who was in town to give the keynote on Managing Async with RQ.

HTML5 Hacks from Øredev Conference on Vimeo .

In 2014, I’m retiring the HTML5 Hacks talks, to begin focusing solely on Single Page Application development in 2014. My hope is to kick out an early release of Building Web Apps with Ember.js very soon, and finish the book in early 2014. After that I’ll be in Louisville, KY at Code PaLOUsa to continue the Ember.js roadtrip.

author books on the subject, blog, and speak at conferences as often as I can.

I work for frog, a product design firm, that for the last forty years has been helping increase the profiles of brands like Sony and Apple through iconic design.

I work within a culture that has deep roots into the Maker Movement; A culture that was making before the Maker Movement was cool, the “original makers” if you will. Written upon our walls and slide decks is the tag, ‘Love What You Make’, and as you might expect many of the frogs that sit around me are craftsfolk, DIYourselfers, and tinkerers. It is not uncommon to see a flying quadcopter, a mesh sensor network of Arduinos, 3D printed prototypes, explorations in next generation gesture with the Leap Motion and Kinect, video production, motion studies, 3D modeling, along with the standard artistic mood boards and web and native mobile application wireframes. Let’s just say there is no shortage of creativity across every medium imaginable.

Sharing My Craft with my Children

Tulsa Mini Maker Faire’s Scott Phillips to put together the closing keynote at the 200ok conference .

JavaScript Makers: How JS is Helping Drive the Maker Movement

The 200ok conference is on track to become Oklaoma’s premier web conference attracting a sold out crowd of web professionals from all over Oklahoma and the neighboring states. Going in, I felt as though I knew my audience well. In other words, if I spoke to them about languages they would understand, JavaScript and HTML5, my message would easily resonate. I also knew that given their location, Tulsa, OK, a presentation that touched upon work life balance and family values would immediate strike a chord as well.

So in the spirit of authenticity, I pretended as if getting prepared for a closing keynote dependent on hacked together hardware and software demos wasn’t challenging enough; I made the decision to include my 6 year old son, Carter with a flying drone and a custom configured Minecraft server accessible over conference wifi. I knew this would ensure that the presentation dangled on the brink of disaster, mirroring the chaotic reality of both open hacking and parenting.

My thinking was that a presentation on this topic should be authentic, and reflect the reality of my proposition, not be an ivory tower, academic/authoritative talk about how to share your craft with your children. I also made sure to not prep Carter. With a loose structure in place, we took the stage and worked our way through a story that consisted of 12 open software and hardware demos that showcased JavaScript as a primary scripting language, and a table full of hardware that ranged from a drone, a dissected wifli helicopter and erector set, a leap motion, and numerous prototyping boards.

Here are some of the highlights:

JavaScript and Prototyping Boards

Earlier this year I did a presentation at HTML5.tx that focused on building an Internet of Things with JavaScript and various open hardware prototyping boards such as Arduino, BeagleBone, and the Raspberry Pi. It was in that talk that I made a connection that eventually led to an introduction to Luke. So, given that the HTML5.tx content was of interest I started the presentation with a demo of the Arduino, Johnny Five, the original Beaglebone and BoneScript.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

  ...

  require('bonescript');

  ledPin = bone.P8_3;
  ledPin2 = bone.P8_4;

  ...

  app.post('/motion', function(req, res, next) {

    console.log(req.body['eventType']);

    res.send('Motion data collected for '  + req.body['eventType'] + ' event');

    if (req.body['eventType'] == "motionstart"){
      digitalWrite(ledPin2, HIGH);
    }
    else if (req.body['eventType'] == "motionend") {
      digitalWrite(ledPin, HIGH);
    }

  });

Nodecopter and the Leap Motion

I started with the basics of the node-ar-drone module:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

  var arDrone = require('ar-drone');
  var client  = arDrone.createClient();

  client.takeoff();

  client
    .after(7000, function() {
      this.animate('flipRight', 1000);
      this.animateLeds('blinkRed', 5, 2);
    })
    .after(3000, function() {
      this.stop();
      this.land();
    });

Later, a crowd favorite was mapping the gestures from the Leap Motion to the Parrot AR drone, so that a one finger clockwise gesture triggered a nodecopter takeoff. A counter clockwise gesture then landed it. I was able to put this together using the leapJS and node-ardrone node modules, based on some initial hacking by Markus Kobler, where he pulled this off at a Nodecopter London event.

I had a great time presenting at HTML5.tx 2013; here is an embed above of the slide deck. I should have the trailr node module in a presentable format soon and I’ll tweet its inclusion in NPM. I have a placeholder here: trailr at npm

I also pushed out the ver.1 trailr-admin UI here: trailr-admin.herokuapp.com

Most of the demos are included in the nodejshacks-emedded repo here: https://github.com/nodejshacks

Very soon, initial documentation will be available at: trailr.io

mitchfincher.blogspot.com

HTML5 Canvas View

mitchfincher.blogspot.com

For this hack we will use IndexedDB to store milestone objects for a calendar application. The UI will provide a simple means to create a new milestone and provide a title, start date, and end date. The calendar will then update to show the contents of the local data store. Figure 6-8 shows the result.

Figure 6-8. FullCalendar.js and IndexedDB

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

<form> <fieldset> <div class="control-group"> <label class="control-label">Add a Milestone</label> <div class="controls"> <h2>New Milestone</h2> <input type="text" name="title" value=""> <input type="text" class="span2" name="start" value="07/16/12" data-date-format="mm/dd/yy" id="dp1" > <input type="text" class="span2" name="end" value="07/17/12" data-date-format="mm/dd/yy" id="dp2" > </div> </div> <div class="form-actions"> <button type="submit" class="btn btn-primary">Save</button> <button class="btn">Cancel</button> </div> </fieldset> </form>

The calendar is provided by FullCalendar.js, a fantastic jQuery plug-in for generating robust calendars from event sources. The library will generate a calendar from a configuration object and a simple div.

1

<div id='calendar'></div>

And we can’t forget to include a few dependencies:

1
2
3
4
5
6

<link href="../assets/css/datepicker.css" rel="stylesheet">
<link href="../assets/css/fullcalendar.css" rel="stylesheet">

<script src="http://code.jquery.com/jquery-1.7.1.min.js"></script>
<script src="../assets/js/bootstrap-datepicker.js"></script>
<script src="../assets/js/fullcalendar.min.js"></script>

To improve the user experience, we will also include date pickers for choosing the dates within the form fields for start and end dates (see Figure 6-9).

Figure 6-9. Date pickers

1 2 3 4

$(function(){ $('#dp1').datepicker(); $('#dp2').datepicker(); });

The Milestone IndexedDB

Now we will set up a global namespace to hold our code, and set up a public milestones array (within the namespace) to hold our milestones temporarily while we pass them between our database and the FullCalendar API. This should make more sense as you continue to read. While we are at it we will need to normalize our indexedDB variable across all of the vendor-specific properties.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

var html5hacks = {};

html5hacks.msArray = [];

var indexedDB = window.indexedDB || window.webkitIndexedDB ||
                window.mozIndexedDB;

if ('webkitIndexedDB' in window) {
  window.IDBTransaction = window.webkitIDBTransaction;
  window.IDBKeyRange = window.webkitIDBKeyRange;
}
Now we can begin to set up our database:
html5hacks.indexedDB = {};
html5hacks.indexedDB.db = null;

function init() {
  html5hacks.indexedDB.open();
}

init();

This will obviously fail for now, but as you can see the initialization begins by calling the open() method on an html5hacks.indexedDB. So let’s take a closer look at open():

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

html5hacks.indexedDB.open = function() {

  var request = indexedDB.open("milestones");

  request.onsuccess = function(e) {
    var v = "1";
    html5hacks.indexedDB.db = e.target.result;

    var db = html5hacks.indexedDB.db;

    if (v!= db.version) {
      var setVrequest = db.setVersion(v);
      setVrequest.onerror = html5hacks.indexedDB.onerror;

      setVrequest.onsuccess = function(e) {
        if(db.objectStoreNames.contains("milestone")) {
          db.deleteObjectStore("milestone");
        }

        var store = db.createObjectStore("milestone",
          {keyPath: "timeStamp"});

        html5hacks.indexedDB.init();
      };
    }
    else {
      html5hacks.indexedDB.init();
    }
  };
  request.onerror = html5hacks.indexedDB.onerror;
}

First, we need to open the database and pass a name. If the database successfully opens and a connection is made, the onsuccess() callback will be fired.

Within the onsuccess, we then check for a version and call setVersion() if one does not exist. Then we will call createObjectStore() and pass a unique timestamp within the keypath property.

Finally, we call init() to build the calendar and attach the events present in the database.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

html5hacks.indexedDB.init = function() {

  var db = html5hacks.indexedDB.db;
  var trans = db.transaction(["milestone"], IDBTransaction.READ_WRITE);
  var store = trans.objectStore("milestone");

  var keyRange = IDBKeyRange.lowerBound(0);
  var cursorRequest = store.openCursor(keyRange);

  cursorRequest.onsuccess = function(e) {
    var result = e.target.result;

    if(!result == false){

        $('#calendar').fullCalendar({
          header: {
            left: 'prev,next today',
            center: 'title',
            right: 'month,agendaWeek,agendaDay'
          },
          weekmode: 'variable',
          height: 400,
          editable: true,
          events: html5hacks.msArray
        });

      return;

    }else{

      console.log("result.value" , result.value);
      buildMilestoneArray(result.value);
      result.continue();
    }
  };
  cursorRequest.onerror = html5hacks.indexedDB.onerror;
};

At this point we are poised to retrieve all the data from the database and populate our calendar with milestones. First, we declare the type of transaction to be a READ_WRITE, set a reference to the datastore, set a keyrange, and define a cursorRequest by calling openCursor and passing in the keyrange. By passing in a 0, we ensure that we retrieve all the values greater than zero. Since our key was a timestamp, this will ensure we retrieve all the records.

Once the onsuccess event is fired, we begin to iterate through the records and push the milestone objects to buildMilestoneArray:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

function buildMilestoneArray(ms) {
  html5hacks.msArray.push(ms);
}
When we reach the last record, we build the calendar by passing a configuration object to fullCalendar() and returning:
        $('#calendar').fullCalendar({
          header: {
            left: 'prev,next today',
            center: 'title',
            right: 'month,agendaWeek,agendaDay'
          },
          weekmode: 'variable',
          height: 400,
          editable: true,
          events: html5hacks.msArray
        });

      return;

Adding Milestones

Now that we are initializing and building our calendar, we need to begin adding milestones to the database via the form. First let’s use jQuery to set up our form to pass a serialized data object to addMilestone() on each submission:

1
2
3
4
5
6
7

$('form').submit(function() {

    var data = $(this).serializeArray();

    html5hacks.indexedDB.addMilestone(data);
    return false;
  });

Now let’s submit a few events and then view them in the Chrome Inspector to ensure they are there (see Figure 6-10).

Figure 6-10. Viewing milestone objects in the Chrome Inspector

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

html5hacks.indexedDB.addMilestone = function(d) { var db = html5hacks.indexedDB.db; var trans = db.transaction(["milestone"], IDBTransaction.READ_WRITE); var store = trans.objectStore("milestone"); var data = { "title": d[0].value, "start": d[1].value, "end": d[2].value, "timeStamp": new Date().getTime() }; var request = store.put(data); var dataArr = [data] request.onsuccess = function(e) { $('#calendar').fullCalendar('addEventSource', dataArr); }; request.onerror = function(e) { console.log("Error Adding: ", e); }; };

We established our read/write connection in much the same way as our html5hacks.indexedDB.init(), but now, instead of only reading data, we write a data object to the data store each time by calling store.put() and passing it data. On the onsuccess we then can call fullcalendar’s addEventSource() and pass it the data wrapped in an array object. Note that it is necessary to transform the data object into an array since that is what the FullCalendar API expects.

Here is a brief summary:

1 Device Access Within the Browser

The client gets smarter.

JavaScript Device APIs continue to evolve, allowing more access to device hardware, services and applications such as the camera, microphone, system sensors, native address books, calendars and native messaging applications. We will explore examples utilizing GeoLocation API, and Device Orientation.

2 Client Side Processing w/ Background Threads

The modern web browser’s runtime is a single threaded, event loop. Asynchronous programming models, reactionary systems design actually benefit from this architecture. Maturing interpreters improve performance. Web Workers API enables background threads in the browser, making heavy computations realistic.

So, the client gets more powerful, and becomes an application development evnvironment. We will explore Web Workers processing heavy computations without blocking the UI for further user interaction.

3 Device Detection and Descriptors / Adaptive Frameworks

Responsive Web Design is great, but it often isn’t enough for larger applications, and applications that need to reach a highly fragmented device market. Adaptive frameworks use DDRs (Device Description Repositories)

We will explore a framework that mixes the best of Responsive with the best of Adaptive: responderJS.

4 HTML5 Connectivity Revolution and HTTP 2.0

Peter Lubbers coined the term, HTML5 Connectivity Revolution, to describe the next level, web network technologies such as: Web Sockets API, XHR2, Event Source and Server Sent Events, SPDY, CORS.

Engage in a demo of robodeck, a Web Socket driven Collaborative presenations framework.

5 Single Runtime, Shared Syntax … the right way

Node.js has enabled the same language, single runtime. But, the paradigms are still quite different. Node streams, inspired by Linux pipes, make IO easy and intuitive. Explore pipe(), pump(), and events in Node streams.

Solutions like Browserify, help bring Node.js libraries and NPM dependency management to the browser. Next up, Domnode, wrapping common, client-side, I/O bound APIs (XHR, SSE, WebRTC, etc.) in Node streams syntax.

6 Embedded JavaScript

With Node.js, Angstrom Linux, and cloud document stores like MongoDB, the server is now embedded in the microcontroller client.

We will explore Arduino wrappers, and Node.js running on the Beaglebone from Texas Instruments.

The combination of Linux and JavaScript open worlds of opportunity.

Here is the node.js server used on the Beaglebone in the demo: beagleserver. The Johnny Five code is located here: node-embedded

In this hack we will explore hosting a web font on a cloud drive. In order to do so, we will learn how to configure an Amazon S3 bucket to accept requests from other domains.

If you are not already familiar with web fonts and @font-face, refer to Hack #12.

In the next section I provide a bit more background on Amazon S3 and the same origin policy, before we get into the details of CORS.

What Is an Amazon S3 Bucket?

Amazon S3 (Simple Storage Service) is simply a cloud drive. Files of all kinds can be stored using this service, but web application developers often use it to store static assets such as images, JavaScript files, and stylesheets.

For performance improvements, web developers like to employ Content Delivery Networks (CDNs) to serve their static files. While Amazon S3 is not a CDN in and of itself, it’s easy to activate it as one by using CloudFront.

A bucket refers to the directory name that you choose to store your static files. To get started let’s set up an account at Amazon and navigate to the Amazon Management Console; see Figure 9-21.

Figure 9-21. S3 Management Console

http://en.wikipedia.org/wiki/Same_origin_policy

As stated in Wikipedia’s definition, the same origin policy is a good thing; it protects the end user from security attacks. But it does cause some challenges for web developers.

This is where CORS comes into the picture. CORS allows developers of remote data and content to designate which domains (through a whitelist) can interact with their content.

Using Web Fonts in Your Application

There are a number of ways to use a web font within your web pages, such as calling the @font-face service, bundling the font within your application, hosting the web font in your own Amazon S3 bucket (more on this later), or converting the file to Base64 and embedding the data inline in a data-uri. By the way, the last technique is similar to the one outlined in Hack #13.

Each of these techniques has limitations.

• When calling the @font-face service you are limited to the fonts within the particular service’s database.
• Bundling the font within your application does not make use of HTTP caching, so your application will continue to download the font file on every page request. Furthermore, you cannot reuse the font within other applications.
• Hosting the font in an Amazon S3 bucket works great, except with Firefox, which enforces the same origin policy on all resources. So the response from the remote server will be denied.
• Converting the font to Base64 adds additional weight to the stylesheet, and does not take advantage of caching.

An exploration into the different types of web fonts is beyond the scope of this hack, so I will assume that you have already selected the web font BebasNeue.otf. You can download free and open fonts from sites such as http://www.dafont.com.

Uploading Your Font to Your Amazon S3 Bucket

Now, all we have to do is to upload the font onto our filesystem in the cloud (see Figure 9-25).

Figure 9-25. An uploaded BebasNeue font

1 2 3 4 5 6 7 8 9 10

<html> <head> <title>S3 - font</title> <meta charset="utf-8" /> <link rel="stylesheet" type="text/css" href="styles.css"> </head> <body> <h1 class="test">HTML5 Hacks</> </body> </html>

In our styles.css let’s add the following and point to our uploaded file. Also, let’s assign the font to our H1 header via the test class name.

1
2
3
4
5
6
7
8

@font-face {
  font-family: BebasNeue;
  src: url('https://s3.amazonaws.com/html5hacks/BebasNeue.otf');
}

.test {
  font-family: 'BebasNeue';
}

Now we’ll open a browser and point to our newly created HTML page. In Opera (see Figure 9-26), Safari, and Chrome our header tag is being styled correctly.

Figure 9-26. Opera browser showing the BebasNeue font

http:// console.aws.amazon.com. Click on Properties→Permissions→Edit CORS configuration, and you should receive a modal prompt.

The configuration can accept up to 100 rule definitions, but for our web font we will only need a few. For this example we will use the wildcard, but if you are doing this in production, you should whitelist the domains to prevent others from serving your font from your S3 account on their own web pages. It wouldn’t be the end of the world, but it might get costly.

The first rule allows cross-origin GET requests from any origin. The rule also allows all headers in a preflight OPTIONS request through the Access-Control-Request-Headers header. In response to any preflight OPTIONS request, Amazon S3 will return any requested headers.

The second rule allows cross-origin GET requests from all origins. The * wildcard character refers to all origins.

1
2
3
4
5
6

<CORSConfiguration>
<CORSRule>
<AllowedOrigin>*/AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
</CORSRule>
</CORSConfiguration>

So, let’s add our new configuration to our Editor and save (see Figure 9-29).

Figure 9-29. Configuring CORS in the S3 Management Console

I’m getting ready for an upcoming talk titled: Rapid Prototyping HTML5 Applications with NodeJS, which I will presenting at Devcon 5 – Austin.

Here is a brief summary:

With HTML5, the modern web browser continues to mature as a capable application platform. The new specifications are broad, impacting nearly every technology associated with modern web development including graphics, connectivity, client-side storage, offline access, graphics, multimedia, and performance. JavaScript continues to be front and center as the core language. NodeJS extends JavaScript’s event loop paradigm to the server, and provides JavaScript engineers with the ability to produce functionality deeper in the software stack. This phenomenon has had an impact on types of software development ranging from full-scale, enterprise, mobile applications to robot hobbyists platforms. See innovative example solutions and learn why NodeJS is an ideal development platform for the production acceleration of next-generation HTML5 applications.

This is the beginning of a transition for me. With the release of HTML5 Hacks, I’m beginning to focus more on my ubiquitous JavaScript content. I’m excited, I have a lot to share.

Look for an update with a web based version of the slides.