Охлаждение после эмиграции. Грустные выводы исследования поэзии Бродского на Python

Жить в США стало лучше, но не веселее. После эмиграции поэт написал больше «холодных» стихов. Установлено математически точно с помощью кода.

Код, за который должно быть стыдно

Жить в США стало лучше, но не веселее. После эмиграции поэт написал больше «холодных» стихов. Установлено математически точно с помощью кода.

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

Это начинается незаметно. Сначала — просто «временное решение». Потом — «сделаем рефакторинг». Но «потом» не наступает никогда. Мы называем это техническим долгом, словно он когда-то будет погашен, но прекрасно знаем — чаще всего это просто красивое описание хаоса.

Где заканчивается слово и начинается образ? Использую Python для поиска особенностей творчества К.Г. Паустовского.

Сравнил Пушкина и Ершова с помощью Python и пытался найти автора "КОнька-горбунка" среди цифр и кода.

Как «Про это» стало первой киберпоэмой. Стихотворение, которое впервые в истории использовало фотоколлаж, разбивку строк по принципу «лесенки» и типографские эксперименты, напоминающие современные веб-дизайн?

Можно ли с помощью Python и математических метрик лучше понять поэзию? В этой статье я покажу, как с помощью кода можно количественно сравнить стили Александра Пушкина и Михаила Лермонтова.

Маршак хорошо переводил Шекспира, но насколько он был близок к оригиналу? Сохранен ли у него ритм, размер, смысл и структура? Установлю это математически точно с помощью Python.

Всем привет! Недавно я делился своим обзором на Devin, в котором рассказал как потратил 500 долларов на вайбкодинг AI‑редактора и остался не особо доволен – он хоть и справился, но было дорого и долго. Продолжаю поиск своего идеального кодинг‑агента и сегодня разбираюсь в Codex от OpenAI.

Почему команда из 200 разработчиков оценивает задачу в 6 месяцев, когда стартап из 10 человек делает её за месяц? Почему продукты со временем теряют способность к инновациям, даже имея все ресурсы? Ответ не в технологиях. Ответ — в ментальных ограничениях.
В современном управлении продуктом существует множество моделей приоритизации — RICE, ICE, MoSCoW, WSJF. Все они основаны на одном принципе: максимальный эффект при минимальных затратах. Матрица Эйзенхауэра и правило Парето стали классикой продуктового менеджмента.
Но есть фундаментальная проблема: эти модели рассматривают ресурсы как константу. В реальности же с каждым спринтом продукт накапливает "кредитную задолженность" — технические, бизнес- и продуктовые долги, которые создают не только объективные препятствия, но и ментальные ограничения. Психологические барьеры, которые сужают рамки для инноваций еще до того, как команда начнет оценивать их реализуемость.
Возникает парадокс приоритизации. Простая задача в начале жизни продукта может стать сложной через год. Изменение, которое раньше занимало неделю, теперь требует месяца. И самое опасное — команда начинает воспринимать эту повышенную сложность как неизбежность, формируя ментальные ограничения, которые отсекают амбициозные идеи еще на стадии обсуждения.
-----
Это Александр Козуб — про то, что находится глубже очевидного. Пока все чинят симптомы, я разбираю системы, которые их создают.

Взгляд на интеграцию ИИ в программирование от опытного программиста (миллион строк кода я, наверное, написал за всю жизнь). Текст писал я сам, это не мусор от GPT, ИИ здесь только исправил ошибки.
Если дать этот текст ИИ на фактчек, то он может как полностью подтвердить мою статью кучей проверенных фактов, так и полностью опровергнуть, и тоже с кучей фактов, т.е. по сути будет заниматься черри-пикингом - всё зависит от формулировки вопроса. И где же тогда правда? Правда, я думаю, у тех, кто в этой среде годами работает и получает много опыта как разработки с ИИ, так и без него. Т.е. имеет хоть какие-то экспертные знания. В этой статье мнение одного из таких людей. Мнения одного человека, конечно, мало, нужно обобщать опыт сотен людей из разных сфер программирования. Я вношу в это обобщение свой небольшой вклад.

Я уволился из своей первой работы SRE‑инженером после особенно тяжелой недели дежурства. Семь ночей подряд я просыпался от PagerDuty. Семь ночей подряд я чинил одну и ту же проблему с памятью, которую никто не хотел исправлять «по‑настоящему», потому что «горячий фикс же работает». На восьмое утро я пришел в офис и положил заявление на стол.
Это было пять лет назад. С тех пор я прошел через четыре компании, построил on‑call процессы с нуля в двух из них, и научился главному: дежурства не должны убивать людей. Физически и морально. Давайте поговорим о том, как построить on‑call ротацию, которая не приведет к массовым увольнениям.

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

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

Мне нужно написать скрипт авторега аккаунтов для одного популярного сервиса. для регистрации аккаунтов нужна электронная почта.
Ранее я уже использовал для таких задач python-библиотеку tempmail, но она перестала работать.

Сегодня хотелось бы поговорить с вами о такой теме как Легаси.
Давайте дадим определение, что такое легаси.
Легаси - это тот код, который писали до нас и который пришел нам от других.
Легаси - это не всегда «плохой» код, а просто код, который устарел по технологии, по структуре или по пониманию.
Почти любой проект со временем превращается в легаси, если его не обновлять.
На своем опыте разработки я могу классифицировать легаси на три категории. Опять же я не претендую на абсолютную объективность. Это только моя классификация, на основе того, с чем лично я столкнулся.
1) Технологии, которые еще работают, но есть обновленные версии пакетов, фреймворков и инструментов. Просто в данный момент код работает на предыдущих версиях. Самый очевидный пример проект написанный на Vue2, когда есть Vue3. Переписать его на новую версию с одной стороны не так уж и трудно. А с другой это связано с подводными камнями. Если мы переходим с Option Api на Composition Api то простой заменой одного кода на другой не обойтись. Некоторые вещи работают иначе. И придется отлавливать локальные проблемы. Если проект небольшой и сложной логики там мало, то это делается быстро. Если же она есть то проблемы точно будут. Кроме того не стоит забывать, что часть пакетов и библиотек, которые работают с Vue2, не работают с Vue3. Следовательно придется искать аналоги. В целом проблемы и способ перехода здесь прозрачны и это самый легкий вариант.
2) Нельзя переписать, но можно работать. Это проекты написанные на старых технологиях, как jquery и других. Они не могут быть быстро и легко переведены на современные инструменты. Так как для этого придется все писать заново. Однако код, который был написан, достаточно понятен и его не так сложно поддерживать. А переезд на новый вариант это параллельная разработка нового. Здесь тоже все понятно. Мы не имеем возможности бесшовно перейти на новые версии, потому что их просто может не быть. Поэтому приложение пишется с нуля на новом стеке.

Не откладывайте на завтра то, что можно сделать сегодня. Именно эта мысль для меня стала одной из ключевых в разработке приложений. «Почему?» — спросите вы.
Все очень просто. Говорите себе: «Это я потом поправлю, а это я потом перепишу. А вот это пока подождет. А файловую систему я потом продумаю»? Так вот это «потом» может так и не наступить. А ваш проект превратится в мусор. А даже если вы и вспомните о том, что пора что-то куда-то переносить, вместо двух файлов у вас будет 100 или больше. И вы уже не будете помнить, что за что отвечает и где лежит. В итоге вместо одного часа вы потратите день или больше на рефакторинг, которого можно и нужно было избежать.
В общем, ключевое — это не бежать сразу писать код, а сначала все продумать. Структуру, архитектуру, всякие эти фишечки и прочее. Хотя бы в общих чертах. Иначе ваш проект очень скоро будет приносить вам боль, а время вы потратите совсем не на то, что вам бы хотелось.

После начала Специальной Военной Операции многие западные компании объявили о прекращении своей деятельности в России и Белоруссии и некоторые из них стали блокировать пользователям с российскими и белорусскими IP-адресами доступ на свои ресурсы в сети Интернет. Яркими примерами таких блокировок являются сайты: intel.com, dell.com, chatgpt.com, community.cisco.com, mongodb.com, tenable.com, wiki.zimbra.com, releases.hashicorp.com, registry.terraform.io, vagrantcloud.com, solarwinds.com и множество других.
Такие блокировки мешают IT-специалистам из России и Белоруссии получать доступ к актуальной информации и программному обеспечению необходимому для обучения и работы. Препятствуют получению актуальных релизов программных продуктов и критических обновлений безопасности, что в условиях участившихся хакерских атак стало особенно важным.
Также, в качестве упражнений для ума, можно поизучать вопросы о допустимости дискриминации по национальному признаку и принципе сетевой нейтральности.
В этой статье будет рассказано о том, как сконфигурировать роутеры марки Keenetic (возможно и других марок, поддерживающих установку пакетов из репозитория Entware) для развертывания на них программного пакета обеспечивающего расширенное управление маршрутизацией. Будет приведена инструкция как установить на роутер Telegram-бота для быстрого и удобного управления маршрутизацией трафика.
В это статье НЕ БУДЕТ инструкций о том откуда взять работающий VPN и НЕ БУДЕТ инструкций о том как обходить блокировки Роскомнадзора. Обсуждать это в комментариях к статье тоже НЕ НУЖНО.
Моя статья посвящена изучению современных инструментов и технологий и объясняет то как получить доступ к легальным сайтам, доступ к которым изнутри страны не ограничен и которые самостоятельно закрыли доступ для пользователей из России и Белоруссии.
Отдельно хочу заметить, что я регулярно вычитываю законы которые затрагивают мои права, свободы и законные интересы и не собираюсь давать Роскомнадзору правовых оснований для скрытия этой статьи из публичного доступа. Конечно, я не могу исключать попыток Роскомнадзора скрыть мою статью путём расширенного толкования действующих законов, либо превышения должностных полномочий и выходом за пределы правового поля. Однако надеюсь что и в этом случае у меня хватит знаний и опыта для юридической защиты моей публикации.
Продолжая чтение настоящей статьи вы полностью соглашаетесь с тем что всеми полученными знаниями, технологиями и программными продуктами следует распоряжаться добросовестно и разумно, не планируете нарушать действующее законодательство и собираетесь получать доступ только к ресурсам, использование которых не запрещено в стране вашего пребывания.
Если вы не согласны хоть с чем-то из вышеописанного - вам следует немедленно прекратить чтение настоящей статьи.

Делюсь с вами задачей, которая позволит бесцельно потратить ваше время, как уже это сделала со мной. Под катом небольшая история из жизни и немного кода на JS.

Espruino + ESP32: как вывести русский текст и подключить кириллический шрифт ? История из жизни, создание и подключение кастомного шрифта 🦐