Одержимый кодом🔥
213 subscribers
22 photos
14 links
Привет, разработчик! Я Данил Щуцкий (CutCode) backend PHP developer, одержимый своим делом! На этом канале публикую свои мысли и истории из личного опыта.
Youtube: https://www.youtube.com/@CutCodeRu
ЛС: @leeto_telegram
Download Telegram
Привет всем! 🚀

Я Данил Щуцкий. Бэкенд-разработчик, основатель проекта CutCode (канал YouTube и Laravel-комьюнити), создатель open-source админ-панели MoonShine.

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

Здесь я буду публиковать свои заметки, размышления и наблюдения о жизни, работе, технологиях и многом другом.
6
Одержимость не приобретается, это часть характера

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

Меня часто спрашивают и удивляются: как мне удается работать, брать дополнительные проекты, записывать контент для канала, вести блог на хабре, контрибьютить в open source и при этом оставлять энергию на личную жизнь?

Я и сам удивлялся, за счет чего мне это удается? Ответ прост - я одержим свои делом! И это придаёт мне сил. 💪

Наверное, у вас возникает вопрос: "А как приобрести эту одержимость? Ведь я тоже люблю писать код, думаю это мое призвание. Но при этом меня хватает только на работу в найме, и к концу дня я обычно выжат как лимон. А на выходных и смотреть на код не могу, да и в целом часто выгораю."🤷‍♀️

Ответ также прост, либо вы себя обманываете и это не ваше любимое дело, либо одержимость вам не дана от природы.

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

Прошло время. Я повзрослел, интересы стали меняться и юношеское желание каждый день заниматься рэпом, перешло в желание работать с кодом!

Конечно же я не подразумеваю под работой с кодом печатание функций и строк в редакторе - я имею ввиду профессию разработчика, работа над большими, интересными и значимыми проектами, которые приносят пользу: CutCode (обучение разработке на Laravel), книга Ninja guide, open-source MoonShine. По аналогии с рэпом, я постоянно вовлечен в процесс - фиксирую в телефонных заметках интересные мысли когда гуляю, часто в голове пишу код, а перед сном строю планы по разработке на завтра.

*️⃣Как вывод:
Любимое дело меняется, а одержимость остается - это часть личности.
Любимое дело*Одержимость=Бесконечная энергия.

А что думаете вы по поводу любимого занятия и одержимости?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍72
Докер стал недоступен 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. Протестировано на Голландии.

Давайте обсудим ситуацию! Если есть проверенные варианты решения проблемы - поделитесь!
Прощай Spatie/Ignition!😐

С версии 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
😱7🔥21
Законтрибьютил сахара ребятам в Buggregator/trap https://github.com/buggregator/trap/releases/tag/1.8.0

Кстати рекомендую Buggregator! После обзора вошел в мой повседневный dev рацион 🪲
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤‍🔥1🔥1
Век живи - век учись. Или случаи когда интуиция подводит.

Пост о моих наблюдениях по объекту реквеста 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’) параметр с роута.
🔥12❤‍🔥51🤔1🍓1
Только что пощупал IDX от Google! Делюсь своими впечатлениями, собственно канал для этого и создан.

Щупал в процессе общения в чате MoonShine: задали вопрос, я порекомендовал решение проблемы и сразу его протестил в IDX.

И если коротко, то впечатлен, супер крутая песочница, чтобы быстро в несколько секунд развернуть тот же Laravel, набросать или проверить решение.

Как видно на скрине, нам сразу доступно web-превью (также можно открыть в соседней вкладке). Hot reload присутствует💪

Есть прикольная фича - проект можно расшарить (мне будет полезно по MoonShine, чтобы быстро показать решение). Но чтобы расшарить надо будет указать email товарища.

Можно быстро отсканировать QR-code на мобиле и глянуть как там дела с адаптивной версткой.

Есть ИИ помощник в виде Gemini.

Из проблем (думаю потому что пока в бете или возможно только у меня):
- Автокомплит только по нативным функциям php (импорты тоже придется писать самостоятельно);
- Нельзя сделать публичный проект/расшарить проект просто по ссылке (хотя бы web-превью), чтобы можно было демонстрировать сниппеты кода и сразу показывать как это работает (для меня было бы киллерфичей)

Вообщем, как песочница огонь (если закрыть все проблемы).
🔥12👍5🤔3❤‍🔥1
Муки выбора. Нейминг геттеров и сеттеров

Недавно я задумался о правилах нейминга геттеров и сеттеров. Всегда придерживался правила с префиксом 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. А что вы думаете об этом? Думаю, что это очень простая, но важная тема, о которой может высказаться разработчик любого уровня!
🔥9👍6❤‍🔥22
Привет, коллеги!
Уже около года публикую статьи на Хабре, и сегодня обнаружил, что вошел в первую сотню рейтинга пользователей. Это значительное достижение для меня, и я очень рад, что мои материалы находят отклик у такой широкой аудитории.

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

Спасибо всем, кто читает и поддерживает мои статьи на Habr! Буду стараться продолжать создавать качественный контент!
👍23🔥73❤‍🔥1🎉1💯1