PHP *

В этом году должен выйти PHPUnit 10 (релиз планировался на 2 апреля 2021 года, но был отложен). Если посмотреть на список изменений, то бросается в глаза большое количество удалений устаревшего кода. Одним из таких изменений является удаление метода MockBuilder::setMethods(), который активно использовался при работе с частичными моками. Этот метод не рекомендуется использовать с версии 8.0, но тем не менее он описан в документации без каких-либо альтернатив и упоминания о его нежелательности. Если почитать исходники PHPUnit, issues и пул-реквесты на GitHub, то станет понятно, почему так и какие есть альтернативы.

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

Не секрет, что чем больше проект, тем с большим количеством проблем он сталкивается даже в самых элементарных аспектах.  В продукте Plesk, над которым я работаю, PHP является одним из основных языков, и количество кода на нем превышает 1 миллион строк. Соответственно, мы активно используем PHPUnit для тестирования. Кроме большого объема кода, поддержка двух платформ (Linux и Windows) доставляет нюансы, как и тот факт, что поддерживается несколько бранчей с приличной разницей возраста (крупные релизы), а активно вносят правки несколько десятков инженеров. В статье я хочу поделиться некоторыми практиками, которые мы используем при работе с PHPUnit.

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

От версии 8 к 8.1

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

Большинство символов можно просто набрать с клавиатуры и использовать в коде PHP в их исходном виде. Например, $string = "php.watch" - это полностью допустимая строка в PHP, а $num = 42 - допустимое число. Также можно использовать многобайтные символы (для хранения которых требуется более одного байта), например, этот совершенно допустимый эмодзи: $emoji = "?".

PHP, наряду со многими другими языками программирования, поддерживает определенное количество escape-последовательностей для использования различных символов, которые не могут быть набраны с обычной клавиатуры, не могут быть представлены в текстовой форме (например, невидимые символы или различные управляющие символы) или иным образом не считываются. Эти символы используют escape-последовательности, которые распознает PHP.

Что касается чисел, PHP поддерживает стандартные десятичные числа, но также может использовать и другие нотиции, такие как двоичное, восьмеричное, шестнадцатеричное и даже научное (scientific) представление. Они могут сделать код более читаемым и понятным в зависимости от контекста.

На написание этой статьи меня подтолкнуло обсуждение докладов с Heisenbug 2021 в нашем корпоративном чате. Причиной является тот факт, что достаточно много внимания уделяется «правильному» написанию тестов. В кавычках — потому что на бумаге все действительно логично и аргументированно, однако на практике такие тесты получаются достаточно медленными.

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

Привет, сегодня я хочу поговорить об ужасной кодовой базе, с которой вы скорее всего прямо сейчас имеете дело. Есть проект и вы нужны, чтобы добавлять новые фичи и фиксить баги. Но вы открываете IDЕ, делаете пул репозитория с проектом — хочется плакать. Кажется, что с этим кодом невозможно работать.

Давайте отбросим эмоции. И посмотрим, что можно быстро предпринять, чтобы облегчить страдания.

В последнее время было достаточно много обсуждений производительности в PHP. И даже несмотря на то, что у нас есть PHP8, JIT и куча других улучшений, многие по-прежнему продолжают жаловаться на то, что PHP "недостаточно производительный". Что PHP - это язык, подходящий только для модели запрос-ответ. Что PHP слишком медленный и его не нужно использовать для высоконагруженных систем. С одной стороны от части всё это правда. Если мы строим какую-то систему, для которой вопрос производительности критичен, то использовать классический блокирующий PHP явно не стОит. Большая часть функций и библиотек PHP созданы для работы в традиционном блокирующем окружении, что уже подразумевает собой не самую высокую производительность. Однако PHP может работать быстро, более того, он может работать очень быстро. Как? Обычно у нас может быть две причины, из-за чего будет проседать производительность: мы либо совершаем какие-то сложные вычисления, либо у нас есть блокирующй ввод-вывод. Первое к сожалению (или к счастью) мы не можем решить в PHP. Но блокирующий ввод-вывод для PHP совсем не проблема. В PHP-сообществе есть люди, которые пишут асинхронный код уже на протяжении несколько лет. Конечно одновременно с этим бОльшая часть сообщества по-прежнему считает асинхронный PHP - дикостью. Я часто слышал: "Ты наверно совсем отчаянный, если собираешься писать что-то асинхронное на PHP". По правде говоря, у нас у всех есть это предубеждение, что PHP не подходит для подобного рода задач. И в большинстве случаев это предубеждение основано на неверных представлениях о самой "асинхронности". Неверные предубеждения в свою очередь ведут к неправильным ожиданиям, что в свою очередь приводит к разочарованию и обвинениям в том, что PHP "не по-настоящему асинхронный".

