IS 4010: Application Development with Artificial Intelligence

Week 01: Course introduction and setup

Brandon M. Greenwell

Course introduction

About the instructor

Read my GitHub profile README

The software world has changed

• AI code assistants now appear in browser, editor, terminal, and repository workflows.
• Knowing how to use these tools effectively is becoming a required skill for new graduates.
• Our goal is proficiency in both programming languages and AI-augmented development workflows.

Our course philosophy

• This course directly addresses the valid concerns of using AI in education.
• We’ll use AI to handle boilerplate and accelerate development, not to do our thinking for us.
• You’re the pilot! You’re responsible for every line of code, and you must understand, test, and be able to explain the code you submit.
• We’ll test where AI assistance is useful or unreliable, including context limits, fabricated claims, and repeatability.

What we’ll learn

• Write readable, tested Python and Rust code.
• Use Git and GitHub for version control and collaboration.
• Leverage AI code assistants to write, debug, and refactor code.
• Build data-driven applications that interact with documented APIs.
• Create a unique portfolio project that showcases your skills to future employers.

Our roadmap

• Foundations & modern tooling (Git, GitHub, AI assistants) (weeks 1-2)
• Python fundamentals with an AI partner (from basics to OOP) (weeks 3-6)
• Building a Python application (APIs and professional tools) (weeks 7-8)
• Rust fundamentals and application development (weeks 9-14)
• Final solo project, built alongside the second half of the course

Key course components

• Our grading is designed to reflect hands-on, applied skill.
• Labs: 65%
• Final (solo) project: 20%
• Class participation: 15%
• Our primary communication channel will be our associated class channel in Microsoft Teams.

Important course links

• Course Canvas: uc.instructure.com (grades, slides, labs, due dates, etc.)
• Labs repository: GitHub (all 14 labs and status badges)
• Official syllabus: Simple Syllabus (the authoritative record)
• Communication: Microsoft Teams (primary discussion, questions about the material, questions about the labs, etc.)

The final project: your portfolio piece

• The culmination of this course is a student-choice final project.
• You get to propose and build an application you’re passionate about.
• The project must meaningfully use Python or Rust and document your AI-enhanced workflow.
• This is your chance to create something unique that you can proudly showcase.

Setup fest

• Time to get our hands dirty.
• We’ll now spend the rest of the session setting up our development environment.
• Checklist: Follow the detailed setup guide.
  • Install Visual Studio Code
  • Install Git
  • Install uv (it manages Python 3.12 for us)
  • Defer the Rust toolchain until Week 09

How to know it’s working

• Open your terminal or command prompt and run the following commands:
  • git --version
  • uv --version
  • uv run python --version
• We’ll walk through this together.

Lab 01 this week

• Create your GitHub account if you haven’t already.
• Use the terminal, fork and clone the semester repository, then run uv sync --locked.
• Submit your fork URL in Canvas and confirm the Week 01 badge is green.
• Not sure what that looks like? The demo repository shows a passing badge, a failing one you can click into, and later weeks that have not run yet.

Terminal basics

Terminal, shell, and prompt

• The terminal is the text window where you work.
• The shell reads a command and asks the operating system to run it.
• The prompt shows that the shell is ready for your next command.
• In this course: use Git Bash on Windows or your default shell on macOS/Linux.
• VS Code’s integrated terminal is the same kind of interface inside the editor.

Location and command anatomy

uv run python hello.py
│  └──────── arguments ────────┘
└ command

• Every terminal has a current working directory.
• Relative paths begin from that directory; absolute paths name the full location.
• Spaces separate the command from its arguments.
• A command can read, create, change, or delete files, so read it before pressing Enter.

Five commands to start

pwd                 # Where am I?
ls                  # What is here?
cd path/to/folder   # Move to another folder
mkdir practice      # Create a folder
code .              # Open this folder in VS Code

• Press Tab to complete a path.
• Press Up arrow to reuse a command.
• Press Ctrl+C to stop a running command.
• Use pwd and git status whenever you are unsure where you are.

Safe terminal habits

