ft_transcendence

by bhagenlo

written for version 12.1

Welcome to the World of Software Enigneering.

Turns out, in real life one doesn't always recreate everything, for every project, from scratch.
For now, say goodbye to your old friends C & C++. You will be using a new programming language, libraries, and frameworks, even.

And since this much is different, you're almost back to square 1. But not completely.

Transcendence will be a very different experience from what you're used to at 42. The closest thing to this you experienced at 42 was your piscine.

You'll have to learn (at least) one new programming language and get to know the gigantic complexity looming inside the JavaScript Ecosystem. And as if this wouldn't be enough, you'll also have to find out how to tackle this in a bigger team.

Time to take stock of what you have and what you need:

You can code, and you can read others' (imperative) code. You know C-based syntaxes. You can search for specific information. You know that when you bang your head against a problem long enough, you'll be the one still standing.

This is what you needed throughout the Core. However, as I said, transcendence is different:

You need to learn (at least) one whole new programming language.
You have to work in a bigger team.
The problem space (a.k.a the number of possible problems to tackle) is way larger compared to every other project so far. Choosing which battle to pick up will be way more important than being good at slamming your head against a particular problem.
You'll (probably) be working across different parts of the codebase, in different programming languages, and with different frameworks and technologies.
Good communication will become much more important compared to how it used to be.
You have (at least) an order of magnitude more things you don't know about.
You can always, and very easily, add more features ('cause everything is so loosely specified) instead of testing your existing ones properly.

What a list.
When reading that list again, it seems like you know so little that you don't even know where to start with transcendence. It's hard to come up with a good plan when you don't know that. But you need one. How can you change this?

You can change this by first learning more.

My advice is to do a pre-transcendence piscine.

Get yourself and you team two weeks (or whatever you find suitable - I took four, and wouldn't go lower than one week.).

In this time, you might want to do the following:

For 1., it's kinda obvious, isn't it? You split yourself up, and then do a piscine in TypeScript, NestJS, SQL, HTML & CSS and your frontend framework. Easy, isn't it?
Why is 2. even a problem? Shouldn't more people 'just' mean 'more work gets done'?
To understand why this isn't necessarily the case, read Fred Brooks' essay The Mythical Man-Month or have a look here for a good summary.
(3.) is the case in just about every real-world project.
Find out how other people are doing it.
Find out what Agile, Scrum and Kanban are. Yes, you can google those on your own :)
Now that you're familiar with the terminology, jump right in and find out whether it suits you:
1. Set up a Kanban board, and fill your backlog.
2. Make a draft of how you'd structure your teamwork with this new knowledge. Do you want to do standups? What about sprints?
For tackling 4., come up with ideas on how to limit the 'damage' from communication overhead (as described in The Mythical Man-Month).
You surely already have/had some kind of idea on how to split up the project.
Would your communication benefit from splitting it up differently?
What communication can you do upfront that limits the amount of communication you need to do while implementing features? (Hint: Almost everything written here will have this as a welcome side effect already.)
For 5., read up on Design Thinking. You are in a high-uncertainty environment (already since you know very little compared to the things you 'need' to know).
This means that it makes sense to structure everything you do based on the way you learn the most - at least at first. Why? Because otherwise, you might end up with almost-done features you have to redo completely, because you avoided checking some assumption (you did not know about) first.
This can mean postponing the implementation of features that will slow down testing to the very end. It can also mean implementing/trying out the things you know the least about (those with the greatest uncertainties) first. Or it could just mean setting up everything so you have fast feedback loops as soon as possible.
To the very least: Make sure that you have a working setup (docker composed, with database, backend, and frontend from the very beginning.
Which brings me to 6..
Have a usable (especially testable) state of your project on main. Always.
Make branches small, and merge them fast (maybe even with a review?).
This makes sure idle team members can always test, test, and test - which in turn will increase your bug count, and bring you closer to making sure you implement features correctly before moving on to the next.

Does that sound like a lot? It is.

But do those points also sound like not doing them up front might become very costly in the long term?

I bet they do.

So, be a nice 42 student, do your pre-transcendence piscine, and enjoy the rest of it much more.

I wish you the most of fun :)

This guide will always assume that you 'obey the rules'. That is, that when the subject asks for NestJS in the backend, and you think you know better/want use something different, it assumes that you'll stick with NestJS.

Thankfully, 42 'allowed' us to choose much more freely here. In contrast to all of the other projects, not checking every box in the Basics part of the evaluation sheet won't let you fail immediately, but only remove a few percent from your end result (and you can pass with 90%).

I think this is on purpose, and makes it possible for us to choose differently when we see fit, which is very nice. In case you're wondering how I know this: This is what I did.

#Prerequisites

I hope that I could convince you to follow this plan. The proposed prerequisites for this project are the outcome of the things written above. The first point has to become much more granular to be usable, though:

#Learning the Programming Languages

Fittingly, there are at least five different (domain specific) languages you need to use/understand for transcendence. It's definitely useful if all of you know all of these languages a little, but in case you need to split it up, I'd go for:

SQL: 1 person
TS & NestJS: 2 people
HTML, CSS, frontend: 2 people

Yes, hopefully the SQL person will be able to switch after some time.

#TypeScript

For TypeScript, the most important thing to understand is to understand what it is. So, what is it?

TypeScript is JavaScript with way less random 'surprises'. It is JavaScript, but enhanced in a way that lets you build bigger applications more easily.

The enhancement that makes this posssible is TypeScripts Gradual Type System.

But enough of this. You don't need to become a TypeScript expert, you just have to be able to read and write little snippets.
For this, you need to understand a few features of it first:

Open up the TypeScript Playground
Anonymous Functions a.k.a lambdas
- JS/TS has two ways to create a function:
  example.js
```
function inc(a) {
        return (a + 1)
}

var inc2 = ((a) => {
        return (a + 1)
})
```
- Pick a few simple functions you can come up with, and implement them in both ways.
Higher order functions: JS/TS have so-called Higher order functions, and developers use them all the time.
- Get to know the mighty three: map, filter and reduce.
  Implement the examples in this article.
A gradual type system:
You're almost done. Now, let a few things go wrong. Call functions with the 'wrong' arguments (a string instead of a number) and see what happens.
Not so good, right?
Then, add type annotations to every function you broke. For example:
example.ts
```
function inc(a : number) : number {
        return (a + 1)
}

var inc2 = ((a : number) : number => {
        return (a + 1)
})
```
I think that those are the major hindrances to getting started with TypeScript. If you know some more: Please let me know! :)

