Создание autoselect-компонента на Symfony/Vue. Часть 2.
Сегодня в серии:
1) Развернём проект с минимальной базы, подтягивая руками все пакеты
2) Научимся работать с БД в IDE
3) Научимся писать фикстуры и использовать рандомайзер имён
4) Затронем библиотеку lodash и axios, научимся лимитировать обращения к методам, отправлять запросы и получать ответ от бэка
5) Немного поигрались с CORS-политикой
6) Зафиналим наш компонент и будем крутыми ребятами
Залетай под кат!
https://telegra.ph/Sozdanie-autoselect-komponenta-na-SymfonyVue-CHast-2-06-11
Сегодня в серии:
1) Развернём проект с минимальной базы, подтягивая руками все пакеты
2) Научимся работать с БД в IDE
3) Научимся писать фикстуры и использовать рандомайзер имён
4) Затронем библиотеку lodash и axios, научимся лимитировать обращения к методам, отправлять запросы и получать ответ от бэка
5) Немного поигрались с CORS-политикой
6) Зафиналим наш компонент и будем крутыми ребятами
Залетай под кат!
https://telegra.ph/Sozdanie-autoselect-komponenta-na-SymfonyVue-CHast-2-06-11
Telegraph
Создание autoselect-компонента на Symfony/Vue. Часть 2.
Сегодня зафиналим наш autoselect-компонент. Но для начала расскажу, где я был: дорабатывал положенные 2 недели на старой работе и готовился к выходу на новую. Больше пока сказать не могу, кроме того, что компания большая, требуют там больше и работать надо…
Что такое assert'ы и зачем нужен Symfony-валидатор
Крайне полезная информация, которая в своё время стала для меня очень приятным открытием. Хочешь чистый код и грамотную валидацию?
Тебе сюда, бро.
Крайне полезная информация, которая в своё время стала для меня очень приятным открытием. Хочешь чистый код и грамотную валидацию?
Тебе сюда, бро.
Telegraph
Что такое assert'ы и зачем нужен Symfony-валидатор
Самая рутинная и бОльшая часть работы среднестатистического backend-разработчика - написание API, которое потом будут дёргать клиенты. Если, конечно, мы говорим о современной разработке, где front и back пишутся отдельно. Клиентской частью может быть как…
Пишем чат на web-сокетах в Symfony приложении
Подъехала годнота:
* Мы напишем чат с использованием web-socket'ов на PHP (да, это возможно)
* Мы научимся разворачивать Symfony-приложение в docker
* Познакомимся с новыми инструментами и технологиями
Клац, чтобы прочитать
Приятные новости - у нас на канале теперь ещё один автор :) Парень учится, но делает это быстро и разбирает крайне интересные темы, с одной из которых ты можешь познакомится в сегодняшней статье. Все вопросы можно обсудить в нашем чатике - https://t.me/junsenior_chat
Подъехала годнота:
* Мы напишем чат с использованием web-socket'ов на PHP (да, это возможно)
* Мы научимся разворачивать Symfony-приложение в docker
* Познакомимся с новыми инструментами и технологиями
Клац, чтобы прочитать
Приятные новости - у нас на канале теперь ещё один автор :) Парень учится, но делает это быстро и разбирает крайне интересные темы, с одной из которых ты можешь познакомится в сегодняшней статье. Все вопросы можно обсудить в нашем чатике - https://t.me/junsenior_chat
всем привет :) ребят, появилась идея немного попрогать в realtime - повисеть часа 2 на стриме
что думаете?)
обсудить можно в нашем чатике - https://t.me/junsenior_chat
что думаете?)
обсудить можно в нашем чатике - https://t.me/junsenior_chat
Telegram
dev notes chat
Общаемся, обсуждаем, задаём вопросы :)
CRUD - от сложного к простому
В этой статье рассматриваем, как типичные обращения к базе данных писались раньше, и как их можно написать сейчас.
Помимо этого, проект оборачивается в docker и вся работа выполняется из-под контейнера.
Интересно? Залетай под кат!
В этой статье рассматриваем, как типичные обращения к базе данных писались раньше, и как их можно написать сейчас.
Помимо этого, проект оборачивается в docker и вся работа выполняется из-под контейнера.
Интересно? Залетай под кат!
Redis: пишем URL-сокращатель
Сегодня у нас полезная теория и вкусная практика по Redis - key-value-хранилищу, способному решать огромный диапазон задач.
Чтобы понять всю красоту этой технологии - под катом пишем URL-сокращатель. Залетай, читай, комментируй.
Сегодня у нас полезная теория и вкусная практика по Redis - key-value-хранилищу, способному решать огромный диапазон задач.
Чтобы понять всю красоту этой технологии - под катом пишем URL-сокращатель. Залетай, читай, комментируй.
jun on Notion
Redis: пишем URL-сокращатель
Что это такое?
Тема следующей статьи
Anonymous Poll
11%
Событийная модель в Symfony
15%
Прикладная софтина на Go
28%
Web-приложение на Go
39%
Разбор структуры данных + алгоритма на ней
7%
Твой вариант
Пока готовим несколько интересных вещей, запушу интересную тему на обсуждение:
https://kinsta.com/blog/php-7-4/ - обзор нововведений и изменений в PHP 7.4, который вот-вот должен выйти.
Больше всего радует типизация, что-то вроде лямбда-функций и предзагрузка данных в память. Говорят, что можно будет загнать туда большую часть фреймворка и радоваться производительности :) Что думаете? Залетайте в чат, там всё обсудим :)
https://kinsta.com/blog/php-7-4/ - обзор нововведений и изменений в PHP 7.4, который вот-вот должен выйти.
Больше всего радует типизация, что-то вроде лямбда-функций и предзагрузка данных в память. Говорят, что можно будет загнать туда большую часть фреймворка и радоваться производительности :) Что думаете? Залетайте в чат, там всё обсудим :)
Kinsta®
What’s New in PHP 7.4 (Features, Deprecations, Speed)
PHP 7.4 is coming with new features, deprecations, and a boost in performance. Check this in-depth overview of what's new in PHP 7.4!
PHP + Go = ♥️ или RoadRunner в действии
Решил разобраться с RoadRunner - сервером, который умеет запускать несколько процессов PHP-приложения и стабилизировать нагрузку. Да, паттерн "один запрос - один процесс - смерть" больше не работает, и это круто.
Сегодня интегрируем RoadRunner и разбираемся, как работают воркеры. В следующей части разберёмся, как это работает внутри и поиграем с большими нагрузками.
#phpживи
Клац-клац, чтобы твой PHP не умирал на каждый запрос
Решил разобраться с RoadRunner - сервером, который умеет запускать несколько процессов PHP-приложения и стабилизировать нагрузку. Да, паттерн "один запрос - один процесс - смерть" больше не работает, и это круто.
Сегодня интегрируем RoadRunner и разбираемся, как работают воркеры. В следующей части разберёмся, как это работает внутри и поиграем с большими нагрузками.
#phpживи
Клац-клац, чтобы твой PHP не умирал на каждый запрос
jun on Notion
PHP + Go = ♥ или RoadRunner в действии | Notion
Привет.
К теме предыдущей статьи - отличное сравнение бенчмарков на PHP 7.4:
парни из Badoo сравнивают PHP 7.4, PHP 7.4 + Preload, RoadRunner и RoadRunner после оптимизации
А так же рассказывают, чем Preload отличается от OPCache и почему он зайка
Короче, к прочтению рекомендую - https://habr.com/ru/company/badoo/blog/472528/
Более того, как только PHP 7.4 релизнется, а будет это где-то в ноябре, постараюсь подробно рассмотреть и пощупать, как подключать Preload к Symfony-приложениям
парни из Badoo сравнивают PHP 7.4, PHP 7.4 + Preload, RoadRunner и RoadRunner после оптимизации
А так же рассказывают, чем Preload отличается от OPCache и почему он зайка
Короче, к прочтению рекомендую - https://habr.com/ru/company/badoo/blog/472528/
Более того, как только PHP 7.4 релизнется, а будет это где-то в ноябре, постараюсь подробно рассмотреть и пощупать, как подключать Preload к Symfony-приложениям
Хабр
Пробуем preload (PHP 7.4) и RoadRunner
Привет, Хабр! Мы часто пишем и говорим о производительности PHP: как мы ей занимаемся в целом, как мы сэкономили 1 млн долларов при переходе на PHP 7.0, а та...
Как найти работу? Резюме, собеседования, подготовка
Рассказываю, какие выводы я сделал из почти 10-ти пройденных за год собеседований, как они проходили, где я работал и почему мне не нравится энтерпрайз.
Надеюсь, мой опыт будет полезен. Залетай под кат!
Давайте немного попишем код на листочке...
Рассказываю, какие выводы я сделал из почти 10-ти пройденных за год собеседований, как они проходили, где я работал и почему мне не нравится энтерпрайз.
Надеюсь, мой опыт будет полезен. Залетай под кат!
Давайте немного попишем код на листочке...
jun on Notion
Как найти работу? Резюме, собеседования, подготовка | Notion
Привет. Настало время рассказать о том, как я искал работы, какие были собеседования и что там у меня спрашивали. Думаю, ты сможешь многое почерпнуть для себя о том, как сейчас проводят собеседования и что обычно ждёт работодатель.
Lumen + Docker + Websockets
Рассказываю как настроить систему websocket'ов через socket.io в Lumen
Зачем? Потому что могу, и ты сможешь - го читать
Рассказываю как настроить систему websocket'ов через socket.io в Lumen
Зачем? Потому что могу, и ты сможешь - го читать
Medium
Lumen + Docker + Websockets
Последнее время работаю с Lumen. Lumen — это урезанная версия Laravel, аля symfony-skeleton для Symfony. По этой причине большинство…
Вы просили паттерны? Их есть у меня.
Transactional outbox - паттерн, о котором на русском очень мало информации. Хотя понимание его структуры и схемы работы критически важно в случае создания системы логирования для твоего приложения.
Не хочешь влететь на штрафы, не сохранив факт оплаты от своего юзера? Тогда велком под кат - клац.
Transactional outbox - паттерн, о котором на русском очень мало информации. Хотя понимание его структуры и схемы работы критически важно в случае создания системы логирования для твоего приложения.
Не хочешь влететь на штрафы, не сохранив факт оплаты от своего юзера? Тогда велком под кат - клац.
Telegraph
Паттерн Transactional outbox
Что может быть сложного в логировании? Создал инстанс какого-нибудь Monolog'а, навтыкал $logger->info() под каждой строчкой, выполнение которой хотелось бы запечатлить в истории, и сиди себе посматривай в журнал. А вдруг где-то будет ошибка, лог не сохранится…
Тесты, ревью и флоу вокруг разработки
В одной из компаний, где я работал, была замечательная надпись на стене - "97 дней без багов". Это была одна из немногих компаний, где ревностно следили за чистотой кода, за процессом деплоя и флоу вокруг программирования, что позволяло выдавать стабильность работы всего портала. А портал был далеко не маленький.
Сейчас я опишу эти практики и, надеюсь, кто-то возьмёт их себе на вооружение.
В одной из компаний, где я работал, была замечательная надпись на стене - "97 дней без багов". Это была одна из немногих компаний, где ревностно следили за чистотой кода, за процессом деплоя и флоу вокруг программирования, что позволяло выдавать стабильность работы всего портала. А портал был далеко не маленький.
Сейчас я опишу эти практики и, надеюсь, кто-то возьмёт их себе на вооружение.
Telegraph
Тесты, ревью и флоу вокруг разработки
В одной из компаний, где я работал, была замечательная надпись на стене - "97 дней без багов". Это была одна из немногих компаний, где ревностно следили за чистотой кода, за процессом деплоя и флоу вокруг программирования, что позволяло выдавать стабильность…
С наступающим, друзья! Кода без ошибок, работы без нервов и новогоднего настроения!
https://twitter.com/podbolotnik/status/1211968223471648769?s=20
https://twitter.com/podbolotnik/status/1211968223471648769?s=20
Twitter
цитаты из лапенко
Включи что-нибудь новогоднее — такое, чтобы в крови конфетти закрутились! https://t.co/wQ62CMLwL2
Если ты можешь сделать плохой код лучше - сделай
В одной из компаний где я работал было очень хорошее правило, которое называли тех.долгом: если по задаче ты затронул файл, код в котором оставляет желать лучшего - поправь то, что можешь.
Это не означает, что ты должен начать рефакторить весь проект, переходя из файла в файл, нет. Это означает, что если ты можешь выделить немного времени, дедлайны не горят, спринт ещё не заканчивается и в целом нет каких-то блоков - выдели время и исправь очевидно плохие места.
Например, на моём текущем проекте более 1кк строк кода. Проект писали десятки людей на протяжении многих лет. Часто бывает так, что открывая какой-либо файл я вижу комментарий за 2015 год - "Это может пригодится, пока не удаляем". Окей, Ctrl + F → поиск → нет соответствий. Значит, не то что можно - это нужно удалить. Или, например, ты видишь deprecated-модуль. Посмотри аннотации - скорее всего, этому модулю много лет и он, вероятно, уже нигде не используется и был переписан. Удаляй. Если бизнесу это не пригодилось в течении пары лет - дальше тоже не пригодится. Сомневаешься? Уточни у лида или товарищей по команде, которые на проекте долгое время - использовалось ли это где-то в последние годы. Скорее всего они даже не вспомнят что это.
Бывает, что какой-то контроллер писали в режиме хаоса - были правки на бой, ребята написали пелену кода прямо в контроллере и, поправив ошибку, к этому файлу никто не вернулся. Создай класс-сервис, вынеси туда эту пелену и заинжекти его в класс-контроллер, если у тебя на это есть время. А ещё круче будет, если параллельно к этому ты напишешь тесты.
Увидел функцию из PHP5, которая перечёркнута и ты знаешь её новый аналог - примени (главное версию PHP на сервере проверь; если 5 - не правь, и подумай о смене работы). Так, например, в старом PHP многое делалось через строки - в строке могли объявить функцию, могли вызвать её через строку. Всё это уродство можно заменить, поэтому если увидел - твой долг это поправить. Как писал дядя Мартин - ты должен спорить с бизнесом и доказывать ему, что рефакторинг - это важно, прежде всего, для самого бизнеса.
Так же хорошая практика поделить задачу и рефакторинг на разные коммиты - на PR лид скажет тебе спасибо.
В одной из компаний где я работал было очень хорошее правило, которое называли тех.долгом: если по задаче ты затронул файл, код в котором оставляет желать лучшего - поправь то, что можешь.
Это не означает, что ты должен начать рефакторить весь проект, переходя из файла в файл, нет. Это означает, что если ты можешь выделить немного времени, дедлайны не горят, спринт ещё не заканчивается и в целом нет каких-то блоков - выдели время и исправь очевидно плохие места.
Например, на моём текущем проекте более 1кк строк кода. Проект писали десятки людей на протяжении многих лет. Часто бывает так, что открывая какой-либо файл я вижу комментарий за 2015 год - "Это может пригодится, пока не удаляем". Окей, Ctrl + F → поиск → нет соответствий. Значит, не то что можно - это нужно удалить. Или, например, ты видишь deprecated-модуль. Посмотри аннотации - скорее всего, этому модулю много лет и он, вероятно, уже нигде не используется и был переписан. Удаляй. Если бизнесу это не пригодилось в течении пары лет - дальше тоже не пригодится. Сомневаешься? Уточни у лида или товарищей по команде, которые на проекте долгое время - использовалось ли это где-то в последние годы. Скорее всего они даже не вспомнят что это.
Бывает, что какой-то контроллер писали в режиме хаоса - были правки на бой, ребята написали пелену кода прямо в контроллере и, поправив ошибку, к этому файлу никто не вернулся. Создай класс-сервис, вынеси туда эту пелену и заинжекти его в класс-контроллер, если у тебя на это есть время. А ещё круче будет, если параллельно к этому ты напишешь тесты.
Увидел функцию из PHP5, которая перечёркнута и ты знаешь её новый аналог - примени (главное версию PHP на сервере проверь; если 5 - не правь, и подумай о смене работы). Так, например, в старом PHP многое делалось через строки - в строке могли объявить функцию, могли вызвать её через строку. Всё это уродство можно заменить, поэтому если увидел - твой долг это поправить. Как писал дядя Мартин - ты должен спорить с бизнесом и доказывать ему, что рефакторинг - это важно, прежде всего, для самого бизнеса.
Так же хорошая практика поделить задачу и рефакторинг на разные коммиты - на PR лид скажет тебе спасибо.
Выжигающие задачи
Почему люди увольняются? Я увольнялся по нескольким факторам: предложение на более вкусное место работы, несработка с командой, отвратительное руководство.
В том случае, когда человек увольняется из-за проблем на работе, а не из-за предложения новой, что-то как правило служит точкой невозврата - достал лист, написал заявление, отнёс начальнику. И, как мне кажется, такой точкой нередко выступают определённого рода задачи.
Как правило, такая задача летит мимо спринта. Аналитики нет, оценки - тоже. Формулировка крайне скудная - реализовать *описание фичи в нескольких словах*.
Ключевая проблема тут - это отношение руководства к процессу работы команды в целом. Но, если уже тебе довелось в такой команде работать, то не остаётся ничего другого, кроме как научится такие задачи определять.
В очередной раз столкнулся на работе с прекрасной постановкой - реализовать возможность *функционал фичи*. Аналитики нет, в спринт задачу вкинули уже после его запуска. Совокупность факторов - и я не разбираясь перевёл статус задачи в "In progress". И через пару дней пообещал себе, что без предварительной оценки, какие бы факторы вокруг не происходили, задачи больше браться в работу не будут.
Основные критерии:
1. Описание задачи затрагивает несколько логических разделов в коде. Например, моя задача, если бы я получше вчитался в описание, затрагивала ядро генерации PDF-файлов и подразумевала большой объем кода в совершенно другом месте для реализации бизнес-логики.
Как это можно было решить? Вчитаться на планировании, поставить задачу на аналитику, выявить проблему и разбить задачу на 2 подзадачи, поочерёдно втягивая их в спринт.
2. Нет чёткой оценки времени. "Да делай, ещё есть время" - самый паршивый для разработчика ответ. В голове сразу мысли: "Сколько? Когда могут спросить? До конца спринта? Или уведём в следующий?". Ответы такого формата делают только одно - заставляют торопиться, из-за чего возникают ошибки, в PR пушатся всё новые комментарии и цикл "правки - PR - комментарии" раскручивается.
3. Нет приёмочный критериев (для тех, кто в танке - приёмочные критерии - одноимённый раздел, который можно активировать у карточки задачи в jira). Это, наверное, самая важная часть, резюмирующая большинство из вышесказанного. Если тебе набросали макет, дали краткую формулировку, но в разделе с приёмочными критериями пусто - уже стоит задуматься, а брать ли задачу или стоит сначала обсудить. Когда менеджмент/команда/лид описывает то, что он хочет видеть на выходе - это уже половина решения. На одном из предыдущих мест работы в процессе формулировки приёмочных мы с командой могли обсуждать задачу несколько встреч подряд, находя всё новые и новые моменты, разбивая задачу на новые подзадачи и описывания новые блокирующие связи. Потеря времени? Как бы ни так. После такого планирования весь пулл подзадач выполняется за пару дней, что бизнесу идёт только на пользу.
Я ни в коем случае не говорю о том, чтобы ты требовал резжевать задачу за тебя. Нет, разжевать надо тебе, но сделать это нужно перед тем, как браться за работу.
Так вот, чтобы не сидеть весь спринт над одной задачей, не слушать вопросы менеджмента о её статусе, не ловить подводные камни (они всегда будут, но большинство можно выявить на планировании) и не смотреть на десятки комментариев в PR - учись ловить такие задачи, задавать вопросы, и не приступать к выполнению, пока не будет всех ответов. Лучше потерять время на берегу.
Почему люди увольняются? Я увольнялся по нескольким факторам: предложение на более вкусное место работы, несработка с командой, отвратительное руководство.
В том случае, когда человек увольняется из-за проблем на работе, а не из-за предложения новой, что-то как правило служит точкой невозврата - достал лист, написал заявление, отнёс начальнику. И, как мне кажется, такой точкой нередко выступают определённого рода задачи.
Как правило, такая задача летит мимо спринта. Аналитики нет, оценки - тоже. Формулировка крайне скудная - реализовать *описание фичи в нескольких словах*.
Ключевая проблема тут - это отношение руководства к процессу работы команды в целом. Но, если уже тебе довелось в такой команде работать, то не остаётся ничего другого, кроме как научится такие задачи определять.
В очередной раз столкнулся на работе с прекрасной постановкой - реализовать возможность *функционал фичи*. Аналитики нет, в спринт задачу вкинули уже после его запуска. Совокупность факторов - и я не разбираясь перевёл статус задачи в "In progress". И через пару дней пообещал себе, что без предварительной оценки, какие бы факторы вокруг не происходили, задачи больше браться в работу не будут.
Основные критерии:
1. Описание задачи затрагивает несколько логических разделов в коде. Например, моя задача, если бы я получше вчитался в описание, затрагивала ядро генерации PDF-файлов и подразумевала большой объем кода в совершенно другом месте для реализации бизнес-логики.
Как это можно было решить? Вчитаться на планировании, поставить задачу на аналитику, выявить проблему и разбить задачу на 2 подзадачи, поочерёдно втягивая их в спринт.
2. Нет чёткой оценки времени. "Да делай, ещё есть время" - самый паршивый для разработчика ответ. В голове сразу мысли: "Сколько? Когда могут спросить? До конца спринта? Или уведём в следующий?". Ответы такого формата делают только одно - заставляют торопиться, из-за чего возникают ошибки, в PR пушатся всё новые комментарии и цикл "правки - PR - комментарии" раскручивается.
3. Нет приёмочный критериев (для тех, кто в танке - приёмочные критерии - одноимённый раздел, который можно активировать у карточки задачи в jira). Это, наверное, самая важная часть, резюмирующая большинство из вышесказанного. Если тебе набросали макет, дали краткую формулировку, но в разделе с приёмочными критериями пусто - уже стоит задуматься, а брать ли задачу или стоит сначала обсудить. Когда менеджмент/команда/лид описывает то, что он хочет видеть на выходе - это уже половина решения. На одном из предыдущих мест работы в процессе формулировки приёмочных мы с командой могли обсуждать задачу несколько встреч подряд, находя всё новые и новые моменты, разбивая задачу на новые подзадачи и описывания новые блокирующие связи. Потеря времени? Как бы ни так. После такого планирования весь пулл подзадач выполняется за пару дней, что бизнесу идёт только на пользу.
Я ни в коем случае не говорю о том, чтобы ты требовал резжевать задачу за тебя. Нет, разжевать надо тебе, но сделать это нужно перед тем, как браться за работу.
Так вот, чтобы не сидеть весь спринт над одной задачей, не слушать вопросы менеджмента о её статусе, не ловить подводные камни (они всегда будут, но большинство можно выявить на планировании) и не смотреть на десятки комментариев в PR - учись ловить такие задачи, задавать вопросы, и не приступать к выполнению, пока не будет всех ответов. Лучше потерять время на берегу.
Технический материал писать долго и временами сложно.
Переписывать документацию, как я это делал по-началу, больше как-то не хочется :) А сложные кейсы, возникающие на работе, порой описываются (по вечерам) за неделю-две.
Чтобы канал не простаивал по паре недель без материала, думаю добавить контента и хочу посоветоваться с вами, что вам будет интересно? Хайпить на тупых картинках, репостить новости из других каналов и заливать прочей грязью ленту я не буду.
Заметки с/о работе, как и технические статьи, я буду продолжать писать, это никуда не пропадёт :)
Переписывать документацию, как я это делал по-началу, больше как-то не хочется :) А сложные кейсы, возникающие на работе, порой описываются (по вечерам) за неделю-две.
Чтобы канал не простаивал по паре недель без материала, думаю добавить контента и хочу посоветоваться с вами, что вам будет интересно? Хайпить на тупых картинках, репостить новости из других каналов и заливать прочей грязью ленту я не буду.
Заметки с/о работе, как и технические статьи, я буду продолжать писать, это никуда не пропадёт :)
Утренний дайджест на junsenior
Всем кофе, пацаны. Утро первого дня рабочей недели знаменует новую рубрику на канале - дайджест новостей из мира технологий, которые нам интересны. Сегодня кое что вкусное из мира PHP за прошедшую неделю.
Наверняка ты слышал про асинхронный PHP (привет, ReactPHP). Вероятно, если ты подписан на мой канал, ты также слышал о Symfony.
Так вот, их объединили и запаковали в отдельный фреймворк - DriftPHP (да, мы получаем Symfony-архитектуру, реализующую событийную модель).
Обязательно посмотри свежее интервью с разработчиком (с очаровательным русским акцентом интервьюера) DriftPHP - https://www.youtube.com/watch?v=uebhqc2BZXw
Вдохновившись, я решил написать материал, где мы установим, настроим и напишем небольшое приложение посредством этого фреймворка.
Тестирование - неотъемлемая часть разработки. Важно следить и за тем, чтобы тестовый фреймворк был в актуальном состоянии, чтобы не пропустить патчи безопасности и новые фишки.
7-ого февраля зарелизили PHPUnit 9. Теперь, для написания тестов нам нужно иметь версию PHP не ниже 7.3 и можно использовать PHP7 синтакс. Помимо этого, многие методы были помечены устаревшими (например, у MockBuilder устаревшим объявлен setMethods()). Все изменения описаны в официальном релизе - https://phpunit.de/announcements/phpunit-9.html, рекомендую ознакомиться.
1 февраля в статусе черновика опубликовали RFC с предложением добавить переопределение арифметических операторов и операторов конкатенации - https://wiki.php.net/rfc/userspace_operator_overloading
Хорошо это или плохо - тема активно обсуждается. Лично мне эта идея импонирует, и я бы активно использовал такую возможность.
Ещё одна тема, активно обсуждаемая на реддите - это появление возможности кидать PR в репозиторий с английской документацией - https://github.com/php/doc-en.
Как по мне - это действительно круто. В случае адекватного ревью документация может расшириться примерами, описанием неявных мест и подводных камней.
Всем кофе, пацаны. Утро первого дня рабочей недели знаменует новую рубрику на канале - дайджест новостей из мира технологий, которые нам интересны. Сегодня кое что вкусное из мира PHP за прошедшую неделю.
Наверняка ты слышал про асинхронный PHP (привет, ReactPHP). Вероятно, если ты подписан на мой канал, ты также слышал о Symfony.
Так вот, их объединили и запаковали в отдельный фреймворк - DriftPHP (да, мы получаем Symfony-архитектуру, реализующую событийную модель).
Обязательно посмотри свежее интервью с разработчиком (с очаровательным русским акцентом интервьюера) DriftPHP - https://www.youtube.com/watch?v=uebhqc2BZXw
Вдохновившись, я решил написать материал, где мы установим, настроим и напишем небольшое приложение посредством этого фреймворка.
Тестирование - неотъемлемая часть разработки. Важно следить и за тем, чтобы тестовый фреймворк был в актуальном состоянии, чтобы не пропустить патчи безопасности и новые фишки.
7-ого февраля зарелизили PHPUnit 9. Теперь, для написания тестов нам нужно иметь версию PHP не ниже 7.3 и можно использовать PHP7 синтакс. Помимо этого, многие методы были помечены устаревшими (например, у MockBuilder устаревшим объявлен setMethods()). Все изменения описаны в официальном релизе - https://phpunit.de/announcements/phpunit-9.html, рекомендую ознакомиться.
1 февраля в статусе черновика опубликовали RFC с предложением добавить переопределение арифметических операторов и операторов конкатенации - https://wiki.php.net/rfc/userspace_operator_overloading
Хорошо это или плохо - тема активно обсуждается. Лично мне эта идея импонирует, и я бы активно использовал такую возможность.
Ещё одна тема, активно обсуждаемая на реддите - это появление возможности кидать PR в репозиторий с английской документацией - https://github.com/php/doc-en.
Как по мне - это действительно круто. В случае адекватного ревью документация может расшириться примерами, описанием неявных мест и подводных камней.
