Category: Uncategorized

Introduction

Every project comes with its own set of challenges. These range from technical to personal in nature and with varying degrees of difficulty in their resolution. These challenges provide the opportunity to flex your problem-solving skills and often can lead to greater understanding of the people and tools that you are using.

Unwinding Dependencies

Perhaps the greatest challenge that I’ve faced in our project was very recent and allowed me to gain a greater understanding of some of the fundamental tools that come with Python out-of-the-box. Our project is focused on developing a web application that allows its users to create algorithmic stock trading strategies. This project relies heavily on historical stock market data, for which we use the yfinance Python library.

Two weeks ago (the week of 2/17/2025), Yahoo Finance changed their API which broke most versions of yfinance. For most stock tickers, yfinance would return zero results with an error message stating that it was possible the stock had been delisted. These changes were far reaching, with a number of posts from StackOverflow, Reddit, GitHub, and niche stock trading forums all having the same issues. Our project was at a bit of standstill – we couldn’t perform much testing without the data. Our frontend team was effectively the only functional area that could still perform work and verify its integrity.

The same day we found the issue, yfinance released an update that corrected the issues. It turns out that Yahoo Finance had changed their API which led to the downstream issues in the yfinance library. The solution was to simply upgrade your yfinance version to the most recent release. This notion is great in theory, but our project is the culmination of several years of work and leverages some dependencies that aren’t necessarily deprecated, but also aren’t the most recent versions. With this in mind I began working on a solution.

The first step was to verify that the solution would work – I stood up a test project and installed the latest version in a virtual environment and attempted to fetch data. When this worked, I tried the simplest form of troubleshooting and simply upgraded the version in our project’s requirements.txt file and reinstalled the requirements in my virtual environment for the project. While I hoped it would be, the solution wasn’t this simple. I was getting a different error message though, so I knew I was making progress.

The next step was to resolve an error that was occurring regarding our inputs to the optimization component of our project. The error stated that strings were being passed to the optimizer and that they couldn’t be resolved. This hadn’t been an issue in the past, so there must have been some explicit type-casting that was removed from the yfinance library. Explicitly casting our user input to the type that the library expected solved that error message. However, this wasn’t the end of the climb. This yielded a new error message.

The next issue that arose was a date format error that occurred in an indirect dependency to our backtester. Older versions allowed for date-formatted strings to be passed to our backtester, but newer versions moved away from this and required explicit dates to be passed. However, version 2.4.3 still supported the methods that our project uses. Rolling this dependency back to this version cleared the error message and allowed us to start our controller and frontend simultaneously.

Basic Python

While none of this required any high-speed Python, it did require some intense problem solving sessions as many of the error messages had traces exceeding 100 lines. In addition, it got me far more familiar with Python’s virtual environments and experimenting with varying versions of the Python Interpreter – something that I hadn’t dug into much in the past.

Uninstalling and reinstalling virtual environments over and over was tedious, but it allowed me to understand their benefits. I could containerize my changes to a new virtual environment, test them, and when they didn’t work I could delete the virtual environment, rollback my changes, and try something new. All of this done without affecting my computer’s base Python environment.

This experience also got me familiar with having several versions of Python installed on my computer and setting my virtual environment to run with an interpreter that was different than the one I use for my personal projects. I was able to test my changes with Python 3.9-3.13 while still being able to do other work with Python 3.13.

Conclusion

While challenges aren’t always fun – especially when they include unwinding a web of dependencies – they do provide unique opportunities to dive into the “dark corners” of our skills. These dark corners can be areas we haven’t had to explore previously, areas that we’ve been avoiding, or areas we simply haven’t had time to explore in our skillset. However, when problems like these arise, they facilitate a need to explore them which can be one of the greatest motivators for knowledge gain. Unwinding the challenges that we faced with the yfinance library did just that for me with respect to the Python Interpreter and virtual environments.

The Project

Our team is working on a cloud based web application geared towards testing and creating high-performant trading strategies for investors. This project has exposed me to not only new technologies, but new APIs for technologies that I was already somewhat familiar with. I have primarily shifted into creating route handlers for the backend of our web application using Flask. Previously I had very minimal exposure to Flask, having mostly only heard about it. It has quickly become my favorite technology in our stack. On the other hand, working with backtesting.py proved to be challenging for me and I was wildly unsuccessful at using it compared to my peers.

Flask

Having worked with model-view-controller architectures in the past, I was exposed to route handling via JavaScript and was hesitant to make the leap to Python to achieve the same ends. However, I have found that Flask appears to be even easier than JavaScript for setting up routes and getting them to operate properly.

