MongoDB provides document-oriented storage, with replication, indexing and rich query support. It blends aspects of distributed key-value stores by keeping most of the data in memory, pulls in fine-grained indexing and query language reminiscent of relational databases, provides map-reduce support for data processing similar to Big Table, while optimizing for fast in-place modifications. In the near term, it will provide horizontal scaling and sharding.
The tradeoff for MongoDB is in lack of transactions and being not fully ACID. This means MongoDB does not offer single-server durability. Data is only eventually consistent. Due to filesystem operational choices (fsync vs. append-only writes, commit log, etc.) MongoDB can lose data during hard server loss.
Realizing all theses aspects, why did I choose to go with MongoDB?
A few weeks ago, I looked up Twilio in conjunction with a telephony project. I was intrigued by the promise of a simple REST web API for building SMS and voice based interactions within web apps. In prototyping, I ended up developing a Rails plugin called Twilioflow which allows simplified development and testing of telephony apps.
Having spent some time at AT&T/Lucent Bell Labs, I had heard my share of war stories from the programmers and managers who worked on the venerable Audix system. From that perspective, Twilio is yet another example of creative destruction made possible by improvements in the general purpose computing platform coupled with an extensible network protocol (HTTP). Operationally, Twilio goes even further by harnessing Amazon's EC2 infrastructure and we can be sure they have numerous other tricks up their sleeve.
Two years ago, over the summer, I put out several social games on Facebook, Hi5 and Orkut.
It was fun to brainstorm ideas, get something out, and watch the rush of users hitting your servers. The whole process of maintaining, updating and expanding your apps and increasing user engagement was instructive. Another bonus was understanding the intricacies of building on top of other platforms and the headaches of dealing with ever-changing API and policies. In short, it was a great experience.
Experience is what you get, when you didn't get what you wanted.
Within just 3 months into the new year, the TiE Oregon SW & Internet group has organized two great events for entrepreneurs, gathering together six successful veterans who shared their stories, recounted lessons learned, mistakes made and the opportunities taken. Both events were packed with an engaged audience, resulting in informative and honest Q&A.
The first event in February featured Nitin Khanna, former Chairman and CEO of Saber Corp, Sudhir Bhagwan, former Chairman and CEO of SnapNames and Matthew Compton, then venture partner at Madrona and now CEO at ShopIgniter. That discussion was about getting big and growing fast with venture capital, and was covered by the Oregon Business magazine. The second event held yesterday was focused on bootstrapping your startup into generating solid profits, and included Mona Westhaver, President of Inspiration Software, Taizoon Doctor, former CEO of Xovix and Ryan Buchanan, CEO of eROI. Both of these events were hosted by Brent Bullock at Perkins Cooie who did a splendid job of moderating and directing the flow of discussion, as well as elaborating on some of the legal aspects to issues faced by the panelists. Starting Out For those wondering about starting out, there were three diverse beginnings, each with a unique mindset.
This weekend, tens of thousands will get their hands on the iPad. Several people have been playing with it already. John Doerr has been widely quoted with his lusty lines:
“I’ve touched it, I’ve carressed it and I hope to sleep with it this Saturday night. It’s not a big iPhone. It’s the future.”
That coupled with an announced doubling of the iFund has a lot of developers and companies considering iPad as a must-have checkbox platform and a potential moneymaker.
For most people, backing application databases is usually (touch wood) a one-way operation. You take your precautionary measures, employ some kind of hosted or scripted backup solution, and hope that you only infrequently, if ever, have to restore from an old database.
But, what if you want to take a database snapshot at any time, keep a list of such snapshots and restore at will from any of them at any time? And you want to do it from the UI? Sounds far-fetched?
Here is one scenario.
With Rails and Rake, here is how you can make your sales guy happy and get him to buy you some Mai Tais.
