ITmozg

В 2002 году мир математики стал свидетелем исторического момента, когда российский математик Григорий Перельман представил первую из трех новаторских работ, представивших доказательство неуловимой гипотезы Пуанкаре. Эта гипотеза ставила в тупик математиков более столетия, что сделало ее одной из самых сложных нерешенных проблем в этой области. Работа Перельмана была поистине революционной. Он успешно сориентировался в запутанном лабиринте топологии и в конечном итоге предоставил строгое и элегантное доказательство своей гипотезы. Его достижение потрясло математическое сообщество и сразу же привлекло внимание коллег и экспертов со всего мира. В знак признания своих исключительных достижений Григорий Перельман был награжден престижной медалью Филдса в 2006 году, что считается высшей наградой в математике. Однако реакция Перельмана на эту похвалу была столь же нетрадиционной, как и его математическое путешествие. Совершив беспрецедентный шаг, он отказался от медали Филдса, избегая всеобщего внимания и традиционных атрибутов успеха. Его затворнический и скромный характер стал очевиден миру. Но отказ Перельмана принять признание на этом не ограничился. Математический институт Клея также пообещал существенное финансовое вознаграждение в один миллион долларов за доказательство гипотезы Пуанкаре. Поступок, который еще больше сбил с толку многих, Перельман отказался и от этой значительной суммы. Его цитировали: «Меня не интересуют деньги или слава; я не хочу, чтобы меня выставляли напоказ, как животное в зоопарке». Действия Перельмана оставили в мире больше вопросов, чем ответов. Его отказ как от медали Филдса, так и от премии в миллион долларов пролил свет на его глубоко укоренившиеся ценности и приоритеты. Это выдвинуло на первый план математика, движимого не похвалами или богатством, а непоколебимой преданностью делу чистой математики и поиску истины. Вклад Григория Перельмана в математику и его загадочная личность оставили неизгладимый след в этой области. Его решение отказаться от признания и богатства в пользу интеллектуальной честности служит свидетельством чистоты его математических занятий. В анналах математики он остается уникальной фигурой, блестящим умом, который разрешил одну из величайших математических загадок нашего времени и решил сделать это на своих собственных условиях. ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

🔥 СВЕЖИЙ АД, ПРЯМО В ТВОЙ МОНИТОР! 💀 Они думали, что ад остался на Марсе… Они ошибались. DOOM возвращается — теперь в виде лёгкого, как бензопила в руках Мародёра, и безжалостного, как ракета в лицо кибердемону, порта на Go. Никаких платформенных цепей. Никакого CGo. Только чистая ярость и кросс-компиляция, рвущая реальность на куски. 🔸 Запускается везде, где бьётся сердце Go 🔸 Минимум балласта — только стандартная библиотека Go 🔸 Полная линейка ада: DOOM, DOOM II, Ultimate DOOM, Final DOOM 🔸 WAD — твой пропуск в бездну: приноси своих демонов 🔸 Память в бронежилете: защита от переполнений буфера (но не от зубов какодемона) 🔸 Оружие массового поражения — кросс-компиляция под любую цель Подготовься. Натяни броню. И перезаряди BFG… https://github.com/AndreRenaud/gore ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. https://max.ru/tipsysdmin Типичный Сисадмин https://max.ru/channel_win_sysadmin Системный Администратор Windows https://max.ru/channel_linux_admin Linux: Системный администратор https://max.ru/channel_linuxmod Linux https://max.ru/channel_i_linux Системный администратор https://max.ru/channel_devopslib DevOps, SRE, Sysadmin https://max.ru/channel_devops_star DevOps Star (Звезда Девопса) Excel лайфхак 📌 https://t.me/Excel_lifehack Excel лайфхак Английский с нуля 🇬🇧 https://max.ru/UchuEnglish 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С https://max.ru/channel_DevLab1C 1С:Предприятие 8 Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика https://max.ru/channel_cpp_geek C++ geek Программирование Go📌 https://max.ru/golang_lib Библиотека Go (Golang) разработчика Программирование React📌 https://max.ru/react_lib React Программирование Rust📌 https://max.ru/channel_rust_lib Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика https://max.ru/channel_java_geek Java Geek GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии в IT📌 https://max.ru/progjob https://max.ru/channel_rabotait Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Бонус 📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП

🔐 Путеводитель по аутентификации: от Cookies до OAuth 2.0 Разбираться в способах входа пользователя в систему можно бесконечно, но эта шпаргалка отлично раскладывает всё по полочкам. Давайте разберем эволюцию методов «узнавания» пользователя. 1. WWW-Authenticate (Basic Auth) Самый древний способ. Браузер запрашивает логин/пароль и отправляет их в каждом заголовке. • Минус: Невозможно нормально управлять жизненным циклом сессии (сложно разлогиниться). 2. Session-cookie Классика веба. После входа сервер создает сессию в базе, а браузеру отдает Session ID в куках. • Проблема: Плохо масштабируется и «не дружит» с мобильными приложениями, которые не всегда умеют работать с куками так же, как браузеры. 3. Token & JWT Чтобы не дергать базу данных каждый раз, придумали токены. • Token: Обычная строка, которую проверяет отдельный сервис валидации. • JWT (JSON Web Token): «Умный» токен. Он содержит внутри хедер, полезную нагрузку (данные пользователя) и подпись. Серверу не нужно лезть в базу, чтобы проверить его валидность - достаточно проверить подпись. 4. SSO (Single Sign-On) Когда у вас много сайтов (a.com, b.com), а логин один. Центральный сервис аутентификации (CAS) берет на себя проверку личности и перенаправляет пользователя между ресурсами без повторного ввода пароля. 5. OAuth 2.0 Стандарт для предоставления доступа сторонним приложениям (например, «Войти через Google»). Основные сценарии: • Authorization Code: Самый безопасный (через браузер и сервер). • Client Credentials: Для общения между двумя серверами. • Implicit Grant: Упрощенный путь для мобильных и JS-приложений (сейчас считается менее безопасным). • Password Grant: Прямая передача логина/пароля (используется только в доверенных приложениях). #backend #security #jwt #oauth #webdev ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

📌7 распространённых асимптотических сложностей алгоритмов 1. O(1) — Константное время - Время выполнения не зависит от размера входных данных. - Пример: доступ к элементу массива по индексу. 2. O(log n) — Логарифмическое время - Время выполнения растёт медленно при увеличении размера входных данных. Обычно встречается в алгоритмах, которые на каждом шаге делят задачу пополам. - Пример: бинарный поиск в отсортированном массиве. 3. O(n) — Линейное время - Время выполнения растёт прямо пропорционально размеру входных данных. - Пример: поиск элемента в массиве перебором всех элементов. 4. O(n log n) — Линейно-логарифмическое время - Время выполнения растёт чуть быстрее линейного, включает логарифмическое число операций для каждого элемента. - Пример: сортировка массива быстрой сортировкой или сортировкой слиянием. 5. O(n²) — Квадратичное время - Время выполнения пропорционально квадрату размера входных данных. - Пример: сортировка пузырьком, где сравниваются и при необходимости меняются местами все пары элементов. 6. O(2ⁿ) — Экспоненциальное время - Время выполнения удваивается с каждым новым элементом во входных данных. Такие алгоритмы становятся непрактичными для больших входных размеров. - Пример: генерация всех подмножеств множества. 7. O(n!) — Факториальное время - Время выполнения пропорционально факториалу размера входных данных. - Пример: генерация всех перестановок множества. ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

Git Merge vs Rebase Одной из самых мощных возможностей Git является работа с ветками. Однако при работе с ними нам нужно интегрировать изменения из одной ветки в другую, и способов сделать это несколько. Есть два основных метода: 1. Merge (слияние) Когда вы сливаете ветку A в ветку B (с помощью git merge), Git создаёт новый merge-коммит. У этого коммита два родителя — по одному от каждой ветки, что символизирует объединение их истории. - Это неразрушающая операция, которая сохраняет точную историю проекта. - Merge особенно полезен в командной работе, когда важно сохранить целостность и хронологию изменений. Минус: merge-коммиты могут "засорять" историю, усложняя отслеживание конкретных изменений. 2. Rebase (перебазирование) Когда вы перебазируете ветку A на ветку B (с помощью git rebase), это означает: "Давайте сделаем вид, что изменения из ветки A были сделаны поверх последних изменений ветки B." - Rebase переписывает историю проекта, создавая новые коммиты для каждого из исходных коммитов. - Результат — чистая, линейная история. Минус: может быть проблематично, если над веткой работают несколько человек, ведь перебазирование переписывает историю, что усложняет совместную работу при уже опубликованных ветках. Когда что использовать? - Merge — когда важно сохранить полную историю и вы работаете с общими ветками. Идеально для слияния feature-веток в main или develop. - Rebase — для личных веток или когда нужна чистая, линейная история для удобства отслеживания изменений.

Важно: не делайте rebase публичной истории. Если ветка уже опубликована и с ней работают другие, переписывание истории приведёт к конфликтам и путанице.

♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

Параллелизм против Конкурентности — это не одно и то же ➡️𝐂𝐨𝐧𝐜𝐮𝐫𝐫𝐞𝐧𝐜𝐲 (Конкурентность): Конкурентность означает, что приложение продвигается сразу по нескольким задачам одновременно. Хотя одно ядро процессора может выполнять только одну задачу за раз, оно достигает конкурентности за счёт быстрого переключения между задачами. Пример: Слушать музыку и писать код одновременно. Процессор так быстро переключается между задачами, что создаётся ощущение одновременного выполнения. Основная цель конкурентности — максимально загрузить CPU, минимизируя время простоя. ➡️𝐏𝐚𝐫𝐚𝐥𝐥𝐞𝐥𝐢𝐬𝐦 (Параллелизм): Параллелизм означает одновременное выполнение нескольких задач. Для достижения параллелизма задачи разбиваются на независимые подзадачи и обрабатываются одновременно на нескольких CPU, ядрах или GPU. Пример: Обучение модели глубокого обучения путём разбиения датасета на батчи и параллельной обработки каждого батча на разных GPU. Цель параллелизма — увеличение скорости обработки за счёт параллельного выполнения задач. Они не исключают друг друга: - Можно иметь конкурентность без параллелизма. - Можно иметь параллелизм без конкурентности. - А можно совместить оба подхода для систем с высокой производительностью. ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

7 обязательных стратегий для масштабирования вашей базы данных ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

BIOS и UEFI / стадии UEFI / драйвера и протоколы Сергей Пушкарёв — руководитель отдела разработки BIOS в YADRO. Сергей начал работу с BIOS и UEFI ещё в университете и может очень много рассказать об этой области. С Еленой Лепилкиной и Антоном Афанасьевым наш герой во всех подробностях разобрал, что происходит на самом низком уровне софта после того, как пользователь нажимает кнопку включения компьютера. Параллельно осветил разные подходы и типичные проблемы разработки в своей сфере, тонкости взаимодействия драйверов, а также разницу между BIOS и UEFI. А напоследок ответил, к чему приводят баги в BIOS и как стараются их избежать, если цена ошибки слишком высока. 0:00 - Тизер 1:12 - Представление Сергея Пушкарева 2:11 - Карьерный путь Сергея 4:50 - История развития BIOS и UEFI и разница между ними 11:28 - Достоинства UEFI 14:14 - Стадии работы UEFI 15:09 - Что работает до UEFI 18:25 - стадия SEC и режим Cache-Is-RAM 22:58 - стадия PEI 27:54 - переход в 64-битный режим 28:42 - PE-файлы,Terse Executable и вопросы производительности 30:46 - DXE стадия и запуск драйверов 33:02 - Протоколы для взаимодействия драйверов 37:58 - Эволюция спецификации: новые архитектуры, Device path для нового железа 40:31 - Загрузка ноутбука через Wi-Fi, разница драйверов Linux и UEFI 42:58 - Работа разработчиков BIOS 44:06 - Баги в UEFI 46:45 - Разработка UEFI под новую платформу 50:38 - Взаимодействие BIOS с BMC, Redfish 53:22 - Разработка драйвера на EDK2 59:55 - Нужен ли ассемблер разработчику BIOS 1:04:13 - Как поменялся процесс загрузки с приходом UEFI 1:05:51 - Взаимодействие BIOS и операционной системы 1:07:20 - Как UEFI работает на ARM 1:11:29 - VFR - DSL-язык для описания меню 1:14:23 - Активное использование Open-Source 1:16:22 - Рынок компаний разработчиков UEFI 1:20:33 - Разработка UEFI для системы, которой нет в железе 1:21:37 - Баги в релизах и процесс тестирования 1:25:59 - Дальнейшее развитие BIOS: ускорение работы, драйверы на Rust 1:35:07 - Заключение источник ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

