Русский
Русский
English
Статистика
Реклама

Конференции

По следам черного лебедя о чем говорили ИБ-эксперты на конференции Умные решения умная страна

15.12.2020 10:11:51 | Автор: admin
Онлайн-конференция Умные решения умная страна: инновационные технологии для новой реальности, организатором которой выступила компания ЛАНИТ, была наполнена полезным и разнообразным контентом. Продолжаем делиться самым интересным (о выступлении всемирно известного футуролога Кьелла Нордстрема можно почитать здесь).

Во второй день форума, Technology Day, прошла секция Информационная безопасность, на которой руководители компаний и эксперты в области ИБ делились своим видением трендов, уже оказывающих или лишь начинающих оказывать свое влияние как на современный бизнес, так и на общественную жизнь в России. (Я тоже, кстати, рассказывал про оценку рисков информационной безопасности.) В этой статье я сделаю обзор выступлений на нашей секции. Важно отметить, что никакая статистика и анализ не уберегут от наступления событий, описанных Нассимом Талебом в его книге Черный лебедь. Непредсказуемые события непрогнозируемых масштабов случаются, и 2020-й год стал наилучшим тому подтверждением.

Онлайн-платформа конференции. Приветственное слово модератора секции Информационная безопасность Андрея Голова

Уроки 2020 года



Крайне нетипичным дипломатично назвал в своем докладе 2020 год Андрей Голов, генеральный директор компании Код Безопасности. Шаг за шагом он проследил цепочку изменений, вызванных к жизни пандемией коронавируса. Удаленка разрушила привычный периметр безопасности корпоративной инфраструктуры, породив новые модели потребления ИТ-сервисов и, как следствие, значительно изменив ландшафт киберугроз. К вышеперечисленному добавился макроэкономический идеальный шторм, каскад государственных локдаунов и разрыв цепочек поставок.

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

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

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

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



Самым, пожалуй, богатым на новые тренды стал доклад Алексея Лукацкого, бизнес-консультанта по вопросам безопасности Cisco. Алексей выделил семь основных тенденций, касающихся кибербезопасности как непосредственно, так и в преломлении бизнеса.

  • Усиливается регуляторная нагрузка на эксплуатантов информационных систем и ужесточение ответственности за нарушения.
  • Самой важной метрикой в информационной безопасности становится время обнаружения атаки, а отчеты службы ИБ включают все больше метрик, связанных с бизнес-целями предприятия.
  • Невозможность обеспечить абсолютную защиту от угроз смещает фокус внимания служб ИБ с предотвращения атак на своевременное обнаружение и реагирование на них.
  • Самым слабым звеном любой системы безопасности остается человек. Число атак, связанных с социальным инжинирингом, будет только расти.
  • Количество событий безопасности в сложной системе ИБ превысило физические возможности специалистов по реагированию на них.
  • Злоумышленники все чаще атакуют не своих жертв напрямую, а их поставщиков ПО и оборудования.
  • Растет важность безопасной разработки, предъявляющей новые требования к создателям программного кода на всех этапах его производства.

Кибербезопасность в эпоху цифровой трансформации



Мир погружается в цифру, а неопределенность растет. Растет и число кибератак, несущих угрозу новой реальности. Николай Фокин, руководитель отдела информационной безопасности компании ЛАНИТ-Интеграция, напомнил о том, что кибератаки входят в ТОП-5 глобальных угроз наряду с изменением климата, эпидемиями и природными катастрофами. К 2022 году, по оценке ВЭФ, ущерб мировой экономики от киберпреступлений может достичь $8 трлн.

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


Один из самых распространенных векторов атаки шифровальщиков RDP. На теневом рынке стоимость покупки учетных данных организации составляет всего $20. При этом большинство компаний не применяют необходимые средства защиты от этой угрозы.

Николай Фокин

Вывод Николая не внушает оптимизма: 90% компаний по-прежнему могут быть взломаны за несколько дней, а 77% бизнесов не имеет четкого плана реагирования на киберинциденты. Помочь в этой ситуации может только тотальный пересмотр всех политик ИБ, ужесточение контроля за средствами удаленного доступа, внедрение технологий многофакторной авторизации и программ обучения персонала правилам цифровой гигиены.

Проект Безопасность детей ХМАО-Югры в сети Интернет



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

Более половины родителей признаются, что используют гаджеты, чтобы занять ребенка. Девять из десяти родителей прибегают к электронным устройствам в процессе обучения своих детей в возрасте 3-6 лет. Сделать эти процессы максимально безопасными призван проект-финалист премии IT Stars имени Георгия Генса Безопасность детей ХМАО-Югры в сети Интернет.

Ханты-Мансийский автономный округ стал площадкой для эксперимента не случайно. Многие родители здесь работают вахтовым методом и зачастую не в состоянии контролировать время, проведенное ребенком в интернете, или характер потребляемого им контента. Помочь им в этом был призван специальный продукт Kaspersky Safe Kids.

За год его использования детский интернет-трафик претерпел серьезные изменения. Интересным стало падение популярности компьютерных игр с 32% до 16%. Связано это по всей видимости с тем, что родители сочли эту категорию наименее желательной. Зато значительно вырос трафик новостных ресурсов, интернет-магазинов и банков. Проект уже отмечен многочисленными благодарностями родителей, учителей и представителей администрации округа.

Защита от несанкционированного доступа к инфраструктуре бизнеса



С распространением цифровизации бизнеса среди всех инструментов анализа информационной защищенности корпоративной инфраструктуры пентест выходит на первый план. Мурад Мустафаев, руководитель службы информационной безопасности компании Онланта, и Дмитрий Донской, директор по развитию группы компаний Эшелон, рассказали о том, как инсценировка преднамеренного взлома помогает объективно определить уровень защищенности компании, и привели живой пример.


Главным выводом эксперимента стало четкое понимание необходимости мониторинга всех ИБ-событий в реальном времени. Наилучшим способом добиться этого на сегодняшний день является использование SIEM-систем. Неудивительно, что подобным инструментам уделено большое внимание в федеральном законе N 187-ФЗ, посвященном требованиям к защите критической информационной инфраструктуры.

Безопасность виртуальной облачной сети предприятия



Доклад Дмитрия Жечкова, менеджера по развитию бизнеса сетевой виртуализации и безопасности VMware в РФ и СНГ, был посвящен новым подходам к обеспечению информационной безопасности в условиях новой нормальности. Параллельно с трендом цифровизации бизнеса и массовым переходом на удаленную работу сформировалось три основных потенциально уязвимых области в ИТ-инфраструктуре любого предприятия:

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

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


VMware уже пошла по этому пути, предлагая создавать безопасные цифровые экосистемы предприятий, основанные на решениях Workspace ONE, Carbon Black, NSX и CloudHealth.

Экономическая оценка рисков информационной безопасности



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

  • производственные;
  • инфраструктурные;
  • управленческие;
  • организационные;
  • антропогенные;
  • законодательные;
  • санкционные;
  • нарушения;
  • репутационные.

Анализ более 3 тыс. инцидентов позволил нашей команде вывести общие закономерности, помогающие понять, какой экономический ущерб могут нанести те или иные нежелательные события. Так, к примеру, опыт ЛАНИТ показывает, что ущерб от инцидентов, связанных с нарушением или блокировкой деятельности бизнеса в результате хакерской атаки, для компаний среднего размера, как правило, находится в диапазоне 0,5-10% годового оборота. Ущерб от кражи конфиденциальной информации может достигать 100% годового оборота. Причем чем меньше компания, тем уровень ущерба выше.


Информационная безопасность остается одной из ключевых сфер ИТ. Тональность докладов, прозвучавших на конференции Умные решения умная страна, говорит о том, что проблема ее обеспечения не просто не решена, она с каждым годом становится все более актуальной. А значит, мы продолжим обсуждать ее и в следующем году. В том числе и на Хабре.

Видеозаписи докладов, а также презентации спикеров конференции Умные решения умная страна: Инновационные технологии для новой реальности, организованной компанией ЛАНИТ, доступны до 1 февраля 2021 года на платформе мероприятия. Вам понадобится заполнить простую форму для регистрации и в разделе Библиотека IT-знаний выбрать интересующий материал.
Подробнее..

РосКомСвобода на ОГФ2020 рассказываем про открытые данные о пандемии и праве на приватность

17.12.2020 16:16:33 | Автор: admin
image

