• общее ускорение работы кода за счет перегонки всей кодовой базы в плюсы;
• кастомный компилятор и транслятор кода, который перегоняет php
  в C++ современная версия kphp позволяет писать на php очень близкому к современным стандартам и делает код понятным, предсказуемым и отлаживаемым;

• kPHP уже 2 года в OpenSource и получил тысячи звёзд на GitHub.

Какие возможности дает kPHP нашей команде?
1. Мы получаем строго типизированный php = снижение потенциальных рисков написать код с ошибкой;

2. В php нет полноценного параллелизма, а в kPHP – есть: сам механизм реализован на основе джоб-воркеров и сейчас полноценно работает из коробки. Это дает возможности к кратному росту скорости исполнения кода. Например, при переводе одного из основных методов API на этот подход нам удалось сократить время исполнения кода на несколько сотен миллисекунд;

3. Общее ускорение работы кода за счет перегонки всей кодовой базы в плюсы.

Но, как говорится, есть нюанс:
PHP и C++ – это хоть и близкие языки, но в ряде случаев их внутрянка сильно отличается. Самый яркий пример – это массивы, которые имеют отличие в реализации. Обычно, в такие моменты kPHP довольно демократичен к разработчику: есть полифилы, которые позволяют сохранить привычные методы с их сигнатурой. Но все же kPHP не даст использовать то, что не вписывается в концепт перегонки в плюсы.

По каким критериям мы определяем качество новой ML-модели:

1. recall – насколько точно модель не упускает из виду сообщества. Здесь мы получили +4 п.п. от точности предыдущей модели;
2. precision – надежность оценки: прирост +12 п.п. среди тех, кого модель считает бизнесами, реально являются бизнесами;
3. accuracy – новая модель модель на 9% чаще правильно определяет бизнес-сообщество.

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

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

Какие особенности разработки мы учли?

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

Что получилось?

В результате рефакторинга скорость разработки новых фичей в карточке товара увеличилась в ~3 раза. После тщательного тестирования, мы убедились, что весь функционал сохранен. Теперь все карточки написаны на React – маленький шаг для человечества, но большой для социальной сети с огромной историей и количеством пользователей.

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

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

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

А какие сайд-проекты есть у вас?

• не приходят уведомления;
• переходы по push-уведомлению – с заблокированного экрана, из «шторки», из открытого или свернутого приложения;
• переход из состояния разлогина после получения push;
• переход по push-уведомлению с включенным «Don't keep Activities» (характерно для Android-приложений).

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

Если push-уведомление ведет на WebView, то надо обратить внимание, что WebView открывается корректно на обеих платформах, и что в push зашит корректный URL.

На что стоит обратить внимание при тестировании уведомлений:

1. устаревший токен;
2. очередь со стороны Apple;
3. максимальное и минимальное количества отображаемых символов;
4. звуковое сопровождение нотификации и встроенные изображения;
5. проблемы на серверной стороне.

Подробнее о тестировании push-уведомлений можно почитать здесь:
https://habr.com/ru/company/youla/blog/553762/

Что такое MVI?

MVI (Model-View-Intent) – это архитектурный паттерн, Unidirectional Data Flow подход проектирования системы, в которой все представляется в виде однонаправленного потока действий и управления состояния.

Как это работает?

Мы создаем интерфейс-маркер, который будет отвечать за какое-либо событие, состояние экрана и при этом не влиять на состояние экрана.

При таком подходе состояние представления (View) описывается моделью (Model), которая сохранена в объекте ViewModel.

View подписывается на изменения модели – в нашем случае путем RxJava– и делает изменения в себе в соответствии с новым состоянием.

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

Как и почему мы реализовали свой MVI-фреймворк на Android?

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

С какими проблемами мы столкнулись в результате?

 1. код на больших и сложных экранах становился трудным в поддержке и расширении;

2. из-за ошибок проектирования мы сталкивались с неконсистентностью системы,

3. отсутствие логирования приводило к долгому поиску багов.

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

MVI строится на основе трех компонентов – модели, намерения (действия) и состояния экрана. Логика приложения диктуется пользователем: например, он хочет загрузить картинку в высоком разрешении, и различными внешними эффектами (далее – side-effects), например, внезапной потерей соединения.

MVI подход решают задачу реализовать механизм, который будет обрабатывать намерения пользователя и их следствия (например, ответ от api).

Наш опыт внедрения MVI-фреймворка.

