Wednesday, February 5, 2014

Age of Context

Robert Scoble's talk on the Age of Context at the Google Developer Group Silicon Valley.

talk by Robert Scoble

Age of Context: Mobile, Sensors, Data & Future of Privacy
book by Robert Scoble and Shel Israel

The five forces changing the mobile landscape are sensors, wearables, location, privacy and data.

Sensors today are found in everything from clothing to automobiles. Wearables allow us to take computers with us without the detriment of holding while also giving them access to data only found when we have something always on. Location is giving these computers and the big data assets everything we do down to one-and-a-half meters. Data is taking all of this information and compiling it to be used together and return usable metrics.

The idea lacking from these five forces is context.

This context means highly personalized products. You will be tracked, but catered to. Google Now tracks your movement, your email, your calendar to show where you are going and what you will do. This will lead to new anticipatory services and products. Programs like Google Now will evolve and be joined by deeper and more complex programs that utilize this massed quantity of data.

Programs like these will be able to see everything, but this won't be a bad thing. Uber and GE use industrial internet to track you and enable more personalized services. Why wait for a taxi when you know exactly where it is and they know exactly where to pick you up?

Context will give much deeper insights into customers. Pinpoint marketing will allow vendors to know what you want so they can show you the products that will work best for you. With the change from mass market to pinpointed personalized people will most likely see less ads but all will be relevant.

The mobile revolution is here and the context is defining what all of this loose information is. From Nest, that allows you realtime information about your smoke detector and thermostat, to smart bluetooth beacons used to locate your keys.

Tuesday, November 19, 2013

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 and

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 Other helpful resources for using Go with Docker, check out:
embedded doc: godoc -http=:6060 & chrome http://localhost:6060

Friday, October 18, 2013

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

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"

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

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,

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.
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 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.

Mirror API
Google ask samples
OpenCV4Android SDK

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:
Device required specialized hardware and components and was late-to-market because of problems with the Specialized hardware.
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.

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.
Apple M7 Motion Co-Processor
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.