...

суббота, 1 августа 2020 г.

ХудоБедно учим онлайн — поговорим об этом

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

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

Обо всем этом и появилась идея провести онлайн-митап под названием “Худобедно учим онлайн”.


Кто участвует?

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


  • Антон Морев (amorev.ru). CTO Wormsoft и онлайн-преподаватель NodeJS в школе OTUS.
  • Сергей Жук (sergeyzhuk.me). Backend разработчик в Skyeng (который, кстати, тоже занимается онлайн-образованием), автор книг и скринкастов по ReactPHP.
  • Наш гость — Дмитрий Елисеев (elisdn.ru). Основатель deworker.pro и автор множества скринкастов, серии статей и стримов по WEB программированию. У нас с ним недавно было онлайн-интервью

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


Когда и где?

Диалог пройдет в формате прямой трансляции 3 августа в 17.00 (Москва, Киев, Минск) в YouTube — ссылка вот. Присоединяйтесь, участвуйте в дискуссии, задавайте вопросы — активному участнику положен приз:)

Ссылка на трансляцию: https://youtu.be/hIGmB4TmWaQ

Let's block ads! (Why?)

Точечная сварка под микроскопом

Хомяки приветствуют вас друзья!

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

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

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

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

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

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

Что касательно самого кабеля, тот тут лучше не экономить и взять вот этого товарища. РКГМ сечением 25 кв. мм. Производство Россия «Рыбинсккабель». Это хитрый многожильный провод с изоляцией из кремний-органической резины повышенной твердости, в оплетке из стекловолокна пропитанного эмалью или теплостойким лаком. Он очень тонкий и гибкий. Изоляция провода абсолютно равнодушна к повышенным температурам, пламя зажигалки едва способно вызвать хоть какое-то тление. Длинна термостойкого змея 2.2 метра.

Внутренние отверстия магнитопровода смажем вазелином. Ту же процедуру проводим с кабелем. Несмотря на то, что кабель достаточно тонкий по сравнению со своими более дешевыми собратьями, в трансформатор нужно попытаться вместить 4-5 витка. Но вот незадача. 700 Вт МОТ позволяет вместить в себя только 3 витка. Не беда! На помощь приходит система рычагов и отвёрток. В общем, включив смекалку и мотаем 4 витка в такой небольшой трансформатор.

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

Теперь их необходимо соединить к медным шинам на ручке для контактной сварки. Болт тут диаметром 8 мм и длинной 20 мм. Обязательно устанавливаем шайбу Гровера, она обеспечит надежный прижим, если соединительный узел ослабиться в процессе работы.

Самую простую ручку для контактной сварки можно заказать на алиэкспресс. Но мне приглянулся более продвинутый вариант созданный одним народным умельцем. Зовут его Генадий Збукер. Он сам собирает сварочные аппараты, дополняет их ручками которые сам проектирует и печатает на 3D принтере. Называется такая конструкция держатель электродов точечной сварки «ZBU 5.1» с кнопкой и пружинами. 3D модели ранних версий, таких ручек, можно найти на сайте Thingiverse, автор позаботился чтобы при желании каждый мог собственноручно сделать подобный держатель для электродов. Это заслуживает уважения! Так же у него на сайте можно заказать расходные материалы (не реклама, а рекомендация).

Что касаемо ручки для контактной сварки. Выполнена она довольно качественно. Печать корпуса тут осуществляется ABS пластиком. Особенность версии «5.1» в том, что на борту есть два вентилятора, которые способны охлаждать медные шины в процессе непрерывной работы. Питаются они от 5 вольт через разъем micro USB. Ток потребления не более 300 мА.

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

Электроды выполнены из жаропрочной хромовой бронзы БрХЦр. Поскольку электроды при сварке быстро изнашиваются, к ним предъявляются требования по стойкости сохранения формы при нагреве до 600 градусов и ударных усилиях сжатия до 5 кг на квадратный миллиметр. В процессе работы такие электроды особо не прилипают и не обгорают. Импульс тока сварки аккумуляторов должен быть очень коротким, иначе есть шанс прожечь дыру в корпусе, что приведет к выходу его из строя.

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

Функционал контроллера довольно простой. Он выдает два последовательных импульса с паузой между ними. Первый импульс называется «присадочным», а второй «основным». Он приваривает метал друг к другу. Все переменные времени импульса регулируются с помощью энкодера, включая паузу между ними. Управление силовым трансформатором осуществляется c помощью довольно мощного симистора на 40 А. Он устанавливается по входу первичной обмотки. Маркировка BTA41-600.

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

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

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

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

Размещаем внутри корпуса МОТ, импульсный блок питания на 12 вольт и запихиваем внутрь сетевой провод. Длинна его полтора метра. Распределяем все необходим провода по своим разъемам, и в принципе все. С электроникой разобрались.

В результате всех манипуляций у нас получился довольно красивый контроллер для точечной сварки. Силовые провода выводятся через отверстия в верхней крышке корпуса. Тут же разместился разъем для подключения кнопки «концевика». Все эстетично и просто. Вроде как показалось мне. Все подписчики канала знают, что ничего просто так не бывает. Что-то, да должно пойти не так. И это один из тех случаев! Пора проверить аппарат в деле.

Для сварки возьмем старый аккумулятор и никелевую ленту толщиной 0.15 мм. Установим время сварки 20 мс для каждого импульса. Это соответствует одному периоду переменного напряжения из сети. Если там 50 Гц, то это одна пятидесятая. В результате испытаний оказалось, что на самых коротких выдержках времени, ленту не то чтобы варит, а прожигает насквозь. Теперь это не аккумулятор, а сплошная вентиляция…

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

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

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

В Китае есть готовые контроллеры для точечной сварки, заказываю и жду. Это одна из самых продвинутых версий плат. Модель NY-DO2X. Кроме того что она дает двойной импульс с паузой, так еще тут есть возможность регулировать мощность. Симистор тут установлен BTA100 рассчитанный на ток в 100 ампер. Рабочее напряжение 1200 В.

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

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

Слева направо трансформаторы: 700 Вт, 800 Вт и 900 Вт. Чем больше магнитопровод, тем больше мощность. Тут видно на сколько 900 Вт вариант больше своего предшественника. Размеры: длинна 106 мм, высота 89 мм, ширина 66 мм.

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

Выбиваем провод из сердечника железным стержнем.В общей сложности данная операция занимает 20 минут. Медные косы не выбрасываем, а сдаем на металл и покупаем пиво. Обязательно извлекаем магнитные шунты, которые установлены для мягкой работы магнетрона и зачищаем края отверстий в магнитопроводе как это было показано ранее. В такой большой трансформатор без труда помещается 4 витка. При желании можно вместить и 5-тый, но я не стал переводить вазелин) Последовательно с мощным симистором припаиваем первичную обмотку только что перемотанного МОТ-а. Не жалеем припоя и делаем все как для себя.

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

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

Что означают лампочки над цифрами? Первый светодиод говорит о наличии питания. Второй светодиод горит когда нажата кнопка на ручке. Третий загорается только в момент наличия импульса. В общем первые три красные светодиода чисто информационные. Четвертая зеленая лампочка — это счетчик наработки, суммирует каждое нажатие на педаль или «концевик» внутри сварочной кучки. Сбрасывается счетчик двойным нажатием на красную кнопку. Дальше оранжевый светодиод. Первый устанавливает длительность «первого импульса». Выбирается он в периодах. Установим один что будет ровняться 20 мс. Второй светодиод задает мощность импульса. Поставим скажем 35 процентов. Минимум 30 максимум 99.9%. Зеленый светодиод между оранжевыми определяет паузу между импульсами. Так же в периодах. Поставим 2. Последние два оранжевые светодиода так же определяют длительность и мощность, но уже «второго импульса». Поставим 2 периода и мощность выкрутим на 100 процентов. Собственно все, теперь можно потыкать в какую-нибудь ленту и посмотреть как происходит сварка, изучить точки, подобрать режимы на контроллере и прочее.

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

Если накоротко закоротить вторичную обмотку, то даже 700 Вт МОТ способен нагрузить сеть до значений свыше 4 кВт. На сколько больше мне не известно, так как ваттметр уходит в защиту при достижении такой нагрузки. Ток вторичной обмотки при этом зашкаливает за 600 А, свыше предела измерения мультиметра. На входе первичной обмотки максимальный ток зафиксирован 21 ампер, при этом напряжение в сети проседает с 230 до 217 вольт.

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

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

Контроллер благодаря отслеживанию перехода фазы через ноль, открывает симистор на 100 процентах практически в нуле роста амплитуды напряжения. При этом видно что напряжение и ток идут с небольшой задержкой относительно друг друга. При 50 процентах контролер открывает симистор только на половине полупериодов сетевого напряжения. Этот метод аналогичен с Широтно-импульсной модуляцией. Такой режим используется в регуляторах освещенности – диммерах. Яркость свечения лампы накаливания будет напрямую зависеть от площади обрезанной синусоидой. В нашем случае это нужно для всяких деликатных сварок.

Теперь наша задача довольно проста. Нужно приварить ленту для точечной сварки к аккумулятору. Но тут возникает пару вопросов. Какую ленту будем варить и к какому аккумулятору? Помните момент когда у нас сварочник с 700 Вт трансформатором отказывался приваривать никелевую ленту? Идентичная ситуация происходит с новым 900 Вт МОТ-ом.

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

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

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

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

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

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

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

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

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

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

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

Электропроводка в квартире. Специально для фильма был сделан удлинитель с сечением провода в 2.5 квадрата. Даже смотря на это, слабенький 700 Вт МОТ умудрялся просаживать сеть под нагрузкой.

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

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

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

Собранный аппарат для контактной сварки получился довольно компактным и универсальным. Он собирался только ради того, чтобы сварить аккумуляторы для шуруповёрта и паяльника с Китая, которому нужно питание 24 вольта. Часто при ремонтах не хватает портативного инструмента. Конструктор в виде ячеек под аккумуляторы 18650 мы печатали на 3D принтере, они упрощают задачу при формирования сборок с разными напряжениями и ёмкостями, позволяя складывать элементы в любой последовательности. Сборки соединяются между собой специальными пазами. Теперь самостоятельно перепаковать свой старый самокат не составит никакого труда.

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

Как сказал Мастер Йода:
Тебя послушать — так сложно все. Слышишь, что сказал я?
― Ты должен чувствовать силу, она между тобой, мной и камнем, везде…
― Да… нооо нет



Полное видео проекта на YouTube
Архив с полезностями
Наш Instagram

Let's block ads! (Why?)

[Из песочницы] Да хватит уже делать плохие митапы

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

К сожалению, как и до карантина, на 70% этот водоворот состоит из кала.

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

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

Вот они.

0. Самое главное — модерация


Модерация невероятно важна. Это crucial thing любого хорошего мероприятия. Роль модератора – краеугольная, именно от него зависит, получат ли люди удовольствие и пользу или потеряют пару часов жизни.

Что происходит на митапах без модерации:

  1. На нетворкингах интроверты смотрят в телефоны и уходят, не раскрывшись, без новых знакомств
  2. На питч-сессиях самые громкие/наглые участники отбирают всё эфирное время, и остальные остаются не услышаны
  3. Спикерам люди задают нерелевантные вопросы и тратят общее время
  4. Спикеры заговариваются, отходят от темы и тратят время/размывают фокус

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

Но как быть хорошим модератором?

1. «То, что сейчас происходит, приносит пользу участникам?»


Это универсальный вопрос, который модератор должен задавать себе раз в 10 секунд.

Тема, на которую рассуждает спикер, релевантна аудитории? Может быть, его стоит чуть-чуть направить?

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

В кофе-брейках люди знакомятся друг с другом или разбредаются по углам?

Вы должны понимать – кто ваша аудитория и зачем они к вам пришли. Если в данный момент они не получают пользу, а вы просто сидите и стесняетесь направить спикера или намекнуть участнику, когда он вышел за временнОе ограничение, – вы разрушаете ваше мероприятие и уничтожаете десятки (а то и сотни) человеко-часов.

2. Знакомьте людей на нетворкингах


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

Хороший нетворкинг ивент начинается с того, что модератор знакомит участников. Дайте каждому 20-30 секунд на короткое интро. Начните с себя – подайте пример.

Людей слишком много? Разбейте их на группы по 8-10 человек, а потом перемешайте и устройте новый круг.

30 секунд на 10 человек это всего лишь 5 минут. Но за эти 5 минут каждый мысленно отметит: кто ему показался интересным и с кем ему хотелось бы пообщаться поближе. Более того, это помогает завязать диалог: согласитесь, «Привет, ты значит онлайн-ритейл делаешь? О, как знакомо, а я, как ты слышал, интернет-магазины создаю. Расскажешь подробнее?» гораздо лучше чем стандартное «Привет, я Вася, а чем ты занимаешься?».

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

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

3. Следите за повествованием спикеров


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

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

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

Есть много способов сделать это вежливо и тактично.

«Александр, это невероятно интересно, но я боюсь, что немногие в зале настолько глубоко разбираются в X. Ты упомянул Y – мне кажется это гораздо более популярная история – расскажи подробнее, как вы её решали?»
«Мария, ты поразительно много знаешь об X, и я уверен, можешь сутками рассказывать про это. Но увы, у нас всего пара часов, поэтому мне приходится немного сужать темы: могла бы ты поподробнее рассказать про Y – популярную сегодня вещь?»
Улыбайтесь, будьте вежливы и добры. Вы – не воспитатель, отчитывающий вышедшего за тайминг человека. Вы искренне хотите помочь человеку поделиться своим самым полезным опытом с залом.

Нет ничего печальнее, чем видеть грустных спикеров в конце мероприятия при полупустом зале. Особенно больно, когда люди выходят прямо во время их выступления. «Я что-то заговорился про Х… Видимо, здесь это было не всем интересно…». А ведь будь рядом хороший модератор – всё было бы хорошо.

4. Модерируйте вопросы спикерам


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

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

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

«Извините, но я боюсь это слишком узкая тема. Лучше поймайте спикера после выступления и обсудите её тет-а-тет»
«Я позволю себе дополнить вопрос: мне кажется, всем было бы интересно услышать не только про X, но и про весь сегмент в целом»
«Извините, ответ на этот вопрос уже прозвучал чуть раньше»
И так далее. Зал – это хаос, это очень много разных людей. Некоторые из них плохо формулируют вопросы, кто-то отвлекся и спрашивает то, что уже было, и так далее.

Не идите на поводу у стеснения – вежливо откажите человеку в вопросе и передайте микрофон следующему. Весь остальной зал скажет вам спасибо.

Послесловие


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

Помните, что 15 минут бесполезного времени на митапе в 100 человек, – это сожённые в никуда человеко-сутки.

Let's block ads! (Why?)

Новости Blender3d и около него

Очередной выпуск новостей про Blender3D (мою любимую 3Д программу) за текущую неделю. На этой неделе не было добавлено каких-то сногсшибательных фишек, но кое-что интересное произошло. Добро пожаловать под кат
  1. Микрософт присоединился к спонсорам Блендера. Микрософт теперь золотой корпоративный спонсор, вместе с такими компаниями, как Ubisoft или Intel. Надо отметить, что суммы, которые ежемесячно жертвуют золотые корпоративные спонсоры не очень значительные. Это всего 30 000 $ в год, что, конечно, копейка для таких гигантов. Тем не менее, копейка рубль бережет и чем больше спонсоров, тем лучше для разработки. Интерес Микрософта объясняется тем, что они используют Блендер в генерации 3Д-моделей для тренировки ИИ
  2. Одно из важных событий Blender 2.90—это «починка» модификатора Multires. Модификатор был переделан и сейчас дорабатывается его UI. Ожидается, что Multires существенно облегчит работу со скульптингом. Многие художники были недовольны текущим воксельным ремешером, который по их словам не дает делать реалистичные модели и больше подходит для мультяшных образов. Что ж похоже их чаяния скоро сбудутся
  3. Не ясна ситуация с инструментом Add Object. Он появился в версии 2.90, но теперь его отключили. Инструмент должен был позволить добавлять объекты в сцену более удобным образом и ближе к тому, как это позволяют делать другие программы. Но пока он похоже появится в более поздней версии 2.91
  4. В версии 2.91 также появились particle nodes. Т.е. ноды для управления частицами и создания сложных эффектов. Это довольно мощный и ожидаемый инструмент, который является частью большого блендеровского проекта «Everything nodes», т.е. ноды для всего. Впрочем, сейчас ноды частиц скрыты от конечного пользователя и доступны только при включении экспериментальных опций режима для разработчиков. Так что вероятно они появятся в Блендере только несколько версий спустя. Хотя использовать их будут явно раньше

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

См. картинку ниже

Обратите внимание на радужные склянки. Это пример дисперсии в тонких пленках

Полный список новых фишек, можно просмотреть здесь

Let's block ads! (Why?)

[Перевод] Использование таймеров systemd вместо заданий cron

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

Эти таймеры, как и задания cron, могут, в заданное время, вызывать выполнение различных действий в системе. Например — запуск скриптов командной оболочки или программ. Таймеры могут срабатывать, например, раз в день, причём — только по понедельникам. Ещё один пример — срабатывание таймера каждые 15 минут в рабочее время (с 8 утра до 6 вечера). Но таймеры systemd могут кое-что такое, что недоступно заданиям cron. Например, таймер может вызвать скрипт или программу через заданное время после некоего события. Таким событием может быть загрузка системы или запуск systemd, завершение предыдущей задачи или даже завершение работы сервиса, вызванного ранее по таймеру.

Таймеры, используемые для обслуживания системы


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

В качестве примера приведу здесь сведения о таймерах, которые имеются на виртуальной машине, использованной мной для экспериментов. Здесь, для получения списка всех таймеров, я использовал команду systemctl status *timer. Подстановочный символ в виде звёздочки играет здесь ту же роль, которую он играет в других подобных командах. А именно, он сообщает системе о том, что нас интересуют все таймеры (timer units, их ещё называют «unit-файлы таймера» или «юниты таймера») systemd:

[root@testvm1 ~]# systemctl status *timer
● mlocate-updatedb.timer - Updates mlocate database every day
     Loaded: loaded (/usr/lib/systemd/system/mlocate-updatedb.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● mlocate-updatedb.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Updates mlocate database every day.

● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily rotation of log files.

● sysstat-summary.timer - Generate summary of yesterday's process accounting
     Loaded: loaded (/usr/lib/systemd/system/sysstat-summary.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:07:00 EDT; 15h left
   Triggers: ● sysstat-summary.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Generate summary of yesterday's process accounting.

● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Mon 2020-06-08 00:00:00 EDT; 3 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Discard unused blocks once a week.

● sysstat-collect.timer - Run system activity accounting tool every 10 minutes
     Loaded: loaded (/usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:50:00 EDT; 41s left
   Triggers: ● sysstat-collect.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Run system activity accounting tool every 10 minutes.

● dnf-makecache.timer - dnf makecache --timer
     Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:51:00 EDT; 1min 41s left
   Triggers: ● dnf-makecache.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started dnf makecache –timer.

● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
     Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 08:19:00 EDT; 23h left
   Triggers: ● systemd-tmpfiles-clean.service
       Docs: man:tmpfiles.d(5)
             man:systemd-tmpfiles(8)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily Cleanup of Temporary Directories.

С каждым таймером связано, по меньшей мере, шесть строк, содержащих сведения о нём:
  • Первая строка содержит имя файла таймера и короткое описание цели существования этого таймера.
  • Вторая строка выводит сведения о состоянии таймера. А именно, сообщает о том, загружен ли он, даёт полный путь к файлу таймера, показывает состояние vendor preset (disabled или enabled).
  • В третьей строке показаны сведения об активности таймера, куда входят данные о том, когда именно таймер был активирован.
  • В четвёртой строке содержатся дата и время следующего запуска таймера и примерное время, оставшееся до его запуска.
  • Пятая строка сообщает имя сервиса или события, вызываемого таймером.
  • Некоторые (но не все) файлы юнитов таймеров systemd содержат указатели на документацию. Такие указатели есть, в моём примере, в описаниях трёх таймеров.
  • Последняя строка в описании таймера представляет собой запись журнала, которая связана с самым свежим экземпляром сервиса, вызванного таймером.

Если вы попробуете выполнить на своём компьютере команду systemctl status *timer, то представленный ей набор таймеров вполне может отличаться от моего.

Создание таймера


Хотя мы могли бы разобраться с особенностями работы таймеров, проанализировав какие-нибудь существующие таймеры, я предлагаю создать собственный unit-файл сервиса (файл конфигурации сервиса, service unit) и файл таймера, с помощью которого будет вызываться соответствующий сервис. Мы тут, чтобы не усложнять повествование, приведём довольно тривиальный пример. Но после того как мы с ним разберёмся, вам будет легче разобраться в работе других таймеров.

Для начала создадим простой файл конфигурации сервиса, который будет запускать что-то простое, вроде команды free. Например, это может понадобиться в том случае, если нам надо регулярно мониторить объём свободной памяти. Создадим unit-файл с именем myMonitor.service в папке /etc/systemd/system. Он не обязательно должен быть исполняемым.

# This service unit is for testing timer units
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs system statistics to the systemd journal
Wants=myMonitor.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/free

[Install]
WantedBy=multi-user.target

Этот файл, пожалуй, можно назвать простейшим файлом конфигурации сервиса. Теперь давайте проверим его состояние и протестируем его для того чтобы убедиться в том, что он работает так, как ожидается.
[root@testvm1 system]# systemctl status myMonitor.service
● myMonitor.service - Logs system statistics to the systemd journal
     Loaded: loaded (/etc/systemd/system/myMonitor.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
[root@testvm1 system]# systemctl start myMonitor.service
[root@testvm1 system]#

А почему ничего не выводится в консоль? Дело в том, что по умолчанию стандартный вывод (stdout) от программ, запускаемых systemd с помощью unit-файлов сервисов, перенаправляется в журнал systemd. Благодаря этому, по крайней мере, до тех пор, пока соответствующие записи существуют, эти записи можно проанализировать. Заглянем в журнал и поищем записи, относящиеся к нашему сервису и к дню, когда мы проводили испытания. Соответствующая команда будет выглядеть так: journalctl -S today -u myMonitor.service. Ключ -S — это сокращённый вариант --since. Он позволяет указывать временной период, за который утилита journalctl ищет записи. Дело тут не в том, что нас не интересуют более ранние результаты. В нашем случае таких результатов просто не будет. Этот ключ использован для того чтобы сократить время, которое нужно утилите на поиск данных. Если компьютер работает уже давно, в журнале может накопиться очень много записей.
[root@testvm1 system]# journalctl -S today -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Thu 2020-06-11 09:40:47 EDT. --
Jun 11 09:12:09 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 09:12:09 testvm1.both.org free[377966]:               total        used        free      shared  buff/cache   available
Jun 11 09:12:09 testvm1.both.org free[377966]: Mem:       12635740      522868    11032860        8016     1080012    11821508
Jun 11 09:12:09 testvm1.both.org free[377966]: Swap:       8388604           0     8388604
Jun 11 09:12:09 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
[root@testvm1 system]#

Задача, которая запускается с помощью файла конфигурации сервиса, может быть представлена отдельной программой, последовательностью программ, или скриптом, написанном на любом скриптовом языке. Добавим в unit-файл myMonitor.service ещё одну задачу, включив в него, в конце раздела [Service], следующее:
ExecStart=/usr/bin/lsblk

Снова запустим сервис и проверим журнал. Там должно быть что-то, напоминающее то, что показано ниже. А именно, в журнал должны попасть данные, выводимые обеими командами:
Jun 11 15:42:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 15:42:18 testvm1.both.org free[379961]:               total        used        free      shared  buff/cache   available
Jun 11 15:42:18 testvm1.both.org free[379961]: Mem:       12635740      531788    11019540        8024     1084412    11812272
Jun 11 15:42:18 testvm1.both.org free[379961]: Swap:       8388604           0     8388604
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sda             8:0    0  120G  0 disk
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─sda1          8:1    0    4G  0 part /boot
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: └─sda2          8:2    0  116G  0 part
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sr0            11:0    1 1024M  0 rom
Jun 11 15:42:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 11 15:42:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.

Теперь, после того как мы уверились в том, что всё работает правильно, создадим, в папке /etc/systemd/system, unit-файл таймера, дав ему имя myMonitor.timer. В файл добавим следующее:
# This timer unit is for testing
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs some system statistics to the systemd journal
Requires=myMonitor.service

[Timer]
Unit=myMonitor.service
OnCalendar=*-*-* *:*:00

[Install]
WantedBy=timers.target

Указатель времени OnCalendar в этом файле, *-*-* *:*:00, должен приводить к тому, что таймер выполняет вызов юнита myMonitor.service каждую минуту. Подробнее об OnCalendar мы поговорим ниже.

А пока мы можем взглянуть на записи журнала, имеющие отношение к запуску сервиса, вызываемого таймером. Мы, кроме того, можем включить режим наблюдения за таймером. Однако наблюдение за сервисом позволит видеть результаты практически в режиме реального времени. Для этого нужно запустить journalctl с ключом -f (follow):

[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --

Запустите таймер, но не включайте его в автозапуск при загрузке системы. 
[root@testvm1 ~]# systemctl start myMonitor.timer
[root@testvm1 ~]#

Понаблюдайте некоторое время за тем, что происходит.

Один из результатов появляется сразу же. А следующие будут выводиться с интервалом примерно в одну минуту. Понаблюдайте за журналом несколько минут.

[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Jun 13 08:39:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:39:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:39:19 testvm1.both.org free[630566]:               total        used        free      shared  buff/cache   available
Jun 13 08:39:19 testvm1.both.org free[630566]: Mem:       12635740      556604    10965516        8036     1113620    11785628
Jun 13 08:39:19 testvm1.both.org free[630566]: Swap:       8388604           0     8388604
Jun 13 08:39:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sda             8:0    0  120G  0 disk
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: └─sda2          8:2    0  116G  0 part
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:40:46 testvm1.both.org free[630572]:               total        used        free      shared  buff/cache   available
Jun 13 08:40:46 testvm1.both.org free[630572]: Mem:       12635740      555228    10966836        8036     1113676    11786996
Jun 13 08:40:46 testvm1.both.org free[630572]: Swap:       8388604           0     8388604
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sda             8:0    0  120G  0 disk
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: └─sda2          8:2    0  116G  0 part
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:40:46 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:41:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:41:46 testvm1.both.org free[630580]:               total        used        free      shared  buff/cache   available
Jun 13 08:41:46 testvm1.both.org free[630580]: Mem:       12635740      553488    10968564        8036     1113688    11788744
Jun 13 08:41:46 testvm1.both.org free[630580]: Swap:       8388604           0     8388604
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sda             8:0    0  120G  0 disk
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: └─sda2          8:2    0  116G  0 part
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sr0            11:0    1 1024M  0 rom
Jun 13 08:41:47 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:41:47 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.

Обязательно проверьте и состояние таймера, и состояние сервиса.

Удалось ли вам заметить тут то, что заметил я? Возможно, вы, читая журнал, обратите внимание как минимум на две вещи.

Во-первых — на то, что вам не нужно делать что-то особенное для логирования того, что ExecStart из myMonitor.service пишет в stdout. Эта возможность входит в стандартные функции systemd по запуску сервисов. Но это означает, что вам, вероятно, потребуется проявлять осторожность при запуске скриптов из файлов конфигурации сервисов, обращая внимание на то, каков объём данных, который они пишут в stdout.

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

Причина того, что таймер не запускается в :00 секунд каждой минуты, заключается в том, что система таким образом стремится предотвратить одновременный запуск нескольких сервисов. Например, при настройке указателя времени OnCalendar можно пользоваться такими значениями, как Weekly, Daily, да и другими подобными. Эти сокращённые способы именования моментов времени настроены так, чтобы таймеры, в которых они используются, запускались бы в 00:00:00 соответствующего дня. Когда так настроено множество таймеров, высока вероятность того, что все они сработают одновременно.

Именно поэтому таймеры systemd намеренно спроектированы так, чтобы они запускались бы не в точно указанное время, а с некоторым случайным отклонением от него. Это отклонение нельзя назвать совершенно случайным. Таймеры запускаются где-то во временном окне, которое начинается с указанного момента и заканчивается моментом, отстоящим от исходного на одну минуту. Это время, в соответствии с документацией к systemd.timer, поддерживается в стабильном состоянии с учётом всех остальных объявленных в системе таймеров. В вышеприведённом фрагменте журнала можно видеть, что таймер срабатывает сразу же после его запуска, а потом — примерно через 46 или 47 секунд после начала каждой следующей минуты.

Чаще всего такой вот вероятностный подход к определению точного времени срабатывания таймеров всех устраивает. При планировании таких задач, как, например, выполнение резервной копии чего-либо, до тех пор, пока подобные задачи выполняются в нерабочее время, никаких проблем это не вызывает. Системный администратор, настраивая задания cron, может указать чётко определённое время их запуска, нечто вроде 01:05:00, стремясь к тому, чтобы эти задания не конфликтовали бы с другими. Существует большой набор способов указания времени, которые подобное позволяют. Случайные изменения во времени запуска задания, не превышающие минуту, обычно особой роли не играют.

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

AccuracySec=1us

Для указания желаемой точности таймера можно пользоваться особыми ключевыми словами. Эти ключевые слова можно применять и при настройке повторяющихся и «одноразовых» событий. Система понимает следующие ключевые слова:
  • Микросекунда: usec, us, µs.
  • Миллисекунда: msec, ms.
  • Секунда: seconds, second, sec, s.
  • Минута: minutes, minute, min, m.
  • Час: hours, hour, hr, h.
  • День: days, day, d.
  • Неделя: weeks, week, w.
  • Месяц: months, month, M (месяц определён как 30,44 дня).
  • Год: years, year, y (год определён как 365,25 дня).

Все стандартные таймеры, которые имеются в /usr/lib/systemd/system, настроены с использованием гораздо более длительных диапазонов, задающих точность их запуска, так как в случае с этими таймерами срабатывание их в строго заданное время не особенно важно. Взгляните на спецификации некоторых таймеров, созданных системой:
[root@testvm1 system]# grep Accur /usr/lib/systemd/system/*timer
/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h
/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h
/usr/lib/systemd/system/logwatch.timer:AccuracySec=12h
/usr/lib/systemd/system/mlocate-updatedb.timer:AccuracySec=24h
/usr/lib/systemd/system/raid-check.timer:AccuracySec=24h
/usr/lib/systemd/system/unbound-anchor.timer:AccuracySec=24h
[root@testvm1 system]#

Для того чтобы лучше познакомиться с внутренним устройством файлов таймеров из директории /usr/lib/systemd/system, вы можете просмотреть их содержимое.

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

[root@testvm1 system]# systemctl enable myMonitor.timer

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

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

Типы таймеров


Таймеры systemd обладают другими возможностями, которых нет у заданий cron, «одноразовых» или повторяющихся, которые вызываются только с привязкой к реальному времени и к реальным датам. Таймеры systemd можно настроить так, чтобы они вызывались бы на основании изменения состояния других юнитов systemd. Например, таймер можно настроить так, чтобы он срабатывал бы через заданное время после загрузки системы, после входа в неё пользователя, или через заданное время после активации определённого сервиса. Такие таймеры называют монотонными (monotonic). Эти таймеры сбрасываются после каждой перезагрузки системы.

В следующей таблице приведён список монотонных таймеров с краткой характеристикой каждого из них. Там же есть и описание таймера OnCalendar, который монотонным не является и применяется в тех случаях, когда нужно организовать единовременный или повторяющийся запуск чего-либо в будущем. Эта таблица основана на документации systemd.timer.


При настройке монотонных таймеров могут использоваться те же ключевые слова, что были описаны выше при разговоре об AccuracySec. Но надо отметить, что systemd приводит соответствующие временные промежутки к секундам. Например, вам нужно задать таймер, который срабатывает один раз, через пять дней после загрузки системы. Выглядеть его описание может так: OnBootSec=5d. Если компьютер был загружен 2020-06-15 в 09:45:27, то таймер сработает 2020-06-20 в 09:45:27 (или в пределах 1 минуты после этого момента времени).

Описание событий календаря


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

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

При использовании OnCalendar= для настройки таймеров используется следующий базовый формат для указания даты и времени:

DOW YYYY-MM-DD HH:MM:SS

DOW (Day Of Week, день недели), это необязательная часть вышеприведённой конструкции. В других полях можно использовать символ звёздочки (*), символизирующий любое значение, которое может находиться в занимаемой им позиции. Все формы указания даты и времени приводятся к нормализованной форме. Если время не указано, предполагается, что это — 00:00:00. Если дата не указана, а время указано, то таймер сработает либо в день его запуска (условно говоря, «сегодня»), либо на следующий день («завтра»). Это зависит от текущего времени. Для указания месяцев и дней недели могут использоваться их названия. Здесь можно использовать списки значений, разделяемые запятой. Диапазоны значений можно разделять тремя точками (), которые ставят между начальным и конечным значением диапазона.

При указании дат в нашем распоряжении есть пара интересных возможностей. Так, тильда (~) может использоваться для указания последнего дня месяца, или для указания даты, на заданное количество дней предшествующей последнему дню месяца. Косая черта (/) может применяться, в виде модификатора, для указания дня недели.

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


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


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

Для начала взглянем на спецификацию, которая содержит только дату, не содержит сведений о времени (обратите внимание на то, что время в полях Next elapse и (in UTC) различаются, это различие зависит от местного часового пояса):

[student@studentvm1 ~]$ systemd-analyze calendar 2030-06-17
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

Теперь добавим в описание сведения о времени. В данном примере дата и время анализируются раздельно, как сущности, не связанные друг с другом:
[root@testvm1 system]# systemd-analyze calendar 2030-06-17 15:21:16
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    

  Original form: 15:21:16                  
Normalized form: *-*-* 15:21:16            
    Next elapse: Mon 2020-06-15 15:21:16 EDT
       (in UTC): Mon 2020-06-15 19:21:16 UTC
       From now: 3h 55min left              
[root@testvm1 system]#

Теперь рассмотрим пример, в котором дата и время рассматриваются совместно. Для этого их нужно заключить в кавычки. Но если вы будете использовать такую конструкцию в OnCalendar, не забудьте убрать кавычки, иначе вы столкнётесь с ошибками:
[root@testvm1 system]# systemd-analyze calendar "2030-06-17 15:21:16"
Normalized form: 2030-06-17 15:21:16        
    Next elapse: Mon 2030-06-17 15:21:16 EDT
       (in UTC): Mon 2030-06-17 19:21:16 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

Теперь проверим что-нибудь из предыдущей таблицы. Мне особенно нравится такое описание из неё:
2022-6,7,8-1,15 01:15:00

Проанализируем его:
[root@testvm1 system]# systemd-analyze calendar "2022-6,7,8-1,15 01:15:00"
  Original form: 2022-6,7,8-1,15 01:15:00
Normalized form: 2022-06,07,08-01,15 01:15:00
    Next elapse: Wed 2022-06-01 01:15:00 EDT
       (in UTC): Wed 2022-06-01 05:15:00 UTC
       From now: 1 years 11 months left
[root@testvm1 system]#

Теперь давайте взглянем на описание Mon *-05~3, но в этот раз запросим у программы сведения о следующих 5 срабатываниях таймера, в котором использованы такие настройки:
[root@testvm1 ~]# systemd-analyze calendar --iterations=5 "Mon *-05~3"
  Original form: Mon *-05~3                
Normalized form: Mon *-05~03 00:00:00      
    Next elapse: Mon 2023-05-29 00:00:00 EDT
       (in UTC): Mon 2023-05-29 04:00:00 UTC
       From now: 2 years 11 months left    
       Iter. #2: Mon 2028-05-29 00:00:00 EDT
       (in UTC): Mon 2028-05-29 04:00:00 UTC
       From now: 7 years 11 months left    
       Iter. #3: Mon 2034-05-29 00:00:00 EDT
       (in UTC): Mon 2034-05-29 04:00:00 UTC
       From now: 13 years 11 months left    
       Iter. #4: Mon 2045-05-29 00:00:00 EDT
       (in UTC): Mon 2045-05-29 04:00:00 UTC
       From now: 24 years 11 months left    
       Iter. #5: Mon 2051-05-29 00:00:00 EDT
       (in UTC): Mon 2051-05-29 04:00:00 UTC
       From now: 30 years 11 months left    
[root@testvm1 ~]#

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

Дополнительные материалы


В интернете есть много публикаций по systemd, но они, в основном, слишком краткие, очень упрощённые, или даже содержат ошибки. В этой статье приведены некоторые хорошие источники информации по systemd. Ниже дан список ссылок ещё на некоторые качественные материалы по этой теме. 
  • Практическое руководство по systemd, подготовленное Fedora Project.
  • Шпаргалка от Fedora Project, в которой сопоставлены команды старой системы SystemV и systemd.
  • Подробности о systemd и о причинах создания этой системы.
  • Материал со сведениями и советами, посвящённый systemd.
  • Материалы Леннарта Поттеринга (Lennart Poettering), архитектора и основного разработчика systemd. Эти материалы предназначены для системных администраторов, они написаны между апрелем 2010 года и сентябрём 2011, но они всё ещё не потеряли актуальности. Практически все другие достойные публикации о systemd основаны на этих статьях.
  • Материал об управлении датой и временем системы с помощью systemd.
  • Статья об управлении запуском компьютера с использованием systemd.

Итоги


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

Даже хотя файлы конфигурации сервисов, созданные нами в ходе экспериментов, обычно вызываются с помощью таймеров, для их вызова можно, в любое время, воспользоваться командой вида systemctl start myMonitor.service. Одним таймером может запускаться несколько задач. Это могут быть, например, и Bash-скрипты, и утилиты Linux. Файл конфигурации сервиса можно составить так, чтобы при его вызове выполнялись бы несколько скриптов. Можно сделать и так, чтобы скрипты запускались бы по отдельности.

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

Чем пользуетесь вы? Таймерами systemd или заданиями cron?

Let's block ads! (Why?)

Июль. Пора считать ракетки — «Ответ: 14! И не только Марс»

Вячеслав Ермолин — 1 августа 2020

Результаты пусковых программ к августу 2020 года (по странам).


Статистика запусков с начала года (июль). Легенда в конце текста.

Июль 2020 года стал месяцем-рекордсменом. 14 запусков от пяти стран. Две аварии.


Запуски за июль.

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

Китай. Шесть запусков. Спутники ДЗЗ, технологические и для разведки. Геостационарный спутник связи. И первый для Китая «марсианский» запуск — успешно запущена тяжелая АМС к Марсу. Авария при запуске новой ракеты-носителя от частной компании.

США. Четыре запуска. Успешный запуск «марсианской» миссии — очередной (пятый) марсоход. Первый в году коммерческий спутник для SpaceX (корейский разведчик). Военные спутник на редко летающей Minotaur IV. Авария мелкоракетки от Rocket Lab.

Россия. Два запуска. Грузовой корабль снабжения МКС — Прогресс МС-15. Два геостационарных спутника связи на РН «Протон».

■ Япония. «Марсианский» запуск арабской АМС к Марсу.

Израиль. Неожиданный запуск спутника разведки.

Европа, Индия, Иран, и другие … ничего не запустили… для них выход из карантина затянулся.

Такой темп запусков (12-15 в месяц) предполагался в прогнозах 19-го года. Но амбициозные планы на 20-й год уже не будут реализованы в полном объеме.


Прогнозы (неофициальные от меня) на 2020 год


Легенда к инфографике статистика

Hires статистика запусков 2020 года
Hires запуски за месяц

Let's block ads! (Why?)

Небольшое расследование расследования по делу хакера, взломавшего Twitter

Наверное, все помнят, как около 2 недель назад были взломаны более 50 крупных Twitter-аккаунтов (Маска, Гейтса, Обамы, Apple и др).

Правоохранители задержали троих подозреваемых – 17-летнего Graham Clark и 22-летнего Nima Fazeli («Rolex») из Флориды, а также 19-летнего Mason Sheppard («Chaewon») из Великобритании.

Во всей этой истории меня заинтересовало то, как вычислили реальных персонажей, стоящих за этой атакой. А точнее одного персонажа Mason Sheppard с ником «Chaewon».

Перед атакой на Twitter, пользователь «Chaewon» разместил на форуме «OGUsers» объявление о продаже услуги замены адреса эл. почты для Twitter-аккаунтов.

К несчастью для хакеров, данный форум был взломан 31.03.2020 г. (и до этого в конце 2018 г.), а его дамп находится в паблике (я писал про это в Telegram-канале).

Об этом и пишет спецагент налоговой службы США Tigran Gambaryan (Тигран Гамбарян) в своем отчете (PDF).

В дампе форума для пользователя «Chaewon» был найден адрес эл. почты (kpopisepic51@gmail.com) и IP-адреса (79.66.149.155 и 82.132.236.55).

С одного из этих IP также зарегистрирован пользователь «mmm» (f77twitter@gmail.com). Судя по нашей информации пароль этого пользователя «Mason123». С точно таким же паролем на форуме находится пользователь «Ghoxl» (20fdisciplina@gmail.com). Кстати, у «Chaewon» в мессенджере Kik имя «MasyOGF», такое же, как и у «mmm, о чем оба пользователя сообщали на форуме сами.

И вот тут начинаются странности с отчетом спецагента Тиграна Гамбаряна. Он пишет про связь «Chaewon» с неким пользователем «Mas» (masonhppy@gmail.com) по IP-адресу на том же самом форуме «OGUsers». Однако, никакого «Mas» с адресом masonhppy@gmail.com там нет, а есть связанные «mmm» и «Ghoxl» (см. выше) и пользователь «mas» (poop987@protonmail.com).

Пользователь «Chaewon» действительно оставлял сообщение на форуме с текстом “IT IS MAS I AM MAS NOT BRY I AM MAS MAS MAS!@”, как пишет спецагент. Кстати, “BRY” это сокращение от “BRYSON”, пользователь «Bryson» заблокирован на данном форуме за мошенничество.

Если внимательно анализировать дамп форума, то видно, что 15.05.2019 пользователь «mas» сменил имя на «Chaewon», а спустя почти месяц 19.06.2019 имя «mas» занял пользователь «wasdwasd123».

Далее спецагент находит адрес masonhppy@gmail.com в базе «Coinbase» и видит там имя/фамилию «mason sheppard».

Тут тонкость в том, что адреса masonhppy@gmail.com нет ни в базе «OGUsers» (о чем я уже написал выше), ни в утечке паролей пользователей «Coinbase». Этот адрес не светился ни в одной другой утечке паролей, которые мы анализировали (чтобы вы понимали речь идет о более чем 30 миллиардах паролей, прошедших через нас за несколько лет).

Каким образом адрес masonhppy@gmail.com появился в расследовании мне установить не удалось.

Получается, что спецагент что-то не договаривает в своем отчете. Либо он имеет доступ к базе, информацию о которой не имеет права разглашать (например, доступ к базе «Coinbase» в режиме реального времени для поиска по IP), либо Mason Sheppard был найден по-другому (например, через запрос британскому провайдеру «TalkTalk Communications Limited» из чьей сети “сидел” хакер) и по какой-то причине это также не может быть разглашено. Тогда часть расследования просто пропущена в опубликованном отчете, с целью скрыть реальные способы деанона, которые используются спецслужбами. Возможно спецслужбы США просто притянули доказательства за известное место. Ну либо самый плохой вариант – взяли вообще не того.

Новости про утечки информации и инсайдеров всегда можно найти на Telegram-канале «Утечки информации».

Let's block ads! (Why?)

Есть возраст?

image
Алоха, хаброжители! Каждый из вас делает это ежедневно. А все вместе мы делаем это всё дольше и дольше. Это — старение. Ожидаемая продолжительность жизни в развитых странах удвоилась за последние 150 лет.

Этот график в упрощённой форме показывает, что именно мы теряем и приобретаем в течение жизни. Он составлен на основе когортных данных. Из-за того, что данные за определённые периоды были неполными, кривые графика не охватывают все возрастные категории. Например, среди детей были собраны не все данные, либо по абсолютно другим методикам. К тому же детальные исследования среди 80-100-летних стали возможными только недавно — до этого большинство пробандов просто не доживало до таких преклонных лет.
image

За 100% приняты максимальные значения, достижимые в течение жизни. Теперь по отдельным параметрам:

image

Сила
Мышечная сила достигает своего пика к 30 годам и затем начинает постепенно снижаться. Обьём остаётся тем же, но за счёт прироста жировой ткани (на снимке МРТ бедра жир белый, а мышцы тёмные). Это если не тренироваться.

Скорость.
Это — да и ещё раз да. Я чувствую, что много чего уже не могу делать так же быстро, как 20-летние. Например вот это подныривание под ленту… да много ещё чего. Но, с другой стороны, на подьёме в горы меня (и мою астму) шутя обгоняют 70-летние поджарые старушки в треккинговых ботинках и шортиках. Некоторые из них при этом хихикают в кулачок.

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

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

Финансы.
Посконная мудрость, согласно которой «в 30 лет ума нет- и не будет; в 40 лет денег нет — и не будет», опровергнута статистическими данными, по которым накопление личного состояния идёт, самое позднее, до 50 лет. После выхода на пенсию количество денег, которыми человек свободно располагает, закономерно уменьшается.

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

Деменция и когнитивные навыки (интеллект и логическое мышление).
Деменция подкрадывается незаметно и прячется под тысячей масок. Мне часто приходится слышать от пациентов:
— Как в спортзале тренишь, так и мозги надо прокачивать. Вот мне деменция не грозит, потому что я каждый день решаю кроссворды.
Так ли это? К сожалению, нет. Мозг устроен немного сложнее, чем мускулы. Деменция косит всех подряд — эрудитов и полиглотов, знаменистостей и меценатов. Но чем выше интеллект, тем больше тот резерв, которым можно противостоять деменции. Снизить (а не свести к нулю) риск деменции может образование новых синаптических связей в центральной нервной системе, иными словами, обучение новому (а не повторение уже известных скиллов, как решение кроссвордов). Причём это новое должно быть действительно новым, диаметрально противоположным тому, что вы уже умели или знали до этого. Например, если до этого вы были лыжником, то самое время перейти на тай-чи гимнастику. Несмотря на кажущуюся медлительность и простоту, тай-чи — это серьёзный челлендж уже в силу ассимметричности движений. Фотограф Лени Рифеншталь впервые нырнула с аквалангом, когда ей было уже хорошо за 70. Ей удалось сохранить ясность ума и хорошую память в течение долгих лет.

image

Ответственное поведение (добросовестность, сознательность).
Знание и выполнение принятых в обществе норм и правил. Порядочность и прилежность. Очень сильно зависит от культурных норм и особенностей воспитания. Как-то мы с пятилетней дочерью поехали в отпуск в Эльзас. Мы гуляли в лабиринте средневековых улочек и я с любопытством заглядывала в крошечные патио, цветущие летние дворики.
— Мама! — сказала мне дочка. Нельзя по таким местам всё время лезть. Там же написано: «Приват».

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

В рамках социокультурного проекта «Forever young» исследователи задали десять вопросов сотне жителей Берна в возрасте от десяти до ста лет:
• На какой возраст вы себя ощущаете?
• Как вы справляетесь со старением?
• Как долго вы хотите прожить?
• Какой возраст вы считаете самым лучшим?
• Как именно вам хотелось бы постареть?
• Предпринимаете ли вы что-нибудь, чтобы замедлить старение?
• С какого возраста люди считаются старыми?
• Bы мечтаете о бессмертии?
• Ощущаете ли вы страх перед смертью?
• Что бы вам обязательно ещё хотелось пережить, испытать в оставшейся жизни?

А вам есть что сказать по этому поводу? Можно высказаться в комментариях.

Есть возраст? Есть. А если «нет»?
Отвергни однозначность истин,
Тебе сегодня столько лет,
Как в Безинги подводных быстрин.

Есть возраст? Нет. А если «да»?
Но в Безинги бурлит вода,
Она умчит тебя туда,
Куда не каждому повадно,
Но ощущение отрадно:
Прозрачна с выси быстрина.

Let's block ads! (Why?)

Последнее обновление CentOS ломает GRUB2-efi загрузчики

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

О проблеме на форумах и багтрекерах начали писать вчера. Похоже, что проблема затрагивает все системы с UEFI загрузчиком и актуальна как минимум для версий CentOS 7.8 и 8.2. Вот и мне вчера под вечер не повезло обновиться и перезагрузить сервер, обеспечив себе ночь веселья.

Проблема проявляет себя в момент перезагрузки сервера в виде зависшего экрана с заставкой биоса, от чего сначала вообще не понятно, что происходит — ни ошибок, ни консоли grub, только зависшая заставка bios.


Решение

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

yum downgrade grub2\* shim\* mokutil

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

После этого загрузчик обновится на старую версию и сервер должен загрузиться.


Исключение пакетов из обновления

Чтобы при следующем обновлении загрузчик опять не сломался, надо добавить проблемные пакеты в исключения (строка exclude=grub2* shim* mokutil) в файл конфигурации yum /etc/yum.conf.

Проблемные версии пакетов для CentOS 7, именно с ними ломается UEFI загрузчик:
grub2-2.02-0.86.el7.centos.x86_64
shim-x64-15-7.el7_9.x86_64

Let's block ads! (Why?)

Как видеоигры помогают прокачивать реальные навыки и найти работу мечты: расшифровка

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

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

Делимся с вами расшифровкой эфира.

***

Меня зовут Андрей Чернявский. Я выпускник ВМК МГУ, 2005 года, кафедра квантовой информатики. Преподавал довольно долго там же. Моя жизнь связана с наукой, это – моя бесконечная любовь. Я занимаюсь квантовой информатикой, также – неврологией в Научном центре неврологии, и, помимо этого – анализом данных и разработкой учебных курсов проекта Game Academy, формально — CTO данного проекта. Хотел бы рассказать именно о нашем проекте.
Проект посвящен играм, как можно догадаться из названия и из моего фона – все, наверно, узнают Fallout, о котором, в том числе, пойдет речь сегодня.

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

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

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

Любые игры полны условностей и упрощений для повышения реиграбельности, цена ошибки в них – около нуля.


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

Замечательный комментарий. Об этом мы очень много думали.

Приведу один пример: в Испании есть компания на базе университета, которая делает приложение по связи игр с навыками. У них есть одна научная статья (правда, у меня к ней довольно много критики). Я попробовал их сервис, в который подключается аккаунт Steam – он рассказывает, в какие игры вы играли в последнее время и какие навыки как бы натренировали. Я тогда играл в Fallout 4 (честно признаюсь – я не фанат этой части, люблю предыдущие, особенно 1 и 2); мне написали, что, оказывается, я, поиграв часов 10 в Fallout 4, натренировал решение проблем, аналитическое мышление и все такое. Правда, я не понял, как это F4 тренировал мое аналитическое мышление.

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

Четких понятий здесь нет, но все примерно понимают, что это означает. Hard — это конкретные навыки: например, играть на гитаре, резать по дереву, бить по мячу сильно в футболе (у меня из этих есть только первый навык). Soft это очень широкое понятие: принятие решений, эмоциональный интеллект, “traits”, мотивации.

Игры гораздо сильнее относятся именно soft; они очень редко развивают hard-скиллы. Определенные вещи можно тренировать, например, с помощью VR. В Центре неврологии шлемы виртуальной реальности используются для реабилитации после инсультов, это можно причислить к soft, хотя мы говорим не совсем об этом. Если подумать о чем-то более конкретном, например, можно взять EVE Online. Как многие шутят, это «симулятор Excel» — работу с таблицами вполне можно назвать хардскиллом.

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

Какие навыки человек мог развить после 5000 часов в DOTA?


Да, это безумное количество времени. Есть «теория десяти тысяч часов»: предполагается, что столько времени требуется, чтобы стать настоящим мастером в каком-то деле – то есть, получается половина пути.

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

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

Вот моя кепка VaultTec. На ней есть надпись: HARD WORK IS HAPPY WORK. Я с этим согласен на все 100%. Когда я был безумно счастлив от своей работы? Например, когда я делал свою диссертацию и неделю сидел почти без сна, как псих, над кодом по анализу квантовой запутанности, пытаясь его перевести на первую версию QUDA, которая была жутко неудобна, это было очень сложно, и мне было безумно интересно. Для диссертации это было вообще не важно, и дедлайна не было, но я все равно почти не спал, работал и получал безумное удовольствие.

Я надеюсь, у всех когда-то было что-то подобное в работе. Еще был другой проект по квантовым вычислениям, над которым я сидел две недели и спал по 4 часа максимум; при этом, можно было сделать в три раза меньше того, что сделал я. Или – работа над данными в Game Academy. Когда я начинал это делать, это было занятие на уровне «я попробую помочь» — но потом я снова сидел без сна, связывал разные работы, машинное обучение, статистику. Это было очень трудно, но приносило невероятное удовольствие.

К чему я это рассказываю? Многие пишут на тему того, «как найти призвание». Важно понять следующее: обычно человек в своей жизни уже делал что-то, что было связано с его призванием. Он уже этим занимался. Часто такие моменты ищут в детстве или еще где-то. Кроме того, человек впадает в поток (хотя я и не люблю слово «поток»): в таком состоянии ему не нужна внешняя мотивация, он будет неотрывно сидеть и делать. Но ведь именно так мы постоянно играем в игры: вроде бы и спать хочется, и есть, но ты сидишь и играешь, у меня так было много раз с Fallout, Arcanum и другими RPG-играми. То же самое в работе.

Я называют это «core motivations» — вещи, которые сами по себе являются сверхмотивационными для человека, за которыми он будет сидеть без сна.

Что для вас есть хорошие игры?


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

Для меня хорошие игры — это игры, в которых есть настоящие трудности, в которых победить сложно. Примеров можно привести множество: например, Stellaris или Europa Universalis 4. Там такие правила, что освоить их будет сложно любому человеку. Или, например, Dark Souls – конечно, есть люди с супер-реакцией, и им играть легко, но большинство тратит на нее огромные усилия. Это тоже относится к core motivations.

Как-то раз, когда я занимался данными для Game Academy, я вдруг обнаружил, что вообще не играю – ни ночью, ни днем, ни в одну игру. И я подумал, что это странно: я же люблю играть, что происходит? Вспомнил, что, когда я занимался другими своими научными проектами, я тоже не играл.

Я стал думать, почему, и нашел очевидный ответ: в моих любимых однопользовательских RPG присутствуют ровно те вещи, которые я люблю в работе. Их две. Во-первых, развитие персонажа: если я дохожу до level cap, я бросаю игру, потому что мне надо постоянно развиваться – и в моих научных работах тоже всегда присутствует развитие, обучение, я чувствую, что расту. Во-вторых, охота за сокровищами: в RPG всегда ищешь сундуки, в которых может оказаться новый супер-меч, и в науке, анализе данных, то же самое. Это мой стиль. Я не беру стандартные методы, я беру сложную задачу, пробую её по-всякому и сижу над ней ночи напролет, пока не нарвусь на решение.

Вот те вещи, которые двигают поток — как в игре, так и в работе. Их можно анализировать через игры. И, кроме этого – отличать hard skills от soft skills, но при этом не привязываться к слову «скиллы» и стараться смотреть шире.

В соревновательных играх разделяют роли на carrier, support, технических игроков. Вы следите за этими ролями в исследованиях?


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

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

Как зависит уровень интеллекта от жанров, на что показывает высокий и низкий уровень игроков?


Я пытался в анализе данных использовать жанры, но это не работает. «Жанр» — это очень условное разделение. Взять хотя бы мои любимые RPG: тут есть action-RPG, есть сюжетные, есть олдскульные с дико сложной механикой, есть Fallout 4, который и к RPG причисляется условно (даже Fallout 3 гораздо проще в плане механики, чем первые части). Или стратегии: к ним относятся как совсем простенькие игры, так и серии от Paradox.

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

Существует ли строгая статистическая корреляция между профессией и любимыми играми?


Я расскажу, с чего началась моя работа. Основатель проекта, Ирина – близкая подруга моей близкой подруги, она позвонила мне, чтобы обсудить его. Я подумал – классно, я люблю игры, сам думал об этом, сам давно замечал подобное, было бы здорово заодно посмотреть на современный machine learning (я до этого занимался ML только в 2004-06 годах). Удалось собрать (с использованием открытых старых данных из Steam) довольно большую базу с информацией о том, во что и сколько играли игроки и какие у них профессии. В процессе я попробовал новый machine learning, нейросети, SVM, деревья решений, бустинги.

Профессий, связанных с IT, оказалось не намного больше, но все же больше. Я стал думать, как к этому подойти, обсуждал с людьми. Мне порекомендовали использовать классическую статистику; это, конечно, в разы сложнее, чем ML. Были использованы банальные точные тесты; тут прелесть в том, что можно получить совершенно строгие зависимости и конкретные (а не абстрактные) корреляции. Они были получены, что меня очень порадовало. Когда работаешь с реальными данными, связанными с людьми (например, в неврологии), получить что-то статистически значимое очень тяжело, но здесь — удалось.

Удалось получить довольно сильные корреляции между IT-профессиями и определенными играми: например, сложными tower defense. Было забавно потом обсуждать это с людьми: у меня много знакомых программистов, особенно – системных программистов, и оказалось, что многие из них играют в Defense Grid («любимая игра, всем отделом играем!»). Я её опробовал — там действительно требуется алгоритмическое мышление. Попадались и другие головоломки, и есть определенные идеи, как можно расширить и углубить это исследование; в общем, корреляции действительно статистически значимы. Если интересно, можно поговорить об аккуратности результатов.

В другом вопросе упоминалась серия Total War. Второй важный результат нашей работы – корреляция между сериями Total War / XCOM и менеджерскими позициями. Это было интересно: мне очень нравятся обе эти серии, но хорошо играть в них у меня никогда не получалось, сколько бы я ни пробовал. Тогда я решил засесть за XCOM на день (не просто так, а для проекта!). У меня опять толком не получилось, но я аккуратно записал, что именно меня напрягает в этой игре и почему мне тяжело играть в нее. Позвонил Ирине – она сама менеджер, у неё PhD по менеджменту – и описал свои наблюдения. Она ответила: «О, ты только что мою жизнь описал».

Например, одна из основ игры в XCOM – это работа с рисками. Когда играешь в RPG, тебе обычно не приходится просчитывать риски на уровне более сложном, чем обычный выбор из двух зол. В XCOM всегда существует много вероятностей – в том числе глобальных, заметных не сразу и действующих отложенно (а в RPG – только «взял не тот меч, тебя убили, перезагрузился»). Их нужно уметь оценивать. Если вы в XCOM играли, вы знаете, как устроен тактический ход: у каждого юнита есть два действия, которые можно потратить на передвижение; по-хорошему, нужно тратить одно (мало ли, что впереди), но это же нудно! Нужно делать баланс и учитывать мотивацию – это довольно менеджерская вещь. Корреляция сильная, и обсуждения с конкретными людьми показали, что она соответствует действительности.

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

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

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

Серьезные работы все же есть. Например, было доказано, что 3D Action (многие в них играют) тренируют то, что называется hand-eye coordination, а также быстрое принятие решений. У меня был курс по принятию решений, и тут важно отметить, что быстрое и медленное принятие решений – это два совершенно разных soft skills.

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


Мы анализируем не только по Steam. У нас было уже несколько MVP с разными принципами работы. Сначала мы делали автоматизированную систему, основанную на найденных корреляциях, но она давала мало информации. Потом мы попробовали противоположный подход с аудитом, и это дало нам много инсайтов и повысило понимание. Мы проводили анализ игр и опрашивали самого человека о том, что его ночью держит в играх, о жизненной ситуации и так далее. Основная идея в том, что нельзя на 100% расписать человека по его профилю в Steam, это не работает. Человек должен сам себя анализировать, заглядывать внутрь себя. Я вот до того момента, как меня осенило на тему «почему это я не играю во время проекта?», ни разу не задумывался о том, что меня держит в играх то же, что и в работе. Большинство людей, с которыми мы ведем обсуждения, тоже об этом не задумывается.

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

Существует ли строгая статистическая корреляция с профессиями?


Да, как я сказал, она существует. Радость абсолютная. Один из важных моментов здесь — это коррекция P-value, то есть коррекция статзначимости на множестве тестов (кто знает статистику, тому понятно), потому что проверяется много всего. Тут сравниваются разные игры с разными типами профессий, и нужно статистическую значимость учитывать, делить разные сметы. Во многих работах об этом абсолютно забывают, но здесь – что очень здорово – даже с полной строгостью коррекции статзначимости все было действительно значимо, и результаты действительно есть. Как в тех корреляциях для программистов и менеджеров, которые я приводил.

Как способность играть в сложные игры вроде SpaceChem и Stellaris лучше показывает уровень интеллекта, чем полученное образование?


Я приведу один пример. У меня есть очень близкий человек, у него 9 классов образования. Понятно, что в обществе к такому пренебрежительно относятся. Но он с детства всегда играл в хорошие игры, первый Fallout проходил, например. Всегда было понятно, что у него все в порядке с интеллектом, несмотря на 9 классов. Сейчас у него все хорошо, есть успешный бизнес. Я уверен, что это не единственный пример (собственно, я знаю еще примеры).

Если взять SpaceChem — это еще одна игра, которая сильно коррелируется с IT. В Steam можно найти отзывы на неё, вроде «прихожу с работы программистом, снова программирую этот химический завод». А в Stellaris и другие игры от Paradox просто невозможно играть без хорошо развитой рабочей памяти. Там очень много правил, и если их не держать в уме, все рушится. Если в какой-то игре – в том же Stellaris, или даже в Skyrim – у человека наиграно 500 часов, из этого можно сделать определенные выводы. У Skyrim нет онлайна, все квесты можно переделать часов за 100 – значит, человек что-то креативное сам придумывает, проявляет нестандартное мышление. Такие связи тоже есть, и люди, склонные к творческим профессиям, часто играют в определённые игры огромное количество часов, придумывая что-то самостоятельно. К таким можно отнести Stardew Valley или Cities: Skylines – я в них играл и просто проходил, но они могут придумывать красивую геометрию города, например, делать свои карты или что-то еще необычное.

Научная сторона: как собираются данные, как анализируются, почему создатели платформы уверены в том, что рассказывают?


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

Какие игры рекомендуются для того, чтобы прокачать, например, уверенность в себе?


Важный вопрос. Аудитория, с которой мы начали (мы, конечно, будем расширяться в будущем) – это довольно трудная аудитория, геймеры. Часто они бывают на низкооплачиваемых профессиях, которые могут быть автоматизированы. Зачастую, когда с человеком общаешься или опрашиваешь его, возникает впечатление, что его основная трудность – не в том, что он чего-то не умеет, а в неуверенности. Даже если человек играет в те же игры от Paradox, объективно сложные, он все равно говорит «да я ничего не могу, куда мне». Неуверенность – это один из ключевых моментов. Сейчас я не могу посоветовать определенные игры, но мы подходим к этому комплексно. Одна из задач нашей платформы – помогать людям объективно видеть свои плюсы. Я очень надеюсь, что это получится.

Будете ли анализировать игровых стримеров?


У нас был интересный эксперимент, когда Ирина с HR-ом анализировали стримера по Fortnite, подмечали некоторые навыки, но в целом – это планы на будущее.

Существуют разноплановые слои игровой информации. Самый простой – это сами аккаунты XBOX / PS Live / Steam, часы игры, ачивменты, рецензии, и на это сейчас делается упор. Плюс – опросы, которые человек заполняет более широко; здесь все чуть сложнее. Следующий слой – это внутриигровое поведение человека, тут — гораздо сложнее. Мы на это нацелены, но здесь нужны более серьезные подходы. Хотя уже есть примеры – например, компания, которая анализирует игроков в DotA и предлагает советы по тренировке.

Расскажите о людях, которые играют в одну игру (например, action), она им надоедает, они идут в следующую (например, гонку), и так далее, они не заканчивают ни одну из них и постепенно возвращаются по кругу.


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

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

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

В RPG я обычно играл за воинов, очень редко – за магов (если это фэнтези); все прямолинейно, обычно, типа «lawful good». Но я попробовал выйти из этого застарелого паттерна, и в очередную сессию в Enderal (это мод для Skyrim, бесплатный, отличного качества) решил играть максимально неблизким мне персонажем. Я стал играть за ассасина, и это был невероятный экспириенс. Я делал это осознанно, анализируя свои ощущения. Изначально я думал – господи, да зачем я его взял, сейчас бы тут все решил за воина. А потом оказалось, что есть много прикольных возможностей, можно проходить различными способами, иногда – даже лучше, чем воином.

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

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

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

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

Но нужно помнить, что для того, чтобы совет был действительно полезным, им нужно пользоваться. Он должен войти в привычку, скоррелироваться с бытом. Здесь как раз помогают игры. Если подумать – сколько решений мы принимаем в день в жизни? Имеются в виду именно значимые решения, которые заставляют задуматься, а не те, которых мы даже не замечаем (по подсчетам, их может быть 35 тысяч). Их не так много. Но в игре их много – например, каждый ход в Civilization – это пачка решений. И к каждому из них можно применить совет. По моим наблюдениям, для того, чтобы совет вошел в привычку в жизни, нужна неделя-две, если регулярно пользоваться им, но в играх на это нужно несколько часов. В играх очень высокая плотность решений; кроме того, эмоции вызывают запоминание.

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

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

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

У нас на тему вижна был интересный стрим, кстати. И здесь шикарно помогают RPG. Когда я играл в Fallout: New Vegas, я придумал себе образ персонажа, его предысторию, жизненные принципы и цели – и тут внезапно получилось, что решение по генерации персонажа разрешается не за целый день, как обычно бывает у меня, а за пять минут. Каждое решение, встреченное в игре, я принимал с точки зрения целей меня-персонажа – и все решения принимались элементарно. Здесь главное – то, что мозг это запоминает, и ты привыкаешь думать о целях, когда принимаешь решения; более того, мозг запоминает и то, насколько легче даются решения, если есть цель. Естественно, наша методика обучения не ограничивается играми. Нужно поиграть – потом применить в жизни, снова поиграть – снова применить. Игры дают привычку, применять в жизни становится легко, и это действительно помогает. Если честно, я очень нервничал, пока не увидел положительные отзывы – я всегда стараюсь научить людей, для меня очень важно, чтобы они что-то усваивали. В отзывах люди писали, что им стало веселее играть, они перестали читать спойлеры, они начали придумывать кучу безумных историй внутри игр – особенно мне запомнилась одна история из RimWorld. И в жизни наши советы оказались полезны, наши ученики их применяют. Важно не забывать, что без игровой составляющей применение таких советов занимает раз в пять больше времени, и зачастую у людей не хватает терпения применять их.

Игры как опросник сотрудника. Почему опросник легко обмануть, а игру – нет?


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

Насчет модели. В работах постоянно выстраивается модель: «игры – скиллы», «скиллы – работа». В части, где «игры-скиллы», мы разобрались: там не все просто, это не совсем скиллы – это мотивации, их нужно выстраивать. Это очень интересно, когда делаешь анализ данных и пытаешься построить эту модель, получается безумное удовольствие. Понятно, что она пока не закончена, впереди еще очень много интересной работы, мы сотрудничаем с разными людьми, с учеными, у нас замечательные коучи. Мы сейчас планируем взаимодействие с человеком, который занимается лидерством в компании, где много выходцев из BioWare. Очевидно, что модель намного сложнее. И та часть, где «скиллы-работа», тоже. Здесь приведен пример: какие скиллы свойственны стартаперам, какие – разработчикам.

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

То есть, модель не настолько проста. Тут нужна скорее не «работа», а «контекст работы»; в каждой профессии есть контексты, и получение этих контекстов – это безумно интересные задачи на анализ данных.

Как работает профориентирование?


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

Первое – это интроспекция: помочь через игры, через то, как человек играет, намного лучше разобраться в себе. Поставить вижн, понять, куда хочется прийти, понять core motivations. Я искренне считаю, что, если человек в жизни занимается чем-то, что не относится к его главной мотивации и главному счастью, то это какая-то неправильная жизнь.
Хотя не обязательно, чтобы мотивация лежала именно в его работе. Например, если core motivation лежит в семье человека, то он может работать на ее благо и тоже получать огромное удовольствие от этого.

Мне очень хочется помочь людям. Это было мое хобби всегда, я знал, как это делать, знал некоторые приемы. Но в играх это делать намного проще – помочь, поставить, сформулировать, чего человек четко не хочет, понять, в чем человек силен, а дальше — помочь пользователю сформировать путь к этим вещам. По развитию навыков, по выполнению упражнений в жизни и в играх, по конкретным вещам – например, по прохождению каких-то курсов. Наша мечта – сделать так, чтобы это было похоже на skill tree в играх, с различными навыками и выполнением требований для их обретения. Когда этот этап пройден, когда четко можно сказать, какие навыки есть у человека, можно помогать человеку найти работу мечты. От работодателей идет множество запросов на разные вещи; например, я недавно разговаривал с другом по ВМК, у него свой айтишный бизнес – он говорил, как сложно найти программиста-управленца, тимлида в программировании. Программистов самих по себе очень много, хотя среди них еще нужно выбрать хорошего программиста, но еще сложнее – найти человека, у которого при программистской базе есть менеджерские навыки и навыки коммуникации. Игры здесь, конечно, могут помочь.

Кстати, нам в проект нужны два человека. Один – data scientist; работа абсолютно творческая, огромное поле для деятельности, куча задач, очень много работы. Пример задачи: есть названия профессий и есть базы данных с этими профессиями, но названия не коррелируют (того же программиста могут называть по-всякому – программер, кодер, software engineer и так далее). Здесь может помочь обработка описаний профессий и вакансий с помощью NLP. Потом из всего, что есть – из инсайтов, данных, надо будет формировать правила, rule-based-систему, которая будет выдавать людям полезную информацию, которую они прочтут. Работы очень много, безумно интересная работа – я бы сам дальше занимался ею, но на все времени не хватает. Поэтому нам очень нужен человек, которому интересно работать с данными, ML, статистикой; кстати, мой друг поможет со статистикой, он – гуру статистики. И, конечно, наше дополнительное требование – любовь к играм, эрудиция в играх, а также общая эрудиция – надо понимать, что с чем связано, какие есть профессии, работы. Надо знать Python, иметь опыт и любить данные. Должно быть знакомо это состояние treasure hunting, когда смотришь на табличку с данными и думаешь – может, попробовать так, может, здесь будет статистически значимо. Я только сегодня этим занимался, с данными по игрокам в EVE Online. Сначала вроде бы ничего, но потом все-таки нашел значимое.

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

Более того, у меня есть мечта. То гипер-оказуаливание игр с «дофаминовыми ямами», которое сейчас происходит, меня очень расстраивает. Я помню мой глубокий шок, когда я узнал, что «это» есть не только на мобильных платформах. Когда-то мне подарили PlayStation 3 c GTA5 – я стал играть, мне нравилось, попалась сложная миссия. Я ее несколько раз провалил, и увидел окошко: «нажмите кнопку для пропуска». И как это понимать? Это ведь серия, в которой есть сложные задания, приносящие огромную радость при успехе – вспомните миссию с вертолетиком в Vice City. Моя искренняя мечта состоит в том, что Game Academy будет развиваться и сможет доказать пользу игр, и этим повлияет на геймдев – вырастет спрос именно на хорошие игры, и их будет больше выходить.

Важный момент состоит в том, что попытки сделать «edutainment» обычно натыкаются на то, что создатели не могут выдержать баланс: люди, которые преподают, обычно не разбираются в играх, и наоборот, и получается полная каша. Мне приносит безумную радость то, что в нашем курсе, хотя бы, удалось совместить: и в игры интересно играть, и польза есть.
В общем, нам нужен full stack-программист, которому это нравится. Мы сотрудничаем с очень крутым продукт-дизайнером, у нас есть представления, у нас есть wireframe – и это нужно реализовывать, с упором на frontend. Дизайн будет, backend – по большей части на мне и на data scientist, но совмещать это нужно. Нам нужен человек с опытом законченных проектов – чтобы были проекты с deployment и пользователями.

Но, опять же, мы – стартап, нас мало, если что – задачу можно отдать на аутсорс, и в команду нам нужны люди, которые горят играми и хотят, чтобы игры помогали людям.
Если вы хотите поделиться своим опытом того, как вам удалось что-то развить в себе с помощью игр, пишите на почту Game Academy, или на мою почту. Мы рады любому сотрудничеству: может быть кто-то захочет с нами работать; многим нравятся наши проекты, многие помогают по комьюнити и по другим вещам. Я сам начал с того, что просто хотел помочь этой команде. Любому живому обсуждению про игры мы тоже рады. Особенно интересный момент – то, в какие игры вы играете по ночам, что именно держит вас в них и не дает идти спать, и – чувствуете ли вы, что по жизни вас держат такие же вещи. Если кому-то будет интересно отписаться о своем опыте, буду очень рад.



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook — как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса — как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend — как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret — как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock — кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS — как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег — как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs — как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард «Левелорд» Грей, создатель игр Duke Nukem 3D, SiN, Blood — про личную жизнь, любимые игры и о Москве.
  10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем — про игры, их жизненный цикл и монетизацию

Let's block ads! (Why?)