CollaTed Terms

At this point, our team is indeed knee-deep in development. We are familiar with our tools, or our “tech stack” and the benefits and limitations of them. Vue.js provides an excellent framework for creating a single-page web application, Flask is a reliable and easy-to-use server framework, as is MySQL for our database.

The steepest learning curve has probably been learning how to use Vue.js. As a component based front-end rendering framework, it is similar to React, with some minor differences. Setting up the router was straightforward, and the division of HTML-like elements into file-based components is familiar.

The current version of Vue.js allows developers to use one of two APIs for creating components, “Composition API” and “Options API”. When I was first reading through the docs and learning with various tutorials, this wasn’t immediately clear to me, and I was mixing methods from each of the APIs. When I re-visited the Vue.js documentation I realized I had to choose one, and I made this choice solely based on what the majority of the code currently supported.

The main difference is that “Options” follows a declarative approach to creating components and their associated data and methods. The “Options API” is the more “traditional” method, used in older versions of Vue.js, and the “Composition API” is newer. “Composition” allows for a little more flexibility, which has proved to be beneficial as someone using it for the first time.

“Composition API”‘s more flexible structure has also allowed us to make changes to the application a little more easily, and it proves to us that we can continue to make these changes. For example, we originally intended to use different git branches to have different versions of the application available to show the various vulnerabilities we are researching. Recently we decided to change this, and to use multiple endpoints in the server to explore different vulnerabilities. Changing the server to fit this was trivial; we just created more endpoints and adjusted our naming scheme as needed.

From the front end, we needed a way to call these different endpoints based on a user’s input. We wanted a global state variable that could be toggled, for example, a “sqli_vulnerable” boolean variable that could be checked to determine which server resource to fetch. Luckily, Vue.js has an unofficial/official state management library called “pinia”. It was actually very easy to implement this library, and I think it will provide an excellent way to manage state variables for this purpose, and it could be utilized later to provide other features to the application.

There are many articles and resources that guide developers on how to write “clean code.” In A Guide on How to Write Clean Code [1], Maryam Dashtirahmatabadi lists seven rules to follow that will result in “clean code,” including principles of DRY (Don’t Repeat Yourself), SOLID [2], with a few more general rules like “Write testable code” and “Code should be readable.”

These are all good tips but the article is brief, and Dashtirahmatabadi doesn’t quite touch on the implications of writing “clean code.” In another article I read, The Art of Writing Clean Code: A Key to Maintainable Software [3], the author touches on the real importance of writing code that is maintainable for future developers and collaborators. It is the obvious requirement that good code can be compiled (or interpreted) by a machine, but it is equally important that our teammates and other contributors can parse out vital information from our code base(s).

My experience so far in the capstone project has been mostly developing solo, but this week we had a meeting in which I walked through my code. I opened files and explained what each method and component does, while running the project locally. This went well overall but it certainly exposed many weak points, inconsistencies and redundancies that we clear to me, even though I had just written most of it in the last two months.

Something that is contributing to the slight mess is that I am trying to implement server methods with varying degrees of security in mind; some things should be designed poorly, with the intent of changing the code between different variations of the entire app. This has led to some whole segments intentionally commented out, with vague notes about what might be a better practice.

The snippet above shows a clear example of bad coding practice, with a comment about what might be a better idea.

A big hurdle this term is going to be organizing how we handle these types of variations. We have discussed having multiple branches in the repository that will deploy versions of the application with varying levels of security. This introduces a more general scope of clean code; organizing branches and providing clear instructions and documentation about how to use them.

In the same code, there is an example of good commenting. When another teammate initially read through the code, they added comments for each dependency and some of the initial setup steps:

I look forward to the rest of this quarter, because more of the team is going to start developing, and there will surely be questions about best practices, refactoring and cleaning up small messes that will contribute to a better product overall.

References

1. https://medium.com/swlh/a-guide-on-how-to-write-a-clean-code-776ce278755f
2. https://en.wikipedia.org/wiki/SOLID
3. https://reflectoring.io/clean-code/

The most significant development since my last post is the adoption of a somewhat standard method of separating different versions of our test application. We needed a way to have different iterations of the application, and git provides this natively as a version control tool.

