JavaRush – здесь становятся программистами

Неделя была длинной, как legacy-код без документации. Выдыхаем, закрываем лишние вкладки и переходим к мемам 😎

Нашли способ срезать расходы на AI на 70% 💸 Наткнулись на инструмент, который перед отправкой модели превращает текст в обычную PNG-картинку. Звучит как бред — но счёт за Claude Code реально падает на 59–70%. Разобрались, почему картинка выходит дешевле того же текста. И — что важнее — в каком случае этот же трюк может тихо уронить тебе прод. Собрали, что выяснили. ЧИТАТЬ 👉

Что такое preoptimization и почему она может навредить Вы написали простую функцию. Она работает, но вдруг возникает мысль: «А что будет, если однажды её вызовут миллион раз?». И вместо того чтобы переходить к следующей задаче, вы начинаете переписывать код: добавляете кэширование, более сложные структуры данных, убираете «лишние» операции. Проблема лишь в том, что этого миллиона вызовов может никогда и не быть. Именно это называют преждевременной оптимизацией (preoptimization). Никто не говорит, что думать о производительности плохо, но оптимизация до того, как появились реальные данные о том, где именно возникает проблема, почти всегда означает потратить время не там, где это действительно нужно. Классическая цитата на эту тему принадлежит Дональду Кнуту: «Преждевременная оптимизация — корень всех зол в программировании». Звучит категорично, но за этими словами стоит вполне конкретная идея: большая часть времени выполнения программы обычно приходится на небольшую часть кода. Оптимизировать всё подряд — значит тратить усилия на 90% кода, который не является узким местом. Есть и другая проблема. Любая оптимизация делает код немного сложнее. Если она не приносит реальной пользы, команда платит эту цену напрасно: такой код сложнее читать, тестировать и изменять. А когда через месяц появляется новое требование, может оказаться, что «оптимизированную» версию придётся полностью переписывать – и сложность, которую добавляли ради скорости, теперь только мешает. Хороший подход выглядит иначе: сначала сделать код рабочим и понятным, а если действительно возникла проблема с производительностью – измерить, где именно она находится, и только после этого оптимизировать конкретное место. Не гадать, а измерять. Для этого существуют профайлеры – инструменты, которые показывают, сколько времени программа проводит в каждой функции. Вместо того чтобы гадать, разработчик получает конкретные цифры и работает именно с той частью кода, которая действительно является узким местом. Для начинающего разработчика здесь есть простой ориентир: если нет конкретной проблемы с производительностью, нет и причины заниматься оптимизацией. Хороший код достаточно быстрый для своей задачи и при этом остаётся понятным для людей, которые будут работать с ним через полгода. Часто именно простота оказывается лучшей оптимизацией.

Роботы, которые строят мосты, как муравьи Несколько дней назад исследователи из MIT представили систему под названием FloatForm. Она состоит из небольших роботов, каждый размером примерно с тарелку. По отдельности они почти ничего не могут, но стоит им оказаться на воде вместе – и они самостоятельно соединяются друг с другом, образуя мост, платформу или даже сцену для концерта. А когда необходимость исчезает – конструкция так же самостоятельно разбирается и собирается в другом месте. Каждая такая «лодочка» оснащена собственными двигателями, датчиками и магнитными креплениями. Большинство решений роботы принимают самостоятельно, координируя свои действия с ближайшими соседями. Центральный планировщик лишь определяет конечное расположение роботов в конструкции. Самое интересное, что источником вдохновения для этой разработки стали муравьи. Во время наводнений некоторые их виды спасаются, образуя живые плоты. Ни один муравей не управляет другими. Каждый следует очень простым локальным правилам, но вместе колония создаёт сложную и устойчивую конструкцию. Именно этот принцип исследователи использовали и в FloatForm: множество автономных роботов координируют свои действия между собой, чтобы сформировать нужную структуру. Авторы отмечают, что такой децентрализованный подход делает систему более устойчивой. Если один робот временно выходит из строя или теряет ориентацию, остальные продолжают работать, а затем он снова присоединяется к группе. Кроме того, систему можно масштабировать, просто добавляя новых роботов. Пока исследователи протестировали систему с восемью роботами, но в симуляциях она уже успешно работала с 64. В будущем авторы проекта видят множество практических применений: временные мосты после стихийных бедствий, плавучие рынки, мобильные платформы для строительства, экологического мониторинга или проведения спасательных операций.

AI дороже сеньора: пишет код за €16 700 в месяц 🤯 Дали свежему Fable 5 волю ровно на час — просто посмотреть, на что способна топ-модель. Заглянули на счётчик: €100. За час. Прикинули на месяц — вышла зарплата крепкого сеньора. Где-нибудь в Штатах. И вот сидим и переосмысливаем, за что вообще теперь платят в разработке. Написали, к чему пришли. 👉 ЧИТАТЬ →

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

Наверное, каждому знакомо это состояние, когда смотришь на список дел и думаешь: «У меня совершенно нет сил». Сегодня утром Понедельничный Котик чувствует себя именно так. Но дела сами себя не сделают, поэтому Котик решил узнать, что говорит нейронаука об усталости. Оказалось, что исследователи из Университета Брайтона выдвинули интересную теорию: во многих ситуациях усталость – это не сообщение о том, что организм полностью истощён. Это защитный сигнал мозга, который пытается не допустить, чтобы организм потерял равновесие (это состояние называют гомеостазом). Проще говоря, мозг постоянно оценивает: «Если мы продолжим в таком темпе, хватит ли организму ресурсов?». Если ответ кажется рискованным, он заранее посылает сигнал: «Остановись. Передохни». Получается, ощущение усталости не всегда означает, что ресурсы уже закончились. Иногда это означает, что мозг просто не хочет рисковать. Так что же делать в такой ситуации? Исследователи не советуют «пересиливать себя» в этот момент, а вместо этого постепенно учить свой мозг точнее оценивать возможности организма. Для этого подойдёт регулярная умеренная физическая активность (например, прогулка, лёгкая растяжка или спокойная езда на велосипеде) даже в состоянии усталости. Фактически мозг начинает получать новые доказательства: «Мы уже проходили километр после тяжёлого дня — и всё было хорошо. Значит, и в этот раз справимся». Конечно, это не означает, что любую усталость нужно игнорировать. Если организм истощён из-за болезни, недостатка сна или перегрузки, отдых остаётся необходимым. Но исследование напоминает об одной интересной вещи: иногда мозг подаёт сигнал об опасности с определённым запасом. Поэтому сегодня Понедельничный Котик не будет заставлять себя целый день работать через силу. Но и лежать весь день на диване тоже не станет. Сначала он отправится на небольшую прогулку, и, возможно, именно она поможет мозгу поверить, что силы ещё остались.

Go с нуля: честный роадмап 🦫 Трое инженеров в Google психанули из-за того, что C++ собирается по полчаса, — и придумали Go. Сегодня на нём работает бэкенд Uber, Dropbox и Cloudflare, а ещё на нём написаны Docker и Kubernetes. Порог входа ниже, чем у многих языков, платят — как за взрослых, а конкурентов на рынке меньше, чем в Java или Python. Меньше давки у входа — больше шансов. Собрали честный роадмап: как выучить Go с нуля до бэкенда — по этапам, без «сначала полгода теории». 👉 ЧИТАТЬ РОАДМАП → 🚀 НАЧАТЬ GO БЕСПЛАТНО →

Если вам тоже кажется, что рабочая неделя была как regex – как будто коротко, но болит непропорционально сильно, – то вот порция лечебных мемов 🤕