For the record, here's a synopsis of some older projects and writing I started elsewhere. The first three at least are still pretty relevant:

• Making maps with WebGL — this demo still gets praise when "geo" people see it for the first time. I used GPU-accelerated cartographic projection and texturing to animate a shape-changing map.

• Using the REST interface as the JavaScript interface with Fermata — I've still been using and improving Fermata as my go-to AJAX/REST/HTTP library both for clientside (often bridging between CouchDB views and D3.js visualizations) and node.js (usually talking to other web APIs).

• Using a job management system to process geodata — although I'm not using this post's particular system, with Argyle Tiles underway I've been dealing with an even larger volume of geodata again.

• Unsafe at Certain Speeds: Dangers Designed into Django — tips and concerns architecting secure-by-design Django apps.

• Choosing a template language(s) — doesn't actually give you a comparison between current template engines, more of a high-level overview.

Last week I began publicly launching Argyle Tiles, and it's been getting closer to beta nearly every day since.

I'm gradually gathering as much good-looking aerial and satellite imagery as I can, and turning it into tiles for those "slippy maps" you see in more and more web/mobile apps these days. There are several great ways to turn OSM data into custom-themed street maps, but sometimes a product needs visual imagery too. That's a lot of data to host and keep improving just for one app.

It's challenging, but I'm pressing forward because it feels like somebody should. I'll need to find enough other developers/companies who are willing to share in the costs to make this sustainable, but the nice thing about building out global tile coverage is I can start "lo-fi" and grow with whatever budget the service can earn.

Argyle Tiles won't be hiring a fleet of airplanes to turn the entire globe into a high-resolution 3D facsimile of itself, or sending an army of expensive camera backpacks to far away places, any time soon. Maybe someday, but we've gotta start somewhere. For my part, I intend to make and keep this service as truly open as possible. I really want for a map tile downloaded from our server to be yours: to keep, to remix, or I guess even to resell if you must.

For now I'll be starting with existing public domain data. Even that will take some time and revenue to build out fully (and beautifully), but I'll at least be able to offer basic global coverage at relatively low resolution, and full coverage of the United States at pretty amazing detail. If you or a company you know (or hey, even just an app you use!) needs a "satellite" base in their map but their product doesn't fit contractually or philosophically within the restrictions of the bigger commercial providers, please let me know.

I've tried to explain this many times to myself, to clients and to peers. And will try again to explain it here.

Various types of Couch

I suppose you could call these subspecies.

Apache CouchDB

Started life as Lotus Notes built of the web.

It is "a database that uses JSON for documents, JavaScript for MapReduce queries, and regular HTTP for an API". Masterless synchronization is a very important part of its DNA, and I'd also note its ability to attach arbitrary binary files to said JSON documents.

Use for:

• all your NoSQL needs, or…
• prototyping, casual app hosting
• de-facto standard for peer-to-peer replication

Riak

No relation, not relevant, not capable of interbreeding. Happens to resemble CouchDB enough to merit a brief mention.

Use for:

• all your NoSQL needs, when…
• …you're not interested in CouchDB, but want a reliable document store that speaks JSON over HTTP

BigCouch

Apache CouchDB plus scalability (via Dynamo-style clustering).

Use for:

• bigger datasets and/or greater uptime

TouchDB

Apache CouchDB minus scalability (currently lacks certain storage and concurrency optimizations)

Use for:

• not-too-big datasets in native apps (Android, iPhone, Mac)

PouchDB

Apache CouchDB in the browser.

Use for:

• offline Chrome and/or Firefox webapps

Couchbase 2.0

1. is still Membase, and has nothing at all in common with Apache CouchDB
2. except it will provide the same MapReduce/GeoCouch view features via the same API calls
3. (actually via a heavily modified fork of Apache CouchDB — consider this an implementation detail)
4. except it may be replication-compatible with TouchDB (and therefore CouchDB!) via a "Syncpoint" bridge
5. (actually includes the efforts of many past/present Apache CouchDB contributors — consider this too an implementation detail)

Use for:

• all your NoSQL needs, and…
• speed and scalability
• also, did I mention speed and scalability?

So what is a Couch?

Uhh.

It seems, at its core, a Couch is a non-atomic collection of atomic JSON documents. Each document has a unique identity, and a sequential list of changes to a given set of these documents is always available.

This core enables two common extensions:

1. Masterless, eventually consistent replication between any two such collections
2. Incremental (asynchronous) indexing of a collection, usually via "map" and "reduce" functions, usually defined by JavaScript code

The first extension — peer-to-peer synchronization! — is the most interesting. The second extension is related to the first — because of the simple/powerful syncability of a collection's changes feed, we can decouple the practical "optimized access" indexing options from the core collecting of data.