I will be the first to say that I am not a huge fan of JavaScript – I think that its syntax is unintuitive (as well as some of its comparison results). However, I do understand that it is one of the most powerful languages to use when working with web applications. For this reason, I was hesitant to move away from it for route handling for our projects. However, after spending a week working with Flask and trying various things out, I feel that it offers a much more intuitive – but just as powerful – opportunity to handle routes.

A route in Flask is simply a Python function with an @app.route() decorator attached to it. This decorator takes relative path and request methods arguments and binds them to the application so that they can be reached by others. Then, the request is automatically passed to the function the decorator is applied to and the function executed. This means that with just a handful of lines of code, you can create complex route handling logic that performs whatever task you want. For its intuitiveness and ease-of-use, Flask has become my favorite technology in our stack.

Backtesting

I won’t try to convince anyone that backtesting.py is bad technology – it is a large, highly used project with a lot of great features. I think that our collective experience as a team with backtesting.py was less than ideal because we were trying to reshape its out-of-the-box functionality to meet the specifications that were being supplied to us from another backtesting solution.

This was particularly difficult because of the way that each of the backtesting solutions handled the warm-up period for trades, which is the amount of historical data to use to “warm-up” the backtester. The two libraries used different methods and definitions for these warm-up periods, which ultimately led to the need for manual manipulation of the warm-up data in backtesting.py. In addition, I do not have much background in trading which made learning the library even more difficult, especially as trading-specific terms were used regularly in the documentation.

I don’t believe backtesting.py is a bad technology by any stretch of the imagination, however diving into the weeds of the library turned into a very long ordeal for me – longer than was realistically available for our team to meet our project requirements in the time we have in the capstone courses.

No Bad Technology

I don’t necessarily believe in the idea of “bad” technology – most technologies are developed to be used by one person or another. However, that does not mean that individuals won’t have preferences in what they use. I have enjoyed my time working with Flask much more than I enjoyed my time with backtesting.py. That’s not to say that Flask is better than backtesting.py, it’s just that I have found it much more intuitive and easy-to-use than I found backtesting.py. Perhaps this is because I’m much more familiar with programming and the topics under its umbrella than I am with trading. Either way, I’m glad to have shifted from working on the stock-specific technologies to the more computer science related technologies.

Clean Code

