Чтобы транзакции в InnoDB работали предсказуемо, важно понимать внутреннюю логику InnoDB. Ошибки чаще всего возникают не из-за отсутствия транзакций, а из-за неверных ожиданий относительно уровней изоляции и работы блокировок.
В этой статье давайте разберём несколько распространенных заблуждений и на примерах посмотрим, как на самом деле работают транзакции.
Никак не могу оставить в прошлом, одну историю, произошедшую со мной больше 7 лет назад.
На тот момент я, еще студент последнего курса универа, только получил свою первую работу в IT... Как сейчас помню свои эмоции. Наконец-то, спустя годы подготовок и отказов, вот, наконец получаешь свойпервый «настоящий» проект. Осмотревшись по сторонам, понимаю, что кругом меня не то что других джунов нет, но даже мидлов. Сплошные синьоры и лиды, как тогда казалось — грозные дядьки, с большим опытом... Ну ничего, сейчас я им покажу, что такое «молодая гвардия» 😂.
Получаю компьютер, креды для доступа, мне подробнее рассказывают про проект, присылают ссылки на минимальный набор сервисов, что нужно будет локально поднять для работы и отправляют настраивать окружение. В первый же день я сломал заботливо предустановленную мне убунту 😂 (удалил «не ту» версию питона, которая, как выяснилась, очень нужна), ну да ладно, мелочи, с кем не бывает?
Установил минт, начал настраивать IDE, окружение, забрал себе нужные сервисы, вроде все хорошо, НО в одном из сервисов стабильно падает один и тот же тест. Запускаю отдельно — все хорошо и стабильно. Запускаю через сборщик (mvn test) — падение. Пытаюсь разобраться, что происходит — ничего не понятно. Тест падает из‑за мока, которого вообще нет в этом тестовом сценарии. Больше того, смущает ситуация, что ни на ci, ни у кого из коллег такого не происходит. Тест стабилен, да и в нем не меняли ничего уже довольно давно. Вывод: проблема на моей стороне и разбираться мне с ней самому.
Это начинается незаметно. Сначала — просто «временное решение». Потом — «сделаем рефакторинг». Но «потом» не наступает никогда. Мы называем это техническим долгом, словно он когда-то будет погашен, но прекрасно знаем — чаще всего это просто красивое описание хаоса.
Когда использование инструмента грозит потерей качества. Сравнивать нужно не только скорость, но и качество кода, время на дебаггинг и код-ревью.
Я пишу всякое на Go в Ви.Tech (IT-дочка ВсеИнструменты.ру) и как и все, люблю подискутировать на технические темы.
У этой заметки сложная судьба, мне загорелось написать ее еще летом, но совершенно не хотел говорить об очевидных вещах и писать миллион первую статью со ссылкой на гугловский go code review comments. Тема уже разобрана всеми кому не лень, на русском языке вот у Николая @JustSkiv Тузова, есть замечательное видео на его ютуб канале, раскладывающее по полочкам, для чего это нужно.
Последний дисклеймер и перейду к сути: тема на самом деле очень обширна и я сознательно сконцентрировался на одном аспекте (неуместные определения интерфейсов). Буду рад, если продолжим общение в комментариях, очень не хватает Хабра начала 10-х годов, с живыми, а иногда и крайне горячими, инженерными дискуссиями.
Мы продолжаем нашу серию статей, посвящённых фундаментальным концепциям разработки. Сегодня мы поговорим о проверенных практиках, которые помогают разработчикам избегать распространённых ошибок и работать эффективнее. Мы разберём принципы SOLID, а также парадигмы YAGNI, DRY и KISS, которые особенно актуальны в объектно-ориентированном программировании.
Из первых уст рассказываю как переход на Temporal обеспечил надежную доставку клиентских услуг в контексте обычного хостинга.
Рассказываем, как безобидная строка JavaScript-кода привела к нарушению стабильности тестов продукта, а также о том, как можно избежать подобных ошибок.
Откройте любой пулл‑реквест в проекте с любой «чистой архитектурой» и вы скорее всего увидите не обсуждение бизнес‑логики, а срач. «Это нельзя класть в UseCase, это логика домена!», «Зачем тут еще один DTO, мы же просто поле прокидываем!», «Этот интерфейс не нужен, у нас никогда не будет другой реализации!». Полагаю, очень много людей с таким сталкиваются.
Эта статья — о том, почему архитектура из спасения превратилась в тонны говнокода. И, что самое главное, — как прекратить этот хаос и, наконец, начать просто писать код, который работает, а не «следует всем концепциям».
На собеседованиях часто можно услышать вопрос: «Назовите принципы хорошего кода». Даже начинающие, но уже имеющие практический опыт программисты интуитивно понимают: хороший код — это читаемый, переиспользуемый, легко расширяемый и поддерживаемый. Но что обеспечивает эти качества? Ответ кроется в объектно-ориентированном программировании (ООП).
Индустрия разработки программного обеспечения переживает фундаментальную трансформацию. Еще два года назад идея доверить AI написание производственного кода казалась фантастикой. Сегодня это реальность для сотен тысяч разработчиков по всему миру.
Согласно данным Anthropic, Claude Code используют более 115 тыс. разработчиков, которые обрабатывают 195 млн строк кода еженедельно. Уровень внедрения среди разработчиков составляет 53% — это лидирующий показатель на рынке. База активных пользователей выросла на 300%, а доход увеличился в 5,5 раза за последние месяцы.
Но что действительно важно, это не статистика внедрения, а фундаментальный сдвиг в подходе к разработке. AI-инструменты больше не просто ускоряют написание кода. Они меняют саму парадигму: от «Как это закодить?» к «Что именно нужно построить?».
В этой статье мы рассмотрим практические паттерны и подходы к R&D и проверке гипотез с использованием современных AI-инструментов, в частности Claude Code — терминального агентного инструмента.
Всем привет! Меня зовут Виктор, и более трёх лет я работаю с языковыми моделями – от проприетарных решений вроде ChatGPT до open-source систем, которые можно разворачивать локально и встраивать в собственные продукты. Я застал времена жутких галлюцинаций GPT-3.5 и ждал обещанного GPT-5 – того самого почти AGI, которое, казалось, вот-вот появится.
За это время многое изменилось: появились десятки моделей, которые можно запустить даже на слабом ноутбуке, и мощные коммерческие системы, способные понимать с полуслова. Но одно остаётся неизменным – AGI так и не случилось.
Если два года назад нам уверенно обещали, что «всё уже близко», то теперь даже крупнейшие компании признают: ждать придётся долго.
И это не плохо. Просто разработчикам, приходится учиться работать с тем, что есть, и извлекать максимум пользы из нынешних LLM.
За годы работы с моделями я выработал ряд принципов, которые помогают получать стабильные и читаемые результаты. На первый взгляд – ничего нового: это те же инженерные практики, которые мы применяем в обычном программировании.
Но в контексте LLM они начинают работать совсем иначе.
Привет, Хабр! Меня зовут Константин Репин, я старший программист в Fix Price. В этой статье расскажу, как мы облегчили жизнь нашим коллегам-ревьюерам, внедрив в процесс AI-ассистента для код-ревью. Начну с краткого описания инструмента, а затем перейдем к практике — покажу нашу реализацию и поделюсь опытом, включая примеры кода.
Многие embedded-разработчики привыкли работать без автоматизированных тестов, полагаясь на ручное тестирование и отладку через программатор. Это кажется простым и быстрым решением для небольших проектов. Однако при росте кодовой базы и команды такой подход приводит к критическим проблемам: баги возвращаются в новых релизах, знание о системе хранится только в головах разработчиков, а каждое изменение требует длительного ручного тестирования на стенде.
Автоматизация CI/CD для embedded-систем решает эти проблемы, хотя требует начальных усилий на настройку инфраструктуры.
Почему одни команды релизят предсказуемо и без героизма, а другие тушат пожары на продакшене каждую неделю?
Мы решили выяснить, какие инженерные практики превращают разработку в систему с понятными процессами и предсказуемыми результатами.
Исследование 100+ респондентов.
Hawk — это open-source трекер ошибок, разработанный в России. Позволяет отслеживать ошибки в веб-приложениях, API и мобильных сервисах. В этой статье подробно рассмотрим функциональность, которая сегодня доступна пользователям Хоука — от регистрации до продвинутых SDK-функций и планов на будущее.
Ночь. Курсор мигает, как маяк в тумане. Логи шепчут о том, что в коде — своя улица, свои правила и кодекс общения. Объекты — не безмолвные элементы системы. У каждого свой характер, привычки и слабости. Один щёлчок и поведение меняется: кто-то отдаёт приказы, кто-то внимательно прислушивается, а кто-то терпеливо ждёт сигнала. Эта статья — карта такого города.
Всем привет! Меня зовут Бромбин Андрей и сегодня разберёмся в поведенческих паттернах ООП. Короткие определения, идеи через ясные метафоры и рабочие примеры на Java. Всё это для того, чтобы система не трещала по швам, а решения были ясными, предсказуемыми и поддерживаемыми.
Многие разработчики привыкли везде ставить if-проверки, даже для условий, гарантированных кодом. Зачем проверять то, что не может нарушиться? Такие проверки создают шум в коде и мусор в релизе. Assert решает эту проблему: документирует допущения и исчезает из финальной сборки. В статье покажу все преимущества assert'ов и предостерегу от подводных камней их использования.
Взгляд на интеграцию ИИ в программирование от опытного программиста (миллион строк кода я, наверное, написал за всю жизнь). Текст писал я сам, это не мусор от GPT, ИИ здесь только исправил ошибки.
Если дать этот текст ИИ на фактчек, то он может как полностью подтвердить мою статью кучей проверенных фактов, так и полностью опровергнуть, и тоже с кучей фактов, т.е. по сути будет заниматься черри-пикингом - всё зависит от формулировки вопроса. И где же тогда правда? Правда, я думаю, у тех, кто в этой среде годами работает и получает много опыта как разработки с ИИ, так и без него. Т.е. имеет хоть какие-то экспертные знания. В этой статье мнение одного из таких людей. Мнения одного человека, конечно, мало, нужно обобщать опыт сотен людей из разных сфер программирования. Я вношу в это обобщение свой небольшой вклад.
Я верил, что с приходом ИИ жизнь разработчика превратится в сказку. ИИ будет писать код, а я — придумывать фичи и строить продукт. В реальности я полдня пишу промты, а еще полдня трачу на правки за Copilot. Быстрее написать код самому.
Почему промты занимают так много времени и как компании учат сотрудников использовать ИИ, чтобы он не портил никому жизнь — рассказываю в статье.
