Friday, February 27, 2009

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions.

I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which?

Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both professionally.

I feel like I'm in the same situation again. Erlang is clearly successful and useful, but its syntax is not so wonderful. Haskell is profoundly elegant, and perhaps even higher level, but it doesn't seem as popular, nor does it seem to have success stories as great as Erlang does.

Another interesting thing to note is that Erlang is really good at Erlang-style concurrency. Haskell doesn't have the same zen in this field as Erlang has, but Haskell has successfully tackled a wider variety of approaches to concurrency--at least, that's the feeling I get when I read this page.

Is there anyone out there who enjoys Python's elegance as much as I do who can give me some advice on committing to either Erlang or Haskell? Am I too far ahead of the curve in my hopes to one day code professionally in one or the other? Should I just wait for Reia? Have any mere mortals such as I had success with reading Real World Haskell? Should I take a break from playing with weird languages and do something useful, like write a Facebook app or an Android app?

Friday, February 20, 2009

Computer History: Epigrams in Programming

If you haven't read Alan Perlis's Epigrams in Programming, it's worth taking a few minutes.

Wednesday, February 18, 2009

Python: Logging to Email in Pylons

I figured out how to get Pylons to send logging messages via email. Note, this is separate of the Paste mechanism which sends email when there is an uncaught exception. Here's a diff of my .ini file:
-keys = console
+keys = console, smtp

keys = generic

level = INFO
-handlers = console
+handlers = console, smtp

class = StreamHandler
@@ -67,5 +67,11 @@
level = NOTSET
formatter = generic

+class = logging.handlers.SMTPHandler
+args = ('', 'myapp@localhost', [''], 'myapp log message')
+level = WARN
+formatter = generic
Once everything is setup, you can add calls like the following to your controllers:
log.error("This is a test of the logging system.")

Monday, February 16, 2009

MySQL: MySQLdb Bugs

Here's a blog post from the author of MySQLdb that explains why development was at a standstill for so long.

Friday, February 13, 2009

Vi In JavaScript

Benjamin Sergeant sent me a link to Vi in JavaScript. Heh, cool hack. Reminds me of JS/UIX which is an implementation of UNIX in JavaScript.

Friday, February 06, 2009

Books: Ruby for Rails

I just finished a series of blog posts called Ruby: A Python Programmer's Perspective. Now, I'd like to finish up by writing a quick review of Ruby for Rails. Overall, it wasn't bad. If you can't tell by my other posts, I learned a lot. I really enjoyed the middle of the book which covered Ruby, but I got bored toward the end when the author spent three chapters improving an ecommerce site.

The author appears to be an intelligent, native English speaker, however his grammar patterns made it difficult for me to read the book quickly. Here is an example:
We must be able to determine before executing an action what state we're in with regard to the visitor's login status and its importance. [p. 440]
Translation: "Don't show the login form if the user is already logged in."

Here's another example:
Facility with Ruby will stand you in good stead in your controller programming, as well as your model programming. [p. 438]
Translation: "If you don't know Ruby, you're going to have a hard time writing controllers and models." Note, this sentence is in chapter 16. I would argue that anyone who has made it to chapter 16 knows that you need to know Ruby to be proficient with Rails ;)

By and large, the code was pretty good. However, there were a few times when I was pulling my hair out. Here's an example:
def Work.all_periods
find(:all).map {|c| c.period }.flatten.uniq.sort
This ActiveRecord code pulls down every musical Work in the entire database in order to get a list of the 5 or so musical periods. I know that people love to say that Rails doesn't scale. Given this example, I'd have to agree. I would have preferred to see the code that makes the database do the hard work instead of downloading the entire table to the application server.

One thing I will say about this book is that a lot of people have read it. I like to submit errata to authors. If I find a technical error in a book, it's a good sign that I'm paying attention, so I try to find as many errors as possible. When I went to submit errata for this book, about half of the errors I found had already been submitted by other readers. That was pretty impressive.

In summary, if you need to learn Ruby in order to use Rails, this book is worth reading.

Thursday, February 05, 2009

Ruby: A Python Programmer's Perspective Part IV

This is a somewhat random list of things that were interesting or surprising to me when I read Ruby for Rails. The previous post in the series is Ruby: A Python Programmer's Perspective Part III.

