@@Disorrder везде свои сложности. Где-то нужно просто JSON перекладывать. Но нужно это делать очень быстро и используя только стандартные библиотеки (знаю такие системы). Где-то распределенные транзакции, с возможностью быстрого отката (например, онлайн ритейлеры). У меня самая сложная задача была - создать сервис обработки большого количества данных, которые я получала из разных систем, их нужно было нормировать, синхронизировать, обновлять в случае изменений. Где-то синхронно получала, данные, где-то асинхронно из очереди событий. На основе этих данных нужно было делать коммерческие расчеты. И все еще усложнялось практически отсутствующим ТЗ, задача была поставлена «сделай также как делают N вручную». А там на каждое расчетное поле скидывают SQL из 500 строк, и каждую неделю SQL менялся.

@@PakshinaNina после такого ответа чел обратно вернулся делать джастифай контент центр

Спасибо за доклад, было познавательно

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

Отличный доклад! Было интересно послушать <3

@@eeenvyy добрый день, спасибо за позитивную обратную связь! Это мотивирует :)

а на 30:30 стало совсем страшно )

@@qerteuijbcfujg - у нас дыра в безопасности! - ну хоть что-то у нас в безопасности. На самом деле, с 0-rtt самая главная атака - это replay attack. То есть злоумышленник может «скопировать» и повторить запрос, который был сделан легитимным пользователем. Если это запрос страницы, то это одно. А если это операция по оплате, то уже серьезнее. Вообще браузер и так-то может задвоить запрос, само приложение должно быть устойчиво к двойным запросам. Запросы должны быть идемпотентны. А еще предлагают в качестве защиты принимать по 0-rtt только get запросы без query.

@@Igor_melnikov ха, кажется это естественный путь :)

Стрим был в 1080, но при перезаливке ужалось. Я обычно с телефона смотрю или в миниатюрном плавающем окне, поэтому не задумывалась о высоком качестве. Буду иметь ввиду, что для некоторых это важно!

@@PakshinaNina Да, просто текст на картинках, насыщенных объемом технической информации читать приятно и четко когда хотя бы FullHD, а тут слегка все было замылено. Не то что принципиально, просто я подумал, что сейчас уже это не проблема для всех выкладывать в FullHD. Я как раз стрим смотрел на мониторе 43 дюйма) Спасибо.

@@nelson5158, снова смотрим видео в 144 :( Вот задумалась, куда можно дублировать видео, чтобы люди могли смотреть без тормозов.

слушают о мире технологий и не знают про впн...

@@DJcRuT000с впн не те ощущения))

Большие мониторы - норм. Имел опыт ивентов

@@user-io1sr3jx7o спасибо, посмотрю!!

@@unicoxr5tj417 это я пока аудиторию набираю, потом буду снимать видео про ноготки 💅 (шутка)

@@PakshinaNina ноготки-норм тема. У мну в городе одна девчонка лет 40 дошла от ноготочков, до своего солону красоты)

да брось их много, просто как и почти все айтишники они скромники-интроверты

@@DimaTiunov не, мало

@@L0wPressure, коллеги! С чем работал: siemens, wago, fastwel? :)

@@PakshinaNina GE Fanuc, Trei, Тэкон и немного с Siemens :)

@@L0wPressure из перечисленных только Тэкон знаю (ну и сименс) :)

@@PakshinaNina их слишком много, чтобы все знать, да и ни к чему. Но GE достаточно активно до 14 года использовались, пока не началось импортозамещение :)

А, понял, висячий байт останется

@@mikhailm.887да, все верно :)

Добрый день, про escape analysis и аллокации есть немного в докладе про сборщик мусора, посмотрите по таймкодам.

Подскажите, Чем мультиплескирование в http2, отличается от мультиплескирования в http3? Вопрос исходит из проблемы HOL, которая есть в http2, хотя вроде как мультиплескирование должно её решать, а в http3 она решена...

​@@egorshiryaev6058 Дисклеймер: я не специалист по теме, исхожу из своего (возможно неверного) понимания лекции. http2 построен поверх tcp и обработка ситуаций с потерянными пакетами делается на этом уровне (TCP), который про мултиплексирование (происходящее на уровне выше) не знает, и ничего лучше, чем всё заморозить, пока не пропихнётся потерянный покет (соственно HOL-ситуация), не может придумать. А в http3, всё это происходит на том уровне, который знает про мультиплексирование, а значит может другие "каналы" в рамках мультиплекса обрабатывать независимо, подмораживая (если это вообще необходимо, например datagram режиму такое и вовсе ни к чему) только тот, в котором была потеря.

Да, разработчики утверждают, что pprof использует дополнительную нагрузку в 5% для профилирования ЦП и кучи. Поэтому pprof безопасно использовать в продакшене с точки зрения потребления ресурсов. С точки зрения безопасности другой вопрос: у вас в продакшене будет запущен еще один экземпляр сервера какой-то «левой» библиотеки, и это уже нужно обсуждать с вашей службой безопасности (а с ними всегда непросто :))

@@PakshinaNina спасибо за ответ!

Добрый день! В понедельник будет практикум по профайлингу и бенчмаркам (основные команды, как интерпретировать результат). В планах сделать несколько коротких практических видео по паттернам многозадачности (worker pool, for-select-done, errgroup). Думаю еще сделать практику по gRPC и по REST API. Но если ждете что-то конкретное, то пишите :)

@@PakshinaNina websocket хотелось бы посмотреть, с хорошей реализацией и аутентификацией (хотя бы н примерах), ,grpc тоже интересно Спасибо за внимание

@@developerdiary3136 да, вебсокеты тоже запишу в todo лист :)

Спасибо, буду стараться!