Я лид команды – и хочу идти дальше вверх! Точнее, не уверен, что хочу, но в айтишке надо ведь расти и развиваться, значит, следующая позиция для меня — менеджмент на уровень выше. Или нет?

Как пробиться на новый уровень, если компания нанимает на руководящие позиции извне? На чём фокусироваться? Как перестать скучать по разработке? А может, к ней надо вернуться?

Знакомы такие рассуждения? Тогда эта статья для вас:)

Меня зовут Максим Шульга, я руководитель департамента разработки Документы Онлайн в МойОфис. Наша команда работает с современными стеками: высоконагруженные бэкенды на Java и Python, фронтенд на React и TypeScript и другие.

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

Типичная проблема новичков при изучении языка программирования — они тонут в море учебных материалов. Интернет предлагает тонны статей, курсов и книг по C++, но как выбрать действительно стоящие?

Меня зовут Владислав Столяров, я руководитель команды анализа безопасности продуктов в мультипродуктовой экосистеме МойОфис. Наши решения — Документы Настольные и Документы Онлайн — во многом работают благодаря C++, так что мне есть чем поделиться. В этой статье расскажу, что делать, если вы вдруг решили залететь в плюсы, но уже чувствуете, как накрывает экзистенциальный кризис от обилия информации.

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

Для МойОфис как мультипродуктовой экосистемы со сквозными сценариями — все эти вопросы очень актуальны! Поэтому на прошлой неделе JS-еры, дизайнеры и UX-исследователи нашей и других компаний собрались на митапе под названием Frontend&UX Talks, чтобы обсудить эти и другие проблемы современного веба. Получилось интересно, драйвово и даже сказочно! (и я в прямом смысле этого слова :-))

Под катом расскажем в 7 тезисах, к каким выводам пришли и как именно: поехали!

О фронтенде в 2025-м году мы поняли, что...

Понятный и простой код — куда важнее, чем кажется

Примитивы это сказка! (причем буквально...)

Реактивное программирование актуальное и удобное! Но не для всех...

Следить за CSS обновлениями каждый квартал – базовый минимум

Темизация это нелегко, но есть лазейки!

Редизайны продуктов – это не страшно! (ну почти...)

За сложными интерфейсами – глаз да глаз...

Хоттейк: важная проблема работы с UX – нехватка коллективных процессов. Например, аналитики ставят задачи на реализацию интерфейсов без вовлечения дизайнеров, а команды работают изолированно, перебрасывая этапы по цепочке. Такой подход приводит к потере контекста, нестыковкам и лишним итерациям.

Но есть альтернатива — совместная работа над дизайном и аналитикой с самого начала, включая конкретные этапы исследований (подготовка гайда, интервью и тд). Спойлер: мы выбрали этот вариант:)

Меня зовут Света Самойленко, я старший дизайнер-аналитик пользовательского взаимодействия и лид пользовательских исследований в настольных редакторах МойОфис. Это сложный продукт на кросс-платформенном C++17-ядре (Qt5/QML для десктопов, Kotlin/Swift для мобильных платформ), веб-версия использует TypeScript/React с WASM-компиляцией ядра.

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

Идея этой статьи родилась во время задушевных разговоров на кухне и за утренним кофе с коллегами. Началось все с вопроса: «Что ты сказал бы себе прошлому, чтобы релизы стали легче, а спринты прекраснее?» Конечно, в тот момент я ничего дельного не ответил, но, кажется, наконец‑то сформулировал идеальную фразу: «Настоящий разработчик, Слав, это не тот, кто с сияющим макбуком и вкусным смузи. Разработчик — тот, кто делает то, что нужно сделать. И в легаси покопаться приходится, и memory leak дебажить, а он всё равно делает, потому что так надо».

Привет, Хабр! Меня зовут Вячеслав Чащухин, я — разработчик в МойОфис. Занимаюсь мобильной версией Squadus — цифрового рабочего пространства для совместной работы и деловых коммуникаций.

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

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

В Международный день космоса (21 мая — не путать с 12 апреля, знаменитым Днем космонавтики) мы поговорили с тремя коллегами, которые когда-то изучали орбитальные траектории и даже готовили космонавтов к полетам, а теперь создают цифровую вселенную в МойОфис: мультипродуктовую экосистему со сквозными сценариями. И космический бэкграунд им в этом помогает :)

Скорее ставьте фоном «Белое солнце пустыни» (если вы вдруг не в курсе, то вот откуда пошла эта традиция)...

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

Меня зовут Владимир Ревякин, я старший инженер-программист компании «МойОфис», и вместе с QA-инженером Анной Рукавицыной мы подготовили этот материал, чтобы поделиться опытом реализации функции шаринга данных через графовую базу ArangoDB в рамках разработки платформы «Документы Онлайн». Если коротко — это продукт для совместной работы и хранения документов в рамках единой мультипродуктовой экосистемы.

В российских источниках не так много полезной информации по ArangoDB, и наша задача — исправить это недоразумение. Разберем главные нюансы работы с этой системой БД в разработке и тестировании, вспомним ее плюсы, минусы и потенциальные баги. Текст будет полезен как инженерам любых грейдов, которые связаны с работой над базами данных (сил вам...), так и классическим разработчикам продуктов.

Продакт сегодня – настоящий человек-оркестр из мира IT: он и гипотезы проверит, и бизнес-модель выстроит, и с клиентом общий язык найдет. Понятно, что одной конкретной теоретической базой тут не обойтись: нужны компетенции и знания из разных сфер. И здесь вам помогут книги. Я Катя Ольхова, продакт-менеджер МойОфис Почта и… книжный червь :)

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

Что бы мне почитать, если:

Я продакт на старте карьеры и боюсь, что сил, времени или терпения хватит всего на одну книгу из списка

Нужно детально разобраться, какая бизнес-модель у твоей компании, разрушить ее и построить заново

Хочу понять, как создать продукт, который формирует привычку

Учусь проводить с клиентом качественные интервью: не просто продавать идею, а слышать и понимать потребности собеседника

Необходимо научиться управлять проектами в сжатых сроках

Учусь всегда нанимать нужного человека на горящую позицию

Часто попадаю в конфликтные ситуации на работе и хочу лучше их прорабатывать

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

Меня зовут Катя Орешкова, и я работаю над Mailion — корпоративной почтовой системой от компании МойОфис. Основное ядро продукта написано на Go, но в целом технологический стек включает множество языков и технологий: Go, Java, Python, PHP, C++, C# (бэкенд), а также JavaScript/TypeScript с React (фронтенд). Продукт состоит из десятков модулей, предоставляет сотни функций и поддерживает до миллиона пользователей, что требует глубокой проработки архитектуры, разработки и интерфейсов.

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

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

Новый перевод от команды МойОфис расскажет вам, как субструктурные типы и система владения в Rust помогают создавать безопасные и эффективные программы. Автор разбирает ключевые теоретические аспекты, выясняет, какие преимущества они предоставляют, и показывает, почему их использование становится неотъемлемой частью разработки современных языков. Вы узнаете, как субструктурные типы помогают обеспечивать безопасность и жизнеспособность программ, а также познакомитесь с идеями и проблемами их внедрения на практике.

VS Code сам по себе не нуждается в представлении, однако многие программисты, привыкшие в нём разрабатывать, упускают одну очень полезную вещь. Благодаря встроенным возможностям по разработке расширений можно легко автоматизировать многие рутинные задачи — например, те, что выполняются в командной строке.

В этой статье, второй в серии материалов о нестандартных возможностях VS Code, разберём инструменты для создания интерактивных расширений, которые я применяю в работе над решениями productivity suite платформы МойОфис. Под катом мы рассмотрим веб-панели и их разновидность – веб-представления, а также другие стандартные средства VS Code API, такие, например, как элементы строки состояния (кнопки и сообщения).

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

