Category: Uncategorized

Hello again! Just in case you’re not quite in the loop, I am doing a Website Security Research Project where my team and I are developing a PHP Laravel application to be intentionally vulnerable so that we can penetration test it and be able to write descriptive documentation on it to teach about how vulnerabilities are exploited and manifested in code. I wanted to take some time to write about a technology that I am currently deeply entrenched with when it comes to some of my responsibilities in the project and is probably one of my most favorite technologies of all time, being GitHub Actions. GitHub Actions is a continuous integration and continuous delivery (CI/CD) framework that allows you to automate many things upon a Pull Request (PR) being made to your repo being building, testing, and deploying your application in a streamlined way. To do this within your repository’s, you create workflows files that are written in YAML and placed within the .github/workflows directory from the root of your project. With the workflow files, you can decide the name, when to run it, and the jobs that are to be run within this workflow. Every workflow file, when ran by GitHub Actions directly, is called an Event with a typical workflow file looking something like this:

This is an extremely powerful tool that I find to be a MUST in a developer’s toolkit for any project, and it even has a way to run it locally through the act command found here.

While this is great and all, for my project specifically it has been a help in one way and an unfortunate pain in another way. First with the positives, it has been great with making sure that the application builds successfully when someone is adding something through a PR so that we all know that it is good to go. This is where the positives stop, however, as there has been a new problem with running the newly made Feature Tests with the application. Currently, the main way to run the tests against the Docker container that our application is hosted in is to use ./vendor/bin/sail test. The problem that we are running into, however, is that when the event to run the tests within the job gets ran, all the tests fail, saying that they cannot connect to the MySQL database docker container that should be running when we build the application. To make matters even worse from a debugging standpoint, when I use the act command to try and create the environment that would be running on the GitHub Action servers locally, the tests work, so I am in a special kind of debugging problem of it works for me but not them. GREAT!

Even though everything isn’t sunshine and rainbows, we can start with thinking about what could be wrong and possible solutions to this issue. From my understanding, because we are using workflows that do a lot of the setup for the Docker network, which allows all your containers (application, MySQL, etc.) to communicate with each other, make the networking between the application and database be misconfigured. Another idea is that this might be a timing issue, where the Docker container for the MySQL database isn’t ready yet. Looking towards solutions, however, there might be something that could solve this on the way as my teammate Cody has been working on a more streamlined way to build the application and run all the necessary commands to add tables and data into the database with error handling of waiting for the MySQL Docker container to be responsive before moving forward with building the application. If this doesn’t work, there are still some ideas about checking the database through a command like this ./vendor/bin/sail exec mysql bash -c 'while ! mysqladmin ping -h"localhost" --silent; do sleep 1; done' within the workflow, but I am still learning the ins and outs about how the networking works within GitHub Actions, especially with the buildx workflow. I could be on the wrong track through my debugging, though I have to start somewhere so knowing what isn’t working first is the best way to know what will in the future!

Thank you for reading my post!

Intro

Welcome back everyone and hope that you’re having a great 2025 so far! Today, I wanted to take some time to talk about good and bad coding principles, as I am someone that likes to be as thorough as possible to make sure that anyone of any skill level can read and understand the code that I write. Through exploring the philosophies of Clean Code which was a book written by Robert C. Martin, and Code Smells which was popularized by Kent Beck, I feel that these two philosophies of writing code can help with reaching the goal of making my code accessible to anyone that is extending my code or understanding my code.

This code smells bad…

Let us start with our exploration into Code Smells. When programmers work on an application, we tend to see a few patterns or the way we structured our code that need to be refactored, like repeating code (not following the DRY principle) or code that is dependent on other code. Now these aren’t bugs by any means but can signify weakness in the design of an application and might increase the risk of bugs and program failure in the future if not addressed now. These patterns are what programmers call Code Smells and there are two main types of them being Within Classes and Between Classes.

NOTE: I will not be covering everything between the two types as that would make this blog post unnecessarily long, but I will cover some code smells and provide code examples. For a more in-depth explanation and examples of code smells, you can check [1] in the citations section.

Let us start Within Classes and expand our scope from there. One of the easiest examples of a code smell that may seem counterintuitive is code comments, as they can be proof that the code is not self-documenting to the programmer reading the code. Take the example below to validate an age in python:

This code is not self documenting as it is both hard to look at the way the validate_age function calculates the age passed in but to make it more self documenting, you can split up a lot of the functionality into named functions that describe the code being written:

Ain’t that pretty on the eyes now! While not the only Within Class code smell, it sure is an important one that makes a world of difference.

