I released a small php script for easily handling geodata in couchdb via php a while ago, check it out here. I also put together a short tutorial on how to integrate this script in your CakePHP application. The article is available here on the CakePHP Bakery.
PhoneGap currently has an issue with the keyboard not appearing whenever a form input is selected on a web site. The key here is that the keyboard IS actually showing up, but it is being drawn behind the UIWebView used to render the webpage.
Here’s the solution I came up with. I don’t understand enough about the rendering heirarchy to explain the why, but here’s the how:
In the GlassAppDelegate.m source file you should see a block of code that looks like the following:
// Set up the image picker controller and add it to the view
Simply move this block of code BELOW the following line. This renders the imagePicker object after the web view.
webView.delegate = self;
Problem - the imagePicker is obscuring the web view! Simply add the statment imagePickerController.view.hidden = YES; to the above block of code so that the entire block looks like:
// Set up the image picker controller and add it to the view
As it sounds like, we are just hiding the imagePickerController’s view - we don’t need it when the application starts anyways. But, we do need it when we access the images API through javascript, so find the block:
Recently, I’ve been working on a project that requires a lot of geocoding. Google provides a free service that takes any string as an input and returns a bunch of JSON encoded data if that string matches a physical location. Check it out here.
Unfortunately, Google’s geocoding service is limited to 15k requests per day per IP. Sounds like a lot, but for certain applications this limit can be reached very quickly.
What’s a good solution in these cases? Why, how about use my favorite up-and-coming database, CouchDB, to store a repository of geo-data mined from Google? Why use CouchDB? As previously mentioned, google natively return JSON data for geocoding requests. Perfect. CouchDB just happens to store documents natively in JSON!
The following is a rough and tumble library I put together called GeoCouch that you can use to easily handle geocoded data in CouchDB. This lib has a narrow scope right now - the requirements are:
I call this my erlang playground instance. Here’s what’s installed:
Ubuntu Server Hardy 8.0.4
Apache 2 listening to port 80
Erlang R12B-3
CouchDB 0.8 listening to port 5984
Yaws v1.76 listening to port 8080
MochiWeb Library
The instance ID is ami-12ae4a7b and I’ve made it public so feel free to use it to your hearts content!
I plan to add to this instance whenever I find time. I definitely want to get SSL socket communication going using this tutorial. I’m also interested in Kevin’s virtuerl project over a hypotheticalabs for quick and easy VM management because the whole reason I’m going through the trouble of doing this on EC2 is I think development on any erlang system should start and end with multiple physical machines.
Lately I’ve been thinking a lot about this new-fangled contraption, Document Oriented Databases. Ok, so maybe these aren’t that new-fangled - Lotus Notes is a document oriented database and it’s been around for 20 years or so. But, they’re new-fangled to me; my experience to date has solely been with relational databases.
So what is a Document Oriented Database? Actually, just what it sounds like - a data store whose primary unit is a document. A document can be anything, usually a collection of key-value pairs that describe something, anything… it’s really that simple, really no different than a Microsoft Word document…
Just had a funny thought since CouchDB and Erlang have been on my mind so much lately. Everyone’s familiar with the LAMP and WISC stacks, right? (Linux, Apache, MySQL, PHP and Windows, IIS, SQLServer, C# from those of you who aren’t)
Could the next big stack to hit mainstream be LYCE - Linux, Yaws, CouchDB, and Erlang?
Given that scalability is such a huge issue right now, and Elastic/Cloud computing is almost certainly the next big infrastructure movement, I certainly think at least Erlang and CouchDB will go mainstream.
Another variant could be LYSE - Linux, Yaws, SimpleDB, and Erlang.
One Apache project I find very interesting right now is CouchDB. From the site:
Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. Among other features, it provides robust, incremental replication with bi-directional conflict detection and resolution, and is queryable and indexable using a table-oriented view engine with JavaScript acting as the default view definition language.
Why is it interesting?
Schema-free - as a web app developer, I can relate to anyone who has had frustration or is fed up with managing and maintaining schemas. CouchDB offers a document-based system where each document in the database is loosely related. This means no more schemas to update and manage - simply throw new data into the database. How do I retrieve data that is related to each other? That’s a topic for another conversation, but this’ll get you started. Scroll to the section titled, ‘Views’.
RESTful HTTP/JSON API - JSON is quickly becoming a powerhouse as a data-transfer mechanism. Combined with the principles of REST and accessed through HTTP, querying a CouchDB will be familiar to anyone who’s worked with data-driven applications in Adobe’s Flex technology. At Figaro Interactive, that’s pretty much all we do, so CouchDB fits right into our workflow!
There are more reasons why I’m excitedly watching the CouchDB project, but I’ll save them for a later post. I just wanted to drop a quick line and increase awareness of this pretty cool project.