Author: Joshua Jansen

So far in developing an MMA prediction model, I’ve spent some time resolving a series of technical and theoretical problems. The project has been a lot of fun and stressful at times, but I’ve picked up a lot of knowledge along the way and made some great friends.

Why I Chose This Project
I chose to work on an MMA prediction model because I have a particular interest in mixed martial arts and machine learning. The idea of using statistical insights and historical fight data to make predictions about upcoming fights was a compelling challenge for me. Initially, I was drawn to problem-solving because predicting sporting outcomes combines data analysis, pattern recognition, and general world knowledge which sounded like a fun task.

The Most Difficult Issue and How I Solved It
One of the most difficult issues that I have faced was being able to scrap data from a website. I had no prior experience in this and have had a class in developing websites, so some experience in html. It was interesting learning how to use scrapy to be able to grab the right element from the website to be stored as json data. Initially I kept grabbing all the wrong things but then after a few tutorials I learned about the scrapy terminal which made pulling data instant so I could see what my code would do and not have to wait 20 mins for it to scrap everything.

Expectations and What I Would Do Differently
Until now, the project has lived up to my expectation regarding technical difficulty and the extent to which I have been able to apply myself and learn. Nevertheless, there is one area that I would have done differently, and this is planning to a greater degree at the initial stage, particularly the process of data collection. If I were to repeat the project, I would most likely spend more time initially on planning the database structure.

Project Management and Teamwork
This project was managed pretty well, but more regular check-ins and more defined roles for labor would have benefited. Having greater communication between teammates may have made several weeks go by a bit smoother. Greater collaboration would have also perhaps allowed the model to evolve more quickly.

Overcoming Doubts
Initially, I did have some doubts about whether I would be able to aid sufficiently in the project, especially since it involved machine learning subjects and a great deal of data manipulation. But as I’ve progressed, I’ve become more confident in my ability to tackle tough problems and solve them, in part due to my teammates helping me out.

The Most Interesting Part of the Project
The most interesting aspect of this project to me is the utilization of data science in a dynamic, live application like MMA. It is interesting to see how the model can predict results of fights using data and how it teaches me about how machine learning and algorithms can be applied in sports analysis.

Who Will Use This Project?
The primary users of this project will be MMA fans, analysts, and even betting enthusiasts who want to gain insights into future fight outcomes. They can use this model to make more informed decisions about their predictions, especially when looking at fighters’ statistics and trends over time.

5 Things I’ve Learned
How to preprocess and clean complex data.
The importance of feature engineering and selecting relevant features for a predictive model.
How to use SQL databases to query data in an efficient manner.
Why handling missing or incomplete data becomes crucial to ensure model accuracy.
How t employ fast-api to a database by creating endpoints.

Work with Teams
I have learned that collaboration is essential. Having outside feedback or bouncing ideas off others can significantly contribute to the success of a project. In future projects, I would ensure that there is more team effort and peer review in the initial stages.

Handling Setbacks
At times, I’ve been bogged down by some aspects of the project, such as how to enhance the prediction model or handling edge cases in the data. When that happened, I took a step back, analyzed the problem thoroughly, and usually checked online forums or my teammates. Breaking the problem into tiny pieces always pushed me ahead.

Life Hacks for Managing Work and Projects
One of my best life hacks for dealing with school, group assignments, and projects is creating clear, achievable daily or weekly goals. I like to break up a large project into tiny tasks because it keeps me going and makes me less overwhelmed. Another tip is speaking up early if there are hurdles, whether it’s with classmates, professors, or mentors.

Conclusion
This MMA prediction model has been a rewarding project so far, combining sports with my passion for data science. As we continue to refine the model, I am excited to see how much further we can learn and how this project might evolve into something even more sophisticated.

Welcome back to another blog post! My team is deep into building our prediction model with two core technologies that we have been using: SQLAlchemy and PostgreSQL. Below, I’ll share why SQLAlchemy has become my favorite tool and why PostgreSQL is a close runner-up (despite some frustrations), and how both are shaping my teams development process.

