Александр Мещеряков freecoder_xx

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

Когда я увидел, что Лесли Лэмпорт (да-да, тот самый товарищ из учебников) приезжает в Россию и делает не доклад, а сессию вопросов-ответов, я немного насторожился. На всякий случай, Лесли — всемирно известный учёный, автор основополагающих работ в распределённых вычислениях, а ещё вы его можете знать по буквам La в слове LaTeX — «Lamport TeX». Вторым настораживающим фактором является его требование: каждый, кто придёт, должен (совершенно бесплатно) заранее прослушать пару его докладов, придумать по ним минимум один вопрос и только тогда уже приходить. Решил посмотреть, что там Лэмпорт вещает — и это великолепно! Это в точности та штука, волшебная ссылка-таблетка для лечения зомбятины. Предупреждаю: от текста может знатно подгореть у любителей сверхгибких методологий и нелюбителей тестировать написанное.

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

Лесли Лэмпорт — автор основополагающих работ в распределённых вычислениях, а ещё вы его можете знать по буквам La в слове LaTeX — «Lamport TeX». Это он впервые, ещё в 1979 году, ввёл понятие последовательной согласованности, а его статья «How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs» получила премию Дейкстры (точней, в 2000 году премия называлась по-старому: «PODC Influential Paper Award»). Про него есть статья в Википедии, где можно добыть ещё несколько интересных ссылок. Если вы в восторге от решения задач на happens-before или проблемы византийских генералов (BFT), то должны понимать, что за всем этим стоит Лэмпорт.

Эта хабрастатья — перевод доклада Лесли на Heidelberg Laureate Forum в 2018 году. В докладе пойдёт речь о формальных методах, применяемых в разработке сложных и критичных систем вроде космического зонда Rosetta или движков Amazon Web Services. Просмотр этого доклада является обязательным для посещения сессии вопросов и ответов, которую проведет Лесли на конференции Hydra — эта хабрастатья может сэкономить вам час времени на просмотр видео. На этом вступление закончено, мы передаём слово автору.

---

Когда-то давно Тони Хоар написал: «В каждой большой программе живет маленькая программа, которая пытается выбраться наружу». Я бы это перефразировал так: «В каждой большой программе живет алгоритм, который пытается выбраться наружу». Не знаю, правда, согласится ли с такой интерпретацией Тони.

Поисковая выдача на ListenNotes.com

Listen Notes — это поисковая система и база данных подкастов. Технология на самом деле очень скучная. Никакого ИИ, глубокого обучения или блокчейна. «Если вы должны объявлять о внедрении ИИ, то вы не используете Настоящий ИИ» :)

После прочтения этой статьи вы сможете повторить мой проект или легко сделать нечто подобное. Не придётся нанимать много разработчиков. Помните, когда Instagram привлёк $57,5 млн и отошёл к Facebook за $1 млрд, у них было всего 13 сотрудников — и это не только разработчики. Покупка Instagram произошла в начале 2012-го. Сейчас 2019 год, и сегодня как никогда просто создать что-то значимое с крошечной инженерной командой — даже из одного человека.

Это шестая статья из цикла «Теория категорий для программистов». Предыдущие статьи уже публиковались на Хабре:
0. Теория категорий для программистов: предисловие
1. Категория: суть композиции
2. Типы и функции
3. Категории, большие и малые
4. Категории Клейсли
5. Произведения и копроизведения

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

Рассмотрим подробнее место произведения и копроизведения типов в программировании.

Произведение типов

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

Строго говоря, произведение типов не коммутативно: нельзя подставить пару типа (Int, Bool) вместо (Bool, Int), хотя они и содержат одни и те же данные. Однако произведение коммутативно с точностью до изоморфизма, задаваемого функцией swap, которая обратна самой себе:

swap :: (a, b) -> (b, a)
swap (x, y) = (y, x)

Можно рассматривать такие пары как различные форматы хранения одной и той же информации, как big endian и little endian.

Хабр, привет. Перевел пост, который идёт строго (!) в закладки и передаётся коллегам. Он со списком блокнотов и библиотек ML и Data Science для разных отраслей промышленности. Все коды на Python, и размещены на GitHub. Они будут полезны как для расширения кругозора, так и для запуска своего интересного стартапа.



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

В данной статье мы разберем алгоритм консенсуса Паксос, обсудим зачем он нужен, почему работает, докажем его корректность и немного поговорим о проблемах практического применения. Во многом это вольный пересказ статьи Лесли Лампорта «Paxos Made Simple»

Зачем нужен распределенный консенсус и что это такое

Мы собрали книги, которые рекомендуют своим коллегам по цеху резиденты Hacker News. Здесь нет справочников или руководств по программированию, зато есть любопытные издания о криптографии и теоретической информатике, об основателях IT-компаний, есть и научная фантастика, написанная разработчиками и о разработчиках — как раз то, что можно взять в отпуск.

Недавно мы в Voximplant улучшали авторизацию в SDK. Посмотрев на результаты, я несколько опечалился, что вместо простого и понятного токена их стало две штуки: access token и refresh token. Которые мало того что надо регулярно обновлять, так еще документировать и объяснять в обучающих материалах. Помня, что в OAuth два токена нужны в основном из-за разных сервисов, на которых они используются (даже вопрос на stackoverflow есть), а у нас такой сервис один, я несколько офигел и пошел на второй этаж вытрясать души из разработчиков. Ответ получился неожиданным. Его нет на stackoverflow. Зато он есть под катом.

Должен признаться: я читаю ACM Magazine. Это делает меня «ботаником» даже по меркам программистов. Среди прочего, я узнал из этого журнала о «метаморфическом тестировании». Раньше я никогда о нём не слышал, как и все люди, которых я спрашивал. Но научная литература по этой теме на удивление объёмна: есть множество невероятно успешных примеров её применения в совершенно разных областях исследований. Так почему же мы не слышали о нём раньше? Существует только одна статья для людей вне научных кругов. Пусть теперь их будет две.

Краткая предыстория

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

def test_dist():
    p1 = (0, 3)
    p2 = (4, 0)
    assert dist(p1, p2) == 5

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

Это приводит нас к генеративному тестированию (generative testing): написанию тестов, покрывающих случайное множество в пространстве состояний. Самым популярным стилем генеративного тестирования является property based testing, или PBT. Мы находим «свойство» (property) функции, а затем генерируем входные значения и проверяем, соответствуют ли выходные значения этому свойству.

def test_dist():
    p1 = random_point()
    p2 = random_point()
    assert dist(p1, p2) >= 0

Преимущество PBT заключается в покрытии большего пространства. Его недостаток — утеря специфичности. Это уже не оракул-тест! Мы не знаем, каким должен быть ответ, и функция может быть ошибочна, но таким образом, что обладает тем же свойством. Здесь мы полагаемся на эвристики.

Почти пять тысяч лет человечество изучало свои изделия, используя только органы чувств: кузнецы прислушивались к звону дамасской стали, архитекторы Великих пирамид наощупь оценивали гладкость блоков. Исследовать рукотворные предметы, не разбирая или ломая их, мы не умели до XIX века, пока не началась история технологий неразрушающего контроля (Nondestrcutive Inspection, NDI).

Вот уже несколько лет в узких кругах обсуждается будущее транспорта. Говорят, что все виды транспорта и все способы передвижения людей должны объединиться в единую услугу «мобильности», простую и удобную в получении и оплате. Эта концепция называется Mobility-as-a-Service (MaaS) — слияние всех транспортных операторов, частных и «государственных», в единого виртуального поставщика. Понятно? Вряд ли. Попробуем разобраться, что же это за MaaS и какую роль технологии и, в частности, смартфоны будут иметь в будущей транспортной революции.

В "Черном Зеркале" была серия (S2E1), в которой создавали роботов, похожих на умерших людей, используя для обучения историю переписок в социальных сетях. Я хочу рассказать, как я попробовал сделать что-то подобное и что из этого получилось. Теории не будет, только практика.

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

• Предсказывать завершение фразы пользователя с учетом истории разговора
• Работать в режиме чат-бота
• Синтезировать логи разговоров целиком

Вот что получилось у меня

Бот предлагает завершение фразы

Бот предлагает завершение диалога

Бот общается с живым человеком

User: привет
Bot: привет
User: как ты?
Bot: собираюсь
User: баг пофиксил?
Bot: нет
User: почему?
Bot: да не получается
User: ты сегодня когда дома будешь?
Bot: не знаю пока
User: ты занят?
Bot: в магазин еду 

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

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

Один из моих читателей спросил меня:

Вернон, в своей книге «Implementing DDD» много говорит об архитектуре Порты и Адаптеры, как о более продвинутом уровне Слоистой Архитектуры. Хотелось бы услышать ваше мнение на этот счёт.

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

TL;DR Если применить принцип инверсии зависимостей к слоистой архитектуре, то в конечном счете получим Порты и Адаптеры.

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

— Эдсгер Вибе Дейкстра

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

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

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

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

Проиллюстрирую рядом воспоминаний. Вспомните траву под ветром в Сталкере и пробежку до 4-го энергоблока под переговоры военных; финальные диалоги с Элизбет из Биошока; многоэтажный остров Хэнша из Deus Ex; практически все первые впечатления от колоний Mass Effect; перестройку сознания в «Трассе-60»; концовку первой книги «Ведьмака». И так далее.



