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

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


Sjoerd Knibbeler создал это изображение специально для The Correspondent; остальные изображения в этой статье входят в серию 'Current Studies' (2013-2016), подробнее о которой можно узнать в конце статьи.

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



UPD. Перевел этот текст на английский.

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

Почему я так делаю? Потому что со временем я заметил, что иначе я мешаю остальным

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

Собственно, что делать руководителю и команде, достаточно хорошо написано в «Сгоревшие сотрудники: есть ли выход» (uyga) и «Гори, гори ясно, пока не погасло» (Lisichkina). Краткий спойлер от меня: достаточно быть внимательным руководителем и заботиться о сотрудниках, остальное — разные по степени эффективности инструменты.

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


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

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

Критика C — классический для нашей индустрии эпистолярный жанр. Она звучит то громче, то тише, но в последнее время буквально оглушает. Пример — перевод статьи Дэвида Чизнэлла «C — не низкоуровневый язык», опубликованный в нашем блоге некоторое время назад. Про C можно говорить разное, в дизайне языка действительно много неприятных ошибок, но отказывать C в «низкоуровневости» — это уже слишком!

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

Алан Кей — это магистр Йода для ИТишников. Он стоял у истоков создания первого персонального компьютера (Xerox Alto), языка SmallTalk и концепции «объектно-ориентированного программирования». Он уже много высказывался о своем взгляде на образование в сфере Computer Science и советовал книги тем, кто хочет углубить свои познания:

• Алан Кей: как бы я преподавал Computer Science 101
• Алан Кей: «Какие книги Вы бы посоветовали прочесть тому, кто учится на Computer Science»
• Алан Кей (и коллективный интеллект Хабра): какие книги формируют мышление тру инженера
• Алан Кей и Марвин Мински: Computer Science уже имеет «грамматику». Нужна «литература»

Недавно на Quora опять подняли эту тему и обсуждение вышло на первое место на Hacker News. Предлагаю вашему вниманию «новый» список суперстарых и фундаментальных книг по программированию и мышлению программиста от Алана Кея.

Lisp 1.5 Programmers Manual

by John McCarthy, 1962



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

ещё восемь раритетов:

14 мая, когда Трамп готовился спустить всех собак на Huawei, я мирно сидел в Шеньжене на Huawei STW 2019 — большой конференции на 1000 участников — в программе которой были доклады Филипа Вонга, вице-президента по исследованиям TSMC по перспективам не-фон-неймановских вычислительных архитектур, и Хенга Ляо, Huawei Fellow, Chief Scientist Huawei 2012 Lab, на тему разработки новой архитектуры тензорных процессоров и нейропроцессоров. TSMC, если знаете, делает нейроускорители для Apple и Huawei по технологии 7 nm (которой мало кто владеет), а Huawei по нейропроцессорам готова составить серьезную конкуренцию Google и NVIDIA.

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

Только в прошлом году в тему было вложено больше 3 миллиардов долларов. Google уже давно объявил нейросети стратегическим направлением, активно строит их аппаратную и программную поддержку. NVIDIA, почувствовав, что трон зашатался, вкладывает фантастические усилия в библиотеки ускорения нейросетей и новое железо. Intel в 2016 году потратил 0,8 миллиарда на покупку двух компаний, занимающихся аппаратным ускорением нейросетей. И это при том, что основные покупки еще не начались, а количество игроков перевалило за полсотни и быстро растет.


TPU, VPU, IPU, DPU, NPU, RPU, NNP — что все это означает и кто победит? Попробуем разобраться. Кому интересно — велкам под кат!

Намедни работая над одной ошибкой в одном опенсорсном проекте, увидел как коллега (тоже работающий параллельно над той же проблемой) залил такой вот коммит [31a078bec7]:

   	/*
-	 * Select the list item based on the index. Negative operand means
-	 * end-based indexing (-2, ...), and -1 means out of range.
+	 * Decode end-offset index values.
   	 */
-	if (opnd < -1) {
-	    index = opnd+1 + objc;
-	} else {
-	    index = opnd;
-	}
+	index = opnd + (opnd <= TCL_INDEX_END)*(objc - 1 - TCL_INDEX_END);
   	pcAdjustment = 5;

Изменение само по себе правильное (теперь TCL_INDEX_END есть константное определение (-2)).

И грубо говоря в уме это разворачивается в следующее (все переменные int):

index = opnd + cmp(opnd, (-2))==>(0 | 1) * (objc - 1 - (-2));

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

Во первых, это изменение касается самой «главной» функции в этом проекте (TEBCresume), ибо она ответственна за исполнение байт-кода (JIT скомпилированных инструкций языка TCL). По этой причине эта функция еще и самая большая (порядка 6 тысяч строк + примитивы и макросы) и одна из самых сложных в кодовой базе проекта, с множественными `goto`, головоломными макросами для работы со «стеком» исполнения, свёртка/развертка NRE (nonrecursive evaluation) и т.д. и т.п.

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

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

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

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

Отобраны лучшие 10% из примерно 200 прочитанных книг о маркетинге, продажах и всем связанном — самые «пробивные» вещи, которые помогут вам не тратить время на всякий шлак, а сразу начать с главного.

