Веб Мастерская | Веб разработка и программирование | ИТ | IT

PHP:

Коллеги, кто хоть раз видел «Call to a member function on null», тот уже познал боль. Обычно это происходит так: запрос к MySQL вернул ноль строк, а код всё равно пытается вызвать метод у объекта.

Раньше писали так:

$phone = null;
if ($user !== null && $user->profile !== null) {
$phone = $user->profile->phone;
}

Длинно, скучно и легко забыть одну проверку. В продакшене это мгновенно превращается в фатал.

В PHP 8+ есть nullsafe оператор ?->:

$phone = $user?->profile?->phone;

Если $user равен null, цепочка не падает, а просто вернёт null. Дальше решаем сами: дефолт, бейдж, 404 или лог.

Где реально выручает:

— $user из репозитория: SELECT ... LIMIT 1 может вернуть пустоту;
— связи: $order?->customer?->email;
— DTO и сущности, где часть полей не заполнена.


Но нюансы из мастерской:

— ?-> хорош там, где «нет данных» — нормальный сценарий.

— Если объект обязан быть, не прячьте ошибку. Лучше исключение или проверка на уровне сервиса.

— Для массивов он не подходит: используем $data['phone'] ?? null.

— Не заменяет типизацию. ?User $user = null и строгие контракты всё ещё спасают.

— Если используете PDO, не путайте false и null. Удобнее, когда репозиторий возвращает ?User, а не сырой результат fetch().

Пример:

$user = $repo->findById($id);
$email = $user?->getContact()?->getEmail();
return $email ?? 'не указан';


Меньше лесенки из if, больше читаемости. Но помним: nullsafe — не магия, а аккуратный способ работать с пустыми результатами БД.

Вот так. Идем кодить дальше! 🚀

HTML:

Коллеги, хватит тянуть библиотеки ради одной всплывашки! В 2026 нативный Popover API уже спокойно живёт в продакшене, а многие всё ещё пишут велосипеды.

Раньше: плагины, z-index войны, слушатели на document, «а почему оно не закрывается?». Теперь достаточно двух атрибутов:





<button popovertarget="menu">Меню</button>
<div id="menu" popover>Я нативный поповер.</div>

Без JS. Браузер сам:

• поднимет элемент в top layer поверх всего;
• закроет его по клику вне и по Esc;
• возьмёт на себя базовую доступность;
• отдаст :popover-open и ::backdrop для стилей.

Если нужно не переключать, а явно открыть или закрыть:





<button
popovertarget="menu"
popovertargetaction="show"
>Открыть</button>

<button
popovertarget="menu"
popovertargetaction="hide"
>Закрыть</button>

Три режима:

1️⃣ popover="auto" — закрывается сам, вытесняет другие. Идеален для меню, фильтров, быстрых действий.

2️⃣ popover="hint" — мягкий режим для подсказок, которые не должны агрессивно всё закрывать.

3️⃣ popover="manual" — полный ручной контроль, без автозакрытия.

Из мастерской:

— Не делайте из поповера модальное окно. Для диалогов есть <dialog>.

— Не прячьте контент через display: none вручную — браузер сам управляет видимостью.

— Состояние стилизуйте через :popover-open, фон через ::backdrop.

— Для позиционирования у кнопки смотрите в сторону CSS Anchor Positioning.

Поддержка в 2026 отличная, но на старых проектах всё равно проверяйте. Это тот самый случай, когда можно удалить лишний JS и оставить чистую разметку.

Вот так. Идем кодить дальше! 🚀

КЕЙС:

Коллеги, небольшой клиент попросил внутреннюю CRM: клиенты, задачи, статусы, пара отчётов. Бюджет скромный, срок — две недели.

Стажёр предлагает: «Давайте честный MVC: роуты, контроллеры, модели, middleware, валидация, слои!» Звучит солидно. Но я посчитал: 15 сущностей, 3 экрана, 1 роль. Если строить дворец, не успеваем.

Выбрал классическое ООП: аккуратные классы, простые сервисы, тонкий слой БД. Без фреймворочной магии.


Что сделали:

— Client, Task, Status как сущности;
— ClientService и TaskService для логики;
— один входной файл с простым роутингом, PDO-обёртку и минимум зависимостей.


Почему это быстрее:

— меньше слоёв — меньше кода, который надо писать и отлаживать;
— не нужно спорить о «правильном» разделении ответственности там, где задача на один метод;
— правку в продакшене можно найти за 5 минут, а не блуждать по папкам.


Итог: рабочую версию отдали за 5 дней, поддержка занимает минуты, клиент доволен.

Спустя месяц клиент попросил экспорт в Excel. Добавили один метод в сервис и простой шаблон, а не переписывали половину проекта.

Важно: я не против паттернов. Для большого проекта с командой, ролями, API и сложными сценариями слои оправданы. Но для маленькой внутренней системы классическое ООП часто выигрывает у «архитектуры ради архитектуры».

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

Вот так. Идем кодить дальше! 🚀

ДАЙДЖЕСТ НОВОСТЕЙ:

Привет, коллеги! 👋 Пока одни паникуют из-за ИИ, мы с вами как всегда спокойно пилим проекты. Но следить за индустрией надо, поэтому я собрал для вас топ-5 новостей веб-разработки за эту неделю.

