Авторизация через OAuth и OIDC

Мы постоянно сталкиваемся с авторизацией через сторонние сервисы, и эти сервисы запрашивают доступ к нашим контактам, фото и другим чувствительным данным.

Иногда возникает необходимость самому реализовать авторизацию через сторонние сервисы (single sign-on). В каких-то случаях подобную функциональность из коробки предоставляет фреймворк, а вам нужно только правильно всё настроить. Но в задачах, связанных с безопасностью, важно знать, что происходит под капотом, и ничего не должно делаться на ощупь.

В замечательной статье An Illustrated Guide to OAuth and OpenID Connect по полочкам раскладывается эта тема. OAuth, OpenID Connect, кто на ком стоял, из каких шагов состоит и для чего каждый используется.

Также есть видео на понятном, неспешном английском.

Статья дает базовые знания, чтобы в голове появилась чёткая картинка об этих технологиях. Если необходимо погрузиться в тему, то в конце приводятся ссылки на другие, более глубокие статьи.

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

Пятничное развлекательное

Один день в неделю у нас "культурный код". Мы делимся интересным вне технических постов. Сегодня у нас "Жизнь" Конвея.

Это игра без игроков, созданная в 1970 году. Задаёшь начальное состояние и наблюдаешь. Правила просты:
— в каждой клетке либо есть жизнь, либо нет
— в пустой (мёртвой) клетке, с которой соседствуют три живые клетки, зарождается жизнь
— клетка живёт в компании 2-3 живых соседок. Если соседей меньше 2, то клетка умирает от одиночества. Если соседей больше 3, то клетка умирает от перенаселённости

Такие правила позволяют создавать удивительные вещи. Например, планер (glider) неизменно движется. Выше вы видите ружьё Госпера — это бесконечно растущая конфигурация, которая создаёт новые планеры, двигающиеся вниз-вправо. Есть неизменные фигуры — Райский сад и другие.

Эрик Реймонд (автор Собор и базар) предложил сделать планер эмблемой хакеров.

Игра жизнь встречается даже в пасхалках Google, о чём мы писали. Симулятор смотрите тут.

#fun

Кино на выходные

Посмотрел тут Не беспокойся, дорогая (2022) с Оливией Уайлд в качестве актёра и режиссёра. Что же, рейтинг в 6.6 на кинопоиске и 5.9 на imdb — это ещё завышенная оценка. Абсолютно бездарный фильм с кучей ружей Бондарчука, когда показывают деталь типа зомби-танцовщиц, которая никак дальше не используется и не развивается. После просмотра совершенно не о чем подумать и нечего обсудить. Смотреть не рекомендую.

С теплом вспоминал Тринадцатый этаж (1999), о котором мы давненько писали в подборке интересных фильмов. Фильм не очень динамичный по современным меркам, но в нём схожие вопросы поднимаются куда глубже, чем в поделке 2022 года. Блин, по ощущениям, треть хронометража в "Не беспокойся" показывают процесс уборки дома. Увлекательнее смотреть, как растёт трава.

Посмотрите Тринадцатый этаж, он того стоит. Или те фильмы подборки, что ещё не видели.

#fun #films

ООП на простых примерах

В 40-минутном видео аккуратно объясняют три кита объектно-ориентированного программирования. Примеры даны на TypeScript, но понятны любому разработчику. Автор аккуратно иллюстрирует необходимость ООП, рассказывает про инкапсуляцию, наследование и полиморфизм. Покрыты даже относительно сложные вещи вроде параметрического и ad-hoc полиморфизма.

На трёх китах ООП автор не заканчивает. Вторая половина ролика повествует о композиции и агрегации на примере автомобиля с двигателем и колёсами, об абстрактных классах и интерфейсах, и даже немного о дженериках. Завершает изложение реализация паттернов Dependency Injection и Singleton. При этом Singleton во многих случаях является антипаттерном и мы не рекомендуем его применять.

Обратите внимание, как автор умело использует IDE для автогенерации сеттеров и геттеров. Не забывайте, что IDE — ваш добрый друг, который много чего умеет.

Про нюансы getattr и setattr в питоне мы делали отдельные посты.

#sudo #youtube #procode

Индексы в PostgreSQL

До поры, до времени базами данных можно просто пользоваться, не особо вникая в детали работы. Но однажды что-то где-то начинает подтупливать. Тут-то и приходится разбираться.