It's possible to add methods directly to an object instead of to a class:
>> obj =
=> #<Object:0x348c44>
>> def
>> puts "Hi!"
>> end
=> nil
=> nil
The methods are attached to what's called a singleton class. There is a singleton class that is associated with every object:
You can think of an object's singleton class as an exclusive stash of methods, tailor-made for that object and not shared with other objects--not even with other instances of the object's class
Class methods are similarly methods that are attached to the singleton class of an object of type Class.

There's even this weird syntax to attach additional methods to a class's singleton class:
?> class << C
>> def f2
>> puts 'f2'
>> end
>> end
=> nil
?> C.f1
=> nil
>> C.f2
=> nil
It's possible in Python to attach methods directly to an object in Python too, but there is no formal notion of a singleton class. However, every object in Python does have a __dict__ which is a dict containing all the state and methods for that object:
>>> class C:
... def f(self): pass
>>> c = C()
>>> = 'bar'
>>> c.__dict__
{'foo': 'bar'}
>>> C.__dict__
{'__module__': '__main__', '__doc__': None, 'f': <function f at 0x6fef0>}
Moving on--you can inject a module's methods directly into an object:
obj =
Here's a useful way to inspect the class hierarchy:
?> class D < C
>> p ancestors
>> end
[D, C, Object, Kernel]
=> nil
In Ruby, singleton classes of class objects are sometimes called metaclasses. This is confusingly different from metaclasses in Python. In Python, a metaclass is the class (aka type) of a class. Hence, Python would call the Ruby class named Class a metaclass, whereas in Ruby, the metaclass of a class named C is an anonymous container for the class methods of C. Does your brain hurt yet? ;)

Ruby has a global named $SAFE:
It's very difficult to clean up user the point where you can feel safe about running eval on it. Ruby maintains a global variable called $SAFE, which you can set to a higher number (on a scale of 0 to 4) to gain protection from dangers like rogue file-writing requests. $SAFE makes life with eval a lot safer. Still, the best habit to get into is the habit of not using eval. [p. 348]
You can break into an object's private data using instance_eval:
>> class C
>> def initialize
>> @x = 1
>> end
>> end
=> nil
?> c =
=> #<C:0x360718 @x=1>
>> c.instance_eval { puts @x }
=> nil
Here's a fun way to inject methods dynamically into a class:
>> Object.class_eval { define_method("foo") { puts 'hi' } }
=> #<Proc:0x0035b100@(irb):15>
>> obj =
=> #<Object:0x3599cc>
=> nil
Unlike Python, JavaScript, and Scheme, you don't get closures just by nesting functions:
?> def f
>> def g
>> puts a
>> end
>> a = 1
>> g
>> end
=> nil
?> f
NameError: undefined local variable or method `a' for main:Object
from (irb):29:in `g'
from (irb):32:in `f'
from (irb):35
That's because method scopes don't stack on top of one another. However, you can create a closure using
>> def f
>> a = "hi"
>> g = do
?> puts a
>> end
>> end
=> nil
?> f
=> nil
I think I like the Scheme approach better.

Proc objects handle arguments in a different way than methods do. It's sloppier--more like JavaScript and Perl:
>> def f(x)
>> p x
>> end
=> nil
?> f(1, 2, 3)
ArgumentError: wrong number of arguments (3 for 1)
from (irb):56:in `f'
from (irb):56
?> p = {|x| p x}
=> #<Proc:0x0033a414@(irb):58>
?>, 2, 3)
(irb):58: warning: multiple values for a block parameter (3 for 1)
from (irb):60
[1, 2, 3]
=> nil
Notice that calling a proc with the wrong number of arguments resulted in a warning instead of an exception and that all the arguments were pushed into a list in order to fit into one parameter.

Here's another example of this. Notice how Ruby will or will not unpack a list depending on context:
>> [[1, 2]].each {|x| p x}
[1, 2]
=> [[1, 2]]
>> [[1, 2]].each {|x, y| p(x, y)}
=> [[1, 2]]
I suspect this might be convenient, but I wonder if it occasionally bites unsuspecting programmers.