Хочу поделиться опытом автоматизации экспорта заказов из Aliexpress в несколько CRM. Приведенные примеры написаны на PHP, но библиотеки для работы с Aliexpress есть и для других языков. Структура запросов и ответов аналогична. Если перед вами стоит задача интеграции Aliexpress, надеюсь, эта статья будет вам полезна.

Привет, друзья.

Меня зовут Alex Versus и сегодня с вами посмотрим шаблон Singleton, реализацию на языке Golang.

Какая суть?

Одиночка - относится к порождающим шаблонам. Гарантирует:

Привет! В эту субботу PHP-чат Нижнего Новгорода проведет свой четвертый офлайн-митап с интерактивной трансляцией. Доклады подготовят Валентин Удальцов из Москвы и Денис Юрьев из Новосибирска. Записаться на митап можно здесь, поставить колокольчик под трансляцией — здесь. Те, кто будут смотреть онлайн, смогут задать вопросы текстом или голосом прямо из браузера.

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

Какие уязвимости можно найти в типичном PHP-проекте? Удивительно, но любые — от слабых мест и уязвимостей в коде никто не застрахован. Чем быстрее мы их найдем, тем меньше риск для компании. Но чем лучше будем понимать, как можно атаковать наше приложение и как взаимодействуют друг с другом наши фичи, тем легче будет защитить код еще на уровне разработки. Тем более, что в PHP есть свои специфичные уязвимости — те же type juggling, insecure deserialization и local file include.

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

Всем привет, друзья. Меня зовут Alex, я профессиональный разработчик и создатель программных продуктов в веб индустрии. Много лет изучаю языки, делюсь опытом с другими.

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

В этой статье хочу рассказать о проблемах, с которыми столкнулся в процессе интеграции с API по HTTP протоколу, и поделиться опытом их решения.

При разработке фронтенд приложений (mobile/web), часто сталкиваешься с тем, что API на бэкенде еще не реализован. Приходится ждать разработчика на бэкенде, когда он предоставит нужные запросы, постоянно напоминая ему о себе. Не редкость и другая ситуация, когда нужные http запросы уже есть, но они реализованы очень плохо и криво.

Возможно, я бы и не писал эту статью. Но мне показался поразительным тот факт, что все приведенные ниже примеры плохой реализации API попались мне в одном-единственном проекте, одновременно!

В этом проекте я разрабатываю мобильное приложение на Flutter, используя пакет Retrofit, который помогает мне сократить время и код, который приходится писать самому, генерируя значительный код автоматически. Так же использую Insomnia, для первоначальной проверки запросов до реализации их в коде.

Итак, начнем.

Если вы один из тех людей, в кодовой базе которых есть разделение (как и у меня) на уровни приложения (прикладной) и домена, то у вас достаточно часто возникает вопрос: в каком уровне должна находиться эта служба: приложения или домена? Иногда это заставляет задуматься, а не является ли различие между этими слоями все-таки чем-то чересчур необстоятельным. Я не собираюсь в очередной раз писать о том, что подразумевают под собой эти уровни, я расскажу вам как решаю, какому уровню принадлежит служба - приложения или домена:

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

В тот момент я искал кнопочный телефон, чтобы заменить им смартфон, который отнимал уйму времени. Так ко мне попал matrix-фон Nokia 8110 с KaiOS на борту и именно с этого момента когда я клал трубку после очередного разговора, приятели шутили, что мне опять звонил тот самый бог сновидений Морфеус.

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