No Direction - It's been dumped into the ether with no solid direction. No recommended method or path to building your web app is given or hinted at. I'm all for choice and its great Google allow you to use Django, CherryPy, WebPy, etc. but it'd be helpful if a consistent and solid method was given. Unfortunately you're left with the feeling that the GAE has been thrown together with no real thought of making a web app out of it.

Disorganised Documentation - This doesn't help the problem mentioned above as the docs provide 3 or 4 ways of producing a web app from the start. It first tells you how to do it using basic CGI and printing directly to the browser. Then it shows you using the RequestHandler and WSGI app. At which point it doesn't say URLs are now handled by the WSGIApp instead of the app.yaml. Then it brings Django templates into the mix. How about pretty URLs? Oh well we can do that in app.yaml, or using matched groups in the WSGI app. For the love of all thats holy can't we just have a single nice solution? A recommended method? An idea? A guide?

Restrictions - So it gives you all that wonderful choice as mentioned above so you think you're going to make the best of it but oh no. Now you have to put up with the restrictions. No MySQL, no Django admin, restricted URL retrival, restricted security, no file uploading.

So you have to ask the question: Why?

What, ultimately, is the point in it when there's far better out there - Django, Merb, etc.  It has no purpose other than to faff with and so I shall be avoiding it for the forseeable.

Prerequisites

Your Asterisk server must be set up correctly before this API can 'speak' to the server.

