Таким образом, получаем полностью сконфигурированную шину сообщений. Очень просто, не правда ли?
Как раз этот блок конфигураций не сказать что очевидный, особенно тому, кто только начал разбираться.
Разжевали бы, что именно там происходит — полезность статьи сильно бы повысилась.
Вопрос по поводу именования шины ('message-bus').
Имеет ли смысл именовать класс, у которого по определению уже есть имя, причем уникальное?
Иначе говоря, зачем писать
$bus = $this->container->get('message-bus');
если можно
$bus = $this->container->get(MessageBus::class);
плюсы
1) в любой IDE переходим в определение класса по ctrl+ПКМ
2) опять же, при случае, переименовать класс в IDE гораздо удобнее, чем реплейсить строку 'message-bus'
Если вы подразумеваете под архитектурой принцип, по которому файлы
раскидываются по папочкам — да, есть такая тенденция, что фреймворки
это регламентируют все меньше. Как минимум, есть 2 фундаментальных принципа —
разложить по типам (контролеры / вьюшки / исключения и пр.) или же
разложить по фичам (например, есть папка User, в которой все что связано с юзером).
Эта неопределенность действительно немного усложняет вхождение в проект,
но при четком следовании заложенным изначально принципам (которые по хорошему
нужно первый пунктом описать в документации проекта) это не большая проблема.
Под архитектурой проекта можно понимать и логическое деление на компоненты,
а также регламент их взаимодействия. Например, в каком порядке выполняются обработчики запроса или как приложение обрабатывает исключительные ситуации. Это уже завязано на поток выполнения, который контролирует сам фреймворк, и именно это отличает фреймворк от библиотеки. Эти составляющие неизменны и именно их понимание определяет умение разработчика работать с фреймворком.
отличный вариант с весьма низким порогом вхождения, огромным кол-вом гайдов на любые темы и живым комьюнити
Я и про CakePHP это же могу сказать. Symfony c 4 версии например вообще как микрофреймворк позиционируется, простой как 5 копеек. По количеству гайдов и комьюнити с мейнстримом вообще смешно сравнивать.
Понимаете ли в чем дело, Perl тоже хороший язык. Но я бы не рекомендовал начинать сейчас с Perl только потому что он хороший и мне нравится
На какой версии Yii вы бы порекомендовали пилить новый проект? Порекомендовали бы джуну в качестве первого фреймворка?
Да, был очень популярен 6-7 лет назад в странах СНГ.
Сейчас я не хочу тащить в проект морально устаревший и склонный к велосипедированию Yii2.
Особенно забавно смотрятся прибитые гвоздями в php фрейм bower и jquery.
Возможно Yii3 будет хорош, но все что про него сейчас известно — за ~4 года его сделали наполовину.
Ну ок, принудят, так я чуть позже обратно верну (при условии что можно в любой момент отозвать голос, принудиловка себя не оправдает). Как «злоупотребители» узнают что я отозвал голос, им SMS придёт?
Про второй аргумент вообще не понял, приведите пример.
Ну кстати нормальные системы электронного голосования именно эти проблемы и могли бы решать.
— возможность делегировать свой голос человеку, которому доверяешь.
— возможность вообще в любой момент свой голос перенаправить / отозвать. Таким образом некомпетентный представитель власти может быть отстранен от неё сразу же, как только свою некомпетентность проявит.
Тут тоже много тонкостей, поэтому такие возможности требуют множества уточнений (как, впрочем, и любые другие процессуальные нормы), но принципиально неразрешимых проблем тут нет.
Что касается краеугольной проблемы доверия (что автор справедливо выделяет как главную проблему) — да, тут к сожалению ничего не поделать. Мне представляется что это уже вопрос философии — если ли вообще в мире такая информация, которой можно доверять безоговорочно =) В любом случае, при правильно построенной системе ЭГ это ровно одно место, которое будет требовать дополнительного контроля, что уже неплохо.
Несчастными людей делает не наличие комфорта, а отсутствие цели, а это не одно и тоже.
Базовые потребности настолько очевидны и универсальны, что автоматически становятся целью, если человек испытывает нехватку в них. Если же базовые потребности полностью покрываются, цели приходится выбирать, а это не такая уж и простая задача.
Просто следующая ступень декомпозиции и выворачивания кишками наружу минимальных единиц исполнения кода. Были уже IaaS, PaaS, SaaS, теперь доехали до FaaS (function as a service).
Но как по мне, serverless — название неудачное. Какой нафиг серверлесс, если все вычисления выполняются на серверах?
Есть и еще одна причина выбирать максимально строгие правила — убрать правило можно всегда, а вот добавить после килотонн написанного кода уже бывает поздно.
Да, бывают (псевдо)перфекционисты, которые следуют правилам без понимания, но это быстро исправляется вежливой беседой с правильно задаваемыми вопросами… ну или само как-то с опытом приходит.
И добавлю еще пару выкриков в пустоту:
— разделение проверки код стайла и самого код ревью — очень хорошая вещь.
— мало договориться о правилах, нужно к каждому правилу дописывать его обоснование. Чтобы не было «какие-то законы, которые придуманы фиг пойми для чего»
Тут вы правы, охотно верю что все крупные компании подвержены таким фейлам и виноваты в конечном счёте всегда они, это неизбежная составляющая публичности.
Однако, выскажу то, что обычно политкорректно умалчивают — чисто по-человечески обидно за IT специалистов, вынужденных общаться с неадекватными клиентами, по полной использующих вот эту вот пресловутую "клиент всегда прав".
Потерпевшая сторона использует слово "газлайтинг", что весьма иронично — она то может оскорблять и унижать сотрудников компании, она же за это деньги заплатила(
Любопытненько.
Несмотря на то, что некоторые погрешности со стороны организаторов присутствуют (за что они судя по скриншотам сами извиняются), почти полностью статья состоит из необоснованных и надуманных обвинений.
Не буду все перечислять, но где это является общей практикой «тыкать»? Я например обращаюсь на «ты» только к людям, которые являются моими хорошими знакомыми. Ничего глубокого в это не вкладываю, просто базовая вежливость, не более.
И почему скриншоты от имени Ирины, а автор на Хабре — Денис? Странная коллаборация, пусть уж пострадавший человек сам за себя ответит.
Насчет бенчмарков.
Вот вы их делаете в /mnt/c.
Но дело в том что /mnt — это ФС монтированая из Windows, отсюда и проблема с производительностью, т.к. linux с NTFS не очень.
Попробуйте тот же Jekyll генерировать в /home/username, должно быть наоборот ускорение в 2-5 раз (если верить этому)
По смыслу — да, вы совершено правы. Подход «гений царит над хаосом» работает только после того, когда всё что только возможно упорядочить уже упорядоченно.
Как раз этот блок конфигураций не сказать что очевидный, особенно тому, кто только начал разбираться.
Разжевали бы, что именно там происходит — полезность статьи сильно бы повысилась.
Вопрос по поводу именования шины ('message-bus').
Имеет ли смысл именовать класс, у которого по определению уже есть имя, причем уникальное?
Иначе говоря, зачем писать
если можно
плюсы
1) в любой IDE переходим в определение класса по ctrl+ПКМ
2) опять же, при случае, переименовать класс в IDE гораздо удобнее, чем реплейсить строку 'message-bus'
Если вы подразумеваете под архитектурой принцип, по которому файлы
раскидываются по папочкам — да, есть такая тенденция, что фреймворки
это регламентируют все меньше. Как минимум, есть 2 фундаментальных принципа —
разложить по типам (контролеры / вьюшки / исключения и пр.) или же
разложить по фичам (например, есть папка User, в которой все что связано с юзером).
Эта неопределенность действительно немного усложняет вхождение в проект,
но при четком следовании заложенным изначально принципам (которые по хорошему
нужно первый пунктом описать в документации проекта) это не большая проблема.
Под архитектурой проекта можно понимать и логическое деление на компоненты,
а также регламент их взаимодействия. Например, в каком порядке выполняются обработчики запроса или как приложение обрабатывает исключительные ситуации. Это уже завязано на поток выполнения, который контролирует сам фреймворк, и именно это отличает фреймворк от библиотеки. Эти составляющие неизменны и именно их понимание определяет умение разработчика работать с фреймворком.
Я и про CakePHP это же могу сказать. Symfony c 4 версии например вообще как микрофреймворк позиционируется, простой как 5 копеек. По количеству гайдов и комьюнити с мейнстримом вообще смешно сравнивать.
Понимаете ли в чем дело, Perl тоже хороший язык. Но я бы не рекомендовал начинать сейчас с Perl только потому что он хороший и мне нравится
Да, был очень популярен 6-7 лет назад в странах СНГ.
Сейчас я не хочу тащить в проект морально устаревший и склонный к велосипедированию Yii2.
Особенно забавно смотрятся прибитые гвоздями в php фрейм bower и jquery.
Возможно Yii3 будет хорош, но все что про него сейчас известно — за ~4 года его сделали наполовину.
Про второй аргумент вообще не понял, приведите пример.
— возможность делегировать свой голос человеку, которому доверяешь.
— возможность вообще в любой момент свой голос перенаправить / отозвать. Таким образом некомпетентный представитель власти может быть отстранен от неё сразу же, как только свою некомпетентность проявит.
Тут тоже много тонкостей, поэтому такие возможности требуют множества уточнений (как, впрочем, и любые другие процессуальные нормы), но принципиально неразрешимых проблем тут нет.
Что касается краеугольной проблемы доверия (что автор справедливо выделяет как главную проблему) — да, тут к сожалению ничего не поделать. Мне представляется что это уже вопрос философии — если ли вообще в мире такая информация, которой можно доверять безоговорочно =) В любом случае, при правильно построенной системе ЭГ это ровно одно место, которое будет требовать дополнительного контроля, что уже неплохо.
Базовые потребности настолько очевидны и универсальны, что автоматически становятся целью, если человек испытывает нехватку в них. Если же базовые потребности полностью покрываются, цели приходится выбирать, а это не такая уж и простая задача.
Всё так, только потом apt-get clean не забываем делать
Но как по мне, serverless — название неудачное. Какой нафиг серверлесс, если все вычисления выполняются на серверах?
Да, бывают (псевдо)перфекционисты, которые следуют правилам без понимания, но это быстро исправляется вежливой беседой с правильно задаваемыми вопросами… ну или само как-то с опытом приходит.
И добавлю еще пару выкриков в пустоту:
— разделение проверки код стайла и самого код ревью — очень хорошая вещь.
— мало договориться о правилах, нужно к каждому правилу дописывать его обоснование. Чтобы не было «какие-то законы, которые придуманы фиг пойми для чего»
Тоже хочу всегда в срок успевать
Тут вы правы, охотно верю что все крупные компании подвержены таким фейлам и виноваты в конечном счёте всегда они, это неизбежная составляющая публичности.
Однако, выскажу то, что обычно политкорректно умалчивают — чисто по-человечески обидно за IT специалистов, вынужденных общаться с неадекватными клиентами, по полной использующих вот эту вот пресловутую "клиент всегда прав".
Потерпевшая сторона использует слово "газлайтинг", что весьма иронично — она то может оскорблять и унижать сотрудников компании, она же за это деньги заплатила(
Несмотря на то, что некоторые погрешности со стороны организаторов присутствуют (за что они судя по скриншотам сами извиняются), почти полностью статья состоит из необоснованных и надуманных обвинений.
Не буду все перечислять, но где это является общей практикой «тыкать»? Я например обращаюсь на «ты» только к людям, которые являются моими хорошими знакомыми. Ничего глубокого в это не вкладываю, просто базовая вежливость, не более.
И почему скриншоты от имени Ирины, а автор на Хабре — Денис? Странная коллаборация, пусть уж пострадавший человек сам за себя ответит.
На просторах интернета находил и совсем фантастические варианты (97 байт?!), но такое запускается при ну очень специфических условиях
Вот вы их делаете в /mnt/c.
Но дело в том что /mnt — это ФС монтированая из Windows, отсюда и проблема с производительностью, т.к. linux с NTFS не очень.
Попробуйте тот же Jekyll генерировать в /home/username, должно быть наоборот ускорение в 2-5 раз (если верить этому)
twitter.com/andyweirauthor/status/1128172660939153408