Порой путь человека может быть предопределён. Завтра исполняется 69 лет Тиму Бернерсу-Ли, создателю всемирной паутины, о жизни которого мы завтра вам расскажем подробно. Великие люди порой затмевают своих предков, так случилось и сейчас: мало кто знает родителей человека, создавшего WWW.

Но как вам создание одной из первых программ для диагностики ошибок в железе и ПО первого коммерческого компьютера? Первая в мире женщина-фрилансер в 1955 году с четырьмя детьми? Человек, который в середине ХХ века смог добиться равных условий труда и равной оплаты для программистов? Женщина, которая считает, что самое классное в программировании – это машинный код! Это всё мать Тима, Мэри Ли Бернерс-Ли (Вудс). Сейчас мы познакомимся с ней поближе!

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

❯ Семья и учёба Мэри Ли

Мэри Ли родилась в учительской семье в 1924 году. Её мать с рождением ребёнка преподавать перестала, а отец продолжил. Он занимался с теми детьми, успехи и способности которых были невысоки. Мэри пошла в одну из первых школ с совместным обучением мальчиков и девочек. Сама Мэри любопытно отзывалась о своём месте обучения:«Школа не отличалась академичностью, но занималась воспитанием хороших граждан; там не было побоев палками, задержаний и прочих дисциплинирующих моментов. А в школе брата была и травля, и удары палками, и другие подобные вещи».

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

После возвращения в Бирмингем выяснилось, что здание, где проходили занятия, подверглось бомбардировке, было разрушено крыло здания. В институте не хватало преподавателей: все ушли на фронт. За два года у Мэри сменилось 5 учителей математики, что сильно сказалось на обучении. В возрасте около 20 лет лишь благодаря стипендии она смогла уехать в Манчестер и заняться там инженерной подготовкой за свой счёт. Стипендия составляла 75 фунтов в год, чего хватало, со слов Мэри, на безбедную жизнь. Для примера, у её коллег (еврейских беженцев) было всего 22 фунта в год.

В 1944 году Мэри как талантливую выпускницу направили в центр авиационных исследований, но там она остаться не смогла. Её брат, лётчик, совсем недавно погиб на войне. Мэри вернулась ближе к дому, она тяжело переживала смерть брата и хотела быть ближе к своей семье. До 1947 года она продолжила изучать математику в институте и увлеклась астрономией, которая привела её в… Австралию!

❯ Австралия, астрономия и дискриминация

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

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

Удивительный путь в программисты

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

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

Сама Мэри так описывала своё собеседование: «Я пошла на собеседование; и, поскольку я кое-что знала о компьютерах, я могла задавать умные вопросы. Это должно было на треть увеличить мою первоначальную зарплату». Так она устроилась в фирму «Ферранти», где ей предстояло работать с первым коммерческим компьютером «Ferranti Mark 1».

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

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

❯ Совсем (не)пыльная работа

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

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

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

Отдельную проблему создавала оперативная память. Она была реализована через трубки Уильямса–Килберна и вмещала двадцатибитное слово. Второе слово в память уже не помещалось и переходило во вторичную память, магнитный барабан. Любая настройка программ вызывала большие сложности в том числе и из-за того, что машина была одна и время пользования было сильно ограниченным. В то время существовала шутка, связанная с IBM: у руководителя висел плакат с надписью «ДУМАЙ!», а у работников фирмы «Ферранти» тоже висел плакат «Думай, но не здесь!»

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

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

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

❯ Кто должен бороться с дискриминацией?

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

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

Бунт удался. В 1951–1952 годах, когда происходили описываемые события, фирма «Ферранти» установила равные зарплаты для молодых сотрудников вне зависимости от их пола. По мере роста мастерства и продвижения по службе они стали получать равные прибавки, выполняя одинаковую работу.

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

❯ Любовь, семья, работа и фрилансерство

