Smlep

Building a three-player chess website

2020-12-26T00:00:00+00:00

Context

Around the end of 2019, as we were going through our few last months of engineering school, we ended up having a quite consequent amount of free time due to the highly irregular organisation of courses throughout the year.

Daniel, a friend of mine from school who has been a huge fan of chess for a while now told us one night about how he read about this chess variant with three players and how he thought it would be interesting to build a game engine for it.

Since I had time to ~~waste~~ spend building something ~~funny~~ meaningful, I was interested in getting involved in this project to make it grow and be something more than only a game engine (which I thought nobody would use anyway, since playing chess through command line on a single computer does not seem that appealing).

That’s how, Daniel, Vincent (another friend from school with whom I had worked on many side projects), and I decided that we were going to build a website so that people could come and play chess with two of their friends.

What is three-player chess?

Some might wonder what really is 3-player chess, do the rules change when introducing a third player, and if they do, how?

Even though 3-player chess seems like a simple and precise concept, there are many variations with light differences and not one set of rules for 3-player chess. These different variations come in variants with different names (Trichess, Chess for three, Three-Player Chess, Yalta chess…) but not every mention of one variant describes the same rules and there is a huge lack of norm here.

The variation of chess played on yalta-chess.com can be considered as a unique variant, but mostly inspired by Yalta Chess (not much suspense here) from which we tried to follow the rules as much as possible, but once again, the rules differed depending on the articles.

On our website, you’ll play on a 96-cell board (32 for each player, just like usual chess).

The moves are the same as classic chess, but it can take some time to get used to the moves around the center or the board when starting to play Yalta Chess. The only real difference with 2-player chess is how winners and losers are handled.

The winner is the first player to checkmate another player, meaning that there are one winner and two losers. This makes the game more interesting, rewarding aggressive strategies since playing too defensive might end up in a loss where one of the other players checkmated the third player.

Early development

Our initial goal was pretty simple and seemed easy to accomplish, the tasks which needed to be done could have been summed up as:

Building a game engine, implementing every rule and move.
Having a game page on which 3 players could play together with a decent user experience.
Having a basic matchmaking system, so that players could join games easily.

It looked easy and fast, the game engine was the main challenge since the special shape of the board made the classic 2-player chess implementation unsuitable for our needs and we needed to come up with a smart way to handle the board. Once the game engine was out of the way, the only remaining thing would be to build a simple website with basic functionalities.

Two of us already had some web development knowledge which we acquired through previous side-projects, I would not say that we were amazing (or good) web developers, but we were at least decent. Well, for the backend at least, our UI/UX level was (and still is, but those who saw the website already know that) pretty bad.

Since we weren’t looking for high performances in our game engine because a few milliseconds were not going to impact the user experience, building the engine was actually pretty fast. One of us focused on it, and after a few days we had a game engine implementing the rules and about everything we needed except promotions, castling, and en passant which came later.

Our implementation relied on the fact that instead of using one 8x8 board as in 2-player chess, we considered the board as 3 distinct 4x8 sub-boards, each sub-board filled with a different color on the example below:

The website, on the other hand, was way more complicated than we anticipated, handling concurrent plays with real-time information transfer between the players (without refreshing after each move) and implementing a decent user experience was much more challenging than we expected.

Our first playable version looked like this:

With the three boards representing the three sides of the board as explained above.

This first version allowed us to check that our engine worked as intended, but required us to refresh a page to see the other players’ moves and wasn’t very user friendly.

That’s when we really became aware that the website part of the project would require an amount of work strongly higher than the game engine implementation.

A basic project

The more we implemented new features on our website, the more features we thought about which seemed to be required to have a decent user experience on the website. Some of these features were not necessary but seemed like good ideas/interesting to implement so we implemented some of them and the others were listed and put aside for later.

After a few weeks, we had a decent result for the play part of the website; three players could play on the same page, moving by selecting a piece and moving it to its location and seeing the actions’ results in real-time.

Our first matchmaking system was fairly basic, there was a list of created games, and any player could join any game, if the user was the third player to join a game, it would start, and if there were 3 players already in the game, the user would be considered as a spectator. On top of that, any user could create a new game.

At this time we had already spent way more time on this project than we thought we were going to, even though we had only implemented the features we thought were necessary to have a good time playing the game. The website’s current state was enough to send the link to some friends and play games with them if we wanted to, the global design of the website wasn’t nice, but playing stayed pretty intuitive.

Not so basic anymore

