RSS Feed

Thomas Ross Hallock

My implementation of Tonobeb – a board game played with dice

10-April 2011

Back in 1983, my uncle Bruce came up with a fun board game played with dice. My dad made a nice wooden board for it and Bruce got a write-up of the the game published in Gameplay Magazine. Fast forward to 2006 and I made a playable web version of the game; it was the first web application that I finished, and even now, I’m a bit impressed in using it. This pre-dates jQuery, so please savor the library-free hand-coded javascript ajaxy goodness. Without further ado, I present Web Tonobeb:

If someone else loads this page at the same time as you, you will be matched with them automatically. Alternatively, you can challenge a friend by e-mail.

I just open sourced Web Tonobeb on github; I probably won’t have much time to turn it into something that Yahoo games would want to acquire, but you might! Clone away!

A proof of concept HTML + JS-based distributed computing platform

10-October 2009

[update] Just fixed a bug that was preventing this from working in most browsers. Go ahead and give it a try now.
distributed browser based Mandelbrot set rendererI made this browser-based Mandelbrot set zoomer for Yahoo’s Open Hack Day NYC 2009. It is built in HTML + JS and will use the browser of anyone that has the page loaded to construct fractal images for other users that are also viewing the page. Click on the large image to zoom deeper and deeper. It works best in Safari 4, okay in Firefox 3.

This is a proof of concept of portable browser-based distributed computing. (It even runs on iPhone.) The web server will ask your browser to render a specific square on the complex plane onto a canvas. Your browser will then submit the rendered square by turning the canvas into a data URL and posting it to the server’s cache. At the same time, your browser is requesting that the server send out render requests for all squares necessary to make up your current view of the complex plane. These requests may be rendered by your browser, or they may be rendered by another user’s browser that currently has the page running. Load it up on two or three computers at the same time and you’ll notice a significant increase when rendering parts of the fractal. The server caches the tiles, so browse to an obscure part of the fractal to make sure that the system is actually sending requests to the swarm. You can see the last square that your browser rendered just below the large square.

This technique can be used for a specific type of problem where the information that describes the problem and the result is significantly lighter-weight than the computation required to solve it. Specifically, this would also work well for a web-based ray-tracer.

This idea was partially inspired by Resig’s Test Swarm service that distributes front-end toolkit testing to any user that hits the site with their browser.

San Francisco timeline / skyline wallpaper

25-September 2009

After looking at traffic coming to thesellery.com, I noticed that many of the requests were for a desktop picture that I made a couple of years ago. It’s a picture of the San Francisco skyline that fades from the olden days to 1971.

Here it is in 1440 x 900:

The original 1971 version is available on Brad Templeton’s website.

[update] After googling around a bit, I found this page. It offers a MySpace theme ready to copy and paste. Guess what the background image is? Guess whose server is being used to host that background image? Chances are that there are quite a few MySpace pages that are linking directly to this image, which would explain the steady hit-rate for this image that I’ve noticed over the past few months. I’m seriously thinking about telling my server to redirect requests from MySpace to something that’s not quite so G-rated :)

Life after 40; W3C compliance, IPv6, cloud policy, and open APIs

7-September 2009

My hipper-than-thou grandmother asked for comments on this article provoked by the 40th anniversary of the internet and the issues regarding the erosion of the openness that the internet was founded on.

So, here are four things that I’m looking forward to, or concerned about that are in the internet’s immediate future:

full standards compliance across web browsers

Web standards are becoming stronger. The latest versions of all the major web browsers support HTML 5 to some extent, and are all relatively standards compliant. The popularity of older versions of Microsoft Internet Explorer put application development into a dark age that spanned almost a decade. Internet Explorer was not standards compliant, so it made it very difficult make web applications that worked the same way on other browsers like Firefox and Safari.

The web is more standards-compliant than it ever has been, and as people and IT departments get around to upgrade their browsers, innovation on the web will flourish in ways that we have not yet seen. This is a very good thing.

Saturation of IPv4 will force rapid adoption of IPv6

The article references difficulties that some developers experience with getting applications to talk to each other across internal company networks. The inevitable coming of IP6 will make this less of an issue. IP is the addressing system used on the internet that identifies each machine on the network. All internet-connected machines use IP version 4 (IPv4), but we are approaching a point where the number of machines connected to the internet will be greater than the number of addresses that IPv4 can uniquely identify. Wikipedia says that all IPv4 addresses will be used up some time in 2010.

The IPv4 problem is the equivalent of a neighborhood policy stating that house numbers can only have three digits, and there is demand for over 1000 houses to be in the neighborhood. This creates a supply vs. demand situation, so the price of IPv4 addresses will increase as more and more of them are needed as the internet grows.

