Channel: Одержимый кодом🔥
Привет всем! 🚀
Я Данил Щуцкий. Бэкенд-разработчик, основатель проекта CutCode (канал YouTube и Laravel-комьюнити), создатель open-source админ-панели MoonShine.
Добро пожаловать на мой Telegram-канал, который я создал с целью вести свой личный блог, делиться и обсуждать с вами свои наблюдения, мысли и идеи.
Здесь я буду публиковать свои заметки, размышления и наблюдения о жизни, работе, технологиях и многом другом.
Я Данил Щуцкий. Бэкенд-разработчик, основатель проекта CutCode (канал YouTube и Laravel-комьюнити), создатель open-source админ-панели MoonShine.
Добро пожаловать на мой Telegram-канал, который я создал с целью вести свой личный блог, делиться и обсуждать с вами свои наблюдения, мысли и идеи.
Здесь я буду публиковать свои заметки, размышления и наблюдения о жизни, работе, технологиях и многом другом.
Одержимость не приобретается, это часть характера
В этом посте речь пойдёт об одержимости любимым делом. Важно чтобы оно было именно любимым, но этого не всегда достаточно для успеха, давайте расскажу поподробнее.
Меня часто спрашивают и удивляются: как мне удается работать, брать дополнительные проекты, записывать контент для канала, вести блог на хабре, контрибьютить в open source и при этом оставлять энергию на личную жизнь?
Я и сам удивлялся, за счет чего мне это удается? Ответ прост - я одержим свои делом! И это придаёт мне сил.💪
Наверное, у вас возникает вопрос: "А как приобрести эту одержимость? Ведь я тоже люблю писать код, думаю это мое призвание. Но при этом меня хватает только на работу в найме, и к концу дня я обычно выжат как лимон. А на выходных и смотреть на код не могу, да и в целом часто выгораю."🤷♀️
Ответ также прост, либо вы себя обманываете и это не ваше любимое дело, либо одержимость вам не дана от природы.
Давайте объясню на себе. В юности я занимался рэпом, обожал делать музыку, гулял и сочинял текст в голове, складывал строки перед сном, просыпался и что-то записывал, был одержим, я мог заниматься этим бесконечно. Но ведь у меня были и другие увлечения - я также занимался спортом, катался на велосипеде, рисовал, играл в футбол: все эти занятия мне нравились, но я не был ими одержим.
Прошло время. Я повзрослел, интересы стали меняться и юношеское желание каждый день заниматься рэпом, перешло в желание работать с кодом!
Конечно же я не подразумеваю под работой с кодом печатание функций и строк в редакторе - я имею ввиду профессию разработчика, работа над большими, интересными и значимыми проектами, которые приносят пользу: CutCode (обучение разработке на Laravel), книга Ninja guide, open-source MoonShine. По аналогии с рэпом, я постоянно вовлечен в процесс - фиксирую в телефонных заметках интересные мысли когда гуляю, часто в голове пишу код, а перед сном строю планы по разработке на завтра.
*️⃣ Как вывод:
Любимое дело меняется, а одержимость остается - это часть личности.
Любимое дело*Одержимость=Бесконечная энергия. ♾
А что думаете вы по поводу любимого занятия и одержимости?
В этом посте речь пойдёт об одержимости любимым делом. Важно чтобы оно было именно любимым, но этого не всегда достаточно для успеха, давайте расскажу поподробнее.
Меня часто спрашивают и удивляются: как мне удается работать, брать дополнительные проекты, записывать контент для канала, вести блог на хабре, контрибьютить в open source и при этом оставлять энергию на личную жизнь?
Я и сам удивлялся, за счет чего мне это удается? Ответ прост - я одержим свои делом! И это придаёт мне сил.
Наверное, у вас возникает вопрос: "А как приобрести эту одержимость? Ведь я тоже люблю писать код, думаю это мое призвание. Но при этом меня хватает только на работу в найме, и к концу дня я обычно выжат как лимон. А на выходных и смотреть на код не могу, да и в целом часто выгораю."
Ответ также прост, либо вы себя обманываете и это не ваше любимое дело, либо одержимость вам не дана от природы.
Давайте объясню на себе. В юности я занимался рэпом, обожал делать музыку, гулял и сочинял текст в голове, складывал строки перед сном, просыпался и что-то записывал, был одержим, я мог заниматься этим бесконечно. Но ведь у меня были и другие увлечения - я также занимался спортом, катался на велосипеде, рисовал, играл в футбол: все эти занятия мне нравились, но я не был ими одержим.
Прошло время. Я повзрослел, интересы стали меняться и юношеское желание каждый день заниматься рэпом, перешло в желание работать с кодом!
Конечно же я не подразумеваю под работой с кодом печатание функций и строк в редакторе - я имею ввиду профессию разработчика, работа над большими, интересными и значимыми проектами, которые приносят пользу: CutCode (обучение разработке на Laravel), книга Ninja guide, open-source MoonShine. По аналогии с рэпом, я постоянно вовлечен в процесс - фиксирую в телефонных заметках интересные мысли когда гуляю, часто в голове пишу код, а перед сном строю планы по разработке на завтра.
Любимое дело меняется, а одержимость остается - это часть личности.
Любимое дело*Одержимость=Бесконечная энергия. ♾
А что думаете вы по поводу любимого занятия и одержимости?
Please open Telegram to view this post
VIEW IN TELEGRAM
Докер стал недоступен 30 мая 2024 г. Что известно?
При открытии сайта появляется надпись:
403 Forbidden
Since Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria. If you are not in one of these cities, countries, or regions and are blocked, please reach out to https://hub.docker.com/support/contact/
России в абзаце с пояснением проблемы не указано. Написал в техподдержку. Ответ:
Hi there,
Thank you for contacting Docker Support.
At this time we are no longer doing business with Russian or Belarusian companies and have removed the ability to purchase subscriptions from these countries.
https://www.docker.com/blog/dockers-response-to-the-invasion-of-ukraine/
Since Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Russia, Iran, North Korea, Republic of Crimea, Sudan, and Syria.
Best regards,
Docker Support
Получается что доступ к Docker России и Беларуси ограничили.
В настоящий момент у меня на Docker завязано много проектов, и есть довольно большая зависимость от этого сервиса. Что можно сделать сегодня для дальнейшего использования Docker?
У меня получилось создать новый аккаут Docker с использованием VPN. Протестировано на Голландии.
Давайте обсудим ситуацию! Если есть проверенные варианты решения проблемы - поделитесь!
При открытии сайта появляется надпись:
403 Forbidden
Since Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria. If you are not in one of these cities, countries, or regions and are blocked, please reach out to https://hub.docker.com/support/contact/
России в абзаце с пояснением проблемы не указано. Написал в техподдержку. Ответ:
Hi there,
Thank you for contacting Docker Support.
At this time we are no longer doing business with Russian or Belarusian companies and have removed the ability to purchase subscriptions from these countries.
https://www.docker.com/blog/dockers-response-to-the-invasion-of-ukraine/
Since Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Russia, Iran, North Korea, Republic of Crimea, Sudan, and Syria.
Best regards,
Docker Support
Получается что доступ к Docker России и Беларуси ограничили.
В настоящий момент у меня на Docker завязано много проектов, и есть довольно большая зависимость от этого сервиса. Что можно сделать сегодня для дальнейшего использования Docker?
У меня получилось создать новый аккаут Docker с использованием VPN. Протестировано на Голландии.
Давайте обсудим ситуацию! Если есть проверенные варианты решения проблемы - поделитесь!
Прощай Spatie/Ignition!😐
С версии 11.9, Spatie/ignition больше не входит в коробку Laravel. Это означает, что в режиме дебага нас теперь будет ждать более компактная версия с минимальным набором информации.
Spatie/ignition был важным инструментом в Laravel, предоставляя подробную информацию об ошибках и помогало разработчикам быстро находить и исправлять проблемы. Видимо, с новым обновлением, Laravel идет в сторону упрощения и минимализма.
Но не стоит печалиться и ностальгировать по старой доброй (и более подробной) странице с ошибками. Есть хорошая новость - вы можете продолжить пользоваться привычным инструментом! Просто установите spatie/laravel-ignition в свой проект:
, или добавьте зависимость:
А что бы вы убрали из коробки Laravel?
С версии 11.9, Spatie/ignition больше не входит в коробку Laravel. Это означает, что в режиме дебага нас теперь будет ждать более компактная версия с минимальным набором информации.
Spatie/ignition был важным инструментом в Laravel, предоставляя подробную информацию об ошибках и помогало разработчикам быстро находить и исправлять проблемы. Видимо, с новым обновлением, Laravel идет в сторону упрощения и минимализма.
Но не стоит печалиться и ностальгировать по старой доброй (и более подробной) странице с ошибками. Есть хорошая новость - вы можете продолжить пользоваться привычным инструментом! Просто установите spatie/laravel-ignition в свой проект:
composer require spatie/laravel-ignition
, или добавьте зависимость:
"spatie/laravel-ignition": "^2.4"
А что бы вы убрали из коробки Laravel?
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Законтрибьютил сахара ребятам в Buggregator/trap https://github.com/buggregator/trap/releases/tag/1.8.0
Кстати рекомендую Buggregator! После обзора вошел в мой повседневный dev рацион🪲
Кстати рекомендую Buggregator! После обзора вошел в мой повседневный dev рацион
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
Release v1.8.0 · buggregator/trap
1.8.0 (2024-05-29)
What's Changed
Add tr() and td() functions by @roxblnfk in #102
Add trap()->code() sugar by @lee-to in #103
Change release generation type to Github API by @lotyp in #106...
What's Changed
Add tr() and td() functions by @roxblnfk in #102
Add trap()->code() sugar by @lee-to in #103
Change release generation type to Github API by @lotyp in #106...
Век живи - век учись. Или случаи когда интуиция подводит.
Пост о моих наблюдениях по объекту реквеста Laravel и небольшие заметки. Итак, я всегда думал, что
и
это одно и то же, но в процессе разработки MoonShine было замечено странное поведение (на самом деле с объектом реквеста Ларавел такое было часто). Пришлось заглянуть под капот и удивится.
Первый вариант это сбор всего с реквеста и обращение по ключу, вот такой “красивый” код:
Второй же вариант еще более красивый, и под капотом мы не дергаем тот же самый метод get, а обращаемся к магическому __get (редко встречаются такие вызовы):
Который, в свою очередь, работает через класс Arr и позволяет обращаться к параметрам реквеста через точку (для вложенности). При этом если ничего не найдет, то дополнительно поищет в параметрах роута. Это намного тяжелее и результат может быть непредсказуемым. На самом деле меня и смутило, что мы еще лезем в роут, в объекте реквеста еще есть сессии (не удивился бы, если бы полезли сразу и туда)
На заметку. Есть еще
Который также через Arr::get соберет все параметры, но не полезет в роут
Ну и всегда был отдельный метод для получения исключительно параметров с роута
Как раз его вызов я и не ожидал, когда дергал request(‘key’).
Тот случай, когда сахар вреден и легко запутаться.
Не перестаю удивляться решениям в реквесте Laravel и все чаще заглядываю под капот, когда речь идет о взаимодействии с Laravel.
В итоге:
request(‘key’) лучше не использовать. Я думаю врядли вам потребуется получать значение отовсюду откуда только можно.
request()->get(‘key’) нормально, но без вложенности через точку.
request()->input(‘parent.key’) наверное, идеально подойдет для подобных манипуляций, плюс вложенность.
request()->route(‘key’) параметр с роута.
Пост о моих наблюдениях по объекту реквеста Laravel и небольшие заметки. Итак, я всегда думал, что
request(‘key’)
и
request()->get(‘key’)
это одно и то же, но в процессе разработки MoonShine было замечено странное поведение (на самом деле с объектом реквеста Ларавел такое было часто). Пришлось заглянуть под капот и удивится.
Первый вариант это сбор всего с реквеста и обращение по ключу, вот такой “красивый” код:
return $this->query->all()[$key];
return $this->request->all()[$key];
Второй же вариант еще более красивый, и под капотом мы не дергаем тот же самый метод get, а обращаемся к магическому __get (редко встречаются такие вызовы):
$value = app('request')->__get($key);
Который, в свою очередь, работает через класс Arr и позволяет обращаться к параметрам реквеста через точку (для вложенности). При этом если ничего не найдет, то дополнительно поищет в параметрах роута. Это намного тяжелее и результат может быть непредсказуемым. На самом деле меня и смутило, что мы еще лезем в роут, в объекте реквеста еще есть сессии (не удивился бы, если бы полезли сразу и туда)
public function __get($key)
{
return Arr::get($this->all(), $key, fn () => $this->route($key));
}
На заметку. Есть еще
request()->input(‘key’)
Который также через Arr::get соберет все параметры, но не полезет в роут
Ну и всегда был отдельный метод для получения исключительно параметров с роута
request()->route(‘key’)
Как раз его вызов я и не ожидал, когда дергал request(‘key’).
Тот случай, когда сахар вреден и легко запутаться.
Не перестаю удивляться решениям в реквесте Laravel и все чаще заглядываю под капот, когда речь идет о взаимодействии с Laravel.
В итоге:
request(‘key’) лучше не использовать. Я думаю врядли вам потребуется получать значение отовсюду откуда только можно.
request()->get(‘key’) нормально, но без вложенности через точку.
request()->input(‘parent.key’) наверное, идеально подойдет для подобных манипуляций, плюс вложенность.
request()->route(‘key’) параметр с роута.
Только что пощупал IDX от Google! Делюсь своими впечатлениями, собственно канал для этого и создан.
Щупал в процессе общения в чате MoonShine: задали вопрос, я порекомендовал решение проблемы и сразу его протестил в IDX.
И если коротко, то впечатлен, супер крутая песочница, чтобы быстро в несколько секунд развернуть тот же Laravel, набросать или проверить решение.
Как видно на скрине, нам сразу доступно web-превью (также можно открыть в соседней вкладке). Hot reload присутствует💪
Есть прикольная фича - проект можно расшарить (мне будет полезно по MoonShine, чтобы быстро показать решение). Но чтобы расшарить надо будет указать email товарища.
Можно быстро отсканировать QR-code на мобиле и глянуть как там дела с адаптивной версткой.
Есть ИИ помощник в виде Gemini.
Из проблем (думаю потому что пока в бете или возможно только у меня):
- Автокомплит только по нативным функциям php (импорты тоже придется писать самостоятельно);
- Нельзя сделать публичный проект/расшарить проект просто по ссылке (хотя бы web-превью), чтобы можно было демонстрировать сниппеты кода и сразу показывать как это работает (для меня было бы киллерфичей)
Вообщем, как песочница огонь (если закрыть все проблемы).
Щупал в процессе общения в чате MoonShine: задали вопрос, я порекомендовал решение проблемы и сразу его протестил в IDX.
И если коротко, то впечатлен, супер крутая песочница, чтобы быстро в несколько секунд развернуть тот же Laravel, набросать или проверить решение.
Как видно на скрине, нам сразу доступно web-превью (также можно открыть в соседней вкладке). Hot reload присутствует💪
Есть прикольная фича - проект можно расшарить (мне будет полезно по MoonShine, чтобы быстро показать решение). Но чтобы расшарить надо будет указать email товарища.
Можно быстро отсканировать QR-code на мобиле и глянуть как там дела с адаптивной версткой.
Есть ИИ помощник в виде Gemini.
Из проблем (думаю потому что пока в бете или возможно только у меня):
- Автокомплит только по нативным функциям php (импорты тоже придется писать самостоятельно);
- Нельзя сделать публичный проект/расшарить проект просто по ссылке (хотя бы web-превью), чтобы можно было демонстрировать сниппеты кода и сразу показывать как это работает (для меня было бы киллерфичей)
Вообщем, как песочница огонь (если закрыть все проблемы).
Муки выбора. Нейминг геттеров и сеттеров
Недавно я задумался о правилах нейминга геттеров и сеттеров. Всегда придерживался правила с префиксом
Возникла идея сформировать комплексный подход к неймингу и пользоваться исключительно им. Чтобы все контрибьюторы уже огромного фреймворка MoonShine их придерживались и "говорили на одном языке"!
В целом, наверное, местами каша в нейминге появилась из-за продолжительной дружбы с Laravel, где также присутствует разнообразие и мы наблюдаем
Ну а в чем собственно проблема? Спросите вы.
Проблема в том, что
В реальности портянка кода будет даже больше, но уже и эта бросается в глаза.
Исходя из этого примера, формируем первое правило:
1. Для fluent-методов используем сеттер без префикса set.
Ок, вроде разобрались. В глаза попался геттер для получения имени поля - $field->name()
Выглядит красиво и большой соблазн присутствует оставить как есть. Но! Это также публичный метод, плюс у него есть аргумент
2. Геттеры всегда с префиксом get, исключения обсуждаем в процессе ревью пул реквестов
После мыслей по геттерам, снова решил взглянуть на сеттеры под новым углом и размышляю, как поступить с fluent всегда без префикса, но если метод используется очень редко, то с префиксом? Но если метод очень редкий, то возможно и fluent лишний?!
В общем пока оставляем правила 1 и 2. А что вы думаете об этом? Думаю, что это очень простая, но важная тема, о которой может высказаться разработчик любого уровня!
Недавно я задумался о правилах нейминга геттеров и сеттеров. Всегда придерживался правила с префиксом
getName, setName, но недавно при рефакторинге MoonShine я заметил кашу в нейминге, которая имеет право на жизнь, но это не тру.Возникла идея сформировать комплексный подход к неймингу и пользоваться исключительно им. Чтобы все контрибьюторы уже огромного фреймворка MoonShine их придерживались и "говорили на одном языке"!
В целом, наверное, местами каша в нейминге появилась из-за продолжительной дружбы с Laravel, где также присутствует разнообразие и мы наблюдаем
getKey, setRelations в моделях, но при этом видим path(), host(), fullUrlWithQuery(array $query) .Ну а в чем собственно проблема? Спросите вы.
Проблема в том, что
getName, setName не подойдет для всех ситуаций, особенно если речь о fluent interface. Просто представьте большой билдер:TableBuilder::make()
->setFields($fields)
->setItems($items)
->setTdAttributes($attributes)
->setAsyncUrl($url)
->set...
->set...
->set...
В реальности портянка кода будет даже больше, но уже и эта бросается в глаза.
Исходя из этого примера, формируем первое правило:
1. Для fluent-методов используем сеттер без префикса set.
Ок, вроде разобрались. В глаза попался геттер для получения имени поля - $field->name()
Выглядит красиво и большой соблазн присутствует оставить как есть. Но! Это также публичный метод, плюс у него есть аргумент
name(?int $index = null) и на вид он ничем не будет отличаться от сеттера и будет вводить в заблуждение. Я искал компромисс между красотой и здравым смыслом, и метался между правилом - для геттеров всегда использовать префикс get, а также использовать префикс get для не публичных геттеров и редко используемых. Остальные геттеры, часто используемые для красоты интерфейса, оставить без префикса, но здравый смысл победил и так появилось второе правило: 2. Геттеры всегда с префиксом get, исключения обсуждаем в процессе ревью пул реквестов
После мыслей по геттерам, снова решил взглянуть на сеттеры под новым углом и размышляю, как поступить с fluent всегда без префикса, но если метод используется очень редко, то с префиксом? Но если метод очень редкий, то возможно и fluent лишний?!
В общем пока оставляем правила 1 и 2. А что вы думаете об этом? Думаю, что это очень простая, но важная тема, о которой может высказаться разработчик любого уровня!
Привет, коллеги!
Уже около года публикую статьи на Хабре, и сегодня обнаружил, что вошел в первую сотню рейтинга пользователей. Это значительное достижение для меня, и я очень рад, что мои материалы находят отклик у такой широкой аудитории.
Несколько дней я побуду среди топовых хабровчан (может с кем-то знаменитым познакомлюсь). Однако, хочу поделиться опытом взаимодействия с Habr - по себе заметил, что комьюнити на Habr порой бывает недружелюбным. Это не уменьшает ценность платформы и уникальных знаний, которыми здесь делятся, но иногда хотелось бы более конструктивной критики и доброжелательности. В CutCode-комьюнити намного уютнее. Надеюсь, что со временем Habr станет более приветливым местом для авторов.
Спасибо всем, кто читает и поддерживает мои статьи на Habr! Буду стараться продолжать создавать качественный контент!
Уже около года публикую статьи на Хабре, и сегодня обнаружил, что вошел в первую сотню рейтинга пользователей. Это значительное достижение для меня, и я очень рад, что мои материалы находят отклик у такой широкой аудитории.
Несколько дней я побуду среди топовых хабровчан (может с кем-то знаменитым познакомлюсь). Однако, хочу поделиться опытом взаимодействия с Habr - по себе заметил, что комьюнити на Habr порой бывает недружелюбным. Это не уменьшает ценность платформы и уникальных знаний, которыми здесь делятся, но иногда хотелось бы более конструктивной критики и доброжелательности. В CutCode-комьюнити намного уютнее. Надеюсь, что со временем Habr станет более приветливым местом для авторов.
Спасибо всем, кто читает и поддерживает мои статьи на Habr! Буду стараться продолжать создавать качественный контент!
Obsidian или Notion?
Использую Obsidian для заметок и планирования. Очень нравится скорость его работы, md-редактор и связи между заметками.👍
Но есть и минусы - сложно делится заметками и синхронизировать информацию между устройствами.
Знакомый посоветовал посмотреть Notion. Много готовых решений (шаблонов), фишки по автоматизации и возможности для командной работы.
❓А что вы используете для заметок и планирования личной жизни и работы?
Использую Obsidian для заметок и планирования. Очень нравится скорость его работы, md-редактор и связи между заметками.👍
Но есть и минусы - сложно делится заметками и синхронизировать информацию между устройствами.
Знакомый посоветовал посмотреть Notion. Много готовых решений (шаблонов), фишки по автоматизации и возможности для командной работы.
❓А что вы используете для заметок и планирования личной жизни и работы?
📢 Мой опыт разработки open-source проекта на примере MoonShine
Привет, коллеги! Написал еще одну статьей на Хабре, где я рассказываю о своем опыте разработки MoonShine. С какими я столкнулся проблемами и как их решал:
https://habr.com/ru/articles/833618
Буду рад вашим отзывам и комментариям! 🚀
Привет, коллеги! Написал еще одну статьей на Хабре, где я рассказываю о своем опыте разработки MoonShine. С какими я столкнулся проблемами и как их решал:
https://habr.com/ru/articles/833618
Буду рад вашим отзывам и комментариям! 🚀
Хабр
Open-source. Плюсы и минусы на примере MoonShine Laravel
Привет, коллеги! Сегодня хочу поделиться опытом создания и развития open-source проекта MoonShine , которому стукнуло уже 2 года. 🎉 Идея возникновения Всё началось с идеи в telegram-чате Laravel...
Pest vs PHPUnit: Моя история выбора🧐
История нашего знакомства с Pest началась с обзора на моем канале. Тогда я еще не вполне осознавал все преимущества этого подхода, но меня впечатлило отсутствие классов, что значительно сокращало тестовые файлы. Также привлекли удобный fluent-интерфейс для написания тестов, функциональный подход и возможность группировки тестов для удобного вызова.
Мы решили рискнуть и перевести нашу open-source админку MoonShine с PHPUnit на Pest. В процессе возникли вопросы, о которых поговорим позже, но мы решили идти до конца, полагая, что это дело привычки: нужно просто принять новый, красивый подход.
Не буду ходить вокруг да около и сразу скажу главную мысль итогового обзора:
Не стоит использовать библиотеку, с которой невозможно работать без вспомогательных плагинов для IDE.
Pest как раз такая библиотека, и сейчас вы поймете почему.
Мы используем динамические свойства внутри функций (под капотом магические __get, __set, но сути не меняет). Классов нет, но создаются свойства, которые IDE не может определить между тестовыми функциями. Даже с плагином свойства подсвечиваются как нечто инородное, что со временем начинает резать глаз.
Подход через fluent от функции expect в реальном проекте выглядит так (смотреть обложку поста).
Постоянно хочется разбить на несколько expect, но плагин настаивает на соблюдении концепции и использовании and.
Преимущество группировок и их быстрых вызовов утратило актуальность с появлением атрибутов с группами в новых версиях PHPUnit, что выглядит даже удобнее.
В итоге, лично для меня плюсов не осталось, а минусы очевидны: тесты сложнее читать, без плагина их невозможно писать и понимать, много костылей.
Мы решили вернуться к PHPUnit и отказаться от Pest. Я рад, что мой курс по изучению продвинутых методик Laravel на примере интернет-магазина, часть 2 (API), задержался, так как планировал делать его с Pest. Теперь понимаю, что не стоит.
Однако, несмотря на этот негативный опыт, я не жалею, что попробовал Pest. Любой опыт, даже неудачный, позволяет лучше понимать свои инструменты и делать более осознанный выбор в будущем. Подробнее мысли изложил в ролике - https://youtu.be/1tWhPTmLW34
История нашего знакомства с Pest началась с обзора на моем канале. Тогда я еще не вполне осознавал все преимущества этого подхода, но меня впечатлило отсутствие классов, что значительно сокращало тестовые файлы. Также привлекли удобный fluent-интерфейс для написания тестов, функциональный подход и возможность группировки тестов для удобного вызова.
Мы решили рискнуть и перевести нашу open-source админку MoonShine с PHPUnit на Pest. В процессе возникли вопросы, о которых поговорим позже, но мы решили идти до конца, полагая, что это дело привычки: нужно просто принять новый, красивый подход.
Не буду ходить вокруг да около и сразу скажу главную мысль итогового обзора:
Не стоит использовать библиотеку, с которой невозможно работать без вспомогательных плагинов для IDE.
Pest как раз такая библиотека, и сейчас вы поймете почему.
Мы используем динамические свойства внутри функций (под капотом магические __get, __set, но сути не меняет). Классов нет, но создаются свойства, которые IDE не может определить между тестовыми функциями. Даже с плагином свойства подсвечиваются как нечто инородное, что со временем начинает резать глаз.
Подход через fluent от функции expect в реальном проекте выглядит так (смотреть обложку поста).
Постоянно хочется разбить на несколько expect, но плагин настаивает на соблюдении концепции и использовании and.
Преимущество группировок и их быстрых вызовов утратило актуальность с появлением атрибутов с группами в новых версиях PHPUnit, что выглядит даже удобнее.
В итоге, лично для меня плюсов не осталось, а минусы очевидны: тесты сложнее читать, без плагина их невозможно писать и понимать, много костылей.
Мы решили вернуться к PHPUnit и отказаться от Pest. Я рад, что мой курс по изучению продвинутых методик Laravel на примере интернет-магазина, часть 2 (API), задержался, так как планировал делать его с Pest. Теперь понимаю, что не стоит.
Однако, несмотря на этот негативный опыт, я не жалею, что попробовал Pest. Любой опыт, даже неудачный, позволяет лучше понимать свои инструменты и делать более осознанный выбор в будущем. Подробнее мысли изложил в ролике - https://youtu.be/1tWhPTmLW34
Please open Telegram to view this post
VIEW IN TELEGRAM
Привет, коллеги!
Как всё успевать и не выгореть в хаосе задач? Я прошел путь от работы по найму, где моё время организовывали за меня, до самостоятельного управления множеством проектов.
Оформил статью на Хабре, в которой делюсь приемами тайм-менеджмента, которые помогают мне оставаться продуктивным и не терять мотивацию.
Прочитайте, если хотите узнать, как справляться с многозадачностью и находить баланс между работой и отдыхом:
https://habr.com/ru/articles/835572/
Как всё успевать и не выгореть в хаосе задач? Я прошел путь от работы по найму, где моё время организовывали за меня, до самостоятельного управления множеством проектов.
Оформил статью на Хабре, в которой делюсь приемами тайм-менеджмента, которые помогают мне оставаться продуктивным и не терять мотивацию.
Прочитайте, если хотите узнать, как справляться с многозадачностью и находить баланс между работой и отдыхом:
https://habr.com/ru/articles/835572/
Хабр
Плохой тайм-менеджмент — официальный спонсор твоих выгораний
Друзья, всем привет! В этой статье хочу поделиться с вами своим опытом и наблюдениями по тайм-менеджменту: как всё успевать и не выгорать в огромных джунглях бесконечных задач, проектов и общения....
Друзья, приветствую!
Как вы уже, наверное, знаете, Notion заблокировал аккаунты пользователей из России. И как назло, я только начал привыкать к этому удобному инструменту. 🙄 Выяснил все подробности у техподдержки, и вот что они сказали:
- Если вы всегда использовали Notion бесплатно и никогда не оплачивали подписку с российской карты, ваше Notion-пространство не будет удалено!
- Однако, если вы хоть раз оплачивали Notion с российской карты, ваше пространство будет удалено. В этом случае, вам стоит перенести свои данные на другой Notion-аккаунт, который всегда был бесплатным. (Завтра я напишу подробнее о том, как совершить переезд с одного аккаунта на другой.)
- Доступ к Notion для всех пользователей из России в будущем будет закрыт. Если вы пользовались бесплатной версией или не оплачивали с российской карты, то получите доступ снова, когда покинете страну или включите VPN.
Что касается меня, я не платил за Notion российской картой и надеюсь, что мне повезет и буду дальше пользоваться аккуратненько. Но на всякий случай, лучше сделать резервную копию своих данных ближе к 9 сентября.
А вы как относитесь к этой ситуации? Переезжаете с Notion? Делитесь своим опытом и мнением в комментариях! 💬
Как вы уже, наверное, знаете, Notion заблокировал аккаунты пользователей из России. И как назло, я только начал привыкать к этому удобному инструменту. 🙄 Выяснил все подробности у техподдержки, и вот что они сказали:
- Если вы всегда использовали Notion бесплатно и никогда не оплачивали подписку с российской карты, ваше Notion-пространство не будет удалено!
- Однако, если вы хоть раз оплачивали Notion с российской карты, ваше пространство будет удалено. В этом случае, вам стоит перенести свои данные на другой Notion-аккаунт, который всегда был бесплатным. (Завтра я напишу подробнее о том, как совершить переезд с одного аккаунта на другой.)
- Доступ к Notion для всех пользователей из России в будущем будет закрыт. Если вы пользовались бесплатной версией или не оплачивали с российской карты, то получите доступ снова, когда покинете страну или включите VPN.
Что касается меня, я не платил за Notion российской картой и надеюсь, что мне повезет и буду дальше пользоваться аккуратненько. Но на всякий случай, лучше сделать резервную копию своих данных ближе к 9 сентября.
А вы как относитесь к этой ситуации? Переезжаете с Notion? Делитесь своим опытом и мнением в комментариях! 💬
Forwarded from Новости от CutCode
Привет, коллеги!
Появилась возможность заказать маскотов PHP - слонов со скидкой! 🐘
Как на фотке, но в реальности они еще красивее и на ощупь пушистые.🙏 Не забываем, что скоро новый год, и слоник - отличный подарок.
Цена будет 2000 рублей за слона (если наберем от 50 штук). Заявки оставляйте в комментариях к этому посту.
Все говорят, купи слона. А ты возьми и купи.
Появилась возможность заказать маскотов PHP - слонов со скидкой! 🐘
Как на фотке, но в реальности они еще красивее и на ощупь пушистые.
Цена будет 2000 рублей за слона (если наберем от 50 штук). Заявки оставляйте в комментариях к этому посту.
Все говорят, купи слона. А ты возьми и купи.
Please open Telegram to view this post
VIEW IN TELEGRAM
HTML Embed Code: