LaterLoop: Read Webpages Later on Your Phone or Anywhere

LaterLoop: Read Webpages Later on Your Phone or Anywhere:
Interesting application built with Google App Engine mentioned at Google IO -- sc
"You may not have tried it but reading webpages on your phone can work surprisingly well.

Whether you’re on the couch at home, taking the morning commute or waiting at the airport, you can catch up on your reading list whenever you have a minute or more.

LaterLoop is a free service that’s optimized for iPhones, Blackberries, Nokias and similar smartphones. LaterLoop also has a clean web interface for your regular browser."

Your own appengine

Your own appengine

My main gripe with appengine is that while you're sticking your app on a lot of iron, it's pretty much stuck there forever because of the infrastructure. Your app is not portable. You can't just take it off of Google's iron and host it yourself.

So, when I was listening to part 3 of the google app engine intro, I heard him describe BigTable as a "a distributed, fault-tolerant and schema-free", I knew I heard that before. I heard that from the CouchDB project. I never saw a need for CouchDB, but it's looking interesting now.

After looking at the SDK for appengine, the datastore interface is pretty simple, there's no reason it couldn't be implemented with CouchDB as the backend. Giving you your own "distributed, fault-tolerant and schema-free" datastore.

Also in part 3 that they run your python code on a low overhead, distributed, fault-tolerant infrastructure.. I knew I heard that before too. I heard it with the Parallel Python project.

Need a decentralized, fault-tolerant file system? There's Tahoe. Tahoo provides that too.

So let's say you have 20 servers, a mix match of database, media and http servers. Now instead of partitioning them to have their own roles, they become nodes in a cloud all handling http, appserving, media file serving and data storage.

If you create a webserver inside of parallel python that basically brokers requests for different sites to the parallel python cloud, a node in llpy then executes the request. llpy may contact the couchdb cloud. All using the power of the cloud. Therefore if you have 22 sites and only 5 get heavy traffic, you don't have to waste the power of the other 17 machines on the slow sites.

The appengine SDK looks like a start to create such a system. The datastore modules provide a way to interface CouchDB. Recreating the http brokering system with llpy shouldn't be that hard.

And once the django community finds a way to work it's ORM onto Google's datastore api (which I know they will), implementing Django inside your own parellel python/couchdb appengine wouldn't be hard.

Creating your own appengine wouldn't be for the average joe schmoe, It would be for big companies with some iron.

Worries about using GAE as a commercial platform?

18 April 2008 - Mark McLaren's Weblog: "Worries about using GAE as a commercial platform?

If I were a business with an interest in using GAE commercially, storing my valuable data in proprietary Google storage would worry me somewhat. There are open source versions of BigTable available (e.g. HBase, HyperTable) and these owe there existence to Google but as there is not yet a standard 'GQL' mechanism, data exit strategies seem limited.

I would be greatly concerned that my applications are hosted by Google and that my Python developers were exposed to Google. GAE could be described as a lobster pot. Getting Google to host your business means that Google are in a prime position to absorb successful businesses, steal talented developers, learn more about your business quicker than you can yourself and learn from your mistakes."

The GAE SWF Project at Aral Balkan

The GAE SWF Project at Aral Balkan: "Today I'm releasing The GAE SWF Project, a resource of Flash and Flex-related knowledge specifically aimed at getting you up and running quickly with Google App Engine. If you want to skip all the details and start playing with it, skip to the Getting Started section.

Everyone else, read on!

When Google announced Google App Engine last week, I couldn't believe what I was hearing. It was as if someone had said, 'Hey, Aral, tell us what your perfect development environment is and we'll build it for you.'"

Google Datastore and the shift from a RDBMS

Google Datastore and the shift from a RDBMS: "Diving into the Datastore docs to get a grip on what’s the best way to implement it shed some light on the transition any developer thinking about writing data-backed apps for GAE (Google App Engine) will need to tackle.

Some notes on terminology, Google has Entities, Kinds, and Properties. These correspond roughly to Rows, Tables, and Columns in RDBMS-speak. Kinds can also be called classes, because in the Python API, you create a class and inherit from the appropriate datastore class. Entities may also be referred to as instances, since performing a query returns a list of objects (instances)."

Google AppEngine - A Second Look | High Scalability

Google AppEngine - A Second Look | High Scalability: "It's been a few days now since GAE (Google App Engine) was released and we had our First Look. It's high time for a retrospective. Too soon? Hey, this is Internet time baby. So how is GAE doing? I did get an invite so hopefully I'll have a more experience grounded take a little later. I don't know Python and being the more methodical type it may take me a while. To perform our retrospective we'll take a look at the three sources of information available to us: actual applications in the AppGallery, blogspew, and developer issues in the forum."

Web hosted cron job schedulers

Google App Engine (GAE) currently comes without CRON scheduling support, while this is likely to change in the future I thought i would check out whats available in web-based scheduling services. These services basically make a scheduled HTTP request to your server.

Authentication to your server seems like a good idea, or at least your scripts should be hidden under very hard to guess URLs

-- MG