В 1952 году Мэри познакомилась со своим будущим мужем, причём знакомили их аж трижды, но сначала это были мимолётные рабочие встречи, и лишь когда их в третий раз познакомили, уже на праздничном ужине, они вдруг поняли, что раньше встречались. Мэри вспоминала забавную историю, когда она всю ночь работала за компьютером, а будущий муж звонил по телефону, но Мэри слышала всё, что он говорит, несмотря на работающие рядом очень громкие телетайпы. Позже был торжественный ужин, на котором их «познакомили», скоротечный роман, свадьба в 1954 и рождение Тима Бернерса-Ли в 1955 году.

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

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

Мэри вспоминала, что ей очень хотелось на работу, она любила свою работу, но никогда не сомневалась, что сделала правильный выбор и стала мамой четверых детей. Она потом вспоминала, что семейное счастье и дети в самом прямом смысле ломают карьеру. Позже была создана F International – британская компания, которую основала другая женщина-программист Стефани Ширли. Эта копания работала именно с женщинами-программистами-фрилансерами. Это была первая подобная компания, и её, в широком смысле слова, политическое влияние имело не меньшее значением, нежели экономическое. Фирма активно привлекала внимание прессы к проблеме работы женщин-программистов. История этой фирмы, по хорошему, стоит отдельного текста.

Однако для Бернерс-Ли работа в этой фирме не совсем подходила, у Мэри были свои заказчики, например, к ней обращалось Лондонское транспортное управление. Задача Мэри состояла в том, чтобы уменьшить задержки движения общественного транспорта. Группа специалистов рассчитывала, какие условия могут создавать автобусные пробки, а Мэри переводила это всё в работающую программу. Работ было множество, например, запуск метеозондов в военном городе, где нужно было быть крайне аккуратной с округлениями. Параллельно происходила компьютерная революция. Сначала для выполнения задачи Мэри пришлось выучить Mercury, потом Algol, сильно позже – Fortran, уже после возвращения на постоянную работу. Никакие лавры не позволяли отставать от прогресса.

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

❯ Возвращение на работу и новый статус

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

И вот тут она вернулась в программирование, научившись использовать фортран. Мэри стала работать в фирме, которая специализируется на PERT (Program Evaluation and Review Technique), методе оценивания и анализа проектов, которые используются при управлении огромными сложными проектами и оптимизации этих систем.

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

Позже она со смехом вспоминала: «Теперь я знаю, почему все инструкции такие плохие». Мэри на собственном опыте столкнулась с тем, что писать их – сложный процесс. Просто собрать объём информации и комментариев совершенно недостаточно. После того как она проводила всю работу, делала инструкцию понятной и доступной… Менялась сама программа! Программа существенно меняется чертовски быстро. Да и написание инструкций требовало очень серьёзного анализа – что такое «очевидно»? что такое «все понятно»? Чему уделить много времени? Проработав несколько лет, Мэри поняла, что больше не вытягивает тот уровень и… просто ушла на пенсию в 1987 году в возрасте 62 лет, причём вместе со своим мужем, которому исполнилось 65.

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

❯ Что самое главное в жизни?

У Мэри редко брали интервью, а когда брали, спрашивали в основном про старшего сына Тима Бернерса-Ли и интернет. При этом хоть сама Мэри и называет себя в шутку «бабушкой интернета», но не превозносит заслуги своего старшего сына.

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

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

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

Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей в нашем блоге на Хабре и телеграм-канале.

Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.

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

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

❯ Проблема остатка (Remainder issue)

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

Возможно и вы с этим сталкивались, когда вводили всякие мапперы, делегаты, интеракторы (те, что репозитории репозиториев) и прочее. Помогли ли они мне? Нет. Лучшее решение, что я видел — это Flux- и ELM-like архитектуры, которые заявляют «чистую» функцию как единицу деления логики, но со всеми вытекающими отсюда удобствами и следующими за ними «эффектами».

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

❯ Проблема масштабирования (Scalability issue)

В прошлый раз я упоминал «интуитивный» подход к решению задачи масштабирования и рассказывал почему он не работает. По крайней мере не у меня.

А какой не интуитивный?

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

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

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

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

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

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

❯ Проблема разрывов (Gaps issue)

И вот тут становится интересно. Все дело в Hello World. Мне все никак не дает покоя вопрос: какая у него архитектура?

Hello world

Я видел примеры Hello World в разных языках, фреймворках и архитектурах (кроме Open GL, конечно же), и у них не было проблем с его реализацией. Если не считать проблемой то, сколько усилий надо приложить, чтобы написать изначальный шаблон. Но, если результат одинаковый, не значит ли это, что разница только в том, сколько обвязок надо написать, чтобы Hello World работал? И нужны ли они? Тогда я стал думать: а что общего у всех этих реализаций Hello World в разных архитектурах? И как-то я пришел к мысли, что скорее всего правильный ответ — Алгоритм. И он до безобразия тривиален.

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

Более интересные примеры

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

А вот еще интересное наблюдение: если мы немного обобщим алгоритм Hello World, отделив show от Hello World, то увидим, что он дважды появляется в алгоритме этого примера.

Все еще слишком просто, правда? Следующий учебный пример — работа со структурами данных. И в самом простом виде — это CRUD плюс “показать все” с хранением в списке (он же List). Этот пример, не очень интересный с точки зрения реализации, интересен тем, что он добавляет в предыдущий алгоритм композицию.

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

Появление Gaps issue

Но что происходит даже с этими простыми программами, когда мы пытаемся перенести их в UI-среду?

Легче всего Hello World, потому что он просто обрастает кучей компонент, которые помогают ему “жить” в новой среде. Даже не интересно.

А вот Hello %user name% приходится куда сложнее. Беднягу размазывает по компонентам системы или архитектуры: в одном месте мы слушаем ввод имени, в другом показываем приветствие, а в третьем прописываем реакцию на введенное имя.

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

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

Причина — асинхронность

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

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

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

Решение — закрытие разрыва

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

Напомню как всё было, и в этот раз уже не буду лукавить: путь нашей логики начинается в каком-то из callback’ов, а не в абстрактном “начале”. По мере выполнения мы продвигаемся все глубже по стеку вызовов, выполняем одну за другой функции, и в самой верхней точке нашего графика мы обращаемся к источнику данных: бэкенду, файлу, какой-то системе хранения. И что здесь обычно находится?

Обычно это вызов какой-то “асинхронной” функции: корутины, async- или suspend- функции, уж простите мой котлинский, или какой-то функции с callback’ом, или функции возвращающей какой-нибудь Future, Promise или Single.

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

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

Так вот вопрос: а почему бы нам не повторить этот же трюк с UI?

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

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

❯ Proposal

Давайте писать функции…

Да, может звучать нелогично, тем более, что я уже говорил о том, что это не помогает Flux- и ELM-like архитектурам, но я объясню. Начнем с проблемы остатка.

Влияние на решение проблемы остатка

Добавлю небольшую аналогию с математикой. Как я и говорил «архитектура» — это делитель. А чтобы при делении не оставалось остатка — нам нужно найти наибольший общий делитель. Чем и является функция, на мой взгляд. Чем больше я смотрю на реализации всех наших «архитектур», тем больше я вижу, что все они, по сути, просто один из способов удобнее объединять и специализировать функции (и тут я подразумеваю, что метод класса — это функция, которая иногда неявно принимает дополнительный аргумент).

Дальше лучше — проблема масштабирования.

Решение проблемы масштабирования

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

А что с разрывами?

Решение проблемы разрывов

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

❯ Концепт

Так что же я предлагаю?

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

Во-вторых, у этой функции (композиции функций) должна быть возможность работать независимо от «сторонних» систем, поэтому я предлагаю вынести ее в свой поток, чтобы у нее была возможность спокойно выполняться, блокироваться при необходимости, параллелиться и тому подобное. Пусть будет “синхронной”. Обычно мне не надо, чтобы логика продолжала свое выполнение, когда она ждет какой-то ресурс. А если такое поведение нужно, то почему-бы его не описать его явно? И назвать бы этот поток Main, но имя уже “занято”. =)

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

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

В конце концов, применив этот концепт, я хочу помочь всем нам проектировать и писать кроссплатформенные приложения в самом широком смысле этого слова: разрабатывая и реализуя end-to-end алгоритмы которые прозрачно перескакивают с бэкенда на фронт и обратно, которые не видят различия между разными видами фронтов, будь то Web, iOS или Android, или разными типами вроде UI, CLI, или TalkBack.

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

Увидимся.

• Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей в нашем блоге на Хабре и телеграм-каналах (статьи и новости).

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.

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

Игр для калькуляторов, как на просторах бывшего СССР, так и за рубежом громадное количество, остаётся только выбрать. Наиболее популярная — это «Посадка на Луну». Однако, для меня она показалась скучной и неинтересной, а сам код сложным и запутанным. Поэтому мой выбор пал на крестики-нолики, так как все мы играли в них в школе, и мне стало интересно сыграть в неё с калькулятором.

Реализовать игру решил на модели HP-32S, поскольку он мне очень полюбился за красоту архитектурной реализации и удобство программирования.

❯ Основа программы

В предыдущей своей статье "Калькуляторы с обратной польской нотацией" я делал обзор литературы для программируемых калькуляторов. Среди которой была замечательная книга А.Г. Гайшут "Калькулятор твой помощник и соперник в играх".

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

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

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

Описание программы Крестики-нолики из книги:

Главная задача – это перенос этого кода с МК-61 на калькулятор HP-32S. Для начала, разберёмся как эта программа работает.

❯ Проверка программы на МК-61

Первое, что я сделал – это перенабрал код из книги в формате, который понимает онлайн-эмулятор МК-61.

Кстати, если интересно, то можно попробовать поиграть в эмуляторе, чтобы понять принцип работы. Для этого копируем код, вставляем в область «Код программы:» и нажимаем кнопку «Ввести в память». Картинка из книжки выше подсказывает нам, что калькулятор даёт координаты, куда ставить "X", а мы ему в ответ передаём координаты, куда ставить "O".

