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

Неужели сегодня можно раскрыть преступление вообще не вставая из-за компьютера? Только на основании следов, которые люди оставляют в базах данных, в истории мессенджеров, в логах операторов связи, на камерах наблюдения?

Или это фантастический киберпанк?

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

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

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

Биллинг сотовых операторов

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

Затем следователи изучали несколько других ниточек, в том числе подробно проверяли личности всех, с кем разговаривал по телефону руководитель научного центра Сигнал, где разрабатываются вещества. Оказалось, что 6 июля 2020 года он очень плотно общался с разными сотрудниками ФСБ, которые раньше не попадали в поле зрения Bellingcat. Если раньше руководитель Сигнала общался с ФСБ раз в месяц, то теперь за один день состоялось 15-20 звонков.

Детализацию биллинга продают, в том числе, сотрудники операторов мобильной связи. Детализация звонков и SMS по конкретному номеру стоит 20 тыс. руб. за первый месяц и 7000 руб. за каждый следующий, скидка до 50% при заказе от 5 абонентов. Геолокация по номерам телефонов 110 тыс. руб. за телефон в месяц.



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

Детализация биллинга выявила много интересного, в том числе один из каналов связи фсбшников WhatsApp, что довольно неожиданно.

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

Социальный граф и дата-майнинг

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

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

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



Мы все купленные биллинги загружаем просто в базу MySQL и потом по ней уже можно делать конкретный запрос. Узнать, например, какой номер чаще всего созванивается с другим рассказывал главный расследователь Bellingcat Христо Грозев.

Авиаперелёты

На следующем этапе следователи проверили авиаперелёты каждого сотрудника в этой группе из шести человек.

Узнать попутчиков/пассажиров рейса на чёрном рынке сейчас стоит 15 000 руб. за рейс.

Здесь тоже обнаружилась корреляция.



Информацию по авиаперелётам каждого гражданина можно найти в базах от авиакомпаний. Некоторые из них слиты уже давно. По этим базам нашлось 37 совпадений.



Грозев говорил, что сначала базы пробивали всплепую, но потом стали выбирать их более целенаправленно.

Перелёты и поездки человека за один год пробиваются по базе МВД Магистраль за 2000 руб.



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

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

Базы данных

Следователи Bellingcat собрали информацию на каждого из шести членов группы. Услуга Роспаспорт (данные паспорта, загранпаспорта, адресов регистрации, фото владельца) стоит всего 1400 руб. с человека, за 11 человек со скидкой с могли взять 10 тыс.



Места парковок и поездки из базы Поток (движение и остановки по камерам города) стоят 2500 руб. за авто за первый месяц и 1500 руб. за следующие.

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

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



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



Bellingcat несколько лет отслеживает разнообразные источники информации в открытом доступе и собирает их. Собственно, такое же хобби есть у многих читателей подпольных форумов и телеграм-каналов со сливами данных. Удобнее провести поиск по своим базам, чем запускать платный пробив по коммерческим сервисам вроде всем известного телеграм-бота Глаз бога, у которого в России более 200 тыс. пользователей.


Платформа Глаз блога объединяет более 40 источников информации. Один запрос на расширенный поиск через телеграм-бота стоит 30 рублей

Активисты Bellingcat собрали большое количество таких баз. В наше время подобным занимаются все, кто интересуется исследовательской журналистикой с цифровой криминалистикой в интернете (forensic investigations).

Цифровая криминалистика

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

Многие преступления можно расследовать и раскрыть не вставая из-за компьютера.

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

Слив персональных данных как фундамент гражданской журналистики

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

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

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

В принципе, тут нет ничего нового.

В России такие базы начали продавать на компакт-дисках ещё в 90-е годы. Около десяти лет назад были популярны сервисы пробива Radarix.com и RusLeaks.com, которые были вскоре закрыты. На их место пришли другие, а в даркнете подобные сервисы довольно хорошо известны. В последние годы отрасль вышла на принципиально новый уровень, поскольку количество баз данных сильно увеличилось. На рынке действуют даже специальные гаранты сделок, посредники, которые защищают клиентов (покупателей информации) от мошенников.

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

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

• Таргетированный сбор информации на конкретного человека через краудсорсинговую сеть анонимных информаторов (Google для персоналий)
  
• Автоматизированная биржа купли/продажи персональных данных. Например, каждый пользователь сможет продать здесь видеозаписи, сделанные со своего видеорегистратора или смартфона с записью соседей или коллег по работе.
  
• Создание фейковых личностей через генерацию персональных данных в БД (сейчас в ФСБ людям на выдуманные фамилии делают паспорта с давней датой выдачи, но история авиаперелётов, штрафы за парковку и другой цифровой след у них отсутствует).
  
• Генерация источников с отравленными данными от контрразведки.

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

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

Минутка заботы от НЛО

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

Как написать комментарий и выжить

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

Что делать, если: минусуют карму | заблокировали аккаунт

Кодекс авторов Хабра и хабраэтикет
Полная версия правил сайта

---

На правах рекламы

Подыскиваете VDS для отладки проектов, сервер для разработки и размещения? Вы точно наш клиент :) Посуточная тарификация серверов самых различных конфигураций, антиDDoS и лицензии Windows уже включены в стоимость

Подробнее об этом хаке и особенностях его работы можно узнать из доклада на !!con 2020 Playing Breakout inside a PDF!!

Если вы его не смотрели, то попробуйте открыть файл breakout.pdf в Chrome.

Как и многие из вас, я всегда считал PDF довольно безопасным форматом: автор создаёт текст и графику, после чего он открывается в программе просмотра PDF, больше ничего не делая. Несколько лет назад я мимоходом слышал об уязвимостях Adobe Reader, но особо не задумывался о том, как они могут возникать.

Изначально Adobe сделала PDF именно для этого, но мы уже выяснили, что сегодня это совсем не так. В 1310-страничной спецификации PDF (на самом деле довольно понятном и интересном чтиве) описывается безумное количество возможностей, в том числе:

• Встроенный Flash
• Аннотации в виде звука и видео
• Аннотации в виде 3D-объектов (!)
• Метаданные Web capture
• Произвольные математические функции (в том числе и Тьюринг-неполное подмножество PostScript)
• Формы с поддержкой Rich text, использующие подмножество XHTML и CSS
• Вложения в виде файлов и коллекций файлов

но самое интересное для нас

• Это скрипты JavaScript на основе стандартной библиотеки, совершенно отличающейся от библиотеки браузера

Разумеется, большинство программ для чтения PDF (кроме Adobe Reader) не реализует основную часть этих возможностей. Однако Chrome реализует JavaScript! Если вы откроете подобный файл PDF в Chrome, то он запустит скрипт. Я выяснил, повторив действия из этого поста о создании PDF с JS.

Однако здесь есть хитрость. Chrome реализует только крошечное подмножество огромной поверхности Acrobat JavaScript API. Реализация API в PDFium браузера Chrome в основном состоит из подобных заглушек:

FX_BOOL Document::addAnnot(IJS_Context* cc,                           const CJS_Parameters& params,                           CJS_Value& vRet,                           CFX_WideString& sError) {  // Not supported.  return TRUE;}FX_BOOL Document::addField(IJS_Context* cc,                           const CJS_Parameters& params,                           CJS_Value& vRet,                           CFX_WideString& sError) {  // Not supported.  return TRUE;}FX_BOOL Document::exportAsText(IJS_Context* cc,                               const CJS_Parameters& params,                               CJS_Value& vRet,                               CFX_WideString& sError) {  // Unsafe, not supported.  return TRUE;}

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

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

Вероятно, можно встроить в PDF компилятор C, скомпилировав его в JS, например, с помощью Emscripten, но тогда компилятор C должен будет получать ввод из формы простого текста (plain text), а вывод выполнять снова в поле формы.

На самом деле, я заинтересовался PDF пару недель назад из-за PostScript; я читал посты Дона Хопкинса о NeWS напоминающей AJAX системе, но реализованной в 80-х на PostScript.

Забавно, что PDF стал реакцией на PostScript, который был слишком выразительным (являясь полнофункциональным языком программирования), слишком сложным в анализе и восприятии. Наверно, PDF по-прежнему остаётся в этом плане шагом вперёд, но всё равно смешно, что он разросся всеми этими возможностями.

Ещё один любопытный момент: как любой долгоживущий цифровой формат (лично я испытываю нежные чувства к файловой системе FAT), PDF сам по себе является своего рода историческим документом. Мы можем отследить, как поколения инженеров добавляли нужные им в своё время функции, пытаясь при этом не поломать уже существующие.

Я не совсем понимаю, зачем разработчики Chrome вообще заморачивались поддержкой JS. Они взяли код программы чтения PDF из Foxit; возможно, у Foxit был какой-то клиент, использовавший валидацию форм через JavaScript?

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

Breakout

Так что же мы можем сделать с предоставляемой нам Chrome поверхностью API?

Кстати, должен извиниться за неидеальное распознавание коллизий и непостоянную скорость игры. БОльшую часть игры я содрал с туториала.

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

Мы не можем менять цвет заливки текстового поля во время выполнения, зато можем менять прямоугольник его границ и задавать стиль границ. Мы не можем считывать точное положение мыши, однако можем при создании PDF привязать к полям скрипты mouse-enter и mouse-leave. Также во время выполнения нельзя добавлять поля: придётся ограничиться тем, что мы поместили в PDF в момент создания. Любопытно, почему разработчики выбрали именно эти методы? Это похоже на какой-то стереотип о программировании на олдскульном FORTRAN: необходимо объявлять все переменные заранее, чтобы компилятор мог статически выделить под них память.

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

• Ракетку
• Кирпичи
• Мяч
• Очки
• Жизни

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

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

Во-вторых, мы создаём поле под названием whole, закрывающее всю верхнюю половину экрана. Chrome не ожидает, что отображение PDF будет меняться, поэтому если перемещать поля в JS, то получатся довольно сильные артефакты. Это поле whole решает данную проблему мы включаем/отключаем его во время рендеринга кадра. Этот трюк заставляет Chrome подчищать артефакты.

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

Полезные ресурсы

• Справочное руководство по PDF, шестая редакция
• Справочное руководство JavaScript for Acrobat API
• Туториалы Брендана Загерски Minimal PDF и Hand-coded PDF
• В документе PDF Inside and Out есть отличные примеры.
• Библиотека Python pdfrw обладает идеальным для такой работы уровнем абстракции. Многие библиотеки слишком высокоуровневые и раскрывают только графические операторы. Самостоятельная генерация данных PDF возможна, но довольно неудобна, потому что нужно правильно реализовать форматы структур данных и байтовые сдвиги.

---

На правах рекламы

Закажите сервер и сразу начинайте работать! Создание VDS любой конфигурации в течение минуты, в том числе серверов для хранения большого объёма данных до 4000 ГБ. Эпичненько :)

Иногда YouTube или Twitch не подходят как стриминговая платформа скажем, если вы пилите портал с вебинарами или контентом 18+, нарушаете авторские права или хотите максимально отгородить свою трансляцию от остального интернета. У них есть много альтернатив как в виде сервисов (те же минусы, недостаток контроля и непредсказуемая политика), так и в виде self-hosted решений. Проблема опенсорсных стриминговых проектов в том, что все они начинаются с крохотной связки из пары технологий, а затем отчаянно пытаются вырасти в сервис, добавляя сложные веб-интерфейсы, чаты, библиотеки стримов и в конечном счёте отдаляясь от исходной цели: дать миру инструмент, который по понятному мануалу позволит запустить свой сервер трансляций. Что с ним будет дальше, в какие системы будет встроена эта картинка это только ваше личное дело, а самописный аналог твича с лагающими и отваливающимися сервисами и периодически валящимся билдом не нужен никому, кроме его разработчиков. Поэтому в этой статье мы разберём минимальную цепочку действий для запуска своего RTMP-сервера с плеером.

Структура

Здесь всё просто: за приём и кодировку потока из OBS отвечает RTMP модуль Nginx'a. Сконвертированный поток он выставляет наружу, где его подбирает HLS (HTTP Live Streaming) клиент в браузере и выдаёт уже готовую картинку в плеере.

Установка

При выборе сервера упор стоит обратить внимание на процессор. Я взял эпичный сервер с двумя ядрами и пробовал наращивать битрейт, чтобы определить граничные условия на 11-12k нагрузка стала болтаться в районе 96-100%, так что для обработки действительно тяжёлого потока лучше взять мощности с запасом:



Нам понадобится Docker для установки контейнеризованного nginx-rtmp с FFmpeg и любой веб-сервер (включая тот же Nginx) для раздачи страницы с плеером. Я ставил на Ubuntu 20.04:

$ sudo apt-get update$ sudo apt-get install \  apt-transport-https \  ca-certificates \  curl \  gnupg-agent \  software-properties-common \  nginx$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -$ sudo apt-key fingerprint 0EBFCD88$ sudo add-apt-repository \  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \  $(lsb_release -cs) \  stable"$ sudo apt-get update$ sudo apt-get install docker-ce docker-ce-cli containerd.io

Запускаем контейнер c проброшенными портами:

docker run -d -p 1935:1935 -p 8080:80 --rm alfg/nginx-rtmp

Затем в OBS на клиенте указываем наш сервер с произвольным ключом потока (ключ = индентификатор стрима):



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

Осталось настроить сервер. В nginx.conf укажите путь до вашей страницы:

location / {                                                      root /var/www/;                                                    index index.htm index.html;                                   autoindex on;                                }

sudo nginx -s reload

В index.html просто скопипастим код из примера hls.js:

  <script src="http://personeltest.ru/aways/cdn.jsdelivr.net/npm/hls.js@latest"></script>  <!-- Or if you want a more recent alpha version -->  <!-- <script src="http://personeltest.ru/aways/cdn.jsdelivr.net/npm/hls.js@alpha"></script> -->  <video id="video"></video>  <script>    var video = document.getElementById('video');    var videoSrc = 'https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8';    if (Hls.isSupported()) {      var hls = new Hls();      hls.loadSource(videoSrc);      hls.attachMedia(video);      hls.on(Hls.Events.MANIFEST_PARSED, function() {        video.play();      });    }    // hls.js is not supported on platforms that do not have Media Source    // Extensions (MSE) enabled.    //    // When the browser has built-in HLS support (check using `canPlayType`),    // we can provide an HLS manifest (i.e. .m3u8 URL) directly to the video    // element through the `src` property. This is using the built-in support    // of the plain video element, without using hls.js.    //    // Note: it would be more normal to wait on the 'canplay' event below however    // on Safari (where you are most likely to find built-in HLS support) the    // video.src URL must be on the user-driven white-list before a 'canplay'    // event will be emitted; the last video event that can be reliably    // listened-for when the URL is not on the white-list is 'loadedmetadata'.    else if (video.canPlayType('application/vnd.apple.mpegurl')) {      video.src = videoSrc;      video.addEventListener('loadedmetadata', function() {        video.play();      });    }  </script>

Теперь на 8080 порту нашего сервера раздаётся жутковатый мультик про зайца:



Остаётся только изменить путь на http://server_ip:8080/live/stream-key.m3u8 и идти смотреть трансляцию!



Нагрузку в реальном времени можно проверять командой docker stats:

Заключение

Размещая стриминговый клиент на своём сервере важно помнить, что весь трафик со всех зрителей будет проходить прямо через него значит, если одновременный онлайн у вас будет больше 1-2 человек, стоит изучать способы распределения нагрузки (ведь транскодирвоание ощутимо давит и на CPU). Для запуска полноценного кластера есть энтерпрайзное (но опенсорсное) решение SRS aka Simple Realtime Server (GitHub, 10k звёзд, огромная вики, сложная архитектура). В него стоит вникать, если вам стримы нужны для решения настоящих задач, а не чтобы поиграться с приватным видеопотоком.

---

На правах рекламы

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

Чрезвычайно оптимальная форма для печенья Мартина Лерша.

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

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

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

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

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


В течение предыдущих нескольких лет Лерш экспериментировал с дизайном форм.

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

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

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


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

Однако это не остановило Лерша, создавшего собственные тематические рождественские тесселяции из колокольчиков, ёлок и других фигур при помощи бесплатной платформы Tess. Друг помог ему напечатать на 3D-принтере несколько форм для печенья, после чего он замесил тесто. Любимое пепперкаке (pepperkake) Лерша это великолепное норвежское имбирное печенье. Работающий химиком Лерш рассказал, что когда-то оно изготавливалось с карбонатом аммония из толчёных оленьих рогов, однако сегодня большинство людей заменяет его разрыхлителем для теста.

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

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


Ещё одна форма Лерша эффективная, но гораздо менее праздничная.

Абрахамсен утверждает, что в случае сложных фигур наподобие рождественских ёлок, нахождение одного наиболее эффективного способа их расположения на плоскости теста на сегодняшний день является нерешаемой задачей. В 1999 году алгоритм был способен решать задачу об упаковке только для квадратного контейнера, содержащего до четырёх объектов (простых восьмиугольников), и для полных расчётов программе требовалось 24 часа. При добавлении в уравнение каждого нового многоугольника алгоритму становилось всё сложнее решать задачу, потому что становится труднее упаковать объект в контейнер, когда пространство уже занято. Насколько известно Абрахамсену, с тех пор не было найдено более быстрого алгоритма.

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


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

---

На правах рекламы

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

Ускорители частиц вокруг нейтронной звезды в конструкции галактического маяка. Источник: A Neutrino Beacon. A. A. Jackson, arXiv:1905.05184

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

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

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

Кажется, на этот вопрос есть разумный ответ.

Гипотеза

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

Младенец не понимает слов, не различает объекты вокруг, не умеет складывать буквы в слова. То есть он ещё не готов к приёму информации ни по каким каналам.

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

Что мы ищем

Что конкретно мы ищем в настоящее время?

Проекты поиска внеземных цивилизаций начался в начале 19 века, вскоре после изобретения радио. Так, в 1899 году Никола Тесла на своей экспериментальной станции в Колорадо-Спрингс обнаружил странный повторяющийся статический сигнал. В 1959 появилась идея поиска межзвёздных сигналов в микроволновом спектре (doi:10.1038/184844a0). В 1960 году начался анализ данных с радиотелескопов на наличие сигналов. Значительный вклад внесли и советские учёные. Книга астрофизика Иосифа Шкловского Вселенная. Жизнь. Разум (1962), возможно, вдохновила просветительскую деятельность Карла Сагана.

В 70-е годы проект поиска внеземной жизни SETI в NASA впервые получил государственное финансирование, затем лишился его. В 1995 году возродился в рамках негосударственного Института SETI (Калифорния).


Десктопная версия программы распределённых вычислений SETI@Home для анализа радиосигналов от внеземных цивилизаций, 2007 год

Техносигнатуры

В программе SETI используются данные нескольких международных радиотелескопов, в том числе LOFAR в Европе, MWA в Австралии и Lovell Telescope в Великобритании.


Микроволновое окно земной атмосферы для наземной радиоастрономии

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

В 2015 году был запущен проект прослушивания радиоэфира Breakthrough Listen с бюджетом $100 млн. Он предполагает использование тысяч часов на двух основных телескопах: телескоп Грин-Бэнк (США) и Parkes Observatory (Австралия). В октябре 2019 года заключено соглашение с командой космического телескопа TESS (Transiting Exoplanet Survey Satellite). Тысячи новых экзопланет, которые обнаружит TESS. Будут сканироваться на предмет техносигнатур, то есть маркеров наличия технологии.

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

Фотоны

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

Этот вариант уже изучается. Например, в рамках проекта Breakthrough Listen телескоп Automated Planet Finder способен детектировать в том числе оптические сигналы от направленных лазеров. Телескоп сможет обнаружить лазер мощностью 100 Вт лазер с расстояния около 4,25 светового года, то есть от ближайшей к нам звезды Проксимы Центавра.


Проксима Центавра, ближайшая звезда к Солнечной системе. Находится на расстоянии 4,22 световых года в тройной звёздной системе Альфа Центавра

Сейчас идут научные дискуссии о том, насколько эффективен высокоэнергетический лазер в качестве маяка для межзвёздных коммуникаций. Подробнее см. результаты анализа звёздных систем на предмет лазерного излучения (A Search for Laser Emission with Megawatt Thresholds from 5600 FGKM Stars, doi: 10.3847/1538-3881/aa6d12).

Оптические наблюдения имеют важное значение ещё и потому, что позволяют обнаружить астроинженерные сооружения типа сферы Дайсона. Например, в 2015 году была опубликована работа о странном мерцании (изменении потока излучения) звезды KIC 8462852, что может быть вызвано влиянием астроинженерного сооружения, такого как рой Дайсона.


Изменение потока излучения KIC 8462852 на протяжении 12 месяцев в 2017-2018 гг

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

За последнее время учёные выдвинули различные идеи относительно того, какие мегаструктуры в принципе может построить цивилизация типа III.

Нейтрино

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

Эту идею развивает д-р Альберт Джексон из хьюстонской технологической компании Triton Systems. В своей научной работе он описывает конструкцию межзвёздного маяка вокруг нейтронной звезды или чёрной дыры для фокусировки пучков нейтрино (arXiv:1905/1905.05184).

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


Конструкция передатчика на основе нейтронной звезды

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

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


Одна из гравитационных линз, которые нашла обученная нейросеть на фотографиях с телескопа Хаббл, doi: 10.3847/1538-4357/ab7ffb

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

Такое инженерное предприятие возможно только в цивилизации типа II, которая использует энергию собственной звезды, по Кардашёву это энергия около ~410³³ эрг/с (или 410²⁶ Вт) в несколько триллионов раз больше, чем потребляет человечество в настоящее время. Конкретно от Солнца такая цивилизация получит 3,82810²⁶ Вт.

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


Сравнение размеров IceCube и Эйфелевой башни

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



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

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

Гравитационные волны

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

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


Искривление пространства-времени во время слияния чёрных дыр. Рендер: Aaron M. Geller, Northwestern University/CIERA


Сигнал, зарегистрированный 14 сентября 2015 года двумя детекторами LIGO, с возрастающей частотой от 35 Гц до 250 Гц и амплитудой деформации метрики в 1x10^-21, совпадает с предсказаниями ОТО для слияния двух чёрных дыр массами 36 и 29 солнечной, doi: 10.1103/PhysRevLett.116.061102

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

Продвинутые цивилизации могут передавать информацию через такие носители, которые мы пока не можем себе представить. Гравитоны? Стерильные нейтрино? Тёмная материя? Возмущения поля? Туннели из квантовой запутанности, которая сформировалась в момент Большого взрыва? Пока можно только фантазировать. Наверное, это задачи для науки на ближайшие миллионы лет по мере перехода нашей цивилизации к типу II, а затем к типу III.

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

Поиск продолжается

---

На правах рекламы

Недорогие VDS на базе новейших процессоров AMD EPYC и NVMe хранилища для размещения проектов любой сложности, от корпоративных сетей и игровых проектов до лендингов и VPN.

За последний год разработчики Vimeo писали код бэкенда на множестве языков PHP, Go, Ruby, Python, NodeJS, Java, C, C++ и немного на Rust.

В 2004 году мы начинали всего с одного: PHP. Это был идеальный язык для новых стартапов наподобие Vimeo. Интерпретатор PHP позволял предпринимателям быстро разрабатывать прототипы и имел большую стандартную библиотеку, позволявшую избавиться от мороки с повседневными задачами типа отправки писем и доступа к базам данных.

Большинство стартапов развалилось, однако некоторые из них, взявшие за основу PHP, по-прежнему были живы спустя десяток лет. Немногие из них добилась резкого роста, а в дальнейшем кое-кто из этих стартапов (самым заметный пример это Facebook) решил, что PHP является узким местом, и начал мигрировать с него. Для этого исхода было две серьёзные причины: производительность PHP и сложность поддержки больших кодовых баз PHP.


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

С 2004 года за десять лет Vimeo вырос во много раз, и наша кодовая база PHP росла вместе с ним, но мы не выросли настолько, чтобы эти проблемы встали перед нами в полную силу. Однако когда Facebook публично отказался от использования PHP, некоторые разработчики решили, что PHP постепенно становится FORTRAN эпохи Интернета. Новая волна бэкенд-разработчиков начала планировать, как нам преобразовать 500 тысяч строк кода на PHP в набор лучше спроектированных, более производительных и удобных для тестирования сервисов на Go.

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

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

Для проникновения усовершенствований PHP в Vimeo потребовалось какое-то время. Сначала нам пришлось избавиться от старой версии PHP (5.4), работавшей в продакшене долгие годы уже после истечения её срока годности. Благодаря миграции на PHP 7 значительно ускорилась реакция бэкенда; кроме того, улучшенный синтаксис PHP 7 позволил нашим разработчикам писать чуть более чистый код с полной поддержкой типов возвращаемых значений и параметров.

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

Статический анализ это круто

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

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

Базовая функциональность Psalm приблизительно похожа на контроль типов в TypeScript, а также позаимствовала кое-какие идеи у созданного Facebook языка Hack (производного от PHP). Psalm сообщает разработчику, когда код на PHP может вызвать ошибку несоответствия типов в продакшене, а также когда логика непонятна. Кроме того, инструмент имеет дополнительную функциональность наподобие обнаружения неиспользуемых классов и методов, позволяя автоматически устранять многие найденные проблемы.

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

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

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

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

Старый код необязательно является легаси

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

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

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

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

• Эффективно выполняет свою задачу
• Прост для статического анализа
• Хорошо протестирован
• Идиоматичен

К счастью, созданное нами ORM удовлетворяет всем четырём критериям.

Кроме того, сохранение надёжного старого кода даёт нам возможность сосредоточить усилия разработчиков на том, что приносит бизнесу материальную выгоду, и в соответствии с договором я обязан (но в то же время и рад) сказать, что в последнее время Vimeo находится на подъёме, выпустив множество отличных продуктов наподобие Vimeo Record.

PHP не обязан быть ужасным

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

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

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

---

На правах рекламы

Эпичные серверы это виртуальные серверы для размещения сайтов от маленького блога на Wordpress до серьёзных проектов и порталов с миллионной аудиторией. Создайте собственный тарифный план в пару кликов, максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!

В 2019 году была написана потрясающая статья Parse, dont validate. Я крайне рекомендую изучить её всем программистам (а также недавнее дополнение к ней Names are not type safety). Её основная идея заключается в том, что существует два способа проверки валидности входящих данных функции:

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

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

Инструмент контроля типов является хрестоматийным примером валидатора!

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

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


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

fun_call ::= fun_name ( integer )

можно определить для функций конкретные правила грамматики:

one_to_five ::= 1 | 2 | 3 | 4 | 5fun_call ::= lil_fac( one_to_five )         | ... other function definitions ...

Придумывание таких конкретных грамматик один из способов создания предметно-ориентированных языков (domain-specific languages, DSL). И в самом деле, DSL являются отличным способом обеспечения непредставимости недопустимых состояний. Разумеется, это решение не масштабируется, если вы хотите создать язык общего назначения с пользовательскими функциями.

Альтернативой создания очень конкретной грамматики является повышение уровня абстракции для усложнения возникновения недопустимых состояний. Например, частым источником программных ошибок является индексация вне границ массива. Такая ситуация возникает, потому что язык программирования предоставляет разработчику только примитивную операцию индексирования: a[x]. Здесь x является integer, но его значение может выйти за границы, что приведёт к исключению или вылету программы (если вам повезёт). Один из способов предотвращения такой ситуации заключается в определении более конкретного типа числа integer от нуля до 12, чтобы система типов отклоняла все потенциально недопустимые операции индексирования, а затем находила более точный тип для каждого массива мы снова встретились с валидацией.

Ещё одно решение можно заметить, что обычно массивы используются лишь ограниченным количеством способов. Например, очень часто производится итерация по массиву с выполнением каких-то вычислений. Вместо того, чтобы заставлять каждого программиста вручную писать для этого циклы for (Массивы в этом языке начинаются с 0 или с 1? Они заканчиваются на array.length or array.length 1? Индексы массива имеют определённый тип?), мы можем создать общую операцию fold (редукции). Аналогично, вместо того, чтобы заставлять кодеров писать собственные реализации хэш-таблиц, можно предоставить встроенную в язык реализацию. Предоставляя разработчикам более качественные абстракции, вы снижаете вероятность возникновения недопустимых состояний.

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

В мире компьютерной безопасности у подобных обсуждений есть непосредственный аналог. Модель защиты большинства компьютерных систем позволяет обеспечивать разделение между операциями, которые я могу (пытаюсь) выполнить и операциями, которые мне разрешено выполнять: я могу попытаться удалить чей-то веб-сайт, однако этот запрос будет отклонён как неавторизованный (по крайней мере, на это стоит надеяться). Для сравнения, в системах на основе моделей возможностей объекта допустимость вызова таких операций зависит от того, есть ли у меня возможность (которую невозможно подделать), предоставляющая мне разрешение на их выполнение. В таких системах нельзя даже попробовать выполнить операцию, которую мне не разрешено выполнять. Например, в REST API, использующем мандатные URI я не могу даже отправить запрос DELETE для /users/alice, а должен вместо этого отправлять его на какой-то случайный неподбираемый URI если у меня нет этого URI, то я даже не могу начать отправлять запрос. Следовательно, цель безопасности на основе возможностей объекта заключается в непредставимости неавторизованных состояний.

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

В молодости я много программировал на Tcl. Большинство читателей согласится, что этот язык максимально далёк от современного языка программирования со статической типизацией (часто об этом говоря с искренним отвращением). Тем не менее, мысль о реализации непредставимости недопустимых состояний была совершенно естественной для меня и других программистов на Tcl. Я часто начинал проект с создания интерпретатора с чистого листа, избавляясь от всех встроенных конструкций языка (циклов, процедур, даже арифметики), а затем добавляя тщательно отобранное множество высокоуровневых предметно-ориентированных примитивов. Этот DSL потом становился конфигурационным файлом приложения, защищённого тем, что недопустимые конфигурации выразить невозможно.

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

---

На правах рекламы

Эпичные серверы для разработчиков и не только! Дешёвые VDS на базе новейших процессоров AMD EPYC и хранилища на основе NVMe дисков от Intel для размещения проектов любой сложности, от корпоративных сетей и игровых проектов до лендингов и VPN. Вы можете создать собственную конфигурацию сервера в пару кликов!

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

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

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

Внешние факторы

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

Он обладал механистическими привычками. Его реакция на любую смену темы была всегда одинаковой. Настала его очередь говорить? Давайте я покажу свой экран. Появилось сообщение об ошибке? Получайте полноэкранный скриншот в BMP с огромным прямоугольником, внутри которого самого сообщения почти не видно. Нужно объяснить ключевое слово? Ещё один скриншот. Спасибо, Л., мы ведь не знали, как пишется foreign key.

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

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

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

Это никак не связано с акцентом. Я привык к иностранным акцентам. Это просто ещё одно проявление его посредственности.

Он не реагировал на то, что ему говорили и вносил изменения в поведение интерфейсов и API, не сообщая об этом никому. Так как у нас не было ревизий кода (code review), которые я упорно стремился внедрить, мы обнаруживали эти беспричинные изменения, только когда что-то ломалось.

Хуже всего было то, что у Л., похоже, каждые несколько минут происходила когнитивная перезагрузка. В той компании ветки Git были настроены совершенно неправильно две master-ветки для одного репозитория, одна для фронтэнда, другая для бекэнда. Мой код криптографии относился к master-ветке фронтэнда. Мы говорили о ветках с упоминанием их названий примерно десять минут, и было совершенно понятно, что я выполняю мою работу во frontend-crypto, которую мы упоминали много раз.

Внезапно он спросил меня, совершенно не к месту: Крис, а в какой ветке ты работаешь?

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

Плохой код

Обычно я работаю с семейством языков C и в веб-разработке пишу на C#. Мне пришлось выучить JavaScript, Python и Django. В результате теперь я почти исключительно пишу на JavaScript и работаю во фронтэнде. Обычно я бекэнд-разработчик; в том проекте всю работу по бекэнду выполнял Л.

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

Я пишу конечную точку

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

Допустим, я прошу этот API поискать ключи шифрования десяти людей. Вот найденное количество и коды состояний HTTP на моём плохом Django:

Возвращённое        Код HTTPколичество10               200 (полный успех)1-9              206 (частичный успех)0                204 (данные не найдены)Ошибка сервера   500 (исключение)

Если ответ содержит меньше строк, чем запрошенное количество, то я возвращал массив их идентификаторов not-found.

Я обратился к Л., чтобы он исправил мой синтаксис Django, но не переписывал логику, и вот что он сделал:

Возвращённое        Код HTTPколичество10               200 (полный успех)1-9              200 (неправильно)0                200 (неправильно)Ошибка сервера   400 (неправильно)

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

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

Ради справедливости надо сказать, что существует множество подходов к тому, как обрабатывать промежуточные уровни успешного выполнения действий API. Я почти никогда не видел никаких кодов состояний 2XX, кроме 200; 200 и 500 это единственные коды, которые возвращает большинство разработчиков. Большинство разработчиков знает только три или четыре кода состояний. Л. знал два и один из них был неправильным.

Можно было бы благородно допустить что у Л. есть собственный подход, отличающийся от моего; на мой взгляд, если кодов больше, чем четыре, значит, на то есть причина, и поэтому я их использую. Однако уже проработав с ним несколько месяцев, я был уверен, что он просто скопипастил во все строки одну и ту же, вероятно, взятую с StackOverflow. Он сохранил мою логику фильтрации для всех заданных мной случаев (0, 19, 10), но вставил для всех них одинаковую строку.

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

Реакция руководства

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

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

И этому человеку платили.

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

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

Менеджеры, не знающие кода

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

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

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

Но если бы я был руководителем, Л. уже бы искал другую работу.

Этика работы в разработке ПО это спектр, в котором существует два полюса:

1. Делать всё максимально идеально, и к чёрту все дедлайны
2. Выполнять минимально возможный объём и сделать своим единственным приоритетом выполнение списка задач. Устранять слабые места написанием юнит-тестов (которых мы не писали).

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

---

На правах рекламы

У вас могут быть не лучшие коллеги, но за надёжные серверы вам не нужно волноваться. Наша компания предлагает серверы с Linux или Windows. Не экономим на железе только современное оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить!

Статистический подход к объяснению ошибочных дедлайнов в инженерных проектах

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

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

Общая информация

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

Проблема

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

Последствия

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

Известные причины

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

Чрезмерный оптимизм, эффект Даннинга-Крюгера, чистая неопределённость или просто математика?

Пятая стадия: ПРИНЯТИЕ.

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

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

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

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

Это просто математика!

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

• Я считал, что это займёт 10 минут, потому что в голове на 100% знал код, который нужно написать.
• Написание кода и в самом деле потребовало примерно 710 минут. А потом потребовалось 2 часа из-за совершенно неизвестного мне бага во фреймворке.

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

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

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

Как мы оцениваем время в нормальных условиях

Нормальное распределение (гауссиана)

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

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

Я имею в виду, что не имеет смысла говорить 15 минут, потому что это редкий случай, или 7 минут, если только на улице нет дождя. И с большой вероятностью вы окажетесь правы. Если в 18 из 20 случаев путь занимал 5 минут, то определённо существует высокая вероятность, что он займёт 5 минут (медиана) и на этот раз. Вероятность примерно равна 90% (если, разумеется, не вдаваться в более сложные вычисления).

Но график искажён!

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

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


Для этой отдельной задачи медиана (median) по-прежнему имеет более высокую вероятность, чем среднее (mean)! Если вы попытаетесь угадать значение моды (mode), имеющей наивысшую вероятность, то при увеличении объёма задачи ошибётесь ещё сильнее

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


Уравнение задержки на основании этой гипотезы

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

Как же воспользоваться этим знанием?

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

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

1. Проще сказать, займёт ли задача X больше/меньше/столько же времени по сравнению с задачей Y, чем точно определить, сколько займёт их выполнение. Так получается, потому что если скошенность кривых приблизительно одинакова (что справедливо для похожих задач), то сравнение медиан даёт примерно такие же результаты, как и сравнение средних.
2. Я не запоминаю и не записываю каждую отдельную задачу, чтобы проводить вычисления и получать среднее (и не могу найти никаких данных для таких опытов). Поэтому я обычно оцениваю неизбежную погрешность (среднее-медиана) как процент от времени на задачу, который увеличивается/уменьшается в зависимости от того, насколько я освоился со средой разработки. (Нравится ли мне этот язык/фреймворк (40%) Есть ли у меня хорошие инструменты отладки? (30%) Хороша ли поддержка IDE? (25%) и т.д.).
3. Я начал разделять спринты на задачи равного размера чтобы обеспечить некую однородность процесса оценки времени. Это позволяет мне воспользоваться пунктом 1. Бывает легко определить, что две задачи примерно равны по времени. Кроме того, это делает задачи ещё более похожими на то, к чему применима гипотеза, и всё становится более предсказуемым.
4. Применив эти принципы, при наличии ресурсов можно организовать тестовый прогон. Например, если за X1 дней Y1 разработчиков выполнило Z1 однородных задач, то мы можем вычислить X2 (дней), зная Y2 (количество имеющихся разработчиков) и Z2 (общее количество оставшихся задач).

---

На правах рекламы

Эпичные серверы для разработчиков и не только! Недорогие VDS на базе новейших процессоров AMD EPYC и NVMe хранилища для размещения проектов любой сложности, от корпоративных сетей и игровых проектов до лендингов и VPN.

В начале фильма Терминатор 2: Судный день Джон Коннор использует лэптоп для подбора PIN украденной дебетовой карты.


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


Номеронабиратель (War Dialer) из Военных игр (1983 год)


Чёрный ящик из Тихушников (1992 год)

Недавно я вспомнил эту сцену из Терминатора 2, поэтому начал гуглить лэптоп из Терминатора 2.

Оказалось, что это Atari Portfolio первый в мире палмтоп-компьютер (наладонный компьютер). Он был выпущен в июне 1989 года.


Компьютер имел монохромный ЖК-дисплей с разрешением 240x64 пикселей или 40 символов x 8 строк и работал от трёх батареек AA.

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

Для начала изучим нужные технические требования!

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


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

PPPPP   IIIIIII   N    NP   PP     I      NN   N IDENTIFICATIONP   PP     I      N N  NPPPPP      I      N  N N   PROGRAMP          I      N   NNP       IIIIIII   N    NStrike a key when ready ...

После этого Джон нажимает на Enter и на экране начинают прокручиваться числа. Если посмотреть спустя несколько кадров:


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

12345678901234567890123457890123456780

Можно было бы предположить, что это просто повторяющиеся четыре раза цифры с 1 по 0, но при внимательном изучении выясняется, что строка длиной всего 38 символов. В третьем повторе пропущена цифра 6, а в последнем цифра 9.

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

Ну, всё выглядит довольно просто. Я осваивал Python, поэтому написал скрипт на Python 3:

#!/usr/bin/env python3import timeimport randomdelay = 0.025print("PPPPP   IIIIIII   N    N")time.sleep(delay)print("P   PP     I      NN   N IDENTIFICATION")time.sleep(delay)print("P   PP     I      N N  N")time.sleep(delay)print("PPPPP      I      N  N N   PROGRAM")time.sleep(delay)print("P          I      N   NN")time.sleep(delay)print("P       IIIIIII   N    N")time.sleep(delay)print('')input("Strike a key when ready ...")print("\n\n12345678901234567890123457890123456780")lines = 1length = 38decrease = 1while True:    for i in range(0, length):        print(random.randint(0,9), end='')    print('')    time.sleep(delay)    lines += 1    if (lines == 5):        lines = 0        length -= decrease        if (decrease == 1):            decrease = 2        else:            decrease = 1    if (length <= 4):        breakfor i in range(0, 10):    print("9003")print("\nPIN IDENTIFICATION NUMBER: 9003")print("\na>", end='')

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

При помощи поиска Google по картинкам я нашёл сайт, продающий пластмассовые панели для Atari Portfolio с нанесённой на экран красивой графикой:


Немного поэкспериментировав с termtosvg, в частности, с функцией SVG-шаблонов, я смог создать этот безумный SVG:


Несмотря на то, что я уже больше десяти лет поддерживаю html5zombo.com, до создания этого SVG я не ценил всех их возможностей. Они могут встраивать изображения? CSS? Javascript? Любой сайт, позволяющий пользователям загружать произвольные SVG и рендерить их, теперь получил моё величайшее уважение.

Пока я развлекался созданием своего небольшого автономного SVG, меня не покидала мысль о том, что мой код на Python на самом деле никогда бы не запустился на Atari Portfolio. В Atari Portfolio установлена DIP Operating System 2.11 (DIP DOS), по большей части совместимая с MS-DOS.

В первых классах старшей школы, ещё до того, как мне начали платить за профессиональное написание ПО, я писал софт для BBS, моды и игры на смеси Turbo Pascal и скриптового языка PCBoard Programming Language, напоминавшего BASIC. Проведя минимальные исследования, я выяснил, что если смогу написать программу на Turbo Pascal и скомпилировать её, то она, вероятно, будет работать на Atari Portfolio.

Я не писал на Turbo Pascal почти 25 лет, но ведь такое не забывается?

Мне нравится форк DOSBox под названием DOSBox-X, поэтому я скачал и установил самую последнюю SDL2-версию для OS X. Затем я нашёл Borland Turbo Pascal 7.0, который помещу сюда, потому что искать его было настоящим мучением.

В этом ZIP вы найдёте четыре файла, которые являются образами гибких дисков. Если поместить их в папку, например, ~/tp, после запуска DOSBox-X и монтирования диска C вы сможете смонтировать их как диск A следующим образом:

imgmount a ~/tp/Disk01.img ~/tp/Disk02.img ~/tp/Disk03.img ~/tp/Disk04.img -floppy

после чего переключиться на диск A: и запустить INSTALL:

A:INSTALL

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


Это можно сделать, выбрав в DOSBox-X Drive -> A -> Swap disk. Выполнится переход с Disk 1 на Disk 2. Затем просто продолжайте повторять процесс и нажимать на Ввод, пока не установятся все четыре диска.

После завершения установки она попросить настроить CONFIG.SYS и AUTOEXEC.BAT (не забывайте, это 1992 год).


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

C:cd tp\binTURBO

В детстве я провёл столько времени с этим IDE, что теперь испытал своего рода ностальгию. Но потом я начал портировать свой скрипт Python на Pascal и ностальгия быстро рассеялась. Хотел бы я сказать, что написал всё целиком в IDE, но в какой-то момент мне пришлось перейти в VSCode, а потом скопировать файл обратно в папку DOS. Люди, которые до сих пор работают в WordPerfect for DOS, я вас и понимаю, и не понимаю.

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

program pinid;uses crt;var i: byte;var pos: byte;var lines: byte;var length: byte;var decrease: byte;var delay_amount: integer;begin     randomize;     delay_amount := 25;     clrscr;     writeln('PPPPP   IIIIIII   N    N');     delay(delay_amount);     writeln('P   PP     I      NN   N IDENTIFICATION');     delay(delay_amount);     writeln('P   PP     I      N N  N');     delay(delay_amount);     writeln('PPPPP      I      N  N N   PROGRAM');     delay(delay_amount);     writeln('P          I      N   NN');     delay(delay_amount);     writeln('P       IIIIIII   N    N');     delay(delay_amount);     writeln('');     write('Strike a key when ready ...');     readln;     writeln('');     writeln('');     writeln('12345678901234567890123457890123456780');     pos := 0;     lines := 1;     length := 38;     decrease := 1;     while true do     begin          for i:= 1 to length do                write(random(9));          writeln('');          delay(delay_amount);          lines := lines + 1;          if (lines = 5) then          begin               lines := 0;               length := length - decrease;               if (decrease = 1) then                   decrease := 2               else                   decrease := 1;          end;          if (length <= 4) then               break;     end;     for i:= 1 to 10 do     begin          writeln('9003');          delay(delay_amount);     end;     writeln('');     writeln('PIN IDENTIFICATION NUMBER: 9003');     writeln('');end.

Краткие объяснения:

• В Pascal есть объявления типов. Тип byte может быть числом в интервале 0-255.
• Файлы начинаются с program и названия программы, вероятно потому, что все модули имеют общее пространство имён, но имя файла не важно.
• Модули импортируются словом uses. Модуль crt используется для манипулирования экраном.
• := это синтаксис присвоения значения переменной, чтобы можно было сравнивать при помощи = и отличать их друг от друга.
• Если блоки длиннее одной строки, их нужно оборачивать в begin and end, а не в фигурные скобки или пробелы.
• Если в начале скрипта не выполнить randomize, то создаваемые случайные числа всегда будут одинаковыми, как и выходные строки.
• WRITE выводит строку, WRITELN выводит строку с переводом строки. READLN получает ввод до получения перевода строки.

Работает ли код? Вот запущенная в DOSBox-X программа:


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

1. Купить на Ebay Atari Portfolio.
2. Купить параллельный интерфейс Atari Portfolio и, вероятно, новую переднюю панель, потому что старая наверняка поцарапана.
3. Найти в моей коробке с кабелями параллельный кабель.
4. Найти PC или лэптоп с параллельным портом, установить на него MS-DOS v6.22.
5. Скачать FT.COM и установить его на PC.
6. Собрать EXE в Dosbox-X и передать его на Atari Portfolio.
7. Украсть дебетовую карту.
8. Обернуть часть карты алюминиевой фольгой, купить последовательный интерфейс Atari Portfolio, подключить кабель к карте.
9. Запустить программу.
10. Лёгкие деньги!

---

На правах рекламы

Закажи и сразу работай! Создание VDS любой конфигурации и с любой операционной системой в течение минуты. Максимальная конфигурация позволит оторваться на полную 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Эпичненько :)

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

• Посещён 1 миллион страниц
• Записано по 65 метрик каждой страницы
• Запрошен 21 миллион URL
• Зафиксировано 383 тысячи ошибок
• Сохранено 88 миллионов глобальных переменных

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

Зачем рендерить миллион веб-страниц?

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

Общий план был простым: написать скрипт для веб-браузера, заставить его рендерить корневую страницу миллиона самых популярных доменов и зафиксировать все мыслимые метрики: время рендеринга, количество запросов, перерисовку, ошибки JavaScript, используемые библиотеки и т.п. Имея на руках все эти данные, мы могли бы начать задаваться вопросами о том, как один фактор корреллирует с другим. Какие факторы сильнее всего влияют на замедление рендеринга? Какие библиотеки увеличивают время до момента возможности взаимодействия со страницей (time-to-interactive)? Какие ошибки встречаются наиболее часто, и что их вызывает?

Для получения данных достаточно было написать немного кода, позволяющего Puppeteer управлять по скрипту браузером Chrome, запустить 200 инстансов EC2, отрендерить миллион веб-страниц за пару выходных дней и молиться о том, что мы действительно правильно поняли ценообразование AWS.

Общие значения

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

HTTP 2 сейчас более распространён, чем HTTP 1.1, однако HTTP 3 по-прежнему встречается редко. (Примечание: мы считаем сайты, использующие протокол QUIC как использующие HTTP 3, даже если Chrome иногда говорит, что это HTTP 2 + QUIC.) Это данные для корневого документа, для связанных ресурсов значения выглядят немного иначе.


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

Для связанных ресурсов HTTP 3 используется почти в 100 раз чаще. Как такое может быть? Дело в том, что все сайты ссылаются на одно и то же:


Самые популярные URL ссылок

Есть несколько скриптов, связанных с большой частью веб-сайтов. И это ведь означает, что эти ресурсы будут в кэше, правильно? Увы, больше это не так: с момента выпуска Chrome 86 ресурсы, запрашиваемые с разных доменов, не имеют общего кэша. Firefox планирует реализовать такой же подход. Safari разделяет свой кэш уже многие годы.

Из-за чего тормозит веб: прогнозируем time-to-interactive

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


Корреляции метрик с dominteractive

По сути, каждая метрика позитивно коррелирует с dominteractive, за исключением переменной 01, обозначающей использование HTTP2 или более старшей версии. Многие из этих метрик также положительно коррелируют друг с другом. Нам нужен более сложный подход, чтобы выйти на отдельные факторы, влияющие на высокий показатель time-to-interactive.

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


Диаграмма размаха метрик таймингов. Оранжевая линия это медиана, ящик ограничивает с 25-го по 75-й перцентиль.

Один из способов определения отдельных факторов, влияющих на высокий показатель time-to-interactive выполнение линейной регрессии, при которой мы прогнозируем dominteractive на основании других метрик. Это означает, что мы назначаем каждой метрике вес и моделируем время dominteractive страницы как взвешенную сумму других метрик, плюс некая константа. Алгоритм оптимизации расставляет веса так, чтобы минимизировать погрешность прогноза для всего набора данных. Величина весов, определённая регрессией, сообщит нам что-то о том, как каждая метрика влияет на медленность страницы.

Из регрессии мы исключим метрики таймингов. Если мы потратим 500 мс на установку соединения, то это добавит 500 мс к dominteractive, но это не особо интересный для нас вывод. По сути, метрики таймингов являются результатами. Мы хотим узнать, что становится их причиной.


Коэффициенты регрессии для метрик, прогнозирующей dominteractive

Числа в скобках это коэффициенты регрессии, выведенные алгоритмом оптимизации. Можно интерпретировать их как величины в миллисекундах. Хотя к точным значениям нужно относиться скептически (см. примечание ниже), интересно увидеть порядок, назначенный каждому аспекту. Например, модель прогнозирует замедление в 354 мс для каждого перенаправления (редиректа), необходимого для доставки основного документа. Когда основной HTML-документ передаётся по HTTP2 или более высокой версии, модель прогнозирует снижение time-to-interactive на 477 мс. Для каждого запроса, причиной которого стал документ, она прогнозирует добавление 16 мс.

В процессе интерпретации коэффициентов регрессии нужно помнить о том, что мы работаем с упрощённой моделью реальности. На самом деле time-to-interactive не определяется взвешенной суммой этих входящих метрик. Очевидно, что есть причинные факторы, которые модель выявить не может. Бесспорной проблемой являются искажающие факторы. Например, если загрузка основного документа по HTTP2 коррелирует с загрузкой других запросов по HTTP2, то модель встроит это преимущество в веса main_doc_is_http2_or_greater, даже если ускорение вызвано запросами не к основному документу. Нам нужно быть аккуратными, сопоставляя показания модели с выводами о реальном положении дел.

Как на dominteractive влияет версия протокола HTTP?

Вот любопытный график dominteractive, разделённый по версиям протокола HTTP, используемым для доставки корневой HTML-страницы.


Диаграмма размаха dominteractive, разделённая по версиям протокола HTTP первого запроса. Оранжевая линия медиана, ящик ограничивает с 25-го по 75-й перцентиль. Проценты в скобках доля запросов, выполненная по этому протоколу.

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

Это показатели для версии протокола, используемой для доставки корневой HTML-страницы. А если мы рассмотрим влияние протокола, используемого для ресурсов, на которые ссылается этот документ? Если провести регрессию для количества запросов по версии протокола, то получится следующее.


Коэффициенты прогнозирующей dominteractive регрессии для количества запросов по версии протокола

Если бы мы поверили этим показателям, то пришли бы к выводу, что перемещение запрашиваемых ресурсов при переходе с HTTP 1.1 на 2 ускоряется 1,8 раза, а при переходе с HTTP 2 на 3 замедляется в 0,6 раза. Действительно ли протокол HTTP 3 более медленный? Нет: наиболее вероятное объяснение заключается в том, что HTTP 3 встречается реже, а немногочисленные ресурсы, передаваемые по HTTP 3 (например, Google Analytics), больше среднего влияют на dominteractive.

Как на dominteractive влияет тип контента?

Давайте спрогнозируем time-to-interactive в зависимости от количества переданных данных при разделении по типам передаваемых данных.


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

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


Коэффициенты прогнозирующей dominteractive регрессии для количества запросов, переданных инициатором запроса

Здесь запросы разделены по инициаторам запросов. Очевидно, что не все запросы равны. Запросы, вызванные элементом компоновки (например, CSS или файлов favicon), и запросы, вызванные CSS (например, шрифтов и других CSS), а также скриптами и iframe значительно замедляют работу. Выполнение запросов по XHR и fetch прогнозируемо выполняются быстрее, чем базовое время dominteractive (вероятно, потому, что эти запросы почти всегда асинхронны). CSS и скрипты часто загружаются так, что препятствуют рендерингу, поэтому неудивительно, что они связаны с замедлением time-to-interactive. Видео относительно малозатратно.

Выводы

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

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

Библиотеки

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

Какие библиотеки JavaScript используются сегодня наиболее часто? Если следить за темами конференций и постов, было бы вполне логично предположить, что это React, Vue и Angular. Однако в нашем рейтинге они совершенно далеки от вершины.

10 самых используемых библиотек

Просмотреть полный список библиотек по уровню использования

Да, на вершине находится старый добрый jQuery. Первая версия JQuery появилась в 2006 году, то есть 14 человеческих лет назад, но в годах JavaScript это гораздо больше. Если измерять в версиях Angular, то это произошло, вероятно, сотни версий назад. 2006 год был совершенно иным временем. Самым популярным браузером был Internet Explorer 6, крупнейшей социальной сетью MySpace, а скруглённые углы на веб-страницах были такой революцией, что люди называли их Веб 2.0. Основная задача JQuery обеспечение кроссбраузерной совместимости, которая в 2020 году совершенно отличается от ситуации 2006 года. Тем не менее, 14 лет спустя аж половина веб-страниц из нашей выборки загружала jQuery.

Забавно, что 2,2% веб-сайтов выбрасывали ошибку, потому что JQuery не загружался.

Судя по этой десятке лучших, наши браузеры в основном выполняют аналитику, рекламу и код для совместимости со старыми браузерами. Почему-то 8% веб-сайтов определяют полифил setImmediate/clearImmediate для функции, реализация которой даже не планируется ни в одном из браузеров.

Прогнозирование time-to-interactive по использованию библиотек

Мы снова запустим линейную регрессию, прогнозирующую dominteractive по наличию библиотек. Входящими данными регрессии будет вектор X, где X.length == количество библиотек, где X[i] == 1.0, если библиотека i присутствует, X[i] == 0.0, если её нет. Разумеется, мы знаем, что на самом деле dominteractive не определяется наличием или отсутствием конкретных библиотек. Однако моделирование каждой библиотеки как имеющей вклад в замедление и выполнение регрессии для сотен тысяч примеров всё равно позволяет нам обнаружить интересные находки.

Наилучшие и наихудшие для time-to-interactive библиотеки по коэффициентам регрессии

Посмотреть полный список библиотек по коэффициентам регрессии, прогнозирующей dominteractive

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

Наилучшие и наихудшие для времени onload библиотеки по коэффициентам регрессии

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


Посмотреть полный список библиотек по коэффициентам регрессии, прогнозирующей onloadtime

Наилучшие и наихудшие библиотеки для jsheapusedsize по коэффициентам регрессии

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


Посмотреть полный список библиотек по коэффициентам регрессии, прогнозирующей jsheapusedsize

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

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

---

На правах рекламы

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

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

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

К сожалению, не всё так радужно. WSL по-прежнему является неким инородным элементом, который отделён от родной среды Windows. В частности, не может взаимодействовать с родными инструментами Windows.

А ведь изначально всё задумывалось совсем иначе, пишет Джулио Мерино (Julio Merino), автор блога для разработчиков jmmv.dev. Подсистема должна была стать совсем другой, но фактически вышел провал, в каком-то смысле.

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

Обзор архитектуры WSL 1

Давайте сначала взглянем на WSL 1, и первым делом на её странное название. Почему эта функция называется подсистемой Windows для Linux? Разве не наоборот? Это же не подсистема в Linux, которая делает что-то связанное с Windows, а именно наоборот! То есть грамотно она должна называться Подсистема с функциональностью Linux для Windows или Подсистема Linux для Windows или LSW. Откуда путаница?

Есть мнение, что Microsoft была вынуждена выбрать название наоборот, чтобы избежать упоминания чужих торговых марок. Вот слова Рича Тёрнера (Rich Turner), проект-менеджера WSL:


Что ж с другой стороны, такое странное название технически можно считать корректным, если внимательно изучить архитектуру ядра Windows NT. На странице Архитектура Windows NT в Википедии мы находим следующее:

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

Windows NT разработана с нуля для поддержки процессов, запущенных из множества операционных систем, а Win32 был просто одной из этих подсистем окружения. На такой платформе WSL 1 предоставляет новую подсистему окружения, подсистему Linux, для запуска бинарников Linux поверх ядра Windows NT. У подсистем окружения Win32 и Linux должна быть одна общая интегральная подсистема.

Что всё это на самом деле значит?

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

Способ, которым процесс выполняет системные вызовы, и семантика этих системных вызовов специфичны для операционной системы. Например, на старых х86 это выглядит так: открытие файла в системе Win32 системный вызов 17h, который инициируется через прерывание INT 2EH, а при открытии файла в системе Linux это системный вызов 5h, который инициируется через прерывание INT 80х.

Но концептуально открытие файла это открытие файла, верно? Нам особенно не интересно, что номера системных вызовов или номера прерываний отличаются друг от друга. И в этом заключается ключевой аспект дизайна WSL 1: подсистема Linux в ядре NT это, проще говоря, реализация уровня системных вызовов Linux перед ядром NT. Эти системные вызовы позже делегируются примитивам NT, а не вызовам Win32. Самое главное: нет никакого перевода с системных вызовов Linux на системные вызовы Win32.

В каком-то смысле это подвиг архитектурной мысли и реальной программной разработки, учитывая в целом хорошую поддержку Linux-приложений под WSL 1 и помня о множестве реальных внутренних отличий NT от Unix, когда Windows вообще нативно не воспринимает стандартную юниксовую логику forkexec.

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

Причины для создания WSL 2

Если WSL 1 так крут, то зачем нужен WSL 2? Здесь две причины:

• WSL 1 должен, по сути, реализовать все двоичные интерфейсы приложений (ABI) ядра Linux, как говорится, бит к биту. Если в интерфейсе есть ошибка, WSL 1 должен её воспроизвести. А если есть функция, которую трудно представить в ядре NT, то она либо не может быть реализована, либо нуждается в дополнительной логике ядра (и поэтому становится медленнее).
  
  
  Уровни и интерфейсы между ними: API и ABI. Высокоуровневое сравнение
  
  
• Подсистема Linux в WSL 1 должна соблюдать любые ограничения и внутренние различия, существующие между ядром NT и традиционным дизайном Unix. Наиболее очевидным отличием является файловая система NTFS и её семантика, а также то, как эти различия вредят производительности бинарных файлов Linux. Низкая производительность файловой системы, видимо, была распространённой жалобой при использовании WSL 1.

WSL 2 выбрасывает всю часть подсистемы Linux и заменяет её полноценной (но очень хорошо скрытой и быстрой) виртуальной машиной. Затем виртуальная машина внутри себя запускает обычное ядро Linux, правильную файловую систему Linux и стандартный сетевой стек Linux. Всё это работает внутри VM.

Это означает, что красота дизайна WSL 1 исчезла: ядро Windows NT больше не видит ничего в мире Linux. Просто большой чёрный ящик, который делает что-то неизвестное внутри себя. Ядро Windows NT видит только точки подключения VMENTER и VMEXIT для виртуальной машины и запросы чтения/записи на уровне блоков на виртуальном диске. Это самое ядро NT теперь ничего не знает о процессах Linux и доступе к файлам. Точно так же работающее ядро Linux ничего не знает об NT.

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

Потерянный потенциал

С точки зрения пользователя, подсистема WSL 2 выглядит лучше: действительно, приложения Linux теперь работают намного быстрее, потому что не проходят через неудобную эмуляцию системных вызовов Linux в ядре NT. Если NTFS трудно использовать с семантикой Linux, то теперь такой проблемы нет, потому что теперь окружение Linux использует ext4 на своём виртуальном диске. И поддержка приложений Linux может быть гораздо более полной, потому что ну, потому что WSL 2 это и есть полноценный Linux.

Но подумайте, за счёт чего достигнуто это удобство? Чего мы лишились?

Какой должна была стать WSL, если бы всё работало так, как задумано:

• Представьте, как здорово набрать ps или top в сеансе WSL и увидеть рядом процессы Linux и Windows, причём любой из них можно убить командой kill?
  
• Представьте, как здорово манипулировать службами Windows из сеанса WSL?
  
• Как здорово использовать ifconfig (аналог ipconfig из Windows, хотя есть ещё ip) в рамках сеанса WSL для проверки и изменения сетевых интерфейсов компьютера?
  
  
  
• По сути, можете представить выполнение абсолютно всех задач системного администрирования в Windows из линуксовой консоли WSL? Это же сказка!

Хотя такого никогда не существовало, такой мир вполне можно себе представить и это могла обеспечить только архитектура WSL 1. И это вовсе не фантазии, потому что именно такую модель использует macOS (хотя это немного читерство, ведь macOS, по сути, является Unix).

Вот что бесит сильнее всего, пишет Джулио Мерино: Хотя я могу установить WSL на свою машину разработки для Azure, но никак не могу его использовать вообще ни для чего. По-прежнему приходится работать в CMD.EXE, поскольку здесь происходит взаимодействие с нативными процессами и ресурсами Windows, а инструменты, с которыми я имею дело, предназначены только для Windows.

На странице вопросов и ответов написано, что WSL 1 не будет заброшен, то есть можно запускать дистрибутивы WSL 1 и WSL 2 вместе, проапгрейдить любой дистрибутив на WSL 2 в любое время или вернуться на WSL 1. И если посмотреть на строгую приверженность к обратной совместимости Microsoft, из-за которой мы до сих пор вынуждены пользоваться архаичными инструментами и протоколами, это может быть правдой. Но поддержка WSL 1 колоссальное усилие, потому что придётся отслеживать и соответствовать всем изменениям Linux. Как бы то ни было, будем надеяться, что WSL 1 продолжит своё существование. И кто знает, вдруг когда-нибудь всё-таки воплотится в жизнь тот волшебный мир, который мы представляем?

Уровень совместимости в BSD

Интересно, что семейство операционных систем BSD ( FreeBSD, OpenBSD, NetBSD, MidnightBSD, GhostBSD, Darwin, DragonFly BSD) всегда отставали от Linux и других коммерческих операционных систем. Но у них очень давно была реализована эта совместимость на бинарном уровне, о которой мы говорим. Джулио Мерино говорит, что совместимость с Linux в ядре NetBSD была реализована ещё в 1995 году, то есть четверть века назад и за 21 год до рождения WSL 1.

И самое замечательное, эта совместимость не ограничивается только Linux. На протяжении многих лет NetBSD поддерживала эмуляцию различных операционных систем. Поддержка SVR4 появилась в 1994 году, и в течение короткого периода времени NetBSD даже поддерживала бинарные файлы PE/COFF да, правильно, это бинарные файлы Win32! Таким образом, в некотором смысле NetBSD реализовала модель WSL 1 наоборот: она позволяла запускать бинарные файлы Win32 поверх ядра NetBSD ещё в 2002 году. Вот так вот.

---

На правах рекламы

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

If This Then That сервис для автоматизации задач и создания пайплайнов из действий в разных сервисах. Это самый известный и функциональный продукт на рынке, но популярность ему навредила: полноценное создание апплетов теперь возможно только с платной подпиской, а на реддите периодически появляются жалобы на нестабильную работу сервиса. Как и в случае с любым полезным но платным продуктом, ищущий альтернативы обрящет их в опен-сорсном комьюнити. Мы сравним три self-hosted инструмента: Huginn, Beehive и Node-RED, попробуем их в действии и выберем лучший по функционалу и удобству использования.

Huginn

Huginn один из старейших сервисов автоматизации рутинных задач, первая версия была выпущена весной 2013 года. В скандинавской мифологии Хугин и Мунин вороны Одина, приносящие ему новости обо всё происходящем в мире, здесь же это менеджер агентов, выполняющих небольшие задания по заданным триггерам. Агентов можно объединять в цепочки и вообще организовывать в структуры произвольной сложности. Hugginn даже иногда используют целые компании для автоматизации процессов (пример>). Агенты могут:

• Мониторить любой сайт и реагировать когда появляется определенная информация. Базовый пример агент утром проверяет прогноз погоды и присылает уведомление, если днём будет дождь
• Следить за темами в твиттере и обращать внимание на пик упоминаний, например во время горячего обсуждения
• Следить за понижением цен на товары/билеты/подписки/etc
• Отслеживать упоминания как Google Alerts
• Отслеживать изменения целых сайтов или их частей. Подойдёт для тех кейсов веб-скрапинга, которые не покрывается вариантами выше. Например повесить алёрт на изменение страницы с пользовательским соглашением или продукт, переходящий из беты в релиз
• Распознавать цепочки заданий, сформулированных простым текстом, через Amazon Mechanical Turk
• Отправлять и получать вебхуки
• Отслеживать текущую геолокацию и сохранять историю перемещений
• Использовать интеграции с открытыми API любых сервисов (довольно много уже готово, но для экзотики придётся написать своего агента, это несложно)
• При срабатывании триггера запускать кастомный JS/CoffeeScript код без непосредственного редактирования агентов
• Аггрегировать все действия в один процесс и выдавать в итоге дайджест сразу по нескольким темам
• Отправлять алёрты и вообще любые выходные данные через RSS, вебхуки, EMail и SMS

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



За семь лет разработки Huginn собрал сообщество, дописывающее новых агентов по мере необходимости. Также у него открыта программа на Bountysource.

Установка

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

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

  docker run -it -p 3000:3000 huginn/huginn

Ждём установки и запуска, затем идём на 3000 порт, логинимся под дефолтной учёткой admin:password и видим полностью готовый к работе сервис. По умолчанию в Huginn уже есть несколько агентов (они были на графе выше), но мы создадим свою цепочку с нуля.

Сначала создадим агента, читающего RSS-версию хабра:



Все доступные опции и общая информация для каждого агента указывается справа от полей, удобно. Пока нам не нужны никакие поля кроме url. Вставляем адрес, сохраняем, снова идём на /agents/new и делаем агента, реагирующего на данные от агента-читателя:



Затем создаём сценарий из этих двух агентов и ставим на запуск.

Beehive

В Beehive агенты называются ульями (hives) сейчас список на вики насчитывает 43 готовых улья. Они могут:

• Читать и постить в социальных сетях и мессенджерах, пересылать посты из одного сервиса в другой. Поддерживаются Twitter, Telegram, Facebook (ограниченно), Slack, Discord, Tumblr, Mastodon, Jabber, Rocket.Chat, Gitter, IRC, Mumble
• Мониторить сайты, RSS и OpenWeatherMap. Для веба также можно представляться не только клиентом, но и сервером, реагируя на входящие запросы.
• Слать по триггеру HTTP-запросы, пуши, EMail, SMS, сообщения в любом из вышеперечисленных сервисов, постить на Pastebin, загружать файлы в S3.
• Аггрегировать данные мониторинга из GitHub, Prometheus, Nagios
• Использовать в качестве триггера не только стандартные ивенты и таймер, но и полноценный cron.
• Выполнять произвольные команды из хост-системы
• Мониторить отдельные каталоги в хост-системе
• Управлять умным освещением, совместимым с Philips Hue

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

Установка

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

docker run -it -p 8181:8181 fribbledom/beehive

Вот только админка уверенно откажется загружаться из-за запросов на localhost, поэтому придётся пробросить адрес:

docker run -it CANONICAL_URL="http://personeltest.ru/away/your.ip.address.here:8181" -p 8181:8181 fribbledom/beehive

Авторизация не предусмотрена видимо, подразумевается что без аутентификации в админку просто не попасть.

Процесс создания заданий и цепочек целиком показан на гифках из репозитория:

Node-RED

Здесь мы уже имеем дело не просто с агент-менеджером, а с полноценной платформой для организации задач, ориентированной не только на программистов, но и на обычных пользователей. Как и аналоги, Node-RED помимо использования готовых сценариев и модулей (нод) позволяет определять кастомные задачи, их логику и триггеры. Но если в других менеджерах любая кастомизация означает написание интерфейса (или целого модуля) с нуля или переписывание существующего, то здесь создавать все задачи и сценарии можно не выходя из браузера с помощью визуального программирования потоков данных. Создание модулей всё ещё требует навыков программирования, как и работа с API или ядром системы, но в целом из всех трёх вариантов только этот действительно близок к IFTTT по простоте использования, и помимо самого широкого функционала, у него еще и самое обширное сообщество, выкладывающее тысячи самописных модулей и сценариев.


Пример организации сценария

Установка

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

docker run -it -p 1880:1880 -v node_red_data:/data --name mynodered nodered/node-red

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

Инстанс Node-RED будет доступен (без авторизации) на 1880 порту. Так как hello-world пример вообще не поможет понять довольно сложное устройство сценария, лучше прочитать полный туториал здесь.

Заключение

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

• Hugginn покрывается много базовых сценариев из коробки, быстрое создание задач и сценариев. Продвинутые варианты требуют много кода и отладки, мало реально работающих интеграций со сторонними сервисами. Позволяет реализовывать базовую логику в сценариях.
• Beehive много готовых интеграций, которые явно пишутся разработчиками в первую очередь для себя. Если ваш сценарий не основывается на сложной логике, а просто тащит данные из API и отдает их на обработку или отправку, то это самый быстрый вариант для запуска.
• Node-RED возможность детально прорабатывать сценарии, огромное количество доступных модулей, сложно разобраться и запустить первый сценарий. Но зато потом можно сворачивать этой штукой горы.

---

На правах рекламы

VDSina предлагает мощные и недорогие VDS с посуточной оплатой для установки практически любого программного обеспечения. Интернет-канал для каждого сервера 500 Мегабит, защита от DDoS-атак включена в тариф, возможность установить Windows, Linux или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки. Обязательно попробуйте!

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

10 декабря 2020 года состоялся релиз долгожданной игры Cyberpunk 2077, а за день до этого вышла новая версия Proton 5.13-4 с поддержкой Cyberpunk 2077. То есть пользователи Linux смогли играть в Cyberpunk 2077 с первого же дня. Это наглядный пример, насколько великолепная ситуация сейчас с поддержкой игр на Linux-десктопах.

Если вам говорят, что Linux отличная платформа для игр, то это уже не преувеличение! За такое положение вещей мы должны благодарить Proton.

Что такое Proton?

Proton это относительно новый инструмент, который выпустила компания Valve Software (официальный анонс от 22.08.2018 года). Он интегрирован со Steam Play, а его задача максимально упростить запуск Windows-игр под Linux.

Хотя Proton интегрирован со Steam Play, но его можно собрать из исходников и использовать отдельно.

Под капотом Proton работают другие популярные инструменты, такие как кастомная версия Wine (бльшую часть сделанных Valve модификаций приняли в основную ветку) и DXVK, которые в противном случае пришлось бы устанавливать и поддерживать самостоятельно. Наличие такого интегрированного решения значительно облегчает пользователям переход на Linux без необходимости изучать базовые системы и не теряя доступ к своей библиотеке игр.



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

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

Steam также поддерживает работу с локальными установками Proton, поэтому никто не мешает вручную инсталлировать его на своей машине. Для этого нужно создать новую директорию в ~/.steam/root/compatibilitytools.d/ и поместить туда содержимое dist, полученное после сборки из исходников. Затем команда make install установит Proton внутри директории Steam для текущего пользователя. Корректная установка выглядит так:

 compatibilitytools.d/my_proton/ compatibilitytool.vdf filelock.py LICENSE proton proton_dist.tar toolmanifest.vdf user_settings.sample.py version

Остаётся перезагрузить Steam и можно пользоваться! Если пройти в настройки Steam Play, то там в выпадающем списке инструментов для совместимости появится proton-localbuild.

Что такое ProtonDB?

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

Оценка игре выставляется по пятибалльной шкале:

• Платина: отлично работает из коробки
  
• Золото: отлично работает после твиков
  
• Серебро: работает с незначительными проблемами, но в целом запускается
  
• Бронза: работает, но часто вылетает или имеет проблемы, мешающие играть комфортно
  
• Неисправна: либо не запускается, либо принципиально неиграбельна

На данный момент в базу включено 109 984 отчёта о 16 754 играх. Вот как выглядит рейтинг 10 самых популярных:

• Counter-Strike: Global Offensive золото
  
• Dota 2 серебро
  
• PLAYERUNKNOWN'S BATTLEGROUNDS неисправна
  
• Grand Theft Auto V золото
  
• Team Fortress 2 бронза
  
• Tom Clancy's Rainbow Six Siege неисправна
  
• Rust бронза
  
• Rocket League золото
  
• Apex Legends бронза
  
• Football Manager 2021 серебро

Из этой десятки самых популярных игр у трёх рейтинг золото, у двух серебро, у трёх бронза, а две игры не запускаются или неиграбельны. То есть 50% из десятки топовых игр нормально запускаются под Linux. Если взять сотню самых популярных игр, то этот показатель составляет 80%. Таким образом, большинство игр действительно работают в линуксовой среде.

В базе ProtonDB для каждой игры опубликованы отзывы реальных тестеров. Указана подробная конфигурация его оборудования, версия Proton и детальный отзыв по пунктам, с указанием стабильности и производительности, звука, графики и других параметров. Здесь же геймеры могут найти советы и твики, как заставить игру нормально работать в той или иной конфигурации.

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

Под Linux сегодня доступны Cyberpunk 2077, Red Dead Redemption 2, Death Stranding и многие другие игры. Вообще, сложно найти игру класса AAA, которая не запускается под Linux.

Состояние VR на Linux

Под Linux есть даже шлемы виртуальной реальности. По крайней мере, Valve Index протестирован и гарантированно работает. Хотя говорят, что это единственный шлем с официальной поддержкой Linux. Однако другие шлемы типа HTC Vive или Vive Pro могут запускать игры под Linux через кроссплатформенный движок SteamVR.


Valve Index с полной поддержкой Linux

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


Skyrim VR с модами. Источник: Patola

Вот Linux-совместимость самых популярных VR-игр, по рейтингам пользователей ProtonDB:

• Phasmophobia золото
  
• VRChat золото
  
• Elite Dangerous золото
  
• Microsoft Flight Simulator серебро
  
• Assetto Corsa золото
  
• Beat Saber платина
  
• 8-Bit Arena VR нет отзывов
  
• Assetto Corsa Competizione золото
  
• Tabletop Simulator платина
  
• DiRT Rally 2.0 платина

Не совсем понятно, по каким признакам ProtonDB составляет рейтинг популярности игр. Например, в нём отсутствует Half-Life: Alyx (релиз состоялся в марте 2020 года), которую называют самой революционной игрой в мире VR. Это первая адаптация культовой Half-Life для виртуальной реальности, которая при этом действительно устанавливает новые стандарты игровой разработки (см. видео ниже). В самом Steam она получила награду VR-игра 2020 года. Багов под Linux не очень много, но достаточно для того, чтобы Valve пока не указывала факт поддержки Linux на официальной странице игры в Steam. Но она играбельна.


После Half-Life: Alyx начали появляться и другие сложные игры с глубокой физикой и мощной интерактивностью, такие как Karnage Chronicles (июль 2020) и The Wizard Dark Times (июнь 2020).


Физический рюкзак: новая фишка, которую поддерживает всё больше VR-игр. Вы заводите руку за спину и достаёте рюкзак, в котором хранится инвентарь. Источник: Metro: Exodus

Так или иначе, но из десятки ProtonDB практически идеально запускаются почти все игры. Только по 8-Bit Arena VR нет отзывов, а у остальных рейтинги платина и золото. Это удивительный результат, который является заслугой кроссплатформенного программного обеспечения SteamVR, с которым интегрирован Proton.


Дом SteamVR в виртуальной реальности

Справедливости ради, у SteamVR есть ряд известных багов под Linux. Например, не работает наголовная камера шлема Index и не срабатывает комбинация клавиш для скриншотов. Если бы SteamVR выпускался полностью с открытым исходным кодом, такие баги исправили моментально. К сожалению, остаётся только терпеливо ждать, когда их исправит Valve.

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


Final Soccer VR

Проект SteamVR официально стартовал в 2015 году, когда Valve создала программные интерфейсы OpenVR API для поддержки разнообразного VR-оборудования. Хотя основная часть SDK открыта, но сами драйверы остаются проприетарными. Это даже вынудило сообщество запустить альтернативный открытый проект Open Source Virtual Reality (OSVR). К сожалению, на данный момент его разработка приостановлена и даже сайт ушёл в офлайн. Зато вполне здравствует OpenXR (с реализацией Monado) полностью открытая и свободная альтернатива проприетарным API от Valve. Последняя бета-версия SteamVR даже поддерживает OpenXR, наряду с нативными интерфейсами OpenVR. На самом деле опенсорсные разработки в мире VR/AR идут полным ходом. Например, можно упомянуть библиотеку XRDesktop, которая реализует в виртуальной реальности традиционные десктопные интерфейсы Linux. Поддерживается интеграция с существующими оконными менеджерами.


XRDesktop: десктопный интерфейс Linux в виртуальной реальности. Источник: Collabora

А также мультиплатформенную опенсорсную утилиту OVR Advanced Settings, которая бесплатно доступна в Steam. Очень полезный инструмент для детальной настройки VR-конфигурации.



Подводя итог. На практике под Linux можно использовать практически любое VR-устройство. Для этого нужно пойти в Steam и установить программу SteamVR.

Важность игр

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

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

Вот почему система Proton для запуска игр под Linux настолько важный проект. Будем надеяться, что Valve не забросит его.

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

---

На правах рекламы

Серверы для игровых серверов и любых других задач это про наши эпичные! Все серверы защищены от DDoS-атак. Лучше один раз попробовать.

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

Оказывается, некоторые программы невозможно удалить. Например, на отдельных моделях Samsung невозможно удалить Facebook (есть только опция 'disable'). Говорят, на Samsung S9 вдобавок предустановлены неудаляемые приложения Microsoft.

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

Всё это надо зачистить.

Очень редко встречаются примеры моделей, на которых нет лишних программ. Например, когда вышел первый iPhone, то компания Apple жёстко зафиксировала пакет установленных приложений, поэтому оператор AT&T не смог добавить туда свой привычный мусор.

Есть ещё пример смартфонов от Google начиная с Google Phone G1 в 2008 году, затем линейки Nexus и вплоть до текущих Pixel (Pixel 1, 2 и 3). На них тоже нет почти никакого мусора, если не считать слишком большого количества приложений Google, которые тоже считаются якобы системными и не удаляются полностью. Ну и небольшого количества сторонних неудаляемых приложений. Например, на Nexus5 намертво вшит HP Cloud Print. Но об этом позже.

В принципе, по такой логике и многочисленные приложения от Apple на iPhone можно считать ненужным мусором. Если быть точным, на iPhone предустановлены 42 приложения, не все из которых легко удалить: App Store, Calculator, Calendar, Camera, Clock, Compass, Contacts, FaceTime, Files, Find My Friends, Find My iPhone, Game Center, Health, Home, iBooks, iCloud Drive, iMovie, iTunes Store, iTunes U, Keynote, Mail, Maps, Messages, Music, News, Notes, Numbers, Pages, Passbook, Phone, Photos, Podcasts, Reminders, Safari, Settings, Stocks, Tips, TV, Videos, Voice Memos, Wallet, Watch, Weather.

На Android предустановлено 29 приложений, и тоже некоторые из них не удаляются стандартными средствами: Android Pay, Calculator, Calendar, Camera, Chrome, Clock, Contacts, Docs, Downloads, Drive, Duo, Gmail, Google, Google+, Keep, Maps, Messages, News & Weather, Phone, Photos, Play Books, Play Games, Play Movies & TV, Play Music, Play Store, Settings, Sheets, Slides, YouTube.

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

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

Зачем они это делают? Ну очевидно, что из-за денег. По партнёрским соглашениям установить программы партнёра стоит одних денег. А установить те же самые программы в виде неудаляемых уже совершенно других денег. Это просто предположение.

Хотя это просто удивительно. Мы платим за телефон Samsung сотни долларов! И они ещё хотят урвать пару баксов на партнёрских соглашениях!


Возможность удалить приложение отсутствует

Facebook всегда заявлял, что отключение (disable) приложения то же самое, что и удаление. Хотя оно (приложение) потом и занимает немного места в памяти, но не должно проявлять никакой активности или собирать данные. Но в последнее время люди настолько потеряли доверие к Facebook, что не верят даже в это. Мол, а почему оно тогда полностью не удаляется из системы?

Facebook и Microsoft годами заключает соглашения c производителями телефонов и операторами связи по всему миру. Финансовые условия не разглашаются. Facebook также отказывается говорить, с какими конкретно партнёрами у него сделки на неудаляемые приложения.

Впрочем, неудаляемые они только теоретически. На практике достаточно открыть ADB (Android Debug Bridge) и запустить пару команд.

На телефоне должна быть разрешена отладка по USB, а на компьютере установлен USB-драйвер устройства.

Скачать ADB для разных операционных систем можно по следующим ссылкам:

• Windows
  
• macOS
  
• Linux

Извлекаем содержимое zip-архива в любое удобное место, и уже там запускаем окно консоли.

Теперь приступаем.

pm list packages | grep '<OEM/Carrier/App Name>'

выводит список установленных пакетов.

pm list packages | grep 'oneplus'
package:com.oneplus.calculator
package:net.oneplus.weather
package:com.oneplus.skin
package:com.oneplus.soundrecorder
package:com.oneplus.opsocialnetworkhub
package:cn.oneplus.photos
package:com.oneplus.screenshot
package:com.oneplus.deskclock
package:com.oneplus.setupwizard
package:com.oneplus.sdcardservice
package:com.oneplus.security
package:cn.oneplus.nvbackup
package:com.oneplus.wifiapsettings

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

Для удаления конкретного пакета запускаем такую команду:

pm uninstall -k --user 0 <name of package>

Это работает без рутования.

Для упомянутых в начале статьи неудаляемых программ это выглядит так:

Facebook

pm uninstall -k user 0 com.facebook.katana

Facebook App Installer

pm uninstall -k user 0 com.facebook.appmanager

Microsoft OneDrive

pm uninstall -k user 0 com.microsoft.skydrive

Microsoft PowerPoint

pm uninstall -k user 0 com.microsoft.office.powerpoint

Microsoft OneNote

pm uninstall -k user 0 com.microsoft.office.onenote

и так далее.

Кстати, приложения от Facebook действительно лучше удалить, потому что они собирают и отправляют в компанию огромный объём персональных данных обо всех аспектах вашей деятельности. Чтобы оценить объём собираемых данных, взгляните на эту диаграмму. Она сравнивает, какие данные о вас собирают разные мессенджеры: Signal, iMessage, WhatsApp и Facebook Messenger.


Источник: 9to5Mac

Facebook Messenger высасывает буквально всё, что может. А вот Signal относится к пользователям гораздо более уважительно. Оно и понятно: это криптомессенджер, ориентированный на приватность.

Понятно, почему в Android нельзя удалить системные приложения штатными средствами. Но список системных приложений тоже неоднозначный. Например, перечисленные пакеты трудно назвать системными. Но штатными средствами удалить их тоже нельзя, только отключить (disable):

• Google Play Музыка
  
• Google Play Фильмы
  
• Google Play Книги
  
• Chrome
  
• YouTube
  
• и др.

Однако описанный выше метод позволяет полностью удалить их тоже.

Например:

Google Play Музыка

pm uninstall -k user 0 com.google.android.music

Google Play Фильмы

pm uninstall -k user 0 com.google.android.videos

и т. д.

Более того, метод подходит вообще для любого системного компонента.

Например:

pm uninstall -k user 0 net.oneplus.launcher

и мы навсегда избавляемся от встроенного лаунчера.

Примечание с форума xda-developers. Что касается системных приложений, то они снова появятся после сброса настроек. Это означает, что они всё-таки по-настоящему не удаляются с устройства, а просто удаляются для текущего пользователя (user 0). Вот почему без 'user 0' команда adb не работает, а эта часть команда как раз и указывает произвести удаление только для текущего пользователя, но кэш/данные системного приложения всё равно останутся в системе. И это хорошо, потому что даже после удаления системного приложения телефон всё равно сможет получать официальные обновления OTA.

Кстати, с 1 апреля 2021 года в России начнут принудительно устанавливать российский софт на все новые смартфоны. Список из 16 приложений уже утверждён, вот некоторые из них:

• ICQ (для обмена сообщениями);
  
• Новости Mail.ru;
  
• OK Live;
  
• MirPay (платёжная система, только на Android);
  
• Applist.ru (программа-агрегатор для доступа к социально значимым интернет ресурсам).

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

---

На правах рекламы

Нужен сервер с Android? У нас возможно даже это! VDSina предлагает недорогие серверы с посуточной оплатой, установка любых операционных систем с собственного ISO.

Почему делегирование обязанностей лучше, чем распределение задач

Доверие высочайшая форма мотивации. Оно выявляет в людях самое лучшее.

Стивен Р. Кови, Семь навыков высокоэффективных людей

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

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

Наконец-то, у нас появился Винсент, я могу поручить ему заняться A и B; Тед будет делать C, D
и E, Джен займётся F, G и H, а я смогу добраться до I, J, K, L и M.

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

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

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

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

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

Так чьё это видение?

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

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

Слишком много любви к метрикам

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

К сожалению, мелкие задачи в Jira (или в любом из десятков других систем отслеживания ошибок) приносят с собой перспективу целого множества новых вкусных графиков и диаграмм: burn down, burn up, velocity, lead time, cycle time, task age, throughput, failed deployment, flow and control. Всё это манит, как ребёнка манит конфета.

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

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

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

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

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

Бедным программистам, трудящимся на самом фронте работ, ничего не остаётся, они просят: Сэр, пожалуйста, можно мне ещё немного? Я просто хотел спроектировать один небольшой сервис. Я знаю, что недостоин этого, но пожалуйста, можно ли мне просто писать собственные sql-запросы без этого ужасного ORM?

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

Своим менеджерам они могут справедливо сказать: Это была твоя работа, не моя!

Оценка всегда требует ресурсов

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

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

Проблема в том, что как только вы начнёте работать над одним из них, то осознаете, что подразумеваемые проектные решения неверны. Теперь вам нужно потратить ГОРАЗДО больше времени, чем прежняя оценка задач, а все остальные задачи, зависящие от этого ошибочного решения, окажутся недействительными. Весь карточный домик развалится. Пришла пора ещё одного ещё дня возни с бэклогом? Какая трата времени!

Вывод

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

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

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

Я, Бартоломеу, буду обеспечивать соответствие требованиям.

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

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

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

---

На правах рекламы

VDSina предлагает мощные и недорогие VPS с посуточной оплатой. Интернет-канал для каждого сервера 500 Мегабит, защита от DDoS-атак включена в тариф, возможность установить Windows, Linux или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки. Обязательно попробуйте!

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

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

Если ваше приложение становится чуть сложнее, то вы переходите к инструментам наподобие Gatling. Они позволяют симулировать виртуальных пользователей, выполняющих различные сценарии, что намного полезнее, чем простая осада одного или нескольких URL. Но даже этого недостаточно, если вы пишете приложение, использующее одновременно WebSockets и HTTP-вызовы в течение долговременной сессии, а также требующее повторения по таймеру определённых действий. Возможно, я серьёзно недоглядел чего-то в документации, но мне не удалось найти способа, допустим, настроить периодическое событие, запускаемое каждые 30 секунд и выполняющее определённые действия при ответе на сообщение WebSocket, а также производящее действия по HTTP, и всё это в рамках одной HTTP-сессии. Я не нашёл такой возможности ни в одном инструменте нагрузочного тестирования (и именно поэтому написал на работе свой собственный инструмент, который надеюсь выложить в open source, если найду время на подчистку кода и отделения его от проприетарных частей).

Но предположим, что у вас есть стандартный инструмент наподобие Gatling или Locust, который работает и удовлетворяет вашим нуждам. Отлично! Теперь давайте напишем тест. По моему опыту, сейчас это самая сложная задача, потому что нам сначала нужно разобраться, как выглядит реалистичная нагрузка вас ждёт один-три дня кропотливого изучения логов и ведения заметок по показателям сетевых инструментов в браузере при работе веб-приложения. А после того, как вы узнаете реалистичную нагрузку, то вам придётся написать код, который сводится к следующему: подмножество вашего приложения будет притворяться пользователем, общаться с API и выполнять действия, которые совершает пользователь.

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

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

Откуда берётся сложность

По сути, ситуация такова:

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

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

Симуляция пользователей. Действительно ли она нужна?

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

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

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

Написание тестов сложная задача. Как и их поддержка.

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

А, да, и теперь вам нужно писать для всего этого ещё и интеграционные тесты.

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

Может быть, не подвергать всё нагрузочному тестированию?

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

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

• Старый добрый анализ. Усесться с ноутбуком, ручкой и пониманием системы в целом, выделить на это полдня, и вы получите примерные расчёты основных параметров и ограничений масштабирования системы. Когда вы наткнётесь на бутылочное горлышко или встретитесь с неизвестными переменными (сколько транзакций в секунду может поддерживать наша база данных? Сколько мы их генерируем?), то можно будет протестировать конкретно их!
• Разворачивание фич. Если вы можете медленно разворачивать фичи на всех пользователей, то вам может и не понадобиться нагрузочное тестирование! Вы можете измерять производительность экспериментально и проверять, достаточно ли её. Достаточно? Разворачиваем дальше. Мало? Откатываемся назад.
• Повторение трафика. Это совершенно не поможет с новыми фичами (для них воспользуйтесь предыдущим пунктом), но поспособствует пониманию критичных точек системы для уже имеющихся фич, при этом не требуя большого объёма разработки. Вы можете взять отслеженный ранее трафик и повторять его (многократно снова и снова, даже комбинируя трафик различных временных периодов), наблюдая за производительностью системы.
  
  

  ---

  
  

  На правах рекламы

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

Когда я десяток лет назад переехал в США для работы в Facebook, то понятия не имел, хорошим или плохим был оффер. Я даже не торговался и согласился на ту сумму, которую мне предложили. Отчасти это вызвано тем, что я был в восторге от приглашения, отчасти тем, что я совершенно не знал, чего мне ждать. К своей чести, Facebook предложил мне на 78% больше, чем изначально (думаю, так получилось, потому что они ожидали, что я буду обсуждать условия, чего я не делал).

К счастью, в последние несколько лет благодаря сайтам наподобие glassdoor и levels.fyi стало очень легко узнавать средние зарплаты и их диапазон. Не хватает только одного информации о том, сколько можно зарабатывать, если ты по-настоящему хорош, допустим, входишь в 1% лучших инженеров FB (то есть на уровне примерно 100 инженеров). В этом посте я поделюсь своими зарплатами и карьерным ростом, чтобы дать представление о том, насколько быстро можно развиваться и как при этом будет меняться зарплата.

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

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


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

Первый год

Я устроился в FB как E4 с базовой зарплатой в 127 тысяч долларов и начальной долей акций на сумму 280 тысяч долларов. Facebook тогда экспериментировал со множеством новых продуктов и в компании была куча легко реализуемых возможностей. В первой половине года я в основном работал в качестве соло-разработчика, который очень быстро мог разрабатывать готовые к продакшену прототипы. За это время я создал 3 новых крупных фич/мелких продукта. Во второй половине года все три инженера-сениора, работавших над одним из важнейших продуктов в нашей области, ушли в другой отдел, поэтому я сказал своему менеджеру, что могу заняться этим продуктом. Из-за важности продукта за шесть месяцев в команде снова набралось четыре инженера, а поскольку я был первым, то стал техническим руководителем проекта.

За выпуск трёх фич и создание команды из четырёх человек меня повысили до E5 и выдали премию в 32 тысячи долларов (10% как уровню E4 и множитель оценки производительности 2,5), плюс дополнительный гонорар 112 тысяч долларов.

Общая компенсация: 229 тысяч долларов

Второй год

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

Из-за того, что мы продолжали делать продукт более успешным и собрали команду из десяти инженеров, меня повысили до E6 и дали премию в 56 тысяч долларов (15% как уровню E5 и множитель оценки производительности 2,5). Также мне заплатили дополнительный гонорар в 185 тысячи. Благодаря успеху команды и моей роли в нём мне дали дополнительную долю акций в 486 тысяч. Эта доля выдаётся сверх ежегодного гонорара и его получает всего 35% всех инженеров компании.

Общая компенсация: 304 тысячи долларов

Третий год

Я ушёл из своей предыдущей команды и с ещё двумя инженерами основал новую команду для повторного создания с нуля одного из важнейших продуктов FB. За 6 месяцев мы создали работающую версию и получили благословение руководства на дальнейшую работу. Мы активно начали рекрутинг в команду, и к концу года она выросла до 12 инженеров. Разработка продукта продолжилась, но в последствии выяснилось, что это была ошибка. Нам нужно было разрабатывать его итеративно, а не выпускать сразу крупномасштабным, как мы стремились.

Мне выдали премию в 60 тысяч (20% как уровню E6 и множитель оценки производительности 1,625), а также дополнительный гонорар в 200 тысяч. Благодаря наработкам, которые мы внесли в новый продукт, мне дали дополнительную долю акций на 860 тысяч.

Общая компенсация: 508 тысяч

Четвёртый год

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

Мне выдали премию 45 тысяч (20% как уровню E6 и множитель оценки производительности 1,125). За все годы это был самый низкий множитель производительности, я впервые вошёл в категорию соответствует требованиям. На этот раз никакой дополнительной доли.

Общая компенсация: 775 тысяч долларов (из-за повышения стоимости акций на самом деле в налоговой форме было указано больше одного миллиона).

Пятый год

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

Мне выплатили премию 47 тысяч (20% как уровню E6 и множитель оценки производительности 1,125), а также дополнительный гонорар в 225 тысяч. Учитывая то, что бОльшую часть года мы закладывали фундамент продукта, моя оценка оказалась ниже, но к концу года мы показали успешность, благодаря чему мне дали дополнительную долю в 907 тысяч и повысили до E7.

Общая компенсация: 750 тысяч долларов

Шестой год

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

Я вернулся к хорошим оценкам и получил премию 93 тысяч (25% как уровню E7 и множитель оценки производительности 1,625), а также дополнительный гонорар в 650 тысяч. Благодаря прогнозируемому будущему влиянию нашей работы мне выдали дополнительную долю в 816 тысяч.

Общая компенсация: 1,1 миллиона долларов

Год 7

В этом году наш продукт совершил настоящий прорыв. Его стали упоминать на совещаниях M-team (небольшой группы руководителей с которыми советуется Цукерберг) и он начал влиять на общие показатели Facebook. Команда увеличилась до 25 инженеров. Мы сделали ставку ещё на два новых продукта, один из них провалился, зато другой показал признаки успеха. Теперь у нас было портфолио из одного очень успешного продукта, одного умеренно успешного и одного перспективного.

Мне дали премию 78 тысяч (25% как уровню E7 и множитель оценки производительности 1,25), дополнительный гонорар 650 тысяч и дополнительную долю акций на 1,2 миллиона. Благодаря влиянию нашего продукта на доходы Facebook меня повысили до E8.

Общая компенсация: 1,3 миллиона долларов

Восьмой год и далее

Я снова отправился в приключение и организовал новую команду из 4 людей. Сейчас мы по-прежнему находимся на начальных этапах нового продукта.

В этом году мне выплатили премию 90 тысяч (30% как уровню E8 и множитель оценки производительности 1), дополнительный гонорар в 840 тысяч и дополнительную долю в акциях на 1,1 миллиона.

Общая компенсация за год 8: 1,5 миллиона долларов (из-за повышения стоимости акций на самом деле в налоговой форме было указано больше двух миллионов)

Краткая сводка за годы работы в Facebook:

• В первый год я учился быть хорошим инженером,
• Во второй год я учился быть хорошим техническим руководителем,
• В третий-четвёртый годы начинал нечто новое с нуля. Хотя мы не добились успеха, зато узнали, как это делается
• В годы с пятого по девятый я продолжал следовать модели третьего-четвёртого годов: начинал что-то новое, выпускал и совершенствовал продукт, а затем увеличивал масштаб, чтобы сделать его успешным.
• В первые годы на мои успехи влияли мои навыки, удача и умение оказаться в нужном месте. Если бы три инженера-сениора не ушли из команды, то я бы не стал техруком так быстро, а потому был бы, по крайней мере, на один уровень ниже, а суммарные заработки в FB оказались на 25% меньше
• В последующие годы в основном важна была моя способность раньше других находить новые возможности и хорошо их реализовывать.
• Повышения с E6 до E7 и с E7 до E8 в основном были связаны с созданием чего-то успешного. Моя реализация могла быть идеальной, но если бы не успех продукта, меня бы не повысили.

---

На правах рекламы

Эпичные серверы это VDS для размещения сайтов от маленького интернет-магазина на Opencart до серьёзных проектов с огромной аудиторией. Создавайте собственные конфигурации серверов в пару кликов!

Проблема

Штрихкод классная штука для маркировки всего на свете, от товаров до людей. Сейчас в ходу около двух десятков стандартов двумерных штрихкодов, и ещё десятки неудачных, трагически непонятых, самопальных и внутренних корпоративных вариантов, большинство из которых с треском проигрывает обычному QR-коду. Распространённость и простота реализации сделали его самым популярным среди двумерных штрихкодов, но и у него есть недостаток, характерный для всех линейных собратьев: он вмещает очень мало информации. В 2-3 килобайта можно уместить ссылку или небольшой отрывок текста, но даже небольшая картинка или обычный документ уже не влезут даже в самый большой код.


Понятно, что вместимость обычного QR-подобного квадратика можно увеличить, увеличивая размер матрицы, добавляя цвета и играясь с формой ячеек. Единого стандарта для таких расширенных кодов нет, кроме проприетарного Microsoft Tag (HCCB) с неясными перспективами развития и использования. Расширение палитры и изменение пикселей также усложняет чтение кода в сложных условиях (плохая печать, цветное или недостаточное освещение), но всё равно даёт очень ограниченное увеличение ёмкости и не позволяет без боли передать даже мегабайт данных.

Хороший пример такого самодельного стандарта Jabcode

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

TXQR

Первой готовой и продуманной реализацией, из всех, что мне удалось найти, стал TXQR от Ивана Данилюка (блог, GitHub). В проекте есть спецификация и PoC на Go с приложением под iOS.



Сначала код TXQR просто прокручивал обычные QR-коды в цикле, а телефон старался их считать как можно точнее, получая коррекцию ошибок только при следующем повторении цикла. В тестах автор гонял файл на 13 килобайт, получив пиковую скорость 9 KB/s. В следующей итерации формат стал использовать фонтанные коды (точнее, Luby transform code), чтобы через избыточность позволить выполнять коррекцию ошибок в любых фреймах, не дожидаясь прокрутки цикла:



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



Теперь в пике TXQR выдаёт около 25 KB/s при низком уровне коррекции ошибок. Запомним это значение и перейдём к его преемнику, созданному двумя годами позже. Встречайте,

Cimbar

Cimbar (Color Icon Matrix bar codes) ещё больше отошёл от стандарта QR-кода, сохранив только визуальное сходство. Этот формат выжимает как можно большую пропускную способность, используя сразу цвета, иконки 8х8 вместо обычных пикселей и, разумеется, анимацию. В одну клетку кодируется 4 бита информации, и еще 2 или 3 бита добавляется за счёт использования цветовой схемы (на 4 или 8 цветов), позволяя хранить до 7 бит в одной клетке:



Кодирование в cimbar происходит по алгоритму, схожему с хэшированием изображений: декодер сравнивает тайл 4х4 со словарем из 16 ожидаемых тайлов и выбирает тот, у которого оказывается самый близкий хэш. Аналогично, для каждого тайла берётся средний цвет и сравнивается со словарём ожидаемых цветов, затем выбирается ближайший. Затем полученные данные проходят проверку ошибок по комбинации кода Рида Соломона, для фонтанных кодов используется wirehair. В текущем (не окончательном) формате размер сетки 1024х1024 символа, и при использовании на маленьких экранах или с плохой камерой код не всегда читается хорошо, поэтому разработчик обдумывает вариант пожертвовать пропускной способностью в угоду универсальности.

Выглядит итоговая картинка довольно жутко и эпилептично, но позволяет добиться при обычном уровне коррекции стабильных 700-800 KB/s! Это в 32 раза быстрее чем пиковая скорость TXQR при заниженной коррекции ошибок, и в этом можно убедиться самостоятельно:

1. Заходим на cimbar.org и загружаем файл потяжелее. Сначала лучше не уходить в крайности, я разок попробовал загрузить 10-мегабайтный .apk и устал держать телефон на весу, пока он качался, поэтому начинать стоит с 500KB-2MB.
2. Качаем приложение под Android
3. Включаем режим полёта и сканируем код. Не забудьте выбрать нужную цветовую палитру, по умолчанию на сайте и в приложении стоит 4 цвета.
4. Наслаждаемся магией!

Заключение

Пока проект существует как PoC, но разработчик явно хочет довести его до ума и развить в полезный стандарт. Доки и реализация на питоне лежат в основном репозитории, оптимизированная библиотека на C/C++ живёт отдельно, мобильное приложение здесь. На сайте cimbar.org кодировщик работает через wasm, репо найти не удалось.

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

---

На правах рекламы

Наша компания предлагает аренду VPS для совершенно любых проектов. Предлагаем широкий выбор тарифных планов, максимальная конфигурация позволит разместить практически любой проект 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!

Бытует мнение, что IT-специалисты народ своеобразный, и все у них заточено под компьютеры и технологии. Что даже Новый год они встречают вместе с нейросетями среди роботов в костюме из полупроводников за написанием очередной программы для оборудования по вакцинации 5G-станций. И что питаются эти ребята инфракрасным излучением и двоичным кодом. Опросы показали, что для ИТ-специалистов Новый год это традиционный семейный и домашний праздник, на котором принято ставить ёлку, готовить Оливье, пить шампанское и запускать фейерверки. А в большинстве компаний принято отмечать праздник новогодним корпоративом, который чаще всего проходит в ресторане, с кокаином и шлюхами с алкоголем и высшим руководством. Но статистика и стереотипы не отображают истинное положение дел отдельно взятого человека. Поэтому про празднование НГ, про подарки, и вообще как хотели бы провести праздники, и как провели новогодние выходные, спросим у самих айтишников! Ниже приведена подборка комментариев хабровчан к постам с поздравлениями Нового года за предыдущие годы.

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



vadimkonshin
27 декабря 2006 в 23:07
Меня о том, как буду отмечать Новый год, не спрашивали? А, вас спрашивали? Кого-нибудь из хабравцев спрашивали, например, Какие блюда у тебя будут стоят на праздничном столе?

Terras
26 декабря 2016 в 18:17
Жена поедет к своим на каникулы, а я куплю 3 бутылки пива, 5 гамбургеров, 10 сникерсов, включу Tony Hawk Pro Skater и буду деградировать пару дней, потом снова включу редактор и буду делать небольшой рефакторинг.

Isis
31 декабря 2011 в 18:10
Объявляется новогодний пост добра. (В новый год можно ;)) Всем отписавшимся плюсую рейтинг и карму. Это ваша возможность вылезти из минусов! :)

valzevul
31 декабря 2011 в 19:41
За С, за Perl, за Unix-shell,
За Windows, Гейтса, за Intel,
За скрипт, за байт, за Unicode,
За Linux, да за Hello, World!!

С Новым годом, друзья! :)

ra1nbow
1 января 2010 в 03:19
Уррааа!!! С Новым 7DA годом Хабралюди!!! И пусть я сейчас сижу в скучном кафе, где пьяный народ веселится под попсу (да, занесла судьба), Хабрахабр со мной (ага, на телефоне)!!! Спасибо вам всем за прошлый год, я думаю новый будет еще лучше!

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


ahiskali
1 января 2010 в 00:44
Желаю всем новых гаджетов, красивых девушек, интересных игр, кармы, вдохновения, желания что-нибудь сделать, времени и счастья, хотя бы от того, что они добились чего-то в жизни! Пусть вы получите все это в новом году.

white_panda
1 января 2013 в 01:29
А у меня +12, целый день дождь и, соответственно, никакого ощущения праздника. Поэтому спасибо всем в этом треде за создание настроения, работает!

Всех с Новым Годом, ура!

ADOLF88HITLER
31 декабря 2012 в 19:05
Обнулите себя. Начните Новый год с чистого листа

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


kahi4
31 декабря 2013 в 19:27
Все желают хорошего и безбажного кода, а я же хочу отдельно поздравить всех инженеров хабра!
С Новым годом, товарищи, без которых не было бы столь большого количества таких клевых вещей)
Желаю, чтобы у Вас просто удавались все расчеты, без проблем находились оптимальные программы управления, сходились все ряды и все системы были устойчивые! Чтобы у навигационных устройств СКО не выходило за требования, чтобы электромагнитные волны распространялись так, как вам нужно, а не как вздумается природе, чтобы фильтр Калмана не схлопывался, а радиоэлектроника не горела!
Чтобы Вы шли по намеченному пути и не отклонялись от него больше, чем на три сигмы, а все случайные шумы были Гауссовскими!
Ну и общее чтобы Вам всегда дул попутный ветер во всех ваших начинаниях и Вы всегда достигали поставленные цели!
С Новым годом, тов. инженеры, с Новым годом, жители Хабра, с Новым годом, IT сообщество)

omfg
31 декабря 2008 в 17:06
Хабралюди! Я в 2009 уже! Тут клево, кризиса нет, зарплату подняли, всех кого посокращали вернули обратно!!!
Всех с новым годом, всех люблю!!!!!)


Surgeon
31 декабря 2008 в 18:51
а я уже разок Новый год встретил в интернете дома новый год давно наступил(Камчатка).Шампанского одного нет, открыл:)
Через 5 часов встречу наяву в Питере:)
Всем удачи и новых идей!
и пусть желания офигеют от ваших возможностей! =)

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

iklementiev
31 декабря 2014 в 20:01
Дорогой Дед Мороз!
Подари мне пожалуйста сегодняшнюю ночь без компьютера!
Хороший мальчик Илюша.

vitalikk
31 декабря 2009 в 17:50
Вот мне, например, хочется найти под ёлочкой дизайнера/художника-фрилансера, который будет готов вместе со мной (программистом, в общем-то) работать много, кропотливо и фанатично над развитием своей студии =)

Новый Год время, когда следует подвести итоги уходящего года и составить планы на год наступающий.

Mako_357
2 января 2017 в 12:34
Хочу это желание. Человек чего то хочет, но двигаться от этого не будет. Если он чего то хочет, то это не означает, что он это сделает. Человек ставит цель и хочет её достигнуть. Но хотеть мало. Надо пообещать себе выполнить её.
На самом деле ничего страшного не произойдёт, если не сдержать слово. Это просто стиль жизни. Одни дают обещания и не выполняют, потом угнетают себя или вообще им всё равно. И другие, которым важно держать слово.
Какая выгода из этого? Если слово не дежишь или не даёшь выгода в том, что можно ничего не делать. Отдохнуть, расслабится. Это выгодно. Прикольная, классная жизнь, в которой ничего не происходит.
Какие выгоды от того, что держать и давать своё слово? Достижение своих целей.
Важно ли человеку жить той жизнью, где он достигает целей, быть успешным или той, где можно поленится, пожить в комфорте, откладывая дела на потом?

Tavee
2 января 2017 в 11:48
Обещаю выучить верстку и тд. Ну и немного секса

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

redhummer
28 декабря 2006 в 06:09
Однозначно прикуплю курицу гриль, какую-нибудь рыбину и шампанского. В обязательном порядке будет присутствовать салат из кальмаров. Но всё это мелочи.
Меня больше грют мысли о первом января =)

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

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

Coogle
28 декабря 2006 в 20:33
Буду поздравлять и выпивать тосты с колегами и друзьями, сидя за ноутбуком с включённой вебкамерой и приконектиным к Skype :-)

deenween
28 декабря 2016 в 17:52
Жена уже распланировала выходные. Поездки, кино, лыжи, теща А так хочется 3 бутылки пива, 5 гамбургеров, 10 сникерсов....

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


Travin
30 декабря 2007 в 14:13
Призываю людей, которые зарабатывают в интернете, в знак уважения к компьютеру и интернет на новый год повесить свою компьютерную мышь на елку.

iOrange
1 января 2014 в 03:11
Продолжу свою Новогоднюю традицию по раздаче плюсов в каменты и то_слово_которое_нельзя_упоминать. С Новым Годом!

Isis
31 декабря 2011 в 20:47
Потратил 120+ голосов за карму. Ушел за стол :)
Еще раз с наступающим и наступившим!

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

hrych
28 декабря 2006 в 14:47
В прошлую новогоднюю ночь я сидел один с бутылкой коньяка и хорошим шоколадом. Не скажу, что было весело. Но необычно и совсем неплохо. А необычное как раз и запоминается.

Djeid
28 декабря 2006 в 15:02
В прошлый НГ мне хотелось праздника и мы с друзьями его сделали, а в этом году хочется домашнего уюта, елку с фонарями, шоколадных конфет, мамины пельмени и телевизор до утра :)

MEXX
1 января 2008 в 22:16
Присоединяюсь ко всем, кто дома, в одиночестве и в интернете, только с поправкой, что я и не праздновал вовсе :))

ozware
13 ноября 2009 в 10:04
я понимаю, что одиночество это удел великих, но не дай бог такое случится!

пока что каждый раз НГ провожу в новом месте, обычно это заграница))

TuiKiken
12 ноября 2009 в 22:45
У меня тоже был случай Вышел с друзьями на Новый год на улицу, прошёлся Помню была слякоть, мелкий моросящий дождь создающий какую-то дымку, тусклые огни фонарей, свет которых вязнул в этой дымке и гопнички плясали у ёлок. Меня это всё как-то угнетало. Новый год у меня ассоциируется с чем-то новым, чистым и лучшим А тут я увидел полную противоположность. Пошёл домой, запустил онлайн игру а там мой друг сидит. Такой же угнетённый. Я принёс бочонок вина и сидел у монитора всю ночь попивая алкоголь.

dekin
29 декабря 2007 в 14:58
Я сегодня с утра работал у Заказчика и умудрился сделать, казалось бы, невозможное в последний рабочий день уходящего года: согласовать разработанное мной ТЗ (между прочим, 8 подписей!), у которого дедлайн истекает как раз сегодня.
И вот буквально пару минут назад с чувством выполненного долга залез на Хабр. И вновь приятно удивился: кому-то понравился мой пост про Новый Год:)
Спасибо вам, хабрадрузья! С наступающим!

masterOk
1 января 2012 в 07:45
Вот уходит старый год:
Пусть с собой он заберет
Все невзгоды и печали,
Коннекты, что порой слетали.

Заберет он пусть заботы,
Звезды, что идут с traceroute,
DoS'еров пусть с наших сайтов
Заберет он без возврата.

Жадных, мелочных клиентов,
Нелюбимых конкурентов,
Палки, что в колеса лезут,
Ламерских мозгов протезы.

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

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

Что с собой он принесет?
Мы сейчас, увы, не знаем,
Но, как прежде, пожелаем
Всем айтишникам сейчас

Не лагал чтоб комп у вас,
Чтоб программы компилились,
Сети чтоб всегда ловились.
Шашлыки чтобы на даче,

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

Много раз сходить в кино,
Наконец-то отоспаться,
От рутины оторваться,
Новых завести друзей,

Целей достигать быстрей,
И чтоб вири на машине
Никогда не заводились,
Да и вы чтоб не болели.

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

И большой-большой зарплатой
Оценили чтобы вас.
Вот на этом я рассказ
И заканчиваю. Глянь!

На столе пивка стакан
Уж налит. Давай поднимем,
Программист, или админ ты,

Эникейщик ли виндовый,
BSD-шник ли суровый,
Новый Год встречать пора!
Drink, айтишники! Ура!

---

На правах рекламы

Вдсина поздравляет всех с Новым Годом! Пускай 2021 приносит только хорошее, а всякого рода неприятности и ковиды остаются в старом году!
И в обычный день, и в Новый Год наши виртуальные серверы работают безупречно и без сбоев. Используем исключительно брендовое оборудование, лучшую в своём роде панель управления серверами собственной разработки и одни из лучших дата-центров в России и ЕС. В Новом Году порадуем множеством приятных сюрпризов.