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

Приятно, да? 

Нет. Не душите нового сотрудника.

Всем привет! Меня зовут Павел Стрельченко, я — Android-разработчик в hh.ru, и  сегодня мы поговорим про онбординг. Онбординг — это организованная помощь новому сотруднику в адаптации к необычным для него условиям. Все это необходимо, чтобы новичок как можно скорее разобрался: куда можно обратиться за информацией, где искать необходимые доступы, откуда скачивать софт, и начал приносить пользу команде и бизнесу. 

В сегодняшней статье я опишу типичную первую неделю нового сотрудника в мобильных командах hh.ru.

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

Всем привет! Меня зовут Паша Стрельченко, я Android-разработчик в hh.ru. В этой статье поведаю историю о том, как начиналась адаптация Jetpack Compose в нашем продакшн-приложении. 

Привет! Меня зовут Паша Стрельченко, я — Android-разработчик в hh.ru. Впрочем, сегодня я буду выступать в качестве проджект-менеджера нашего техбренда. Официально, конечно, у нас такой должности нет, да и деврелов тоже. В общем, справляемся своими силами. 

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

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

Меня зовут Павел Стрельченко, я – Android-разработчик компании hh. Я расскажу вам как эволюционировали наши CI скрипты на протяжении трех лет, с какими проблемами мы сталкивались, как анализировали их и пытались изменить, а также что вообще делали и к чему в итоге пришли. 

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

Всем привет! Меня зовут Паша Стрельченко, и я — Android-разработчик в hh.ru. В этой статье расскажу об укрощении feature-флагов. Если больше нравится аудиовизуальный формат, его можно найти на нашем youtube-канале. В статье я расскажу чуть больше технических подробностей, чем в видео, так что должно получиться интересно.

Как и множество других компаний, мы в hh.ru с интересом приглядываемся к Kotlin Mobile Multiplatform. Особенно нас заинтересовал вопрос, связанный с удобством работы iOS-разработчиков с общим SDK. Наши iOS-инженеры пишут на Swift, поэтому нам важно было убедиться: то публичное API, которое мы сформируем, будет выглядеть на Swift так же удобно и классно, как и в Kotlin. Мы провели объёмный ресёрч, в рамках которого подготовили специальный репозиторий "Kotlin-Swift-Interopedia", которым и хотим поделиться с сообществом.

На портале документации KMM можно найти страницу, посвящённую интеропу между Kotlin и Swift. Но в ней не рассматриваются все возможные конструкции языка Kotlin-а, поэтому даже после чтения документации оставалось множество вопросов.

Как поведут себя abstract-классы? Что будет с sealed-интерфейсами? Удобно ли мне будет работать с лямбдами в качестве аргументов функций? Enum-ы превратятся в Swift-овые enum-ы?

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

Относительно недавно на Хабре анонсировали специальный инструмент, который может немного улучшить опыт iOS-разработчиков — плагин moko-kswift от компании IceRock. Но даже с его помощью не все боли могут быть исправлены прямо сейчас.

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

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

Если вам удобнее не читать, а смотреть или слушать, то вы можете посмотреть выпуск о дизайн-системе в нашем видео-блоге “Охэхэнных историй”. 

Спустя два месяца после написания цикла статей «Navigation Component-дзюцу» я задумался: неужели всё действительно так плохо? Может быть я поддался волне критики гугловых разработок и просто пропустил тревожный звоночек, принявшись исправлять баг за багом, проблему за проблемой с помощью костылей и палок?

Оказалось, во многом так оно и есть: в этой статье-дополнении я хочу рассказать, в чём была проблема, как её исправить и как это поменяло моё мнение о Navigation Component.

Начиная с Android Studio 4.1, Google прекратил поддержку кастомных FreeMarker-ных шаблонов. Теперь вы не можете просто взять и написать свои ftl-файлы и сложить их в определённую папку, чтобы Android Studio самостоятельно добавила их в меню New → Other. В качестве альтернативы нам предлагают разбираться в плагиностроении и создавать шаблоны изнутри плагинов IDEA. Нас в hh такая ситуация не очень устраивает, так как есть несколько полезных FreeMarker-ных шаблонов, которые мы постоянно используем и которые иногда нуждаются в обновлениях. Лезть в плагины, чтобы поправить какой-то шаблон? Нет уж, увольте. 

Всё это привело к тому, что мы разработали специальный плагин для Android Studio, который поможет решить эти проблемы. Встречайте – Geminio.

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

Это третья и заключительная статья в цикле про различные кейсы навигации с Navigation Component-ом. Вы также можете ознакомиться с первой и второй частями

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

Это вторая из трёх статей про реализацию кейсов навигации при помощи Navigation Component-а.

Два года назад на Google I/O Android-разработчикам представили новое решение для навигации в приложениях — библиотеку Jetpack Navigation Component. Про маленькие приложения уже было сказано достаточно, а вот о том, с какими проблемами можно столкнуться при переводе большого приложения на Navigation Component, информации практически нет.

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

Здесь можно почитать первую статью с теорией плагиностроения.

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

Жизнь с многомодульным проектом не так уж проста. Чтобы избежать рутины создания нового модуля мы создали собственный плагин для Android Studio. В процессе реализации мы столкнулись с отсутствием практической документации, перепробовали несколько подходов и откопали множество подводных камней. Получилось две статьи: “Теория” и “Практика”. Встречайте!