Next week (9/14/11, 4:00 pm, Chelmsford Public Library, McCarthy Meeting Room. Directions.), I’ll be giving a hands-on introduction to running Hadoop on Amazon EC2.

It will be as hands-on as the previous talk was conceptual. For the actual material, we will use the excellent tutorial by Michael Noll. Michael first wrote it in 2007 and has kept it up to date. The tutorial helps you install map/reduce and use it for computing the count of every word in a large text. We will use Ulysses by James Joyce as our sample text. Can we do this in 90 minutes? Yes, we can. But the goal is to get the most out of the journey.

To get the most out of the talk, you should be prepared to sign up for an Amazon account. They require a credit card but the credit card won’t actually get charged because our usage will be a few cents and well under the free limit. If you don’t want to sign up for an Amazon account, that’s OK too — we’ll use one as the example and will project it on the screen.

Look forward to seeing you there.

The report speaks for itself. If Max and Co. at Blackbox achieve half of what they have set out to do, it’ll change the way investing and entrepreneurship gets done.

I mention the report and the brouhaha accompanying it on this blog for two reasons:

1. It tracks our experience well.
2. It fits our business model: Early Stage IT is a partner to start-up teams and can bring your team that much needed technology focus, or add to it.

Given the stakes, expect the next few months to be a slugfest. The unbelievers will talk about how this cloud stuff is all hot air. The believers will speak of it as “a learning moment” and make suggestions so this type of thing “never happens again”.

Both sides are right in their own way but I think the stumble as well as the reaction to it is quite normal. Malcolm Gladwell wrote this essay about the Challenger disaster a quarter-century ago. To quote his introduction,

Who can be blamed for a disaster like the Challenger explosion, a decade ago? No one, according to the new risk theorists, and we’d better get used to it

Can this stumble be characterized similarly? I think so. And we’d better get used to it.

The force driving the push to the cloud is economic. This event does not really change the economics of the cloud. It brings the risks into sharper relief but that can’t be bad for the industry, can it? It will help us tone down the rhetoric.

We need to fix some problems in this business. How cloud vendors can get away with not publishing an SLA is hard to understand. Hopefully this event will increase the pressure for that.

Perhaps a new vendor will emerge that will offer an SLA to differentiate themselves. Priced a bit higher than the Amazons and Rackspaces of the world, it will help us determine the extra premium that an SLA commands.

There is another way to solve this dilemma: through an insurance model. Insurance companies measure risk and put a value on it. Their model is to evaluate your home/business/car and place a premium on its risk. And make specific suggestions for mitigating that risk. And reducing your premium if you implement those suggestions.

But we need to be concerned about over-fixing the problems. Inevitably, there will be suggestions for avoiding this type of an issue in the future: more automation to compensate for the failures of automation. That’s the type of thing Gladwell cautions against. Beyond a certain level, mindless automation doesn’t help much. And sometimes it gives us books priced at over a million bucks!

First, a little bit about Early Stage IT. We do IT for Early Stage companies. No, not installing machines type of stuff. More like IT strategy and execution, especially web applications. Our positioning is exactly in this space: startups. What attracts me to this space is that it’s very dynamic, it attracts a lot of very smart people who are not only smart, but can get things done and make concepts come to life. We started a couple of years ago, and it took a while to get things going — a long dry spell in a lousy economy — but things have started to turn around, and I’m happy about that.

Let me talk first about a failure. It’s kind of the right of passage in the startup world, right? We built this web site for helping High School seniors search and apply for scholarships. We built the web site on Google App Engine. I coded most of it, and we had a young woman helping out.

She had dropped out of the workplace about 6 years ago when her second child was born, and now that he was entering kindergarten, she was ready to go back to work. Of course, technology moves on and she needed to polish up her skills. And she still needed to be able to help out in his classroom and be there to meet the school bus, that sort of thing. So we made a deal: I would help her develop her skills and she would do what she could coding-wise.

Sounds wonderful, right? We’d made some mistakes in how we structured ourselves — three partners plus a marketing guy working on equity and we just couldn’t make a go of it. And there wasn’t enough equity there to try and sell it so we’re in the process of dissolving it.

But within that failure was a big success too. We had a functioning web site that had been built for less than a thousand dollars, partly on Google App Engine, partly on Amazon. We took payments using PayPal, we had a marketing web site built on Drupal Gardens, all of it free.

