Наша команда отвечает в Skyeng за личный кабинет и CJM пользователя до оплаты. Изначально проект был написан на Symfony 4.4 и представлял собой набор слабо связанных компонентов, которые были ответственны за правила работы для фронтенда.

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

У нас были лишь юнит-тесты: каждый покрывал логику одного класса. Все тесты вместе давали покрытие основной логики кода и гарантию, что все работает правильно. Но 100% покрытие кода тесты не обеспечивали. И сейчас не обеспечивают.

Код был сравнительно простой, простые были и тесты. В то время мы еще полностью не управляли CJM пользователя. Но когда это понадобилось, существовавших юнит-тестов оказалось недостаточно.

И мы обратились к функциональным.

• Продукт, где находятся все базовые запросы сотрудников. По нажатию пары кнопок можно получить все нужные справки, доступы, отметить отпуск, отгул или вообще оформить увольнение. То есть не надо ни с кем разговаривать. Каждое действие запускает набор скриптов, который создаёт все нужные задачи в Джире или автоматически оформляет все нужные документы.
• Сами наборы скриптов. У любой заявки есть процесс, который мы продумали и автоматизировали, то есть не надо ничего придумывать. Например, при смене роли пользователя (переходе на другую должность) собираются и добавляются-отзываются все доступы и ставятся все нужные задачи.
• SLA на каждое действие. Как только есть описанный процесс — можно назначать ответственных и сроки. Теперь, если вам нужна какая-то бумажка от кадров, не вы заходите и спрашиваете, готово ли, а уже кадры должны уложиться в свои SLA, и у каждого шага есть ответственный.
• Бота, который в первые дни работы «ведёт» сотрудника.
• Автоматизацию микромоментов. Например, за день до ухода в отпуск в слаке проставляется соответствующий статус плюс у сотрудника становится видно в профиле, кто за него работает и по каким вопросам.

Вы когда-нибудь встречали такие операторы, как materialize и dematerialize в RxJS? А что насчет класса Notification? Вероятно, многие слышали, но не до конца представляли, где их можно применить на практике.

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

Materialize

Для начала вспомним, какие типы значений может эмитить объект типа Observable: это next, error и complete. Если вы не помните, что это значит, здесь можно почитать.
Соответственно и про observer, набор коллбэков (onNext, onError, onComplete), тоже советую вспомнить.

Вот что говорится в документации о materialize операторе: «A function that returns an Observable that emits Notification objects that wrap the original emissions from the source Observable with metadata».

1. Собрал по данным методологических исследований карту навыков английского языка, разбитую на сотни отдельных веток, связанных друг с другом, как в хорошей RPG.
2. Отскринил несколько реальных учеников по этой карте и придумал, как с её помощью вычислить образовательный прогресс.
3. Наложил карту навыков на контент, чтобы каждое упражнение автоматически учитывалось в оценке прогресса (о, это было долго и сложно).
4. Провалидировал на тысячах внутренних тестов, не зависящих от системы оценки прогресса.
5. Заложил адаптацию для учеников разных языковых групп, поскольку родной язык ученика даёт ему какие-то навыки сразу, а какие-то делает очень сложными.
6. Семь раз усложнил, а после существенно упростил систему.

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

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

На старте было просто: связаться с нами можно было только через почту. Входящим ящиком был IMAP, исходящим — SaaS сервис по отправке почты, забрать письма с которого было то еще приключение. Мы смотрели на заголовки и соединяли письма в цепочки, как в любом почтовике: Gmail, Outlook. В таком виде передавали операторам. 

Но оказалось, что с теми метаданными, которые мы предоставляли операторам, им было неудобно работать — много времени отнимал поиск пользователей в базе по адресу почты и теме сообщений.

Так появился проект линковка.

В этой статье я хочу поделиться опытом работы со скроллом в приложении, написанном на Jetpack Compose.

Какое-то время назад я решил, что надо попробовать Compose в деле и начал делать pet project приложение Хотелки, суть которого в записи своих желаний и возможности делиться списком желаний с помощью любого мессенджера.

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

Бывают ситуации, когда компонент необходимо добавить на страницу динамически. Например, тултип или баннер. В такие моменты на помощь приходит Angular, который умеет создавать компоненты в рантайме и рендерить их. Для этого разработчик может воспользоваться методом createComponent у ViewContainerRef.

Но с 13 версией фреймворка API этого метода немного изменился. В этой статье поделюсь тем, как теперь выглядит процесс динамического добавления компонента.

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

Заодно разберемся с таким понятием, как неявные анимации.

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

Как собирались мнения

