Максим Кудрявцев

фигня, я всегда работал на куче бирж, никогда не понимал зачем себя ограничивать одной?
Ну правда апворк приносил раньше 95 процентов доходов, да и сейчас наверно тоже у большинства приносит так же.
Работы по прежнему много, упадка кроме как собственных ресурсов не чувствую.

Когда то собрал эти ссылки может помогут
PSD HTML CMS Шаблоны www.enfusionthemes.com www.mafiashare.net
HTML PSD PHOTOSHOP followdesign.com
Zoom эффект\галерея www.starplugins.com
Шаблоны chocotemplates.com css-free-templates.com
Флешь шаблоны www.flashmo.com
Шаблоны бесплатно www.websitetemplatesonline.com
Templatemonster blog.templatemonster.com/free-website-templates
PSD шаблоны all-psd.ru
Полезные разработки efimov.ws followdesign.com
Фото для фона patterns.ava7.com
Различные меню\всп окно\ и т.д. webscript.my1.ru

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

Все запущенные процессы Docker помещает в изолированную среду процессов, файловой системы и сетевого стека. Есть много особенностей по работе с Docker, т.к он предполагает, что в одном контейнере вы запускаете один процесс. Если вам нужно запустить целый набор демоном, тут появляются проблемы, нужно писать шелл-скрипт, который все это поднимет в контейнере. Так же есть особенности по сети, файловой системе. Для кого то Docker спасение и решение всех проблем, но я как сисадмин от этого всего не в восторге.

Да. Вы указываете whiteList всё остальное будет игнорироваться.

P.S. кстати можно не указывать верхний регистр, если используете флаг /i, и е находится между а-я))

/^[а-я ]+$/iu

На 32-битном проце 64-битное ядро просто не загрузилось бы. Или модель другая, или на сайте Интела опечатка.

Поставьте себя на место заказчика:
1. CMS с богатым опытом (уже более 10 лет на рынке)
2. Имеет самую большую в России долю по eccommerce
3. Имеет бесплатную качественную поддержку
4. Имеет широкую документацию
5. Во всех регионах от малых до самых топовых студий можно найти специалистов без труда.
6. Обратная совместимость. Полная и безоговорочная. Вы всегда получите доступ к новым фичам и вам не придется доплачивать дохрена программистам чтобы перейти на новую версию движка т.к. старый уже не поддерживают и он кишмя кишит дырами.
7. Уже готова большая часть функционала которая вам нужна, и оттестирована годами. Только шаблон по сути натяни + немного кастомизируй логику под свои БП.
8. Есть штатная интеграция с 1с, у нас весь бизнес в России почти на ней.

Ключевое: "бизнес не любит риски", и потому в большинстве случаев bitrix самая удобная и выгодная система для заказчика как минимум в России.

За 6 летний опыт работы в направлении веб-студий, столько компаний повидал которые писались на каких нибудь:
а) Самописных движках
б) Бесплатных движках к которым прибили гвоздями функционал который в них не заложен
в) Или вовсе на питоне/руби
... которых не хотели брать ни одна из топ 10-20 региональных студий (РнД) на поддержку, и они потом переписывали заново проекты... на bitrix.

Bitrix это стандарт отрасли по ecommerce в России. Сейчас глобальный тренд на рынке - работы по поддержке и развитию проектов становится все больше чем работы по созданию новых.

И когда вы пишите на bitrix framework, у вас будет всегда много работы, т.к. bitrix не только популярен, но становится все популярнее, следите за вектором. Сейчас он входит в топ 8 CMS в мире, за последние годы прибавил 5 позиций и продолжает увеличивать свою долю.

А на счет качества... Мне порой приходит на ум ассоциация с PHP. PHP издавна отвоевала огромную долю рынка, но потом у нее появился некоторый период застоя. А тут сбоку питоны, руби. И все ругали PHP, говорили что у него не самая лучшая поддержка ООП (немного улучшившаяся с первыми 5х релизами), но в сети были модны статьи в духе PHP не круто, "PHP все", сейчас его долю на рынке веба по откусывают.
Но вот нифига, за счет большого сообщества и богатой инерции просто PHP стал улучшаться, преодолели кризис PHP6 и разногласий, и вуаля, уже php7 который уже "более-менее", и php пошел в гору.

Так и с битрикс думаю. Скорее он уже до-перепишет свое ядро на человеческий код, чем его сместят с рынка.
Работы по новому ядру активно ведутся, и оно уже 4 год живет параллельно со старым. От релиза к релизу переписывается все большая часть модулей, компонентов, структуры базы, что немаловажно с поддержкой миграции кода и данных.

Ну и что немаловажно это те люди которые пишут этот код. Если вы в топовой веб-студии с хорошими архитекторами и ведущими программистами - код на bitrix Framework будет написан качественно, и грамотно на новом ядре в традициях ООП, использования паттернов, грамотно собраны в модули и компоненты. Если же вы фрилансер или в мелкой студии, скорей всего ваши проекты будут "дурно" пахнуть, вся логика будет в шаблонах, или вообще в 1 шаблоне который будет напрочь состоять из сплошного роутинга.

Никакого отношения сингелтону этот код не имеет.

с какой целью его автор создает экземпляр объекта в статичном методе

У этого приема много названий. По сути это статический метод-фабрика, еще можно встретить "именованный конструктор".

class User {
    private function __construct($email, $password) { /* ... */}
    public static function create($email, $password) { 
         return new static($email, $password); 
    }
    public static function createWithProfile($email, $password, UserProfile $profile) {
         $user = static::create($email, $password);
         $user->profile = $profile;
         return $user;
    }
}

$user1 = User::create('example@example.com', 'example');
$user2 = User::createWithProfile('example@example.com', 'example', new UserProfile(
    $firstName, $lastName, $avatar /* ... */
));

Основная идея тут - сделать возможность задания последовательности действий, и при этом запретить пользовательскому коду эту последовательность как-то нарушить. Все для того что бы ограничить человека от возможных ошибок.

Отличие тут в том что мы не возвращаем экземпляр класса, он однаразовый. Только для этой последовательности.

Почему бы не сделать так, спросите вы:
(new Reboot())->reboot();

Потому что нам не нужен этот инстанс. Функция reboot ничего не должна вернуть, а объект который создается - одноразовый. Почему так - надо смотреть в контексте. При работе с процессами я могу придумать десяток кейсов когда это надо.

По сути можно было бы спокойно сделать это обычной функцией, но автор посчитал что так будет читабельнее. Говнокод часть тут только имя класса - Reboot. Имена классов, интерфейсов и т.д. должны быть существительными. Мы описываем тип объектов. Но это единственное место к которому я могу придраться.