Above this core are where most of the differences lie. Does this collection contain data from multiple users, or just one? Will a collection live redundantly across multiple servers, or be self-contained on just one? Will a user have direct access to this collection of data, or use it only through a middleware layer? Does this data include access control and indexing methods and display logic, or is that outside the scope of a database?

In my opinion, direct bi-directional access to my own data via a standard peer-to-peer synchronization protocol is the most alluring, most important, feature of a Couch. However, implementing this in practice foists all manner of odd questions and unusual concerns upon the database layer. The Apache CouchDB project has managed some very creative solutions to perhaps 90% of these problems, but the solving the next 90% will test the community's (communities'?) mettle.

And why does this matter.

Imagine a world.

Where you don't need to give your data to a big corporation, to have it on all your little devices.

Where you don't need to take your data out of one app, to use it in another.

Where you don't need all your data, but it doesn't hurt to keep it.

Is this terribly important? Maybe maybe not.

At all likely? No.

Worth investigating?

I think so. And the Couch ecosystem provides a great foundation for trying.

Hippie.

So all this data freedom mumbo-jumbo is for paranoid people who hate business models and don't believe in economies of scale.

Learning/knowing/understanding the Couch model is still important. It will improve the way you think about data. It will improve the way you manage state. It will improve your architecture.

The Couch ecosystem is still young, and it is becoming kind of a mess. But the diversity within this particular species of "NoSQL database" is an indication of how resilient the DNA in its nucleus is. Its core model is solid enough in theory and simple enough in practice that we already see a baseline of interoperability between Couches of all shapes and sizes.

Ignore all the magic unicorn webscale utopia stuff, pretend most versions aren't nearly impossible to compile, pretend the best API documentation isn't trapped in narrative form, and give CouchDB a try anyway. Then something something…relax! Okay.

Consider this post a Part One, of ???.

I decided that I won't accept a world where everyone owes the phone company around $1000 a year just for access to the internet between destinations. Especially not when (as marketed, anyways) the lion's share of that mound of cash is for fancy sounding things I have little use for. Like "Unlimited Audio Chat Minutes" and "Hidden Charges We Pretend Are Taxes".

Anyway, the industry codeword for the alternate universe in which this exists is: pre-paid. Or perhaps "live outside North America" but my experience there is limited.

AT&T GoPhone

I was originally planning on using AT&T's GoPhone service, as I could buy a $15–25 data package and just pay 10¢ a minute when using the audio chat app built-in to my iPhone. However, it turns out that, while in no uncertain terms must a carrier let you take your phone number along to another service, trying to move a number to a cheaper offering within a provider is not something AT&T seems to feel like doing.

By the time I got that issue off the table, GoPhone had changed their pricing structure so that the aforementioned data packages were only available with a more-minutes-than-I-use-in-a-year monthly voice plan. Effectively, they raised the price of their prepaid data service by $25 month and probably without shedding any tears either.

Note that this is still a slightly better deal than normal: if you were to buy iPhone off-contract — doesn't even need to be unlocked, since GoPhone is an AT&T SIM — just needs a configuration profile installed — you could save well over $350 a year with this plan.

I'm not going to attempt to extensively document the process. Some reps are very helpful and sympathetic, others pretty much will only do what the next step in their customer service flowchart says. The main trick is to avoid saying anything that rhymes with "iPhone" and firmly play your "do you want my money in exchange for a prepaid MicroSIM or not?" card.

T-Mobile Monthly4G

Since my goal was to waste not significantly more than $30/month on keeping my iPhone from being just an iPod touch. T-Mobile has the perfect pre-paid plan for this. I recommend this article outlining the process, and there are other guides. If you have an unlocked iPhone, it's not much harder to get the basics working than with GoPhone.

Except.

T-Mobile does not have 3G, as far as the iPhone is concerned. This may be changing, but that's a forward-looking statement with no promises attached. Three cheers if it comes to the Tri-Cities and I'm still on T-Mobile, but I'm not holding my breath meanwhile.

Fact is, EDGE works and I'm content enough with it. I've tweeted, emailed, looked up directions and/or gotten my bearings, even downloaded some decent-sized attachments. It's rare I really absolutely need to watch YouTube in the grocery store parking lot.

Oh, and the other reason I'm happy to be content with this situation.

Tethering ("Personal Hotspot") also works with this $30/month plan! I'm not sure if it's supposed to or what, but I sure don't feel guilty using it via EDGE speeds on an "Unlimited 4G" plan, and it's quite a nice perk.

Twilio

