The (second) first post

As a developer, it is important to write clean and readable code that is easy to maintain and understand. However, as projects grow and evolve, it can be easy for code to become cluttered and difficult to navigate. This is where code smells come in. Code smells are indicators that something may be wrong with the code, such as poor design or lack of organization.

One example of a code smell is the use of magic numbers. Magic numbers are numerical values that are used in the code without any explanation of their meaning. It can be difficult to understand the purpose of a magic number, and it can also make the code less readable. A better practice would be to use constants or variables to store these values and give them a meaningful name.

example of “magic numbers”
cleaned up

Another example of a code smell is duplicated code. Duplicated code is when the same code is repeated multiple times throughout a project. Not only is this a sign of poor organization, but it also makes it harder to maintain the code. When a change needs to be made, it must be made in multiple places, increasing the chance of introducing bugs. To avoid this, it is better to refactor the code and extract common functionality into a separate function or method.

On the other hand, writing clean code is all about making sure your code is easy to understand, maintain and change. To write clean code, it is important to follow a consistent coding style, to use meaningful variable and function names, and to organize your code in a logical way.

A good example of clean code is the Single Responsibility Principle (SRP). SRP states that a class should have one and only one reason to change. This means that a class should have a single, well-defined responsibility. This makes it easy to understand the purpose of a class and also makes it easier to change or extend the class in the future.

Another example of clean code is the separation of concerns. Separation of concerns means that different parts of the code should be responsible for different things. For example, the code for handling user input should be separate from the code for displaying output. This makes it easier to understand the code and also makes it easier to change or extend the code in the future.

Martin Fowler said “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” As a student, I would definitely say I got into the bad habit of not writing super clean code, especially for smaller assignments. Working on this capstone project has definitely influenced the code I’ve been writing for other classes for the better.

First Term Recap

With the first term of our capstone project almost finished, I thought it might be good to go over the basics of what we completed over the past 10 weeks. Our team has been working on re-developing a website for the Soundbendor Lab. While majority of it was creating the two major technical documents needed to begin, we also laid out the bare bones of the site. We did this by starting to work with some of the tools we will be utilizing for the rest of the project.

Current Soundbendor Lab Website

Documents

The first step in the process was creating the requirements document, which is essential for any sort of complex project, like building a website. It’s basically an outline of what you need the end result to be. Requirements documents list out function, form, and feasibility requirements for the project at hand. Requirements can be functional, meaning they outline what the website or product needs to do. For example, a requirement might state that a website needs to have a search function. Form requirements deal with the look and feel of the site or product. Feasibility requirements focus on whether or not the project is actually possible given the resources and time constraints. Requirements documents are important because they help to keep everyone on the same page and ensure that the final product meets everyone’s needs.

The next step was creating the design document. It outlines the overall design of the site, including the layout, content and even things such as the aesthetic design. The technical document also specifies the functionality that will be included on the site. This can include contact forms, searchable databases, or e-commerce functionality. The design document is an important tool for communicating the vision for the project to the development team. In our capstone project, we spent a considerable amount of time developing the design document. We wanted to make sure that our website met all of the requirements of our client while also ensuring that our website was easy to navigate and understand.

Portion of the Table of Contents from Design Document
Portion of System Specifications from Requirements Document

Tools

One of the tools we used in our project was Strapi, an open-source, Node.js-based content management system (CMS). It enables developers to easily build and manage customizable APIs for their web applications. Strapi’s main goal is to make it easy for developers to create and manage APIs while also providing the option to use their own tools and frameworks. Strapi is also available as a headless CMS, which means that it can be used with any front-end technology such as the one we are utilizing, React. In addition, Strapi provides an intuitive admin panel that makes it easy to manage your content.

Strapi CMS Homepage

Another tool we used, which is used by the majority of developers today, was React, a JavaScript library for building user interfaces that was created by Facebook. It is Declarative, which means that it makes code easy to read and understand. React is also Component-Based, which means that it is easy to reuse code. Next.js is a React framework that enables the creation of static and server-side rendering React applications. We chose to use React with Next.js for our capstone project because we wanted to create a frontend that was static. This meant that we could host our application on their local computer, which would greatly reduce the overall cost.

AWS is a cloud computing platform that offers a variety of services, including storage, computing power, and databases. For our capstone project, we used AWS to store our media files in a shared directory on AWS Simple Storage Solution (S3) and to create a simple database instance on AWS Relational Database Server (RDS). AWS RDS is a relational database service that makes it easy to set up, operate, and scale a database in the cloud. Using AWS RDS, we were able to quickly create a database instance and connect to it from our web app. AWS S3 is a simple storage service that offers a secure, scalable way to store and retrieve data. By storing our media files in AWS S3, we were able to provide access to them from anywhere in the world without having to worry about server capacity or bandwidth limits.

