В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Scala User Group

2140 membersпожаловаться на группу
2020 November 30

KS

Kirill Shelopugin in Scala User Group
Sergey Alaev
PhD понадобится, когда эта машинерия сломается или поведет себя неадекватно из-за каких-то конфликтующих импортов, новой версии скалы, странных типов. Сидишь такой, ковыряешься и думаешь, что руками бы всё это прописал минут за 40 интенсивного копипаста с 0 проблем.
Хорошо. Уберешь из @derive(x, y, z) то, что сломалось и напишешь своё, если не устроит. Зачем тут PhD? К тому же, там достаточно подробно пишется, что и для чего не было найдено.
Какой у тебя опыт использования дерева, чтобы мы могли сравнить? Я полтора года им пользуюсь без проблем. Сколько пользуешься ты и какие проблемы возникли, давай обсудим
источник
23:07пожаловаться#1

AS

Artem Sokolov in Scala User Group
Vladimir Sapronov
эту байку придумали люди, которые пытаются натянуть определение на свои монолиты
всем адекватным людям примерно понятно, что такое микросервис - как-то без принудительной координации 30-40 разработчиков пишут сервисы примерно одинакового размера
все нравится максимальная минимальность
короче сейчас бы докторскую защитить определив слово "микро"
"примерно понятно"
угу
также как и понятно что это хорошо
а монолит плохо
но насамом деле в 95% случаев микросервисы архитектурно были выбраны зря. а среди оставшихся 5% гдето 90% выбрали скоупы микросервисов неудачно

может в вашем случае и удачно
но микросеврис на 500 строк, кмк, требует хорошего обоснования
источник
23:08пожаловаться#2

KS

Kirill Shelopugin in Scala User Group
RattenK 🍄🐀🌹
Еси дуби не вывозит вывод, то потом тыщу лет пытаешься понять где надо импортнуть инстанс и чего. А так сразу поймешь чего не хватает
Факт. Я-то о том, как бы оно с дедушкиным не начало враждовать.
источник
23:08пожаловаться#3

SA

Sergey Alaev in Scala User Group
Kirill Shelopugin
Хорошо. Уберешь из @derive(x, y, z) то, что сломалось и напишешь своё, если не устроит. Зачем тут PhD? К тому же, там достаточно подробно пишется, что и для чего не было найдено.
Какой у тебя опыт использования дерева, чтобы мы могли сравнить? Я полтора года им пользуюсь без проблем. Сколько пользуешься ты и какие проблемы возникли, давай обсудим
Деревом не пользовался, экстраполирую свой опыт с макросами и сложной имплиситной деривацией в целом.
источник
23:09пожаловаться#4

VS

Vladimir Sapronov in Scala User Group
Artem Sokolov
"примерно понятно"
угу
также как и понятно что это хорошо
а монолит плохо
но насамом деле в 95% случаев микросервисы архитектурно были выбраны зря. а среди оставшихся 5% гдето 90% выбрали скоупы микросервисов неудачно

может в вашем случае и удачно
но микросеврис на 500 строк, кмк, требует хорошего обоснования
ну OK, начали с того, что размер микро не определен, закончили тем, что монолиты - лучше микросервисов
я не против всего этого
источник
23:09пожаловаться#5

KS

Kirill Shelopugin in Scala User Group
Sergey Alaev
Деревом не пользовался, экстраполирую свой опыт с макросами и сложной имплиситной деривацией в целом.
По своему опыту могу сказать, что обычно ошибки, производимые деревом и монголией, достаточно понятны. В крайнем случае, опять же, ничего не мешает убрать оттуда то, что не выводится и написать руками, это opt-in всё-таки
источник
23:10пожаловаться#6

VS

Vladimir Sapronov in Scala User Group
Artem Sokolov
"примерно понятно"
угу
также как и понятно что это хорошо
а монолит плохо
но насамом деле в 95% случаев микросервисы архитектурно были выбраны зря. а среди оставшихся 5% гдето 90% выбрали скоупы микросервисов неудачно

может в вашем случае и удачно
но микросеврис на 500 строк, кмк, требует хорошего обоснования
Вообще ничего не требует, принимает данные сладывает в динамодб, дергает внешний апи - все
источник
23:10пожаловаться#7

VS

Vladimir Sapronov in Scala User Group
конфиг чуть ли не длиннее чем сам код
источник
23:10пожаловаться#8

AS

Artem Sokolov in Scala User Group
Vladimir Sapronov
конфиг чуть ли не длиннее чем сам код
да.
вы понимаете стоимость накладных расходов но оборачивание всего этого в отдельный сервис?
источник
23:11пожаловаться#9

R

RattenK 🍄🐀🌹 in Scala User Group
Kirill Shelopugin
Факт. Я-то о том, как бы оно с дедушкиным не начало враждовать.
Имплисит из компаньона < имплисит из неявной функции? :(
источник
23:11пожаловаться#10

SA

Sergey Alaev in Scala User Group
Vladimir Sapronov
эту байку придумали люди, которые пытаются натянуть определение на свои монолиты
всем адекватным людям примерно понятно, что такое микросервис - как-то без принудительной координации 30-40 разработчиков пишут сервисы примерно одинакового размера
все нравится максимальная минимальность
короче сейчас бы докторскую защитить определив слово "микро"
Микросервис - это не только код. А все остальные телодвижения требуют усилий. Достаточных, чтобы задуматься о пользе сотен 500-строчных микросервисов
источник
23:11пожаловаться#11

VS

Vladimir Sapronov in Scala User Group
Artem Sokolov
да.
вы понимаете стоимость накладных расходов но оборачивание всего этого в отдельный сервис?
расходы в рантайме? или в разработке?
источник
23:11пожаловаться#12

VS

Vladimir Sapronov in Scala User Group
уточни
источник
23:11пожаловаться#13

KS

Kirill Shelopugin in Scala User Group
RattenK 🍄🐀🌹
Имплисит из компаньона < имплисит из неявной функции? :(
Да вроде нет. Но утверждать не буду
источник
23:12пожаловаться#14

SA

Sergey Alaev in Scala User Group
Kirill Shelopugin
По своему опыту могу сказать, что обычно ошибки, производимые деревом и монголией, достаточно понятны. В крайнем случае, опять же, ничего не мешает убрать оттуда то, что не выводится и написать руками, это opt-in всё-таки
Согласен, но хочется единообразия, чтобы при добавлении новых моделей не заниматься прикладным олимпиадным программированием, а строгать по шаблону.
источник
23:12пожаловаться#15

VS

Vladimir Sapronov in Scala User Group
Sergey Alaev
Микросервис - это не только код. А все остальные телодвижения требуют усилий. Достаточных, чтобы задуматься о пользе сотен 500-строчных микросервисов
в нормальных девопсах и платформах - это только код и у нас все хорошо с этим
источник
23:12пожаловаться#16

AS

Artem Sokolov in Scala User Group
overall
но скорее в рантайме, в обслуживании девопсами, в инфраструктурных требованиях\
источник
23:12пожаловаться#17

KS

Kirill Shelopugin in Scala User Group
Sergey Alaev
Согласен, но хочется единообразия, чтобы при добавлении новых моделей не заниматься прикладным олимпиадным программированием, а строгать по шаблону.
В 99% это и будет строгание по шаблону. Те случаи, которые придется описать руками, будут достаточно сложны сами по себе, чтобы и без дерева принести проблемы
источник
23:13пожаловаться#18

VS

Vladimir Sapronov in Scala User Group
Artem Sokolov
overall
но скорее в рантайме, в обслуживании девопсами, в инфраструктурных требованиях\
все хорошо это все понимают, наши девопсы рады маленьким сервисам - говорят, что когда в одном сервисе и http и стриминг какой, то непонятная фигня с ресурсами происходит и автоскейлинг иногда не вывозит, а когда отдельно то нагрузка на каждый отдельный сервис лучше скейлится
но это они так говорят
источник
23:14пожаловаться#19

AS

Artem Sokolov in Scala User Group
Vladimir Sapronov
конфиг чуть ли не длиннее чем сам код
кстати вопрос. зачем для этого отдельный сервис, зачем этот конфиг писать? не проще добавить 1 функцию в существующий сервис?
источник
23:14пожаловаться#20