If it can be measured, it can be improved.
Everyday we are living our lives. Immediate goals such as getting dressed, or making it to work on time, have their own motivation. Goals beyond the here and now take focus and dedication. Setting up feedback loops help - information on our progress can be motivating when we fall behind. Giving the right suggestion at the right time can be particularly effective. Part of this project is to look at identifying teachable moments and guiding the subject to the shorter path to their goals. Software/algorithms have the potential to turn streams of data into personal, relevant suggestions.
The inputs coming into the software should be diverse. Location is a personal favorite because of everything that can be deduced from time and location together. Purchases of all kinds are a very influential moment if one can be reached at the moment just before purchasing. This is especially true of purchasing food. Reminding one of the larger goals of healthy eating or staying within a budget can overcome an impulse purchase.
Inputs should be as timely, automatic and unintrusive as possible. All the data generated by someone from a cellphone and laptop computer can be cataloged and classified. Ownership and privacy are a critical concern. The benefits will be compelling enough to cautiously proceed with such collection.
Many inputs will not be available automatically, so a simple user interface will be important to collect this data. Examples are general mood, what is being considered for a purchase, or the kind of experience one wants to create in the next half day.
The cell phone or bluetooth earpiece or headset (google glass) is the avenue here. The software needs an avenue to intentionally interrupt what you're doing because the time seems right for a relevant suggestion.
If at the end of the month, by inputting data and considering suggestions, it feels like things are going better than they were before, or maybe better than they ever have been, then the system will be working.
The IRC channel I'm in most of the time has a karma system.
#pdxtech:someone> donpdonp++ #pdxtech:karmabot> donpdonp has 13 karma
With the rise of dogecoin, its a useful experimentation platform. There are way more coins and they cost next to nothing so its simple to experiment with micropayments in whole.
The giving of karma remains the same. A new bot talks to a dogecoind process to get the pool total and issue payments. There are a variety of systems to allocate payment. What I am going with is to calculate each user's karma percentage of the total, then use that percentage against a daily payout total.
Karma is payed out every night, also if a payment happens, that user's karma is cut in half. The goal is to provide some kick-back for a short amount of time, then reduce to zero until the next karma is earned.
update Mar-2014: the karma system is implemented in simplified form. a single doge is given out (recently raised to 5 doge) for each karma awarded, with a cap of 3 karmas per hour.
LittleBird. Rails contracting.Apr/ May / Jun/ Jul/ Aug/ Sep
CoinThink scripting.Nov/ Dec
- temp <wunderground station name>
display the last temperature reading for this station. also monitors the temp of a default portland station every 10 minutes and alerts when the temperature goes below freezing. also remember last-used station on a per-user basis to report the best station for that user with just 'temp'.
- noaa <zone name>
display any published alerts for this zone
- temp <wunderground station name>
coindesk pulls in the rss feed via this handy google rss to json service
watches the mtgox price for swings larger than 5% inside 60 minutes (10 min poll)
query the spacepeople api every 10 minutes for changes to the list of people in space
monitor the github status json url and publish any change notices
search calagator for matching events
monitor the conversation for long urls and post a shortened one via is.gd
You receive an unexpected, non-descript box in the mail.
In the box is a card and a set of instructions that enable membership in a special group of coders. Coders that work around the world and are backed by a foundation that allows for travel and project experimentation.
The card is a creditcard sized device with 'codename' on the front. An embedded NFC chip holds an encryption key. The instruction sheet has a URL that will load an Android app which can read the card and use the key.
One of the instruction steps is to order a debit card from the Google Wallet service. Deposits to your wallet from the foundation enable you to work from remote locations by paying for airfare, lodging, and food.
In the most official act yet for cointhink.com, a post was made to the bitcointalk forums. This is the culmination of 7 months of effort on this project. Cointhink was built to bring automation to bitcoin market customers. A variety of trading algorithms can be evaluated based on profitability using live market data (MtGox).
After given each script an initial purse and implementing simulated trades, the next logical step was a leaderboard. This adds an element of gamification to the scripts. The best-performing scripts show up at the top of the leaderboard. The usual BTC/USD arbitrage chart is still there, too.
In July 2011, I started an irc bot (donpdonp/neuronirc) because irc provides a simple yet powerful human-to-human and human-to-computer interface. It was built on the principle of loosely coupled, coordinated processes.
The foundation of the coordination is the redis pub/sub mechanism. Messages encoded in JSON are sent over pub/sub channels to interested listeners. There is redis support for nearly every language, therefore an extension to the bot can exist in nearly any language even though the core of the bot is in ruby.
This setup was working well but didn't go quite far enough. While new functionality or 'modules' was now possible in any language, the creation of and launching of new modules required significant administrator intervention. The users or participants in the channel could surely contribute their own useful code to the irc bot and I wanted a way to capture those contributions easily, without administrator intervention
Users in an irc chatroom could now give code to the bot to extend its functionalities. I started to use it all the time because it was simple and fast to add a new command to the bot's inventory. Some script management commands were added to make it easier to list your scripts, delete one of them, and create a script from the contents of a url (usualy a github gist). Script complexity ranged from simple to complex.
Now that there are 20-something scripts inside the neuronbot (called zrobo on #pdxtech/freenode), I forget about scripts that I've wrote in the past. Many of them are periodically executing. That starts to feel like sci-fi. I can read and understand any single script, but the entire system is starting to grow beyond my ability to comprehend.
Scripts listen for messages and messages have types. Most often the type is a new line of text from an irc chatroom. That has a particular type. It was a huge leap forward when a new type of message started to be emitted once a minute. Thats a message indicating a change in time, which enables scripts to run periodically. This month scripts have the ability to emit their own messages. This lets complexity be distributed across multiple scripts. One script can be dedicated to monitoring a feed of some sort, such as the weather or a bitcoin marketplace. When conditions are right, a signal is emitted and another script can take action based on that.
Another area of exploration is to standardize the message format amongst different irc bots, and use an irc channel as a bus for messages between bots.
Modern websites are web services with an html front end. Web services need to be easy to manage and easy to scale. The variety of ways to architect these features is a never ending playground of possibilities. Below is a description of features and current thinking on how to achieve those features.
Easily scale up or down the group of virtual machines that provides the service. Any one server should be able to be removed without affecting the service. tool: libcloud Add more compute nodes programatically, even across different VPS providers.
Rather than handling an HTTP request, the request goes into a queue. Workers on different VMs pull jobs off the queue. Different VMs are united by access to a common distributed datastore. tools: redis, mozilla circus
The bitcoin blockchain experienced a fork due to a subtle bug in the pre-0.8 bitcoin app. The 0.8 version was being used by a majority of the miners. After it had been suggested to increase the maximum blocksize, a large block (#225430) was generated by miners on 0.8. This large block was not processable by pre-0.8 apps. There was a significant percentage of miners on pre-0.8 and that brings us to the first, and core problem - how pre-0.8 handled the error.
Fix 1) Block 225430 was a valid block. It was the error handling of the bitcoin client that caused the problem. The hash was valid for its contents and for its place in the blockchain. The client should have been able to verify that before iteration over the transactions. It was the number of transactions that causes bdb to fail. The client should be changed to compartmentalize an exception that happens after the validity of the block is determined. When this valid block caused an error in processing after validation, the client should treat that as an irrecoverable internal error. The pre-0.8 miners and clients would have shut down and the chain would not have forked.
Fix 2) It is my understanding that all the forks exist in each client's blockchain. If so, put up a large warning that a fork exists and things may not be what they seem. The greatest let-down of this blockchain fork event is that the great promise to merchants was invalidated. Since I've been using bitcoin, the mantra has been that after 3, and at most 6, confirmations, it was statistically impossible to get a false-positive on a transaction. Thats true for a single chain. The large, now infamous, payment made on the 0.8fork that was simply un-done out of thin air when the pre-0.8 chain achieved the most length, showed that iron-clad agreement to be false. If the app could warn the user of the existence of a fork, then they'd have a chance to investigate further.