У нас уже был заход про EXPLAIN. Теперь перейдем к более серьезным вещам, которые нужны при работе с реляционными базами, в частности, PostgreSQL — индексы.

Первая статья из цикла знакомит с особенностями применения индексов в PostgreSQL. Эти знания помогут лучше понимать и обосновывать, для чего и когда использовать индексы.

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

Для освоения статьи требуется полная сосредоточенность и погружение, понадобится неоднократно гуглить. В общем, чтиво как раз на воскресный денек :)

На этой статье можно не останавливаться. Далее в цикле нас знакомят с нюансами использования конкретных типов индексов: Hash, B-tree, GiST, SP-GiST, GIN и RUM, BRIN и Bloom.

Многие практически значимые детали, приведенные в статьях часто спрашиваются на собеседовании разработчиков уровня middle.
#skills #database

БезТЗатый программист

В 24-минутном видео Михаил Флёнов (автор книги Linux глазами хакера и других) рассуждает о важности технического задания (ТЗ) в разработке. В видео полно занятных примеров из его карьеры. Особый интерес представляют истории о выкидывании ненужных фич — лучше кода может быть только его отсутствие. Самым дорогим в разработке оказывается функционал, которым никто не пользуется. Время и ресурсы потрачены, а проблемы бизнеса не решены.

По нашему опыту, техническое задание позволяет прийти к однозначному пониманию того, что нужно сделать разработчику и что получит в результате заказчик. Фрилансеру ТЗ позволяет оценить трудозатраты и соориентировать по срокам и стоимости. Кстати, сам процесс декомпозиции задач положительно влияет на точность оценки сроков разработки. Мы писали о нашем опыте отслеживания рабочего времени.

Не требуется делать ТЗ по ГОСТ или фиксировать его на годы вперёд. Можно прописывать user story и фиксировать их. Можно итеративно дополнять или корректировать ТЗ. Но важно, чтобы у всех сторон процесса создания продукта было общее понимание планов на разработку. С увеличением размера системы важность ТЗ возрастает.
#youtube #edu

Практика распила монолита

Несколько лет в индустрии шли жаркие споры "микросервисы против монолитов". У каждой из сторон было множество адептов. Однозначного решения нет.

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

— контейнеризация и хранение контейнеров

— применение API Gateway, настоящего швейцарского ножа в мире микросервисов для решения сотни инфраструктурных задач

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

— tracing, прослеживание пути запроса среди множества сервисов. Предлагаемое решение jaeger мы уже упоминали в отдельном посте про разухабистое логгирование

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

В статье приводятся не только теоретические выкладки, но и конкретные инструменты. Отдельно можно порекомендовать сервис, которым пользуется автор для выбора инструментов — Cloud Native Computing Foundation. Очень классная интерактивная и наглядная карта, где для различных задач собраны сервисы, решающие эти задачи.

В заключении автор напоминает: прежде чем внедрять — подумайте, какие задачи и проблемы вы этим решаете. Эта истина применима к любой технологии
#skills

Покоряем большие CSV

Классная практическая статья Working with large CSV files in Python from Scratch рассказывает о хитростях работы с большими CSV-файлами.

В статье рассматриваются примеры:
— подсчёт строк в большом файле. Для этого применяется mmap, который использует низкоуровневое API операционной системы. Это позволяет ускорить чтение большого файла. Сам mmap заслуживает отдельной статьи. В ней с примерами на питоне объясняется, откуда берётся ускорение, плюс другие интересности, в том числе уровня системных вызовов ядра

— разбиение большого файла на части, с которыми дальше удобнее работать

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

— хранение в виде столбцов ускорит выполнение запросов путём ограничения данных, среди которых идет поиск. Этот пункт достаточно хардкорный, рекомендуем пройтись отладчиком по коду — иначе не разобраться в нюансах

Мы на практике неоднократно сталкивались с гигабайтными CSV, которые иногда даже не умещались в оперативную память.

Например, вы знаете, что линуксовый sort --unique читает файл целиком в оперативную память? А для работы ему надо примерно в 2,5 раза больше памяти, чем весит исходный файл. То есть для сортировки файла в 10 гигов нужно около 25 гигов оперативной памяти. Решение этой проблемы заслуживает отдельного поста.
#python

Составляем документацию разработчика пошагово без диет и тренировок

Мы уже писали о своём опыте документирования проектов.

Теперь заход от больших ребят, в несколько другой плоскости.

Начинается статья с интересной блок-схемы, где отображены типичные вопросы по документации:
— Есть ли у вас документация?
— Актуальна ли она?
— Легко ли её найти?
— Читает ли её кто-то?
— В одном ли месте всё собрано?

В зависимости от ваших ответов на эти вопросы, автор рекомендует посмотреть те или иные пункты статьи. В них даются конкретные практические советы.

Часто полезная информация разбросана по разным источникам. Как подключиться к инфре писали в общем чате, нюансы работы с сервисом написали в личку, R&D таки зафиксировали в конфлюенс. Поэтому на первом шаге рекомендуется собрать всё вместе.

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

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

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

Стоит позаботиться также о читабельности. Тут все банально — на текст должно быть приятно смотреть. В статье на этот счёт есть конкретный набор советов.

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

И в заключение: с документацией, как с тестами. Не стоит думать, что, если проект не покрыт тестами, то и смысла писать их нет. Нужно просто начать покрывать тестами новый код и это уже будет хорошо. Если документация устаревшая или её вообще нет, начните с малого — начните писать её к новым разработкам.
#sudo #skills

Кино на выходные

Думаю, вы слышали о Стивене Хокинге. В 21 год ему поставили диагноз "боковой амиотрофический склероз" и предположили, что жить ему осталось 2.5 года. Болезнь прогрессировала, он перестал ходить, потом утратил возможность двигать руками. После воспаления лёгких он утратил способность говорить.

...В 2018 году он умер в возрасте 76 лет. Практически не имея возможности контактировать с окружающим миром, он вёл исследования, писал книги, выступал и даже летал в невесомости.

К просмотру рекомендуется фильм Вселенная Стивена Хокинга (2014) и одна из его книг, Краткая история времени.

#fun #films #books

Проектируем систему — System Design

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

Для изучения проектирования есть классный репозиторий аж на 200к звезд, в котором собраны различные типовые архитектуры с прицелом на подготовку к интервью. Обычно эта важная часть интервью называется system design.

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

О типовых решениях разных задач обязательно нужно знать, чтобы не городить очередной велосипед при решении новой проблемы. На эту тему у нас был отдельный пост.
#skills #резюме

Этапы выполнения запросов в PostgreSQL

Очередная фундаментальная статья на тему PostgreSQL для вдумчивого чтения. На этот раз также супер важная тема — этапы выполнения запросов. В прошлый раз мы писали об индексах.

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

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

Как итог: чтиво направлено больше на понимание кишочков, но менее захватывающим от этого не становится.

Статья является первой из цикла. Далее автор освещает использование статистики, индексное и последовательное сканирования, соединение вложенным циклом или хешированием. Всё это приблизит к глубокому пониманию того, как выполняются запросы в PostgreSQL.
#skills #database

Python import: Advanced Techniques and Tips

Импорты в питоне могут стать головной болью начинающего разработчика, особенно при переходе от запуска в IDE разработчика на чужую машину. Полезно один раз детально разобраться в этой теме. В статье рассматриваются разные вопросы работы с пакетами в питоне. Доступен перевод в двух частях: часть 1, часть 2.

Начинается статья с базового описания модуля как пространства имён и применения dir для его исследования. Далее объединение модулей в пакет и разные варианты импорта.
В статье также подробно освещаются следующие темы:
— абсолютные и относительные импорты. На практике относительные импорты — зло, PEP8 рекомендует применять абсолютные импорты в большинстве ситуаций

— import path и порядок поиска модулей

— создании своего пакета для PyPI. Классический setup.py, плюс установка изменяемого пакета для удобной разработки без необходимости переустановки. Интересным дополнением является включение ресурсов или данных в пакет на примере иконок для GUI-приложения

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

— перезагрузку модулей. Проблема в том, что повторный импорт не приводит к перечитыванию модуля, по факту используется старая версия. Для перезагрузки модуля надо использовать importlib.reload. Этот и предыдущий пункты позволяют вместе организовать динамические плагины в проекте

— работу с разными модулями в зависимости от доступности библиотек или версии интерпретатора. Это позволяет применять разные библиотеки. Нет bokeh для визуализации? Используем matplotlib. Не все фичи будут доступны, но будет работать

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

Заход на правильную организацию импортов был в посте об анализаторах кода.
#python

Жизненная история

Мы часто видим на конференциях доклады об изящных технических решениях сложных проблем. Каждый второй изобретает вундервафлю, у каждого первого хайлоад и всё красиво.

Но в реальности всё не так радужно. Бизнесу нужны решения здесь и сейчас, и продукт нередко растёт стихийно, функционируя на костылях и подпорках.

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

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

Пока происходили все эти события, бизнес вырос в пять раз. Монолит переехал на микросервисы. Инфраструктуру перенесли в kubernetes, что позволило создать распределённое отказоустойчивое решение в трёх дата-центрах.

Автор выделяет следующие преимущества kubernetes:
— канареечные выкаты, позволяющие производить A/B-тестирование
— деплой без даунтайма
— балансировка нагрузки
— горизонтальное автомасштабирование
— интеграция запуска тестов в CI с различными хитрыми конфигурациями
#skills

Частичное клонирование репозитория

Репозиторий может разрастаться до очень больших размеров. Причины могут быть разные: используете монорепо для большого проекта, храните некоторые тяжелые артефакты или просто используете удаленную гит репу, как хранилище. Команда clone может выполняться ощутимо долго.

В git есть возможность частично клонировать репозиторий (partial clone). В статье рассматриваются разные способы частичного клонирования. Каждый раз мы выбираем, какие объекты клонировать не нужно.
— blobless clone не клонирует blob объекты
— treeless clone не клонирует директории
— shallow clone — самый минималистичный вариант. С помощью параметра depth можно выбирать глубину клонирования истории, например, только последний коммит.

По каждому из пунктов автор приводит наглядные картинки и рассматривает особенности применения других команд при partial clone.

Для работы с ограниченной рабочей копией есть интересная команда sparse-checkout. На github более подробная статья с примерами применения этой команды.
#skills

Признаки хорошего логирования

Продолжим тему разухабистого логирования. Насколько подробно и много нужно писать в лог?

Иногда смотришь на портянку логов и понимаешь, что ничего непонятно. Однотипные строчки следуют одна за другой, глаза разбегаются. Логов так много, что ими уже никто не пользуется. Бывает и противоположный случай. Приложение явно работает, кряхтит шестеренками, а в stdout логов всего пара строк. И тоже возникают вопросики, что же там происходит. Поэтому важно отслеживать объём генерируемых логов. Логов должно быть не слишком много, но и не слишком мало.

"DB Connected", "Test completed", "Message processing completed" — подобные записи в логах порождают много вопросов. Что? Куда? Важно стараться давать больше конкретики. Если подключаетесь к базе, то укажите IP и порт. Запускаются какие-то тесты — стоит указать, какие именно. Прошла обработка сообщения — укажите, что за обработка.

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

На практике мы встречали попытки обратить внимание, показать важность лог сообщений различными символами. "!!! DB Connected" — примерно такое можно встретить. Не надо так. Это усложняет чтение и затрудняет поиск того, что действительно нужно найти. Для выделения важности логов придумали уровни логирования. Вот ими и стоит пользоваться.

И напоследок: логи, как и код, стоит рефакторить, критически смотреть на их информативность и необходимость.
#devfm #skills

Пятничное развлекательное

Никаких больше споров Python или Java. Знакомимся с "идеальным языком программирования" DreamBerd.

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

К чему проблемы с индексом начала массива, 0 или 1? Давайте использовать -1. И разрешать использовать нецелые числа для индексов.

Туда же спор о "табы против пробелов". Очень просто — для отступа нужно использовать 3 пробела. Кстати, минус 3 пробела тоже работает.

Конечно, для сравнения можно использовать ==, === и даже ====.

Булевы переменный могут хранить true, false и maybe. Для классов можно создавать только 1 экземпляр. Всё равно большинство разработчиком больше не требуется.

Читайте и наслаждайтесь.
#fun

Введение в Kubernetes

В повседневной разработке без докера не жизнь, а каторга. Мы делились нашим опытом, какие именно задачи решает докер.

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

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

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

Первая статья — концептуальное введение о необходимости оркестрации контейнеров без привязки к кубернетесу.

Вторая статья освещает основные концепции — cluster, nodes, pods, namespaces, кто на ком стоял.

Третья подробнее рассказывает о супер-важной штуке в кубере — подах (pods). Почему не хватает контейнера, из чего состоит под, в каких состояниях он может быть и как проверить его работоспособность.

Кто-то должен управлять всем развернутым зоопарком, предоставлять API для взаимодействия, решать на каком узле запустить под, контролировать работоспособность различных частей кластера и пытаться приводить всё к требуемому состоянию (desired state). Четвертая статья рассказывает о мастер-ноде и компонентах, которые берут на себя все эти задачи.

Пятая статья вводит ещё один набор концепций, которые активно применяются в кубернетесе — deployments, stateful set, daemon, jobs. Со всем этим неизбежно сталкиваешься на практике.

И заключительная, шестая статья рассказывает о том, как устроено взаимодействие различных частей в кластере, какие IP-адреса существуют, для чего они используются и как в обращении с ними помогают load balancer и ingress controller.

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

🔥, если интересна тема кубернетеса.
#skills

Доступаемся до ChatGPT

Нейросеть ChatGPT уже многие попробовали, и это просто вау! Для тех, кто ещё не пробовал — очень рекомендуем. Интересные варианты использования:
— можно решать и оптимизировать задачи на программирование. В комментариях к посту про быстрый поиск в 37 Гб файле подписчик уточняющими вопросами уровня "а как можно улучшить" заставил нейросеть пройти те же шаги, что и автор статьи

— проходить собеседования, причём и теорию, и практику. ChatGPT умеет писать код -__-

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

— писать рефераты и конспекты. Нам прислали интереснейший пример: для подготовки к экзамену студент ввёл "напиши небольшой конспект для экзамена на тему ХХХ" и получил действительно годную выжимку по вопросу. 20 минут и готов конспект для подготовки по всем вопросам к экзамену

Какие ещё есть примеры использования? Проявите фантазию и делитесь в комментариях.

Из грустного: сервис не работает из России, но думаем с VPN уже все разобрались :)

Также требуется регистрация. На этот случай рекомендуем удобный сервис BugMeNot. Просто вводите сайт, а в ответ будет предложены учетные данные для входа.

BugMeNot бывает полезен, когда не хочешь регистрироваться на каком-нибудь ресурсе.
#edu

Google Coding Interview With An Artificial Intelligence (ChatGPT)

В видео Clément Mihailescu, бывший Software Engineer из гугла, а нынче со-основатель площадки AlgoExpert, сервиса платной подготовки к интервью проводит mock google coding interview с чат-ботом. Иногда в процессе бот отваливался. Сами вопросы:
— напиши функцию определения палиндрома. Интересно то, что на повторный вопрос ChatGPT выдал совершенно другой код. Первый раз код был "в лоб", очень длинный и хорошо документированный. Второй раз код был в стиле Си-хакеров, пусть код и на JavaScript

— оцени сложность по памяти и времени этого алгоритма (space-time complexity). Автор комментирует ответы бота и восторгается, как внимательно в ответе раскрываются нюансы и граничные случаи

— поиск подстроки, которая является самым длинным палиндромом заданной строки. Вопрос с подвохом — решение в лоб имеет сложность O(n^3), а оптимальное решение O(n^2). Как вы понимаете, ChatGPT сразу выдаёт решение квадратичной сложности. Сам автор говорит, что когда-то не смог решить эту задачу на своём собеседовании в Lyft. Причём при очередной попытке задать этот же вопрос бот выдал решение O(n^3), но подметил, что это решение "не самое эффективное, но простое и его проще понять"

— хитрая задача про награду студентов. В этот момент я сдался, без подготовки такую задачу не решить. Обратите внимание, что бот документирует свой код, правильно решает крайние случаи, рассказывает, как пошагово работает код — все важные аспекты, которые должен учесть собеседуемый для получения оценки strong hire. Единственное, чего не делает бот — не задаёт уточняющих вопросов, но, вероятно, это связано с изначально детальной постановкой вопроса
#skills #резюме

JWT и его друзья

Хорошая заметка, чтобы вникнуть в token-based authentication.

Начинается всё банально — чем аутентификация отличается от авторизации. Дальше интереснее — access и refresh-токены. Что это, как устроены, почему они в паре и какое имеют отношение к авторизации.

Автор уделяет внимание процессу обновления токенов, правильному хранению, а также компрометации — что будет, если токены угонят.

Очень важно уметь правильно обращаться с токенами и хранить их. Во многих мануалах на просторах интернета учат, как делать проще, но не как делать правильно.

В заключение автор кратенько сравнивает JWT со столь привычными для многих cookie sessions и даёт несколько практических советов.

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

Для проекта средних размеров предлагаем взять популярное open source решение — Keycloak и развернуть его как сервис. Да, сначала будет непросто и нужно разобраться в особенностях. Но на длинной дистации это правильное решение.
#skills