База Open Street Map (OSM) является открытым ресурсом, пополняемым добровольцами. Она широко используется в проектах, где нужно отобразить что-либо на карте. Встаёт вопрос - насколько данные в ней полные и корректные?

Мы попробуем ответить на него для объектов типа "строение" (дом) на территории России. В этом нам поможет база объектов ГАР ФИАС, которая также содержит объекты такого типа, и её с некоторыми оговорками можно брать за эталонный уровень полноты. С оговорками - потому что каждый месяц в ней появляются новые объекты. На данный момент в ней около 32 млн строений (не считая гаражей, земельных участков и устаревших объектов).

Объекты ГАР ФИАС не содержат координат GPS, но есть ещё один открытый ресурс - Публичная кадастровая карта Росреестра. К сожалению, она не даёт выгружать данные целиком, как предыдущие базы, а предоставляет только API, по которому можно извлекать один объект за раз. Но зато она для многих из них содержит GPS, так что можно их сопоставить с GPS от OSM.

Забегая вперёд, озвучим результат: OSM содержит около 24% от всех домов ГАР, ПКК - около 21%, пересечение OSM с ПКК - 6% и разница координат несущественная.

Для получения результата использовался движок нормализации адресов Pullenti Address.

Давайте поговорим про найм. Я даже не представляю, сколько человек я собеседовала за свою карьеру.
И знаете, что каждый раз удивляет? — Смысл вопросов.
Меня иногда ставят в тупик вопросы, которые задают на собеседованиях. Так как многие вопросы не раскрывают специалиста!
И я хочу предложить вам расширить превычные темы вопросов еще четырьмя блоками, которые мне помогают в поиске игроков в команду!

В последние годы Китай продемонстрировал поразительный технологический скачок, создав ИИ-инструменты, которые не просто конкурируют с западными аналогами, но и предлагают уникальные решения, меняющие правила игры. От распределённых систем обработки данных до инновационных моделей естественного языка — китайские разработчики научились сочетать скорость, масштаб, точность и экономию, создавая продукты, которые уже обходят западные аналоги. Я собрал топ самых впечатляющих китайских ИИшек, которыми лично сам пользуюсь. Осторожно! Статья для тех, кто просто не хочет потерять ИНТЕРЕСНЫЕ ССЫЛКИ. Подробнее о каждой нейросети— далее в статье.

Привет! Меня зовут Олег Кретинин, и я разработчик в команде общих компонентов в Яндекс Еде. Сегодня я расскажу о том, как мы смогли успешно снять нагрузку с нашей базы данных, а также уменьшить её размер.

Помимо сервисов, написанных на C++, Go и Python, у нас есть монолит, он же «кора», на PHP, который всё ещё представляет огромную кодовую базу, хранит кучу логики и предоставляет данные по API для 120 сервисов.

После обновления фреймворка и версии PHP мы принялись за решение другой проблемы, которая всё чаще и чаще давала о себе знать. В тот период у нас возросло количество инцидентов, связанных с базой данных, и нам нужно было что‑то придумать, чтобы стабилизировать проект максимально быстро. Случалось, что всё сыпалось во время праздничных дней, когда количество заказов увеличивалось на 30–40%, или во время разовых массовых операций, например когда однажды в большую сеть ресторанов добавлялся бесплатный соус к каждой позиции меню.

Давным‑давно, когда мир ML состоял из бустингов, линейных моделей и статистических подходов, перед нашей командой API Яндекс Карт стояла задача сделать качественный Геокодер. Это алгоритм, который конвертирует текстовые запросы пользователей в поисковой строке карт в координаты и обратно. Он нужен, когда люди вводят адреса с ошибками, опечатками или народными наименованиями, например «Мяснитская 8». Геокодер должен понять, что имелось в виду «улица Мясницкая, дом 8/2», и вернуть на карте отметку с точной локацией и координатами.

