Вот цитата из Линуса Торвальдса за 2006 год:

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

Что очень похоже на «правило представления» Эрика Реймонда от 2003 года:

Сверните знания в данные, чтобы логика программы стала глупой и надёжной.

Здесь просто резюме идей, подобных мысли Роба Пайка от 1989 года:

Доминируют данные. Если вы выбрали правильные структуры данных и всё хорошо организовали, то алгоритмы почти всегда будут самоочевидными. Структуры данных, а не алгоритмы, играют центральную роль в программировании.

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

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

Если дефолтный порядок не устраивает, то разработчики прибегают к свойству z-index: оно даёт контроль над виртуальной осью z (глубиной), которая концептуально проходит «сквозь» страницу. Таким образом, элемент с более высоким z-index отображается «ближе» к пользователю, то есть рисуется поверх элементов с более низкими индексами.

«Agile мёртв». Люди всё время так говорят. Но обязательно добавляют: «Мы просто шутим». Они типа имели в виду, что это у тебя такие неправильные и глупые практики, что это для тебя Agile мёртв. Но «настоящий» Agile не мёртв. Просто все его делают неправильно. Так что я понял: настоящий Agile — это, знаете ли, Agile в теории. Даже я его внедрял. И знаете что? Мне надоело.

Недавно я видел в статьях ту же самую старую защиту: «Но-но-но, проблема в водопаде, скраме и неправильной реализации Agile, несоблюдении Манифеста… бла-бла-бла». Тогда Боб Маршалл сказал мне правду. Он сказал: «Заткнись, Чарльз. Манифест Agile — это кувшин, который мы наполняем». Он сделал несколько замечаний, с которыми мне пришлось согласиться. Я задумался. Результатом стала эта статья.

В статье показано, как создать нерекурсивную zip-бомбу, которая обеспечивает высокую степень сжатия путём перекрытия файлов внутри zip-контейнера. «Нерекурсивная» означает, что она не зависит от рекурсивной распаковки декомпрессорами файлов, вложенных в zip-архивы: здесь всего один раунд. Выходной размер увеличивается квадратично от входного, достигая степени сжатия более 28 миллионов (10 МБ → 281 ТБ) в пределах формата zip. Ещё большее расширение возможно с помощью 64-разрядных расширений. Конструкция использует только наиболее распространённый алгоритм сжатия DEFLATE и совместима с большинством парсеров zip.

• zbsm.zip 42 kB → 5.5 GB
  
• zblg.zip 10 MB → 281 TB
  
• zbxl.zip 46 MB → 4.5 PB (Zip64, менее совместима с парсерами)

Исходный код:

git clone https://www.bamsoftware.com/git/zipbomb.git

zipbomb-20190702.zip

Данные и исходники иллюстраций:

git clone https://www.bamsoftware.com/git/zipbomb-paper.git

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

В статье я покажу интересное реальное применение динамического программирования — задача вырезания швов (seam carving). Задача и методика подробно описаны в работе Авидана и Шамира «Вырезание швов для изменения размеров изображения с учётом контента» (статья в свободном доступе).

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

Три недели назад я получил очень лестное письмо из Кембриджского университета с предложением выступить судьёй на премии Адама Смита по экономике:

Дорогой Роберт,

Меня зовут Грегори Харрис. Я один из Организаторов премии Адама Смита.

Каждый год мы обновляем команду независимых специалистов для оценки качества конкурирующих проектов: http://people.ds.cam.ac.uk/grh37/awards/Adam_Smith_Prize

Наши коллеги рекомендовали вас как опытного специалиста в этой области.

Нам нужна ваша помощь в оценке нескольких проектов для премии Адама Смита.

Ждём вашего ответа.

С наилучшими пожеланиями, Грегори Харрис