В конце — суммация книг, которые хабровчане рекомендуют в комментариях помимо основного списка.

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

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

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

У нас не очень простое собеседование. Нужно пройти 3 шага:

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

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

Выигрыш невозможен. Вы только решаете, насколько быстро проиграть


Какой следующий ход?

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

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

Здравствуйте! Представляю вам любительский перевод руководства реализации своего языка программирования на JavaScript — PL Tutorial.

От переводчика

Мы создадим свой язык программирования — λзык (в оригинале — λanguage). В процессе создания мы будем использовать достаточно много интересных техник, таких как рекурсивный спуск, стиль передачи управления, базовые техники оптимизации. Будет создано две версии интерпретатора — обычный и CPS-интерпретатор, транс-компилятор в JavaScript.

Автор оригинала — Mihai Bazon, автор известной библиотеки UglifyJS (инструмент для минимизации и форматирования JS-кода).

Вчера Mozilla довела до финальной версии один из своих экспериментальных проектов Firefox Send: простой и безопасный сервис обмена зашифрованными файлами. Поддерживаются файлы до 1 ГБ (до 2,5 ГБ после авторизации в Firefox Account).

Сервис выглядит просто, но под ним работает движок, который обеспечивает настоящее end-to-end шифрование, то есть вы никуда не передаёте файлы в открытом виде — они шифруются конкретно на вашем ПК, а расшифровываются на компьютере получателя (JS в браузере). Как это работает, можно посмотреть на примере Firefox Sync, здесь реализована похожая архитектура.

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

Менеджер памяти

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

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

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

Не будем лукавить: JavaScript никогда не был идеальным языком программирования. Одним из слабых мест в JS была модульность, а точнее её отсутствие. Действительно, зачем в скриптовом языке, который анимирует падающие на странице снежинки и валидирует форму, заботиться об изоляции кода и зависимостях? Ведь всё может прекрасно жить и общаться между собой в одной глобальной области — window.

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

Эта статья появилась в результате общения с участниками TC39 и разработчиками фреймворков, а также чтения исходных кодов, блогов и книг. Мы рассмотрим следующие подходы/форматы: Namespace, Module, Detached Dependency Definitions, Sandbox, Dependency Injection, CommonJS, AMD, UMD, Labeled Modules, YModules и ES2015 Modules. Кроме того, мы восстановим исторический контекст их появления и развития.

Мы больше не контролируем свои домашние каталоги.

В моём собственном 25 обычных файлов и 144 скрытых. В дотфайлах хранятся данные, которые не принадлежат мне: они принадлежат программистам, чьи программы решили захватить моё пространство, предназначенное для хранения моих личных файлов.

Я не могу убрать эти файлы в другое место. Если я попытаюсь их удалить, они появятся снова. Всё, что я могу сделать — это сидеть и знать, что в темноте, за кулисами, они есть. Ожидание в тишине. Некоторые из этих программистов решили дополнительно разместить здесь несколько обычных файлов и каталогов. Они хорошо видны каждый раз, когда я выполняю ls. Понятия не имею, как в мою личную папку попали каталог node_modules, файлы package-lock.json, yarn.lock (я никогда сознательно даже не ставил yarn!), какие-то два странных лог-файла от какой-то Java-программы, явно использующей СУБД H2, и папка Desktop. Последнюю создал Steam, что довольно неудачно, поскольку на моей машине просто нет рабочего стола или какого-то десктопа. Боюсь того дня, когда услышу громкий стук в дверь — и один из этих программистов ворвётся и сообщит, что собирается хранить часть своей мебели посреди моей гостиной, если я не возражаю.

Этот пост — список забавных и хитрых примеров на JavaScript. Это отличный язык. У него простой синтаксис, большая экосистема и, что гораздо важнее, огромное сообщество.

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

Привычный хаос в названиях коммитов. Знакомая картина?

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

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

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

Типичные возражения студентов, когда им говорят об изучении C:

• «Кто-то его ещё использует?»
  
• «Это глупо»
  
• «Почему мы изучаем C?»
  
• «Мы должны учить что-то лучшее, например, C++» (смех в зале)

Здесь будет длиннющая стена текста, с типа случайными мыслями. Основные идеи:

1. В C++ очень важно время компиляции,
2. Производительность сборки без оптимизаций тоже важна,
3. Когнитивная нагрузка ещё важней. Вот по этому пункту особо распространяться не буду, но если язык программирования заставляет меня чувствовать себя тупым, вряд ли я его буду использовать или тем более — любить. C++ делает это со мной постоянно.

Блогпост «Standard Ranges» Эрика Ниблера, посвященный ренжам в C++20, недавно облетел всю твиттерную вселенную, сопровождаясь кучей не очень лестных комментариев (это ещё мягко сказано!) о состоянии современного C++.

Даже я внёс свою лепту (ссылка):

Этот пример пифагоровых троек на ренжах C++20, по моему, выглядит чудовищно. И да, я понимаю, что ренжи могут быть полезны, проекции могут быть полезны и так далее. Тем не менее, пример жуткий. Зачем кому-то может понадобиться такое?

Давайте подробно разберём всё это под катом.