natevw proudly presents:
It's the tenth Independence Day since 9/11.
Since then the government, the shadow government, the establishment and the suicide bombers have continued their fight against "democracy".
The rule of the people, by the people, for the people. Which people is in a constant state of turmoil, but it shall perish from the earth. So I must constantly defend against terrorism — against believing any mere people should have me afraid.
Freedom is a state of heart. Never forget.
In May, starting to acclimate as a freelancer, I started wondering how much client work and side projects I should consider. How many things should I be working on?
Well, most stoves have four burners. Here's what I set on in June:
ShutterStem and other personal data management apps are still lingering below (in the oven). There's a lot of infrastructure needed for most of my ideas there — not just technologic and financial, but also building with and for people who care. So it was really encouraging to participate in IndieWebCamp this past weekend, too.
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.
I suppose you could call these subspecies.
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:
No relation, not relevant, not capable of interbreeding. Happens to resemble CouchDB enough to merit a brief mention.
Use for:
Apache CouchDB plus scalability (via Dynamo-style clustering).
Use for:
Apache CouchDB minus scalability (currently lacks certain storage and concurrency optimizations)
Use for:
Apache CouchDB in the browser.
Use for:
Use for:
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:
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.
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.
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.