Don G. Park

Bluetooth 4.0

I first heard about Bluetooth in 1999 (before I heard about wifi!). It was the most amazing sounding thing. All devices being able to easily communicate with each other, facilitating the Internet of Things. Its 2011 and Bluetooth is used for headsets, keyboards, and mice.

Battery drain and security bugs were two big detrements to Bluetooth adoption during its early years. The most important use case in my opinion, the ability to pass application-level messages between phones that have never met before, is sill not possible. For two bluetooth devices to communicate, they must "pair" which needs user intervention to complete. To even begin paring they must be discoverable. Being discoverable sends usage of the Bluetooth radio way up and becomes a noticeable battery drain. In the very earliest implementation of bluetooth, bluesnarfing was possible, where a phone's address book or other information could be copied without the phones having met before and without user intervention. This created a stigma that has remained with bluetooth discovery to this day.

With the relative popularity of zigbee - a sensor-network style protocol with neighbor discovery, low data rates, and extremely low battery usage - port of Bluetooth 4.0 is returning to its roots as a general purpose low power data transport. Its called Bluetooth low energy and chipset manufacturers are already selling wifi+bluetooth 4.0 chips that are ready for adoption into smartphones.

The smartphone automatic shared-interest app will get its best shot yet, very soon. Define what you're interested in, business, dating, buying or selling goods. When you get near someone who is running the same app on a bluetooth 4 smartphone, it could swap contact info for a later hookup, or start beeping loudly to say "hey someone in this room is selling that DVD you've been looking for. Here is their photo."

IPv6

With IPv6 deployment finally starting to begin, the old set of 4 billion IPv4 addresses is being replaced with the new set of 340 trillion trillion trillion IPv6 addresses. The "limited" IPv4 address space was the driving force behind NAT which keeps individual devices from communicating directly. With the wide array of security holes in Microsoft Windows that existing during the first 10 years or so of the Internet's life and growth, the walled-garden effect of NAT was seen as a benefit, a critical measure of protection from viruses.

What was lost was a fundamental utility of the Internet, that devices should be free to communicate directly with each other. Instead of NAT, the entry points to corporate networks can use packet inspection to filter out unwanted traffic, providing the same safety benefit as NAT but allowing for the possibility of point to point communications that is important for new services, and new efficiencies for existing services to arise on the Internet.

If mobile operators adopt IPv6 addressing for mobile devices, it is one step towards a new class of smartphone apps - M2M or Mobile to Mobile. Voice and Video calls could be more efficient if traffic could pass directly between phones.

GPS II-F

The Global Positioning System, deployed in the 90s, is slowly getting a host of upgrades that improve the ability to acquire a signal, the accuracy of position information, and resistance to interference.

What to watch for? GPS receiver chips that can listen to the new L5 signal from the Block IIF-1 Satellite launched in May 2010.

I feel my efforts recently have been narrow and rooted in desire rather than meaning. I consider myself fortunate to have control of most of my time. Recently I've been thrown back to quetsions of what am I working on, why is this important.

Maslow's hierarchy of needs helps me put things in perspective, and gives me a tool for thinking about whats important. Numbering the levels from the bottom, I feel secure in levels 1 and 2. Level 3 definitely lacking. Level 4 has a foothold. Level 5 works out in very specific subject areas.

Looking outward at the world in an abstract sort of way, it seems to me that a useful goal is to get as many people as possible as high up the chart as possible. So which group to focus on helping? And does asking that question make sense without having some actual people in mind? Maybe its best to just find whoever is easiest to access and help them. Maybe its better to think about people struggling at the lowest level.

The hammer I'm most comfortable and effective with is software development so i look for those kinds of nails. One good example of which is using Open Street Maps to  improve the road maps in Haiti after the earthquake.

The Everyone Delivers project I work on has a certain social good aspect to it. The economics of transportation will make people living close to the requester the cheapest option for delivery. Meeting people in your neighborhood is assumed to be a good thing, even just once.

Its winter now and while I find the cold invigorating in small amounts, being warm is one of my favorite things. I'd rather be too hot than too cold. It is an obvious way to help, if not an easy way, by keeping human beings sheltered from the elements.

(unfinished)

The site I'm working on has a billing component to it. Important concepts in the site are user and delivery. The site has one piece of billing logic that says a completed delivery costs 50 cents. How should a bill for a given user on a given month be computed?

The naive approach, plan A, is to scan all deliveries that happened within the given month and look for completed deliveries by the given user.

