В мире PHP-программирования существует набор трендов. Некоторые люди активно продвигают их (в книгах и на сайтах) как «современный PHP», а другие подходы выставляют как устаревшие, глупые или просто неверные.

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

^{Эй, PHP, эти переменные выглядят как мусор, согласен?
Нет? Ну, посмотри-ка снова…}

tl;dr:
Мы обнаружили две use-after-free уязвимости в алгоритме сбора мусора в PHP:

• Одна присутствует во всех версиях PHP 5 ≥ 5.3 (исправлена в PHP 5.6.23).
• Вторая — во всех версиях PHP ≥ 5.3, включая версии PHP 7 (исправлена в PHP 5.6.23 и PHP 7.0.8).

Уязвимости могут удалённо применяться через PHP-функцию десериализации. Используя их, мы отыскали RCE на pornhub.com, за что получили премию в 20 000 долларов плюс по 1000 долларов за каждую из двух уязвимостей от комитета Internet Bug Bounty на Hackerone.

Хэш-таблицы используются везде, в каждой серьёзной С-программе. По сути, они позволяют программисту хранить значения в «массиве», индексируя его с помощью строк, в то время как в языке С допускаются только целочисленные ключи массива. В хэш-таблице строчные ключи сначала хэшируются, а затем уменьшаются до размеров таблицы. Здесь могут возникать коллизии, поэтому нужен алгоритм их разрешения. Существует несколько подобных алгоритмов, и в РНР используется стратегия связных списков (linked list).

В Сети есть немало замечательных статей, подробно освещающих устройство хэш-таблиц и их реализации. Начать можно с http://preshing.com/. Но имейте в виду, вариантов структуры хэш-таблиц — несметное множество, и ни один из них не совершенен, в каждом есть компромиссы, несмотря на оптимизацию циклов процессора, использования памяти или хорошее масштабирование потокового окружения (threaded environment). Одни варианты лучше при добавлении данных, другие — при поиске и т. д. Выбирайте реализацию в зависимости от того, что для вас важнее.

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

Здесь же мы подробно рассмотрим, как устроены хэш-таблицы в РНР 7, как с ними можно работать с точки зрения языка С и как ими управлять средствами РНР (используя структуры, называемые массивами). Исходный код в основном доступен в zend_hash.c. Не забывайте, что хэш-таблицы мы используем везде (обычно в роли словарей), следовательно, нужно проектировать их так, чтобы они быстро обрабатывались процессором и потребляли мало памяти. Эти структуры решающе влияют на общую производительность РНР, поскольку местные массивы не единственное место, где используются хэш-таблицы.

Возьмите переменную и увеличьте её на 1. Звучит просто, верно? Ну… С точки зрения PHP-разработчика, наверное, да. Но так ли это на самом деле? Здесь могут возникнуть некоторые трудности. Существует несколько способов инкрементировать значения, они могут выглядеть равноценными, но под капотом PHP работают по-разному, что может привести к, так сказать, интересным результатам.

С рождением PHP 7 не прекращаются споры об абстрактных синтаксических деревьях, just-in-time компиляторах, статическом анализе и т. д. Но что означают все эти термины? Это какие-то волшебные свойства, делающие PHP гораздо производительнее? И если да, то как это всё работает? В этой статье мы рассмотрим основы работы языков программирования и разъясним для себя процесс, который должен выполняться до того, как компьютер запустит, например, ваш PHP-скрипт.

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

Интерфейс можно считать своеобразным договором между системой и внешним окружением. В рамках компьютерной программы «система» — рассматриваемая функция или модуль, а «окружение» — весь остальной проект. Интерфейс формально описывает, какие данные могут передаваться между системой и окружением. А «реализацию» можно охарактеризовать как «система минус интерфейс». В языках наподобие Haskell интерфейсы могут быть крайне специфическими. А в языках вроде Python они, напротив, очень обыденны. Выбранный тип интерфейса может повлиять на размер созданного технического долга и производительность программиста. О том, как это посчитать, написано ниже. Также будет предложен метод для оценки и сравнения разных интерфейсов. На основании этих сравнений вы сможете сами понаблюдать за способами использования языка или программного инструмента.

Перевод статьи Vitalij Mik Clean Code Architecture and Test Driven Development in PHP

Понятие «архитектура чистого кода» (Clean Code Architecture) ввел Роберт Мартин в блоге 8light. Смысл понятия в том, чтобы создавать архитектуру, которая не зависела бы от внешнего воздействия. Ваша бизнес-логика не должна быть объединена с фреймворком, базой данных или самим вебом. Подобная независимость даёт ряд преимуществ. К примеру, при разработке вы сможете откладывать какие-то технические решения, например выбор фреймворка, движка/поставщика БД. Также вы сможете легко переключаться между разными реализациями и сравнивать их. Но самое важное преимущество такого подхода — ваши тесты будут выполняться быстрее.