Разработанный для России Геокодер отлично справлялся, но мы хотели найти способ быстро адаптировать это решение к адресным системам других стран. Технологические ограничения не позволяли быстро адаптировать решение, поскольку для каждой страны требовалась разработка собственных правил геокодирования, которые бы учитывали различия и языковые особенности. Однако появление и развитие алгоритмов deep learning открыло новые горизонты: методы active learning, аугментации данных и contrastive learning позволяют значительно улучшить итоговое качество геокодирования и учитывать нюансы различных адресных систем.

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

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

Дисклеймер: я не врач и не даю здесь рекомендаций. Названия лекарств привожу не для рекламы, а потому, что мне их выписывал доктор. Основная часть данных получена из личного опыта, консультаций с четырьмя докторами, медицинской литературы и ChatGPT 4o. Лично мои мнения помечены как «думаю, что...».

Итак, что произошло

Десятого декабря у меня был юбилей. Через три дня, в пятницу 13-го (я не верю в приметы) пошли с коллегами в ресторан отмечать событие. Было хорошее настроение и хороший коньяк. Через два часа захотелось в туалет. Струя оказалась тоненькой. Через 15 минут пошел еще раз – она стала еще тоньше, а в очередной поход через еще 15 минут исчезла вовсе. Я подумал, что пора прекращать пить и надо идти домой, ждать когда алкоголь выйдет из крови. Но дома лучше не стало, хотя отрезвел полностью. Я не спал  всю ночь, искал решение в интернете и пробовал что-нибудь сделать – ничто не помогало. Утром в девять я был в больнице, в очереди к урологу. Было уже страшно, что лопнет мочевой пузырь или откажут почки. Когда вошел в кабинет доктора, не смог даже самостоятельно лечь на кушетку из-за резкой боли внизу живота. Доктор быстро вставил мне катетер в уретру и я наконец понял, что такое настоящее счастье, когда услышал звук бурного потока мочи в рядом стоящий тазик.

При переходе от монолитной к микросервисной архитектуре разработчики часто сталкиваются с несколькими проблемами.

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

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

Использование в практике таких паттернов как Strangler Fig Pattern, Parallel Run Pattern, Decorating Collaborator Pattern и Change Data Capture позволяет разработчикам значительно снизить риски и проблемы, возникающие при таком сложном переходе.

Давайте рассмотрим основные концепции этих паттернов.

Привет, Хабр! Go часто называют «языком простоты»: мол, нет лишних фич, легко стартовать, запустил горутину — и вперед! Но в реальности эта «простота» — палка о двух концах. Я собрал самые распространенные (на мой взгляд) антипаттерны в Go, которые приводят к дедлокам, паникам и километрам непонятного кода.

Легкий и простой способ настроить бесплатную синхронизацию Obsidian между всеми своими устройствами.

Меня зовут Сергей Гребенюк, я лидер разработки Sidec (Росреестр). Расскажу, как решили задачу объединения двух топиков с соотношением один ко многим и почему не устроило решение на Kafka-streams (kafka docs) и RocksDB (github). А также о том, как, опираясь на гарантии доставки exactly-once (EOS) (confluent docs), смогли снизить требования к ресурсам в несколько раз.

На иллюстрации показаны два подхода к объединению топиков: с persistent cache и in-memory cache. Мы перейдём от первой схемы ко второй. 

Путь от новичка до CTO долог, извилист и полон сайд-квестов. Можно ли пройти всю миссию в одной компании? Поможет ли карьере докторская диссертация? Или, может быть, проще назначить себя директором в стартапе? Мы в beeline cloud изучили истории нескольких специалистов — среди них как руководители корпораций, так и CTO небольших ИТ-компаний — чтобы разобраться, как выглядит карьера техдира.

Бонус для читателей: в конце статьи мы собрали дайджест книг для ИТ-директоров и сочувствующих тех, кто начинает движение к этой должности.

Вы знаете, что обычные сетевые библиотеки Go начинают «тяжело дышать», если их нагрузить десятками тысяч соединений? Неважно, делали вы HTTP API или свой TCP сервер — дефолтные инструменты вроде net всегда имеют свои лимиты. Тут-то хорош зайдет Netpoll — библиотека, которая позволяет серверам обрабатывать сотни тысяч соединений одновременно и при этом не терять в производительности.

Привет, Хабр и его читатели! 

Меня зовут Дарья Четыркина, я программист SQL в IT-компании «Автомакон». Предлагаю обсудить проблему, которая может «съедать» производительность вашего SQL Server — фрагментация индексов, в конце статьи будут решения этой ситуации. Если вам важно, чтобы SQL Server всегда работал на полную мощность, эта статья — для вас.

Когда дело касается SQL Server, индексы — это ваши верные помощники: они организуют данные так, что сервер может находить нужные записи быстрее, чем обычный поиск. При этом со временем индексы начинают «разваливаться» и создают массу проблем. Фрагментация индексов — невидимый враг, который замедляет запросы, увеличивает нагрузку на сервер и лишает ваш SQL Server той оптимальной скорости, ради которой и создаются индексы. Разберемся, почему возникает фрагментация индекса, как она вредит производительности и что можно с этим сделать.

Всем привет! Меня зовут Саша, я руковожу группой разработки Composer Core в Ozon Tech. В этой статье я расскажу о том, как устроена пользовательская часть одного из ведущих российских маркетплейсов, в развитии которой на момент написания статьи участвуют сотни специалистов из десятков команд. При наличии такого количества людей разрабатывать новую функциональность, не рискуя сломать уже существующую, является достаточно сложной задачей.

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

Продукт, который мы разработали, вряд ли когда-нибудь станет open-source-проектом, так как он слишком зависит от специфики инфраструктуры Ozon Tech. Но основные принципы могут быть полезны при проектировании похожих систем.

Недавно мы опубликовали в блоге перевод статьи о том, как GitHub заменил SourceForge в роли доминирующей платформы для хостинга кода. Но, как справедливо отметил автор оригинала, его мнение основано на открытых источниках и интервью с коллегами. А потом своим ви́дением поделился один из сооснователей GitHub, Скотт Чакон, который «действительно был там». Под катом — перевод его ответной статьи о реальных причинах победы GitHub. 

HADI - это метод проверки гипотез, который состоит из 4-х основных этапов: гипотеза → действие → данные → выводы. Этапы идут последовательно один за другим. Затем цикл повторяется снова.

Из жизни малышей и гигантов

PGlite 0.2

Опенсорсный проект ElectricSQL явил маленькое чудо. Совсем маленькое: сервер PostgreSQL уместился в архив 3МБ.

Сервер сделан как клиентская библиотека TypeScript/JavaScript, PostgreSQL можно запускать в браузере, Node.js и Bun, ничего больше инсталлировать не надо, всё есть. Есть и некий API "live query", для реакции на изменения данных в таблицах. Утверждают, что обычные CRUD-запросы исполняются за 0.3 мс.

Ресурсы:

сайт;

репо;

доки

каталог расширений (22 расширения Postgres, в том числе pgvector, и 1 плагин для PGlite - live);

первые бенчмарки.

Более того: компания Supabase уже запустила сайт postgres.new, построенный поверх PGlite, мол, have fun.

Привет, Хабр! Эта статья для тех, кто хочет понять, когда стоит использовать sync.Map, а когда достаточно обычной map с мьютексом.

В Каруне этот вопрос иногда возникал на код ревью, поэтому такая статья мне показалась полезной. TLDR: sync.Map лучше работает на задачах, где много операций чтения, и ключи достаточно стабильны.

Внутреннее устройство sync.Map

sync.Map — это потокобезопасная реализация мапы в Go, оптимизированная для определенных сценариев использования.

Основная структура sync.Map выглядит примерно так:

type Map struct {
    mu Mutex
    read atomic.Value // readOnly
    dirty map[interface{}]*entry
    misses int
}

type readOnly struct {
    m       map[interface{}]*entry
    amended bool
}

type entry struct {
    p unsafe.Pointer // *interface{}
}

Здесь мы видим несколько ключевых полей:

Привет, Хабр! Меня зовут Александр Бардаш, я главный архитектор интеграционных платформ в МТС. Сегодня расскажу, почему ИТ-архитекторам важно хотя бы иногда всегда читать книги, и поделюсь подборкой для начинающих. Жду вас под катом и в комментариях!