PHP *

Столкнулся с проблемой нормальной реализации коллекций в PHP. Доктриновские коллекции мутабельны и инвариантны. PSL коллекции инвариантны. Нигде не видел непустых коллекций. Везде меня что-то не устраивало и было принято решение написать свою open source реализацию иммутабельных коллекций с ковариантными темплейт-параметрами и выстроенной иерархией пустых и непустых коллекций. В качестве статического анализатора был выбран Psalm.

Перед вами первая статья из серии «Как использовать KPHP в open source?».

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

В сегодняшнем выпуске обсудим:

• базовое использование composer с KPHP;
• как писать и запускать unit-тесты для KPHP;
• бенчмаркинг KPHP-кода (профилирование затронем в другой раз);
• как правильно сравнивать результаты бенчмарков.

Автоматические end-to-end тесты хороши тем, что позволяют сымитировать действия пользователя на сайте. Мы можем запрограммировать в скрипте теста действия типа открыть страницу, нажать на кнопку, ввести данные в поля ввода, нажать галочки и радиокнопки, отправить форму, и ждать на выходе нужный результат. Увидел текст "Ваше сообщение принято. Спасибо" - тест пройден. В ином случае - не пройден. Все прозрачно и понятно. Можно написать автотесты на все критично важные модели поведения пользователя на сайте, перед каждым обновлением кода на боевом сервере прогонять их и таким образом значительно повысить качество разработки. Но мы пойдем еще дальше...

Привет, сообщество!

Это в очередной раз Александр. Рад представить вам ещё один выпуск новостей про PHP фреймворк Yii. Новостей не было довольно долго, но это не потому, что ничего не происходит, а как раз наоборот: происходит всё и сразу. Над Yii3 работать всё приятней так как пакеты стабилизируются, а фреймворк становится более полным.

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

Что делать, если сайт на WordPress грузится медленно? Ответ на самом деле прост – настрой кеширование. Можно ещё заниматься оптимизацией изображений, настройкой lazy loading и прочими хитростями. Но кеширование всё равно остаётся ключевым способом ускорения любого сайта на Вордпресс. Кажется, всё просто, зайди в Google, напиши "WordPress cache", найди статью, где больше всего картинок, скачай упомянутый в статье плагин и выстави настройки согласно скриншотам. При любом раскладе твой сайт сразу начнет работать в разы быстрей.

Но дьявол, как обычно, кроется в деталях. В интернете есть самые разные обзоры и сравнения плагинов кеширования. И за столько лет кто-то же должен был выдать идеальный рецепт? Но нет. Все эти обзоры сводятся к тезису: «мы сделали 10 одинаковых сайтов, установили плагины с дефолтными настройками и смотрим, где страница загрузилась быстрее». При этом все забывают, что нюансов при оптимизации кеширования вагон и маленькая тележка. Похоже, эта статья первая, которая примет во внимание реальное поведение пользователей на сайте, вместо сравнения скорости загрузки одной страницы в тепличных условиях.

Используя бестселлеры с Themeforest или, те же конструкторы, вроде Elementor, WP Backery и прочие, сайт обречен на 5-15 секунд TTFB (time for first byte, время ответа сайта) при загрузке КАЖДОЙ страницы. С одной страницы может быть несколько сотен обращений к базе данных, выполняться большое число php-функций, подключаться множество библиотек. Естественно, что такая скорость недопустима, она влечет за собой понижение в поисковой выдаче, "отказы" посетителей, сливы бюджетов на рекламу и так далее. С этим нужно что-то делать.

PHP широко известен как интерпретируемый язык программирования, использующийся в основном для разработки сайтов. Однако немногие знают, что для PHP есть ещё и компилятор под .NET — PeachPie. Но вот насколько он качественно сделан? Сможет ли статический анализатор найти в этом компиляторе реальные ошибки? Давайте же узнаем!

Благодарю за отклики

Получив разноплановые отклики в виде комментариев и «кармы» на свою первую статью на Хабре «Фреймворк на PHP: CodeIgniter 4. «Лёгкий пример» использования Database Migrations (миграций) и Seeding (посев)», особенно хочется отметить тех членов сообщества, которые разделили точку зрения автора и в своих комментариях нашли нужные слова, чтобы поддержать автора в его намерении поделиться впечатлениями, что CodeIgniter 4 — это актуально.

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

Телеграм-бот криптовалютного кошелька на основе  php-telegram-bot 