РосКомСвобода совместно с Инфокультурой весь день вела на Общероссийском гражданском форуме (ОГФ'2020) площадку Право на приватность и открытость.

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

Ключевые цитаты из выступлений:



Все видео выступлений








Ссылки на полные обзоры в конце статьи.

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

image

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

Кто же акторы нарушения наших цифровых прав, нашего права на приватность? Это государства, корпорации и киберпреступники.


У каждого из них свои цели и методы. По мнению Козлюка, у общества нет рычагов давления на госорганы и потому в качестве самозащиты гражданам остаются повышение цифровой грамотности и инструменты общественного давления в виде подачи исков, участия в кампаниях, подписания петиций. К слову, у Роскомсвободы есть кампания против слежки через распознавание лиц Bancam. В рамках неё мы требуем ввести мораторий на массовое распознавание лиц, пока система видеонаблюдения не станет прозрачной и подотчётной и не будет иметь гарантии защиты от подобных злоупотреблений. Вы можете помочь нам, присоединившись к кампании и подписав петицию на сайте Change.org.

image

Координатор проекта Pandemic Big Brother Алёна Рыжикова на примере, собственно, Pandemic Big Brother рассказала о конкретных перекосах в мерах, принятых государствами по всему миру. В частности, она выделила массовые штрафы и даже аресты за т.н. коронафейки (информацию о пандемии, противоречащую официальной) и распознавание лиц, которое стали применять в отслеживании нарушителей карантина, вплоть до автоматического штрафа на основании его результатов. Подобное, по её словам, практикуют не только в России, но и во многих других странах.

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


Pandemic Big Brother интерактивная карта, на которой фиксируются случаи нарушения цифровых прав граждан, такие как введение слежки, цензуры и контроля за коммуникациями.

Юристы РосКомСвободы готовы помочь всем, кто пострадал из-за незаконной слежки. Ваши обращения вы можете присылать на адрес legal@roskomsvoboda.org

image

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

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


Единственный подходящий закон о защите во время чрезвычайных ситуаций. Он, к слову, не содержит ничего об ограничении прав, которые власти применяли с таким упорством, но только то, что должны делать МЧС и другие органы по координации своих действий во время ЧС. Федеральная власть не хотела рисков и потому поступила хитро, а именно: переложила все решения на субъекты. Как результат Москва начала принимать свои законы, которые вошли в диссонанс с федеральным законодательством. Даже если бы ковида не существовало, его стоило бы придумать, по крайней мере для московских властей, которые годами держали эти технологии под сукном и ждали возможность начать их использовать, сказал Дарбинян. По его словам, различные технологии для слежки у московской мэрии были давно, и пандемия послужила спусковым крючком для их использования.

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



Кандидат биологических наук, независимый аналитик Алексей Куприянов представил доклад об общественном аудите государственной статистики. С 13 марта эксперт собирает данные по распространению коронавирусной инфекции по России. В апреле он стал публиковать их и в Фейсбуке на страничке инициативной группы Watching Covid-19.ru, где вместе с коллегами, в том числе другими докладчиками Алексеем Ракша и Борисом Овчинниковым, выкладывает аналитику. Основные источники данных Стопкоронавирус.рф и СМИ, на первых порах ещё бюллетени Роспотребнадзора.

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

Куприянов отметил, что это первая пандемия, по которой так много открытых данных, но, к сожалению, они не очень достоверны. Аналитик выявил две главных фальсификации, из-за которых доверять информации невозможно:
избыточное сглаживание данных, когда показатели долгое время находятся на одном уровне (собянинский коридор);
дагестанский скачок, когда все вдруг резко выздоровели (в других регионах тоже такое было, например, в Марий Эл, где добились отрицательного количества заболевших).

Эта пандемия развивается благоприятно в плане открытости данных, но она совершенно проиграна в плане достоверности данных.


Для получения более точных данных, по мнению учёного, необходимы:
машиночитаемые данные;
доступ к дезагрегированным данным;
расширение спектра доступных параметров;
смещение акцента с агрегирования на валидацию.

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

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

image

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

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

Общая численность населения неточна, например, из-за разницы между переписью населения и учётом за обозначаемый период. Также есть проблема подсчёта числа людей в регионах с интенсивной трудовой миграцией. Заболеваемость трудно исчислять из-за проблем диагностики, неучтённости повторных диагнозов и пр. Что касается смертности, то 74% врачей подтверждают в опросах те или иные манипуляции с кодировкой смертности, в двух случаев из трёх это происходит под административным давлением.

Чем больше интерес к какому-то статическому показателю, тем больше этот показатель фальсифицируется.


По потребности в объёмах медпомощи последние исследования проводились ещё в СССР. Заявленные объёмы медорганизаций не обеспечены финансами, они непрозрачны и определены не научными методами. По обеспеченности кадрами нет единых, полных и научно обоснованных нормативов нагрузки. Многие нормативы сформированы 30-40 лет назад и отстают от возможностей современных технологий. Штатные расписания не соответствуют нормативам по медперсоналу. Нагрузка по ставкам искажена требованиями исполнения майских указов президента и не соответствует фактической.

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

Для решения проблем спикер предлагает:
сформировать единую научно обоснованную систему управленческого мониторинга;
открыть данные для профессионального сообщества;
упростить и устранить дублирование отчётности;
изменить управленческий вектор с наказания на мотивацию;
упростить порядок оплаты медпомощи.

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

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

image

Генеральный директор Zecurion Алексей Раевский порассуждал о том, должен ли код быть открытым с точки зрения безопасности. По его мнению, нельзя однозначно ответить, ухудшает или улучшает ли безопасность открытие исходных кодов. Надо понимать, что в открытых кодах сразу же найдут много дыр, которые придётся оперативно закрывать.
Важно не то, как мы открываем алгоритмы и как их впоследствии сертифицируем, а важно то, каковы последствия использования этих алгоритмов. Не должно быть такого, что, например, штраф начисляется автоматически на основе решения алгоритма.


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



Директор АНО Информационная культура Иван Бегтин говорил об общественном контроле за алгоритмами в аспекте безопасности раскрытия кода. По его словам, большая часть госсистем на данный момент не использует умные алгоритмы, но переход к принятию решений на основе ИИ постепенно происходит и у них. Примеры тому Банк России, Росфин, Правительство. Там, где есть трансфер денег, это используют, резюмировал спикер. Хотя происходит это крайне непублично.

Пока государство приближается к использованию ИИ, компании его уже внедряют ИИ. Однако у государства есть проблема работа с уклоном в наказания.
Если дошёл до суда, тебя либо оштрафуют, либо посадят, но оправдан ты не можешь быть. Главная функция адвоката развалить дело до суда. Шансов, что тебя оправдают, мало. Что хорошего в алгоритме, у которого выборка будет изначально тебя посадить, размышляет Бегтин.


Однако нерелевантную выборку можно поправить. Для этого, к примеру, в ЕС разрабатывается стандарт проверки алгоритмов, по которому ответственность за ИИ несут его разработчики. Если система что-то неправильно распознала оштрафуют её авторов.
Раскрыть данные можно и нужно, убеждён Бегтин. Но в России пока некому проверять их и следить за искусственным интеллектом. Для этого нужно повышать квалификацию чиновников.

image

Глава юридической практики Роскомсвободы, управляющий партнер Digital Rights Center Саркис Дарбинян тоже посетовал, что юриспруденция не развивается экспертно, она давно уже не наука.

По его словам, депутаты действуют в духе Давайте примем закон, а подзаконные акты о том, как их применять, напишет правительство.


Население не особенно доверяет государственным информационным системам, потому что те не раскрывают протекающие внутри процессы. Мы только догадываемся, как всё работает, но кто, когда загружает данные, как использует, с какой целью не знаем. Это ярко иллюстрируют кейсы Сергея Межуева и Антона Леушина первые известные нам случаи ошибки распознавания лица.

Поэтому право должно развиваться постепенно, с учётом специализированных знаний. Это, кстати, одна из причин, почему РосКомСвобода требует ввести мораторий на массовое распознавание лиц: в этой области нет правового и социологического исследования, хотя понятно, под прицелом камерам человек ведёт себя по-другому, нежели без них. Присоединиться к кампании против распознавания лиц можно здесь.

Гости секции Гражданские инициативы по приватности и открытости в период пандемии коронавируса представили конкретные проекты, рассказали о проведённых ими исследованиях и тестах, и даже посвятили в детали расследования, касающегося утечек данных из госструктур. Подобное об этом читайте по ссылке ниже, а сейчас мы расскажем, что сделала непосредственно РосКомСвобода.



Журналист Андрей Каганских продолжил тему приватности и рассказал об утечках данных московской системы распознавания лиц и как благодаря РосКомСвободе в полиции раскрыли занимавшихся пробивом по лицу сотрудников. Он интересовался темой давно, предположив, что, поскольку данные из всех госсистем утекают, скорее всего, сольют их и с камер распознавания лиц. В ноябре 2019 года он обнаружил, что, хоть система и не была запущена в полном объёме, с неё уже появились утечки:

Работали всего 2% камер, но с них уже вовсю банчили данные на чёрный рынок.


Об этом стали писать СМИ, которым Департамент информационных технологий Москвы отвечал одно и то же, хотя это явно противоречило объективной реальности: Доступ к данным ЕЦХД [Единый центр хранения и обработки данных Москвы прим. ред.] имеют только уполномоченные сотрудники органов исполнительной власти и правоохранительных органов.

К началу пандемии система видеонаблюдения заработала полноценно. Весной данные на чёрном рынке стали доступны за 1 тыс. долл. За полгода чиновники так и не остановили утечки данных с московских камер. РосКомСвобода мониторила ситуацию всю весну, а летом провела эксперимент: волонтёр Анна купила полное досье на себя за 15 тыс. руб. Кроме того, выяснилось, что барыги на чёрном рынке на просьбу показать, как работает слив данных, предоставили данные шести человек просто в качестве примера. Если бы я был полицейским, это было бы шесть эпизодов в уголовном деле, сказал Каганских.

ДИТ отвечает, что система анонимна, но на деле возможны так называемые корреляционные атаки, когда фотографии сопоставляются с данными из других систем, в результате чего личность человека раскрывается. Так, в МВД есть система, которая сверяет изображения с данными из системы Российский паспорт. Получается, что анонимность системы по факту формальна. Можно использовать две системы и фото человека и на выходе получить досье на него.

В ноябре мэрия выделила 237 млн на реформу этой системы. Но можно израсходовать раз в 10 меньше денег на систему безопасности МВД, которая просто будет запугивать коррумпированных полицейских, которые сливают данные на чёрном рынке, считает Каганских. По его мнению, власти хотят исправить техническую часть системы, в то время как надо работать над юридической. Полиция, ДИТ не контактируют с людьми, поэтому расследование удалось провести благодаря тому, что полиция любит сливать данные на чёрный рынок и зарабатывать. Зарабатывать, кстати, гроши. Мы только догадываемся, как работает система распознавания лиц. К слову, это ярко иллюстрируют кейсы Сергея Межуева и Антона Леушина первые известные нам случаи ошибки этой системы.

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

В России есть огромная системная проблема со сливами: сотрудники силовых ведомств постоянно что-то сливают. Это значит, что службы безопасности МВД и ФСБ плохо справляются о своей работой.


image

Разработчик плагина CensorTracker РосКомСвободы Вадим Мисбах-Соловьёв представил инструмент для противодействия слежке в интернете.

CensorTracker умеет следующее:
определять наличие домена в реестрах ОРИ и заблокированных сайтов;
проверять блокировки по закону о суверенном Рунете;
предоставлять доступ к заблокированным доменам.

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

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

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

Мы гарантируем приватность пользователей, заявил Мисбах-Соловьёв.


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

Читайте подробные обзоры с секций по ссылкам ниже:
Открытость и приватность: дисбаланс между правами граждан и действиями государства в эпоху пандемии коронавируса здесь.
Открытые данные как инструмент общественного контроля борьбы с пандемией здесь.
Ответственные алгоритмы: как открытость способна повлиять на легитимность технологий в обществе? здесь.
Гражданские инициативы по приватности и открытости в период пандемии коронавируса здесь.
Подробнее..

Материалы Avito Design Talk видео и презентации

17.12.2020 18:19:07 | Автор: admin

Привет! Недавно прошёл наш митап для дизайнеров соспикерами изТинькофф, Циана иАвито. Ребята рассказывали про краудсорсинг, точки роста дизайнера, его значимости наразных скоростях работы команды иобсуждали сайд-проекты накруглом столе.


Под катом видеозаписи выступлений стаймкодами для удобной навигации иссылки напрезентации спикеров.



Точки роста для дизайнера вкрупной компании Настя Ларкина, Авито


Работа дизайнера намного больше, чем красивые картинки. Настя рассказала, как участвовала взапуске чат-бота Авито Работы, икакие точки роста нашла для себя накаждом этапе создания продукта отформирования consumer journey map дообщения сразработчиками иредакторами.



00:00 Представление темы испикера
01:44 Что такое Авито Работа ивчём еёглавный продуктовый челлендж
08:09 Customer journey map Работы
09:13 Проблема продукта иеёрешение
13:16 Создание интерфейса чат-бота: исследование
17:22 Передача макетов вразработку
21:12 Проверка решения наканареечных запусках
26:49 Осознанная работа стекстом иеёвлияние нарезультат
31:00 Вывод: точки роста для дизайнеров


Посмотреть презентацию Насти

Значимость дизайнера наразных скоростях разработки Алексей Кандауров, Циан


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



00:00 Представление темы испикера
06:52 Определения: что такое значимость иразные скорости работы
13:13 Если нет ограничений посрокам, апостановка задач нечёткая
14:16 Край спектра нормальной продуктовой разработки
15:12 Другой край спектра нормальной продуктовой разработки
16:20 Метод быстрых экспериментов growth hacking
18:06 Дизайн кодом
22:20 Чему нас учит дизайн-сообщество
26:30 Мифы продуктового дизайна икак насамом деле
30:42 Парадокс значимости


Посмотреть презентацию Алексея

Дизайн вкраудсорсинге икраудсорсинг вдизайне Владимир Погорелов, Тинькофф


Владимир рассказал, как устроен внутренний краудсорс-проект Тинькофф под названием Klecks, поделился способами улучшенияUX, когда упроекта нетUI, иснижения порога входа вприложения для программистов.



00:00 Представление темы испикера
00:37 Что такое краудсорсинг иKlecks
02:58 Эволюция интерфейсов Klecks
14:20 Краудсорсинговые UX-исследования Тинькофф
21:23 Какие тесты можно проводить накрауде
22:38 Начто обращать внимание накрауд-тестах


Посмотреть презентацию Владимира

Круглый стол Личные проекты дизайнеров


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



На этом всё. Увидимся нановых митапах!

Подробнее..

Небольшая подборка онлайн мероприятий 2020 года

01.01.2021 14:13:32 | Автор: admin

Всех хабравчан поздравляю с наступившим 2021 годом!

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

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

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

Надеюсь год 2021 окажется более подуктивным, успешным и будет легче для всех нас. Всем успехов и до встречи!

Подробнее..

Рецепт дня готовим сообщество профессионалов, не выходя из своего отдела

14.01.2021 10:07:09 | Автор: admin

Историями о профессиональных сообществах сейчас вряд ли кого-то удивишь. Гильдии образуют по разным причинам: кто-то из интереса, кто-то чтобы быть в тренде, а кто-то из-за недостатка общения на профессиональные темы. Это история о том, как бизнес-направление компании ЦФТ, Денежные Переводы Online, желая производить больше и быстрее, в очень короткий срок утроило штат инженеров, которых не успели нормально заонбордить, и в итоге чуть не уронили качество продукта и не сожгли ключевых членов команды.

Доклад в виде пошагового рецепта QA-лидам, fullstack feature team-лидам, SM и всем тем, кто решает задачу эффективной настройки процессов команд, представила на конференции TeamLead Conf 2020 Head of Android QA одного из флагман-продуктов компании ЦФТ Надежда Потаенко.

Продукт ЦФТ Золотая Корона в 2016 году прочно стояла на позиции самой крупной системы денежных переводов без открытия счета на территории России и СНГ. В момент, о котором пойдет повествование, у пользователей появилась возможность начать отправлять переводы не только офлайн, но и через веб и мобильные фронты.

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

Стало понятно, что продукт взлетел, и его надо срочно развивать. Именно высокая востребованность продукта заставила ЦФТ очень быстро вырасти. За три года команда разработки продукта Денежные Переводы Online увеличилась с 7 до 200+ человек. В какой-то момент старые производственные процессы просто перестали работать. Сотрудники вынуждены были отправиться на поиски новых конфигураций.

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

Для кого готовим?

Гильдия, о которой мы поговорим это 25 QA Android инженеров. Если вы не имеете отношения к качеству, это не страшно. Рекомендации, которые вы увидите здесь, легко портируются как на команду разработки, так и на команду аналитики. Информация может быть полезна даже agile-гуру и вообще всем людям, которые ищут точку опоры для создания профессионального сообщества, но пока что ее не нашли.

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

Что было в холодильнике?

Шел 2016 год, и в компании стал развиваться продукт, который начал активно зарабатывать деньги. Ранее этот продукт разрабатывала сравнительно небольшая команда из 20 человек (4 компонентные команды: Backend, Web, iOS, Android), все сидели в славном городе Томске и были экспертами в продукте. Казалось, все идет просто идеально!

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

Так много и быстро производить не получалось просто не хватало рук. ОК, просили получайте!

Настал 2018, и боги провозгласили год найма и новых рук. Компания начала расти, причем не только в Томске, но параллельно в Новосибирске и в Питере. На графике видно, что в конце 2018 появилось 130 инженеров в 3 локациях, а в 2019 их стало больше 200. Это около 30 команд, которые сейчас совместно пилят один и тот же продукт: Денежные Переводы Online.

От такого роста ожидали увеличение скорости разработки и сокращение TTM, но получили совершенно иную картину.

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

Почему так получилось? Команда разработки росла быстрее, чем в ней адаптировались процессы.

  • Не успевали качественно онбордить

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

  • Разный уровень hard skills в разных локациях

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

Например, в Томске инженеры предпочитали вести тестовую документацию в виде чек-листов и подробно там ничего не расписывать. В Питере считали, что это хаос и вред, и каждое ответвление flow должно быть покрыто стопочкой тест-кейсов.

Другой пример: в Новосибирске инженеры считали, что побегать за аналитиком и дожать из него недостающую информацию это ОК. В Питере ребята сказали: Ну нет! Должен быть четкий Definition of Ready. Мы ни за кем бегать не будем!

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

  • Релизила по-прежнему одна команда

Главная боль всего 2018 и части 2019 года заключалась в том, что несмотря на увеличение количества команд, которые в изоляции друг от друга производили вполне годные фичи, стабилизацией, сборкой, багфиксингом, поставкой в прод занималась по-прежнему одна и та же релиз-команда. Конечно, она не могла качественно пропустить через себя такой объем производства.

Выпуская релизы раз в 2-3 недели, члены команды горели на работе, потому что жили там до 2 часов ночи. Они почти ненавидели новых людей, которых зачем-то кто-то нанял.

В какой-то момент Надежда поняла, что надо спасать коллег по цеху.

Шаг 1: Перемешать и поставить на плиту

Первым шагом стало привлечение к процессу регрессионного тестирования и вообще к релиз-производству QA инженеров из фича-команд, которые раньше в этом процессе не участвовали, для того, чтобы:

  • Повысить степень причастности и ответственности;

  • Выровнять уровень понимания бизнес-логики продукта.

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

Шаг 2: Довести до кипения

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

Например, что-то тестили, попали на незнакомый flow, испугались, завели баг, кинули его в чат Android: кто-нибудь потом разберется. А на самом деле просто заехала новая фича, поменялся flow, а тест-кейсы еще не актуализировали.

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

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

Как тушить все это, было непонятно.

Шаг 3: Остудить, еще раз перемешать

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

  • Выработать единый подход к регрессу;

  • Найти способы ускорить регресс;

  • Восстановить качество релизов;

  • Делиться друг с другом экспертизой в продукте.

Все QA в команде Денежных Переводов Online находятся в своих фича-командах. В каждом спринте у них есть собственные sprint goal. Но понимания, зачем QA-инженеры из этих обособленных фиче-команд раз в две недели собираются все вместе в трех локациях, чтобы кому-то помогать, ни у кого не было. Надежда решила начать сначала, и собрать всех очно в одной локации.

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

А еще ей хотелось сформулировать цель совместной работы.

Летом 2019 года все собрались и познакомились, после чего родилась цель: выпускать качественный продукт быстро, чтобы заказчик и пользователи были довольны.

Качественно и быстро это отсылки к желаемому сокращению ТТМ и к восстановлению уровня качества.

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

Мозговой штурм был построен на базе книги 5 пороков команды Патрика Ленсиони. И на него было потрачено около 8 часов.

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

Когда участники встречи разъезжались, заряд community был такой мощный, что все говорили: Эге-гей! Да мы следующий регресс вообще за день бахнем!.

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

Шаг 4: Выпекать до готовности

В команде Денежных Переводов Online договорились проводить регулярные встречи гильдии раз в 2 недели.

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

Но не релизами едиными живет ДП Online. В течение обычных двухнедельных спринтов сотрудники пишут тест-кейсы, занимаются ревью кода автотестов, тестируют требования. И в этом производственном цикле возникают вопросы, по которым хочется посоветоваться с коллегами или набросить optimise на какой-то процесс. Обсуждению таких инициатив, вопросов, болей решили посвятить вторую часть регулярных встреч гильдии.

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

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

Канал коммуникации очень простой: QA-инженеры раз в две недели встречаются онлайн в Microsoft Teams.

За счет таких встреч им удалось выработать единый подход к регрессу и найти способы ускорить его.

Осторожно! Горячо!

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

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

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

Шаг 5: Сбрызнуть соком лимона

Сообщество - это не всегда только про решение проблем. Это неизбежно история про обучение и QA-сообщество ДП Online не исключение. Например, кто-то хочет научиться пользоваться снифферами, а кто-то мечтает, чтобы ему объяснили, как безболезненно протестировать пуши на интеграции. Такие запросы есть всегда. Самое главное, что по востребованным темам есть эксперты, и нужно лишь решить вопрос формата подачи информации.

Надежда решила устроить получасовые обучающие митапы во время созвонов гильдии.

В команде появился такой wishlist:

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

Но проблемы начались с самого первого митапа.

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

С тех пор в команде договорились, что все на 100% должны четко понимать, что именно будет обсуждаться.

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

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

Шаг 6: Дать отдохнуть

В ДП Online решили отправлять сотрудников в командировки для того, чтобы они начали встречаться не только онлайн, но и лично. Когда появилась страничка графика поездок, очередь туда выстроилась до конца 2020 года. И все, естественно, хотели в Питер, ведь две другие локации находились в Сибири.

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

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

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

Профиты командировок:

  • Для продукта: быстрый шаринг экспертизы;

  • Для инженеров: сменить обстановку, пообщаться с иногородними коллегами.

За счет командировок сотрудникам QA-сообщества ДП Online удалось выработать единый подход к регрессу и найти способы ускорить его, восстановить качество релизов и делиться друг с другом экспертизой в продукте.

Что дальше?

В 2020 году в ЦФТ появились новые цели саморазвития гильдии.

  • Коммуникация с QA-гильдиями других платформ продукта;

Если в 2019 году сотрудники команды притирались и учились друг с другом общаться, то сейчас внутри Android community очень теплая и уютная атмосфера. Но там готовы раздвинуть границы и подсмотреть, что происходит у других сообществ. Уже запланированы встречи кросс-платформенного community.

  • Ежемесячные публикации блога с обзором новостей платформы и сообщества.

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

Есть и продуктовые цели.

Если раньше в ДП Online существовал басфактор в виде единой выпускающей команды, то теперь он исчез. Тем не менее, процесс релиза непрозрачный, очень тяжело онбордить в него людей. Поэтому стоит цель однозначно работать над его упрощением и над снижением порога входа в проект автотестирования. А еще могут потребоваться новые hard skills, ведь продукт компании динамичный.

Выводы в цифрах и фактах

На картинках активности, которые пробовали применять в QA-сообществе ДП Online.

Рост качества, произошедший на почве работы сообщества, напрямую отразился на количестве hot fixов на число выпущенных версий.

И немного статистики релизов продукта за 2018-2019 годы. Внизу красным подсвечены hot fixы. В 2018 году в ДП Online было нормой раз в 3-4 релиза выпустить hot fix. С 2019 года, когда начала собираться гильдия экспертов, hot fixов почти нет. За весь 2019 год выпустили всего 4. Причем речь не о клиентских, а о технических hotfixах, например, когда какое-то событие было потеряно в Google Analytics.

Кроме того, активности, которые были направлены на решение продуктовых проблем, принесли несколько положительных сайд-эффектов:

  • Тюнинг soft skills;

  • Единое информационное поле;

  • Здоровая конкуренция;

  • Новые лиды.

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

Программный комитет Saint TeamLead Conf 2021 ждет ваши доклады.

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

Присоединяйтесь!

Подробнее..

Есть ли жизнь без Auto Layout?

24.12.2020 16:21:15 | Автор: admin
Технология Auto Layout появилась в 2012 году, но споры и дебаты о том, как правильно верстать интерфейс, не утихают до сих пор. Использовать ли Auto Layout интерфейс в билдере или в коде? Верстать без него на фреймах или вообще использовать что-то стороннее? Тема такая горячая, что обсуждение докладов в кулуарах на эту тему часто проходит на повышенных тонах у каждого есть свое мнение на этот счет. Сейчас, 8 лет спустя, вопрос всё ещё актуален, к тому же появились новые технологии и библиотеки для верстки.

На профессиональной конференции разработчиков мобильных приложений Apps Live 2020 был круглый стол с представителями Юлы, проектов VPROK и DeliveryClub. Мы обсудили все эти вопросы, а также быстрее и удобнее ли с AL или все-таки можно решать вопрос скорости другим способом.




Начал дискуссию Семен Мацепура из VPROK.

Семен Мацепура (vprok.ru): Сначала расскажу про наше приложение. Полгода назад мы приняли решение написать с нуля приложение конкретно под интернет-магазин. У нас был довольно сжатый срок написать MVP примерно за 2 месяца, и мы решили сделать упор на архитектуру. Выбор пал на архитектуру RIBs, чтобы в дальнейшем мы могли поддерживать проекты, масштабироваться и расти.

При этом мы понимали, что на старте в MVP у нас будут более-менее легкие экраны с довольно легкой анимацией. Поэтому мы решили использовать Auto Layout без сторонних библиотек, потому что на тот момент это было более легким в поддержке, чем фреймы. И позволяло нам создавать легкие анимации в 2 строки кода.

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

Передаю слово своему коллеге Александру.

Александр Канчурин (vprok.ru): Дополню Семена по архитектуре. Команда у нас была разнородная. И было важно, чтобы каждый мог понимать, что происходит в любом месте кода. А с Auto Layout все были знакомы, было интуитивно понятно, как на нем верстать будь то просто констрейнты в коде или же XIP файлы. К тому же с помощью Auto Layout можно лаконично верстать и сложные интерфейсы.

Да, проблемы с ним конечно же есть. Но не на всех экранах есть, например, проблемы с FPS. Когда мы получили на 2% экранов просадку по FPS, мы провели исследование внутри команды и выяснили, что Auto Layout не на первом месте среди этих проблем. Среди проблем были: подготовка данных для отображения и King-Phisher (на удивление), вместо которого мы собираемся использовать механизмы URLSession.

Да, может быть, там, где у нас действительно есть проблемы из-за Auto Layout, мы будем использовать фреймы, но это меньше 2% наших экранов. Поэтому пока мы не видим смысла переходить на фреймы с Auto Layout все легко решается и всем все понятно.

Хорошо, это мы услышали одну позицию. А пока перейдем к Юле, у которой чуть более радикальный подход к разработке. Павел?

Павел Тихонов (Юла): Да, у нас более радикальный подход в том смысле, что мы вообще не используем Auto Layout. Он еще есть в проекте, потому что это куски legacy, но когда мы туда доберемся, мы его выпилим полностью.

Объясню, почему. Мы используем не голые frame, а сторонние библиотеки для удобной работы с ними. Две из них это PinLayout и FlexLayout обертки как раз над фреймами, которые позволяют декларативно объявлять весь интерфейс. Из-за этого, на начальном этапе у нас чуть-чуть выше порог вхождения, потому что человеку, как минимум надо разобраться с самой библиотекой. Но в будущем мы имеем код-ревью проще. Я смотрю код на Swift, а не открываю какой-нибудь XIB/Storyboard и не просматриваю xml.

Да, не спорю, можно использовать констрейнты в коде. Но нам без них проще жить я не пытаюсь представить в голове, как эти констрейнты просчитаются, как разойдутся, разъедутся и т.д. Я просто читаю Swift и вижу, как объявлены view относительно друг друга, как они позиционируются внутри за меня pin или flex посчитают фреймы, константы и т.д.

Тут еще вопрос в чем у нас минимальное iOS, которое поддерживается это 10.3, а это iPhone 5. А у нас, во-первых, много вариантов Layout, во-вторых, они все комплексные, сложные одновременно списки товаров отображаются не только на первой вкладке, но имеется, как минимум, три вида отображения этих списков. И с этой точки зрения уход от системы именно этого движка дает нам прирост даже на Айфон 5.

Понятное дело, это не дает какого-то супер-плавного layout, который мы видим на iPhone 11 Pro (сейчас уже 12). Но сильно помогает сделать так, чтобы все-таки FPS не проседал, не фризился интерфейс и так далее.

Передаю слово моему коллеге Андрею Опарину.

Андрей Опарин (Юла): Я дополню про Auto Layout. Когда у нас действительно очень сложные вьюшки и нужно, например, что-то скрыть/что-то показать, то довольно сложно обновлять эти констрейнты. Это либо сразу несколько констрейнтов надо обновлять, либо высоту в 0 ставить, отступы убирать и все такое. И без Auto Layout мы по одной модели можем отрендерить, пролейаутить Layout в одном месте: что нужно скрыли, что нужно показали. Например, FlexLayout это очень хорошо позволяет делать.

Второй момент, что очень часто независимо от того, на чем мы верстаем, нам нужно в какой-то момент рассчитывать размеры. Наиболее часто мы хотим рассчитать высоту. Кто-то считает это относительно контента например, высоту строки через bound rect. Я опишу наш подход на примере UI-label. Мы ставим какую-нибудь ширину и вызываем sizeToFit и относительно этой ширины рассчитывается высота. Точно также мы можем сделать наоборот установив высоту, вызвать sizeToFit, и у нас рассчитается ширина.

Такой же подход у нас к дереву вьюх. Мы можем взять опорную ширину, и в sizeToFit уже есть опорная ширина и начальная точка origin 0,0. Мы можем в одном методе Layout расставить все наши элементы относительно точки 0,0, относительно опорной ширины, залейаутить все наши элементы, взять max Y последнего, и получить высоту нашей вьюхи.

ОК. Перейдем к третьей команде. Это DeliveryClub. Ее представляет Кирилл. Кирилл, какие у вас подходы?

Кирилл Шаханский (DeliveryClub): У нас подход дефолтный, потому что, мне кажется, использование Auto Layout это то, что приходит в голову в первую очередь. То, что мы пользуемся преимущественно нативными инструментами, нам помогает еще при найме новых сотрудников, иначе бы это было некой проблемой. То есть в целом я на стороне добра Auto Layout, мы его используем по максимуму, кроме очень сложных кейсов, как, например, transitions и, возможно, анимация.

Тогда следующий вопрос ко всем. Мы говорим, что да, Auto Layout срабатывает, но есть какие-то сложные экраны, где что-то идет не так. Вопрос: что является сложным экраном, как вы это замечаете, используете ли какие-то метрики? Или это просто визуально определяется? Опишите, что происходит в таком сложном случае и как вы действуете при этом.

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

Александр Канчурин (vprok.ru): У нас классический пример сложного экрана это коллекции внутри коллекций. Это горизонтальные списки, например, карточек продуктов в каком-нибудь каталоге. Но мы проводили измерения с помощью инструментов в Xcode и убеждались в том, что Auto Layout на последнем месте.

Кирилл Шаханский (DeliveryClub): Здесь опять же вопрос да, AutoLayout на последнем месте, но насколько это отставание видно для пользователя? У нас iOS 12 (мы совсем слабые устройства не поддерживаем), но коллекции в коллекциях активно используются, и каких-то особых просадок не наблюдаем.

Александр Канчурин (vprok.ru): По нашему опыту, для пользователя очень сильно заметно было, когда мы неправильно данные подготавливали. После того, как подготовку данных изменили, стало намного лучше и лишь где-то иногда местами пролаги случаются. То есть, да, Auto Layout вместе со скрин-рендерингом на это сильно влияют. Поэтому мы хоть и топим за Auto Layout, но признаем, что у него есть проблемные места, и там, возможно, мы будем использовать и считать голые фреймы. К тому же это довольно просто получается.

А коллекции в коллекциях у вас прямо реюзаются? Например, есть ячейка с коллекцией она прямо при реюзе проседает или как?

Кирилл Шаханский (DeliveryClub): У меня есть опыт в двух проектах с разными подходами. В текущем проекте при расчете таких вещей у нас каждая вьюха сама считает размер внутренней коллекции, а внешняя коллекция запрашивает у ячейки ее размер для конкретной модели. View может рассчитать свой размер на основании состояния, которое зашито во view-модель, и она его считает, условно говоря, ручками. Так как расстояние между своими элементами вьюха знает тот же лейбл она считает через bound rect или через sizeToFit то размер коллекции она тоже может знать.

Более интересно у нас было в предыдущем проекте, где мы использовали тоже нативный API systemLayoutSizeFitting. Там мы создавали вьюшку, конфигурировали ее с помощью view модели и накладывали констрейнты. И, в зависимости от направления скролла коллекции, если мы знаем фиксированные ширину (чаще всего) или высоту, systemLayoutSizeFitting достаточно быстро все считает и лагов не вызывает. Например, в случае коллекция в ячейке мы загружали данные, вызывали layoutIfNeeded, коллекция выставлялась и считался contentSize. И это было достаточно быстро.

Ещё вопрос к Юле. Павел говорил, что все еще есть legacy с Auto Layout. То есть в какой-то момент произошел переход от Auto Layout к новому подходу. Расскажи поподробнее, как это случилось и почему? Это произошло из каких-то лагов, проблем в приложении? Или вы просто решили, что так удобнее?

Павел Тихонов (Юла): Когда у нас был Auto Layout, у нас было много подходов. Мы использовали XIBы и сториборды, могли констрейнты расставлять руками (тогда еще не было якорей). Еще был Visual Format Language, когда описываешь строкой констрейнты, и потом они создаются. И, несмотря на мощные на тот момент девайсы, мы начали наблюдать появление лагов, подергиваний на нашей выдаче, а именно на список товаров интерфейс становился комплексным, сложным. Помимо правильной верстки мы меняли и подготовку данных часть в фон переводили, часть считали по-другому, что-то заранее просчитывали. После этого стало получше, но те же подёргивания как были, так и остались. Все это вместе подтолкнуло нас к тому, чтобы отказаться от Auto Layout и сказать: Нет, спасибо, с нас хватит, мы перейдем на фреймы.

Кстати, известный iOS-разработчик Питер Штейнбергер писал в Твиттере, что если вы Bank of Amerika, то вы получите от UIKit, в том числе от Apple, дополнительные выставления setNeedsLayout/layoutIfNeeded в каких-то случаях. Это немного смущает, потому что движок Auto Layout снова начнет все эти расчеты, пересчеты и т.д., что может повлиять на перфоманс.

Хорошо. Давайте закончим с библиотеками Flex и Pin. Расскажите про порог входа? Насколько сложно адаптировать новых ребят, сколько уходит на это времени?

Андрей Опарин (Юла): PinLayout это библиотека, чтобы руками фреймы не высчитывать, в ней легкие конструкции. Таких библиотек на GitHub, наверное, тысячи и в ней ничего особенного нет.

FlexLayout да, тут порог входа повыше, потому что FlexLayout основан на кроссплатформенном фреймворке Yoga. FlexLayout напоминает верстку Swift UI тоже на стеках, примерно также позиции рассчитываются. Есть, конечно, нюансы например, нужно ставить приоритеты как в Auto Layout (сжатие-расширение). Это может по началу путать, сам иногда забываешь про это.

Внутри FlexLayout работает от листьев по сути. Он рассчитывает размеры всех вьюх тоже через sizeToFit (у которых есть внутренний размер). Потом идет наверх, все это собирает и расставляет все отступы. В результате мы там одним методом Layout получаем все рассчитанные фреймы.

Павел Тихонов (Юла): Но мы не наблюдали сложностей с порогом вхождения у ребят в команде никому не приходилось разбираться днями, ночами и неделями. К тому же, если ты застреваешь на FlexLayout, то можно использовать его с PinLayout или даже вообще перейти только на него, он очень простой. У нас был случай, когда новый человек в команде за день собрал ячейку для коллекции, задав всего пару вопросов.

Андрей Опарин (Юла): Но проблемы есть и во Flex. У него есть некое неявное поведение. Например, когда у нас горизонтальный стек в вертикальном стеке, и мы в горизонтальный стек положили какой-нибудь лейбл и картинку, то в некоторых ситуациях он почему-то не ограничивает этот горизонтальный стек внешним. Это тоже может иногда путать. Но это, скорее, баги в самом Flex. Например, у каждой ноды есть свойство display. И если мы отключаем display, не отображая элемент, то FlexLayout не скрывает его, а просто фрейм в 0 ставит. Но если мы поставим фрейм в 0 у какой-нибудь кнопки, у нее внутри будет лейбл, и без script to bounce у нас будет этот лейбл отображаться. Проблем в FlexLayout не так много, но это тоже может запутывать.

Вы упомянули про Swift UI. Как вы считаете, решит ли это наши проблемы с Layout или только еще запутает сильнее?

Семен Мацепура (vprok.ru): Думаю, Swift UI в массы, скорее всего, придет только через пару лет, так как большинство проектов там поддерживает две версии ниже, чем актуальные iOS. Соответственно, до этого момента всё еще поменяется десять раз, и, возможно, довольно кардинально. Поэтому мы пока к нему присматриваемся и делаем это очень аккуратно.

Александр Канчурин (vprok.ru): Я бы еще добавил, что для нас переход к Swift UI будет равносилен переделыванию некоторых слоев архитектуры, а это повлечет за собой немалые последствия, поэтому нужно будет больше времени для разработки.

Кирилл Шаханский (DeliveryClub): У нас, наверное, аналогичная ситуация. Даже если мы поднимем версию, вряд ли мы будем активно на него переходить. Но кажется, SwiftUI может решить проблему и быстрой верстки, и быстрого обсчета. В стадии production Swift UI может стать стандартом де-факто.

Андрей Опарин (Юла): Я тоже пробовал Swift UI. Там классная, всегда валидная верстка. Единственное, что после последнего TTDC, когда обновили SDK, они добавили пару компонентов и поставили им iOS 14. Это обычная практика у них, но мы могли бы собрать новые элементы и для iOS 13. Вторая проблема у них с навигацией, то есть в случае present нескольких экранов, вызывая dismiss для закрытия двух или трех. То же самое с navigation-стеком. Как это нормально делает Swift UI, я пока не понял но можно, например, пробрасывать какие нибудь флаги, для того, чтобы понять до какого экрана закрывать стэк.

Последний вопрос: Есть ли жизнь без Auto Layout?

Павел Тихонов (Юла): Конечно, она есть. И в Юле можно наблюдать это каждый день. И, да, жизнь без AutoLayout не становится сложнее, больнее, хуже или еще как-то. Местами, она становится даже проще. А если говорить про поддержку прошивок и девайсов пятилетней давности, то и плавнее.

Работа над программой докладов весенних конференций уже идёт: 22 декабря Программный комитет FrontendConf встречался онлайн со спикерами, а в пятницу, 25 декабря, в 19:00 состоится встреча докладчиков и ПК DevOpsConf.
Подключайтесь сами или перешлите своим докладчикам!

Для 2021 года мы подготовили 14 конференций, в том числе и перенесенных с этого года. Смотрите план наших конференций на весь 2021 год с датами закрытия Call for Papers.
Изучайте, подбирайте конференцию для себя!
Подробнее..

Серия вебинаров по серверной разработке на Kotlin

07.12.2020 14:17:59 | Автор: admin
Все больше инженеров выбирают Kotlin для разработки серверных приложений. Полная совместимость с Java, корутины и высокая безопасность делают Kotlin отличным инструментом для подобных задач.

Мы организуем серию вебинаров (на английском языке), где расскажем о разработке бэкенда на Kotlin в сочетании с технологиями Apache Kafka, Spring Boot и Google Cloud Platform. Вебинары подойдут для Kotlin- и Java-разработчиков любого уровня подготовленности, в том числе для разработчиков мобильных приложений без опыта серверной разработки.

Kotlin и Apache Kafka, 10 декабря 2020, 19:30 20:30 МСК
Kotlin и Google Cloud Platform, 17 декабря 2020, 19:30 20:30 МСК
Kotlin и Spring Boot, 14 января 2021, 19:30 20:30 МСК

Подробнее о каждом из вебинаров читайте ниже.


Kotlin и Apache Kafka


image

Зарегистрироваться

O чем этот вебинар?


Виктор и Антон покажут, как использовать Apache Kafka в сочетании с Kotlin для управления потоками данных. Презентация также даст обзор внутренней архитектуры Apache Kafka.

Спикеры:
  • Антон Архипов, Developer Advocate в команде Kotlin, JetBrains
  • Виктор Гамов, Developer Advocate, Confluent

Когда состоится вебинар?


10 декабря 2020
19:30 20:30 МСК
Подробная информация

Kotlin и Google Cloud Platform


image

Зарегистрироваться

О чем этот вебинар?


На вебинаре мы расскажем, как применить Kotlin в проекте с кодовой базой на Java, поговорим о таких возможностях Kotlin, как корутины, и продемонстрируем процесс развертывания приложения на Google Cloud.

Спикер: Джеймс Уорд, Developer Advocate, Google Cloud Platform

Когда состоится вебинар?


17 декабря 2020
19:30 20:30 МСК
Подробная информация

Kotlin и Spring Boot


image

Зарегистрироваться

О чем этот вебинар?


В ходе вебинара Рэй поможет вам создать бэкенд-сервис с использованием Spring Boot и Spring Cloud GCP и покажет полезные сервисы Google Cloud для баз данных, хранения и мониторинга состояния. Когда приложение будет готово, Рэй покажет, как с помощью Google Cloud Platform сделать из него бессерверный сервис, и продемонстрирует возможности автоматического масштабирования.

Спикер: Рэй Цанг, Developer Advocate в Google Cloud Platform и Java Champion

Когда состоится вебинар?


14 января 2021
19:30 20:30 МСК
Подробная информация

После регистрации вы получите письмо с подтверждением и приглашением, которое сможете добавить в календарь. Мы пришлем вам напоминание за день до начала вебинара.

Все вебинары бесплатные. Записи будут доступны на канале JetBrains TV в Youtube. Подпишитесь на JetBrains TV, чтобы не пропустить появление записей.

Узнайте больше о бэкенд-разработке на Kotlin


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

Ваша команда Kotlin
The Drive to Develop
Подробнее..

Epic Scrum Fails предновогодний скрам-стендап

11.12.2020 16:14:18 | Автор: admin
Встретимся 15 декабря и вместе посмеёмся над историями скрам-мастеров, помня, что в каждой шутке есть своя мораль. В программе вредные советы от Сбера, МТС, Альфа-Банка, ОТП и Райффайзенбанка.

Присоединяйтесь к нам!



О чем будем говорить


Что бывает, когда 8 шапок скрам-мастеравстречаются с реальной жизнью!

Наташа Епейкина, Райффайзенбанк

От создателей это не на нашей стороне и в Jira этого не было.

Фейлы скрам-команд, и что можно с этим сделать

Росянок Виталий, МТС

Фейлы, с которыми встречаются все скрам-мастера. Обсудим тривиальные косяки скрам-команд в комичной форме, увидим себя и разберём варианты решений.

Молотки, гвозди и парное программирование

Арсений Кельдышев, Райффайзенбанк

История о нанесении добра и несусветной пользы.

Как перестать волноваться и начать жить СМу?

Екатерина Шевченко, ОТП Банк

На что похожи взаимоотношения СМ и команды? Два кейса из реальной практики.

Сейчас смешно, а раньше было поучительно

Никита Щербаков, Сбер

Важные истории из жизни СМа и команды, над которыми сейчас можно посмеяться.

Самые Большие Ошибки Скрам-мастера

Сергей Макаркин, Альфа-Банк

Как гарантировать провал Agile и привить сотрудникам отвращение к Scrum.

>>> Начнем митап в 19:00 (МСК).
Регистрируйтесь, чтобы получить ссылку на трансляцию: письмо придет вам на почту.

До встречи онлайн!
Подробнее..

Три проекта с Премии Рунета, которые помогут с интересом провести время

07.12.2020 16:06:42 | Автор: admin


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

О них под катом.

My Big Love все про вино




Самым неожиданным номинантом для меня лично стал винный проект, который называется My Big Love. Он, кстати, победил в номинации Здоровье и отдых.

Это онлайн-витрина вина, которую разработчики называют winetech-проектом. Интересно, есть еще что-то из этой отрасли? Кроме, конечно, приложения Vivino о нем я знаю давно и пользуюсь с момента появления. Было бы неплохо, если бы Winetech-отрасль активно развивалась.

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

Интересный момент во всем этом наличие истории выпитого вина. Сервис My Big Love показывает, что вы пили и когда. Ассортимент пока включает около 600 наименований, через какое-то время разработчики обещают увеличить это количество до 5000.

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

Игрология


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

Есть и вариант для любителей гаджетов проект предлагает оценить цифровую платформу для настольных игр с поддержкой основных платформ, включая PC, iOS и Android.



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

Плюс ко всему, проект выпускает и собственные настольные игры. В портфолио около 40 самых разных игр, среди которых есть весьма популярные. Это Свинтус и Данетки. К Свинтусу иллюстрации рисовал Вася Ложкин, это сразу видно.

Островок




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

Компании в этом году исполнилось 10 лет, так что свою премию она получила заслуженно. За время своего существования она заключила большое количество договоров. Сейчас в базе Островка более 130 тысяч объектов, и база постоянно растет.

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

Вот такие три проекта мне понравились. В списке номинантов есть и другие компании, но мне больше всего понравились те, которые помогают переносит тяготы пребывания на карантине.
Подробнее..

Удаленная работа с Microsoft Teams Microsoft 365 Virtual Training Day

08.12.2020 10:15:01 | Автор: admin
Чтобы работать в удаленной среде, сотрудники должны иметь возможность безопасно взаимодействовать из любого места. Наше онлайн-мероприятие Microsoft 365 Virtual Training Day: удаленная работа с Microsoft Teams поможет вам предоставить удаленным сотрудникам инструменты, ресурсы и решения, необходимые для поддержания связи и продуктивности.

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

Во время этого тренинга, состоящего из двух частей, вы узнаете, как:

  • Давать возможность коллегам встречаться и сотрудничать из дома
  • Создавать приложения для повышения производительности, доступные на любом устройстве
  • Обеспечить лучший удаленный пользовательский интерфейс

Когда: 17-18 декабря
Язык: английский с субтитрами на русском

Регистрация



Вот чего можно ожидать:
Введение Введение
Обзор Microsoft Teams в Microsoft 365 Создание и управление командами
Перерыв: 10 минут Перерыв: 10 минут
Внедрение управления, безопасности и соответствия Microsoft Teams Управление совместной работой в Microsoft Teams
Перерыв: 10 минут Перерыв: 10 минут
Подготовка среды для развертывания Microsoft Teams Manage communication in Microsoft Teams
Завершение Завершение
Подробнее..

Конференция Demo Day новое образовательное мероприятие OTUS

08.12.2020 18:19:49 | Автор: admin

11 декабря вас ждет 6 лекций по разным IT-направлениям: программирование, тестирование, Data Science, управление и информационная безопасность. Участие бесплатное. Подробнее о формате рассказываем в статье.

За время существованияOTUSмы успели поэкспериментировать с разными мероприятиями. У нас были митапы в офисе, карьерный интенсив и CTF-соревнования. На регулярной основе проводим практикумы, открытые занятия и дни открытых дверей.

А сейчас у нас родилось желание проводить ивенты, которые бы олицетворялиOTUS. То есть объединяли бы все наши направления, преподавателей и студентов. Как раз в таком фестивальном формате пройдет в пятницу 11 декабря онлайн-конференция Demo Day.


За почти четыре года существования Отус накопил приличный капитал это наши преподаватели и их знания о самых последний кейсах индустрии. Мы хотим начать делиться с сообществом этими знаниями, нам кажется, что это полезный и необходимый вклад в развитие IT-специалистов, в рост их компетентности. Приходите и оцените!

Дмитрий Волошин

основатель OTUS


Что вас ждет в программе Demo Day?

17:30 - 18:00Ведущий мероприятия харизматичныйблогер Лекс АйТиБорода. Он откроет мероприятие, выступит модератором докладов и подведет итоги.

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


18:00 - 18:40Тестирование.

Тема:Тестирование мобильных приложений. Альтернативы реальным девайсам.

Вы рассмотрите все альтернативы с их плюсами и минусами, облачные фермы, локальные фермы, реальные устройства, эмуляторы/симуляторы.

Спикер:Наташкин Александр, Head of Mobile QA at ЮMoney (ex Яндекс.Деньги). 12 лет опыта работы в сфере IT, более 7 из них в QA.


18:40 - 19:20Программирование

Тема:Боли и прелести GraphQL на примере реальных проектов

Вы рассмотрите реальные кейсы внедрения GraphQL, возникнувшие в них проблемы и их решения. Также преподаватель расскажет, как с этим работать на NodeJS.

Спикер: Антон Морев, Wormsoft, основатель и IT-директор. За годы работы ему удалось выполнить множество как обычных, так и нестандартных задач, которые мотивируют к постоянному изучению изменяющихся технологий.

Как основатель и IT-директор Антон контролирует все процессы разработки в компании и занимается внедрением решений по оптимизации процессов.


19:20 - 20:00Data Science

Тема:Строим мосты между 2D и 3D данными с помощью Pytorch3D

На докладе вы с экспертом посмотрите на конкретные кейсы применения Pytorch3D для работы с облаками точек и 3d мешами, с обзором доступного функционала и с базовым объяснением терминов. Особое внимание уделим дифференцируемому рендеру. Доклад будет интересен тем кто интересуется работой с 3D данными, но не сталкивался ранее с Pytorch3D.

Спикер: Женя Ческидова, Deep Learning Engineer в Wolf3d, Таллин. Сейчас работает над технологией восстановления 3Д-меша лица по одной фотографии. Главная сфера интересов в глубоком обучении в настоящий момент работа с 3D-данными.


20:00 - 20:40Управление

Тема:Техники продуктивной корпоративной коммуникации

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

Встреча будет полезна тем, кто:

1. Чувствует хаос в поступающей информации

2. Испытывает проблемы с ненужными встречами (где половина сотрудников сидят, уткнувшись в телефоны)

3. Сталкивается с нарушением границ в рабочем общении

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

Спикер: Александр Пряхин, технический директор в CityAds Media. В профессиональном программировании прошел долгий путь от Junior Developer до CTO. Разработал различные обучающие курсы: от изучения языка PHP до построения масштабируемых систем и архитектур.


20:40 - 21:20Тестирование, MySQL

Тема:Пример оптимизации производительности в 32 раза

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

- нагрузочное тестирование

- оптимизация систем

- MS SQL

- Очереди

- .Net

- Анализ производительности

Спикер: Виктор Ганелес, эксперт по тестированию производительности ПромСвязьБанк. Более 6 лет занимается тестированием производительности в крупных банках. Постоянный спикер крупных международных конференций (SQA Days и прочие)


21:20 - 22:00Информационная безопасность

Тема:Методы внедрения вредоносного кода

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

Спикер: Артур Пакулов, ex-вирусный аналитик в Kaspersky Lab. Специалист в области низкоуровневого программирования, обратной разработки и анализа вредоносного программного обеспечения.


Для нас это новый формат, поэтому нам будет очень важно получить от участников обратную связь и идеи. В апреле мы планируем провести более масштабный ивентOTUS Fest, который будет длиться 3 дня и предложит участникам еще больше полезных докладов.

Ждем вас!Регистрация на Demo Day бесплатная. Планируете ли вы посетить конференцию? Какие темы вам интересны?

Подробнее..

Гибридные облачные технологии, как основа для успешной цифровой трансформации

09.12.2020 16:05:25 | Автор: admin
17 декабрясостоится ключевое онлайн-событие от Microsoft Microsoft HYBRID Cloud Forum,
Который будет состоять из двух паралелльных сессий:

  • Microsoft Azure track. Интеграция Microsoft Azure в локальную инфраструктуру.
  • Modern Workplace track. Организация современного виртуального рабочего места.

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

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

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

Подробности о программе под катом.

Регистрация



В начале форума участников ждет общая пленарная сессия:

  • 09:5510:00 Сбор гостей
  • 10:0010:10 Azure глобальная стратегия, Марк Руссинович, CTO Azure, Microsoft
  • 10:1010:25 Стратегические инициативы и анонсы, Кристина Тихонова, президент, Microsoft Russia / Дмитрий Халин, член правления, вице-президент по облачным и цифровым решениям, ПАО МТС
  • 10:2510:40 Использование технологий Bing Cognitive Search для виртуальных смарт ассистентов, Анастасия Данилина, исполнительный директор по стратегическим партнерствам, ПАО Сбербанк / Александр Липкин, директор департамента технологического развития и поддержки ключевых заказчиков, Microsoft Russia
  • 10:4011:10 Облака Microsoft и российское законодательство: можно ли совместить и как правильно это сделать, Михаил Емельянников, эксперт в области информационной безопасности и безопасности бизнеса, управляющий партнер консалтингового агентства Емельянников, Попова и партнеры

После пленарной сессии форум будет разделен на два параллельных потока:

1. Modern Workplace track

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

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

  • 11:1011:50 Гибридная инфраструктура современного рабочего места, Илья Бойко, ведущий технический эксперт по решениям Microsoft, Microsoft Russia
  • 11:5012:10 Бесшовная интеграция традиционной и облачной инфраструктур СПАО Ингосстрах, Алексей Клепиков, вице-президент по ИТ, член правления, CIO, СПАО Ингосстрах
  • 12:1012:45 Защита АСУТП с использованием Azure Defender for IoT, Кирилл Богданов, эксперт по решениям Microsoft в области информационной безопасности, Microsoft Russia
  • 12:4513:15 Построение SOC как сервис c Azure Sentinel, Иван Мелехин, директор по развитию НИП, АО НИП ИНФОРМЗАЩИТА
  • 13:1513:45 EDR insource vs MDR outsource, Александр Русецкий, руководитель направления защиты от направленных атак центра информационной безопасности, АО Инфосистемы Джет / Александр Ахремчик, ведущий аналитик центра мониторинга и реагирования на инциденты ИБ Jet CSIRT, АО Инфосистемы Джет
  • 13:4514:15 Интеллектуальное решения для соблюдения нормативных требований и управления рисками: End Point DLP, Кирилл Богданов, эксперт по решениям Microsoft в области Информационной Безопасности, Microsoft Russia

2. Microsoft Azure track

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

  • 11:1011:45 Почему HYBRID и почему именно сейчас. ASH/HCI, Антон Ватов, архитектор облачных решений и сервисов Azure, Microsoft Russia / Валентин Логинов, Head of Presale Azure Stack, ПАО МТС
  • 11:4512:15 Как мы видим развитие экосистемы Edge и IoT в России совместно с МТС, Станислав Сикачина, менеджер по развитию технологических практик в Российских партнерах, Microsoft Russia / Андрей Плавич, руководитель центра разработки устройств и планирования сети IoT и М2М, ПАО МТС
  • 12:1512:45 Azure IoT Central и NB-IoT Dev Kit от МТС, Дмитрий Тетерук, архитектор IoT решений. С 2017 года и отвечает за взаимодействие с партнерами и заказчиками в регионах CEE и Nordics, Microsoft Russia / Виталий Бачук, старший менеджер по продукту центра разработки устройств и планирования сети Интернета Вещей и М2М, ПАО МТС / Андрей Плавич, руководитель центра разработки устройств и планирования сети IoT и М2М, ПАО МТС
  • 12:4513:05 Погружаемся в Azure IoT Edge, Александр Сурков, эксперт, обладатель статусов MVP / Microsoft RD / Microsoft MCT
  • 13:0513:35 Гибридная инфраструктура и Open Source, Александр Белоцерковский, архитектор облачных решений, Microsoft Russia
  • 13:3514:05 Партнерская экосистема Microsoft в гибридных решениях, Михаил Чепурин, менеджер по развитию партнёрского канала в сегменте крупного производства, Microsoft Russia

Выберете интересующее вас направление, зовите коллег и регистрируйтесь на Microsoft HYBRID Cloud Forum.

Ждем вас 17 декабря!
Подробнее..

Digital-мероприятия в Москве c 14 по 20 декабря

14.12.2020 10:07:17 | Автор: admin

Подборка мероприятий на неделю


image


Digital Retail 2020


  • 15 декабря (вторник)
  • онлайн
  • бесплатно
  • Как российскому retail и eCommerce выстроить процессы, увеличить продажи и справиться с ростом

Epic Scrum Fails: предновогодний скрам-стендап


  • 15 декабря (вторник)
  • онлайн
  • бесплатно
  • 15 декабря наше Scrum Community приглашает вас на скрам-стендап! В эти предновогодние дни встретимся и вместе посмеёмся над скрам-мастерскими ошибками, помня, что в каждой шутке есть своя мораль. В программе истории от Сбера, МТС, Альфа-Банка, ОТП и Райффайзенбанка.

Positive Technologies и Check Point в Yandex Cloud Marketplace


  • 17 декабря (четверг)
  • онлайн
  • бесплатно
  • В Cloud Marketplace пополнение. Недавно в нем появились два продукта для обеспечения сетевой безопасности: PT Application Firewall и Check Point CloudGuard IaaS.
    17 декабря представители Positive Technologies и Check Point выйдут в прямой эфир, чтобы рассказать о своих продуктах и ответить на ваши вопросы.

ANALYST MARATHON #3. Онлайн-конференция


  • 17 декабря (четверг)
  • онлайн
  • от 2 100 р.
  • Analyst Marathon это образовательное онлайн-мероприятие для BA/SA-аналитиков. Первая часть конференции будет посвящена процессам интеграции информационных систем в банковской сфере. Во второй части речь пойдет о дашбордах и визуализации данных, проблеме техдолга, различиях между проектом и продуктом, карьере аналитика

Дзен-митап: исследования и рекомендательные системы.


  • 18 декабря (пятница)
  • онлайн
  • бесплатно
  • 18 декабря мы сменим направление и обсудим наукоёмкие задачи поговорим об обучении с подкреплением (reinforcement learning) и об атаках на модели.
    Эти темы популярны сами по себе, а в применении к рекомендациям особенно интересны. От Дзена будет история о том, как возникла задача ранжирования по сложной негладкой метрике, какие подходы в ней пробовали и что заработало лучше всего.
Подробнее..

QA Meeting Point доклады

14.12.2020 16:17:31 | Автор: admin
Привет, Хабр!

В этом году мы в DINS провели нашу первую конференцию для QA-инженеров. К нам подключились более 900 человек из 90 городов России и Европы, чтобы послушать доклады с кейсами и дискуссию круглого стола о карьерных перспективах в тестировании.

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

Что делать, если у вас слишком много автотестов


Спикер: Сергей Потанин QAA Team Lead в Wrike, Воронеж.

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


Где логика?! История тестирования одного микросервиса


Спикер: Денис Кудряшов инженер по тестированию в Leroy Merlin, Москва.

Чем сложнее системы в микросервисах, тем больше в них бизнес-логики. Неважно, остается она в микросервисе или выносится в отдельное приложение ее нужно тестировать. Денис рассказал, как методики структурного тестирования помогут справиться с этой задачей. Из кейса Leroy Merlin вы узнаете, как повысить надежность и скорость выполнения тестов с помощью моков и других инструментов.


Автоматизация тестирования мобильного приложения Яндекс.Деньги


Спикер: Александр Наташкин руководитель мобильного тестирования, Яндекс.Деньги, Санкт-Петербург.

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


Отлавливаем баги в коде и рабочем процессе


Спикер: Елена Гурова Team Lead QA в Usetech, Ростов-на-Дону.

Елена разобрала реальные баги прямиком из багтрекера Usetech, рабочих чатиков и совещаний.

Звездами шоу стали:
  • А давайте релиз в пятницу, во второй половине дня?
  • Как это попало в продакшн?!
  • Вы же уже исправляли это, почему опять сломано?

И другие жизненные истории и способы их решения.


Качество релизов ответственность команды


Спикер: Людмила Малеева QA engineer в Miro, Пермь.

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


Правда или миф: хороший QA-инженер не будет оставаться в профессии, а станет разработчиком


Инженеры DINS встретились за виртуальным круглым столом и поговорили о реальных перспективах развития в качестве QA-инженера. Стоит ли QA-инженеру становиться разработчиком? Сколько можно заработать в этой профессии? Просто ли достичь вершины карьеры или придется сильно постараться, чтобы выделиться? Смотрите и делитесь своими мнениями в комментариях!


QA Meeting Point 2020: как это было


Кроме докладов мы позаботились и о подарках и развлечении участников конференции: провели флешмоб и зарядку, раздали мерч за лучшие вопросы, разыграли участие в спортивном марафоне от LiveBody и Apple Watch 6. Немного подробнее в видео ниже.

Подробнее..

Монорепо жизнь до и после

15.12.2020 10:11:51 | Автор: admin
Это история о том, почему в одном из направлений Юлы отказались от практики отдельных репозиториев на микросервисы и внутренние библиотеки, перейдя на монорепозиторий, и что из этого вышло. О проблемах, с которыми столкнулись в компании, и тех, которые получилось решить при помощи этого переезда, рассказал на конференции Golang Live 2020 руководитель b2b-разработки Юлы Валентин Дубровский.



В этой статье мы поговорим о:

  1. Проблемах, которые решает монорепо;
  2. Минусах монорепозитория;
  3. GO в команде B2B Юлы;
  4. Том, как мы вводили монорепозиторий.

Внимание! Я буду говорить не про монолит. У многих любое моно- ассоциируется именно с ним.



Речь пойдет о монорепозитории.

Какие проблемы решает монорепо?


Десять лет назад фронтенд и PHP-код хранились у нас в одном репозитории по 10 Gb (GitLab/GitHub).

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

Сегодня мы попробуем осмыслить шаг назад и поговорим про монорепозиторий.

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

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

Ориентирование на местности


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

А потом приходит его коллега и спрашивает: Ты делал сервис, который загружает картинку пользователя. Расскажешь, где его найти?. Он не может сам сориентироваться по поиску через GitLab/GitHub в устаревшей документации сервиса. Поэтому обращается к разработчику сервиса напрямую.

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

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

Приватные репозитории


Кроме того, монорепозиторий позволяет решить проблему работы с приватными репозиториями.

Рассмотрим сценарий. В базе данных есть адаптер: Redis, MongoDB обертка над общей публичной библиотекой. Мы делаем для нее отдельный репозиторий. И осуществляем некий порядок действий: добавляем CI, который прогоняет тесты, навешиваем тэги при релизе master. Дальше начинаются танцы с бубнами. Как притянуть эту библиотеку в наш репозиторий? Ведь через Go.mod это не так просто сделать.

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

Одна задача один Pull request


Еще один интересный плюс монорепозитория связан с самим выполнением задачи.

Разработчик берет задачу, которая затрагивает несколько сервисов. Например необходимо что-то сделать в GraphQL, или вокруг микросервисов.

У него два алгоритма.

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

Второй вариант решения этой проблемы декомпозиция задачи по сервисам. Там есть общая родительская задача. Ревью проходят по одному, вне контекста общей задачи. Или же можно попробовать сымитировать контекст. Но это все дополнительные действия, которые нужно предпринять, несмотря на то, что задача маленькая. Ведь изменилось условно 15-20-30 строчек кода.

Если задача небольшая, монорепо позволяет сделать все в рамках одного pull request. Ревью сможет заняться один разработчик, у которого будет полный контекст по задаче. Это удобно и ускоряет поставку задач на production из-за того, что мы избавляемся от лишнего оверхеда.

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

Команда делает сервис, доводит его до production. Продакт и бизнес довольны. Разработчики идут на кухню, разговаривают с другой командой, и та заявляет, что у них уже есть такой сервис.

Улучшаем командный процесс


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

Эти вопросы можно решить и в полирепозиториях. Но в монорепо это происходит само по себе.

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

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

Окружение


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

Есть инструмент docker-compose, который просто идеален для локальной разработки. В нем настроен билд сервиса и запуск. И это прекрасный вариант, не требующий лишних действий.

Базовые штуки в локальном окружении настроить очень просто. Например, запуск линтера на pre-commit hook. Мы должны закинуть в .git скрипт, который будет запускаться на pre-commit hook. Это позволяет отлаживать простой код на локальном уровне, а не в CI.

Минусы монорепозитория


В любом процессе, технологии, решении есть свои сложности. Самый большой минус монорепозиториев это проблема зависимостей.

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

В монорепозитории так не получится, и придется следить за breaking changes. Мы не можем использовать разные мажорные версии в разных репозиториях. Кроме того, нужно внимательно следить за внутренними библиотеками.

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

При использовании монорепа усложняется CI/CD процесс.

Если мы живем в парадигме один сервис один репозиторий, мы находимся в 4 джобах: test, build, deploy и что-нибудь еще. Слили master, сбилдили, задеплоили ОК.

В монорепозитории это сложнее, потому что при сливе master, нам нужно билдить только то, что изменилось. Монорепозиторий будет потихоньку разрастаться. В нем может быть 30, 40, 50, 100 сервисов. И если мы будем билдить все, ни к чему хорошему это не приведет.

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

GO в команде B2B Юлы




У нас несколько десятков микросервисов на GO.

GRPC и Kafka используются для общения между микросервисами, GRPC для синхронных, Kafka для асинхронных. Это важно, потому что GRPC по протофайлу представляет нам генерированный клиент, и в монорепозитории его достаточно просто использовать между микросервисами. Для клиентов мобильных приложений и веба мы используем GraphQL.

Gitlab CI используется для билда Docker-образов и для выливки на тестовые стенды.Мы используем Gitlab CI для всех наших CI-процессов, пишем его сами без DevOps. DevOps-инженеры помогают дать нам пайплайн, который мы дернем для того, чтобы вылить сервис на тестовое окружение.

Наши сервисы имеют однотипную структуру, которую мы определили на раннем этапе.
Это не стандартный Golang package layout, а своя версия.

До монорепо на каждый сервис и каждую внутреннюю библиотеку у нас заводился отдельный репозиторий. Внутренние библиотеки (мы называем их провайдерами) хранились в отдельной группе. Есть две разные группы: для микросервисов и для провайдеров. И в обе нужно было давать доступы всем заинтересованным людям.

В каждом сервисе должен быть реализован CI/CD. Базовые штуки мы вносили в Gitlab CI шаблоны, и инклюдили. Если вы знакомы с Gitlab CI, понимаете, о чем я назовем это переиспользованием шаблонов.

Для кода, который можно переиспользовать, мы заводили свой репозиторий.

Я уже упоминал, что с приватными репозиториями не все так просто, поэтому мы сделали небольшой ход конем: подняли Athens. В ней можно указать путь до GitLab и креды до него, это позволяет стягивать приватные репозитории через GOPROXY. Для каждого разработчика, для каждой CI машины это выглядит так: ты делаешь пустой приватный пакет, указываешь Go proxy до Athens, и она упрощает жизнь.

Кроме того, мы сделали отдельный репозиторий для docker-compose, где указывали latest до registry каждого сервиса.

Как мы вводили монорепо


Сначала нужно было объединить репозитории.

Это сложный процесс, и мы разбили его на шаги:

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

Первая стратегия выглядит следующим образом: мы все фризим. Для этого подготавливаем инфраструктуру в монорепо. Это самый простой паттерн действия.

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

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

Дальше мы переходим к локальному окружению.

Как я уже говорил, docker-compose идеально для этого подходит. Лучшая стратегия: отправить через volume в каждый билд путь до до локальной директории go modules. Тогда, если вы что-то делаете go.mod, оно попадает в GOPATH/pkg/mod. И это ускорит билд.

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

После чего мы добавили rest proxy для Kafka. Он позволяет продьюсить и консьюмить из Kafka через обычный Postman.

Теперь поговорим о билдах.

Мы пошли по такому сценарию: для каждого сервиса использовали директиву Gitlab CI only changes. Записали в only changes Dockerfile, go.mod, наши внутренние библиотеки и все зависимости от внешних сервисов:



Это все здорово работает до тех пор, пока не меняется что-то общее, например, go.mod. Когда у нас сливается сервис, в который добавилась новая библиотека, CI начинает все билдить.

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

Что мы сделали еще? Раньше у нас были пухлые Gitlab CI файлы. Но в монорепо можно обращаться к локальным скриптам. И мы выделили папку script на CI и тяжелые вещи, которые нужны в CI, пишем на Go-коде. Например, выбор ревьювера.

Выбор ревьювера эволюционировал у нас в интересном формате. Сначала мы просто скидывали в чат созданные pull requests. Но ревью проходили долго потому, что все надеялись друг на друга и не приступали к задаче.

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

С монорепо мы решили перенести это в CI. Когда аттачится pull request, мы запускаем наш Go-скрипт и выбираем двух случайных ревьюверов. Первого на основе измененных файлов: кто больше всего трогал, тот и выбирается рандомно среди топ-кандидатов. Второго из всего проекта монорепо.



Это очень круто работает.

Естественно, в монорепозитории как по маслу пошли такие вещи, как нотификация при открытии PR, или нотификация, если PR долго не ревьювятся. Каждые 2-3 часа мы напоминаем: Эй, не забудь про ревью!.



Это повышает конверсию из pull requests в релиз, работает коллективная ответственность.

У нас нет Continuous Delivery в production, а релиз происходит так:



Сейчас в нашей компании почти continuous delivery в production (кстати, он есть на тестовые стенды), но еще не совсем. Думаю, мы дойдем на него на следующей стадии.

Выводы


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

Для нас переход в монорепозиторий стал успешной практикой, поскольку:

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


Возможно, в очень большой компании стоит делать монорепозитории по направлениям.

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

Хотите больше материалов по go-разработке? У вас есть возможность купить видео с Golang Live 2020.

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

Digital-мероприятия в Москве c 21 по 27 декабря

21.12.2020 10:07:55 | Автор: admin

Подборка мероприятий на неделю


image


QA Online LoGeek Night Russia


  • 21 декабря (понедельник)
  • онлайн
  • бесплатно
  • На встрече мы рассмотрим инфраструктуру, сервисы и тестирование на проекте по разработке плагинов для 3D приложений, а также автоматизацию высокоуровневого тестирования ПО максимального уровня безопасности для авионики.
    У вас будет возможность задать вопросы нашим специалистам, а также принять участие в розыгрыше призов от Luxoft в режиме online за лучший вопрос!

Удаленные digital-профессии 2021


  • 22 декабря (вторник) 24 декабря (четверг)
  • онлайн
  • от 380 р.
  • Для кого мастер-класс:
    Для маркетологов и интернет-маркетологов
    Для тех, кто хочет освоить новую профессию
    Предпринимателям и владельцам бизнеса
    Количество мест ограничено.

DDP Mobile Conf 2020


  • 23 декабря (среда)
  • онлайн
  • бесплатно
  • Конференция DDP Mobile Conf 2020 взгляд 360 на создание мобильных бизнес-приложений. Эксперты обсудят современные подходы, принципы разработки и развития сложных приложений, поделятся успешными кейсами. Организатор конференции digital-интегратор DD Planet.
    Спикерами конференции выступят представители рынка мобильной разработки и компаний, создающих собственные крупные приложения. В программе ожидаются доклады ВКонтакте, АЗС Газпромнефть, DD Planet, 65apps и другие. Сайт мероприятия.

Рождественские лекции: Наука звука в Цифровом деловом пространстве


  • 24 декабря (четверг)
  • Покровка 47
  • бесплатно
  • Хотите услышать, как звучит водород? Стать повелителем интерактивной скульптуры? Узнать, как тип личности и характер влияет на музыкальные предпочтения и заново открыть для себя магию звука? Приходите на Рождественские лекции: Наука звука в ЦДП. Здесь вы встретитесь с композиторами, художниками и экспериментаторами, испытаете новый музыкальный опыт, познакомитесь с инновациями в аудиобрендинге и, конечно же, получите мощный заряд новогоднего настроения.
Подробнее..

Делимся докладами-2020 и анонсируем конференции-2021

21.12.2020 14:15:23 | Автор: admin


Недавно мы завершили сезон из восьми конференций для разработчиков от Joker до Mobius. И теперь хотим сделать три вещи:


  • Подвести итоги: рассказать и о победах, и о проколах. В том числе про нашу новую виртуальную площадку
  • Анонсировать конференции 2021-го: JPoint, HolyJS, Heisenbug и другие
  • Поделиться записями 14 отличных свежих докладов



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


Сначала расскажем о том, что затрагивало всех, а затем про игровое.


Классический вид


Чем этот сезон отличался от предыдущего для тех, кто игровой вид запускать не хотел?



Воркшопы
Мы обнаружили, что для онлайна хорошо подходят практические выступления. Сидя перед экраном, удобно смотреть на то, что спикер делает на своём экране. Правда, есть сложность: воркшоп особенно хорошо работает, когда его смотрят в прямом эфире, а в записи уже не совсем то. Поэтому, например, на DotNext спикер Макс Аршинов попросил для его выступления вообще не делать запись.


Победа: как показывают отзывы, зрители действительно рады воркшопам.


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


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


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



Стабильность
Самое главное в онлайн-трансляции чтобы она не падала. Так что мы проводили работу над этим.


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


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


Качество
Если со стабильностью всё в порядке и картинка не пропадает, дальше можно думать о том, чтобы она была как можно лучше. Мы ставим себе планкой 4K, и тут кто-то может спросить: зачем онлайн-конференции вообще столько, когда у большинства зрителей даже нет 4K-монитора? Ответ можно найти в старом докладе Одноклассников об их live video: мы сделали поддержку 4K на вырост, потому что если отдебажить для неё плеер и разобраться с производительностью, то 1080p даже на слабых устройствах будет играть прекрасно.


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


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




Игровой вид


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


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


Идея в следующем: есть 2D-пространство, позволяющее ходить между разными докладами и партнёрскими стендами, как в играх. Там можно общаться: когда подходишь к другому зрителю, под игровым пространством вы видите друг друга с помощью веб-камер. То есть можно разговаривать с теми, кто рядом, как на офлайновых конференциях. И возможно взаимодействовать с различными объектами.



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


Для виртуальной платформы мы не использовали какое-то общедоступное решение, а запилили своё собственное. И Сева vbrekelov Брекелов, участвовавший в работе над ним, рассказал подробнее:


Мы хотели сделать нетворкинг интересным и рассматривали разные варианты и браузерные, и VR. Решили, что 2D-игрушки это интересно, изучили доступные решения, пообщались со Spatial Chat и Gather.town. Но обнаружили, что их не получится интегрировать как следует. Например, возникает сложность с точки зрения авторизации: доступ к самой конференции есть только у зрителей с билетами, и требуется, чтобы доступ на виртуальную площадку тоже был только у них. Со сторонними решениями это сложно или невозможно, и при этом они зачастую ещё и дорогие. И мы поняли, что надо делать что-то своё.



В итоге сделали свою виртуальную площадку с помощью PixiJS. Если коротко, то PixiJS это такой JS-движок для управления Canvas, позволяющий делать всякие штуки с передвижениями. Но надо понимать, что это далеко не Unreal Engine. Это удобная прослойка между Canvas и кодом, но многое надо реализовывать самостоятельно: отображение карты, нескольких людей на ней одновременно, демонстрацию всех перемещений. Поэтому у нас Коля Молчанов делал поверх PixiJS наш игровой движок. А мы с Кириллом Толкачёвым (tolkkv) в это время занимались нашим видеорешением на WebRTC (и поняли, что WebRTC это боль).


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


А помимо разработческих задач, были и продуктовые. Не было какого-то человека со стороны, который пришёл бы и сказал рисуем всё вот так. Нам самим надо было понять, как всё должно выглядеть, какие нам нужны локации. Обсуждали это с дизайнером, составили ТЗ. Решили в дизайне отталкиваться от атмосферы пиксельных игр что думаете о результате?


Затем был ещё один большой пласт работы. Виртуальная площадка конференции это целый ряд разных локаций. Каждая локация PNG-картинка, которую мы разбиваем на клетки 30x30. И дальше на клетках нужно было вручную указывать, что это за объект: это стена, сквозь неё нельзя пройти, это стенд партнёра, вот здесь будет открываться такая-то ссылка, а это переход на другую локацию с таким-то ID. В общем, перед Joker мы с Колей Молчановым не уходили из офиса: размечали карту, выкатывали последовательно на test/dev/prod, тестировали на каждом шаге.



Наш редактор, где мы размечаем NPC-объекты


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


Хвалят за то, что атмосфера конференции получается живее, чем когда есть только сайт с расписанием и видеоплеером.


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


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


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


Вот о следующем сезоне давайте и поговорим.




Анонс-2021: новые даты и новые цены


В апреле мы начнём новый конференционный сезон. Что можем о нём сказать?


  • Определились с датами пяти конференций (с другими продолжаем определяться, полный список будет на jugru.org):
    Heisenbug: 6-9 апреля, билеты уже в продаже
    JPoint: 13-16 апреля, билеты уже в продаже
    Mobius: 13-16 апреля
    HolyJS: 20-23 апреля, билеты уже в продаже
    DotNext: 20-23 апреля
  • Этот сезон, как и два предыдущих, пройдёт в онлайне (пандемия не спешит исчезать). Так что поучаствовать снова можно будет из любой точки планеты.
  • И поскольку он пройдёт в онлайне, мы бросим силы на то, чтобы онлайн-платформа с виртуальной площадкой стала богаче возможностями пока не назовём список новых фич, но наверняка станет интереснее.
  • Мы пересмотрели тарифную сетку. Раньше было два варианта билетов: Standard (на одну конференцию) и Full Pass (абонемент на весь сезон). Теперь появляются ещё два: бюджетный Basic (вдвое дешевле Standard, но не даёт доступ к видеозаписям дискуссионным зонам, смотреть доклады можно только в прямом эфире) и Extended (на одну конференцию, но даёт также доступ к видеозаписям остальных). Подробно все варианты можно сравнить на сайте конференции при выборе билета.
  • И, как обычно, цена билетов растёт по мере приближения конференции. Так что самый выгодный момент для приобретения сейчас.
  • Если вы участвовали в наших последних конференциях, то больше информации скоро получите (или уже получили) по почте.



Видеозаписи докладов



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


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


Heisenbug (тестирование)
Тест-кейсы как код (Артем Ерошенко)
Воркшоп: Как начать свой проект автоматизации с нуля с божьей помощью и Selenide (Андрей Солнцев): часть 1 часть 2


Mobius (мобильная разработка)
Jetpack Compose live coding declarative UI Антон Шилов)
gRPC в iOS приложениях. REST in peace? (Светослав Карасев)


