Сейчас то время года, когда студенты выбирают себе классы для обучающих навыков. Один из навыков, который будет поощряться, — обучение LaTeX. Другие могут придти к использованию LaTeX по другим причинам: кто-то хочет сверстать книгу; кто-то слышал, что LaTeX может иметь отношение к журналу Digital Humanities; ну и так далее. Я написал это эссе в качестве предварительного введения в LaTeX. Оно не научит вас использовать редактор (я не имею квалификации для этого!), но я попытаюсь популярно объяснить тем, кто ещё не использует LaTeX, для чего именно он нужен. Это поможет им понять, стоит ли LaTeX усилий на его изучение (не говоря уже о том, чтобы просто заставить его работать). Почему такое большое эссе? Потому что многие из евангелистов превратили LaTeX в фетиш и распространяют дезинформацию о его истинных достоинствах. Хочу прояснить ситуацию.

1. Что такое LaTeX?

По словам официального сайта, LaTeX — это «высококачественная система набора и вёрстки» и «стандарт де-факто для обмена и публикации научных документов». С этим никто не спорит.

Когда люди спрашивают у меня карьерного совета в IT, я считаю полезным изложить три пути, с которыми сталкивался в своей карьере: основатель, руководитель и наёмный работник. Оставляю за скобками инвестора, потому что этим лучше заниматься после успешной (или неудачной) попытки пойти по одному из трёх вышеперечисленных путей.

Ниже я обрисую преимущества/недостатки и полезные стратегии для каждой роли.

Я написал эту статью, потому что на удивление часто приходится сталкиваться с людьми, которые при обсуждении карьеры думают только об одном пути, игнорируя другие варианты. Когда другие дают им советы, то часто рекомендуют следовать дальше по этому выбранному пути (как партнёр Y Combinator и бывший основатель я тоже очень виноват в этом).

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

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

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

Назовём нашего конкурента вебу NewWeb (э, брендингом можно заняться потом). Для начала нужно понять, почему веб изначально стал успешным. Веб обошёл другие технологии создания приложений с лучшими инструментами для разработки GUI, так что у него явно есть какие-то качества, которые перевешивают недостатки. Если мы не будем соответствовать этим качествам, мы обречены.

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

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


Это ты, хакер фронтенда

История о чувстве зрения, восприятии кадров и частоты обновления, размытости движущегося объекта и телевизионных экранах.
(также см. перевод статьи того же автора «Иллюзия скорости» — прим. пер.)

Введение

Вы могли слышать термин кадры в секунду (FPS), и что 60 FPS — действительно хороший ориентир для любой анимации. Но большинство консольных игр идут на 30 FPS, а кинофильмы обычно записывают на 24 FPS, так зачем же нам стремиться к 60 FPS?

Кадры… в секунду?

Ранние времена кинопроизводства

Съёмки голливудского фильма 1950 года «Юлий Цезарь» с Чарлтоном Хестоном

Когда первые кинематографисты начали снимать кино, многие открытия делались не научным методом, а путём проб и ошибок. Первые камеры и проекторы управлялись вручную, а плёнка была очень дорогой — настолько дорогой, что при съёмке старались использовать наименьшую возможную частоту кадров, лишь бы сэкономить плёнку. Этот порог обычно находился между 16 и 24 FPS.

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

Настоящее время и воспринимаемое время

Вы спокойно блуждаете по директории $HOME, думая о своих делах.

$ whoami
> user

$ pwd
> /home/user

Но что-то вас беспокоит. Это как маленький камушек (little rock), попавший в ботинок. Вы снимаете обувь, чтобы посмотреть, в чём дело.

$ ls -lah ./left-shoe
---------- 1 root root 4 May 30 13:20 little-rock

Странно. Он здесь, но как будто не принадлежит вам. Его оставил root, Рок Теймер, и только он решает его судьбу.

TL;DR: К концу этого эссе я надеюсь убедить вас в следующих фактах. Во-первых, что современные десктопные операционные системы никуда не годятся. Они раздутые, тормознутые и напичканы легаси-хламом, а кое-как работают только благодаря закону Мура. Во-вторых, что инновации в десктопных ОС прекратились около 15 лет назад, а основные игроки вряд ли собираются много вкладывать в них снова. И наконец, я надеюсь убедить вас, что мы можем и должны начать с нуля, усвоив уроки прошлого.

«Современные» десктопные ОС раздуты

Возьмём Raspberry Pi. За 35 долларов я могу купить отличный компьютер с четырьмя процессорными ядрами, каждое на частоте более гигагерца. У него также есть 3D-ускоритель, гагабайт оперативки, встроенные WiFi с Bluetooth и Ethernet. За 35 баксов! И всё-таки для многих задач, которые я хочу на нём запустить, Raspberry Pi ничем не лучше компьютера на 66 мегагерц, который был у меня в колледже.

Вы видели результаты бенчмарков MJIT? Они удивительные, правда? MJIT буквально выносит все остальные реализации без вариантов. Где он был все эти годы? Всё, теперь с гонкой закончено?

Однако вы можете понять из заголовка, что не всё так просто. Но прежде чем разобрать проблемы этих конкретных бенчмарков (конечно, вы можете пролистать вниз к симпатичным диаграммам), нужно рассмотреть важные базовые основы сравнительного анализа.

MJIT? TruffleRuby? Что это всё такое?

MJIT — это ответвление Ruby на Github от Владимира Макарова, разработчика GCC, где реализована динамическая JIT-компиляция (Just In Time Compilation) на самом популярном интерпретаторе Ruby — CRuby. Это отнюдь не окончательная версия, наоборот, проект на ранней стадии разработки. Многообещающие результаты бенчмарков были опубликованы 15 июня 2017 года, и это основной предмет обсуждения в данной статье.

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

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

В течение многих лет мы обновляли фронтенд Facebook трижды в день, используя простую стратегию веток master и release. Инженеры избирательно выбирали из ветви master изменения в коде, которые прошли ряд автоматизированных тестов, для включения в ветвь release, откуда происходили ежедневные обновления. В целом, таким способом выбиралось от 500 до 700 изменений в день. Раз в неделю мы отрезали новую ветвь release и собирали изменения, которые не отобрались в течение недели.

Это приблизительная расшифровка лекции о предсказании переходов (предсказании ветвлений) на localhost, новом цикле лекций, организованном RC. Выступление состоялось 22 августа 2017 года в Two Sigma Ventures.

Кто из вас использует ветвления в своём коде? Можете поднять руку, если применяете операторы if или сопоставление с образцом?

Большинство присутствующих в аудитории поднимают руки

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

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

На конференциях часто на стендах раздают подарки. Обычно нужно решить какую-то задачку.

Невинная головоломка

Некоторые из задач предусматривают решение головоломки с кодом, вроде такой:

Каким будет результат выполнения следующего кода:

public class Sum {

    public static void main(String[] args) {
        System.out.println(0123 + 3210);
    }
}

1. 3293
2. 3333
3. Этот код не компилируется
4. Этот код приводит к ошибке IllegalArgumentException
5. Ничего из вышеперечисленного

Моя обычная реакция — или немедленно покинуть стенд, или, если время позволяет, набрать код на ноутбуке, чтобы посмотреть результат (или поискать в Google). Вы можете упрекнуть меня в лености, но я предпочитаю представлять себя экспертом по тайм-менеджменту.

«Чего-то здесь не хватает». Спорим, такая мысль первой придёт в вашу голову, если увидите моё рабочее место в офисе. Здесь нет монитора и мыши. Есть только парень, который молотит по клавиатуре, глядя словно в пустоту.



Это всего лишь я, и мои коллеги гарантируют вам, что я обычно не опасен. Я программист в офисе компании Vincit в Тампере (Финляндия). И ещё я слепой. В этой статье хочу немного рассказать, как я работаю.

Некоторое время назад на отличной конференции maintainerati я пообщался с несколькими друзьями-мейнтейнерами о масштабировании по-настоящему больших проектов open source и о том, как GitHub подталкивает проекты к определённому способу масштабирования. У ядра Linux абсолютно иная модель, которую мейнтейнеры-пользователи GitHub не понимают. Думаю, стоит объяснить, почему и как она работает и чем отличается.

Ещё одной причиной для написания этого текста стала дискуссия на HN по поводу моего выступления «Мейнтейнеры не масштабируются», где самый популярный комментарий сводился к вопросу «Почему эти динозавры не используют современные средства разработки?». Несколько известных разработчиков ядра энергично защищали списки рассылки и предложение патчей через механизм, похожий на пулл-реквесты GitHub, Но по крайней мере несколько разработчиков графической подсистемы хотели бы использовать более современный инструментарий, который гораздо легче автоматизировать скриптами. Проблема в том, что GitHub не поддерживает тот способ, которым ядро Linux масштабируется на огромное число контрибуторов, и поэтому мы просто не можем перейти на него, даже для нескольких подсистем. И дело не в хостинге данных на Git, эта часть явно в порядке, а дело в том, как на GitHub работают пулл-реквесты, обсуждение багов и форки.