The address space problem has been mitigated to some extent by using a technique called NAT (we use it at the Old Homestead). NAT (Network Address Translation) allows a sub-network of machines to communicate with the internet using a single public IP address. While it mitigates the IPv4 address shortage problem, NAT makes it a bit more difficult to establish point-to-point communication between two computers that are each behind a NAT gateway. So, instead of making software that works like this: (computer A) <--> (computer B), you have software that works like this: (computer A) <--> (service provider) <--> (computer B). NAT is the reason behind a significant number of providers of internet services; it allows them to act as, and in some cases charge for being an intermediary between you and whoever you are trying to connect to. Services like Vonage, GoToMyPC, WebEx, and Skype come to mind as I’m writing this.

To summarize, the limits of IPv4 have made it expensive to uniquely identify computers on the internet, and have fostered a genre of companies that act as an unnecessary middle-man to many online services to solve this problem.

IPv6 solves the address space problem completely; IPv6 allows for enough addresses to uniquely identify every atom in the universe. In an ideal scenario, ISPs would offer an unlimited number of IPv6 addresses to their customers, allowing them to address their machines from anywhere without the need of a third party. The middle-man companies would have to change their business model or go out of business, and a new type of peer-to-peer software would blossom and bring about all sorts of new innovative applications to the internet. There are security implications that go along with this new model of communication, so we end up with the classic toss-up of availability vs. security, but that’s a choice that I would like to have.

We may also see new hardware applications that leverage the increased network availability that IPv6 brings for things that are currently considered too trivial for network connectivity. For example, controllable light switches that can report that they are left on, and temperature sensors that can tell you if you need to start your A/C or heater before you come home.

Two more things and I’m done:

Cloud services

Google, Amazon, and Microsoft all offer cloud services that promise nearly unlimited scaling and reliability for hosted web applications. This is great, but it also leads to centralization of policy between only a few companies, which may end up stifling innovation if the company that owns the cloud decides to prohibit services that compete against the ones that they already offer. This has not proved to be a problem yet, but this issue parallels the net neutrality debate and controversies around Apple’s iPhone app store to some extent.

Open APIs

Many services, big and small, eBay, Google, UPS, and FaceBook, just to name a few, are “opening up” their platform using standards like SOAP, REST, or plain XML. This means that they are releasing formal specifications that tell people like myself how to write software that interacts with their service and extend it in ways that the company hasn’t yet anticipated. In an interesting twist on the idea of using standards to open platforms, the RSSCloud project proposes using RSS in an innovative way to replace centralized messaging services like twitter and Facebook.

turning the premailer interface invisible

28-August 2009

[update: looks like premailer changed their interface a little,
which broke my domain-level meta-interface for it. I'll fix it sometime, just not now :(]

Premailer is a nifty ruby script that turns most of the css from external stylesheets and style blocks into inline css on each element. This is useful if you want to be sure that HTML e-mails will remain mostly in-tact in the viewer’s mail client.

It’s a great script, but the interface could be better… and by better, I mean invisible. … so I bought the domain inlinecss.com and made it work with premailer and your URLs. No interface required; just add .inlinecss.com after the TLD in the URL of the page that you want to inline, and the site will mirror the inlined version of your page.

For example, to inline google.com, turn http://google.com/ into http://google.com.inlinecss.com/

refracting magnifying glass effect with Javascript

20-March 2009

After playing with this code and this demo of a javascript mouseover zoom effect, I decided to take the magnifying glass effect one step further and add some refraction:

It uses concentric images placed on top of each other to achieve the illusion. Paste in a URL to any image you want and you can play with it. It’s in an iframe, so you’ll have to dig a little if you want the source; it’s pretty ugly right now.

Beautiful: GMail’s filters and lack of folders

17-March 2009

picture-31I was setting up a GMail filter today and noticed something unique about the way the filters are designed: it’s impossible to create one filter that conflicts with another. This allows the user to not have to worry about the order of application of the filters. Beautiful!

This is mostly thanks to GMail’s use of labels instead of folders. Every other e-mail client that I’ve used: Mail.app, Eudora, Outlook, Zimbra, and Thunderbird, all (or need to have) a way to assign a priority to filters to specify which filter has the last say with your messages. For example, one filter might move a message to folder A, but if the message is also matched by a filter that moves messages to folder B, then the first filter’s action is undone. When filters move messages to folders, it becomes important which filter was applied last. Using labels instead of folders, each filter just adds to the message’s list of labels, so it does not matter which order they were applied in.

The rest of the actions, like “Forward it to:”, “Never send it to Spam”, “Mark as read”, “Archive it”, and “Star it” all have this same property; they can all be done without undoing the effects of the previously applied filter. The only action that kind of breaks this rule is “Delete it”, which gives some insight into GMail’s initial hesitation to allow users to delete messages when GMail first rolled out.