DEV Community: Christopher Lam

The Rising Coder - Week 13/13 (Project Week 3/3)

Christopher Lam — Sat, 26 Nov 2022 00:39:58 +0000

Good morning, good afternoon and good evening! It has finally arrived, the final blog entry to The Rising Coder and my journey at the Northcoders Bootcamp, and what an absolute pleasure it has been and I would not trade in this precious 13-week experience for anything at all.

From the mentors that supported myself and fellow students, my fellow cohort members that were always approachable and supportive during every step of the way, and to my final project team that were an absolute pleasure to work with over the course of the past three weeks.

Throughout the bootcamp I was regularly talking with a previous alumni Atlas Sproson who I coincidentally met through a mutual Discord server, and his advice & words stuck with me throughout the bootcamp. He had told me that once the clock hits 5PM and you're on your way back home on the train that the reality begins to set in. You realise that your journey has ended for now, and whilst it was a bittersweet parting, it's definitely not goodbye forever!

So, what exactly happened during my final week at the Northcoders Bootcamp and what are my future plans going forward? Feel free to skip ahead to the specified sections below at your pleasure:

Match Me If You Can - Internal Networking Event
Final Week Schedule
How the final day went
Team G3O's Final Project
Self-Reflection
Thoughts going forward - what now?

Match Me If You Can - Internal Networking Event

As Northcoders has a large network of hiring partners that are interested in hiring Northcoders Graduates, one of the events that Northcoders holds is called the "Match Me If You Can" that is abbreviated to MMIYC. This event aims to connect Northcoders Graduates with hiring partners so that we can get our foot in the door with our first Junior Software Engineer positions. I will be completely honest with you, I'm not the social butterfly by any means and I really felt out of my depth and comfort zone when I signed up for this event.

However, going into this bootcamp has changed me for the better. Previously it would have been easy to ignore this opportunity or to cancel my attendance altogether because of nerves. But, what I had learnt from my time at this bootcamp is that if you aren't willing to put in the time and push yourself out of your comfort zone then you won't be able to create any positive changes for yourself.

So the moment I booked my £17.00 return ticket from Macclesfield to Manchester, I made a stern committment to try my best during the MMIYC event. As these types of events and spaces are not what I'm comfortable with, I frantically researched a few days prior for a few YouTube videos to help myself feel prepared both mentally and physically.

Below this I will link the three videos that helped me out during my first time in a long time attending a networking event in hopes that it will help you. But, my main takeaway is that as long as you set yourself a goal and you push yourself of your comfort zone to give yourself a chance, then you will make progress - so give it your best shot, I'm sure you will not regret it at all!

Final Week Schedule

For those that are unfamiliar with the final project phase structure at Northcoders or perhaps need a refresh, here's the breakdown:

Week 1 - Introduction to Agile Methodology & Team-building exercises & Spiking Technology
Week 2 - Coding your project
Week 3 - Polishing off your project's MVP (Minimum Viable Product) & Presenting your project

During the second week of the final project phase, we exclusively build up our project's MVP, and following the third week - we aim to completely finish coding altogether on Wednesday. This is not to say that we finish the project entirely with all MVP and post-MVP features, but to get to a stage that we are comfortable demonstrating the project.

Thursday itself is reserved for the project's demonstration video that would be used for Friday. Our team had a bit of confusion alongside other teams in our cohort because of recent changes to the structure of the final project phase demonstrations due to the numbers of Northcoders rapidly growing each cohort.

However, here is a brief summary of what to expect for the final project phase demonstration:

REQUIRED - You will need to record a live demonstration video of your application for a maximum of 3-minutes with a voiceover. This will include information regarding what the project is, what tech stack was explored for the project, and what features your project has.
REQUIRED - Submitting a Dropbox that includes your project's live demonstration video with voiceover & photos of each team member.
REQUIRED - Submitting a Typeform that includes: Your team name, your team's project name, an extensive list of technology your team used and why, each name of your team member with personal biographies that would be submitted to the Northcoders Project Showcase for each individual team's projects.
OPTIONAL - If you have time, you will be able to create a slide show that has your tech-stack and explained in brief detail, what you think went well for your project, what you and your team could have done better, and if given more time what would you and your team have liked to implement in the future.

How The Final Day Went

Today was my final day at Northcoders and it wouldn't have been a proper farewell without going to the office! The previous two times I came to the office were my first day of the course (August 30th), and two days ago (November 23rd) for the MMIYC event, and those two times it took me 35 minutes to get from Piccadilly Station to the Northcoders Office which is near Manchester Metropolitan University.

The reason for that is both a mix of not living in Manchester and visiting often, and my compass tracking on my iPhone being turned off so my phone didn't properly track where I was going - but I managed to find this out a day before so it only took me 15 minutes to walk there as it should!

We started the day off by being given a task by Jim (The cohort lead mentor) called the "Retro" or "Retrospective". This is in short a brief period where you and your team get together and write on sticky notes in private about the things that you think went well, what could have gone better, and what you want to strive for in the future. But the trick to this is that you don't show each other what you have written yet so that neither of you and your team members are influenced by one another. So when the time comes for the reveal, you all put it on a board and talk through it all.

Or... That would have been the case for me and my team. As our team had already talked through the day prior about all of the above points, we had already been influenced by one-another and so the actual retro task for us was a bit difficult 😂

Although besides that, it was very nice being able to finally meet my team that comprises of Ellie Lyons, Kirils Knazevs, Nikita Selanko, Antony Lester andJon Linford in person at the office (Antony & Jon were unfortunately not able to come though).

Fast-forwarding to 11:30, it was finally to get the show on the road! We were moved into one of the small conference rooms in the office and sat in rows of seats staring at the screen that housed the presentation that included the presenting team's name & project demonstration video that we submitted a day prior.

There were so many great projects that were created during our cohort that included:

An original Wordle-inspired game called WordPearl
An interactive application to find friends to play boardgames with called All Aboard
An application that allows users to track their belongings so they never get lost called wHere
An interactive application to find local activities through creating & joining activities pinned on the map called Activime
A bucketlist application for future to-do activities with built-in communication features to inspire each other called WhyNot
A swipe-powered matching system for all of the foodies called Dinder
An interactive application aimed to teach children about growing your own plants called Seedlings
A nifty little application to find your kid's next Christmas present called Santa's Little Helper
A built-for-purpose application to track the latest discounts from multiple UK supermarkets called Supermaaaart
A Pokemon-Go-inspired application that enables you to take a quick screenshot of a bird to find out its species called Birdly
A gamified application that incentivises you to journey outside called Questr

And then there was our final project called Find 'n Dine - which will be covered below!

Team G3O's Final Project - Find 'n Dine

Our original name of Team G3O was meant to remain anonymous for the world to see, but because of a few miscommunications when submitting the incorrect team name on Thursday, we were outed as team "Overlords", so much for not letting anyone know about what "Team G3O" really meant 🤦

Besides that, getting into our final project - what exactly is it, why did we build it and what tech stack did we use to create it?

Find 'n Dine - Brief Summary

So quite briefly, Find 'n Dine is a cross-platform application that was built to help indecisive foodies find their next favourite dining location with a swipe of a finger. The user will be presented with a deck of cards that contains information regarding the restaurant's Google Review Stars, the restaurant's website & location, a carousel of images and the ability to add a restaurant to a list of favourites.

When the user decides to swipe right for interested and left for not interested, they are shown a little "Helper Icon" in the form of a green heart and red broken-heart for respective right and left swipes.

If the user wishes to remove a restaurant from any of the three lists (Interested/Not Interested/Favourited), then they just need to swipe to the left on each restaurant card to delete, or if they really want to clear the entire list then they would click the Clear button that would erase the entire list from the user's local storage.

The idea initially came across when we were discussing potential project ideas during the first week of the project phase when we had discussions of "What problems do we face and what could make it easier?" - and the topic that came up was "Trouble picking something new for date night", and that was when the seed was planted.

Prior to this our group had two other project ideas and of which one of those project ideas was what we originally gunned for until it was... gunned down 😂 And then this project idea arose to the surface and so that is where we have arrived to by the end of the project phase!

Find 'n Dine - Tech Stack

For both the Front-End and Back-End development of our final project, we used TypeScript which is a type-safe superset of JavaScript because we were already initially interested in learning about TypeScript because we constantly hear about it in the market, but it was only until we started using it ourselves that we understood the benefits and how much it improves developer experience.

Without further ado, I will introduce you to the tech stack that we used for both the Front-End and Back-End:

Front-End Tech Stack

React-Native & Expo Go - As our team wanted to create a cross-platform application that runs on both iOS and Android, we opted to use React-Native because of the cross-platform development nature of the platform and the accessible transition. However, as React-Native does not come with a pre-bundled packages to make lives of developers any easier, we opted to use Expo Go which allows us to view the changes to our application on our phones live, as well as being able to not write a single line of native iOS/Android code like you may be required to in traditional React-Native.
Redux & Redux-Persist - Our vision for the application was to ensure that the user's list of restaurants were to be stored locally and not be deleted upon reloading the application. Initially we tried to use the traditional React-Native Async Storage, however as we were using Expo Go - this library was yet to be supported and as a result, we had to find a work-aroound. Luckily we found Redux that allowed us to store all of this state pertaining to the restaurant lists of the user in a single store, and through using Redux-Persist, we were able to persist this data so that it was not lost on reloads.

Back-End Tech Stack

MongoDB & Mongoose - The dataset that we were working with originally included Antony Lester having to web-scrape for over 6+ hours on the Friday of the first week of the project phase, to which the number of lines of code was well over 260,000+. As a result of this, each of the objects had inconsistent data that was different from each other and were completely non-relational, and so we opted to use MongoDB because of it's non-relational database nature and ability to store JSON objects with relative ease. Mongoose was used to easily connect up our API server and host online.
GraphQL & Apollo GraphQL - Similar to our reasoning behind learning a new piece of technology, we had heard about GraphQL as an alternative to the traditional REST API. A quick TLDR is that REST APIs will typically return all of the data on a JSON object unless specified and so you could be under/over-fetching as a result. However, GraphQL eliminates this because you only fetch for the data you need. In order for our team to retrieve data from the database, we used Apollo GraphQL with Mongoose to easily connect the two to start making queries quickly.

Self-Reflection

As I mentioned at the beginning of this blog post, when I bid my farewells to the Northcoders tutors and fellow cohort members, and then finally my team members - it dawned on me that it's all over, just like that... I won't lie and say that it wasn't sad to part ways, but I really am glad that I joined the Northcoders Bootcamp and met everyone I had on the course.

From being a completely anxious wreck at the start of the course to feeling the happiest I have been in a long while, it's a night-and-day difference. Reflecting on how much progress I have made since both the start of the precourse and last year where I was not in the best place mentally, it has been amazing. I've been able to learn about so much in-demand technologies including JavaScript, TypeScript, Node, Express, GraphQL, Redux, Tailwind and so much more and I can finally confidently say that I can indefinitely add value, to of which I definitely could not have said previously.

Going into the bootcamp itself I wanted to contribute and create a safe atmosphere that encourages one-another to be positive and friendly towards one-another, and both the Northcoders Staff and my fellow cohort members reciprocated tenfold!

Originally I started writing this blog because I wanted to document my own journey so I can reflect on what I've done and perhaps give guidance to future Northcoders, but whenever people on the cohort meet me for the first time and drop in to say hi and that they've read my blog, I'm honestly beyond happy! So if you are reading this and you were one of them, then thank you for reading and supporting me, I really wish you all the best even after we have finally finished our journey for now and graduated!!!😌

Thoughts Going Forward

Although this is the end of one journey does not mean it's the end of my journey! After arriving home and finally feeling the reality of my time at Northcoders ending and laying lost before writing this blog post, I realised that I really enjoyed being able to voice to myself and others who were interested, about what I've been doing in hopes that I can encourage others.

So my thoughts going forward are that I would like to create a weekly blog series that will contain things that I have done for that week so that I can keep a solid routine of self-reflection so that I can keep track of what I've done, and keep you guys in the loop of what I've been up to 😊

Perhaps if you are reading this as a fellow cohort member and thought it was too late to start writing about your own experiences and journey, then I really implore you to give it a try yourself! Having that extra somebody to give you that extra nudge on the back like you guys have done for me when you mention you've ready my blog posts really does help, and so if you decide to start writing your own blog entries then please tag me and I'll be sure to join you on your journey together! 😊

But for now, I will definitely be taking a small break before returning to my grind, and again thank you for all of the continued support along the way and I hope to see you in my next series that will also be on my blog page!

Socials

Feel free to give me a follow on any of my socials down below!

The Rising Coder - Week 12/13 (Project Week 2/3)

Christopher Lam — Fri, 18 Nov 2022 19:52:49 +0000

Good morning, good afternoon and good evening! Thank you for coming to check in on me and my progress for the semi-final week at the Northcoders Bootcamp, and what can I say besides thank the lords that it's the weekends!

Before I dive into what I've been up to this week, be sure to follow me on Linkedin, Twitter and Dev.to to keep up-to-date with my journey both here at Northcoders and beyond as a Software Engineer!

Before going straight into a list of topics of what happened this week. I would like to introduce the lovely members of Team G3O that have embarked on the journey of the final Northcoders Project with me:

So, this week we finally got stuck into the nitty gritty of coding our final Northcoders project. I won't go into too much detail until next week to avoid giving it away, but here's a list of topics that I'd like to cover in this week's blog post:

The importance of "Spiking" technology
Learning to trust the team
Enjoying the process
Importance of documentation & navigating documentation
What is TypeScript and why you should learn it

The importance of "Spiking" technology

