Technical – Pam’s Blog

Week 5 – Getting Stuck and Unstuck

It has been a very productive yet not productive week for me. I was able to dedicate most of my week for this project yet also had a lot of hiccups along the way since it has been a while since I’ve worked on full stack project. I think total I have spent more than 30 hours this week to get my wheels rolling. I think it took me a few hours doing actual coding and most of the time debugging.

There were many types of obstacles I’ve faced while coding this week. One of them was syntax. Since I’ve been trying to learn and juggle 3 different programming languages on weekly basis, it was very confusing to switch gears and code in another language. I spent a lot of time searching for syntax and notations, especially for things like arrow notations with no parameters, React concepts and notations for state handling and rendering, and Mongoose functions. I didn’t find an easy way to do this, just experimenting dividing my days of the week to focus on one language / project a day instead of trying to do little bit of each everyday. And also lots and lots of googling. However, it was no biggie. It was something that I could find answers right away and fix.

The harder part was actual code debugging when I have no idea what has gone wrong. Most of the my time I have spent this week was trying to fix up the bug that form was not updating with everything in the front end validation and backend API setup. Since there are so many parts involved in this one bug, debugging was a pain. There are many types of debugging methods out there and the main debugging method I’ve used were incremental inspection, logging, and asking for help.

When I run into problem, I first identify the problem by checking if there are error messages either on terminal or console. Then I would follow the indicated line back to the code to backtrack and find the piece of code that creates the problem. When there are no errors, I check in increments. Is my form able to render the previous data? Check. Am I able to edit the form? Check. Is the submit button working? Check. Is it sending information to the backend? Yes. Is the backend receiving the information? No. Then I eliminate all the front end form related code from the source of problems. Then I would break down again and check in backend whether route is correctly defined, if reducer is set up correctly, etc. It may be possible that I’m not able to fix the bug but at least I can identify it.

Accompanying the method above, what I like to do is log EVERYTHING. As soon as I find out the chunk of the code that’s not working, I’ll add print statements to log every step on the console. Some problems are not so obvious when I skim through the code. Everything seems to make sense and logically flow well. But once I start logging everything, I’m able to find out if there are some connections or data missing. I personally find this method the easiest and most useful tool when debugging.

With the two methods above, I was able to identify where I got stuck but I didn’t manage to fix it. I was just learning and using some libraries for the first time and I did not grasp the concepts fully. Even with lots of googling and trying, I found no solution. So what I did was I asked for help from my teammates. After all it is a group project right? Since I have teammates who are working on the same project, I have people who are familiar with the tools and languages to get advice on. Thus I just reached out for help and luckily one of my teammates has more experience with the tools and was able to debug and explain to me what the problem was within few hours. It turns out I was trying to solve the problem by fixing another section. Sometimes it is easy to get stuck in one particular zone and not able to see the big picture of suspect of other parts that were problematic. You might feel vulnerable asking someone for help but sometimes it is much more efficient to do so since the problem I spent days to debug was solved was fixed within hours with another set of eyes.

Debugging is a long patience game that requires a keen eye for details. There are many ways to approach and there’s no right way. I think it’s best to have a set of go-to approaches that works for you to help move forward, whether it is coding or any other project in life you work on.

Week 3 – Software Project Planning

It’s week 3. After choosing the tech stack, Team QuizBanana went straight into project planning. Luckily there was a very extensive plan template provided for us to refer to, it was not too hard to break it down. The plan in my mind was jumbled up and maybe < 50% formed, but as we worked on this together, I feel a lot of ideas got organized. I have much more clear view of the project and smaller task goals I need to achieve.

I think the key to having a successful and complete project regardless of the project type (software, culinary, medical, etc.) is to have a robust and thorough project plan. It is very crucial in shaping the project and becoming the base of the architecture. It is the time where the base structure and shape are constructed. Without a good plan, it would be more time consuming and risky to restructure or start from scratch. Think of a construction site. If a building was designed without thorough consideration of safety, material, and design, it would be really costly in time and money to either tear it down or make it bigger once the walls are put in. Even if has finished with poor structure, it may be weak to disasters like earthquake and tornadoes, which is also not we want.