The lambda keyword lets you create an anonymous function. A lambda is an object of class Proc. However, lambdas and behave differently when it comes to the return statement:
>> def return_test
>> l = lambda { return } # This return exits the lambda.
>> puts "Still here!"
>> p = { return } # This return exits return_test.
>> puts "You won't see this."
>> end
=> nil
?> return_test
Still here!
=> nil
The book says:
The matter of how Proc objects, code blocks, and lambdas related to each other has been, and still is, in a certain amount of flux. Don't be surprised if you see differences...from one version of Ruby to another. [p. 355]
To confuse things further:
It's worth mentioning that lambda has a synonym: proc. However, because proc and look and sound so similar, but don't do exactly the same thing, Matz has agreed in principle to phase out proc, leaving just and lambda. [p. 356]
Code blocks are not instances of Proc. They exist only in the syntax of Ruby. There is no such thing as a Block class or a Block object. However, you can convert a code block into a Proc object.

Ruby also supports bound methods:
>> class C
>> def f
>> puts 'f'
>> end
>> end
=> nil
?> c =
=> #<C:0x326a7c>
>> my_f = c.method(:f)
=> #<Method: C#f>
=> nil
You can also unbind and rebind a bound method to another instance.

Here's something I personally haven't seen in any other language. You can capture the act of subclassing a class, mixing in a module, or adding a method to a class as a runtime event. For instance, ActiveRecord in Ruby on Rails uses this functionality. Anytime someone subclasses ActiveRecord::Base, it captures the event (by defining a class method called "inherited") and adds the class to a list named "@@subclasses".

To alias a function under a new name, use the alias keyword: "alias :old_name :new_name". This is interesting, because in Python, you would just write "old_name = new_name". In Python, it's mandatory to use parenthesis when you call a function, so "old_name = new_name" is no different than saying "a = b" if a and b are both ints. The same isn't true of Ruby because "old_name = new_name" is essentially like "old_name() = new_name()" which doesn't even make sense. It's not a big deal, but it's just interesting to note that by making parenthesis non-mandatory, it leads to having an alias keyword. It also leads to writing "" instead of "my_proc()".

Everyone knows Ruby's string interpolation syntax: "Foo: #{bar}". However, Ruby also appears to support Python-like string interpolation:
>> puts "I weigh %.2f pounds." % 205.3
I weigh 205.30 pounds.
Ruby returns the value of the last expression encountered in the function. This is convenient if you don't want to have to explicitly type "return". However, I think it can lead to some unexpected results. Namely, unless a function documents what it's going to return, you should just assume it's going to return garbage:
def do_something
# Doing something.

def print_name(name)
puts "Name is #{name}"

def talk_to_user
puts "What's your name?"
name = gets

In the above code, talk_to_user will return 5 even though 5 has absolutely nothing to do with talk_to_user. In Python, if you don't explicitly "return" something, the function will return None by default.

Okay, that's it. If you've made it this far, thanks for reading!

Ruby: A Python Programmer's Perspective Part III

This is a somewhat random list of things that were interesting or surprising to me when I read Ruby for Rails. The previous post in the series is Ruby: A Python Programmer's Perspective Part II.

I've mentioned before that Ruby has symbols which are similar to, but distinct from, strings (which are mutable). The syntax is :foo. To create a symbol with spaces, use :"foo bar".

Ruby has two syntax for ranges. ".." includes both endpoints. "..." does not include the right endpoint and thus behaves like slices in Python do:
>> (0...2).each {|x| p x}
=> 0...2

>> (0..2).each {|x| p x}
=> 0..2
Since the "+" operator is just syntactic sugar for the "+" method, the following are equivalent:
>> 1 + 1
=> 2
>> 1.+(1)
=> 2
Whenever possible, I think interpreters should raise an exception if you misspell something. Hence, I found the following interesting:
>> def f
>> p @undefed_instance_variable # This prints nil.
>> p undefined_local # This raises a NameError.
>> end
=> nil
>> f
NameError: undefined local variable or method `undefined_local' for main:Object
from (irb):39:in `f'
from (irb):41
nil and false are the only two objects that evaluate to false:
>> if []: puts "Still true"; end
Still true
=> nil
In Python, "truthiness" is a lot more complex. For instance, [1] is true, whereas [] is false, and in general, classes can define their own notion of truthiness.

Ruby has "==", "===", ".eql", and ".equal". "===" is for case statements. "==" is related to ">=", etc. ".eql" tests that the two objects have the "same content". Usually, "==" and ".eql" return the same thing, but their implementation is different. ".equal" is reserved for object identity. Hence:
>> "a" == "a"
=> true
>> "a".eql?("a")
=> true
>> "a".equal?("a")
=> false
>> "a" === "a"
=> true
If you want to see all of a class's instance methods, use the "instance_methods" method. If you don't want to see inherited methods, pass false to "instance_methods":
>> class C
>> def f
>> end
>> end
=> nil
?> C.instance_methods
=> ["inspect", "f", "clone", "method", "public_methods",
"instance_variable_defined?", "equal?", "freeze", "methods", "respond_to?",
"dup", "instance_variables", "__id__", "object_id", "eql?", "require", "id",
"singleton_methods", "send", "taint", "frozen?", "instance_variable_get",
"__send__", "instance_of?", "to_a", "type", "protected_methods",
"instance_eval", "==", "display", "===", "instance_variable_set", "kind_of?",
"extend", "to_s", "hash", "class", "tainted?", "=~", "private_methods", "gem",
"nil?", "untaint", "is_a?"]
?> C.instance_methods(false)
=> ["f"]
Using Class.instance_methods.sort is helpful too.

When you are appending one string onto the end of another string, using += does not modify the original string, whereas << does:
>> s = "foo"
=> "foo"
>> t = s
=> "foo"
>> s += "bar"
=> "foobar"
>> s
=> "foobar"
>> t
=> "foo"
>> u = t
=> "foo"
>> u << "bar"
=> "foobar"
>> u
=> "foobar"
>> t
=> "foobar"
Indexing a string returns that character's ASCII value, which is a bit surprising. Slicing does what you would expect:
=> "abc"
>> s[1]
=> 98
>> s[1,1]
=> "b"
However, indexing a string to set a character works as expected:
>> s[1] = 'B'
=> "B"
>> s
=> "aBc"
Arrays have a "concat" method. "concat" and "+" operate as you might expect. "concat" is conceptually "concat!" because it modifies the array, but it's spelled without the "!":
>> s = [1, 2]
=> [1, 2]
>> t = [3, 4]
=> [3, 4]
>> s + t
=> [1, 2, 3, 4]
>> s
=> [1, 2]
>> s.concat(t)
=> [1, 2, 3, 4]
>> s
=> [1, 2, 3, 4]
>> t
=> [3, 4]
To get both the values and indexes of an array as you loop over it, use the each_with_index method:
>> ['a', 'b', 'c'].each_with_index {|x, i| puts "#{i} => #{x}"}
0 => a
1 => b
2 => c
There are a couple ways to create a hash. The second syntax is a bit weird to my eyes:
>> {:a => :b}
=> {:a=>:b}

