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

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

*ждуна

Вааааще нету смысла что-то свое придумывать в этом случае)) Меня бы это скорее насторожило как соискателя)

а СПА - js фреймворки тоже нельзя юзать?

Ну, это можно понять и на примере кода с юзаением фреймворка. Даже проще будет понять

У меня на блоге новый пост, возможно будет интересно: https://www.yegor256.com/2018/09/12/clear-code.html Буду рад комментариям.

https://i.ytimg.com/vi/5naXMNosy7Q/maxresdefault.jpg

"Создатель языка программирования Python Гвидо ван Россум объявил о том, что из языка уберут служебные слова master («хозяин») и slave («раб») по соображениям политкорректности." опять за старое :)

"Создатель языка программирования Python Гвидо ван Россум объявил о том, что из языка уберут служебные слова master («хозяин») и slave («раб») по соображениям политкорректности." опять за старое :)

он же уже послал всех нахуй

да я вот только новость увидел

не, я о том когда Гвидо писал что он устал и уходит

https://github.com/python/cpython/commit/012f5b968a738b15ae9b40c499a1c0778b0615a9 меня очень радует как у них стиль кода для наименования переменных отсутствует. slaveargs > worker_args

питон же

видимо да

чтобы тебе было, что вбросить в чат

походу каждый чат обязан пройти через эту тему

?

давно к слову не скидывал видос на эту тему: https://www.youtube.com/watch?v=Fuac__g928E

неожиданно интересно, спасибо

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

вот видосик посмотри

а ты его курс слушал, о котором он в конце говорит?

Нет

Пацаны помогите, что то туплю немного. У меня есть событие - показ витрины. И задача чтобы показ витрины означал автоматически "случилосьСобытиеАБтестов", правильно ли я делаю, что кидаю событие "случилосьСобытиеАБтестов" в слушателе события показа витрины, или мне лучше просто два события подряд кидать во время их наступления

так то я рассжудаю так - витрина показана? Удостовериваемся что показана, и если это так то кидаем событие что "случилосьСобытиеАБтестов"

ну как.. PostDeleted. А мне еще надо было отдельно отрабатывать PopularPostDeleted. И был вопрос - генерить оба события после удаления популярного поста или все-таки в обработчик PostDeleted проверить был ли он популярным(там был SoftDelete так что вполне проверялось). Как думаешь что натуральнее, делать еще одно специальное событие или не делать.

логика АБтеста вообще левая по отношению к тому месту где у тебя показывается витрина. нет?

логика АБтеста вообще левая по отношению к тому месту где у тебя показывается витрина. нет?

ага левая

у нас просто своя система для АБ тестирования, основаная на самописной убийце кликхауса

у нас просто своя система для АБ тестирования, основаная на самописной убийце кликхауса

громко :)

и я не могу просто при событии указать что оно было таким то юзером совершенно(с такой то группы тестирования) а должен кидать событие "событиеАбТестированияСлучилос" - нейминг пиздец

но щас у меня листенер по сути просто кидает другео событие

т.е. в событии ВитринаПоказана нет юзера, котормоу она показана?

тоже смотрится как гавно на уровне Смотрите я прочитал статью про евентбус

т.е. в событии ВитринаПоказана нет юзера, котормоу она показана?

есть, но там нет инфы о самом АБ тесте и его группах

т.е тот код просто поазывает витрину, не знаю что он там тестируется как то

хотя стоп

есть

блять

по сути это одно и тоже событие

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

а во втором что у такого то пользователя случилось событие аб тестов

все таки думаю отсавлю как есть, дял себя выбрал аналогию с рождение цыпленка

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

нет

но с другйо стороны разбитие скорлупы ен значит что цыпленок вылупился

В тред призываются специалисты по проектированию донорно акцептороной связи между микросервисами через Rest при наличии присутствия Swagger yaml definition у убоих сервисом и строго типизированного клиента только у одного (jira rest API)

Вопрос: для первого сервиса мне все равно придётся генерировать код клиента

Нужно ли мне пользоваться вендорной зависимостью для второго?

Первому ответившему

Нужно ли мне пользоваться вендорной зависимостью для второго?

42

Я думаю что и там и там нужно одинаково делать

Принцип последовательности

Нет

а у тебя случайно под рукой нет примера клея, которым склеиваются микросервисы? или вообще примера красивой реализации оных на жаве, например? если я хочу сделать микросервисы. мне нужно, чтобы они как-то между собой общались. Т.е. нужен какой-то аналок enterprise service bus? но в каком формате там будут бегать события? в каждом сервисе лежит интерфейс которым описываются эвенты? или вот он говорит, что страница может собираться со многих сервисов, что они могут быть аки виджеты. но тогда нужны ручки, чтобы дёрнуть конекретный сервис, когда нужны данные. эти ручки — они в инстансе сервиса или всё через эвенты делается? и как быть с базой данных, когда одна таблица используется разными микросервисами? ОРМ одна или для каждого сервиса свой инстанс?

RabbitMQ, graphql

это про ремоут колл, а тут вопрос когда они в одном процессе живут

Намного легче от этого стало?)

graphql например вообще контекст использования до лампочки, это просто язык запросов

а про базу данных - Уди об этом тоже говорит если у тебя одна таблица используется несколькими сервисами - у тебя проблемы

СУБД может быть и одна общая на все микросервисы, имею ввиду инстансы, тут уж как проще девопсам это организовать. но доступ у каждого МС должен быть строго ограничен от остальных и вообще нужно, чтобы по щелчку могло переключаться. Для клея на инфраструктуром уровне советуют использовать Service Mesh.

СУБД может быть и одна общая на все микросервисы, имею ввиду инстансы, тут уж как проще девопсам это организовать. но доступ у каждого МС должен быть строго ограничен от остальных и вообще нужно, чтобы по щелчку могло переключаться. Для клея на инфраструктуром уровне советуют использовать Service Mesh.

общий класстер субд, или инстанс, или сервис меш - все это инфраструктурные нюансы которые никакого отношения не имеют к микросервисам. Та же сервис меш - это больше про аудит и секьюрити сетей, более хитрая топология виртуальных сетей поверх твоего класстера. Это примерно как overlay network в докере, примерно тот же уровень инфраструктуры.

ну так я и говорю про инфраструктурную вещь.

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

например - захочу я например запилить класстер серверов для разруливания аудио/видео/webrtc - я вполне могу захотеть там service mesh для того что бы грамотно всем этим рулить но пофакту - все это будет одним таким вот сервисом.

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

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

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

да, именно.

это про ремоут колл, а тут вопрос когда они в одном процессе живут

они не могут жить в одном процессе, они же микросервисы. каждый микросервис - свой процесс. Не ну как, если ты на эрланге пишешь у тебя больше вариантов)

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

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

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

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

а вот тут чувствуется бэкграунд php-ника, где для того что бы http обрабатывать надо nginx поднимать

ну да я именно на это и ссылаюсь

что есть люди которым это неочевидно

если пхп, то обязательно http