Google App Engine lets you run web applications on Google's infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it's ready to serve your users.
You can serve your app from your own domain name (such as
http://www.example.com/) using Google Apps. Or, you can serve your app using a free name on the
appspot.com domain. You can share your application with the world, or limit access to members of your organization.
Python Course (if you need to learn Python):
With App Engine, you only pay for what you use. There are no set-up costs and no recurring fees. The resources your application uses, such as storage and bandwidth, are measured by the gigabyte, and billed at competitive rates. You control the maximum amounts of resources your app can consume, so it always stays within your budget.
App Engine costs nothing to get started. All applications can use up to 1 GB of storage and enough CPU and bandwidth to support an efficient app serving around 5 million page views a month, absolutely free. When you enable billing for your application, your free limits are raised, and you only pay for resources you use above the free levels.
In the first video module we will start off with the boilerplate code for a new app (Hello World)
We will learn about the different files needed to get an app running on appengine and how to use the Development Server and Local Host for developing our code base.
We will update the Boilerplate Code and create a starting point for our File Structure.
Jinja2 is a modern and designer friendly templating language for Python, modelled after Django’s templates. It is fast, widely used and secure with the optional sandboxed template execution environment
We will use Jinja2 template, which can be imported straight from Python2.7, to give life to our website.
ALSO!!!!! a great Tutorial on HTML one-page layout can be found here
So you’ve cracked your knuckles and started working on that awesome python webapp you want to write. You get through writing a few pages and finally you need to tackle that loathsome task: form input handling and validation. Enter WTForms.
But why do I need yet another framework? Well, some webapp frameworks take the approach of associating database models with form handling. While this can be handy for very basic create/update views, chances are not every form you need can map directly to a database model. Or maybe you already use a generic form handling framework but you want to customize the HTML generation of those form fields, and define your own validation.
With WTForms, your form field HTML can be generated for you, but we let you customize it in your templates. This allows you to maintain separation of code and presentation, and keep those messy parameters out of your python code. Because we strive for loose coupling, you should be able to do that in any templating engine you like, as well.
NDB saves data objects, known as entities. An entity has one or more properties, named values of one of several supported data types. For example, a property can be a string, an integer, or a reference to another entity.
NDB can group multiple operations in a single transaction. The transaction cannot succeed unless every operation in the transaction succeeds; if any of the operations fail, the transaction is automatically rolled back. This is especially useful for distributed web applications, where multiple users may be accessing or manipulating the same data at the same time.
NDB uses Memcache as a cache service for "hot spots" in the data. If the application reads some entities often, NDB can read them quickly from cache.
An application uses NDB to define models. A model is a Python class that acts as a sort of database schema: it describes a kind of data in terms of the properties. The underlying Datastore is very flexible in how it stores data objects—two entities of the same kind can have different properties. An application can use NDB models to enforce type-checking but doesn't have to.
Each entity is identified by a key, an identifier unique within the application's datastore. The key can have a parent, another key. This parent can itself have a parent, and so on; at the top of this "chain" of parents is a key with no parent, called the root.
Entities whose keys have the same root form an entity group or group. If entities are in different groups, then changes to those entities might sometimes seem to occur "out of order". If the entities are unrelated in your application's semantics, that's fine. But if some entities' changes should be consistent, your application should make them part of the same group when creating them.
App Engine applications can send email messages on behalf of the app's administrators, and on behalf of users with Google Accounts. Apps can receive email at various addresses. Apps send messages using the Mail service and receive messages in the form of HTTP requests initiated by App Engine and posted to the app.
When you create a new application with Google App Engine, your app is served on the appspot.com domain. If you want your application to be served on a custom domain in addition to appspot.com, you can use a domain you already control or you can register a new one. If you prefer, you can serve your application on all subdomains in a given custom domain by using wildcard subdomain mapping.
Unit testing allows you to check the quality of your code after you've written it, but you can also use unit testing to improve your development process as you go along. Instead of writing tests after you finish developing your application, consider writing the tests as you go. This helps you design small, maintainable, reusable units of code. It also makes it easier for you to test your code thoroughly and quickly.
When you do local unit testing, you run tests that stay inside your own development environment without involving remote components. App Engine provides testing utilities that use local implementations of datastore and other App Engine services. This means you can exercise your code's use of these services locally, without deploying your code to App Engine, by using service stubs.
A service stub is a method that simulates the behavior of the service. For example, the datastore service stub shown in Writing Datastore and Memcache Tests allows you to test your datastore code without making any requests to the real datastore. Any entity stored during a datastore unit test is held in memory, not in the datastore, and is deleted after the test run. You can run small, fast tests without any dependency on datastore itself.
UneedTesting Framwork -> http://code.google.com/p/uneedtest/
The Local Unit Testing for Python article described how to run unit tests for your application. While unit tests are great for testing the separate units of your code, the integration of those code units is what makes your application run—so integration testing is just as important.
For App Engine applications, request handlers are critical integration points. While a WSGI application routes requests to the right handler, the handler itself processes the request data and generates a response (read more about Request Handlers). Request handlers are normal Python objects like any other function or class, which makes them easy to use in automated tests. But because a WSGI application wraps them like a shell, we will use a similar shell in our tests.
App Engine applications can authenticate users who have Google Accounts, accounts on your own Google Apps domain, or OpenID identifiers. An application can detect whether the current user has signed in, and can redirect the user to a sign-in page to sign in or create a new account. While a user is signed in to the application, the app can detect whether the current user is an administrator, making it easy to implement admin-only areas of the app.
We will be using the Users API to create an Admin Section to our website.
In this video we will expand and udate our Admin Page with a Template and look at how we can use and manage our Data using the NDB API. The NDB API provides persistent storage in a schemaless object datastore. It supports automatic caching, sophisticated queries, and atomic transactions. NDB is well-suited to storing structured data records. It provides an alternative to the App Engine Datastore API.
The Blobstore API allows your application to serve data objects, called blobs, that are much larger than the size allowed for objects in the Datastore service. Blobs are created by uploading a file through an HTTP request. Typically, your applications will do this by presenting a form with a file upload field to the user. When the form is submitted, the Blobstore creates a blob from the file's contents and returns an opaque reference to the blob, called a blob key, which you can later use to serve the blob.
Link to "Python - The Next Level" course:
Here is a Coupon Code for approx. 50% OFF cost of course: 19820516
(Coupon code included with link above)
Source Code for Appengine Project in the Course (Not including the HTML, CSS or JS files)
Constant state of learning, thirst for the artistic and I love the product of hard work. I try to bring the creative passion into my entrepreneurial endeavors. I currently operate 2 businesses in the fields of Architectural Design, and Computer Programming.
I pride himself on keeping things simple while have fun during the learning process.
"Hands on learning is the ultimate path to a solid education."
With a down to earth and fun loving "Not So Serious" learning path, I feels my courses can make everyone feel comfortable learning even the hardest of topics.