Меня зовут Екатерина, я IT-архитектор в ML-команде SimbirSoft, специализируюсь на темах по обработке естественного языка. Сегодня мы обсудим особенности решения задач распознавания речи. Проверим наши предположения на собственных аудиоданных, которые будем переводить из акустического сигнала в текст тремя передовыми коммерческими системами: Yandex SpeechKit, SaluteSpeech от Сбера и SpeechFlow от Bluepulse. Статья будет полезна тем, кто интересуется тенденциями развития машинного обучения или хочет присмотреться к возможностям и уязвимым местам существующих решений для их внедрения в бизнес-приложения.

После появления на рынке API для беседы с ChatGPT 3.5 каждый второй заказчик решения на основе машинного обучения (ML) хочет внедрить у себя ИИ, который может красиво и содержательно общаться на русском языке.

Меня зовут Екатерина, я IT-архитектор команды SimbirSoft, специалист по ML и поклонница всего, что связано с обработкой текстов на естественном языке (NLP). Сегодня будем разбираться в тонкостях решения одной из популярных на рынке задач – автоматического составления аннотаций. Для эксперимента мы использовали две GPT-подобных модели, «заточенных» на русский язык:  GigaChat и YandexGPT. Заявленный потенциал систем тестировали на текстах трёх жанров: научном, научно-популярном и художественном. Что из этого получилось, расскажем в статье.

Материал будет полезен тем, кто следит за тенденциями развития машинного обучения на рынке и в целом интересуется внедрением больших языковых моделей (LLM) в ML-проектах – для оценки их возможностей «из коробки».

Привет, Хабр! С вами Валентин, архитектор направления Backend компании SimbirSoft. В данной статье мы с коллегами поделимся опытом реализации большого и сложного проекта с микросервисной архитектурой, а также поговорим о роли архитектора в таких проектах. 

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

Привет, Habr! С вами Антон, руководитель Архитектурного комитета компании SimbirSoft. Мы продолжаем цикл статей, посвященных практическому внедрению подхода Design API First в разработку наших проектов. Настало время поделиться практическим опытом использования спецификаций OpenAPI для кодогенерации контрактов backend.

Дисклеймер: Материал публикации в первую очередь передает практический опыт работы системных аналитиков и практикующих архитекторов при интеграции Design API First с непосредственным процессом разработки. Некоторые технические детали реализации будут описаны не полностью.

На связи снова Архитектурный комитет компании SimbirSoft, и мы продолжаем наш цикл статей, посвященных Design API First. Ранее мы уже писали о том, что представляет собой этот подход, приводили пример спецификации для сервиса аутентификации и рассказывали, как мы интегрируем этот паттерн в наш конвейер разработки.

Сегодня мы немного отвлечемся от бэкенда и разберем автоматизацию одной из рутинных задач на стороне frontend-разработки. А именно описание моделей интерфейсов для взаимодействия фронта с беком, а также написание API-сервисов, в которых фиксируются endpoints, методы запросов и формат передачи данных (query-параметры, заголовки, тело).

Всем привет! Продолжаем наш цикл статей о внедрении подхода Design API First на проектах нашей компании. Ранее мы рассмотрели использование этого подхода, описали плюсы и минусы, узнали, как на практике выглядит проектирование API на примере сервиса аутентификации. Сегодня расскажем о том, как мы встраиваем Design API First в наш конвейер разработки, подробно остановимся на инструментах, помогающих с технической точки зрения организовать этот процесс. Объясним, как реагировать на изменения требований и обеспечивать версионность, а также что использовать для мокирования данных. Рассмотрим различные варианты применения: для нового проекта, для существующего проекта (где изначально был Code First).

4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений

5 часть: Design API First. Кодогенерация Roslyn

Привет, Хабр! На связи Антон, руководитель Архитектурного комитета компании SimbirSoft. Вместе с моими коллегами в прошлой статье мы рассказали про особенности применения подхода Design API First. Сегодня покажем, как реализуется этот подход на практике на примере сервиса аутентификации пользователей.

Есть и продолжение, 3 часть: Интеграция паттерна Design API First в конвейер разработки ПО: наш опыт

4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений

5 часть: Design API First. Кодогенерация Roslyn

За окном 2023 год, а среди разработчиков только и разговоров, что про микросервисы да API First. Несмотря на то, что эти темы не новы, похоже, что их актуальность даже набирает обороты.

Про микросервисы уже много написано и теоретического и практического. Есть у этого подхода и свои евангелисты (Microservice Architecture) :) В целом это тема достаточно холиварная, особенно при крайних точках зрения. Сегодня мы ее отложим, но обязательно вернемся в контексте темы этой статьи. Конечно, это будет не менее обсуждаемая история, посвященная методологии API First и программным интерфейсам (прежде всего, web, но не только) при проектировании и разработке современных информационных систем :)