🔐 Как на самом деле работает электронная цифровая подпись (ЭЦП)? Разбираем по шагам! Мы часто слышим про «цифровые подписи», но как именно математика и криптография защищают наши документы? На прикрепленной схеме отлично показан весь процесс. Сохраняйте себе, чтобы не потерять! 📌 Процесс делится на два главных этапа: создание подписи (у отправителя) и её проверка (у получателя). 📤 ЭТАП 1: Создание подписи (Сторона отправителя) 1. Создание хэша: Берется исходный документ и пропускается через математический алгоритм - хэш-функцию (например, SHA-256). На выходе получается уникальный «цифровой отпечаток» документа. Главная фишка хэша: если изменить в документе хоть одну запятую, хэш изменится полностью. 2. Шифрование: Отправитель берет этот хэш и шифрует его своим Закрытым ключом (Private Key). Этот ключ есть только у него! 3. Готово: Зашифрованный хэш - это и есть Цифровая подпись. Она прикрепляется к оригинальному документу, и весь этот пакет отправляется по сети. 📥 ЭТАП 2: Проверка подписи (Сторона получателя) Когда документ доходит до адресата, получателю нужно убедиться в двух вещах: что документ прислал именно заявленный автор, и что файл не подменили по пути. 1. Свой хэш: Получатель берет присланный документ и сам пропускает его через ту же хэш-функцию (SHA-256). Получает новый хэш. 2. Расшифровка подписи: Затем получатель берет прикрепленную цифровую подпись и расшифровывает её Открытым ключом (Public Key) отправителя (этот ключ доступен всем). После расшифровки он получает оригинальный хэш, который сделал отправитель. 3. Момент истины - Сравнение: Получатель сравнивает два хэша. ✅ Если они совпадают: Документ 100% подлинный. Его подписал владелец закрытого ключа, и по пути в тексте ничего не меняли. ❌ Если они разные: Документ был изменен злоумышленником при пересылке, либо подпись недействительна. 💡 Главное правило асимметричной криптографии: Подписываем - своим закрытым ключом 🔑 Проверяют нас - нашим открытым ключом 🔓 ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

Но что же такое коды Хэмминга? Истоки коррекции ошибок. ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

Антипаттерн: "Сначала MVP - потом нормальная схема" Частая ошибка при старте проекта - отложить продумывание структуры базы «на потом»:

«Сейчас сделаем быстро MVP, а потом приведём БД в порядок».

И вот что часто происходит: – MVP превращается в продакшн без переработки схемы. – Костыли начинают множиться. – Появляется технический долг, который сложно погасить: миграции становятся болью, связи - запутанными, а данные - ненадёжными. Типичные симптомы: — nullable-поля без нужды — дублирование данных — универсальные таблицы вроде entities или attributes — "магические" значения в enum-полях — отсутствие внешних ключей и индексов Как избежать: 1. Минимум нормализации - с самого начала. Даже для MVP важно заложить понятную структуру. 2. Используй миграции сразу. Даже если это скрипт в папке migrations/, а не полноценный tool. 3. Заведи ER-диаграмму. Она не обязана быть идеальной, но уже поможет избежать хаоса. 4. Смотри в будущее. Планируешь рост? Подумай о расширяемости схемы. 5. Не стесняйся рефакторить. Лучше на раннем этапе изменить структуру, чем через год бояться сломать прод. 👉 MVP не должен значить "без архитектуры". Плохая схема - это замедление развития и боль на каждый новый фичереквест. ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

