Appendix A — Building Your Research Environment

“It is the glory of God to conceal things, but the glory of kings is to search things out.” — Proverbs 25:2 (ESV)

You are about to spend a semester producing the foundation of a publishable paper. That work has a workshop, and this appendix is where you build it. Not a GPU rack. Not a server farm. Four tools — a place to keep your code under version control, a place to write the paper, a place to run the experiment, and a place to keep your sources — and the discipline to wire them together in Week 1 instead of the night before the symposium.

Hear me before you read another word: you do not need administrator rights on your laptop, and you do not need a powerful machine. Every required tool in this course runs in a browser tab on a school-locked Chromebook. I will show you that path first, because it is the cheapest path that works and it leaves no excuse. Then I will show you the local path for those of you who have admin and want your tools on your own disk. Both produce identical, gradeable, reproducible work. Choose by your situation, not your pride.

Coach’s Note — “Count the cost” (Luke 14:28, ESV) is not just about money. It is about friction. The student who spends three days fighting a CUDA install they didn’t need is the student who runs out of runway in Week 15. Pick the lightest setup that does the job, and spend the saved hours on the actual research.

A.1 — Choose Your Environment

This is a reading-, experimenting-, and writing-heavy course. The “lab” is not a hypervisor or a rented GPU — it is four free accounts and one folder. Most of you will never install anything. Find your row and commit to the path; don’t mix-and-match until you’ve got the basics working.

The backbone is smaller than you fear. The single non-negotiable account for the whole course is a free GitHub account — it is where you submit, where your paper’s code and data manifests live, and where your reproducibility gets graded. Everything else hangs off it. If you do nothing else this week, create that account.

Project → minimum environment

Don’t over-provision. Here is what each graded deliverable actually requires. Notice that nothing on this list needs a GPU you own.

A GPU is not the backbone of this course. A handful of you will choose an AI domain where a model genuinely needs a GPU for an afternoon. For that and only that, Colab and Kaggle give free GPU hours (see A.5). Nobody in this practicum should buy a graphics card. If you think you need one, the problem is almost always that your experiment is scoped too big for a one-semester practicum — fix the scope.

A.2 — Path A: The Browser-Only, No-Admin, Free Path

This is the path I want most of you on. It needs zero installs, zero admin rights, and (as of 2026) zero dollars. Do it in this order; it takes about an hour.

Step 1 — A free GitHub account (the submission backbone)

1. Go to github.com and sign up. A free account is plenty — it gives you unlimited public and private repositories.
2. Apply for the GitHub Student Developer Pack at education.github.com/pack with your .edu email. It’s free and unlocks extras (more Codespaces hours, Copilot, etc.) — as of 2026, verify current benefits, they change.
3. Create one repository for your project: your-username/research-practicum. Make it private for now (peer review is double-blind later — Chapter 15 — and you don’t want your name leaking through a public repo before you’re ready). Initialize it with a README.txt and a Python .gitignore.

That repo is your lab notebook’s permanent home. Every submission in this course is a link to a tagged commit in it. Memorize that sentence.

How to submit, every time. Commit your work, push it, and create a tag for the deliverable, then paste the tag’s URL into the assignment. From the browser you can do all of this without the Git CLI: edit files in github.com, then on the repo’s Releases page click Draft a new release, create a tag like wk09-environment, and submit that release URL. A tag is a frozen, named pointer to an exact commit — it is how a grader (and a future reproducer) gets exactly the bytes you meant, not whatever the repo looks like next week. We treat the tag as the thing that was submitted.

Step 2 — Overleaf for the paper (start the LaTeX template in Week 1)

You write the final paper in a real conference template, and I want you to create the empty shell now, in Week 1, so LaTeX is never a Week-15 surprise.

