2020-06-20: РИТ-2020 - online нетворкинг приближается к offline

Короткая ссылка: RIT-2020

Ссылки сюда (2) →

РИТ-2020 проходил в этом году в длинном online-формате. Два дня 25-26.05 шло несколько параллельных треков докладов весь день, а потом еще неделю, до 05.06 каждый день с 16 и до вечера шел один трек докладов и мастер-классы. Это был эксперимент по переводу конференции в online-формат так, чтобы дать много разного контента и возможностей для нетворкинга. Как и на KnowledgeConf после доклада спикер со всеми желающими слушателями перемещался в отдельную zoom-комнату для ответов на вопросы, помимо выступлений в рамках расписания имелась возможность организовать собственный митап или экспресс-выступление по какой-то теме - как и на офлайн-РИТ.

Главный сюрприз для меня был в конце первого дня - организаторам удалось организовать online-нетворкинг на afterparty почти как в offline. Люди объединялись в группы, как обычно бывает вокруг столов, и там были обсуждения не менее интересные, чем обычно на afterparty. И до 11 вечера люди точно оставались. На второй день afterparty было столь же активным. Сделано это на технологии spatial.chat. Если на той же технологии будет сделано фойе конференции, то вообще будет супер. И, может быть, обсуждение докладов тоже делать не в zoom-комнатах, а таким способом. Правда там экран не расшаришь, а иногда это бывает надо, чтобы отвечать на вопросы на слайдах презентации.

Вообще для меня лично нетворкинг - очень важная составляющая часть конференции. Хотя на доклады я тоже активно хожу, не пропускаю слоты, если только не завязалось какого-то супер-интересного разговора. Но я знаю докладчиков и участников, которые вообще почти не смотрят доклады - ведь их можно посмотреть в записи, а активно занимаются нетворкингом. Я на IT-конференциях довольно давно, с 2010, и видел как культура нетворкинга формировалась на офлайн-конференциях, как объясняли, да и сейчас объясняют людям, что подойти к докладчику, который стоит у стола и заговорить - это нормально. Заметим, что так есть не на всех конференциях, и есть большое различие между конференциями именно по уровню и свободе нетворкинга, а не только по самим докладам.

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

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

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

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

А вот за последние годы по всем темам начали бурно развиваться серии конференций. Особенно в IT - ontico, jug. Идет несколько конференций каждую неделю. И тут возникает вопрос - на какие из них ходить. Старая логика не работает, когда конференций не 3-5, а 10-20. А нынешний выход в online еще раз поменял ситуацию - организаторы научились делать не просто трансляции, а реальное пространство общения. И очевидно не будут от этого отказываться, возможно, будут развивать композитные форматы. И у тебя получается 100+ потенциально доступных конференций и вебинаров по разным темам. Как быть - у меня пока нет версии ответа. Буду искать.

И это для меня не умозрительная тема, а актуальный текущий вопрос. Уже после РИТ был TechLead, и я его пропустил. Фактически не было сил, почему-то меня online выматывает больше чем offline. Но, может, это вопрос привычки. В общем, я не пошел, но при этом во вторник, это была середина второго дня конференции, я по ленте отчетливо понял, что зря я не стал слушать. Надо было собраться и освободить время. У меня еще работа была, с офлайн ты ушел на конференцию - и все. А тут ты в принципе можешь совмещать, перемещения - мгновенны.

В общем, буду экспериментировать и искать формат.

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

Alexey Kuksyonok. Прививка гибкости, или Как расшевелить функционального монстра

Пост на FB Первый доклад Alexey Kuksyonok. Прививка гибкости, или Как расшевелить функционального монстра. Алексей, помимо основной работы в DataArt, активно работает в воронежском и питерском клубе PM и в рамках клубов они ведут консалтинг. И в докладе он рассказывал про кейс консалтинга на оборонном предприятии, разрабатывающем программно-аппаратные комплексы. Организация устроена традиционно, по функциональным отделам. Проектная команда набирается из сотрудников отделов, но занятость не гарантируется, подчинение функциональному руководителю сохраняется, а у PM - много ответственности и никакой власти. Их PM позвал помочь на горящий проект, сроки которого многократно переносились и который был в ручном управлении. Рассказ был о том, как в этих условиях за счет внедрения гибких методологий по мотивам Scrum удалось проект перевести в предсказуемую ситуацию и привести к успеху. Причем уже после четвертого спринта они отпустили команду в самостоятельное плавание.