When we started this project, we did not define the real scope of users who would use it, the more we worked on it and the more features we started implementing, the more we started to want to make it public so that everyone could come and play.

As we started having less free time due to school projects and then the real jobs we got after graduating, we spent way less time developing this project the following months but we kept working on it and added a lot of new sfeature. Some of those being necessary for a public release, some that we felt were a really nice addition for users and some which might just be really useless (Hello, in-game chat). Among these extra-features are:

A custom game system to play with friends with custom settings
A public queue system to play with random unknown players
A training mode to play against bots in different difficulties
A profile system with ranks, elo, skins, themes, and statistics
Game timers
A board rotation system, to see the board as one of your opponents
An in-game chat
The possibility to show replays of games
A documentation section to explain the website and the game rules
A landing page to explain to new users what happens here
A new implementation of the game engine with improved performances and a graph system (replacing the 3x4x8 sub-boards implementation)

And of course, a landing page to welcome new players to our website. The old matchmaking system based on a game list was removed, since the public queue and private game system fully replaced the need for it.

Costs and revenues

As we added new features and new services which started to increase potential costs, we had to consider the business aspect of the website. We were not fully against trying to monetize it but we did not want this to impact the user experience, driving potential users away because of aggressive advertising or pay-to-win systems.

We considered ads, but generic ads (such as adsense) would require to have a huge amount of traffic to really generate money and they usually don’t fit well into a website. We did not want our website to get significantly less enjoyable for users just to win a few euros every month (or year).

We considered some other solutions than ads but in the end, we did not find an adequate business model. Not being able to generate revenue is not currently an issue, since the goal never was to quit our jobs and start working on this project every day of the week. Nevertheless, we did not anticipate when we started this project (before we decided to add many unexpected features) that there were gonna be real costs to run the website.

Indeed, the website now runs using many different services and tools which come with a cost, meaning that we cannot sustain with this business model (which is not one, since we generate no revenue) if our user count grows too much.

As long as our monthly costs stay under a few dozen of euros, it is fine, I’d say that we are happy to pay for it if some people are happy to play on yalta-chess.com. But if this website became too popular, we would have to scale up the different services we pay for (hosting, Redis, database…), resulting in hundreds of euros bills.

Hence, if too many people end up enjoying our website, at some point we will have to shut it down (or strongly restrict traffic) if we still cannot generate revenue.

This is really unlikely to happen since we don’t plan on doing real advertising for this project, and we are not so presumptuous as to think that this website is good enough to deserve this much success. But we still have to consider this scenario, and if it happens we will still try to consider ways to generate revenue, we are not fully closed to ads, but we feel like right now nothing fits our needs, maybe we’ll set up a donation system but those rarely work.

What’s next

We probably spent too much time on this website, way too much, but most features were implemented because we enjoyed it and not really because we felt like all of them were required.

We still have dozens of ideas about improvements that could be implemented for this project which could make me work on this project for a few extra months or years. But I thought it was time to wrap it up and prepare everything needed for a public release, putting all remaining ideas into an issue list with implementation ideas if a V2 came to be implemented one day.

This will make this project feel like a complete product (even though I know it’s not), allowing me to move on to other side-projects.

Come try the website at yalta-chess.com, if you don’t find any players in the public queue and you don’t have any friends to play private games with, head to the training section (Create a custom game => Training) and try playing against our bots with various difficulties.

A special thanks to Daniel and Vincent for working with me on some parts of the project and for their continuous reviews of the website’s progression.

If you want to get in touch about this project, feel free to contact me at smlep@yalta-chess.com.

Internship: Resume and Career

2019-10-05T00:00:00+00:00

Context

To complete my Master in Data Science I’m doing at EPITA, I’m now looking for an internship in Machine Learning / Data science.

Education

EPITA

EPITA is a five year engineering school specialized in computer science, for the fourth and fifth year, I am now studying Data Science and Computer Vision.

At school I worked on a lot of small projects in Python, C#, Java, C, C++ and Scala which brought me a good knowledge on many programming languages, and nice overall algorithms skills.

I started studying there in September 2015, and will be graduated in September 2020, after completing my end-of-studies internship.

Griffith College Dublin

In 2017, for the second semester of my second year at EPITA, I had the opportunity to spend one semester abroad and I chose to go to Dublin from January 2017 to June of the same year.

There, I studied Computer Science, including algorithms, java, and android mobile development. It was a good opportunity to study in an English environment and to learn a new culture.

Experience