The next step up, plan B, is to keep a separate accounting journal for each user. Each completed delivery gets a journal entry. The journal is scanned for all transactions in that month.

Say the billing logic changes at some point, with plan A the old deliveries would be computed with the new logic. That probably is the wrong thing to do. With plan B, charges going forward would be computed with the new logic. On the other hand, if the logic were found to be faulty, plan A would be ideal and plan B means cleaning up all journal entries.

Another argument for plan B is to allow for adjustments outside the business logic. Perhaps there are transaction fees from paypal that are accounted for seperately. Those can be easily added to a journal, where as plan A could not capture that value. Maybe a specific customer should get a refund of $5 for whatever reason. Its easy to put that into the journal.

Then I think, why implement an accounting journal in the site at all? Aren't there accounting packages that are made for managing credits and debits? I would like the website to speak directly to an accounting package, adding new journal entries as needed. I don't know of an open source account/enterprise-planning/business-intelligence product that works this way. Do you? I imagine there are benefits to using a real accounting package, reports and such made by people who know accounting.

My friend @natronics visited Mission Control in Houston TX last month. He took this photo.

It was meant to look like this original nasa photo of Gene Kranz, standing inside Mission Control.

This was supposed to be a meaningful post on the younger generations taking over from the older generations. Lets just say I'm glad @natronics and people like him are learning, exploring, and inspiring others.

About a month ago i was introduced to bitcoin. Now im completely hooked and facinated by it. There is so much to say about it I dont know where to begin.

The first thing I can say is economics itself is fascinating because of the questions it asks. It asks what does money mean? How does money influence people's behavior? Its at least half psychology. At the same time its highly measurable and observable.

The personal computer and the Internet has created the greatest playground for value transfer in the history of mankind. There is so much in my head about it that I'm having trouble writing about any piece of it. The amazing properties of cryptographic strength, the real-world implications of infinity, how convention can be just as powerful as encryption. There are existing markets with real volume (10000+ bitcoins traded per day). There are people dedicated to running the hardware to create bitcoins and they exist because of how the rules of the bitcoin economy were laid out.

on the plane from los angeles back to portland, in the middle of the night, with all the beauty and splendor of looking down on major cities through patchy clouds at night, i wrote down these statements:

• a repetitive thought becomes a belief
• a belief held over a long time becomes a value
• values guide actions
• actions impact reality
• focus can filter reality through inclusion/exclusion
• reality comes via sensory inputs

Jumping from one processor to two creates a world of parallel execution issues. Having two couchdb servers creates consistency and locking issues for the appserver using the datastore. Document datastores are coming into use for real-world large scale websites - FourSquare/MongoDB for example.

The goal is simple: consistency across more than one server - a webapp with multi-site redundancy. One server runs some number of app servers and some number of document stores. Usually a few appservers and one store. This sets up easily and on a low-cost machine. How is a webapp constructed so that I can start some number of extra servers at will? Note the servers may only have Internet-speed connections instead of being in the same data center. The Appservers can run independently of each other, with session data in a browser cookie. Datastore consistency between servers is the key.

Assume two sites A and B with one appserver and one datastore per site. Round-robin DNS is setup to distribute requests between servers. When one datastore gets an update, it performs the update locally and distributes that update to all other servers as fast as it can.

A user requests the user profile page. Server A serves the page with user data retrieved from its datastore. The user changes the street address in a browser and presses save. The POST goes to server B, the result of which is a redirect to the user profile page. This user profile page comes from server A. Has the user record on server A been updated to reflect the change? The answer is maybe. It will eventually become consistent but we don't know when. Sometimes this is important, sometimes it isn't.

A more difficult example is if an update went to server B and a delete went to server A. When server B communicates the update to server A, the record will no longer exist. These are the exact issues dealt with by distributed version control systems such as git.

The best research I have come across for keeping seperate datastores in sync is Amazon's Dynamo project. Using three consistency controls, N R W, different attributes of speed, durability, and consistency can be emphasized in the storage system.

The reason I am interested in couchdb above other document storage projects is its single-mindedness on map/reduce. One of the shockers about couch is that it does not map/reduce amongst multiple nodes on its own. A separate project, Lounge, which doesn't seem to have much momentum, is for that.

Today I learned about BigCouch. I'm not sure if its a significant change to the couchdb code, or more of a front-end helper (I suspect the former). It takes dynamo-style storage controls and applies them to managing multiple couchdb processes. awesome.

