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

В пятницу 13 сентября 2019 года Мэтью Принс и Мишель Зэтлин, сооснователи компании Cloudflare из Сан-Франциско, занимающейся интернет-безопасностью, стояли на узком мраморном балконе, с которого открывался вид на Нью-Йоркскую фондовую биржу. Стайка директоров компании сгрудилась рядом с Принсом, готовая вести вслух обратный отсчёт. «Громче! Громче! – призывал их Принс. – Пять! Четыре! Три!..» Ровно в 9:30 основатели потянулись к знаменитому колоколу биржи, знаменующему начало торгового дня, а также – выход их 10-летней компании на биржу. Так они изменили свою жизнь и сорвали куш. В тот момент они обогатились на миллионы долларов.

Более сотни сотрудников и инвесторов, стоявших внизу на первом этаже, разразились радостными криками, а их поднятые телефоны фотографировали происходящее. Кристин Холлоуэй, сотрудник №11, подняла взгляд на балкон, сделала несколько фотографий, а потом отправила их через мессенджер своему мужу, Ли Холлоуэю, третьему сооснователю компании. Он в это время находился дома, в Калифорнии. Периодически чьё-нибудь знакомое лицо выныривало из толпы, чтобы сказать ей: «Ли должен был быть здесь».

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

Вокруг языка Scala всегда было много хайпа и неоднозначных суждений.

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

В ответ на это один из очень активных членов сообщества (Li Haoyi) описал своё видение дальнейшего пути языка Scala.

Статья у него получилась интересной, посему решил перевести её.

В сети гуляет интересная задача, которую задавали на собеседовании в Twitter.

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

Еще в декабре мне попалась одна совершенно замечательная статья на английском, посвящённая использованию системы типов языка для более широкого класса задач, для повышения надежности приложений и простоты рефакторинга. К сожалению, в тот момент я был слишком занят написанием статей по ФП, которые крайне важно было написать, пока свежи воспоминания. Но теперь, когда с этой задачей я справился, наконец дошли руки перевести эту замечательную заметку. Оригинальный язык примеров — Хаскель, но я решил переписать их на раст, для более широкого охвата аудитории. Однако язык тут совершенно неважен, советы этой статьи я применяю в ежедневной разработке на вполне себе "приземлённых" C# и TypeScript, так что если вы просто стараетесь писать надёжный и поддерживаемый код, то, вне зависимости от языка, статья вам будет в тему.

Благодарю за вычитку и помощь в переводе Hirrolot, funkill и andreevlex

RESTinio, наш небольшой встраиваемый HTTP-сервер, продолжает развиваться. Одной из отличительных особенностей RESTinio является то, что в его реализации активнейшим образом используются многоэтажные C++ные шаблоны (о чем уже рассказывалось ранее: 1, 2).

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

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

easy_parser_router как альтернатива express-router-у

express-router и что с ним не так?

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

Мы в Cloudflare объявили о поддержке HTTP/3 в сентябре прошлого года, когда отмечали девятый день рождения. Наша задача всегда состояла в улучшении интернета. Сотрудничество в области стандартов — важная часть процесса, и нам повезло участвовать в разработке HTTP/3.

Хотя HTTP/3 ещё на стадии черновика, мы заметили большой интерес к новому протоколу со стороны наших пользователей (инфраструктура Cloudflare обслуживает более 10% сайтов интернета — прим. пер.). К настоящему моменту поддержку HTTP/3 активировали более 113 000 зон, и если у вас экспериментальный браузер, то теперь вы можете получить доступ к этим зонам по новому протоколу! Здорово, что его включили так много людей: работа по HTTP/3 большого количества реальных веб-сайтов означает, что можно тестировать больше разнообразных свойств со стороны браузеров.

Поделюсь с вами одной историей. Около двадцати лет назад я получил степень по физике, но занимался реверс-инжинирингом и криптоанализом. Наша компания AccessData работала в конце 90-х и начале 2000-х. Тогда правительство США постепенно снимало ограничения на экспорт криптографии, однако парольная защита в большинстве программ по-прежнему оставалась довольно бесполезной. Мы брали офисные программы, я проводил реверс-инжиниринг и выяснял алгоритм шифрования, а потом ломал криптозащиту.

Это был нескончаемый поток интересных, но не особенно сложных математических головоломок. За всё время я написал около сорока взломщиков паролей. Мы продавали их домашним пользователям, системным администраторам, местным и федеральным правоохранительным органам. Мне пришлось несколько раз съездить в федеральный центр подготовки сотрудников правоохранительных органов в Глинко, чтобы объяснить ребятам из Секретной службы, ФБР и АТФ основы криптографии и как использовать наши продукты.

