Archive for the 'Technology' Category

Transportable Media is Passé

August 8, 2013

I’m a student pilot and thought I would try out a flight simulator for the Mac. X-Plane has a downloadable demo but to purchase it requires DVDs. They even state that the DVD must be in your computer to run the full version.

I’ve been saying to people for a long time that transportable media is passé. Apple agrees with that having removed optical drives from their computers. My building has Webpass so I could download 200 GB in less than 5 hours according to a recent speed test. Coincidently James from an earlier post works at Webpass now. Thanks for the speediness.

X-Plane seems pretty good. I did some landings at SQL (San Carlos airport) with the demo version which didn’t include scenery for that area. I’d like to see better support for multiple monitors. My MBP with no optical drive has 2 thunderbolts and an HDMI dying to power my cockpit.

So I wait for a downloadable version. Either that or maybe the old powerbook hanging on my wall as a digital picture frame has a drive that still works.

NoDB is the new NoSQL

July 23, 2013

NoSQL was all the rage a few years ago. You could shove stuff into it with no schema and maybe have an index or two to speed queries. That simplified application design in some cases. To simplify even more consider using the NoDB pattern where there is no database!

An example of a NoDB app from a few years back was a Twitter proxy we used for caching Twitter feeds and setting up security to allow Flash access. We code named it “Twoxy.” The only input was a Twitter URL and there wasn’t a need for a database. Caching was done with memcached or a file cache and we disabled the DB in Rails with “frameworks -= ‘activerecord'”.

Clooney's

Another example of NoDB is this Sinatra app that let’s you play 1-4-24 online. The entire state of the game is stored in the session which is an encrypted cookie. No database is required to store the odds used by the AI. Initially the odds were cached-as-you-go in memory using some memoizing but are now loaded at startup.

This NoDB pattern is wonderfully simple but there are downsides. One problem can occur when storing the state in a cookie. If the app makes synchronous requests then one request may change state simply to have the state reversed by a competing request. To prevent this make serial requests or do not change cookies when they aren’t needed. Putting session state in memcached could also prevent this problem.

Another downside is there is no history or audit trail. Another downside is there’s no way to aggregate sessions e.g. a high score list. (I lied, 1-4-24 actually has a database for this purpose: Amazon’s DynamoDB. I thought DynamoDB would be super easy to setup since it has a lightweight API. However, I needed some features not available in v1 of the Ruby API and the v2 API hasn’t been streamlined too well yet. It took longer than expected but now I know more than I need to about DynamoDB).

The end result turns out to be very scalable. For gameplay I can spin up as many Heroku dynamos as needed and there will be no contention on a database. DynamoDB claims to be very  scalable so writing or reading high scores should be fine as well.