Чтобы начать играть на клавиатуре калькулятора, нужно нажать кнопку [С/П]. В ответ будет выведено число, первое число всегда «9» (центр поля). В ответ необходимо ввести свою координату, например, «2» и нажать [С/П]. И так далее, пока вы не проиграете (калькулятор выведет «77», либо будет ничья (калькулятор выведет «0»).

Чтобы посмотреть последний ход калькулятора, надо обменять регистры X и Y местами, для этого нужно нажать на клавишу [⟷].

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

❯ Анализ кода программы для калькулятора МК-61

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

Особенность программирования МК-61 в том, что он пропускает команду перехода, если условие истинно, и исполняет — если ложно! Поэтому все условия для python пришлось инвертировать. Плюс, я для удобства ввёл дополнительные функции, которые также перенёс впоследствии в HP-32S: функция вывода координат крестиков и ввода ноликов, функция ничья и победа калькулятора:

Первое – инициализирую регистры калькулятора:

После всех подпрограмм идёт головная программа:

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

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

Исходный код доступен в репозитории проекта.

И, да, код вполне себе работоспособен, в чём несложно убедиться:

❯ Перенос кода на HP-32S

Напомню, что калькулятор HP-32S, который есть у меня, принадлежит семейству калькуляторов HP10B/14B/17B/17BII/19BII/20S/21S/22S/27S/28S/32S/32SII/42S, таким образом, всё, что приводится ниже, с небольшими адаптациями можно будет перенести и на другие модели этой серии.

Трудозатраты в предыдущей главе, по переносу кода на python, были проделаны с двумя целями:

1. Понять, как же работает этот код (увы, не выполнено).

2. Более удобно переносить на другую модель калькулятора.

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

Вооружившисьдокументацией на калькулятор HP-32S, я переписал программу крестиков-ноликов с питона для него. Для удобства я делал это в таблицах Exel. Как я уже говорил, особенность калькулятора в том, что он маркирует каждую строку буквой и цифрой, а любая метка – это смена буквы. Таблицы идеально подходят для этого.

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

Код программы для калькулятора HP-32S:

В силу того, что на калькуляторе HP-32S можно сделать вывод на экран конкретного регистра (с указанием имени регистра), а также запрос ввода другого конкретного регистра, то ввод-вывод становится чуть более интерактивным и интересным.

Лучше один раз увидеть, чем тысячу раз прочитать.

❯ Выводы

Изначально задача казалась мне такой простой, но заняла у меня достаточно приличное время. Её ценность состояла в том, что мне удалось разобраться — как же программировать для калькулятора HP-32S. В результате оказалось, что из модельного ряда калькуляторов, с которыми я занимался — эта версия оказалась самая дружелюбная и удобная.

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

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

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

1. Гитхаб этого проекта

2. Первая часть «Калькуляторы с обратной польской нотацией»

3. Сайта автора «Гайштут и его друзья»

4. Онлайн-эмулятор МК-61

5. Документация на калькулятор HP-32S

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

• Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные статьи.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.

Дисклеймер ↓

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

Но в итоге сегодня наша статья наконец-то выходит в свет. Из цензуры — только внимательная рука корректора. Передаем слово Максу Яковлеву.

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

❯ Некоторое время до

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

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

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

Важно понимать, что любой типичный хостинг находится под DDoS-атакой практически 24/7: хоть одного клиента в каждый момент времени да атакуют. Поэтому DDoS для нас — это даже несколько банально. За 17 лет мы повидали много чего и в принципе знаем ключевые (и не только) паттерны, откуда, что, куда и как.

❯ Добрый вечер

14 сентября, ближе к 18:00, в нас влетел очередной DDoS, с которым известно что делать. Отбили — пошли отдыхать. И не успел я допить чай, как атака повторилась, потом опять, а потом еще раз. Каждый раз интервал уменьшался, а объем нарастал.

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

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

Из дополнительных проблем в СПб: аплинки подключены через свитчи с переподпиской, QOS или не работает, или не хватает буфера → разваливается сигнализация. Дополнительно существуют громадные растянутые VLAN, из-за чего атака на одну подсеть затрагивает огромное количество клиентов. Мониторинг и контрмеры работают слишком медленно.

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

❯ Мы накидываем план

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

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

И стратегически: построить свои сети во всех локациях. И собственную защиту.

В первую очередь отказываемся от существующей системы подавления DDoS, потому что она приносит больше вреда, чем пользы. Сетевики начинают спать по очереди, текущий flow-мониторинг меняем на семплированный Inline IPFIX с payload-ом. Таким образом не ждем, пока соберется поток, и принимаем решения за секунды. Этот шаг помог уменьшить среднее время обнаружения каждой атаки: чтобы понять, что она началась и как нужно действовать, нам сначала нужна была пара минут, чуть позже — 15 секунд, а сейчас автоматика реагирует почти мгновенно.

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

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

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

❯ Строим свою сеть

Начинаем с Питера. План включал в себя апгрейд маршрутизатора с установкой дополнительных плат и подключение к различным каналам и точкам обмена трафиком. Цель — увеличить пропускную способность: нам нужно было научиться принимать трафик атак и блокировать более точечно, а не просто кидаться блекхолами и снимать префиксы. Кроме того, стало понятно, что объемы атак могут расти и нам нужно будет научиться расширять емкость более оперативно, не проходя весь цикл «найти железо → найти емкость → собрать».

Обычные маршрутизаторы не всегда эффективны для такой деятельности: они обладают слишком сложным и дорогим конвейером обработки трафика, предназначенным для других задач. Исходя из этого мы решили действовать комплексно: помимо расширения каналов и увеличения портовой емкости сервисных и пограничных маршрутизаторов начали внедрять пакетные платформы на базе Juniper PTX. Они хоть и попроще, но в них много дешевых 100G/400G-портов, как раз то, что нам нужно.

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

В итоге в Питере мы добили емкость по основным направлениям до 500+ гбит, а по автономке у нас сейчас суммарно около терабита. Уже через две недели после этого ситуация в СПб стабилизировалась: емкости хватало, фильтры отрабатывали оперативно. В остальных локациях сеть была арендованная: и в Казахстане, и в Европе. По этой причине параллельно с выравниванием ситуации в Питере у нас появилась новая приоритетная задача: поставить в заграничные локации собственные маршрутизаторы и дотянуться до них из Питера — тянуться решили через M9.

Девятка до сих пор крупнейшая пиринговая точка и сосредоточение телеком-инфраструктуры РФ и СНГ. Кроме основных трасс для всей России, туда же заходят каналы от СНГ — зачастую единственные.

Магистральные каналы между площадками дают несколько преимуществ:

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

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

3. Наше управление не развалится никогда, даже если внешние стыки в локации будут забиты под полку.

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

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

Но из-за ее громоздкости отправили 204 — и теперь в казахстанском ЦОДе у нас стоит платформа, которой хватит на целый машинный зал облака, а не на наши несколько стоек. На память осталась только фотка со стикером из аэропорта Екб:

К декабрю дотянулись и в Европу: теперь у нас есть узлы во Франкфурте и Амстердаме с арендованной магистральной емкостью. Там появились выходы и в интернет — через Tier-1 операторов, и на европейские обменники.

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

Раз уж пошли по локациям, то добавлю, что в этом году запустились и в Москве, в IXcellerate. Это Tier-3 с уникальной системой охлаждения по типу «холодная стена». Я там был на экскурсии — наверное, самое интересное, что я видел в России и СНГ, а поездил я немало. Пиво еще вкусное у них было — тоже плюс 🙂

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

❯ Почему мы не спрятались за подрядчиками

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

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

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

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

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

❯ Что сейчас

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

Работы еще много: всю эту новообразовавшуюся сеть нужно резервировать и расширять. На М9 мы взяли целую стойку и собираемся ставить шасси MX960 — с большим запасом на будущее. Оно будет выполнять роль магистральной развязки, принимать внешние стыки и выступать ядром сети дата-центров по Москве, у нас там большие планы. Не забываем и про Северную столицу: платформа PTX10003 станет ядром нового узла на Кантемировской («Радуга»), где будет перемыкать магистрали и стыки с внешними сетями, выступая частью инфраструктуры очистки трафика в Санкт-Петербурге.

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

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

Для выделенных серверов по части сети у нас получилось очень интересное предложение. По запросу скорости мы даем вплоть до 100—200 гигабит на сервер, так мало кто умеет. Кроме простого интернета — широкий набор сетевых решений: тут и более-менее стандартные L2/L3 VPN на MPLS, и любые манипуляции с внешней маршрутизацией. Для владельцев своих AS соберем транзит, притянем любую популярную точку обмена трафиком. Для тех, кто хочет ими стать, — поможем выпустить ASN, арендовать или купить сети, анонсировать их в мир.

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

❯ И напоследок — неудобный вопрос от маркетинга

— Почему не начали делать все это раньше, а триггером стало то, что на нас пришла атака?

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

А почему атаки стали триггером? Все банально. Во-первых, мы поняли, что начали расти сильно быстрее, чем планировали. Стало понятно, что нужно больше емкости, больше сервисов — и не когда-то, а сейчас. Во-вторых, появились новые угрозы, которые не отражаются стандартными средствами. В какой-то момент мы переросли «стандартные» подходы, которые мог бы использовать игрок меньшего размера, — нужно было пилить какой-то кастом или средствами сторонней компании, или самостоятельно. Мы выбрали второе.

Присоединяйтесь к нашему комьюнити в Телеграме — здесь можно общаться с сообществом, задавать вопросы руководителям, гендиректорам и фаундерам, и предлагать идеи ↩

Когда на меня накатывает хандра, я бросаю всё и пилю свой игровой движок. Это неблагодарное занятие, но меня прёт.

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

И вот я тут спустя 5 лет.

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

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

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

Ну и вот про одну такую ошибку я хотел поговорить. Есть такой движок — ODE (Open Dynamics Engine). Он появился где-то в палеолите, динозавры его накодили, от документации остались только царапины на скалах. Но он работает, он простой в использовании, и у него есть сишные заголовки, поэтому я мог просто написать враппер на Nim и использовать его в своём движке. В Nim вообще ни хрена нету, поэтому канонический способ — это взять какую-нибудь библиотеку из Си, научиться её вызывать, а потом говорить всем, что ты написал крутую программу на Nim.

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

Разумеется, если вы не планируете делать Minecraft, то вам может понадобиться что-то поинтересней, чем кубик. В ODE есть специальный класс Trimesh, который как раз позволяет вам сделать сложную геометрию. Фактически, вы можете создать любое тело из набора треугольников. Типа такого:

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

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

Так и появилась эта дурацкая невидимая стена.

Фактически, я мог ходить по сцене, и где-то я упирался в тот самый треугольник, который вообще-то должен был быть там, где нарисован. Я в принципе даже что-то такое и ожидал, потому что, как я уже где-то писал, только три раза в своей жизни я написал код, который заработал с первого раза. Наверняка я где-то перепутал координату — вместо X передал Y, или наоборот, ну что-нибудь такое. Эти программисты, вы знаете!

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

И тут я вспомнил эту недалёкую женщину из заЩИТников! Если кто не знает, она сделалась невидимой и решила спрятаться в дожде. Отличный план, надёжный, как швейцарские часы:

Я подумал, что это прям мой случай, и решил полить свою стену дождём, чтобы увидеть её. Дождя у меня не было, зато были кубики, поэтому я создал штук 50 и стал кидать их вниз. При касании стены они к ней прилипали, и я мог видеть её очертания. А когда что-то видишь — отлаживать в разы легче!

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

Если нужно где-то найти таких же неудачников, как я, то самое лучшее место для этого — интернет. И я нашёл его — единственного человека, который отстрадал своё и рассказал об этом. Представляете, в 2006 году у какого-то чувака из Германии пятая точка горела точно так же, как у меня сейчас! Не знаю, что он выкурил (похоже, что исходники), но, ОКАЗЫВЕТСЯ, физический движок ожидает от вас трёхмерные точки, но передавать их надо как четырёхмерный вектор, просто в четвертой координате надо поставить мусор, типа так: [x1, y1, z1, 0, x2, y2, z2, 0, ...]. Скажите, как по const dReal* Vertices я должен понять, что там ждут в гости четырёхмерные вершины?

За что я люблю опенсорс — можно всегда докопаться до истоков всего. Я полез в исходники, и вот что обнаружил.

В 2003 году пришёл Russel Smith и добавил всю эту функциональность с trimesh collisions, в том числе интересующую меня строчку:

Тут всё понятно, потому что в определении чётко говорится, что dVector3 — это четырёхмерный вектор (есть некий шарм в этой логике).

А потом через пару месяцев врывается Erwin Coumans и переписывает так, чтобы тип был непонятен:

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

Я переписываю код с добавлением четвертой координаты, и все начинает работать.

Такие дела.

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

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

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

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