Привет! Как и многие в 2025 году, я постоянно работаю с ChatGPT и Gemini: они помогают мне в работе, отвечают на сотни вопросов и просто развлекают. За время работы с ИИ у меня накопилась целая коллекция мини-промптов, которые делают процесс проще, результативнее и даже веселее. Сегодня делюсь с вами.

С момента, как OpenAI выпустила свой новый генератор картинок, прошло уже почти 3 месяца. Хайп уже давно прошел, а у меня дошли руки до статьи на Хабре

Эта статья про полезные юзкейсы генерации картинок, с которыми каждый из вас может сталкиваться.

Постарался найти такие юзкейсы, которые у графических дизайнеров будут стоить десятки тысяч рублей 💫

Внутри много примеров, прям много

И да, в статье я не топлю про полную замену дизайнера, а именно про снижение человекочасов, которые уходят на дизайн. Так как сам в общем то и дизайнер

Токены летят быстрее, а результат — медленнее: парадокс квантизации DeepSeek-R1. Замеры 4 версий модели доказали: уменьшение размера ускоряет генерацию отдельных токенов, но что происходит с общим временем ответа?

Привет!
Задумывались, какую версию квантованной LLM выбрать: Q4_K_M, Q6_K или Q8_0? Насколько Q6_K хуже справляется с задачами по сравнению с Q8_0? И что вообще означают все эти буквы в суффиксах?

Примечание: это адаптированный перевод моей статьи на Medium. Перевод был сделан при помощи мозга, а не нейросетей или Google Translate.

Если вам довелось уже почитав статьи про mcp технологию озадачиться вопросом «а что же происходит под капотом» и при этом какое то представление о том, что же такое mcp, у вас все таки есть, то, возможно, эта заметка поможет вам сделать еще один шаг к пониманию что за всем этим скрывается.

Казалось бы, совсем недавно мир только начал знакомиться с тем, что такое большие языковые модели (LLM). Вскоре после этого появились их многочисленные вариации — на любой вкус и цвет, от узкоспециализированных до универсальных моделей. Затем началась волна интеграций: LLM начали встраивать в различные сервисы, приложения и API, упрощая и автоматизируя рутинные процессы.

Следующим стало появление LLM-агентов — интеллектуальных систем, способных самостоятельно принимать решения и выполнять сложные задачи, взаимодействуя с внешними сервисами. Вместе с ростом их популярности возникла новая проблема — отсутствие единого стандарта взаимодействия между агентами и их окружением.

И вот, компания Anthropic представила решение этой задачи — новый протокол Model Context Protocol (MCP), который стандартизирует взаимодействие агентов с различными сервисами и между собой.

Давайте разберёмся, что такое MCP, и с чем его едят!

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

Всё это, конечно, субъективно. Например, я определяю по ощущениям: где-то к третьему абзацу статьи просто понимаю, что это писал ИИ. Вежливый «ЧатГПТ», брызжущий метафорами (чаще поверхностными) «Дипсик», логичный до наивности «Клод», оптимистичный «Грок» — разницы нет. ИИ и всё.

Итак, сегодня моя цель формализовать паттерны среднего чистого (без промптов) ИИ и сделать промпт, который позволит определить то, насколько заданный текст похож на творчество ИИ. Почему не определить автора? Потому что я знаю людей, которые пишут, как ЧатГПТ-мини: реально гладкий, поверхностный текст, никаких резких поворотов и углублений. И знаю, как может писать ИИ под хорошим промптом. Так что давайте я просто попытаюсь определить наиболее распространенные паттерны моделей, которые можно выделить в тексте.

Сегодня я решил изучить новую библиотеку Cloudflare OAuth provider, которую, судя по заявлениям, почти полностью написали при помощи LLM Claude компании Anthropic:

Эта библиотека (в том числе и документация по схеме) была по большей мере написана при помощи Claude — ИИ-модели компании Anthropic. Результаты работы Claude были тщательно проверены инженерами Cloudflare, уделившим особое внимание безопасности и соответствию стандартам. В исходный результат было внесено множество улучшений, в основном тоже при помощи промптов Claude (и с проверкой результатов). Промпты модели Claude и созданный ею код можно посмотреть в истории коммитов.

[…]

Подчеркнём, что это не «вайб-кодинг». Каждая строка была тщательно проверена и согласована с соответствующими RFC специалистами в сфере безопасности, уже работавшими в этими RFC. Я пытался подтвердить свой скепсис, но оказалось, что я ошибался.

Я и сам в последнее время достаточно много писал подобным образом код при помощи «агентских» LLM. И я тоже специалист по OAuth: я написал API Security in Action, многие годы был членом OAuth Working Group в IETF и ранее работал техлидом, а затем архитектором безопасности в ведущем поставщике решений OAuth. (Также у меня есть степень PhD в сфере ИИ, полученная в группе изучения интеллектуальных агентов, но ещё до возникновения современного ажиотажа вокруг машинного обучения). Поэтому мне было очень любопытно, что же создала эта модель. И сегодня, сидя на паре совещаний, я решил изучить результаты. Дисклеймер: я лишь вкратце просмотрел код и нашёл несколько багов, а не выполнял полный анализ.

Любой, кто хоть раз пытался «по-быстрому» проанализировать CSV-файл или прототип БД, сталкивался с выбором из неудобств: открывать в Excel, запускать Jupyter, возиться с pandas, или поднимать Postgres/ClickHouse ради пары запросов. Мне показалось странным, что в 2025 году до сих пор нет удобной zero-setup SQL-песочницы для локальных данных.

Так родился PondPilot - open-source инструмент для анализа данных, работающий прямо в браузере, без серверов и настройки.

Digital nomad - это человек, который добровольно решил сняться с якоря и жить свободно. Я к этой категории не отношусь. Меня скорее обстоятельства заставили сняться с большого тяжёлого якоря и двинуть куда подальше. Этим "куда подальше" оказались Штаты. Пока я жил во Владивостоке, я умудрился несколько раз отказаться от предложений с релокацией в Корею (Южную, на всякий случай уточняю), в Сингапур, в Канаду и США. Поэтому довольно иронично, что спустя 5 лет я оказался здесь.

В этой статье я больше хочу поделиться не тем как и почему я решил переехать, а скорее историей "оседания" там, куда приехал. Конкретно, я хочу затронуть три важных темы: культура и язык, быт, поиск работы. Это мой опыт, мой путь, конкретно про США (Калифорния). Кому-то он будет полезен - класс! Если кого-то это заденет за живое - сочувствую вам. Итак, пристегните ремни, мы...

Приветствую, дорогой читатель!

С момента появления в нашем любимом веб-сервере Angie замечательной функции ACME-челленджа через DNS прошло уже достаточно времени, чтобы оценить все преимущества этого решения. Эта поистине революционная фича подарила нам долгожданную возможность получать wildcard‑сертификаты буквально в несколько кликов.

Однако, как это часто бывает с новыми технологиями, до сих пор у многих пользователей, особенно только начинающих свое знакомство с Angie, возникают вполне закономерные вопросы вроде: «Как правильно это настроить?» или «Как это вообще работает под капотом?». Именно для таких случаев, дорогие друзья, и была задумана эта подробная статья — максимально простыми и понятными словами описать весь процесс настройки от начала и до конца.

Путь от простых хижин к роскошным особнякам, украшенным фресками и колоннами, в Pharaoh — это не просто вопрос архитектуры и разные текстуры. Это отражение заботы игрока о своём виртуальном городе, его нуждах, вере и безопасности. Каждое жилище в городе это FSM, реагирующая на условия вокруг: достаток еды, доступ к воде, религиозные обряды, культурные радости и много чего еще.

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

В этой статье попробую рассказать, как устроена эволюция домов, какие требования стоят за каждым уровнем жилья и как это было реализовано в оригинальной игре. Если вы вдруг пропустили встречу нашего жреческого круга... простите, предыдущие статьи про восстановление исходников этого старого ситибилдера, — обязательно найдите время, чтобы взглянуть на пару интересных моментов (Добро пожаловать в Древний…, ecs, dynvtbl, логические потоки и Фараоне, Как построить мастабу, Как рисуется карта в Фараоне, Новый дом для Фараона)

Все скриншоты в статье сделаны уже на рендере проекта, исходники на github

Как же меня бесят статьи в духе “Как всего за 139 рублей в месяц развернуть свой сайт-визитку на vps”. Какие 139 рублей за сайт-визитку, совсем уже стыд потеряли?!

В этой статье я вам пошагово расскажу и покажу как бесплатно разместить и вести ваш личный сайт(блог, cv, wiki). Вам даже отдельный домен не нужен (всё будет “из коробки”), хотя в последнем шагом мы и его прикрутим. От вас нужны будут базовые знания git и просто уметь работать с markdown.

Однажды я устал расшифровывать аудио пачкой инструментов в духе «Балерино-Капучино и Бобрито-Бандито» и решил собрать свой пайплайн.

В статье расскажу, как я подключил ИИ к обработке голосовых записей буквально за вечер. Мне нужно было загружать запись голоса в нейросетку и на выходе получать выжимку с итогами встречи — саммари/фоллоу‑апами/«минутками». Я хотел от софта безопасности данных, локального запуска и минимума вложений (в идеале 0 затрат). Я системный аналитик, поэтому не был готов писать приложение целиком.

По моей инструкции вы сможете сделать подобный конвейер своими силами даже без навыков кодинга.

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

В этой статье я покажу, как буквально за один вечер можно заложить фундамент цифровой репутации для стартапа или рet-проекта: заполнить выдачу управляемыми упоминаниями, получить первые качественные ссылки, усилить доверие к бренду и даже немного подстегнуть трафик. Без магии, без бюджетов, без агентств. Только вы, браузер и системный подход. Всё, что рассказываю, покажу на примере микросервиса, который мы запустили этой весной. Примеры публикаций — в тексте, результаты стратегии — в финале.

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

Переход на микросервисы – это часто как переезд из тесной, но понятной коммуналки (монолита) в огромный город с кучей отдельных квартир. Свободы больше, масштабироваться проще, команды независимы – красота! Но тут же вылезает проблема, о которую разбиваются многие корабли: как поддерживать порядок и целостность данных, когда они размазаны по десяткам этих "квартир"-сервисов со своими собственными базами данных?

Старый добрый ACID, который спасал нас в монолитах с одной большой базой, здесь уже не помощник. Пытаться натянуть на микросервисы классические распределенные транзакции с двухфазным коммитом (2PC) – это почти всегда путь к страданиям. Представьте: один сервис захватывает блокировку, ждет подтверждения от другого, тот ждет третьего... Чуть что не так – вся цепочка висит, пользователи ждут, система тормозит, доступность падает. Звучит знакомо? Именно поэтому умные люди придумали альтернативу – паттерн, известный как Saga.

Многие разработчики работают в Linux-среде, но не всегда глубоко понимают, как взаимодействие с ОС происходит на низком уровне. На собеседованиях всё чаще спрашивают про системные вызовы Linux. В этой статье мы рассмотрим, какие вызовы встречаются чаще всего и как они работают.

Микросервисная архитектура стала де-факто стандартом для построения современных масштабируемых приложений. Вместо единого монолитного приложения система разбивается на набор мелких независимых сервисов, каждый из которых отвечает за свою четко обозначенную функцию. Такой подход позволяет упрощать разработку и развертывание отдельных компонентов, повышать отказоустойчивость и масштабируемость системы. Однако переход к микросервисам и их эффективное использование сопряжены с рядом сложных задач. Для их решения в практике выработаны архитектурные паттерны – типовые подходы и шаблоны проектирования.

В данной статье мы разберем несколько ключевых паттернов, связанных с микросервисами. Речь пойдет о паттернах миграции и интеграции (таких как Strangler Fig – «удушающее дерево» и API Gateway), о сетевых и структурных паттернах (Service Mesh, Sidecar), о шаблонах работы с данными (Database per Service, CQRS) и об особом подходе к хранению состояния (Event Sourcing). Для каждого паттерна мы рассмотрим его суть, назначение, примеры использования, а также плюсы и возможные сложности. К некоторым паттернам приведены упрощенные диаграммы и фрагменты кода, чтобы иллюстративно показать, как они работают на практике.

Мы — команда студентов из ИТМО, которая прошла путь от хакатонов до продуктовой разработки. На собственном опыте расскажем, как выстроили инфраструктуру, способную масштабироваться, переживать сбои и не стоить, как полкоманды в найме.

Когда вы только начинаете делать стартап, инфраструктура кажется чем-то второстепенным. Важнее MVP, фичи, дизайн, пичдек. Но в какой-то момент всё внезапно перестаёт помещаться на одном сервере, руками деплоить становится больно, SSL не обновляется, а продакшн падает из-за перегрузки или забытого docker-compose up.

Kubernetes? Слишком сложно, долго и дорого. Монолит? Неудобно масштабировать. Мы искали третий путь — и нашли его.