Да карш хорошая вещь. Я вот работаю на дому. Было две машины на семью.. моя вообще стала "плохеть". Аккум сдох, тормоза когда едешь после долгого простоя скрипят... жалко машину. Продали одну... Так теперь из дома реже стал выходить.. Стараюсь дела пачками "выполнять". А не как раньше: в голову мысль пришла и вперед.. карш бы для таких как я самый топчик.
А кто кривым стартером не пользовался ни когда - то же не достоин :)
Это просто развитие... технологии меняются. Я долго не хотел пересаживаться на автомат, сейчас вполне все устраивает. (Правда машина с ручным режимом и лепестками, на "если что" )
Так там уже так важен ли этот кикдаун. и так ускорения вполне достаточно. Покрайней мере мне сейчас и с 200лс. и 300+нм хватает для вполне разумных обгонов. Кикдаун это уже либо для удовольствия (чтоб почувствовать щеки на подголовниках, либо когда обгон делаешь уже практически в лоб :)
Но понятно еще конечно что дело еще в стиле вождения и в привычках
Ну вопрос спорный канешн :)
Был у меня солярис (правда это еще только в 13 году), но за 10+ лет владения им кикдауном не пользовался. Это что то ужасное (возможно после алмеры с двигателем 1.8): выходишь на обгон, тапку в пол в расчете на этот самый кик и...... машина сначала наоборот замедляется... в итоге я всегда перед обгоном переключал автомат на 3 перед обгоном и потом уже на обгон. Впрочем может сейчас изменилось. Сейчас тоже не пользуюсь, но сейчас машина и без кикдауна хорошо ускоряется. Брал когда один из плюсов за то что выбрал - наличие ручного режима. Правда как то только раз ради интереса в нем ехал - уж слишком много ступеней :).
В этом году пришлось поездить на вазе с ручкой - прям кайфанул :). Но тут сила привычки - стаж с 87 года
Ну у не умеющих читать доку (причем совсем базовую) везде будут проблемы. Кому то кажется, что и для того что бы включать комп нужен ВУЗ
Нет. Это не мое решение. Изредка бывают некие обновления, которые потенциально могут, что то затронуть. Тогда я говорю, что только через меня, после того как я локально проверю. (на практике такое было пару раз). Проблем не было ни когда.
Мы не про "должен", а про "может". В случае с CMS это, как правило, достаточно нормальная ситуация. Естественно случаи когда сопровождается сменой версии PHP - это отдельная ситуация. Конечно свою "лепту" вносят в этот процесс разработчики сторонних модулей и модулей разработанных на самом проекте за всю его историю.
Некоторые обновления закрывают дыры, некоторые добавляют что то в соответствии с изменением законодательства. и т.п. Ситуации тут разные. Тут должен быть разумный подход. не всегда "длинный цикл" это хорошо.
Дело то не в количестве разработчиков, а в количестве команд. У каждой команды свой цикл разработки, свой взгляд на будущее, на поддержку той же обратной совместимости и т.д и т.п. Соответственно чем больше элементов от разных команд, тем больше шанс все возможных "конфликтов" составляющих проекта.
Архитектура.. На мой взгляд, это больше тема для холиваров тем кому интересно. А так это инструмент, принимаешь его правила или берешь другой. При этом не означает же что в своем модуле (внутри) для этой CMS ты должен придерживаться такой же архитектуры. Тут еще пример а вы смотрели код виндус, макос или пакетов в линукс? Вы уверены что там все круто с архитектурой? :) небольшой пример. Я как то пересекался, нужен был один пакет для работы с PDF. а нашелся подходящий только уже заброшенный и даже из реп выкинутый. Там код был пипец какой, я его подправил для своих целей, и его даже вернули в некоторые дистры. (и фидбеки я получал) Но код так и остался никакой, я начинал рефакторинг, то так эта ветка и заглохла (мне этот пакет стал совсем не нужен)
Отвлекает пользователя? каким образом? То что в списке доступных модулей висит, например, "Голосование", "Форум"? А зачем пользователю этот список смотреть часто?
Да ладно? Опять же...
У меня Битрикс обновляют сами клиенты чаще всего. При этом даже мажорная версия это не проблема. В основном проблемы при обновлении версии PHP. Да и то в сторонних или самописных модулях разработчики которых (по ощущениями) пишут до сих пор аки на PHP 5.6. (но точно такие же разработчики не поменяют свой подход если их пересадить на фреймворки). CMS стараются исходить из парадигмы что обновления могут накатывать и не специалисты.
Обновление через композер это точно не дело не специалиста. В симфе и ларе на сколько сильно парятся об обратной совместимости? А теперь: а если вам нужный модуль уже перешел на симфу последнюю - и там есть нужный функционал, а еще 10 модулей не перешли. И тут речь не о том, что такой ситуации вообще не возможно на cms. Дело в том, что в случае CMS у вас больше кода от одного разработчика, а значит шанс такой ситуации меньше
Серьезно? Т.е. для нуба CMS это "делать сложно." и надо нанимать дорогого спеца. А взять "бэкенд-фреймворк" и все становится "ясно и просто"? Вы реально так думаете или это просто троллинг?
Я очень поверхостно знаком с джумлой, но что то сильное подозрение, что этот "готов разбираться" - "не смог разобраться".
При этом, обратите внимание, вы написали "нуб оставляет"... т.е. если этот нуб берет лару то он начинает резко все красиво сооружать и у него на выходе сайт-конфетка? Мне почему то кажется, что этот самый нуб (даже если "готов разбираться") на ларе и симфони, создаст куда более кривой сайт чем на любой достаточно популярной cms
Ну т.е ни какой конкретики.
Т.е. вы считаете, что если некий разработчик переведет решение с условного WP на условную симфу то у него резко пропадет количество вопросов? Или вы сравниваете криворукого "разработчика" на ВП и реального Профи на симфе? И как так сложилось (по вашему) что CMS это проблемы ,а фреймворки это их отсутствие.
В реальности все зависит от:
1. По прежнему определяется объемом задач, которые закрывает готовое решение. И при одинаковой квалификации разработчика, если cms покрывает больше - то ее применение правильное решение. Если разработчик косячит с CMS, ну я бы опасался ему доверить и на фреймворке, даже если его знания подтверждены, т.к. это будет означать что он "программист [название_конкретного_фреймворка]", а не программист. И может где то не достаточно погрузиться в тему.
2. И, вынесу отдельным пунктом, квалификацией. У меня вот наглядный был однажды пример очень яркий. Обратились с просьбой решить проблемы с битрикс сайтом. Стал разбираться: оказалось просто кто то не читал доку. Основная проблема была в кеширвоании. Так вот это некто реализовал очень грамотное решение - все по феншую. Но есть нюанс: он не знал как работает кеширование в битриксе, в итоге одно накладывалось на другое и получалась невообразимая хрень.
Есть и еще один момент. Вот вы пишите на неком фреймворке, собирая то, что есть уже в некоей CMS из кучи компонентов через композер. все как бы ок. Но. Это ваш проект зависит уже не от одного вендора, а от многих. И это тоже может доставлять дополнительные задачи. Не сталкивались? А я вот, например, столкнулся что пришлось "взять на обслуживание" достаточно популярный vue компонент, потому что его поддержка закончилась активная, и форки тоже не решали проблемы, в общем свой форк и вот уже я имею дополнительную задачу. (да, конечно, он мне хлопот не доставляет, но тем не менее)
Все должно определяться субъективными для проекта целями, задачами и условиями (не каждый проект может себе позволить штат программистов, или дополнительный бюджет на подробную документацию, дополнительное тестирование и написание тестов). Где то вполне может быть оправдано вообще написание реального "самописа" для существующего решения, но все равно это удорожание.
И что в этом такого? По хорошему при использовании фреймворков вы точно так же не должны тащить внутрь своей бизнес логики чужие решения. А подключать их условно на уровне инфрастурктуры. Если конечно нет объективной необходимости поступить иначе. В любом случае исходите из реалий конкретного проекта и стараетесь обезопасить себя макссимально от сильной завязанности на чужой код