🚨 Срочный патч для Next.js и React!
Vercel выкатили внеочередное обновление безопасности, закрыв критические уязвимости в Next.js и React. Если у вас или ваших клиентов висят проекты на этом стеке, бегом обновляйтесь. Безопасность — это не шутки, коллеги.

🚀 Bun 1.4.3 залетел в прод!
Вышел новый релиз Bun 1.4.3, который снова хвастается космической скоростью установки пакетов. Если вы еще не пробовали заменить npm на Bun в своих пет-проектах или на фрилансе — самое время. Сэкономите кучу времени при CI/CD.

🎨 CSS и HTML в 2026 году
В нативном вебе активно закрепляются View Transitions, API Popover и Anchor Positioning. Это значит, что сложные попапы и плавные переходы между страницами теперь можно делать без тонны JavaScript. Фронтендерам на заметку — код станет чище, а клиенты будут в восторге!

🛠 Обновление Chrome DevTools
В Chrome DevTools добавили поддержку soft navigation в разделе Performance и улучшили работу с MCP-серверами. Теперь отлавливать просадки FPS и следить за производительностью SPA-приложений стало еще удобнее.

📝 WordPress 7.2 уже на подходе
Для тех, кто делает сайты для малого бизнеса: Beta 1 версии 7.2 выходит 20 октября. Это финальный крупный релиз года, так что готовимся обновлять клиентские сайты и тестировать новые фишки.

Какую из этих технологий вы уже щупаете в своих проектах? Делитесь в комментах! 👇

Вот так. Идем кодить дальше! 🚀

ФАКТЫ И ЦИФРЫ:

Сколько сайтов уже на HTTPS в 2026?

Коллеги, давайте без лирики — только цифры, которые заставляют задуматься.

По данным на осень 2026 года:

🔒 ~96–97% страниц, загружаемых в Chrome и Firefox, отдаются по HTTPS. Три года назад было 91%. Прогресс есть, но он замедлился.

🌐 Если смотреть на все зарегистрированные домены (включая заброшенные блоги 2014 года и лендинги, которые «потом доделаю»), картина скромнее — порядка 84–87%. То есть каждый 7-й сайт в интернете до сих пор встречает посетителя надписью «Не защищено».

📱 В мобильном трафике доля HTTPS ещё выше — ~98%, потому что браузеры на смартфонах просто пессимизируют и блокируют mixed-content агрессивнее.

🏢 Среди топ-10 000 сайтов мира — 99,2%. Тут без вариантов: нет сертификата — нет тебя в выдаче, нет в рекламных сетях, нет в доверии пользователя.


А теперь практический вывод, коллеги:

Если вы делаете сайт для малого бизнеса и клиент говорит «да ладно, у нас же не банк, зачем SSL» — покажите ему эти цифры. В 2026 году сайт без HTTPS — это как вывеска «Мы не заботимся о ваших данных». Конверсия падает на 12–18% просто из-за красного замка в адресной строке.

И да, бесплатный Let's Encrypt никто не отменял. Настройка — 15 минут. Автопродление — одна строчка в cron. Отмазка «дорого и сложно» умерла ещё в 2019-м.

Проверьте свои проекты сегодня. Особенно те, что «на поддержке с прошлого года». Один curl -I https://ваш-домен — и сразу видно, не протух ли сертификат.

Вот так. Идем кодить дальше! 🚀

ИЗ ПРОФЕССИИ:

Как задавать правильные вопросы на код-ревью

Коллеги, давайте честно: код-ревью у многих вызывает либо панику («сейчас меня разнесут»), либо скуку («опять формальность»). А всё потому, что мы не умеем задавать вопросы. Не отвечать на них — а именно задавать.


Из мастерской. Вот что реально работает:

❌ «Почему ты так написал?». Звучит как допрос. Собеседник сразу уходит в оборону.

✅ «Вижу, тут выбран подход X. Расскажи, почему не Y? Хочу понять контекст, вдруг я что-то упустил.». Вы не нападаете — вы учитесь. И даёте человеку пространство объяснить.

❌ «Это неправильно.». Точка. Без аргумента. Без альтернативы. Просто приговор.

✅ «А что будет, если сюда придёт null / пустой массив / юзер без токена? Давай разберём кейс.». Конкретный сценарий вместо абстрактного «неправильно».


Три правила, которые я вбил себе в голову за годы в продакшене:

1️⃣ Вопрос > Утверждение. «Может, здесь лучше вынести в хук?» работает в сто раз лучше, чем «Вынеси в хук». Вы предлагаете диалог, а не приказ.

2️⃣ Спрашивайте про «почему», а не про «что». Код вы видите сами. А вот контекст решения — нет. «Почему тут не useMemo? Есть причина?» — и вам ответят: «Да, ререндер тут дешевле, чем мемоизация». И вы станете чуть умнее.

3️⃣ Не копите вопросы в один комментарий-простыню. Лучше три коротких треда по делу, чем стена текста на 40 пунктов. Человеку физически тяжело это разгребать.

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

Код-ревью — это не экзамен. Это парное программирование, растянутое во времени. И чем лучше ваши вопросы, тем быстрее растёт вся команда.

Вот так. Идем кодить дальше! 🚀