BP
Там секретных чатов даже нет
Да вроде есть
Size: a a a
2020 September 01
с#
Да вроде есть
да, там долго не было мультиаккаунтов и щас их добавили и вообще добавлять стали всё
с#
так что должны быть
DP
Переслано от badtrousers
AD
Это за что?
I
Не прошел тест тьюринга
Думал мы тут с котами шутки шутим 😼
Думал мы тут с котами шутки шутим 😼
AD
Не прошел тест тьюринга
Думал мы тут с котами шутки шутим 😼
Думал мы тут с котами шутки шутим 😼
Там целый рассказ нужно писать, что происходит на картинке, а не 30 секунд давать )
AD
Когда ты мимокрокодилл с телефона, такая себе идея )
AM
Достаточно было черкануть "кот даёт лапу"))
AM
А вообще я представляю себе уровень стресса. Мало того, что котокапчей встречают, потом ещё злой админ с кложурой на аватарке рассказывает, что ты тест Тьюринга не прошёл
ML
А вообще я представляю себе уровень стресса. Мало того, что котокапчей встречают, потом ещё злой админ с кложурой на аватарке рассказывает, что ты тест Тьюринга не прошёл
хаскложурой, на минуточку
AM
Точно
AD
Во во, так и чувствую, что во времена, когда машины все же возьмут свое, админы первыми будут наказаны, за столь радикальные капчи, и не уважение даже к своим мешкам с костями )
AM
У админов тяжёлая судьба они уже сейчас воюют с роботамиботами. Кожаные мешки тоже под удар попадают иногда, конечно)
I
Кстати хочу эксперимент провести. Если кто-то кинет спам, то НЕ удалять его, а только репотрить.
Интересно, через сколько telegram его сам прибъет.
Интересно, через сколько telegram его сам прибъет.
I
вопрос по "архитектуре"
есть условный "васянский" event-soursing
- типа write модель, которая просто журнал событий
- куча "микросервисов" со своими внутринними read моделями, которые генерятся из write
норм ли "сервису" менять свою внутреннюю read модель напряму или нужно всегда генерить событие для write?
есть условный "васянский" event-soursing
- типа write модель, которая просто журнал событий
- куча "микросервисов" со своими внутринними read моделями, которые генерятся из write
норм ли "сервису" менять свою внутреннюю read модель напряму или нужно всегда генерить событие для write?
AN
вопрос по "архитектуре"
есть условный "васянский" event-soursing
- типа write модель, которая просто журнал событий
- куча "микросервисов" со своими внутринними read моделями, которые генерятся из write
норм ли "сервису" менять свою внутреннюю read модель напряму или нужно всегда генерить событие для write?
есть условный "васянский" event-soursing
- типа write модель, которая просто журнал событий
- куча "микросервисов" со своими внутринними read моделями, которые генерятся из write
норм ли "сервису" менять свою внутреннюю read модель напряму или нужно всегда генерить событие для write?
В смысле клиенту? По-моему да. Если обратного потока нет, то никакой контракт не нарушается. Правда естественно можно нарватсья на дыры в логах
VP
вопрос по "архитектуре"
есть условный "васянский" event-soursing
- типа write модель, которая просто журнал событий
- куча "микросервисов" со своими внутринними read моделями, которые генерятся из write
норм ли "сервису" менять свою внутреннюю read модель напряму или нужно всегда генерить событие для write?
есть условный "васянский" event-soursing
- типа write модель, которая просто журнал событий
- куча "микросервисов" со своими внутринними read моделями, которые генерятся из write
норм ли "сервису" менять свою внутреннюю read модель напряму или нужно всегда генерить событие для write?
Иногда (при факапах) может быть полезно восстановить текущее состояние из лога