Love-Hate Relationship: SQLAlchemy & PostgreSQL
SQL-Alchemy is definitely my favorite technology that I have used since beiginging work on this project, as it is an ORM-Object-Relational Mapper-that allows me to work with databases in a Pythonic way (I like Python). Instead of writing raw SQL (Yuck), I get to define classes that map directly to tables in PostgreSQL, which keeps my code cleaner and more maintainable, as well as my sanity maintains for another day. In particular, I love how relationships between tables can be managed straightforwardly once everything is set up correctly.

In contrast PostgreSQL is an incredibly robust and capable, but it can be cumbersome to configure initially. Creating roles, setting permissions, and learning its advanced features (like partitioning, custom data types, etc.) can be overwhelming. Yet, for production-level applications where performance and reliability matter, PostgreSQL really shines, once our team of course has done the legwork to get everything running smoothly.

Challenges and Potential Improvements
While I have been enjoying using SQLAlchemy, the learning curve certainly was steep. Getting sessions, relationship configurations, and some of the more advanced querying patterns took me a while to learn. I would love clearer error messages on models or misconfigured relationships, those cryptic stack traces can be hard to unravel.

With PostgreSQL, I would like a smoother setup process. Perhaps a guided setup wizard to ease the early stage of setting up roles, databases, and security policies.

Learning Curves
The ORM approach in SQLAlchemy was the hardest to get used to for me. Once I got over that learning curve, it has been a huge timesaver. The SQL part of PostgreSQL has been relatively easy. If you know the basics of SQL, then simple queries and CRUD operations are pretty straightforward.

If I Could Start Over
I would have probably started with a simpler database like SQLite, just to prototype quickly. Then at some other point I’d migrate to PostgreSQL for the rich features and scalability. Also, I wish I had used Docker from the very beginning to containerize PostgreSQL. It would have saved me from the hassle of local installations and configuration quirks across different machines.

Hello there!

Todays post we will be looking at two topics, clean code, and code-smells!

Looking at the articles, “What Is Clean Code? A Guide to Principles and Best Practices” (clean code) and “When and Why Are Smells Introduced?” (code smells), I will be looking at practices that I want to start as well as stop in order to write better, more maintainable code. Let me share with you some of the things I learned from these articles.

What I’m Starting: Writing Small, Single-Responsibility Classes
While reading the article clean code, the Single Responsibility principle, SRP, stood out to me. It states that “every class should have a single, focused purpose.” (Codacy, 2023) this idea reduces complexity, makes testing easier, and improves maintainability. On the other hand, code smells article identifies that Blob Classes or classes handling too many responsibilities usually are created at the start of the project and remain problematic (Verwijs, 2021). It explains, “Classes that are poorly designed tend to be smelly right from the beginning and continue to be so for a long time” (Verwijs, 2021).

With SRP, we can actually be proactive at avoiding Blob Classes and laying down a good foundation for clean and scalable software. We can look at this with a code example. Suppose we are developing an e-commerce application and need to handle customer orders, storing them in a database. In that case, one Blob Class approach can combine these responsibilities into one class, which over time will create a big mess.

Code Smell Example: Blob Class

class OrderManager:
    def mark_as_paid(self, order_id):
        print(f"Order {order_id} marked as paid.")

    def save_to_database(self, order_data):
        print("Order saved to the database.")

    def generate_invoice(self, order_id):
        print(f"Invoice generated for order {order_id}.")

This may be fine for the moment, but as time goes on and we decide to add more features-such as sending notifications or handling refunds-it will inflate the class. This is a violation of SRP and brings about complexity.

Clean Code Example: SRP in Action
Here’s a refactored design using SRP:

class OrderService:
    def mark_as_paid(self, order_id):
        print(f"Order {order_id} marked as paid.")

