Легкий и простой способ настроить бесплатную синхронизацию 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{}
}

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

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

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

Салют!

Совсем недавно я выкладывал статью "Как пройти собеседование на позицию системного аналитика в 2024 году". Там были вскользь упомянуты вопросы, которые могут встретиться. Теперь публикую полный перечень наиболее популярных вопросов из теоретической секции.

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

Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала. 

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

Вероятно, вы слышали о планировщике Go раньше, но насколько хорошо мы знает о том как он работает? Как он связывает горутины с потоками?

Разберем по очереди операции, которые выполняет планировщик.

В последнее время наблюдаю тенденцию увеличения обязанностей системного аналитика, и, кажется, в явном виде об этом никто не говорит. Наоборот, смотря профессиональные чаты и общаясь с коллегами, я в большинстве случаев считываю превалирующую мысль, что системный аналитик — это специалист, который должен и может всё: и бизнес-цели по SMART поставить, и базу данных разработать. Мне как системному аналитику видится в такой тенденции будущая проблема моей профессии: знания и достижения, которые я приобретаю сейчас, будут обнуляться на каждом новом проекте, потому что там от меня будут ожидать что-то совсем другое. В этой статье пробую разобраться почему системный анализ как подход к решению задач превратился в должность “человек-оркестр”?

Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

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

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

Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.

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