Last week I briefly covered the concept of "Spiking" technology and what it entails. If you would like to read more on that then please click on [this link] to find out more(https://bit.ly/3ErsmO9) . However, if you would like a simple explanation of what this means, then spiking technology includes exploring new technology to see how easy or difficult it is to setup and use, and exploring how fit for purpose it is.

Spiking is an incredibly significant part of the SDLC (Software Development Life Cycle) because changing technologies in the middle of an on-going project can throw spanners in the works and cause more headaches than necessary.

Our team had multiple incidents with the technologies that we were using throughout this week that ranged from not being able to even run an emulator to view the changes happening to the code, and much more - and so in essence, when you are planning out what technologies that you and your team are going to use in the future, ensure that your entire team are able to get the tools working before you explore if the technology itself is at a conceptual level, worth it for your project.

Learning to trust the team

During the Northcoders Bootcamp, the extent that you work with others are limited to pair programming with different members of the cohort. Therefore, besides pair programming we had little exposure to what it was like working in a group atmosphere on a single project. To add to this uncertainty of working with people on a single project, we had been speaking the prior 6-weeks on the back-end and front-end projects working solely on our projects, and so it was easy to only trust in myself during that time.

I won't sugarcoat it and say that I was anxious going into the final project phase because I hadn't worked with Jon, Cookie and Nikita before in pair programming, and it was a huge question mark in general going into the final project phase. However, as soon as the first day of actually coding our final project this week, I had learned the importance of trusting your team and letting myself gradually open up and trust everyone.

Whenever I, myself and the others needed help from each other, we would jump straight into the same Discord channel and start trying to figure out why things weren't working. Sure, sometimes we weren't able to find a solution immediately when we jumped in to try and fix things, but having another fresh pair of eyes and brains does wonders!

Personally for me and Cookie that have been consumed with working like cavemen on the back-end, which is an in-joke because going into the Front-End portion of the final project was like cavemen who have been living in the caves for years and finally seeing how much humanity has evolved 😂 We would feel lost in what was going on because of this and I'm sure that Ellie, Jon, Nikita, and Antony had also felt the same because they were in the dark working on the front-end portion of the project.

But everytime that we had our daily morning standups (9AM on Discord) and afternoon standups (1:30 PM), I would be blown away at how much everyone has progressed on with their work, and it was just always a pleasure to see everyone's progress and share group therapy sessions when all of our code wasn't working the way we wanted it at all 😂

Enjoying the process

Perhaps backtracking a little back to last week's blog post, but I'm glad that my team was truly onboard with the idea that we decided to go with because the two other project ideas were too reliant on generating documentation more than it was coding, and didn't have the "enjoyful factor that we would want.

The most important part of the final project phase I believe is stepping out of your comfort zone and exploring new technologies within reason and really enjoying the process itself. For our group, we judged that our current project is challenging and fun to create - as opposed to spending over 2-3 weeks on a project that none of us are enthusiastic about.

Therefore, if you are a current Northcoder fast approaching the final project phase, then I really do implore you to explore new technologies and enjoy the process!

Importance of Documentation & Navigating Documentation

So you've heard it time and time again, documentation, documentation, documentation... I will be honest with you, before starting the Northcoders course and even a few weeks into the Fundamentals Phase of the course, I was always quick to close the documentation because it was so confusing and demotivating because I didn't understand what was being written.

However, the importance of documentation cannot be emphasised that much more during the final project phase, or when you're deciding to explore new technologies! For our group that were using a variety of different and new technologies, the only option was to navigate the documentaiton to gain an understanding of what we are actually trying to use.

But, what I have personally learnt about documentation is that building tolerance to not automatically alt + f4 and close the documentation is the first step. The second step would be to read the little summary blurb on most documentation that is there to explicitly tell you what that technology does, and during this step really think about what you're trying to achieve and if this technology will help you achieve what you want. The third step would be to view the "features" of that technology to further explore if this is something that will enable you to build things the way you want. The fourth step would be to view existing examples of that technology and to really read the code to understand what is going on. Lastly would be to just start using it. Sure, you can view endless video tutorials, however the best way to internalise anything is to learn by doing, so get your hands dirty with the new technology!

What is TypeScript and why you should learn it

With the absence of technical jargon you may have noticed that I don't want to spoil what our team have been using and working on, but I would just like to introduce what "TypeScript" is and why I think you should learn it.

TypeScript is a strongly typed programming language that is called a "Superset" of JavaScript. This means that you are able to specify a function's paremeters and its return value's type to be a certain type, and how it looks.

You might be asking? What is this, and why is it important? - Adding types to your functions and variables is what is called "Static Typing", and is especially important because it allows you to see ahead of time any errors where you may have assigned an incorrect data type to a certain variable.

But, this is not the only great thing about TypeScript. Another great thing about TypeScript is that unlike JavaScript that provides you the errors only after you have run the code, TypeScript will flag the errors before compilation, and this saved our team a significant portion of time during development especially since we were working with numerous packages and quite often, we wouldn't know what code someone else has written and so having the static type definitions of what data is what and what type, essentially was really useful for self-documentation.

I personally can confidently say that we wouldn't have been able to make this much progress as a team without of course working properly as a functioning team that gets along well, but without TypeScript we would be wasting a lot of time with inputting the wrong data types and a lot more!

Thoughts Going Forward

I am honestly really proud of not just myself, but my entire team pulling together and really giving it our all on this final project. Instead of feeling dejected about not getting a piece of code working for 1-2 days, we would each wallow in each other's sorrows and have a good laugh, it's honestly a great team atmosphere! I simply can't believe that next week will be my final week at the Northcoders Bootcamp, and I am both nervous and really looking forward to what happens above and beyond Northcoders!

But for now, I'm going to enjoy my time away from looking at code this weekend and enjoy the new Pokemon Scarlett and Violet that came out today!

As always, if you have made it this far thank you for the continued support and I hope to see you all again this time next week when the coding of our final project should be finished!

Socials

Feel free to give me a follow on any of my socials down below!

The Rising Coder - Week 11/13 (Project Week 1/3)

Christopher Lam — Fri, 11 Nov 2022 23:16:54 +0000

Good morning, good afternoon and as always good evening, it's that time of the week again for another instalment of The Rising Coder!

Thank you for coming to check out my blog again this week and I hope you can find this week's blog useful for going into Week 1/3 of the final Project Phase of the Northcoders Bootcamp.

But before that, be sure to follow me on Linkedin, Twitter and Dev.to to keep up-to-date with my journey both here at Northcoders and beyond as a Software Engineer!

So diving straight into the big unknown that is otherwise known as the Northcoder's Project Phase because it is heavily shrouded in mystery, but I hope that with this week's blog entry that I can demystify these mysteries so that you, the future Northcoders can confidently enter the Project Phase with confidence!

For those of you who are wondering what I've been up to this week, I've broken down everything into its own sections below:

Careers Day - CV Writing Workshop with Keely Madgin
Careers Day - Aceing Your Tech Test with Jim Stevenson
Careers Day - Industry Insights with Mal Browne
Careers Day - Presenting Yourself with Kathy Brooke
Careers Day - Preparing For Interviews with Darren Holland
Previous Technical Recruiter Tips & Tricks with Michael Whittam
Introduction to the Project Phase
Project Phase - Concept of Spiking
Agile Standups (Meetings)

Careers Day - CV Writing Workshop w/ Keely Madgin

To start off this week, we had the long-awaited "Careers Day", which is an entire day from 9-to-5 dedicated to ensuring that we create a polished CV that's ready to be sent to future employers.

In order to gain access to Northcoders' personally curated job board, you will need to first create a CV that the Careers Team at Northcoders are happy with to send, but don't worry as you're assigned a personal careers advisor earlier on!

I won't get into complete specifics of the structure of a CV as there are an insurmountable amount of information regarding this, but will instead write a few summary points to think about when it comes to writing your CV:

Things To Consider:

Why did you want to become a Software Developer in the first place?
Why did you come to Northcoders? (Remember joining the course and perservering is already an amazing feat within itself and speaks volumes for itself, so really think about it!)
What were you doing before?
What makes YOU unique?
What transferrable skills do you have that would help you FIT what a company is looking for?

Things To Avoid:

Avoid clichés that are often thrown around such as "I am a hardworking person...", as that is the fastest way for a Hiring Manager or Recruiter to ignore your CV!
Rambling on - If you write too much on your CV then you'd: run out of things to talk about, show that you can't be succinct and to the point.
Listing skills in a table - Many templates will have some sort of tables and whilst this looks great, the reality is that recruiters/hiring managers process it through some piece of software. Therefore, to ensure your CV has the highest probability of being actually looked at, consider not writing details in a table!
Giving yourself a subjective "rating" - This is a common cliché in CVs where you subjectively "rate" your own skills for example in React. AVOID THIS AT ALL COSTS - before you even have an interview, you have already planted a seed at the back of the interviewer's head and that's what we want to avoid!

Careers Day - Aceing Tech Tests w/ Jim Stevenson

Perhaps one of the most things that I'm personally nervous about besides behavioural interviews are the infamous "Technical Tests" or "Tech Tests" that are integral to landing your first position as a Software Engineer.

However, Jim's fantastic advice that focused on the single concept of: "Communicate, communicate, and finally communicate!" was at the forefront of his presentation, and made it significantly easier to follow his advice with complete confidence.

Whether you are thinking about "How do I break this problem down?" to the actual process of "Okay this is how I will break this problem down", make sure that you're talking aloud and communicating your thoughts honestly.

If you don't know something remember that is completely FINE and DO NOT be afraid to admit this and ask for help or if you're able to have a quick Google Search on the official documentation because this is what you would be doing on the job anyway!

With those precursors out of the way, the types of tech tests and advice that Jim provided are as follows:

On-Site Test

Duration: Short
Nature Of Test: Focused on seeing how you break down problems and communicate it in real-time with future team members.
Common Style: Whiteboard & Pseudo Code - Focused more on writing down how you would proceed with breaking down the problem and writing pseudo code.

Take-Home Test

Duration: 6-8 Hours
Nature Of Test: Focused on seeing how you break down problems, how you structure your code, how clean your code is, and seeing how much you can do in a set time frame.
Top Tip: Give yourself a strict time limit to do what the test asks for within those time restrictions. It demonstrates accurately what you can do with that time limit and you can adhere to time restrictions.
Bonus Tip: If you did not manage to complete the test on-time, don't be afraid to write pseudo code to show what you were thinking of implementing if given enough time.
MUST: Whenever you've finished a take-home test. Make sure to write a complete README detailing what you have done!

Careers Day - Industry Insights w/ Mal Browne

Mal's presentation on the industry insights provided a valuable sneak preview of the types of developer teams there are available and what we can realistically expect upon graduation.

Types Of Developer Teams

The three distinct types of developer teams that you can expect to work for are:

In-House - This is where you work as part of a company's internal In-House Software Engineer team to build the core products/services of the company.
Agency - You work for an agency that provides Software Development expertise to their clients and assist these clients with building technology.
Consultancy - Similar to working in an agency, you will be responsible often for both providing Software Development expertise with coding AND professional insights and advice to clients.

Getting Hired As A Junior Developer

A few of the points that Mal pointed out that can help you get your first job as a Software Developer are:

Attend as many events such as networking events and hackathons
Even after the bootcamp ends, make sure you keep coding regularly to keep in form!
Consider contributing to Open Source projects on GitHub
Keep up-to-date with industry news & developments
Setup a professional LinkedIn profile

Careers Day - Presenting Yourself w/ Kathy Brooke

The significant amount of value that this presentation was able to deliver was invaluable to me personally because I had struggled often with self-presentation especially with behavioural interviews.

With Kathy's presentation on "Presenting Yourself", we covered:

The importance of confidence
Separation of "Personal" and "Professional" values
Breathwork - how and its importance
Jaw Movement
Personal Takeaway: Orbiting

Importance of Confidence

The definition of self-confidence is a state of being clear-headed that your chosen course of action is correct. For us Northcoders Graduates going into our first position as Junior Software Engineers, this means having complete conviction in our own values and the direction that we want to take ourselves.

Separation of "Personal" and "Professional" Values

Perhaps one of the most intriguing concepts that Kathy taught us was the introduction of "Personal" and "Profesional" values and separating them both.

Personal Values are unyielding values that you have when interacting day-to-day outside of work. For example, mine are: Respect, Honesty, Loyalty, Friendship and Love.

Whilst Professional Values are values that you expect yourself to unyieldingly adhere to in the workplace. For example, mine are:** Kindness, Trustworthiness, Challenge, Honesty, Recognition and Learning**. So this would translate to being able to work with people that I can trust my back to, and recognising each other's achievements and pushing each other to learn and achieve more!

But the most integral part of this was being told that instead of wearing our personal values into interviews, we should wear our professional values instead. This is because when we hold our personal values in an interview and feel rejected, then the ego would take a hit and come full circle in destroying our self-confidence.

As someone who as mentioned prior, struggled with this first-hand it made a world's difference. Instead of feeling that a company rejected me on a personal level based on my personal values, I can have my Professional Values "armour" tank the hit and keep moving forward, because it's for both party's interests to go separate ways if their values are the complete opposite.

Breathwork

When we become nervous we tend to make immediate gasps and exhales of air which leads to irregular breathing patterns. Therefore, Kathy had taught us the importance of regularly practicing inhalation/exhalation exercises so that it becomes natural during high-pressure situations.

Personal Takeaway: Orbiting

One of the key takeaways from Kathy's presentation was the idea that I'd call "Orbiting." This is the idea that reminds you that you are there to solve the company's problem. Everything that you say about yourself should always orbit back towards solving a company's problem. If you are able to check all of their boxes with confidence, then you're well on your way forward!

Careers Day - Preparing For Interviews w/ Darren Holland

The key points from Darren's presentation were the following:

Understand and be able to explain what a company does in a single sentence.
Research the company's mission, vision and values. What professional values align?
Understand the organisation's history
Fully understand the company's USP (Unique Selling Proposition)
Understanding what makes you a valuable hire: Your successes and things you're proud of, the times that you stepped up as a leader or team member, as well as learning from failures.

A core point that Darren and the Careers Team have emphasised throughout was the importance of not just "assimilating" and pretending a company's values as your own, but really having matching values, and to communicate your entire thought process - and then whether or not your values, communication style and personality match up is nothing you can control!

Previous Technical Recruiter Linkedin Tips w/ Michael Whittam

On Thursday, fellow cohort member Michael Whittam who had previously worked as a technical recruiter shared a few useful tips for users that have never used LinkedIn before.

He had shared with us that in LinkedIn, you are able to refine your "Job Alerts" to only show certain jobs with specific keywords, and to filter for jobs that are posted most recently.

For example in the LinkedIn job alerts, you can have the following settings:
("junior" OR "graduate") AND ("software engineer" OR "software developer" OR "back end" OR "front end" OR "javascript" OR "react") NOT ("mid level" OR "senior level" OR "lead")

By refining your criteria, you will be able to have access to daily notifications for the latest jobs without receiving the "mid-level/senior-level" positions that aren't useful to us Junior-level developers!

Introduction to the Project Phase

Now for perhaps what you've come for, the actual introduction to the project phase! The Project Phase at Northcoders spans over 3-weeks and is broken down into the following:

Week 1 - Careers Day, Introduction to Projects, Software Development Lifecycle, Communications Workshop and Project Pitches
Week 2 - Building the project with Agile Methodologies (Scrum, Kanban, TDD, Pair Programming)
Week 3 - Presentation Week

This week we first focused on the "Software Development Lifecycle" which are the steps that you need to take when building software. Although there are extensive resources available online and so I will just provide a brief bullet-point list:

Feasability - How feasible is the idea in terms of: time, resources-cost, operational cost?
Requirement Analysis - What exactly is needed to build the MVP?
Design - How exactly are you going to break down the project into smaller parts? (E.g. Components tree)
Coding - The actual process of coding the project with best industry practices.
Testing - Writing appropriate unit tests for self-documentation of working production code.
Implementation - Putting the actual project plan into action
Maintenance - How is the project going to be maintained? (We do not need to worry about this at this stage!)

After understanding this approach you are split into groups of 4-6 people (Including yourself) and come together to develop 3 projects that you would be pitching on a Thursday Afternoon in front of your seminar group.

During the actual presentation in front of your seminar group (Not to be confused with the cohort group which is the entire cohort for the month, e.g. August/October Cohorts) in the order of the group numbers. Each group will present their first project idea and then swap to the next group. Each rotating with the mentors' feedback to ensure that each team has enough time dedicated to receiving useful feedback to improve upon.

Project Phase - Concept of Spiking

Spiking refers to a term in Software Development where you research the feasability and actual usefulness of technologies that you may have not used before for your project(s). During our time at Northcoders, we have learnt: JavaScript, React, Express and PostgreSQL as our tech-stack. Therefore, we are encouraged to explore new technologies, and so the "spiking" of technologies to check their viability is important.

Although throughout this week the concept of "Spiking" was vague - myself and the group I am working with understood that the scale of spiking is more on a spectrum that included thinking about:

How easy/difficult is it for installation and ease of use across the entire team? Will we spend more time configuring individual setups rather than actually writing production code?
Will this piece of technology be too difficlt to learn as a collective group for the 1-week timeframe? - The worse thing that you can do is have a single expert in an entirely new language like Go-lang and burden one member with it all.
Is this challenging us? - On the opposite spectrum of being too difficult, are you really challenging yourselves and learning something new?

Our group admittedly had a single idea that we had thought was the "Golden Egg", but after receiving feedback from the mentors on our pitches, had come to a single idea that has had its tech-stack refined and user stories drilled down properly - the only thing now is to start writing code!

Project Phase - Agile Standups (Meetings)

This last section on the project phase besides spiking, planning as a team your projects (Which is unique to each team hence I did not write a separate topic on this), are the "Agile Standup Meetings." This is simply a meeting that is held every morning (or whenever is most convenient for your team) that aims to answers the three main questions of:
1) What did you do yesterday?
2) What are you going to do today?
3) Are there any blockers preventing you from progressing with your work today?

