Skip to content

Week 2 - first features

During this week we will give you the first features that we expect your application to have. You should also locally configure the use of code quality validators and unit tests for maintaining the code in your project.

During phase 1 you will not deploy the code anywhere, make sure you can spin up and use the application locally.

Introduction

The application requirements will be given to you with user stories, one of the many standard ways that development requirements could be given to you in the industry.

Each user story also expands to give you the subtasks, written in a more direct form. This is done to avoid confusion during the course.

One of the goals is to start implementing these features in your application. Next week you will receive even more requirements.

Why not give all requirements at once?

Knowing everything about the application before starting development is called the waterfall model.

This is an old-school development method that finds little use today due to the increasing complexity in modern projects. Also, when working with an external client or a higher-up with no formal development experience, it will be very difficult to get the full list of requirements at the start. People change their minds, information will get lost in translation, etc.

For this reason we will imitate the agile development approach. New requirements will be drip-fed to you every week and you will need to iterate.

In addition to application requirements, you will also have some operations requirements. These are here to ease you into the Ops side of things.

Development requirements

This week's application requirements are given below as user stories.

As a user, I want to be able to create text posts on the website so that I can share my thoughts with others.
  • There should be a box on the page where the user can type their thoughts.
  • The user can hit a button, to submit their post.
  • Posts are displayed on the main page.
  • Each post shows the content the user submitted.
As a user, I might want to give some extra information when sharing my thoughts so that others may recognize me.
  • People should be able to put their name or a nickname on their post, so we know who is saying what.
  • Name/nickname uses a separate input field.
  • Leaving the name input empty should default to "anonymous".
  • The used name/nickname should be displayed on the post.
As a user, I want to be able to upvote/like and downvote/dislike posts so that I can express my opinion about the content.
  • Next to every thought, there should be a "like" button and a "dislike" button.
  • User can upvote/like any post.
  • User can downvote/dislike any post.
  • Vote counts are displayed for each post.
As a user, I want to access the entire application through a widely used web browser so that I can use the platform without needing to install additional software.
  • All application features are accessible via web browser.
  • Application must be compatible with modern web browsers (Chrome, Firefox, Safari).
As a system administrator, I want all posts and votes to persist after server restarts so that users don't lose their content and the application maintains its state reliably.
  • All posts remain available after server restart.
  • All vote counts remain accurate after server restart.

Operations requirements

This week, we recommend that you set up all the tools listed below in your project and run them locally. Just so you can get a feel for how they work.

Warning

You don't need to use the examples this manual gives. Choose tools that you are comfortable with or want to use.

Backend unit testing

Modern testing frameworks like pytest for Python or Go's built-in testing package make it easy to write and run unit tests.

Find a unit testing framework that fits your project requirements and test it out locally. Unit testing is required only on the backend code. Push the configuration and package requirements to your project.

During the first phase, we will have lenient requirements for unit testing. We ask you to only implement three different unit tests.

Code quality

Static analysis tools (aka linters) like ESLint for JavaScript, pylint for Python, or golangci-lint for Go provide feedback on the code quality before it reaches production, helping catch issues early in the development cycle.

Find linters that fit your project requirements and test them out locally. Make sure that all code is checked: frontend and backend. Push the configuration and package requirements to your project.

Failure

You might be tempted to configure your linter to be as permissive as possible, this way you will have a working linter but you don't have to deal with annoying code style errors.

Keep in mind that during the checkpoint week we will look at your linter configuration, try to follow best practices. This will also help you during later weeks.

Consistent formatting

Tools like Prettier for JavaScript, Black for Python, or gofmt for Go automatically format your code according to predefined rules, eliminating debates about coding style.

Find formatters that fit your project requirements and test them out locally. Make sure that all code is checked: frontend and backend. Push the configuration and package requirements to your project.

Tools that format, lint, or do both?

Some tools focus solely on formatting (like Prettier or Black), others only on linting/code quality (like golangci-lint or pylint), while some tools can do both.

For example, Ruff for Python combines the functionality of multiple tools including formatting and linting.

You can use a tool that does both, just make sure that formatting and linting are two distinct steps in your workflow.

Documentation requirements

Every project needs documentation so that developers, system administrators, and others can quickly access basic information about the application. For this course, we (the teaching staff) need documentation to quickly understand your project structure and assess your progress. Better documentation leads to a smoother grading experience.

What we expect your documentation to have?

High-level structure of the project

  • Are the frontend and backend separate?
  • What tech stack is in use?
    • Include version info for important frameworks and packages.

More detailed info about the application

  • API endpoints
    • What endpoints does your backend application serve?
  • Function signatures
    • Bring out some important functions and their signatures.
    • Using a standard code documentation tools for your functions is recommended
      • Python Docstrings, Godoc, etc.
    • You could include a command in your repository README that spins up a documentation web server

Development workflow

  • Can you run a hot-reloadable development server? How to do it?
  • What are the commands to build and run your application?
    • How to access the application after running it?
  • How to run your tests, linters, formatters?
  • If I were to clone this repo, then how would I get to a working application in my browser?
    • Describe the exact steps.

Use of AI

  • The use of AI is allowed, but it needs to be documented.
    • What parts are written by AI? Where has AI assisted you?
    • Make sure to comment the code as well

This is the list of questions your documentation should roughly answer, but you should be ready to answer questions during the checkpoint that you might not have documented.

Keep in mind that each week we will provide additional documentation requirements, so your documentation will evolve with every iteration. Make sure to keep it up to date.

Tasks

  • Go through the user stories and implement all features.
  • Add locally runnable unit tests to your backend code.
    • Implement three different tests.
  • Configure and locally run a linter.
    • For backend and frontend.
  • Configure and locally run a formatter.
    • For backend and frontend.
  • Go through the documentation requirements and document your project.