• First you'll need to ensure the Manager interface is active and you've set the correct permissions (If you'd like this explaining please leave a comment).
• Secondly make sure you are setup with the ability for two endpoints to call each other.  This won't work if you have one phone on the server.

Install

Firstly you'll need to get hold of the library and there's two routes to take.  You can either install via PEAR or simply checkout the source from the Google Project:

svn checkout http://asterisk-php-api.googlecode.com/svn/trunk/ asterisk-php-api

Originating a Call

Once you've got it all ready you need to start your new file thats going to make use of it.  In this example I'm creating a simple dialler called: "call.php" which will take two GET variables, with one being the callee and one the caller.

 
<?php
/**
* To use this simply call it directly or via an Ajax call.  E.g.
* http://192.168.1.5/call.php?no=07943233397&from=229
*/
 
require 'AsteriskManager.php';
 
$number   = str_replace(array(' ', '(', ')', '.', ','), '', $_GET['no']);  //I'm just cleaning the input here.
$from      = 'SIP/'.$_GET['from']; //The SIP handset of who's dialling the outside line
$context  = 'asteriskcontent'; //This is the context in your Asterisk dial plan that this call is made to
$cid        = $number;
 
//Setup basic parameters for the connection
$params = array(
  'server' => '192.168.1.5',
  'port' => '5038',
  'auto_connect' => true
);
 
//Initialise
$am = new Net_AsteriskManager($params);
 
//Login to the Asterisk Manager interface
$am->login('user', 'pass');
 
//Originate Call is one of the commands available and it causes a call to be made and connected between two endpoints.
$am->originateCall($number, $from, $context, $cid, 1, 30000);
?>
 

By looking at the comments above you should see how this works and the steps required. If not then leave any comments and I'll build on the above. It's sometimes difficult to know what people already know so apologies if this is too simple or complex.

Later on I'll show how to work with queues - adding, removing, listing, etc.

1. DowningStreet doesn't bloody shut up!!

2. The site has complained about being snowed under 3 times so far.  They could sort this easily by using Django instead of Rails.

Other than that it seems alright.  For Rubyists you may be interested in the Twitter Rubygem by John Nunemaker: Twitter.


gem install twitter


P.S. Green as in: new, rookie, etc

Well it seems the metric is flawed and so sayeth one of the developers of the Google App Engine during one of the IO talks done in May.

In that talk he mentions that people have been trying to run load tests on the GAE that simply throw hundreds of concurrent requests and conclude the test after one second.  Unfortunately this isn't realisitic and so the optimisations that are built into the system don't have time to kick in.

I'd say this isn't just an issue for GAE - its an issue with this benchmarking method full-stop.  Because as he says - its unrealistic.

Take the following example numbers from the slides:

Realistic values
• 50,000 users / day
• 2 pageviews / user
• 100,000 pageviews / day
• 5 requests / pageview
• 500,000 requests / day
• 5.8 requests / second

To some people 50k users may not seem much but irrespective I'd say its certainly a sizable chunk for the majority of readers here.  As you can see if a site is being hit by 50,000 users per day they can expect a realistic hit rate of 5.8 concurrent requests per second.

Let me say that again: A site that gets 50,000 user per day can expect just 5.8 average concurrent requests per second.

Thats a realistic number and it blows out of the water the benchmarking methods that hammer a server for one second with hundreds of requests.  People using those benchmarks have two flaws:

1. If they get a low number they may be unfairly assuming a poor service based on a spurious and unrealistic testing methodology.
2. If they get a high number they'll assume that their server can take sustained heavy load which is certainly not the case.

What the speaker then recommends is performing more realistic load tests spread over time.  This not only provides a more realistic basis for conclusions but also enables servers to adapt to the increasing load.

You can see the video which is about making production ready apps on Google App Engine by visiting its IO page here.

UPDATE

Digg Effect / Slashdotting

One of the obvious counters to this criticism which is also expressed at the end of this talk is that the Digg Effect or Slashdotting is indeed something that requires high 'per second' load testing.  However, thats not the case as these phenomena actually occur over a period of minutes and even hours and not a vertical spike.  The number of concurrent hits is still relatively low and so these hundreds per/sec tests don't fit here either.

Putting aside my grammatically dodgy statement the Django Project (the b3zt framework evaz!) has created the Django Foundation.  A non-profit organisation in the same vein as Mozilla, Apache, etc it aims to oversee the development, direction and future of the Django project.

You can find out more about the groups goals at the Foundation page on Django Project.

Lots of warm fuzzy snuggles to the community too:

We certainly couldn't have gotten here without the amazing support and contributions from our community of users and developers. To everyone who's used or contributed to Django: thanks!

Free Rails Ebook

Shop - Plugs into Amazon feed to get products and revenue generation from Associates tag (not quite finished as it needs to be styled better).

Gallery - The front end of this is all MooTools based SmoothGallery2.0 with a nifty backend providing uploading, tagging, etc.  I think the SmoothGallery is great but I can see it struggling with anymore pics in it.

Contact - Simple email on sending.  Also embedded MSN Live maps - it looks so much nicer than Google's and its easier to use.

XML Sitemap - Using Djangos built-in Sitemap generator.

Blog - Basic blog with the FreeComments plugin.

Some of the pages can be edited much like a CMS.  This is standard in Django when you use something called Flat Pages.

As a first proper released project of Django I'm chuffed.  Its come out nicely and its immensely fast compared to my Rails sites.

I plan on doing a few more in Django before moving onto MERB in the not to distant future.

Then I realised its been done a million times before:

• Programming Languages as Cars
• Programming Languages as Boats
• Programming Languages as Women 1 & 2

So what is my answer to all of this?

To create a brand new Yet Another!!!  "Yet Another Language As"

This was again compounded when I had to implement a patch in my Asterisk PHP API which is Subversion hosted.  As the current version was out of date the patch failed so needed to be done manually.  If on the other hand we'd been using Git or Mercurial I could simply Pull the contributors changes.  Nice and simple!  No fuss, no bother, just get on with it.

So now to the point of my post: Mercurial.

Now Git was great but I think I've found a new friend in Mercurial.  Although Mercurial is still lacking in some areas (named branches still can't be deleted nicely) I think it's future is much brighter.  For starters its ported to more platforms.  This is an advantage gleaned form it being developed in Python.  Which is my major point here - being in Python makes it nicer, easier and cleaner to deal with.  Writing extensions to Hg is a snap with a nice built-in API.  So its immaturity in features is more than made up for its potential.

It has all the advantages of Gits distributed methodology but with the flexibility to grow beyond its existing state easily and rapidly.

Free Mercurial Hosting

• Intuxication
• FreeHG
• ShareSource
• Assembla