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).
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.
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.
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.
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.
]]>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.
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?
Here, are the areas my talks will focus on in 2015:
HTML Hacks training content. If you or your company need training, give us a shout.
Here is a brief outline of the workshop:
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.
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.
Tulsa Mini Maker Faire’s Scott Phillips to put together the closing keynote at the 200ok conference .
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:
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 |
|
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 |
|
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.
Walter Higgins’ great ScriptCraft library. I wasn’t expecting the conference wifi, and single access point, to suffice in allowing Carter and I to interact within virtual world. I was also concerned about the dynamic IP, and having to change it on the fly, start/restart the server, etc. So I made the decision 10 minutes before to not have Carter log in, and I would just speak to the possibility instead. In true 6 year old fashion, he rebelled and logged onto my server, popping up in front of me wearing a Creeper mask, as I was mid stream explaining how to script wooden signs with his 1st grade sight words as a homework exercise.
1 2 3 4 5 6 7 8 9 10 |
|
Needless to say, his innapropriate behavior was a crowd favorite. I have to admit, it was mine as well.
As JavaScript-centric web applications continue to become the standard, and the browser continues to evolve into a full-featured web application platform, developers need powerful debugging tools to help quickly troubleshoot issues and fix them efficiently. Issues can range from HTML/CSS browser inconsistencies, JavaScript exceptions, and a myriad of performance issues that range from DOM access to network latency.
There a number of tools that web developers can use to help make debugging front end applications less painful.
In this tutorial, we will walk through the top tools available and how to use these tools by addressing some of the most common issues faced in modern web application. This is a beginner to intermediate level tutorial for web developers getting started with debugging the web, or programmers coming from other languages who want to better understand how to troubleshoot client side JavaScript, the DOM, performance, and network calls.
To demonstrate we will be debugging a simple web application. The source code is available here: https://github.com/jessecravens/techpro-debugging.
Read more at: http://tech.pro/tutorial/1404/debugging-modern-web-applications-part-1
]]>So, as you might expect, a single-threaded architecture can be problematic to the user experience if a particular script takes a long time to complete.
Read more at: http://tech.pro/tutorial/1487/web-worker-patterns
]]>For SXSWi and FluentConf this year, @boyofgreen and I created a demo application to showcase some of the hacks that we included in our book OReilly’s HTML5 Hacks.
The demo application, Nerdclustr, is an HTML5 mobile application that brings ‘nerds’ of all types together conferences and provides a visual map that updates in real time. The application was written with Node.js and the Express web framework. It demonstrates the following specifications: HTML5 Web Forms, Geo Location API, WebSocket, Canvas, CSS3 transforms.
Given, the attention that Web Components and Polymer.js have been getting lately, I felt this was a good opportunity to demonstrate some of the exciting new specifications that are making their way to modern browsers. For the sake of this tutorial, I’ll be using and providing screenshots of Google Chrome, but it should be worth your time to explore the status of each of the specifications in other modern browsers as well.
In this tutorial, we will take a look at the HTML5 specs mentioned above in detail. Then, we will explore Polymer.js and build out an example application.
Read more at: http://tech.pro/tutorial/1421/building-next-generation-widgets-with-web-components
]]>here.
HTML5 Hacks
html5hacks.com, and on github: github.com/html5hacks.
I also added a few more new hacks, involoving Web Components (Shadow DOM, HTML Imports, Custom Elements) and Polymer.js. You can find that source code available here: github.com/html5hacks/fluent2013-html5hacks
It’s been alot of fun co-presenting with Jeff, but my next two sessions, I will be going at HTML5 Hacking solo. You can catch my next presentations in NYC on July 24th–25th at Devcon5 2013 NYC or November 4th–8th at Øredev 2013.
]]>This is an exploration of Handlebars.js template library when used with Ember.js views. Many of the Handlebars.js tutorials on the web discuss the Handlebars API, but not in the specific context of using Handlebars with Ember.js. In addition to filling that void, I’ll also give a brief background of JavaScript templating in general to provide perspective as to the problems it is solving.
This tutorial will be divided into two parts. In Part 1, you should gain a clear understanding of JavaScript templates, the capabilities of Handlebars expressions and helpers, and how to write your own Handlebars helpers.
Read more at: http://tech.pro/tutorial/1308/emberjs-views-and-live-templates-with-handlebarsjs-part-1
]]>The following tutorial will provide an overview for building Ember.js applications with Yeoman. Keep in mind, Yeoman is a framework agnostic collection of tools, used to manage the workflow of any JavaScript application or plugin. For the sake of this tutorial, we have chosen to focus on Ember.js, as a case study.
Our workflow would not be complete without also setting up our testing strategy, so we will also include a standard BDD (Behavior Driven Development) setup with the Mocha testing framework.
Read more at: http://tech.pro/tutorial/1249/modern-emberjs-application-workflow-with-yeoman-and-mocha
]]>Created by Opera, Server Sent Events standardizes Comet technologies. The standard intends to enable native real time updates through a simple JavaScript API called EventSource, which connects to servers that asynchronously push data updates to clients via HTTP Streaming. Server Sent Events use a single, unidirectional, persistent connection between the browser and the server.
Unlike the Web Socket API, Server Sent Events and EventSource object use HTTP to enable real-time server push capabilities within your application. HTTP Streaming predates the WebSocket API, and it is often referred to as Comet or server push. The exciting part here is that the Server Sent Events API intends to standardize the Comet technique, making it trivial to implement in the browser.
In a standard HTTP request and response between a web browser and a web server, the server will close the connection once it has completed the processing of the request. HTTP streaming, or Comet, differs in that the server maintains a persistent, open connection with the browser.
It is important to note that not all web servers are capable of streaming. Only evented servers such as Node.js, Tornado, or Thin are equipped incorporate an event loop that is optimal for supporting HTTP streaming. These, non-blocking servers handle persistent connections from a large number of concurrent requests very well.
A complete discussion on evented vs. threaded servers is out of scope for this post, but that being said, in the upcoming hack we will provide a very simple evented server implementation example to get you started. We provide a simple browser based JavaScript to connect to the server, and a server side implementation using Ruby, Thin, and Sinatra. For the record, this is also very easy to do with Node.js.
Here is a link to the companion github repository: https://github.com/html5hacks/chapter9
The Sinatra documentation describes itself as a “DSL for quickly creating web applications in Ruby with minimal effort.” This text has focused primarily on Node.js (HTTP Server) and Express.js (web application framework) to quickly generate server side implementations for hacking out functionality.
It would a disservice to not mention Ruby, Rails and Sinatra in the same or similar light as we have Node.js in this text. Although learning Ruby is another learning curve, in the larger scheme of programming languages it is a less daunting curve than most. And as most die-hard Rubyists will preach, it is arguably the most elegant and fun to write of all modern programming languages. Ruby on Rails, and its little brother Sinatra are also great web application frameworks to start with if you are new to web application development.
Much like Node.js and Express, Sinatra makes building small server implementations nearly trivial. So for the context of HTML5 Hacks, that allows us to focus our efforts on programming in the browser.
For now let’s build a simple HTTP Streaming server using Sinatra.
To get started with Ruby On Rails or Sinatra, check out the great documentation available at http://guides.rubyonrails.org/getting_started.html and http://sinatrarb.com/intro, respectively.
Our goal in the next hack is to build a simple streaming server and use the EventSource object to open a persistent connection from the browser. We will then push notifcations from one ‘admin’ browser to all the connected receivers. Sounds simple, right? Let’s get started.
Open up a file and name it stream.rb. Then add the following: Simple requiring of Sinatra and the JSON library:
1 2 |
|
Then, we set up a public folder, and set the server to use the evented ruby server, Thin.
1 2 |
|
Set up two routs for serving our 2 pages: index and admin. We will use Erb as our templating language. The details are out of scope, but our use is very minimal. More on Erb here: http://ruby-doc.org/stdlib-1.9.3/libdoc/erb/rdoc/ERB.html
1 2 3 4 5 6 7 |
|
We’d like to timestamp each notification, so here is a very simple function definition.
1 2 3 |
|
We also set up two empty arrays: one to hold the connections and the other to hold out notifications.
1 2 |
|
Now, for the routes. When our browser loads it s page, we have JavaScript running which will use the EventSource object to connect to a url here: http://localhost:4567/connect.
More on EventSource later.
But for now you can see the magic of the evented HTTP stream, the connection is held open until a callback is fired to close the stream.
1 2 3 4 5 6 7 8 9 10 11 |
|
Finally, any data this posted to the /push route is pushed out to each connected device.
1 2 3 4 5 6 7 8 9 10 |
|
As we said before, you can just follow the instructions at our git repository to pull down and build this code. Or if you have been following along, launch a terminal, navigate to the directory where you code is, and run:
1
|
|
Figure 9.15 Starting the Sinatra Server
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
The admin page will contain an input tag and a simple button.
1 2 3 4 |
|
And our receiver pages will display a simple piece of text:
1 2 3 |
|
By launching one browser window to http://localhost:4567/admin you should now see our admin form.
Figure 9.16 The initial admin page
http://localhost:4567 in your browser and you should see.
Figure 9.17 The initial index page
1 2 3 4 5 6 7 |
|
Now, lets open up five browser windows: one admin at http://localhost:4567/admin and four more receivers at http://localhost:4567
Figure 9.18 Opening 5 browser windows
1 2 3 4 5 6 7 |
|
Now we can add a simple notification with the available data,
1 2 3 4 5 6 7 |
|
And here is the final script for the admin:
1 2 3 4 5 6 7 8 9 |
|
For our Push Notifcations we will make use of Eric Hynds great jQuery plugin jquery-notify, located here at github: [github.com/ehynds/jquery-notify] (https://github.com/ehynds/jquery-notify)
In order to display the notification, we will need to include some markup to the receiver page.
1 2 3 4 5 6 7 |
|
This creates a hidden div tag in the bottom of the document. We are not showing the CSS that uses “display: none” to hide it, but you can see more by examining the source code in the companion git repo.
Figure 9.19 Inspecting the DOM in Chrome Dev Tools
1 2 3 4 |
|
And here is the final script for the receiver:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
It’s that simple. The EventSource API is minimal and plugging it into a web framework like Sinatra or Node.js is straightforward.
Now, as we submit notifications from the admin page, our receiver pages are updated with time stamped notifications:
Figure 9.20 Pushing Notifications to the Connected Browsers
We had a great turnout for the ‘Battle of the HTML5 Hackers’ presentation at SXSWi on Tuesday.
Nerdclustr: an HTML5 mobile Application that helps nerds find other like-minded nerds at conferences events.
Using realtime and mapping technolgies, the app visualizes nerd behavior in map pin clusters.
Nodjitsu for the quality node.js WebSocket service. After a 2-day hackathon to get the app launched, I ran through a number of deployment options, many of which I have used before for Rails applications. Nodjitsu won out in that it actually supported the WebSokcet protocol and made deployment super simple using the jitsu CLI.
here.
During the book signing, the bookstore informed us there were only 3 copies left. I’m not keen to the selection process of books, but I was little surprised at the limited number of technical books. This is certainly a reflection of the SXSWi demographic, and we also tailored our content and presentation style to this audience.
The slide deck is available here:
Stay tuned for our next presentation happening online, through O’Reilly Webcasts. Join us for ‘Rethinking the Possibilities of Browser-based Apps with HTML5’ on Wednesday, March 27, 2013 10AM PT.
]]>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
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 |
|
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
|
|
And we can’t forget to include a few dependencies:
1 2 3 4 5 6 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 |
|
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 |
|
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 |
|
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.
]]>