Until this point I had been pretty comfortable using the basic git commands like “commit”, “push”, and “pull”, but this becomes routine and I would typically be using my own projects and committing to “main”. The stakes were low.

In this case, I am providing instructions, not only for my team members but also for anyone in the future who wants to test out the project for themselves. The naming conventions and steps don’t have to be “easy,” but I still need to document them. We also decided to include either a document or web page that guides a user through set up and installation, as well as exploring all of the vulnerabilities of the application.

I always appreciate good documentation when I start using a new tool, so I am challenging myself to be clear and concise with the write-ups and instructions for this project. The repository is already somewhat large and convoluted, with SQL scripts, server code and front-end code all occupying the same space. I am almost obsessive when it comes to this kind of documentation and I can see that I will need to place some guidelines of my own to avoid going down any documentation rabbit holes and wasting a bunch of time.

In the end, some of the naming conventions and git practices we decided on are not all that complicated, and it seems like it was a lack of this type of information in earlier design documents and discussions that made it seem urgent at this point. Going forward will be easier with these standards in place.

As we near the deadline for publishing version 0.0.1 of our project, there are some tasks that have quickly become time-consuming and feel somewhat re-iterative. A significant portion of our project is the creation and modification of a full-stack web application. We use a MySQL database, a Flask server/API and VueJS for our front end. We all have experience building this type of application, and it is not the focus of our project. I have discovered that the more important aspect of our work will be in researching security vulnerabilities and writing reports based on them.

When we first met, one of the team members suggested we use the code editor Cursor, which is a fork of Visual Studio Code, but with AI tools and automation built in. I had the chance to use Cursor this week when we started coding version 0.0.1, and it was almost a revelation. Instead of manually writing SQL queries to create a database, tables and sample data, I wrote a prompt describing the tables and Cursor created a SQL script for me. I started editing some of the fields and the auto-complete feature made changes accordingly in the rest of the document. I still spent some time editing, fine-tuning and debugging the application, especially when it came to integrating the API and the database server, but having Cursor complete the somewhat mundane aspects of the task was really nice.

As the project goes on, we will have to create new and more secure iterations of the application, so having a tool that automates the easy stuff will become quite valuable and allow us to dedicate more time to write ups and presentations.

Now, of course, everything comes with a price, in this case literally. Cursor has three tiers, and the free one only allows a certain amount of “tab completions” or code suggestions. This may be a limiting factor soon, and it has led me to start researching other AI solutions. I will probably try a few Visual Studio Code plugins before I consider paying a monthly fee for a code editor.

Term: naive

As mentioned above, our general task is to create a web application with certain vulnerabilities and to re-iteratively redesign the application to address those vulnerabilities. As I get into coding and actually designing this application, I am finding it a little difficult to intentionally make it “bad” or “naive.” The tools that exist for databases and servers are built around making it easy to do things right, and finding workarounds to make things “poorly” is becoming more of a task than I thought it might.

For example, the default server design for Flask interacting with MySQL is that of an object-relational mapper, where you can just write object-oriented Python code to create queries on the database. I had to look up how to execute a text based SQL script (to be intentionally subject to SQL injection).

Hello, my name is Ted and this is my blog. Here I will record and reflect on particular themes, or terms, that I encounter as I finish the remaining quarters, or terms, of my education. In particular, I will focus on the lessons, experiences and trials that will culminate in my senior capstone project.

I have been attending Oregon State University since the Fall of 2022, and I expect to graduate in the Fall of 2025. I live in a hundred-year old home made from hundred-year-old timbers in the Central District of Seattle, with my lovely partner, a few house plants and vegetables and plenty of spiders. I work as a manager at a cafe/bike shop, which combines two of my interests: food and bikes.

Another interest, one that I will be exploring and sharing with this blog, is creating useful technology. When I started learning the basics of programming and web development I experienced the instant gratification of writing a few lines, entering a few commands and watching the fruits of my (very low-effort) labor display on the screen. I am excited to start work on a project that will have real-world implications and which will expose me to industry standards and peer professionals.

I mostly have experience with web technologies. I like working with React, and I have been dabbling with Typescript because I enjoy the slightly stricter and seemingly cleaner practices in strongly-typed languages like Java and C.