Bootstrap is a frontend CSS framework that we used in our capstone project. It provides a responsive design that makes it easy to develop mobile-first projects. Bootstrap includes a number of pre-built components that can be used to create common web elements, such as buttons, progress bars, and form controls. In addition, Bootstrap provides a grid system that can be used to create fluid, responsive layouts. Bootstrap is easy to use and saves time by reducing the need to write custom CSS code.

Bare Bones setup of new website created with React and Bootstrap

I am really happy with the work we have done so far on our capstone project. In terms of the requirements and design documents, I feel as though we have set up a solid roadmap for what the nexts steps in the project are. And, I think using tools like Strapi, React, AWS, and Bootstrap will help us successfully develop the Soundbendor Lab website into something more customized to the client. I am looking forward to continued progress in the next two terms!

Blog Post 2

I am very excited to actually begin the “real” work on the project this week, as technical writing will probably be the death of me. While I understand that these documents are part of the process, honestly, I hate them. This is not a complaint, just a simple fact, and I would like it to be noted. I understand why people get the impression that STEM folks are all boring nerds, technical documents are so dry you will literally be physically and mentally dehydrated after reading one. In my opinion writing them is far worse, like crawling through a desert.

The one exception to my technical writing hatred is making figures. Figures are technically not part of the actual technical writing, but as they are essential to the overall technical document, I believe, technically, they count. They are my oasis in desert, a refreshing break in between the dunes of text. I don’t think anything would make me happier than if the only thing I was responsible for was spending hours on Figma making an aesthetically beautiful and functional mockup of our proposed site design.

Initial Proposed Home Page Mock-Up
Initial Proposed Team Page Wireframe

Also, it’s not just limited to making mock-ups and wireframes. I love a good database schema or ER diagram. I think tangibly organizing my thoughts so I have a better grasp of how the relationships between the entities might work is very satisfying. It also shows me the gaps in my logic or plan that I need to fill in or revise.

Initial Proposed Database Schema for Our “People” Object

Maybe it’s just part of being in STEM, but I believe a lot of my frustration creating these documents comes from the feeling that language alone can be incredibly limiting as far as communicating your ideas. I don’t want to try to explain in complete sentences how things will work because I don’t think I’m particularly good at it, I just want to show you. I could write paragraph after paragraph trying to verbally communicate how I think the home page should look and function, or I could make a mock-up with a couple notes and convey way more information with a much smaller margin for confusion.

One of the members of my team has a few years experience working as a professional software engineer, and they have been an integral part in the ease of this first phase of our project. They very clearly seem to have an image of how all the parts of this website need to come together, and getting to pester them with questions has greatly expanded my understanding of web development. They also mentioned that while these documents are genuinely part of the processes, very rarely are the actual developers the ones writing them. This information brought me much joy.

All in all I am very pleased with how the project is going thus far. There are almost always a few things you can find to to complain about, as with anything in life, but as long as the list of good stuff is longer than the list of bad stuff, I will be happy. If trekking through the technical writing desert is the most difficult part of the project, I’d say I’ve got it pretty good.




Hello world!

Though this was the default title, I felt as though it was an appropriate title for the first post of a Computer Science degree capstone project blog.

As everyone enjoys talking about themselves, I thought I could start this off by introducing myself. My name is Ann Marie Hicks, I turned 25 less than two weeks ago, and I live in Columbia, South Carolina. I have a cat, Sunday, and a currently unnamed foster kitten who I have been calling “little boy”. I have been fostering cats for about two years now, but I think “little boy” might be my first foster fail (which sounds terrible but just means I’m going to keep him). My hobbies include starting arts and crafts projects and finishing about half of them, watching my boyfriend cook, and long-weekend trips to places within a 6-hour drive. Our most recent excursion was to DC over Labor Day weekend, which is 7 hours away but we first stopped in Richmond to visit family, so technically the original destination was less than 6.

“little boy” sitting on my friend’s laptop
Sunday looking well-behaved (shes not)

I was put in the Soundbendor Lab Website group, which wasn’t my first choice but it’s kind of hard to be upset about your project being web development. Also, it’s only been a few days since being placed in our groups, but from the bit of contact we’ve had, I’m fairly certain I have excellent teammates. I’m excited to be starting this capstone project as it indicates the beginning of the end of my undergraduate career, which is both a thrilling and terrifying prospect. On the one hand, I started college in the fall of 2016, so 3 different schools, 2 breaks, and 1 global pandemic later, I am more than ready to be done with this chapter of my life. On the other hand, I have no idea what the next chapter holds, and as the main goal during my quarter century here on Earth has been to get through school, I know just setting the next long-term goal will be an ordeal.

Thankfully, I have a school year and capstone project to worry about before I really have to face that crisis.