So lessons learned, and the lessons are these:

1. Get good legal help and structure the company in a way that makes it possible to adapt.
2. Make sure we’re not just a a bunch of chiefs, we have a few Indians too.
3. Eric Ries talks about validated learning. Validate that you have a market, that if you build it, they actually will come.
4. Finally, if I’m going to participate in a cash-free deal, I have to look at it like a VC would. And if you assume that VC’s generally know what they’re doing, you have to conclude that for us to take part in something, we have to have a pretty firm notion that the likelihood of being backed by someone with money is high.

To the topic of today’s conversation, there are many reasons to get an advisor. If you want them because they look good on your company profile — Trophy Advisors, if you will — that’s a different story.

If you want them because they will help make the company, let me turn the question around: if you could get professional assistance from someone without paying a lot of money, would you take it? My bet is, you wouldn’t. You’d wonder why it was so inexpensive. You’d wonder if you were being sold a bill of goods. You’d wonder if the person was going to just steal your idea. The bottom line is, you want someone you can trust. You want someone who is as good in their field as you are in yours. In other words, this relationship has to be based on trust and mutual respect. That’s the key ingredient and if that’s missing, you don’t want that person.

There are a lot of areas where you can save money. In today’s technology environment, with Cloud Computing and open source software and NoSQL databases, the cost to actually develop something is not the barrier. The barrier is how you identify who the buyers will be, how you will sell to them, what exactly do they want, what are your barriers to entry, what is your value proposition, etc. Those are the critical elements that will determine your success.

So is there no other way to get key talent? Sure there is, but it’s hard. It’s harder than raising money from an investor. You have two tools: First, the vision. Not just that you can make money. Some people are motivated solely by money, others want to see a purpose in what they’re doing. If you can share that purpose, that mission, then that’s your reason to collaborate in making it happen. If you don’t share that vision, the other tool is the promise of future money. To assemble the right founding team, you need five things:

1. Trust – you must absolutely trust this person
2. Ability – they must have the key skills you need at formation time
3. Available – the best people are usually not available…they are busy doing other things
4. Desire – they must share your vision and desire to see it happen
5. Commitment – they must be willing to work for free until you can get funding

Having 2 or 3 out of 5 is not good enough. You need all five. A client that I’ve gotten to know pretty well convinced me this way: he has done startups before and done successful exits. He has an impressive Rolodex and can get f&f money. The concept is not that far away from being tested. Either way, he can help us get other business because of his connections. That line of argument was convincing enough.

But what if you are just coming up with a SaaS service? What metrics should you base your pricing on? I’d like to look at it from a provider’s point of view.

In this post I’ll just focus on pricing metrics. What about some of the other factors he mentions, like SLA? Later.

Activity-Pricing Congruence

Let’s do a thought experiment. You have been asked to set up and operate a call center for a credit card company. Each of your representatives will need a computer connected to the company database with a fast network. Each rep will also need a phone. A set of 800- numbers and a call routing system will bring the customer phone calls to them. Before a rep gets a call, a voice response system will interact with each caller and get their credit card info and verify their PIN, etc. You find two suppliers that have different pricing models:

1. Supplier A’s pricing is component-based. $x per computer, $y per CPU-hour of the company mainframe, $z per megabyte/sec of bandwidth, $v for the voice response unit, etc.
2. Supplier B’s pricing is activity-based. $s per service call. The costs for computers, network, phone, everything, is rolled into the one number.

Which would you pick? Based on actual numbers, supplier A may be cheaper but supplier B’s charges will be a lot more predictable. Many SaaS companies set their pricing in units that make sense to them, even though it makes them less transparent to the customers. Why should the customer bear the uncertainty? The key is to have a pricing scheme that makes sense to the customer.

The Price of Simplistic Pricing

The pricing scheme should be simple and congruent with usage, that was the message above.

But there is such a thing as too simple. For example, Salesforce.com charges by the number of licensed users and the per-user price is considered steep for anyone except the dedicated user. This has an interesting effect: most companies limit the number of employees who have licenses to the few who need to interact with it all day long. For everyone else, they hire a contractor to write a data extract program. And a reporting package to sit around this extracted data. And batch processes to keep stuff synchronized.

