cheatsheets.zip — коллекция шпаргалок для разработчиков в одном месте

Сайт с быстрыми справочниками по языкам, фреймворкам, инструментам. Без воды — только синтаксис, команды, горячие клавиши. Когда нужно вспомнить regex, git-команду или синтаксис Python, а лезть в документацию лень.
​
Что есть
🔘Языки: Python, JavaScript, Go, Rust, C/C++, Java, PHP, Kotlin, Swift, Dart
🔘Инструменты: Docker, Kubernetes, Git, Vim, Bash, RegEx, LaTeX
🔘Фреймворки: Laravel, Express, jQuery, GraphQL
🔘Форматы: JSON, YAML, TOML, Markdown
🔘Горячие клавиши: VS Code, IntelliJ, Figma, Photoshop, Obsidian, Slack, Chrome DevTools
​
➡️ Для кого: когда переключаешься между языками и забываешь синтаксис. Когда нужен быстрый reminder, а не 50 страниц документации.

📎 Сам сайт со шпаргалами, код на GitHub

@prog_stuff

Представьте: продакшен падает ночью. Причина — null где-то в глубине сервиса. Никто не знал, что он там может быть. Компилятор молчал.

А теперь другая история: разработчик 20 минут борется с ошибками компиляции. Исправляет. Деплоит. Всё работает. Никто не просыпается ночью.

Сегодня рассказываю про одну интересную статью. Автор утверждает: компилятор бесполезен не потому что он слабый, а потому что мы постоянно его обманываем:

1️⃣Null — говорим "это String", но на самом деле может быть null

2️⃣Unchecked exceptions — говорим "возвращает String", но может выкинуть исключение

3️⃣Касты — говорим компилятору "trust me bro, это точно Dog", а через месяц там оказывается Cat

4️⃣Side-effects — функция возвращает void, но делает что-то критичное. Компилятор не знает что
​
➡️ Что происходит когда перестаёшь лгать

Вместо null — Option<String>. Теперь компилятор видит разницу и заставляет обработать отсутствие значения.

Вместо кастов — union types. Добавили новый case? Компилятор покажет ВСЕ места, где нужно обработать новую логику.

Вместо "это просто int" — UserId, AppId, PostId. Теперь их невозможно перепутать.
​
➡️ Реальный кейс

Google Cloud outage в июне 2025 — причина null в неожиданном месте. Автор показывает, как диалог с компилятором мог бы предотвратить это: изменил тип поля на опциональное → получил сотни ошибок компиляции → понял, что дизайн неправильный → переделал на union type → компилятор показал все места, где нужна новая логика → добавил валидацию → скомпилировалось → задеплоил → спокойно спит.

📎 В общем, статья годная

@prog_stuff

«Ага! Теперь мне всё ясно. Напишу код, который точно решит твою проблему! 🚀»

Обзор статьи от Herb Sutter: почему C++ растёт быстрее всех, несмотря на Rust, безопасность и AI

Главный архитектор C++ в Microsoft подводит итоги 2025 года. Тезис: «Software taketh away faster than hardware giveth» — наши задачи растут быстрее, чем мощность железа. Так было 80 лет, так будет и дальше.
​
➡️ Главные ограничения 2025 года

🔘Электричество — не чипы. Все сделки OpenAI теперь в гигаваттах. Microsoft CFO: «Нам не хватает не GPU, а места и электричества для них»

🔘Чипы — NVIDIA самая дорогая компания мира, TSMC — главная точка отказа планеты
​
➡️ Рост языков 2022-2025

Самые быстрорастущие: Rust и C++. При этом C++ за год добавил столько разработчиков, сколько всего Rust-программистов в мире.
​
➡️ А как же «C++ небезопасен»?

🔘Только 3 из топ-10 уязвимостей MITRE связаны с языком

🔘79% кибератак вообще без malware — атакуют другое

🔘Проблемный язык — C, не C++. Единственное исследование, разделившее их (Mend.io), показывает: C++ по безопасности ближе к другим языкам, чем к C
​
➡️ Про ИИ

🔘«Если ваша работа — следовать сложным инструкциям и нажимать кнопки, ИИ за ней придёт. Но это не большинство программистов»

🔘AWS CEO: «Заменить джунов на ИИ — одна из самых тупых идей, что я слышал»
​
📎 Полная статья

@prog_stuff

Себастьян Рашка подвёл итоги года в LLM-мире. Рашка — автор книги «Build A Large Language Model (From Scratch)» и независимый исследователь, который пишет код руками и разбирается в деталях. Его обзоры ценны тем, что это взгляд практика, а не маркетинговый пересказ пресс-релизов.

➡️ Главное открытие года — RLVR и GRPO

DeepSeek R1 в январе показал, что reasoning-поведение можно развить через reinforcement learning с проверяемыми наградами. Модель стоила ~$5M вместо ожидаемых $50–500M. После этого буквально все крупные лабы выпустили свои "думающие" модели.

GRPO стал любимым алгоритмом исследователей — он концептуально интересный и не требует безумных бюджетов для экспериментов.

➡️ Тренды года

🔘Inference-time scaling — тратим больше на генерацию ответа, получаем лучше результат. DeepSeekMath-V2 так дошёл до золотого уровня на математических олимпиадах

🔘Tool use — LLM учатся использовать поиск и калькуляторы вместо галлюцинаций

🔘Benchmaxxing — модели оптимизируют под бенчмарки, а не под реальные задачи. Llama 4 — яркий пример: цифры отличные, а пользователи разочарованы

➡️ Про использование LLM в работе

Рашка пишет: если модель делает всю работу, а человек только смотрит — это путь к выгоранию. Удовольствие от решения сложной задачи пропадает, когда LLM выдаёт ответ за секунду.

Его подход: критичный код пишет сам (чтобы понимать и расти), а рутину типа argparse-бойлерплейта отдаёт модели.

➡️ Прогнозы на 2026

🔘Diffusion-модели для текста выйдут в продакшн (Gemini Diffusion первый)
🔘RLVR расширится за пределы математики и кода — химия, биология
🔘RAG начнёт уступать длинному контексту
🔘Прогресс будет больше от inference-оптимизаций, чем от самих моделей

Статья на ~13k слов, но читается легко. Рашка не просто перечисляет события — он объясняет, почему это важно, и добавляет свой опыт. Особенно полезны секции про практическое использование LLM и честный разговор про burnout.

📎 https://magazine.sebastianraschka.com/p/state-of-llms-2025

@neuro_channel

Любопытная статья «Код стал дешёвым. Софт — нет»

Автор пишет, что Claude Code, Cursor и компания убили стоимость написания кода. Но не стоимость понимания проблемы.
​
Мы входим в эру «персонального софта» — люди генерируют себе трекеры расходов, Chrome-расширения, фитнес-приложения точно под свои нужды. Не ищут SaaS, который решает 80% задачи — делают свой за вечер. Используют и выбрасывают.
​
Но есть нюанс. Трекер ломается, когда банк меняет формат CSV. Расширение умирает, когда сайт обновляет вёрстку. Фитнес-приложение разваливается, когда нужен офлайн-режим. Код написать легко — сделать так, чтобы оно работало в реальном мире, всё ещё дорого.
​
Автор разбирает, почему мы не вступаем в золотую эру SaaS, почему истории про $10k MRR за выходные — чаще маркетинг, чем реальность, и что теперь реально отличает инженера от генератора кода.

📎 https://www.chrisgregori.dev/opinion/code-is-cheap-now-software-isnt

@prog_stuff

Разработчик сделал свой процессор и запустил на нём GIF-плеер. Звучит безумно, но на самом деле это реально — и вот как это работает.

➡️ Что такое FPGA

Обычный процессор (Intel, AMD) — готовая схема, залитая в кремний на заводе. Изменить её нельзя.

FPGA — микросхема из миллионов логических блоков, соединённых сеткой проводников. На каждом пересечении — транзисторный ключ. Когда загружаешь конфигурацию, каждый ключ получает команду «включись» или «выключись» — и это определяет, как блоки соединены между собой.

Ничего не двигается физически — это электрическая перекоммутация. Но в результате микросхема начинает работать как процессор, который описал автор. Не эмуляция, а реальные такты, реальные провода, реальная скорость.

➡️ Что сделал автор

1️⃣Описал простой RISC-V процессор на SystemVerilog

2️⃣Загрузил на FPGA-плату — получился работающий CPU @ 25 MHz