Onto the Between Class code smells with Data Classes. Data Classes are classes that just store data and has no methods to manipulate that data within it. Let us say that you have a Temperature class and want it to store data only, then you would do something like this:

But what happens when you want to update the temperatures in the Temperature class? Well then you have to make that global function to operate on data which smells a little too much like rotten fish to me 🤢. Data classes are not always a bad practice, as they can be important in being a clear structure to hold data when transferring data between systems and when you are implementing the “separation of concerns” principle where data structures like Temperature and actual code logic are stored separately. However, you need to make sure that when you are using a data class that should have behavior, like updating the temperature in this case, that the class is then developed with methods in mind to do such a task and not have the code else where so we can update the code to look like:

This smells like a much better cooked cod to me than anything else😃.

But we can make it clean(er) again!

• When talking about clean code, it is not always easy to discern what someone is talking about because certain people have certain standards when it comes to how they define their code as clean. However, Robert C. Martin wrote a book about certain conventions, standards, and practices that are still used today to determine the cleanliness of how source code looks. Assessing a code base for following clean code standards is a little tricky but you can tell if a coding project follows these conventions for clean code through aspects like
• Effectiveness, Efficiency, and Simplicity
  • We first want to make sure that the code solves the issue that it was set out to solve, then if it does so efficiently, lastly if the solution is done in a simple manner.
• Format and Syntax
  • The main point here is really to just make sure that the format of indentation and consistent syntax across the entire project is paramount here. For python, you can think of PEP8 being the sort of style guide you need for your code to follow.
• Naming
  • Naming variables and functions clearly and descriptively can help developers quickly understand what the variable or function is doing, and how it is related to the rest of the code.
• Conciseness versus Clarity
  • When developing code, you need to be careful to strike a balance between the two as concise code improves readability and maintainability, but it being equally important to ensure that the code is clear and easy to understand as over concise code can interfere with the readability of code.
• Reusability
  • Reusability is all about improving the efficiency and productivity of development by reducing the amount of code that needs to be written and tested.
• Having a Clear Flow of Execution
  • Making sure that your code follows a clear and logical structure makes it is less prone to errors, and easier to modify and extend which makes it more efficient in terms of time and resources in the long run.
• Using the Single Responsibility Principle
  • This principle states that each class or module should have only one reason to change. You can think of this as making sure that a function is only doing one step to your solution.
• Having a “Single Source of Truth”
  • This principle means that there is only one place where a particular piece of data or configuration is stored in the codebase, and any other references to it in the code refer back to that one source. Think of an API key. This is important because it ensures that the data is consistent and avoids duplication and inconsistency.
• Only Exposing and Consuming the Information you need
  • This principle is more important when you are working around with objects, as you should only extract and use the specific data you need rather than passing around entire objects. Exposing and Consuming the information you need is best for the efficiency of the application in the long run.
• Modularization
  • Basically just make sure that you’re breaking down large, complex code into smaller, more manageable modules or functions as it makes the code easier to understand, test, and maintain.
• Project Structure
  • A well-organized project structure helps developers find and modify code easily, reduces code complexity, and improves project scalability and maintainability. Think about using directory names like build, src, test, etc.
• Documentation
  • This is probably one of the most important parts to me, as I have been on the receiving end of bad documentation MANY times in my software development journey. When code is well-documented, it can save time and effort in debugging and maintaining the code so proper code comments and outside documentation that describes code flow is important.

All Clean!

Thank you for reading until the end of this blog post! I had a lot of fascinating moments of learning about these principles and how I want to use them in the future with my current Senior Software Development Project. Specifically Modularization of my code, as I have been writing a lot of code that works first and need to refactor it soon so that I can follow the best principles for the rest of this project.

Citations

[1] GeeksforGeeks. “Code Smell – A General Introduction and it”, Geeksforgeeks, 08 Sep. 2020. Available: https://geeksforgeeks.org/code-smell-a-general-introduction-and-its-type/.

[2] G. Cocca, “How to Write Clean Code – Tips and Best Practices (Full Handbook)”, freeCodeCamp, 15 May. 2023. Available: https://freecodecamp.org/news/how-to-write-clean-code/.

A lot has happened since the last post on here. Mainly that the senior capstone project team that I am a part of to create a Vulnerable Web Application has decided that the best way to move forward with creating the application is through using a web framework called Laravel. This decision came off of the fact that a vulnerable web application we were going to use as a base was in PHP, and found that to make the development experience better we could switch to Laravel to do our web application in. I’m really excited to develop the web application but one of the blockers that I am having with the project is learning Laravel itself, so I wanted to take this blog post to try and teach what I’ve learned about Laravel so far to you so that I may reinforce the learning that I’ve done and teach you all something’s that might be interesting to you! Do note, this won’t be a full coverage of everything Laravel has to offer, you can find that here, but this will cover certain aspects of the framework that I learned about and how it pertains to my portion of work for the project.

First, one of the main things that you learn with Laravel is how it operates on a Model-View-Controller (MVC) architecture. Simply speaking, there are three logical components being the:

• Model: Responsible for representing database data and interacting with the database
• View: Responsible for presenting data to the user. Laravel does this through Blade templates that let you compile HTML with dynamic elements.
• Controller: Responsible for processing requests, retrieving data from Models, and passing the data to Views

Once you understand how the architecture that Laravel operates on, next is how a new project is structured, as defined below. Note that these are not all the directories that Laravel generates for your project, but I feel that they are the most important ones:

• App
  • Http/Controllers
    • PHP code files that represent the main logic for a webpage and interacts with your views and models.
  • Models
    • Representations of your database table and serves as a layer of abstraction for interacting with that data.
• Database
  • Contains database migrations, model factories, and seeds.
    • Can also house SQLite databases
• Public
  • Contains the `index.php` file as the entry point to the application.
  • Also houses assets like CSS or JavaScript.
• Resources
  • Where you will store your views (aka Blade template files).
• Routes
  • Contains all routing definitions within `web.php`.
    • `web.php` contains the routes themselves.

For me, after we set up the initial parts of the website I was tasked to making one of my webpages, being the Patient Feedback page that will house both Stored and Reflective XSS vulnerabilities. You need to create your database, models and controllers separately with a PHP tool called artisan, a command line tool that installs with Laravel once you created the project. Using the commands php artisan make:migration create_names_table, php artisan make:model Name, and php artisan make:controller NameController will create the database, model, and controllers respectively. For the view, you can create a file within the resources/views directory with the extension .blade.php where you can write HTML with some special Blade formatting. Next, within routes/web.php you can define the routes needed to access your webpage like this Route::get('/name', 'NameController@index')→name(‘name.index');, however, because we already have an authentication plugin installed almost all routes to our team’s web application will look like Route::get('/name', 'NameController@index')→middleware(['auth', 'verified'])→ name(‘name.index'); where middleware is just a mechanism for filtering incoming HTTP requests where this authentication middleware needs the user to be verified to access this page. Lastly is the database, located in database/migrations as there you define what the table you just created in the database will look like through the premade `up` function like this:

Moving forward with the controller and model, however, is something that is very dependent on the implementation of the web page you are trying to create and not something I fully understand right now. The commands that were talked about earlier will create outlines for you for both a Model and Controller, but it is up to you on how to implement the logic of the web page and how it interacts with the database.

Thank you for reading through, and I hope you learned something new today about how Laravel works and how to get started with developing in it!

Hello to everyone that found their way here! My name is Sean and I would like to introduce myself to you all and what my blog will be about.

First, a little bit about me. I’m currently a student at Oregon State University, going through their Computer Science degree program with a focus in Cybersecurity. Before I started this degree, I’ve been interested in programming since high school when I started with web programming with HTML, CSS, and JavaScript. Though, my interest in programming changed later to more system languages like python, where in my pursuit of knowledge I was also introduced to ethical hacking. Using my programming knowledge and this new passion for ethical hacking, I competed in multiple CTFs (Capture the Flag) tournaments to hone my skills until I got to college, where I could learn more things formally. Though moving away from my journey as a techy, I’ve recently been on more of a discovery of myself and have found new hobbies like rock climbing and hiking, though I have a big journey ahead to get good at rock climbing. Most of the social activities that I like though are DnD, video games (especially Guild Wars 2 and Minecraft), and just hanging out with my cat Kai.

Now let’s talk about what this blog is going to be about. I mainly want this blog to be two things, being:

1. How my senior capstone project is going through the nine months I have to do it.
2. Any interesting things I learned in my own research or other classes.

Breaking it down a bit more, I want my coverage of my project to be about any successes, failures, struggles, why’s and how’s, plans and detours that come along with any programming project. On the other hand, I want to talk about my learning journey and other cool tech news, as there is so much that I have to learn about in the tech industry. With having much to learn, I feel that being able to teach others about topics I am interested in will help with gaining a better understanding of the material at hand so that I can look at myself every day and say that I’m better at my career than who I was yesterday.

With all of that being said, I want to thank you all for reading this post about me and my journey, and I hope to see your guy’s comments to my learning journey!