Чтобы транзакции в InnoDB работали предсказуемо, важно понимать внутреннюю логику InnoDB. Ошибки чаще всего возникают не из-за отсутствия транзакций, а из-за неверных ожиданий относительно уровней изоляции и работы блокировок.

В этой статье давайте разберём несколько распространенных заблуждений и на примерах посмотрим, как на самом деле работают транзакции.

Привет, Хабр! Меня зовут Сергей, я фронтенд-разработчик в Rusprofile. Давайте поговорим о работе autocomplete – автозаполнении полей в браузере. 

Благодаря этой функциональности жизнь пользователей может быть проще. Не нужно тратить время на копание в чертогах разума в поисках почтового индекса, адреса или точного названия компании. Можно не записывать логины, ИНН и другую информацию на стикеры вокруг монитора, все нужные данные подставляются автоматически. Формы на 5-10 полей перестают выглядеть такими уж устрашающими. 

Но в то же самое время, наверное, все мы видели, как путаются местами имя и фамилия из автозаполнения, а иногда кажется, что автоматически подставляются какие-то совсем случайные значения.

Эта статья – небольшая рефлексия на тему autocomplete; о природе проблем, с которыми сталкивается разработчик при работе с этим инструментарием.

Надеюсь, будет интересно для фронтендеров, менеджеров продукта, дизайнеров – коллег, у кого в бэклоге есть задачи про формы; а также для всех, кому близки темы о веб-разработке.

В Rusprofile наш домен — регтех, мы помогаем компаниям оценивать надежность контрагентов. Каждый день сотни скриптов качают данные из официальных открытых источников, парсят и строят кеши.

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

Эта статья — о том, как «проклятье масштаба» оказалось алгоритмической задачей; решение — получилось благодаря принципам обхода ориентированных графов; а запаса прочности решения хватило, чтобы с момента появления на протяжении лет не требовалось дополнительных ресурсов и каких‑либо доработок.

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

Будут технические детали, теория графов и немного рефлексии.

Ситуация: пишешь код на JS, хочешь обработать исключение, пробрасываешь throw, ловишь его с помощью try‑catch. Но добавим нюанс: пусть это нужно сделать для setTimeout. Эта функция использует окружения браузера — не JS‑функция, асинхронная.

Загвоздка: catch не сможет поймать ошибку.

Этот пример — одна из нескольких особенностей JS, из‑за которых я считаю обработку исключений «из коробки» на этом языке неудобной. Но есть и хорошие новости — для JS существуют альтернативные способы работы с исключениями, с которыми дела обстоят получше; например, паттерн «контейнерный тип».

Давайте разбираться.

Зачем нужен статический анализ кода, кажется, никому объяснять сегодня уже не нужно. Но одно дело — поддерживать код «чистым» с первого коммита, и совсем другое — встраивать новый инструмент в проект, который за несколько лет успел разрастись и пережить несколько итераций глобального рефакторинга. Мы работаем с большим количеством плохо документированных источников данных, а статический анализ кода помогает учитывать самые разные граничные случаи.

И ещё один момент: Rusprofile почти целиком написан на PHP, языке со слабой динамической типизацией. Статический анализ кода на PHP уже несколько лет набирает популярность, сказывается здесь и движение самого языка в сторону более строгой типизации. Но мы опасались, что без предварительной подготовки кода пользы от него мало. Аннотировать типами весь код в реальных бизнес-условиях тоже нереально. Сильно медлить с внедрением в рабочий процесс тоже нельзя: чем дальше, тем сложнее что-то кардинально улучшать. Поэтому нужно было оперативно запускаться, чем-то пожертвовав.

Сейчас множество всяких наборов данных в разных областях выкладывают под лицензией OpenData, то есть скачивай и используй (но не искажай). Но, конечно же, раз эти данные открытые, то все их создают как им угодно. Отсюда — множество проблем при обработке, начиная с получения и заканчивая интерпретацией. Мы работаем с открытыми данными последние пять лет, и за весь опыт работы накопилось немало интересных случаев. Под катом — основные проблемы и примеры ребусов, путешествий во времени и прочей чертовщины, с которой мы ежедневно боремся.