Этим постом я запускаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В программе: рассказ об основах SQL, возможностях простых и сложных SELECT, анализ производительности запросов, разбор [не]эффективного применения индексов и особенностей работы транзакций и блокировок в этой СУБД.

Курс не претендует на лавры "войти в айти", поэтому подразумевает наличие у слушателя опыта программирования или работы с другими СУБД, и, главное, желания самостоятельно изучать тему работы с PostgreSQL глубже.

Для тех, кому комфортнее смотреть и слушать, а не читать - доступна видеозапись и слайды.

Самый больной вопрос для любого разработчика, которому приходится вычитывать данные из базы: "Как сделать мой запрос быстрее?". Классический ответ - необходимо создать подходящий индекс. Но куда именно его стоит "накатывать", да и как вообще он должен выглядеть?..

Мы научили наш сервис визуализации планов PostgreSQL отвечать на эти вопросы, и под катом расскажем, чем именно он руководствуется в своих рекомендациях.

Привет! Меня зовут Виктория Кабыткина, я работаю старшим системным аналитиком в компании Lamoda. По своему опыту как в банковской сфере, так и в сфере e-commerce, могу заметить, что во многих компаниях существует тенденция избавляться от монолита и переходить на микросервисную архитектуру. 

Тенденция популярна и заставляет задуматься над множеством вопросов. А нужен ли на таких проектах бизнес-аналитик? А системный? А если все-таки нужен, то чем он там занимается? Какие задачи он решает? Полезен ли команде? 

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

• Многоуровневая архитектура;
• «Клиент-сервер»;
• «Каналы и фильтры»;
• «SOA»;
• «Издатель-подписчик»;
• «Общие данные»;
• «Одноранговая сеть»;
• «Брокер сервисов».

Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес‑аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции, требования, и все, что связано с проектированием систем.

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

API-First — один из популярных подходов к проектированию серверных приложений. Для обеспечения этого подхода создано множество программных продуктов. Однако сложно найти продукт, который поможет реализовать этот подход для серверных приложений, использующих брокеры сообщений в качестве средства интеграции —  такие, как Apache Kafka, RabbitMQ, Apache ActiveMQ. Мы решили это исправить и представляем вам свое решение AxenAPI.

Привет, Хабр! Трендом в ИТ стало расширение объема знаний и навыков за счет смежных компетенций. К примеру, углубленное владение инструментарием REST API, которое обычно ассоциируют с разработчиками, может быть и частью работы системного аналитика. Эта статья — набор практических задач по REST API, специально подготовленных для системных аналитиков с высоким уровнем грейда.

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

Этой статьёй я открою серию материалов про управление требованиями на разных этапах проекта.  Уже больше 10 лет я работаю в IT и успела побывать бизнес аналитиком, системным аналитиком и руководителем проектов. Также я выступаю в роли ревьюера на курсе «Системный аналитик». 

Начинающим аналитикам бывает не просто разобраться в разных подходах к документированию  требований и множестве нотаций моделирования. У кого-то даже проскальзывают сомнения, а нужно ли все это знать или можно просто изучить формат описания user story? Я попробую развеять эти сомнения на примере учебного проекта.

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

Привет, Хабр! Я Оксана Нечитайлова, руководитель отдела сервисного дизайна продуктов в YADRO. Руковожу различными командами уже более 17 лет и за это время поняла: многие недооценивают навык формулирования правильных вопросов. Большинство специалистов уверены, что это некое «врожденное» умение. Но в реальности рабочих задач не каждый может так формулировать вопросы, чтобы получать на них полезные ответы.

Умение правильно задавать вопросы — это навык, который можно развить. И нужен он не только менеджерам и тимлидам, а всем, потому что мы задаем много вопросов по работе каждый день.

В статье расскажу:

• какие виды вопросов бывают и какие ошибки в них допускают чаще всего,

• какие практики повысят навык формулирования вопросов,

• как не вестись на манипулятивные вопросы и избегать их в своей речи.

Привет, Хабр! Меня зовут Виталий Киреев, я руководитель R&D в SpaceWeb. В статье расскажу, как мы внедрили JSON-RPC в разработку SpaceWeb и объясню, почему выбрали именно эту технологию, а не RESTful API. А ещё покажу реальные кейсы и метрики использования технологии JSON-RPC.

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

На этот счёт есть рассуждения на тему полноты, непротиворечивости, реализуемости, понятности для команды, согласованности со стейкхолдерами. Все необходимые артефакты для разработки, конечно, должны быть собраны и правильно оформлены. Фактически, это рассуждения о качестве требований: требования готовы, когда они удовлетворяют критериям готовности (критериям качества).

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В этой лекции мы узнаем, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. Разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош, чем отличается Materialize от Memoize, а Gather Merge от "просто" Gather.

Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2) и слайды.

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

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

При работе с современными веб-приложениями реального времени незаменима возможность отправлять события с сервера на клиент. Именно этой необходимостью продиктовано то, что за годы работы было изобретено несколько методов для этой цели, каждый с собственным набором достоинств и недостатков. Первоначально единственным вариантом был длинный опрос. Затем в качестве альтернативы появились веб-сокеты — более надёжное решение для двунаправленной коммуникации. Вслед за веб-сокетами появились события, отправляемые сервером (SSE), более простой метод, обеспечивающий однонаправленную связь от сервера к клиенту. Забегая вперёд, сейчас разрабатывается ещё и протокол WebTransport, который может тем более изменить ландшафт этой области, обеспечивая более эффективный и гибкий подход, располагающий к масштабированию. В некоторых нишевых случаях можно присмотреться и к технологии WebRTC, предназначенной для работы с событиями в направлении сервер-клиент.

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

Это глава 21 моей книги «API». v2 будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

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

Системный аналитик. Краткий гайд по профессии. Часть 1.

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

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

Статей о селектах хватает, попробуем про апдейты. "ТОП-100" вопросов не обещаю - тут бы с одним разобраться. Разработчиков OLTP-систем под MS SQL Server и кандидатов на подобные вакансии приглашаю под кат.

Код на T-SQL, и он идеален. Атомарности нет, целостность вернём ручными апдейтами, изоляция с дюрабилити только мешают. Программируем без оглядки на ACID, который жив лишь в статье википедии.