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

Когда таких форматов становится много, возникает закономерный вопрос: как показать их пользователю удобно, быстро и без необходимости скачивать файл к себе на компьютер? У нас в GitVerse этот вопрос постепенно вырос в отдельную продуктовую и инженерную задачу. Так появилась поддержка просмотра разных типов файлов — от упомянутого выше Markdown до более специализированных форматов.

Я расскажу, почему вообще человечество пришло к идее текстовых форматов для оформления документов, как Markdown стал фактическим стандартом индустрии, зачем нужен Typst и как мы внедряли его поддержку на платформе с помощью WebAssembly.

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

Сначала переехали почта и офисные приложения. Потом пришли трекеры задач, инструменты для дизайна. Даже обработка видео и трёхмерная графика теперь доступна онлайн. И вот, казалось бы, последний бастион — полноценные IDE — тоже дрогнул.
Настройки окружений, специфичные для ОС зависимости, вечные «оно работает у меня» — всё это становится анахронизмом. Удобнее открыть вкладку и просто начать работать без установки, обновлений и потерянных на настройку выходных.

Если вы тимлид, DevOps или поддерживаете живой репозиторий, то наверняка знаете эту ситуацию: нужно быстро поправить README, обновить контент для Pages или внести небольшую правку по итогам рецензирования. Изменений на несколько минут, а дальше стандартный сценарий: клонировать репозиторий, открыть IDE, дождаться индексации, вспомнить, в какой ветке вообще планировалась правка. Сам код при этом простой, а контекст задачи давно понятен.

Мы в GitVerse регулярно сталкивались с такими случаями — и как пользователи, и как команда продукта. Поэтому решили не «делать ещё одну IDE», а упростить именно этот класс задач. Об этом и расскажем в статье.

Поиск по коду — одна из тех функций, ценность которых ощущается мгновенно. Она либо есть и экономит часы, либо её нет — и ты начинаешь открывать файлы вручную, клонировать репозиторий, запускать find или средства своей IDE и вспоминать «где же это было».
Мы добавили в GitVerse поиск по коду в репозиториях. и сделали это быстро. Не потому что «срезали углы», а потому что опирались на инструмент, который десятилетиями решает задачу поиска по коду внутри Git: git grep. Пока другие поднимают тяжёлые поисковые платформы, возводят кластеры, строят индексаторы, мы выбрали простое и проверенное решение, которое работает прямо сейчас.

Привет, на связи Виктор Степанов, лид одной из core-команд GitVerse. Сегодня хочу поговорить о важном аспекте нашей платформы — пользовательском опыте. А именно о том, как мы разрабатывали тёмную тему для GitVerse. Это был не просто косметический апгрейд, а полноценный инженерно-дизайнерский проект, в котором переплелись эргономика, технические ограничения и, конечно, ожидания пользователей.

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

Привет, на связи Виктор Степанов, лид одной из core-команд ИИ-платформы для работы с кодом GitVerse. Сегодня я хочу поделиться коротким рассказом о том, как мы начали проектировать и разрабатывать публичный API для нашей платформы.