There are a lot of different editors and it largely boils down to personal preference. Most Python programmers use complex but extremely powerful IDEs (Integrated Development Environments), such as PyCharm. As a beginner, however - that's probably less suitable; our recommendations are equally powerful, but a lot simpler.

In your `static/css/blog.css` file you should add following code:

`h1 a` is a CSS Selector. Any `a` element inside of an `h1` element (i.e. when we have in code something like: `<h1><a href="">link</a></h1>`) is the tag we're applying our styles to, and we're telling it to change its color to `#FCA205`, which is orange. Of course, you can put your own color here!

Wohoo! Looks awesome, right? The code we just pasted is not really so hard to understand and you should be able to understand most of it just by reading it.

As you can see, there is an error. Heroku created a new database for us but it's empty. We also need to sync it:

You see, when you're building a website, you always need a similiar set of components: a way to handle user authentication (signing up, signing in, signing out), management panel for your website, forms, uploading files, etc.

Luckily for you other people long ago noticed that web developers face similar problems when building a new site, so they teamed up and created frameworks (Django is one of them) that give you ready components you can use.

To understand what Django actually is for, we need a closer look at the servers. The first thing is that the server needs to know that you want it to serve you a webpage.

When a request comes to a web server it's passed to Django which tries to figure out what actually is requested. It takes a webpage address first and tries to figure out what to do. This part is done by Django's __urlresolver__ (Note that a website address is called a URL - Uniform Resource Locator, so the name *urlresolver* makes sense). It is not very smart - it takes a list of patterns and tries to match the URL. Django checks patterns from top to the bottom and if something is matched then Django passes the request to the associated function (which is called *view*).

Imagine a postman with a letter. She is walking down the street and checks each house number with the one on the letter. If it matches, they put the letter there. This is how the urlresolver works!

In the *view* function all interesting things are done: we can look at a database to look for some information. Maybe the user asked to change something in the data? Like a letter saying "Please change description of my job." - the *view* can check if you are allowed to do that, then update the job description for you and send back a message: "Done!". Then the *view* generates a response and Django can send it to the user's web browser.

`PostForm`, as you probably suspect is the name of our form. We need to tell Django, that this form is a `ModelForm` (so Django will do some magic for us) - `forms.ModelForm` is responsible for that.

When we submit the form, we are back in the same view, but this time we have some more data in `request`, more specifically in `request.POST`. Remember that in HTML file our `<form>` definition had variable `method="POST"`? All the fields from the form are now in `request.POST`. You should not rename `POST` to anything else (the only other valid value for `method` is `GET`, but we have no time to explain what the difference is).

So in our *view* we have two separate situations to handle. First one: when we access the page for the first time and we want a blank form. Second one: when we go back to the *view* with all form's data we just typed. So we need to add a condition (we will use `if` for that).

Now, we will show you how cool Django forms are. Blog post needs to have `title` and `text` fields. In our `Post` model we did not say (as opposed to `published_date`) that these fields are not required, so Django, by default, expects them to be set.

Now we know how to add a new form. But what if we want to edit an existing one? It is very similar to what we just did. Let's create some important things quickly (if you don't understand something - you should ask your coach or look at the previous chapters, since we covered all the steps already).

This looks almost exactly the same as our `post_new` view, right? But not entirely. First thing: we pass an extra `pk` parameter from urls. Next - we get the `Post` model we want to edit with `get_object_or_404(Post, pk=pk)` and then, when we create a form we pass this post as an `instance` both when we save the form:

Congratulations! Your application is more and more complete!

The command above will create a directory called `myvenv` (or whichever name you chose) that contains our virtual environment (basically bunch of directory and files). All we want to do now is starting it by running:

So what is an object? It is a number of properties and actions. It sounds weird, but we will give you an example.

If we want to model a cat we will create an object `Cat` that has some properties, i.e. `color`, `age`, `mood` (i.e. good, bad, sleepy ;)), `owner` (that is a `Person` object or maybe, in case of a strayed cat, this property is empty).

You can think of a model in the database as of a spreadsheet with columns (fields) and rows (data).

- `Post` is the name of our model, we can give it a different name (but we must avoid special characters and whitespaces). Always start a name with an uppercase letter.

What about `def publish(self):`? It is exactly our `publish` method we were talking about before. `def` means that this is a function/method. `publish` is a name of the method. You can change it, if you want. The rule is that we use lowercase and underscores instead of whitespaces (i.e. if you want to have a method that calculates average price you could call it `calculate_average_price`).