In order to create a thorough project plan, we have approached this in multiple angles. We had client and client’s requirements, initial plan of codebase structure, software and libraries, flowcharts, wireframes, database schema, and breakdown of tasks with assignments and hours. Client and requirements is where we started, and also what is the most important part of the project. The goal is to satisfy the client’s needs. Therefore we lined up all the requirements and made sure our plan covers all of client’s needs. Having the main tech stack settled last week made it easier to figure out software and libraries to use, since there are related packages we can use for the project. Codebase structure plan came naturally since there are standard ways of setting up the folders based on the stack we are using. For flowcharts, we have created web page flow, login/sign up logic, and actual quiz logic. These help guide the order things should happen and also prioritize which parts need to be done first. Wireframing and designing database schema reinforces and puts together everything from above, that somewhat works as a check. By going through the wireframe, we get a good sense of design layout and fill in the missing parts in database schema or the logic. Then we divided up the tasks by features and pages to assign to everyone based on their specialty.

Personally, I dread doing planning despite it being one of the most crucial parts on project. However, having it broken down into pieces and being able to work on it in a collaborative team setting, I think the plan came out well covered and detailed enough for us to move along to the next step. Good team effort brought us a long way and I’m quite satisfied with the end result overall.

Week 2 – Choosing Tech Stack

It’s week 2 of the project. So far I have formed Team QuizBanana 🍌 with two wonderful persons to share this journey with and finalized on the project topic – software programming quiz. This project requires a responsive web application that needs CRUD features for users, have users create timed quizzes, send out links, receive submissions, and be able to view the result analytics. In order to create a good robust app, it seemed reasonable to start with planning. In this blog post I’ll talk about choosing tech stack as part of planning process.

There are many different ways of creating web app and different combinations of languages and frameworks. Mainly web app is divided into frontend (aka client side) and backend (aka server side). Frontend refers to everything that people can see on screen, mainly visual. Backend refers to all the logistics that happens to show what is on the frontend. A full stack refers to the set of tools/frameworks that are compatible to be worked with both frontend and backend. Since we are going to work on the entire project on our own, I would consider we are working on full stack development. Ones I’ve explored as options for our project were MEAN, MERN, Python + Django.

MEAN stack is shorthand notation for MongoDB + Express.js + Angular.js + Node.js. MERN stack is similar to MEAN except React.js is used instead of Angular.js. Both MEAN and MERN stack are based on JavaScript framework and Django is based on Python framework. The Python stack could potentially be Python + Django + Apache + MySQL. The reason I have picked MEAN and MERN are that those are the most popular and widely used stack for industry for web application. The reason I picked Python + Django is that python is relatively easy language and relatively easier to pick up.

Since I did not have experience working with Django, I’ve researched and found some information here¹. This article lays out the key differences in the aspects of Django and Express.js side by side. Some of the points that stood out to me was that although Django is very fast, it is more complex than Express.js, less scalable, and less flexible. Since we’re going to be working on this in less than 2 months, I thought the key part was how fast we can pick up and use. Also no one from the group had expertise on Django. That ruled out the option.

Now left with MEAN vs MERN, I have found out some distinctions through this article². Pros of MEAN stacks include many plugin availability, development possibility for different applications, while pros for MERN stack include easier learning curve, simpler UI, and better data handling for CRUD. Since one of our major functionality includes CRUD for users, and again easier to pick up, MERN seemed to be best option for our group.

After discussing these options with the group, we have unanimously agreed on using MERN stack since we all had some experience working with it and anticipated easier to find tutorials and solutions based on stack popularity.

References

Jeel Patel. “Django Vs Express: The Key Differences To Observe in 2022”. Monocubed. https://www.monocubed.com/django-vs-express/. Accessed 12 Jan. 2022.
Orione Solutions. “MERN vs MEAN : WHICH STACK TO USE IN 2021”. Data Science Central. TechTarget. https://www.datasciencecentral.com/mern-vs-mean-which-stack-to-use-in-2021/. Accessed 12 Jan. 2022.