Замена маршрутизатора: Производитель A: 10% сломано Производитель B: 10% сломано P(одновременно A и B сломаны): 10% × 10% = 1% Замена маршрутизатора (или прошивки) почти всегда решает проблему.

Добавление усилителя Wi-Fi: Маршрутизатор A: 90% работает Маршрутизатор B: 90% работает P(одновременно A и B работают): 90% × 90% = 81% Дополнительный маршрутизатор почти всегда ухудшает ситуацию.

Все беспроводные сети, будь то LTE или mesh-сети, рано или поздно падают, но я могу поставить на то, что ваша сеть Wi-Fi менее надёжная, чем телефонное соединение LTE. На конференции Battlemesh v10 мы все сидели в комнате с десятками экспериментальных неправильно сконфигурированных маршрутизаторов Wi-Fi с открытыми сетями, которые могут дать выход в Интернет, а могут и не дать. Из-за чего сеть бывает надёжной или ненадёжной?

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

С самого начала Discord активно использовал Elixir. Виртуальная машина Erlang стала идеальным кандидатом для создания высокопараллельной системы реального времени, которую мы собирались создать. Первоначальный прототип Discord был разработан на Elixir; сейчас он лежит в основе нашей инфраструктуры. Задача и предназначение Elixir простые: доступ ко всей мощи Erlang VM через гораздо более современный и дружественный язык и набор инструментов.

Прошло два года. Сейчас у нас пять миллионов одновременных пользователей, а через систему проходят миллионы событий в секунду. Хотя мы абсолютно не сожалеем о выборе архитектуры, пришлось проделать массу исследований и экспериментов, чтобы добиться такого результата. Elixir — это новая экосистема, а экосистеме Erlang не хватает информации о её использовании в продакшне (хотя Erlang in Anger — это нечто). По итогу всего пути, пытаясь приспособить Elixir для работы в Discord, мы извлекли некоторые уроки и создали ряд библиотек.

Разработка программного обеспечения как будто в худшую сторону отличается от других дисциплин информатики.

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

А теперь я работаю с разработкой ПО, и это невыносимо скользкая тема. Ни одна концепция точно не определена. Результаты оцениваются с характеристиками «обычно» или «в целом». Сегодняшние исследования могут или не могут помочь завтрашней работе. Новые подходы часто опровергают предыдущие методы, а сами ярко горят недолгое время, а потом выходят из моды, когда всплывают их ограничения. Мы верили в структурное программирование. Затем начали верить в языки четвёртого поколения, потом в объектно-ориентированные методы, потом в экстремальное программирование, а теперь, может быть, в open source.

Об авторе: Тэмми Бутов — технический руководитель инфраструктуры для разработчиков в Dropbox. Это управление потоками кода — полный цикл использования Go в Dropbox, от программирования до выпуска. Она выступала на конференции GopherCon 2017 на тему того, как разработчики Dropbox создают и поддерживают работу крупномасштабных сервисов на Go.

Как Dropbox пришёл к использованию Go

Тэмми цитирует статью Роба Пайка «Go в компании Google: языковой дизайн в службе разработки ПО» от 2012 года, поскольку она в целом хорошо передаёт, почему Go хорошо работает и в Dropbox:

«Go — эффективный, масштабируемый и производительный язык. Некоторые программисты получают удовольствие от работы с ним; другие находят его прозаическим, даже скучным. В этой статье мы расскажем, почему все эти позиции не противоречат друг другу. Go спроектирован для решения проблем, возникающих в софтверной разработке в Google, что привело к созданию языка, который не является прорывным с исследовательской точки зрения, тем не менее это прекрасный инструмент для разработки крупных софтверных проектов». — Роб Пайк, 2012

Масштаб Dropbox впечатляет:

• Более 500 млн пользователей
• 200 000 бизнес-пользователей
• 500 петабайт пользовательских данных
• Многоэкзабайтная система хранения Go

Эта статья представляет собой адаптацию разделов 2 и 3 из главы 9 моей книги «Глубинное обучение с Python» (Manning Publications).

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

---

Ограничения глубинного обучения

Глубинное обучение: геометрический вид

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

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

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

Вот тот сниппет:



Что бы вы ожидали от него?

Здесь используется цикл for in, который проходит через перечислимые свойства объекта. Поскольку указано только свойство A, можно предположить, что будет показано сообщение с буквой А. Ну… я ошибался. :D