Кстати, редактор в админке при создании файла использует файл шаблона страницы (их даже может быть несколько на выбор). Можно его отредактировать. В шаблоне сайта это директория page_templates. Документация.
И какое оно? Я не могу понять как интерпретировать такие оценки в этом ключе. Статья о том, что вам не понравился Битрикс, значит плюсы статье это минусы Битриксу? А минусы статье, это потому что статья про Битрикс на Хабре не нужна должна быть заминусована. Так что это тоже минусы Битриксу?
Битрикс на Хабре никогда не любили. Самому Битриксу от этого, кажется, ни тепло, ни холодно.
А кто это должен делать? Я? Но как? Битрикс обновляется через собственную систему обновления.
выше @a0fsпишет страшное. Что там на сервер чего-то вписывается вредоносное.
В принципе, он правильно пишет. Битриксу действительно необходимы права на запись всюду. И даже его собственное ядро не является исключением. Хотя бы из-за обновлений. Но я лично не сталкивался с проблемами из-за этого. Плюс у Битрикса есть собственные механизмы безопасности: проактивная защита, сканер уязвимости. А сам продукт периодически проходит какие-то аудиты безопасности, что даёт какую-то надежду, что при регулярных апдейтах хотя бы через уязвимости ядра ничего не пролезет.
Я, в силу опыта работы с ним, хорошо знаю недостатки Битрикса. Но при этом на Вордпресс я не согласен. У него своих проблем вагон. В частности мне показалось довольно сложным поддерживать вордпресс в свежем состоянии. Потому что при обновлениях он склонен разваливаться. А если не поддерживать, то он тут же становится целью для атак. Битрикс в этом плане намного лучше. У него надёжно работающие обновления, и есть кое-какие инструменты контроля безопасности.
Не могу ничего сказать про другие CMS в сравнении - не имею опыта. Зачем вообще выбирать Битрикс? Мне кажется, Битрикс, он такой энтерпрайзный. Как 1C, винда, всякие ERP-системы. Ты платишь за лицензию, тебе дают сапорт (неплохой, кстати), обновления, а вокруг куча компаний, которые готовы разрабатывать и поддерживать сайты на Битриксе. На Битриксе работает куча корпоративных сайтов, которые не интернет-магазины.
Ну и конечно, часто решение о том, что использовать принимает разработчик, на которого довелось наткнуться заказчику. Я лично сделал горстку мелких сайтов на младших версиях Битрикса. Почему не другая CMS? Потому что я работал с Битриксом. Почему не голый фреймфорк? Потому что небольшой сайт со стандартным функционалом проще сделать на CMS.
А удалось ли вам картировать, кто кого подключает в старом ядре?
Не уверен, что я правильно понял ваш вопрос, но думаю, что я довольно хорошо понимал жизненный цикл страницы. По крайней мере, когда работал с Битриксом. То есть лет, наверное, 7 назад.
И да, а почему не работает "выгрузить БД тут, импортировать там" - где может выскочить несовместимость с новой версией Битрикса?
Так можно. Вообще мне нравились в Битриксе две вещи. Система обновления и система резервного копирования. Первая способна весьма стабильно обновлять систему, причём через множество версий. А вторая способна забэкапить и с помощью одного скрипта развернуть сайт обратно в другом месте.
Но когда работаешь с системой контроля версий, кладёшь туда файлы проекта, ядро битрикса не включаешь. Соответственно появляется зависимость от конкретной версии ядра. В мире пхп такое решается через композер, только не в мире битрикса.
Можно попробовать включить и ядро в проект. Но битрикс ОЧЕНЬ тяжёл, а каждое обновление будет приводить к огромным коммитам.
Чёрт с ним с ядром. Часть конфигурации проекта неизбежно хранится в БД. Инфоблоки, например. Они меняются через интерфейс админки. Как это синхронизировать с кодом? Можно сделать подобие миграций и все подобные изменения реализовывать средствами API. Но тогда мы значительной части функционала админки, за который уплочено. И мы всё ещё не можем гарантировать, что кто-то не сделает в админке что-то, что приведёт к рассинхронизации с зафиксированным состоянием. Плюс обновления битрикса изменяют данные в БД. И как понять, были ли они безопасны относительно того, что зафиксированно в коде или нет?
В корпоративном портале с этим ещё страшнее. Там приходится синхронизировать изменения компонентов, если ты их кастомизировал, чтобы не потерять новые фичи. Так что я перед крупными апдейтами несколько дней на это выделял.
Битрикс состоит из множества слоёв легаси. В некотором смысле они выбрали виндовый подход к развитию. Я работал с битриксом более 10 лет ещё со времён php4, когда никакого ООП там вообще не было. И автолоада тоже. Тогда он не казался мне сложным. Роутинг на файлах был вполне понятен и сваливал всю работу на Apache. Компоненты просто инклюдились и конфигурировались в коде, а визуальный редактор упрощал этот процесс. Потом всё это стало обрастать зачатками MVP в новых компонентах 2.0 и комплексных компонентах, и примитивными зачатками ООП. При этом бешено разрастался функционал ещё на старых технологиях. Компоненты и шаблоны в тыщи строк сохранились в Битриксе до сих пор. Потом борьба за производительность привела к множеству слоёв кеширования. И так далее.
Потом возникла новая надежда - D7. Но он развивался крайне медленно, а старые компоненты никто не спешил переписывать, продукт был уже очень большим. К этому добавился Битрикс Корпоративный портал, который дьявольски оттягивал ресурсы на новые фичи, а рефакторинг так и не наступал. И уж тем более никогда не шло речи о новом Битриксе, несовместимом со старыми наработками. Так что D7 стал лишь ещё одним вариантом сделать что-то в Битриксе.
Из-за того, что компоненты жили в директории bitrix рядом с кодом самого Битрикса, было крайне сложно вести проект в системах управления версиями. Так что добавилась возможность держать свои компоненты и модули в отдельной директории. Что усложнило и без того нелёгкую процедуру поиска кода, который тебе надо исправить. Плюс часть конфигурации всё равно в БД и нет миграций. Запихнул код в гит? Поздравляю, теперь придумай как накатывать данные и обеспечить совместимость с нужной версией Битрикса.
В итоге образовалась какая-то адовая сложность. Тонны документации, курсы, сертификация. Я наблюдал, как люди, которым я делал сайты, даже поддерживать их не могут. Некоторые битриксоиды считают это за плюс - всегда хватает работы по поддержке.
Был для начала Битрикс просто для сайтов. Дальше они интегрировались с 1С, вышел 1С-Битрикс. И принадлежит 1С.
Вроде бы Битрикс никогда не принадлежал 1С. Это совместное предприятие.
То есть, реально движок (как минимум, декларативно) отвечает не только за вывод инфы в сети, но ещё за оплату, налоги, отчётность.
Ну как... Битрикс, который для магазинов (редакции Бизнес), имеет модуль для интеграции с 1C. Так как 1С у каждого предприятия имеет свои особенности конфигурации, нельзя просто взять и настроить этот модуль в админке, чтобы отчётность и склад заработали. Требуется работа по интеграции и стоить она будет прилично. Но далеко не все даже интернет магазины это используют. И есть куча сайтов на Битриксе, которые магазинами не являются и вообще никакую интеграцию с 1С не используют.
Может потому что курьеры работают не на сам Самокат, а через компанию-прокладку - партнёра? А может для повышения собственной значимости курьеров. А может и то и другое.
И это тоже выдаёт в этой историю маркетинговую лабуду. Ну будет нормальный человек так писать текст? А маркетолог компании будет.
Тоже это насторожило. И либо это история для того самого героя комикса, либо в Самокате всё вот настолько дырявое. Ну ладно, ещё возможен вариант, что всё было и в имеющемся приложении, только неудобно, так что герой рассказа проанализировал взаимодействие с бэком и переписал фронт.
Это понятно. Хотя, вот прямоугольник со скруглёнными углами, это очень хорошая полезная для компании формула изобретения, хорошо иметь такой патент. А на вот это... Ну такое. Если бы это был более абстрактный патент на способ установки питаемых аксессуаров на ноутбук, то было бы лучше.
Скорее всего. Но так как это ледокол, кажется, что не велика проблема. Важнее эффективно ломать лёд, а до льда он уж как-нибудь доползёт. Он атомный, энергии много.
Реально сомнительная штука в том виде, в котором изображена в патенте. Помимо неудобства использования клавиатуры можно найти и другие недостатки. П-образная форма означает, что снизу под ноутбуком с одной стороны появляется некоторая толщина, которую также нужно скомпенсировать с остальных четырёх сторон для устойчивости ноута. А как? Надетое устройство не позволит закрыть ноутбук. Значит его надо каждый раз снимать. А при перевозке ноута из-за своей формы этот зарядник будет занимать изрядно места в сумке или рюкзаке. Почему он хотя бы не Г-образный? Ну и потери энергии у беспроводной зарядки выше, а значит часть ценной энергии батареи ноута вылетит в трубу. Дополнительный USB-разъём и короткий кабель кажутся на фоне этого куда более удобным решением. Или даже внешняя беспроводная станция с коротким проводом - она по крайней мере более компактна и не мешает пользоваться клавиатурой самого ноутбука и закрывать его.
Это еще что?! То есть вагон генератор с КПД двигателя 25% и КПД
Так, давайте ка не вносить изменения в исходные условия. У нас вагон с электрическим отоплением.
Если вагон генератор ломается, вот пожар там небольшой. Все вагоны в -45 градусов остаются без отопления.
Только если он ломается весь. Но там есть резервный генератор, которого нет в вагоне.
Пока резервный вагон доедет,
Речь о плановом обслуживании. Вагону никуда не надо ехать. На случай ЧП в пути есть резервный генератор.
Сломался генератор в вагоне, не проблема, прокинули кабель в соседний вагон
Перегрузив генератор вдвое?
У электробуса (или электромобиля), нет излишков энергии и они греются дизельной горелкой
Дело как раз в том, что у них нет лишней энергии и им негде её взять в принципе. Электрический нагреватель в вагоне позволяет сделать универсальное решение для электрифицированных линий и для неэлектрифицированных. кстати я не видел электромобилей с подогревом топливной печкой.
Мотор дизельный в вагоне зимой напрямую сможет обогревать вагон, как в автомобиле (это огромное преимущество над вагон-генератором), плюс догревать лишней электроэнергией, например кондиционеры на обогрев включать. Или, чтобы не гонять зря мотор, дизельное топливо можно направлять в печку напрямую, как в электробусах или электромобилях. Экономим ресурс генератора, достаточно в таком режиме одного генератора на 4 вагона.
Вам бы военную технику проектировать.
Вагоны все равно нужно обслуживать.
Ну да. Поэтому если добавить десяток операций, то стоимость и время обслуживания не изменится. Так что ли?
Есть. Но без кондиционера можно жить. Я имею ввиду именно охлаждающую установку. Не знаю как у современных вагонов устроена система вентиляции, но вполне вероятно, что она может работать и в пассивном режиме при движении поезда. Электрические отопители весьма надёжны. Но вот когда из-за выхода из строя двигателя у тебя вообще нет электричества, то не работает ни кондиционер, ни отопление. Допустим, что в таком воображаемом вагоне с дизель-генератором всё же есть аварийное питание, от акков или генератора с приводом от колёсной пары, но его хватит на освещение, и вентиляцию, никак не на отопление. Кроме того, если у нас в вагоне есть помимо кондиционера ещё и дизель, то надо обслуживать два аппарата вместо одного. Выход из строя любого из них приведёт к сбою кондиционирования. Две точки отказа вместо одной.
А когда у нас есть вагон-электростанция, то его можно поставить на плановое обслуживание целиком и взять резервный вагон в поезд. А не все вагоны поезда поставить на обслуживание. Если в пути случилось ЧП, и один из дизелей вышел из строя, есть резервный. Его можно запустить и на ходу заняться обслуживанием дохлого. Или дотянуть до депо.
В общем, мне лично такой подход с индивидуальным генератором на вагон кажется плохим прям со всех сторон.
Почему 202,5 кВт? От 60 до 90 в зависимости от типа вагона. Это в рывке. А так как один из трёх генераторов в запасе, значит обычно вагону хватает 2/3 максимальной мощности. То есть 40 и 60 кВт на обычный и двухэтажный вагон.
Я почитал серию ваших комментариев, и мне кажется, вы плохо представляете себе все сложности обслуживания десятков дизельных двигателей. И это только для одного состава.
Мне кажется, преимущество в модульности. Надо больше энергии, ок, у нас есть вагон генератор. И не надо для этого разрабатывать новый электровоз с избыточной мощностью электрогенераторов, которая ещё и нередко окажется ненужной.
В номинале один вагон-электростанция способен обеспечить электроэнергией до 23 одноэтажных вагонов (с централизованным электроснабжением) или 15 двухэтажных вагонов зимой, когда у них включено отопление.
Речь, напомню, о электростанции мощностью 1350 кВт. То есть на один двухэтажный вагон до 90 кВт.
Кстати, редактор в админке при создании файла использует файл шаблона страницы (их даже может быть несколько на выбор). Можно его отредактировать. В шаблоне сайта это директория page_templates. Документация.
И какое оно? Я не могу понять как интерпретировать такие оценки в этом ключе. Статья о том, что вам не понравился Битрикс, значит плюсы статье это минусы Битриксу? А минусы статье, это потому что статья про Битрикс на Хабре не нужна должна быть заминусована. Так что это тоже минусы Битриксу?
Битрикс на Хабре никогда не любили. Самому Битриксу от этого, кажется, ни тепло, ни холодно.
А кто это должен делать? Я? Но как? Битрикс обновляется через собственную систему обновления.
В принципе, он правильно пишет. Битриксу действительно необходимы права на запись всюду. И даже его собственное ядро не является исключением. Хотя бы из-за обновлений. Но я лично не сталкивался с проблемами из-за этого. Плюс у Битрикса есть собственные механизмы безопасности: проактивная защита, сканер уязвимости. А сам продукт периодически проходит какие-то аудиты безопасности, что даёт какую-то надежду, что при регулярных апдейтах хотя бы через уязвимости ядра ничего не пролезет.
Я, в силу опыта работы с ним, хорошо знаю недостатки Битрикса. Но при этом на Вордпресс я не согласен. У него своих проблем вагон. В частности мне показалось довольно сложным поддерживать вордпресс в свежем состоянии. Потому что при обновлениях он склонен разваливаться. А если не поддерживать, то он тут же становится целью для атак. Битрикс в этом плане намного лучше. У него надёжно работающие обновления, и есть кое-какие инструменты контроля безопасности.
Не могу ничего сказать про другие CMS в сравнении - не имею опыта. Зачем вообще выбирать Битрикс? Мне кажется, Битрикс, он такой энтерпрайзный. Как 1C, винда, всякие ERP-системы. Ты платишь за лицензию, тебе дают сапорт (неплохой, кстати), обновления, а вокруг куча компаний, которые готовы разрабатывать и поддерживать сайты на Битриксе. На Битриксе работает куча корпоративных сайтов, которые не интернет-магазины.
Ну и конечно, часто решение о том, что использовать принимает разработчик, на которого довелось наткнуться заказчику. Я лично сделал горстку мелких сайтов на младших версиях Битрикса. Почему не другая CMS? Потому что я работал с Битриксом. Почему не голый фреймфорк? Потому что небольшой сайт со стандартным функционалом проще сделать на CMS.
Не уверен, что я правильно понял ваш вопрос, но думаю, что я довольно хорошо понимал жизненный цикл страницы. По крайней мере, когда работал с Битриксом. То есть лет, наверное, 7 назад.
Так можно. Вообще мне нравились в Битриксе две вещи. Система обновления и система резервного копирования. Первая способна весьма стабильно обновлять систему, причём через множество версий. А вторая способна забэкапить и с помощью одного скрипта развернуть сайт обратно в другом месте.
Но когда работаешь с системой контроля версий, кладёшь туда файлы проекта, ядро битрикса не включаешь. Соответственно появляется зависимость от конкретной версии ядра. В мире пхп такое решается через композер, только не в мире битрикса.
Можно попробовать включить и ядро в проект. Но битрикс ОЧЕНЬ тяжёл, а каждое обновление будет приводить к огромным коммитам.
Чёрт с ним с ядром. Часть конфигурации проекта неизбежно хранится в БД. Инфоблоки, например. Они меняются через интерфейс админки. Как это синхронизировать с кодом? Можно сделать подобие миграций и все подобные изменения реализовывать средствами API. Но тогда мы значительной части функционала админки, за который уплочено. И мы всё ещё не можем гарантировать, что кто-то не сделает в админке что-то, что приведёт к рассинхронизации с зафиксированным состоянием. Плюс обновления битрикса изменяют данные в БД. И как понять, были ли они безопасны относительно того, что зафиксированно в коде или нет?
В корпоративном портале с этим ещё страшнее. Там приходится синхронизировать изменения компонентов, если ты их кастомизировал, чтобы не потерять новые фичи. Так что я перед крупными апдейтами несколько дней на это выделял.
Битрикс состоит из множества слоёв легаси. В некотором смысле они выбрали виндовый подход к развитию. Я работал с битриксом более 10 лет ещё со времён php4, когда никакого ООП там вообще не было. И автолоада тоже. Тогда он не казался мне сложным. Роутинг на файлах был вполне понятен и сваливал всю работу на Apache. Компоненты просто инклюдились и конфигурировались в коде, а визуальный редактор упрощал этот процесс. Потом всё это стало обрастать зачатками MVP в новых компонентах 2.0 и комплексных компонентах, и примитивными зачатками ООП. При этом бешено разрастался функционал ещё на старых технологиях. Компоненты и шаблоны в тыщи строк сохранились в Битриксе до сих пор. Потом борьба за производительность привела к множеству слоёв кеширования. И так далее.
Потом возникла новая надежда - D7. Но он развивался крайне медленно, а старые компоненты никто не спешил переписывать, продукт был уже очень большим. К этому добавился Битрикс Корпоративный портал, который дьявольски оттягивал ресурсы на новые фичи, а рефакторинг так и не наступал. И уж тем более никогда не шло речи о новом Битриксе, несовместимом со старыми наработками. Так что D7 стал лишь ещё одним вариантом сделать что-то в Битриксе.
Из-за того, что компоненты жили в директории bitrix рядом с кодом самого Битрикса, было крайне сложно вести проект в системах управления версиями. Так что добавилась возможность держать свои компоненты и модули в отдельной директории. Что усложнило и без того нелёгкую процедуру поиска кода, который тебе надо исправить. Плюс часть конфигурации всё равно в БД и нет миграций. Запихнул код в гит? Поздравляю, теперь придумай как накатывать данные и обеспечить совместимость с нужной версией Битрикса.
В итоге образовалась какая-то адовая сложность. Тонны документации, курсы, сертификация. Я наблюдал, как люди, которым я делал сайты, даже поддерживать их не могут. Некоторые битриксоиды считают это за плюс - всегда хватает работы по поддержке.
Вроде бы Битрикс никогда не принадлежал 1С. Это совместное предприятие.
Ну как... Битрикс, который для магазинов (редакции Бизнес), имеет модуль для интеграции с 1C. Так как 1С у каждого предприятия имеет свои особенности конфигурации, нельзя просто взять и настроить этот модуль в админке, чтобы отчётность и склад заработали. Требуется работа по интеграции и стоить она будет прилично. Но далеко не все даже интернет магазины это используют. И есть куча сайтов на Битриксе, которые магазинами не являются и вообще никакую интеграцию с 1С не используют.
Может потому что курьеры работают не на сам Самокат, а через компанию-прокладку - партнёра? А может для повышения собственной значимости курьеров. А может и то и другое.
И это тоже выдаёт в этой историю маркетинговую лабуду. Ну будет нормальный человек так писать текст? А маркетолог компании будет.
Тоже это насторожило. И либо это история для того самого героя комикса, либо в Самокате всё вот настолько дырявое. Ну ладно, ещё возможен вариант, что всё было и в имеющемся приложении, только неудобно, так что герой рассказа проанализировал взаимодействие с бэком и переписал фронт.
"Московские новости" сообщают про 11 пострадавших.
Это понятно. Хотя, вот прямоугольник со скруглёнными углами, это очень
хорошаяполезная для компании формула изобретения, хорошо иметь такой патент. А на вот это... Ну такое. Если бы это был более абстрактный патент на способ установки питаемых аксессуаров на ноутбук, то было бы лучше.Скорее всего. Но так как это ледокол, кажется, что не велика проблема. Важнее эффективно ломать лёд, а до льда он уж как-нибудь доползёт. Он атомный, энергии много.
Реально сомнительная штука в том виде, в котором изображена в патенте. Помимо неудобства использования клавиатуры можно найти и другие недостатки. П-образная форма означает, что снизу под ноутбуком с одной стороны появляется некоторая толщина, которую также нужно скомпенсировать с остальных четырёх сторон для устойчивости ноута. А как? Надетое устройство не позволит закрыть ноутбук. Значит его надо каждый раз снимать. А при перевозке ноута из-за своей формы этот зарядник будет занимать изрядно места в сумке или рюкзаке. Почему он хотя бы не Г-образный? Ну и потери энергии у беспроводной зарядки выше, а значит часть ценной энергии батареи ноута вылетит в трубу. Дополнительный USB-разъём и короткий кабель кажутся на фоне этого куда более удобным решением. Или даже внешняя беспроводная станция с коротким проводом - она по крайней мере более компактна и не мешает пользоваться клавиатурой самого ноутбука и закрывать его.
Так, давайте ка не вносить изменения в исходные условия. У нас вагон с электрическим отоплением.
Только если он ломается весь. Но там есть резервный генератор, которого нет в вагоне.
Речь о плановом обслуживании. Вагону никуда не надо ехать. На случай ЧП в пути есть резервный генератор.
Перегрузив генератор вдвое?
Дело как раз в том, что у них нет лишней энергии и им негде её взять в принципе. Электрический нагреватель в вагоне позволяет сделать универсальное решение для электрифицированных линий и для неэлектрифицированных. кстати я не видел электромобилей с подогревом топливной печкой.
Вам бы военную технику проектировать.
Ну да. Поэтому если добавить десяток операций, то стоимость и время обслуживания не изменится. Так что ли?
Есть. Но без кондиционера можно жить. Я имею ввиду именно охлаждающую установку. Не знаю как у современных вагонов устроена система вентиляции, но вполне вероятно, что она может работать и в пассивном режиме при движении поезда. Электрические отопители весьма надёжны. Но вот когда из-за выхода из строя двигателя у тебя вообще нет электричества, то не работает ни кондиционер, ни отопление. Допустим, что в таком воображаемом вагоне с дизель-генератором всё же есть аварийное питание, от акков или генератора с приводом от колёсной пары, но его хватит на освещение, и вентиляцию, никак не на отопление. Кроме того, если у нас в вагоне есть помимо кондиционера ещё и дизель, то надо обслуживать два аппарата вместо одного. Выход из строя любого из них приведёт к сбою кондиционирования. Две точки отказа вместо одной.
А когда у нас есть вагон-электростанция, то его можно поставить на плановое обслуживание целиком и взять резервный вагон в поезд. А не все вагоны поезда поставить на обслуживание. Если в пути случилось ЧП, и один из дизелей вышел из строя, есть резервный. Его можно запустить и на ходу заняться обслуживанием дохлого. Или дотянуть до депо.
В общем, мне лично такой подход с индивидуальным генератором на вагон кажется плохим прям со всех сторон.
Почему 202,5 кВт? От 60 до 90 в зависимости от типа вагона. Это в рывке. А так как один из трёх генераторов в запасе, значит обычно вагону хватает 2/3 максимальной мощности. То есть 40 и 60 кВт на обычный и двухэтажный вагон.
Я почитал серию ваших комментариев, и мне кажется, вы плохо представляете себе все сложности обслуживания десятков дизельных двигателей. И это только для одного состава.
Дизельный двигатель нужно обслуживать. Это не печку топить.
Мне кажется, преимущество в модульности. Надо больше энергии, ок, у нас есть вагон генератор. И не надо для этого разрабатывать новый электровоз с избыточной мощностью электрогенераторов, которая ещё и нередко окажется ненужной.
Речь, напомню, о электростанции мощностью 1350 кВт. То есть на один двухэтажный вагон до 90 кВт.