the readme.io site already has headers for each page. removing these …

…so they don't duplicate

0_overview.md

@@ -1,5 +1,3 @@
-##Welcome to Phoenix!
-
 Phoenix is a web development framework written in Elixir which implements the server-side MVC pattern. If you've ever used a similar framework, say Ruby on Rails or Python's Django, many of the concepts will be familiar to you. Phoenix is not, however, simply a Rails clone. It aims to have the best of both worlds, high developer productivity _and_ high application performance. Phoenix also has some interesting new twists, channels for managing Websockets, pre-compiled templates and the potential for alternative architectures which may make services more manageable from the very beginning of your project.
 
 If you are already familiar with Elixir, great! If not, there are a number of places you can go to learn. You might want to read through the [Elixir guides](http://elixir-lang.org/getting_started/1.html) first. You might also want to look through any of the books, blogs or videos listed in the [Resources Guide](http://www.phoenixframework.org/docs/resources).

A_up_and_running.md

@@ -1,4 +1,3 @@
-##Hello Phoenix!
 The aim of this first guide is to get a Phoenix application up and running as quickly as possible.
 
 Before we begin, we will need to install Elixir and Erlang. The Elixir site itself has the latest and most complete [installation information](http://elixir-lang.org/getting_started/1.html). Currently, Phoenix requires Elixir version 1.0.0 or greater which in turn requires Erlang version 17.0 or greater.

B_adding_pages.md

@@ -1,5 +1,3 @@
-##New Pages
-
 Our task for this guide is to add two new pages to our Phoenix application. One will be a purely static page, and the other will take part of the path from the url as input and pass it through to a template for display. Along the way, we will gain familiarity with the basic components of a Phoenix application: the router, controllers, views and templates.
 
 

C_routing.md

@@ -1,5 +1,3 @@
-### Routing
-
 The router is the main hub of any Phoenix application. It matches HTTP requests to controller actions, wires up realtime channel handlers, and defines a series of pipeline transformations for scoping middleware to sets of routes.
 
 The router file that Phoenix generates, `web/router.ex`, will look something like this one.

D_controllers.md

@@ -1,5 +1,3 @@
-##Controller Guide
-
 Phoenix controllers act as a sort of intermediary modules. Their functions - called actions - are invoked from the router in response to HTTP requests. The actions, in turn, gather all the necessary data and perform all the necessary steps before - in a typical case - invoking the view layer to render a template.
 
 A newly generated Phoenix app will have a single controller, the `PageController`, which looks like this.

E_views.md

@@ -1,5 +1,3 @@
-##Views
-
 Phoenix views have two main jobs. First and foremost, they render templates (this includes layouts). The core function involved in rendering, `render/3`, is defined in `Phoenix.View`. Views also provide functions which take raw data and make it easier for templates to consume. If you are familiar with decorators or the facade pattern, this is similar.
 
 Phoenix defines view behavior in layers. The deepest level is `Phoenix.View`, from Phoenix itself, which doesn't appear in our generated application code. Since Phoenix is a dependency of our application, we have access to `Phoenix.View` even though we don't see it directly.

F_templates.md

@@ -1,5 +1,3 @@
-###Templates
-
 Templates are what they sound like they should be - files into which we pass data to form complete HTTP responses. For a web application these responses would typically be full HTML documents. For an API, they would most often be JSON or possibly XML. The majority of the code in template files is often markup, but there will also be sections of Elixir code for Phoenix to compile and evaluate.
 
 EEx is the default template system in Phoenix, and it is quite similar to ERB in Ruby. It is actually part of Elixir itself, and Phoenix uses EEx templates to create files like the router and the main application view while generating a new application.

H_ecto-models.md

@@ -11,8 +11,6 @@
 
 
 
-##Ecto Models
-
 Most web applications make use of some kind of datastore to hold data that the application needs to function. Phoenix does not currently ship with a model layer for interacting with a database as some server side MVC frameworks do. Fortunately, one of Elixir's core projects is [Ecto](https://github.com/elixir-lang/ecto), a dsl for interacting with databases. Currently, Ecto only supports the PostgreSQL relational database via the `postgrex` adapter, but there are plans to expand the list of supported databases in the future.
 
 Before we begin, we'll need to have PostgreSQL installed on our system. We'll need to create a database for our application as well as a user with a password which our application can log in as.