DEV Community: Faris Daffa

Last Slide: the homework card for the lecture deck you never opened

Faris Daffa — Thu, 22 Oct 2026 15:57:43 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Opening a 40-page lecture slide deck the night before class is pure dread. You skipped the lecture, you did not do the reading, and you know opening that PDF will take forty minutes of skimming through title cards, bullet points, and derivations you do not need right now.

Last Slide is a skip card for that unread deck. It is not a summarizer. It does not produce study packs, flashcard sets, or WhatsApp digests. When you skip class, you do not want an AI tutor explaining the entire curriculum. You just want the leftover slide still projected on the whiteboard after everyone left the room.

Last Slide extracts the native text from your PDF directly in your browser tab, passes a budgeted slice to Gemma 3 4B running on your local machine via Ollama, and fills exactly four fields:

What you missed: exactly two sentences explaining what the lecture covered.
Due: the one homework assignment or due date if it is actually written on a slide, complete with the slide number. If nothing is due, it explicitly says so.
They will ask: one exam-style question grounded in the slides, so you are ready if called on.
You can skip: one sentence pointing out the appendix, optional reading, or repeated examples you can safely ignore.

No files leave your computer. Scanned PDFs without text layers are refused immediately.

Demo

Live UI: https://last-slide.onrender.com/
Source Code: https://github.com/Faris0520/last-slide

Running locally

Install Ollama and pull Gemma 3 4B:

ollama pull gemma3:4b
ollama serve

Clone and start the client:

pnpm install
pnpm sample
pnpm dev

Open the local Vite URL in your browser. You can click Load sample to run the bundled 12-page sample deck (CS 101 Hash Tables), or drag and drop your own lecture PDF.

If you access a deployed frontend over HTTPS, the browser blocks requests to localhost:11434 by default. Start Ollama with the origin flag to allow cross-origin requests:

OLLAMA_ORIGINS="https://last-slide.onrender.com" ollama serve

On Windows PowerShell:

$env:OLLAMA_ORIGINS="https://last-slide.onrender.com"; ollama serve

Code

The project is open source under the MIT license:

Faris0520 / last-slide

Last Slide

A skip card for the lecture PDF you never opened.

Drop a native-text slide deck. Last Slide reads it in this browser tab (pdf.js), keeps only a budget of pages (deadline language always included), and asks Gemma 3 4B via local Ollama for four fields: two sentences of what you missed, the one due date if it is actually on a slide, one exam question, and what you can skip. Scans are refused. Nothing is uploaded.

Setup

Install Ollama and pull the model:

ollama pull gemma3:4b
ollama serve

Install and run the app:

pnpm install
pnpm sample
pnpm dev

Open the URL Vite prints. Load the bundled sample (CS 101 Hash Tables) or drop your own PDF. Confirm before anything is sent to http://localhost:11434.

If you open a deployed https page (Render), the browser will block localhost unless Ollama allows that origin:

OLLAMA_ORIGINS=https://YOUR-APP.onrender.com

…

View on GitHub

The core logic is divided into three focused TypeScript modules:

src/lib/pdf.ts: Extracts text per page in the browser tab using pdfjs-dist. Refuses scans if total text is under 50 characters.
src/lib/ingest.ts: Manages a strict 4,500-character budget. Runs a regex pre-pass for deadline keywords (tugas, homework, due, deadline, submit) so homework slides are never cut off by early filler slides.
src/lib/card.ts: Defines the strict JSON schema and system prompt that confines Gemma 3 4B to four fields.
src/lib/ollama.ts: Probes local Ollama health and posts to /api/chat with schema constraints.

Here is the keyword-first budgeting from src/lib/ingest.ts:

export const CHAR_BUDGET = 4_500
export const DEADLINE_RE =
  /\b(tugas|pengumpulan|homework|assignment|due\s+date|\bdue\b|deadline|uts|uas|submit)\b/i