Меня зовут Антон, я руководитель Архитектурного комитета в компании SimbirSoft. Мы используем подход API First для проектов самой разной направленности, где есть несколько команд разработки (как минимум Backend и Frontend), а также при высокой неопределенности на этапе реализации (быстроменяющиеся требования и цели, параллельные процессы проектирования и реализации, высокие запросы к TTM и так далее).

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

Этот материал открывает цикл статей, посвященных практическому внедрению методологии API First в разработку наших команд. Если быть точным, то мы отдаем предпочтение «младшему брату» API First, практикующему  проектирование (design), — известному как Design API First. Чтобы избежать путаницы, далее термин «API First» будет обозначать подход к разработке ПО, а термины «Design API First» и «Design First» – проектирование ПО в рамках подхода API First.

2 часть: Как мы внедряли Design API First. Показываем на примере сервиса аутентификации

3 часть: Интеграция паттерна Design API First в конвейер разработки ПО: наш опыт

4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений

5 часть: Design API First. Кодогенерация Roslyn

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

Я Антон, руководитель Архитектурного комитета SimbirSoft, и в этой статье я расскажу о полученном опыте с точки зрения технологических особенностей реализации frontend-части. Рассмотрим большое количество нестандартных элементов игрового интерфейса и общие требования и ограничения к frontеnd-части приложения (архитектура, model, service, store и т.д.). Поделюсь, как реализовали:

— набор визуальных элементов приложения;

— элементы пагинации;

— сложный компонент на примере кнопки;

— составной компонент на примере g-card-list;

— анимацию.

Привет, Хабр! Меня зовут Влад, я frontend-разработчик в SimbirSoft. Я часто задумывался, почему на проектах, где используется Node.js (в частности Nuxt.js и Next.js — фреймворки на базе Vue и React), мы каждый раз, словно по шаблону дополнительно используем еще одну прослойку бэка —  PHP, Java, C# или другой язык программирования, к примеру, «неродной» JavaScript. И тогда я с головой погрузился в анализ ситуации по работе с популярными системами управления базами данных (СУБД), файлами, изображениями и другими естественными потребностями современного проекта. 

Привет! Меня зовут Алексей. Я занимаюсь проектированием фронтенд-составляющей ИТ-систем в архитектурном комитете SimbirSoft. Последние два-три года во фронтенд-сообществе активно обсуждается и используется термин «микрофронтенд» (далее МФ). Разные компании делятся своими подходами к организации подобного архитектурного решения, но до сих пор в Сети мало описания проблематики, которую призваны решить МФ-ы, критерии их применимости и ограничения в использовании. В этой статье постарался сравнить разные способы организации МФ-ов, а также сформировать рекомендации, где какой подход использовать.

Материал может быть полезен как аналитикам и командам разработки при проектировании архитектуры на проекте и закладки процессов, так и владельцам продуктов, поскольку внедрение МФ-ов может дать более управляемую разработку.

Одна из проблем использования языков объектно-ориентированного программирования (ООП) и баз данных в сложности их согласования между собой. Знание языка структурированных запросов (SQL) и умение писать запросы позволяют взаимодействовать с БД напрямую. Но использование «чистого» SQL может занять довольно много времени, предъявляя повышенные требования к навыкам специалиста.

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

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

Привет! В прошлой статье мы рассказывали о 7 из 14 кейсов, с которыми столкнулись только за последний год, работая в саппорте на зарубежном проекте. Напомним, уже 9 лет мы сотрудничаем с клиентом из Великобритании, который предоставляет ПО для госпиталей и обеспечивает целый ряд шагов бизнес-процесса. Предысторию проекта и то, как работа в саппорте помогает развивать IT-продукт и повышать квалификацию, описали здесь. 

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

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

Продолжаем делиться опытом нашего коллеги Алексея, который после 7 лет программирования на зарубежном проекте неожиданно для себя возглавил службу поддержки третьей линии. В этой статье расскажем про первые семь кейсов, которые были найдены и устранены только за последний год.

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

...Был отличный зимний день, ничего не предвещало беды. Внезапно данные от одного госпиталя перестали приходить. Прошло 5 минут, мы были спокойны – ранее такое случалось несколько раз по 10-15 минут из-за проблем в сети госпиталя. 

10 минут. Начинаем испытывать легкое беспокойство, на всякий случай откладываем задачи, чтобы быть готовыми срочно переключиться на проблему. Госпиталь молчит.

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

Ценность IT-специалиста зачастую повышается по мере того, как он на своем проекте осваивает не только программирование, но и смежные области – аналитику, основы работы с большими данными, работу на саппорте, управление командами. Об этом погружении “в глубину IT” рассказывает Алексей – один из наших опытных программистов. После 7 лет разработки он возглавил саппорт на своем проекте и готов поделиться опытом, к чему это привело.

“Как говорится, если вы хотите быть лучшим, вам надо войти или в 1% лучших в определенной области, или в 15% лучших в двух смежных областях, или в 30% лучших в трех смежных областях. При этом усилия, затрачиваемые на то, чтобы стать лучшим в конкретной области, возрастают по экспоненте”, - отмечает наш коллега.