fear86
0
На Го это принято делать независимыми микросервисами, и потом связывать через тот же rest api. Плюсы и минусы такого решения как бы очевидны.
fear86
0
По опыту знаю что вертикально пиксели немного не так смотрятся как горизонтально, нет проблем с этим?
fear86
+2
А как смотреть сериальчики или ютуб во время работы на одном мониторе?
fear86
+4
А я как раз мигрирую с gitlab на bitbucket. Правда мигрирую с собственного хостинга. Так как достала возня с обновлениями и и то во что превратился интерфейс gitlab. Ну плюс bitbucket лучше и проще интегрируется с jira из коробки. Если посмотреть вокруг, по знакомым то все пользуются github и bitbucket одновременно. Gitlab пользуют единицы.
fear86
0
6-й был, он просто в релиз не вышел.
fear86
0
И причем тут oscommerce? Разработчики magento не имеют ничего общего с разработчиками oscommerce. Кроме того, что компания Irubin Consulting делала на нем сайты, перед тем как нанять Varien на разработку Magento. Но это как называть всех кто делает приложения под android, создателями android ))
fear86
–1
К сожалению еще достаточно много проектов крутится на старых версиях движка, и там даже нет поддержи php 5.4, максимум 5.3. Никто не будет обновлять движок, и уж тем более пилить поддержку нового пхп не видя в этом явной экономической выгоды.
fear86
+1
Вот и выросло новое поколение, которое не помнит настоящего хабра, когда в комментариях было в разы больше полезной информации чем во всей статье.
fear86
0
symfony2 https://github.com/symfony/symfony/blob/f29d46f29b91ea5c30699cf6bdb8e65545d1dd26/src/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php#L271
fear86
0
Так вы бы хоть написали какая была задача. И как в итоге origin помог ее решить. Было бы интересно почитать.
Тащить же сюда каждый hello world смысла нет. Учитывая что все это есть в доках.
fear86
0
Да стоит начать с kubernetes. И понять за чем все же вам нужен origin. Так как из статьи можно сделать вывод что он вам не нужен.

ps: если что можете писать в личку, я с радостью поделюсь опытом по kubernetes. Работаем с ним уже почти год.
fear86
0
Так может быть есть смысл начать сначала с него? Так как Origin по факту это расширение функционала kubernetes. Если писать статью про него то хотелось бы увидеть именно фичи origin, сборку контейнеров, менеджмент подсетей, пользователей и тд. Так как сейчас статься похоже больше на «Как сделать docker run через Kubernetes api средствами OpenShift Origin».

ps: можно было просто сделать kubectl create -f pod.json тогда не пришлось бы Origin даже сетапать ))))
fear86
0
Не совсем понятно причем тут opensoft. Это все стандартный функционал kubernets.
fear86
0
Доказать авторство на кусок кода, о существовании которого ты даже не знаешь, будет та еще задачка ) Даже у больших компаний это не всегда получается, при очевидных доказательствах копирования большого количества кода. Вспомните те же суды с гуглом и ораклом.
fear86
0
Угу, я так и написал, что это не самое лучшее решение. Но зато самое простое.
fear86
0
У нас уже давненько все отказались от ppoe/l2tp. Сейчас у всех привязка по маку. Суть в том что большинство конфигов в инете обходятся без скриптов, просто проверкой доступности шлюза провайдера. Это конечно проверка так себе, но лучше чем ничего. И тут получается мы завязаны на инфраструктуру провайдеров. А должно все работать из коробки, настроил железку, отправил ее в другой город, там ее воткнули в сеть и она работает. И тут уже без скриптов не обойтись :)
fear86
0
Просто обычно все настройки завязаны на то, что ISP статический, и ip шлюза заранее известен. Это делает железку совершенно не переносимой.
fear86
0
Отлично, вот все никак руки не доходили донастроить свой, что бы работал с dhcp. Хотелось сделать универсальный роутер все же, а не заточенный под конкретных провайдеров.
fear86
0
Ни кто же не заставляет вас этим пользоваться. Но и говорить, что нет возможности это реализовать — не корректно.
fear86
0
Closure нельзя но можно объект с методом __invoke или через рефлексию как super_closure сделать. Было бы желание )
fear86
0
Все зависит от конкретных задач, если использовать closure как точку входа для асинхронных процессов, а всю логику хранить в моделях, то можно жить.
fear86
0
Далеко нет, имеет отличное применение во всяких job queue. Лично пользуюсь super_closure + jmsjob.
fear86
–1
В чем проблема то? Serialize и вперед. Другое дело что memcache ничего не хранится постоянно, это не база данных. И расчитывать, что то что вы туда положили, получится забрать нельзя.
fear86
0
Ну и конечно же, у всего этого есть один большой минус который проигрывает микросервисному подходу. Вы будете ограниченны одним физическим сервером. Расшарить свой объект на 1+n серверов не получится.
fear86
+1
Кстати есть же http://php.net/manual/en/book.shmop.php и http://php.net/manual/en/book.pthreads.php, так что можно что то придумать )
fear86
+2
Возможно тогда вам нужен не php? Есть же вон ruby, go, python, java (тут вообще ближе всего к пхп, так как из нее уже почти все перетянули). Там как раз с этим будет проще, и не надо будет извращаться.

Так же можно не ждать, а сделать самому) http://zephir-lang.com/
fear86
+2
Вот только цена разработки (портирования) будет выше и вряд ли окупится когда либо )
fear86
+2
В чем проблема? memcache, redis, mongodb и прочие — решают эту проблему. Плюс дает вам возможность выбора конкретного решения под конкретную задачу. Нужно хранить объекты в памяти? вот вам memcache. Нужно шарить в кластере? Вот вам redis или mongo. Еще есть сессии, который нативные, и которые можно перенести по требованию в memcache или любое другое место. Ну а если вам нужен демон, то пишите демона, php отлично с этим справляется.
fear86
0
Есть смысл ради https://www.varnish-cache.org/docs/3.0/tutorial/esi.html но тут должна быть поддержка на стороне приложения.
fear86
0
Начать изучать docker с http://kubernetes.io и https://www.openshift.org
fear86
0
Хороший опыт проектирования ПО куда полезнее будет. Разработка инструментов, микросервисов, api, общая архитектура системы и отдельно взятых узлов (контейнеров). Так что легче всего будет только архитектору ПО для линукс систем, и сетей )
fear86
+3
Больше похоже на какой то перевод, но переводчик ничего не понимает в контейнерах и кластерах, поэтому и текст получился непонятный.
fear86
0
Вот тут github.com/jpetazzo/dind бери и собирай на здоровье )
fear86
0
Да, я имел ввиду вызов из других обьектов. И я ошибся с общим родителем, класс надо наследовать, или хотя бы наследовать тот класс в иерархии, который содержит нужный нам метод/свойство.
Вот так тоже можно:
class a {
  protected function test()
  {
    return 'protected';
  }
}

class e extends a {
}

class c extends a {
  public function __call($name, $args)
  {
    return call_user_func_array(array(array_shift($args), $name), $args);
  }
}

$e = new e();
$c = new c();
echo $c->test($e);
fear86
0
new static(); самое частое использование
fear86
0
Если мне не изменяет память то достаточно что бы у классов был общий родитель. Но не обязательно наследовать нужный класс.
fear86
0
Некоторые вещи про php лучше не знать. Например то что есть трюк вызывать protected методы не только из вашего класса )
fear86
0
Так же гугл вам бы мог помочь узнать что в kebernetes своя реализация для этого.
fear86
0
Да я знаю про volume в docker, но они не работают. Они годятся только когда у вас 2-3 контейнера на одной машине, а не когда сотни на нескольких физических серверах.
fear86
0
Если я правильно понял по коду, то он отталкивается от статических данных, а не от текущей нагрузке на ноду. Это не спасает когда у нас 10 подов на одной ноде жрет ресурсов больше чем 20 на другой. При равной конфигурации. Но в теории можно дописать туда своих алгоритмов ))