export function planIngest(pages: PdfPage[]): IngestPlan {
  const keyword = pages.filter((p) => DEADLINE_RE.test(p.text))
  const keywordNs = new Set(keyword.map((p) => p.n))

  const sent: PdfPage[] = []
  let chars = 0

  function take(page: PdfPage) {
    if (chars >= CHAR_BUDGET) return
    const room = CHAR_BUDGET - chars
    const text = page.text.length > room ? page.text.slice(0, room) : page.text
    sent.push({ n: page.n, text })
    chars += text.length
  }

  // Prioritize pages containing deadline language
  for (const page of keyword) take(page)
  // Fill remaining budget with sequential slides
  for (const page of pages) {
    if (keywordNs.has(page.n)) continue
    take(page)
  }

  sent.sort((a, b) => a.n - b.n)
  const sentNs = new Set(sent.map((p) => p.n))
  const skipped = pages.filter((p) => !sentNs.has(p.n)).map((p) => p.n)

  return { sent, skipped, keywordPages: keyword.map((p) => p.n), chars }
}

And the Ollama call in src/lib/ollama.ts sending the raw JSON schema directly into format:

export async function completeViaOllama(
  url: string,
  model: string,
  messages: ChatTurn[],
  schema: Record<string, unknown>,
): Promise<string> {
  const res = await fetch(`${base(url)}/api/chat`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      model,
      messages,
      format: schema,
      stream: false,
      options: { temperature: 0.2, top_p: 0.9 },
    }),
  })
  if (!res.ok) {
    const detail = await res.text().catch(() => '')
    throw new Error(`Ollama answered ${res.status}${detail ? `: ${detail.slice(0, 200)}` : ''}`)
  }
  const data = (await res.json()) as { message?: { content?: string } }
  return data.message?.content ?? ''
}

How I Built It

The stack is intentionally lean: React 19, TypeScript, Vite, pdfjs-dist, and plain CSS. There is no custom backend server.

1. Extracting text locally with pdf.js

Instead of uploading files to a cloud document processor, the user drops their PDF directly into the browser tab. pdfjs-dist runs in a web worker, walks through each page, and collects the text stream.

If total extractable text across all pages is under 50 characters, Last Slide stops immediately and shows an error. There is no hidden OCR fallback. Lecture slides with real text parse in milliseconds; scanned photo decks are rejected honestly.

This approach was informed by community discussions on client-side PDF handling, particularly Shadman's writeup on Comparing open source PDF libraries (2025 edition), which details how pdf.js excels at client-side extraction without server overhead.

2. The 4,500-character budget

Language models slow down when fed entire 60-page PDF transcripts, especially on consumer laptops running on CPU. To keep inference practical, I capped the ingest at 4,500 characters.

The challenge with a simple character cutoff is that professors almost always put the homework assignment on the penultimate slide. If a student drops a 25-slide deck and you take the first 4,500 characters, slide 24 gets cut off, and the student misses their assignment.

The solution in planIngest is a keyword-first budget plan. It scans for words like homework, assignment, due, deadline, and tugas. Pages matching those words get top priority in the character budget. The remaining character allowance is then filled by the earlier slides in sequential order.

3. Taming Gemma 3 4B with constrained decoding

Small models like Gemma 3 4B are fast and capable of running locally, but when asked for open-ended summaries, they tend to ramble, parrot slide headers, or invent extra homework tasks.

In my earlier projects (Touch Soil and Unramble), I learned that small open-weight models become remarkably reliable when their decoding is strictly constrained.

Rather than asking the model to write paragraphs and parsing with regular expressions, Last Slide passes a strict JSON schema (CARD_SCHEMA) directly into Ollama's format parameter. Under the hood, this enforces grammar-constrained decoding: the runtime physically zeroes out token probabilities that violate the schema. The model cannot output markdown fences, conversational commentary, or unexpected JSON keys.

4. Intentional friction and honest CPU wait times

