Представьте ситуацию: на демо клиент испытывает VR-тренажер «Работы на высоте».

Легкий ветерок, стальной пролет, панорама города. Красота. Клиент поднимается по лестнице, останавливается на краю и с восхищением говорит: «Как круто вы сделали, что от вида вниз у меня голова закружилась!» Мы переглядываемся. Потому что «круто» — это не мы сделали. Это заслуга плохой оптимизации раннего прототипа.

Пока персонаж карабкался, движок героически пытался «на лету» подгрузить пачку тяжелых моделей. FPS просел, рендер начал задыхаться, и вестибулярка клиента объявила забастовку. Иммерсивность —10/10, комфорт — где-то в районе отрицательных значений. Если голова кружится, это должно быть запланировано геймдизайнером, а не видеокартой. 

Привет, я backend-разработчик SimbirSoft Андрей. В этой статье разберем, как сделать так, чтобы VR-проекты на Unity работали стабильно и были дружелюбны к вестибулярному аппарату игрока.

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

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

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

Привет, Хабр! Я Иван, backend-разработчик IT-компании SimbirSoft. И в этой статье разберемся, почему геймификация полезна для обучения сотрудников.

Сетевой протокол — это набор правил, которые определяют принципы взаимодействия устройств в сети. Однако, на практике «идеального» соблюдения стандартов не бывает: разработчики зачастую отступают от рекомендаций. Кто-то не влезает в запланированный канал связи (например, эта проблема особенно актуальна для устройств «умного дома» без постоянного питания). Кто-то таким образом пытается скрыть информацию от злоумышленников или затруднить реверс-инжиниринг их систем (чтобы привязать пользователя к оплате лицензии). А кто-то просто считает, что может сделать лучше имеющихся аналогов. Собственный проприетарный протокол иногда даёт выигрыш по пропускной способности или задержкам, но при интеграции с другими системами и устройствами, это может создать серьёзные проблемы для сетевых инженеров. 

Представьте, что ваша система — идеально отлаженный механизм; и вдруг нужно заменить одну шестерёнку, а разработчик уволился, лицензия отозвана (бывает, что купленное вами может не принадлежать вам :), исходники потеряны или устройство пришло в негодность. В таких случаях приходится восстанавливать поведение протокола почти «с нуля».

Привет, Хабр! Меня зовут Виталий, я python-разработчик в SimbirSoft. Цель этой статьи — дать практическое введение в реверс-инжиниринг сетевого трафика и анализ протоколов передачи данных. Сразу уточню: здесь не будет взлома или обхода защиты — я уважаю интеллектуальную собственность и законодательство. Материал посвящён техническим приёмам, которые будут полезны инженерам и специалистам по интеграции систем. Статья будет полезна разработчикам, аналитикам, менеджерам, которые работают с указанными решениями.

Всем привет! Меня зовут Николай, я DBA-разработчик SimbirSoft. Если вам приходилось иметь дело с табличной моделью данных SQL Server Analysis Services (SSAS), то вы наверняка знаете, что на сервере она работает только в режиме In-Memory и использует под свои процессы выделенную часть оперативной памяти. А когда памяти недостаточно для нормальной работы, то возникает системное сообщение о ее нехватке.

В этой статье я кратко рассмотрел причины и общие стратегии по решению данной проблемы, а также рассказал о своем опыте на примере табличной модели объемом около 100 ГБ на MS SQL Server 2019 Ent.  

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

Есть несколько способов решения. Они зависят от проблематики, требований, доменной области, пожеланий заказчика и т.д. Есть несколько возможных вариантов реализации.

Меня зовут Екатерина, я 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% лучших в трех смежных областях. При этом усилия, затрачиваемые на то, чтобы стать лучшим в конкретной области, возрастают по экспоненте”, - отмечает наш коллега.