Пишем отладчик для Linux Part 1: Setup https://blog.tartanllama.xyz/writing-a-linux-debugger-setup/ Part 2: Breakpoints https://blog.tartanllama.xyz/writing-a-linux-debugger-breakpoints/ Part 3: Registers and memory https://blog.tartanllama.xyz/writing-a-linux-debugger-registers/ Part 4: Elves and dwarves https://blog.tartanllama.xyz/writing-a-linux-debugger-elf-dwarf/ Part 5: Source and signals https://blog.tartanllama.xyz/writing-a-linux-debugger-source-signal/ Part 6: Source-level stepping https://blog.tartanllama.xyz/writing-a-linux-debugger-dwarf-step/ Part 7: Source-level breakpoints https://blog.tartanllama.xyz/writing-a-linux-debugger-source-break/ Part 8: Stack unwinding https://blog.tartanllama.xyz/writing-a-linux-debugger-unwinding/ Part 9: Handling variables https://blog.tartanllama.xyz/writing-a-linux-debugger-variables/ Part 10: Advanced topics https://blog.tartanllama.xyz/writing-a-linux-debugger-advanced-topics/ ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

💡 Топ-15 строительных блоков системного дизайна, которые стоит знать: 1. Балансировщик нагрузки (Load Balancer): Распределяет входящий трафик между несколькими серверами, предотвращая перегрузку одного из них. Повышает доступность, устойчивость к сбоям и уменьшает время отклика. 2. API-шлюз (API Gateway): Единая точка входа для всех клиентских запросов в архитектуре микросервисов. Обрабатывает маршрутизацию, аутентификацию, ограничение частоты запросов и агрегацию данных. 3. DNS (Система доменных имён): Преобразует читаемые доменные имена в IP-адреса. 4. Кэш (Cache): Хранит часто запрашиваемые данные в памяти. Существенно снижает задержки и нагрузку на базу данных. 5. CDN (Сеть доставки контента): Доставляет статический контент (изображения, CSS, JS и т.п.) с серверов, расположенных ближе к пользователю. Снижает задержки и расход трафика, особенно на глобальном уровне. 6. База данных (Database): Основное хранилище данных. Может быть SQL или NoSQL в зависимости от требований. Поддерживает запросы, индексацию, транзакции и надёжность. 7. API (Программные интерфейсы): Определяют, как сервисы взаимодействуют между собой, часто через HTTP или gRPC. Обеспечивают модульность и чёткое разделение ответственности. 8. Микросервисы (Microservices): Разделяют монолитное приложение на независимо развёртываемые сервисы. Повышают гибкость, изоляцию ошибок и масштабируемость. 9. Ограничитель запросов (Rate Limiter): Контролирует количество запросов от пользователя или сервиса в заданный период. Защищает API от злоупотреблений и обеспечивает справедливость. 10. Объектное хранилище (Object Storage): Хранит большие бинарные объекты (изображения, видео, резервные копии) с высокой доступностью и надёжностью. Примеры — AWS S3, Google Cloud Storage и др. 11. Очередь сообщений (Message Queue): Обеспечивает асинхронную коммуникацию между сервисами через очередь (например, Kafka, RabbitMQ). Позволяет слабо связать компоненты и справляться с пиками нагрузки. 12. Шардинг (Sharding): Разделение больших объёмов данных между несколькими базами или таблицами. Обеспечивает масштабирование и повышение производительности запросов. 13. Репликация (Replication): Копирование данных между узлами базы данных. Повышает отказоустойчивость и производительность чтения. 14. Консистентное хеширование (Consistent Hashing): Метод распределения данных между узлами с минимальными изменениями при масштабировании. Часто используется в кэшировании и распределённых хранилищах. 15. Система мониторинга (Monitoring System): Отслеживает состояние системы, собирает логи и метрики, отправляет оповещения при сбоях или аномалиях. Критически важна для наблюдаемости, отладки и обеспечения доступности. ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

🚀 Как улучшить производительность API? Оптимизация API — ключ к быстрой и стабильной работе приложений. Вот 5 проверенных техник: 1️⃣ Пагинация (Pagination) Разбиваем большой объем данных на страницы. 🔹 Уменьшает нагрузку 🔹 Позволяет обрабатывать большие выборки 2️⃣ Асинхронное логирование (Async Logging) Сохраняем логи в буфер, а затем на диск. 🔹 Меньше задержек 🔹 Выше пропускная способность 3️⃣ Кэширование (Caching) Часто используемые данные храним в кэше, а не в БД. 🔹 Быстрый доступ 🔹 Меньше запросов к базе данных 4️⃣ Сжатие данных (Payload Compression) Сжимаем запросы и ответы. 🔹 Уменьшение объема трафика 🔹 Быстрая загрузка/выгрузка 5️⃣ Пул соединений (Connection Pool) Повторно используем открытые соединения с БД. 🔹 Снижение накладных расходов 🔹 Повышение эффективности 📌 Используй эти подходы, чтобы ускорить свой API и улучшить пользовательский опыт. ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

В чём разница между аутентификацией на сессиях и JWT? Многие разработчики не знают об этом различии, хотя оно критически важно. Большинство веб-приложений используют один из двух подходов к аутентификации: сессии (где состояние хранится на сервере) или JWT (где состояние передаётся вместе с клиентом). 1. Аутентификация на основе сессий Когда пользователь входит в систему, бэкенд генерирует случайный session ID, сохраняет его в кэше или базе данных и устанавливает этот ID как HttpOnly cookie в браузере. При каждом запросе браузер отправляет cookie, сервер находит соответствующую запись и восстанавливает пользовательский контекст. Такой подход: • сохраняет чувствительные данные на сервере; • позволяет мгновенно завершить сессию удалением записи. Преимущества сессий: • 🔹 Мгновенная деактивация доступа (“выйти отовсюду”) - одной строкой: просто удалить запись из Redis или SQL. • 🔹 Секреты никогда не покидают сервер, что снижает риск утечки. • 🔹 Отлично подходит для малых и средних систем, где кэш - не узкое место. Но: при горизонтальном масштабировании понадобятся «липкие» сессии или реплицированный кэш, что добавляет задержки и усложняет инфраструктуру. 2. Аутентификация с помощью JWT (JSON Web Token) После входа сервер подписывает JWT, содержащий: • заголовок (например, alg, typ), • полезную нагрузку (claims - sub, role и т.д.), • цифровую подпись. JWT - это просто base64-строка (не шифрованная): любой может прочитать данные, но подделать их может только владелец секрета. Сервер не хранит состояние - любой узел может локально проверить подпись и доверять данным. Преимущества JWT: • 🔸 Беспамятный (stateless): не требует общего хранилища, подходит для микросервисов и edge-нод. • 🔸 Удобен для SPA и мобильных приложений, напрямую работающих с бэкендами. • 🔸 Лёгкий: помещается в заголовок Authorization или cookie. Минус: JWT нельзя отозвать после выдачи - он действителен до истечения срока, так что «экстренный выход» или блокировка аккаунта требуют дополнительной логики. Вывод: • Если главное - возможность немедленно отозвать доступ, выбирай сессии. • Если нужна масштабируемость без состояния, выбирай JWT, но помни, что токены нельзя «забрать обратно» после их выдачи. ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

Работодатели давно играют в волков. Просто теперь соискатели научились отвечать Сейчас много говорят о «соискателях-волках». Это кандидаты, которые приукрашивают опыт, одновременно работают в нескольких компаниях, регулярно ходят по собеседованиям, принимают оффер и продолжают искать условия получше. Они легко увольняются, не испытывают особой преданности работодателю и рассматривают компанию прежде всего как источник дохода. О них пишут статьи, снимают видео и предупреждают HR-специалистов. Нам объясняют, что так нельзя, что это разрушает доверие и что хорошие трудовые отношения должны строиться на честности. Мысль разумная. Только есть небольшая проблема: работодатели начали играть в эту игру гораздо раньше. https://habr.com/ru/articles/1054232/ ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

Как работает Git? Для начала важно понять, где хранится наш код. Обычно предполагается, что существует только два места: удалённый сервер (например, GitHub) и локальный компьютер. Однако это не совсем так. Git использует три локальных хранилища на нашем компьютере, а значит, наш код может находиться в четырёх местах: • Рабочая директория (Working directory): место, где мы редактируем файлы. • Область подготовки (Staging area): временное место, где файлы находятся перед коммитом. • Локальный репозиторий (Local repository): содержит закоммиченный код. • Удалённый репозиторий (Remote repository): сервер, где хранится код (например, GitHub). Большинство команд Git в основном перемещают файлы между этими четырьмя локациями. Теперь вопрос к тебе: знаешь ли ты, с каким хранилищем работает команда git tag? Эта команда позволяет добавлять аннотации к коммиту. ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

🚀 Регулярные выражения (RegEx) в Linux: Полная шпаргалка Сохраняйте в избранное, чтобы всегда было под рукой при работе с grep, sed, awk или при написании Bash-скриптов! 📌 🧩 Базовые символы (Matching Characters) • . — Любой символ (кроме переноса строки) • \w — Буквенно-цифровой символ + подчеркивание • \W — Любой НЕ буквенно-цифровой символ • \d — Любая цифра (0-9) • \D — Любой символ, кроме цифры • \s — Пробельный символ (пробел, таб, перенос) • \S — Непробельный символ ⚓️ Якоря (Anchors) • ^ — Начало строки • $ — Конец строки • \b — Граница слова • \B — Не граница слова 🧮 Квантификаторы (Quantifiers) • * — 0 или более вхождений • + — 1 или более вхождений • ? — 0 или 1 вхождение • {n} — Ровно n вхождений • {n,} — n или более вхождений 👻 Жадные vs Ленивые (Greedy vs Lazy) • * — Жадный (захватывает как можно больше символов) • *? — Ленивый (захватывает как можно меньше символов) • +?, ??, {n}? — Ленивые версии остальных квантификаторов 🗂 Классы символов (Character Classes) • [abc] — Любой символ из списка: a, b или c • [^abc] — Любой символ, КРОМЕ a, b или c • [a-z] — Любая буква в диапазоне от a до z • [0-9] — Любая цифра от 0 до 9 📦 Группы и Диапазоны (Groups and Ranges) • (abc) — Захватывающая группа (сохраняет совпадение) • (?:abc) — Незахватывающая группа (ищет, но не сохраняет) • | — Логическое ИЛИ (например, cat|dog) • \1, \2, \3 — Ссылки на 1-ю, 2-ю, 3-ю захваченные группы 🚩 Флаги / Модификаторы (Flags) • g — Глобальный (ищет все совпадения, а не только первое) • i — Игнорировать регистр (A = a) • m — Многострочный (^ и $ работают для каждой строки текста) • s — Dotall (позволяет точке . совпадать с переносами строк) • x — Extended (позволяет использовать пробелы и комментарии в самом RegEx) 🛡 Экранирование (Escaping) • \ — Используется для экранирования спецсимволов, чтобы искать их буквально. • Символы, которые нужно экранировать: [ \ ^ $ . | ? * + ( ) { } 👀 Опережающие и ретроспективные проверки (Lookarounds) • (?=abc) — Позитивный lookahead (совпадает, если дальше идет abc) • (?!abc) — Негативный lookahead (совпадает, если дальше НЕ идет abc) • (?<=abc) — Позитивный lookbehind (совпадает, если перед ним идет abc) 🌐 Свойства Unicode (работают с флагом u) • \p{L} — Любая буква из любого языка • \p{N} — Любой числовой символ • \p{Sc} — Любой символ валюты ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg

🌦 Weathr - погода прямо в терминале Если ты живёшь в консоли, то это маст-хэв: weathr рисует живую погоду в виде ASCII-анимаций - дождь, снег, грозы, смена дня/ночи и даже пролетающие самолётики. Данные тянет из Open-Meteo. Что умеет: 🔴realtime-погода + атмосферные ASCII-анимации 🔴автоопределение локации (по IP) или ручные координаты в конфиге 🔴гибкие единицы измерения (metric/imperial) 🔴режим симуляции погоды для теста (--simulate rain/snow/thunderstorm/...) Установка (самый простой вариант): cargo install weathr Про приватность: авто-локация делает запрос к ipinfo.io, но это опционально - можно отключить и указать координаты вручную. ⭐️ Репозиторий: GitHub https://github.com/Veirt/weathr ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @itmozg