Одержимый кодом🔥

Кому слона?

Друзья, приветствую! Как вы уже, наверное, знаете, Notion заблокировал аккаунты пользователей из России. И как назло, я только начал привыкать к этому удобному инструменту. 🙄 Выяснил все подробности у техподдержки, и вот что они сказали: - Если вы всегда использовали Notion бесплатно и никогда не оплачивали подписку с российской карты, ваше Notion-пространство не будет удалено! - Однако, если вы хоть раз оплачивали Notion с российской карты, ваше пространство будет удалено. В этом случае, вам стоит перенести свои данные на другой Notion-аккаунт, который всегда был бесплатным. (Завтра я напишу подробнее о том, как совершить переезд с одного аккаунта на другой.) - Доступ к Notion для всех пользователей из России в будущем будет закрыт. Если вы пользовались бесплатной версией или не оплачивали с российской карты, то получите доступ снова, когда покинете страну или включите VPN. Что касается меня, я не платил за Notion российской картой и надеюсь, что мне повезет и буду дальше пользоваться аккуратненько. Но на всякий случай, лучше сделать резервную копию своих данных ближе к 9 сентября. А вы как относитесь к этой ситуации? Переезжаете с Notion? Делитесь своим опытом и мнением в комментариях! 💬

Привет, коллеги! Как всё успевать и не выгореть в хаосе задач? Я прошел путь от работы по найму, где моё время организовывали за меня, до самостоятельного управления множеством проектов. Оформил статью на Хабре, в которой делюсь приемами тайм-менеджмента, которые помогают мне оставаться продуктивным и не терять мотивацию. Прочитайте, если хотите узнать, как справляться с многозадачностью и находить баланс между работой и отдыхом: https://habr.com/ru/articles/835572/

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

📢 Мой опыт разработки open-source проекта на примере MoonShine Привет, коллеги! Написал еще одну статьей на Хабре, где я рассказываю о своем опыте разработки MoonShine. С какими я столкнулся проблемами и как их решал: https://habr.com/ru/articles/833618 Буду рад вашим отзывам и комментариям! 🚀

Obsidian или Notion? Использую Obsidian для заметок и планирования. Очень нравится скорость его работы, md-редактор и связи между заметками.👍 Но есть и минусы - сложно делится заметками и синхронизировать информацию между устройствами. Знакомый посоветовал посмотреть Notion. Много готовых решений (шаблонов), фишки по автоматизации и возможности для командной работы. ❓А что вы используете для заметок и планирования личной жизни и работы?

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

Муки выбора. Нейминг геттеров и сеттеров Недавно я задумался о правилах нейминга геттеров и сеттеров. Всегда придерживался правила с префиксом 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. А что вы думаете об этом? Думаю, что это очень простая, но важная тема, о которой может высказаться разработчик любого уровня!