Before any text is sent to Ollama, Last Slide displays an explicit confirmation checkbox stating exactly how many characters will be sent, which slides are included, and which slides were held back. The user must check this box before generating.

When running on CPU without a dedicated GPU, generation takes between one and two minutes. Last Slide states this honestly on screen while the status indicator runs, rather than hiding the wait behind fake progress bars.

5. Projector slide aesthetic

The design does not look like a SaaS dashboard or a Notion document. It looks like a lecture slide left on an overhead projector after class:

Warm beige paper background (#F3EDE0)
Deep ink typography (#1A1612)
Newsreader for titles, IBM Plex Sans for body text
One red pen accent (#B42318) used strictly once: on the homework due date.

Why Does Open Innovation Matter?

This project could not exist in this form on a closed commercial API:

Course material privacy: Lecture slides, unpublished problem sets, and mid-term exam hints belong to students and universities. Asking students to upload their course PDFs to third-party cloud servers creates data leakage risks. With Ollama and Gemma, the entire workflow remains on the user's laptop.
Zero per-token costs: Commercial APIs charge per input token. When students ingest dozens of slide decks across a semester, API costs accumulate quickly. Running Gemma locally costs nothing beyond electricity.
Architecture decoupling: The model tag in Last Slide is a plain configuration string (gemma3:4b). If a user has a laptop with more VRAM, they can switch to an 8B or 12B variant without changing a single line of backend logic.
Resisting feature bloat: Cloud AI providers encourage complex multi-step pipelines because their business model relies on API volume. Open-weight models allowed me to build an ultra-focused, four-field skip card designed specifically for students who want to do less work, not more.

The lazy payoff

The Week 3 theme is Slow and Steady: tools that reward laziness.

Many AI study tools try to make students study harder by generating twenty flashcards, multi-chapter summaries, and interactive quizzes. Last Slide does the exact opposite: it accepts that you skipped the lecture, and it lets you stay lazy without failing.

Consider the bundled sample deck, CS 101 Hash Tables (12 slides):

Slides 1 to 10 explain dictionaries, collision handling, chaining, linear probing, and load factors.
Slide 11 is the homework: implement a chain-hash map, due Friday 24 October at 17:00.
Slide 12 is an appendix containing optional readings from Knuth and office hour schedules.

If you skip opening this deck, Last Slide produces:

What you missed: "Hash tables provide expected O(1) dictionary operations by hashing keys to bucket indices. Collisions are inevitable and are handled through chaining or open addressing."
Due: "Implement a chain-hash map in the language of the course. Due Friday 24 October, 17:00 (Slide 11)."
They will ask: "Explain how load factor determines when a hash table must rehash, and why tombstones are necessary when deleting in open addressing."
You can skip: "The optional Knuth reading in the appendix and the previous year's binary search tree quiz."

You skip reading 12 slides, you skip the optional appendix, you never miss the assignment, and you have an answer ready if the professor asks you about hash collisions. That is the lazy payoff.

Prize Categories

Gemma

Last Slide runs Gemma 3 4B locally via Ollama (gemma3:4b). It leverages Ollama's schema-constrained decoding (format: CARD_SCHEMA) to produce a reliable four-field JSON payload on consumer hardware without hallucinating deadlines or rambling.

Best Use of Render

The static frontend of Last Slide is hosted on Render (https://last-slide.onrender.com/). The architecture separates the user interface from inference: the UI is served globally via Render's static site network, while all document parsing and model inference stay entirely local on the visitor's machine via OLLAMA_ORIGINS.

Touch Soil: an offline garden planner with Gemma running in your browser

Faris Daffa — Wed, 07 Oct 2026 06:36:41 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Touch Soil is a garden planner that tells you what to plant this week, and it runs entirely in your browser. You pick your climate zone, optionally mention what you already grow, and an open-weight Gemma model writes a weekly plan: what to plant now, the one job worth doing, and the thing you should skip.

No account. No server. Nothing you type ever leaves your device, because there is no "elsewhere" to send it to. After the first model download, it works with the internet unplugged, which is exactly where a garden usually is.

I built it for this week's theme, Touch Grass: the whole point is that the screen part is short. You open the page, read a plan that takes one minute, and go put your hands in the soil.

Demo

Deployed app: https://touch-soil.onrender.com

Note for first load: the Gemma weights (about 1 GB) download once into your browser cache, then load locally from disk. You need a browser with WebGPU (recent Chrome or Edge).

Code

Repo: https://github.com/faris0520/touch-soil

Faris0520 / touch-soil

An offline garden planner with Gemma running in your browser

Touch Soil

An offline garden planner: you pick your climate zone, and an open-weight Gemma model running entirely in your browser (via WebLLM) writes a "what to plant this week" plan. No server, no account, and your garden data never leaves your device.

Why open

Runs with no internet after the first model download: WebGPU inference in the browser, so it works at the garden, on a trail, or anywhere the signal doesn't.
Data stays local: the zone you pick and what you're growing are never sent anywhere; there is no backend at all.
Everything is swappable: the climate data is a small JSON-style table anyone can fork and correct (frost-date datasets are US-centric, so this one includes tropical wet/dry seasons too), and the model is one string away from being any WebLLM-supported open-weight model.

How it works

Engine picker. Two ways to run the same open-weight…

View on GitHub

The interesting files:

src/data/climates.ts: the climate table. Nine zones, from USDA frost zones to tropical monsoon seasons.
src/lib/planner.ts: the prompt, the JSON schema, and the deterministic offline guide.
src/lib/llm.ts: model selection and the WebLLM engine setup.

How I Built It

The stack is deliberately boring: Vite, React, TypeScript, plain CSS. All the novelty is in how the AI piece works:

You choose where the model runs. A picker offers two engines for the same open-weight Gemma: downloaded into the browser (WebLLM), or an Ollama server on your own machine. The Ollama path only detects models you have already pulled; it never downloads anything by itself. This also gives browsers without WebGPU a real AI option.
Heavy actions ask first. Before the first browser download (about 1 GB) and before sending your garden details to the local Ollama server, a confirmation panel explains exactly what is about to happen.
The model runs in the browser. WebLLM runs open-weight models on your GPU through WebGPU. The app picks the smallest Gemma available in WebLLM's prebuilt list (Gemma 3 1B, quantized) and caches it after the first download.
The model cannot break the format. Small models love to ignore instructions, so instead of trusting prompts I constrain decoding: WebLLM gets a JSON schema via response_format, Ollama gets the same schema via its format parameter. The model can only emit { plants: [{ name, why }], task, skip }, and the UI renders that structure itself. My first free-form version produced headings like "Plant now (3)" and a greeting, the constrained version cannot.
The climate facts are plain data. Frost-date planners assume USDA zones, which is unhelpful if your garden has a wet season instead of a winter. Touch Soil bundles a small table: four temperate bands, tropical lowland and highland (monsoon wet/dry seasons), arid, and Mediterranean. It is intentionally small and honest about being approximate, and it is a JSON file you can fork and correct for your region.
There is a no-AI fallback. If neither engine can run, a rule-based guide written from the same dataset takes over. The app is never empty.

One war story from the build: Gemma 3's prebuilt WebLLM record ships both a context_window_size override and a sliding_window_size base config, and the engine refuses to start with both active. The fix (the engine tells you this, to its credit) is switching the record to sliding-window mode with attention_sink_size: 0.

Why Does Open Innovation Matter?

For this project, the open pieces are not a detail, they are the whole argument:

It works where the garden is. No signal, no problem: once cached, the in-browser model runs offline, and the Ollama engine only ever talks to your own machine. A closed API would make the app useless exactly when and where it should be most useful.
Your garden stays yours. What you grow, your zone, your questions: none of it reaches a cloud. The Ollama engine even shows a confirmation naming the exact server your details will go to, and the WebLLM engine shows one before its one-time download.
You can swap the brain. The model is one string in src/lib/llm.ts. Want a bigger Gemma, a different open-weight model WebLLM supports, or another local Ollama model? Change a filter or type a name. Want better climate data for your region? Edit a JSON table and open a pull request.
It costs nothing to run. No API bill per plan. The compute is the device you already own.

Prize Categories

Gemma (the planner runs on an open-weight Gemma model in the browser)
Render (the app is deployed on Render: https://touch-soil.onrender.com)

My friend rambles in interviews, so I built him Unramble

Faris Daffa — Sat, 03 Oct 2026 14:41:30 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My friend, Agus, has a problem I recognized because I have it too. He knows his stuff. Ask him about a project he shipped and, on paper, the answer is all there. But ask him out loud, in an interview, and the answer wanders: it starts three digressions deep, never lands the result, and buries the one sentence that mattered somewhere in the middle. He is not a weak candidate. He is an unpracticed one, and practice is exactly the thing he cannot do, because practicing means saying half-finished answers out loud to another human, at night, repeatedly, until it stops being embarrassing.

So I built him Unramble: a practice partner for real interviews that runs entirely on his laptop. He pastes a job description and a few CV bullets. Gemma 3, running locally through Ollama, writes seven interview questions tuned to that role. He answers out loud, into the microphone. Whisper, running locally inside the app's own server, transcribes him. And then the part he actually needed: the report.

Every sentence of his answer gets a color that says what job it was doing: blue set the Situation, purple named the Task, green carried the Action, yellow landed the Result. Gray is filler. He can literally watch an answer go green, green, gray, gray, gray, and never reach yellow. Below the transcript: relevance and conciseness scores, STAR coverage, a "tangled" meter computed from measured filler density and sentence length, and a rewritten version of his own answer with the detours removed, keeping only his real facts. Any question can be re-answered on its own and rescored, so the weak one gets drilled until it stops being weak.

One rule shaped the whole build: nothing he says ever leaves his laptop. The recordings live in browser tab memory and are never written anywhere. The transcript, the scores, the report: all in local storage. The models run on his machine. There is no server to upload to.

Demo

https://unramble.farisdaffa.in

Code

GitHub: Faris0520/unramble

Faris0520 / unramble

A practice partner for real job interviews that runs entirely on your laptop.

Unramble

A practice partner for real job interviews that runs entirely on your laptop.

Unramble was built for one real person: a friend preparing for interviews whose answers know all the facts but fall apart in the telling. You speak an answer out loud, and the app shows the structure behind it: which sentence set the scene, which one carried the action, where you drifted into filler. Then Gemma rewrites the answer, straight.

Everything is local. Questions and scores come from Gemma 3 4B through Ollama Transcription comes from Whisper through transformers.js, inside the app's own server Recordings live in browser tab memory and are never written anywhere. There is no server to upload to, so an interview rehearsal stays as private as it should be.

Quick start

One-time setup (details in SETUP.md):

winget install Ollama.Ollama
ollama pull gemma3:4b

Then:

npm install
npm run build
npm start

Open http://localhost:3000…

View on GitHub

How I Built It

Three open-source pieces, glued together as one local pipeline:

Question generation and scoring: Gemma 3 4B via Ollama. The app talks to Ollama's local REST API with structured output (a JSON schema Ollama enforces), which is how a 4B model stays reliable: generation returns exactly { questions: string[7] }, and scoring returns sentence tags plus integer scores, every time, on a laptop CPU. The model tag is one environment variable, so he can swap in a bigger Gemma when his hardware allows.
Transcription: Whisper via transformers.js. The browser records the take, decodes it with its own AudioContext, mixes to mono, resamples to 16 kHz, and hands the app's server a plain PCM WAV. The server runs the quantized Whisper model in-process; the weights download once into the project folder and work offline from then on. For Indonesian answers, an environment variable switches to the small model, which hears the language better.
The metrics that do not need a model at all. Filler counting, sentence splitting, and the tangled score are computed in plain TypeScript from his actual answer. A model judges structure; the app measures facts. The report never shows a number that was not measured.

Two details I am proud of. First, the transcript is editable before scoring: if Whisper misheard a word, he fixes it, and the score is computed on what he approved, not on what the machine guessed. Second, the on-screen checklist: the setup page pings Ollama, sees exactly which local piece is missing, and prints the one command that fixes it. A friend who would rather not debug a local stack by hand gets that command with a Copy button.

The interface follows Notion's design system, on purpose: a report about your weakest answer should read like a calm document, not a dashboard. Pastel tints carry the sentence structure, purple is reserved for the one action per screen, and the same layout works on a phone, because practice happens wherever the laptop opens.

Why Does Open Innovation Matter

An interview rehearsal is the most private thing a job seeker does. You say half-finished sentences. You forget words you know. You ramble, and you know you are rambling while it is happening. Nobody would want a recording of that on somebody else's server.

That is the argument for open, local AI in this specific product, and it is not a technical argument, it is a dignity argument. With a closed API:

his voice and his weakest answers would sit in someone else's cloud, on someone else's retention policy;
every practice rep would cost money, and the whole point of practice is unlimited reps;
it would need the internet, and the moment he most wants to practice is 2 AM before a morning interview, when he just needs the thing to work.

With the open stack, the privacy story is inspectable instead of promised. The Ollama process runs on his machine, on a port he can see. The model weights sit in a folder he owns. If he wanted, he could read every line that touches his voice. And because the core is open, the app can grow with him: swap the model when a better open one lands, fine-tune on his own practice answers someday, run it forever at zero cost on hardware he already owns.

Open innovation also meant I could build this in a weekend and hand it to one specific person, with no API budget, no accounts, and no server to maintain. The tool exists because one real friend needed it, and it can keep existing on his laptop whether or not I ever touch it again.

Handing it over

Handover happened on his actual laptop, in his room, with the setup page doing its job: he installed Ollama, pulled the model, and watched the checklist tick green one piece at a time. He is a computer science student, so halfway through the download he asked what exactly was running on his machine. That question is the reason this app is local, and this friend is the one person I could not answer with trust me. So I opened the folders instead: model weights in a directory he owns, transcript and scores in local storage, recordings that are never written anywhere. He can read every line that touches his voice. Most people have to take that on faith. He can just check.

Then I handed him the microphone and sat where he could not see me, because a first take needs an audience of nobody. He pasted a junior developer posting he had actually applied to, answered the first question out loud, and produced the answer he always produces: every fact present, one long green Action doing most of the talking, the yellow Result arriving late and out of breath. The tangled meter flagged it without mercy. The moment that mattered came when the rewrite rendered, though. The app had kept only his real facts and cut the detours, and he read his own answer, straight, and said the thing this whole project was built for: oh. That is what I meant.

He drilled the weakest question again that night, on his own, with me out of the room. I know because a screenshot of the second report arrived later with no caption: same question, less gray, the yellow landing where it belongs. That screenshot is the best evidence this project has produced, because it shows the tool in its natural habitat: 2 AM, one nervous person, one laptop, no budget, no account, no me. He is a computer science student. If he ever wants to make it better, he can read the code and change it. That was always the real handover: not a service I keep alive for him, but a folder of open pieces he fully owns.

Prize Categories

Gemma

Thanks to the open-source projects it stands on: Gemma, Ollama, Whisper, and transformers.js.

Hi there! Welcome to my Dev.to profile

Faris Daffa — Wed, 25 Sep 2024 23:23:41 +0000

Hello, welcome to my Dev.to profile /.\

I'm Faris Daffa, 18yo, i live in Jambi City, Indonesia.

I am currently an undergraduate student at Computer Science or Informatics, Faculty of Science and Technology, Jambi University.

Nice to meet ya!

26/09/2024