Иными словами, митап прекрасно заменяется форматом "пойдем попьем пивка, вот предлагаемые топики для срача: ....". Но под такое мероприятие бюджет не получишь и с работы командировку не выпишешь. А вот под митап\конференцию - вполне.

Ну, кроме части про "себя показать". Но это уже эм, другая история, про обоснование, которое к обмену информацией как таковому относится слабовато и вообще "практическое применение" имеет весьма сомнительное. Никто же не думает, что Сергей (он точно пишет статьи, но мне почему-то помнилось, что он еще и регулярно таки выступает или выступал) или там ребята Яндекс на митапы ходят исключительно и вообще для того, чтобы поделиться с миром своими открытиями. Это конечно тоже, но это такой благовидный предлог, приследующий совсем другие цели, в первую очередь - формирование технического бренда.

Да пицца с пивом решают
Когда в мейле это было

прочитал 1.7к сообщений, простите за слоупоковское фомо

Надо выдергивать беседы в дерево комментариев

Бот, который публикует фомо в пост на реддите, а и потом реплаями к нему предыдущие сообщения?)

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

И все ответы на тегнутое

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

без проблем, когда хостить будем?)

Mvp- heroku

Можно попробовать уложиться в бесплатные лимиты Google cloud

да где захостить найдем, это не проблема 😉

Ребят, подскажите пожалуйста. Есть java grpc сервер и надо в нём обрывать запрос по таймауту, то есть не рвать конекшн с клиентом, а переставать считать ответ. Типа время обработки зависит от входных данных очень сильно, но нет способа оценить сколько она займет при получении запроса, т.к. зависимость не тривиальная, а у клиента стоит таймаут 1 минута. В итоге получается что клиент через минуту отваливается, а сервер по прежнему пытается считать ответ и это может затянуться на сутки или больше даже, что абсолютно бессмысленно. При этом мест, где может долго обрабатываться достаточно много и везде вставлять проверки на Thread.isInterupted не хотелось бы

Context.withDeadline (https://github.com/grpc/grpc-java/blob/master/context/src/main/java/io/grpc/Context.java#L298)

а как добраться до Context? У меня есть ServerBuilder и класс который рпц метод переопределяет

у меня есть чатик по gRPC, он довольно мёртвый, но мб там помогут https://t.me/grpcio (попробуйте туда репостнуть вопросы)

в доках пример такой:

 Context.CancellableContext withDeadline = Context.current()
          .withDeadline(someReceivedDeadline, scheduler);
       try {
         withDeadline.run(new Runnable() {
           public void run() {
             Context current = Context.current();
             while (!current.isCancelled() && moreWorkToDo()) {
               keepWorking();
             }
           }
         });
       } finally {
         withDeadline.cancel(null);
       }

то есть тоже надо везде проверять на этот флаг?

это внутренности и вам туда не надо.

это в основном используется для клиента, типа такого
response = blockingStub.withDeadlineAfter(deadlineMs, TimeUnit.MILLISECONDS).sayHello(request);