3️⃣Написал на C GIF-декодер (стандартная библиотека не влезла в 32 KB RAM, пришлось писать базовые функции самому)

4️⃣Запустил — гифка 195×146 px крутится на ~4 FPS

➡️ И зачем это

Красивый пример того, как устроены компьютеры под капотом. От описания логики до картинки на экране — всё в двух репозиториях: сам процессор, плеер для гифок.

@prog_stuff

Статья о том, почему разработчики устают не от кода, а от всего вокруг него

➡️ Главная мысль

Продуктивность — это не «делать больше», а «решать сложные задачи эффективно». Большинство инженеров тратят ментальную энергию ещё до того, как написали первую строчку кода.
​
➡️ 7 грехов

1️⃣Context switching — 23 минуты на возврат в фокус после одного уведомления

2️⃣Multitasking — оптимизируем время ответа вместо времени решения

3️⃣Urgency illusion — обсуждаем имена переменных часами, игнорируем архитектурный долг

4️⃣Parkinson's law — работа растягивается на всё отведённое время

5️⃣Zeigarnik effect — незакрытые задачи съедают «ментальную RAM» фоном

6️⃣Decision fatigue — к обеду мозг уже не способен на сложные решения

7️⃣Brooks's law — больше людей в проекте = медленнее, а не быстрее

Автор предлагает системный подход: батчить коммуникации, агрессивно таймбоксить задачи, автоматизировать мелкие решения (линтеры, шаблоны), делать сложное утром, писать next step перед уходом с работы.

Подробнее в самой статье, тут только кратко суть описал, чтобы вы поняли интересно вам почитать или нет.

📎 https://strategizeyourcareer.com/p/the-7-deadly-sins-of-software-engineers-productivity

@prog_stuff

Статья на GitHub с 12k+ звёздами о том, почему код становится сложным — и дело не в алгоритмах

Автор вводит понятие «когнитивная нагрузка» — сколько всего разработчику нужно держать в голове, чтобы понять код. И показывает, как мы сами её раздуваем: глубоким наследованием, слоями абстракций, микросервисами ради микросервисов.

Любимый пример: стартап с 5 разработчиками сделал 17 микросервисов и отстал на 10 месяцев. Каждое изменение требовало правок в 4+ местах.

Цитата, которая запомнилась: «A little copying is better than a little dependency» — Rob Pike.

Статья не очень доинная, с примерами кода и конкретными антипаттернами.

📎 https://github.com/zakirullin/cognitive-load

@prog_stuff

OpenAI рассказала, как обслуживает 800 миллионов пользователей ChatGPT на обычном PostgreSQL — больше миллиона запросов в секунду, без кастомных модификаций.

Архитектура: 1 primary инстанс + ~50 read реплик на Azure-инфраструктуре. Latency на p99 — двузначные миллисекунды. Правда, есть нюанс — write-heavy workloads OpenAI вывела в Azure CosmosDB, а в PostgreSQL оставила read-heavy операции.

Что интересно — они не стали городить сложную систему. Вместо этого взяли стандартный PostgreSQL и выжали из него максимум через базовые практики: connection pooling (PgBouncer) для переиспользования соединений вместо создания новых, query optimization для профилирования и переписывания тяжёлых запросов, strategic indexing — индексы ровно там, где нужны.

Для AI-функций используют расширение pgvector — хранят и ищут высокоразмерные векторы (embeddings) для семантического поиска в данных ChatGPT.

База обслуживает данные пользователей, истории разговоров и API-взаимодействия.

➡️ Главный вывод: PostgreSQL действительно масштабируется до экстремальных нагрузок, если правильно настроить. Не нужно сразу бежать за NewSQL или распределёнными системами — сначала стоит выжать всё из проверенных решений.

Инженеры OpenAI подчёркивают: успех в том, что они фокусировались на best practices, а не на переизобретении колеса. Connection pool, индексы, read реплики — это всё есть в документации PostgreSQL. Просто нужно применить грамотно.

Годный пример того, что правильное разделение нагрузки важнее выбора модной БД. PostgreSQL для чтения + CosmosDB для записи — и никакого шардинга одной базы. Простая архитектура побеждает.

📎 OpenAI Blog, Hacker News

@prog_stuff