1. Sign up free at overleaf.com (the free tier compiles full papers; it limits some collaboration/history features — fine for one author, verify limits as of 2026).
2. New Project → Templates, and pick by your target venue (you’ll firm the venue up in Chapter 16):
   • ACM venues (most of CS — SIGCHI, SIGPLAN, etc.): search the acmart template. Use the sigconf proceedings option. As of 2026 the class file is acmart.cls (around v2.18, dated 2026/06/01 — verify the literal version string in your project). ACM runs accepted papers through a pipeline called TAPS that emits the two-column PDF and an HTML5 version.
   • IEEE venues: search IEEEtran (IEEEtran.cls, v1.8b; \documentclass[conference]{IEEEtran}, two columns).
3. Put your name on the title, write one sentence of abstract, hit Recompile, and confirm you get a PDF. That’s the whole Week-1 task: prove the template builds.

Two craft details you’ll use in Chapter 14, set up now so you’re not surprised:

% ACM submission (single-column, for review). Add 'anonymous' for double-blind venues.
\documentclass[manuscript,review,anonymous]{acmart}
% ...later, camera-ready becomes:
% \documentclass[sigconf]{acmart}

anonymous is what produces the “ANONYMOUS AUTHOR(S)” header that double-blind review (Chapter 15) requires. Page length is counted in the single-column submission format, not the two-column camera-ready — don’t let that bite you.

Coach’s Note — Why Overleaf even on the local path? Because LaTeX toolchains are heavy, version-fussy, and the acmart/IEEEtran classes are already preloaded on Overleaf. There is almost no reason to install a full TeX distribution for a single conference paper. Even tenured researchers draft on Overleaf. Use it.

Step 3 — A Python/Jupyter workspace in the browser (Colab or Codespaces)

You have two good no-install options. Pick one and stick with it.

Option 3a — Google Colab (best for notebook-style experiments, optional free GPU).

1. Go to colab.research.google.com, New notebook. It’s a hosted Jupyter notebook — nothing to install.
2. Connect it to your GitHub repo: File → Save a copy in GitHub, pointing at research-practicum. Now your notebooks are version-controlled.
3. Pin your environment so it’s reproducible. In the first cell:

   !pip install -q scipy==1.18.0 statsmodels scikit-learn matplotlib seaborn
   !pip freeze > requirements.txt   # commit this file — it is your environment manifest

   Free-tier sessions are ephemeral — they reset and time out (limits vary, as of 2026). That is a feature for reproducibility, not a bug: it forces you to re-create your environment from requirements.txt every time, which is exactly what a reproducer will do. Save data and outputs to your repo or Google Drive; never trust the session disk.

Option 3b — GitHub Codespaces (best if you want a full VS Code + Linux + terminal in the browser).

1. From your repo on github.com: Code → Codespaces → Create codespace on main. You get browser VS Code on a Linux container — you are effectively root in there, so pip, git, even Docker work, all with no admin on your laptop.
2. Free personal accounts get roughly 120 core-hours/month (about 60 hours on the default 2-core machine), as of 2026 — verify your quota. Stop the codespace when you walk away (Codespaces menu → Stop) so idle hours don’t burn your budget. Delete it when the deliverable’s done.

Either way, your reproducibility deliverable in Chapter 9 is the same: a notebook that runs top-to-bottom, a pinned requirements.txt, and a fixed random seed (Chapter 9 covers the full seeding ritual — numpy, random, and the framework you use).

Step 4 — A Zotero library for your sources

You will read dozens of papers and you must cite them honestly and exactly. Zotero is the free, open-source reference manager that does this.

1. Create a free account at zotero.org and use the web library (zotero.org/mylibrary) — no install needed. Add the Zotero Connector browser extension if your browser allows extensions; if it doesn’t (locked-down machine), you can add items by DOI/ISBN/arXiv ID by hand in the web library.
2. Make a collection named for your project. As you do the Chapter 3 literature search, save every paper into it — capture the DOI, not just a PDF.
3. When you write in Overleaf, export the collection as a BibTeX (.bib) file straight from the web library: select the collection → the ⋯ (More) menu → Export → choose BibTeX format → save the .bib and drop it into your Overleaf project. As of 2026 the web library exports BibTeX with no add-on and no install. Re-export whenever you add sources. This is the path most of you will use, and it is enough for everything this course grades — see the box below before you reach for anything heavier.

The no-admin .bib path, and where “Better BibTeX” fits. You will see Project 4 and other places mention Better BibTeX. It is a popular Zotero add-on that auto-syncs a .bib file and pins stable, human-readable cite keys (e.g. jimenez2024swebench) that don’t churn when you re-export. It is genuinely nice — but it requires the Zotero desktop app, which needs admin rights to install (Path B). If you’re on a locked-down or no-admin machine, you do not need it. The web library’s plain BibTeX export above is the no-admin default, and it produces a fully valid, gradeable .bib. The only thing you give up is auto-generated cite keys, and there are two clean ways to keep yours stable by hand:

• Set the cite key once, in the item. In the web library, the cite key Zotero exports comes from the item’s metadata; give each paper a sensible, consistent Date and first-author Last name and Zotero builds a predictable key. Whatever key it assigns, decide it once and stop touching the item’s author/year, and the key won’t move on re-export.
• Rename keys in the .bib if you must — then never re-export over it. If you hand-pick keys like jimenez2024swebench directly in the exported file, treat that file as the source of truth for keys and re-export to a different filename so you don’t clobber your edits. (The cleaner habit is to fix metadata in Zotero and re-export, exactly as Chapter 4 teaches — but on the no-admin path you may not have auto-keys, so this manual fallback exists.)

Bottom line: Better BibTeX is optional convenience, not a requirement. Wherever this book asks for “a references.bib from Zotero,” the no-admin web-library export satisfies it. Reach for Better BibTeX only if you’re already on Path B and want the auto-sync.

That’s Path A. Four browser tabs, one repo, zero installs. Go.

A.3 — Path B: The Local Path (admin rights required)

Take this path only if you have administrator rights on your own machine and you genuinely prefer your tools on local disk. If you can’t get admin, use Path A — don’t fight your IT department for a week. Local buys you offline work and faster iteration; it costs you setup time. Worth it for some, a trap for others.

Step 1 — Git, locally

git --version        # macOS: already there, or installs with Xcode CLT. Windows: install "Git for Windows".
git config --global user.name  "Your Name"
git config --global user.email "you@example.edu"
git clone https://github.com/your-username/research-practicum.git

Submission is the same as Path A, but from the command line:

git add -A
git commit -m "Week 9: reproducible environment"
git push
git tag wk09-environment        # name the frozen deliverable
git push origin wk09-environment

Then submit the tag’s URL on GitHub. Same rule as before: the tag is the thing you submitted.

Step 2 — Python + a virtual environment + Jupyter

Use a virtual environment so this course’s packages never collide with anything else on your machine. From inside your cloned repo:

python3 -m venv .venv                 # create an isolated environment in ./.venv
source .venv/bin/activate             # macOS/Linux
# .\.venv\Scripts\activate            # Windows PowerShell
pip install --upgrade pip
pip install scipy statsmodels scikit-learn matplotlib seaborn jupyterlab
pip freeze > requirements.txt         # commit this — your environment manifest
jupyter lab                           # opens Jupyter in your browser, served locally

Add .venv/ to your .gitignore (the GitHub Python .gitignore already does). You commit requirements.txt, not the environment itself — the manifest is what makes the work reproducible; the half-gigabyte of installed packages is not.

Coach’s Note — A reproducible environment is the difference between “it works on my machine” and science. requirements.txt is the minimum. Chapter 9 goes further — pinned versions, conda-lock for transitive dependencies, Docker for system libraries like CUDA, and archiving a tagged release to Zenodo for a permanent DOI. Don’t reach for the heavy machinery until your project actually needs it; pinned pip freeze carries most practicum projects all the way to the symposium.

Step 3 — Zotero desktop

Install Zotero from zotero.org/download, sign in to sync with your web library, and add the Zotero Connector for your browser. On this path — and only this path, because it needs the desktop app and therefore admin rights — you can also add the Better BibTeX add-on, which keeps a .bib file auto-updated and pins stable cite keys for your paper. It’s a convenience, not a requirement: if you ever lose admin and fall back to Path A, the web library’s plain BibTeX export (A.2, Step 4) produces the same gradeable .bib. The paper itself still lives on Overleaf — there is no local-LaTeX requirement in this course.

A.4 — Verify the Whole Setup (do this in Week 1)

Don’t assume it works. Prove it. You pass this acceptance test when every box is checked:

• GitHub: a (private) research-practicum repo exists with a README.txt, and you can create a release/tag and copy its URL.
• Submit drill: you’ve made a throwaway tag (e.g. wk01-setup) and confirmed the tag URL opens the exact files you expect.
• Overleaf: your acmart or IEEEtran project compiles to a PDF with your (or “ANONYMOUS”) name on it.
• Notebook: a Colab/Codespaces/local Jupyter notebook runs a cell that imports scipy and prints scipy.__version__, and you’ve committed a requirements.txt.
• Reproducibility seed: that notebook sets a fixed seed and produces the same number on two runs.
• Zotero: one real paper is saved in your project collection with its DOI, and you’ve exported a .bib.

If all six pass, your research environment is real. Tag it wk01-setup, push, and submit — that’s your first commit to a paper that could end up at a real venue.

A.5 — When (and Only When) You Need a GPU

Most of you will not. But if your chosen AI domain truly requires running a model on a GPU — say you’re fine-tuning or doing vision work — use free hosted notebooks before you spend a cent:

• Google Colab — free GPU sessions (type/availability vary and can vanish mid-session; as of 2026). Fine for “load a model and watch it run” and small fine-tunes. Save checkpoints to Drive/your repo constantly, because sessions reset.
• Kaggle Notebooks — a free weekly quota of GPU hours (as of 2026, roughly 30 hrs/week — verify), often more predictable than Colab for a planned run.

If, and only if, a free notebook genuinely can’t hold your job, you rent a GPU by the hour (RunPod, Lambda, Vast.ai, or a hyperscaler) — never buy one for a semester course. And if you rent:

1. Set a budget alert before you launch anything.
2. Keep a teardown checklist: stop the instance the moment the run finishes, delete the volume, confirm in the billing console that the meter stopped.
3. Treat every idle hour as money on fire. Stop. Delete. Verify.

Coach’s Note — The honest scoping question is not “how big a GPU can I get?” It’s “what is the smallest experiment that tests my hypothesis?” A practicum is one semester. A result on a small model, run cleanly and analyzed honestly, beats a half-finished run on a model you couldn’t afford. Scope to what you can finish.

A.6 — Stewardship and the Discipline of “Just Enough”

Two threads run through everything above, and they’re the same thread.

The first is honesty before God with your environment. Reproducibility is not bureaucratic box-checking — it is telling the truth about what you did, in enough detail that another person can stand where you stood and see what you saw. Proverbs says the glory of kings is to search things out (Prov. 25:2, ESV); a result no one can reproduce hasn’t been searched out, it’s been asserted. The pinned requirements.txt, the fixed seed, the tagged commit — these are how you keep your word about your own work.

The second is stewardship of what you’ve been given — your time, your school’s locked-down laptop, a free tier somebody else pays to provide, a rented GPU’s meter. “Count the cost” (Luke 14:28, ESV) before you build, and don’t take more than the work requires. The cheapest path that does the job, used fully and torn down when done, is not the lazy choice. It is the faithful one. It leaves you the runway to do the actual research — which is the whole point.

Build the environment this week. Tag it. Then go find your problem.

See you in the lab.