Зачем писать блог-пост
Блог-пост -- шаг 15 из 16 в Cloud Resume Challenge. Но это не формальность. Блог-пост выполняет три функции:
- Закрепление знаний -- объясняя другим, вы лучше понимаете сами (эффект Фейнмана)
- Портфолио -- рекрутеры и нанимающие менеджеры читают блоги кандидатов
- Нетворкинг -- статья привлекает внимание в профессиональном сообществе
Статистика
- 73% нанимающих менеджеров проверяют онлайн-присутствие кандидата
- Кандидаты с техническими блогами получают на 40% больше откликов
- Статья в топе Dev.to может получить 5,000-20,000 просмотров
Структура блог-поста CRC
Шаблон
1. Заголовок (Hook)
2. Введение: зачем я это сделал
3. Архитектура: что я построил (диаграмма!)
4. Путешествие: 3-4 ключевых вызова и их решения
5. Моды: что я добавил сверх базового CRC
6. Уроки: что я узнал
7. Что дальше
8. Call to Action
1. Заголовок
Заголовок должен быть конкретным и привлекающим внимание:
| Плохо | Хорошо |
|---|---|
| "Мой опыт с CRC" | "Как я построил serverless-резюме на AWS и получил первый оффер" |
| "Cloud Resume Challenge" | "CORS, cold starts и 3 AM debugging: мой путь через Cloud Resume Challenge" |
| "AWS проект" | "От нуля до production: 16 шагов Cloud Resume Challenge на AWS" |
2. Введение
Расскажите вашу историю, а не историю CRC:
Три месяца назад я уволился с работы бухгалтером. У меня была
одна сертификация (AWS Cloud Practitioner), ноль опыта в IT
и горящее желание стать облачным инженером.
Знакомый посоветовал Cloud Resume Challenge. "Лучший способ
доказать, что ты умеешь строить, -- это построить что-то."
Вот что из этого вышло.
3. Архитектура
Обязательно включите архитектурную диаграмму:
[Браузер] → [CloudFront] → [S3]
↓
[API Gateway] → [Lambda] → [DynamoDB]
↑
[GitHub Actions] ← [GitHub Repo]
↓
[SAM/CloudFormation]
4. Путешествие: проблемы и решения
Это самая важная часть. Расскажите о 3-4 реальных проблемах, с которыми вы столкнулись:
## Проблема 1: CORS
Я потратил 4 часа на CORS. Фронтенд отправлял fetch-запрос
к API, но браузер блокировал ответ. Я видел "CORS policy" ошибку
в консоли, но не понимал, что делать.
**Что помогло:** Я нарисовал на бумаге, что происходит:
1. Браузер отправляет OPTIONS запрос (preflight)
2. API Gateway должен ответить с Access-Control-Allow-Origin
3. Только после этого браузер отправляет GET запрос
Решение: настроить CORS на HTTP API Gateway. Одна строка
конфигурации -- 4 часа отладки.
**Урок:** Читайте логи. Ответ был в CloudWatch всё это время.
5. Моды
Если вы реализовали модификации -- расскажите о них. Это выделяет вас:
## Security Mod: Spoof Troop
Я добавил security headers через CloudFront Response Headers Policy.
Content-Security-Policy, HSTS, X-Frame-Options -- теперь мой сайт
получает A+ на securityheaders.com.
Это заняло 2 часа, но дало мне тему для разговора на собеседовании:
"Расскажите о безопасности вашего проекта."
6. Уроки
Конкретные, честные уроки:
## Что я узнал
1. **Документация > видеокурсы.** AWS docs спасали меня чаще, чем YouTube
2. **Ошибки -- лучший учитель.** 403 Forbidden научил меня IAM лучше, чем любой курс
3. **IaC экономит время.** Первый деплой занял 2 часа руками. С SAM -- 30 секунд
4. **Cloud дорогой, если не следить.** Забытый NAT Gateway = $32/месяц
Стиль написания
Принципы
- Первое лицо -- "Я сделал", не "было сделано"
- Конкретика -- "4 часа на CORS", не "некоторое время на отладку"
- Честность -- покажите ошибки, а не только успехи
- Код -- включайте snippets, но не весь код
- Визуальность -- диаграммы, скриншоты, таблицы
Длина
Оптимальная длина: 1,500-2,500 слов. Достаточно для глубины, но не утомительно для чтения. Читатели тратят в среднем 7-10 минут на техническую статью.
Чего избегать
- Не пересказывайте документацию -- читатели могут прочитать её сами
- Не копируйте весь код -- покажите ключевые фрагменты
- Не будьте скучными -- добавьте юмор, эмоции, личные детали
- Не врите -- если что-то скопировали, скажите об этом