Как собрать портфолио за первый семестр: разбор четырёх проектов и стека

Четыре проекта в открытом доступе — вот что остаётся от первого семестра Computer Science, если писать код не в конспект, а в репозиторий. Их автор до учёбы пять лет проработал в администрировании и логистике, а стек собрал сам, без курсов: чистый HTML и CSS, ванильный JavaScript, Python, Node.js и деплой на Vercel.

Зачем это разбирать, если вы не он? Потому что набор проектов здесь выстроен по нарастающей сложности, и эту логику легко скопировать под себя. Ниже — что именно даёт каждый проект и в какой последовательности их собирать.

Четыре проекта: чем каждый полезен

Sloward Barber — сайт барбершопа целиком

Онлайн-запись, автоматическое письмо-подтверждение, админ-панель, бэкенд, фронтенд и база данных. Сделано на чистом HTML, CSS с кастомными свойствами и ванильном JavaScript — без фреймворков и без шага сборки.

Сама запись на стрижку тут не главное. Собирая интерфейс без готовых библиотек, автор прошёл путь от палитры и типографики до набора переиспользуемых компонентов, то есть сделал дизайн-систему руками. Параллельно — поток авторизации, пусть и сымитированный через localStorage: настоящей сессии там нет, но состояния, переходы и защита маршрутов уже отработаны.

И отдельный слой, который обычно откладывают на потом: мета-теги, Open Graph, Schema.org, sitemap.xml, robots.txt. Плюс доступность — :focus-visible, prefers-reduced-motion. Мелочи, но именно они превращают учебную страницу в то, что не стыдно открыть чужому человеку.

PromptQuest — игра про промпт-инжиниринг

Больше двадцати заданий с растущей сложностью, подключённых к API Claude от Anthropic. Написано на Python.

Первый настоящий опыт работы с языковой моделью как с внешним сервисом: как формулировать запрос, как проверять, что ответ осмысленный, как выстроить прогрессию, которая учит на практике, а не пересказывает теорию. Автор называет это своим первым контактом с API ИИ в продакшене — и это честная формулировка.

Villa Bertoni — сетка турнира по бильярду

Система для реального чемпионата: регистрация пар, автоматическая генерация встреч, свой визуальный стиль. Фронтенд на JavaScript, бэкенд — собственная API на Node.js, данные сохраняются.

Здесь впервые пришлось думать правилами, а не вёрсткой. Сетка закрывается только тогда, когда число участников укладывается ровно, чтобы в финале гарантированно оказались двое. И первый случай, когда API проектируется с нуля, а не просто подключается чужая.

Tower Defense Espacial — коротко

Двумерный Tower Defense на Python с космической темой. Игровой цикл, коллизии, управление состоянием. Сам автор называет это базой, которая понадобилась до перехода к вебу, — и возразить нечего: по времени это самый дешёвый способ набить руку на логике.

Что получилось на выходе

Стек: ничего лишнего

• Языки: JavaScript, TypeScript, Python, HTML5, CSS3.
• Среда исполнения: Node.js.
• Инструменты: Git, GitHub, Figma.
• Работа с ИИ: промпт-инжиниринг, API Claude от Anthropic.
• Деплой: Vercel.

Фреймворков в списке нет, кроме Node.js на бэкенде. На фоне вакансий, где просят React и Docker, набор выглядит скромно. Зато он честно показывает, что человек понимает, как всё устроено внутри, — а это учится дольше, чем синтаксис любого фреймворка.

В каком порядке это повторять

1. Игра на Python. Цикл, коллизии, состояния. Самые дешёвые в отладке задачи: ошибку видно сразу на экране, а не в логах сервера.
2. Сервис с бизнес-логикой и своей API. Образец вроде сетки турнира хорош тем, что правила проверяемы: она либо сходится, либо нет. Тут же появляется опыт проектирования эндпоинтов, а не только их вызова.
3. Сайт целиком — от дизайн-системы до sitemap.xml. Ключевое отличие от предыдущих этапов: работу нужно довести до продакшена, а не до состояния «локально работает».
4. Проект с внешней моделью. Промпты, проверка ответов, постепенное усложнение заданий. Логично делать последним, когда уже есть опыт с чужими API.

Почему именно такой порядок? Каждый следующий шаг опирается на предыдущий. Без понимания состояний сложно писать авторизацию, без своей API — подключать чужую, без умения довести проект до деплоя бессмысленно браться за интеграцию с моделью.

Типичные ошибки

• Держать проекты на своей машине. В исходнике всё выложено на Vercel — и это часть работы, а не приятный бонус к ней.
• Оставлять репозиторий без README. Скриншот, стек и инструкция запуска — минимальный набор, дальше уже необязательно.
• Ждать, пока «дорасту» до фреймворка, и не публиковать ничего. Ванильные проекты в портфолио лучше пустой страницы на GitHub.
• Пройти туториал и не поменять в нём ни строчки. Ценность появляется там, где приходится решать свои правила — как с сеткой на восемь или одиннадцать участников.
• Забыть про sitemap.xml, мета-теги и :focus-visible. Кажется ерундой, пока не сравнишь два своих проекта рядом.

Когда этот путь не сработает

Если цель — вакансия, где первым делом смотрят на React, Vue, тесты и CI, четыре ванильных проекта туда не занесут. Они закрывают другое: понимание основ и привычку доводить вещь до публикации. Фреймворк после такого учится заметно быстрее, чем наоборот.

Что здесь по-настоящему переносимо на чужой контекст — привычка превращать упражнение в работающую штуку. Автор формулирует это просто: он предпочитает учиться на проектах, которые работают от начала до конца, вместо того чтобы копить отдельные задачи. Четыре проекта за один семестр — вполне достаточная иллюстрация того, что подход рабочий.