The net result of this simplistic pricing model is that Salesforce.com can’t realize revenue for this add-on ecosystem and the customers end up with a kludge.

If Salesforce.com priced themselves by usage rather than by number of users, they might get a lot more users (although with less per-user revenue). And the customers wouldn’t end up operating a custom-done kludge designed to avoid the expense of Salesforce.com at the core.

1. Code with this assumption in mind: all incoming (into GAE) requests will use https://abc.appspot.com; all outgoing links embedded in return HTML should use https://www.abc.com.
2. Set secure: always in the application configuration.
3. For static files, use https://abc.appspot.com — there is no reason to serve them through the proxy.
4. The reverse proxy will not transform authentication tokens in any way; these may require special attention.

The flexibility associated with Some Assembly Required is hardly Amazon’s fault but I’ve got tired of building and rebuilding these pieces. I am embarking on a project to reduce the install and deployment times of these components. The first component I am going to tackle is the reverse proxy. I would like to reduce the deployment time from a couple of hours to under 10 minutes.

Edit 11/17/10: A Chef-based deployment implementation is now in place. We met our goal.

With this goal in mind, I have been looking at Administration platforms (complete list here). There are four serious contenders¹: CF Engine or its variants such as cfruby, Puppet, Chef and RightScale.

I can’t claim decades of experience with systems management; I had to rely on other people’s experience. Research on the web showed a lot of people citing reasons why they switched from CF Engine to Puppet but none going in the other direction. So even though I have had success with cfruby, I felt it was better to look at the other platforms.

Puppet is the established player in this space. It is the safe technology choice and is used for managing infrastructures in many large companies. A couple of articles cement this conclusion: one and two. The first article is a little weak but I found the ensuing discussion to be very informative. This comment in the second article seems to be a fair summary of the Puppet vs Chef comparison:

Puppet has perfected automating the traditional sysadmin tasks, while Chef tackles elastic operations and application integration better.

At the end of this analysis I was already leaning toward using Chef as the platform. This announcement from RightScale sealed the case.

Why not directly choose Rightscale as a solution? If they were open source, they would be worth serious consideration. After a bit of experimenting with Chef, if it doesn’t meet my goals, I’m more inclined to try Rightscale than Puppet. The problems Rightscale is trying to solve have more in common with the problems we at Early Stage IT need to solve; that’s less so with the problems Puppet is aimed at solving. But if a platform pivot is required at all, it’s a couple of weeks down the road.

My starting point: The Momoro Hoax.

Meanwhile, did you notice that all four of these solutions are Ruby-based? Where did that come from? With Amazon’s and Rightscale’s adoption on Ruby and with Puppet as the premiere platform, Ruby has become the de facto standard in this space.

We will be building a Personal Resume Tracker — an application for managing your resume-send-out process. It’s hardly a finished application but will serve the purpose for which it was intended: as a pedagogical tool.

• Storing various versions of your resume,
• Composing and including a cover letter,
• Mailing a resume & cover letter out and
• Keeping track of who was mailed what version when.

We will build this application in 5 steps, starting from where the Hello World example leaves off. To give you a road map, here are the 5 steps:

1. A data model for the application and replacing the Greeting class with the Person class.
2. A ResumeDoc class and uploading and downloading files.
3. A Contact class that represents an email contact made with a person. Implementation of the data model begun in step 1 is completed here. This step discusses how to navigate the data model.
4. Sending out a plain-text email with attachment. We utilize the GAE mail API, one of a number of services available in the GAE environment.
5. We utilize the Markdown API for converting plain-text to HTML and sending HTML-format email. We download an open source module and integrate it into our application.

Debugging

Before delving into programming, a few words about debugging resources.

• The logging API comes in handy for logging program events to the console. The logs are then available through the GAE Launcher, Eclipse or through the GAE Application Dashboard.
• The state of the database may be viewed from GAE Launcher and through a browser window when running in the local sandbox. The state of the production database may be examined through the Application Dashboard.
• If running under Eclipse, pydev provides a complete debugging support.

Step 1: Data Model and the Person class

The data model is self-explanatory. Our application stores many versions of resumes and a list of people with whom the applicant wants to communicate. She can select a person and a resume, write a cover letter for the occasion and send. A system like this is a great way to accumulate statistics on which messages and which versions of resumes are effective and which less so, but we get ahead of ourselves here.