Teaching Assistant for third year students

Starting in January 2019, I became a teaching assistant for the third year students at EPITA.

As an assistant, my job was working with a team of 53 assistants managing a promotion of 600 third year students:

Redaction of programming subjects.
Creation of tutorials, bringing knowledge to students on multiple languages (C++/C/Java/SQL/UNIX).
Helping the students to fulfill the tutorials and subjects.

Inside this big team, some of us had roles, which meant having bigger responsibilities and a bigger amount of work. My role was to be the quality manager inside the team:

Inspection of the coherence, the feasibility and the form of the subjects created by the team.
Handling of review and help sessions for the other assistants when they have to do a presentation to the students.
Accountable for the quality of everything produced by the assistants for the students.

This job was divided in two different parts, the first one, went from January to July and consisted in teaching C++, Java and SQL inside a smaller team (only 32 assistants) with a smaller amount of students (about 400), and the second one started in August 2019 and is expected to last until January 2020, where the taught languages were C and Shell, the team was bigger (53 assistants) and the amount of students too (more than 600).

I did this job in parallel to my studies, and it brought me a lot of knowledge about the languages I taught and how to work with a team in a complex infrastructure with interesting subjects to work on.

Back-End developer at Brainsonic

From September 2018 to January 2019, I did an internship in a marketing agency in Paris called Brainsonic.

Brainsonic is an agency specialized in content creation and social media with many teams working on different kind of projects, such as Brand Content, Social Media handling, Events, and the web department.

There, I was an intern with two main goals: to help with the development of many web projects for different clients such as Microsoft, NestléWaters, SNCF or Elior. The second one was to do some research on an emerging technologies called Progressive Web Apps.

During this internship I worked on many web technologies, the ones I used most were PHP, HTML, CSS, JavaScript, Service Workers, Heroku, Symfony and Webpack.

Teaching Assistant for first year students

From September 2017 to June 2018, I was a teaching assistant in Caml and C# for the first year students at EPITA:

Supervising programming practice sessions
Correction of the students submissions
Creation of subjects for practice sessions and exams

Writing a simple program to gather news from various APIs

2019-02-01T00:00:00+00:00

Context

During January, I had a lot of spare time compared to what I usually have: I had just finished my fourth year internship and was waiting to really resume the lectures I had at school.

So I decided to work on another small project because I really enjoyed working on my last open-source project (you can take a look at what I wrote on SpacingChecker a few months ago).

Finding what to work on

The first main step of working on this project was to find what kind of project I wanted it to be. All I knew is that I wanted to work on something different from SpacingChecker, that meant no complex regular expression checking in shell, and more precisely no shell at all.

I didn’t really have more constraints or things I did not want to do, that left me with plenty of choice about what to create, so I started to think about what I thought I needed.

A few months before that, I started to get interested about startups and new tech products, so I tried to make a habit of staying up-to-date with tech news and innovations.

To do so, I spent a few minutes a day on Product Hunt and GitHub and I found some really interesting products and open-source softwares, some that I still use today (like f.lux for example). In the beginning, I really enjoyed that, but after some time, some day it really started to feel like a chore and it became harder to stay up-to-date.

So I decided to create a tool which would make this easier for me, and that’s how I started my own news aggregator.

Preparation steps

Where should my news come from?

First, I did a small list of what I wanted to have in my aggregator, and I knew I would add more features later if I had enough time/motivation:

Product Hunt: A must have for me, a good place to find new softwares and websites.
GitHub: The GitHub’s explore section is really nice to stay updated with the last popular open-source projects.
A way to have global world news, not only tech news because geek life can only get you so far :wink:.

What technologies should I use?

So, in the end, what I had to do was make calls to some APIs, maybe do some scraping, and then find a way to bring this information to me simply (command line tool, website, or e-mails were the first solutions I thought about).

Python seemed like an obvious choice to me, since I knew well this language, it was going to be easy to make calls to an API, to scrap websites, to send e-mails or even to display the information I gathered on a website (I had a good Django background).

Moreover, I enjoyed writing code in Python for some popular reasons such as the ability to write code fast, the light syntax and the huge amount of already existing packages.

Starting to gather

Once (almost) everything was decided, I was able to start gathering data.

Product Hunt

Product Hunt was the first website where I tried to gather data, my goal was to get the links and information for the most popular products each day so that I could easily see if I found any of them interesting, and if I did, access to more details by following the link to the owner’s website.

