В Naumen множество команд: одни развивают уже существующие продукты, а другие — создают новые. Сегодня мы расскажем про Naumen Project Ruler. Команду сформировали в прошлом году, но им уже удалось завершить несколько проектов и создать уникальную атмосферу внутри. Игорь Путин, владелец продукта и тимлид Naumen Project Ruler, поделился, как живёт стартап внутри компании.

Меня зовут Денис, я тимлид команды R&D в Naumen Service Managment Platform. 

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

В этой статье я поделюсь опытом своей команды. Расскажу, как, используя maven плагины, чуточку Groovy и очень много Jenkins, наш сервис выжил в многомодульном монолите с тысячей внешних зависимостей. 

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

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

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

На сегодняшний день существует несколько популярных подходов к созданию ПО, которые определяют как работу вендоров, так и развитие ИТ-индустрии в целом. Первый — классическая разработка, которая предполагает работу с нуля над определенным программным продуктом для конкретного заказчика. Второй — low-code платформы и их производные, в основе которых лежит принцип ухода от парадигмы «ручного труда» за счет оптимизации бизнес-процессов на уровне платформы. 

Заметным трендом сейчас является рост популярности no- и low-code подходов к разработке ПО. Подобные изменения в свое время пережили традиционные рынки вместе с появлением конвейерного производства, которое сделало доступным для массовой аудитории не только товары, но и оборудование. Похожий принцип заложен и в эволюции вендорных компаний. Причем в последние годы этот процесс заметно ускорился — благодаря цифровизации бизнеса и росту доли заказов с неизбежно похожими параметрами. 

Между тем, до конца разобраться в специфике low-code до сих пор не получается не только у клиентов, но даже у ИТ-специалистов. Например, часть профессионального сообщества опасается, что развитие low-code приведет к отказу от дорогой high-code разработки. В свою очередь клиенты, которые привыкли к high-code, воспринимают low-code продукты как инструмент для создания эскиза информационной системы. Рассмотрим особенности разных подходов к разработке ПО и критерии, по которым их выбирают вендоры и заказчики.

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

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

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

Меня зовут Саша и я аналитик SMP Mobile. Это мобильное приложение, с помощью которого коллеги могут, например, зарегистрировать заявку по QR коду в офисе и не только.

В жизни каждого начинающего аналитика рано или поздно наступает момент, когда ему выпадает первая большая задача. Конечно, возникает масса сложностей и аналитик совершает ошибки. Сегодня расскажу про свой опыт решения большой аналитической задачи на примере чек‑листов в SMP.

Большая часть ИТ-конференций — это сборник best-practices, которые призваны не только научить чему-либо, но и показать компанию спикера с выгодной стороны. Также спикеры сталкиваются с NDA — не всеми данными можно делиться, поэтому доказать эффективность предложенных инструментов непросто. В таких условиях сложно полностью перенять опыт коллег и досконально разобраться в вопросе. Но что, если и спикеры, и участники — это сотрудники одной компании? Рамки секретности снимаются и обмен опытом становится более прикладным.

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

Меня зовут Андрей Аркаев. Я занимаюсь разработкой на Java с 2002 года. Сейчас развиваю бизнес-систему для контактных центров в Naumen. Как и многие другие бизнес-системы мы используем ORM. В статье поговорим о Hibernate, так как эта библиотека распространена для Java.

Наш продукт развивается более 15 лет и накопил в себе много кода, в том числе легаси. Мы начинали с Hibernate версии 3 и прошли через 3 больших версии.

Если посмотреть статистику привязки к версиям Hibernate в Maven Central, то окажется, что к версии 5.5 привязано 400 проектов, к 5.6 — 1200 проектов, а к свеженькой 6.1 — буквально 180 проектов. То есть 6.1 еще только набирает обороты. Уже появляются первые доклады, как всё хорошо и радужно при обновлении на новую версию, однако реальность обычно другая. Поэтому интересно разобраться, какие есть сложности и проблемы, и как переходить на эту версию.

Сделаю ремарку: эта статья не рассказывает обо всех изменениях, а только о самом интересном и важном для меня и моих проектов.

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

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

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

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