>> Hash[:a => :b]
=> {:a=>:b}
By default, you'll get nil if you try to lookup a key that doesn't exist in a hash. As I've mentioned before, I prefer to get exceptions by default if I misspell things. Fortunately, the fetch method exists:
>> h = {:a => :b}
=> {:a=>:b}
>> h[:c]
=> nil
>> h.fetch(:c)
IndexError: key not found
from (irb):50:in `fetch'
from (irb):50
The default nil behavior of Ruby hashes is particular frustrating to me since Ruby uses hashes for keyword arguments. It's really easy for a misspelled option to lead to a silent bug:
>> def f(arg, options)
>> p arg
>> if options[:excited]
>> puts "Oh, yeah!" # This doesn't get printed.
>> end
>> end
=> nil
?> f("hello", :excitid => true) # Oops, typo.
=> nil
I think real support for keyword arguments is better. Here's the Python:
>>> def f(arg, excited=False):
... print arg
... if excited:
... print "Yeah!"
>>> f("hello", excitid=True)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: f() got an unexpected keyword argument 'excitid'
You can still use the Ruby approach in Python using the "**kargs" syntax, but it's not the default.

I was a little surprised that you could connect two statements with a semicolon inside parenthesis:
>> (puts 'hi'; puts 'there') unless 100 < 10
=> nil
Iterating over a string yields lines, not characters like it does in Python:
>> "foo\nbar".each {|line| puts line}
=> "foo\nbar"
When using regular expressions, the =~ operator returns the index of the match, whereas the #match method returns a MatchData object:
>> /o/ =~ 'foo'
=> 1
>> /o/.match('foo')
=> #<MatchData:0x35d5cc>
Be careful. The MatchData object stores captures starting at 1, whereas the #captures method stores captures starting at 0:
>> match = /(o)/.match('foo')
=> #<MatchData:0x357654>
>> match[1]
=> "o"
>> match.captures[0]
=> "o"
See my earlier post concerning "^" vs. "\A" in regular expressions. Ruby and Python are subtly different. Whereas I would normally use "^" in Python, to get the same behavior, I would use "\A" in Ruby.

If you want to treat a string as an array of characters, use '"foobar".split(//)'.

String#scan is a pretty cool method that repeatedly tries to match a regular expression while iterating over a string. Unlike #match, it returns all of the matches, instead of just the first:
>> s = "John Doe was the father of Jane Doe."
=> "John Doe was the father of Jane Doe."
>> s.scan(/([A-Z]\w+)\s+([A-Z]\w+)/)
=> [["John", "Doe"], ["Jane", "Doe"]]
Okay, that's it for this post, but I've got more coming :)

Ruby: A Python Programmer's Perspective Part II

This is a somewhat random list of things that were interesting or surprising to me when I read Ruby for Rails. You may also be interested in my previous post: Ruby: A Python Programmer's Perspective.

In Python, directories map to packages and files map to modules. This is similar to Java. Ruby is not like this. Ruby is more like Perl. Basically, any file in any directory can contain code for any module. That means that there are module declarations in the code itself.

Ruby has global variables. They start with $, such as $gvar.

A variable defined at the top-level of a file is not global. The top-level has its own local scope, just as class, module, and method definition blocks each have their own local scope::
>> a = 1
=> 1
>> def f()
>> p a
>> end
=> nil
>> f
NameError: undefined local variable or method `a' for main:Object
from (irb):3:in `f'
from (irb):5
This is different than Python that treats anything at the top-level of a file as a module-level global.

Ruby does not segregate global variables into modules. They're really global:
>> module M
>> $a = 'foo'
>> end
=> "foo"
>> $a
=> "foo"
Variables that start with an uppercase letter are constants. Hence, you can't treat them like normal variables:
>> def a
>> L = 1
>> end
SyntaxError: compile error
(irb):13: dynamic constant assignment
L = 1
from (irb):14
The way private methods work is a bit unusual compared to C++, Java, etc. A private method is a method that cannot be called on any object other than the implicit self. That means, you cannot have an explicit receiver--even if the receiver is of the same class!
>> class C
>> def public_method
>> puts "Public!"
>> private_method # An implicit receiver is okay.
>> end
?> def someone_elses_private(other)
>> other.private_method # An explicit receiver is not.
>> end
?> private
>> def private_method
>> puts "Private!"
>> end
>> end
=> nil
?> c =
=> #<C:0x34911c>
>> c.public_method
=> nil
>> d =
=> #<C:0x346cdc>
>> c.someone_elses_private(d)
NoMethodError: private method `private_method' called for #<C:0x346cdc>
from (irb):33:in `someone_elses_private'
from (irb):45
That means you can't even explicitly write "self.private_method"!

Ruby has variables at the class level and it has class variables, and they're not the same:
>> class C
>> @class_instance_variable = 'hi'
?> def self.class_scope_method
>> p @class_instance_variable # This works.
>> end
?> def set_class_variable
>> @@class_variable = 'bar'
>> end
?> def print_class_variable
>> p @@class_variable # This works.
>> puts "Now, try @@class_instance_variable:"
>> p @@class_instance_variable # This doesn't.
>> end
>> end
=> nil
?> C.class_scope_method
=> nil
>> c =
=> #<C:0x31946c>
>> d =
=> #<C:0x317fe0>
>> c.set_class_variable
=> "bar"
>> d.print_class_variable
Now, try @@class_instance_variable:
NameError: uninitialized class variable @@class_instance_variable in C
from (irb):77:in `print_class_variable'
from (irb):85
The book says:
Class variables, like @@subclasses...are scoped in such a way that they are visible when self is the class to which they belong, a descendant (to any level) of that class, or an instance of the class or its descendants. Despite their name, they're not really class scoped; they're more like hierarchy scoped. Matz has mentioned plans to change the scoping of class variables in future versions of Ruby so that their visibility is more confined to the class (or module; modules can have class variables too) where they're defined. [p. 364]
These are all pretty much the same:
>> x = 11
=> 11
>> if x > 10: puts x; end
=> nil
>> if x > 10 then puts x; end
=> nil
>> puts x if x > 10
=> nil
Ruby has "===" and "==". "===" is called the "threequal operator" and it is the backbone of the case statement. Every class can define "===" and "==" in any way it sees fit, and they may not be the same. Ruby does not have an "is" keyword like Python does.