Возможно, почти каждый из нас был в сотнях миров Гипериона, наблюдал за дисфункцией реальности и шел к Нижнему Краю на «Внеполосном». Мы вместе ходили с Морриган в самоубийственную атаку на дракона; вместе спасали друзей в Far Cry; вылетали на террор сектоидов в Лиме и ехали вместе с Каином в такси в V:tM.

Это и многое другое рождает парадокс suspension of disbelief — приостановку неверия.

Экосистема Rust еще не до конца устоялась. В ней часто появляются новые библиотеки, которые заметно лучше предшественников, а ранее популярные фреймворки устаревают. Именно это произошло с веб-фреймворком Iron, который мы использовали при разработке Exonum.

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

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

В этой подборке: Rust 1.30, Rust 2018, конференция RustRush, Amethyst 0.9, сквотинг crates.io, сборщик мусора, споры про 2D графику, Non-lexical lifetimes, функциональный GUI.

Rust 1.30 и тестирование Rust2018

Вышел Rust 1.30 (обсуждение). Основные нововведения — частичная стабилизация процедурных макросов, импорт макросов через обычный use, улучшение системы модулей, "сырые" идентификаторы и поддержка no_std приложений (подробнее в хабропереводе).

Rust 1.31 будет первым выпуском редакции (edition) "Rust2018" (что за "редакции"?), в связи с чем всех желающих приглашают подключаться к тестированию бета версии 1.31 и cargo fix.

RustRush 2018: конференция 15-16 декабря в Москве

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

Обновился сайт (rustrush.ru) — опубликован почти полный список докладчиков и программа, начата продажа основной партии билетов.

Будут четыре участника проекта Rust Language: Стив Клабник, Эшли Уильямс, Паскаль Хертлиф, Катарина Фей. Из других звёзд локальных и не очень — Максим Лапшин с прошивкой IP-камеры, Костя Степанов и Пьер Кригер aka tomaka. Программа.

Моему сыну, как и многим мальчишкам, нравятся автомобили. Причём чем они больше и необычнее — тем больше нравятся. Когда мы идём по улице, а мимо проезжает эвакуатор или снегоуборочная машина, он неизменно дёргает меня за руку, указывает на заинтересовавший его объект и говорит: «Папа, б-р-р!». Говорит он так потому, что ему один год и вышеуказанные два слова составляют 40% его словарного запаса. Тем ни менее, в общем мысль понятна — обратить внимание на автомобиль. Давайте подумаем, каким образом ребёнок в возрасте 8-10 лет сказал бы своему сверстнику то же самое. Что-то вроде «Ух ты, смотри какая крутая тачка!», да? Мысль та же, но обратите внимание — уже шесть слов вместо двух. И, наконец, представьте, каким образом то же самое скажет человек лет в тридцать: «Эй, смотри, да это же Ferrari California 2008-го года выпуска с двигателем V8 мощностью в 454 лошадиных силы и 7-ми скоростной коробкой-автоматом! Она до сотни разгоняется за 3.9 секунды!». Да, здесь уже больше деталей, но, если вы не автомеханик или фанат Ferrari — они вам скорее всего не нужны и не важны. Основная же мысль — всё та же, что и в «Ух ты, смотри какая крутая тачка!» или «Папа, б-р-р!». Но выражена она уже в 30 слов.

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

Некоторые люди как-то неправильно поняли WebAssembly. Есть те, кто считает, что раз браузеры уже поддерживают выполнение WebAssembly (ещё с 2017 года), значит всё уже готово. Даже и близко ещё нет, готов лишь MVP (минимально жизнеспособный продукт). Я могу предположить откуда произрастает корень этого заблуждения: после релиза MVP его разработчики пообещали поддерживать обратную совместимость на уровне «любой написанный сейчас код будет работать и в будущем». Но это ведь не значит, что разработка WebAssembly закончена, совсем нет! Множество фич разрабатывается прямо сейчас и планируется к разработке в ближайшем будущем. И когда они будут реализованы — всё очень сильно изменится.

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

Давайте посмотрим на то, что у нас уже есть сейчас и что нам ещё предстоит открыть.
(Под катом много картинок, трафик)

В последней статье по WebAssembly я сделал следующее утверждение:

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

Многие люди выразили заинтересованность в этой теме, так что давайте рассмотрим её подробнее! В этой статье сравним WebAssembly с тремя технологиями: Flash, Java-апплеты и немножко с PNaCL. Кроме того, статья сосредоточиться на использовании в вебе, хотя раньше мы рассматривали варианты использования WebAssembly в офлайне. Но о таком сравнении поговорим позже. Наконец, эта статья похожа на поедание тапаса [испанская закуска из множества разных компонентов — прим. пер.], здесь куча маленьких разделов. Мне кажется, она слегка коротковата, но в то же время я пытаюсь вести блог, а если продолжать её расширять, то это займёт вечность, так что извините.