В первой статье рассказывалось про кодогенераторы, но почему-то здесь контроллер написан вручную. Я понимаю, что новичкам не обязательно знать про ресурсы, но банальные конвенции именования методов лучше соблюдать, раз уж Вы учите их работе с фреймворком. Потом будет проще переучиться.
Удаление обязательно делать методом POST(лучше, конечно, через method_field('DELETE'), но списываем на новичков) и вкидывать csrf-token. Зачем-то же он нужен…
Конструкцию array(...) не видел уже миллион лет :)
Переменная $uploadSuccess присваивается, но нигде не используется. Там вообще лучше обернуть в try...catch, но, опять же, новичкам хватит и простой проверки if ($uploadSuccess) {...}.
Это вообще огонь :)
$album = Album::with('Photos')->find($id);
$albums = Album::with('Photos')->get();
Ну и про code style уже говорили. Вообще не понимаю людей, жадных на пробелы…
Почему же? У врачей, как-раз таки, 3-хбалльная шкала. Врач второй категории, первой и высшей. И, хотя я не знаю конкретных кейсов, думаю свитчинг из одной специализации в другую вряд ли делает врача "джуном". В медицине тоже есть базовые знания о том, как устроен человеческий организм, обязательные для всех специальностей. И багаж этих знаний, как мне кажется, должен сделать освоение новой специализации достаточно простой и непродолжительной задачей. По аналогии с переходом из одного ЯП в другой, например
В какой-то момент, где-то на 2-м году работы, начал на вопросы менеджеров в духе "а можем ли мы сделать так, чтобы...", начал отвечать "мы можем сделать все, если это можно описать словами и оно не конфликтит с другими фичами. Вопрос только в ресурсах". Спустя еще пару лет, оглядывясь назад, понял, что осознание этого делает разработчика мидлом. На этом этапе он вполне самостоятелен, может принимать решения и от него можно ждать достойного результата.
Но тут справедливо возникает вопрос. Если мидл может сделать все, то что тогда отличает сеньора от мидла? И, хотя, по мнению некоторого количества интервьюверов, я вполне достоин сеньорской позиции, у меня до сих пор нет ответа на этот вопрос. Может, я осознаю это еще через пару лет? А может, возможность отличить мидла от джуна и делает тебя сеньором?
Может, у кого-то есть понимание, в какой момент Вы стали сеньором? Поделитесь мыслями. Очень мучает этот вопрос :)
Конечно требует. GC то нет :) Если бы не требовал - была бы боль как в С. Но как по мне, делает это самым вразумительным и элегантным способом :)
К стати, а что на счет go? мне кажется он, как минимум, не хуже ноды по всем трем параметрам. Дополнительным бонусом еще и полноценная многопоточность. Разве нет?
Ок, в скорости python проигрывает, даже на порядки. Но все-равно, в критических ситуациях GC и "single-threaded by design" делают js непригодным к "сидению на 3-х стульях." (ситуациях, как эта, например: https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f). Да и весь интернет полон статей о том, как избавиться от утечек в node.js, так что говорить, что он не требует заботы о памяти тоже не совсем корректно.
Так что в целом я считаю, что rust, все же, лучший кандидат на этот пост. Со скоростью, близкой к С, без GC и с минимальной болью от контроля памяти :)
А можно вопрос, что именно javascript пытается? Все тот же GC и все тот же GIL. Единственное, что до недавнего времени отличало js от python - это non-blocking IO. Но asyncio тут всех уравнял. И хоть асинхронная экосистема в python-е еще не совсем зрелая, принципиального отличия между python+asyncio и js я не вижу. Оно есть?
Мне кажется, что "заботиться" о памяти нужно в С. В rust-е о ней заботится компилятор. Если оно скомпилилось - значит оно не течет(unsafe не в счет :)). При этом даёт очень внятные объяснения о том, что в коде не так. А владение и заимствование - можно принять как особенности языка.
Если не ошибаюсь, rust таки успешно сидит на всех 3-х стульях. Единственный недостаток - это время компиляции. Но, думаю, это цена, которую не жалко заплатить за гарантии, которые он дает.
Сложно ли переходить из идеи? И почему решились на такой шаг? Второй год думаю, закончится лицуха — посталю VSCode. Но приходит время, лицуха дохнет — хватаюсь за голову. Нужно перетащить все настройки, деббаггеры, бызы данных и прочую хрень… На вскидку не меньше недели адаптации. Забиваю и продливаю лицуху :)
Советую порыть в сторону функциональных ЯП и ленивых вычислений. Не силен в функциональщине, но мне кажется Ваши фракталы имеет много общего с монадами. Может подчерпнете интересных идей.
Двусторонний биндинг бесполезен без реактивного фреймворка/либы. К сожалению, для реакта — это не react-way, а в других фреймворках/либах он есть из коробки. Разве нет?
когда данные, нужные одному лишь чайлду, заставляют всех родителей и соседние компоненты перерендериваться
Если не ошибаюсь, в реакте эта проблема решается контекстами и порталами. Во vue3 также вводят порталы, назвав их телепортом. Нужен ли этот концепт в отрыве от фреймворка — немного сомнительно.
Дайте, пожалуйста, знать, что получится. Еще интересно по поводу сети. Как я понимаю, проблемы сети между wsl и виндой помножатся на проблемы сети между wsl и докером. На данный момент проблемы с сетью отпугивают от wsl больше всего :)
Это в Вашем мире логика первична и только так. Я предлагаю посмотреть с другой стороны. Данные — это содержание. Код — это обертка.
Докажите, что Ваш подход единственно правильный вот этому парню.
Это Вы предлагаете делать базу тупым хранилищем. По-моему, база должна гарантировать консистентность и обеспечивать инвариантность. Тогда mapper слой можно свести к минимуму.
Еще раз, я не пытаюсь сказать, что Ваш вариант неправильный. Я о том, что он не единственный правильный.
По сути база — это единственный источник правды в Вашем клиент-серверном приложении. И если ее структура не соответствует бизнес-логике — у Вас тоже будут проблемы. В конце концов, если взглянуть чуточку шире, то весь Ваш бек-енд — это всего-лишь буковка С в аббревиатуре MVC, а моделью в этом случае выступает база. Не думали с этой точки зрения? Просто не стоит быть настолько категоричным. Все очень относительно.
Существует 2 подхода к разработке: code-first и database-first. Они оба имеют право на жизнь. Говорить, что какой-то из них "в корне неправильный" может только слепец. Дальше читать не стал.
В первой статье рассказывалось про кодогенераторы, но почему-то здесь контроллер написан вручную. Я понимаю, что новичкам не обязательно знать про ресурсы, но банальные конвенции именования методов лучше соблюдать, раз уж Вы учите их работе с фреймворком. Потом будет проще переучиться.
Удаление обязательно делать методом POST(лучше, конечно, через method_field('DELETE'), но списываем на новичков) и вкидывать csrf-token. Зачем-то же он нужен…
Конструкцию array(...) не видел уже миллион лет :)
Переменная $uploadSuccess присваивается, но нигде не используется. Там вообще лучше обернуть в try...catch, но, опять же, новичкам хватит и простой проверки if ($uploadSuccess) {...}.
Это вообще огонь :)
$album = Album::with('Photos')->find($id);
$albums = Album::with('Photos')->get();
Ну и про code style уже говорили. Вообще не понимаю людей, жадных на пробелы…
Почему же? У врачей, как-раз таки, 3-хбалльная шкала. Врач второй категории, первой и высшей. И, хотя я не знаю конкретных кейсов, думаю свитчинг из одной специализации в другую вряд ли делает врача "джуном". В медицине тоже есть базовые знания о том, как устроен человеческий организм, обязательные для всех специальностей. И багаж этих знаний, как мне кажется, должен сделать освоение новой специализации достаточно простой и непродолжительной задачей. По аналогии с переходом из одного ЯП в другой, например
В какой-то момент, где-то на 2-м году работы, начал на вопросы менеджеров в духе "а можем ли мы сделать так, чтобы...", начал отвечать "мы можем сделать все, если это можно описать словами и оно не конфликтит с другими фичами. Вопрос только в ресурсах". Спустя еще пару лет, оглядывясь назад, понял, что осознание этого делает разработчика мидлом. На этом этапе он вполне самостоятелен, может принимать решения и от него можно ждать достойного результата.
Но тут справедливо возникает вопрос. Если мидл может сделать все, то что тогда отличает сеньора от мидла? И, хотя, по мнению некоторого количества интервьюверов, я вполне достоин сеньорской позиции, у меня до сих пор нет ответа на этот вопрос. Может, я осознаю это еще через пару лет? А может, возможность отличить мидла от джуна и делает тебя сеньором?
Может, у кого-то есть понимание, в какой момент Вы стали сеньором? Поделитесь мыслями. Очень мучает этот вопрос :)
ЗЫ: снимал на синдром самозванца xD
Конечно требует. GC то нет :) Если бы не требовал - была бы боль как в С. Но как по мне, делает это самым вразумительным и элегантным способом :)
К стати, а что на счет go? мне кажется он, как минимум, не хуже ноды по всем трем параметрам. Дополнительным бонусом еще и полноценная многопоточность. Разве нет?
Ок, в скорости python проигрывает, даже на порядки. Но все-равно, в критических ситуациях GC и "single-threaded by design" делают js непригодным к "сидению на 3-х стульях." (ситуациях, как эта, например: https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f). Да и весь интернет полон статей о том, как избавиться от утечек в node.js, так что говорить, что он не требует заботы о памяти тоже не совсем корректно.
Так что в целом я считаю, что rust, все же, лучший кандидат на этот пост. Со скоростью, близкой к С, без GC и с минимальной болью от контроля памяти :)
А можно вопрос, что именно javascript пытается? Все тот же GC и все тот же GIL. Единственное, что до недавнего времени отличало js от python - это non-blocking IO. Но asyncio тут всех уравнял. И хоть асинхронная экосистема в python-е еще не совсем зрелая, принципиального отличия между python+asyncio и js я не вижу. Оно есть?
Мне кажется, что "заботиться" о памяти нужно в С. В rust-е о ней заботится компилятор. Если оно скомпилилось - значит оно не течет(unsafe не в счет :)). При этом даёт очень внятные объяснения о том, что в коде не так. А владение и заимствование - можно принять как особенности языка.
Если не ошибаюсь, rust таки успешно сидит на всех 3-х стульях. Единственный недостаток - это время компиляции. Но, думаю, это цена, которую не жалко заплатить за гарантии, которые он дает.
Это не сработает. Ключи массива должны быть уникальны.
Я просто оставлю это здесь
https://www.php.net/manual/ru/class.splenum.php
Сложно ли переходить из идеи? И почему решились на такой шаг? Второй год думаю, закончится лицуха — посталю VSCode. Но приходит время, лицуха дохнет — хватаюсь за голову. Нужно перетащить все настройки, деббаггеры, бызы данных и прочую хрень… На вскидку не меньше недели адаптации. Забиваю и продливаю лицуху :)
Советую порыть в сторону функциональных ЯП и ленивых вычислений. Не силен в функциональщине, но мне кажется Ваши фракталы имеет много общего с монадами. Может подчерпнете интересных идей.
Двусторонний биндинг бесполезен без реактивного фреймворка/либы. К сожалению, для реакта — это не react-way, а в других фреймворках/либах он есть из коробки. Разве нет?
Если не ошибаюсь, в реакте эта проблема решается контекстами и порталами. Во vue3 также вводят порталы, назвав их телепортом. Нужен ли этот концепт в отрыве от фреймворка — немного сомнительно.
Дайте, пожалуйста, знать, что получится. Еще интересно по поводу сети. Как я понимаю, проблемы сети между wsl и виндой помножатся на проблемы сети между wsl и докером. На данный момент проблемы с сетью отпугивают от wsl больше всего :)
ну камон
Докажите, что Ваш подход единственно правильный вот этому парню.
Еще раз, я не пытаюсь сказать, что Ваш вариант неправильный. Я о том, что он не единственный правильный.
Существует 2 подхода к разработке: code-first и database-first. Они оба имеют право на жизнь. Говорить, что какой-то из них "в корне неправильный" может только слепец. Дальше читать не стал.