🦢 jenssegers/agent - PHP пакет с интеграцией с Laravel, предоставляющий инструменты для разбора UserAgent'а
https://github.com/jenssegers/agent
https://github.com/jenssegers/agent
GitHub
GitHub - jenssegers/agent: 👮 A PHP desktop/mobile user agent parser with support for Laravel, based on Mobiledetect
👮 A PHP desktop/mobile user agent parser with support for Laravel, based on Mobiledetect - jenssegers/agent
Большой список материалов для изучения асинхронного программирования на php: что такое корутины и причем тут генераторы, промисы, реактивное программирование, потоки, популярные решения вроде amphp, reactphp, swoole и много других репозиториев под разные задачи, использующие асинхронные решения.
https://github.com/elazar/asynchronous-php
https://github.com/elazar/asynchronous-php
Очередная статья от Матьяса Нобака с вызывающим названием: «Не тестируйте конструкторы».
https://matthiasnoback.nl/2021/05/dont-test-constructors/
https://matthiasnoback.nl/2021/05/dont-test-constructors/
matthiasnoback.nl
Don't test constructors
Common constructor problems will be caught by your static analyzer | Exposing state breaks encapsulation | The test doesn't explain why you need the property assignments | Replace the constructor unit test with some higher-level test | What if I just want…
PHP | PHPBench
PHPBench - это инструмент для проверки производительности вашего PHP-приложения.
https://github.com/phpbench/phpbench
PHPBench - это инструмент для проверки производительности вашего PHP-приложения.
https://github.com/phpbench/phpbench
ashallendesign/short-url - пакет для создания коротких ссылок.
https://github.com/ash-jc-allen/short-url
https://github.com/ash-jc-allen/short-url
GitHub
GitHub - ash-jc-allen/short-url: A Laravel package for creating shortened URLs for your web apps.
A Laravel package for creating shortened URLs for your web apps. - ash-jc-allen/short-url
Forwarded from Пых (Валентин Удальцов)
Continious Integration
CI — must have для проекта любого размера. CI повышает качество кодовой базы, дисциплинирует команду и сокращает количество и продолжительность ревью.
Идеи проверок на базе нашего пайплайна в Happy Inc.:
• кодстайл PHP-кода (PHP CS Fixer, PHP_CodeSniffer),
• статический анализ PHP-кода (Psalm, PHPStan, PHPMD),
• валидность composer.json/lock (composer validate),
• наличие лишних пакетов (composer-unused),
• отсутствие пакетов в списке явных зависимостей (ComposerRequireChecker),
• уязвимости в пакетах (Roave Security Advisories, Local PHP Security Checker),
• синтаксис Yaml-файлов (Symfony Yaml),
• синтаксис Twig-шаблонов в проектах на Symfony (
• соответствие типов инъекций контейнера Symfony (
• депрекации сервисов и конфигов Symfony (
• маппинг Doctrine и соответствие ему схемы БД (
• связность/зацепление и направление зависимостей (Deptrac, dePHPend),
• ну и конечно же, тесты!
Также обратите внимание на репозиторий Static analysis tools for PHP и доклад 25+ инструментов для аудита кода.
CI — must have для проекта любого размера. CI повышает качество кодовой базы, дисциплинирует команду и сокращает количество и продолжительность ревью.
Идеи проверок на базе нашего пайплайна в Happy Inc.:
• кодстайл PHP-кода (PHP CS Fixer, PHP_CodeSniffer),
• статический анализ PHP-кода (Psalm, PHPStan, PHPMD),
• валидность composer.json/lock (composer validate),
• наличие лишних пакетов (composer-unused),
• отсутствие пакетов в списке явных зависимостей (ComposerRequireChecker),
• уязвимости в пакетах (Roave Security Advisories, Local PHP Security Checker),
• синтаксис Yaml-файлов (Symfony Yaml),
• синтаксис Twig-шаблонов в проектах на Symfony (
bin/console lint:twig),• соответствие типов инъекций контейнера Symfony (
bin/console lint:container),• депрекации сервисов и конфигов Symfony (
bin/console debug:container --deprecations),• маппинг Doctrine и соответствие ему схемы БД (
doctrine:schema:validate),• связность/зацепление и направление зависимостей (Deptrac, dePHPend),
• ну и конечно же, тесты!
Также обратите внимание на репозиторий Static analysis tools for PHP и доклад 25+ инструментов для аудита кода.
Пых
Continious Integration CI — must have для проекта любого размера. CI повышает качество кодовой базы, дисциплинирует команду и сокращает количество и продолжительность ревью. Идеи проверок на базе нашего пайплайна в Happy Inc.: • кодстайл PHP-кода (PHP CS…
Хорошее объяснение того что нужно делать на CI
☠️Nginx vs. Apache: практические примеры отличий двух веб-серверов.
https://www.digitalocean.com/community/tutorials/apache-vs-nginx-practical-considerations
https://www.digitalocean.com/community/tutorials/apache-vs-nginx-practical-considerations
Digitalocean
Apache vs Nginx: Practical Considerations | DigitalOcean
Apache and Nginx are the two most common open source web servers in the world. Together, they are responsible for serving over 50% of traffic on the internet…
🥢Пишем тесты без использования фреймворков для создания моков. [EN]
https://blog.frankdejonge.nl/testing-without-mocking-frameworks/
https://blog.frankdejonge.nl/testing-without-mocking-frameworks/
Frank on Software
Testing without mocking frameworks.
By creating your own fakes, you can free yourself from using mocking frameworks. Find out how you can benefit from it.
Forwarded from Beer::PHP 🍺 (Кирилл Сулимовский)
The Everybody Poops Rule (Все какают)
👉 Как мне кажется отличная аллегория, которая применима к программированию. Все мы постоянно сталкиваемся с ситуациями, когда в коде приходится идти на компромиссы. Иногда из-за нехватки времени, иногда для избежания оверинжиниринга, иногда из-за несовершенства системы, нехватки знаний и т.д. И мы сознательно оставляем в коде "дерьмо", ведь не каждая часть нашего приложения должна быть идеальной.
📌 Все какают. Но дома это делают не в каждой комнате. У вас есть специальная комната, в которой вы какаете, ставите дверь, и только там это делаете.
Да, звучит странно, но зато хорошо запоминается 😂
❗️ Важно понимать, что этот процесс управляемый. Данное правило как раз помогает с этим жить при помощи сокрытия и инкапсуляции. Если код изолирован — не важно, что скрывается за интерфейсом. Главное, что мы гадим в определенных частях и "держим дверь закрытой".
👍 Конечно, у подобных мест тоже следует определить стандарты. То есть нельзя совсем забить и втулить туда какой-то
❗️ Также то, что вы можете всё изолировать — не значит, что это нужно делать всегда и везде. Прежде чем это сделать задайте себе несколько вопросов:
• Как часто код будет использоваться?
• Как долго его можно не трогать?
• Является ли это основным доменом в вашей компании? (здесь лучше этого не делать)
👍 Еще круче — сразу планировать возможный рефакторинг. То, что сегодня вы изолировали может понадобиться бизнесу в будущем или где-то аукнуться в самый неподходящий момент. Круто быть к этому готовым. Лучше всего это место задокументировать, чтобы точно знать о всех отклонениях.
#junior #oop #source
👉 Как мне кажется отличная аллегория, которая применима к программированию. Все мы постоянно сталкиваемся с ситуациями, когда в коде приходится идти на компромиссы. Иногда из-за нехватки времени, иногда для избежания оверинжиниринга, иногда из-за несовершенства системы, нехватки знаний и т.д. И мы сознательно оставляем в коде "дерьмо", ведь не каждая часть нашего приложения должна быть идеальной.
📌 Все какают. Но дома это делают не в каждой комнате. У вас есть специальная комната, в которой вы какаете, ставите дверь, и только там это делаете.
Да, звучит странно, но зато хорошо запоминается 😂
❗️ Важно понимать, что этот процесс управляемый. Данное правило как раз помогает с этим жить при помощи сокрытия и инкапсуляции. Если код изолирован — не важно, что скрывается за интерфейсом. Главное, что мы гадим в определенных частях и "держим дверь закрытой".
👍 Конечно, у подобных мест тоже следует определить стандарты. То есть нельзя совсем забить и втулить туда какой-то
God Object с методами в 1000 строк, вызывающие запросы к БД в foreach. Здесь важно найти баланс. Это тоже непростая работа. Помните, положив код "за дверь" он не становится лучше, а значит учитывайте риски того, что вам придётся его переписывать.❗️ Также то, что вы можете всё изолировать — не значит, что это нужно делать всегда и везде. Прежде чем это сделать задайте себе несколько вопросов:
• Как часто код будет использоваться?
• Как долго его можно не трогать?
• Является ли это основным доменом в вашей компании? (здесь лучше этого не делать)
👍 Еще круче — сразу планировать возможный рефакторинг. То, что сегодня вы изолировали может понадобиться бизнесу в будущем или где-то аукнуться в самый неподходящий момент. Круто быть к этому готовым. Лучше всего это место задокументировать, чтобы точно знать о всех отклонениях.
#junior #oop #source
А может на PHP?
☀️PHP Дайджест № 204 (17 – 31 мая 2021) https://habr.com/ru/post/560158/
Для тех кому лень читать я буду в течении нескольких дней выкладывать короткие и самые интересные отрывки из дайджеста