Categories
CS 462

The Project So Far

It’s almost the end of Winter term and our Furever Matchup application is finally coming together. In light of all the progress that’s been made so far, I’ll be answering some questions about the project and my role in it.

Why did you choose your project, and has it met your expectations thus far?

I liked the idea of combining technology with animal adoption because it makes the process more engaging and accessible. Initially, I expected the project to be more straightforward, but the complexity of handling different user roles and managing user interactions made it more challenging than I thought. Still, seeing the system come together has been rewarding.

What was the most difficult challenge, and how did you solve it?

One of the biggest challenges was implementing user authentication and role-based access control. Since the project involves different user types—adopters, shelters, and admin—each with varying permissions, setting up secure and intuitive access was tricky. I used Flask’s built-in authentication features along with role-based logic to ensure the right people had the correct access. I had to learn a lot about balancing security with ease of usability.

What would you do differently on your project and why?

I would set up clearer milestones and deadlines earlier. While we managed to get the core features working, some tasks took longer than expected, which led to a bit of scrambling near the end. Better-defined expectations from the start would have helped keep things on track.

Do you feel your project was managed well or poorly, and how would you change things?

Overall, it was managed pretty well considering our group had different tasks and schedules to work around. Aligning everyone’s progress was sometimes difficult, but we managed to get new releases out in time. Regular check-ins helped, but I think being able to work in-person could have made things smoother.

Did you initially have doubts about your ability to complete the project? How do you feel now?

I initially had doubts, especially since I didn’t have much experience working on a full web app from scratch. There were times when debugging authentication issues or handling database queries made me wonder if I’d get everything working in time. But now, I feel much more confident in my ability to break down problems and find solutions.

Who will use your project? Will it benefit them?

Since we’re not working with a project partner, this was more of a proof-of-concept project rather than something that will be actively used. However, if it were fully implemented, the primary users would be animal adopters and shelters. Shelters could list pets, while adopters could browse, favorite animals, and get updates. The goal is to make the adoption process more engaging and personalized, helping both sides find better matches.

How have you handled getting ‘stuck’ on the project?

I’d take a break, then approach the problem from a different angle—sometimes looking at documentation, asking for help, or debugging step by step. Also, explaining the issue to a teammate often helped me realize what I was missing. As a last resort, I would lay on the ground staring at my ceiling until I could work through the problem.

What are 5 things you learned from working on your project?

  1. User authentication is harder than it looks – Handling login, password resets, and access control took more planning than I expected.
  2. MongoDB requires a different mindset than SQL – Working with a NoSQL database changed how I thought about storing and retrieving data.
  3. Front-end planning matters – Mockups in Figma helped, but I underestimated how much UI/UX design affects usability. I would spend more time on the CSS styling than the actual code itself.
  4. Good documentation is essential – When switching between tasks, having clear documentation made debugging and collaboration easier.
  5. There are always bugs – No matter how much I tested something, I’ll see a bug that I missed in the presentation videos. Even when there are no bugs on my end, someone else running the application will find one I can’t reproduce, which makes debugging especially tricky.

Categories
CS 462

The Good and the Bad: Writing Clean Code

Writing code is an art unto itself, but writing clean code that is both maintainable and still makes sense is a skill that requires practice. I tend to focus too much on getting my code to work rather than being able to understand it at a later time. After reflecting on a couple of articles about clean code and code smells, I’ve identified some practices I’d like to adopt more often—and some habits I want to avoid.

What is Clean Code?

According to Soyak (2024), clean code is code that is “well-organized, easily understandable, and maintainable.” Writing clean code isn’t just about making it functional—it’s about ensuring that anyone (including your future self) can understand and modify it without undue effort. Soyak highlights several key principles, including:

  • Define variables close to where they are used.
  • Group closely related functions near each other.
  • Keep code lines short and focused.
  • Avoid horizontal alignment (lining up code across lines).

I’ve often aligned lines of code or comments because I find it visually pleasing. However, as Soyak points out, this practice can introduce unnecessary complexity. Misaligned spacing in different editors or environments can make the code look disorganized and can introduce problems down the line. Here’s an example: 

# Bad
variable1     = 10
variable2     = 20
total_value   = variable1 + variable2

# Good
variable1 = 10
variable2 = 20
total_value = variable1 + variable2

One other area I want to improve is grouping related functions near each other. In the past, I would simply list functions in the order I wrote them, making it harder to find and update related logic. By grouping functions logically, I can navigate and refactor my code more easily, especially in larger projects. For example:

# Grouped Functions
def validate_user(user):
    # Validation logic here

def save_user_to_db(user):
    # Database logic here

def send_welcome_email(user):
    # Email logic here

What are Code Smells?

On the other end of the spectrum you have code smells. Code smells, according to Kanjilal (2022), is code that is “inefficient, nonperformant, complex, and difficult to change and maintain.” These bad practices don’t necessarily break functionality, but they indicate deeper problems that could grow over time. Common examples include:

  • Duplicate code
  • Long methods
  • Over-reliance on comments
  • Data clumps

Duplicate code can creep in as projects grow, especially when I’m in a hurry to implement features. However, duplicating logic wastes time and makes maintenance harder. Instead, I want to reuse existing functions whenever possible. By reusing functions, I can avoid redundancy and reduce the risk of inconsistencies during updates.

