Это дайджест новостей от CutCode. Сергей Пантелеев и Данил Щуцкий с ежемесячным обзором новостей в мире PHP и Laravel.

Привет, Хабр!

Laravel — это целая экосистема, которая позволяет разрабатывать веб-приложения с невероятной скоростью и гибкостью. Но вот вопрос: как быть уверенным, что все эти красивые строки кода не развалятся в самый неподходящий момент? Ответ очевиден — тесты!

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

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

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

Рассмотрим классические ситуации, когда разработчики начинают жаловаться на производительность БД - а виновата-то и не она!

Статья про то, как я изменил стандартное поведение нормализации ввода и решил проблемы валидации, возникшие из-за этого. В статье упоминаются слова ООП, наследование, фабрики, сервис-провайдеры и другие.

Данный пост нацелен на неопытных PHP-специалистов. От этой информации лучше программировать вы не станете. Ожидаемая польза:

Мне когнитивно и морально легче, когда уменьшается «магия» того, с чем работаешь. Может тебе тоже

Возможно чуть-чуть реже статьи на хабре будут тебя отпугивать

Объясню на 4 примерах — каждый лишь немного сложнее предыдущего.

Пример 1: запуск программы, написанном на компилируемом языке (Go): в полной статье

Пример 2: Запуск скрипта PHP без OPCache и JIT

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

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

Вот схематично представил всю последовательность работы PHP скрипта без включенных OPCache и JIT (каждый из них по отдельности рассмотрим в следующих двух примерах).

У нас привычный «исходный код» PHP (файл hello-world.php):

<?php echo "Hello world";

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

php hello-world.php

Процесс №1 — Компиляция в байт-код
Сначала исходный код обрабатывается Zend Compiler — это PHP компилятор. Первый из двух основных компонентов Zend Virtual Machine.

В отличие от рассмотренного выше компилятора Go:

задача PHP компилятора — преобразовать исходный код не в машинный код, а в код-посредник - байт-код;

процесс компиляции происходит при каждом запуске программы (вместо лишь единоразового - до запуска программы, как в примере с Go)

В случае PHP этот байт-код назвали PHP OPCode.

Байт-код — является более низко-уровневым, чем исходный код. Он содержит набор команд для интерпретатора (об интерпретаторе в следующем пункте). Байт-код не может выполняться процессором напрямую.

Чтобы посмотреть результат работы компилятора — сам байт-код — выполним команду:

php -d opcache.opt_debug_level=0x20000 -d opcache.enable_cli=1 hello-world.php

Получим:

$_main: ; (lines=3, args=0, vars=0, tmps=1) ; (after optimizer) ; /hello-world.php:1-2 0000 EXT_STMT 0001 ECHO string("Hello World") 0002 RETURN int(1)

Вначале видим $_main: — обозначает, что следующие строки относятся к функции main. Появление такой функции в байт-коде для глобальной области видимости PHP — занятная историческая особенность, дошедшая из других языков;

Следующие 3 строки начинаются на ; — так обозначаются комментарии. Одна из целей — для дебаг-информации;

Последние 3 строки — непосредственно код нашего приложения, который будет выполняться виртуальной машиной в следующем шаге.

Процесс №2 — Выполнение байт-кода

Следующий возникающий в голове вопрос, когда разобрался с тем, как работать с данными в данной архитектуре (а может у кого то этот вопрос стоит первым) - как микросервисы будут взаимодействовать между собой?

В данной статье разберемся с синхронным и асинхронным взаимодействием, сложностями и разными подходами.

Приветствую тебя читатель, я решил написать про ACID и Транзакции PostgreSQL своим языком, с понятными примерами, эта статья ориентирована на людей готовящихся к собеседованию, кто захотел узнать нюансы транзакций в PostgreSQL или про ACID, а также для людей которые знают теорию, но сами ещё ни разу не писали транзакции. Я не ставил перед собой цели рассмотреть и объяснить работу транзакций на очень глубоком уровне. Была цель привести понятные примеры, дать макет работы с транзакциями, а также пощупать основные возможные проблемы при работе с транзакциями в PostgreSQL.

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

На связи Егор из блока поддержки платформы F5, сегодня предлагаем вспомнить основы systemd. Поскольку утилит и возможностей в нем много, а новые функции добавляются регулярно, следить за всем этим может быть непросто, так что начнем с основ.

Systemd — это init процесс, который запускается при загрузке ядра операционной системы linux и его задачей является форкать другие процессы. Информацию о том, какие процессы необходимо исполнить он берет из, так называемых “юнитов” (systemd unit - https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html). Юниты бывают различных типов, каждый из которых выполняет определенную задачу.

TL;DR В статье рассказывается о доступе к внутрикорпоративным ресурсам через соединение Forti из подсистемы Windows для Linux (WSL).

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

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

Что такое One Million Checkboxes?

Добрый день, коллеги! Как известно, компания "Postgres Professional" более не рекомендует использовать секционирование с использованием pg_pathman, а рекомендует использовать вместо него декларативное секционирование. Однако помимо синтаксического сахара и утилитарного кода по поддержке интервального (в стиле Oracle) секционирования, я обнаружил для себя ещё одну проблему в такой миграции (переходе). Надеюсь, коллеги из PGPro доработают декларативное секционирование к моменту окончательного выпиливания pg_pathman.

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

Редис – это кеш? А, может быть, это основная база данных? Так мы и живём в Мойре – опенсорс-системе реалтайм-алёртинга, родом из компании Контур. Расскажу вам про плюсы и минусы такого подхода, про жизнь в Редисе при 3 миллионах RPS, про миграции данных и оптимизацию базы.

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

File Uploader представляет собой элемент интерфейса, который позволяет пользователям выбирать и загружать файлы. Обычно он состоит из кнопки «Выбрать файл» или поля для перетаскивания файлов, которые пользователь может выбрать для загрузки.

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

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

В апреле этого года мы, команда производительности из Postgres Professional, совместно с коллегами из Selectel решили протестировать несколько дистрибутивов PostgreSQL и узнать, как они себя поведут на разных архитектурах. С результатами можно ознакомиться в этой статье, но, как сразу было верно отмечено читателями, там был один важный косяк –  мы не сравнили производительность ванильного PostgreSQL с применением всем известных настроек по улучшению производительности и Postgres Pro Enterprise из коробки as is. Терпеть такое не было решительно никакой возможности, поэтому сегодня будет продолжение истории и ответ на важный для многих вопрос: «А есть ли у нашего форка хоть какое-то преимущество перед бесплатной ваниллой?» Или мы просто накатили общеизвестный конфиг и занимаемся импортозаместительным переклеиванием наклеек?

Это дайджест PHP и Laravel от CutCode. Давайте посмотрим, что произошло за прошедший месяц в мире PHP и Laravel.

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

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

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