Что принципиально важно и отличает данное внедрение Scrum от множества других. Тут не было задачи "внедрить процесс", а была задача "решить проблемы". Был анализ, и решениями были элементы Scrum, дополненные метриками и адаптированные к ситуации. В комментах - краткое содержание.

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

Экспресс-анализ. Проблемы команды и РП - понятны. Про проблемы директора - гипотезы, на старте не было доступа!

• непредсказуемый процесс
• черная дыра ресурсов
• низкая точность оценки
• ручной микроменеджмент

Матрица решений.

• Объем задач на небольшой срок
• Задачи в виде измеримых результатов
• Это - спринты!
• Обещание ресурсов на спринт от функциональных менеджеров.
• Цель спринта и задачи на спринт - директор (он же PO), а оценка - от команды на планировании, вместе с функциональным менеджером - и из этого идут цели на спринт.
• Разграничить роли, полномочия и зоны ответственности. Без самоорганизованности
• Запустить ритм разработки - дейли, демо и прозрачность. В результате директор видит прогресс - и пропадает необходимость микроменеджмента.
• Метрики для команды и менеджеров - оценка эффективности на ретро. Мы видим по jira, результат - на демо.

Дальше 5-6 встреч с директором, обсуждение ситуации. Для начала - его опыт, как достиг, чем занимается сейчас. Задача - выйти на его понимание проблемы. Оно подтвердило гипотезы - и они вышли с планом решений, директор одобрил. Итого - поддержка директора, PM, и части команды.

Оформили устав проекта

• Базовый правила оценки: плохо (неожиданный провал)/нормально (провал, но своевременно детектированный)/хорошо (сделали)
• Роли проекта - включая внешних стейкхолдеров.
  • В частности они - спрямляли горизонтальные коммуникации
• Критерий поставки и критерий приемки: DoD и acceptance test
• Процесс планирование - activity diagram, (похожа на блок-схемы - это близко).
• Задачу оценивала команда, проверял функциональные менеджеры (они - эксперты). А директор (спонсор) принимает.

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

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

Второй спринт - задач было сделано много, но разрозненные. Предложение - замкнутые демонстрабельные объемы. Учет блокировок. Третий спринт - выполнение, но разрозненное. И сделали, чтобы был фокус

• Документация - на единый сервер.
• Если задача не завершается - анализ и декомпозиция.
• По ресурсам - график на спринт.

4 спринт - наконец, начали фокусироваться на целях спринта. Ресурсы проанализировали - отпуска, внезапные командировки, отвлечения

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

А команда после этого команда наконец смогла оценить сроки бэклога. И в целом пришли к ней двухнедельными спринтами.

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

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

А это - выводы Алексея. Родилась методология, пригодная для таких организаций. Отличия от скрам

• больше ролей (функициональные руководители и PM)
• отчетность и метрики
• фиксированный объем задач и сроки
• тщательная работа с рисками
• наказания за невыполнение целей

Выводы.

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

Рекомендации:

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

Пост Alexey Kuksyonok: Максим Цепков как всегда оперативно делает стенограмму доклада. И не просто делает, а качественно отражает его суть, за что ему очердное огромное спасибо!💪

Так что если кто-то не успел посмотреть доклад, можно попробовать составить своей мнение о нем по стенограмме от Макса. За деталями можно ко мне в личку! :)

Николай Архипов. Как мы побеждаем неопределенность в Delivery Club

Пост на FB Николай Архипов. Как мы побеждаем неопределенность в Delivery Club. Доклад о технологичном проведении бизнес-экспериментов в сервисе непосредственно на проде, в реально функционирующей бизнес-среде. На конкретном примере - изменение алгоритма назначения курьеров, чтобы повысить сроки доставки, от жадного до JustInTime.

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

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

Фреймворк GIST: Goals (бизнеса) - Ideas (для достижения целей) - Step projects (фичи для реализации) - Tasks

