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

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 лет.

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

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

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

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

За многие годы моей карьеры я столкнулся с множеством вызовов и уникальных ситуаций, которые позволили мне глубоко погрузиться в мир гибкого управления проектами. Думаю, статья будет полезна РМ’ам всех уровней.

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

Гибкость в управлении проектами – это способность адаптироваться к меняющимся условиям и требованиям без потери эффективности. Использование правильных инструментов и техник может значительно улучшить адаптивность команд и проектов.

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

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

Я поделюсь своими впечатлениями от участия в этом формате, рассмотрю проблемные моменты и предложу, что с ними можно сделать.

Ory Kratos - современный cloud native сервер идентификации с поддержкой PassKeys, MFA, FIDO2, TOTP, WebAuthn, с возможностью управления профилями, схемами пользователей, входом через внешние сервисы, регистрацией, восстановлением аккаунта, с поддержкой passwordless входа. Написан на Go, headless, API-first.

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

Недавно меня спросили, какие фреймворки обратной связи я знаю. Я растерялся и сходу вспомнил только бутерброд, а также то, что хвалить нужно публично, а ругать — приватно. Это заинтриговало меня: какие же существуют практики для правильной обратной связи?

Давайте рассмотрим гипотетическую ситуацию: коллега принёс в офис кота, и тот поцарапал ваш ноутбук. Как правильно дать обратную связь, используя разные фреймворки?

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

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