Knowledge gained from Projects

Git-Mastery:

MarkBind:

Open:

RepoSense:

TEAMMATES:

Git-Mastery

DESMOND WONG HUI SHENG

CodeRabbit

CodeRabbit is an AI-powered code review tool that integrates directly into developers' GitHub Pull Requests (PRs). For team project, it acts as an automated "gatekeeper" that catches common mistakes before a human mentor reviews the code.

Learning Points:

  • Learn automated context-aware reviews: CodeRabbit analyzes the entire repository to understand how a change in one file might break another, providing instant, comprehensive feedback on every pull request.
  • Identify edge cases in PRs: It identifies potential issues, such as bugs that static analyzers miss, security oversights, and logic errors that only surface under specific conditions.
  • Summarize complex changes: It automatically generates a summary and walkthrough of code changes, which is particularly handy for large PRs where context helps teammates understand the scope of the work.

Resources:

Claude Agent Skills

Claude Agent Skills is a specialized feature within the Claude ecosystem that allows developers to define and package complex, reusable behaviors as "skills" that the AI can invoke when needed.

Learning Points:

  • Encapsulate Domain Logic: Developers can create specific skills that encapsulate the complex logic of their project, such as a "Scope-Parser-Skill" that handles the different scenario, ensuring the AI uses the most robust method every time.
  • Modularize Intelligence: Instead of overwhelming the AI with a massive list of instructions, developers can break them into modular skills that the agent only activates when the context of the task requires them.
  • Continuous Skill Refinement: Developers can iteratively improve these skills by feeding the agent feedback from failed runs.

Common Usage:
We will create AGENTS.md file. It will contain high-level overview of the repository. Moreover, .claude folder will also be created, it will contains different skill.md files, which contain a more detailed information about the specific component of the repository.
Ideally, when we give a task to AI Agent, it will read through AGENTS.md file to identify the skills needed to perform the task. Thus, it only need to read the relevant skill.md.

Resources:

Git Worktree

Git Worktree is a native Git feature that allows developers to manage multiple working directories (worktrees) attached to a single repository.

Learning Points:

  • Eliminate Context Switching Friction: Instead of using git stash and git checkout to move between branches, developers simply change directories. This preserves their uncommitted changes, terminal history, and IDE state in each branch exactly where developers left them.
  • Optimized Resource Usage: Worktrees share the central .git directory and object database, making them much faster and lighter than a full git clone.
  • Isolated "Agent" Workspaces: In a AI-driven workflow, developers can assign a dedicated AI agent (like Claude Code) to its own worktree. This provides the agent with a bounded context where it can research, build, and test a specific task without interfering with their primary work or other ongoing AI tasks.

Common Usage:
Suppose we are working on a repo named worktree. We can create a new worktree using

git worktree add ../worktree-testing

which create a directory named worktree-testing at the same level as worktree. A new branch worktree-testing, which is the same as directory name, will be created. If we want to specify the branch name, we can use

git worktree add ../worktree-testing -b hotfix

Note that no two worktrees can work on the same branch. Now, we can open worktree-testing separately and make changes accordingly.


If we want to see the full list of worktrees, we can use

git worktree list

Once we are comfortable with the changes, we can just merge or rebase the branch, which is similar to our usual workflow.

git merge hotfix
git rebase hotfix

To delete the worktree, we can remove the worktree-testing directory, and it will be marked as prunable. Then, we can run

git worktree prune

Besides, we can remove clean worktrees (no untracked files and no modification in tracked files) by running

git worktree remove ../worktree-testing 

Resources:

Github Copilot

GitHub Copilot is a sophisticated AI-powered developer tool that functions as an intelligent pair programmer, helping developers write code with greater efficiency and less manual effort. Unlike traditional autocomplete, it uses advanced large language models to understand the deep context of the project to suggest everything from single lines of code to entire functional blocks. By automating routine tasks and providing real-time technical guidance, it allows developers to focus more on high-level problem solving and architectural design.

Learning Points:

  • Ensure Full Repo Understanding: Before implementation, provide Copilot with comprehensive context by indexing the repository and opening relevant files to ensure it understands the project structure and architectural decisions.
  • Verify Understanding via Q&A: Use a Q&A section in Copilot Chat to clarify its internal logic and ensure it isn't making false assumptions about the codebase. Explicitly asking AI not to assume but to verify against actual files (like package.json or custom logic) prevents confident but incorrect "hallucinations".
  • Provide Existing Code Examples: Feed Copilot snippets of the existing project patterns to ensure consistency across the codebase.
  • Demand a Full Implementation Plan: Instruct Copilot to generate a step-by-step reasoning plan before it writes a single line of code. Breaking down complex tasks into atomic, verifiable steps allows developers to identify logical flaws in the AI's approach early on.
  • Evaluate Multiple Solutions: Prompt Copilot to offer several distinct solutions so developers can evaluate the trade-offs in robustness and platform compatibility themselves. Moreover, developers can also provide some possible solution to Github Copilot for evaluation.

Resources:

ChatGPT Codex App

ChatGPT Codex App is an AI coding assistant that helps developers go from idea to working code faster. Instead of only suggesting the next line, it can help with planning, implementation, debugging, and documentation, so it feels more like a practical coding partner in day-to-day work.

Learning Points:

  • Turn plain language into real coding tasks: We can describe the task (debugging, fixing bugs, new implementation, etc) to Codex. Codex can give me a detailed implementation plan before it starting coding. We can exchange idea to better improve our approaches. Once we have reached an agreement, then started coding. Streamline the process, and speed up the development cycle.
  • Use project context for better output: Codex gives much stronger suggestions when it can read the relevant files first, because it can follow the repo's structure, naming style, and existing patterns.
  • Reduce mistakes with quick verification: A good habit is to ask Codex to explain assumptions, point to specific files, and run checks or tests so the final result is safer and more accurate.
  • Speed up debugging work: It can help trace likely root causes, propose focused fixes, and produce small patches that are easier for teammates to review.
  • Write clearer docs faster: Codex is also useful for drafting PR summaries, technical notes, and simple explanations for complex code changes.

Resources:

GitHub Actions

GitHub Actions is a CI/CD automation platform built into GitHub that lets us run workflows directly from our repository. It helps automate repetitive engineering tasks like testing, linting, building, and deployment whenever events such as push, pull request, or manual dispatch happen.

Learning Points:

  • Automate development workflow: We can define workflows in YAML files under .github/workflows to automatically run checks and scripts, which reduces manual work and human error.
  • Protect code quality in pull requests: By running unit tests, lint checks, and security scans on every PR, GitHub Actions helps us catch issues early before merging.
  • Use event-driven pipelines: Workflows can be triggered by repository events (e.g., push, pull_request, release) so automation happens at the right stage of the development cycle.
  • Reuse and scale with actions: We can use community actions from GitHub Marketplace or create our own custom actions to keep workflows modular and maintainable.
  • Secure secrets and deployments: GitHub Actions integrates with encrypted secrets and environment protection rules, allowing safer automation for deployment and external service integration.

Common Usage:
Create a workflow file at .github/workflows/ci.yml and define jobs for testing/building.

An Action is a packaged automation step we can use in a workflow. There are lots of prebuilt Actions made by Github or third parties. We can find these reusable Actions from Marketplace

name: CI

on:
    pull_request:
    push:
        branches: [ main ]

jobs:
    test:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v4
            - name: Setup Node
                uses: actions/setup-node@v4
                with:
                    node-version: 20
            - run: npm ci
            - run: npm test

Jobs run in parallel unless needs is added. Each job has its own steps, and is run in separated virtual environment. Steps inside one job run in order.

${{}} is Github Actions expression syntax. {{ secrets.USERNAME }} reads an encrypted secret at runtime, and their values are masked in logs. Secrets can be passed through with: or env:.

jobs:
    test:
        runs-on: ${{ matrix.os }}
        strategy:
            matrix:
                os: [ubuntu-latest, macos-latest, windows-latest]
    steps:
        - uses: actions/setup-node@v4
            with: 
                username: ${{ secrets.USERNAME }}
                password: ${{ secrets.password }}
        - run: echo test
    
    deploy:
        needs: test
        runs-on: ubuntu-latest
        steps:
            - run: echo deploy

Resources:

GOYAL VIKRAM

Tool/Technology 1

List the aspects you learned, and the resources you used to learn them, and a brief summary of each resource.

Tool/Technology 2

...

JOVAN NG CHENGEN

Knowledge

List the aspects you learned, and the resources you used to learn them, and a brief summary of each resource.


ChatGPT Codex

Resources: Introducing Codex · Codex App · Codex Now GA

Codex is OpenAI's agentic coding system (powered by GPT-5.3-Codex) that can receive a task description, write code, run it in a sandboxed cloud environment, debug errors, and open a pull request for review.

Access & Interfaces:

  • Available via ChatGPT Plus ($30/month), CLI, IDE extension, and the web at chatgpt.com/codex
  • Each task runs in its own isolated cloud sandbox, pre-loaded with your repository

Key Features:

  • Remote Codex: Delegate long-running tasks to cloud machines and open PRs from anywhere — including mobile. Unlike local AI assistants, tasks run asynchronously
  • Worktrees: Run multiple agents in parallel on different features simultaneously, each in isolation
  • Skills: Reusable, shareable instruction sets that align agents with team standards (code understanding, prototyping, documentation)
  • Automations (Background): Codex works unprompted on scheduled workflows — issue triage, alert monitoring, CI/CD integration, and more
  • Mid-task steering: Unlike one-shot prompts, you can guide and interact with Codex while it's working without losing context
  • Integrations: GitHub today; issue trackers and CI systems coming soon

Claude Code

Resources: Claude Code Overview · Claude Code Releases

Claude Code is Anthropic's agentic coding CLI that understands your entire codebase and can work across multiple files and tools to complete tasks end-to-end.

Access & Interfaces:

  • Available via Claude Pro ($20/month) or API
  • CLI (terminal), VS Code extension (inline diffs, @-mentions, plan review), JetBrains plugin, web app at claude.ai/code

Key Features:

  • Multi-agent collaboration: Multiple agents can work together on a task, share context, and hand off work
  • Checkpoints: Saves progress and allows instant rollback to a previous state — critical for long agentic tasks
  • MCP (Model Context Protocol): Open standard for connecting Claude Code to external tools — Google Drive, Jira, Slack, or custom tooling. MCP servers can be self-hosted
  • Git integration: Natively stages changes, writes commit messages, creates branches, and opens PRs
  • Hooks: Shell commands that execute in response to events (tool calls, session start/stop) — enables automated workflows without leaving the harness
  • CLAUDE.md: Project-level instruction files that scope Claude's behavior to your conventions
  • Compared to Codex: Better performance on complex multi-file tasks due to its richer harness; local-first but supports remote agents

Git Hooks

Resources: githooks.com · Lefthook GitHub · pre-commit vs lefthook comparison · Using Lefthook across a team

Git hooks are scripts that run automatically at specific points in the Git workflow. They are stored in .git/hooks/ but are not tracked by version control — hook managers solve this by committing the config to the repo.

Hook Lifecycle:

Hook When Common Uses
pre-commit Before commit is created Lint, format, secret detection
commit-msg After commit message is written Enforce Conventional Commits
pre-push Before push to remote Run tests, check branch policy
post-commit After commit Notifications, doc generation

Tool Comparison — Lefthook vs pre-commit:

Lefthook pre-commit
Language Go Python
Execution Parallel (faster) Sequential
Config lefthook.yml .pre-commit-config.yaml
Hook sources Local scripts Community hook registry
Best for Polyglot/any project Python-heavy projects

Lefthook is preferred in the Git-Mastery project for its performance and language-agnosticism. Configuration example:

# lefthook.yml
pre-commit:
  parallel: true
  commands:
    lint:
      glob: "*.py"
      run: ruff check {staged_files}
    format:
      glob: "*.py"
      run: ruff format {staged_files}

Install with lefthook install after placing lefthook.yml at the repo root.

Git-Mastery implementation: Lefthook was adopted across the exercises repository (#265) and the app repository (#76).


Trunk-Based Development

Resources: Atlassian Guide · DORA Capabilities · trunkbaseddevelopment.com · Harness Complete Guide

A source control branching model where all developers integrate into a single branch (main/trunk), keeping it always releasable and avoiding long-lived branches and merge hell.

Core Principles:

  • Short-lived feature branches only (ideally ≤1 day, ≤1k LoC) — never let branches diverge far from trunk
  • Every commit on main must be in a deployable state — enforce this via CI gate
  • Squash merges for clean history and atomic rollbacks
  • Never merge unless CI passes; require minimum approvals via branch protection rules
  • Feature toggles to ship incomplete features without long-lived branches

Why it works:

  • Forces small, reviewable changes — reduces cognitive load on reviewers
  • Conflict surface shrinks proportionally to integration frequency
  • DORA research confirms TBD is a key predictor of elite software delivery performance (~85% of top-performing teams use CI/CD pipelines)

Minimum Viable CI/CD pipeline:

  1. Unit tests — fast, per-function/module, run on every commit
  2. Integration tests — API-level flows against a virtual environment
  3. E2E / Synthetic tests — run on the actual environment (traditionally flaky; mitigation: retries, stable selectors, isolated state)
  4. Deployment gates — post-deploy smoke tests; rollback automatically on failure

Feature Flags (vs long-lived branches):

  • Incomplete code is merged but hidden behind a runtime toggle
  • Code exists in production but is off — removes the need to maintain a parallel branch
  • Tools: LaunchDarkly, Unleash (open-source), or simple environment variables

CodeQL & Static Analysis

Resources: GitHub CodeQL docs

CodeQL is GitHub's semantic code analysis engine. It treats code as data and runs queries to find security vulnerabilities automatically.

How it works:

  • Creates a database from your codebase by extracting a relational representation of the code
  • Runs queries (written in QL) against that database to find patterns matching known vulnerabilities
  • Results surface as code scanning alerts on PRs and in the Security tab

Key points:

  • Covers OWASP Top 10 out of the box for supported languages (Python, JS/TS, Go, Java, C/C++, etc.)
  • Can be added as a GitHub Actions workflow (github/codeql-action)
  • Free for public repos; included in GitHub Advanced Security for private repos
  • Complements linters (which check style) — CodeQL checks for security and correctness

Git-Mastery implementation: CodeQL was set up alongside main branch hardening (#116).

LOH JIA XIN

GitHub Copilot

GitHub Copilot is an AI-powered coding assistant built by GitHub and OpenAI that helps programmers write code faster and with less effort.

Learning points:

  • Give examples of existing code with similar functionality, to avoid hallucination and ensure the code quality is consistent across the codebase
  • Properly describe the expected usage of the product which is not always obvious when implementing libraries and dependencies. This can affect the implementation method chosen.
  • Ask for many possible solutions (ie. planning) and evaluate them yourself before deciding on one and guiding the AI tool to implement it.

Resources:

Claude Code

Claude Code is an AI coding assistant by Anthropic that helps with code generation, refactoring, debugging, and repository-level understanding through natural language instructions.

Learning points:

  • Give explicit constraints (tech stack, coding style, and file targets) so the tool can make precise edits with fewer iterations.
  • Use task-specific command modes (for example /review) to get focused outputs for different goals such as code review, planning, or implementation.

Resources:

Tool/Technology 2

...

SAN MUYUN

ContextManager

A context manager in Python is a structured way to handle resources so setup and cleanup are done safely and automatically, usually through the with statement. Instead of manually opening and closing files or connections, a context manager guarantees that cleanup logic still runs even if an exception occurs inside the block, which reduces bugs and resource leaks. Under the hood, this works through the context manager protocol (__enter__ and __exit__), where __enter__ prepares the resource and __exit__ handles teardown. This pattern makes code cleaner, easier to read, and more reliable because resource handling is localized to one clear block. Common examples include file I/O, database transactions, thread locks, and temporary state changes, and a good rule is to use with whenever something must always be released or restored.

resources:

Utilising Codex for coding

OpenAI Codex is an AI coding agent, a large language model specialized for software tasks, combined with tools that let it work inside a real project. It can be very useful to read and understand files across a repository, run terminal commands, propose and apply code edits, generate test cases etc.

AI Agent:

Agent.md is a project-specific instruction file that tells an AI coding assistant how to behave inside a codebase: what the project does, how the folders are organized, coding conventions, testing commands, and things to avoid. It improves AI performance by informing the LLM exactly how the project’s structure or style from scattered files look like, so it makes more accurate edits, follows the right conventions, avoids breaking assumptions, and produces code that fits the repository better.

Features of a good Agent.md includes:

  • State a clear role
  • Indicates the executable commands
  • Project knowledge
  • Real Examples

Ideally, Agent.md should be very specific on the task that this particular AI Agent should carry out, like writing test cases, debug, refactoring, instead of being very generic.

resources

Prompt Engineering:

Prompt engineering is the practice of designing clear, specific instructions so an AI can produce more accurate, useful, and consistent outputs.

A good prompt should:

  • give enough information about the task
  • provide desired response/output format
  • any constraints that is not clearly stated in the task information provided to the LLM

If the task is complicated, it is always recommended to break it into smaller tasks, and prompt the AI to complete a sequence of smaller tasks.

resources:

MarkBind

CHUA JIA CHEN THADDAEUS

GitHub Copilot

GitHub Copilot is a code completion and programming AI-assistant that assist users in their IDE. It uses LLMs can assist with code generation, debugging or refactoring through either real-time suggestions or language prompts

Key Learning Points:

  • Context is King! Providing all relevant files immediately leads to faster, more accurate fixes. The AI performs best when it "sees" the full scope of the bug.

  • Don't stop at the first working fix. Specifically, we can try asking the AI to improve code quality and clarity after the initial generation helps eliminate "AI-style" clutter and technical debt.

  • Initial AI suggestions often prioritize the simplest fix. It still requires manually prompts & investigation for edge cases to ensure the solution is robust.

  • We should treat AI as a collaborator, and not an automated system. Reviewing proposed changes and selectively implementing only what fits the project context prevents the introduction of unnecessary or incorrect logic.

Agent Skills

Agent Skills are folders of instructions, scripts, and resources that agents can discover and use to do things more accurately and efficiently. These skills are designed to be automatically founded and used by AI agents, providing them user-specific context they can load on demand hence extending their capabilities based on the task they’re working on.

Key Learning Points:

  • Moving instructions from a giant system prompt into a SKILL.md file allows for "progressive disclosure," where the agent only loads the knowledge it needs for the specific task at hand.

  • Provide a strict directory layout (Instructions in SKILL.md, automation in scripts/, and context in references/) to ensure the agent can reliably find and execute tools.

  • Include specific trigger phrases & tags, as well as clear and well defined steps. This prevents the agent from guessing, thus ensuring it follows the exact logic required for the most effective application.

HARVINDER ARJUN SINGH S/O SUKHWANT SINGH

AI-Assisted Coding Tools

So far, I've experimented with many AI coding tools, incorporating them into my workflow and trying them out.

I've tried opencode, Mistral Vibe, Proxy AI, Github Copilot, Cline.

They can be divided into roughly two categories; AI tools that live in the CLI and those that integrate directly into IDEs. While their usage may be similar (many of them can inject context using slash/@ commands, in addition to other common features), their value can be quite different.

I've found that tools that integrated directly into IDEs felt superior for engineering, provided that one does not enable settings such as "YOLO" mode (editing without permission). This way, you may review the AI's work file-by-file, and guiding it if its approach needs changing.

While I've found human-in-the-loop workflows to feel better as a developer (more supervision over work), less hands-on approaches also can be useful for iterating quickly. However, I've also found that the success of these methods are highly contingent on model quality.

On top of that, leveraging plan/act modes, skills, and keeping context focused can improve model performance.

Resources: Cline documentation

TypeScript (and the JavaScript/Node ecosystem)

So far, I've been working on much of the CLI components of MarkBind. I've done much research on it due to working on PRs such as TypeScript migration and Migrating TypeScript output from CJS to ESM. I would say currently I'm more well-versed in it than an average developer due to my deep involvement in these migration works where I've had to update tooling, workflows, and developer experience regarding TypeScript.

Key Learning Points

  • CJS vs ESM: CommonJS (CJS) and EcmaScript Modules (ESM) are different module systems for the JavaScript environment. Their key difference is in how they resolve imports/other modules - CJS was primarily designed for server-side, and modules are loaded synchronously. This is compared to ESM which allows for both synchronous and asynchronous module loading. As the ecosystem is currently moving towards ESM, MarkBind has migrated to ESM.
  • Node Versions: Even-versioned releases in Node are LTS. Using newer version of Node allow you to use newer features that are sometimes nicer for Dev Experience.

Resources: CJS vs ESM (Better Stack)

Langchain

I learnt and used Langchain to create an AI workflow for the CSV classifier task.

Resources: Langchain documentation

HON YI HAO

AI Coding Tools

Skills

Worked with the team to explore adding repo-specific AI coding skills for common harnesses such as Claude, OpenCode and GitHub Copilot.

Subagents

Created subagents to handle specific tasks such as writing unit tests, generating documentation, and refactoring code.

Vue

Reactivity (Vue 3)

Learned about Vue 3's reactivity system, including ref, reactive, and computed properties.

Used reactive and computed to implement dynamic data tag count in CardStack Component.

TypeScript migration

tsc

Learned to use the TypeScript compiler (tsc) to check for type errors and compile TypeScript code to JavaScript.

Several useful configs/flags learned:

  • outDir: specifies the output directory for compiled JavaScript files.

PDF generation for MarkBind sites

When making my own course notes with MarkBind, I realised a need to export the entire site to pdf file so that it could be printed and brought to exams, and distribute easily in general. That's why I started exploring the idea of creating a @/packages/core-pdf module that achieves this goal.

Applications

  • Export MarkBind sites to be distributed as pdf files
    • example use case: generate pdf for CS2103T ip/tp to be submitted for use in CS2101
  • Export MarkBind sites to be printed for offline use
    • example use case: generate pdf for personal notes to be printed and brought to exams

Experimentation

Considering MarkBind already creates a static site with proper formatting, with appropriate CSS for media print, I decided to leverage on that and use a headless browser to render the site and print it to pdf.

Challenges

Solved (i think)

Page order when merging

  • In the built _site directory, the pages are individual .html files, with no particular order in the directory.
    • This makes it difficult to determine the correct page order when merging them into a single pdf.
  • Implemented solution:
    • Parse the .html pages to extract the <site-nav> structure, which contains the correct page order.
    • Use the extracted page order to merge the individual pdfs in the correct sequence.

Hidden elementes

  • Some elements (e.g. panels) can be collapsed by default and thus hidden when rendered, which may lead to missing content in the generated pdf.
  • Implemented solution:
    • Inject javascript into the rendered page to expand all collapsible elements before printing to pdf, ensuring all content is included in the final output.

Outstanding issues

Big dependency/bundle size

  • The headless browser library (Puppeteer) is quite large, which may not be ideal for a MarkBind plugin.
  • Possible solution: Make Puppeteer an optional dependency, try to use the system's browser if available, only fallback to Puppeteer if no suitable browser is found.

iframes rendering

  • Some pages with iframes (e.g. pdf and youtube videos) may not be able to show the rendered content but just the placeholder instead
  • Attempted solution: use Puppeteer to take a screenshot of the iframe and inject that into the page. I can't get it to work though

Open

DALLAS LIM JUIN LOON

OpenCode

OpenCode is a CLI program for agentic coding. It allow users to use the same application with different LLM models, supporting many different providers.

Aspects learned

  • Planning: Creating a plan for the agent to follow in order to complete a task allows ensuring implementation will be as specified.
  • Context management: Provide only strictly required information to the agent when prompting and writing project rules to manage the context window effectively. Agent's exploration of the codebase can provide most of the low level details.
  • Skills: Progressive disclosure of skills to the agent allows sterring the agent's behavior only when needed, preventing pollution of context

Resources

  • Youtube: Many content creators create videos about agentic coding that can be transferred across different harnesses.
  • Aihero: A website with articles and resources for agentic coding.

QML

A declarative language for designing user interfaces, which can be used through PySide to create GUI applications in python.

Aspects learned

  • Syntax: Using QML classes to create layouts, signals to handle interations, models and views to display data.
  • Resources: Including external resources like images and custom modules to use custom classes written in QML and python.

Resources

GABRIEL MARIO ANTAPUTRA

Git Internals

Learnt about the internal workings of Git, including how Git stores data, how it manages branches, etc.

Electron

Learnt how to develop desktop applications using Electron. In particular, although I had prior experience with Electron, the tech stack was a bit different from what I had used before. For example, I used electron forge before, but this time I used electron builder, which is supposed to be more powerful and flexible. I also had to learn how to set up the project structure and configure the build process for the electron app.

React (Typescript)

Used React with Typescript for the frontend of the electron app. Learnt core concepts like using hooks for state management and side effects, as well as how to structure a React application. I also had to learn how to integrate React with Electron.

Tailwind CSS

Learnt how to use Tailwind CSS for styling the electron app.

Redux

Learnt how to use Redux for state management in the electron app.

Markbind

Learnt how to use Markbind for creating documentation and websites. In particular, I learnt how to setup the markbind project, since I wasn't the one doing that in my CS2103T team.

Github Workflow and CI/CD

Learnt more about Github workflow and CI/CD by setting up Github Actions for my projects. I set up actions for checking linting, building and deploying the pages, building and testing the electron app, etc. The most notable thing I learnt was testing the electron app on mac os environment, which was very useful since I don't have a mac os device to test on.

Prompt and Context Engineering

Practiced context and prompt engineering by comparing self proposed solution with AI generated solution and analyzing the differences. By comparing different prompts and contexts, I learnt how to craft better prompts and optimise context to get better results from AI models.

Using Github Copilot Code Review

Found out about Github Copilot Code Review and used it to review my code and get suggestions for improvements.

RepoSense

CHEN YIZHONG

Tool/Technology 1: GitHub Copilot

  • Collaborative Context Management: Understand how to provide good context for Copilot Agent to work with, such as providing relevant files or documentation snippets (.github/copilot-instructions.md) to helps the agent generate more accurate suggestions.

  • Verification and Human-in-the-Loop: Understand to treat Copilot’s output as a "first draft" that requires additional prompting and extensive testing regarding logic flow and existing architectural constraints.

  • AI-Assisted Code Reviews: Use Copilot directly in GitHub to analyze PRs by asking it to explain complex logic, identify potential edge-case bugs, or ensure adherence to project standards. It can also be called directly to a review on its own.

Resources used:

Tool/Technology 2: Claude Code

  • Agentic Workflows: Experimented with using autonomous subagents capable of executing multi-step tasks like major refactoring. (Breaking down into Planning + Model Making + Writing Tests + Executing with TDD)

  • Efficient Branch Management (Worktrees): Leveraging Git worktrees with Claude Code to perform mutliple concurrent experimental changes in isolated environments, preventing interference with main development tasks.

Resources used:

HALDAR ASHMITA

AI Coding Tools

This module exposed me to multiple AI coding tools that are popular in the market, such as GitHub Copilot, Codex by OpenAI, and Claude Code.

Claude Code

My first major use of Claude Code for RepoSense PRs was to implement a YAML configuration wizard, which revealed both the promise and the limits of AI-assisted development.

  • Plan mode proved genuinely useful for scoping out the work ahead.
  • However, I quickly learned that leaving Claude entirely to its own devices was not a viable approach. I had to continuously review the code it produced, prompt it to re-examine its own output for potential issues, and actively probe for bugs — catching problems like a null branch issue that might otherwise have slipped through.
  • Beyond debugging, the collaborative process required real engagement: discussing potential features, weighing multiple implementation approaches, and asking targeted questions. For instance, exploring two different ways to handle git usernames and evaluating the tradeoffs of each.
  • Crucially, I also had to bring my own knowledge of the codebase to the table. When the generated plan referenced CSS files, I was the one who recognised that the main frontend used SCSS and flagged the inconsistency for the sake of consistency, something Claude did not realize until it was told. This is why I kept "manually accept edits" enabled throughout.

The broader takeaway is that working with AI on an existing codebase still demands that the developer be deeply familiar with it. Claude is a powerful collaborator, but it cannot be expected to independently scour a codebase and always arrive at the most contextually appropriate solution. That judgment still has to come from you.

Terminal UIs

While working on my YAML config wizard, I spent some time researching about terminal UIs, when deciding wheher to implement a TUI or GUI for the wizard.

  • A TUI, or Text-based User Interface, is an interactive interface that runs entirely inside a terminal emulator. It is like a GUI but rendered with characters, box-drawing symbols, and ANSI color codes instead of pixels and windows.
  • They have been around since the early days of computing (ncurses-style apps like vim, htop, and midnight commander are classic examples) and have seen a real renaissance with modern frameworks that make them much easier to build.
  • Modern libraries like Bubble Tea (Go's Elm-inspired TUI framework), Rich and Textual for Python, and Ink for React-based terminal rendering can build TUIs.
  • I was weighing whether to go this route, something that lives entirely in the terminal using keyboard navigation, text-based forms, and styled layouts, or go with a more traditional GUI.
  • A TUI felt natural for a config wizard since developers are already in the terminal, it would avoid any frontend dependency overhead, and keeping more of RepoSense CLI-native felt elegant.
  • But ultimately I decided against it. GUIs just offered more flexibility for the kind of user experience I wanted to build, especially for something as structured and potentially complex as YAML configuration, where visual hierarchy, validation feedback, and form layouts benefit from a proper windowed interface.

So after the research detour, I went with a GUI.

.yaml files

A YAML file is a human readable, plain-text file used mainly for configuration. DevOps, and data serialization. It uses indentation-based, hierarchical structures rather than curly braces or bracckets for data storage. Such a key-value pair structure makes it more readable and human friendly compared to JSON or XML. Key aspects:

  • Uses whitespace indentation to define structure, with colons : separating keys and values.
  • It supports multiple data types (such as strings, integers, booleans etc.), sequences such as lists/arrays, and maps.
  • Highly sensitive to indentation (spaces, not tabs). Comments are created with the # symbol.

Worked with YAML files when exploring the development of a GUI .yaml config filee generation wizard.

GitHub Actions

GitHub Actions is GitHub's built-in CI/CD platform that automates workflows in response to repository events like pushes and pull requests.

  • Workflows are defined as YAML files in .github/workflows/ and consist of jobs that run on GitHub-hosted virtual machines (runners).
  • Each job contains a sequence of steps that can run shell commands or use pre-built community actions (e.g., actions/checkout, actions/setup-java).
  • Jobs can run in parallel across a strategy matrix of different OS and tool versions, and workflows support caching, artifact uploads, and conditional execution via if expressions.

Across my contributions to RepoSense, I gained significant practical experience with how GitHub Actions CI interacts with the development workflow.

  • RepoSense's integration.yml runs a build matrix across six OS variants (Ubuntu, macOS, Windows) and includes separate jobs for backend tests (Gradle checkstyleAll, test, systemTest) and Cypress frontend tests.

  • One of my earliest lessons came from the temp repo directory PR (#2537), where I refactored repository cloning to use temporary directories. The change worked locally but broke system tests on CI because the test environment assumed cloned repos persisted across test runs for snapshot reuse. I had to add a SystemUtil.isTestEnvironment() guard to skip cleanup in tests, teaching me that CI runners have different lifecycle assumptions than local development.

    • Similarly, the build.gradle deleteReposAddressDirectory() cleanup function had to be updated to match the new naming convention, showing me how Gradle build scripts and CI are tightly coupled.
  • The title.md to intro.md rename PR (#2516) and its follow-up removal of backward compatibility (#2566) taught me about the CI pipeline's breadth. Changes that touched build.gradle, Vue frontend components, Cypress test support files, and documentation all had to pass linting, checkstyle, unit tests, system tests, and frontend tests across the full OS matrix.

  • The config wizard work gave me the deepest CI experience.

    • I learned that RepoSense's Cypress tests run via Gradle's testFrontend task, which uses the ExecFork plugin to start Vite dev servers as background processes before running tests. When I added wizard-specific Cypress tests, they initially failed in CI because the global support.js beforeEach hook visits localhost:9000 before every spec — interfering with wizard tests on port 9002.
    • I went through a cycle of writing tests, removing them when CI failed, debugging the port isolation issue, fixing it by adding a conditional guard in support.js and using Cypress.env('configWizardBaseUrl') with absolute URLs in intercepts, adding the serveConfigWizard Gradle task with proper dependsOn/mustRunAfter ordering, and then rewriting the tests from scratch.
  • I also encountered multiple rounds of linter failures in CI — Pug lint errors and Java checkstyle violations. That passed locally but were caught by the CI pipeline's stricter enforcement, reinforcing the importance of running the full lint suite locally before pushing.

Calling LLMs in Programs

This activity showed me how to move from using an LLM interactively to embedding it inside a real Python workflow.

  • I learned how to use AI to call an OpenAI model from code using the SDK, pass structured prompts and dataset rows into the model, and capture the output in a machine-usable form for downstream processing. Here, that meant using an LLM to validate keyword labels in a CSV instead of relying only on manual checking.

  • I also learned that calling LLMs in programs requires more than just sending prompts. In practice, we had to handle environment setup, API keys, Python package installation, and compatibility issues between models and SDK parameters.

  • The activity also surfaced operational concerns that matter in scripts: rate limits, batching requests, retries, progress logging, and writing outputs to files like validation_report.csv. I learnt that when LLMs are used programmatically, the surrounding engineering is just as important as the prompt itself.

  • A major takeaway was that LLMs work well in scripts as one component in a larger pipeline. I used deterministic rules for initial labeling, then layered LLM validation on top as a semantic checker. We can combine traditional code for consistency and speed with LLMs for judgment and language understanding.

GitHub Worktrees

Worktrees are a Git feature that allow you to have multiple branches checked out simultaneously on your system, through multiple working directories all associated with a single local repository. This allows users to work on multiple features/branches without constantly switching between them and stashing changes.

  • All worktrees share the same underlying Git history, saving disk space compared to multiple full clones.
  • They eliminate the need for git stash when switching tasks, as each has their own dedicated workspace. Operations like git fetch or creating a new branch are immediately reflected in all linked worktrees.

Commands

  • git worktree list
  • git worktree add <path> [<branch>]
  • git worktree remove <path>
  • git worktree prune

Resources used:

Java Packages

Files, JVM, and Shutdown Hooks

  • Working with the Files package in Java introduced me to how the JVM manages file system interactions at a higher level of abstraction than the older java.io API.
  • Through the java.nio.file package, I explored how to perform common file operations: reading, writing, copying, and deleting, in a more expressive and reliable way.
  • This led naturally into understanding the JVM itself more deeply: how it manages the lifecycle of a running Java program and what happens as it prepares to shut down.
  • From there, I learned about shutdown hooks, which are threads registered with the JVM's runtime that execute automatically when the program is about to terminate, whether through a normal exit or an interruption.
  • This was particularly relevant in the context of file handling when resolving a critical user-reported bug in RepoSense (PR #), as shutdown hooks provide a mechanism to ensure resources are cleanly released and any pending file operations are properly completed before the process exits, guarding against data loss or corruption.

Google Stitch

I presented a teachback on Google Stitch, a Google Labs tool that generates high-fidelity UI designs from plain text prompts, and found it impressive for early-stage prototyping.

  • It runs on an AI-native infinite canvas where you can bring in images, text, or even code as context, and a design agent tracks your progress across the whole project. Under the hood it uses Gemini and Nano Banana.
  • What really sold me on it was the MCP integration with Claude Code — Stitch produces a DESIGN.md file that captures your color tokens, typography scales, and layout rules in a format Claude Code understands natively, so instead of copying and pasting design specs between apps, your agent connects directly and reads them in real time.
  • To wire it up, you need a Google Cloud project with the Stitch API enabled, and then you can either use a Stitch API key (simpler) or OAuth via gcloud (more stable for heavy use)
  • I went with the API key approach first. The Claude Code command is: claude mcp add stitch --transport http https://stitch.googleapis.com/mcp --header "X-Goog-Api-Key: YOUR-API-KEY" -s user, and once that's in you can verify it's live by running /mcp inside Claude Code and checking the server list.
  • The tools Claude Code can then call include create_project, generate_screen_from_text, get_screen_code, and build_site, which means you can describe a screen in natural language, have Stitch generate it, and have Claude Code pull the HTML/CSS and scaffold it into React components, all without ever leaving the terminal.
  • The typical flow for simple apps: five minutes designing in Stitch, a couple minutes for the MCP export, then Claude Code handling the backend and deploying.

Vue.js and Pug

Through building the RepoSense Configuration Wizard, I gained hands-on experience with Vue.js and the Pug templating language.

Vue.js is a progressive JavaScript framework for building user interfaces. It uses a component-based architecture where each .vue file encapsulates a template, script, and style block.

Pug is an indentation-based HTML templating language that eliminates closing tags and angle brackets, producing cleaner and more concise markup. Vue supports Pug natively via <template lang="pug">, allowing developers to write Pug syntax while still using Vue directives like v-model, v-for, and @click.

  • I learned how to structure a Vue project with reusable components, and how to manage cross-component communication through props, events, and a centralized store.
  • Midway through development, I migrated all templates from standard HTML to Pug, which reduced template verbosity significantly.
  • This taught me Pug's indentation-based syntax for expressing HTML hierarchy, how to bind Vue directives in Pug (e.g., v-model, v-for, @click, :class), and the importance of running a Pug linter (puglint) to catch formatting issues.
  • I also learned that Pug's conciseness comes with trade-offs: the indentation sensitivity can make diffs harder to read and requires careful attention to nesting depth, especially in components with complex conditional rendering.

Writing Cypress tests for Vue.js

I wrote a comprehensive Cypress end-to-end test suite for the config wizard.

Cypress is a JavaScript end-to-end testing framework for modern web applications. Unlike Selenium-based tools that run outside the browser, Cypress executes directly in the browser alongside the application, giving it native access to the DOM, network requests, and browser APIs. It provides a chainable command API (e.g., cy.get().type().blur()) for interacting with elements, cy.intercept() for stubbing and spying on network requests, and cy.wait() for synchronizing on asynchronous operations.

  • A key technique I learned was using cy.intercept() to stub backend API calls, which allowed the frontend tests to run independently of the Java backend server.
  • I created reusable setupIntercepts() helper functions that accept overrides, making it easy to test both success and error scenarios. For example, passing { validate: { valid: false, error: 'Repository not found' } } to simulate an invalid repo URL.
  • I also learned how to test multi-step wizard flows by writing navigation helper functions that programmatically advance through earlier steps before testing the target step.
  • Other Cypress patterns I picked up include stubbing window:alert with cy.stub().as('alert') to assert on alert messages, using cy.wait('@alias') to synchronize on intercepted network requests, and configuring a custom baseUrl via Cypress.env('configWizardBaseUrl') so the wizard tests can target a different dev server than the main RepoSense app.

YU LETIAN

Project Knowledge

RepoSense

Vue.js

  • Working with .vue single-file components using Pug templates, scoped SCSS, and Vue 3 composition patterns
  • Built a reusable c-scroll-top-button component with a scroll-container-id prop, avoiding duplication across summary.vue, c-authorship.vue, and c-global-file-browser.vue
  • Used composables as the Vue 3 idiomatic pattern for shared stateful logic

Cypress

  • Ran tests via ./gradlew testFrontend or npm run cypress:open/run
  • Debugged cy.scrollTo() failures — the key lesson: Cypress won't scroll an element unless it's actually scrollable (scrollHeight > clientHeight), so tests need to ensure content is loaded first

AI in Development

Gemini integration for Java

resources Used:

MCP Server Basics

  • Built calculator MCP servers (calculator, plane ticket (with google api), weather reporter) from scratch
  • Understood the architecture
  • Connected local MCP servers to Claude Desktop via claude_desktop_config.json

Setup claude github

  • use claude and copilot to create, review PRs.

TEAMMATES

AARON TOH YINGWEI

Tool/Technology 1

Github Copilot

  • The model used matters. Claude models are much more effective and understanding large code bases and the relationships between different components.
  • Context matters. Conversations that drag for too long tend to hallucinate and give inaccurate answers.

Tool/Technology 2

Claude Code

I familiarised myself with key claude commands that enable me to manage the context window of a conversation and learnt to plug local LLMs into Claude Code.

Context Management

  • Auto-compaction triggers at ~95% usage, summarising older history automatically
  • /compact — manually compress at ~80–90%; run at logical task breakpoints
  • /clear — full wipe; use when switching to an entirely new task

/resume and /rewind

  • /resume — returns to a previous session via an interactive picker; or use claude --resume / claude -c from the terminal
  • /rewind — rolls back to any prior turn; choose to revert conversation only, code only, or both. Trigger with /rewind or double-tap Esc

/model

Switch models mid-session without restarting. Use Option+P / Alt+P as a shortcut while composing.

  • /model opus — most capable, slowest
  • /model sonnet — balanced default
  • /model haiku — fast and lightweight

To use Gemma 4 locally, connect Claude Code to Ollama's Anthropic-compatible API. Gemma 4 (26B MoE, 3.8B active) supports 256K context with zero API cost.

@ File References

  • Type @<filepath> to inject a file's content directly into context. Claude Code autocompletes the path — faster than describing the file or waiting for Claude to find it.

Tool/Technology 3

Upgrading Encryption Stack

  • AES-GCM vs AES-ECB: AES-GCM is an authenticated encryption mode providing both confidentiality and integrity in one primitive, whereas AES-ECB is deterministic and unauthenticated — the same plaintext always produces the same ciphertext, making it vulnerable to pattern analysis.

  • Non-deterministic encryption: AES-GCM uses a random IV per encryption call, so the same plaintext produces a different ciphertext each time. This breaks any code that compares ciphertexts directly and requires a decrypt-then-compare approach instead.

  • SHA-1 vs SHA-256: SHA-1 is considered cryptographically weak by modern standards. Upgrading to SHA-256 provides stronger collision resistance and a larger 256-bit output.

  • Key separation: Using the same key for both AES encryption and HMAC is bad practice as cross-algorithm interactions can theoretically leak key material. Separate independently generated keys should be used for each purpose.

Tool/Technology 4

Schema Management

  • Liquibase change logs - should be the source of truth. Liquibase logs all changes, its authors, time etc and includes rollbacks. Hibernate update is unreviewable and untraceable.
  • Hibernate validate — switch from update to validate so Hibernate verifies the schema matches entities on startup instead of silently patching it. Makes schema drift visible immediately rather than masking missing migrations.
  • Separation of concerns — Liquibase owns the schema; Hibernate only verifies it.

Migration Workflow

  • liquibase-hibernate as referenceUrl — reads the desired schema directly from entity annotations, eliminating the need to spin up a server on a reference branch just to materialise its schema for diffing.

FLORIAN VIOREL TANELY

Github Copilot

Learning points:

  • Provide as much context as possible, using extensions (@), commands (/), and file context (#)
  • Keep each chat focused on a relatively small objective
  • Agent mode is powerful for complex tasks, and also good as an investigative tool compared to ask mode with findings given as a rich document
  • Treat is as a pair programmer, explain and ask things as you would to a human partner
  • It is easy to get lost changing codes since Copilot makes it much easier to debug and try things out quickly that it is worth the time to ask yourself if any changes should be part of another PR

Resources used:

  • Github website
  • Gemini and ChatGPT for additional help List the aspects you learned, and the resources you used to learn them, and a brief summary of each resource.

KOH WEE JEAN

Gemini Code Assist

Gemini Code Assist is an AI-powered collaborator integrated directly into the IDE to help developers write, understand, and troubleshoot code.

Learning points:

  • Codebase Navigation: Used the assistant to track execution flow and trace logic across multiple files, which is invaluable for understanding how legacy systems and new implementations interact in a large codebase.
  • Linting and Formatting: Leveraged the tool to pre-check code against strict project style guides, quickly catching and resolving checkstyle and linting errors before pushing commits.
  • Context-Aware Debugging: Learned to feed specific error logs and file context into the prompt to rapidly diagnose complex issues, such as database connection failures or syntax errors.

Resources:

PHOEBE YAP XIN HUI

GitHub Copilot

  • Effective for understanding a large codebase using #codebase, helping me to identify relevant directories and files for E2E test migrations

  • Useful for generating repetitive or boilerplate files (e.g. SQL-specific E2E test JSON) when similar examples already exist

  • Less effective at identifying logical errors, often fixing symptoms (modifying test data) instead of root causes (updating test logic)

  • Struggles with browser-based E2E tests due to lack of awareness of actual UI state and rendered content

  • May ignore constraints in prompts and go off-tangent, requiring careful supervision and iteration

  • Different modes can serve different purposes: Ask/Plan for exploration, Edit/Agent for code generation

  • Undo functionality is useful for restarting cleanly.

  • Output quality can be inconsistent even with similar prompts, requiring manual verification (especially for strict JSON formats).

Data Migration

  • Data migration can be approached either top-down (front to back) or bottom-up (back to front), depending on the situation.
    • Example dependency chain: DeleteInstructorActionTest → InstructorLogic → Logic → InstructorsDb.

    • Top-down approach (front to back): Starts from endpoints of dependency

      • Changes are usually non-breaking initially.
      • Risk of missing dependent components if the call chain is not fully traced.
    • Bottom-up approach (back to front): Starts from database or low-level components.

      • Changes are often breaking during migration and require iterative fixes.
      • Immediately reveals all affected files and dependencies.
    • The choice of approach should be made based on the scope, risk, and complexity of the migration task.

GCP in GitHub Actions

Deployment Credentials

  • Treating CI/CD auth as an afterthought is a real risk as deployment credentials have broad cloud access, never expire by default, and are hard to rotate

  • Short-lived tokens (via Workload Identity Federation) eliminate an entire class of risk. If a token leaks, it's expired within the hour

Authentication

  • Workload Identity Federation: Rather than storing a credential, the pipeline proves its identity

    • GitHub issues a signed token containing the repo, branch, and run context, which GCP validates against a trust policy configured once
  • IAM makes least privilege concrete: grant a specific role, to a specific identity, on a specific resource. A compromised deploy pipeline should only be able to deploy

  • Scoping trust by repo and branch goes further because even a fork of the same codebase can't trigger a deploy.

SARIPALLI BHAGAT SAI REDDY

Cursor

Learned how to use Cursor as an AI-assisted development environment for code generation, refactoring, debugging, and understanding unfamiliar codebases.

Resources used:

  • Cursor official documentation
    Learned the main product features, including inline editing, AI chat, and codebase-aware assistance.
  • Hands-on project experience
    Applied Cursor in real coding tasks, which helped me understand how to use it effectively for implementation and debugging rather than just code generation.

agents.md

Learned how to define project-specific agent instructions using agents.md to improve consistency, task delegation, and adherence to coding conventions.

Resources used:

  • Online examples and community discussions
    Learned how developers use agent instruction files to guide AI behaviour in coding workflows.
  • Personal experimentation
    Practised writing instructions tailored to software engineering tasks such as editing files, following project structure, and maintaining style consistency.

OpenAI API

Learned how to integrate the OpenAI API into software applications to build LLM-powered features and automate language-based tasks, such as csv pasing for form submissions.

Resources used:

  • OpenAI API documentation
    Learned the fundamentals of API usage, request formatting, and response handling.
  • Personal implementation work
    Built familiarity with practical integration concerns such as prompt design, output parsing, and feature prototyping.

Prompt Engineering for Software Engineering Tasks

Learned how to design effective prompts for technical tasks such as code generation, debugging, summarization, and implementation planning.

Resources used:

  • Repeated use of Cursor and OpenAI API
    Learned through experimentation how prompt specificity, constraints, and context improve output quality.
  • Community-shared prompt patterns
    Observed effective prompt structures used by other developers for engineering workflows.

AI-Assisted Debugging and Refactoring

Learned how to use AI tools to analyse bugs, explain code behaviour, and support incremental refactoring in existing systems.

Resources used:

  • Cursor in day-to-day development
    Used AI support to trace bugs, understand unfamiliar code, and explore alternative implementations.
  • Real project experience
    Helped me understand the strengths and limitations of AI when working with non-trivial codebases.

Rapid Prototyping of AI Features

Learned how to quickly prototype AI-enabled product ideas by combining LLM APIs with frontend or backend applications.

Resources used:

  • Personal software projects
    Gained experience turning simple ideas into working prototypes using AI components.
  • OpenAI API documentation
    Provided the technical basis for implementing these features correctly.

YONG JUN XI

General Knowledge

Testing

  • Additional logic in test case may introduce issues:
    • More logic to maintain & might diverge.
    • Depending on the frontend may cause tests to pass if the frontend code is buggy (false-positive).
    • Depending on the local test case external logic may mismatch with what the front-end expects.
  • Be very particular about test cases (we want them to fail to spot bugs).
  • Hard-coded test inputs allow full control of the desired outcome.
  • UUID has a different format than long.
  • The server depends on the docker status, so I need to run docker first.
  • Back door APIs for testing aims to improve testing performance by providing a more direct way to perform API calls without going through the UI, for databases it allows direct manipulation to set up the exact db state the test requires. However, it may introduce security risks like allowing unauthenticated users to make API calls and false positives in test outcomes if front door API calling isn’t tested properly.
  • TestNG: @BeforeTest and @BeforeMethod differences: @BeforeTest runs before the entire test class, @BeforeMethod runs before every @Test in the same class, same applies to @AfterTest and @AfterMethod. Source

Design Patterns

  • Builder Design Pattern to allow separation of construction logic from the final product and enables flexibility in building variations of the same product.

Tips

  • You can right click and inspect a web UI element to check its ID for debugging.
  • You can terminate the E2E test early to keep a browser open, so when an E2E test fails, I can reload the previous browser to check the latest state of the failed E2E.
  • Splitting a big PR into multiple smaller ones may cause the codebase to be in an non-ideal state (such as removing tests first will introduce a codebase with un-tested features), but fine if done in one go during the same iteration or migration. Other choices include defining the clear boundary of each small PR using commits within the same PR, or push the PRs into a separate branch before merging that branch into master.
  • It’s possible to create a PR to fork’s master branch to run the CI privately.
  • You can change the base branch that a PR merges into if you have write access.

Tools

Github Copilot

  • Copilot is able to automatically scan similar files and all scripts related to them before writing the json file I need.
  • Non-agentic AI like ChatGPT on browsers can be more useful in catching mistakes in scripts and less prone to hallucinations compared to agentic AI that have to deal with a large context frame.
  • You can ask Copilot to access the git commit history on the current branch to check for potential bugs due to changes made.

VSCode

  • To run the debugger on E2E tests (add –debug-jvm to the gradle command).
  • To print statements when running tests using gradle (add –info to the gradle command).
  • Possible to run “Convert Indentation to Spaces” in the command line in VSCode.
  • Possible to run “Trim Trailing Whitespaces” in the command line in VSCode.

Git

  • Can use keywords like Closes #<issue-number> or Fixes #<issue-number> to automatically close an issue when a PR is merged, but this doesn’t work in issues (an issue cannot close another issue).
  • git switch -c <branch-name> to create and switch to the new branch, which was introduced solely for checking out branches, while ‘git checkout’ can be used for branches, commits, and files.
  • You can create a new branch and make it track an upstream branch using git switch -c <branch-name> <upstream-name>/<upstream-branch-name>.
    • Example: To fetch a branch called chore/new-branch from the upstream repo and work on it locally, simply create a new branch of any name (preferably similar to better distinguish) and make it track that upstream repo branch.
    • Command line: git switch -c chore/new-branch upstream/chore/new-branch.
  • Rebasing with -i (interactive) git rebase -i <target-branch>.
    • Rebasing to move the current commits on top of the HEAD of the target branch (i.e. doesn’t do anything if current branch is already on top).
    • Using interactive tag -i, we are able to edit/refactor the commits on the current branch and rebase will perform the operations.

TestNG

  • Sometimes snapshots can be detected to be obsolete, especially if it doesn’t match the rendering anymore, run ng test --u to update snapshots.

Gradle

  • Gradle runs tests parallelly which is much faster to run everything then a single suite which runs sequentially (Extremely slow).
  • Github CI uses extensive powerful cores that scales dynamically and has fine-tuned resource control, which is why it runs so much faster than locally.

Hibernate

  • Hibernate ignores inserted @UpdateTimestamp annotated attributes.
  • @CreationTimestamp and @UpdateTimestamp are initialized automatically with the same initial value, then @UpdateTimestamp will update itself when the entry is updated. Source