What is “clean code”? While readability might be the first thought when answering this question, it is also important to understand that clean code is also easily understandable and easily modified. In Mfonido Mark’s article “Writing Clean Code: Best Practices and Principles,” (https://dev.to/favourmark05/writing-clean-code-best-practices-and-principles-3amh) some of these principals are outlined. Mark also outlines the benefits of writing clean code, which can include increased readability, increased maintainability, better opportunities for collaboration, reduction in bugs, and increased efficiency.

Mark goes on to identify a number of practices that promote clean code and foster the benefits of writing clean code. While we (as developers) often like to think that our code falls into the category of “clean”, it’s also important to be critical of our own coding styles and work to adhere to best practice standards in order to facilitate a more efficient and product professional environment. After having read Mark’s article, I reflected on some of these practices and saw room for improvement in my own coding practices. Moving forward, there are a few of these clean code practices that I realized I could improve upon:

• Keeping Methods and Functions Short
  • My own style often puts too much into a single method or function – after all, “calculate_price()” should be calculating the entire price, right?!
  • Realistically, a function like calculate “calculate_price()” should depend on getting the totals of the user’s items, calculating the total, applying discounts, calculating the tax, and adding all of those numbers together.
  • Having functions like this more modularized allows for much easier collaboration and modification in the future. If the sales tax changes at some point in the future, or how sales are taxed is changed, it becomes much easier to make that modification without affecting any other entities.
• Using Comments and Documentation
  • I am notorious for “over-commenting” my code. While I don’t comment every single line, I do often create a pretty granular overview of what exactly my code is doing.
  • Mark’s article points out that your code should be self-explanatory rather than heavily commented, but that comments should still be used for complex algorithms and decisions and public APIs.

Again, without this period of self-reflection, I likely would have continued coding in a way that doesn’t quite align with “clean code” best practices. And in turn, I would have continued to produce code that was not as readable, understandable, or modifiable as it could have been. By taking these tips into consideration, I am able to be more effective as a professional and as a developer.

Code Smells

In Georgina McFadyen’s article “Common Code Smells” (https://8thlight.com/insights/common-code-smells), McFadyen explains that developers often get caught up in creating sound logic and handling of things like edge cases. However, as McFadyen points out, that often leaves much to be desired when thinking about maintainability and other issues that don’t change the essence of how the system works. Code Smells should be thought of as an indicator that a piece of code should be refactored – much like a foul smell in your refrigerator may indicate that it’s time to clean it out.

Again, as developers we all like to think that we are adhering to best practices when it comes to clean code, but it is important to reflect on your work and identify areas that can be improved upon. For instance, McFadyen points out some of these smells that almost appear to be directed at me:

• Data Clumps
  • This smell refers to cases where method calls take the same set of parameters across different calls.
  • This smell can indicate that these parameters are related and can be combined into a class to represent an idea or an object.
  • Addressing this Code Smell can improve the organization of your code.
• “Primitive Obsession”
  • Often it is easier and quicker to assign values to a primitive type in order to accomplish our goals. However, using primitives for these means is not always effective at communicating to others what that primitive is representative of.
  • In these cases, it may be beneficial to create a basic class that better communicates that idea. McFadyen’s example is a string variable called “id” that needs to be validated. While we (and others) may have an idea that this is an identifier of some type, we don’t know what qualifies it as valid.
  • In this example, we can wrap the “id” into a “ProductId” class with a validation method. This change can allow others to go read this class, understand that it is an identifier for a product, and understand what makes these identifiers valid.
  • These changes can better communicate to other developers what the intent of the ID is.

It’s Important

By striving to improve the cleanliness of and working to eliminate the smells in our code, we not only improve ourselves but also enable those around us. Even though we all might think that we are doing our part to keep code clean and smell-free, it’s also important to take a moment to step back and reflect on what we can be doing better. Keeping your code clean and free of smells allows for increased effectiveness and efficiency of not only you, but your fellow developers.

As the term begins to wind down, I find my time being stretched more thinly than it has been the rest of the quarter. Final projects, exams, and gearing up for the holidays with my family have all required more of me and the time that I have throughout the day. While this part of the term has always been the most stressful, it provides unique opportunities to practice and hone some of the skills that it requires me to use.

Prioritization

The first of these skills is prioritization. Will missing out on family events be worth the extra couple of percentage points of a grade that marks the difference between a high and low A? After all, an A, even if on the lower end, still reflects a 4.0 for a course.

This is a special time of year – and time of my life – in which my children are very aware and excited for the holidays. These times are ones that, if I miss them, I won’t get them back. Knowing this has allowed me to set healthy boundaries both professionally and educationally and set aside my perfectionism to complete tasks adequately, but not necessarily perfectly. For me, my educational journey has been primarily for my family’s future and my desires have been secondary to that. I do thoroughly enjoy the field and material, but if it were not something that would help my family be more successful in the future I would not be pursuing it.

Goals

The demand by my family and my courses for my time also allows me to be introspective about what my goals truly are. I aspire to graduate Summa Cum Laude, and am on pace to do so. However, for me it is not the end of the world if I don’t. If it means missing one-time experiences with my family, I will gladly sacrifice that goal to be present with them. On the other hand, graduation has been my priority for going on five years now and I cannot sacrifice my chances of achieving that goal, even if it unfortunately means that I miss out on some small moments. I’ve got three quarters left and after those thirty weeks of classes (with plenty of time off in between them) I will be able to present for every moment. This time of year has always been a difficult one since returning to school, but also allows me to be more fluid in my goals and adjust them to what is really important to me.

Determination & Senioritis

This quarter has been especially difficult because of the fact that I can see the “light at the end of the tunnel” as it relates to finishing my degree. I’ve heard this go by a number of names, but the one that has always stuck with me was ‘Senioritis’. Knowing that I’m nearly done after having put so much hard work into completing my degree has lulled me into a state of dragging my feet and lacking motivation to finish as strongly as I have started. This was much more apparent for the first portion of the quarter, but thankfully my determination has kept me from falling into a rut. Taking a little bit of time to reflect on my goals has helped to keep me focused on what I need to do to achieve them, though I still have found myself procrastinating more than usual.

I’ve also had a hard time figuring out whether it’s actually ‘Senioritis’ or a lack of interest in some of my classes. Half of my classes this quarter are courses that I’m not particularly excited to take or have had a number of problems which have turned me off to them. However, for the other two (this course and Open Source Software) I have still felt very motivated and interested in. This would lead me to believe that maybe it’s just a quarter that I’m not excited about but am on the verge of completing and can soon look back on as a bump in the road.

Conclusion

While this time of year presents its own unique difficulties as a student, an employee, a father, and a husband, it has also provided me the opportunity to exercise some of the skills I’ve built throughout my life. Balancing special moments with my family with successfully and adequately completing my coursework has allowed me to practice my prioritization skills. Those same difficulties have allowed me to be introspective about my goals in order to make those prioritization decisions. And finally, knowing that the end of my educational journey is nearing and the lack of motivation that it has passed along has allowed me to showcase my determination towards achieving my goals.

Navigating Large Workloads

This term at OSU has been one of the heaviest workloads that I think I may have had throughout my time in the program. While unexpected, the challenges that come with balancing the needs of all of my courses has presented unique opportunities for me – especially as my team and I work through our Capstone project. I am typically the type of person who will add more to my plate (sometimes absurdly) in order to make the lives and work of my teammates less stressful and easier. However, this quarter I have had to learn to let others be responsible for their share of a project in order to help ensure that I am successful in all of my courses. I still find myself trying to take on more than I probably need to, but I have found that it is beneficial to encourage everyone’s participation rather than taking on too much work.

Differing Approaches to Work

In addition to learning to encourage others to be more involved in our project, it has also been difficult for me to adjust to the various approaches to work that are present in our group. I am typically a very plan oriented person who tends to work ahead in order to try and head off any potential issues that may arise. In previous group assignments I had the opportunity to choose my teammates and often tried to align course schedules with peers that had similar philosophies – often I was working with friends who shared the same outlook.

This course has required me to be much more adaptable to others’ schedules and approaches to completing assignments. It has been rather challenging for me, especially with my personal responsibilities, including ensuring that I am staying present as a father and husband. This need for adaptability has led to some long nights in order to ensure that everyone has contributed to the assignment and had a chance to look it over before it gets submitted.

With all of this being said, I still think that I will stick to my philosophy of working ahead in the future. I think that the added stress of trying to put a bow on a given assignment the night that it’s due is not conducive to complete, productive, and effective work. However, this project has made me understand the difficulties and intricacies of navigating deadlines and due dates when groups of individuals – with varying lifestyles, timezones, and obligations – come together.

What’s Next?

Navigating a large workload as well as working with a group of individuals that I’m not very familiar with has posed unique challenges this quarter. However, these challenges have also allowed me to develop a more empathetic and understanding outlook when schedules don’t align perfectly or hiccups occur. The main thing for me to focus on is being vocal about my concerns regarding last minute work and expressing my concerns and interests to avoid it. While this is not always possible, it at least lays my concerns out on the table in an attempt to make the situation more inline with my outlook. Moving forward, I will be more proactive in working to ensure that we have at least a window for corrections in the event of unforeseen circumstances.

Who am I?

Hello, everyone! My name is Tyrell and this is the start of my journey through Oregon State University’s nine-month capstone courses.

I currently live in western Montana and relish in the outdoor opportunities that my home state has to offer. I have a lovely wife and two beautiful children that I spend my time with, as well as our three Corgis! When I’m not on dad duty, I enjoy fishing, UTV riding, personal coding projects, and playing a variety of video games.

Why Computer Science?

I am a computer science student through OSU’s distance learning program and am nearing the completion of my degree. My journey to OSU and Computer Science is a bit long and scattered, but can be boiled down to a few core memories of my life.

When I was quite young – around the ages of four through eight – I was first introduced to computers by my father. He had an old Macintosh desktop – I couldn’t tell you the model, I just remember the color being a dingy tan color and how bulky the computer was. I was introduced to the device’s built-in “Paint” equivalent which I used to create various toddler drawings, and several text based adventure games. I really enjoyed the time I had playing around on that machine and I look back fondly on those experiences.

Following this machine, we bought a family Toshiba desktop when we moved to Montana. This machine was the first time that I got to really tinker with computers. We ended up replacing and adding hard drives and disk drives to this device as my dad would bootleg the shows that he directed at the local community theater to provide recordings to the cast members.

The next core memory that helped to pave the way for my entry into computer science was at a much later time in my life, in my early-twenties. I got a job in project management for a small software start-up that was developing GIS solutions for telecommunications company. The small size of this company meant that we all had to wear many hats, and one of mine was minor code changes that needed to happen when others weren’t available to make them. Seeing how complex some of our company’s systems were piqued my interest and got me interested in learning how to code in my free time.

The last of these core memories was the final catalyst needed for me to fully commit to pursuing computer science in an all-in manner and happened in my mid-twenties. I was interviewing for a new job with the owner of the company and he posed the question “What do you want to be when you grow up?” It seems like a silly question at first glance, but for whatever reason really got me thinking about what it was I wanted to make into a career. As I thought about this, I thought back on the memories I spoke of before, and eventually decided to pursue computer science. I haven’t looked back and have enjoyed every moment of it.

What’s Next?

Now that you know a little bit about me, what’s next? Well, this blog is intended to document a part of my pursuit to be a successful computer scientist, specifically my journey through the OSU capstone courses and the project that I work on through those courses. Along the way, we’ll talk about new (to me) technologies, goals, roadblocks, successes, and the courses themselves.

I look forward to making this journey with all of you!

Welcome to blogs.oregonstate.edu. This is your first post. Edit or delete it, then start blogging!