DEV Community: Bradley Hill

Confidently Incorrect - Recipe Collection App : So far...

Bradley Hill — Mon, 03 Jun 2024 20:10:50 +0000

Confidently Incorrect since 1987

The set-up

So I have been continuing to code whilst looking for my first Apprenticeship (Alternance, here in France) job as a software dev, as I have said previously I have been continuing following The Odin Project curriculum, but have recently had my focus switched onto a personal side-project that I had been toying with whilst I was studying at Ada Tech School, a website where people could curate their own collection of recipes from a variety of different, well known, recipe/cooking websites.

The initial inspiration was seeded when I stumbled across a web-scraping library made in Python for the express purpose of scraping from these popular recipe resources, recipe-scrapers.

My initial, now long abandoned, plan was to use Next/Nuxt to create the front-end and have the back-end be in Python, to allow me to use the recipe-scrapers library, and to use Supabase to organise the database of users and their collection of recipes, and allow the users to enter a list of ingredients and be presented with a selection of recipes from their own curated collection that contained those recipes, allowing people to get some inspiration on what to cook based on the ingredients available to them at the time. Using the recipe-scrapers library, I would have allowed them to enter a URL to add a recipe into their collection, as well as a page displaying all the recipes currently stored in the collection and allow them to delete any they no longer wished to be included. Nothing too crazy, a pretty sweet simple idea, which I would make sure was responsive enough to look good when viewing on a phone.

A week or two of work, and it'll be done....

The ==real== beginning

So with all the confidence of someone about to discovery how incorrect he was, I went about setting up a Nuxt project in my frontend directory, and very quickly got lost in the bells and whistles and functionalities included, all of them very useful and baked in, but quickly realising that, in reality, all I really wanted was to practice using Vue, so with a quick back track and a quick Vite install of Vue3, I was back to square one, albeit with a tiny sliver more of understanding of where and when to use Nuxt, namely, in a bigger and more complex project and in the future when I had a touch more experience.

The next step then was to get my backend directory set-up, that should be a bit simpler, I've used python a little bit before, no need to dive into Django, I knew that Flask was a relatively lightweight framework that I could use for my backend, and I was pretty certain it would have the essentials that I needed for my project...and at least so far I was correct.

But boy did I not anticipate virtual environments and dependency issues....

Virtually environmentally dependent

My previous experience with Python had been pretty shallow, just writing little scripts and following a few tutorials, making simple console based games and such. Setting up a virtual environment wasn't necessarily difficult, although not the simplest thing I have done since starting to learn coding, it is obviously very useful. Creating a customisable environment, where I define the version of Python I want to use and install the needed libraries in a local environment, stopping me from polluting my global python environment with relatively specialised and particular libraries.

The real issue was after setting up my virtual environment and installed the recipe-scrapers library and it's dependencies.....it didn't work.

Now, it had been a couple of months since the last time I had tried using the recipe-scrapers library, but I couldn't see why it wasn't working. My initial instinct was that I had made a mistake in my code, but eventually after verifying it was correctly implemented, I thought perhaps I had made a mistake with setting up my venv (virtual environment), that being the most recent technology that I had implemented, but after removing it and setting it up again, and no obvious issues... I was stumped....for at least 3 days (more like a full week, if I am being honest...)

Eventually I went back to the GitHub for the library and checked out the raised Issues, and lo-and-behold, right there at the top is someone pointing out that :

Adding lxml>=5.0.0,<5.1.0 to requirements-dev.txt and reinstalling via pip resolved this issue for me.

Ahah! Sweet relief, it wasn't my own stupidity causing issues, but some dependency for the recipe-scrapers library having a breaking update! And the solution is right there, thank god for disconsented!
This sent off on a short detour exploring the use and usefulness of a requirements.txt file (A pythonesque json.lock file which lists all the necessary libraries and the version required), and solved my issue.

Finally, a working recipe-scraper!

Preparations Complete....now what?

So finally I had everything in place. My root directory had backend and frontend directories, with a Python virtual environment set up with Flask framework structure in place, and a working recipe-scraper library, and a vite-Vue project set up in my frontend directory.
The next step is planning the architecture of the site and figuring out what routes I would need to define, what kind of different pages I would need, what functionality I want to include for the MVP....wait, I'm forgetting something....

Basic Databasing

The final part of my set-up tripod, a database! So my initial thought was to use a SQL based database with tables everywhere, with the help of a colleague I had sketched out a fairly basic schema for my relational database....but with a bit of reflection, and realising that recipe-scrapers was returning a JSON, I decided to look into MongoDB, knowing that it's document based system might not be more suitable to my application, with storing recipes as documents in a collection for recipes and the relevant information (Title, Image, Time to cook, Ingredients, Cooking Instructions) and having a separate collection for Users (Username, email, password). So using the MongoDB Atlas online set-up, I created a basic database, and using the connection string provided, I will be able to connect from my backend to my database!

The End of the Beginning

So for now I have all the pieces in place and ready, and will need to give some thought to sketching out the architecture of the site itself, and roughly sketching out the API routes. In my next article, I will detail the next steps I have taken and how the structure of the actual site began to take form and evolve, as well as more of the details of the actual code being used in the front and back ends.

Until next time, be safe and stay happy, thank you for taking the time to read my little side project introduction and set-up.

Confidently Incorrect - Navigating Battleships

Bradley Hill — Tue, 16 Apr 2024 08:45:44 +0000

Confidently Incorrect since 1987

Background

So I started The Odin Project a while ago now...at least a year now, with a big slow-down during the 9 months of my studies with Ada Tech School, but I have since returned to The Odin project with gusto, and would like to take the time to discuss my latest mini-project, the last suggested project for the part of The Odin Project curriculum regarding JavaScript.

Here is the GitHub link to the project: Battleships

Now I have been using TypeScript for many months now and see no reason not to use TypeScript to complete the JavaScript projects, nothing like type safety for improving the quality of my code, and the Intellisense improvements certainly make it more pleasing to work with in VSCode.

There is a full description of the objectives to be met during the project, and we are tasked with writing our code practising Test-Driven Development, and Object Orientated Programming.

So what will we be needing for this project? Ships, of course! And a Player object too, not to mention a Gameboard object to put our Ships on, and our Players to have one each. Then a GameLoop to manage the game logic, of course.

Let's not forget the TDD, so I guess a folder full of our test suites as well(I'm using Jest for testing). And of course a CSS file for styling, HTML file and a script file for the DOM manipulation, got to try and maintain a good separation of concerns! So eventually I ended up with a nice little architecture like this:

And with a month or so of on and off working on the program, with various distractions, not least of which has been the job hunt, I have ended up with a game that looks like this:

Now evidently I am no genius when it comes to the visual design, but I am happy with the simplicity and the colours, all the important information is readily visible to the player, and a simple dropdown selector for changing the difficulty (we will talk about that later, oh yes!) and space for the moves made by both players.

Using TDD, or how I learned to love tests.

Now I have been introduced to testing in my studies, found them interesting but didn't have much use at the time for them, and with the time pressures of our group projects there was little wiggle room for writing tests... More's the pity, it seems.

Now, it definitely took me a little while to wrap my brain around the change in thinking that TDD requires. Testing something....before there is something to test? Seems madness, illogical, putting the cart in front of the horse.... But it really helps! The process is often described as Red, Green, Refactor.

Red: Write a test. The most simple basic test you can think of. You need an object back from a function, great. Test that it returns an object. No more. No less. This test will fail (Comes back red when you run your automated testing library npm test for this project), because we have nothing for it to test. Well, we can fix that....
Green: Write the code to pass the test. Now stop for a second, and go back and read that first sentence. Write the code to pass the test. No more than that. So your test is checking that your function returns an object? Write the function, return an object. Stop. No more than is necessary to pass the test. This definitely resulted in me back tracking and deleting some code I had enthusiastically carried on typing with after writing enough to pass the test, but honestly it's probably the key part of the process.
Refactor: After your test is passing (run your test suites, see that glorious green of victory!) time to go back and refactor the test, or in my case write a new test, that will test the next part of the function that you require.

This process helps writing tighter, cleaner code, with each addition to the code being focused and minimal, and whilst considering what test to write it gives you direction and centres attention on the necessary.

Could be better

Boy is there room for improvement......

Whilst I am happy (enough) with the project to consider it finished personally, there are many things which could be improved and implemented.

A better Game Over/ You Won message. This would probably be better handled similarly to the introductory message, with an HTML element that is displayed depending on the end of game state. Honestly, the only reason I haven't done this was my rush to be done with the project.

Taking a broader view of the code base, I have received some very useful feedback from the user u/jambalaya004 on Reddit, that I will list here, as it seems to me to be very good feedback for me to take onboard.

Methods nested inside objects : It makes the code harder to read, and any future updating of the code would quickly become a spaghetti nightmare. Splitting up the functions and adding them to the objects by reference would be cleaner and easier to modify in the future.

This is the largest change I think I need to bear in mind, I would much rather my code be easy to read for when I return to it in the future, or it gets passed to another person to modify. I may return to the project in the coming weeks and attempt to refactor it in this respect, although for now I must return to the job hunt for now.

Typescript Interfaces : They suggested that I move all the Interfaces out from each file and containing them within a src/models directory. This is just a simple and elegant change, I feel a bit stupid for no thinking of it myself. I can then just import the interfaces to where they are needed and improves the organisation of the project.
If, If, If, If : Nested if statements, I myself thought that there was too much nesting of If statements even as I was writing the code. They point out it adds complexity (the Enemy of clean code) and complicates testing (I definitely experienced some of this). So I will be doing some research and learning on how to invert if statements and other ways to reduce code paths and nesting.
let should not be my default but const : Something I am trying to shift away from is my instinctive defaulting to declare my variables with let and using const to make immutable what doesn't need to change. Definitely good advice and something I could improve on in this project.

To conclude

I am pleased with this project, it definitely has taken effort on my part and I have learnt some good practising that I look forward to using going forward. I also can see more clearly the good habits I want to try and instil now before the bad habits set in.

There were frustrations and compromises and victories, but little by little I can see my progress, and I still enjoy the act of overcoming these new challenges and learning more and more. Each day is another little lesson. I look forward to continuing with The Odin Project and the next challenges, but in the meantime I must return to looking for my alternance (apprenticeship) and maybe a small personal project before launching into the next part of the curriculum.

Until next time, be safe and stay happy, thank you for taking the time to read my little Project review.

Confidently Incorrect - Microblogging Platform

Bradley Hill — Tue, 05 Mar 2024 11:15:30 +0000

Confidently Incorrect since 1987

Docker, Laravel and MVC

This was a fun project, smaller group, but a return to PHP, this time using the Laravel framework, and having to manage installing docker and using a provided container for the project was the first challenge for us, to the point that before beginning working on the project we had an afternoon reserved for ensuring the Windows users had WSL2 installed and setup to be best placed to initialise the project. Luckily I have been using Ubuntu for all of my coding at Ada Tech School since the beginning, and it definitely simplified this process for myself, although I did make a small mistake with copying the .env.example file provided to .env file after installing the docker container which caused it not to work, so I had to do a fresh installation making sure to follow the readme to the letter this time.

As a team we decided to conduct the majority of our work as a mob, with one person piloting the keyboard and the others discussing and deciding how to proceed with what code to write, as well as to have a daily meeting each morning to decide upon what our specific goals for that day will be and how we are going to proceed, with a recap held after the lunch break and at the end of the day, to review the work we have done.

Our early days were spent getting used to the Laravel framework, studying the documentation and looking at various short tutorials, from which we used Blade to create our Views, the pages that will be displayed to the users.

One of the benefits of using Laravel is that it imposes an MVC architecture to the project, the Model-View-Controller architecture, which helps greatly with organising the files with shared responsibility into shared directories, separating the responsibilities between the View (user interface and presenting data), the Model (data and business logic) and the Controller (the in-between responsible for communicating between the View and the Model, coordinating the flow of data and the applications' behaviour).

It also helps with writing code bearing in mind the SOLID principles, a very useful group of principles to bear in mind whilst using Laravel and its Object Orientated Programming.

This all went well, but our progress slowed as we progressed from creating the various pages we were going to use, to coding the routes and routing, but once we had become more confident with the syntax become easy to define our endpoints and routing for switching pages.

We also began using an ORM (object relational manager) with our database Eloquent which whilst our first time using an ORM, does very quickly become clear that it facilitates our interaction with our database, which we were using a PostgreSQL database which came bundled in our initial docker container for this project.

The one great failure on our part with our project, was neglecting the testing, when we had PHPUnit available for us to create a suite of unit tests, feature tests, and API testing, all of which would have improved the quality of our application.

If I were to redo this project, I would start from a TDD (Test driven development) approach, and ensure that we had a decent coverage with our tests. It may seem to slow down the process of writing the code, but writing the tests before the code can end up saving you time in the long run, by catching bugs early, and crafting higher quality code from the beginning.

And that is it for this short series discussing the projects completed whilst studying at Ada Tech School, at least whilst I was studying there.

My next short series of articles will be coming shortly, so until next time, stay safe and be well!

Confidently Incorrect - Furniture Re-Sale Site

Bradley Hill — Tue, 27 Feb 2024 10:47:33 +0000

Confidently Incorrect since 1987

COPAMEBA and managing an online store

So with this project our objective was to create a site allowing an (imaginary) client to manage her stock of second-hand furniture for re-sale online and allow members to reserve/purchase pieces, and allow the client/admin to add and remove articles.

The organisation of the team for this project was to be in larger groups than before, where we were in groups of four or three before, this project was to be completed as a group of 8, with us being divided into two subteams, one front-end and one back-end. With two weeks to complete the project, we would work for a week and then switch the teams, so the front-end would take over and complete the back-end and vice versa.

The immediate thoughts with regard to this organisation were the importance that the documentation would have when the time to switch would have, and the increased need to usefully comment our code for when the other team took over.

The only constraints on our choice of tech stack was the use of Bootstrap for our CSS, so after a discussion within the group we decided to use React for the front-end with Bootstrap, due to our shared familiarity with it, and for the back-end we would use Node.js and Express, again, sticking to the JavaScript we were most familiar with, and using SQLite for our database, due to its relative ease of install and simplicity to integrate with VSCode.

Building on our previous experience building and using API's we planned our endpoints for the front-end to be able to display the furniture available by category, an individual item and everything currently available.

One of the new challenges with this project (beyond the organisation and synchronisation between teams) was to manage a user authentication system, where users could be created, and we had a column on the users table that would allow us to define if the user had admin privileges, thus allowing us to limit access to the administrators control panel to the designated administrator/s.

The project proved to be challenging, the communication and organisation proving to be the greatest difficulty, although it was well mastered towards the end of the fortnight, with the work we had previously done being nicely and smoothly woven together into the working site.

Our repository is linked here with a rather good readme, thanks to my teammates!

It was particularly satisfying working across the teams to unify our separate sides and seeing how the separate code integrated and became a functional whole. The more I use databases the more I become curious as to the myriad different approaches to organising and storing the data needed, it's a fascinating if expansive area of programming, and I look forward to learning more and more as I gain more practical experience using and building my databases.

Next week's project will be creating a microblogging site returning to PHP this time using Laravel to make our lives a bit easier (?), at least compared to our first brush with PHP vanilla.

Until next time, be safe and stay happy!

Confidently Incorrect - Social Networking

Bradley Hill — Fri, 23 Feb 2024 13:33:19 +0000

Confidently Incorrect since 1987

Social Network using PHP and a database!

In contrast with the previous project, going into this project it felt like an enormous undertaking!
Luckily (perhaps) we were given a decent amount of code already written for us to build on.

As had now become standard for our group projects, we set up a group Trello for organising our tasks and dividing up the responsibility of completing them, as well as agreeing to a daily meeting to discuss the remaining tasks and difficulties and successes from the previous day.

There were three levels proposed to completing this project:

Level One

The proposed social network (inspired by Twitter or Facebook) will display user messages on different pages (the latest messages, those from a particular user, those from followed users, and those associated with a particular keyword).

As we were initially given a large amount of pre-written code, HTML/CSS and PHP, also several SQL requests were pre-constructed. The completion of this first level was largely an exercise in filling in blanks and refactoring erroneous code, some small adjustments to the SQL requests to ensure that the correct data is being recuperated and displayed on the pages. Despite our initial issues with installing and setting up our environment, we all ended up using the MAMP stack, and I believe we had completed all the corrections necessary to be displaying the relevant information from the database after the third day. The first day had been mostly spent setting up the Trello and installing/troubleshooting the environments, and the second day we spent the first half reading a variety of documentation on PHP and SQL, and then begin familiarising ourselves with the code which we had been provided.

Level Two

PHP processing of HTML forms, as well as registration and authentication issues.

This section of the project took as some time, mostly learning some of the nuances of PHP and how to implement the functionality that we wanted. The change in symbol for concatenating kept us on our toes, and eventually, with the help of our teachers, got to grips with the idea of Superglobal variables which enabled us to keep track of a particular user being logged in across the pages of the app as well as managing the visibility of posts users create and who can see what, permissions being managed basically. Which definitely took some work and misfires, but eventually we found that it all started to fit together into an effective web of relations.

We did have an issue with the likes increasing with a page refresh, despite no additionally entries being registered in the database, which I think we resolved on the final day of the project, but for the life of me I can't remember for sure if we did, how we did it....

The project as a whole was very interesting, not only our first introduction to PHP and writing SQL requests and manipulating a database, but also being given an existing codebase to refactor and build from, allowing us to get some practice with reading others code and understanding its purpose and what we can build from it.
The link to the GitHub repository is here

Although I must say the readme file could do with some work, perhaps in the future I will go back and improve it!

Next week is the largest group project we worked on, with two separate teams, for Front and Back ends, with a switching of roles after the first week.

Confidently Incorrect - Navigator Extension

Bradley Hill — Tue, 13 Feb 2024 11:32:45 +0000

Confidently Incorrect since 1987

Creating an extension for Chrome/Firefox

So this project felt a bit smaller in scale than our previous projects, perhaps because of our growing competence with coding, but what it allowed us as a team to do was to concentrate on the processes associated with working as a team on a project.

From the outset, we spent time planning and putting in place the ubiquitous rituals and practices that come with AGILE methodology.

So we set up our Trello board for organising our objectives, and agreed that we would undertake a daily stand-up each morning where we discuss new objectives, how we would assign the objectives for that day, our experiences from the previous day, any ideas or suggestions which we want to share with the group.

As a team of 4 we decided to practice pair programming, changing the pairs on a daily basis, with each person taking a turn at the keyboard throughout the day, to ensure we all were comfortable with the code and had a chance to be actively contributing to the codebase, which was a great experience with us learning how we each approach the code differently and getting to see different styles of solving issues within the codebase.

We also agreed that at the end of each day we would have a 15-minute session where we could share our frustrations and victories from the day, and to decide whether any objectives would need more time to be completed to our satisfaction.
This was particularly easy to implement as we already had a daily ritual of writing a journal entry at the end of each day for our school, Ada Tech School.

So we were given free rein as to what kind of extension we were to create, and after some short discussion we settled upon the idea of an extension which when activated would replace certain words on a webpage with a selection of emojis. After settling upon this idea, we set ourselves to reading documentation and various articles relating to how exactly to go about creating a navigator extension, which we allowed a half day for, after which we came together to share our knowledge and thoughts on how to best go about creating our extension, which we decide to call Sweet Web, and quickly created a little graphic for the project:

So after our research, we decided to create a roadmap for our project to allow us to manage our time and deconstruct the challenges we set ourselves:

Creating the manifest (v3)
Using a Regex to find the words on the page
Having a clickable button to activate/deactivate the extension
Use local storage to allow users to add words to the banned list
Make the extension cross-platform (Firefox as well as Chromium browsers)

All of these goals were achieved, although the most difficult of these objectives turned out to be making the extension work with Firefox, due to Firefox using the version 2 for the manifest files, so in the end we recreated our extension using the older format of the manifest files, which is not exactly what we envisaged to begin with, but most importantly, worked!

So our extension traverses all the nodes of the DOM (Document Object Model) searching for text, at which point, when text is discovered, the regex is used whereupon using the predefined list of banned words (and any user added words from local storage) it will replace those words with a selection of emojis.

As a brief aside, this project was the point in my studies where it became clear to me the time to upgrade from my 6-year-old laptop had arrived, with my laptop taking a markedly longer time to traverse the nodes in the DOM than my colleagues...

This was also the project where we began to take the time to document our project more rigorously, and using Readmi we created a more complete and attractive ReadMe document, as well as having a logbook which we documented our daily struggles and victories within.

Here is the link to our GitHub repository for those interested, although the majority of our documentation is in French, so be forewarned anglophones reading!

This project was great fun to work on, and definitely benefited from our adherence to our daily rituals and constant communication between pairs and individuals, using Slack and regular meetups to ensure that we were all up to date with changes and improvements and bugs within the code.

Next week, I will discuss our first project (and my first encounter with) using PHP!

Confidently Incorrect - Data-Viz and API's

Bradley Hill — Tue, 06 Feb 2024 16:24:16 +0000

Confidently Incorrect since 1987

API's and what they are for...

So here we begin to use a more commonly encountered language, the hot mess that is JavaScript! As well as our first interactions with API's and using the resulting data how we wish.

(For the record, I really quite enjoy JavaScript, especially TypeScript now I have adapted to strongly typing everything.)

So I would like to start by saying that the strict definition of an API still remains a bit...imprecise, for me. Given my background in Hospitality, my understanding of it is that the front-end of the software is equated to the Menu in a restaurant, offering a variety of choices to the customer/client, and the back-end of the software is the kitchen/Back of House, who have access to the raw materials and process the data into digestible and desired dishes, the services proposed by the Menu/front-end. The API then for me are the waiters and waitresses who transmit the demands from the front-end to the back-end, where the back-end prepares the demanded services, which are then delivered to the clients having been prepared by the back-end.

If anyone can explain API's and the role they play better, please do leave a comment below, I would **love **to hear other people's definitions!

Data Visualisation and using API's

Moving on to the project itself, we were simply asked to use an API and represent the information we recuperated visually. All rather simple, with an ocean of possibility in front of us. Our group settled upon the idea of creating something that would be useful to us in the future when the time came for the search for job offers.

As such, we were decided to use the Pôle emploi to get information regarding the Developer job posts available in the many regions of France. From the number available, to what are the most common languages advertised for, common frameworks, amount of experience and similar pertinent information, and then to display the information as pie graphs (delightfully called Camembert by the French!).

Several main problems for us to overcome as a team, the first being our relative inexperience setting up Git and how to use branches (which we did use towards the end of the project, but that can be a discussion in the later projects...), but once we had our repository set up, and a Trello board for creating job tickets we were underway.

How to make API calls correctly
How to visualise our data
How to make it not ugly

So we were lucky when choosing our API to use in as much as a government linked organisation, it is remarkably well documented, so once we had signed up for our auth-token, we had no real issues, beyond a bit of experimentation, getting the data we wanted back. We originally used Postman to test our API calls, but eventually found that there was a built-in test for our API calls on the site. But Postman is a great tool and I will be using again in the future, of that I have no doubt.

The next obstacle we had to overcome was how we were going to be visualising our data. We had already decided pie graphs were the simplest method for displaying the information, so the users can see at a glance, and after a bit of searching we found Chart.js which seemed simple enough for us to use...and eventually it was!
One issue we had was integrating it into our site, and eventually we had to use the CDN method, due to our inexperience with Node, but it worked!

<script src="https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.7.2/Chart.min.js"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/chartjs-plugin-datalabels@0.7.0"></script>

Our final battle was with CSS, with a few issues with the colours on the graphs changing, seemingly unrelated to our styling, but we kept it simple, and navigating our first pull request, but with no conflicts it feels like, in hindsight, it barely counts, merging the graph functionality into the various separate JavaScript files, we were left with a handsome little site, our Choose your career project was finished.

Next week, we will be going over the Navigator Extension project, but this project was great fun and challenging us in ways we hadn't been challenged before. Until next time!

Confidently Incorrect - Pico-8

Bradley Hill — Tue, 30 Jan 2024 10:45:53 +0000

Confidently Incorrect since 1987

Pico-8 and the first collaborative project

So for those who don't know, Pico-8 is a virtual console for people to design and develop their own games with, and enables the sharing of these games for others to use.

Famously the first version of the game Celeste was created with Pico-8, here is that version.

My first time working as part of a group on any coding project, the goal was to create a simple video game using Pico-8 during the 2 weeks and to present our creation at the end of the project.
Simple enough, some fairly basic conditions to be fulfilled :

Moving entities
Events
Interactions

Happily, our group quickly settled on the idea which we were going to use as the basis of our game, that of a mouse foraging and collecting various foodstuffs from a garden/outdoor environment to unlock the door to their home and feed their family inside.

Setting up our GitHub repository was relatively painless, despite it being the first time for some of us, but due to our lack of experience to avoid conflicts we did most of our actual coding as a mob, with us all taking turns at the keyboard, which worked well given the small size of the team and small scale of the project.

We had been provided various useful resources to help us :

Which all proved to be very useful, to greater or lesser degrees.
The main game loop is contained within the _init(), _update() and _draw() functions.

_init() function is initialising the game state, creating the player entity, setting the score and displaying a welcome message, all pretty simple once we had checked the code in some of the demos provided with Pico-8 and a few YouTube tutorials watched.

_update() function contains the game logic, the meat of the sandwich, player movement and collisions we also locked the player from moving whilst the welcome message was still being displayed, camera movement so that the player sprite stayed central on-screen and also kept the screen the other side of the door hidden until it was unlocked, collecting items, the player sprite animation cycle, the unlocking of the door and updating the encouraging message displayed for the player to continue collecting items.

This is very much the section where we spent the greatest amount of time working on, as well as breaking and fixing the game. The _init() function, by its nature of only being necessary at the start of the game was comparatively easy to put in place, as our ideas for our game shifted and evolved we had to add and tweak the _update() function to follow our vision for the game. The collision logic and using the flags took some time for us to use appropriately, but once implemented successfully we found it easy to reproduce, for blocking player movement and collecting the food sprites.

_draw() function is responsible for rendering the game UI, Map and Sprites. The main tricky parts here were updating the map after the door unlocks once enough food had been collected, and displaying the messages and updating them with the score.

Altogether, it was a very enjoyable project, especially for the first time working together as part of a team on the same project. There are definitely things we could have added in if we had more time to work on it, notably some more work on the end-state of the game, adding in sounds and music. But considering that it was our first time using Pico-8 and the Lua language, I am pleased with what we created. The animation of our mouse moving in particular is a point of pride, as well as the sprites made. We did write the majority of our code using VSCode, simply because we found the built-in IDE of Pico-8 a bit...uncomfortable on the eyes.

Next week, our project for introducing us to the notion of asynchronous calls and API's and Data Visualisation!

Confidently Incorrect - Pico-8

Bradley Hill — Tue, 30 Jan 2024 10:45:53 +0000

Confidently Incorrect since 1987

Pico-8 and the first collaborative project

So for those who don't know, Pico-8 is a virtual console for people to design and develop their own games with, and enables the sharing of these games for others to use.

Famously the first version of the game Celeste was created with Pico-8, here is that version.

Moving entities
Events
Interactions

We had been provided various useful resources to help us :

Which all proved to be very useful, to greater or lesser degrees.
The main game loop is contained within the _init(), _update() and _draw() functions.

Let me know if you want to see more code in these articles, or if there is any aspect of the projects you would like to read more about!

Next week, our project for introducing us to the notion of asynchronous calls and API's and Data Visualisation!

Confidently Incorrect - Revisiting previous projects.

Bradley Hill — Mon, 22 Jan 2024 15:11:50 +0000

Confidently Incorrect since 1987

Personal Brief

So I have been learning how to code and broadly development since 2020, during the Covid-19 lockdowns, beginning with the classic triple threat of HTML/CSS/JavaScript, adding into the mix a dash of Python and since returning to live in France 2022 have committed to The Odin Project web-development program and happily began my full time formal learning with Ada Tech School in 2023. Now the search for my 12-month-long apprenticeship (Alternance, en français) begins, as well as continuing my self-study and side-projects.

Introduction to this series of articles

As I approach the end of my formal learning, I would like to take the time to look back at the projects that I have participated in over the course of my training.

6 mini-projects in total, of increasing complexity

A simple 2D video Game - Using Pico-8 and a modified Lua language
An exercise in Data Visualisation and using API's - Using JavaScript and Chart.js
Navigator Extension called 'SweetWeb' for censoring words from sites - Using JavaScript and Manifest.json
Simple Social Network - Using PHP and a predefined simple database.
Used furniture e-commerce website - React was used for the front-end and express and node.js were used for the back-end.
Microblogging platform - using PHP with Laravel as well as first time using a docker container.

Conclusion

Over the next few articles I plan to review and suggest, confidently, changes that could be made to improve the code and perhaps the approach to the project we had whilst working together as a group. All this is an exercise in self-reflection, and revisiting code that has been left behind, and to try and identify weaknesses and suggest changes that I would make now, with the benefits of hindsight and greater experience.