Ruby has a do/while construct like C:
>> begin
?> puts 'hi'
>> end while false
=> nil
This is something that Python lacks, probably because the syntax doesn't fit into the language.

Compared to C, C++, Java, and JavaScript, I think Ruby finally got the switch statement right. There's no need to use the word break:
case "foo"
when "foo"
puts "yep"
when "bar"
puts "impossible!"
puts "huh?"
Ruby has an interesting method-level syntax for exceptions handling:
>> def f
>> 1/0
>> rescue
>> puts "safe!"
>> end
=> nil
>> f
=> nil
Okay, that's it for this post, but I've got more coming :)

Tuesday, February 03, 2009

REST: RESTful Shopping Carts

I've been thinking about the book RESTful Web Services. It has lots of negative things to say about cookies, for instance, "OK, so cookies shouldn't contain session IDs" [p. 252]. Elsewhere in the book, it describes a scheme using temporary URLs for transactions [p. 231].

I was thinking about shopping carts. If you can't use a cookie to store a session ID, then it seems natural to embed the session ID into the URL. (I'm thinking about the case when the user hasn't even logged in yet.) However, therein lies the problem. If you put the session ID in the URL, you open yourself up to well-known session fixation attacks.

Let me explain. Attacker A creates a shopping cart on a legitimate Web site that embeds the session ID (or some other sort of state) in the URL. Attacker A spams a bunch of people. A victim V clicks on the link. He knows that the site is legitimate. He adds a few things to his cart, logs in, and places the order. At this point, the attacker has the user's session ID. He can do whatever he wants with the user's account.

Perhaps I'm completely making this up. Part of being RESTful is being stateless. However, people like to have shopping carts, so some sort of state is necessary as is some way of tying a user (who isn't logged in) to that state. Perhaps there is indeed a way to maintain a shopping cart without requiring the user to log in and without using a cookie. However, naively shoving a session ID into the URL ain't it.

Python: Google App Engine

Here are some things I found interesting, deep, or surprising while reading the documentation for Google App Engine:

Being able to easily roll back to a previous version of your application is a really nice feature.

webapp uses "self.request" instead of a magic global named "request" like Pylons. (Note, magic globals act as proxies for the actual request object which is stored in thread local storage.)

I'm a little confused by:
 run_wsgi_app() is similar to the WSGI-to-CGI adaptor provided by the
wsgiref module in the Python standard library, but includes a few
additional features.
Does that mean GoogleAppEngineLauncher's default template should be updated since it doesn't use run_wsgi_app()?

GQL is meant to be familiar for SQL users, but it knows what you mean when you say:
 greetings = Greeting.gql("ORDER BY date DESC LIMIT 10")
Bret told me:
A good rule of thumb for whether you need transactions is whether you have a set that is based on a get and they essentially have to be atomic.
Concerning keys:
Each entity also has a key that uniquely identifies the entity. The simplest key has a kind and a unique numeric ID provided by the datastore. The ID can also be a string provided by the application.
Use " --clear_datastore appname" to wipe the datastore.

Note that if you elect to use the free domain name, the full URL for the application will be "". I think that means other apps can set cookies for Those can impact my app. I think this is a security problem.

This is interesting:
 type = db.StringProperty(required=True, choices=set(["cat", "dog", "bird"]))
I almost forgot to notice that I didn't really need to load the schema (i.e. model) ahead of time. I just created an object, and that was enough.

Concerning schemas:
A model defined using the Model class establishes a fixed set of properties that every instance of the class must have (perhaps with default values). This is a useful way to model data objects, but the datastore does not require that every entity of a given kind have the same set of properties...An expando model can have both fixed and dynamic properties.
Concerning lists:
A property can have multiple values, represented in the datastore API as a Python list...A single list property may even have values of different types.
 hobbies = db.StringListProperty()
More about schemas:
Two entities of the same kind can have different types of values for the same dynamic property.
Concerning references:
The ReferenceProperty class models a key value, and enforces that all values refer to entities of a given kind.
Here's how to set a reference:
 obj2.reference = obj1.key()  # Or:
obj2.reference = obj1
Concerning orphans:
When an entity whose key is the value of a reference property is deleted, the reference property does not change. A reference property value can be a key that is no longer valid. If an application expects that a reference could be invalid, it can test for the existence of the object using an if statement.
Concerning back-references:
ReferenceProperty has another handy feature: back-references. When a model has a ReferenceProperty to another model, each referenced entity gets a property whose value is a Query that returns all of the entities of the first model that refer to it.
The way they did this is a bit cleaner in my opinion than in Rails since you don't have to duplicate the knowledge about the relationship in both models.