Remember how I had to sort out my number porting issues? Well...at a certain point in the process I decided to stop wasting time on hold just to be told "you can't, not available, we can't" by most AT&T reps. I had a number I liked, so I've entrusted it to Twilio.

Using Twilio is gonna be fun. After a bit of disconcerting radio silence during the initial port (which they apologized for profusely and quickly remedied), they dealt with AT&T's bureaucracy and turned my phone number into an API. Yes, that's right. By gluing together REST calls and callbacks I can pretty much handle calls however I want. Forward to my phone, email myself voicemail as an MP3, turn on a teapot via SMS, set up a call center, or help a bazillion of us poor proles lobby Congress's switchboard that they PLS TO STOP RUINING AMERICA. (I've only personally set up the first one so far.)

There's a few downsides to the way I've currently got it set up, but I haven't even gone beyond the basic "Twimlet" stage of playing with it.

Current downsides, for the record:

• outgoing calls come from (architecturally) temporary number
• forwarded SMS messages must come from my own number rather than the original sender
• can't receive MMS (Twilio simply does not have MMS support. Personally, I've mostly only used MMS to test MMS.)

However, with just a little bit more code, almost all of these can be solved at least as well as Google Voice handles them. If not much much better.

AT&T Tablet Data?

There's another alternative I may look into at some point, especially if I end up needing to work frequently away from someone's home/office/coffeeshop. (But again...even an EDGE connection feels about as fast as airport WiFi, and fetching the important stuff like API documentation, Wikipedia and such works well enough.) AT&T has a "tablet data" plans that give you a decent scoop of internet for a not-indecent amount of your retirement contribution. And Twilio has an iOS client library.

Q. Are you thinking what I'm thinking? A. I dunno Brain, but have you heard about Apple's new $350 iPod touch 3G?

Narf

Another option, if you don't mind a non-iOS device, is to wait for republic wireless to take over the world. (Thanks @hjon for getting them back on my radar!) They look like a great MVNO and I'd love to imagine that one day they'll even be operating their own towers, member-owned style. One can dream. I'm just not that patient in the short term. :-)

A month or two ago I got some spam from LinkedIn offering $50 in advertising credit on their site. Since I'd just gone back to freelancing — perhaps the ad credit "offer" was not coincidental? — I figured I might as well succumb.

Succumb I did.

1. First of all, to use the $50 coupon I had to also put in like $5 or $10 of my own money up front. Lame, but what's $5 or $10 compared to science?
2. I put about 2 minutes of thought into my ad itself, and then tweaked both the image and the wording after a few days mostly because I noticed they were using like "repeatedly re-compress this JPEG until it's less than half a kilobyte" quality on my picture.
3. The ad ran April 9 to May 4 with one accidental pause for a week early on.
4. When I posted the ad, LinkedIn took the liberty of showing everyone "connected" to my profile this fact. Kinda embarrassing, but it's not like we take the site that seriously anyway… (I actually wrote this up because one of my freelance friends saw the post and asked me to share how it went.)
5. Over 215k impressions, 43 clicks and 2 "leads"
6. …basically a "lead" is someone presses a button requesting contact. The first (accidental click? spam?) had hidden his profile or something by the time I got to it although I see it's back now but doesn't list an email address. The second (accidental click? recruiter?) didn't seem quite sure what he wanted.
7. LinkedIn did NOT stop my ad campaign when my account balance ran out...instead they kept billing. I emailed support demanding a refund, got back an almost smarmy response that "that's exactly what our fine print promises" but seemed to imply I would get a refund out of the Generosity Of Their Heart. (We're not talking tons of money, maybe $20 or so....it's kinda hard to sort out what money was extra vs. the initial I-don't-know how much balance I had to add to use the coupon)
8. Overall a very solid "meh" — corroborates with what I heard back in my shareware days that Advertising ⋘ Customer Satisfaction/Networking/Marketing/Product. Maybe if you knew what you're doing i.e. a degree in business/marketing, but my "Impressions" is that I paid the Sucker Tax on this one.

Here's the targeting parameters I set:

In the aforementioned Mac/iPhone shareware days at Calf Trail, we let Google run something like a buck a month in ads — search only, not their "extended network" which I've heard is pretty much dominated by spam farms and scraper sites that may even run up completely fraudulent clicks. It was kinda fun to see mine turn up when I searched for the terms, but my gut feel is that it did zilch for brand/product awareness or anything like that. Maybe should have advertised on complementary terms instead of people already in the market, but...who looks at ads if they can help it anyway?

The moral of the story is that I confirmed my bias, and remain a believer in ads being as much of a leech on me as a producer as they are on me as a consumer. For science.