DotNext (.NET)
Nullability in C# (Jared Parsons)
Как устроен JIT-компилятор в CoreCLR (Егор Богатов)


Joker (Java)
Заменят ли роботы программистов? (Тагир Валеев)
Spring Patterns для взрослых (Евгений Борисов)


HolyJS (JavaScript)
Воркшоп. Новые приключения во фронтенде, версия 2021 (Виталий Фридман): часть 1, часть 2
Революция в микрофронтендах, module federation, Webpack 5 Павел Черторогов


DevOops (DevOps)
Путь (Microsoft) DevOps (Саша Розенбаум)
Платформенная разработка и топологии команд (Михаил Бижан)


C++ Russia (C++)
Ищем баги в продакшене всем миром: GWP-ASan и что дальше (Константин Серебряный)
Дискуссия: Собеседование С++ (Павел Филонов, Илья Шишков, Роман Русяев)


Увидимся в следующем году на новых конференциях!

Подробнее..

ТехноТекст-2020 итого. Результаты, статистика и немного слов

31.12.2020 16:11:51 | Автор: admin

И вот мы в третий раз завершили конкурс IT-статей ТехноТекст. 2020 год получился безумным необычным: довольно трудным, изоляционным, дистанционным, но притом вполне айтишным. В этом смысле конкурс статей о технологиях, придуманный контент-студией Хабра, не только уникален, но и показателен. Подробности о его итогах под катом.

Мы не устаем повторять, что техноавторство для нас особый вид искусства, а для действительно хорошего технического текста нужно совмещать в себе технаря, лирика, гуманитария и физика. Словом, быть человеком Возрождения. Судя по всему, эта концепция становится всё более популярной в IT-среде. Для сравнения:

  • в прошлом году было 213 заявок, в этом 633;

  • в прошлом 12 номинаций и 13 лауреатов, в этом 23 и 25 соответственно (по традиции в некоторых номинациях в этом году Просто о сложном и Сделай сам сообщество могло выбрать своих победителей);

  • в прошлом церемония награждения проходила в традиционном формате, в этом, как и многое в 2020-м, на удалёнке.

23 декабря мы наградили победителей. Как и всегда, ограничения на приём заявок были минимальны: мы не принимали переводы, статьи в соавторстве и тексты, опубликованные до 18.11.2019 и после 09.11.2020. Критерии отбора любая связь с информационными технологиями, 1 автор 1 текст, заявка подается самим автором, подходят все жанры.

Вот уже который год я читаю в комментариях рассказы о том, что Хабр не торт и о том, что корпоративные блоги зло. Так вот, я хочу опровергнуть оба этих тезиса. Уровень статей, которые я оценивал для конкурса, очень высокий, и это касается в том числе текстов из корпоративных блогов. Конечно, стоит сделать скидку на то, что моя специализация не совсем айтишные темы, но, например, в номинации Просто о сложном были именно что классные корпоративные айтишные тексты. Что-то я уже читал в течение года, что-то увидел впервые и был очень рад возможности наверстать упущенное и ещё раз убедиться, что Хабр это то место, где можно найти и интересное, и полезное чтение. Отдельно меня порадовало то, что в этом году исправился сильный перекос научно-популярных статей в космическую тематику. Нет, статей про космонавтику не стало меньше, но стало и больше отличных текстов на другие темы, причем более близкие к научным основам IT от квантовых вычислений до совсем фундаментальной математики. Отрадно и то, что авторы стали меньше стесняться с научной стороной, делая именно научно-популярные, а не популяризаторские тексты.

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