Dynamic properties of expando classes don't do as much. For instance, they're not even validated. There are other limitations as well.

Concerning query laziness:
Query and GqlQuery objects do not execute the query until the application tries to access the results.
Concerning query limits:
The datastore returns a maximum of 1000 results in response to a query, regardless of the limit and offset used to fetch the results. The 1000 results includes any that are skipped using an offset, so a query with more than 1000 results using an offset of 100 will return 900 results.
Concerning keys:
The string encoding of a Key is opaque, but not encrypted. If your application needs keys to not be guessable, you should further encrypt the string-encoded Key before sending it to the user.
Concerning deleting ancestors:
Deleting an entity that is an ancestor for other entities does not affect the other entities. As long as the application does not depend on the existence of the ancestor to build keys for the descendant entities, the application can still access the descendants.
Concerning entity groups:
Only use entity groups when they are needed for transactions. For other relationships between entities, use ReferenceProperty properties and Key values, which can be used in queries...A good rule of thumb for entity groups is that they should be about the size of a single user's worth of data or smaller.
Concerning numeric IDs:
An application should not rely on numeric IDs being assigned in increasing order with the order of entity creation. This is generally the case, but not guaranteed.
Concerning indexes:
An App Engine application defines its indexes in a configuration file named index.yaml. The development web server automatically adds suggestions to this file as it encounters queries that do not yet have indexes configured...The App Engine datastore maintains an index for every query an application intends to make. As the application makes changes to datastore entities, the datastore updates the indexes with the correct results.
The query engine does support IN filters.

More on indexes:
An index only contains entities that have every property referred to by the index. If an entity does not have a property referred to by an index, the entity will not appear in the index, and will never be the result for the query that uses the index...If you want every entity of a kind to be a potential result for a query, you can use a data model that assigns a default value (such as None) to the properties used by filters in the query.
Concerning properties with mismatched types:
When two entities have properties of the same name but of different value types, an index of the property sorts the entities first by value type, then by an order appropriate to the type...A property with the integer value 38 is sorted before a property with the floating point value 37.5, because all integers are sorted before floats.
This one hurts my brain:
If a query has both a filter with an inequality comparison and one or more sort orders, the query must include a sort order for the property used in the inequality, and the sort order must appear before sort orders on other properties.
This one is fun:
This sort order has the unusual consequence that [1, 9] comes before [4, 5, 6, 7] in both ascending and descending order.
Concerning exploding indexes:
You can avoid exploding indexes by avoiding queries that would require a custom index using a list property. As described above, this includes queries with descending sort orders, multiple sort orders, a mix of equality and inequality filters, and ancestor filters.
Concerning transactions:
A transaction cannot perform queries using Query or GqlQuery.
Concerning create-or-update:
Create-or-update is so useful that there is a built-in method for it: Model.get_or_insert() takes a key name, an optional parent, and arguments to pass to the model constructor if an entity of that name and path does not exist.
There is a tool for bulk loading data.

When I went looking for benchmarks several months ago, I couldn't find any. Hence, I used ab to benchmark the hello world that is developed in the tutorial. The app only uses webapp and only has one query. Note, I did "prime the pump" to give GAE a chance to warm up:
ab -c 20 -n 1000 ''
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd,
Licensed to The Apache Software Foundation,

Benchmarking (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Google
Server Hostname:
Server Port: 80

Document Path: /
Document Length: 759 bytes

Concurrency Level: 20
Time taken for tests: 9.510 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 924924 bytes
HTML transferred: 759759 bytes
Requests per second: 105.16 [#/sec] (mean)
Time per request: 190.192 [ms] (mean)
Time per request: 9.510 [ms] (mean, across all concurrent requests)
Transfer rate: 94.98 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 15 32 12.0 31 91
Processing: 106 157 49.9 146 846
Waiting: 105 157 49.9 146 846
Total: 130 189 50.8 178 872

Percentage of the requests served within a certain time (ms)
50% 178
66% 190
75% 200
80% 209
90% 229
95% 245
98% 290
99% 357
100% 872 (longest request)
Latency is the thing I care about most (I assume GAE scales well). Those numbers look pretty decent ;)