From the BigCouch README with some rewording of my own:
Cluster constants

• Q - number of nodes to use, specified during database creation
• N - replication constant. N defaults to 3, but can vary by database just as Q can vary. Document updates will be written to N different nodes.
• R - read quorum constant. When reads are requested, a read is sent to the N nodes that store the particular document. The system will return to the requesting client with the document when R successful reads have returned and agree on versioning. R defaults to 2. Lower R values often result in faster reads at the expense of consistency. Higher R values usually result in slower reads, but more consistent, or agreed-upon data values returning.
• W - write quorum constant. When writing the N copies, the data store will respond to the write client after W successful writes have completed. The remaining N-W writes are still being attempted in the background, but the client receives a 201 Created status and can resume execution. W defaults to 2. Lower W values mean more write throughput, and higher W values mean more data durability.

Immediate consistency is ideal and RDBMS guarantees that. I believe there are advantages to knowing where eventual consistency is good enough. With the user address changes, the next read from the user should show the updated value, since the user is aware that a change should have taken place. Everyone else is happy with eventual consistency. This is app-specific of course. For a social media site, lets say a few minutes is enough time for the system to sync up. I imagine interesting dashboard data can be done on how long it takes for data to achieve consistency on all nodes.

One solution is to rely on ajax calls and client side javascript. The client side javascript pushes the change to one server and gets a positive acknowledgement. Thats enough confidence to change the user UI without doing a server hit, and avoiding the change of hitting the out-of-date server. Doing a page reload and getting old data is still possible. Perhaps affinity per-session for a single server is another solution.

There are a number of good, or at least curious, project ideas that leverage city datasets. What is keeping these projects from being implemented in 30 minutes?

Common attributes of the project ideas are:

• A set or sets of records. Usually with a geographic coordinate
• Displaying the set on a map, given the bounds of the map and additional criteria

Wikis are great for crowdsoucing content creation. Wiki pages have an identifier in a single namespace and their content is free-form. A structured wiki could use tags for hierarchies of pages and a container/key/value structure as content. The document style datastores are an obvious choice for storage. The HTML for CRUD operations fall out of the content of the document itself.

Whats left is markup for query pages and pages that represent an aggregate of data. There are a variety of simplified markup languages for formatting text. If one were extended to build an HTML form, that would help with searches. Aggregating results needs a programming language.

I came across a blog post about how a runner who was using a location tracking tool was hit by a car and was fascinated by the track that had continued to be created after the crash.

The software tracked time per mile. Miles 1-4 were average riding speed. Mile 5 was the site of the accident and 20 minutes elapsed while emergency services were arriving. Miles 6-9 were fast car speed as the cyclist was transported to the hospital.

This is an example of continuous location tracking, so naturally it caught my attention. The blog post mostly goes on about map routes and times. If the person were using IceCondor, they would have a map of their entire day, though with less accuracy than the running-tracking program. In both cases, the result seems to be "so what?". That by itself wasn't compelling enough to make a product.

The interesting part that emerged was the sharing, or alerting, based on the user's position. This person had some helpful bystanders to alert a responsible party. It was a human, but manual process.

"What I didn't realize was that Runkeeper kept going in the background as I lay there, as a very kind bystander used my phone to call my wife and let her know what was happening, and then as I was put into an ambulance and rushed to the hospital."

Even more interesting was the comments:

"The data you can gather from this application is very interesting. Last sunday I started my training as a sailplane pilot, and I tracked my first flight. It's a shame altitude wasn't configured correctly in my iPhone but nonetheless, the visualization of the track in Google Maps is really appealing."

"I use CycleMeter but it sounds pretty much the same. I have it email updates to my wife every 5 miles. After reading this I think I'll change it to every 1 mile."

"Both my husband and I bike and run and we both have the elite program. In June of this year he suffered a heart attack. Thankfully he was not running at the time. But if he had been, I would have know exactly where he was because we can track each other on our computers. I often have to run alone due to our schedules, yet since he is in an office, I know that he is tracking me. RK IS NOT AN OPTION...it is a necessity. "

When cell phones started getting popular, it became a common reason to buy one simply to put in the glove compartment "for emergencies." Many people considered it a no-brainer safety precaution. I believe continuous location tracking will be given the same consideration and this blog post is a nice bit of encouragement.

As far as automatic notification for such an emergency, one solution is having geofences around hospitals in the area. Simply being at a hospital (for most people) is indicator enough to start alerting people so they can determine if there is a situation that needs attention.