Another thing I’d like to avoid are unnecessary or long comments. I try to comment my code so that I can understand what I was thinking when I wrote it, but the line between too much comments and not enough can get a little blurry.

# Unnecessary comment
count = len(users)  # This counts the number of users

# Self-documenting code
user_count = len(users)

Conclusion

By adopting clean code practices and avoiding common code smells, I can write software that is easier to read, maintain, and improve over time. I plan to focus on grouping related functions, avoiding horizontal alignment, eliminating duplicate code, and using meaningful names instead of excessive comments. Writing clean code isn’t just about following rules—it’s about building a foundation for better collaboration and future-proof projects.

References

Soyak, T. (2024, April 28). Clean Code: Definition and Principles — Part 3 (Last Part). Medium. https://medium.com/@tahsinsoyakk/clean-code-definition-and-principles-part-3-last-part-5a247d957c79

Kanjilal, J. (2022, March 11). Understanding code smells and how refactoring can help. Search Software Quality. https://www.techtarget.com/searchsoftwarequality/tip/Understanding-code-smells-and-how-refactoring-can-help

Categories
CS 461

The End for Now

The last day of classes for Fall term is this Friday, and man, am I excited. Just a few more assignments, and I can finally kick back and soak in the Mariah Carey Christmas season. I’m ready for the peppermint hot chocolates, gingerbread cookies, and too many replays of All I Want for Christmas Is You.

On the school front, my group has made a lot of progress on our project. We’ve completed the first two iterations, and our site is shaping up nicely! It can now display all the pets available for adoption and allow users to favorite and unfavorite pets, log in and out, and even search for specific pets. While there are still some small bugs and the styling could use some love, it’s functional and delivering on our initial goals.

Next term will bring more progress on our project and, of course, more writing assignments (yay). But now that we’ve ironed out our team roles and workflow, I’m optimistic about hitting each milestone. We’ve learned a lot about collaboration and problem-solving, and that momentum should carry us through.

On a side note, I managed to knock out a few J.D. Next assignments! Once winter break starts, I’ll switch gears and focus on finishing my law school applications. My goal is to have everything ready so I can hit “send” as soon as my (hopefully much-improved) LSAT score comes in.

So, here’s to wrapping up this term strong and diving into winter break with a sense of accomplishment. I’ll be sipping peppermint hot cocoa and blinding myself with all the Christmas lights.

Until then, see you next time!

Categories
CS 461

The Project

Hello! It’s been a minute since I’ve written anything. These past few weeks have been quite hectic, but I’m excited to share that I’ve finally found out what project I’ll be working on: a “dating” website where adopters can browse through animals waiting to find their forever homes. My team has decided to call it Furever Matchup.

So far, my team and I have completed a few assignments, including our initial design document, which outlines our goals and plans. I’ll be handling user accounts, which is a new challenge for me since I’ve never created an application with login or account management features. Our first prototype is due by the end of the week, so from this moment on, our lives will be consumed by project iterations and progress reports.

In my last post, I didn’t mention that I’m also taking a course called J.D. Next, an 8-week program designed as an alternative to the LSAT, to help prepare for law school. Fortunately, the assignments don’t have strict due dates, which is good because with everything going on, I haven’t managed to start on any of them yet! Thankfully, I have until February 5th to submit them all. I seem to live by the motto, “if it’s not the due date, it’s not the do date.”

I’m a firm believer that everything works out in the end, so before I know it, this term will be over, and I’ll have tackled all those J.D. Next assignments.

Until then, see you next time!

Categories
CS 461

Introduction

Hello! I’m Dania, and this year marks the end of my journey at OSU—one that’s taken me a full decade. My path here wasn’t exactly straightforward. I originally aimed to become a pharmacist, so I started as a pre-pharmacy major. From there, I switched to microbiology, then bioresource research, and then several other majors before I realized I needed to take a break and rethink my direction. After six years of trying different fields, I landed on computer science. It wasn’t exactly my first choice, but it was one of the few options left that I hadn’t yet explored and could complete online. Oddly enough, even though it wasn’t new to me, computer science was the one that finally felt right.

As I work on this capstone, I’ll be sharing my experiences with the year-long project and a bit about my life along the way.

Currently, I live in Albany, OR, and work at the Target warehouse, where I’ve been for three years. Before Target, I worked in several pharmacies across Albany, Lebanon, and Corvallis. My time at the Walgreens pharmacy was a turning point—it was there I realized that pharmacy wasn’t for me. Working at Target is labor-intensive, but they fully cover my tuition, which is a huge help, and I don’t have to deal with customers, which is even better.

Once I graduate, my plan is to go to law school. I’m not too picky about where I go; I’ll be thrilled to get accepted anywhere. Right now, I’m focused on preparing for the LSAT because I need a solid score to offset my GPA after tanking it with all the major changes. This will be my second attempt at the LSAT, as my first try (when I thought I could manage without much studying) was humbling.

With the first official week of the term just kicking off, I’ve listed my top six choices for the capstone project and will soon find out which one I’ll be working on. It’s going to be tough balancing three classes, work, and LSAT prep, but I’m looking forward to it.

Until then, see you next time!