Пятиминутка PHP
2.88K subscribers
334 photos
27 videos
827 links
Подкаст о PHP, DBA, архитектуре, DevOps. Авторское мнение о современных трендах в веб-разработке и интересные беседы с гостями. Темы про СУБД, Linux, DevOps

Автор: @petrmyazin
Download Telegram
Есть фрагмент кода, который генерирует набор уведомлений для пользователя.

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

Первый метод я вынес в отдельный класс вручную.

Далее сформировал инструкцию для AI: "вынеси такой-то метод в отдельный класс, оринетируйся на мой пример..."

Использовал утилиту Aider (https://aider.chat/), в которую зашиты протестированные system и user prompts, также эта утилита умеет отправлять в качестве контекста содержимое файлов исходного кода.

Как выглядел процесс:
- добавление файлов в контекст запроса происходит командой /add и этот процесс очень медленный, чуть ли не минуту на каждый файл (я добавил два файла = 2 минуты)
- далее отправляю основной prompt - нужно подождать ещё около минуты, пока не начнёт генерироваться ответ
- ответ приходит строка за строкой, медленно, наблюдаю в консоли
- как только передача ответа завершилась в дело вступает утилита Aider, которая должна создать новый файл на диске (новый класс) и скорректировать старый код, подставив вызов нового класса. Новый класс был создан без части кода и с обновлением текущего файла не вышло.

Что произошло: ответ от GPT содержал кривой diff, который Aider не смог наложить на существующий исходник. В этом случае в Aider предусмотрена автоматизация: он отправляет новый запрос в OpenAI с просьбой вернуть корректный diff. И опять длительное ожидание.

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

В следующий раз опишу, как эту же задачу я решал с помощью Aider + локально запущенной модели DeepSeek Coder (https://huggingface.co/TheBloke/deepseek-coder-6.7B-instruct-GGUF) и с помощью GitHub Copilot Chat в PhpStorm.
👍14😁1
Производительность PHP оказалась примерно в 4 раза выше, чем CPython.

Опубликована вторая редакция проекта PLB (Programming Language Benchmark), нацеленного на тестирование производительности решения типовых задач на различных языках программирования. В отличие от первой редакции, опубликованной в 2011 году, новый вариант измеряет производительность кода для умножения матриц и решения задачи расстановки 15-ферзей, а также дополнительно оценивает поиск решений в игре Судоку и определение пересечений двух массивов. Код для тестирования был написан на 20 языках программирования.

https://www.opennet.ru/opennews/art.shtml?num=60384
🔥32👍6👎2
Я обратил внимание на редактор кода Zed (https://zed.dev)

Написан на Rust, а как мы знаем "всё становится лучше, если написано на Rust" 👩‍💻

Авторы - бывшие разработчики Electron и Atom (помните такой?), которые разочаровались в ставке на веб-технологии в Electron и решили на этот раз всё сделать "правильно"!

Чем-то напоминает историю создателя Node.js, который позже решил переписать с нуля на Rust и получился Deno.

Что я прочитал в блоге Zed.dev в декабре 2023: они решили переписать всё ещё раз! Теперь силы брошены на разработку Zed 2.

Подробнее про редактор Zed на русском:
https://habr.com/ru/articles/595897/
https://blog.disonds.com/2023/07/16/zed-vysokoproizvoditielnyi-riedaktor-koda-ot-sozdatieliei-atom/?ysclid=lqyuxpxdry430537471
Please open Telegram to view this post
VIEW IN TELEGRAM
🤡18👍7🤔63👎1
Forwarded from Joomla Feed (Sergey Tolkachyov)
Производительность Joomla на PHP 8.3 достигла показателя в 341 RPS, показав прирост в 30%
Агентство Kinsta 2 января 2024 года обновило данные бенчмарк-тестов популярных CMS и PHP фреймворков. При выборе движков для теста учитываются популярность, примерное количество живых сайтов, доля рынка, тенденции использования, доля в поиске (США).

Участники соревнования

На беговой дорожке рядом оказались:
👩‍💻 WordPress
👩‍💻 WooCommerce
👩‍💻 Laravel
👩‍💻 Drupal
👩‍💻 Joomla
👩‍💻 Symfony
- CodeIgniter
- Craft CMS
- OpenCart
- Statamic
- Typo3

⚠️ Все CMS и фреймворки тестировались на дефолтных настройках. Во всех подобных тестах нужно учитывать, что "тяжесть" формирования дефолтной страницы у всех движков разная: разное количество запросов в базу данных (обычно слабое место в быстродействии сайтов), разное количество различных проверок и т.д. Например в Joomla по умолчанию главная страница - это избранные материалы. Из базы данных идёт выборка материалов со статусом избранные, происходит проверка прав доступа к материалам, а так же на странице несколько модулей со своими настройками прав доступа, времени начала и окончания публикации и т.д. С виду одинаковая страница на разных движках под капотом означает разное количество работы. Даже смена типа главной страницы на компонент "пустая страница", где нет выборки из бд, проверки прав пользователя и рендера компонента даёт прирост скорости формирования страницы.

Все движки тестировались на версиях PHP 8.1, 8.2 и 8.3. Так же некоторые на 7.4.

Также для нагрузочных тестов важен показатель RPS - requests per second. Этот показатель означает запрос к Приложению на генерацию данных без учета разного рода кэша.

🔥 Результаты тестов производительности
👩‍💻 Joomla
Joomla показала следующие результаты.
Тестируемая версия Joomla: 4.3.3
Тестируемый URL: главная страница
Размер страницы: 8,111,000 байт
Результаты:
- PHP 8.1: 274 req/s
- PHP 8.2: 265 req/s.
- PHP 8.3: 341 req/s.
Таким образом Joomla "из коробки" на PHP 8.3 показала прирост производительности около 30%.

Другие движки
👩‍💻 Wordpress
Тестировались версии Wordpress 6.4.2 и 6.2.2. Возьмём данные по последней версии, в целом они примерно одинаковые.
Тестируемая версия Wordpress: 6.4.2
Тестируемый URL: главная страница
Размер страницы: 84,257,000 байт
Результаты:
- PHP 7.4: 149 res/s.
- PHP 8.1: 153 req/s.
- PHP 8.2: 158 req/s.
- PHP 8.3: 169 req/s.

👩‍💻 Laravel
Это PHP-фреймворк, на котором обычно пишут "серьёзные" проекты.
Тестируемая версия Laravel: 10.16.1
Тестируемый URL: главная страница
Размер страницы: 27,514,000 байт
Результаты:
- PHP 8.1: 611 req/s.
- PHP 8.2: 670 req/s.
- PHP 8.3: 925 req/s.

👩‍💻 Drupal
Тестируемая версия Drupal: 10.11
Тестируемый URL: главная страница
Размер страницы: 19,102,000 байт
Результаты:
- PHP 8.1: 922 req/s.
- PHP 8.2: 941 req/s.
- PHP 8.3: 1432 req/s.

👩‍💻 Symfony
Также PHP-фреймворк, используемый для бэкенда сайтов и приложений.
Тестируемая версия Symfony: 6.3.0
Тестируемый URL: главная страница
Размер страницы: 559,000 байт
Результаты:
- PHP 8.1: 931 req/s.
- PHP 8.2: 997 req/s.
- PHP 8.3: 1182 req/s.

OpenCart
Специализированный движок для создания интернет-магазинов.
Тестируемая версия OpenCart: 4.0.2.2
Тестируемый URL: главная страница
Размер страницы: 33,014,000 байт
Результаты:
- PHP 8.1: 151 req/s.
- PHP 8.2: 154 req/s.
- PHP 8.3: 164 req/s.

Подробнее
Please open Telegram to view this post
VIEW IN TELEGRAM
👍34🤨15👎4🔥4🤔4🤮2
Forwarded from OpenNews (HK-47)
Рейтинг языков программирования TIOBE за январь 2024 года
Компания TIOBE Software опубликовала январский рейтинг популярности языков программирования, в котором по сравнению с январём 2023 года выделяется перемещение языка JavaScript с седьмого на шестое место, языка PHP с 10 на 7 место, Scratch с 20 на 10 место (рост популярности на 0.83%) , Go - c 12 на 11, Fortran - с 27 на 12 (+0.64%), Object Pascal - c 17 на 13, MathLab - с 15 на 14, Kotlin - с 25 на 17 и Cobol - с 31 на 20. Языком года назван C#, который сохранил 5 место, но стал лидером по росту популярности (+1.43%).
👍20🤔2
Антон Морев показал как он работает на 7 мониторах - я был впечатлён 🤯

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

2 видеокарты, 96 Гб оперативки, 5,5 Тб SSD, чтобы не разбирать хлам файлов просто докупает новые SSD по терабайту - моё почтение!

https://youtu.be/z8pnoBh9o9s?si=RA5g--7htjT1oNQt
🤯49💩36🤪9👍5🤡5😁32🤔1🤮1🥱1🥴1
Тейлор и Ко. возобновляют Laravel Worldwide Meetup (online). Ближайшая встреча 30 января 2024: https://meetup.laravel.com
👍17💩3🤡2👎1
Шаблонизатор Twig 2.0 официально прекратил своё развитие - переходим на Twig 3.0!

Twig 2.0 был выпущен в январе 2017 года, а Twig 3.0 - в ноябре 2019 года - можно считать что Twig 3.0 уже достаточно заматерел.
Symfony 7.0 не будет поддерживать Twig 2.

Что было удалено в ветке 3.0 по сравнению с 2.0: https://twig.symfony.com/doc/2.x/deprecated.html
👍11🤡2😱1
Forwarded from Live PHP
⚡️⚡️⚡️

Приглашаем на очередной митап сообщества Live PHP 👩‍💻
который пройдет в Санкт-Петербурге в четверг, 15 февраля 2024


0⃣ Кирилл Несмеянов 🔥

Все оттенки асинхронности


Многие слышали об асинхронности, но не многие применяли. А те, кто применяли — почти всегда
используют готовые инструменты.
С приходом PHP 8.1 в язык добавили Fiber API, которые изменяют подходы к разработке ПО, но не
только лишь все смотрят в завтрашний день, понимая насколько они могут изменить "правила игры".
В докладе предлагается "изобрести" асинхронность заново, и задуматься о том, что подходы к
разработке с использованием EventLoop, используемые в Revolt/ReactPHP/Amp/etc с приходом файберов
морально устарели.
А может и нет... Решать вам =)


1️⃣ Валентин Удальцов, автор каналов Пых и PHP Point ⭐️

Полиморфизм в современном PHP


На первый взгляд может показаться, что в PHP есть только полиморфизм подтипов. Однако если вооружиться современными инструментами и напильником, можно получить все три вида полиморфизма.
На докладе мы глубоко прокачаем понимание типизации. Обсудим в сотый раз LSP, разберёмся с вариантностью (declaration-site и call-site), реализуем простейшую перегрузку методов и поймём, почему её нет в языке. Будет познавательно и полезно не только в контексте PHP.


2️⃣ Дмитрий Елисеев ⭐️

Переносимое окружение для разработки и тестов


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

✏️ Регистрация обязательна: https://forms.yandex.ru/u/65b750d284227c056de36519

📎 Дата и время сбора: 15 февраля, начало 19:00
🔜 Место встречи: Failover Bar
Санкт-Петербург, 4-я Советская, д.7
https://yandex.ru/maps/-/CDu9r83l

📹 Трансляция: https://youtube.com/live/DhkTJcjJouc
Please open Telegram to view this post
VIEW IN TELEGRAM
👍29🔥20
Forwarded from Alisa Kruglova [MSK -2]
Результаты ежегодного опроса сообщества готовы!

📥1120 мнений о прошедшем 2023 в лендинге и статье.

📎 На каких версиях PHP сидят команды;
📎 Как в сообществе относятся к ИИ-инструментам для разработки;
📎 Статьи, видео, человек года, по мнению сообщества;
📎 Топ инструментов для статического анализа;
📎 и не только.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥27
Все слышали про принципы DRY, KISS, YAGNI...

А как насчёт правила еловой табуретки или правила лестнечных пролётов?

Я уже представил, как на следующем code review напишу: "в этом фрагменте кода стоит применить правило несъедобного исключения" 😀
😁48🤡11🤪4👍3🔥1
Один из ключевых разработчиков nginx, не согласный с политикой нынешних владельцев (компания F5), заявил, что больше не будет контрибьютить в nginx и запустил свой форк FreeNginx: http://freenginx.org/hg/nginx

История обычная.

Что меня удивило: репозиторий под управлением Mercurial! Я, конечно, тоже считаю что Mercurial в своё время был круче git, но уже 2024 год, как привлекать комьюнити к работе с open source на Mercurial?
🤨26🙈19😁8👍3😱1🤝1
Forwarded from Хэндлим тему | Дерепко (Dmitrii)
Тестирования функций из стандартной библиотеки PHP и не только

#пост №7

Цель

Подмена (mock) функций, которые уже “загружены” в PHP еще до подгрузки Composer Autoloader, каких-либо include или других объвлений function name(){}

Подмена не только из под не пустого namespace, например App\Service\name , но и из корневого namespace: проще всего это сделать через use function name;

Проблема

Если объявить функцию с именем, которая уже существует в стандартной библиотеке PHP, то получим ошибку, что такая функция уже существует и переопределить её нельзя.

Можно было бы “выгрузить” её из памяти, но увы, выгружать из памяти функции в PHP нельзя.

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

Ресерч

В php.ini можно найти флаг disable_functions , которая принимает список имен функций, которые нужно “не объявлять” в недрах PHP.

Если использовать этот флаг, то php -ddisable_functions=time -r "echo time();" выкинет ошибку:


❯ php -ddisable_functions=time -r "echo time();"
PHP Fatal error: Uncaught Error: Call to undefined function time() in Command line code:1
Stack trace:
#0 {main}
thrown in Command line code on line 1

Fatal error: Uncaught Error: Call to undefined function time() in Command line code on line 1

Error: Call to undefined function time() in Command line code on line 1

Call Stack:
0.0000 389568 1. {main}() Command line code:0


Это и логично. Функции time больше нет. Но теперь ведь можно создать её самостоятельно?

Если объявить функцию самостоятельно, то ошибки больше не будет:


❯ php -ddisable_functions=time -r "function time() { return 123; } echo time();"
123%


Бинго!

Помещаем объявление функции в библиотеку, создаем State manager, через которого сможем управлять возвращаемым значение “123” и делаем пользователю интерфейс взаимодействия с этим менеджером.

Теперь, если пользователь захочет протестировать вызов time , то сможем самостоятельно указать требуемые значения. Время в будущем, в прошлом, 0, false, что угодно.

Но как быть, если нужно протестировать измененную функцию time лишь в одном тесте, а в других местах оставить всё как есть?

Можно так и сделать: State manager создает для всех тестов функцию, которая эмулирует стандартную time , а в нужном тесте наложить на общую эмуляцию частную.

Вроде всё логично и понятно. Можно накодить и наслаждаться тестированием.

Однако, а как эмулировать системное время? Если с различными полифилами от symfony всё понятно: можно создать какую-то функцию, которая будет базировать на другой функции, преобразовывать результат под новый формат и отдавать его.

Но на какой функции нужно базировать время?

DateTime`* классы? `date() ? mktime ? hrtime ? А если их тоже отключить нужно?

Bash! 🤪

PHP имеет возможность в любое время обратиться к своему старшему брату-башу простыми обратными кавычками: `command` . Результат будет строкой, но всегда можно "кастануть".

Для аналога time() команда `date +%s` .

Значит для State manager осталось написать только возможность использовать не статичное значение, а функцию, которая каждый раз будет выполняться.

Всё это и не только сделано в библиотеке xepozz/internal-mocker

Читаем доку по установке и первичной настройке, добавляем нужные файлы, вписываем следующую конфигурацию:


$mocker = new Mocker();
$mocker->load([
[
'namespace' => '',
'name' => 'time',
'function' => fn () => `date +%s`,
],
]);
MockerState::saveState();


——

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

——

Описание disable-functions: https://www.php.net/manual/en/ini.core.php#ini.disable-functions

Internal mocker: https://github.com/xepozz/internal-mocker/
👍21🙈12🔥6👎3😱2