Just answering these three questions will allow the team to come together and work on removing the blockers so that everyone can start working right away.

Here are a few best practices for an effective Agile Scrum Meeting on the daily:

Make sure that only one person is speaking at a time, and that you're only answering the three main questions.
Make sure that you're swapping which person leads the scrum meetings every morning.
Make sure that you don't have any distractions.
Make sure that you are present in the moment.

Thoughts Going Forward

Honestly, I came into the first project phase week feeling overwhelmed because of the sheer amount of planning and actual honing of multiple project plans. Whether this was the tech-stack or creating user stories to deciding on features. But, I'm really glad that myself and my group have finalised the tech stack, decided on a solid idea and are ready to get the ball rolling!

For now I'll be brushing up on the tech stack we'll be using next week and hopefully catching up on some missed sleep!!!

As always, if you have made it this far thank you for the continued support and I hope to see you all again this time next week when the coding of our final project should be finished!

Socials

Feel free to give me a follow on any of my socials down below!

The Rising Coder - Week 10/13 (Frontend Week 3/3)

Christopher Lam — Fri, 04 Nov 2022 23:38:49 +0000

Good morning, good afternoon or perhaps good evening, it is that time of the week again - another update of The Rising Coder!

As always thank you for coming to check up on me and my journey at the Northcoders Bootcamp and without any further delay, let's get straight onto the topic of what exactly did happen this week?

Week 10 marks the final week of the Front-End section of the Northcoders Bootcamp, and boy has it been an absolute beast of a journey. From the start of the bootcamp where we were struggling to write a simple For-Loop and trying to get our heads around Higher Order Function Array Methods such as map and filter, to using them as if they were second nature.

Even the start of the Front-End block where I remember having mentioned that just thinking about the word "State" just left me in a right state in the first week... But now, I've got a firm understanding of what it is and why we would use State in React.

It all came full-circle and everything that we learnt in order from the start-to-end of this bootcamp have been carefully crafted by Northcoders to ensure that we know everything we need to get our hands dirty in our first Junior roles as developers!

Enough of that... What did you do this week?

As this is our final week working on the Front-End side of development, we were now able to finally start building our own Front-End websites that would consume the Back-End API that we had created during the Back-End project phase during Week 7/13 of the course, and really making this project our own prized possession that we would be sharing with future employers.

Even before going into the actual Front-End project itself, I wanted to try add a bit of spice to my projects by first creating documentation on the root directory of my Back-End API that would detail all of the possible API endpoints and responses that the user would receive, as well as challenging myself to learn a new framework called Tailwind CSS.

And I can say that I definitely do not regret my choice of learning Tailwind CSS. For someone that does not have the best understanding of CSS styling, it was a lifesaver. If you are unfamiliar with what Tailwind CSS is a "utility-first css framework" - in short this means that it comes with pre-bundled CSS classes that you just use to style your code.

But, the beautiful thing about Tailwind CSS is that you never have to leave your code editor to make separate CSS files and link them up with your React Components. This is because all of the styling is done by putting the Tailwind CSS properties in the className of the JSX elements, and then it's up to you how you start building up your components!

Before I go on to talk about my reflections of this entire week and the final Front-End project, here is a link to my live project: Christopher Lam's Northcoders News

Reflection #1 - Take It Slow

Over the course of this week where I'd been working through my project, one of the most important things I had to constantly remind myself that it's absolutely fine to take it slow and at my own pace. It's really tempting to think about what others on your cohort are doing and "how far ahead they are", but at the end of the day, their progress is your own and yours is yours.

I'd admit that I had a lapse of confidence when I couldn't resist the urge to check on how others were doing and feeling that I felt "behind" and felt that physical discomfort that came with stressing myself out.

So TLDR: take a breather, don't look at the others around you and their progress, focus on yourself!

Reflection #2 - Official Documentation's Your Best Friend

Although this is pretty self-explanatory that the people who created React and other libraries built around a certain framework or programing language know what's best, it's really easy to forget this fact! I myself am guilty of trying to Google StackOverflow answers without properly consulting the official documentation first and that's come back to bite me (more on that later)!

Reflection #3 - Regular Breaks Are A God-Send

For those of you that are able to sit at the screen for hours on end without a single break, perhaps this may or may not apply to you but, taking regular breaks and going on a quick walk around the block can really help you both get some vitamin-D, but more. importantly unblock your mind!

The number of times throughout this week and bootcamp in general, where I've been able to just take a break and then come back with that "EUREKA!" moment have been countless, so TLDR is to put that laptop/pc away and treat yourself to some fresh air and vitamin-D!

Reflection #4 - Enjoy Yourself

If you've been in academia for years and had it conditioned in you that every assignment that you're given must cause you stress and is absolutely unenjoyable, then this is what you learn to essentially un-learn here at the Northcoders Bootcamp.

Instead of fighting the Back-end and Front-End projects as if they were your enemies that just cause you unnecessary stress, instead try think of it through the other end.

If you truly enjoy working on your projects then your entire outlook on how you approach your projects and how you feel about your projects will change entirely!

For example, imagine if the projects only caused you stress and you had to try explain your projects to future employers, it'd be difficult to properly convey your excitement over working on the project at all if you only viewed the project negatively. Compare this to if you really enjoyed working on the project and how more clear-cut this would come across to future employers.

So TLDR is really try to challenge your outlook on how you perceive the Back-End and Front-End projects so that you do your future self a favour!

Mini Surprise

Before I close up this relatively shorter blog entry for this week, for those of you who have stuck around to the end, if you interact with my blogs on LinkedIn, go ahead and drop in the comments: What your most memorable moment of the Northcoders experience was, and why?

For what I enjoyed about the Northcoders Experience was being able to meet such an amazing group of people be it all of the mentors or my fellow cohort members that I've had the pleasure of meeting.

And for the most memorable moment, it would have to be what happened today...

If you were in the final Zoom call with Jim - then you would have heard him talk about "Do not use an array's index number as a key." So if you're still reading then yes, that was me 😂

So before I show you the code that was causing us headaches, I'll just explain what happened. In my piece of code I had a CommentsDisplay component that would map over an array of comments and in React, you need to pass in a "key" into a List Item when mapping over it in React, this is so that React knows what to look for.

However, me being the absolute pillock I am, caused an absolute nightmare! So when I was implementing a "Post Comment" and "Delete Comment" feature in my project, I was able to delete the comments perfectly fine, but posting a comment would temporarily bring back previously deleted comments.

I then put in a desparate NC Help request to which Scarlett (One of the brilliant mentors) tried to step in and save the day... Except we both fell flat on the floor and had to get saved by Jim... except Jim was also completely baffled and had to take a bit of time away from the screen to try process what an absolute mess I had made 😂

So without further ado here was the small piece of code that caused the issue:

{comments.map(({ comment_id, author, body, article_id, votes, created_at }, index //<-- THIS) => { 
            const convertedCreationDate = created_at.slice(0, 10)
            return (
                <li key={index} > //<--- AND THIS - THESE TWO LINES OF CODE
                    <CommentCard removeComment={removeComment} comment_id={comment_id} author={ author } body={ body } article_id={ article_id } votes={ votes } created_at={ convertedCreationDate }  />
                </li>
            )
        })}

It really was just this, but it wasn't exactly so clear-cut even when three people including myself were staring at the code in complete bewilderness. Earlier on I had hinted towards this when I said something about always reading official documentation in which this article of documentation by React says: We don’t recommend using indexes for keys if the order of items may change. - And thus again highlights the fact that documentation is absolutely essential as a developer, I'm really sorry for causing a headache Scarlett and Jim, but I'm glad that I got to see a giddy side of Jim that I hadn't seen in the lectures as he was ecstatic and over the moon when he solved the problem - brilliant stuff Jim you lifesaver! 😭

Thoughts Going Forward

And with that less-informative and more personal blog post will come the end of Week 10 and the Front-End block of the bootcamp. Going forward will be the next three-weeks that are focused on the project phase and developing our CVs and preparing for future tech tests, which I am extremely nervous about but excited at the same time.

But for now, I'm just going to enjoy my weekend and watch the League of Legends Championship Finals tomorrow evening and hopefully see you all this time again next week, and as always thank you for reading!

Socials

Feel free to give me a follow on any of my socials down below!

The Rising Coder - Week 9/13 (Frontend Week 2/3)

Christopher Lam — Fri, 28 Oct 2022 18:16:46 +0000

Good morning, good afternoon or good evening and thank you for once again coming back to check on in The Rising Coder blog, I really do appreciate it!

Last week may have been perhaps an over reaction (puns intended) as this week after a coming back with a fresh perspective and mind, we dove more into solidifying our knowledge of React Hooks and State management!

But before I dive straight into what I have been up to this week on the Northcoders Bootcamp - I would like to say a huge thank you to Christian Dutton and Mitchell Wyatt who were respectively our seminar lead and mentors for Seminar Group 1!

For Christian, it is his first time leading a seminar group and he has been the most supportive and personable person for the job and he has done amazing work! Similarly, Mitch who had joined during the Backend portion of the course has done a brilliant job fitting right in and always keeping us all in good spirits whenever we were down.

I wish the best for the both of you in your next cohort group that you will be mentoring, and I'm sure you will both do absolutely smashingly!

Last week over-reaction? How did I React this week?

In order to summarise this week, I would say that I reacted pretty positively to the content that was covered. Perhaps I was over-reacting last week due to fatigue, who will ever know!

However, needless to say that this week I believe that I've soaked up all of the information that was taught like a sponge, and so before I proceed with details pertaining to what we had learned this week, feel free to check out a few of the projects I had worked on this week:

https://github.com/clam119/Pokedex-Stat-Checker - A vanilla Pokémon themed project that displays the stats of the Pokémon provided and built using React, Chart.js and Tailwind CSS. Completed with the help of the charasmatic Keita Darby.
https://github.com/clam119/Northcoders-Marketplace/ - A Front-End website that interacts with a Northcoders Marketplace API provided by Northcoders.

Topics Covered

Fundamentals of the React Hook: useEffect and the dependency array
Fetching Data in React with native Fetch & Axios
React's Loading Pattern
Introduction to React Router - Links & Routes
Introduction to the concept of Optimistic Rendering

React Hook: `useEffect()`

The first topic that we learned this week was a new React Hook called the useEffect hook. This hook allows us to render a piece of information a finite amount of times depending on the "dependency array" that is inside the useEffect call.

The useEffect hook takes in two arguments:
1) The effect that it will want to run
2) The dependency array - An array of variables that the useEffect will depend on.

With this hook, it will only run the function passed in when it detects a change within the variables in the dependency array. If it is not passed in any variables to detect for change, then it will only run a single time.

Let's say that you load up a new "Account" page that depends entirely on the "username" value to fetch the data pertaining to that specific user. IN this case, you would want to run the useEffect hook to fetch that data everytime the "username" changes.