Мы начали искать готовые opensource решения, чтобы встроить их в наш проект. Однако ресерч привел нас к тому, что ни одно из готовых решений не удовлетворяло нашим требованиям. В нашем случае код, написанный на mvi решении, должен был отвечать следующим критериям:

• Масштабируемость и независимость от платформы и внешних библиотек. Архитектура должна быть в крайней степени гибкой и расширяемой.
• Сейчас у нас в проекте используется RxJava, при этом мы планируем перейти на compose и использовать coroutines в будущем.
  Отсюда требование: фреймворк не должен зависеть на сторонние библиотеки.
• Сопровождаемость.
  Чем проще исправлять ошибки и управлять  проектом после передачи в эксплуатацию, тем легче новым разработчикам поддерживать проект;
• Надежность.
  Внутри реализации системы исключены проблемы многопоточной среды. Единый контракт должен обеспечивать безопасность интерфейсов;
• Тестируемость;
• Возможность переиспользования;
• Легкая встраиваемость в проект;
• Детальные и хорошо читаемые логи.

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

В момент, когда мы изучали opensource решения, и не нашли нужного, помог наш активный круг общения и дружная команда :)

Собственное решение реализовал наш бывший коллега Георгий Ипполитов – reduktor. Мы совместно посмотрели предложенный Гошей вариант, после чего он внес  значительные доработки и довел либу до идеального состояния, отвечающего всем нашим критериям.

Библиотека прошла 2 волны улучшений: от первой версии мы довели ее до второй и окончательной, изменив основу либы (Store). В результате мы получили:

• уход от жесткой привязки к RxJava. Появилась возможность использовать в качестве межпотокового взаимодействия любой из общеизвестных способов;
• новые плюшки для удобства написания кода в sideEffect-ах.

А вот и вики либы:

https://github.com/g000sha256/reduktor/tree/wiki

Всё взаимодействие происходит через объект Store. У него есть одно публичное поле – states. При подписке на эту цепочку сразу будет отдано актуальное состояние в текущем потоке. Однако дальнейшие обновления могут приходить в других потоках. Внутри есть проверка состояний на эквивалентность.

Принцип работы:

• Действие может попасть в систему через Initializer. Это может быть событие от взаимодействия с пользователем или любое другое внешнее событие (например, новое сообщение из сокета).
• Далее действие проходит через Reducer. Тут действие может повлиять на изменение состояния. Если состояние изменилось,  информация об этом будет отправлена тем, кто на него подписался.
• После этого действие и новое (либо не изменившееся) состояние попадают в SideEffect.
• Оттуда возвращаются новые цепочки с действиями. Подписываемся на них и ожидаем событий.
• Новые действия будут снова отправлены в Reducer.

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

Когда мы говорим про доступный интерфейс – важно упоминать не только про помощь и эмпатию, но и про помощь всем пользователям.

На какой набор факторов обратить внимание при внедрении доступности в сервис / продукт?

- Семантичная вёрстка;

- Доступность элементов с клавиатуры;

- Подписи и aria-лейблы;

- Правильный атрибут lang.

Но, как бы радостно не было – это ещё не всё. Важно упомянуть и про библиотеки компонентов:

- Angular Material, Material UI, Chakra UI;

- angular-eslint, eslint-plugin-jsx-a11y.

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

- Формулирование требований к доступности в сервисе;

- Мотивация команды на обучение;

- Адаптация процессов внедрения.

Хотите научиться? 

Как и обещали, делимся полезными ресурсами для изучения темы от нашей команды:

📌Web Content Accessibility Guidelines (WCAG)

📌A11ycast with Rob Dodson

📌Веблайнд 

📌Курс по цифровой доступности 

📌Гайд по цифровой доступности

📌Список платных и бесплатных курсов

📌Расшифровка доклада Лены Райан о версиях для слабовидящих

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

Когда мы начали работать со студентами, нас очень поддерживал собственный опыт обучения, ведь большинство из нас – выпускники МГТУ им.Баумана. Можно сказать «отдаем дань технопарку» (*так раньше назывался образовательный центр VK в МГТУ им.Баумана) (смеются). А еще, опыт преподавания нереально прокачивает наши собственные soft skills.

