Brian Zavala

Welcome. I’m Brian Zavala, a Computer Science student at Southern New Hampshire University completing the CS-499 Capstone. This site is my ePortfolio: a single full-stack application enhanced across the three core areas of computer science, paired with the professional self-assessment below. If you would rather jump straight to the code, the projects section has a page for each enhancement.

Professional Self-Assessment

My name is Brian Zavala, and I am completing the Bachelor of Science in Computer Science at Southern New Hampshire University. This self-assessment introduces the ePortfolio I built across the CS-499 Capstone and reflects on how the work in this capstone, alongside the courses that came before it, has prepared me to step into a full-stack web developer role. The artifacts here are not a survey of unrelated assignments. They are three focused enhancements to a single application, Travlr Getaways, that together cover the categories the program is designed to produce: software design and engineering, algorithms and data structures, and databases. Each category is paired with a short narrative, a working code branch on GitHub, and a side-by-side comparison against the original starter so a reader can see exactly what changed.

What the program prepared me for

The most concrete thing I take from the program is the ability to read an existing codebase, find where it is doing too much or too little, and ship a focused change without breaking the parts that already worked. That sounds simple, but it requires a working knowledge of the languages and frameworks involved, an instinct for the patterns a framework wants to be used in, the habit of testing a change against the rest of the system, and the discipline to stop when the work is done.

The Travlr Getaways artifact gave me three turns at exactly that exercise. A first pass hardened the application’s seams: CORS, environment configuration, user-facing error feedback, and a deprecated HTTP client. A second pass fixed how the application moved data around: server-side pagination, indexed lookups, a typed price field, and a cached client store. A third pass closed the most visible security and contract gaps: bcrypt password hashing, refresh tokens, startup configuration validation, server-side input validation, and an API specification a future developer can actually read. Underneath those passes is the fluency the program built up over time: data structures and algorithms, software engineering practice across several courses, database design, and a security habit I now apply by default rather than as a separate review step.

How the work meets the program outcomes

Collaborating in a team environment. This was the outcome I had covered least at the start of the capstone, so I designed the database pass to address it directly. The API.md specification I added documents every endpoint, the token model, the bcrypt cost factor, and the required environment variables, in the shape a new developer joining the project would want to read first. The ePortfolio itself is a second example: each project page is written for a reader who is not in the room with me, frames the artifact for someone evaluating my work, and links to the source so a technical reader can verify the claims.

Communicating with stakeholders. Every deliverable in the capstone was written for two audiences. The milestone narratives explain what changed and why for an evaluator checking against a specific list of outcomes. The ePortfolio pages explain the same work for a future employer or collaborator deciding whether I can do this kind of work for them. Both need the same underlying facts framed differently, and I now treat that framing as part of the engineering work rather than something added after the code is done.

Data structures and algorithms. The algorithms pass is the most direct evidence. Server-side pagination changed an unconditional full-collection scan into a clamped, indexed page query with a structured response envelope. The findOne refactor replaced a multi-document query and an array-index check with the right query for the access pattern. Migrating the price field from string to number is the unglamorous half of the same skill: a data structure choice that lets sorting, range queries, and arithmetic comparison work the way the application actually needs. None of these are exotic algorithms. They are everyday design decisions, made in the spots where the original code had gone the other way.

Software engineering and database. Every category enhancement came down to an implementation choice. The functional HttpInterceptor replaced a hand-rolled token-attaching pattern with the framework’s recommended approach. The BehaviorSubject-backed TripStore is a working RxJS pattern a current Angular developer would reach for by default. On the database side, the bcrypt migration replaced a PBKDF2 hash at one thousand iterations, well below current guidance, with the conventional choice for a Node and Express stack, and the schema redesign controls exactly what is stored and what is allowed to leave the database. What I take from this is fairly practical: a lot of good implementation is just knowing which pattern the framework already gives you and using it instead of hand-rolling your own.

Security mindset. Security thinking shows up across all three categories. CORS was open to every origin in the starter code and was closed to a configured origin. The JWT decode path was hardened against malformed tokens so a bad token logs the user out cleanly instead of crashing the admin interface. The database pass added bcrypt at cost factor twelve, refresh tokens on a separate signing secret with a fifteen-minute access-token lifetime, a startup validator that refuses to boot the server if a required secret is missing or left as a placeholder, and server-side input validation on the trip endpoints. In each case the starter code ran fine; it just trusted inputs and defaults it had no reason to trust. Most of the security work was finding those spots and closing them before someone else could.

What sets me apart

The first thing is consistency across the stack. The artifact is a single multifaceted application rather than three unrelated projects, and the enhancement passes had to fit together: the pagination work had to coexist with the interceptor pattern, and the bcrypt and refresh-token work had to coexist with both. Being able to make changes that respect what is already there is, in my experience, the difference between a developer who can join a team and one who cannot.

The second is initiative outside the curriculum. Alongside the coursework I built and shipped meme-creator.app, an image and meme editor I designed and deployed on my own. I mention it less for the app itself and more for what it shows: I will take an idea from “this would be cool” to a live URL without anyone assigning it.

The third is comfort with the modern developer toolchain end to end: a clean branch per category with single squashed completion commits and compare links against the baseline, continuous deployment through GitHub Actions on this ePortfolio, package and dependency hygiene across Node and Angular, and an intentional choice in every category to use the framework’s recommended pattern. That fluency does not stand out in any single deliverable, but it shows up in the absence of friction across all of them.

How the ePortfolio fits together

The projects section contains four entries: the code review I recorded at the start of the capstone, and one enhancement page for each category, Software Design and Engineering, Algorithms and Data Structures, and Databases. Each enhancement page leads with a short narrative, lists the specific changes with before-and-after code where the change is small enough to show, and links to the corresponding branch on the CS-465 repository so a reader can see the full diff. The single-artifact structure is deliberate: the goal is to show that I can sustain technical attention to one codebase across a full capstone, and that each enhancement reinforces the others, rather than to show a wide range of small disconnected pieces.

For me, the jump from coursework to professional work is not really about learning new skills. It is about using the ones the program already gave me on problems where the result matters. This ePortfolio is the first thing I have built that lives on the internet under my own name, where a stranger might judge it without me in the room to explain it. That raised the bar for how it had to be written, and I tried to meet it. I am ready to take that same standard into a full-stack web role.