Я бы не назвал себя «экспертом» по экономике, но запрос университета не казался чем-то невероятным. У меня есть подписка на The Economist, и я понимаю — очень грубо — как и почему центральные банки устанавливают процентные ставки. Я читал «Капитал в двадцать первом веке» и в основном понял суть первой половины. Несколько постов в моём блоге помечены тегом «экономика». Возможно, я могу внести некий вклад в новую дисциплину вычислительной экономики. В целом казалось вполне вероятным, что организаторы премии Адама Смита захотят услышать мою точку зрения. Я предполагал много неоплачиваемой работы, но всё равно предложение было очень приятным.

Статья входит в серию советов для начинающих программистов


Пример главной страницы Hacker News

Удивительно большое количество ошибок начинающие программисты делают под влиянием технических СМИ.

Учась в школе или колледже, вы основную часть информации о программировании получаете из технических СМИ, таких как Hacker News, встреч, конференций, курсов Free Code Camp и Hacker Noon. Тогда ваш арсенал инструментов с избытком наполняется технологиями, которые там бурно обсуждаются — скажем, микросервисы, некий фреймворк фронтенда или блокчейн.

Самая распространённая ошибка — рассматривать эти источники как зеркало индустрии. На самом деле они больше похожи на базар.

Ключевые моменты

• Многие организации устали от Agile
  
• Часть проблемы — в существовании большой коммерческой отрасли Agile
  
• Нужно вернуться к основам: простоте Манифеста и 12 принципов
  
• Примеры базовых и простых фреймворков: Heart of Agile и Modern Agile
  
• Многие уроки можно извлечь из таких гуманитарных наук, как позитивная психология, направленное самосовершенствование и решение-ориентированная терапия

«Agile agile Agile agile agile agile Agile agile».

Мантра? Не совсем, хотя это может вызвать изменённое состояние сознания.

«Ответ на главный вопрос жизни, вселенной и всего такого?» (Дуглас Адамс, «Путеводитель для путешествующих автостопом по галактике»). Может быть, смотря кого спросить.

Это омонимы. Слова, которые выглядят и звучат одинаково, но имеют разные значения. Как это грамматически правильное предложение, состоящее из трёх совершенно разных слов: «Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo», Дмитрий Боргманн, «За пределами языка: путешествие слова и мысли» (фразу можно перевести так: «Буффальские бизоны, которых пугают буффальские бизоны, пугают других буффальских бизонов» — прим. пер.).

Риск чрезмерной омонимизации заключается в том, что слова начинают означать всё и вся, в то же время не означая ничего конкретного. Это психологический феномен, известный как «семантическое насыщение», форма ментальной усталости.

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

Без try...catch трудно проверять результаты каждого вызова функции для неожиданных значений. Это полезная конструкция. Но у неё есть определённые проблемы. И это не единственный способ обрабатывать ошибки. В статье мы рассмотрим использование монады Either в качестве альтернативы try...catch.

Прежде чем продолжить, отмечу пару моментов. Статья предполагает, что вы уже знаете о композиции функций и каррировании. И предупреждение. Если вы раньше не сталкивались с монадами, они могут показаться действительно… странными. Работа с такими инструментами требует изменить мышление. Поначалу это бывает тяжело.

Не волнуйтесь, если сразу запутались. У всех так. В конце статьи я перечислил несколько ссылок, которые могут помочь. Не сдавайтесь. Эти штуки опьяняют, как только проникают в мозг.

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

В тестах A/B мы попытались замедлять выдачу страниц с шагом 100 миллисекунд и обнаружили, что даже очень небольшие задержки приводят к существенному падению доходов. — Грег Линден, Amazon.com

По опыту, низкая производительность проявляется одним из двух способов:

• Операции, которые хорошо выполняются в небольших масштабах, становятся нежизнеспособными с ростом числа пользователей. Обычно это операции O(N) или O(N²). Когда база пользователей мала, всё работает отлично. Продукт спешат вывести на рынок. По мере роста базы возникает всё больше неожиданных патологических ситуаций — и сервис останавливается.
  
• Много отдельных источников неоптимальной работы, «смерть от тысячи порезов».

