как и обещал, скидываю вам презентацию с доклада, где можно помимо прочего заново найти ссылки на интересные и полезные RFC!

https://excalidraw.com/#json=4oO6flic0-A9GeLO-tZOF,NVvH_ap77sEGm9EMDtRMUg

UPD

ах да, ещё и репозиторий с простым примером работы с куками в ASP.NET Core, где помимо прочего лежит и фронтенд (пожалуйста, не смотрите это, если вы фронтендер)

https://github.com/eveloth/conf/tree/master/authn

завтра в 18:30 я буду выступать на митапе с докладом про cookie-аутентификацию под капотом

приходите!

https://t.me/natti_jun_front/83

Telegram

Наташа пишет для джунов

Митап Джуниоров #19 Этот митап почти полностью для бэков ***🌸*** ***⏰*** Стартуем 05/10, в 18:30 по Мск, вход свободный, всем рады! Запись будет! ***▶️*** Трансляция тут - https://www.youtube.com/watch?v=LRKTPLIFLtA ***📙*** Программа: 1) Доклад «Cookie-аутентификация — как…

Что-то из сегодняшних диалогов напомнило мне об одной из моих самых любимых цитат. Её автор — Джефф Дантмэн, который написал книгу "Assembly language step by step". Перевода её на русский нет — ну или я так и не смог его найти, хотя долго искал, поэтому перевод мой — пришлось тряхнуть стариной и вспомнить о своей когда-то-работе.

---

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

И тут я сболтнул нечаянно, что я — фанат Turbo Pascal, и мне бы очень хотелось научиться писать на нём программы с графическим интерфейсом, который недавно появился в Microsoft Windows. Он поморщился и иронично ухмыльнулся, прежде чем задать Печально Известный Вопрос:

«Ну и зачем тебе это нужно?»Я раньше никогда не слышал этого вопроса (что ж, услышу еще не раз в будущем) и он застал меня врасплох. Зачем? Ну, затем, чтобы... затем... Мне хотелось понимать, как это работает.

«Хе. Ну, для этого есть С.»

Мне так и не удалось снова развернуть разговор в сторону Pascal. Но в попытках это сделать я понял, что писать на Turbo Pascal программы под Windows было нельзя. Это было невозможно. Или... или этот известный автор книг/гуру не знал, как. А может, и то, и другое. До сих пор не знаю. Но я узнал, в чём суть Печально Известного Вопроса.

Запомните: когда кто-то спрашивает вас, «Ну и зачем тебе это нужно?», это на самом деле означает: «Ты задал мне вопрос о том, как сделать что-то, что либо невозможно сделать с помощью инструментов, которые мне нравятся, либо у меня вообще нет в этом опыта, но я не хочу в этом признаваться. Так что... Как, говоришь, сыграли Черные Ястребы?»

После того, на протяжении многих лет, я часто слышал этот вопрос снова:

В: А как можно узнать длину строки в C, не проходясь по ней полностью?
О: Ну и зачем тебе это нужно?В: Как написать модуль на ассемблере, чтобы его можно было вызвать из Turbo Pascal?
О: Ну и зачем тебе это нужно?В: Как написать приложение под Windows на ассемблере?
О: Ну и зачем тебе это нужно?Ну, вы поняли. А ответ на Печально Известный Вопрос всегда один, и когда всякие проныры будут задавать его вам, отвечайте как можно быстрее: «Потому что мне хочется знать, как это работает.»И этого ответа совершенно достаточно.

А в-четвёртых... есть такой жанр, обзоры дистрибутивов Linux. На нём можно собрать неплохое количество просмотров, только есть небольшая проблема — обзор предустановленных пакетов, DE и процесс установки, одинаковый почти что для всех современных дистрибутивов, в плане полезной информации не даёт вообще ничего. А эти самые обзоры чаще всего ничего большего и не предлагают. Точно такое же у меня впечатление от обзоров подобных dotnet-технологий. Выглядит всё это классно, спору нет — и работать оно будет классно на тестовых примерах, тоже спору нет.

Но чего мне не хватает — так это не слов "cool", "fast", "modern" и "now it is the only right way to do X" — а более подробного обзора, что этот blazingly fast modern framework из себя представляет, какие именно он должен решать задачи и на что я могу рассчитывать, а на что не могу.

Использование технологии, конечно, всегда на совести использующего, поэтому я и начал с себя — но, если честно, как было бы классно видеть больше подробных и более вдумчивых форматов — а из такого я пока могу посоветовать только Raw Coding, да наверное и всё.

Давно ничего не писал, потому что устроился на работу и пока что на забирает кучу времени; как мне и говорили, вливаться в проект, особенно большой и особенно первый, требует много сил и времени.

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

Когда я писал тестовое, мне хотелось не только его написать, но и запихнуть туда что-то новое-модное-молодежное, на чём сейчас любят концентрироваться разнообразные англоязычные dotnet каналы. И, скажем так, уже на этом этапе можно поспорить с тем, что это хорошая идея.

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

Но мне так хотелось произвести впечатление, что я решил взять даже не известный более-менее всем minimal API, а Fast endpoints, minimal APIs, как они говорят, made easy.

Так я и познакомился с особенностями model binding в этих самых minimal APIs.

Скорее всего, что такое model binding, вы знаете, особенно если читали «ASP.NET Core в действии» Эндрю Лока — а если не читали, очень советую. Так вот, что особенно в нём, в model binding, хорошо, на мой взгляд, так это возможность получать некий набор query-параметров в виде объекта, как-то так:

```
record PaginationFilter(int PageNumber, int PageSize);

public async Task Get([FromQuery] PaginationFilter filter) {}

`` Таким образомPageNumberиPageSize, переданные в query string, будут связаны со свойствамиPageNumberиPageSizeфильтра пагинации и будут доступны в контроллере через объектfilter`.

Так вот, в minimal APIs model binding работает по-другому, и без дополнительных махинаций так сделать нельзя. А поскольку FastEndpoints построен на minimal APIs, работать это там тоже не будет.

Дело в том, что если вам нужно добиться такого поведения, то классы, представляющие набор параметров, должны либо реализовывать метод TryParse(), либо BindAsync() — о чём я узнал в самое неподходящее время, то есть, не до того, как я придумал, как должен работать мой микросервис и реализовал большую часть из того, что я придумал, а после. Думаю, выводы напрашиваются — и дело даже не в том, что minimal APIs «работают плохо»...

Ко всему прочему, у меня не получилось быстро реализовать эти методы. А быстро надо было — на тестовое у меня было полтора дня, и время это стремительно утекало, пока я читал доку и пытался дебажить нерабочий код. Которого могло бы не быть, если бы я не совершил несколько ошибок.

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

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

В-третьих, как и всегда, документация — это важно. Даже если инструмент кажется знакомым, но это новый инструмент —- хорошо бы внимательно почитать, какие у него ограничения и где он будет вести себя не так же, как старый. Потому что на знакомое поведение можно очень сильно рассчитывать.

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

https://telegra.ph/Kak-ya-rabotu-v-tehpodderzhke-avtomatiziroval-chast-II-04-20

Если вам интересно посмотреть код, то он вот здесь.

Надеюсь как-нибудь оформить всё это во что-то цельное и может быть прям где-то и опубликовать.

Telegraph

Как я работу в техподдержке автоматизировал, часть II

В прошлый раз я рассказывал, как написал программу, анализирующую звонки для колл-центра большого провайдера. Но была на работе ещё одна проблема, и, возможно, даже более сложная. Поскольку дежурный инженер сидит сутки через трое, то ночью он тоже, разумеется…