Наверное, если говорить про лего, как бренд и готовую экосистему - да. Если говорить про саму концепцию (взять лего техник и прикрутить к нему моторчики и голову) - то в целом оно может продолжать существовать. Есть куча "аналогов", например вот и вот и в целом идея в таком формате может продолжать существовать. Думаю, что если ниша востребована, то она не опустеет, здесь нет какого-то ноу-хау, которое было только у лего.
Сам лего техник никуда не девается, как основа для поделок, что главное, кмк.
Надо отметить что некоторые облачные системы и девайсы таки поддерживают локальное управление вместе с облачным, а это без приложения (или другого девайса в локальной сети у которого есть своя морда) скорей всего не сделаешь совсем
Не, если говорить про область ответственности аналитика, там где он выбирает и внедряет и сопровождает решения (нотации, форматы и процессы управления документацией, процессы сбора и формализации требований и тд), то да, тезис вполне актуальный.
Просто на СУБД совсем неуместно смотрится пример и вызывает отторжение. Предложу поменять в статье )
Иметь много инструментов в ящике – это хорошо. Уметь пользовать каждым из них – прекрасно. Но не менее важно понимать границы применимости и в каждой конкретной ситуации использовать наиболее подходящий инструмент – чтобы не забивать молотком шурупы.
Странное требование от аналитика. Аналитик же чаще всего не занимается выбором инструмента, он использует то, что уже внедрено. И если он действительно на позапрошлом пользовался внедренной постгресом и научился им хорошо пользоваться, а на прошлом - пользовался внедренным ораклом и научился им хорошо пользоваться, то почему из этого следует вывод, что он должен уметь выбрать из этих двух более подходящий инструмент?
Кажется если что и можно спрашивать здесь - так это "чем было комфортней пользоваться", "в каком из инструментов было проще решать типовые\нетиповые задачи" и т.д., т.е. просить сравнить именно опыт использования.
Умные гаджеты Sber используют платформу Tuya. Данный сервис сейчас блокирует все новые подключения по идентификатору, который есть у каждого устройства Sber
Поэтому только зигби и локальный хаб (или аналогичные локальные сетапы). Умные девайсы должны быть тупыми и управляться локально, а не ходить самостоятельно в чужие облака, которые и без санкций регулярно закрываются.
Не пойдет, так как в настоящем виде так можно строить только одноэтажное жилье
есть примеры трехэтажных вилл напечатанных, я ж дал ссылку выше
про теплые районы - пока непонятно. примеров нет, но никакой проблемы делать стены шире и заливать в пустоты пену я не вижу. в остальном не сильно от монолита отличается кажется по тепловым свойствам.
без экзотики в виде торнадо и землетрясений.
а тут кстати интересно обсудить. с одной стороны да. с другой стороны в Америке, емнип, как раз таки максимально дешевые дома в торнадных районах, чтобы просто их отстроить заново без проблем. В этом плане простые одно-двух этажные дома - это как раз то что нужно. при этом бетонина кажется более устойчивой к торнадам
Это здорово, только непонятно как это сравнивать. Почему то есть уверенность, что если бы эти же турки делали все кроме стен с напечатанной коробкой - то вышло бы быстрей\дешевле все равно. Ну точней в какой-то момент точно начнет выходить быстрей\дешевле, когда технология пойдет в массы, как это обычно бывает (как с той же обычной 3д печатью)
Ну, тут надо понимать, что пока скоростями меряются только при возведении коробки. Коммуникации и отделка туда не входит, поэтому не знаю, как интерпретировать ваши "построила многоэтажный дом <...> за 6-8 месяцев".
6-8 месяцев
Но если говорить только про коробки, то одноэтажку 75 квадратов они печатают за сутки (~28 часов). "Многоэтажки" тоже печатают (трехэтажную виллу печатал winsun), но честно не знаю как они делают там перекрытия
экономят не на материале, а на работах в заданные сроки (ну т.е. чтобы сделать аналогичное классическим методом - надо нагнать кучу народу). для простых зданий требуется оператор и на небольше время манипулятор для установки балок над проемами (бетоном с поддержками не попечатаешь :D )
С активацией уже купленных ключей вроде никакие площадки пока не отказывали, по крайней мере не слышал таких новостей. Поэтому в условиях, когда издатель скрыл свои игры из условного стима\ориджина\%площадканейм%, купить коробку и активировать по ключу - достаточно простой выход
Простите, а вы уверены, что проблема в "неомидлах, которые хотят на сеньора", а не в вашей вакансии(условиях) и процессе найма? Если вакансия висит больше года, то это звучит как проблема, за это время половина среднестатистических разработчиков уже прошла по рынку мимо вас (где-то вроде слышал, что среднее время работы в компании - 2 года)
В старые легаси проекты нужно безусловно внедрять аккуратно и поэтапно, но я отмечу, что это прям помогает. Понятно, что для очень старых проектов большинство багов так или иначе уже найдено пользователями и поправлено, но нам эта штука помогла найти несколько проблем, на которые мы положили болт.
В качестве поэтапного внедрения мы в CI имели просто два прогона для phpstan - один обязательный с неким минимальным уровнем, а второй необязательный - со следующим. Постепенно фиксили ошибки из необязательного и сдвигали оба уровня.
Начали, конечно, с того, что шаг был необзяательным в сборке и несколько недель фоном (или в рамках соседствующих задач) фиксили ошибки.
Также свежую кодовую базу в легаси проекте мы вынесли в другую папку, так стало проще на нее натравить правила пожесче
Вопрос именно в том, как вы со switch-case навесите авторизацию на группу роутов. Конечно, если вас устраивает на таких объемах каждый роут описывать полностью вручную (вот этот с авторизацией, этот без, этот html с темплейтом и учетом локалей, этот json сырой, этот такой же как вот этот, только без параметров, вместо них вот такие дефолты и тд), то вам все это не надобно, безусловно. вам вообще в этом случае скорей всего хватит пары-тройки .php файлов с инклудами (это кстати описано в цикле статей, который я линканул выше)
Понятно что не надо забивать гвозди шуруповертом. простые одноразовые задачи можно решать без всего этого.
Это не создание маршрута - это фактически конфигурация приложения. То, что его явно нужно конфигурировать кодом каждый раз - это особенность, но фактически это так или иначе происходит во всех фреймворках, просто условный symfony читает кэш DI\роутинга (или строит его по YAML конфигам) неявно для вас, но он тоже это делает это каждый раз при запуске.
Здесь же вы просто явно выполняете это действие. Для новичков на самом деле эта явность кмк очень полезна.
Если вы будете запускать Slim на каком-нибудь RoadRunner, то вы явно увидете разницу между конфигурированием и запуском. Конфигурирование (get) будет вне цикла воркера, а запуск внутри.
Наверное, если говорить про лего, как бренд и готовую экосистему - да. Если говорить про саму концепцию (взять лего техник и прикрутить к нему моторчики и голову) - то в целом оно может продолжать существовать. Есть куча "аналогов", например вот и вот и в целом идея в таком формате может продолжать существовать. Думаю, что если ниша востребована, то она не опустеет, здесь нет какого-то ноу-хау, которое было только у лего.
Сам лего техник никуда не девается, как основа для поделок, что главное, кмк.
Надо отметить что некоторые облачные системы и девайсы таки поддерживают локальное управление вместе с облачным, а это без приложения (или другого девайса в локальной сети у которого есть своя морда) скорей всего не сделаешь совсем
Не, если говорить про область ответственности аналитика, там где он выбирает и внедряет и сопровождает решения (нотации, форматы и процессы управления документацией, процессы сбора и формализации требований и тд), то да, тезис вполне актуальный.
Просто на СУБД совсем неуместно смотрится пример и вызывает отторжение. Предложу поменять в статье )
Странное требование от аналитика. Аналитик же чаще всего не занимается выбором инструмента, он использует то, что уже внедрено. И если он действительно на позапрошлом пользовался внедренной постгресом и научился им хорошо пользоваться, а на прошлом - пользовался внедренным ораклом и научился им хорошо пользоваться, то почему из этого следует вывод, что он должен уметь выбрать из этих двух более подходящий инструмент?
Кажется если что и можно спрашивать здесь - так это "чем было комфортней пользоваться", "в каком из инструментов было проще решать типовые\нетиповые задачи" и т.д., т.е. просить сравнить именно опыт использования.
Поэтому только зигби и локальный хаб (или аналогичные локальные сетапы). Умные девайсы должны быть тупыми и управляться локально, а не ходить самостоятельно в чужие облака, которые и без санкций регулярно закрываются.
есть примеры трехэтажных вилл напечатанных, я ж дал ссылку выше
про теплые районы - пока непонятно. примеров нет, но никакой проблемы делать стены шире и заливать в пустоты пену я не вижу. в остальном не сильно от монолита отличается кажется по тепловым свойствам.
а тут кстати интересно обсудить. с одной стороны да. с другой стороны в Америке, емнип, как раз таки максимально дешевые дома в торнадных районах, чтобы просто их отстроить заново без проблем. В этом плане простые одно-двух этажные дома - это как раз то что нужно. при этом бетонина кажется более устойчивой к торнадам
Это здорово, только непонятно как это сравнивать. Почему то есть уверенность, что если бы эти же турки делали все кроме стен с напечатанной коробкой - то вышло бы быстрей\дешевле все равно. Ну точней в какой-то момент точно начнет выходить быстрей\дешевле, когда технология пойдет в массы, как это обычно бывает (как с той же обычной 3д печатью)
Ну, тут надо понимать, что пока скоростями меряются только при возведении коробки. Коммуникации и отделка туда не входит, поэтому не знаю, как интерпретировать ваши "построила многоэтажный дом <...> за 6-8 месяцев".
Но если говорить только про коробки, то одноэтажку 75 квадратов они печатают за сутки (~28 часов). "Многоэтажки" тоже печатают (трехэтажную виллу печатал winsun), но честно не знаю как они делают там перекрытия
экономят не на материале, а на работах в заданные сроки (ну т.е. чтобы сделать аналогичное классическим методом - надо нагнать кучу народу). для простых зданий требуется оператор и на небольше время манипулятор для установки балок над проемами (бетоном с поддержками не попечатаешь :D )
С активацией уже купленных ключей вроде никакие площадки пока не отказывали, по крайней мере не слышал таких новостей. Поэтому в условиях, когда издатель скрыл свои игры из условного стима\ориджина\%площадканейм%, купить коробку и активировать по ключу - достаточно простой выход
Мне кажется проблема банально в том, что игры на большинстве онлайн площадок стало сильно сложней купить
Простите, а вы уверены, что проблема в "неомидлах, которые хотят на сеньора", а не в вашей вакансии(условиях) и процессе найма? Если вакансия висит больше года, то это звучит как проблема, за это время половина среднестатистических разработчиков уже прошла по рынку мимо вас (где-то вроде слышал, что среднее время работы в компании - 2 года)
В старые легаси проекты нужно безусловно внедрять аккуратно и поэтапно, но я отмечу, что это прям помогает. Понятно, что для очень старых проектов большинство багов так или иначе уже найдено пользователями и поправлено, но нам эта штука помогла найти несколько проблем, на которые мы положили болт.
В качестве поэтапного внедрения мы в CI имели просто два прогона для phpstan - один обязательный с неким минимальным уровнем, а второй необязательный - со следующим. Постепенно фиксили ошибки из необязательного и сдвигали оба уровня.
Начали, конечно, с того, что шаг был необзяательным в сборке и несколько недель фоном (или в рамках соседствующих задач) фиксили ошибки.
Также свежую кодовую базу в легаси проекте мы вынесли в другую папку, так стало проще на нее натравить правила пожесче
Что интересно - не очень понятно, зачем там требуется WSL2. докер в винде вполне прекрасно работает и без него (и местами даже лучше, чем с ним)
Вопрос именно в том, как вы со switch-case навесите авторизацию на группу роутов. Конечно, если вас устраивает на таких объемах каждый роут описывать полностью вручную (вот этот с авторизацией, этот без, этот html с темплейтом и учетом локалей, этот json сырой, этот такой же как вот этот, только без параметров, вместо них вот такие дефолты и тд), то вам все это не надобно, безусловно. вам вообще в этом случае скорей всего хватит пары-тройки .php файлов с инклудами (это кстати описано в цикле статей, который я линканул выше)
Понятно что не надо забивать гвозди шуруповертом. простые одноразовые задачи можно решать без всего этого.
Рекомендую кстати всегда вот этот цикл прочесть. https://symfony.com/doc/current/create_framework/index.html
Дает в целом понимание что и как устроено в больших фреймворках и в частности подводки к архитектуре симофни
Так в целом можно. Но это будет работать только для достаточно простых кейсов. Давайте я добавлю вам требование:
И все эти сложные конфиги сразу заиграют новыми красками
Это не создание маршрута - это фактически конфигурация приложения. То, что его явно нужно конфигурировать кодом каждый раз - это особенность, но фактически это так или иначе происходит во всех фреймворках, просто условный symfony читает кэш DI\роутинга (или строит его по YAML конфигам) неявно для вас, но он тоже это делает это каждый раз при запуске.
Здесь же вы просто явно выполняете это действие. Для новичков на самом деле эта явность кмк очень полезна.
Если вы будете запускать Slim на каком-нибудь RoadRunner, то вы явно увидете разницу между конфигурированием и запуском. Конфигурирование (get) будет вне цикла воркера, а запуск внутри.
пример:
конфигурация https://github.com/n1215/roadrunner-docker-skeleton/blob/slimphp/app.php
запуск https://github.com/n1215/roadrunner-docker-skeleton/blob/slimphp/worker.php
Инструмент, в котором надо даже базовые вещи писать самому, а не брать у сообщества с помощью экосистемы - это сомнительное удовольствие.
Есть Github Sponsors https://docs.github.com/en/sponsors