Привет всем!

Я — Ипатов Александр, backend‑разработчик в ГК Юзтех. Сегодня хочу поделиться своим опытом в интересном проекте, связанном с миграцией БД MsSQL на PostgreSQL в разрезе оптимизации хранимых процедур и функций (далее — хранимых процедур, так как процесс оптимизации не сильно завязан на том, что именно имеем на выходе).

Актуальность проектов, связанных с миграциями серверов и баз данных с зарубежных платных продуктов (Microsoft, Oracle) на аналогичные отечественные или зарубежные open‑source решения (в разрезе статьи будем рассматривать Postgres) в 2024 году очень велика. Те решения, которые были реализованы и поддерживались на протяжении 5–10 лет, потребовалось практически в формате «пожара» переносить на аналогичные. А бизнес, который привык к уже полностью сформированным и отработанным рабочим процессам, не готов к потере эффективности и, как следствие, потере клиентов сервисов, заказов и бизнес‑метрик.

В одном из таких проектов мне удалось поучаствовать. Из начальных условий: проект по переносу БД из MsSQL начался примерно 3 года назад.

На самом деле, проект был более обширный — перенос монолитного сервиса на микросервисы, в том числе, как один из элементов — перенос БД.

Хочется отметить, что перенос схем, таблиц, индексов и других элементов базы данных прошел относительно спокойно. Чего не скажешь о переносе хранимых процедур. Язык T‑SQL, на котором пишутся хранимые процедуры в MsSQL, конечно же имеет отличия от PL/pgSQL, который используется в PostgreSQL. В связи с чем, непосредственно миграция хранимых процедур заняла много времени: точное число хранимых процедур я не назову, но порядок — около 800 штук (среди которых 500 стали работать хуже после миграции, их то и предстояло оптимизировать).

Елизавета Акманова, старший аналитик ГК Юзтех, снова на связи. Сегодня у меня в планах обсудить, зачем и где нужны API Gateway. Для этого верхнеуровнево пройдём по архитектуре этого паттерна, рассмотрим решаемые задачи. Ключевой вопрос на сегодня: Когда стоит использовать эту технологию? Это полезный инструмент но, увы, не всегда.

Всем привет! Меня зовут Лида Анисимова, я backend разработчик продукта — платформы мотивации сотрудников Тил Эйчар. В этой статье хочу рассказать о нашем опыте реализации push-уведомлений. Если вы, как и я полгода назад, ничего не знаете о том, как работают push-уведомления — эта статья для вас. Расскажу о том, с какими трудностями мы столкнулись, покажу, как отправить первый push и какие данные вам могут понадобиться.

Всем привет! На связи снова Алина — аналитик продукта Тил Эйчар. 

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

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

Введение

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

Привет, меня зовут Нина Полторакова, я ведущий тестировщик в ГК Юзтех. 

На данный момент мы с командой занимаемся разработкой и поддержкой ИТ-решений по направлению Life — страхование жизни.

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

Вместо вступления

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

Да у вас, голубчик, аддендум

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

Аддендумы, ИСЖ, периоды охлаждения, полупроводки, периоды ответственности, КВ структуры, андеррайтинги, бррр, тут бы с тестированием разобраться сначала! 

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

Всем привет! С вами снова я, Елизавета Акманова, старший аналитик в ГК Юзтех. Сегодня хочу поделиться, почему и как мы с командой discovery перешли на описание API с помощью OpenAPI, и при чём здесь системный дизайн. 

Привет, я Саша. В продуктовом дизайне уже более 6 лет. Успел поработать как в небольших стартапах, так и в крупных продуктах в B2B и B2C сегментах, а ещё я веду канал о дизайне. 

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

Всем привет! Меня зовут Алина. Я работаю аналитиком более 3-х лет, сейчас –  в ГК Юзтех с продуктом Тил Эйчар. Это программа лояльности и мотивации персонала, которая позволяет снизить стоимость привлечения новых сотрудников и удержать текущих сотрудников.

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

Введение

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

Всех приветствую в своей новой статье! Меня зовут Елизавета Акманова. С некоторыми читателями уже знакомы с предыдущих тем, для новых представлюсь: я системный/бизнес аналитик с опытом работы 3 года. Было много проектов разного уровня и сложности: начиная с монолитов в команде из 4 человек, заканчивая 50+ микросервисами из 90 человек. Но все проекты объединяло одно: API. Абсолютно в каждом присутствовал этот термин, приходилось работать с проектированием API, и сегодня я хотела бы рассказать про подходы, как это можно делать и подчеркнуть особенно метод API-first. 

Всем привет! Меня зовут Александр Остапец, дизайнер продуктов в ГК Юзтех.

В продуктовом дизайне — 4,5 года. За это время разработал дизайн продуктов в сфере B2B, B2C и Enterprise. В статье я поделюсь своим опытом взаимодействия продуктового дизайнера с аналитиком, разработчиком, тестировщиком и продактом, и дам рекомендации по улучшению процессов. Статья будет полезна дизайнерам продуктов, и тем, кто ставит задачи продуктовым дизайнерам.

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

Если это Senior Full Stack разработчик с опытом администрирования Linux, то установка и настройка конфигов Nginx, PHP-fpm, MariaDB для него не будут проблемой (а может и с Docker даже знаком?). 

Разработчик Middle уровня (особенно без опыта с backend) возможно пользуется одним из готовых решений под Windows/MacOS.

Junior верстальщик, в свою очередь, раньше не запускал приложение работающее на PHP на своем компьютере вообще, и вот-вот попробует в первый раз.

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

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

Всем привет! Меня зовут Елизавета Акманова, и я рада приветствовать вас в моей новой статье. Если вы помните, моя первая публикация касалась пяти ключевых трендов в бизнес-анализе. Сегодня я приглашаю вас отправиться в увлекательное путешествие под названием «Рекомендации по моделированию данных».

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

Первое, с чего хочется начать: что такое модель данных и база данных? Зачем их разделяют и в чем их принципиальное отличие? 

Всем привет! Меня зовут Виктория Исаева, я старший специалист по тестированию ГК Юзтех. В этой статье я хочу поделиться нашим опытом внедрения фреймворка Karate для автоматизации ручного тестирования на проекте.

Здравствуйте! Меня зовут Елизавета Акманова, я старший аналитик в ГК Юзтех. Начав свой путь в IT в 2020 году, я претерпела значительное развитие — от участия в микропроектах в небольших группах из 4 человек до работы над сложными, высоконагруженными приложениями с ежедневным участием до 90 специалистов. 

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