Professional Self-Assessment

This ePortfolio introduces my capstone work and documents growth across software design and engineering, algorithms and data structures, databases, security, and user experience. It explains how the artifacts fit together, why specific decisions were made, and how those decisions improve maintainability, security, and clarity for future contributors.

Executive Summary

Focus Areas

  • Modular service design and separation of concerns
  • Secure authentication and data handling
  • MongoDB schema discipline and safe migrations
  • Validation, error shaping, and observability
  • Clear stakeholder communication and review loops

Primary Artifact

TRAVLR is the anchor artifact for this capstone. Enhancements center on login and settings, a dedicated encryption utility, a constrained user schema with defaults, and a reliable update path that is easy to test and reason about.

Register → Login → Update Settings → Re-login test flow verified.

Strengths and Evidence

Collaboration and Stakeholder Communication

During the TRAVLR enhancement cycle I treated the site administrator as the primary stakeholder and shipped in small, reviewable slices. Each slice had a focused pull request with a checklist, a short walkthrough, risks, and a clear rollback plan. Feedback translated to concrete changes: crypto moved out of route handlers, environment variables documented, error payloads standardized, and async bcrypt paths wrapped in try and catch with early returns.

Review threads led to a single validation helper for settings, JSDoc on public functions, and consistent status codes. I posted short stakeholder notes after each iteration that made scope, impact, and next steps easy to track and kept attention on value: safer login, clearer settings UX, and code that is straightforward to extend.

Algorithms, Data Structures, and Engineering Discipline

Authentication follows a narrow, predictable path. Inputs are validated early, unique indexes on username and email support single-document lookups, and bcrypt comparison is handled in a constant-time manner. Duplicate checks were consolidated into one validator to reduce branching and accidental bypasses.

Database calls were simplified. Handlers project only required fields, and settings are normalized so updates can be a single atomic write. The result is less I/O, fewer code paths, and behavior that is easier to reason about and test.

  • util/encryption.js isolates cryptographic concerns
  • Thin route handlers call small, testable helpers
  • Input validation and error shaping remove repetition and ambiguity
  • Schema defaults and constraints reduce defensive code in callers

Security Mindset

Credentials are hashed with salted bcrypt. Reversible encryption is limited to data that must be decrypted by the system, not for passwords. All inputs pass through an allow-list validator. Handlers update only the authenticated user record and project only necessary fields. Errors are generic to avoid user enumeration, secrets live in the environment, and logs exclude sensitive fields by design.

How the Artifacts Fit Together

TRAVLR links the course outcomes in a single, coherent surface. The encryption module and service-style helpers show software design. The authentication pipeline and validation show algorithms and data structures used in practical control flow. The MongoDB schema and migrations show database planning, safe writes, and predictable reads. The portfolio pages reference these changes directly and include a code review video that explains design intent and tradeoffs.

Outcome Mapping

Mapping of CS outcomes to artifacts and evidence
Course Outcome Evidence Result
Software Design and Engineering Encryption utility, service helpers, route refactors, JSDoc Lower complexity per module, easier testing, faster onboarding for new contributors
Algorithms and Data Structures Narrow authentication path, early validation, constant-time compare, reduced branching Predictable control flow with fewer failure modes and clearer performance characteristics
Databases Schema defaults and constraints, projections, single-document updates, migration routine Safer writes and reads with fewer round trips and more consistent documents over time
Security Bcrypt hashing, allow-list validation, generic errors, secret management, least privilege updates Resilience against common risks without sacrificing maintainability
Communication Small PRs, checklists, review walkthroughs, stakeholder notes Traceable decisions and faster, clearer review cycles
UX and Accessibility Clear error messages, consistent forms, predictable flows, semantic markup Lower cognitive load, clearer recovery from errors, better keyboard and screen reader support

Testing and Verification

Manual and Scripted Checks

  • Smoke path: register, login, update settings, logout, re-login
  • Negative cases: invalid payloads, duplicate usernames, unauthorized updates
  • Database assertions: unique indexes applied, projections return only required fields
  • Security checks: no secret values in logs, no sensitive fields in error payloads

Where automation is available, these checks can be expressed as lightweight API tests that run in CI. The goal is fast feedback on regressions without heavy fixtures.

Growth Reflection

I entered the program comfortable with single-file solutions and quick fixes. Over time I learned to design for the next developer. That means smaller modules with a single purpose, data models that reflect real usage, defensive boundaries at the edges, and steady communication with reviewers and stakeholders. The result is a codebase that is simpler to read, safer to change, and easier to test.

Next Steps

Planned Enhancements

  • Introduce basic API contract tests around auth and settings
  • Add rate limiting on login to reduce automated guessing attempts
  • Harden input validation with shared schemas between client and server where appropriate
  • Expand logging fields for observability without exposing sensitive data

Team Practices

  • Keep change size small, keep feedback fast
  • Prefer documented helpers over repeating inline logic
  • Write short stakeholder notes that explain impact and risk

Detailed Evidence and Rationale

Design Choices

  • Separation of concerns keeps cryptography, validation, and persistence isolated so each part can be tested and changed without side effects.
  • Allow-list validation blocks accidental attribute escalation and keeps handlers simple.
  • Schema defaults and constraints turn runtime checks into data guarantees, which reduces code in callers and prevents malformed records.
  • Consistent error shapes make failures predictable for clients and easier to observe in logs and dashboards.

Security Considerations

  • Passwords are never stored in a reversible format and are hashed with a per-record salt.
  • Secrets are loaded from the environment and never committed to the repository.
  • Responses avoid leaking internal structure or hints that could help user enumeration.
  • Database updates operate with least privilege and project only the fields that are needed.

Developer Experience

  • Small PRs with checklists, short videos, and rollback notes make review faster and clearer.
  • Helpers and JSDoc reduce onboarding time by making intent explicit.
  • Predictable flows mean fewer places to instrument and fewer places to debug.