Самая классная фича PHPStorm (и экономически себя оправдывающая) — встроенные WebStorm + Datagrip.
Неплохие фичи (хотелось бы дальнейшего развития) для DevOps'a (шелл, ссх, докер, кубер). Есть плагины на почти все случаи жизни (Markdown? Пожалуйста!).
Если речь про ранчер 1.6 — то да, тоже замечал что ipsec & dns помирают время от времени. Но в 2.0 уже ничего этого нет, пока не замечал таких странностей.
Он же в каталоге вроде есть. Но там есть нюансы в зависимости от ингресс контроллера…
З.Ы. Для меня неожиданность, что ранчер довольно популярное и/или узнаваемое решение в русскоязычном сегменте (да и вообще на этой стороне света)) Наверное стоит организовать какое-то комьюнити...
А не сложно для обычных разработчиков? Тут конфиги уже готовые, а как же понимание?
Как мне было бы проще взять Rancher 2.0 (установка в 1 клик докер команда) и зная AWS ключи можно поднять кластер в один клик без всяких kops и terraform...
Вот теперь понял.
Да действительно, для примитивного типа array и ArrayAccess придется создавать свой псевдотип (например «hashable»?) и оно никак не будет пересекается с «iterable».
Пойти что-ли предложить им «hashable» RFC? ))
Ответ почему типы решили объявлять в конце функции, а не в начале есть тут.
В целом думаю ориентир был на Hack, где это уже было реализовано именно так (типа зачем плодить другие варианты).
Верно! Тогда почему от хранилища с доступом по ключу ждут возможность итерации (iterable)? )
foreach для ArrayAccess никогда работал — https://3v4l.org/8H8vR
А что в PHP есть встроенные классы, которые реализуют только интерфейс ArrayAccess?
Насколько я помню (но могу и ошибаться), все кто реализует ArrayAccess так или иначе используют и Traversable интерфейс в конечном итоге. Например, тот же ArrayObject — он будет принят через «iterable» тип.
Другой вопрос самописные классы — но в них нет проблем добавить еще один дополнительный интерфейс Iterator или IteratorAggregate и все так же будет работать…
Ну проколы бывают у всех. Это хотели сломать еще в 7.0.0 — что было бы естественным.
Обьяснение
It is unfortunate that this change had to happen in a patch release, rather than in PHP 7.0.0. It's my fault that I did not notice during the pre-release cycle that this previously relatively harmless bug completely breaks the null-coalesce operator in PHP 7. However, that's how things went, and at this point a fix was critical.
For reference, the way to fix any issues with this change is to make sure your __isset() or offsetExists() functions behave correctly. If this change causes issues with your code, it indicates that you already have a broken __isset/offsetExists implementation, but it's brokenness did not previously surface (one bug canceling another...)
А вообще согласен, даже patch версии нельзя бездумно или автоматически обновлять, хотя бы не почитав changelog. )
Если говорить о нагрузке, то на данный момент в течение дня приходит от 600 до 2000 строчек с логами в секунду, с периодическими всплесками до 10 тысяч строчек. Данную нагрузку система переваривает без каких-либо проблем.
А можно поинтересоваться мощностью ваших машин выделенных под ELK стек?
Безусловно Rancher со swarm'ом не идет ни в какое сравнение. У ранчера отличное API и есть CLI утилиты. И идея иметь параллельный docker-compose и rancher-compose — тоже отличная идея (в отличии от того же Kubernetes).
Это — docs.rancher.com/rancher/rancher-services/storage-service?
Да, но там всего лишь 2 провайдера, glusterfs (который боязно применять в продакшене) и nfs который тормознутый даже для dev (плюс избыточно). А вот если настроить на хосте convoy с каким-то бекендом, то ранчер по сути не видет это все хозяйство и управлять volumes можно только в консоли хостов. Но подвижки в этом направлении в ранчере идут. Надеюсь вызреет что-то )
более гибкий service discovery
А чего именно Вам не хватает?
Встроенных провайдеров много — это однозначно плюс, но хардкод
<service>.<stack>.<env>.<domain>
иногда избыточен. Нахватает возможностей CNAME из самого ранчера (чтобы не лазить в сам провайдер).
К примеру lb.project1.dev.domain.com -> LB разбрасывает запросы на другие стеки (один проект но разные ветки/девелоперы) -> nginx.prj1_user1.dev.domain.com, nginx.prj1_user2.dev.domain.com и тд. Сейчас, чтобы сделать это нужно у каждого nginx сервиса открыть порт на хосте (иначе DNS запись не создать), потом пойти в LB сервис и загнать каждый стек девелопера под правило по хостнейму. Можно использовать alias'ы, чтобы прописывать более удобные DNS, но опять же это возможность отредактировать только первый уровень хостнейма.
Это да… А кто предоставляет более гибкий acl?
Ну безусловный лидер в этой области Amazon ECS с их амазоновскими полиси. Для ранчера конечно такого монстра не нужно, но GitHub провайдер и разграничений на уровне environments явно маловато (например, разные клиенты, но один прод env).
Он еще определённо сырой, НО ужасно перспективный судя по их репозиторий и активности. Мы начали его использовать для дев окружения, работает стабильно, интересная идея с каталогом готовых стеков (в том числе есть и Kubernetes), но многих вещей не хватает — тома, бекапы (интеграция с convoy), более гибкий service discovery, более гибкий acl, больше авторизаций).
Но да, хотелось бы еще реальные мнения послушать...
Думаю будет интересно все, в правильном порядке (по моему мнению это 3, 1, 2, 4).
Еще интересна тема с сотыми версиями компонентов и вообще про версионность (пакетов, модулей), будет ли версии модуля менять версию мадженты и тд. Что из себя представляет repo.magento.com, можно ли поднять зеркало, как распространять свои модули.
Это извечная борьба между производительностью и удобностью разработки. )
Ну в конфиге можно не пользоваться "::class" и ручками полное имя вписывать «User\Service\RoleService» (сначала сделать вид, что пишешь имя класса — IDE дополнит его, а потом обернуть в кавычки). И волки сыты, и овцы целы )
По моему — это вопрос правильного наименования, в статье не зря есть «best practices».
Хорошей практикой является добавления неймспейса модуля к названию сервиса. Либо использовать абсолютное название класса сервиса.
Я делаю через второй способ:
// В конфиге:
namespace User;
....
'service_manager' => [
'factories' => [
Service\RoleService::class => Factory\Service\RoleServiceFactory::class,
],
],
//В контроллере:
use User\Service\RoleService;
......
public function indexAction() {
//При вводе Ro -> выскакивает автодополнение IDE для класа RoleService
// А в PhpStorm даже без указания use вверху (потом после ввода класа шторм сам добавит нужный use)
$roleService = $this->getServiceLocator()->get(RoleService::class);
// А для автодополнения $roleService приходиться указывать PhpDoc @var
}
Ну естественно конструкция "::class" ограничивает совместимость — только от PHP 5.5.
Зато удобно, привыкаешь в мгновение ока… )
Неплохие фичи (хотелось бы дальнейшего развития) для DevOps'a (шелл, ссх, докер, кубер). Есть плагины на почти все случаи жизни (Markdown? Пожалуйста!).
Ну и правильно, а то вдруг все побегут с AWS на Гугл, а он не резиновый :)
Если речь про ранчер 1.6 — то да, тоже замечал что ipsec & dns помирают время от времени. Но в 2.0 уже ничего этого нет, пока не замечал таких странностей.
Он же в каталоге вроде есть. Но там есть нюансы в зависимости от ингресс контроллера…
З.Ы. Для меня неожиданность, что ранчер довольно популярное и/или узнаваемое решение в русскоязычном сегменте (да и вообще на этой стороне света)) Наверное стоит организовать какое-то комьюнити...
А не сложно для обычных разработчиков? Тут конфиги уже готовые, а как же понимание?
Как мне было бы проще взять Rancher 2.0 (установка в 1 клик докер команда) и зная AWS ключи можно поднять кластер в один клик без всяких kops и terraform...
P.S. № заказа: 6227979088
Да действительно, для примитивного типа array и ArrayAccess придется создавать свой псевдотип (например «hashable»?) и оно никак не будет пересекается с «iterable».
Пойти что-ли предложить им «hashable» RFC? ))
В целом думаю ориентир был на Hack, где это уже было реализовано именно так (типа зачем плодить другие варианты).
foreach для ArrayAccess никогда работал — https://3v4l.org/8H8vR
Насколько я помню (но могу и ошибаться), все кто реализует ArrayAccess так или иначе используют и Traversable интерфейс в конечном итоге. Например, тот же ArrayObject — он будет принят через «iterable» тип.
Другой вопрос самописные классы — но в них нет проблем добавить еще один дополнительный интерфейс Iterator или IteratorAggregate и все так же будет работать…
For reference, the way to fix any issues with this change is to make sure your __isset() or offsetExists() functions behave correctly. If this change causes issues with your code, it indicates that you already have a broken __isset/offsetExists implementation, but it's brokenness did not previously surface (one bug canceling another...)
А вообще согласен, даже patch версии нельзя бездумно или автоматически обновлять, хотя бы не почитав changelog. )
А можно поинтересоваться мощностью ваших машин выделенных под ELK стек?
Да, но там всего лишь 2 провайдера, glusterfs (который боязно применять в продакшене) и nfs который тормознутый даже для dev (плюс избыточно). А вот если настроить на хосте convoy с каким-то бекендом, то ранчер по сути не видет это все хозяйство и управлять volumes можно только в консоли хостов. Но подвижки в этом направлении в ранчере идут. Надеюсь вызреет что-то )
Встроенных провайдеров много — это однозначно плюс, но хардкод иногда избыточен. Нахватает возможностей CNAME из самого ранчера (чтобы не лазить в сам провайдер).
К примеру lb.project1.dev.domain.com -> LB разбрасывает запросы на другие стеки (один проект но разные ветки/девелоперы) -> nginx.prj1_user1.dev.domain.com, nginx.prj1_user2.dev.domain.com и тд. Сейчас, чтобы сделать это нужно у каждого nginx сервиса открыть порт на хосте (иначе DNS запись не создать), потом пойти в LB сервис и загнать каждый стек девелопера под правило по хостнейму. Можно использовать alias'ы, чтобы прописывать более удобные DNS, но опять же это возможность отредактировать только первый уровень хостнейма.
Ну безусловный лидер в этой области Amazon ECS с их амазоновскими полиси. Для ранчера конечно такого монстра не нужно, но GitHub провайдер и разграничений на уровне environments явно маловато (например, разные клиенты, но один прод env).
Но да, хотелось бы еще реальные мнения послушать...
Еще интересна тема с сотыми версиями компонентов и вообще про версионность (пакетов, модулей), будет ли версии модуля менять версию мадженты и тд. Что из себя представляет repo.magento.com, можно ли поднять зеркало, как распространять свои модули.
Ну в конфиге можно не пользоваться "::class" и ручками полное имя вписывать «User\Service\RoleService» (сначала сделать вид, что пишешь имя класса — IDE дополнит его, а потом обернуть в кавычки). И волки сыты, и овцы целы )
Я делаю через второй способ:
Ну естественно конструкция "::class" ограничивает совместимость — только от PHP 5.5.
Зато удобно, привыкаешь в мгновение ока… )