Ссылку на опрос помогли распространить городские чаты и админы крупных PHP-каналов, деврелы компаний, где в стеке есть PHP, конференция PHP Russia, сайт phpcommunity.ru. Вот полный список классных ребят и компаний, которые помогли исследованию сбыться.

Еще пара полезных ссылок на старте.

- Подробнее про результаты опроса за 2021 и сравнение с 2020.

- А здесь 80+ видео и статей за 2020 — в подборке, подготовленной @spasibo_kep

Поехали.

Абсолютное большинство мобильных приложений имеет интересный нюанс – «хвост» старых версий, которыми все еще продолжают пользоваться. В этой статье мы посмотрим, какие проблемы это приносит и как с этим бороться. Материал будет полезен и мобильным разработчикам, и тем, кто каким-либо образом связан с разработкой мобильных приложений, к примеру, разрабатывает backend сервисы, которые используются в приложениях.

Эта статья является логическим продолжением UIKit ты вообще про UI?
Если вы ее пропустили, рекомендую сначала ознакомиться с ней. На всякий случай напоминаю, что весь графический интерфейс – это ответственность слоев (не вью!).

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

Сегодня я не буду подробно разбирать проективную геометрию, глубокие математические обоснования и принципы работы с матрицами. Надеюсь, что вы либо уже знакомы с этим, либо можете разобраться в этом сами. Я постараюсь объяснить все так, чтобы было понятно даже тем, кто видит все эти ужасные слова впервые. 

Давайте разберемся, как работают трансформации, постараемся понять подходы к ним и найти закономерности. Для того, чтобы начать погружение в трансформации, стоит для начала разобраться с контекстом. Ведь мы не просто рисуем карандашом на листе бумаги, мы управляем объектами в виртуальном мире. Сделаю небольшую оговорку – на самом деле все это очень сложные технические процессы (шедевры инженерной мысли), разобраться в которых за 15 минут не получится. Поэтому я буду умышленно упрощать некоторые вещи для того, чтобы сформировать общее понимание.

Привет. Меня зовут Маша, я — тестировщик в команде мобильной платформы. Когда-то для нас была актуальна проблема взаимодействия QA и Support. Сложностей было предостаточно, как и неприятных последствий. Но со временем мы успешно разобрались во всем. Хочу поделиться нашим опытом и рассказать, какие изменения сработали во благо.

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

Наливаем чай-кофе и погнали!

Спойлер - нет! Ну, не совсем. Мы привыкли воспринимать UI как визуальную составляющую, но ведь UI – это User Interface. Так вот, интерфейс – это то, с помощью чего пользователь взаимодействует с нашим приложением. В случае с графическим интерфейсом пользователь его видел и воспринимает информацию. Однако он статичный и, когда пользователь хочет взаимодействовать с ним, он использует другие интерфейсы: тачскрин, клавиатуру или мышку. Да, это тоже интерфейсы. И UIKit как раз таки отвечает не за графический интерфейс, а за распознавание пользовательских жестов и их обработку.

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

Так как же он устроен? У нас же есть базовый класс UIView и куча его стандартных наследников. Мы можем сами создавать свои вью и как угодно их кастомизировать. И все это видим на экране. Почему тогда UIKit и UIView – это не про графический интерфейс? Давайте разбираться.

Эпопея с автодокументацией началась у нас неспроста: 300 разработчиков, 500 репозиториев и 400 сервисов — все живет на 600 хостах и использует 600 баз данных. Изменения происходят настолько часто, что ручной поиск данных в наших масштабах — та еще морока. При этом раньше никакого общего хранилища с актуальной информацией о владельцах проектов, о конфигурациях хостов и связанных с проектами сервисах не было. Расскажу, как мы вконец устали от квестов, перешли на сторону автодоки и почему выбрали в помощь Insight.

Меня зовут Юля, я руковожу командой SRE. Помимо стабильности сервисов, моя команда занимается поддержкой инструмента, который нам позволяет за этими сервисами следить. Это отдельное приложение, генерирующее документацию по всей нашей инфраструктуре.

В 2018 году, когда я только пришла в компанию в роли девопса, мне дали для погружения в процессы простую задачу: допилить скрипт локального разворачивания проектов, чтобы он корректно работал под macOS. То есть скрипт уже был, он успешно работал для Linux-окружения. Его нужно было просто адаптировать, подправить пару регулярок, настроить сеть, дописать инструкцию — совсем не сложно. Я довольно быстро сделала правку в самом инструменте, и казалось, что нет никаких проблем. Но дальше 15-минутная на первый взгляд задача растянулась на 3 месяца.