Как Python помогает находить симметрии в поэтическом тексте. Простой код для поиска палиндромов (слов и фраз, читающихся одинаково в обе стороны) в творчестве Владимира Маяковского.
Творческие секреты поэтессы глазами кода. Что анализ фонетики на Python рассказывает о «шестидесятниках».
Детекция мусора в гречке с помощью нейросети YOLO8n + попытки в real-time детекцию (Docker + FastApi, Gradio, TensorFlow Lite) + предложение добавить такую фичу в приложения продуктовых магазинов. За результатами приглашаю в статью.
Жить в США стало лучше, но не веселее. После эмиграции поэт написал больше «холодных» стихов. Установлено математически точно с помощью кода.
Всем привет! Если вы как и я задавались вопросом "а что там у гуглов", когда находили какую-то новую крутую софтину, смело полагая что если уж есть такое чудо, то у гуглов должно быть что-то еще лучше - то у нас с вами много общего.
И вот сегодня, вместо того чтобы продолжать вайбкодить в клоде, я вдруг вспомнил, что пару месяцев назад слышал что-то про 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 или больше. И вы уже не будете помнить, что за что отвечает и где лежит. В итоге вместо одного часа вы потратите день или больше на рефакторинг, которого можно и нужно было избежать.
В общем, ключевое — это не бежать сразу писать код, а сначала все продумать. Структуру, архитектуру, всякие эти фишечки и прочее. Хотя бы в общих чертах. Иначе ваш проект очень скоро будет приносить вам боль, а время вы потратите совсем не на то, что вам бы хотелось.
