Latest posts
adelf on programming
11 Aug, 11:03
forwarded from @podlodkanews
Podlodka #489 – LaravelLaravel любят за скорость разработки, ругают за магию и регулярно обвиняют в том, что он плодит жирные контроллеры. Вместе с Аделем Файзрахмановым – автором плагина Laravel Idea для PhpStorm и книги «Архитектура сложных веб-приложений. С примерами на Laravel» – разбираемся, что именно делает этот фреймворк лучшим на сегодняшний день способом писать код на PHP.🎧 Слушать выпуск👀 Смотреть выпуск👉Предложить себя в подкаст
adelf on programming
4 Jun, 10:35
Под прошлым постом развернулась дискуссия, которая в очередной раз показала, что в программинге незыблемо только одно правило: it depends.Для типичных монолитных по всем координатам приложений где все свалено в одну кучу: модели в одной папке, контроллеры в другой - то мое правило работает. Там если именовать все в стиле Model/User, Controller/User, т.е. ClassType/Feature, то быстро образуется бардак.Однако продвинутые системы, в которых много классов, быстро переформатируются в папки по доменам, или контекстам, или фичам. И получается, например, домен тот же самый User, папка App/Domain/User, а классы мы именуем DomainName/ClassType. Классы будут App/Domain/User/Controller, User/Handler, User/Model, etc.Поскольку логика приложения красиво разорвана на эти куски, то User/Model редко когда юзают в одном и том же файле с Post/Model, например(это вам не Eloquent модели!). И неудобствadelf on programming
1 Jun, 11:42edited
Часто слышу мнение в стиле "неймспейс это тоже часть имени класса. Используйте его"И, как правило, это выливается в такие классы как App\Controllers\User, App\Models\User, App\Resources\User.Не надо так.Upd: Люди потребовали деталей. Надо примерно так: UserController, UserResource. Вообще, по логике и UserModel надо бы, но один ключевой тип классов можно выделить как основной и суффиксы там не добавлять.
adelf on programming
20 Apr, 13:35
Хранение дефолтных значенийДля новой фичи мне нужно хранить токен Sentry и домен, где этот Sentry работает. Почти у всех он sentry.com, не так много кто использует self-hosted решения. Есть в общем два варианта как хранить эти данные. Либо мы храним все:"token": "<token>", "domain": "sentry.com(или свой какой-то)" }Либо, когда у нас само вырисовывается некое значение по умолчанию, которое будет у большинства, мы можем хранить только токен, если домен у нас sentry.com. А значение домена храним только тогда, когда оно отличается от дефолтного."token": "<token>" // предполагаем, что домен стандартный }В JetBrains IDE предпочитают второе. У них тысячи настроек, но если они являются значениями по умолчанию, то они не хранятся, а при загрузке просто берется то самое значение. Плюса здесь два. Первый - экономия памяти. Иногда копеечная, а иногда весьма значительная. В случаеadelf on programming
18 Jan, 13:07
Исследую сейчас исходники Livewire4. Прекрасный пример, когда две совсем разные логики пытаются всунуть в один метод.Тут можно добавить компонент либо на основе класса, либо на основе вью. И эти две логики не имеют ничего общего.Весь этот код буквально плачет и кричит: тут должны быть два метода! addClassComponent() и addViewComponent()public function addComponent($name = null, $viewPath = null, $class = null): void { // Support $name being used a single argument for class-based components... if ($name !== null && $class === null && $viewPath === null) { $class = $name;$name = null; }if (is_object($class)) { $class = get_class($class); }// Support $class being used a single named argument for class-based components...
Related Channels
Other channels in the same section of the catalogue.