Конечный Автомат (State Machine), также называемый Automata (да, как и игра), - это концепция для разработки, организации рабочих и технологических процессов с учетом текущего «состояния» какой-то задачи, изменения её состояний и, по возможности, для автоматизации процесса.

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

Я занимаюсь back-end / full-stack разработкой на Magento 2 уже 3.5 года. Все эти годы у меня никак не хватает сил и времени перетащить один свой старый (но всё еще довольно популярный) проект с убогого Web-CMS uWeb на что-то более-менее толковое, поддерживаемое и расширяемое. Идей было много - писать с нуля на Symfony, изучать Drupal и делать на нем, привлекать React JS... Но всё это требует значительных временных затрат и от этих идей приходилось отказываться.

И вот недавно мне в голову пришла другая идея: а что если использовать Magento 2 как каркас для моего кастомного проекта?..

На новом проекте, на котором я работаю в качестве PHP Tech Lead. Команда столкнулась с вопросом наведения порядков, один из которых - унификация:

В этой статье я расскажу про то, как можно организовать отказоустойчивое взаимодействие с внешними сервисами. Тема актуальная, очень часто из-за недоступности какого-то одного компонента может пострадать вся система.

О чем статья:

•  Синхронное и асинхронное взаимодействие; 

•  Зависимость доступности от использования синхронного взаимодействия;

•  Способы избавления от синхронного взаимодействия;

•  Избавление от синхронного взаимодействия с внешними сервисами в PHP.

Разговоров о Docker очень много, а вот про LXC гораздо меньше шума. А ведь у LXC есть свои области применения, где он может оказаться удобнее.

Изначально мы применили LXC для контейнеризации нашего массивного веб-приложения с длинной историей разработки с 2006 года. И с этой задачей он справился очень хорошо, нам удалось довольно быстро создать образ и упаковать всё в контейнер.

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

Работая разработчиком в одной веб-студии, пришел клиент с довольно интересной работкой, ему нужен был агрегатор постов из чужих телеграм каналов, так как стек в компании был PHP то решили писать на нем, а конкретно на библиотеке MadelineProto о которой уже есть статья от крутого парня (более подробно об этой либе можете почитать в его статье), вот и началось мучительно создание этого сервиса...

Madeline в общей массе свой очень хорошо, полностью асинхронный и имет под капотом кучу методов для работы как с ботами так и с клиентом, но есть у него одна маленькая проблема (а может и не одна ¯\_(ツ)_/¯) , встроенный EventHandler получает не все новые сообщения из постов (и да я понимаю что есть getHistory, но если бы мы брали сообщения через этот метод, все вышло бы очень медленно работающим и высоконагруженным) Долгие часы и даже дни поиска решения этой проблемы не привели к желаемому результату, все так же процент постов которые пропускались именно Madeline был слишком большим.

Ок, было принято волевое решение забить на данную библиотеку и попробовать найти что-то другое на известном нам стеке, взгляд упал на go-tdlib. Развернули либу и поехали пыхтеть в разработку, и о чудо все посты собираются и все стало чудесно, за исключением одного но... Данная библиотека от пользователя Arman92 сильно отстает от офф методов tdlib и имеет внутри несколько логических ошибок, в общем начали у нас сыпаться паники и другие неприятные вещи. Так как пути назад уже не было, перебрали мы всю либу и обновили методы а так же исправили ошибки и теперь все просто чудесно.

Они наконец-то появятся: поддержка перечислений будет добавлена в PHP 8.1! Пост посвящён более подробному рассмотрению нового функционала.

Миграция платежной системы в облако: Зачем и стоит ли?

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

- быстрый запуск;

- готовая PCI DSS ready инфраструктура;

- дополнительная поддержка, в том числе при прохождении аудита PCI DSS;

- брендирование;

- гибкая цена.

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

Будучи одними из первопроходцев на рынке решений для процессинга электронных платежей, мы построили архитектуру платформу на базе популярных на тот момент (примерно 2012 год) и хорошо зарекомендовавших себя решений - PCI DSS ready инфраструктура с аппаратными межсетевыми экранами Cisco ASA, с сегментацией сети, использовались отдельные хосты для каждой роли - фронтенд с админкой, платежными формами, API и incoming/outgoing прокси; процессинг; хосты выдачи вакантных ключей для шифрования карточных данных; хосты с реляционными БД и т.д. Стек был тоже достаточно традиционный - PHP, Apache, MySQL.