Скорей это делается для тех, кто уже работает в win10. Местами даже возможно будет полезно: с python в win серьезная боль при сборке в pip зависимых от C/C++ компилятора библиотек, что к примеру упростит использование питона с бубунты :) Кроме того, можно развернуть изолированный веб-сервер, хотя пока не ясно как там организована работа tcp/ip/sockets.
Плюс отчасти для ряда задач отпадет необходимость использования docker, vagrant и прочих "радостей" мира виртуализации.
Полностью согласен с вами — чем больше затягиваются гайки на единственной системе ценностей для данного ресурса — тем больший отток пользователей и меньший приток новых. Все сводится к простому итогу: за статьи не платят, рейтинг за статью удалят через месяц — по сути будто этой статьи и не было, поэтому бОльшая часть материалов — чистая реклама с забитым болтом на систему рейтинга. Есть много ресурсов, далеко не научных, где на качественных публикациях можно либо заработать либо получить авторитет, хабр утерял это, к сожалению.
Попытался расшевелить авторитетов, давал бы им отрицательный рейтинг за отсутствие активности — например больше года, может тогда к кому то можно будет обращаться.
Обратите внимание на тех же "идолов" которые вы сами привели выше: ни один из них не движется в сторону усложнения пользовательских рейтинов и систем ценностей "лайков/сердечек/классов" и прочих. Чем больше будут затягиваться гайки, тем больший будет отток пользователей и активных авторов.
На хабре все объясняется куда проще — просто целевая аудитория, которая сидит тут не первый год и имеет какое-либо право на голос/влияние на оценку материалов выросла вместе с самим сообществом. Именно поэтому, 90% статей на хабре — чистая реклама. Посмотрите на статьи в песочнице, которые вскоре можно будет назвать мифом — они вполне качественные, как для начального уровня, но все те же "старожилы" их просто закидают д***мом т.к. в текущий момент времени их навыки в данном вопросе куда выше (к сожалению такая натура человека, мы вряд ли вспомним и приведем в пример то, каков был наш код и его качество n-лет назад) но это вовсе не отменяет необходимости такого рода материалов.
Единственный вариант, по моему скромному мнению, для хабра — это наследование модели публикации как в классической науке с некоторыми изменениями.
А еще насколько я помню по принципам best practice вызов validate() модели при работе с формами лучше выполнять из контроллера, а не метода модели. Т.е. вот это:
if ($model->load(Yii::$app->request->post()) && $model->sendEmail()) {
Yii::$app->session->setFlash('mailerFormSubmitted');
return $this->refresh();
}
нужно привести к виду:
if ($model->load(Yii::$app->request->post()) && $model->validate()) {
$model->sendEmail();
Yii::$app->session->setFlash('mailerFormSubmitted');
return $this->refresh();
}
ну и соответственно убрать ->validate из метода модели и бессмысленные ретурны :)
П.с. — да, статья вовсе не для хабра, в 2008 или ранее возможно бы и было полезно, но такого рода материалов уже не счесть итак.
Неплохой сборник полезных сервисов для анализа сайта (дабы не держать закладки/вручную прокликивать сервисы). Хотелось бы под огнелиса аналогичный плагин.
На хабре уже было более чем достаточно постов, толковых постов, о различных лицензиях и их сравнении, см. тут.
п.с. — вы не шутите, загрузив .bmp картинки, состоящие из черного и белого весом по 1,5-2 мб? В png пожмите (выйдет 10-15кб), не насилуйте людям браузеры…
К вашему сведению opcache включен начиная с PHP 5.5 по-умолчанию, тесты с PHP-FPM показывают аналогичный результат. Ещё объективные возражения по поводу условий тестирования?
Насколько я помню, начиная с версии php 5.5 входит в состав сборки бинарника php, однако он НЕ включен по умолчанию:
;opcache.enable=0
Конечно стараюсь. Но теперь давайте по сути, а не абстрактно и в вакуме. Возьмем достаточно большой файл, что в стиле кодирования такого, что делает код едва ли доступным и расширяемым? Буду очень благодарен комментариям по существу, а не «не такой как все — вон из профессии».
Во 1х вы наступили на те же грабли, на которые я наступил полтора года назад — у вас очень много (а возможно и все) классов наследуют паттерн singleton, который сам по себе является «мертвым» как для расширения так и для тестирования. Очень многие модели реализации в вашей CMS куда лучше будут выглядеть и работать в виде тех же factory, DI — ведь именно в умении выбрать правильный паттерн для конкретной реализации и заключается одна из составляющих работы программиста.
Вы пробовали, к примеру отлаживать Composer, который использует немало компонентов Symfony? Я пробовал, блуждание по пустым прокси-вызовам убивает желание вникать в проект напрочь. Как раз из-за меньшего количества «пустых» вызовов стек меньше и гораздо понятнее.
Верно, но это лишь их огрех из-за больших прослоек прокси или абстракций, уже не помню где, но есть рекомендации по количеству «прослоек» от крайней к основной модели реализации.
Так не кто субъективно не обсуждает личность разработчика и его вклад в opensource, обсуждается именно программный код и принципы, на которые опирался автор, когда его писал.
То есть, вы сознательно игнорируете стандарты стиля и качества написания кода и это по вашему дает вашему проекту больший performance?
Как результат — движок, рендерящий страницу с запросом в БД работает существенно быстрее фреймворка, который никаких запросов не делает и рендерит примитивнейшую фиксированную страницу. В реальных условиях разброс будет ещё больше.
Я скажу вам больше, процедурный код, реализующий те-же функциональные особенности забитый в 1 файл будет делать это еще быстрей, однако вы же не пошли по этому пути. Вы стараетесь, хотя-бы отчасти, сделать ваш проект доступным для работы и доработки другими людьми, расширяемым, однако это едва-ли возможно если вы не следуете общепринятым принципам (т.к. вследствие этого другому человеку нужно будет потратить время на изучение именно вашего стиля расширения).
Отдельно стоит упомянуть размер стека вызовов при ошибке — в CleverStyle CMS он будет существенно меньше чем у Symfony, более осмысленный и простой для понимания, всё это результат осознанного выбора при принятии архитектурных решений.
А будет ли он таким же гибким и понятным как в symfony?
П.с. — все проблемы, связанные с расходом ресурсов и временем генерации страниц уже давно решаются при помощи nginx/php-fpm+opcache и прочих шалостей, даже для таких монстров как bitrix(господь упаси).
Проекту явно не хватает автозагрузки с единым стандартом для Namespace\\Class, развертывания из композера и слежение за версиями им же и много чего прочего, что можно изучить по ссылкам выше.
Не знаю за что автора данного, пусть и рекламного поста так усердно сетуют и пинают, но скажу одно — на старом рабочем стенде vertex 4 проработал 2 года (с учетом пары виртуалок, ide с автосохранением, индексацией и кучей мелких файлов) без каких-либо параноидальных настроек и в данный момент его «health» на уровне 98%. Никаких сбоев по вине «ssd» у меня не случалось. На новой железке так же стабильно работает arc 100 (хотя по сети ходят «сплетни» о их ненадежности) и все аналогично хорошо.
По поводу «скорости работы» я думаю для данной аудитории она должна быть более, чем очевидна: возьмите любой «большой» проект на java/php/etc и выгрузите его в ide.
На всякий случай поясню — измениться лишь модель распространения для enterprise пользователей (на странице это явно указано, как и ранее в новостях adobe), для обычных пользователей flash player будет распространяться как и ранее.
Действительно можно, тот же yii2 вам в пример с аналогичными «пакетами» (здесь они называются «расширения») — www.yiiframework.com/doc-2.0/guide-structure-extensions.html. Аналогичные подходы есть и в kohana и laravel с пакетными «наборами» и возможностью динамической инициации в роутере.
Тоже согласен, в случае, если нет уверенности в «успешной и долгой» жизни используемого пакета в vendor или у вас достаточно сильно выражена паранойя можно попросту сделать его форк (что благодаря github делается в полтора клика). Да, это все же будет отнимать определенное время на обслуживание сторонней библиотеки(мержи и т д) но вы будете уверены в том, что до тех пор, пока вам необходим данный пакет он будет доступен.
Плюс, если у вас имеется механизм «релиза» (аналогичный github) можно прикреплять «скомпилированные» версии вашего продукта с включенной папкой vendor на дату релиза.
Очень плачевно видеть на хабре записи, которые бы поместились в твит… Привели бы хоть пару примеров что-ли, что-зачем и для чего лежит в этом репозитории…
Насколько популярен данный «интернет-магазин»? Возможно «веб-мастер» техник, обслуживающий его даже не осознал наличия потенциального доступа к базе данных по средствам SQL-инъекции?
Плюс отчасти для ряда задач отпадет необходимость использования docker, vagrant и прочих "радостей" мира виртуализации.
Обратите внимание на тех же "идолов" которые вы сами привели выше: ни один из них не движется в сторону усложнения пользовательских рейтинов и систем ценностей "лайков/сердечек/классов" и прочих. Чем больше будут затягиваться гайки, тем больший будет отток пользователей и активных авторов.
На хабре все объясняется куда проще — просто целевая аудитория, которая сидит тут не первый год и имеет какое-либо право на голос/влияние на оценку материалов выросла вместе с самим сообществом. Именно поэтому, 90% статей на хабре — чистая реклама. Посмотрите на статьи в песочнице, которые вскоре можно будет назвать мифом — они вполне качественные, как для начального уровня, но все те же "старожилы" их просто закидают д***мом т.к. в текущий момент времени их навыки в данном вопросе куда выше (к сожалению такая натура человека, мы вряд ли вспомним и приведем в пример то, каков был наш код и его качество n-лет назад) но это вовсе не отменяет необходимости такого рода материалов.
Единственный вариант, по моему скромному мнению, для хабра — это наследование модели публикации как в классической науке с некоторыми изменениями.
нужно привести к виду:
ну и соответственно убрать ->validate из метода модели и бессмысленные ретурны :)
П.с. — да, статья вовсе не для хабра, в 2008 или ранее возможно бы и было полезно, но такого рода материалов уже не счесть итак.
п.с. — вы не шутите, загрузив .bmp картинки, состоящие из черного и белого весом по 1,5-2 мб? В png пожмите (выйдет 10-15кб), не насилуйте людям браузеры…
Насколько я помню, начиная с версии php 5.5 входит в состав сборки бинарника php, однако он НЕ включен по умолчанию:
Во 1х вы наступили на те же грабли, на которые я наступил полтора года назад — у вас очень много (а возможно и все) классов наследуют паттерн singleton, который сам по себе является «мертвым» как для расширения так и для тестирования. Очень многие модели реализации в вашей CMS куда лучше будут выглядеть и работать в виде тех же factory, DI — ведь именно в умении выбрать правильный паттерн для конкретной реализации и заключается одна из составляющих работы программиста.
Верно, но это лишь их огрех из-за больших прослоек прокси или абстракций, уже не помню где, но есть рекомендации по количеству «прослоек» от крайней к основной модели реализации.
Я скажу вам больше, процедурный код, реализующий те-же функциональные особенности забитый в 1 файл будет делать это еще быстрей, однако вы же не пошли по этому пути. Вы стараетесь, хотя-бы отчасти, сделать ваш проект доступным для работы и доработки другими людьми, расширяемым, однако это едва-ли возможно если вы не следуете общепринятым принципам (т.к. вследствие этого другому человеку нужно будет потратить время на изучение именно вашего стиля расширения).
А будет ли он таким же гибким и понятным как в symfony?
П.с. — все проблемы, связанные с расходом ресурсов и временем генерации страниц уже давно решаются при помощи nginx/php-fpm+opcache и прочих шалостей, даже для таких монстров как bitrix(господь упаси).
П.с. — покажите проект с 10/10 ( я до 8ки вылизывал достаточно долго).
Проекту явно не хватает автозагрузки с единым стандартом для Namespace\\Class, развертывания из композера и слежение за версиями им же и много чего прочего, что можно изучить по ссылкам выше.
Я думаю данная тенденция очень легко объяснима:
По поводу «скорости работы» я думаю для данной аудитории она должна быть более, чем очевидна: возьмите любой «большой» проект на java/php/etc и выгрузите его в ide.
Плюс, если у вас имеется механизм «релиза» (аналогичный github) можно прикреплять «скомпилированные» версии вашего продукта с включенной папкой vendor на дату релиза.
«веб-мастер»техник, обслуживающий его даже не осознал наличия потенциального доступа к базе данных по средствам SQL-инъекции?