README.md in celluloid-0.6.0 vs README.md in celluloid-0.6.1

@@ -327,10 +327,39 @@
 working, freshly-restarted version.
 
 The main use of the registry is for interfacing with actors that are
 automatically restarted by supervisors when they crash.
 
+Applications
+------------
+
+Celluloid provides a DSL for describing all of the actors in a given
+application. This lets you start a group of actors in one swoop and
+also provides an additional level of supervision: applications supervise
+the supervisors of all the actors in your system, an approach known
+as supervision trees.
+
+Define Celluloid::Applications with the following syntax:
+
+    class MyApplication < Celluloid::Application
+      supervise MyActor, :as => :my_actor
+      supervise AnotherActor, :as => :another_actor
+    end
+
+This will start the MyActor and AnotherActor actors under a supervisor and
+automatically register them as Celluloid::Actor[:my_actor] and
+Celluloid::Actor[:another_actor].
+
+To launch your application, do:
+
+    MyApplication.run
+
+This launches your application in the foreground. To launch in in the
+background, do:
+
+    MyApplication.run!
+
 Signaling
 ---------
 
 Signaling is an advanced technique similar to condition variables in typical
 multithreaded programming. One method within a concurrent object can suspend
@@ -456,12 +485,14 @@
 
 Here are a few rules you can follow to keep this from happening:
 
 1. ***NEVER RETURN SELF*** (or pass self as an argument to other actors): in
    cases where you want to pass an actor around to other actors or threads,
-   use Celluloid.current_actor. If you grab the latest master of Celluloid
-   off of Github, you can just use the #current_actor method when you are
-   inside of an actor itself.
+   use Celluloid.current_actor, or if you're within an actor itself, you can
+   just call the #current_actor method. If you really need to get ahold of
+   "self" in order to add instance-specific behavior, e.g for metaprogramming
+   purposes or adding stubs during tests, call MyActor#wrapped_object to
+   obtain the actual object an actor is wrapping.
 
 2. Don't mutate the state of objects you've sent in calls to other actors:
    This means you must think about data in one of two different ways: either
    you "fire and forget" the data, leaving it for other actors to do with
    what they will, or you must treat it as immutable if you have any plans