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

Порой диву даёшься, чего только люди не сделают «на блокчейне». С середины 2017 я занимаюсь аудитами безопасности смарт-контрактов и повидал всякого. В отдельную категорию я бы выделил «применения блокчейна», которые выглядят логичными и полезными, но в основе содержат проблему. И кочуют из стартапа в стартап вместе с ней. Здесь я рассмотрю ряд таких примеров, опишу проблемы и неработающие способы решения. После прочтения этого текста вы будете знать, с каких вопросов стоит начать, если вам как разработчику/клиенту/инвестору предложат такое «применение блокчейна».

Дисклеймеры

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

1. Supply Chain Management

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

Пятница – самый подходящий день для того, чтобы наконец-то свергнуть власть своего тимлида. Он никогда не решит уволиться по своей воле, потому что это не работа, а сказка. Его нужно сломать и не оставить ему другого выхода. Давайте разберемся, как сделать так, чтобы он пришел к этой мысли самостоятельно!

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

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

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

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

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

Что же делать?

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

Рациональные люди не принимают решения таким образом. Но именно так программисты часто решают использовать что-то вроде MapReduce.

Вот как комментировал этот выбор Joe Hellerstein своим студентам (на 54-той минуте):

Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»

Сколько этажей в вашем датацентре? Google сейчас строит четырёхэтажные, как вот этот в Оклахоме.

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

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

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

«Чтение и личный опыт формируют мировоззрение. И даже если вы не помните самый момент получения опыта или содержания книги, то их влияние на ваше представление о мире непременно остается в Вас. Ваш разум похож на скомпилированную программу без исходного кода — он работает, но не ясно как.»
— Пол Грэм, основатель Y Combinator, программист, инвестор, эссеист


«Взятие Константинополя крестоносцами» (Эжен Делакруа, 1840)

Оригинал — How You Know
December 2014

За перевод спасибо lxsmkv, за ценные уточнения — knagaev.

Я перечитывал Хроники Вилладруэна о Четвертом Крестовом Походе не менее двух раз, а может даже и трех. И если бы мне пришлось записать на бумаге, все то, что мне оттуда запомнилось, то сомневаюсь, что набралось бы и на одну страницу. А теперь, если перемножить это на семьсот, то результат сложится в неприятное, давящее ощущение, которое посещает меня всякий раз когда я гляжу на мои книжные полки. Какая мне польза от всех этих книг если я ничего из них не помню?

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

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

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

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

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

Одно из преимуществ детей в семье – это постоянная постановка вопроса «что бы я сказал собственным детям?» самому себе в тот момент, когда тебя просят дать совет. Мои дети пока маленькие, но я легко могу представить, что я бы сказал им о стартапах, будь они уже в колледже. Именно поэтому я собираюсь сказать это вам.