Merge pull request twitter#78 from williamho/typo-fix

fix typos

web/advanced-types.textile

@@ -156,7 +156,7 @@ h2(#higher). Higher-kinded types & ad-hoc polymorphism
 
 Scala can abstract over "higher kinded" types. For example, suppose that you needed to use several types of containers for several types of data. You might define a <code>Container</code> interface that might be implemented by means of several container types: an <code>Option</code>, a <code>List</code>, etc. You want to define an interface for using values in these containers without nailing down the values' type.
 
-This is analagous to function currying. For example, whereas "unary types" have constructors like <code>List[A]</code>, meaning we have to satisfy one "level" of type variables in order to produce a concrete types (just like an uncurried function needs to be supplied by only one argument list to be invoked), a higher-kinded type needs more.
+This is analogous to function currying. For example, whereas "unary types" have constructors like <code>List[A]</code>, meaning we have to satisfy one "level" of type variables in order to produce a concrete types (just like an uncurried function needs to be supplied by only one argument list to be invoked), a higher-kinded type needs more.
 
 <pre>
 scala> trait Container[M[_]] { def put[A](x: A): M[A]; def get[A](m: M[A]): A }
@@ -209,7 +209,7 @@ However, this now necessitates the compare method
 def compare(that: Container): Int
 </pre>
 
-And so we cannot access the concrete subtype, eg.:
+And so we cannot access the concrete subtype, e.g.:
 
 <pre>
 class MyContainer extends Container {

web/basics.textile

@@ -31,7 +31,7 @@ h3. Why Scala?
 * Concise
 ** Type inference
 ** Literal syntax for function creation
-* Java interopability
+* Java interoperability
 ** Can reuse java libraries
 ** Can reuse java tools
 ** No performance penalty
@@ -176,7 +176,7 @@ You will see this syntax often used when passing an anonymous function as an arg
 
 h3. Partial application
 
-You can partially apply a function with an underscore, which gives you another function. Scala uses the underscore to mean different things in different contexts, but you can usually think of it as an unnamed magical wildcard. In the context of `{ _ + 2 }` it means an unnamed parameter. You can use it like so:
+You can partially apply a function with an underscore, which gives you another function. Scala uses the underscore to mean different things in different contexts, but you can usually think of it as an unnamed magical wildcard. In the context of <code>{ _ + 2 }</code> it means an unnamed parameter. You can use it like so:
 
 <pre>
 scala> def adder(m: Int, n: Int) = m + n
@@ -197,7 +197,7 @@ h3. Curried functions
 
 Sometimes it makes sense to let people apply some arguments to your function now and others later.
 
-Here's an example of a function that lets you build multipliers of two numbers together. At one call site, you'll decide which is the multiplier and at a later call site, you'll choose a multipicand.
+Here's an example of a function that lets you build multipliers of two numbers together. At one call site, you'll decide which is the multiplier and at a later call site, you'll choose a multiplicand.
 
 <pre>
 scala> def multiply(m: Int)(n: Int): Int = m * n
@@ -230,7 +230,7 @@ res1: (Int) => (Int) => Int = <function1>
 
 h3. Variable length arguments
 
-There is a special syntax for methods that can take parameters of a repeated type. To apply String's `capitalize` function to several strings, you might write:
+There is a special syntax for methods that can take parameters of a repeated type. To apply String's <code>capitalize</code> function to several strings, you might write:
 
 <pre>
 def capitalizeAll(args: String*) = {
@@ -262,7 +262,7 @@ scala> calc.brand
 res2: String = "HP"
 </pre>
 
-Contained are examples are defining methods with def and fields with val.  methods are just functions that can access the state of the class.
+Contained are examples are defining methods with def and fields with val.  Methods are just functions that can access the state of the class.
 
 h3. Constructor
 
@@ -404,7 +404,7 @@ class BMW extends Car with Shiny {
 
 <ul>
 <li>Favor using traits. It's handy that a class can extend several traits; a class can extend only one class.
-<li>If you need a constructor parameter, use an abstract class. Abstract class constructors can take paramaters; trait constructors can't. For example, you can't say <code>trait t(i: Int) {}</code>; the <code>i</code> parameter is illegal.
+<li>If you need a constructor parameter, use an abstract class. Abstract class constructors can take parameters; trait constructors can't. For example, you can't say <code>trait t(i: Int) {}</code>; the <code>i</code> parameter is illegal.
 </ul>
 
 You are not the first person to ask this question. See fuller answers at "stackoverflow:Scala traits vs abstract classes":http://stackoverflow.com/questions/1991042/scala-traits-vs-abstract-classes, "Difference between Abstract Class and Trait":http://stackoverflow.com/questions/2005681/difference-between-abstract-class-and-trait, and "Programming in Scala: To trait, or not to trait?":http://www.artima.com/pins1ed/traits.html#12.7

web/basics2.textile

@@ -103,7 +103,7 @@ There is Function1 through 22.  Why 22?  It's an arbitrary magic number.  I've n
 
 The syntactic sugar of apply helps unify the duality of object and functional programming.  You can pass classes around and use them as functions and functions are just instances of classes under the covers.
 
-Does this mean that everytime you define a method in your class, you're actually getting an instance of Function*?  No, methods in classes are methods.  methods defined standalone in the repl are Function* instances.
+Does this mean that every time you define a method in your class, you're actually getting an instance of Function*?  No, methods in classes are methods.  Methods defined standalone in the repl are Function* instances.
 
 Classes can also extend Function and those instances can be called with ().
 
@@ -305,7 +305,7 @@ Exceptions are available in Scala via a try-catch-finally syntax that uses patte
 try {
   remoteCalculatorService.add(1, 2)
 } catch {
-  case e: ServerIsDownException => log.error(e, "the remote calculator service is unavailble. should have kept your trustry HP.")
+  case e: ServerIsDownException => log.error(e, "the remote calculator service is unavailable. should have kept your trusty HP.")
 } finally {
   remoteCalculatorService.close()
 }
@@ -318,7 +318,7 @@ val result: Int = try {
   remoteCalculatorService.add(1, 2)
 } catch {
   case e: ServerIsDownException => {
-    log.error(e, "the remote calculator service is unavailble. should have kept your trustry HP.")
+    log.error(e, "the remote calculator service is unavailable. should have kept your trusty HP.")
     0
   }
 } finally {

web/coll2.textile

@@ -133,7 +133,7 @@ mutates a collection by executing @f@ over each element.
 def find (p: (A) => Boolean) : Option[A]
 </code>
 
-returns the first element that matches the predicate funciton
+returns the first element that matches the predicate function
 
 <code>
 def filter (p: (A) => Boolean) : Traversable[A]
@@ -324,7 +324,7 @@ Pros
 Con
 * Can't change at all
 
-Scala allows us to be pragmatic, it encourages immutability but does not penalize us for needing mutatability.  This is very similar to var vs.  val.  We always start with val and move back to var when required.
+Scala allows us to be pragmatic, it encourages immutability but does not penalize us for needing mutability.  This is very similar to var vs. val.  We always start with val and move back to var when required.
 
 We favor starting with the immutable versions of collections but switching to the mutable ones if performance dictates.  Using immutable collections means you won't accidentally change things in multiple threads.
 

web/collections.textile

@@ -173,7 +173,7 @@ val result = res1 match {
 
 h1(#combinators). Functional Combinators
 
-<code>List(1, 2, 3) map squared</code> applies the function <code>squared</code> to the elements of the the list, returning a new list, perhaps <code>List(1, 4, 9)</code>. We call operations like <code>map</code> <em>combinators</em>. (If you'd like a better defintion, you might like <a href="http://stackoverflow.com/questions/7533837/explanation-of-combinators-for-the-working-man">Explanation of combinators</a> on Stackoverflow.) Their most common use is on the standard data structures.
+<code>List(1, 2, 3) map squared</code> applies the function <code>squared</code> to the elements of the the list, returning a new list, perhaps <code>List(1, 4, 9)</code>. We call operations like <code>map</code> <em>combinators</em>. (If you'd like a better definition, you might like <a href="http://stackoverflow.com/questions/7533837/explanation-of-combinators-for-the-working-man">Explanation of combinators</a> on Stackoverflow.) Their most common use is on the standard data structures.
 
 h2(#map). map
 
@@ -381,7 +381,7 @@ scala> val extensions = Map("steve" -> 100, "bob" -> 101, "joe" -> 201)
 extensions: scala.collection.immutable.Map[String,Int] = Map((steve,100), (bob,101), (joe,201))
 </pre>
 
-now filter out every entry who's phone extension is lower than 200.
+Now filter out every entry whose phone extension is lower than 200.
 
 <pre>
 scala> extensions.filter((namePhone: (String, Int)) => namePhone._2 < 200)

web/finagle.textile

@@ -97,7 +97,7 @@ h3. Sequential composition
 
 Futures have combinators <a href="collections.html#combinators">similar to those in the collections APIs</a> (e.g., map, flatMap). A collection-combinator, you recall, lets you express things like "I have a List of integers and a <tt>square</tt> function: map that to the List of the squares of my integers." This is neat; you can put together the combinator-function with another function to effectively define a new function. A Future-combinator lets you express things like "I have a Future hypothetical-integer and a <tt>square</tt> function: map that to the Future square of my hypothetical-integer."
 
-If you're defining an asynchronous API, a request value comes in and your API gives back a response wrapped in a Future. Thus, these combinators that turn inputs and functions into Futures are darned useful: they help you define your asynchronous API in terms of other asychronous APIs.
+If you're defining an asynchronous API, a request value comes in and your API gives back a response wrapped in a Future. Thus, these combinators that turn inputs and functions into Futures are darned useful: they help you define your asynchronous API in terms of other asynchronous APIs.
 
 The most important <code>Future</code> combinator is <code>flatMap</code>[2]:
 
@@ -565,7 +565,7 @@ abstract class Filter[-ReqIn, +RepOut, +ReqOut, -RepIn]
   extends ((ReqIn, Service[ReqOut, RepIn]) => Future[RepOut])
 </pre>
 
-Its type is better viewed diagramatically:
+Its type is better viewed diagrammatically:
 
 <pre>
     ((ReqIn, Service[ReqOut, RepIn])

web/sbt.textile

@@ -440,7 +440,7 @@ info] SimpleParser should
 [info] == com.twitter.sample.SimpleParserSpec ==
 </pre>
 
-Uhoh.  We need to check for nested objects.  Let's add some ugly
+Uh oh.  We need to check for nested objects.  Let's add some ugly
 guards to our token reading loop.
 
 <pre>

web/specs.textile

@@ -24,7 +24,7 @@ This lesson covers testing with Specs, a Behavior-Driven Design (BDD) Framework
 * "run in sbt":#sbt
 
 
-h2(#example). extends Specifcation
+h2(#example). extends Specification
 
 Let's just jump in.
 

web/type-basics.textile

@@ -64,7 +64,7 @@ scala> res5.head
 res6: Any = 2
 </pre>
 
-And so our application would devolve into a series of casts ("asInstanceOf[]") and we would lack typesafety (because these are all dynamic).
+And so our application would devolve into a series of casts ("asInstanceOf[]") and we would lack type safety (because these are all dynamic).
 
 Polymorphism is achieved through specifying _type variables_.