We replace the file index.html from the Getting Started example with these contents as person.html:

<html>
  <head>
    <link type="text/css" rel="stylesheet" href="/stylesheets/main.css" />
  </head>
  <script type="text/javascript">
    function editPerson(k, n, e, p, btn){
        document.getElementById('prsn_id').value = k;
        document.getElementById('name').value = n;
        document.getElementById('email').value = e;
        document.getElementById('phone').value = p;
        document.getElementById('submitBtn').value = btn;
        document.getElementById('my_form').style.display = 'block';
    }
    function addPerson(){
        editPerson("", "", "", "", "Add");
    }
  </script>
  <body>
  {% if user %}
    <table>
    {% for person in persons %}
        <tr>
            <td><b>{{ person.Name }}</b></td>
            <td>{{ person.Email }} </td>
            <td>{{ person.Phone }} </td>
            <td><button onclick='editPerson("{{ person.key }}", "{{ person.Name }}", "{{ person.Email }}", "{{ person.Phone }}", "Update" ); return false;'>Edit</button> </td>
        </tr>
    {% endfor %}
        <tr>
            <td></td>
            <td></td>
            <td></td>
            <td><button onclick='addPerson(); return false;'>New</button> </td>
        </tr>
    </table>
    <div id="my_form"  style="display: none;">
    <form action="/person" method="post">
      <input name="prsn_id" id="prsn_id" type="hidden" />
      <label for="name" >Name</label>  <input id="name"  name="name"  type="text" size="60"></input><br />
      <label for="email">Email</label><input id="email" name="email" type="text" size="60"></input><br />
      <label for="phone">Phone</label><input id="phone" name="phone" type="text" size="60"></input><br />
      <div><input id="submitBtn" type="submit"></div>
    </form>
    </div>
  {% endif %}
    <a href="{{ url }}">{{ url_linktext }}</a>

  </body>
</html>

The file resume-tracker.py is architecturally similar to helloworld.py:

import os
from google.appengine.ext.webapp import template

from google.appengine.api import users
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
from google.appengine.ext import db

class Person(db.Model):
    Name  = db.StringProperty(required = True)
    Email = db.StringProperty(required = True)
    Phone = db.StringProperty()
    updated = db.DateTimeProperty(auto_now = True)

class PersonPage(webapp.RequestHandler):
    def get(self):
        if users.get_current_user():
            url = users.create_logout_url(self.request.uri)
            url_linktext = 'Logout'
            persons_query = Person.all().order('-updated')
            persons = persons_query.fetch(100)
        else:
            persons = []
            url = users.create_login_url(self.request.uri)
            url_linktext = 'Login'

        template_values = {
            'persons': persons,
            'url': url,
            'url_linktext': url_linktext,
            'user': users.get_current_user(),
            }

        path = os.path.join(os.path.dirname(__file__), 'person.html')
        self.response.out.write(template.render(path, template_values))

    def post(self):
        if users.get_current_user():
            prsn_id = self.request.get('prsn_id')
            name = self.request.get('name')
            email = self.request.get('email')
            phone = self.request.get('phone')
            if prsn_id:
                entity = Person.get(str(prsn_id))
                entity.Name = name
                entity.Email = email
                entity.Phone = phone
            else:
                entity = Person(Name = name, Email = email, Phone = phone)
            entity.put()

        self.redirect('/person')

application = webapp.WSGIApplication(
                                     [('/',             PersonPage),
                                      ('/person',       PersonPage),
                                      ],
                                     debug=True)

def main():
    run_wsgi_app(application)

if __name__ == "__main__":
    main()

Try running this application on your local machine. A change to app.yaml will be needed.

Step 2: The ResumeDoc class

About a year ago, Nick Johnson of Google wrote a piece on uploading and downloading documents. This section borrows heavily from Nick. You will need to add the following two classes to resume-tracker.py.

class ResumeDoc(db.Model):
    Name = db.StringProperty(required = True)
    Body = db.BlobProperty()
    Mime = db.StringProperty()
    Fnam = db.StringProperty()
    updated = db.DateTimeProperty(auto_now = True)