Review: Web hosted cron job schedulers :: chrisTHIS!: "I use DreamHost to host my blog and while it’s a great and fairly inexpensive service, there are some limitations. One is that you cannot run cron jobs without a shell account, which I do not have. A cron job is a frequently executed task, mainly used for running scripts on a frequent basis for website maintenance. While I already do this on my Windows server and I could use it for my needs here at chrisTHIS.com, I wanted to see if there was another way to schedule a cron job for the average Joe Blogger.

I set out looking for web-based cron services and found a few. Here are my reviews of each. None of these are affiliate links, nor am I associated with any of these services. I am providing my honest personal opinions. If you know of more, please let me know!"

OnlineCronServices.com: "Cron is a utility found on Linux/Unix servers used for scheduling script execution. Not all hosting providers offer access to this utility. However, webmasters and developers can still enjoy the benefits of scheduling by using an online cron service. Below is a list of cron services that are hosted remotely.

Name	Starting Price	Free Accounts	Lang.	Basic Auth.
Cron Service	4.95EUR/yr		NL
WebCron.org	n/a		FR
Web Service Scheduler	$11.88/yr		EN
WebbasedCron	$19.95/yr	trial	EN
CronService	$19.95/yr	trial	EN
Onlinecron	n/a		FR
Cronjob.de	2.99EUR/mo	trial	DE
cronjobs.org	n/a		EN
cronjobs.com	5EUR/mo		DE
HostedCron	$10/mo		EN
web-cron.org	30EUR/?		FR
Remote-cron.com	n/a		EN
MyCronJobs.com	?		EN
Cron-Jobs.com	1.02EUR/mo		DE
Webgrid Scheduler	n/a		EN
crontastic.com	?	for beta	EN
Onlinecronjobs.com	n/a		EN

Google App Engine Blog: Getting your data on, and off, of Google App Engine

Google App Engine Blog: Getting your data on, and off, of Google App Engine: "One upcoming feature of Google App Engine that's worth mentioning is large-scale data import and export. We know that many of you have large apps that already run on other platforms, and getting all of that data into the Datastore API is a challenge. And, conversely, we also know that a lot of you want to make sure it's easy to move off Google App Engine in the future, in case you need to switch to a different platform.

With Google App Engine, you own all the data in your app. As stated in our terms, you always have the right to get your data out of Google App Engine at any point. We wouldn't have it any other way."

tecosystems � Clouds Rolling In: The Google App Engine Q&A

tecosystems � Clouds Rolling In: The Google App Engine Q&A: "“If Amazon/eBay/Google/Yahoo offer platforms - and they will, I believe.” - me

That was Saturday. By Monday, Google App Engine had launched with much fanfare. When I said cloudy days were ahead, I obviously believed that to be the case. I just didn’t know that meant Monday.

Some forecaster I am.

Anyway, you’re hearing it here last (seriously) as usual, but as the highest profile entrant into the cloud computing market since Salesforce.com, Google has earned itself a Q&A. Better late than never and all that."

What Exactly Is Google App Engine?

What Exactly Is Google App Engine?

Google hides infrastructure from AppEngine users. AE programmers never (and, in fact, aren't allowed to) think about database scaling and configuration, load balancing , fail-over, etc. In theory, the complexity of writing a highly scalable app completely disappears.

With EC2, you still have to set-up load balancers, configure multiple replicated database servers, implement scalability hacks if things grow too fast (such as distributed caching of data via memcached), keep distros and apps up-to-date, etc. Bottom Line: EC2-based companies still require sys admins, AppEngine companies don't. That will certainly change as more companies begin offering EC2 server management services.

Google provides a non-relational datastore and that's the only datastore available (no traditional file system, no relational databases). With EC2, people generally use MySQL or Postgresql. Amazon offers a non-relational datastore called SimpleDB, but it's a bit *too* simple. For example, it does not support sorting of results sets. Huh? That makes it non-workable in my opinion. There's also an issue with using EC2 virtual machines for your database servers -- Amazon says that when a virtual machine crashes, all the data managed by it disappears, so virtual machine crash = hard drive crash.

With EC2, programmers can use any (non-Microsoft) language to develop their apps. AppEngine users must code in Python. Also, Google does not support sockets at this time. All cross-app communication must be done via HTTP.

At *this* moment in time, it would be difficult to move apps off of AppEngine. Doing that in EC2 is trivial. This, to me, is the biggest issue, as I believe it could make startups less-interesting from an acquisition perspective by anyone other than Google. This will most likely change as people develop compatibility layers. However, Google has yet to provide any information about how to migrate data from their datastore the best I can tell. If you have a substantial amount of data, you can't just write code to dump it because they will only let any request run for a short period before they terminate it.

Some people are complaining about Google having access to their source code. I don't see this as an issue. I'd rather have it be stored at Google than at some small hosting company.

One final nice little thing in AppEngine's favor: Websites that store less than 500MB of data and get roughly 5MM pageviews per month or less can use AppEngine for free. The downside is that Google has yet to say what they'll charge if apps go over that quota, but I have to believe that it will be reasonable. Right now, you're prevented from going above the free-level quotas.