А развейте миф (если это миф) что количество поворотов 90 градусов влияет на итоговое давление? У вас на входах стоят два поворота на 90 после автоматики и перед счётчиками.
Под впечатлением прочитанного тоже пошёл на сайте искать модели, и только не найдя - разобрался, что в статье "прыгает" будущее и настоящее время. На самом деле, тема статьи - это только планируемый самокат, который "будем производить в России". Так что, время покажет что там с реальными цифрами.
PHPStan - это безусловно добро, как и любой инструмент, который находит потенциально слабые места. Но внедрение и чистка кода по его рекомендациям - это по истине "операция по принуждению к добру". Впервые когда я его поставил на одном своём большом проекте, получил >8k потенциальных проблем, и чистка первой тысячи поломала примерно всё.
С тех пор конечно ситуация поменялась и поддержка фреймворков стала получше. Но у меня осталось ощущение, что этот инструмент эффективно полезен только проектам с хорошей кодовой базой, а старым легаси-проектам сначала нужно решать архитектурные проблемы, накопить нужное количество автотестов, а потом уже вычищать код.
Я посчитал что информация "сваливай или увольняйся" могла быть взята из служебной переписки, а её раскрытие даже у нас подпадает под тайну, или я ошибаюсь?
Не позорюсь, а делюсь опытом. У меня было nda с немецкой конторой, где запрещено было многое. Это у нас к ним относятся с усмешкой, а на западе семь нулей и куча ограничений.
Имена для роутов, задаваемые вручную, делаются для того, чтобы при изменении структуры маршрутизации не менять код нигде кроме самого роута.
Имена дают возможность в коде обращаться к роуту по имени, не зная о его структуре. В результате, если позже структура uri поменяется - имена заданные вручную останутся прежними, менять ничего кроме файла роута не нужно будет.
В данной библиотеке, если позже api/pages изменится на api/docs - поменяется и автоматическое имя маршрута и придётся менять обращение к маршруту в коде. При использовании вручную прописанных имён маршрутов - этого не потребуется.
Поиграл, забавно придумывает, витиевато) Только в итоге сломалось, после 5 раунда перекидывает просто на результаты, не добавляя новых сообщений, но всё равно прикольно) https://gamio.ru/game/?key=VgsuuOaUeB7AdwCRDqrp
А как получился 1 час - это в среднем или в идеале? Мне кажется час на джуна - маловато, скорее два-три в день, по крайней мере первый месяц. За час можно разве что скорректировать поток фантазии в нужное русло. Но вот чтобы что-то объяснить до состояния "Ура, понял!" - нужны два диалога, утром и вечером по часу. Плюс вопросы по ходу/по коду.
А если товарищ требует всего час на взаимодействие - это очень хороший джун, берегите таких.
Если я правильно уловил тезис о том, что проще делать веб/хром приложения - то согласен, тут нам разработчикам все карты в руки, но я бы не стал списывать со счетов Flutter, он достаточно хорош.
А ещё у нас есть PWA, которые для запуска простых приложений уже достаточно просты в разработке, да ещё и ставятся не через официальные маркетплейсы, а прямо из браузера.
А дался вам этот D&D? Можно же взять схожую тему. Например игровой проект "Черная книга" - взял славянский сеттинг, придумал свои классы и систему боёвки. Не нравится наше - сейчас скандинавская тема прекрасно продаётся, а настолок по ней - чуть да маленько.
Кто из операторов первым введёт у себя возможность полного отключения входящих звонков и сообщений, чтобы остался только интернет, тому приз.
А развейте миф (если это миф) что количество поворотов 90 градусов влияет на итоговое давление? У вас на входах стоят два поворота на 90 после автоматики и перед счётчиками.
Под впечатлением прочитанного тоже пошёл на сайте искать модели, и только не найдя - разобрался, что в статье "прыгает" будущее и настоящее время. На самом деле, тема статьи - это только планируемый самокат, который "будем производить в России". Так что, время покажет что там с реальными цифрами.
PHPStan - это безусловно добро, как и любой инструмент, который находит потенциально слабые места. Но внедрение и чистка кода по его рекомендациям - это по истине "операция по принуждению к добру". Впервые когда я его поставил на одном своём большом проекте, получил >8k потенциальных проблем, и чистка первой тысячи поломала примерно всё.
С тех пор конечно ситуация поменялась и поддержка фреймворков стала получше. Но у меня осталось ощущение, что этот инструмент эффективно полезен только проектам с хорошей кодовой базой, а старым легаси-проектам сначала нужно решать архитектурные проблемы, накопить нужное количество автотестов, а потом уже вычищать код.
Есть такая книга: "Добыча: Всемирная история борьбы за нефть, деньги и власть"
Она толстенная, но составлена из людских историй, в том числе известных семей Рокфеллеров и Ротшильдов, мне показать очень интересной.
Не силён в законах Германии, возможно вы правы.
Я посчитал что информация "сваливай или увольняйся" могла быть взята из служебной переписки, а её раскрытие даже у нас подпадает под тайну, или я ошибаюсь?
Не позорюсь, а делюсь опытом. У меня было nda с немецкой конторой, где запрещено было многое. Это у нас к ним относятся с усмешкой, а на западе семь нулей и куча ограничений.
Nda - стандартная практика.
На сколько я понял, государство в широком смысле. Это могут быть и проекты ростелекома по созданию ютуба, и проекты ржд по созданию букинга.
Имена для роутов, задаваемые вручную, делаются для того, чтобы при изменении структуры маршрутизации не менять код нигде кроме самого роута.
Имена дают возможность в коде обращаться к роуту по имени, не зная о его структуре. В результате, если позже структура uri поменяется - имена заданные вручную останутся прежними, менять ничего кроме файла роута не нужно будет.
В данной библиотеке, если позже
api/pagesизменится наapi/docs- поменяется и автоматическое имя маршрута и придётся менять обращение к маршруту в коде. При использовании вручную прописанных имён маршрутов - этого не потребуется.Например:
И теперь, если мы хотим поменять маршрут, код контроллера не изменится.
Поиграл, забавно придумывает, витиевато) Только в итоге сломалось, после 5 раунда перекидывает просто на результаты, не добавляя новых сообщений, но всё равно прикольно) https://gamio.ru/game/?key=VgsuuOaUeB7AdwCRDqrp
А как получился 1 час - это в среднем или в идеале? Мне кажется час на джуна - маловато, скорее два-три в день, по крайней мере первый месяц. За час можно разве что скорректировать поток фантазии в нужное русло. Но вот чтобы что-то объяснить до состояния "Ура, понял!" - нужны два диалога, утром и вечером по часу. Плюс вопросы по ходу/по коду.
А если товарищ требует всего час на взаимодействие - это очень хороший джун, берегите таких.
Если я правильно уловил тезис о том, что проще делать веб/хром приложения - то согласен, тут нам разработчикам все карты в руки, но я бы не стал списывать со счетов Flutter, он достаточно хорош.
А ещё у нас есть PWA, которые для запуска простых приложений уже достаточно просты в разработке, да ещё и ставятся не через официальные маркетплейсы, а прямо из браузера.
Статья лёгенькая, буквально в двух словах, поэтому позволю себе показать ещё более простой вариант на картинке под спойлером (автор неизвестен):
буквально в двух словах
Это же просто красивое выражение, в котором, как и в каждой шутке, есть некая доля шутки, и некая доля правды.
Если бы в МС работали только ленивые программисты, они бы не выпустили с десяток операционок и тонну другого софта.
Увлекательный квест, надеюсь всё получится) Искренне желаю вам успеха.
Сам делаю PWA на Vue, а в качестве библиотеки интерфейсов использую varlet-ui, сильно ускоряет разработку, да и результат смотрится привлекательно.
Значит я плохо учил)
Тырить конечно проще) Но коли закрыли доступ и похоже легально - куда деваться?
Да, надо пробовать, согласен.
А дался вам этот D&D? Можно же взять схожую тему. Например игровой проект "Черная книга" - взял славянский сеттинг, придумал свои классы и систему боёвки. Не нравится наше - сейчас скандинавская тема прекрасно продаётся, а настолок по ней - чуть да маленько.