An example of this is in my previous "Northcoders-Marketplace" project that is listed above, where I have a list of users that the user could login to and change the "Username" state.

As the dependency array is looking for any changes in the "username" state, it will run the useEffect again to fetch information for that user:

 useEffect(() => {
        setIsLoading(true);
        API.fetchAllItems()
        .then((itemsData) => {
            setItems(itemsData);
            setIsLoading(false);
        });
    }, [username])

The useEffect hook is a significantly powerful tool in the right hands, but remember to always think about the context of which you are using this hook. During the near-end part of building up the Marketplace project, the useEffect's dependency array had caused me a few headaches because I didn't take into account that the useEffect would run anytime any of the variables changed!

Fetching Data with Fetch & Axios

For the first two-days that myself and my partner were building up the Pokédex Stat Checker - we were exposed to two different methods of fetching data.

The first of which was the native Fetch method that is available on all browsers. This method simply revolves around passing in a valid API endpoint to fetch information from. Once the data has been fetched as an unresolved promise, you would need to parse it through as a JSON object, and then get access to the information.

An example of the native Fetch method would look something like this:

useEffect(() => {
        setIsLoading(true);
        if(userInput.length > 1) {
            fetch(`https://pokeapi.co/api/v2/pokemon/${userInput}/`)
            .then((response) => response.json())
            .then(({id, name, sprites:{other}, species, stats}) => {
                setIsLoading(false);
                const returnedPokemon = {
                    id, 
                    name,
                    other,
                    species,
                    stats
                }
                return setRequestedPokemon(returnedPokemon)
            })
        }
    }, [setIsLoading, userInput, setRequestedPokemon])

Although visibly there's a lot going on - simply what this is doing is making a new Fetch call to the PokéAPI everytime that the value of setIsLoading, userInput and setRequestedPokemon state functions are changed.

Once the data has been successfully fetched from the API, it is then going to set the requestedPokemon state with the returned Pokemon variable.

The second method of the Axios library makes our lives a bit easier because it provides us the information without having to use Response.JSON() to convert it into a JSON object for us to use, and also provides us more information on the Error Codes that we will need in order to handle any errors that come back from the database.

Axios requires a bit more setup but here is an example taken from my codebase:

import axios from 'axios;

const marketplaceApi = axios.create({
  baseURL: "https:/marketplaceapi.herokuapp.com/api/"
})

export const fetchAllItems = () => {
  return marketplaceApi.get('/items');
  .then((response) => {
    return respone.data
  })
 }

As Axios is a package we would need to run npm install axios and then following standard ES6 syntax, import the package where we would need to use it.

The first thing we do after importing is create a "baseURL" variable by first declaring a variable called marketplaceApi and using the axios.create() method, which just involves creating an object with the baseURL property key and the API of choice's link as the value.

The next thing to do is create functions that returns the marketApi with a HTTP method such as GET. Once it has resolved as it is a promise, we get access to the data on a key of data - in which afterwards we are able to use the information as we choose!

React and the `isLoading` pattern

You may have seen in the previous code snippets on this blog where we've set state for a state called setIsLoading() - so, what does this actually mean and why do we do it?