class ResumePage(webapp.RequestHandler):
    def get(self):

        if users.get_current_user():
            url = users.create_logout_url(self.request.uri)
            url_linktext = 'Logout'
            resumes_query = ResumeDoc.all().order('-updated')
            resumes = resumes_query.fetch(10)
        else:
            resumes = []
            url = users.create_login_url(self.request.uri)
            url_linktext = 'Login'

        template_values = {
            'resumes': resumes,
            'url': url,
            'url_linktext': url_linktext,
            'user': users.get_current_user(),
            }

        path = os.path.join(os.path.dirname(__file__), 'resume.html')
        self.response.out.write(template.render(path, template_values))

class ResumeHandler(webapp.RequestHandler):
    def post(self):
        if users.get_current_user():
            file = self.request.POST['file']
            name = self.request.get('name')
            entity = ResumeDoc(Name = name, Body = file.value, Mime = file.type, Fnam = file.filename)
            entity.put()

        self.redirect('/')
    def get(self, key):
        if users.get_current_user():
            doc = ResumeDoc.get(key)
            body = doc.Body
            mime = doc.Mime
            if body:
                self.response.headers['Content-Type'] = mime
                self.response.headers['Content-Disposition'] = 'attachment; filename=%s' % doc.Fnam
                self.response.out.write(body)

The corresponding resume.html file follows the same architecture as person.html. Two differences:

1. Use of tag to specify file input
2. Use of enctype="multipart/form-data" in the form tag to specify text input in the same form.

Create the file resume.html with the following content:

<html>
  <head>
    <link type="text/css" rel="stylesheet" href="/stylesheets/main.css" />
  <script type="text/javascript">
    function editResume(k, n, btn){
        document.getElementById('key').value = k;
        document.getElementById('name').value = n;
        document.getElementById('submitBtn').value = btn;
        document.getElementById('my_form').style.display = 'block';
    }
    function addResume(){
        editResume("", "", "Add");
    }
  </script>
  </head>
  <body>
  {% if user %}
    {% for resume in resumes %}
        <b><a href="/resume/{{ resume.key }}">{{ resume.Name }}</a></b>: {{ resume.updated }}
        <button onclick='editResume("{{ resume.key }}", "{{ resume.Name }}", "Update" ); return false;'>Change</button>
        <br />
    {% endfor %}
        <button onclick='addResume(); return false;'>New</button> <br />

    <div id="my_form"  style="display: none;">
    <form action="/resume" method="post" enctype="multipart/form-data">
      <input name="key" id="key" type="hidden" />
      <div><label for="file" >File</label>  <input id="file" name="file" type="file" size="60"></input></div>
      <div><label for="name" >Descriptive Name</label>  <input id="name" name="name" type="text" size="60"></input></div>
      <div><input id="submitBtn" type="submit" value="Upload"></div>
    </form>
    </div>
  {% endif %}
    <a href="{{ url }}">{{ url_linktext }}</a>

  </body>
</html>

Connect the two classes ResumePage and ResumeHandler to the WSGI framework by replacing the object application with:

application = webapp.WSGIApplication(
                                     [('/',             PersonPage),
                                      ('/person',       PersonPage),
                                      ('/resumes',      ResumePage),
                                      ('/resume/(.*)$', ResumeHandler),
                                      ('/resume',       ResumeHandler),
                                      ],
                                     debug=True)

We have just added three new URLs. The URL /resumes just lists stored documents. The URL /resume/documentKey downloads a specific document to the user’s browser. Notice the use of a regular expression to specify a key. This formulation avoids the use of query strings to specify http arguments. The same URL is used with a post method to upload new documents.

Step 3: The Contact class

The data model for the Contact class is as follows.

class Contact(db.Model):
    person  = db.ReferenceProperty(collection_name='documents')
    resume = db.ReferenceProperty(collection_name='recipients')
    cover = db.TextProperty()
    mailed = db.DateTimeProperty()
    updated = db.DateTimeProperty(auto_now = True)
    def abstract(self):
        inString = str(self.cover)
        return inString if (len(inString) < 30) else (inString[:29] + '&hellip;')

The person attribute of class Contact is a reference to a Person object. Given a Contact object ctct, the corresponding Person object can be obtained by using ctct.person. The dot notation is used to navigate the data model. The data store also implicitly maintains reverse pointers: given an object prsn of class Person, prsn.documents will yield a collection of Contact objects. For example, if we wanted a list of ResumeDoc objects that were sent to george and when, we would write

ctcts = george.documents
for ctct in ctcts:
    print ctct.resume.Name, ctct.mailed

Second, cover was made a TextProperty because StringProperty is limited to 500 characters and a cover letter could surely be larger. The fact that a StringProperty can be part of an index and TextProperty can not, is not much of an issue.

Finally, the method abstract(self) is a quick way of showing the first few words of the cover letter. This method will be used in contact.html, which is shown next.

<html>
  <head>
    <link type="text/css" rel="stylesheet" href="/stylesheets/main.css" />
  <script type="text/javascript">
    function editContact(k, pk, rk, cvr, btn){
        document.getElementById('key').value = k;
        document.getElementById('person').value = pk;
        document.getElementById('resume').value = rk;
        document.getElementById('cover').value = cvr;
        document.getElementById('submitBtn').value = btn;
        document.getElementById('my_form').style.display = 'block';
    }
    function addContact() {
        editContact("", "", "", "", "Add");
    }
    function sendMail(k) {
        alert('Send Mail(' + k + ') will be implemented later');
    }
  </script>
  </head>
  <body>
  {% if user %}
    <table>
    {% for contact in contacts %}
        <tr>
            <td>{{ contact.person.Name }}</td>
            <td><b>{{ contact.resume.Name }} </b></td>
            <td>{{ contact.abstract }} </td>
            <td valign="middle">
                {% if contact.mailed %}
                {{ contact.mailed }}
                {% else %}
                <button onclick='sendMail( "{{ contact.key }}" ); return false;' >Send Mail</button>
                {% endif %}
            </td>
            <td valign="middle"><button onclick='editContact("{{ contact.key }}", "{{ contact.person.key }}", "{{ contact.resume.key }}",
                <r><![CDATA[{{ contact.cover }}]]></r>, "Update" ); return false;'>Edit</button> </td>
        </tr>
    {% endfor %}
        <tr>
            <td></td>
            <td></td>
            <td></td>
            <td></td>
            <td><button onclick='addContact(); return false;'>New</button> </td>
        </tr>
    </table>

    <div id="my_form"  style="display: none;">
    <form action="/contact" method="post">
      <input name="key" id="key" type="hidden" />
      <label for="person" >Person</label>
        <select id="person"  name="person">
            {% for person in persons %}
            <option value="{{ person.key }}">{{  person.Name }}</option>
            {% endfor %}
        </select>
      <br />
      <label for="resume" >Resume</label>
        <select id="resume"  name="resume">
            {% for resume in resumes %}
            <option value="{{ resume.key }}">{{ resume.Name }}</option>
            {% endfor %}
        </select>
      <label for="cover">Cover</label><textarea id="cover" name="cover"  rows="15" cols="80"></textarea><br />
      <div><input id="submitBtn" type="submit"></div>
    </form>
    </div>
  {% endif %}
    <a href="{{ url }}">{{ url_linktext }}</a>

  </body>
</html>

The page shows a drop-down for persons and another one for resumes. The pattern for displaying and editing Contact objects is the same as for other data classes in this example. We have created a Send Mail button but it is not functional at the moment.

Server side handling of the Contact object also follows a similar pattern as for Person and ResumeDoc. The class definition is shown here:

class ContactPage(webapp.RequestHandler):
    def get(self):
        if users.get_current_user():
            url = users.create_logout_url(self.request.uri)
            url_linktext = 'Logout'
            contacts_query = Contact.all().order('-updated')
            contacts = contacts_query.fetch(100)
            resumes_query = ResumeDoc.all().order('-updated')
            resumes = resumes_query.fetch(10)
            persons_query = Person.all().order('-updated')
            persons = persons_query.fetch(100)
        else:
            contacts = []
            resumes = []
            persons = []
            url = users.create_login_url(self.request.uri)
            url_linktext = 'Login'

        template_values = {
            'contacts': contacts,
            'resumes': resumes,
            'persons': persons,
            'url': url,
            'url_linktext': url_linktext,
            'user': users.get_current_user(),
            }

        path = os.path.join(os.path.dirname(__file__), 'contact.html')
        self.response.out.write(template.render(path, template_values))

    def post(self):
        if users.get_current_user():
            key = self.request.get('key')
            pk = self.request.get('person')
            rk = self.request.get('resume')
            cover = self.request.get('cover')
            if key:
                entity = Contact.get(key)
                entity.person = Person.get(pk)
                entity.resume = ResumeDoc.get(rk)
                entity.cover = cover
            else:
                entity = Contact(person = Person.get(pk), resume = ResumeDoc.get(rk), cover = cover)
            entity.put()
        self.redirect('/contact')

Step 4: The Mail API

The Mail API is one of eight Service APIs. These APIs serve to extend the base functionality.

The machinery for sending out emails is almost in place already. All that is needed is one more class whose post method sends the mail and updates mailed attribute of the Contact object and a small changes contact.html. The new class:

class ContactMail(webapp.RequestHandler):
    def post(self):
        if users.get_current_user():
            key = self.request.get('key')
            entity = Contact.get(key)

            mail.send_mail(sender = users.get_current_user().email(),
                           to = '"%s" <%s>' % (name, email),
                           subject = 'Job Application',
                           body = entity.cover,
                           attachments=[(entity.resume.Fnam, entity.resume.Body)])
            now = datetime.datetime.utcnow()
            entity.mailed = now
            entity.put()
        self.redirect('/contact')

In contact.html, change sendMail method:

    function sendMail(k) {
        document.getElementById('mailKey').value = k;
        document.getElementById('sendMail').submit();
    }

Also in contact.html, add this form to the body:

    <form id="sendMail" action="/mail" method="post" />
    <input id="mailKey" name="key" type="hidden" />
    </form>

You will also need to add it to the WSGI framework.

Step 5: Markdown

The emails we send using the code from step 4 are plain text. To be able to send HTML email, the mail API requires two versions: plain text version and HTML version. Recipients will see one or the other version depending on their mail reader and the preferences they have indicated. To keep from duplicating the work of creating two versions of every document, we choose Markdown: a library that takes plain text written according to some text conventions and converts them to HTML. Markdown was created for wiki authors who could not be persuaded to learn HTML but it will serve our purpose here.

A Python library for Markdown is available for download at http://code.google.com/p/python-markdown2/. You need to copy the file markdown2.py into your code directory. Add the line import markdown2 before referencing it.

To markdown plain text, add one more argument to the send_mail function.

    html = markdown2.Markdown().convert(entity.cover),

That’s it. Now all you need to do is master markdown syntax!

Further Enhancements

It has been a long post; hopefully it provides a flavor for how development gets done in the Google App Engine environment. The application is now ready to be uploaded to App Engine.

Enjoy.

Google App Engine supports HTTPS if you access your application through https://abc.appspot.com but not through https://www.abc.com. Google is working on a solution but there is currently no ETA.

Our Reverse Proxy solution acts as a termination point for the client’s SSL connection. It uses an SSL certificate created by a signing authority. For browsers to not issue a warning message to users, such a signed certificate is required. The Reverse Proxy acts as a front-end to Google, sending requests over SSL to your-app-id.appspot.com. It runs in its own virtual machine with one SSL connection to the client and one connection to Google App Engine. Click here to learn more about Reverse Proxies.

The solution described in this post is available as a service from Early Stage IT. You can sign up now, use it as long as you need, cancel any time. The solution includes a self-signed certificate but not one signed by a certificate authority.

Performance Impact

We measured performance by repeatedly requesting a straightforward HTML page from the GAE infrastructure using a simple load tester with instrumentation added to measure response time. The reverse proxy solution can impose a 100ms-400 ms delay on a round trip.

The remainder of this post is a cookbook for setting up the proxy yourself if you don’t want to use our service. It is offered here in the spirit of open source.

Setting up a reverse proxy is conceptually simple. We terminate the SSL connection to https://www.abc.com at the EC2 server and have the server forward the request to https://abc.appspot.com. We built ours following these steps:

1. The foundation. A couple of years ago, Brad Larson described the process of setting up an EC2 server. His purpose was different but the first steps of our process are the same as what he described. Following his lead, bring up an instance of a CentOS AMI. A couple of AMIs we have used are ami-0193f760 in US-East and ami-e32273a6 in US-West (both from RightScale). Snap a 1GB EBS volume to it and attach an IP address. See Brad’s article for details.
2. The components. Squid requires just two components: mod_ssl and squid. Install them both using yum (or apt-get if you are using a different version of Linux). Of course, the vital component is the SSL certificate. We bought ours from GoDaddy. To generate it, generate a 2048-bit key. Use the key to generate a certificate signing request (abc.csr file). Finally, strip the password from the key — providing a password every time you need to start squid can be a pain.

   openssl genrsa -des3 -out abc.key 2048
   openssl req -new -key abc.key -out abc.csr
   openssl rsa -in abc.key -out abc.pem</code>
   
   
    Once the certificate has been generated, copy its contents into a certificate file on the server. The path to the certificate file and the key file (abc.pem) will be needed in the next step.

3. Integration. On the EC2 server,
   • Update /etc/hosts and add the line 01.23.45.67 www.abc.com www_abc.
   • Optional: for speed, add Google nameservers (or others good ones for your locale) to /etc/resolv.conf. To accomplish this, add the lines nameserver 8.8.8.8 and nameserver 8.8.4.4 to that file.
   • Finally, Squid Wiki Configuring SSL Reverse Proxy does a great job of walking through the steps of configuring the reverse proxy. We won’t reproduce the steps for creating a certificate. Here is the config file we use. Not much to it, declaring the SSL connection to the browser and to App Engine and tightening the security parameters.

   acl all src 0.0.0.0/0.0.0.0
   acl Safe_ports port 443
   acl gae dstdomain abc.appspot.com
   
   visible_hostname www.abc.com
   https_port 443 cert=/path/to/cert key=/path/to/key defaultsite=abc.appspot.com
   cache_peer abc.appspot.com parent 443 0 no-query originserver ssl sslflags=DONT_VERIFY_PEER name=appspot
   cache_peer_access appspot allow gae
   always_direct allow gae
   
   http_access allow gae Safe_ports
   http_access deny all
   
   debug_options ALL,1
   
   
    

4. Debugging. For the novice, Squid can be a little cryptic. It was built for speed, not programming ease. Here are a few hints on what to do when things don’t work according to plan:
   • If squid won’t even start, squid –N –d l -D can be useful in figuring out why.
   • If it starts but does not behave as you would expect, that last line (debug_options command) can be used to control the level of detail that is logged. Reading those logs can be a bit of a black art. Use your favorite search engine and the Squid book for help.
5. Operation. Once you have a basic configuration running, tighten up the security and optimize it for performance. We will be adding to this section in the future but here is a good starting point: Six Things First Time Administrators Should Know.

If you use it…

…please cite this blog post. Feedback — positive or negative — gratefully accepted.

1. Cloud Computing. The hardware cost for development was less than $750 including the cost of a laptop.
   • We used Google App Engine for the most part but not exclusively.
   • For confidential documents, we used Amazon S3, preferring to go directly between the browser and Amazon, bypassing Google. Any doubts about whether Google will mine those documents were neutralized.
2. Staying conceptual with the implementation.
   • Google App Engine was great for helping us stay conceptual. They take care of scalability, backups, OS versions, patches. All the stuff that drags you down.
   • Amazon EC2 is too low level. One has to worry about scalability, backups, OS versions, patches. We should have gone up a level by using a service like Rightscale. We haven’t yet, but it’s still an idea worth pursuing.
   • For the same reason, we would consider Amazon RDS over doing our own database management.
3. Open Source Software. Most notably, jQuery. Their slogan is “write less, do more”. The reality matches the slogan. A rich milieu of available software allowed us to assemble components rather than write code. A couple of times we were bitten by it too. A month after we had integrated a component, the developer decided not to support it any more. We switched away. So one has to stay agile but that’s the name of the game anyway.
4. Staying conceptual with the requirements. This was the second-biggest factor: working with a team that trusts you, things don’t need to be written down to an excruciating level of detail. You hear the requirement in vague terms, you implement it, and if you had misunderstood, well, change quickly. Keeping the Agile Manifesto in mind.
5. Tracking shifts in business strategy. This was the biggest factor. The business strategy changed at least a couple of times during the project. The development was continuous, however. We were surprised to discover that the changes forced us to re-factor the code as it was re-purposed to fit the changing strategy — but very little of the code was thrown away. The re-factoring may have made it more modular, actually. By the time the business strategy had settled, we had software components that were well-tested already. Only the final integration was left to do.

Your mileage will vary, of course, but these are the factors that made us successful for this project.