class DatabaseService:
    def save_order(self, order_data):
        print("Order saved to the database.")

class InvoiceService:
    def generate_invoice(self, order_id):
        print(f"Invoice generated for order {order_id}.")

Each class has a single, well-defined responsibility: managing orders, handling database interactions, or generating invoices. This modular design makes the code easier to maintain and test as the application grows.

What I’m Avoiding: Rushed Changes Before Deadlines
The Code Smells article highlights that most smells, such as Spaghetti Code, are introduced just before a release (Verwijs, 2021). The study found that “89%-98% of code smells were introduced in the month before a major release” (Verwijs, 2021). This aligns with the Clean Code article, which warns against sacrificing clarity for speed: “Quick fixes prioritize short-term wins over long-term stability” (Codacy, 2023).

Using another code example scenario we can look at this issue. Imagine having to implement order processing logic quickly when a release date is getting closer. In the absence of due planning, rushed changes can lead to Spaghetti Code.

Code Smell Example: Spaghetti Code

def process_order(order_id, order_data):
    if order_id:
        if is_valid(order_data):
            if not is_paid(order_id):
                mark_as_paid(order_id)
                if save_to_database(order_id, order_data):
                    if generate_invoice(order_id):
                        print("Order processed successfully.")
                    else:
                        print("Invoice generation failed!")
                else:
                    print("Database save failed!")

This is too nested and unclear a structure to read, debug, or extend.

Clean Code Example: Modular Approach
We can avoid Spaghetti Code by breaking the logic into smaller functions:

def process_order(order_id, order_data):
    if not is_valid(order_data):
        print("Invalid order data.")
        return

    if is_paid(order_id):
        print("Order already paid.")
        return

    mark_as_paid(order_id)
    save_order(order_id, order_data)
    generate_order_invoice(order_id)

def save_order(order_id, order_data):
    print(f"Saving order {order_id} to database...")

def generate_order_invoice(order_id):
    print(f"Generating invoice for order {order_id}...")

This is a modular approach, following the principles of clean code, improve readability, and ease debugging.

In conclusion the few key takeaways are, write small single-responsibility classes early in a project. As well as avoid rushed last-minute changes that often lead to the creation of code smells (Verwijs, 2021). Clean code is not just about how it looks; it’s about creating maintainable, scalable, and error-resistant systems (Codacy, 2023).

References

Codacy. (2023, December 19). What Is Clean Code? A Guide to Principles and Best Practices. Blog.codacy.com. https://blog.codacy.com/what-is-clean-code

Verwijs, C. (2021, December 20). In-Depth: What Scientific Research Has To Say About Technical Debt And Code Smells. Medium; The Liberators. https://medium.com/the-liberators/on-technical-debt-and-code-smells-ae8de66f0f8b

Heyo,

This term has gone by relatively fast. Luckily for me my team decided that we wanted to knock out the rest of the term so we could have more flexibility in spending time with our families for Thanksgiving and the coming holidays. So, at this point this post is the last thing I need to do for the term!

The project thus far has been coming along nicely. We built our tech stack up and have a great git repository going, as well as a standardized plan on how things should be done. I also got to spend some time working on scraping with Scrapy which was an interesting learning experience. It wasn’t too hard to learn, but it was a bit confusing until I learned about the Scrapy shell which made things ALOT easier for debugging what was being scrapped. I unfortunately missed a pretty big bug in how the inner was decided simply because in MMA, there are 3 outcomes; a winner, a draw, or a no continue. I had to spend one night staying up a bit late patching it so one of my teammates could finish up the progress report before Thanksgiving. Luckily I got it fixed and everything went smoothly from there.

I have really enjoyed the course thus far because it has provided a relative close real world example of what being a coder is like (I think anyways). Having to do extensive research before even getting to code and having to deal with various needs and wants from my teammates has been a different experience and pace from other classes thus far in the course. I cant wait to see what our team builds in the coming months.