#SQL

First, understand what SQL is and what simple queries to relational Databases look like. Then, to make sure you're able to use it proprely:

Write a migration that creates a table products with product_id (index), name(unique) and price.
Write a query that:
- ... gives you one particular product by name/by id.
- ... gives you all the products for a certain price.
- ... all the products with a name in which (pattern) occurs.
Create a users table (user_id, name) and a friends table (user_id, user_id). Then, write a query gets you the names of the friends of a particular user. For this, you might want to get to know what a (left/right/inner/outer) join is.

#HTML & CSS

HTML & CSS basics:
- Read/Scroll through MDNs HTML basics, followed by their CSS basics.
- Then, have a look at various websites, and try to understand what they're doing. The MDN docs are reasonably simple, imo. (Hint: Use the Inspector)
Understand one of the most important bits of CSS knowledge: That CSS has different rendering algorithms. For this, read on here.
Learn the one layout algorithm you're gonna use most of the time: Flexbox. (-> CSS tricks' A Guide to Flexbox)
If you're still yearning for more: Learn Tailwind.

#(your frontend framework)

This is relatively straigthforward. 'Just' create simple UI elements you think you might need. For example:

Create a simple form.
Create a friend list.
Create a chat interface. (Chat list + messages in the room + write form, or something like that.)

#NestJS

🤷. As I did not use Nest at all, I am a little reluctant to propose something specific to it here. I think it comes down to a 'Get familiar with you backend framework', and that's it. One thing I can think of:

Get into you router, and create a few different routes.

Apart from the Programming Languages part, I think I've already said enough in the beginning.

One last thing I want to mention again:

Set up you docker composed infrastructure.

#During

After this incredibly long intro, there's not so much left. There are a few things that are a little nasty (e.g. getting all the chat roles right), but you definitely have some intuition of what's right there. So, not much during 'during'.

Whenever you have idle team members, let them test ☝️

#Cleaning Up

Not much to say here, either. Well, make sure you implemented what the subject asks us to do (or deviate, and have a good reason for it).

The eval sheet is comparatively sane. There's one surprise on it, though:

It asks about a spectator mode for the game. The subject doesn't mention that, so this one is up to you :)

#Aftercare

Aftercare? For transcendence?

First, give each other a pat on your shoulders. Well done.

Since you're now going out into the grand world: How about we employ some good open source practices for the end?

Let's write some good documentation. If you don't already have one, create a README for your transcendence, and fill it with anything useful. What should such a repo have so that people can use it efficiently?

And then: Enjoy your life without the black hole, and probably working as a software engineer.

Wow. I'm amazed. You finished the Core Curriculum of 42.
The end of a long journey.

Take some time to enjoy yourself, and pat yourself on the shoulder.

I wish you the best on you further journey. I'm a little sad to see you leave, but also quite proud of what you achieved.
I hope this is not only a farewell, but also a goodbye.

And may your paths always be crossed by people you enjoy working with.

❤️, Marvin.

← CPP05-09

Found something to improve? Edit this page on Github!

Additions to the Core →