Ну так если я собираю релизный docker image который по сути имеет отношение к Continious Deployment. Разве это не деплой ?

нет, это сборка. у тебя еще тесты могут быть между. Воспринимай это как разные этапы одного конвеера.

не надо смешивать, так ты только усложняешь

Ну так если мне надо в процессе вытащить из репозитория код, который уже оттестирован и мне нужно только забрать статику. То почему это не CD ?

Даже в кубике есть Volume который тащит из git файлы, чтобы потом замонтировать их.

gitRepo типа

делается это для того, чтобы статику которую будет обслуживать nginx можно было ему подмонтировать. А не собирать nginx со статикой, если это невозможно.

Под статикой я имею ввиду js,css и другие изменеяемые данные, которые будет отдавать nginx

@fes0r Можешь плиз, сказать, это я значит что-то делают не так ? Или это уже нельзя назвать деплоем в контексте Continious Deployment ?

Хотя, да все верно. git тут не нужен. Т.к. нужно было оформить статику как artifact. Но на момент интеграции вроде в gitlab не было артифактов. Видимо поэтому, меня смутило что при деплое не юзается git.

Сорри, был не прав.

Ну так если мне надо в процессе вытащить из репозитория код, который уже оттестирован и мне нужно только забрать статику. То почему это не CD ?

CD это весь процесс, от момента когда ты начал обсуждать фичу до момента когда она попадает на продакшен.

естественно VCS будет частью этого процесса

но deployment это определенная часть CD, маленькая.

но deployment это определенная часть CD, маленькая.

Понял, благодарю за разъяснения.

https://slides.com/sergeyprot-ko/deck-7#/

на вот - я для своих когда-то делал

https://slides.com/sergeyprot-ko/deck-7#/

О, спасибо. Первый слайд зачетный.))

ребят, есть репа на такую функцию: middlware вход по маске ip, в конфиге вводит ip например 99.178.0.0/16 и проходит проверку

В хттпфаундейшн в симфони есть такая штука

можно доки

или пример

Mihail, [03.05.18 23:05] Здравствуйте, назрел небольшой вопрос, всегда ли нужно использовать сеттер к геттеру? к примеру я передаю данные через аргумент в геттер public function getUserTweets($screen_name) { return $this->twitterApi->getStatusesUserTimeline($screen_name); } если с сеттером то private $screen_name; public function setUserTweets($screen_name) { $this->screen_name=$screen_name; } public function getUserTweets() { return $this->twitterApi->getStatusesUserTimeline($this->screen_name); } нужно ли тут использовать вариант с сеттером и геттером или достаточно одного геттера?

Mihail, [03.05.18 23:05] Здравствуйте, назрел небольшой вопрос, всегда ли нужно использовать сеттер к геттеру? к примеру я передаю данные через аргумент в геттер public function getUserTweets($screen_name) { return $this->twitterApi->getStatusesUserTimeline($screen_name); } если с сеттером то private $screen_name; public function setUserTweets($screen_name) { $this->screen_name=$screen_name; } public function getUserTweets() { return $this->twitterApi->getStatusesUserTimeline($this->screen_name); } нужно ли тут использовать вариант с сеттером и геттером или достаточно одного геттера?

я скажу что по хорошему тебе ни геттеры ни сеттеры не нужны но я так, местный сумасшедший

а вообще при проектировании класса всегда смотри как он используется а не "ну прост"

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

в первом случае изменить незвание метода и уже не геттер, а нормальный метод

в том то и дело, что по префиксу понятно, что они делают, если get то что то возвращает

в том то и дело, что по префиксу понятно, что они делают, если get то что то возвращает

если у тебя только по префиксу понятно что они делают - у тебя беда с нэймингом)

это да, к сожалению

setUserTweets - что там за screen_name?

в ней лежит назвнание позовательского аккаунта в твитере

мммм почему оно screen?

пример "@lentaofficialru"

так в твитеровском api написано

(new TwitterService())->userTimeLine($this->user);

хз, как предположение

так в твитеровском api написано

> The screen name, handle, or alias that this user identifies themselves with. screen_names are unique but subject to change. Use id_str as a user identifier whenever possible. Typically a maximum of 15 characters long, but some historical accounts may exist with longer names. Example:

а еще там написано не юзать его как идентификатор)

(new TwitterService())->userTimeLine($this->user);

$twitter($this->user)->timeline()

ну по LoD да)

(new TwitterService())->userTimeLine($this->user);

зачем userTimeLine а не просто TimeLine? есть какие-то другие таймлайны (я не шарю в твиттерах)

и зачем суффикс Service? и так понятно что твиттер это сервис)

у меня тоже не слшком хорошо с неймингом :)

у меня тоже не слшком хорошо с неймингом :)

не я реально не шарю в твиттерах, может там другие таймлайны есть

эта функция ищет пользователя и получает его твиты screen_name это имя пользователя

эта функция ищет пользователя и получает его твиты screen_name это имя пользователя

в доке написано что как идентификатор пользователя лучше юзать id_str

id_str это id просто в виде "54643568" не кдобно очень

ну так речь не про "удобно", а про "правильно"

id_str это id просто в виде "54643568" не кдобно очень

это идентификатор пользователя, неизменный. screen_name может меняться. что тут непонятного?))

если тебе нужно получить ид юзера - должен быть эндпоинт для этого

у меня сервис который получает твиттер api и передаёт данные другому сервису который их обрабатывает(получает массивы с нужными данными, не нжные удаляет)

если тебе нужно получить ид юзера - должен быть эндпоинт для этого

не совсем понял

я не шарю в твиттер апи, но там наверняка есть способ получить id_str по screen_name

и хранить уже id_str в базе

я тож не шарю, но вряд ли)) screen_name-то уникальным быть не должон)

предполагаю там получаешь всю инфу о пользователе(объект User), а потом уже чем хочешь оперируешь в своих целях

я не шарю в твиттер апи, но там наверняка есть способ получить id_str по screen_name

да, верно, по screen_name я получаю массив со всеми данными

я тож не шарю, но вряд ли)) screen_name-то уникальным быть не должон)

он уникальный, но может меняться

я тож не шарю, но вряд ли)) screen_name-то уникальным быть не должон)

он вроде уникальный но ты можешь его поменять и потом кто-то может занять твой

предполагаю там получаешь всю инфу о пользователе(объект User), а потом уже чем хочешь оперируешь в своих целях

верно

он уникальный, но может меняться

херь эти ваши твиттеры)

он вроде уникальный но ты можешь его поменять и потом кто-то может занять твой

тоже верно, да я собирался хранить в базе по id

id_str будет твоим PK

id_str будет твоим PK

тут думаю лучше просто id. Там есть id=12345 a id_str="12345"

это id который хранится в виде строки

понял, screen_name не вечен

так как лучше поступить, обычный метод с параметрами, или сеттеры и геттеры?

ERROR: S client not available

я понимаю,что можно и так и так, но ООП говорит про инкапсуляцию

я понимаю,что можно и так и так, но ООП говорит про инкапсуляцию

ООП штука такая которую мало кто понимает (потому что нет четкого определения что это такое с которым бы все были согласны).

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

кажется приходит просветление(поправте если не прав). В ООП нужно всё рассматривать как обьект и если я пишу в ООП то получаю такое private var1 private var2 public setMethod(var1 var2) $this->var1=var1; $this->var2=var2;

зачем ты делаешь мутабельные объекты ?

кажется приходит просветление(поправте если не прав). В ООП нужно всё рассматривать как обьект и если я пишу в ООП то получаю такое private var1 private var2 public setMethod(var1 var2) $this->var1=var1; $this->var2=var2;

давай просто method без этих set

зачем ты изменяешь состояние потом ?

ну и да - если есть возможность делать имутабельно - это всегда проще

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

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

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

ну такое бывает довольно редко это раз

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

во вторых есть with*

в конструкторе зависимости

в идеале

но это опять очень холиварно

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

класс это общий Api в нём метод UserTweets который получает твиты пользоваетелей

в методе передается id пользвателя

$tweets = $api->tweets($userId); // самое очевидное

$tweets = $api->tweets($userId); // самое очевидное

я так и сделал, но подумал что очевидно не всегда хорошо, ООП не применятеся, вот и спросил совета у более опытных

ну и да - если есть возможность делать имутабельно - это всегда проще

Когда то ты мне целую статью по неймингу давал

ну тоесть ты сделал что то типо билдера

я так и сделал, но подумал что очевидно не всегда хорошо, ООП не применятеся, вот и спросил совета у более опытных

"очевидно не всегда хорошо" (с) фонд золотых цитат php чата

$tweet = Api::builder()->setUserId($userId)->build();

это делается в том случае если параметров куча

> ООП не применятеся ты просишь о чем-то объект, чем не ООП

и некоторые и все они не необязательные

тоесть зачем усложнять если простая ситуация

$tweet = Api::builder()->setUserId($userId)->build();

немного не понял про билдер

немного не понял про билдер

вот я как то видео запилил https://www.youtube.com/watch?v=2THhUFNQGew&