Мы помогаем формировать комьюнити, которое аккумулирует в себе опыт разработчиков. Кроме того, получаем невероятный кайф, когда человек без опыта в iOS-разработке буквально через полгода находит работу и записывает тебе благодарность – это очень ценно. Ещё, мы можем набрать себе отличных молодых специалистов в VK. Огромный плюс здесь в том, что мы уже хорошо знаем ребят, знаем их сильные и слабые стороны. Не секрет, что один из самых сложных и ответственных периодов – онбординг, интеграция в команду. Благодаря курсу, этот период частично проходит в условиях обучения, ребятам проще выходить в реальный проект, ведь они знают, что рядом весь преподавательский состав, готовый тебя поддержать на все 100% :)

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

Легко стать преподавателем и какой план подготовки к этой роли?

Мы сами прошли через учебу в образовательном проекте компании в МГТУ им.Баумана), поэтому хотели обучать студентов, чтобы они становились крутыми разработчиками. Чтобы стать преподавателем  главное – найти желание и время, ведь каждому студенту нужен по-настоящему конструктивный фидбек. Преподавание – точно наше дело :) Нашей команде всегда интересно делиться знаниями. Как-то раз мы задались вопросом «А чему мы могли бы научить себя «молодых» (смеются), если бы у нас была машина времени?» Вот тут, в ответе на этот вопрос, и кроется источник вдохновения :)

Много ли сил и времени уходит на работу со студентами?

Первый раз – да, но когда курс проходит повторно – уже нет. Первым делом, мы готовим лекцию, на подготовку одной лекции уходит около недели. Дальше эту лекцию проводим несколько раз для разных потоков. Подготовка к уже готовой лекции занимает 1-2 дня. Работа со студентами у нас выстроена с помощью менторов, это такие люди, которые служат связующим звеном между преподавателем и командой студентов. Ментор – это выпускник курса, который берет одну команду, сопровождает ее в процессе обучения и помогает ей своим опытом. Плюс ко всему, конкретно на нашем курсе нет домашних заданий, так как все полученные знания студенты сразу же применяют в своих командных проектах.

Как удалось собрать общую преподавательскую команду курса и разработать такую глубокую программу?

Всё получилось довольно легко, основная часть преподавательского состава – из Юлы, где собралась классная инициативная группа. Программа курса уже была спроектирована командой образовательных проектов VK. Мы что-то доработали, добавили что-то новое и актуальное в лекции, используем максимум практических примеров и заданий из реального опыта разработки.

Сколько раз уже собирали группы, сколько у вас выпускников?

Очень много, где-то > 5 потоков, около 200 выпускников. Сейчас мы провели уже 4 курса, а это целых два года. Время летит!

Были ли забавные случаи или что-то запоминающееся?

Да, в основном забавные случаи связаны с дистанционным обучением во время пандемии. К примеру,  как-то раз студент забыл выключить камеру и оказался  во время лекции, буквально, без штанов, поскольку параллельно лекции переодевался :) В принципе, такие случаи наверняка бывали у многих, когда случился локдаун.

Как обычно проходит защита? Как вы выбираете проект-победитель?

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

Что происходит после курса? Следите ли за судьбой своих выпускников?   
Конечно! Периодически мы встречаем наших выпускников-коллег у нас в компании, да и в целом – мы поддерживаем наших студентов. Иногда встречаемся  просто пообщаться в барах, обсуждаем дела, даем рекомендации, если они нужны, продолжаем списываться в чатиках. Наши бывшие студенты работают везде: есть ребята, которые работают и в известных компаниях, и в небольших стартапах. Классно, что курс стал полезным стартом в профессии и все продолжают начатое, развиваясь дальше.

Чему вас научили студенты?

Совершенно точно прокачали наши soft skills и усилили базовые знания, ну и конечно, подарили нам потрясающее окружение, комьюнити, которое сложилось благодаря программе, VK и Образовательному центру VK в МГТУ им. Н.Э. Баумана.

Какие у вас планы на ближайшее время? Будет новый курс?

Конечно! Наш курс проходит каждые полгода. Сейчас мы работаем над тем, чтобы немного адаптировать его с учетом изменений в платформе и разработке. А еще, с нетерпением ждем летний буткемп по мобильной разработке, в который приедут студенты со всей России: с 8 по 25 августа на базе Университета «Сириус» пройдёт бесплатная летняя образовательная программа. На буткемпе будет возможность освоить как iOS-разработку, так и Android-разработку: мы вместе с коллегами из других юнитов готовим интересный материал и будем делиться опытом с начинающими разработчиками.

Ещё немного фото с защиты проектов в офисе VK: