In Fall 2024, I completed an essay for CS4100 that examined the differences between Java’s static type system and JavaScript’s dynamic type system. The goal was to analyze how the contrasting approaches to typing influence software development in areas such as performance, error detection, debugging, and long term maintainability.

Java is a statically typed and strongly typed language. This means that variable and expression types are checked during compile time. These constraints make it possible to detect errors early in development, improve predictability, and optimize performance. Java’s system ensures that a variable can only hold data compatible with its declared type, which reduces runtime surprises and makes the language especially suitable for large, complex applications where reliability is critical.

JavaScript, on the other hand, is dynamically typed and weakly typed. Variables do not need a declared type and can change types at runtime. This flexibility allows for rapid prototyping and quick iteration, but it also introduces the possibility of runtime errors that are difficult to anticipate. Implicit type coercion is common, and while it speeds up development, it can lead to unexpected behaviors. Debugging in large JavaScript projects is therefore more difficult, as type related issues may spread through the code before being caught.

The comparison shows that Java’s static type system promotes performance optimization, reliability, and maintainability. JavaScript’s dynamic type system provides flexibility and supports faster development cycles, particularly in small projects and web applications, but it comes at the cost of error detection and long term stability.

In conclusion, Java and JavaScript reflect two different philosophies in programming language design. Java favors strict control and predictability. JavaScript favors flexibility and speed. The choice between them depends on the goals of the project and the needs of the programmer.

You can read the full essay here.

This October, I got the chance to travel to San Diego for the 37th Annual GMiS Conference, and honestly, it was one of the best experiences I have had in college so far. I was lucky enough to receive a CAHSI travel scholarship that covered my travel, hotel, and registration. The rest of my school group came through our STEM program, and together we made the trip down from Turlock.

We arrived late that first night, around 10 p.m., tired from the long 10 hour train ride but excited for what was ahead. We checked into the Hilton Bayfront, which was hosting the conference, and tried to get some rest because the hackathon started bright and early at 7 a.m. the next morning.

Day 1: Cybersecurity Hackathon Kickoff. The first full day started fast with the CAHSI sponsored Cybersecurity CTF Hackathon. It was my first time competing in a capture the flag style event, and the same went for my teammates. None of us had done anything like it before, but we jumped right in, figuring things out as we went. We spent the day learning how to think like attackers and defenders, solving puzzles, and cracking small security challenges. Even though we placed 35th out of 70, I walked away with new skills and lessons that went far beyond the competition itself.

Day 2: Learning and Growing. The second day was packed with workshops. The one that stood out most was the coding interview prep session led by the Coding Interview Club from El Paso, Texas. Later that day, I joined a supercomputing workshop through CAHSI. It gave me a deeper look into large scale computation and parallel processing, which turned out to be a lot more interesting than I expected.

Day 3: Career Fair and Connections. The last day was the career fair, and it ended up being my favorite part. I met so many people, talked to recruiters, and learned about opportunities I had not even considered before. But the best part of all was the connections I made with my peers. I met amazing people like Nate and Albert, and the friendships that came out of this trip made it unforgettable.

Looking Back. On the train ride back home, I thought about how much this trip meant to me. I felt more confident in myself, more inspired to keep growing, and more grateful for the support from CAHSI and my school for making it possible. What stood out the most was not the tech or the talks. It was the people, the shared motivation, the encouragement, and the sense that we were all working toward something bigger.

In early 2025, I designed and implemented an automated invoicing system for Baron’s Cleaning Services, a DBA of Baron’s Construction Services, Inc. The cleaning division manages multiple day porter contracts that require monthly invoices for recurring service accounts. The goal was to remove manual work, improve consistency, and ensure invoices were always sent out on time. I built the system in Python, deployed it on Google Cloud Run, and scheduled it through Google Cloud Scheduler to run automatically once a month.

System Overview. The automation pulls all account and service data directly from the ClickUp API, which the company uses to track day porter work across multiple client sites. Each account contains nested custom fields such as Client Name, Address, Hours Worked, and Service Period. Using the requests library, the program retrieves the raw JSON data from ClickUp and parses the nested structures into a clean dictionary format. Timestamps are converted from epoch time to standard dates with the datetime module, and this data is then passed into a Jinja2 template that generates a professional invoice layout for each client. Once the invoices are generated, the system connects securely to the company’s SMTP mail server, authenticates, and sends formatted emails to each client contact.

Deployment and Scheduling. After testing the program locally, I containerized it and deployed it to Google Cloud Run. The process is triggered by Google Cloud Scheduler on the first day of each month. Each time it runs, the system starts the Cloud Run container and executes the Python script, pulls updated task and account data from ClickUp, formats invoices with the Jinja2 template, sends the emails through SMTP, and then shuts down automatically.

Preventing Duplicate Invoices. One of the biggest technical challenges was preventing duplicate invoices. I built a logging and verification mechanism that stores unique identifiers for each invoice, generated from a combination of the client name, account ID, and billing month. Before sending a new invoice, the program checks this log in Google Cloud Storage to confirm that the same identifier does not already exist. This safeguard ensures that no account ever receives a repeat invoice, even if a job is retriggered or interrupted.

Impact. Before the automation, invoices for cleaning accounts were created manually each month, which was time-consuming and prone to human error. After the system was deployed, the process became completely automated and consistent. The system now handles invoicing for all day porter service accounts, managing around $60,000 worth of invoices per year. It reduced administrative time, eliminated duplicate entries, and improved the speed and professionalism of client communication.

Reflection. Building this system reinforced how software engineering can directly improve real business operations. It combined backend development, data handling, and cloud automation to create something that saves time and adds reliability every month.

In my final semester at CSU Stanislaus, I worked on ScalpShield, a six-person group project for our E-Commerce Systems Design course. Unlike traditional classes that focus primarily on implementation, this course was built around the idea of problem finding. Inspired by Daniel Pink’s New ABCs, the emphasis was on identifying meaningful problems, designing solutions people would actually adopt, and clearly communicating why those solutions mattered. The final deliverable was not just a working system, but a 25-minute presentation where we had to sell the problem and the solution to both the professor and the class.

Our team chose to tackle ticket scalping and purchase fraud, a problem that affects event organizers, ticketing platforms, and customers alike. With automated bots and resale markets becoming more sophisticated, simply building a technically sound system was not enough. We wanted to design something that could realistically be used by a company, trusted by its staff, and integrated into real workflows. ScalpShield was framed as a SaaS product that companies could subscribe to, while still being flexible enough to integrate directly into an existing ticketing backend.

I was responsible for the backend architecture, machine learning integration, system documentation, and serving as the lead technical communicator for the team. I also led the backend portion of our final presentation and ran the live demo. One of my main goals throughout the project was to make sure everyone on the team understood how the system fit together end to end, so frontend, backend, and data work could move forward in parallel without confusion. With only four weeks to build the system, clear communication was just as important as clean code.

System Overview. ScalpShield was built with a Python FastAPI backend and an XGBoost-based machine learning model trained to identify suspicious purchasing behavior. The backend exposes an API that scores transactions in real time and returns both a risk score and an explanation of why a purchase was flagged. We intentionally prioritized explainability, because a system that simply labels something as “fraud” without context is difficult to trust or adopt. The frontend, built as a dashboard, visualizes this data through a live sales feed, flagged transactions, heat maps, and lists of the most suspicious users.

Live Demo and Adoption Focus. During the final presentation, I ran a live demo that simulated how a company using ScalpShield would interact with the system. The demo showed a staff member logging into the dashboard, monitoring a live feed of ticket purchases, and reviewing flagged transactions along with the reasons they were considered suspicious. Rather than focusing on the model in isolation, we framed the demo around how an operations or fraud review team would actually use the tool day to day. This perspective helped reinforce that ScalpShield was designed for people, not just for technical correctness.

Machine Learning and Explainability. The XGBoost model was trained on engineered transaction features that captured patterns common in scalping behavior. While the model achieved a confidence rate of around 95 percent, we were careful not to treat that number as the sole measure of success. Instead, we emphasized that explainability and integration mattered just as much. The backend surfaces why a transaction was flagged, which makes it easier for users to validate decisions, build trust in the system, and take action with confidence.

Working as a Team Under Time Pressure. With a six-person team and a four-week timeline, coordination was one of the biggest challenges. Clear documentation and shared understanding of system boundaries helped us avoid rework and bottlenecks. Acting as the technical point of contact, I made sure design decisions were documented and communicated early, which allowed everyone to work efficiently on their respective components while still building toward a cohesive system.

Outcome and Reflection. The project was a major success. The system worked end to end during the presentation, and the feedback from the professor and class was overwhelmingly positive. Our professor encouraged us to continue developing ScalpShield beyond the course, noting its potential as a real product. For me, the project reinforced an important lesson from the class itself: in a world where tools and AI make coding more accessible, the real value lies in finding the right problem, designing for adoption, and communicating technical systems clearly. ScalpShield was not just a fun technical challenge, but one of the most rewarding team projects I have worked on.