Просто подумайте об этом. Вы действительно хотите пройти роутинг, подгрузить абстрактный уровень базы данных или какое-нибудь ORM-колдовство? Или просто выполнить какой-то код, чтобы проверить (assert) те или иные результаты?

_{На картинке — Ancient Psychic Tandem War Elephant © Adventure Time}

В этой статье будет рассмотрен процесс внедрения в PHP нового оператора. Для этого будут выполнены следующие шаги:

• Обновление лексического анализатора: он будет знать о синтаксисе нового оператора, что позволит потом превратить его в токен.
• Обновление парсера: система будет знать, где может использоваться этот оператор, а заодно какова его приоритетность и ассоциативность.
• Обновление этапа компиляции: здесь происходит обработка (traverse) дерева абстрактного синтаксиса (AST) и извлечение из него кодов операции.
• Обновление виртуальной машины Zend: во время выполнения скрипта она используется для обработки интерпретации нового кода операции для оператора.

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

На сегодняшний день разработчики PHP ведут работу над API уровня С. И в этом посте я буду по большей части рассказывать о внутренней разработке PHP, хотя если по ходу повествования встретится что-то интересное с точки зрения пользовательского уровня, то я буду делать отступление и объяснять.

В этом посте изложены советы, как не написать код, производительность которого окажется гораздо ниже ожидаемой. Особенно это касается ситуаций, когда движок V8 (используемый в Node.js, Opera, Chromium и т. д.) отказывается оптимизировать какие-то функции.

Не так давно мне довелось выступать на конференции FFConf с докладом «Вам следует использовать <впишите нужную библиотеку/фреймворк>, это самое лучшее!». И основные мысли я решил изложить в публикации, в надежде, что это спровоцирует в профессиональной среде более широкую дискуссию о «стоимости» современных фреймворков на мобильных устройствах.

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



и слайды презентации: speakerdeck.com/paullewis/framework-here-its-the-bestestest.

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

Наверняка многие из вас неоднократно сталкивались с мифами о /dev/urandom и /dev/random. Может быть, в некоторые из них вы даже верите. В этом посте мы сорвём покровы со всех этих мифов и разберём настоящие сильные и слабые стороны этих генераторов случайных чисел.

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

Сегодня многие системы и языки программирования позиционируются как «мощные». Нельзя сказать, что это плохо. Почти каждый из нас считает это положительным свойством. Но в этом посте я хочу донести такую точку зрения, что во многих случаях нам нужны менее мощные языки программирования и системы. Но прежде чем продолжить, уточню: здесь будет мало оригинальных, моих собственных размышлений. Я буду излагать ход мыслей, возникший по прочтении книги Дугласа Хофштадтера «Гёдель, Эшер, Бах», которая помогла мне собрать воедино разрозненные идеи и мысли, бродившие в голове. Также большое влияние на нижеизложенный материал оказали пост Филипа Вадлера и видеозапись с конференции Scala. Ключевая мысль такова:

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

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

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

Прим. перев.: для более полной картины здесь вас также будет ждать перевод Hashing Passwords with the PHP 5.5 Password Hashing API, на которую автор ссылается в статье.

Разбивка на страницы — это способ управления памятью, выделяемой для пользовательских процессов. Все доступы процессов к памяти являются виртуальными, а преобразование их адресов в адреса физической памяти выполняют ОС и аппаратный MMU.

При разбивке на страницы память делится на блоки фиксированного размера. В Linux на x86/64-платформах размер страниц обычно составляет 4 Кб. Каждый процесс содержит в себе таблицу, в которой хранится информация о соответствии адресов страницы и физической памяти — элемент таблицы страниц (page table entry). Чтобы ОС не лезла в эту таблицу при каждом обращении к памяти (иначе для обработки каждого запроса на обращение к памяти потребуется обращаться к ней дважды), применяется небольшой кэш — буфер ассоциативной трансляции (Translationlookaside Buffer, TLB). Этот аппаратный компонент находится в MMU и работает чрезвычайно быстро и эффективно. Система сканирует TLB с целью поиска записи о соответствии адресов страницы и физической памяти. Если нужной записи там не оказывается, тогда ядру ОС приходится обращаться к памяти, искать нужное соответствие и обновлять информацию в TLB, чтобы получить из памяти нужные нам данные.

Если вы хотите больше узнать об управлении виртуальной памятью, то можете изучить эту публикацию. А пока давайте разберем, как в PHP 7 устроена работа с большими страницами (Huge Page).

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



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

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

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

^{Капитан Немо у штурвала «Наутилуса»}

Индексы — один из самых мощных инструментов в реляционных базах данных. Мы используем их, когда нужно быстро найти какие-то значения, когда объединяем базы данных, когда нужно ускорить работу SQL-операторов и т.д. Но что представляют собой индексы? И как они помогают ускорять поиск по БД? Для ответа на эти вопросы я изучил исходный код PostgreSQL, отследив, как происходит поиск индекса для простого строкового значения. Я ожидал найти сложные алгоритмы и эффективные структуры данных. И нашёл.

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