FIT2109 Computer Science Workshop
The Complete Study & Assessment Guide · S2 2026FIT2109 Overview
- Monash University
- Semester 2, 2026
- Level 2
- On-campus applied sessions
FIT2109 Computer Science Workshop develops practical proficiency with the tools used in computer-science work. The unit description names the command line, a powerful text editor, version control, debugging, profiling, secure remote work, virtual machines, data wrangling and metaprogramming.
- Assessed by Demonstration, written work, an in-class test and a project
- Hardest step Explaining why a tool changed the observed state
- How to prepare Rebuild small scenarios and verify every transition
How FIT2109 is assessed
| Component | Weight | Format |
|---|---|---|
| 1. Demonstration | 15% | Allocated applied-session tasks that verify personal fluency with the tools. |
| 2. Written | 35% | Assignment 1 and Assignment 2. Captured due dates were 4 September and 2 October 2026. |
| 3. Quiz / Test | 15% | Supervised on-campus in-class test using SEB. Student instructions state 50 minutes, closed book, with multiple-choice and short or medium answers. |
| 4. Project | 35% | Group project. The captured final-submission due date was 4 November 2026. |
What FIT2109 covers
Follow the unit from shell foundations and Git through containers, debugging, performance, data work, automation and responsible AI-assisted development.
Shell Foundations
Paths, working directories, streams, exit status and a method for diagnosing command failures.Shell Foundations introduces a command as an observable process with arguments, a working directory, input, ordinary output, diagnostic output and an exit status. The key skill is not recalling isolated commands.
- The shell as a program interface rather than a list of shortcuts
- Absolute and relative paths interpreted from the working directory
- Arguments, quoting and the difference between grouping and validation
- Standard input as the default data source for a command
- Standard output as the intended result channel
- Standard error as a separate diagnostic channel
Shell Tools and Scripting
Pipelines, record selection, arguments, validation, recursive file discovery and stable reports.Shell Tools and Scripting develops a pipeline from a series of observable stages: discover eligible files, validate records, filter the population, aggregate values and format a stable result.
- Pipeline stages with one observable responsibility each
- Recursive discovery restricted to eligible regular files
- Blank, comment and malformed record policies
- Pipes as producer-to-consumer stream connections
- Redirection as a destination choice for a stream
- Argument validation before data processing begins
Editors and Modern IDEs
Search, navigation, bounded edits, state awareness and a reviewable feedback loop.Editors and Modern IDEs focuses on the feedback loop rather than a particular product.
- Project-wide search from a failing symbol or exact message
- Symbol navigation and caller inspection
- Bounded edits tied to one behavioural hypothesis
- Focused tests before wider verification
- Saved buffers versus files on disk
- Working-tree changes versus staged content
Git Foundations
Working tree, index, commits, status, focused history and recoverable state changes.Git Foundations is built around three states. The working tree contains editable files, the index contains the proposed next snapshot, and the repository contains recorded commits. A commit records the index.
- Repository snapshots connected by parent relationships
- Working-tree files as the editable project state
- The index as the proposed next snapshot
- Status as two comparisons presented together
- Focused commits that preserve a development narrative
- Commit messages that describe purpose rather than activity
Git Collaboration and History
Branches, ancestry, true merges, tags, merge requests and semantic conflict review.Git Collaboration and History adds movable branch labels, fixed release tags and multiple lines of ancestry to the snapshot model. The graph is formed by parent links between commits.
- Branches as movable labels for continuing work
- HEAD as the checked-out position through a branch or commit
- Tags as labels that remain on selected snapshots
- Common ancestors and the point where histories diverge
- True merges identified by two parent commits
- Fast-forward updates along one existing ancestry
Virtual Machines, Containers and Packages
Isolation layers, Dockerfile phases, runtime dependencies and clean-environment verification.Virtual Machines, Containers and Packages compares isolation boundaries and the ingredients of a reproducible runtime. A virtual machine includes a guest operating system above a hypervisor.
- Virtual machines with a guest operating system
- Containers sharing the host kernel
- Image layers produced during the build
- Build context and the files available to COPY
- Runtime Python dependencies versus test tooling
- System executables required by application behaviour
Command-Line Environments
Remote processes, backgrounding, hangup protection, persistent terminals and observable jobs.Command-Line Environments separates prompt control, hangup protection and persistent terminal sessions.
- SSH connection lifetime versus remote process lifetime
- Background execution that returns the current prompt
- Hangup signals after a controlling session disappears
- Non-interactive jobs protected by nohup and logs
- Persistent terminal sessions created with tmux
- Starting work inside the session that should preserve it
Systematic Debugging
Reproduction, controlled observation, falsifiable hypotheses, root-cause fixes and regression checks.Systematic Debugging begins by making the failure reproducible. Record the exact input, environment, command and observed result before editing code.
- Reproducible inputs, environment and trigger steps
- Symptoms separated from mechanisms and root causes
- The first incorrect value or state boundary
- Falsifiable hypotheses that predict an observation
- Focused tests as executable behaviour contracts
- One controlled change rather than stacked guesses
Profiling and Performance
Defined workloads, repeatable benchmarks, hotspot interpretation and correctness-preserving optimisation.Profiling and Performance applies the debugging evidence loop to resource use.
- A performance question with a named operation and metric
- Representative inputs held constant across versions
- Repeated baseline measurements and visible variability
- Profiles that rank cost by function or operation
- Call relationships that explain repeated work
- Correctness parity before accepting a speed result
Data Wrangling
Data contracts, validation, reconciliation, join cardinality and repeatable transformations.Data Wrangling turns irregular inputs into a form that can answer a defined question. A pipeline can finish successfully while silently dropping rows, coercing invalid values or changing the intended population.
- Source scope and one-record structure
- Structural validity for fields and types
- Semantic validity for meaningful values
- Population validity for in-scope records
- Reconciliation counts at transformation boundaries
- Normalisation choices that preserve needed evidence
Metaprogramming and Automation
Task contracts, idempotent generation, visible failures, safe promotion and human checkpoints.Metaprogramming and Automation begins with a stable task contract. State the inputs, ordered transformations, expected artifacts, failure conditions and points that still require judgement.
- Manual task contracts before implementation
- Explicit input and output ownership
- Generated artifacts separated from hand-edited content
- Idempotent behaviour across repeated runs
- Atomic construction and promotion
- Failure status that cannot resemble success
Agentic Coding
Assessment-specific tool boundaries, evidence-based review, personal verification and use declarations.Agentic Coding is governed by the current assessment rule, not by a tool's capability.
- Assessment-specific rules checked before tool selection
- Chatbot assistance distinguished from direct code-changing agents
- Prompts and responses preserved for the required declaration
- Student decisions to accept, change or reject suggestions
- Project specifications and tests used as evidence
- Personal verification of every accepted change
The weekly sequence extends that foundation through containers, package management, command-line environments, automation and agentic coding. The emphasis is operational: students solve realistic problems, use tools directly and explain the evidence produced by those tools.
The course is best approached as a collection of connected state models. Shell commands read arguments, paths and streams.
Editors change buffers and files. Git compares the working tree, index and repository. Containers combine application source with runtime packages and system tools. Debugging moves from a reproducible symptom to the first incorrect state, while profiling asks where a defined workload spends resources.
Data wrangling and automation reuse the same habits at pipeline scale: declare the population, expose transformations, reconcile totals and fail visibly.
The published assessment structure contains four categories that sum to the complete unit mark. Demonstration is worth 15%, Written is worth 35%, Quiz / Test is worth 15%, and Project is worth 35%.
The timed component is named an in-class test, takes place on campus under supervision and uses SEB. The student-facing instructions describe a closed-book, 50-minute quiz with multiple-choice and short or medium answers.
A separate configuration line displays one hour, so students should follow the live instructions for their attempt.
The mock test and sample solution reveal the kinds of reasoning that matter: reading a Git commit graph, distinguishing pipes from redirection, choosing reproduction as the first debugging move, interpreting Dockerfile phases, comparing remote-session mechanisms and explaining staged versus unstaged changes.
The questions in this guide are newly authored from those families. They do not reproduce the supplied stems or datasets.
Worked example · free
Explain a Git file that is both staged and unstaged
- +1Name the three states: the current commit, the index and the working-tree file.
- +1Explain that an earlier version of parser.py was copied into the index when it was staged.
- +1Explain that parser.py was edited again afterward, so the working tree now differs from the index.
- +1State that the next commit records the indexed version, not the newer unstaged edits.
- +1Verify by inspecting the staged diff separately from the unstaged diff.
Key terms
- Standard input
- The data stream a command reads by default. A pipe can connect another command's standard output to this stream.
- Standard error
- The diagnostic stream kept separate from ordinary output so failures can remain visible while results are redirected or parsed.
- Pipeline
- A composition in which one command's output becomes another command's input. Each stage should preserve a clear record contract.
- Working tree
- The checked-out project files that can be edited. Git compares them with the index to report unstaged changes.
- Index
- Git's proposed next snapshot. A commit records this staged content rather than every current working-tree edit.
- True merge
- A commit with two parents that joins diverged lines of history. Parent structure distinguishes it from a fast-forward.
- Container image
- A built filesystem and configuration used to start containers. It must include the runtime packages and system tools required by the application.
- Reproducible case
- A controlled input, environment and sequence that reliably exposes a fault and provides a baseline for verifying a repair.
- Profile
- Measured information about where a defined workload spends time or resources. It locates cost but still requires interpretation.
- Idempotence
- The property that rerunning an operation with unchanged inputs preserves the same logical result instead of accumulating duplicates or drift.
FIT2109 FAQ
How is the unit assessed?
The published structure has four categories: Demonstration at 15%, Written at 35%, Quiz / Test at 15%, and Project at 35%. The figures total 100%. The captured materials identify the timed task as a supervised in-class test, not a final assessment period test.
What is the in-class test format?
The student instructions describe an on-campus, supervised, closed-book test using SEB, with multiple-choice and short or medium answers. They state 50 minutes, while a separate configuration line displays one hour, so follow the live instructions shown for the current attempt.
What should I practise for shell questions?
Practise resolving relative paths from a known working directory, separating ordinary output from diagnostics, tracing a pipeline from producer to consumer, and explaining whether a command counts lines, occurrences, files or another unit. Use tiny invented fixtures so every result can be predicted.
How should I prepare for Git graph questions?
Draw commits and parent links, then add branch, tag and HEAD labels. Identify the common ancestor, count parents on the integrating commit and inspect the index separately from the working tree. State the graph fact that proves each conclusion.
Why can a container build but fail when it runs?
Build success proves that image-construction instructions completed. The application can still lack a runtime Python package, an external system executable, the expected repository path or a correct start-up command. Verify every supported command inside the built image against a known repository.
What evidence strengthens the assignments?
Use focused tests, logical Git commits, a reproducible setup route, stable command output and a report that connects each defect or design choice to its cause and verification. Demonstrations should use the submitted version and show personal understanding of the result.
What are the AI-use rules for Assignment 2?
The captured specification permits chatbot-style assistance but bars agentic coding tools that directly write or apply changes in the editor or terminal. It requires the prompt, response and the student's explanation of what was accepted, changed or rejected. Always check the current task instructions before using a tool.
Questions students ask in each FIT2109 chapter
- Why does a relative path work in one terminal but not another?
- Relative paths are resolved from each process's current working directory. Two terminals can be in different directories even when they display the same project. Print the directory and resolve the target before changing permissions or code. Chapter 01 · Shell Foundations
- What is the difference between a pipe and output redirection?
- A pipe connects one command's ordinary output to another command's input. Output redirection sends the stream to a file or destination. Using a redirection symbol where a pipe is needed creates a file rather than invoking the intended consumer. Chapter 02 · Shell Tools and Scripting
- Why search before browsing folders manually?
- A failing function name, message or option can appear in implementation, tests, configuration and documentation. Project-wide search reveals those representations quickly and reduces the chance of editing a similarly named but irrelevant file. Chapter 03 · Editors and Modern IDEs
- Why is the index more than a list of filenames?
- It stores the content proposed for the next snapshot. A file can be staged and then edited again because the index preserves the earlier version while the working tree moves onward. Chapter 04 · Git Foundations
- How do I identify where two branches diverged?
- Follow parent links backward from both tips until the histories meet. The shared commit before each line gains different descendants is their common ancestor for the scenario. Chapter 05 · Git Collaboration and History
- What is the key difference between a virtual machine and a container?
- A virtual machine includes a guest operating system above a hypervisor, while a container shares the host kernel and packages the application with its user-space dependencies. That boundary affects portability, isolation and overhead. Chapter 06 · Virtual Machines, Containers and Packages
- Why is backgrounding not enough for a dropped connection?
- Backgrounding returns the shell prompt but leaves the process associated with the session unless other protection is arranged. A later hangup can still affect it, so prompt control and connection survival are separate requirements. Chapter 07 · Command-Line Environments
- What should I do first with an intermittent failure?
- Record the input, environment and exact trigger steps, then reduce the case while preserving the failure. Without a reproducible baseline, you cannot know whether an edit repaired or merely obscured the problem. Chapter 08 · Systematic Debugging
- Why should I profile before optimising?
- The apparent slow line may contribute little to total time. A profile locates dominant measured cost and helps estimate whether a proposed change can materially affect the complete workload. Chapter 09 · Profiling and Performance
- Why keep invalid records instead of silently dropping them?
- A quarantine or rejection report preserves evidence about source quality and lets totals reconcile. Silent deletion can make a smaller output look valid while hiding a parser or upstream data problem entirely. Chapter 10 · Data Wrangling
- What should be automated first?
- Choose a repeated task whose inputs, outputs and success checks can be stated clearly. Stabilise the manual route before encoding it so the tool does not preserve an unclear or unsafe process. Chapter 11 · Metaprogramming and Automation
- Are direct code-changing AI tools allowed for Assignment 2?
- The captured specification says no. It permits chatbot-style tools under stated conditions but bars agentic coding tools that directly write or apply changes in the editor or terminal. Check the current task instructions before use. Chapter 12 · Agentic Coding
How to prepare for the assessments
Revise by rebuilding small systems rather than rereading commands. First draw the state model for the topic. For shell work, label arguments, paths and streams. For Git, draw the current commit, index and working tree, then add branch and tag labels. For containers, separate source, Python runtime packages and system executables. For debugging, preserve a failing input and state the hypothesis before editing.
For profiling, define one workload and correctness check before measuring. For data wrangling, keep a count ledger through discovery, validation, filtering and aggregation. Second, perform one original task in a disposable workspace and inspect every intermediate state. Third, explain the result aloud using the evidence that proves it.
Use the mock question families for retrieval practice, but write new examples and avoid memorising the supplied stems. Before the in-class test, verify SEB through the practice route and rehearse concise distinctions under closed-book conditions. Before assignment submission, reproduce the solution from a fresh repository location and follow the README exactly.
Confirm tests, runtime dependencies, container commands, required reports, Git history and the AI-use declaration. The final goal is personal fluency: you should be able to locate the relevant state, predict a change, verify the outcome and explain why it follows.
Your AI Computer Science tutor for FIT2109
Stuck on a hard FIT2109 question? Sia is AskSia’s AI Computer Science tutor — ask any FIT2109 Computer Science Workshop question and get a clear, step-by-step explanation grounded in how the course is actually taught and assessed. Read this whole study guide free, then take your hardest questions to Sia.