Product Hunt gives the users access to an API which can be used to make simple read-only requests as long as you have an access_token. This token can be obtained by creating an account and going to the API dashboard.

Then, anyone can access the top posts of each day to gather the names, the taglines, the number of votes and the product’s urls.

GitHub

The second website where I liked to find news was GitHub, I really like open-source and learning new technologies, so I felt like going through the most popular repositories daily would be a good way to stay up-to-date.

GitHub also provides an API which does not require authentication to execute read-only requests with a limit of 60 requests per hour. Of course, by being authenticated, you can execute more complex requests and with more requests per hour, but for what I had to do, there was no need to be authenticated.

What I did was requesting the most popular repositories from the last 24 hours and extract basic information about them: the names, the descriptions, the authors and the number of stars.

Global News: The Guardian and Le Figaro

For the news, I first started to use The Guardian, since it has a nice API which can be used by getting an API key by registering there. The API is easy to use and has all the information I needed on the articles.

But the thing with news is that it can only be truly relevant if it’s localized, and since I live in France, I needed to get news from a local newspaper.

So I chose to get news from Le Figaro, which is a French daily morning newspaper. Sadly, Le Figaro does not provide any API, but it has its own rss feed here, and parsing rss feed is really easy with Python using feedparser.

Weather

While I was implementing the API gatherers, I had another idea for improvement. One thing I do every day is checking the weather in the morning, so I chose to add a weather gatherer.

The weather website I decided to use was the popular OpenWeatherMap which is well-known for providing an easy-to-use and free weather API for over 200 000 cities.

This allowed me to get the weather for the next 24 hours with a 3-hour interval which was accurate enough for me.

Displaying the data

Once I had gathered everything I wanted, I had to decide how the results would be brought to me and when.

The when was an easy question, indeed, I designed most of the API calls to get information for today, so I decided that I wanted to get the results daily.

But how was a trickier question…

Command Line Tool

The easiest thing I could do was to simply do command line calls to my Python program and display the formatted output on my computer’s shell every time I wanted to have this information.

This is pretty easy, I simply had to write a few functions to format the data I gathered from the different APIs and have an entry Python file, which once executed would make all the calls, format the output and display them to me.

With a few tricks, I could have made this as a simple shell command I could call from anywhere (like showNews).

The issue with this solution would be that I would have had to open my laptop and start the program each time, this is something I do pretty often, but the goal was to get the news every morning easily, and opening my laptop is not the first thing I do every morning.

Website

The second solution I explored was to display the gathered data in a website, so that I could read the news every morning on my phone, laptop or pretty much anything with internet.

Deploying small websites is something I have done a lot, so I already had the technologies figured out, Django in the back-end, classic HTML and CSS in front-end with Boostrap to have something fast and not too ugly.

To deploy my website online, I would use Heroku which I really enjoyed since it allows me to deploy free websites and I find the git deployment really easy and smooth.

There were two issues (that I found) with the website solution.

First, it was a lot more work than what I was going for in the beginning, because creating and deploying a simple website is still a consequent amount of work if I want to do it well.

The second issue is that this program’s goal was to be as light and small as possible but turning this repository into a Django website was going to make it way heavier than I wanted. Of course, I could keep this repository to only perform the API calls, and design the Django website in another repository, but another goal I had was to have everything in the same repository, so that was not going to work.

Emails

The solution I chose to use was emails. This was pretty easy, I wrote a few functions which formatted the gathered data to be easy to read in an email, then I created a gmail account for this purpose, and using smtplib I was able to send an email to a target I chose.

But what I wanted to do wasn’t to open my laptop every morning, run a Python program and then go to my email reader to read the email I just sent myself, this would just be a waste of time and would be like the command line interface solution but more complicated.

What I needed was for these emails to be sent programmatically every morning, no matter if I had access to my laptop at that time.

Another thing I wanted was to be able to send the email to multiple targets, and to be able to update the target list easily without having to alter my code.

So, I took a free AWS EC2 which I could easily access through ssh. There, I cloned my repository, added my credentials and added a local PostgreSQL database on which I stored all the target emails.

So, every time I’d call sender.py, the calls to the APIs would be made, the results formatted and then an email would be sent to each target on the target list.

And last, to be sure my server would trigger the Python package every morning, I added a cron job for each morning at 8 a.m., here’s the content of my crontab (opened with crontab -e):

0 8 * * * ~/cron/news.sh 2>~/log/error.log