• Work inside the repository for the current task.
• Read AI-suggested commands before approving them.
• Pause when a command says it will delete, overwrite, install globally, or request elevated access.
• Never paste passwords, tokens, or API keys into prompts or committed files.
• Use git diff before committing so you know exactly what changed.

Live demo: from a folder to VS Code

pwd
ls
mkdir is4010-demo
cd is4010-demo
pwd
code .

Narrate the prompt, current directory, relative path, command, and argument. Demonstrate Tab completion, Up arrow, Ctrl+C, and an intentional wrong directory corrected with pwd and cd. Keep this light: the goal is enough fluency to understand the Git commands that follow.

Version control with Git and GitHub

What is version control?

• Think of it as a time machine for your code.
• It tracks every single change you make to a project over time.
• It lets you rewind to a previous version if you make a mistake or need to see an older state of the code.
• It’s the absolute foundation for collaborating with other developers on a shared project.

A brief history of version control

• Early days (1970s-90s): RCS, SCCS - single files, no networking
• Centralized era (2000s): Subversion (SVN), CVS - single server, everyone syncs to it
• Distributed systems (2005): Git was created by Linus Torvalds for Linux kernel development
  • Born out of frustration with existing tools for Linux development
  • Designed for speed, data integrity, and distributed workflows
• Today: Git is widely used, with hosting platforms competing on collaboration and automation features

TEACHING NOTES:

• RCS/SCCS context: These were for individual developers - imagine saving “essay_v1.docx”, “essay_v2.docx” but automated
• Centralized problems: If the SVN server went down, nobody could save their work! All collaboration stopped
• Enter Linus Torvalds: Began Git after the Linux kernel community lost free access to BitKeeper. Focus on the design goals: speed, integrity, and distributed work.
• Why it matters: Understanding this history explains why Git feels complex - it was built by kernel developers for kernel developers
• Modern adoption: Git supports workflows ranging from solo projects to large distributed teams.

Version control systems

Centralized vs. Distributed:

Centralized (SVN, CVS)	Distributed (Git, Mercurial)
Single source of truth	Every copy is complete
Must be online to commit	Work offline, sync later
Simpler mental model	More flexible workflows
Single point of failure	Redundant by design

• Why Git won: Speed, branching, offline capability, and Linux adoption

Git hosting platforms

Platform	Strengths	Best For
GitHub	Largest community, excellent discoverability	Open source, portfolio projects
GitLab	Integrated CI/CD, self-hosting	Enterprise, DevOps workflows
Bitbucket	Atlassian integration (Jira, Confluence)	Teams using Atlassian tools
Azure DevOps	Microsoft ecosystem integration	.NET development, enterprise

• All use Git under the hood - the collaboration features differ
• For this course: GitHub hosts the labs, workflows, badges, and submissions

Git and GitHub

• This is a common point of confusion.
• Git: is the software tool that runs on your computer. It does the actual work of tracking changes. (Think of it like Microsoft Word.)
• GitHub: is a website that stores your Git projects in the cloud. It’s where you share your code and collaborate. (Think of it like OneDrive or Google Docs.)

The core workflow

• Remote (GitHub): a project lives on GitHub.
• git clone: you create a local copy of the repository and its history.
• Local (your computer): you edit files, write code, and fix bugs.
• git add & git commit: you save a snapshot (a commit) of your changes to your local history.
• git push: you upload your new commits from your computer back to GitHub.

Key terminology

• Repository (repo): a folder that contains your project and its entire history.
• Commit: a snapshot of your files at a specific point in time; a saved checkpoint.
• Staging area: a temporary holding place where you gather the changes you want to include in your next commit.
• Push: the command to send your committed changes from your local computer to GitHub.

Core Git commands

• git clone <url> - Download a repository from GitHub to your computer
• git status - See what files have changed and what’s ready to commit
• git add <file> - Stage a specific file for your next commit, once you have reviewed it
• git commit -m "message" - Save your staged changes with a descriptive message
• git push - Send your commits from local to remote

The Git workflow in action

Here’s what the commands actually look like:

# Check what's changed
$ git status
On branch main
Changes not staged for commit:
  modified:   hello.py

# Stage your changes
$ git add hello.py

# Commit with a message
$ git commit -m "Fix greeting message"
[main 1a2b3c4] Fix greeting message
 1 file changed, 1 insertion(+), 1 deletion(-)

# Push to GitHub
$ git push origin main

LIVE DEMO NOTES: - Open terminal and navigate to a demo repository - Modify a file (edit hello.py to change the message) - Run each command and explain the output - Show how git status changes after each step - Demonstrate the GitHub page updating after push - If time permits, show git log to see the commit history

Live demo time!

We’ll create repositories two ways, then walk through the basic Git workflow:

1. Method 1: GitHub first - Create repo on GitHub → git clone
2. Method 2: Local first - Create local repo → connect to GitHub
3. Add & push code - Create Python file, commit, and push
4. Demonstrate git pull - Edit on GitHub, then pull changes locally

DEMO STEPS:

Method 1 (GitHub first): - Create new repo on GitHub: “demo-github-first” - Clone: git clone https://github.com/bgreenwell/demo-github-first.git

Method 2 (Local first): - Create folder: mkdir demo-local-first && cd demo-local-first - Initialize: git init - Create GitHub repo, add remote: git remote add origin https://github.com/bgreenwell/demo-local-first.git - Push: git push -u origin main

Add code to GitHub-first repo only: - Add hello.py: print("Hello from GitHub first!") - Show workflow: git status → git add hello.py → git diff --staged → git commit -m "Add hello script" → git push

Demonstrate git pull: - Edit hello.py directly on GitHub (add a comment or change message) - Back in terminal: git pull to fetch the changes - Show how local file now matches GitHub version

Key points to emphasize: - Both creation methods achieve same result - GitHub-first is easier for beginners - git pull keeps you synced with remote changes - This is the complete collaboration cycle

More useful Git commands

• git log - See the history of your commits
• git log --oneline - Compact view of commit history
• git diff - See exactly what changed in your files
• git pull - Download the latest changes from GitHub
• git init - Turn any folder into a Git repository

Understanding Git’s three stages

graph LR
    A[Working Directory<br/>Your files] --> B[Staging Area<br/>git add]
    B --> C[Repository<br/>git commit]
    C --> D[Remote GitHub<br/>git push]

    style A fill:#ffcccb
    style B fill:#ffffcc
    style C fill:#ccffcc
    style D fill:#ccccff

• Working Directory: where you edit files
• Staging Area: where you prepare what to commit
• Repository: your local Git history
• Remote: your project on GitHub

Common Git scenarios and fixes

• “I made a typo in my commit message”
  • git commit --amend -m "New message"
• “I want to see what I changed”
  • git diff (before staging) or git diff --staged (after staging)
• “I staged the wrong file”
  • git reset HEAD <file> to unstage
• “Authentication failed”
  • Make sure you’re using your PAT, not your GitHub password

Want to learn more?

Useful resources for learning Git and GitHub:

• Pro Git Book - A free reference; chapters 1–3 cover the course foundations
• GitHub Skills - Interactive tutorials directly on GitHub
• Learn Git Branching - Visual, interactive Git concepts
• GitHub Desktop - GUI alternative for those who prefer visual tools
• Atlassian Git Tutorials - Additional topic-based tutorials

Quick reference cheat sheet

Commands you’ll use constantly:

# Getting started
git clone <url>         # Download a repository
git status              # See what's changed
git log --oneline       # View commit history

# Making changes
git add <file>          # Stage a specific file you have reviewed
git commit -m "message" # Save your changes
git push                # Send to GitHub

# Fixing mistakes
git diff                # See what changed
git reset HEAD <file>   # Unstage a file
git commit --amend      # Fix last commit message

Time for Lab 01

• Your first hands-on lab: Git and GitHub fundamentals.
• Objective: fork the semester labs repository, clone your fork, complete the setup record, and push it to GitHub.
• Submit that one fork URL to Canvas; you will keep using it through Lab 14.
• Please navigate to week01/lab01.md in the course repository for step-by-step instructions.