Going forward with GO: Gomega, Ginkgo and Docker

Talk on Nov. 6 2013 by Onsi Fakhouri of Pivotal Labs and Michael Crosby, Jerome Petazzoni and Victor Vieux of Docker

Ginkgo and Gomega: BDD-Style testing in Go

Why you should use Go

Go is an open source platform as a service and is much faster than languages like Ruby and provides easy methods for moving your Command Line Interface from Ruby to Go. Ruby, however, has a much larger developer ecosystem with Rails giving so much away for free for Ruby. In Go, the largest problem is how to test in the new ecosystem.

Why test?

Software is often written to satisfy a specification. This is a static idea isolated from the code and makes it hard to verify the specifics and test the code for errors. To do so you need to take code and write unit tests and then wrap them with integration tests. Writing dynamic tests integrated with the code allows you to have repeatable verifiability and guarantees that your code will work as you refactor, add new features, and as you change components.

At Pivotal Labs, test driven development comprised of tests, red, code, refactor, repeat takes the front stage. This is because through the discipline of first running tests, then code covers all the bases and guarantees that there is a test for everything. This pushes forward that tests are communication and that pairing programming and better documentation with consistent testing creates better code than just comments. This pushes the idea that better code is better because it has to be testable compared to untestable code that collapses into a "big pile of spaghetti" when it fails.

Testing in Go

The first myth is that testing is unnecessary in a compiled statistically typed language. This is false. A compiled language can make guarantees about interfaces and types but not about the behavior of an object let alone objects inside. Testing in Go is considered a first-class citizen, in fact it's as easy as import, write and run tests. This is done through xUnit style tests with no matcher/assertion library. The reason is because it is easy to write unit tests that lack features such as assertion functions and that testing frameworks tend to develop into mini-languages of their own. 

Using the base testing in Go is hard using the included methods because the documentation is unclear, there's lots of repeated setup and lots of repeated custom error handling. Making it into one large test doesn't help, as does making it a table driven test because neither is clearer. This leads to the tests having 1.5 to three times as much code as the actual code.

By using Ginkgo and Gomega you get access to BDD-style testing for Go. Ginkgo is the testing framework with Gomega acting as the matcher library. These are both available through github in Go and give rich semantics for describing your code's behavior. The shared test setup and teardown, short descriptive isolated tests and nested contexts make testing code branches natural while the tests themselves act as specification and documentation. The BDD-style promotes effective pairing and test coverage and while young, Ginkgo acts very mature for a testing platorm. 

Gomega allows for and prefers one-line assertions and provides consistent descriptive output for free. With a rich library of matchers and the ease of writing custom matchers Gomega allows you to expressively describe the behavior of your domain.

Gomega + Ginkgo = Better testing in Go

Gomega and Ginkgo provide the BDD-style testing designed for Go and are built out of a deep respect for Go. They integrate well with Go's test runner to the point of not having to throw everything out the window and start building tests again, you only have to start testing in Gomega. This provides a comprehensive support for asynchronous tests that Gomega extensively supports.

For more information, go to github.com/onsi.ginkgo and github.com/onsi/gomega

Docker: an inside view

What is Docker?

Docker is here to solve the matrix from hell. Developers have tons of stuff to deploy and tons of places to deploy it nowadays but there is no single solution to do so. The solution is Docker, an intermodal shipping container. This includes high and low level approaches such as linux containers, miniature Virtual Machine containers and more and has been described as chroot on steroids. Docker is a runtime for linux containers and provides a standard format and place to share them so developers and fetch an image from the registry with a docker pull and enter the image with docker, run and change.

Why Go?

Go is built on static compilation and using the go build command will embed everything you need save for dynamic libraries through cgo and libc. You can even have a real static binary if you hack the build process! Go is easier to install, easier to test, easier to adopt and is a good candidate for bootstrap. This is because it is neutral. While having a few things in common with C it is not C, nor python, ruby or java. It has what developers need, good asynchronous primitives, low-level interfaces, extensive standard library and data types and strong duck typing. It provides a full development environment by addressing multiple issues of the development workflow. 