Валерий Шунков (@amartology), коллективное сознательное Хабра

Кухня конкурса

По традиции наше жюри было представлено наиболее компетентными и дотошными экспертами:

О каждом подробнее:

  • Денис Крючков человек за занавеской всем Хабром, положивший начало главному IT-ресурсу для техноавторов.

  • Екатерина Горелова руководитель контент-студии Хабра, мегаэксперт в области контент-маркетинга, натива, креатива, оформления и подачи и ещё много чего.

  • Ирина Лосева шеф-редактор контент-студии, знает все тексты конкурса вдоль и поперёк. Чёрный пояс по техническим текстам.

  • Андрей Фильченков доцент университета ИТМО и ФИТиП, спец по ИИ, машинному обучению и настоящий экспертный эксперт по научным и техническим публикациям и работам.

  • Коллективное сознательное Хабра отдельно хотим отметить последнего судью. Он был особенно суров.

Как и в прошлом году, критериев оценки было 5:

  1. актуальность темы (+теме);

  2. техническая грамотность;

  3. лаконичность;

  4. подача (стиль, уровень вовлечения читателя, оформление);

  5. вау-эффект (общее впечатление от работы).

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

Мы ждали около 500 заявок, вы прислали 633 и это на самом деле много. Чтобы избежать субъективности, нам пришлось немного усложнить систему отбора во 2-й тур и финал так чтобы дать каждому тексту несколько шансов. Во многих номинациях разрывы были минимальны (да-да, будем честными, где-то я тоже расстроилась, но против цифр не пойдешь). Пишите, творите, делитесь экспертизой с сообществом и публикуйте новые крутые статьи все, что вышло после 9 ноября, мы примем на ТехноТекст-2021.

