Открыли доступ для всех. Нужно зарегиться, верифицироваться по номеру телефона и у вас будет 50 генераций :) Налетай!

https://openai.com/dall-e-2/

Конфа DotNext на прошлой неделе выложила на ютубе дофига полезных докладов! Ловите ссылочки :

Григорий Кошелев — Kafka: от теории к практике
Андрей Парамонов — gRPC: наш опыт внедрения. Почему всегда он?
Евгений Пешков — .NET: AOT в 2022
Анатолий Жмур — Поговорим о хэш-функциях
Н. Липилин (PVS-Studio) — SAST и SCA: поиск дефектов безопасности в коде проекта и его зависимостях
Круглый стол. Споры об аутентификации и авторизации на платформе ASP.NET Core
Денис Тарасов, Дмитрий Афанасьев — Атакуем цепочку поставок
Сергей Васильев — Обработка XML-файлов как причина появления уязвимостей
Сергей Баранов — Многоликий DDD
Вадим Мартынов — C# vNext: 20 фич из будущего
Круглый стол. Как стать сеньором
Павел Тупицын — Как написать высокопроизводительный драйвер базы данных
Антон Нечуговских — Как мы написали свой lock-free dictionary
Adam Furmanek — Ordering the Chaos: Cleaning Logs and Ordering Events in Microservices
Александр Поломодов — Как развиваться, если ты уже Senior Software Engineer
Алексей Патрин — Обезболивание enterprise-разработки. Применяем лучшее из мира микросервисов
Константин Ахметов (ПСБ) — Бизнес-конфиги
Леонид Андриевский — FFmpeg в приложениях .NET для работы с медиафайлами
С.Огородников, Р.Просин, К.Хабаров — Аутентификация и авторизация на платформе ASP.NET Core
Станислав Сидристый — Тонкие настройки стандартного ThreadPool
Круглый стол. Про Kafka и не только
Станислав Флусов — Миграция с MS SQL в PostgreSQL, когда нужно ещё вчера

Я уже делал похожую подборку с Highload конфы, можно найти по тегу #доклады 😉

Когда выслал другу мем, а в буфере был файл с кодом...

meme-orienting-programming!

stackoverflow наконец одарил новой ачивкой. top 1.00% this year 😃 Господа индусы судя по всему подвинулись на скамейке хД

Вообще, на стеке я уже почти 11 лет. И стараюсь всегда, когда не нахожу ответа - постить свои солюшены. Но по факту, рейтинг набирается довольно рандомно. Если повезет, один-два ответа взлетают и становятся с 100+ апвотами, 99% же или набирают пару-тройку, или же вообще остаются без внимания. В целом, всё так и должно быть - насколько ты полезен сообществу, настолько и апвотают. А полезны обычно какие-то супер-базовые ответы и обычно там уже всё отвечено до тебя. Довольно узкие и сложные ответы может кому-то и экономят время, но по сути - единицам. Какого-то "быстрого" пути я не заметил, но как видно и стратегия "нашёл проблему -> не нашёл решения -> оформил и запостил" на долгосрочной дистанции всё же даёт свои плоды. Тут как и везде - делаешь что-то на постоянке -> рано или поздно получаешь профит. Возможно, еще один вариант - коммитаться во всё новое, новые технологии/фреймворки. Там и проблем больше и таких же заинтересованных в решении этих проблем.

Есть ещё возможность задать сложный вопрос, о который бьёшься головой не первый день и "закинуть" n репутации в качестве мотивации вникнуть в твой кейс. Тот, кто ответит правильно и забирает эти n поинтов себе в карму. А у тебя отнимается. Но тут есть проблема - если никто не ответит, награда присуждается то ли рандомом, то ли как-то ещё, т.е. это не гарантирует, что вы решите проблему. Я разок так вот и "задонатил" кому-то. Спорненько :)

Кстати, не понятно почему не "1%", а "1.00%". Видимо я словил эджкейс, т.к. сотые уже идут у людей <1%. Зарепортить чтоль 😂

И да, по моему опыту на собесах всем фиолетово на твой профиль в stackoverflow :) Так что бустить специально смысла не вижу.

Просто очередная приятная ачивка, не более того 😉 Делитесь в комментах своей статистикой, если есть, интересно глянуть. Всем бобра.

Небольшая задачка по #aws #serverless #telegram_bot

Есть тг бот, работает на AWS Lambda. Приветствует входящих пользователей. Вопрос - как сделать так, чтобы бот через час удалял за собой это сообщение? Условие : serverless решение. В рамках AWS.

Цель : нет нагрузки -> нет трат. Собственно, в этом же и есть преимущество serverless идеологии.

Первое, конечно же что приходит на ум - деплойнуть банальный воркер на минимальный EC2, который будет имитировать простейший scheduler. Может быть cron, может быть простой скрипт зацикленный, который будет ожидать "задания" в виде {messageId}, который нужно удалить в {dateTime}. Но... не хотелось без постоянно поднятой машинки.

Дальше приходит на ум амазоновская очередь SQS. Закидываем в очередь сообщение, ставим ей какой-то readyToHandle в 60 минут. Он через час становится видимым и подписываем на очередь еще одну лямбду, которая автоматически триггернется как только сообщение станет видимо в очереди.
Подходит, но есть одно но - SQS и правда имеет параметр сообщения "DelaySeconds", однако, его максимальное значение - 15 минут. Не подходит.

Вот в целом-то и все доступные варианты, если глянуть поверхностно. Но к счастью, есть ещё один...

Решение

Оказалось, на aws есть сервис States - AWS Step Functions. Машина состояний. Что это такое?

Step Functions — это сервис бессерверной оркестровки, который позволяет комбинировать функции AWS Lambda и другие сервисы AWS для создания критически важных для бизнеса приложений. С помощью графической консоли Step Functions вы видите рабочий процесс своего приложения как серию управляемых событиями шагов. Step Functions основана на конечных автоматах и задачах. Конечный автомат — это рабочий процесс. Задача — это состояние в рабочем процессе, которое представляет собой единицу работы, которую выполняет другой сервис AWS. Каждый шаг рабочего процесса — это состояние (с) habr

Если проще - вы можете "накидать" так называемых шагов на амазоновский юайчик, связать их стрелочками-условиями и быть уверенным, что они исполнятся при определенных условиях. Получается блок-схема. У кого есть айтишное образование точно рисовали такие на парах.

Одним из "степов" может выступать кубик с названием "Wait", который отвечает за "паузу в n ms". Выглядит это вот так. И этот wait time можно в том числе указывать и прграммно. Т.е. данные могут переходить по этим состояниям.

Собственно...подходит! Флоу получился такой :

1. Входит новый пользователь. Лямбда ловит вебхук от телеграма, приветствует пользователя.
2. Лямбда триггерит созданную стейт-машину, передаёт туда условный {messageId} сообщения, которое нужно удалить и время, через сколько секунд.
3. Запускается стейт-машина/флоу на aws. Она переходит в режим ожидания. А через час вызывает мою лямбду, передавая ей мой джсончик с данными.
4. Отдельная лямбда, выполняющая только одну функцию - удаление из тг чата... удаляет сообщение.

PROFIT!

Стоит это всё копейки, при минимальной нагрузке. Что-то а-ля 1000 переходов состояний за 0.025$ + копеечка за лямбду.

Может кому когда понадобится 😉
Если вдруг у вас есть другие workarounds - пишите в комментариях, интересно будет почитать

Кубиты, Квантовые компьютеры - как это работает? Шифрование RSA под угрозой? Или же пока ещё нет?

Все вы слышали про кота Шрёдингера и про какую-то там коробку, в которой одновременно кот существует и не существует, верно? Но ставлю доллар, что навряд ли вы вникали в эту тему. Я не исключение. Ибо не сказать, что я силён в математике и физике чтобы хоть немного понимать сабж.

Но вот вам интереснейшее чтиво на #habr'е, которое пытается "на пальцах" объяснить что есть квантовые компьютеры в сегодняшнем мире, что такое кубит, суперпозиция и квантовая запутанность. А так же каким образом оно может быть полезно для алгоритмики.

Так что если интересно немного расширить кругозор - прыгайте в статью.

ВНИМАНИЕ! Автор хоть и на пальцах написал статью - обязательно дополнительно прочтите все комментарии к ней, ибо, в некоторых утверждениях он (автор) всё же сам не до конца разобрался в некоторых аспектах в теме и в комментариях пришли люди, которые действительно шарят и так же "по полочкам" пояснили. В целом, у вас сложится какое-то начальное понимание, всё довольно доступно изложено.

С этими премиумными статусами телега себе портал в ад открыла! Эпилептики негодуют.

Отключат 💯 , скриньте.