В 2013 году я начал понимать, что утечки приватных данных становятся повсеместными. Действительно, такие случаи участились. И возросло влияние этих утечек на их жертв, включая меня. Всё чаще я писал в блоге на эту тему, которая казалась увлекательным сегментом индустрии инфобеза: как повторное использование паролей на Gawker и Twitter привело к массовому черничному спаму в твиттере, и о том, что пароли юзеров Sony Pictures оказались действительно настолько плохими, насколько можно было ожидать от этих людей, но чёрт побери, до сих пор шокирует видеть свой пароль в этой утёкшей базе. При этом 59% паролей из базы Sony совпадали с паролями от почтовых ящиков Yahoo.

Примерно в то время произошла утечка данных Adobe, и это заставило меня действительно заинтересоваться данным сегментом отрасли, не в последнюю очередь потому, что я был в той базе. Дважды. Самое главное, что она содержала 153 млн других людей. Это была исключительно массовая утечка, даже по сегодняшним стандартам. Всё это вместе — частота утечек, мой анализ баз и масштаб Adobe — заставили меня задуматься: интересно, сколько людей знают? Понимают ли они, что их данные ушли в открытый доступ? Понимают ли, сколько раз? И, возможно, самое главное: изменили ли они свой пароль (да, почти всегда единственный) в других службах, которые используют? И так родился проект Have I Been Pwned (HIBP): поиск своих паролей в множестве утёкших баз.

В воскресенье я как обычно бездельничал, просматривая Reddit. Прокручивая щенячьи забавы и плохой юмор программистов, моё внимание привлёк один конкретный пост. Речь шла о баге в calc.exe.


Неверный результат вычисления диапазона дат в Калькуляторе Windows

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

В последнем семестре университета я выбрал курс компиляторов CS444. Там каждая группа из 1-3 человек должна была написать компилятор из существенного подмножества Java в x86. Язык на выбор группы. Это была редкая возможность сравнить реализации больших программ одинаковой функциональности, написанных очень компетентными программистами на разных языках, и сравнить разницу в дизайне и выборе языка. Такое сравнение породило массу интересных мыслей. Редко можно встретить такое контролируемое сравнение языков. Оно не идеально, но намного лучше, чем большинство субъективных историй, на которых основано мнение людей о языках программирования.

Мы сделали наш компилятор на Rust, и сначала я сравнил его с проектом команды на Haskell. Я ожидал, что их программа будет намного короче, но она оказалась того же размера или больше. То же самое для OCaml. Затем сравнил с компилятором на C++, и там вполне ожидаемо компилятор был примерно на 30% больше, в основном, из-за заголовков, отсутствия типов sum и сопоставлений с образцом. Следующее сравнение было с моей подругой, которая сделала компилятор самостоятельно на Python и использовала менее половины кода, по сравнению с нами, из-за мощности метапрограммирования и динамических типов. У другого товарища программа на Scala тоже была меньше нашей. Больше всего меня удивило сравнение с другой командой, которая тоже использовала Rust, но у них оказалось в три раза больше кода из-за разных дизайнерских решений. В конце концов, самая большая разница в количестве кода оказалась в пределах одного языка!

Заголовок этого поста — прямая отсылка к диаграмме «Времена задержек, которые должен знать каждый программист». В настоящее время есть несколько версий этой диаграммы, и трудно установить оригинального автора. Некоторые говорят, что это Джефф Дин.

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

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

Скоро наступит десятый год, как я профессионально занимаюсь программированием. Десять лет! И кроме формальной работы, почти две трети своей жизни я что-то создавала в интернете. С трудом вспоминаю годы, когда я не знала HTML: даже странно, если подумать об этом. Некоторые дети учатся музыке или балету, а я вместо этого создавала волшебные миры, кодируя в своей детской.

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

Веб-приложения ныне используются повсеместно, а среди всех транспортных протоколов львиную долю занимает HTTP. Изучая нюансы разработки веб-приложений, большинство уделяет очень мало внимания операционной системе, где эти приложения реально запускаются. Разделение разработки (Dev) и эксплуатации (Ops) лишь ухудшало ситуацию. Но с распространением культуры DevOps разработчики начинают нести ответственность за запуск своих приложений в облаке, поэтому для них очень полезно досконально познакомиться с бэкендом операционной системы. Это особенно полезно, если вы пытаетесь развернуть систему для тысяч или десятков тысяч одновременных подключений.

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

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

Примечание переводчика: оригинальная статья опубликована в серии твитов

Вероятно, вы уже читали кучу объяснений, почему обработка связных списков — плохой вопрос для собеседования. Я же в первую очередь хочу объяснить, откуда он вообще взялся. Всем пристегнуться, погружаемся в теорию игр ИСТОРИЮ!

Хотя индустрия программного обеспечения процветала в 80-е годы, но действительно взлетела в 90-е. В это десятилетие число работников отрасли в США утроилось и превысило миллион человек. Со взрывным ростом пришла необходимость нанимать массу сотрудников и оценивать их.

Что нужно оценить? Ну, в первую очередь, знание языков. Согласно TIOBE, в 1986−2006 годы самым популярным языком в мире был C, далее следовал C++. К 2006 году Java вышла на первое место, но C остался рядом.

C работал близко к железу без лишних абстракций. Пустой словарь Python расходует аж 288 байт, то есть 5% всего объёма памяти первого поколения Apple II. Абстракции слишком дороги, слишком много накладных расходов. Если вам нужна сложная структура данных, вы должны построить её самостоятельно с помощью массивов, структур и указателей.

В понедельник на конференции WWDC компания Apple представила классную новую функцию под названием “Find My". В отличие от стандартной «Найти мой iPhone», которая полагается на инфраструктуру сотовой связи и GPS потерянного устройства, функция «Найди меня» способна найти даже устройства без сим-карты и GPS. Например, ноутбуки, или даже «тупые» метки локации, прикреплённые к любому предмету (Apple намекнула на это только в широком смысле).

Идея заключается в том, чтобы превратить всю существующую сеть айфонов в масштабную краудсорсинговую систему по отслеживанию окружающих объектов. Каждый активный iPhone будет постоянно отслеживать сообщения маячков BLE, которые поступают с других устройств. Когда он находит один из этих сигналов, то помечает пакет своими координатами GPS — и отправляет на серверы Apple. Это очень здорово для растеряш вроде меня, которые постоянно теряют вещи: если я оставлю свой рюкзак в туристическом автобусе в Китае в офисе, то рано или поздно кто-то наткнётся на его сигнал — и я мгновенно узнаю, где его найти.

(Стоит отметить, что идею придумала не Apple. На самом деле компании вроде Tile работают довольно давно. И да, им стоит беспокоиться за свой бизнес).

Встроенный инструмент тестирования Google Lighthouse оценивает доступность (accessibility) сайтов по шкале от 0 до 100. Похвально стремиться к максимальной читаемости контента, но оценка 100 не означает, что сайт идеально доступен. Для доказательства я провёл небольшой эксперимент.

Всегда приятно видеть, как люди хвастаются в твиттере своими оценками Lighthouse: это значит, что они заботятся о качестве.



Lighthouse награждает лучшие сайты зелёным кружочком с цифрой 100, которую вы с гордостью показываете клиентам и друзьям.

Классическое объяснение word2vec как архитектуры Skip-gram с отрицательной выборкой в оригинальной научной статье и бесчисленных блог-постах выглядит так:

while(1) {
   1. vf = vector of focus word
   2. vc = vector of focus word
   3. train such that (vc . vf = 1)
   4. for(0 <= i <= negative samples):
           vneg = vector of word *not* in context
           train such that (vf . vneg = 0)
}

Действительно, если погуглить [word2vec skipgram], что мы видим:

• Страница Википедии, которая описывает алгоритм на высоком уровне
  
• Страница Tensorflow с тем же объяснением
  
• Блог Towards Data Science c описанием того же алгоритма, и список продолжается.

Но все эти реализации ошибочны.