• Бизнес быстро принимает решения
• Многие идеи дает команда!
• Трассировка от фичи к бизнес-целям - понятна и прозрачна. Достаточно сравнить фичи по перспективности.

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

Inner Source

• Эксперимент обычно меняет многие модули, все изменения проводит R&D-команда.
• Cобирают в единый бэклог, договариваются кто и что разрабатывает
• Ревьюят коллеги, которые разрабатывают модули
• Раскатка в прод - тоже командами, которые сопровождают фичи.

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

Андрей Смирнов. Soft Skills Remote

Пост на FB Андрей Смирнов. Soft Skills Remote. Доклад был построен на основе интервью тимлидов о проблемах, с которыми столкнулись с переходом на удаленку. И эта часть - вполне понятная. Там, где были распределенные команды, пусть даже часть их была в офисе, переход на удаленку прошел нормально. А те, кто раньше работали в офисе столкнулись с различными проблемами из-за проседания коммуникации.

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

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

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

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

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

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

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

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

Alexandra Vilvovskaya: а если в формате конспекта - было что-то любопытное?

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

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

Андрей Смирнов если будет интересно, презентация по ссылке - https://sandark7.github.io/RIT2020/

Дмитрия Соломенцева из Яндекс. Лидары в беспилотных машинах

Пост на FB Завершающий доклад первого дня был про лидары в беспилотных машинах от Дмитрия Соломенцева из Яндекс, который сам разрабатывает лидар для Яндекс-автомобиля. Но он рассказывал не про свои разработки, а давал общий обзор разных технологий и разных вариантов архитектур и реализация лидаров. Лидар - устройство, которое делает лазерное сканирование пространства и строит картину объектов и их движения. Так вот, и лазеров и сканеров, обрабатывающих отраженный луч - громадное количество, технологии применяются не только в автомобилях, но и на спутниках, дронах, в роботах-пылесосах и так далее. И поэтому задача не в разработке принципиально нового, а в удачной комбинации существующего, обеспечивающего хорошие параметры и низкую цену устройства. Илон Маск считает, что лидеры не нужны, потому что они дороги, а люди обходятся без них. И они на самом деле сейчас дороги. Но фишка в том, что при массовом производстве стоимость сильно снижается. При этом конкретные модели уже сейчас выбраны для использования моделях автомобилях для ограниченных задачах автовождения (удержание на полосе, ехать в пробках), или в роботах-доставщиках. Так что надо решать задачу выбора конкретных технологий в условиях, когда стоимость является существенным параметром, и при этом может существенно измениться. В общем, любопытно. Технических вариантов технологий я раскрывать не буду.

Андрей Евсюков из DeliveryClub. Инженерная культура в IT-компании: зачем она нужна, как её построить и чем всё это обернется

Пост на FB Инженерная культура в IT-компании: зачем она нужна, как её построить и чем всё это обернется. Андрей Евсюков (Andrey Evsyukov) из DeliveryClub. Заглянуть в культуру динамично развивающейся успешной компании - очень интересно. Основа культуры - эксперименты, постоянная проверка новых гипотез. К сожалению, доклад был в форме интервью, и ответы были на уровне общих принципах и подходов. И в нем очень не хватало примеров, подробностей, конкретных историй, именно они интересны, и без них тяжело понять детали.

Тут конкретный пример - использование новых технологий. Принципы, которые были сформулированы в докладе, консервативны: технология появилась давно и зрелая, знакома в компании и легка в освоении новичкам. Такие критерии есть во многих традиционных компаниях, и благодаря им никакие новые технологии не пробиваются. Обсуждение же в zoom с конкретными примерами, показало, что вопреки впечатлению технологии в компании развиваются динамично. Просто компания развивается динамично, и используемые технологии часто выступают ограничениями для развития - вот тут-то и происходит исследование новых и обновление. Сознательное, для решения конкретной задачи. Переход на Clickhouse, когда стало ясно что метабаза через три месяца не потянет нагрузку. Идущее сейчас исследование средств мониторинга, потому что используемая связка Prometheus - Grafana - Graphite не позволяет решить ряд задач - fingerprint, трассировка запросов. Переписывание с Java на Kotlin чтобы решить задачу подбора сотрудников, потому что разработчиков на Java найти гораздо сложнее. И цель была достигнута, они смотрели метрики, что очень интересно. При этом "знакомство с технологиями внутри компании" в их случае не является запретительным фактором, потому что компания - молодая и растущая, и поэтому много сотрудников знакомы с самыми разными технологиями по прошлому месту работы.

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

А пока - спасибо Андрею за доклад и ответы.

Николай Голов из ManyChat. На пути к бессерверным базам данных — как и зачем?

Пост на FB На пути к бессерверным базам данных — как и зачем? Николай Голов из ManyChat. Интересный доклад о дальнейшем продвижении к serverless, снижению расходов на сервера. Теперь не только бэкенд можно делать serverless, как контейнеры, поднимающиеся для обработки одного запроса, и в результате ты платишь не аренду сервера, а за выполнение одного запроса. Это же распространяется на базы данных. Общий принцип - у тебя есть небольшой сервис, который хранит метаданные, обеспечивает безопасность и другую технику. А вот мощности для вычисления запроса поднимаются по требованию. И было рассмотрено три варианта.

• Athena serverless - она вообще не хранит данные, а хранит информацию об их источниках, откуда их можно прочитать по необходимости.
• Aurora serverless - переписанный в варианте serverless PostgreSQL, который очень хорошо масштабирует читающую нагрузку, но не масштабирует записывающую.
• Snowflake serverless, изначально написанный как serverless.

Про Snowflake подробнее. Данные хранятся в микропортициях хранилища S3 amazone, а по запросу - поднимаются вычислительные кластера, в которые подтягиваются необходимые партиции для вычисления запроса. Кластера могут работать как на чтение, так и на запись, и в целом это все оптимизировано под аналитические базы данных, которые хорошо держат нагрузку по записи в ETL-режиме, то есть массовых вставках и преобразованиях данных, и запросы данных. При этом, что интересно, мелкие запросы обрабатываются пулом, который расширяется в зависимости от нагрузки, а для тяжелых может подниматься кластер из многих вычислительных узлов на общих данных, обеспечивающий консистентность. Для OLTP это пока не сильно подходит, все-таки развертывание вычислительных кластеров занимает секунды, а там это дорого.

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

Николай Голов: Напишу уточнение, пока можно - Aurora serverless может работать в режиме PostgreSQL, ИЛИ в режиме MySQL. Сделал акцент на постгрес, но MySQL тоже возможен, как и в RDS.

Алексей Тимин из Badoo. Языки, платформы, версии: масштабируем локализацию

Пост на FB Языки, платформы, версии: масштабируем локализацию. Алексей Тимин из Badoo. Основная тема - разные сообщения пользователям и другой текст на интерфейсе в разных локализациях. И много примеров, с метасимволами в текстовых константах, в которые идет подстановка.

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

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

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

Пока писал, вспомнил еще доклад Wargaming осенью 2016 в Минске на SQAdays-20, там тоже был кусок про региональную специфику, которая касалась не только надписей, но и учета культурных особенностей. Потому что Япония и Китай, например, были противниками во второй мировой, и в каждой из стран есть свои ограничения по использованию символики, часто противоположные. И ряд других подробных аспектов.

Интересно, в докладе Badoo этого не было просто потому, что за рамками, или глобализация сделала мир интернет-знакомств однородным?

Кому интересно - мой отчет с конфы https://mtsepkov.org/SQAdays-20, доклад https://sqadays.com/ru/talk/44074

Андрей Аксенов из Авито и Sphinx. 3 слова про 2 потока

Пост на FB Андрей Аксенов из Авито и Sphinx. 3 слова про 2 потока. По сути доклад о том, что используя библиотеки, надо представлять, что у них под капотом, как именно оно работает. И часто оказывается, что библиотечные решения в ряде кейсов тяжелее простых способов, хотя это не очевидно. И потом, например, для простых счетчиков не нужен mutex, достаточно atomic. B наоборот, в rwlock чтение не полностью разделяемо, есть сериализация при постановке локов - что ни разу не очевидно. И так далее, в докладе очень много техники и деталей.

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 16:22, 20 июня 2020 • нет комментариев