YAML...(Yet Another Markup Language)... Good Morning, Good Afternoon or perhaps Good Evening depending on when and where you're reading this blog post!
It has been an honestly amazing week here at the final week of the backend section of the Northcoders Bootcamp where we focused on a solo portfolio project, made use of Kanban which is one of many agile methodologies used in software development!
But before I dive straight into what we covered this week at Northcoders, I would like to give an ENOURMOUS THANK YOU TO THE NORTHCODER MENTOR TEAM!.
The Northcoders Mentors were especially busy with answering personal requests for help via "NC Help" on Slack (Northcoders' helpline) AND reviewing "Pull Requests" on GitHub with insightful code reviews. You're all amazing and thank you for all of the dedication and kind words!! 😁
Like always if you enjoyed this week's blog, feel free to drop me a follow on Twitter, LinkedIn and GitHub!
The Nitty Gritty - What We Covered
Without further ado, what did we cover here at the final end of the backend section of the Northcoders Bootcamp, and what were my takeaways, well here they are:
- Northcoders News/Games RESTFUL API - Solo Portfolio Project
- Agile Methodology - Kanban
- Git Branches - What, why & how?
- Hosting w/ Heroku
- CI/CD - Continuous Integration & Continuous Delivery with GitHub Actions
Solo Portfolio project - Northcoders News/Games API
Everything that we had learnt within the last two weeks all built up to this moment, our first and very own RESTFUL API that we will be using in just 2-3 weeks time to serve up data to our Front End Project.
I won't sugarcoat it and say I was both nervous and excited at the same time going into this because it's a solo portfolio project that would be required in just a few weeks time.
But, the Northcoders Mentoring Team were on the ball with making sure that they were always able to help myself and the other cohort members, that the nervous anxiety biting away at me had disappeared, and I was able to focus on enjoying the entire process of building up an API from scratch!
So for the final portfolio project that we had to create this week, we were given two options of creating either:
1) News API
2) Games API
I would have instinctually chose the Games API because I love video games, but my hopes were dashed when it was revealed to be boardgames and so I chose the News API (Nothing wrong with a good ol' game of Monopoly or Dungeons & Dragons though!)
Although I won't be going into the specifities of the file structure & code that was used when writing this project because all of the content that has been covered in the last two weeks were used to build this project up!
However, I can say that I am really satisfied with the amount of work that I had completed this week. From setting up the server to listen to requests, to having a fully working RESTFUL API that can Create, Read, Update and Delete data that resides in the database, there is honestly no greater feeling!
One thing that I had to combat this week was the feeling of "Imposter Syndrome", which is the tiny voice at the back of your head telling you that you aren't good enough.
However, the constant positive feedback loop from the mentors when they reviewed my code, talking with fellow friends on the cohort and realising we all felt the same way, and looking back at previous posts to find how far I have come has helped me tremendously.
So if you're another member "A" cohort, not just mine and perhaps to those reading in the future, remember that you aren't alone on this course and if you're here then you're here for a reason and keep cracking on, you're doing amazing!
Git Branches - Not Actual Twigs
So, what are "Git Branches". As the subheading suggests, they aren't the twigs on trees outside, but they are similar!
"Git" is a version control software that is used to keep track of the work that you have done so that should you inevitably break something, you will be able to go back to a time where it wasn't broken!
But, the beauty of Git isn't limited to time-travelling back to the past and present. It's also beautiful because you are able to "Branch Off" and do your own independent work before they are inevitably "Merged" together.
The concept of "Branching" with Git is just that - being able to work on a separate piece of code on another branch and then having another person review the code you have written to ensure quality, before being given essential permission to merge that code - through what we call "Pull Requests" on GitHub.
The process that we followed this week was:
1) "Checkout" into a new branch for a new task (E.g. Task 2 - GET /api/articles using the command of git checkout -B Task-2-GET-Api-Articles which creates a new branch to work from independent of the main branch.
2) Work independently on this new Task-2 branch and once we are happy that we've satisfied the work we need to do for that task. We add, commit & push this code to GitHub using git push origin Task-2-Get-Api-Articles - which will allow you to write information on which task & what you've done in this code as summary.
3) After successfully creating a "Pull Request", we would head straight into Slack and type in /nchelp pr which is just Northcoders Help Pull Request so that Northcoders Mentors would be able to distinguish between a "General Help Request" and "Pull Request - Please Look!" - in which you'd submit the task name & number, and link.
4) Once you've received feedback (This is called a "Code Review") from a mentor and made the adjustments as per the feedback received, go ahead and push those new adjustments, click that green "Merge" button so that those changes are merged into the main repository, and go ahead and press the Delete Branch button in GitHub afterwards.
5) Once you have done this, make sure to go back to the original main branch using git checkout main and use the command git pull origin main so that those changes are pulled from GitHub that were merged and into your local repository!
6) Lastly, in order to clean up the branches that you have, make sure to use the following command to also delete unused branches: git branch -D origin Task-2-Get-Api-Articles and move on with the next task!
Agile Methodology: Kanban
If you have read my first few blog posts, you may have an idea of what "Agile Methodology" eludes to, but for those who may not be familiar:
Agile Methodology is an iterative approach to project management & software development that helps teams deliver value (Atlassian)
In this case, "Kanban" is one of many Agile Methodologies that are used in the Software Development industry because of how it is able to help teams and individualds visually divide up their work and display what is essential and what needs to be done.
The term "Kanban" has its roots in Japan where it's referred to in Japanese as 看板方式 (kanban houshiki) - where an engineer named Taiichi Ohno developed the methodology during the time he was working at Toyota Automotive.
You may have seen huge whiteboards with post-it notes scattered all over it in an engineering team's corner of the office, but this is most likely what is going on!
For a standard Kanban Board, you will have "Core Tasks" that you will be required to have done by a specified time frame, a section of "Done Tasks" that you move these essentially "to-do" post-it notes to, and any "Extra Tasks" that can be done should all of the core tasks have been completed!
However, we live in a digital age and so our choice of Kanban Boards was a piece of software called "Trello", which allows you to create personal boards and share access with other users which is awesome because of that shot of adrenaline everytime you move a section to "Code Review" and "Completed Tasks".
Hosting /w Heroku
You may or may not have heard of the term "Hosting" before, but what does it mean and how do you do it?
Hosting is where you have piece of code that you want to be available on the internet for others (and yourself) to use, and so for us Northcoders, we want to be able to host our backend API for the world to see!
One of the services that we chose to use was "Heroku" which allows users to setup free hosting of backend servers so that we don't have to! (Although sadly the free hosting is unavailable come 26th November 2022 - However, it's hinted that we will have our own platform to perhaps host as Northcoders Students! 👀)
Up until we have had been testing locally, but setting up the database and all of the files so that they would be usable when being hosted to Heroku was another matter.
If you are interested in learning on how to deploy a Back-End Project with Heroku, then try this resource from Codecademy.
CICD - Continouous Integration & Continuous Delivery w/ GitHub Actions
This final lecture today (Friday) covered a really important aspect of the course that will be amazing to understand and explain to prospective employers, and this is the concept of CI/CD or Continuous Integration & Continuous Delivery.
Before I hop onto the CI/CD bandwagon and try to explain what it is. Imagine this, you have finally setup Heroku or hosting for your project and you need to manually test it works on both the local version & production (Deployed) version that other users would use, for every single new change that you make.
I will be completely honest with you, the very thought of having to do all of this manually is enough to drive me insane, especially with how many changes are being made at a constant rate!
Luckiy, CI/CD helps us essentially automate the workflow by taking the code that we write, create an environment that will literally clone the repository, download Node & Postgres (Or any database), run your project and tests, and should those tests pass, it would then update your deployed production version of the code on Heroku.
Now that sounds absolutely AMAZING because us Software Engineers are inherently lazy by nature and don't want to reinvent the next wheel, so anything to ensure that we're happy and productive is a win-win, right?
One of the methods that we were introduced to was "GitHub Actions" and praise the lord, it looks completely overwhelming but once you've gotten your head around it, it's absolutely phenomenal.
First, we would need to create a .github/workflows file in our roote directory of the project, and write a YAML File that will take in the instructions so that GitHub Actions can start automating our workflow.
But, you may have noticed that I've finally mentioned "YAML" which was ruled off at the beginning of the post, right?
YAML... Oh man, this one caused a real headache. YAML stands for "Yet Another Markup Language" as there's a lot of other Markup Language such as "Markdown" (Which coincidentally Dev.to and my favourite software called Inkdrop use to keep track of writing my notes).
YAML caused me a real headache because it takes strict to the next level. The level of indentation, the keywords used, the spacing and the character sensitivity are all taken into consideration, so even ONE typo (E.g. Missed indentation or typing in DATE vs date) and your GitHub Actions workflow will not work!
Here's a link to the Test and Deploy Template that I've made available, which I will definitely be using myself because YAML is a complete nightmare!
Thoughts Going Forward
Honestly, really chuffed with the amount of work that I've gone through this week and really looking forward to the Front End portion of the Northcoders Bootcamp and will definitely be trying to somehow improve my HTML/CSS skills on Sunday, but for now I'm going to enjoy the rest of my Friday evening & Saturday night with friends!
If you have made it to the very end, thank you for sticking around and I hope this week's blog which doesn't contain any code, was somewhat useful and I hope to see you again this time next week!
Socials
Feel free to give me a follow on any of my socials down below!
Top comments (0)