Objectives

I set out to build a blog that enabled intuitive navigation and discovery of the blog's content using a clean and minimalistic interface. Features such as a category sidebar with the number of posts included within each category should enable the user to find other posts that might be of interest.

The blog should include a detailed amount of metadata which informs the reader on how useful the blog's article is. One of my personal dislikes is when I'm reading a blog post and there's no creation or updated date on the post. This leaves me wondering if the solution provided really is aligned to the challenge I'm facing.

The Approach & Solution

Firstly, I drafted a database schema with a rough sketch on my notepad. Following this, I created the 'Category' and 'Post' models within the 'blog' app.

I decided to structure the relationships between categories and posts as a many-to-many relationship. It would have been easier to develop a solution using a one-to-many relationship however, it seemed reasonable to me that a post could fall into many different categories.

Following this, in a separate app called 'users', I created a 'Profile' model which has a one-to-one relationship with Django's default 'User' model. These are connected using Django signals whereby when an instance of 'User' is created, it sends a signal to the custom 'Profile' model to simultaneously create an instance of the 'Profile' model too.

Following the implementation of the models, I designed the URL structure of the application. Working in this way helped me to decide upon the various views that needed to be created. I have learned that it's best to work in order of most generic to most specific in terms of creating the URLs/views.

The final stage was to render the templates which is of course was an iterative process requiring revisions to the models and views as better or more desirable options become apparent.

Evaluation

If I were to repeat the project, I would create a custom user model which would use an email address for registration rather than a username. I think that using usernames is an outdated way of signing up for a website. It's more difficult for a user to remember their username. This fits my personal preferred method of signing up to web services. Additionally, due to privacy concerns, I don't believe in using Google or Facebook's expedited login buttons. They're very convenient at the point of registration but expensive in terms of the data that you're giving away.

Changing over to a custom user model at this point would require an inordinate amount of effort to derive very little benefit. I have used this pattern in a subsequent project.

As with any ever-evolving project, there are certainly still things that I would like to change.