news.sh is a simple bash program used to call my sender.py file, I used it to make some tests and I’m pretty sure it isn’t required anymore, so I might refactor this in the future.

Languages

To speak briefly about the languages, since I was getting French articles from Le Figaro, I was not able anymore to do a full English software. So I decided to have two versions of the sent emails: English and French, the English one using The Guardian and the French one using Le Figaro.

Right now, the emails I send myself are in French, but the way I designed this, it could be swapped by changing two characters in the code. In the future, I might add the desired language in the database next to the target emails to make this more flexible.

Results

Now, each morning I get an email looking like this:

And this is how the English version would look:

The email design is pretty poor in my opinion, but it brings me the information I need each morning so I don’t think I will try to spend hours to try to have pretty emails since the email part is not the main purpose of this project.

To conclude, I really enjoyed working on this project and writing this post, so I will try to find another small project of this kind to work on soon and I might be back with another post of this kind.

Thanks for reading this!

The source code for this project can be found here, you can leave a star if you find it useful :blush:.

Edit: I have implemented a website to subscribe to these daily news with custom configurations, go check it out it’s free: https://www.mycustomnews.com/.

SpacingChecker: A huge tool to do one simple thing

2018-10-31T00:00:00+00:00

Context

I have written some posts about SpacingChecker in the past to talk about how the project was changing and what I was adding, but now that I think I am done with it, it’s time for a concluding post to talk about what really was that project and why it existed.

A few months ago, I started to have to this work in parallel with my studies, where, among other things, we write tutorials for students to help them learn how to code. We are a small team working on it, and one thing I have to do that others don’t is reviewing what the people I work with write.

So, when someone wants to add a new paragraph in a tutorial, he has to create a Merge Request on our GitLab and I (or the other guy who is also in charge of reviewing) have to review and merge if everything is fine.

Of course, everyone did spelling mistakes since we were all only getting started with this job, but there was one kind of mistake that most people did really often: adding, or not, spaces around punctuation. Should we put a space before a :? Is there a space after a ;? What about ! and ?, is this the same rule?

In the end, the answers to these questions were pretty simple, but the issue is that it is language dependent, and more precisely, these rules were really different between English and French.

But we were French students, writing English tutorials, so there was a great deal of confusion about what rule to use, and that meant many mistakes.

I knew that eventually, these rules would stick and that nobody would make these mistakes anymore, but it was going to take some time and I was getting tired of leaving 20 comments on each Merge Request so I decided to create a tool to be able to check if someone made this kind of mistake.

The few hours long project…

At this point, I wanted to create in a few hours a light program to display the spacing mistakes in a text, so I chose which technologies I would use accordingly.

I could have gone for Python to have a program which would parse a file and try to find how spaces were set around punctuation, or maybe the same thing in C or C++ which would be harder to create but would have way better performance. But I didn’t care about the performance, It didn’t matter to me if checking a text file would take 0.002 second or only 0.1 second so I did not go for C or C++.

When I started to think about it, the easiest way to detect these errors would be to parse my file with regular expressions (which I’ll call regexs), so I decided to go for the simplest way I knew to match regular expressions in file: grep.

grep is a command line tool which finds lines matching a pattern in files, all I had to do was to create regexs which matched the spacing errors, feed them to grep with the files I wanted to check, and that was it: a few hours work!

So I started to implement this simple shell program, I decided to first write the rules for French, knowing that I would do the same for English shortly after.

To have a flexible program, I chose to store the languages configurations in different files, which I called language files and gave the .lg extension.

My program was then divided into two files: the language file for French (french.lg) which looked like this back then:

 ,
 \.
[^ ]?
[^ ]!
[^ ];
[^ ]:

And the checker (check.sh) which consisted in a loop going through my language files to then call grep on the target file with each regex contained in the language file.

A few minutes and commits later I had the English language file ready, the French language file had been improved so I had reached what I wanted to have in the beginning: a simple program to detect some spacing errors in a text file in English or French.

My repository at this point can be found here.

But, by the time I had reached this point, I had many new ideas for this program. Most of them were pretty simple or useless, but I wanted to improve my SpacingChecker, so I continued to work on this.

Turning this program into a complete and useful checker

The first thing I wanted was to have options, so that this program could be used in many situations, at this point I already had a simple --help option but I decided to add a few more and to change how I implemented --help.

Help

Since I was beginning to have a big README file which described how my program worked, I realized that the best solution for me would be to simply display the content of my README when someone would trigger the --help option. It seemed like a good solution back then, but now the README has gotten pretty huge, so I might need to rewrite a real help function in the future.

Silent

The silent option, triggered with -s or --silent would hide everything which should be printed on the standard output, so that the only way to know if the program found any errors would be to look at the exit code.

I implemented that the simplest way I knew how (there might be a better solution) is by redirecting the standard output in /dev/null.

The resulting code looks like this:

if [ $SILENT -ne 0 ]; then
  exec 1>/dev/null
fi

Languages

At this point, I had changed the structure of the language files, it was not only a list of regex anymore, but there also was a name for each file and a short name, so each lg file started like this:

# Name: French
# Short: fr

And if we wanted to check a file named test.txt in French, we could call

$ ./check.sh fr test.txt

This made the syntax lighter than when we had to give the language file path.

To display the list of the short names for the available languages, the -loption was created.

-l, --lg or --languages display every available languages and their short names:

$ ./check.sh -l

Short names for available languages:
fr: French
gb: English (GB)
de: German
it: Italian
us: English (US)

Once I had the language file structure figured out, I added more language files (right now, there are french, gb_english, german, italian and us_english), and kept improving the regular expressions for each languages.

So, I added support for ellipses (...), time (hh:mm) and decimal numbers (is it 3.14 or 3,14 in this language?). These new rules are the reason why I had to split GB English and US English.

Deploying the checker

After adding a few options and three more languages my checker was now way bigger than what I expected to create in the beginning. My check.sh which contained the shell script I used to perform the checking just went from 13 lines to more than 150.

To feel like what I created would not be a 100% useless, I tried to make it easy to use for anyone, because at this point, it might seem easy to use, but it was annoying to install.

To run the checker, you had to clone the repository and then call the checker from within the repository. To make it easy to install I decided to add it to a real package manager.

The only package manager I was really using being Homebrew, I wanted to do at least this one, and if it was not too hard, then I would make it able to be installed with apt-get and Pacman.

I won’t explain all the different steps I went through to add SpacingChecker to Homebrew, but it took me an amount of time and mistakes way too high. This was the first program I tried to add to Homebrew (and probably the last one :sweat_smile:) and it took me quite some time to make this work.

But in the end, I reached something and now it can be installed this way:

$ brew tap Smlep/SpacingChecker
$ brew install spacingChecker

Then, to use this from anywhere, just call the spaceCheck command and everything works.

$ spaceCheck us tests/theTortoiseAndTheHare.txt

Looking for a language file...
Searching files corresponding to us
Loading English (US)

Checking tests/theTortoiseAndTheHare.txt:

No error found in tests/theTortoiseAndTheHare.txt

Adding SpacingChecker to Homebrew really made me lose my motivation, so I decided not to add it to apt-get or Pacman for now, but I might do it in the future.

Conclusion

This project took me a few dozen of hours in the end instead of only being a 2 or 3 hour project like I expected in the beginning.

On the one hand, it may seem like a waste of my time since I spent all these hours creating an almost-useless checker that will probably never be used by anyone but me.

But on the other hand, I learned how to build a complete tool from the beginning to the “end” about a simple functionality and I feel like I learned a lot about how to deploy something I created on Homebrew. Moreover, I feel like a regex beast now, so that’s good (but I’ll probably have forgotten everything in a few months).

So, maybe it was a waste of time, but I’m proud I worked on this anyway, and honestly, I had time to waste the weeks I worked on this.

Since I really enjoyed working on that, I might come back with another open-source project in a few weeks or months, as soon as I find an idea which seems worthy of my time (but honestly, pretty much anything productive is I guess).

The source code for this project can be found here, you can leave a star if you find it useful :blush:.

Smlep

Building a three-player chess website

Context

What is three-player chess?

Early development

A basic project

Not so basic anymore

Costs and revenues

What’s next

Internship: Resume and Career

Context

Education

EPITA

Griffith College Dublin

Experience

Teaching Assistant for third year students

Back-End developer at Brainsonic

Teaching Assistant for first year students

Links

Writing a simple program to gather news from various APIs

Context

Finding what to work on

Preparation steps

Where should my news come from?

What technologies should I use?

Starting to gather

Product Hunt

GitHub

Global News: The Guardian and Le Figaro

Weather

Displaying the data

Command Line Tool

Website

Emails

Languages

Results

SpacingChecker: A huge tool to do one simple thing

Context

The few hours long project…

Turning this program into a complete and useful checker

Help

Silent

Languages

Deploying the checker

Conclusion