The isLoading pattern in react is a way for us to display to users a "Loading" screen whilst the data that is being requested by the user is being fetched from an external API.

 useEffect(() => {
        setIsLoading(true);
        API.fetchAllItems()
        .then((itemsData) => {
            setItems(itemsData);
            setIsLoading(false);
        });
    }, [username])

  isLoading ? 
    <h1> Currently Loading Items </h1> :
    <ul className="items-list">
      {items.map(({ item_id, item_name, description }) => {
        return <li key={item_id} <p>{item_name} {description}</p> </li>
      })
    </ul>

This exact same code snippet from earlier is a useEffect that only re-renders whenever the username state changes in the application. When it does, it will the the isLoading state variable to true, in which case it would a basic loading screen.

Once it has finished loading up the data that was being fetched from the external API, it will then set the loading state variable to false and then display the information that was fetched.

React Router - BrowserRouter, Routes, Route, Link

As React is a SPA (Single Page Application), it means that instead of hard reloading the website like traditional websites do, we instead focus on re-rendering components based on state changes.

This does not mean however that we are unable to create different routes that visually display to users in the address bar that we're in another "section" of the website.

For example, even without context you can most likely infer that the following link is a page related to resetting your password: https://fakesite.co.uk/account/forgotten-password

With the use of an external library called React Router DOM, we are able to mimic a traditional website and provide meaningful URL endpoints to ensure that users aren't confused about which section of the React website they are on.

React Router Setup

import { BrowserRouter, Routes, Route } from 'react-router-dom';

const App = () => {
  return (
    <BrowserRouter>
      <div className="App">
        <h1>My App </h1>
        <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/topics" element={<Topics />} />
          <Route path="/about" element={<About />} />
        </Routes>
      </div>
    </BrowserRouter>
  );
};

// src/components/Home
const Home = () => (
  <div>
    <h2>Home</h2>
  </div>
);

In order to do this, we will need to import BrowserRouter, Routes, Route, and Link from the react-router-dom library after downloading it.

After that, we wrap the entire "App" in App.js with the BrowserRouter function so that it will have global access to the React Router's methods.

The next part is to decide which elements on your page if clicked will go to which path. For example here, the Home component if pressed will take the user to the root path of /, whilst conversely if the user clicks on the Topics or About component then they will be respectively sent to those paths.

React Router's Links

If you have learnt a bit about HTML and the <a> anchor tag that is home to a button that if pressed will redirect the user to another location.

This is React Router's way of essentially redirecting the user to a certain part of the website if they click on a link.

For example:

<nav>
  <Link to="/"> Home </Link>
  <Link to="/services"> Services </Link>
  <Link to="/about"> About </Link>
</nav>

Here if the user clicks on any of these links then they will be redirected to the relevant endpoint that is specified after the "Link to".

Introduction to Optimistic Rendering

The final lecture of the week was on a concept that is called "Optimistic Rendering". This concept is essentually thinking mostly about the user experience. Optimistic Rendering by definition is rendering UI changes without confirmation of success from the backend based on the assumption that the request will succeed.

An example of this would be having Reddit's Upvote & Downvote buttons. With optimistic rendering, we are able to render a UI change of the votes on a comment being up/downvoted without confirmation from the server. This is because if we think about it from the user's perspective, an upvote/downvote is not an important feature that will impact them, but because there's no optimistic rendering, they would have to wait a couple of miliseconds/seconds to have confirmation that their upvote/downvote went through.

However, this does not mean that we would want to always optimistically render. When we want to consider the possibility of an optimistic render, we need to ask ourselves how important is it that the user receives confirmation on an action they do on the website.

For example, if you wrote a hurtful comment on Reddit and want to delete it from Reddit, you wouldn't want to optimistically render and automatically assume that the message was deleted. Because chances are that if you receivee an instant feedback that it was deleted but in reality an error occurred on the server side, then that comment you thought you had deleted remains there.

Or perhaps you're shopping on Amazon and because of optimistic rendering, the website says that the transaction was succesful and has pulled money from your bank account - even though there was a server-side error processing the transaction.

As you can see the context of deciding when we would optimistically render changes without confirmation are heavily dependent on the context!

Thoughts Going Forward

With that final short introduction to optimistic rendering, this brings us to the end of yet another blog post and here comes the final frontend project phase! It's been a rollercoaster from the beginning of the Front End section but I believe that my confidence and overall likeability towards the Front End side of development has started to pop its head out.

Mostly because going from the Backend portion of the course where we had a lot of structure in terms of our learning to being left to our own devices. However, the section of the course where we were encouraged to plan everything from start-to-finish and create a template for ourselves to work with helped me regain the once lost structure and it became a lot more enjoyable from there!

With that, thank you as always for reading to the very end and I hope that you all have hopefully learned something new or strengthened some topics that you may have been weak on prior to reading this, and I will see you again after the final Front End project phase!

Socials

Feel free to give me a follow on any of my socials down below!

The Rising Coder - Week 8/13 (Frontend Week 1/3)

Christopher Lam — Fri, 21 Oct 2022 19:55:25 +0000

Good morning, good afternoon or perhaps good evening and thank you as always for sticking around to read this week's instalment in The Rising Coder. The end of this week 8 marks both the end of the first week in the Northcoders Bootcamp and the 2-month milestone!

It's been a really fun journey with my fellow friends in the cohort and the amazing mentors who have been with us since the start. This week has been especially taxing and even had me doubting my own capabilities, so I would like to just re-iterate a few words to my fellow friends in my cohort and potential future bootcampers, and that is you're all doing amazing.

It takes a lot of grit, determination and dedication to finally get to where you are today. Cast yourself back to the introduction week where you're still learning how to write functions. Or perhaps the Fundamentals Block which had you really think about how Higher Order Function Array Methods such as .map() and .filter() worked under the hood, and look at how naturally you've integrated it in your everyday code? Or heck, even just last week when we've learnt about the Backend and even created our own APIs and hosted it on the internet for everyone to see?

You're all doing a great job and we can make it through the next few weeks into our project phase & graduating, you've got this!

My small pep talk aside, this week I will be diving straight into what we have been up to in our first week of the Front End portion of the Northcoders Bootcamp. But, before that if you enjoy my weekly blogs, feel free to drop me a follow on Twitter, LinkedIn and GitHub!

Deep Dive - What Did We Cover This Week?

I'm not sure how I can express how I completely feel about whether I prefer Backend or Frontend Development. (Points if you recognised that pun ).

This week we covered the following topics of:

Introduction to the DOM (Document Object Model), Accessing Elements + DOM Manipulation
Semantic HTML, Accessibility
Introduction to React, JSX, Functional Components, Props
Introduction to React Hooks and "State"

However, before diving straight into this week's content, I'd like to just give a few thoughts about how this week went in general.

When we had finished the Backend project and started our first week in Frontend Development, we would be told that this is around the time that people will often see which type of development that they prefer.

For the Frontend Development side of the course, we are given complete autonomy for the small-scale applications that we create from start-to-finish as long as we're learning and applying the concepts that were taught during the lecture.

For the more CSS & visually artistic developers on the course, I believe that this will be the place that you honestly thrive because you will be able to exercise your visually artistic creative side without any restrictions.

However, this comes at a cost of a "structure" per-se. I can say that I prefer Backend Development because of the rigid structure that we have and how I'm able to instantly receive feedback on whether or not an API's endpoint is working or not and is giving me back information I wanted, without having to worry about any of the styling and CSS that comes with it!

But again, that's just my 2-cents and although it's my first week of the Frontend and using React, perhaps I may come to like it it more!

Introduction to the DOM & DOM Manipulation

The DOM or "Document Object Model" is a tree data structure that displays which elements within a HTML page is the parent/child of another element. So, for example if you have a section in a HTML page, anything that goes inside this section is a "child" of the "section" element.

<section>
  <h1 id="unique-childHeader" class="childHeader"> I am a child of the section element above!</h1>
</section>

With this in mind, we are able to essentially write JavaScript that will have access to the elements on an HTML page and manipulate its property.

One way that we are able to for example manipulate the actual text inside an element using the example above is by getting access to that specific <h1> tag and manipulating what's inside of it.

const childHeader = document.getElementById('unique-childHeader');

function deleteInnerText (domElement) {
  domElement.target.innerText = "";
}
<button onclick="deleteInnerText(childHeader)"</button>

For this example above, we have assigned the DOM element of the H1 in the previous example and assigned it to a variable called childHeader. Then we create a new function called deleteInnerText which will take in a DOM element as its parameter and then once it is called, it will specifically target that DOM element's "innerText" (Which is essentially the text inside an element) and then replace it with an empty string, essentially deleting everything within that DOM element.

Finally, we create a button that upon being clicked, will invoke the deleteInnerText function and that will remove that specific DOM element's inner text.

All-in-all, we spent two-days creating two different small-scale projects that used DOM manipulation so that we could practice these concepts. Me and my partner for the Monday & Tuesday focused on creating a "Who's That Pokémon" game that gave you four options of which Pokémon was hiding behind the silhoutte and would switch to the correct one if you're correct, and lastly a Dungeons & Dragons Themed Character Profile Creator!

Semantic HTML & Accessibility

Another portion of the first few lectures had drilled into us the idea of "Semantic HTML" and "Accessibility." I will be honest in saying that prior to focusing on this idea of "Semantic HTML" and "Accessibility" I had no idea what it was and why it was needed.

In essence, "Semantic HTML" refers to using HTML tags that have really specific meaning so that people who use things such as screen readers will have an easier time being able to navigate your website.

This includes setting up your website so that it has the correct language at the top of the page because people who use screen readers will have the screen reader select that website's language and the audio that's played back to the user will be reflected in the language that's initially setup.

If you've ever used Google Translate and tried to playback an English sentence from the Japanese speaker's side, you would understand how difficult this could be for those who have difficulties browsing the web.

So in essence, making sure that you use proper semantic HTML will enable more people to browse your content without having to worry about any ambiguities that may cause them to struggle. If you would like a resource to learn more about semantic HTML and accessibility, then please click here to learn more!

Introduction to React, JSX, Functional Components & Props

Perhaps the most anticipated section of the Frontend portion of the bootcamp is finally being able to learn about React. I can only speak for myself but I've heard so many great things about React and how it makes a Frontend Developer's life a whole lot easier.

However, React is definitely not for the faint hearted. Especially if you haven't brushed up on a lot of the modern ES6 JavaScript syntaxes such as Ternary Operators, Higher Order Function Array Methods such as .filter(), .map(), and .reduce(), arrow functions and the ... spread operator, and much more, so if you aren't completely comfortable with ES6 syntax, then I would highly recommend trying to get familiar with these as these will without a doubt help out a lot down the line!

I apologise for going on a complete ramble before finally explaining, "What is React?"

"React is a JavaScript library for building user interfaces and is **declarative* and component-based" *.

This is extracted straight from React's Homepage and so what does this mean exactly? It means that React is essentially a tool that makes it a lot easier for Frontend Developers to build UI (User Interfaces) that users will interact with a lot easier.

Up until now when we have wanted to update a HTML's DOM structure, we would have to traverse the DOM's tree-like structure by using recursion and getting that data which takes up a significant amount of time to do so. Instead, React has a virtual DOM which is as it's written in the packaging, a virtual version of the HTML's DOM tree that React uses to get access to the elements in the virtual DOM!

Not only this, beforehand we would have to manually select elements, add eventListeners and then manually assign them to certain elements. This is known as "Imperative Programming" - where we are essentially telling the program to do things in a specific sequence to a T.

However, React is "Declarative" because we just tell React what we want. If we want to have a button that upon being pressed triggers a callback function, we can just go ahead and do that, without all of the hassle like we would do in JavaScript!

And lastly, what exactly does "Component-Based" mean? React is known for building SPA's (Single Page Applications), this means that all of the data will be kept within a single page. Traditional websites that are not SPAs will require you to go to load up a different page when you click something. However, with SPA's built in React, it will react to any changes that's happened with the current state of the application and re-render only specific components based on what has changed.

JSX - JavaScript XML

So what is this mysterious sounding syntax called JSX? As the title has already given it away, JSX stands for JavaScript XML. JSX is essentially what allows us to write both HTML and JavaScript into a single file. Take this for example:

const listItems = ['One', 'Two', 'Three', "Four o'clock rock"];

const rockSchedule = (
  <ul>
    {listItems.map((item) => {
      return <li key={item}>{item}</li>;
    })}
  </ul>
);

const root = ReactDOM.createRoot(document.getElementById('root'))
root.render(rockSchedule);

This here is an example of JSX. First we have an array called listItems and another variable called rockSchedule that contains a <ul> HTML element (Unordered List) and inside this UL, we use curly braces to specify that we're using JavaScript and its methods. And in this case, we are just going to map over the listItems array above, and for each list item in this array, we are going to return an <li>' that has a "unique key" and the actual item in the array - after that, we just create aroot` variable that is rendered to the HTML page.

Components - Functional Components vs Class Components

React Components are split up into individual functional components so that they are reusable and easier to deal with. For example, if you had a button on a to-do list not functioning as it should be doing, then you can easily just go into this component and figure out why it doesn't work.

One big elephant in the room when new React Developers are picking up React for the first time is the concept of "Functional Components" vs "Class Components". When we were first introduced to components, our mentors had just told us that we will only need to focus on functional components because class components are becoming obsolete and will soon become legacy code.

But, that has gotten me thinking and researching why that is. If you cast yourselves back to the Fundamentals Section of the Northcoders Bootcamp (and my blog entry), we had touched upon the Functional Programming Paradigm and Object Oriented Programming Paradigm.

A quick recap is that the Functional Programming Paradigm aims to have each individual function do one specific thing only and to not mutate the data that is passed inside of it. Whilst Object Oriented Programming does not mind the mutation of data because it's built upon the encapsulation of data to new each instance instanstiated from a Class, and being able to have methods and properties inherited by new instances.

Now this brings us to the advice of being told to use Functional Components vs Class Components. From my understanding of these two paradigms, how data is held between the two types of components and seeing the structure of a Class Component in React, this is what I have derived:

Class Components are being discouraged from use because they come pre-packaged with methods (Functions) that are inherited from React, and you aren't completely certain what is being inherited in terms of the properties from Class Components.

An example of a Class Component is:
js class Car extends React.Component { render() { return <h2>Hi, I am a Car!</h2>; } }

The actual functionality of the above example from W3Schools is not important - but what is important is that the new class component extends from React.Component, that means by default it will not be clean and already has methods/properties that can be associated with it.

On the other hand, Functional Components are clean by default. Functional Components are created like a regular function would be and so you would not need to worry about if it has any baggage inside of it, and so you are able to predict how a functional component would behave!

React State, Props and Hooks

Oh boy, I will be completely honest with you and say that the concept of React's State and Props had me losing myself yesterday. "State" refers to data or information about a component, and is stored in a "state." This state that is held within a component will be able to be passed down to child component that will have access to this data, and is able to change the state of that data.

As React essentially re-renders its components based on changes to a component's state, if a child component that has access to "State" that's passed down by its parent component, then React will see that there's a change in the parent component's state of data and cause that to re-render.

Therefore, when a parent component re-renders, all of the children to that parent component must be re-rendered.

One method of storing state in functional components with React are "Hooks". React Hooks essentially allows the user to "hook into" a component's state and get access to it. One of the main hooks that we have focused on learning this week is the "useState" hook.

js const [todos, setTodos] = useState([ { id: 1, item: 'Dishes' }, { id: 2, item: 'Laundry' }, { id: 13 item: 'Rubbish' }, ])
This is an extract from the code that me and my partner had wrote for our to-do-list application. The first argument in the useState React Hook is the current representation of the data's state, and the second argument of setTodos is a function that will be invoked when you wish to update the current representation of the data's state. And lastly, the arguments in the useState function itself represents the default information that's stored in the state. In this case, we have by default got three to-do-list items inside!

Next is the idea of passing down state to child components so that they are able to get access to data and their state:

js <DisplayTodos todos={todos} /> <AddTodo todos={todos} setTodos={setTodos} /> <DeleteTodo todos={todos} setTodos={setTodos} />
This example above has three functional components that are children to this main to-do functional component. We want the DisplayTodos component to only have access to the current list of todo items, whilst the AddTodo and DeleteTOdo functions require both access to the current list of todo items and being able to change the state of the todo items.

In order for us to pass down state as "Props/Properties" to children components, we must specify what they should be called when being passed down, and then have that equal to the state being referenced and passed down.

In this case, we are trying to pass down the todos state by doing the following of <AddTodo todos={todos} />

Lastly, how do we get access to the state that's passed down as Props to these child components, there's two ways:
1) The first is to have "Props" as the argument to the child component and then access it using dot notation. So for example: props.todos
2) Or the second is through using Object Destructuring.

Here's an example of both in action in the DisplayTodos component that onyl has access to the todos state:
`js
//Without Object Destructuring - Pass in as regular props object
const DisplayTodos = (props) => {
return(

{todo.id}: {todo.item}

)
}

//Object Destructuring - Destructured the state inside the parameters
const DisplayTodos = ({todos}) => {
return(

{todo.id}: {todo.item}

)
}
`

Thoughts Going Forward

With that final exerpt on passing down props to child components brings us to the end of this week's blog post! I'm honestly so relieved that it's the weekend and that I've somewhat got a clearer idea of "React State" and how you pass it down to child components, because it was a really difficult hurdle to overcome. I will definitely be trying to relax and spend sometime refining my CSS and React knowledge in preparation for the final two weeks of the Frontend portion of the course!

And so that brings us to the very end, and as always I really appreciate you all for sticking around and tuning in to see how my journey's coding and hopefully learning something along the way, and I hope to see you all this time again next week!

Socials

Feel free to give me a follow on any of my socials down below!

The Rising Coder - Week 7/13 (Backend Week 3/3)

Christopher Lam — Fri, 14 Oct 2022 18:02:34 +0000

~~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!

The Rising Coder - Week 6/13 (Backend Week 2/3)

Christopher Lam — Fri, 07 Oct 2022 17:51:39 +0000

Last week's blog post I mentioned "TGIF", this week I'd like to introduce "PGMF" - otherwise known now as "Please Give Me Friday!" I think that probably serves as a hint towards how this week has been, but before that...

Good morning, good afternoon & good evening, and thank you once again for taking the time to check up on me and my journey at Northcoders

Like always, feel free to drop me a follow on Twitter, LinkedIn and GitHub!

Alright...So what's the deal with week 6?

With a little bit of a preface from this week's blog's opening statement...This week was up until now the most difficult and intense part of the course, even so much so that the mentors who were previous students themselves had something to say during the middle of the week.

Our fantastic lead mentor Christian and mentors Scarlett & Heather shared their personal stories about how this week especially was by far the toughest they had to overcome. Christian ensured us that it's perfectly fine for us to struggle as long as we weren't struggling in silence as he eluded to his own struggles with the seeding of the database for the Thursday & Friday sprint.

All-in-all, Northcoders and the mentors themselves are very aware that this week was difficult and made sure to regularly check-in on us to make sure that we were getting along fine.

But, even with that said. I will admit that this week has definitely been the most overwhelming because up until now, we had most of the file structure given to us and didn't have to worry about handling errors when we were using Express. I had thought I had a pretty decent grasp of Express until we embarked from the "Happy Path" of successful GET requests to the dark territories of error handling and seeding a database using Node-Postgres.

And that was when the ~~fire nation struck~~ realisation I had that the "error handling" and "seeding of databases" was not as simple I had envisioned it to be, but was instead an entirely different beast altogether.

So with that said, the sheer amount of content covered this week makes it difficult for me to provide concrete examples, but instead I will try to explain what we had managed to get covered this week in brief summaries.

Without further ado, here is what we were up to this week:

Setting up queries to the PSQL Database & preventing SQL Injections
Introduction to dotenv environment variables
Introduction to Testing & Development Databases
Introduction to Integration Testing the API Endpoints with Jest's Supertest
Express Middleware Functions & Error Middleware Functions
Introduction to Seeding & Seeding with Node Postgres

Node Postgres

Node-Postgres is a way for Node to interact with a PostreSQL database through callbacks/promises/async & await.

With Node Postgres, you have two main methods of connecting:

1 - Client - This is used when you wish to create a single instance that will only have that single channel of communication.
2 - Pool - This is used when you wish to open up multiple channels of communication - which is useful when you have multiple users that are querying independent things.

With Node Postgres, we will require a bit of setup using "environment variables" to securely connect to the databases because it would be bad practice if the environment variables were stored directly on a project's sourcecode.

ENV - Environment Variables

Environment variables (ENV) are default connection parameters that PSQL will use to login, authenticate and connect to the databases that you have on your localhost machine or an endpoint.

PGDATABASE is used to specify the database that you are trying to access, and you're able to store your environment variables in any means you wish. For security reasons it is not advised to keep environment variables on-file, but for testing purposes they will be kept here.

And as such, if you have environment files in your local repository, it is advised to add .env.* to your .gitignore file so that they are not accidentally uploaded to GitHub!

For the following Client & Pool connections, we setup PGDATABASE manually;

The naming convention of the environment variables for each database will be something similar to: .env.development and .env.test which will all begin with .env

PGDATABASE = my_database_name

However before doing so, we will need to download & require in the dontenv package that will give us access to these environment files that we can use!

Connecting Node-Postgres W/ Environment Variables

Before we hook up Node-Postgres to our PSQL database, we need to understand the two methods that Node-Postgres is able to connect to our database.

The first is via a "Client" which will mostly be accepting a single connection at a time, which is not ideal for us if we're emulating multiple clients making requests and as such, the second option of a "Pool" of connections is what we will be using to connect to our database.

The general configuration for a connection.js file that contains this would look like this:


const { Pool } = require('pg');
const ENV = process.env.NODE_ENV || 'development';

require('dotenv').config({
  path: `${__dirname}/../.env.${ENV}`,
});

if (!process.env.PGDATABASE) {
  throw new Error('PGDATABASE not set');
}

module.exports = new Pool();

We would first require in the "Pool" object that has methods that will allow us to connect to our designated database later on by requiring in the Node-Postgres package that we'd installed.

Secondly, we declare an "ENV" variable that will set the type of environment that we will be working in (Discussed below) whether this is the "development environment" or "test environment".

Third, we require in the dotenv package & configure the path for dotenv to navigate to and assign the database we'll be connecting to the specific database specified in the .env file.

Lastly, if PGDATABASE does not exist then an error will be thrown.

Types of Databases & Integration Testing

Previously we had been using Jest for TDD and had been testing every single function individually to ensure that they were working as intended, and this was referred to as "unit testing."

This week, we were introduced to the concept of "Integration Testing" which is where we aim to test software modules were integrating and working logically as a group, which was pretty tricky to get a proper idea of until we'd incorporated tess for our API's endpoints.

Following this, we were introduced to the four different types of databases that each serve a purpose:

Development Database - This is a database that will need to persist and not reset on every "test" being made using Jest's Supertest. A development database will often have a sheer volume of data vastly contrasting to the test database.
Test Database - This is a database that will not persist and needs to be reset on every single test. The volume of data is significantly lower than the development database because otherwise it'd affect how frequent tests can be completed.
Staging Database - This is a database that test engineers will use to give feedback.
Production Database - This is the live database that will persist and the one users will be using, and as such this is essentially the final product.

It is important to note, all of the data across databases will need to have the same schema and look exactly the same besides the volume of data.

Express Middleware Functions, Error Handling & Error Middleware Functions

Last week when were introduced to Express and the concept of "Middleware", we had it drilled into our head that anytime you hear "Middleware", it means that something will be dealing with the "Request" and "Response".

This holds true for what we covered this week about the Next parameter in Express' Middleware Function, and the existence of "Error Middleware Functions."

So to visualise this, last week a standard Middleware Function that existed in the Controllers of an MVC would be something like this:

const controllerMiddlewareFunc = (req, res) => {
  invokeModelFunction()
  .then(() => do something if successful)
  .catch((err => {
    console.log(err);
  }))
}

But this week, we were introduced to "Error Handling" - which is as the name sounds, how we end up handling errors that come back along the line from our code.

The example below shows you how and where exactly the "next" parameter is invoked if an error occurs:

const controllerMiddlewareFunc = (req, res, next) => {
  invokeModelFunction()
  .then(() => do something if successful)
  .catch((err) => {
    next(err);
  }
}

So here, when an error comes back from the "Model" function then this error will be caught in this .catch() block, and essentially the invocation of the "Next" function will mean that it will be passed into the main app.js that will then handle that specific error.

Error Middleware Functions

A bit more of a specific topic is that of "Error Middleware Functions." This is a function that we use to essentially create a function that will handle in errors, and is characterised by having the four parameters of: err, req, res, next - typically we would also have a custom object sent back to the user that will have a status code & message for example:

//app.js
app.use((err, req, res, next) => {
  if(err.status && err.msg) {
    res.status(err.status).send(err.msg);
  }

  else {
    next(err)
  }
}

//model.js
if (!array.includes(item)) {
  return Promise.reject({ status: 400, msg: "Bad Request" })
}

Here in this example where we've created a reusable custom error middleware function that will check if when it receives an error if it has received an object that has the property names of status and msg, and if it does then it will go ahead and send a response back to the user with that status & message.

If it does not satisfy that certain error middleware function's conditional statement, then it would use the "next" function and pass it to the next error middleware function in the chain until it finds a condition to satisfy it.

If it does not satisfy any of the error handling middleware functions that we had created, then it will simply return a "Status:500 - Server Error" to the user because it cannot find the correct error middleware function!

Introduction to Seeding & Seeding w/ Node-Postgres

I'll be honest with you, the concept of "Seeding" and what it had meant went over my head until Jim, the leader of the 30th August 2022 cohort had used the anecdote of it being the same "Seeding" as you would have in games like "Minecraft."

So "Seeding" is basically generating data and inserting that data into the database for a developer to work on.

Previously when we had covered SQL/PSQL we could manually create an insert statement for all of the information to the database - however, we are Software Developers and so we aren't going to sit there for countless hours and insert all of this data.

Instead, we are going to use Node-Postgres and create a function that would allow us to seed all of the information that was provided to us in the sprint, into the database for us to be able to work on creating endpoints for us to retrieve data!

I would have ended up writing an entire disseration on Seeding & Seeding with Node-Postgres if I tried to explain how all of this was working under the hood the past two-days, but I don't think that would be a great idea 😂

But hopefully, this week's small summary of what we had gotten up to and how intense this week was, was properly conveyed to you all!

Thoughts Going Forward

Honestly I'm really chuffed that myself and the rest of the people in my cohort managed to brave the storm this week and hopefully made it all in one piece!

A few roadbumps personally this week but they were all addressed by the supportive staff here at Northcoders that will take any issues that you have seriously to create a real safespace for every student so that they can feel like they don't have to be anxious at any stage.

So a really, really huge shout out to Northcoders, the mentors and my personal mentor Alex, you're all doing a fantastic job - and that includes you Christian, this may be your first time leading a seminar group but I would have thought you had lead multiple seminars if you didn't tell us this week!

For now, I'm just looking to brush up and internalise what we leaarned this week and prepare myself for next week's week-long solo project for the final week of the back end phase, and I hope to see you all there next week!

Socials

Feel free to give me a follow on any of my socials down below!

The Rising Coder - Week 5/13 (Backend Week 1/3)

Christopher Lam — Fri, 30 Sep 2022 19:04:21 +0000

Did somebody say it was already Friday? Blimey now I understand why the acronym "TGIF" exists. But yet again, another brilliant but definitely exhausting week at the Northcoders Bootcamp!

Good morning, good afternoon and perhaps good evening, and a huge thank you again for coming to check up on me and my journey here at Northcoders

As always, feel free to drop me a follow on Twitter, LinkedIn and GitHub!

So... How has the fifth week treated me?

Perhaps if you have read my previous week's post of comparing how it went to trying to catching a plane that just set off, just imagine that you're stuck in the ocean as the plane that you're trying to catch off has already set off a few hours ago. Yep, that's how I felt this week 😭

The beautiful thing about the structure of Northcoders is that each topic that we learn builds off of concepts that we had covered beforehand. And before you even realise it, you've already learnt so much compared to where you first started!

I mean in all honesty, if I showed myself the code I had written in Express to the past me that had just started Northcoders, I would be skeptical and even ask myself "Where did you copy and paste that code?"

So to fellow Northcoders who may feel like they have struggled with this week's concepts and perhaps feeling behind, please don't put yourself down and instead look back at what you have done so far and be as proud as I am at your own progress.

In order to run we must first walk, and everyone will start walking and running at different times, your time will come!

With that said, this week felt significantly more difficult because previously we were dealing with the "Fundamentals" per the name of the block.

Where we were mostly gaining an understanding of the data types and the intricacies of how they worked because all of this indefinitely feeds into the rest of the course (Backend/Frontend).

What I Struggled Most With

This week I feel like I struggled when we were thrown into the deep end and were told to learn a new library called Inquirer.js and to use the concepts we had learned to implement the library.

I won't sugarcoat it and say that I felt panicked but ultimately was able to take it one step a a time by:

Reading the overview and understanding what the library was and why it was used
Examples of how the library is used and breaking down what syntax is used for what purpose
Reading the documentation on how individual methods in the library work
Breaking down the task from Northcoders and using the library with the concepts covered.

I had the head mentor Christian drop in to see how I was doing and he kindly reassured me that what I felt was normal and was a hurdle everyone has to overcome because once we head to the final projects phase, we would have to learn entirely new technologies.

A huge shout out to all of the mentors that spent this entire week with scheduled periodic drop-ins and keeping us grounded by empathising with our own experiences, you're all exceptionally wonderful!

(P.s. A huge welcome to Mitch as a new addition to the Northcoders team!)

So, what did we cover this week?

This week we built on our understanding of callbacks, asynchronosity and asynchronous functions with the following topics of:

Promises & Promise.all
Creating a HTTP Server With Node's createServer()
Introduction to Express and Middleware
The Concept of MVC - Model View Controller
Introduction to SQL

Introduction to Promises

Promises... I promise you that I struggled with this 😂

So, what are promises? A "Promise" is simply an object in JavaScript that is used for asynchronous computation and it represents a placeholder for an asynchronousoperation that has not yet been completed.

A promise has the three possible states of:

Pending - This is when the promise has not yet been fulfilled.
Fulfilled - This is when the operations have been a success.
Rejected - This is when the operations have been a failure.

In order to "fulfill" or "reject" a promise, we must use the methods of .then() to describe what exactly will happen if the promise is successfully fulfilled, and a .catch() method for unsucessful operations that rejects the promise.

Although this may look strange to those of you who may be unfamiliar with promises, please bare with me:

promise
  .then((response) => {
    // handle success
    console.log(response);
  })
  .catch((error) => {
    // handle error
    console.log(error);
  });

The chaining of .then() followed by the .catch() is only possible because a "Promise" is an object that has the methods (Functions) that are inherited by each new instance of a promise.

Therefore, simply accessing the methods with dot notation and adding a callback function will allow us to add computations upon fulfillment/rejection of the promise.

`Promise.all()`

I admit that I am one of the guilty Northcoderians that thought it was somewhat therapeutic to chain .then()all over the screen 😂

So what exactly is this method and what does it do? Simply put, it will take in all of the pending promises, store them in a single array and with a single .then() and .catch() block will resolve all of the promises in one.

If a single promise within the Promise.all() fails then it will automatically go straight into the .catch() block, and is definitely something I struggled to fully comprehend.

But alas, the concept of Promise.all() is something that is something that will eventually click once you finally hit a bottleneck of having many promises that needs to be resolved all in one location.

Here's an example that I will briefly just like to highlight how useful the Promise.all() method was and how that helped somewhat shine the light on how to use it:


const fetchAllPets = () => {
    return fs.readdir('./data/pets').then((pets) => {
        const allPetsData = pets.map((pet) => {
            return fs.readFile(`./data/pets/${pet}`, 'utf-8')
        })
        return Promise.all(allPetsData);
    }).then((pets) => {
        const parsedPets = pets.map((stringifiedPets) => {
          return JSON.parse(stringifiedPets);
        });
        return parsedPets

})

So this was an example of a function that me and my pair had wrote for one of the sprints this week.

For this example, "fs" which stands for node's "File System" is a module that is used to get access to the local file system and do something with them.

We are using the "promises" version that requires you to resolve the promise before data is sent back.

But the most important part here is that when we define a new variabled called allPetsData which maps over the array of data that we get back from reading the directory ./data/pets is that this within itself is an array of around 13 pending promises.

Imagine if we had tried to resolve this individually, and how many lines of code we would need to use! Instead we just return all of the promises into an array that we then later use for further computation, such an elegant and clean way of doing things!

Creating HTTP Servers With `.createServer()`

Last week I touched upon HTTP methods, CRUD operations and the anatomy of a URL.

This time we were put to the test by using Node's module called HTTP that allows us to effectively create our own server running on the localhost on the port of our choice!

First we would have to require in the HTTP module, create a "server" variable that invokes this HTTP module with a callback, and finally to have the server listen to a port on our machine so that it can pick up requests.

const http = require('http')
const fs = require('fs')
const fsPromises = require('fs/promises')

const server = http.createServer((req, res) => {
  //
}

server.listen(9090, (err) => {
  if(err) console.log(err);
  else console.log('Successful connection on port 9090');
})

With this setup, we can now deep dive into a bit of the anatomy in the example above:

The const server is just the invocation of the createServer method on the http object that we had required in.
This createServer() method takes in a callback that has the "Req/Request" and "Res/Response" as its arguments.
The "Request" is an object that the server receives when a client user makes a "method" request to our server and its endpoints.
The "Response" is also an object but this is what we use to send data over to the user.

Writing Responses Guideline

I believe that this small section is important because being able to successfully send a response back to the user is paramount to both the server and its users, so try and remember the following:

A response will always require a "body" of information that will be sent back to the user.
The response body will need to be of a string data type.
It's recommended that you include a "Header" in your response - this contains metadata that will be sent back to the user pertaining to the response made.

Introduction to Express

A quick recap as to what a "parametric endpoint" is - it's simply a path that has a placeholder that is dictated by what the client puts.

E.g. https://northcoders.com/api/users/:userId

When we created our own servers with the HTTP.createServer() module, we would have to do really ugly computation in order to deal with parametric endpoints.

Here's an example of how messy it can look when we had to deal with a parametric endpoint that ends with a digit.

if (/\d+$/g.test(req.url) && req.method === "GET") {
//
}

Not exactly the easiest code to understand and it can definitely lead to a lot of confusions, but with the minimalistic backend framework of Express.js, our lives are somewhat a little bit easier!

Express is described as a minimalistic framework because it allows us to concentrate on dealing with the requests coming in and serving up responses to the enduser.

With Express we had access to a wide variety of tools such as:

Req.params - This is what we will be using to deal with dynamic parametric endpoints, no more Regex conditionals.
Req.query - This is what we will be using to get access to the queries being parsed in the request by the client.
Res.send()- This is the method we invoke with a string of data to be sent back to the user.
Res.status() - This is the method that we can append to the response being sent back to the user that will contain the status code depending on the HTTP method and if it was successful or not.

I could go on all day about how relieving it was to go from Node's HTTP Module to Express and its features, but I'll save that for another day!

Introduction to the MVC Architecture

The MVC Architecture simply stands for "Model View Controller" and is a simple way of setting up your backend server so that each individual component is responsible for its own functionality.

And as such the functionalities are:

Model - This will deal with data in storage - whether this is reading/writing/updating/deleting data locally or on a database.
View - This is what will be sent back to the user in the form of a HTML file and corresponding CSS/JS files when the server is finished rendering.
Controller - This will handle the requests & responses, and as such is classed as the "Middleware Function". The controller is responsible for taking in requests, sending instructions to the model to retrieve data and send it back to the user.

Previously myself and my pair were bewildered at the concept and questioned why such a concept existed, in which the answer lied in "structure" and "scalability".

Sure, we would be able to create an entire server in one file that handled all three, but if we ever wanted to scale p and perhaps change the "model" that handles the data, then this would be difficult because there would be an infinite amount of code to filter through just to find data pertaining to that model.

Although it makes sense, refactoring it into the MVC Architectural model definitely took a bit of time to get used to and understand!

SQL - My Dreaded Enemy

For so many years I have avoided SQL because of its very nature that just absolutely scared me. But after spending an entire day trying to get to grips with it, I can say that it is something I will need to spend more time with 😭

So, what is SQL? SQL stands for "Structured Query Language" that is based on "relational databases", this means that it has columns and rows of data for each table in a single database, and you're able to "relate" data between tables by doing pretty neat things such as "joining" them together and creating an entirely new table by using data from multiple tables.

Beyond this I could try and explain the complete intracies of the language but then I'd end up writing the documentation, so just know that it's a logically structured language that is useful when making complex queries!

Thoughts Going Forward

I believe that after having talked with Scarlett (one of our great mentors) that we don't have to mess around too much with vanilla SQL with the introduction to "Node-postgres" that has made me feel more at ease and so I'm just ready to enjoy my weekend, and I hope you all are too!

Honestly that's about it for this week's blog, but if you have gotten this far then thank you again for taking the time to read and I will see you next week!

Socials

Feel free to give me a follow on any of my socials down below!

The Rising Coder - Week 4/13 (Fundamentals Week 3/3)

Christopher Lam — Fri, 23 Sep 2022 17:55:26 +0000

Christ, where has the time gone, it's already Friday and another end to a great week at the Northcoders Bootcamp!

Good morning, good afternoon or good evening and thank you as always for coming back to check out my journey at Northcoders - I hope you've all had a lovely week so far and an even better weekend coming up!

P.S. It's already been an entire month since myself and my fellow friends in the same cohort as mine have joined Northcoders, so a huge round of applause for us all, especially for the mentors and cohort members, you guys are absolutely a pleasure to get along with! 😁

As always, feel free to drop me a follow on Twitter, LinkedIn and GitHub!

Soooo... How has my fourth week been?

If you saw last week's post and how I thought it was like trying to catch a train that set off, this week felt like I was trying to catch a plane that just set off 😂

Imagine everything that you had learned previously about functions and how they are able to return a function or an invocation of a function as its value, and then told the next second that you just throw all of that away.

Because that was what we did this entire week! This entire week we focused on the ideas of "Asychronous Functions" and how they work, why we use them and why these will be our best friends for the rest of the Back-End!

But before that, I had mentioned that this week we would have a "Review Day" of the core fundamental concepts of: Array Methods, OOP, Recursion and Closure - and so that was what we did for the entirety of this Tuesday.

I am not going to sugarcoat it at all and be completely honest, the prospect of the review day had led me to become stressed and lose a few hours of sleep during the 3-day weekend.

But I am glad to say that I managed to survive and even receive lovely feedback from the mentors that were happy to say that my understanding of the concepts and my code were fantastic, which was one of the most relieving moments that I've had so far on the course!

List Of Topics Covered This Week

Besides surviving the review day, here's a quick bullet point of all of the concepts that we dove into this week:

Wednesday: Asynchronous Functions , making requests and the anatomy of a callback function in Node.
Thursday: Dealing with multiple asynchronous callbacks and dynamic requests to endpoints.
Friday: HTTPS, CRUD Methods, APIs & Endpoints.

As you can see from the sheer volume of topics above, these are all fundamental topics that we will be needing as we dive into the backend portion of the course, and as always I will try to provide a summary of what I have managed to learn coming out of this week!

Asynchronousity - Who, what, why and how?

The term "Asynchronous" essentially means being able to multi-task and do multiple things at once. For us Software Developers who use JavaScript - JavaScript is known as a single-threaded language, this means that it can only run through code one line at a time. Unlike other "multithreaded" languages such as C++.

This is important to note because we will be using Node.js which will allow us to implement the concept of "Asynchronosity" into JavaScript. Node.js is originally written for JavaScript to have asynchronous functionality, but in fact Node.js is actually written in C++, and so this is the reason that it is able to be multithreaded and handle more than one function at a time!

Understanding this, "Asynchronous Functions" are referred to as "facade functions" because although they look like a regular function, there is something really discerning about them that you will be able to immediately spot, and that is an asynchronous function does not return anything to the user.

Instead, the asynchronous function will return a "Callback" with any data it has and serve it to the user.

With Asynchronous Functions, although they may seem like regular functions, they are entirely different! When a regular function is created and invoked, it gets put on the "Call Stack" which will call "Global" on the call stack.

Asynchronous Functions on the other hand are only able to be put on the call stack when the call stack is empty. So if there are other regular functions on the call stack waiting to be popped off, then these asynchronous functions will be put in what is called the "Task Queue."

Depending on how long it takes for the asynchronous function to receive all of the data it needs will determine which item will first be popped from the task queue into the call stack.

But remember, that the asynchronous functions cannot be moved from the task queue into the call stack until it is empty! - This is where it's difficult to really visualise how long the task queue is, especially with multiple asynchronous functions being run simultaneously!

Making Requests & Node's Callback Function Anatomy

One of the most difficult things that myself and my pair-programming partner had to understand was the "Home-made Request Function" that Northcoders had created to simulate Node's Request function, and how callbacks are structured in Node when we create a callback.

For the home-made replicas of Node/Express' Request function, the anatomy is firstly the "Path" or "Endpoint" that we will be retrieving the data from, and then secondly will be the "Callback Function" that is used to execute the callback passed in as an argument, with the modified data.

Consider this example:

function fetchBannerContent(callback) {
  request('/banner', (err, contents) => {
    contents.copyrightYear = 2022;
    callback(err, { ...contents });
  });
}

Here we have an asycnhronous function called fetchBannerContent that takes in a callback as its argument. The request will be making a request to the path/endpoint of '/banner', and then with a callback that takes an error and the contents that were fetched from the request being made to the endpoint of '/banner'.

In this case, the following object is received from the request:

{
  title: 'Kitty Litter',
  bannerImg: 'https://riotfest.org/wp-content/uploads/2017/10/AcT9YIL.jpg',
  copyrightYear: 2006
};

Within this callback that has access to this data, we simply access the property of copyrightYear and change this from the original "2006" to "2022", and then invoke the original callback in the argument with the callback of (err, {...contents})

For those who have a keen eye, we had decided to create a new object (For a new reference in memory) and use the spread operator (ES6 "...") to copy those contents and then use this in the callback. And so the user wil receive the following object:

{
  title: 'Kitty Litter',
  bannerImg: 'https://riotfest.org/wp-content/uploads/2017/10/AcT9YIL.jpg',
  copyrightYear: 2022
};

Multiple Asynchronous Functions & Dynamic Requests

If dealing with a single asynchronous function wasn't enough, try multiple asynchronous processes at the same time!

But first, the most beautiful things about ES6 and making "Dynamic Requests", is that you don't need to manually enter the path for the request.

function fetchCatsByOwner(owner, callback) {
  request(`/owners/${owner}/cats`, (err, cats) => {
    callback(err, cats);
  });
}

Here we have a simple asynchronous function called fetchCatsByOwner that takes in an owner & callback as its arguments. The request body is where it is beautiful - by using template literals, we are able to put in the "Owner" as an argument and get back an array of cats that belongs to the owner that was passed in as the first argument when we invoke this function!

Perhaps that example was too simple because we would have to manually put in an "Owner". What if we wanted to fetch all of the cats from all of the owners?! Absolute madness!

function fetchAllCats(callback) {
  const catsArray = [];
  fetchAllOwners((err, owners) => {
    owners.forEach(owner => {
      fetchCatsByOwner(owner, (err, cats) => {
        catsArray.push(cats);
        if (catsArray.length === owners.length) {
          const flattenedCats = catsArray.flat().sort();
          callback(err, flattenedCats);
        }
      });
    });
  });
}

Here is a brief breakdown of what exactly is going on here, because it looks like complete chaos!

1 - Firstly this function called fetchAllCats is designed to use a function called fetchAllOwners which will return an array of all of the owners. E.g. `['Chris', 'Daniel', 'Antony', 'Felicity', 'Benjamin', 'Kanti', 'Ikram', 'Christian', 'Alex'].
2 - Secondly, through getting this array of owners - we are going to invoke the fetchCatsByOwner for each user in this array. (And as you can see in the previous example, as thanks to the dynamic route, we don't need to do it manually!)
3 - Third, we push the array of cats that belongs to the owner for each personn in the "owners" array.
4 - Fourth, once the length of the catsArray is equal to the owners array, we will flatten it and sort the cats array by alphabetical order.
5 - Lastly, we invoke the original callback in the argument with (err, flattenedCats) and then this alphabetically ordered array of cat names will be served to the user. (PS Don't flatten your cats 😭)

Introduction HTTPS & CRUD Methods

I won't dive in too deep about the theory behind how the internet works, as this playlst will be a great reference point to how requests are made to servers and how we are able to retrieve data!

However, I will be talking a little about APis, endpoints and "CRUD Operations."

Firstly, APIs or "Application Program Interfaces" are servers that are able to provide raw text data to its users. (If you look for any random API and search for something, it will show you a completely blinding block of text - this is the raw data!)

Through this APIs, they have "endpoints" which just refer to the path that a user will be able to traverse to and get access to the data that exists on that path.

Below is a small explanation of the anatomy in an API:

Example: `https://api.github.com/search/reports?page=2`

https:// - This is the protocol that says how the data should be requested and responded to.
api - Nothing special but an indicator to users of what type of server they are accessing when entering.
github - this is the DNS provided address name.
.com - The top level domain that is often owned by countries or domain name providers.
search/repos/ - This is the "path" or "route" used by the precise document of where information si requested, known as the **endpoint**. Similar to how we are able to dynamically access an endpoint, we can use placeholders like /:placeholder/resource` to be dynamically based on the input from the user.
?pages=2 - Often denoted by a question mark, the page and a number is a "query" that is being made to a server.
& - Using an and symbol, we can chain on other query terms that are available on an API.

As Software Developers these pieces of data that are served as raw text are invaluable to us because we are able to use this data to serve our own desires.

However, how do we get this raw text data into a more "Readable" format for us simple humans?

We will first need to use a method known as `JSON.stringify()' to convert the raw text data into a "JSON" format (JavaScript Object Notation), this will create a stringified object that looks akin to how objects are displayed in JavaScript.

Then we would use the function of JSON.parse() to take this object-looking string and then converts it into a JavaScript Object that we can comfortably use as Software Developers, it really is just that simple!

Lastly (I nearly had forgotten) are "CRUD Operations", and not the "crud" we say when we mess something up!

CRUD Operations stands for "Create, Read, Update and Delete", through certain HTTP methods we are able to:

Create new resources on a database
Read resources from a database
Update resources on a database
Delete resources on a database

And each of these HTTP methods are the following:

POST - This is the method used when we're trying to add something to a database. These requests will need to have a body of text/information that will be held and requested to be added to that database.
GET - This is the method used when we're trying to "get" or receive information back after we make a request.
PATCH/PUT - This is ued to partially update something in a database/resource.
DELETE - THis is the method that is used to delete a specific instance of a resource.

And that's about the gist for what we had learned this week! I could dive deep into the code written for todays's sprint but that would require an entirely new post! But fundamentally everything that we had learned this week was all of this!

Thoughts Going Forward

If you have made it this far to the end, thank you very much as always for checking in on me and my journey at Northcoders, it means the world to me!

I think for now I'm really ready to enjoy a well-deserved weekend and brace myself for the start of the "Backend" portion of the Northcoders Bootcamp - and I hope to see you all again next week!

Socials

Feel free to give me a follow on any of my socials down below!

The Rising Coder - Week 3/13 (Fundamentals Week 2/3)

Christopher Lam — Fri, 16 Sep 2022 20:00:10 +0000

Good morning, good afternoon and good evening! Thank you yet again for coming to check up on me and my blog, and a huge shout out to all of my lovely cohort friends that have been kind enough to check in on my journey and even recommending it to others. I really do appreciate every single one of you! 😊

As always, feel free to drop me a follow on Twitter, LinkedIn and GitHub!

Oops... How has my third week been?

Honestly from the get-go, it has been absolutely hectic. Imagine yourself trying to catch a train that just set off, that was exactly how I feel this week has been. An absolute train wreck of making sure I paid complete attention to each and every single lecture this week!

This week we spent it primarily on learning OOP (Object Oriented Programming), the core concepts and principles and they work in JavaScript. And if I may so, I cannot believe that myself and my fellow cohort have made it out (hopefully) in one piece!

Every single morning at 08:00, I would be making sure I read over the notes made available to prepare myself for the lectures at 09:00. And even then I had to completely focus!

But as the mentors at Northcoders are amazing with their explanations of the core concepts, I managed to somewhat stay afloat this week 😂

So what did you cover this week?

Right off the bat we covered the following topics of:

Introduction to Recursion
Introduction to OOP and its 4 pillars
Prototypes & Prototypal Inheritance in JavaScript via Prototype Chaining
The infamous "this" keyword
Introduction to "Class", constructors, instances.
Extending JavaScript classes and instantiation with new keyword
JavaScript Getters and Setters

Honestly an entire week on OOP and I'm ready to go back to my comfortable home of Functional Programming!

Which I would like to iterate again to myself and my fellow cohort friends, look at what we've done this entire week! Prior to OOP, we had weeks/months perhaps learning about the Functional Programming Paradigm, and we learned about OOP in this one-short week, well done!

Recursion

Did you know that if you Google "Recursion", that it will return itself in the search bar?

Recursion in JavaScript is a function that makes calls to itself, and these are not limited to "returning" itself in a function.

A recursive function works by adding new instances of itself recursed onto the "Call Stack" and will keep on doing so until it is told to stop. However, if it is not told when to stop recursing (caling itself) then it will eventually lead to what's called a "Stack Overflow" because there's not enough memory in the browser/computer because each recursion is waiting for a result from its last recursion.

Confusing, right? I like to not think about recursion so that I don't think about recursing the thought of not liking it 🤣

A recursive function has the three following steps:

1 - Base Step/Exit Case - This is when you tell the function to stop recursing on itself. Think of this as the "if" statement!
2 - Recursive Case - This is the "reason" a function is recursing. Perhaps it's a total is being added to each recurse!
3 - Recursive Step - This is how the function will recurse on itself to walk towards its goal in the recursive case. Perhaps it's recursing to count the numbers from 10 to 1!

OOP & 4 Pillars

"OOP" or "Object Oriented Programming" is another programming paradigm in which you work with objects that will have their own methods (Functions) that are assigned as properties. Instances of these objects and other classes will be able to inherit these methods.

Bit of a mouthful but in short, we're mostly focusing on creating objects and not functions like in the Functional Programming Paradigm. And we are not afraid of a bit of mutation in our objects!

Key Words & Concepts in OOP

Instance - When the term "instance" is used in OOP. It means a newly created object that is derived from a certain class/prototype.
Instantiation - This is just the technical term for when an instance is created.

OOP's 4 Pillars

The OOP paradigm relies on the following four principles of:

Encapsulation - The grouping of data & behaviour into little packages, and limiting data accessibility from the user through things like private naming conventions & variable declarations.
Abstraction - This is removing the more complicated processes from the user and letting them focus on the main task at hand. For example, we don't need to tell someone how to make a cup of coffee with the inner workings of a coffee machine, we just tell them to use the machine!
Inheritance - This is the concept of instances that have been instantiated from a Class/Prototype having access to the prototype's methods and properties.
Polymorphism - This is where an instance that is derived from its parent class/prototype should be able to act as if it is the parent class (As it inherits behaviours/data).

Even after trying to get my head around the entirety of the 4 pillars, I will still need a bit more practice getting my head around these concepts!

Prototypes, Prototypal Inheritance & Prototype Chaining (JavaScript Traversal)

Everything in JavaScript is an object. It's just that "Arrays" etc are a special type of object, and so they all have a prototype. - Top Class Mentor Dave 2022

By the end of our introduction to OOP, if there's one thing to remember from Dave's lectures, was that everything in JavaScript is an object!

As every single object in JavaScript has a "Prototype", you must be wondering what exactly a "Prototype" is.

Prototypes in JavaScript are a mechanism that objects will use to inherit methods from one another. These "Prototypes" will each come with their own custom methods that upon an instantiation of a new instance on a specific prototype, will inherit the methods of that prototype.

JavaScript Traversal with Prototype Chaining

Another topic that was hammered into our heads by Dave was the concept of "Prototype Chaining" and how JavaScript traverses through to check if certain methods are available when called.

In this case, JavaScript will look in the following steps:

1 - Instance: JavaScript will first look to find the called method on the instance that called it.

const myArray = [1,2,3]
myArray.fakeMethod();

2 - The Prototype - So now that JavaScript was not able to find the fakeMethod() on the instance called myArray, it will look at the level above, which is the Array Prototype.

Array.fakeMethod() // fakeMethod is not a function

3 - Layers Above (If necessary), else the Object.Prototype - Once JavaScript has traversed through the instances, and prototype layers, it will eventually reach the highest "Object.Prototype" layer and if it does not exist there, then it does not exist at all!

What is "this"?

The most anticipated keyword that has been said multiple times this week, what is "this"?

"this" is a keyword that will implicitly bind the object that calls it with the following properties that have been defined.

We mentioned previously how "Constructors" will be receiving arguments that are used to store properties on the objects that are instantiated instances of that constructor prototype, right?

We achieve "Encapsulation" by ensuring that each new instance of an object on a specific constructor prototype will be unique to that instance and not shared with others. Consider this:

class Pokemon
  constructor(name, favouriteFood) {
    this.name = name
    this.favouriteFood = favouriteFood
}
const Charmander = new Pokemon("Charmander", "beta blocks");
const Pikachu = new Pokemon("Pikachu", "gamma blocks");
console.log(Charmander) 
console.log(Pikachu) // Each "new" Pokemon will have their own unique properties that are bound by the "this" keyword!

Classes, Constructors, Instances

Classes are what is called "Syntactic Sugar" that sweetens the existing functions that we have in JavaScript and makes our lives a lot easier!

We are able to create a class and have it known to others with the class keyword and a capitalised first letter following the word after, to say to other developers "HEY! This is a class, remember to instantiate new objects using the new keyword"

This brings me nicely to the new keyword that must be called whenver a new object instance is instantiated from a class, such as the above example earlier:

const Charmander = new Pokemon("Charmander", "beta blocks");

Classes are an amazing addition to JavaScript in ECMA 2015 - and have the "Constructors" which hold the properties that are declared upon instantiation and bind it to each individual instance.

In addition to this, we are able to declare methods (Functions) as we would a normal function inside the Class, and these will be inherited by each instantiation and "extension" of the parent class.

Extends and Super

I'm really on fire tonight with how I'm leading into each topic, aren't I? ‎️‍🔥‎️‍🔥‎️‍🔥

When you have defined a class that has properties that are bound to each instance, and methods have been defined.

We are able to use the extends syntax to create essentially a sub-class that will inherit all of the previous methods defined in the parent class of which it extends, and even override existing methods.

Consider this example:

class Pokemon {
  constructor(name, type) {
    this.name = name;
    this.type = type;
  }

  eat() {
    return `${this.name} has started to eat.`
  }

}

class SatiatedPokemon extends Pokemon {
  constructor(name, type) {
    super(name, type)
  }

  eat() {
    return `${this.name} is already full.`
  }
}

const Charmander = new SatiatedPokemon("Charmander", "Fire");
Charmander.eat() //logs "Charmander is already full."

As you can see from this example above, when Charmander which is a newly instantiated instance from the "SatiatedPokemon" class uses the eat() method, because of the rules of JavaScript traversal first looking into the instance, this is the method that will be called!

Adding onto this is the idea of the "Super" keyword that is used to copy over the parent class' properties, but even modify them!

JavaScript's Getters and Setters

The get() and set() methods in JavaScript are used so that the user is able to essentially "get" certain properties and "set" certain properties of an object.

These are especially useful if the properties in question have a "Private Naming Convention" or "Private Property Setting", these are the following:

Private Naming Convention - As the name suggests, these are naming conventions that developers adhere to that tells other developers to not interfere (too much or at all) with certain variables, and these are denoted with an underscore. E.g. _name:
Private Variables With Hashtags - These are properties that will only be accessible inside a Class. And these are denoted by the hashtag "#" symbol, and must be defined before the constructors, and is referable by methods in the class.

class Squirtle extends WaterPokemon{
    #species;
    constructor(name, hitPoints, attackDamage, move) {
        super(name, hitPoints, attackDamage, 'water gun')
        this.#species = "Squirtle";
    }
}
const Chris = new Squirtle("Chris", 70, 20);
//console.log(Chris.species) will have the attributes passed in without the "private" species!

With the get method, we are able to use these exclusively to get access to even private properties, for example:

get speciesName() {
  return this.#species;
}

console.log(Chris.speciesName); // logs "Squirtle"

The Get Method is a function and so you will only need to simply append the name of the function to the right of the "Get" keyword, and it will run the "get" function!

set pkmnAge(age) {
  this.pkmnAge= age;
}

The Set Method will allow the user to set certain properties dynamically by making sure that we call the "set" method with a single argument, otherwise the setter method will not run.

Thoughts Going Forward

If you have somehow made it towards the end, then thank you again for reading and checking out my blog! I'm honestly overwhelmed with how much we have covered this week and for now, I'll be sure to enjoy my 3-day weekend and brush up for doomsday (Review Day) this coming Tuesday!

Socials

Feel free to give me a follow on any of my socials down below!

The Rising Coder - Week 2/13 (Fundamentals Week 1/3)

Christopher Lam — Sat, 10 Sep 2022 16:33:40 +0000

Hey, hi and hello! Thank you for coming to read this week's blog post on my coding journey: The Rising Coder with the Northcoders coding bootcamp!

Feel free to drop me a follow on Twitter, LinkedIn and GitHub!

So, how was my second week?

If I could summarise this entire week, it would be "Absolutely bonkers". The first introduction week helped us become familiar with the setup of a development environment, a recap of the basics of JavaScript (Primitive/Non-Primitive Data Types & methods etc), modules/exports for access to the testing libraries in the future and such.

However, going straight into the start of the week we were introduced to a plethora of abstract concepts and practices which ended with the topic of JavaScript Closures, and I'm so relieved that I managed to get my head around the topics that were covered this week, it was a huge step up from the previous week!

What exactly was covered this week?

Jumping straight into the contents of what we had covered this week, we touched on the following topics:

Pair Programming & Test Driven Development (TDD)
The differences between "Primitive" and "Non-Primitive" Data Types with the main topic of mutability vs immutability & value vs reference.
JavaScript Closures

Pair Programming - So, what is this mysterious practice?

Pair Programming is an agile software development method that operates on the idea that two heads are better than one. Pair Programming is traditionally broken down into two main roles of:

Navigator - The navigator does not touch the code but is responsible for navigating the driver as to how to get to the desired outcome of whatever problem they are trying to solve. This does not mean they provide every method (and the reverse never provide any ideas), but they ensure that the pair are implementing best code practices of clean code & test driven development, and are staying on-course.
Driver - The driver is responsible for listening to their navigator and implementing code that suits the problem they are trying to tackle with their pair.

Over the course of the bootcamp we will be pairing up with another student in our cohort to complete "Sprints" (Work that is done within a short time period), and as such we were given the following tips:

Be accommodating + kind to yourselves and your pair.
Be flexible with the "rules" of pair programming - Do not be bound into only those two roles and don't be afraid of trying something new that works for you and your pair.
Respect each other's boundaries.

The second tip was the most important to me because going into pair programming with the limited mindset of "Only these two roles" will make us both inflexible and unable to explore options that would work for me and my pair.

Test-Driven-Development (TDD)

Test-Driven-Development otherwise often known by its abbreviation of TDD is a common buzzword that you will hear being used by many people within the tech industry. So, what is it exactly?

Test-Driven-Development is a development technique where you build up tests that are designed to fail at first and then build your solution for these tests.

But, why use TDD?

Firstly, is that TDD allows you to have proper proof that the code that you have written is doing exactly as it is intended to do without any weird unintended side-effects.

Secondly, TDD revolves around writing minimal amounts of code to pass each test before refactoring.

If you think about future codebases having tens-and-thousands of lines of code in multiple files, then having tests for each individual unit of code will make both your life and your future colleagues' lives easier because you are able to show each other "Hey this piece of code does this and is shown in its tests."

Rather than writing new lines of code and breaking existing code, and having no tests would make it immeasurably difficult to identify what was going wrong with the code.

Primitive vs Non-Primitive Data Types & Value vs Reference

The concept of "Primitive" vs "Non-Primitive" data types is probably the most crucial concept that myself and my fellow cohort students had to learn about.

Primitive Data Types in JavaScript are: Number, String, Boolean, Undefined, Null and Symbol.

Non-Primitive Data Types in JavaScript are: Objects/Arrays

We first learned that primitive data types are what we call "Immutable". This means that we are not able to directly change the state of that variable once it has been created.

For example, consider the example below:

let exampleWord = "hello";
exampleWord.length = 7;

console.log(exampleWord) //Returns the length of exampleWord to 5;

You are not able to directly change the state of a primitive data type even if you access its properties such as length.

"Non-Primitive Data Types" such as Objects and Arrays whose properties we are able to "mutate" a.k.a. change the properties within these non-primitive data types.

For example:

const arr = [1,2,3];
console.log(arr) // logs an array of [1,2,3]
arr.push(4);
consle.log(arr) // logs an array of [1,2,3,4]

The array above is able to have its properties modified/mutated.

Through understanding primitive data types are immutable and vice-versa for non-primitive data types. We are introduced to the idea of "Value vs Reference."

Primitive Data Types such as Number/Boolean/String are referred to by their value when being compared with other variables. Whilst non-primitive data types such as Objects and Arrays are compared to each other by their "References" in memory.

This means that Arrays/Objects at the moment of initialisation are assigned their own space in memory and are referred to by pointing towards that space in memory in which they occupy.

Closure

That leaves me with the final topic that we covered at the end of this week, which was the concept of Javascript's "Closure", and thank the lord that it's the weekend after going through this concept!

Closure in JavaScript refers to a function having access to variables that are defined within its lexical scope (parent function's scope) or in simple terms, its outer environment.

Consider this example:

function helloWorld() {
  const greeting = "hello";

  function finalGreeting() {
    return greeting +  " world!";
  }

  return finalGreeting();
}

So, what exactly is going on here? First we have a function called finalGreeting() that returns greeting + " world!" But, for those who are keen eyed, within the finalGreeting() function, there is no variable that is created called greeting. So how does it work?

This is because of "Closure". As this function called finalGreeting is living within the function helloWorld, it is able to get access to outside variables living in its lexical scope/parent function scope and utilise them if they are not previously defined inside its own function.

The Tricky Part: COVEs

Probably the most difficult one to understand was the idea of "COVEs" or "Closed Variable Environments" in JavaScript. But, simply but is that JavaScript has a "Garbage Collector" that removes any unused variables once the thread of execution has concluded and all of the code has run.

The concept of a COVE is that variables that are still being referenced by other functions inside will make it so that those variables are stored inside the COVE and are not deleted but are still accessible.

How I remembered it: Recycle Bin Analogy

In order to remember about the COVE, I compare it to the Windows Recycle Bin. Even when files are deleted on your Windows PC, they are still somewhat accessible because they are only moved into the Recycle Bin where you can restore them. So unless you remove them yourself permanently, they will always be stored away in their own reference in memory.

Sound confusing? It most definitely was to me! But, we survived and managed to make it through this week too.

A really huge shout out to the Northcoders Mentors, my fellow cohort members for always being supportive of each other, and to my two partners this week, you guys absolutely rock!

Thoughts Going Forward

Honestly, a really great first week on the Fundamentals part of the bootcamp. Didn't complete the most amount of challenges (Katas), but I did internalise a lot of the material which I can argue is just as important! For now, I will be looking ahead and reading up on a few difficult concepts such as: Recursion and OOP!

And as always, if you have made it this far, thank you very much for reading and I hope to see you next week!

Socials

Feel free to give me a follow on any of my socials down below!

DEV Community: Christopher Lam

The Rising Coder - Week 13/13 (Project Week 3/3)

Match Me If You Can - Internal Networking Event

Final Week Schedule

How The Final Day Went

Team G3O's Final Project - Find 'n Dine

Find 'n Dine - Brief Summary

Find 'n Dine - Tech Stack

Front-End Tech Stack

Back-End Tech Stack

Self-Reflection

Thoughts Going Forward

Socials

The Rising Coder - Week 12/13 (Project Week 2/3)

The importance of "Spiking" technology

Learning to trust the team

Enjoying the process

Importance of Documentation & Navigating Documentation

What is TypeScript and why you should learn it

Thoughts Going Forward

Socials

The Rising Coder - Week 11/13 (Project Week 1/3)

Careers Day - CV Writing Workshop w/ Keely Madgin

Things To Consider:

Things To Avoid:

Careers Day - Aceing Tech Tests w/ Jim Stevenson

On-Site Test

Take-Home Test

Careers Day - Industry Insights w/ Mal Browne

Types Of Developer Teams

Getting Hired As A Junior Developer

Careers Day - Presenting Yourself w/ Kathy Brooke

Importance of Confidence

Separation of "Personal" and "Professional" Values

Breathwork

Personal Takeaway: Orbiting

Careers Day - Preparing For Interviews w/ Darren Holland

Previous Technical Recruiter Linkedin Tips w/ Michael Whittam

Introduction to the Project Phase

Project Phase - Concept of Spiking

Project Phase - Agile Standups (Meetings)

Thoughts Going Forward

Socials

The Rising Coder - Week 10/13 (Frontend Week 3/3)

Enough of that... What did you do this week?

Reflection #1 - Take It Slow

Reflection #2 - Official Documentation's Your Best Friend

Reflection #3 - Regular Breaks Are A God-Send

Reflection #4 - Enjoy Yourself

Mini Surprise

Thoughts Going Forward

Socials

The Rising Coder - Week 9/13 (Frontend Week 2/3)

Last week over-reaction? How did I React this week?

Topics Covered

React Hook: useEffect()

Fetching Data with Fetch & Axios

React and the isLoading pattern

React Router - BrowserRouter, Routes, Route, Link

React Router Setup

React Router's Links

Introduction to Optimistic Rendering

Thoughts Going Forward

Socials

The Rising Coder - Week 8/13 (Frontend Week 1/3)

Deep Dive - What Did We Cover This Week?

Introduction to the DOM & DOM Manipulation

Semantic HTML & Accessibility

Introduction to React, JSX, Functional Components & Props

JSX - JavaScript XML

Components - Functional Components vs Class Components

React State, Props and Hooks

Thoughts Going Forward

Socials

The Rising Coder - Week 7/13 (Backend Week 3/3)

The Nitty Gritty - What We Covered

Solo Portfolio project - Northcoders News/Games API

Git Branches - Not Actual Twigs

Agile Methodology: Kanban

Hosting /w Heroku

React Hook: `useEffect()`

React and the `isLoading` pattern

`Promise.all()`

Creating HTTP Servers With `.createServer()`

Example: `https://api.github.com/search/reports?page=2`