Ирина Лосева, шеф-редактор контент студии Хабра

А вот и статистика

Пик заявок в этом году пришёлся на август когда на конкурс за месяц заявили 312 статей. В уже почти завершенном 2020-м мы решили предоставить авторам полную свободу в выборе номинаций, надеясь, что те самостоятельно решат, куда статья подходит лучше. Как следствие многие (для верности) решили запульнуть везде, поэтому в будущем, скорее всего, выбор будет слегка ограничен.

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

Ну и, разумеется, без хороших текстов это всё не имеет смысла. Даже не говоря о самом конкурсе: делитесь сокровенным и вас оценят! Если у вас есть любимый проект, будь то выращивание пингвинов или постройка глобальных фреймворков, не дайте вашей страсти угаснуть. Для читателя самая интересная статья именно о том, что трогает за душу автора унылые дайджесты никому не нужны. А что это даёт автору? Ведь облечь туманность мыслей в голове в стройные слова - это нелёгкий труд. Но именно это позволяет структурировать мысли, пишите статьи как если бы вы их писали именно для себя, и эти усилия воздадутся сторицей. Положительный отклик сообщества послужит отличным стимулом к новому витку полёта мысли.

Дмитрий Соколов (@haqreu), коллективное сознательное Хабра

Поднимая непростую тему гендера, можем сказать, что в этом году большинство претендентов оказалось мужчинами: 571 человек или 90,2 %. Считаем, что эта несправедливость выправится вместе с растущим ежегодно числом желающих посостязаться в мастерстве технического писательства. Основной костяк текстов пришёлся на внутренний ресурс Хабра: 570 заявок пришли с портала (из которых 183 из блогов компаний), тогда как извне прилетело лишь 63.