Особенно ярко мне запомнились два проекта. Первым был Microsoft Word 97. До его появления файлы шифровались с помощью XOR байтов открытого текста и 16-байтовой строки, которая выводилась из пароля. Самыми распространёнными байтами в файле Word обычно были 0x00, 0xFF или 0x20 (пробел), поэтому мы просто выбирали самый распространённый символ в каждом столбце и проверяли 3¹⁶ вариантов. Восстановление ключа обычно происходило мгновенно, но чтобы людям не казалось, что они зря потратили деньги, мы вставили небольшую анимацию, похожую на голливудскую хакерскую сцену с множеством случайных символов, из которых постепенно проявляется правильный пароль.

Я работаю в Red Hat над GCC, GNU Compiler Collection. Для следующего основного релиза GCC, GCC 10, я реализовывал новую опцию -fanalyzer: проход статического анализа для выявления различных проблем во время компиляции, а не во время исполнения.

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

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

Как и в предыдущий раз, вдохновился я на этот пост благодаря очень популярному вопросу на Quora, а именно: Какой самый абсурдный код вы когда-либо видели? (Ориг. What is the most absurd code you've ever seen?)

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

Всем привет. На связи Владислав Родин. В настоящее время я являюсь руководителем курса «Архитектор высоких нагрузок» в OTUS, а также преподаю на курсах, посвященных архитектуре ПО.

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

---

Предисловие

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

Период времени, в течении которого происходили данные события, характеризовался отсутствием высоких нагрузок, Интернета и проблем с производительностью, для решения которых можно было обойтись лишь методами вертикального масштабирования. Впоследствии, в начале 2000-ых возник тренд на NoSQL базы данных, появилась аббревиатура BASE, которая фактически противопоставлялась классическому ACID (ACID — кислота, BASE — щелочь). Сейчас возникает обратный тренд на ACID. Даже NoSQL-ая MongoDB стала поддерживать ACID.

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

Авторы: Андрей Карпов, khandeliants Филипп Хандельянц.

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

Решил разобраться с новой возможностью С++20 — концептами.

Концепты (или концепции, как пишет русскоязычная Вики) — очень интересная и полезная фича, которой давно не хватало.

По сути это типизация для аргументов шаблонов.

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

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

Скажу честно, я немножко в шоке:) С++ и без того сложный язык, но тут хотя бы есть оправдание: так получилось. Метапрограммирование на шаблонах именно открыли, а не заложили при проектировании языка. А дальше, при разработке следующих версий языка, были вынуждены подстраиваться под это «открытие», так как в мире было написано очень много кода. Концепты же — принципиально новая возможность. И, как мне кажется, в их реализации уже присутствует некоторая непрозрачность. Возможно, это следствие необходимости учесть огромный объем унаследованных возможностей? Попробуем разобраться…

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

Привет, Хабр! Представляю вашему вниманию авторский перевод статьи Microservices – Combinatorial Explosion of Versions.

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

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

Наша цель — получить из лапши коллбэков:

    abActor.getA(ABActor::GetACallback([this](int a) {
        abActor.getB(ABActor::GetBCallback([a, this](int b) {
            abActor.saveAB(a - b, a + b, ABActor::SaveABCallback([this](){
                abActor.getA(ABActor::GetACallback([this](int a) {
                    abActor.getB(ABActor::GetBCallback([a, this](int b) {
                        std::cout << "Result " << a << " " << b << std::endl;
                    }));
                }));
            }));
        }));
    }));

Что-то вроде:

const int a = co_await actor.abActor.getAAsync();
const int b = co_await actor.abActor.getBAsync();
co_await actor.abActor.saveABAsync(a - b, a + b);
const int newA = co_await actor.abActor.getAAsync();
const int newB = co_await actor.abActor.getBAsync();
std::cout << "Result " << newA << " " << newB << std::endl;

Итак, приступим.

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

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

Хабр, это снова я, Алексей Рак (фото не мое). В прошлом году, помимо основной работы, мне довелось стать одним из авторов задач для кандидатов в Яндекс. Сегодня наша команда впервые за долгое время публикует на Хабре реальные задачи для разработчиков, которые устраиваются в компанию. Эти задачи использовались до февраля 2020 года при отборе на стажировку для бэкендеров. Решения проверял компьютер. Сейчас кандидатам достаются похожие задания.

Разборы и код сознательно спрятаны в спойлеры. Если вы готовитесь к собеседованиям в большие IT-компании, попробуйте решить одну или несколько задач, прежде чем смотреть разбор. Отправить решение для проверки можно на Codeforces — ответ придёт сразу же (ссылка на Codeforces и примечание). Код представлен на Python, C++ и Java. Важно: авторский «олимпиадный» код не предназначен для продакшена, он написан исходя из того, что система будет проверять его автоматически.

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

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

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

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

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

Как все начиналось

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

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