MP3 + FP-idea showcase · Class Favorite vote · Proposal peer review

Everyone showed their MP3 live, named the API behind it, and pitched a final project idea in one sentence. Fifteen different APIs turned up across the class, and the most useful thing that happened was watching how people chose them, and what they did when one broke. The habit to keep: share the idea before you build it. The peer review exists because a weakness in your own plan is invisible to you and obvious to someone hearing it for the first time. Your final project is due Friday, 7/24, and you present it Wednesday, 7/22.

• Two lightning talks: the growth of AI-generated video, and AI in real estate.
• The combined MP3 + final project idea showcase: every presenter opened their live site, named the API, showed where the live data appears, and then pitched the final project idea.
• The Class Favorite vote on MP3.
• A proposal peer review in breakout groups: pitch in one sentence, then hear one feature to cut and one thing that is missing.

We did not get to image processing in the browser or the coding-agent demo. Both are covered below.

Picking an API is part of the work, and the pick can fail. Two people had an API die under them mid-project. One built a whole site on a country-data API, deployed it, and the page broke, because the API had been deprecated and now demanded a key. Another lost a date-range feature after burning through the free credits on a first choice. Both switched and shipped. This is normal. APIs are somebody else's service and they change without asking you. Two habits that follow: test the API by itself before you build around it, and make your page show a clear message when the call fails, so a dead API still tells your visitor what happened. A blank screen tells them nothing.

Free is a real requirement this week. With one week left, an API that needs a paid plan, a waiting list, or a complicated key setup is a risk you do not need. Some are free with no key at all, which is the easiest possible start. Some are free after a quick registration. Check which kind you have before you commit.

Not every API hands you data back. Almost everything we practised follows the same shape: you fetch something, you get data, you put it on the page. One project today used a payment API, and that one is a different animal. Its job is to move money and record that it happened. Nothing useful comes back for you to display. When you meet an API, ask what it is for: is it giving me data to show, or is it doing something on my behalf?

A chatbot without a boundary is not a product. We opened with a real story: someone built a good-looking site where you talk to historical figures, posted it, and a commenter immediately asked the fake Gandhi a Python question. It answered, happily and perfectly. The site had no guardrail, so it was a general chatbot wearing a costume. If you build anything conversational, decide what it must refuse. "Stay in character. Never answer what you do not know."

"Why is this project yours?" There are thousands of recipe apps and weather dashboards. That is fine for learning, and nobody expects a final project to be original. But the question worth asking is what makes yours different from the average version of the same idea. The best answers today came from people building for a specific real person: a family business, a high school coach, a parent in another country, an actual paying client. A specific user is the cheapest source of originality there is.

Make AI interview you. Hand it one sentence and it will build whatever it guesses you meant. Tell it to ask you questions first, and to dig out why you really want this thing. The same move works on your own idea before you write any code.

Ask AI for its confidence and its sources. A trick worth stealing: add a standing instruction to your AI tool along the lines of "if this is a subjective judgment, tell me your confidence level" and "give me the reference whenever you can, do not just make judgments for me, I want the evidence." It will not stop the tool from being wrong. It does make the wrong parts easier to spot, because confident prose is very good at hiding them.

As promised in class, here is every API that came up, so you can borrow one. None of these require payment.

If you are still hunting, the public APIs list on Canvas remains the best starting point.

• Image processing in the browser. We did not reach it, and it is genuinely fun: read the pixels off a photo and write your own filter. Instagram filters, from scratch, in about thirty lines. Try it on your own if you want a break from the final project.
• Coding agents and your repo. Also not reached. I will demo this on Monday.
• MDN Web APIs if you want to see what else the browser gives you for free.

1. Build your final project. Aim for one working slice, deployed and live, by Monday. Bring it to class and I will help with it directly. A deployed draft is worth far more of my time than a description of a plan.

2. Act on your peer feedback. You heard one feature to cut and one thing that is missing. Open your PROPOSAL.md, make at least one change based on what you heard, and commit it.

3. Write logs/wk09.md. Along with your usual four sections, add three lines from the breakout:

   • the feature your group told you to cut or shrink
   • the thing they said was missing (a feature, a user, a data source)
   • the one change you made to your PROPOSAL.md because of it

   Those three lines are the only record that the peer review happened, so please do not skip them.

4. Bring your logs on Monday. We are going to take all of your existing weekly logs and build something out of them.

5. Lightning talks. Monday, 7/20 has one slot left and Wednesday is Demo Day. If you still owe a talk, sign up now.

Next class is Monday, 7/20. It is a short one: the last few lightning talks, a wrap-up of all three mini projects, and the coding-agent demo. It is also your last work session before Demo Day.

Final project Demo Day is Wednesday, 7/22. You present your final project live. Final submission is Friday, 7/24.