• 10 советов, как ревьюить код, который вам не нравится

    • Translation
    • Tutorial
    Я постоянно делаю коммиты в проекты open source (Red Hat и др.). И заметил, что больше всего времени отнимают негативные код-ревью, субъективные по сути. Чаще всего такое происходит с коммитами, где мейнтейнеру по какой-то причине не нравится ваше изменение. В лучшем случае такая стратегия код-ревью приводит к потере времени в бессмысленных спорах; в худшем случае он активно препятствует коммиту, создавая враждебную и элитарную среду.

    Код-ревью должен быть объективным, кратким и, по возможности, содержать только определённые факты. Это не политический или эмоциональный спор, а технический. Его цель — продвижение вперёд, развитие проекта и всех участников. Любой коммит должен оцениваться только по существу, а не по субъективному мнению.
    Читать дальше →
  • Я нашёл отличного программиста по имени Стив Возняк

    • Translation
    Давным-давно, когда компьютеры были большими, а бизнес скучным, произошло нечто неожиданное. Молодые хакеры нашли способ собрать персональные компьютеры на дешёвых микропроцессорах от телетайпов и светофоров. Одним из них был Стив Возняк. Эти ребята восприняли ограничения своих компьютеров как вызов, сели и заставили эти крошечные чипы делать удивительные вещи. Вот что публиковал Dr Dobb's Journal в августе 1976 года:



    Это набор арифметических процедур на действительных числах. Микропроцессор (6502, такой же, как в Apple I и II) мог работать только с байтами, то есть целыми числами между 0 и 255. Хуже того, он мог только складывать и вычитать их. Но с помощью этой библиотеки вы можете вычислить $1.2627-1099.56$, или даже взять квадратный корень из пи. Удивительно, но автор программы по имени Стив Возняк уместил основные функции (сложение, вычитание, умножение и деление) в 239 байт, используя всего 127 инструкций.
    Читать дальше →
  • Как выбрать случайное число от 1 до 10

    • Translation
    Представьте, что вам нужно сгенерировать равномерно распределённое случайное число от 1 до 10. То есть целое число от 1 до 10 включительно, с равной вероятностью (10%) появления каждого. Но, скажем, без доступа к монетам, компьютерам, радиоактивному материалу или другим подобным источникам (псевдо) случайных чисел. У вас есть только комната с людьми.

    Предположим, что в этой комнате чуть более 8500 студентов.

    Самое простое — попросить кого-нибудь: «Эй, выбери случайное число от одного до десяти!». Человек отвечает: «Семь!». Отлично! Теперь у вас есть число. Однако вы начинаете задаваться вопросом, является ли оно равномерно распределённым?
    Читать дальше →
  • HTML — это и есть веб

    • Translation
    Что нынче с HTML во фронтенде? В последнее время я разговаривал со многими разработчиками. Похоже, что некоторые даже не разбираются в HTML. В смысле, кое-что они понимают. Они понимают, что такое div и что такое span, и когда всё выглядит хорошо и работает по щелчку, им этого хватает. До такой степени, что многие на вопрос о HTML отвечают: «О, да я сейчас всё делаю в React или Vue». Но на самом деле не имеет значения, что вы пишете только Javascript. Если вы разрабатываете веб-сайты, то HTML — это самое главное для вас. Это и есть веб.

    Речь о том, что потребляется пользователем. Это UI и UX. Вот весь пакет. В порядке убывания важности: HTML, CSS и поведение (которое может быть обеспечено Javascript — а может и нет).

    Я вижу проблему внизу этой технологической пирамиды. Наименьший общий знаменатель Сети. Основа. Ритм-группа. Савоярди всех десертов веба. Это HTML. И мне всё больше кажется, что целый пласт фронтенд-инженеров не знают или не понимают главной технологии фронтенда.
    Читать дальше →
  • Данные по-прежнему важнее

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

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

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

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

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

    Доминируют данные. Если вы выбрали правильные структуры данных и всё хорошо организовали, то алгоритмы почти всегда будут самоочевидными. Структуры данных, а не алгоритмы, играют центральную роль в программировании.
    Читать дальше →
    • +25
    • 5.9k
    • 6
  • Развлекаемся с z-index

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

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

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

    • Translation


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

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

    • Translation
    В статье показано, как создать нерекурсивную 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
    Читать дальше →
  • Динамическое программирование в реальном мире: вырезание швов

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

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

    Эта одна из серии статей по динамическому программированию. Если хотите освежить в памяти методы, см. иллюстрированное введение в динамическое программирование.
    Читать дальше →
    • +22
    • 4.3k
    • 2
  • Я был в семи словах от того, чтобы стать жертвой таргетированного фишинга

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

    «Agile agile Agile agile agile agile Agile agile».

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

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

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

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

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

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

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

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

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

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

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

    • Операции, которые хорошо выполняются в небольших масштабах, становятся нежизнеспособными с ростом числа пользователей. Обычно это операции O(N) или O(N²). Когда база пользователей мала, всё работает отлично. Продукт спешат вывести на рынок. По мере роста базы возникает всё больше неожиданных патологических ситуаций — и сервис останавливается.
    • Много отдельных источников неоптимальной работы, «смерть от тысячи порезов».
    Читать дальше →
    • +20
    • 4.8k
    • 9
  • Svalbard — новое имя проекта Have I Been Pwned перед продажей

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

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

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


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

    «Ну, это похоже на любопытную ошибку, интересно, что может её вызвать», — подумал я про себя. Количество недель, безусловно, делает баг похожим на какую-то ошибку переполнения или задания диапазона, ну вы знаете, типичные причины. Но это всегда может быть какой-то перевёрнутый бит каким-то высокоэнергетическим лучом от какого-то дружественного космического соседа.
    Читать дальше →
  • Сравнение одинакового проекта в Rust, Haskell, C++, Python, Scala и OCaml

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

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

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

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

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

    • Translation


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

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

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

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

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