There are drawbacks to using Go, however. It doesn't solve any problem, but it is easier than erlang and more real than rust. Maps aren't thread-safe, but that is a deliberate decision. They are fast and you can protect access with sync.Mutex or using channels of channels. Go get can't pin a particular revision, a problem Docker has had to deal with by vendoring all dependencies so developers must deal with private repositories manually. Go test can't have destructors or cleanups. In tests, you have use tests like z_frinal_test.go that don't work too well when running individual tests. Go build is painful to build multiple binaries when they share some common code and yet each program has to be in in its own package. You can bypass this by making a package 'main' but then you have to put shared or common stuff aside or use import tricks. Flagging is just right out and there's no IDE. These are all made easier if you use VIM or EMACS. 

For more information on Docker, check Docker.io. Other helpful resources for using Go with Docker, check out:

http://golang.org/ref/spec

http://golang.org/doc/effective_go.html

http://talks.golang.org/2013/bestpractices.slide

embedded doc: godoc -http=:6060 & chrome http://localhost:6060

App Discoverability - Thinking Outside The 4 Inch Box

Talk by Michael Ludden from Samsung

Many app builders look to the OS designer for a partner to work with but looking toward the Carrier or hardware manufacturer may yield much higher returns in market and revenue share.

For example, SK Telecom's T-Store is more popular in South Korea than Apple's App Store or the Google Play Store. These carrier stores are commonly overlooked by American developers because of the stigma found in this country but should be invested in because they are rarely used and can provide an easy source of interest and revenue.

Fragmentation can be an issue but these other paths can lead to success and they offer more options to be the first-to-market. 

The Samsung Developers Conference is October 27th to 29th and will provide many different tracks for developers. This is Samsung's big push to get software developers on the bandwagon.

Overview of Google Wallet APIs

Talk by Nasir Khan, developer advocate at Google, Inc.

Google Wallet has been implemented as the primary payment processor for all Google services including Play, Drive and Chrome. It is also used across the Internet through the 'pay with Google' button. In the real world you find payment options at kiosks as well as transaction details in your phone but now you can transmit money through Google Wallet to other users.

Google Wallet works like any ordinary wallet in how it keeps your payments, offers, loyalty and more in one secure app.

In the past couple years transactions and accounts have grown year after year.

The APIs involved are:
1. Instant Buy API on Web and mWeb
2. Instant Buy API on Android for physical goods
3. Digital Goods API on Web
4. In-app Billing on Android for digital goods
5. Wallet objects API for loyalty and offers

The challenge for mobile commerce is that 97 percent of users abandon a mobile purchase in mid-flow. This has been accounted to browsing but other statistics show a significant amount of shoppers abandoning purchases already in the cart. To solve this, Google uses Instant Buy. Instant buy provides a faster checkout, allows users to skip registration and sign-in, features enhanced security, has a lightweight integration and includes no additional fees.

This works by having users access their Google Wallet, grab their information that is stored there and sends it to the merchant or payment processor. The information sent isn't the actual information of the user but a proxy card that keeps the user safe behind a level of security as well as the shipping and billing information needed.

The Instant Buy API includes simple JavaScript API for back end independent integration, a JavaScript library that renders the Google Wallet button assets and a Web application needed to implement the payment. The API also uses JSON Web Tokens that are cryptographically signed and base64url encoded to verify the originator of the message and includes the signature that is used shared secretly and verified by the Web tokens.

The Buy with Google Button can be implemented in as few as four lines of HTML or five lines of JavaScript. This uses the Masked Wallet call that gives the masked payment credentials, shipping address, billing address and phone number to the application. Clicking the button sends the request  and the information is encrypted.

Clicking through the prompts send the full wallet request which will have the full, exact amount including tax and shipping. The response will contain the Proxy card details and billing address that is backed by the security and encryption found earlier.

The Instant Buy Architecture is part of Google Play Services and so every device running Android 2.2 and higher will have it installed. To utilize it a thin client library is compiled in your app. To set this up, establish a connection to Google Play Services.  This will fetch a masked wallet. The user then clicks on the button and it will then prompt whether or not there is a Google Wallet account already active and whether it is set as default payment. If not, it will work through the authorization prompts. If the user is already authorized then it will move immediately to the confirmation page. The user has to confirm to get the actual full wallet. This is the first point in the whole transaction that the full wallet information is sent.

Some of the apps already using Google Wallet that show increased productivity:
TabbedOut: 25% Google Wallet Purchases
Rue lala: 50% are return customers
Fancy: 20% Conversions 14% basket size

Digital Goods API is also known as the in-app payments API. It is optimized for digital content and is used through the apps. This was designed to let developers handle their app while Google handles the payment.

This API is built around three principles. First a streamlined experience that provides and easy way for consumers to navigate the payment process. Second is a simple integration so developers will feel no stress in implementing them in their applications. Last is attractive pricing, which is run completely through Google at the most aggressive pricing in the industry.

The Wallet Objects API is here to solve the fat wallet challenge. The first part of the challenge is the quantity of cards including loyalty cards, points cards and credit cards. The second is the time consuming sign-up involved for each and every card. Third are the lost benefits. It is estimated that 16 billion dollars in points go unused every year. The Google Wallet Objects API is here to have everything in one place.

This brings back to the three things the Objects API brings, all of your cards in one place, little to no enrollment and a deeper engagement in the programs you are enrolled in. This is designed to be easily integrated into existing loyalty systems.

Two million users have used the new app in the past three weeks since the last app launch. This includes a 23% increase in the Alaska Airlines Mileage Plan since the App launch.

For more information, go to developers.google.com/wallet

Developing High Performance Websites and Modern Apps with Java script and HTML 5

Talk by Doris Chen, Ph.D.

Web Site and Modern Apps

Modern Apps are native JavaScript apps written either for Windows 8 or Windows Desktop. With JavaScript and Windows 8 you will be able to take Web apps and implement them natively as Windows 8 apps without modifying any of the code.

General Best Practices for JavaScript Development

Some tips and tricks that still work for JavaScript Development include:

1. For Safe dynamic content, use innerHTML to create your DOM

2. Link CSS styles heels at the top of the page, not at the bottom

3. Avoid inline JavaScript and inline CSS styles

4. Don't parse JSON by hand, use JSON.parse

5. Build Session "50 performance tricks to make your HTML5 apps and sites faster"
http://channel9.msdn.com/Events/Build/2012/3-132

Game: Make it Run Faster
5 Principles to improve your performance

An example game includes a matrix of players with arms outstretched at 90 degree angles. When one is clicked, it spins and high-fives it's neighbor if they are aligned right. By pressing the F12 key while running an app you can track the UI responsiveness in the app you are running, allowing one to track the CPU utilization and the Visual throughput. Some of the metrics involved include Loading, Scripting, GC, Styling, Rendering and Image decoding. What actually impacts the visual throughput includes networking, HTML, CSS, collections, Javascript, Marshalling, DOM, Formatting, Block Building, Layout and Rendering. These are the variables you need to control to keep the framerate at or above 60 fps. When one needs a more detailed profiler, check out Windows Performance Toolkit at http://aka.ms/WinPerfKit.

Principle #1: Memory Usage: Stay Lean
Keeping track of Garbage Collection will show you where your code needs to be more efficient. Things that trigger a garbage collection include every call to new or implicit memory allocation which reserves GC memory and when a pool is exhausted.

Using the example, instead of creating a new object for each person in each direction, create the person as an object and set the different directions as the states for the objects, cleaning up the object pool.

In this example, the GC time was reduced to 1/3rd the amount of the original code.

This shows that the best practices for staying lean include avoid unnecessary object creation, use object pools when possible and to be aware of allocation patters especially when setting closures to event handlers, dynamically creating DOM (sub) trees and implicit allocations in the engine.

Principle #2: Use fast objects and do fast manipulations
Make sure the order is the same when creating multiple objects or you will create multiple objects rather than states of the same object. You need to also make sure you don't add properties conditionally. This follows the old adage, "Less is More", where programmers should set parameters first in as few lines as possible. One should also make sure not to default properties on prototypes.
Deleting also slows down properties because it forces conversion. You should instead set properties to 0 or undefined to close it off. You should also restrict the total properties to stay away from slower property bags. To keep from those slow property bags you should also restrict using getters, setters and property descriptors in perfect critical paths.

Principle #3 Write Fast Arithmetic
All numbers in JavaScript are IEEE 64-bit floating point numbers which are great for flexibility but present a performance and optimization challenge. To help with this, avoid creating floats if they are not needed. The fastest way to indicate integer math is |0. You can also take advantage of type - specialization for arithmetic by creating separate functions for its and floats by using consistent argument types.

Principle #4 Use Fast Arrays
When writing your arrays, pre-allocate them to speed them up. For mixed arrays, provide an early hint. This will avoid delayed type conversion and copy. You should use typed arrays when possible. This avoids tagging of integers and allocating heap space for floats. One should also keep values in arrays consistent since numeric arrays are treated like typed arrays internally. Keep arrays dense. Explicit caching of length avoids repetitive property accesses.

Principle #5 Do less (cross-subsystem) work
Avoiding chatting with the DOM will relieve the code of excess cycles. Avoid automatic conversions of DOM values. Values from the DOM are strings by default. Paint as much as your users can see. Aligning timers to display frames will cut down your work.

These principles will create a great user experience that will extend the battery life and make the app much richer than before.

Check out BizSpark and DreamSpark for useful tools.

Contact Doris Chen,
doris.chen@microsoft.com
http://blogs.msdn.com/b/dorischen/
@doristchen

Augmentation and Telepresence #throughglass

Talk by Martin Wojtzcyk and Devy Tan-Wojtczyk

Augmented reality is when you enhance reality with computer-generated images, allowing for one to either see or be put into a virtual reality.

Telepresence is the use of virtual reality technology to transmit video and/or audio to communicate with others.

To program for Google Glass, there are a couple methods:

Using Google's Mirror API connects Glassware (HTML) with Google and then to Glass. This allows for easy programming and implementation but causes a lag between the device and the database where your program would lay.

Using GPK, developers would be able to program directly for Glass and upload their programs directly to the device to allow for real time zero-lag environments.

There are many use cases that we are tackling through our startup.

Shopping
Map overlays allow for people to find the store and will navigate to the shop. Overlay changes to on-screen display showing products to purchase. When selected, Glass navigates shopper to the item and describes prices, reviews of products.

Telepresence
Telepresence allows management to contact workers in factories around the world and see through hangouts what the workers see. This enables management to keep track of projects while being in another country.
Telepresence also allows robotics to be implemented in labs to allow for sample checking from home. This also allows for exploration and rescue to be manned from safety.

Resources:

Mirror API
https://developers.google.com/glass/overview

Google ask samples
https://github.com/googleglass

OpenCV4Android SDK
http://docs.opencv.org/doc/tutorials/introduction/android_binary_package/O4A_SDK.html

Functional Fashion and the Future of Mobile - Wearable Android

Wearing Android

The future of mobile devices is wearable

Talk by Siamak Ashrafi, researcher at YLabs

Embedded devices are all around us in card readers, registers, etc. This is the wrong way of doing things.

MEMS sensors are so prolific that you will find them in all mobile devices. The sensors include acceleration, temperature, gravity, gyroscope, light, magnetic field, orientation, pressure, proximity, humidity, vector, camera, microphone and touch. Antennas include CDMA, GSM WiFi, NC and Bluetooth. Sensors make a smartphone close to self aware. Code that includes gravity, accelerometer and linear accelerometer allow devices to sense if you have taken a fall and will notify those needed. 

These sensors allow for seeing, hearing and feeling through camera microphone and touch. This sensor data, coupled with Android, utilizes Google Cloud Messaging to pair sensor suites with devices to connect to the Internet and send the data to anything. Near Field Communication tags allow for quick transfer of information including Bluetooth handshakes, Credit Card information and Wi-Fi passwords. These NFC tags only work when in extremely close proximity, aka skin-to-skin. These low energy devices allow for a bevy of Wearable devices.

The uses of device-based objects are shown in the differences between Rovio and Romo:

Rovio
Device required specialized hardware and components and was late-to-market because of problems with the Specialized hardware.

Romo
Device added wheels to an iPhone and was able to do the same as the Rovio for a fraction of the cost and without the problems thanks to the hardware being already vetted and tested by Apple.

Mind versus Body shift

We have been shifting from using our body to survive to using our mind to survive and our bodies have not adapted to the current level of inactivity and has led to numerous problems.

There are two types of Android devices on the market, those that run Android and those that only utilize Android.

Devices that utilize android but do not run it include the Jawbone Up, Lark, FitBit and the Nike+ Fuelband. The Jawbone Up tracks your sleep, activity, food and drink, mood and others but only mentions what it has been doing when you plug it in. Lark does a lot of what the Jawbone up does but includes a small display while the FitBit includes a large enough display to show a clock and other data in future devices. Nike+ FuelBand only works on iOS but includes a display akin to the FitBit.

Watches

Pebble Watch: Runs other OS, Black and White
Sony Watch: Runs some Android, Color
Samsung Watch: Runs full Android, same hardware as top-level devices a year ago.

Phones

Apple M7 Motion Co-Processor

Glasses

Glass UP: Read-only and includes mail, messages, text messages and notifications.
Recon Jet: Android without Google software
Google Glass

Applications allow new technology to succeed by allowing anyone to adapt and utilize something new. Glass is the next device that won't be left at home.  While Glass is currently in the Explorer Edition, it will change to be more attractive and fashionable in the future. The hardware includes all of the pieces except for the cell antenna, keeping the high-power devices away from your head.

Glass originally used Google's Mirror API to connect to AppEngine to develop applications, now you can write through the GDK to directly program apps. While the GDK allows for deeper implementation, the Mirror API lets programmers unfamiliar with Android to develop with all of the tools needed to get information on Glass.

For Glass, one primary feature is the built-in augmented reality. This required a combination of powerful processors and sensors that wasn't accessible by the public until today's Smartphones.

Android and Bluetooth Low Energy

Talk by Dario Laverde, Senior Developer Evangelist for HTC

Bluetooth Low Energy began in 2001 was introduced with Nokia's Wibree and merged with the main standard in 2010 with Bluetooth 4.0.

The Bluetooth 4.0 core specifications include the classic Bluetooth technology, Bluetooth Low Energy and Bluetooth SMART. Hardware-wise Classic Bluetooth is limited to a 100 meter range with a transfer rate of one to three Mbit/s and uses under 30 mA while BLE utilizes a max range of 50 meters, has a 1 Mbit/s transfer rate and uses under 15 mA of power.

We have seen Bluetooth Low Energy used in health, fitness and proximity but there are many more possibilities. These uses have their own specifications known as BLE Profiles. These are for particular applications and manufacturers are expected to implement specs to ensure compatibility but are not required by the core specification itself.

Some profiles include:

HRP: Heart Rate Profile for pulse monitoring
HTP: Health Thermometer Profile for medical temperature measurement
GLP: Glucose Profile for blood glucose monitors

CSCP: Cycling Speed and Cadence Profile
RSP: Running Speed Profile

FMP: Find Me Profile
PXP: Proximity Profile that allows the device to detect if another device is near

BLE manufacturers are encouraged by Bluetooth SIG to create new profiles and extend others with proprietary characteristics to expand the original ones. This does create difficulty, however, with app developers having to contact the 3rd party manufacturers for specifications. BLE Profiles sit on top of the Generic Attribute Profile on the Host and shares the same radio with the classic Bluetooth but has many layers removed to make it more efficient.

BLE Protocols

General Attribute Profile (GATT)

Phone, the master/central role has the GATT Client, and the BLE Smart device, which is Slave/Peripheral and contains the Service and the Characteristic with the value and descriptors. There are some roles left out including the Broadcast Role. Android BLE only supports the central role but IOS supports both.

BLE GATT Clients and Servers

Servers expose the attributes while the clients use them. The Client Actions include discovering, reading, writing, confirming and indicating while the Server Actions include responding to the client actions, sending notifications and indicating.

To find more information, go to the Bluetooth SIG portal.

BLE Developer Device Kits

BLE chipset OEMs provide device kits which support different profiles. Texas Instruments' Sensorial has a bevy of sensors including acceleration, rotation, pressure, humidity, magnetic field and temperature.

Prior to Android 4.3, several OEMs already have devices on the market that support BLE and each provide their own BLE API including HTC, Samsung, Motorola and others. The BLE API was formally announced at Google IO 2013 and includes API Level 18. In most, if not all, cases, you will build on top of the GATT profile so your app must include the implementation of your required BLE profiles.

Demos

Scanning works slightly different than Classic Bluetooth in that it has its own callbacks.

It is more efficient in that by searching for Low Energy devices allows much faster scans compared to a scan for both classic and low energy Bluetooth devices. Sadly a known issue in Android is that, for the time being, it will only allow four sensor notifications.

Q & A

Resources/References

https://d.android.com/guide/topics/connectivity/bluetooth-le.html

http://processors.wiki.ti.com/index.php/Bluetooth_SensorTag

http://www.htcdev.com/devcenter/opensense-sdk/bluetooth-smart

Bluetooth SIG, Google IO 2013, TI.com/ble,

https://github.com/RadiusNetworks/android-ibeacon-service

contact info: dario.nycjava@gmail.com

Opening!

Greetings Google DevFest West 2013!

We'd like to start off by thanking Google for providing the facilities, room and the teeshirts and other prizes, GDG Silicon Valley and GDG San Francisco for putting on the event and Josh for doing the website.

To view the schedule as well as look at a couple of the talks go to http://www.devfestwest.com/2013 .

For those at the talks, lunch will be on the patio behind the building and there will be a break for lunch and dinner that will be catered. Talks will be held in building CL2 (Crane Beach Room) and CL3 (Maxwell Room).

Thanks for coming and have a great DevFest!

Setting up for DevFest West!

Badges and lanyards out, volunteers prepped, we are ready to go! We will have registration inside Building CL2's lobby (employee entrance). Open the floodgates!

Intro to App Engine and Cloud Computing

Wesley Chung is an engineer, writer, teacher, and was one of the original engineers who built Yahoo! mail. He stopped by our monthly GDG meetup to give everyone an introduction to Google App Engine and cloud platform.

Cloud Platform

Google got involved in cloud computing out of necessity. Google's search index last year exceeded 100 petabytes (100 million gigabytes). Roughly 4 days of video are uploaded to YouTube every minute. We don't know what percentage of that is cat videos.

The cloud technologies Google provides for you to use is an extension of the work they did tackling those internal problems. App Engine, Compute Engine, platform as a service. There are three pillars to their offerings: the compute side, storage, and application services. These combine to give you a platform to deploy your application without the usual worries of load balancing, availability, operating system, and all the little details that typically take up your time to bring your application to deployment worldwide.

Even better, the cloud platform provides APIs for networking functions that usually require extensive configuration, like email, database access, URL feeds, cloud storage, authentication, etc etc etc.

You get a full featured administrative console with too many features to list here. You'll have to explore it yourself. It's impressive.

App Engine

App Engine serves 7.5 billion page views every day. That's a "very googley" number.

Buddy Poke is a cutesy app that's been around almost as long as App Engine itself and is a good example of long term scaling, both in terms of registered users and daily use.

Gigya builds apps for special events, which is an example of short term scaling. Traffic spikes before and during the event, then dies off.

The royal wedding (Will & Kate) blog was hosted on App Engine. 32,000 users were hitting this app every second, peaking at 42kqps (kilo queries per second) when the royal couple kissed. You might call this "Royal Scaling."

This really tested App Engine's scalability

There are samples and tutorials available for web and mobile apps on App Engine, and a showcase of what other developers have built. There is a free tier if you want to try it (it only starts to cost money when you start to get significant traffic; by that point I hope you're making some money off your app), and don't worry about vendor lock-in. You can always move your application to another platform if you want.

Getting Started

You can play around with app engine on a web based SDK (no download required) at the Cloud Playground. Follow the link, clone one of the sample projects, and try it out.

Cloud Platform - Bringing it all Together

App Engine is the gateway to all other Google cloud services: databases (MySQL compatible and NoSQL), Google Translate, BigQuery, Google Prediction API, on demand virtual machines (RHEL/CentOS, Debian), local persistent storage, public cloud storage, there's even a REST API to create and manage VMs. Of course you can incorporate all the other Google APIs into your applications. Read more at the Cloud Platform Blog. 

That's all for this month. Thanks to everyone who attended and watched the talk on our YouTube channel. Happy hacking!

Build Native Apps with HTML5

Joe Marini came by to show us some neat tricks on the Chrome Packaged Apps Platform, building native apps in HTML5.

Native apps in html5 with chrome packaged apps from Joe Marini

We had a huge turnout for this talk!

The public release will include native launch points for each OS (the Mac doc, Windows start menu, etc). Packaged apps run offline as well as online, they run locally and all the code (HTML5 and JS) is stored locally.

He showed some cool demos, including 500px, a code editor with syntax highlighting, and a magazine. The apps can use the native windows controls if you want, or you can build your own using webkit regions.

Packaged apps are an attempt to solve problems inherent in web applications, like intermittent connections. Most web apps have functions that should work offline, but they don't. With a packaged app you can retain offline functionality even if features requiring connectivity won't be available. Packaged apps also have access to platform capabilities and hardware (USB, bluetooth, sockets, etc). Imagine playing a web game with any controller you want. You can create a richer, more immersive experience, with distribution and updates managed through the chrome web store. Packaged apps also support in-app purchases with Google Wallet, as well as analytics.

Joe went into a deep dive into the packaged app structure. One interesting point is the differentiation between online and offline features, and developers need to think about what local resources are required to allow offline features to function in the absence of an Internet connection.

Want some specifics? No plugins! No Flash, no Java. You can embed native code using the HTML5 native client, but it can't use local storage because it is a synchronous API, and a synchronous API call can block the main thread causing your app to hang. You still get the functionality of local storage, as an asynchronous equivalent called Chrome Storage is supplied to be used instead. You can also leverage Chrome's cloud features, such as the Sync API and SyncFileSystem. It supports Google Drive out of the box, and is extensible for use with other services like DropBox.

Joe gave a lot of great pointers on how to build great packaged apps and some live code examples.

Like Dart? There is a chrome.dart github project, and as soon as Dart hits v1.0, they will start working on Dart for packaged apps.

Packaged apps are build with HTML5 and Chrome tools, but they live outside the browser, allowing for more developer options and a richer user experience. It was standing room only for this talk. Pretty cool stuff.

Joe is a developer advocate for the Chrome team, you can find him on twitter and github:
@joemarini
github.com/joemarini