Interestingly I have decided, at the moment, not to purse a job in tech industry. I have applied and made it through the final set of interviews for a job as a full time career firefighter. I will know whether I got one of the 2 available jobs come Monday or Tuesday. Ranking in the top 5 as well as ranking number 2 has been a great confidence boost, as well as has given me experience in interviewing that I had lacked up until this point in my life. Regardless of the outcome, if I get picked or not from among the top 5, I’m happy with where I got.

Have a great rest of the year and happy holidays to whomever reads this! Bye.

Hello,

It has been awhile since my last post. Since then a lot has happened! I was invited to join a project on building a prediction model for Mixed Martial Arts (MMA). The group consists of 4 of us, those being James, Colin, Vili, and of course myself. So far the development processes has consisted of entirely of research and documentation. We all have invested a lot of time in determining how exactly we are going to both build a algorithm as well as store the vast amount of data for the algorithm to process. This initial process is crucial for the coming terms as it lays the foundation for us to be able to build a functional program.

Even though we are in the documentation stage we have hit some roadblocks. Initially we had our weekly meeting set to be on Thursday. however, since all the assignments are due on Thursday, this left us with very little time in order to get any problems corrected before the submissions deadline; which was only a few hours after the meeting ended! We decided that Mondays were best to have our weekly meetings and that we should probably continue to meetings on Thursday but instead they would be for the assignments due next week; not the ones due that night!

One exciting development with the project is the potential to implement machine learning. One of our team members, Vili, is very informed and has a lot of experience with machine learning (more then the rest of us anyways). Although it is a stretch goal we hope to be able to implement machine learning in some way to help bolster our prediction models accuracy rating.

During all this I have continued to work on my other 3 classes that I have going on at the same time. I have also been working full time as a part time employee (full time hours but not a full time employee) at my local fire department. Some interesting developments within the department was the opening of two career positions. I have applied for them and may have an interview within the next two weeks for the spots! Hopefully, Iam able to get on, otherwise I will probably be hunting for a job that actually involves using my Computer Science degree!

Here’s hoping for the best. Until next time have a great day!

Hi!

My name is Josh, and I currently live in Oak Harbor, Washington. Oak Harbor is a decently sized city located on Whidbey Island, which falls into the Pacific Standard Time Zone (PST). During my free time, I mostly enjoy playing video games. I started with action shooters such as Halo and Call of Duty when I was younger. As time has gone on, I found that I enjoy games with more meaningful goals and gameplay loops instead of a meaningless level-up rank. Survival games ultimately won me over, especially those that incorporate strategy, such as games like Don’t Starve Together, Terraria, Stardew Valley, and RimWorld to name a few. My earliest and all-time favorite game, however, is RuneScape. Other hobbies I enjoy include Magic: The Gathering, lifting weights, watching movies, and going on hikes with my wife and dogs.

Video games are the original reason I got into computers. I would constantly try to modify game files and run mods on various games. I attempted to write scripts to automate tasks in games to make my playtime more efficient (I admit to blatant cheating, I know). I never delved deeply into software programming when I was younger, but this early exposure is the main reason I wanted to go to school to learn programming.

Although I love video games, my time at OSU has not been focused on game development. I have instead geared my degree more toward Human-Computer Interaction (HCI) by earning a minor in psychology and taking psychology classes related to Computer Science.

Interestingly enough, my current job and work experience have nothing to do with computer science. I currently work as a part-time firefighter in my hometown and was previously a combat medic in the Army. I am trying to get hired full-time as a career firefighter within the next two months, and if I do, my computer science degree may not see much use after I earn it.

That being said, there are a couple of projects that really interest me, specifically game design projects, as I would love to gain experience building some sort of game. These include from the project portal:

1. HTML 5 Tower Defense Game

2. Online Trading Card Game Maker

3. Text Adventure Game for Education

4. Build an Emulator and Run Space Invaders ROM

Thanks for reading this far, and have a great day!