В этом году я попал в жюри конкурса и участвовал в оценке статей в номинациях Программирование и DevOps. Приятно удивил спектр статей: начиная от задачи ускорения вычисления поколений в Game of Life, заканчивая добавлением кастомного кода в MBR. Во всех статьях чувствовалась увлечённость авторов. Это один из ключевых моментов, когда ты проникаешься идеей авторов, читать статью становиться интересно не только из технических соображений добавляется эмоциональный окрас. Стоит отметить огромный конкурс в категории Программирование. Два десятка статей добралось до финала, и все они написаны на очень высоком уровне как по техническому содержанию, так и с точки зрения вовлечения читателя. Мне бы хотелось дать один совет тем, кто хотел, но не решился поучаствовать в конкурсе.Очень часто нам кажется, что наша деятельность, наши исследования, увлечения, просто сложные баги в коде это то, что никого не может заинтересовать, но это не так. За каждым багом в коде скрывается история. Попробуйте её рассказать и, возможно, в следующем году на конкурсе будут награждать именно вас.

Михаил Кумачёв (@Ceridan), коллективное сознательное Хабра

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

  1. Программирование (10%)

  2. Сделай сам (7,2%)

  3. Научно-популярное/Просто о сложном (по 6,8%)

Подробнее по всем тут:

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

Встречайте героев

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

ПРОГРАММИРОВАНИЕ поздравляем Дениса Тишкова (@DenisT) его статья: Вычисления на GPU зачем, когда и как. Плюс немного тестов.

СИСТЕМНОЕ АДМИНИСТРИРОВАНИЕ ура Евгению Парфёнову (@Sayanaro) с его работой С Hyper-V на VMware и обратно: конвертация виртуальных дисков.

ТЕСТИРОВАНИЕ с победой Павла Довгалюка (@Dovgaluk) его статья: Обратная отладка виртуальных машин в QEMU.

МОБИЛЬНАЯ РАЗРАБОТКА жмём руку (разумеется, дистанционно) Даниилу Субботину ( @subdan) победила его статья FigmaExport: как автоматизировать экспорт UI-Kit из Figma в Xcode и Android Studio проекты.

ЖЕЛЕЗО И ЕГО РАЗРАБОТКА что называется, не софтом единым. Владимир Омелянчук (@power-link) живое тому подтверждение с материалом LED-драйвер со стоимостью BOM-а меньше 1$. Это возможно?.

ИСКУССТВЕННЙ ИНТЕЛЛЕКТ поздравляем Дмитрия Ватолина (@3Dvideo) его статья: Deep Fake Science, кризис воспроизводимости и откуда берутся пустые репозитории.

МАШИННОЕ ОБУЧЕНИЕ (эксперт-партнер в номинации Glowbyte) поздравляем с заслуженной победой Александра Кукушкина (@alexanderkuk) с его статьей Проект Natasha. Набор качественных открытых инструментов для обработки естественного русского языка (NLP).

У статьи, претендующей на лучшую в Машинном обучении, должна быть структура из которой будет понятен контекст статьи в мире ML. Статья должна быть концентратом с высокой плотностью и динамикой мысли. Не хочется видеть идеальный разбор с консервативными примерами из старых учебников. При этом хочется увидеть где-то глубину и если не ML-методов, то domain-области, где применение МL материально. В идеале хочется видеть разбор SOTA-методов, обсуждение лучших практик в индустрии, о которых, возможно, широко не рассказывают на arhiv.org или конференциях с книгами. На Хабре в этом смысле можно раскрыть интуицию и направление мысли, если коммерческая тайна не позволяет говорить слишком подробно про подход.В будущем хотелось бы увидеть статьи, больше отражающие тренды и их проекцию на действительность interpretable AI, causal inference, операционализация моделей, байесовские методы, Federated ML. Обзоры методов, разработанных от FB,Google (не только NLP).

Александр Бородин, ведущий эксперт по моделированию финансовых рисков GlowByte Consulting

ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ с победой Антона Лопаницына (@Bo0oM) с его выигрышной статьёй: Фишеры icloud и где они обитают.

БЛОКЧЕЙН поздравляем Андрея Сабельникова (@andrey_sabelnikov) с публикацией Сколько нужно рома, чтобы получить новую кольцевую подпись?.

ПРОСТО О СЛОЖНОМ (наш экспертный партнер в этой номинации dentsu Russia) поздравляем Антона Жиянова (@nalgeon), его работа: Юлия Iuliia. Всё о транслитерации.

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

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

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

Рассказать просто может только настоящий эксперт-практик. Тема, в которой автор действительно разобрался, имеет наибольшую ценность. Но также важно потратить хотя бы какое-то время на то, чтобы понять, чем живёт аудитория, в которую вы целитесь, и зачем ей читать этот текст.

Юрий Лысенко, директор по стратегическим технологиямdentsuRussia

DEVOPS с победой Ивана Осадчего (@iosadchiy) за статью Оптимизация работы с PostgreSQL в Go: от 50 до 5000 RPS.

ГЕЙМДЕВ с победой Алексея Лесового (@lesha_lesovoy) его статья: Armored Warfare: Проект Армата. Хроматическая аберрация.

НАУЧНО-ПОПУЛЯРНОЕ с победой Александра Дикарева (@AlekDikarev) выигрышная статья Как глубока Бездна Челленджера: измерение глубины.

СДЕЛАЙ САМ поздравляем Дмитрия Дударева (@Dudarion) его статья: Как я делаю цифровую минигитару.

ОБ IT ДЛЯ ДЕТЕЙ триумфатором этой номинации стал Александр Ночкин ( @nochkin) статья Начать заниматься роботами должно быть просто понравилась всем, кто ее читал.

ПРОСТО О СЛОЖНОМ (ВБОР СООБЩЕСТВА) сообщество избрало победителем Андрея Мелихова (@amel-true) с его статьей Архитектура современных корпоративных Node.js-приложений.

СДЕЛАЙ САМ (ВБОР СООБЩЕСТВА) победителем народного голосования оказался Гуменюк Иван (@Meklon) и его работа Гидропоника. Выращиваем сверхострый чили и заставляем всех его есть.

SOFT SKILLS с победой Руслана Закарьяева ( @RuslanZakariaev) за его Советы руководителю от руководителя.

ЛУЧШИЙ РЕПОРТАЖ поздравляем Веронику Самохину (@Aminopyrodin) ее репортаж: ICFP Contest 2020 от идеи до воплощения. Как организовать контест и выжить.

ЛУЧШИЙ КЕЙС выиграл Никита Славин (@Nslavin) его материал: How old is this house. Как я делал карту возраста домов Петербурга

ЛУЧШАЯ ПОДАЧА победа Алексея Карамышева (@Ommand), его работа: Равномерное перемещение объекта вдоль кривой.

ЛУЧШАЯ ЭКСПЕРТИЗА (партнёр-эксперт в этой номинации МегаФон) тут победителем стал Роман Проскуряков ( @humbug) и его статья C++ быстрее и безопаснее Rust, Yandex сделала замеры.

Какой должна быть статья, чтобы быть лучшей? Нет однозначного ответа на этот вопрос. Для себя я, наверное, сформулировал бы следующие критерии применительно к статье: она безусловно должна быть интересной, она должна вызывать реакцию со стороны сообщества, она должны вызывать эмоции, причём необязательно ох, ну ничего себе или класс, надо попробовать, но вполне допускается и негативная коннотация, типа да что вы там втираете. Эмоция, на мой взгляд, самое главное, что должно быть в подобном сообществе. Эмоции двигают вперёд, заставляют работать с собственным знанием и вступать в дискуссии. Также статья должна быть небанальной, содержать новое знание, личный опыт, и, немаловажно, подача материала должна нести в себе желание рассказать сообществу что-то новое, что улучшает общую базу знаний, общий опыт. Наверное, это ключевые критерии.

Леонид Чёрный, директор по управлению данными в компании МегаФон

УДАЛЁННАЯ РАБОТА с победой Ларису Большакову ( @Lara_ball007) с её статьей: Какие ошибки делают руководители на удалёнке.

IT ВНЕ IT поздравляем Ярослава Сергиенко ( @pallada92) его статья: Трехмерный движок в коде ДНК.

ЗДОРОВЬЕ ГИКА с победой Дмитрия Руднева ( @dmitriyrudnev) за его работу Тёплый, ламповый и очень опасный.

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

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

Кажется, что за последнее время DIY-статьи выходят длиннее возможно, это связано с тем, что инженеры стали больше времени уделять своим хобби, и это здорово!

Виталий Юркин (@aivs), коллективное сознательное Хабра

Аналогично прошлому году, в ближайшее время у всех победителей в профиле появятся значки Лучший техноавтор-2020.

Как награждали и что хотим сказать

В силу очевидных причин (откройте браузер / включите ТВ / посмотрите в окно) в 2020 году награждение просто не могло проходить по традиционной, так полюбившейся всем нам модели. Мы бы очень хотели лично пообщаться с номинантами, пожать руки победителям и вручить им награды, но пришлось оставаться в тренде и ограничиться онлайн-церемонией. Но мы и не думаем отчаиваться!

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

Алексей @Boomburum Шевелев, главный над самым главным в пользовательской поддержке Хабра

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

Два важных наблюдения внутри Хабра-2020 и конкурса ТехноТекст-2020. Во-первых, я помнила статьи почти всех финалистов и это показательно: значит, аудитория и эксперты сходятся в оценках, это много говорит об уровне победителей они нереально крутые. Во-вторых, этот год показал, насколько чувствительно Хабр реагирует на окружающие события, новые тренды, какие-то локальные айтишные факты. Это говорит о живости и включённости аудитории, о возможности эффективного диалога внутри ИТ-сообщества. Но всегда чего-то не хватает. Как ни парадоксально, лично мне как айтишнику не хватает хороших практических статей по ИТ-менеджменту, который реально приносит результат в компаниях. Увы, в этой среде пока либо теория, либо скудные редкие кейсы. Думаю, 2021 год принесёт свои тренды и будет много интересного контента. Пишите лаконично (не коротко, а осмысленно!), доказательно, иллюстрируйте публикации хорошими примерами, схемами, программным кодом создавайте профессиональный контент, это бесценный вклад в жизнь всего ИТ-сообщества. И конечно, это ваш опыт, личная прокачка скилов. И да, участвуйте в ТехноТексте, это интересно, полезно и важно для оценки себя как автора. Надеюсь, встретимся на награждении уже офлайн!

Виктория Гонгина (@Exosphere), один из главных модераторов Хабра

Ещё раз спасибо коллективному сознательному экспертам и крутым техноавторам, которые помогали оценивать статьи: @ErmIg@haqreu @aivs @Loxmatiymamont @dmitrysamsonov @Ceridan @trashwind @amartology @Mofas @PatientZero @LukaSafonov

И отдельная благодарность нашим замечательным партнёрам компаниямdentsu Russia, Glowbyte и МегаФон.

А вообще, что хотим сказать. Мы верим, что следующий ТехноТекст получится ещё круче, что участников будет больше, а церемония пройдёт в офлайне. Хотя как знать? В IT-сообществе быть затворником не зазорно.

У каждого свой Хабр. И мой Хабр это конечно образовательное сообщество. Если смотреть на отдачу от личного общения до маркетинговых исследований эта образовательная константа-доминанта важна для многих. При чём здесь текст и ТехноТекст? Образование на Хабре своего рода текстовая ювелирка. Каждый урок - единственный и неповторимый текст, когда важно не только что и зачем, но и как. Поэтому выбирая лучшие публикации, мы оценивали не только информативную ценность и профессиональный опыт, но и эрудицию и свободу автора, талант быть собой и не бояться выразить себя в словах. По большому счёту, именно знания и свобода то лучшее в нас, что сделает и этот мир лучше. Пишите, скоро мы начнем новый ТехноТекст.

Екатерина Горелова, руководитель контент-студии Хабра

Увидимся в следующем году! А если вы участвовали и не победили отчаиваться не стоит. Пытайтесь снова, и все обязательно получится.

Подробнее..

Как разрабатывать сотни AB экспериментов

12.01.2021 10:14:24 | Автор: admin
А/Б-тестирование это способ измерить эффективность нового функционала путем сравнения. Вы создаете новый заголовок, кнопку или изображение и показываете их только части аудитории сайта. В течение нескольких недель собираете статистику об использовании нового функционала и на основании этого принимаете решение об открытии новой фичи для 100% пользователей.

Senior Frontend Developer ЦИАН Иван Бабков, который разрабатывал приложения для регистрации доменов, интернет-банкинга и поиска по жилой недвижимости в своем докладе на конференции Frontend Conf рассказал об инфраструктуре компании для работы с А/Б-экспериментами, проблемах и путях их решения.

image

Что такое A/B тестирование


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

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

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

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

Все было хорошо ровно до того момента, пока в компании не предположили, что, во-первых, люди не замечают этот блок; во-вторых, в ЦИАН много акций, и размещать их на главной странице сайта больше не хотят.

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

Но хорошо бы основывать решение на аналитике. Поэтому нужно сделать следующее: взять 100% пользователей и разделить их на две группы по 50%. Первой показать старый вариант интерфейса, второй новый.



Спустя какое-то время, когда накоплены данные, которые отправлялись с разных вариантов интерфейса, можно сделать вывод, что конверсия в клики по первому варианту интерфейса 17%, по второму 25%. Логично, что на сайте предпочли оставить второй вариант. Это поможет в дальнейшем улучшить user experience.

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

Пример разработки frontend A/B эксперимента в ЦИАН


Чтобы погрузиться глубже, приведу пример того, разрабатывали отдельно взятый A/B эксперимент в компании с самого начала и до момента его завершения (полной выкатки на бой).

В какой-то момент продакт-менеджер ЦИАН совместно с дизайнером и аналитиком создали задачу следующего вида:



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

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



Дизайнер рисует два варианта макета:



А. Старый вариант, где есть один блок акций.

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

Первое, что необходимо сделать: перенести описание эксперимента в код. В ЦИАН есть админка, позволяющая добавлять и редактировать новые эксперименты:



В ней нужно заполнить форму следующего содержания:

  • Название эксперимента;
  • Время, когда он начнется;
  • Количество A/B групп;
  • Процентное соотношение в A/B группах.

При нажатии кнопки СГЕНЕРИРОВАТЬ, вся информация попадает в базу данных, откуда бэкенд может ее запрашивать.

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

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



Вариант ответа это список, в котором есть объекты с именем эксперимента и A/B группа, в которую попадает пользователь в этом отдельном эксперименте.

Нужно внести полученную с бэкенда информацию об эксперименте в Redux store и проверить в компонентах, какой вариант интерфейса в коде нужно отрисовывать в A/B группе.

В проекте есть всего две директории:



  1. GKCard это директория, в которой лежит компонент жилого комплекса, который вы видели на скриншоте;
  2. PromoLabel компонент акции (в примере: скидка на квартиры до 7%).

В компоненте GKCard отрисовывается PromoLabel.

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



Добавляем директорию ab, в нее директорию с названием эксперимента (в нашем примере: newbuilding_promos), а туда все файлы.

В компоненте жилого комплекса добавляем всего несколько строк:



  • connect, чтобы получать данные из store;
  • PromoLabel с новой версткой, где будет 3 акции;
  • Флаг isABEnabled для того, чтобы отрисовывать либо старый, либо новый вариант акции.

В connect берем список всех экспериментов, ищем в них эксперимент под именем newbuilding_promos, проверяем, есть ли такой эксперимент, и в этом объекте находим поле A/B групп, которое получили с бэкенда.



Если его значение 1, то отрисовываем новый вариант акции. Если нет, то старый:



То есть пользователь попадает в группу 1, если он получает новый вариант интерфейса.

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



Для отправки в примере использована библиотека ReactGA, но можно использовать множество других библиотек в NPM. В ЦИАН используют библиотеку собственной разработки, дублируя туда отправку:





Мы зарелизили задачу, все хорошо. Спустя две недели приходит новая.

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



В задаче были данные, что 13% пользователей кликают на блок акций в старом варианте, 21% в новом. Стейкхолдер вместе с аналитиками попросили Ивана раскатать вариант В на 100% пользователей. Это повысит конверсию в клике: пользователи видят эти акции, все хорошо.

Чтобы сделать это, нужно воспользоваться админкой:



Нужно перекинуть пользователей в БД в группу В. Теперь пользователи с ID от 0 до 99 увидят второй вариант интерфейса. Первый вариант не увидит никто.



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



В ЦИАН хранят не только актуальные, но и уже завершенные эксперименты. Никогда не знаешь, когда может понадобиться информация о них.

Теперь нужно перенести файлы из этой директории на нужный уровень вложенности проекта (в нашем случае рядом со старым блоком акций) и удалить старый блок:



Все! Следы эксперимента остались лишь в git log и в БД.

Немного про инфраструктуру


Есть запрос. Он пришел из браузера на наш внешний Nginx:



На Nginx мы запускаем скрипт, который генерирует ID от 0 до 99. Есть функция примерно следующего вида:



Функция возвращает число от 0 до 99. Она принимает строчку в виде уникального идентификатора пользователя. В нашем примере это будет:

uid = abfd-4843

Эта строчка передается функции md5 для генерации хэша:



Хэш получается шестнадцатеричный:

hash = FD029AAD2251AD74F8223B4F4A80B6EA

Мы преобразуем его в десятичное число и делим на 100:



parseInt(hash, 16)=3.363082047354731e+38

Остатком от этого деления будет число от 0 до 99. В нашем примере 68:

parseInt(hash, 16) % 100 = 68

График, который иллюстрирует равномерность распределения сгенерированных ID на 10 млн уникальных идентификаторов пользователя:



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

Мы запрашиваем страницу с ID, который только что сгенерировали, и передаем его как HTTP заголовок:



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



Request body


Запрос выглядит примерно так:



Мы передаем ID, только что нами сгенерированный на Nginx, и список экспериментов (их имен, которые фронтенд хочет получить от бэкенда). Бэкенд должен запросить этот список из БД, что он и делает:



Мы получили информацию из БД и должны вернуть приложение в наш фронтовый микросервис.



Но тут есть важный момент: мы должны вернуть не все эксперименты, а только часть.



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

Это мы делаем следующим образом: берем сгенерированный ID (например, 50) и информацию, которую храним в БД.



Среди прочей информации (название эксперимента, время его начала, насколько эксперимент актуален, идет ли он сейчас, номер задачи) есть два важных элемента. Это списки, которые были сгенерированы при создании. Они содержат числа от 0 до 99. Числа уникальны, то есть в первом и втором списке не может быть числа 0.

Почему их два? Потому что при создании эксперимента мы создавали две A/B группы.
Берем наше число (в примере AB_ID = 50) и ищем в каждом из списков. Находим во втором:



Это говорит нам о том, что пользователь с ID = 50 попадает во вторую A/B группу и увидит второй вариант интерфейса.

Но одновременно у нас идет множество экспериментов:



В одном из них пользователь может попасть в третью группу, в другом во вторую, в третьем в первую.



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

Ответ выглядит следующим образом:



Это список, в котором есть объекты следующего содержания: имя эксперимента и A/B группа, в которую попадает пользователь.

Теперь фронтовое приложение имеет все данные, чтобы понять, в какой группе находится пользователь. Нужно отрисовать необходимый блок, передать его на клиент, и вместе с ним отослать список информации об экспериментах. Чтобы, если это необходимо, продолжить эксперимент на клиенте (допустим, отправку данных в систему аналитики).



Теперь у нас есть два варианта интерфейса, на которые приходят две разные группы пользователей:



Озвученный подход к проведению A/B экспериментов не единственный. Можно проводить их не только в приложениях сервера рендерингом, но и исключительно на клиенте. Например, делать это на бэкенде, подмешивая дополнительные результаты в поисковую выдачу только для определенной группы пользователей. И даже на Nginx (но мы так не поступаем, так как считаем его неподходящим инструментом для бизнес-логики).

Как принудительно попасть в определенную A/B группу?


Понятие A/B тестирования отчасти пришло к нам из медицины. Есть понимание, что в каждом эксперименте должна быть контрольная группа.

В ЦИАН ею является нулевая группа. То есть пользователи при делении попадают, допустим, в две группы, и нулевая всегда избавлена от интерфейсов.

Чтобы автотесты или ручное тестирование, когда тестировщик проверяет задачу, могли попасть в определенную группу, передаем с фронта HTTP заголовок с ID.



Это ID от 0 до 99. Nginx настроен таким образом, что он игнорирует генерацию нового идентификатора и принимает тот, который пришел с клиента, пробрасывая его дальше. Соответственно, все дальнейшие предложения видят ID, которые мы передали с клиента.

Когда Nginx проигнорировал генерацию нового ID, он передает запрос на фронтовый микросервис.

Планы


Система ЦИАН не идеальна. И есть некоторые моменты, которые Иван планирует улучшить:

  • Таргетировать эксперименты по определенным параметрам (пол, геопозиция, дата регистрации и т.п.).
    В компании хотят научиться проводить эксперименты, например, для 17% мужчин из Петербурга, которые зарегистрировались у нас не ранее года назад.
  • Добавить возможность таргетировать по дополнительным параметрам в админку, чтобы не делать этого руками.
  • Разрабатывать больше экспериментов.

Но уже сегодня A/B эксперименты приносят свои плоды.

ЦИАН это крупнейший сервис по поиску недвижимости в России и один из самых больших в мире. Компания входит в мировой ТОП-10 крупнейших сайтов по недвижимости по версии Similar Web.

В подобных условиях каждое продуктовое или архитектурное решение должно быть продуманным и обоснованным, и постоянное проведение A/B экспериментов помогает этого достичь.

Frontend Conf 2021 пройдет 29 и 30 апреля. Но билеты на нее по самой выгодной цене вы можете приобрести уже сегодня.
Подробнее..

21 и 22 января два бесплатных онлайн-митапа (QA и iOS)

14.01.2021 16:09:15 | Автор: admin

Привет! Новый год новые митапы.

Уже через неделю мы проведём два первых в этом году митапа, первый из которых будет полезен тестировщикам, а второй iOS-разработчикам. Спикеры будут из Альфа-Банка, а вот участники круглого стола по теме из Сбера, Тинькофф и Райффайзенбанка.

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

Программа под катом

21 января, 19.00 МСК QAчественное общение

В программе 3 доклада от Альфа-Банка и викторина с призами. Мы постараемся сделать эти пару часов максимально полезными для всех собравшихся.

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

19:05-19:40, Дмитрий Гадеев, Kubernetes. Жизнь ДО и ПОСЛЕ

Руководитель направления сопровождения инфраструктурных сервисов, Альфа-Банк

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

19:40-20:10, Ксения Коломиец, Сайт-конструктор. Тестирование без боли

Старший специалист по тестированию, Альфа-Банк

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

20:10-20:40, Александр Долинский, Тестирование API в большой команде

Руководитель группы тестирования, Альфа-Банк

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

20:40-21:00, Викторина в Kahoot с розыгрышем призов

Страница регистрации

22 января, 19.00 МСК Mobile Talks

19:05-19:40, Василий Пономарев, Техническая сторона UI-компонентов

iOS-разработчик, Альфа-Банк

Василий расскажет о реализации UI-компонентов, принятых на вооружение архитектурных решениях. А также покажет пример из практики и разберет преимущества и недостатки данного подхода.

19:40-20:15, Евгений Онуфрейчик, Новый разработчик. От старта до выхода на орбиту

iOS-разработчик, Альфа-Банк

Женя расскажет о процессе погружения нового разработчика в проект мобильного приложения Альфа-Банка, о сложностях адаптации и как мы с ними справляемся. Объяснит, как выглядит процесс со стороны новичка что он ощущает и как понимает происходящее. А также расскажет, какова в этом роль и зоны ответственности наставника.

20:15-20:35, Викторина в Kahoot с розыгрышем призов

20:35-21:35, Круглый стол Качество vs скорость разработки как найти баланс?

  • Сергей Нанаев, Head of iOS, Альфа-Банк

  • Роман Голофаев, Mobile Community Lead, Райффайзенбанк

  • Александр Поломодов, Руководитель управления разработки цифровых экосистем, Тинькофф

  • Иван Бубнов, Руководитель направления мобильной разработки, Сбер

Страница регистрации.

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru