что за глупость, достаточно, что бы задача затронула то же место, что и хотфикс

И это так сложно решить?)

что за глупость, достаточно, что бы задача затронула то же место, что и хотфикс

не если код просто меняется - то проблем не будет. проблема с теми конфликтами которые git никак не затрекает (переименовывание файлов, перемещение оных и т.д.) но это отловит CI и зафэйлит билд

руками легко, автоматически - сложно

руками легко, автоматически - сложно

да тоже легко. проблемы те же

семантических конфликтов еще не бывает если ты никогда не рефакторишь код)

типа "модуль хуево назвали ну и хуй с ним"

не если код просто меняется - то проблем не будет. проблема с теми конфликтами которые git никак не затрекает (переименовывание файлов, перемещение оных и т.д.) но это отловит CI и зафэйлит билд

смотри… ветка от мастера, меняем 5-ю строку, мержим в дев ветка от мастера, меняем 6-ю строку, мержим в мастер и потом мастер мержим в дев… я вижу конфликт

смотри… ветка от мастера, меняем 5-ю строку, мержим в дев ветка от мастера, меняем 6-ю строку, мержим в мастер и потом мастер мержим в дев… я вижу конфликт

у меня не такая схема

я от мастера на КАЖДЫЙ релиз отвожу релиз ветку

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

ты трогаешь только в одном месте, дальше гит изменения именно перенесет корректно

(ну или можно придумать очень скользский кейс где нет). А вот добавление кода гит корректно уже может не захэндлить если изменения в файлах о которых релиз ветка ничего не знает))

например ты ответвился и потом перенес код в другой модуль. Все, привет конфликты

и их словит только стат анализ и тест сюиты

не, проблема в том, что у нас еще тест ветка для тестирования

ну это твои проблемы)))

опять же, у меня так было на прошлом проекте

и да там были конфликты - релиз ветки потому удобнее

с ними вероятность конфликтов меньше

но они всеравно будут

потому не вижу смысла автоматизировать. тем более что я трачу на черипики минут 10 на спринт. Нет смысла автоматизировать и повышать риски

но мастер от которого релиз ветка же стабильный?

все ветки считаются стабильными)

ну т.е. туда идут выполненные и протестированные ветки

но это не мешаем разработчикам вмердживать говно раз в день0

ну т.е. туда идут выполненные и протестированные ветки

нет

trunk based dev - все идет в мастер как только разработчик считает что "усе". Причем в идеале каждый день. даже если фича не закончена. дальше свое дело делают фичатоглы и branch by abstraction

нету "тэст брэнчей" или "продакшен брэнчей". Есть релиз ветки которые делаются для код фриза на релиз. Сначала льем релиз на тэстинг/стэйджигг и потом уже на прод

весь процесс создания веток и т.д. через слэк. что-то типа @jenkins please freeze code или чето такое

и как часто релиз?

пока-что раз в две недели

а деплоимся по 1-2 раза в день))

ну как.. это багфиксы разумеется...

но в итоге хотим придти к тому что бы мастер сразу лить на тестигг и потом тот же билд лить на прод если все хорошо

но для этого надо больше e2e/приемочных тестов

и как часто релиз?

и да релиз и деплой это не одно и то же) в том плане что у тебя фича может быть на продакшене месяц но ее никто не релизил

Скажите ка, а норм тема биндить конфиги в сервисы на уровне регистратора в сервис контейнере (который регает сервисы)

или похер где их биндить, я думал может есть бест практис какой-нибудь

под конфигами я подразумеваю конфиги для доступа к внешним данным\сервисам

ты имеешь в виду то, что в каком-нибудь ларавеле можно дёрнуть config('token') из любого места?

в симфони например особо выбора нет - либо пробрасывать токены отдельными аргументами в конструктор, либо инжектить весь контейнер и у него дёргать ->getParameter('api_token')

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

учитывая что у меня самый верхний уровень это сервис контейнер

получать в виде аргумента конструктора

и только

а классы должны быть по максимуму framework agnostic, чтобы ничего не знали про всякие config('api_token') или Yii::$app->params['api_token'] и прочее

контейнер наружу аще не торчит. в коде забудь про его существование. Есть очень мало кейсов, где он вылазит (и даже не он, а специально изолированный сервис локатор)

бред… $a = 1; isset($a->id); isset($a["id”]); - вот это все валидно, а вот это вот $a = new StdClass(); isset($a[“id”]); - дает фатал

Там же array access вроде нету

Вот и ругается)

ну да.. а у инта конечно есть array access ?

Ну, пхп оправдывать - гнусная идея, так что не буду)

хехе ну да…

Всем привет! Знаком не по наслышке с использование Dependency injectioin не через конструктор, ни через сеттер. Делается привязка интерфейса к реализации, а потом в сервисах тупо дергается что-то типа $container->get('AnimalInterface'). Меня посещает мысль, что это очень кривое внедрение зависимостей и что лучше внедрять через конструктор. Но четкие аргументы почему это плохо довольно сложно сформулировать. Максимум это то, что методы сервиса не знают откуда берется зависимость. Что думаете по этому поводу?

Ты уверен что ты под DI подразумеваешь именно то, что оно означает?

Мне кажется у тебя проблема в определении контекста DI и сервис-контейнера с его биндингами

И нет ничего плохого в биндинге зависимости через интерфейс, это норм практика

Ты кажется путаешь биндинг зависимостей и инъекцию зависимостей

Всем привет! Знаком не по наслышке с использование Dependency injectioin не через конструктор, ни через сеттер. Делается привязка интерфейса к реализации, а потом в сервисах тупо дергается что-то типа $container->get('AnimalInterface'). Меня посещает мысль, что это очень кривое внедрение зависимостей и что лучше внедрять через конструктор. Но четкие аргументы почему это плохо довольно сложно сформулировать. Максимум это то, что методы сервиса не знают откуда берется зависимость. Что думаете по этому поводу?

Тут нет di если ты юзаешь контейнер напрямую

Это сервис локатор со своими плюсами и минусами

Как раз хотел предположить, что это сервис локатор

Всем привет! Знаком не по наслышке с использование Dependency injectioin не через конструктор, ни через сеттер. Делается привязка интерфейса к реализации, а потом в сервисах тупо дергается что-то типа $container->get('AnimalInterface'). Меня посещает мысль, что это очень кривое внедрение зависимостей и что лучше внедрять через конструктор. Но четкие аргументы почему это плохо довольно сложно сформулировать. Максимум это то, что методы сервиса не знают откуда берется зависимость. Что думаете по этому поводу?

если ты передаёшь контейнер в конструктор - у тебя теоретически появляется зависимость от всего, что есть в контейнере, потому-что ты можешь что угодно вызвать в реализации. Если у тебя будут более конкретные зависимости - будет, например, проще увидеть, что "что-то тут уже больно много зависимостей, может быть что-то пошло не так?"

?

речь про другое тащемта

Я имел ввиду не передачу контейнера через конструктор, а именно внедрение зависимостей через него

ERROR: S client not available

ну значит сори, я не понял =\

если ты передаёшь контейнер в конструктор - у тебя теоретически появляется зависимость от всего, что есть в контейнере, потому-что ты можешь что угодно вызвать в реализации. Если у тебя будут более конкретные зависимости - будет, например, проще увидеть, что "что-то тут уже больно много зависимостей, может быть что-то пошло не так?"

Это херовой локатор, есть хорошие)

Это херовой локатор, есть хорошие)

а чем херовый отличается от хорошего?

у хорошего коэффициент плюсов\минусов чуть лучше

Ограничениями

у хорошего коэффициент плюсов\минусов чуть лучше

:D

лучший!

хороший локатор есть у фаулера, у него же есть сравнение с DI в плане плюсов и минусов.

контейнер целиком юзать и все сервисы публичными делать - плохо потому что теряется контроль за зависимостями

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

Когда только начинаешь изучать идея прокинуть контейнер везде и использовать любые сервисы кажется очень удобной) ну или это только у меня так было)

При этом смотришь какой нибудь старый код с глобальными переменными и такой типо функции, а сам на самом деле нечто такое используешь)

Ребята, у меня опять по докеру вопрос, если знатоки имеются тут. В тот раз определили что нужно под каждый проект делать свой докер композ с nginx fpm. Получается должен быть сверху ещё nginx проксик, который будет на 80 порту, а самих проектов nginx уже будет на разных портах?

Нужно все проекты одновременно запускать?

Ну да, допустим они не зависимы друг от друга

Когда только начинаешь изучать идея прокинуть контейнер везде и использовать любые сервисы кажется очень удобной) ну или это только у меня так было)

А что тут плохого? Контейнер вызываешь только в одном месте - в конфигурации. А в самих сервисах он никак не вызывается. Экземпляры зависимостей создаются на лету при создании объекта сервиса.

А что тут плохого? Контейнер вызываешь только в одном месте - в конфигурации. А в самих сервисах он никак не вызывается. Экземпляры зависимостей создаются на лету при создании объекта сервиса.

Я о том, когда везде иньектится именно контейнер, а внутри уже без контрольно используется

Я о том, когда везде иньектится именно контейнер, а внутри уже без контрольно используется

Ну это бесспорно вариант не оч

Ребята, у меня опять по докеру вопрос, если знатоки имеются тут. В тот раз определили что нужно под каждый проект делать свой докер композ с nginx fpm. Получается должен быть сверху ещё nginx проксик, который будет на 80 порту, а самих проектов nginx уже будет на разных портах?

берешь какой nginx-proxy контейнер и радуешься

ну мол тогда у тебя все будет абсолютно прозрачно

берешь какой nginx-proxy контейнер и радуешься

Ну я так и планировал, меня как раз интересует так ли делают

Ну я так и планировал, меня как раз интересует так ли делают

https://github.com/jwilder/nginx-proxy - я вот про это

Ага, я понял

Спасибо

Да, с nginx-proxy четко получилось

еще letsencrypt-companion под него глянь

еще letsencrypt-companion под него глянь

Вообще то что нужно, спасибо

Всем привет! Знаком не по наслышке с использование Dependency injectioin не через конструктор, ни через сеттер. Делается привязка интерфейса к реализации, а потом в сервисах тупо дергается что-то типа $container->get('AnimalInterface'). Меня посещает мысль, что это очень кривое внедрение зависимостей и что лучше внедрять через конструктор. Но четкие аргументы почему это плохо довольно сложно сформулировать. Максимум это то, что методы сервиса не знают откуда берется зависимость. Что думаете по этому поводу?

1) плохое решение потому, что быстро понять о каких классов зависит класс 2) сложнее тестировать, тк мокать придется весь контейнер 3) сложнее рефакторить если потребуется

Привет! Посоветуте, пожалуйста, пакет для websocket client?

Сущность — это объект?

Да