В статье подробно разобраны разные виды LLM, их особенности и сценарии использования. Какие модели лучше подходят для программирования? Какие эффективнее справляются с переводами, генерацией текста или анализом больших объемов данных? Автор статьи Chris Wellons* протестировал популярные открытые модели — Mistral, Qwen, DeepSeek-Coder, Mixtral, Llama 3.1 и другие, — чтобы понять их сильные и слабые стороны. Также автор делится опытом и практическими советами, которые помогут вам запустить и использовать LLM на собственном оборудовании. Хотите разобраться, какую модель выбрать под свои задачи и как эффективно запустить её на локальном оборудовании? Тогда приступим!

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

Программирование — это не только алгоритмы и логика, но и удивительное разнообразие синтаксиса языков. Работая над новым средством подсветки синтаксиса для llamafile, разработчик Justine Tunney* исследовала 42 языка программирования — от классического C и экзотического Tcl до мощного Ruby. 

Justine делится своими открытиями о том, насколько причудливым и непредсказуемым может быть лексический синтаксис. Например, триграфы в C — устаревший инструмент для поддержки клавиатур с ограниченными символами, фиксированные длины строк в FORTRAN, вложенные комментарии в Haskell или строки с двойными квадратными скобками в Lua. Ruby вообще оказался чуть ли не самым сложным языком для подсветки из-за его контекстно-зависимого синтаксиса.

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

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

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

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

Своим постом автор Jenny Jam* пытается заполнить этот пробел. Он рассуждает, когда C — идеальный выбор, а когда лучше обратиться к другим языкам. Описывает, как настроить среду разработки и выбрать инструменты, разобраться в версиях, особенностях сборки и тонкостях работы с библиотеками.

Цель статьи — упорядочить представление о языке C и его экосистеме, и, конечно, дать практические советы, которые пригодятся в реальных проектах.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

Привет Хабр! Меня зовут Владислав Столяров, я руковожу группой анализа безопасности продуктов в компании МойОфис. Полгода назад я узнал, что в статическом анализаторе Svace можно создавать собственные диагностические правила. Это показалось мне очень любопытным. В статье я хочу поделиться своим неоднозначным опытом и рассказать о попытке реализовать такую кастомную диагностику. Но обо всём по порядку.

В статье разработчик Барри Ревзин* объясняет, как можно определить и проверить свойства типов для обеспечения тривиального перемещения, разбирая нюансы эффективности, удобства и точности реализации. Основная проблема здесь в необходимости учёта всех особенностей типов, включая пользовательские функции, наследование и перегрузку. Это требует как сложных эвристик, так и новых инструментов языка. 

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

Почему некоторые разработчики останавливаются в развитии, выбирая путь посредственности, и при этом получают отличные зарплаты, повышения и признание? 

Программист и основатель нескольких компаний Эрик Дитрих* объясняет это феноменом «экспертов-новичков» — самоуверенных дилетантов, которые имеют влияние именно благодаря своей ограниченности. Под катом читайте, как такие псевдоэксперты появляются и приводят продуктивные команды к деградации. А также советы, как избавиться от влияния их «экспертного» мнения, сохранить эффективность коллектива и самому не попасть в ловушку ложного всезнайства.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

«Одержать сто побед в ста битвах – это не вершина воинского искусства. Повергнуть врага без сражения – вот вершина» Сунь Цзы.

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

А можно прямо сейчас сделать так, чтобы быть готовым к атакам?

Конечно! И здесь китайская мудрость устами Сунь Цзы говорит: «Непобедимость заключена в себе самом...».

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

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

В основе системы видео-конферец-связи в наших продуктах Squadus и Squadus PRO лежит open-source решение Jitsi. Однако нам пришлось существенно его доработать – у базовой Jitsi есть ограничения, которые не позволяют выстроить надёжную корпоративную ВКС под бизнес-цели.

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

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