METANIT.COM

Как двоичные данные транслируются в инструкции ассемблера

В Чёрную пятницу — 1 ТБ в Облаке Mail от 99 ₽ в месяц Подключите подписку Mail Space на год, а платите как за 9 месяцев. С подпиской вы получите бесконечное место в Облаке Mail для ваших фото и видео с телефона и 1 ТБ для всего остального — всего от 99 ₽ в месяц. Перейти на сайт #реклама 16+ cloud.mail.ru О рекламодателе

Стратегии работы с базами данных (продолжение предыдущего поста) 1. Когда нагрузка на чтение и запись высокая (сбалансированная нагрузка): * Используйте основную базу данных для всех операций записи. * Передавайте интенсивный трафик чтения на несколько реплик для чтения через асинхронную репликацию. * Применяйте кэш Redis для обработки «горячих» ключей и снижения нагрузки на базу данных. * Учитывайте, что иногда могут возникать промахи кэша (cache miss) — в таких случаях обращение будет перенаправлено к основной базе данных. * Группируйте операции записи и оптимизируйте индексы, чтобы поддерживать стабильную производительность. 2. Когда нагрузка на запись постоянно растёт: * Разделите базу данных на шарды (сегменты). * Каждый шард хранит часть набора данных, благодаря чему операции записи распределяются. * Ваше приложение должно уметь направлять запросы к нужному шарду. * Подходит для масштабного развёртывания, но может быть сложным при выполнении комплексных запросов или транзакций между шардами. 3. Когда требуется гибридная масштабируемость (NewSQL): * Системы вроде CockroachDB работают как SQL, но масштабируются как NoSQL. * Встроенные функции автоматического шардирования и перераспределения нагрузки избавляют от необходимости вручную управлять шардами. * Обеспечивается глобальная согласованность данных между узлами. * Подходит для мультирегиональных приложений, где важны строгая согласованность и отказоустойчивость. 4. Когда требуются операции с высокой степенью надёжности (финансовые операции): * Система разрабатывается специально для эконом. операций, например, бухгалтерского учёта, платежей... * Очень высокая скорость работы, устойчивость к сбоям и подход, основанный на формальной верификации. * В первую очередь обеспечивается корректность — предотвращаются двойные списания, условия гонки и частичные записи. * Идеально подходит для операций с деньгами, когда каждая транзакция должна быть точной, надёжной и безопасной.

Стратегии работы с базами данных (продолжение в следующем посте)

Линус Торвальдс о резервном копировании данных: «Только слабаки используют резервное копирование на ленту: настоящие мужчины просто загружают свои важные данные на FTP, и пусть остальной мир их копирует" - Линус Торвальдс, 1996 г., LKML (Оригинал: "Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it") «Мой подход к хранению данных таков: я загружаю их в интернет, и если они стоят того, чтобы их сохранить, кто-то другой сохранит их для меня». — Линус Торвальдс, 2025 г., Linus Tech Tips (Оригинал: "My data storage approach is: I upload it to the internet, and if it's worth saving, somebody else will save it for me.")

Новый выгодный тариф "Первый мобильный" от Ростелекома. В него включено только самое нужное: 100 ГБ, 1000 минут и 1000 SMS всего за 300 рублей в месяц. Стоимость фиксируется до конца 2027 года, а номер останется с вами навсегда. Подключайтесь онлайн с бесплатной доставкой SIM-карты. Подать заявку #реклама rt.ru О рекламодателе

Вкратце про математические деревья

Механизмы авторизации API (продолжение к предыдущему посту) Контроль разрешений пользователей в современных API 1. Управление доступом на основе ролей (RBAC, Role‑Based Access Control) → Определение ✓ Назначает разрешения на основе роли пользователя (администратор, редактор, зритель). → Как это работает ✓ Пользователи → Назначенные роли → Роли → Предоставление разрешений. → Оптимально для ✓ Систем с чётко определёнными группами разрешений. ✓ Панелей управления, SaaS‑приложений, CMS‑платформ. 2. Управление доступом на основе атрибутов (ABAC, Attribute‑Based Access Control) → Определение ✓ Принимает решения об авторизации на основе атрибутов. → Атрибуты включают ✓ Атрибуты пользователя (возраст, отдел, подписка). ✓ Атрибуты ресурса (тип, владелец). ✓ Атрибуты среды (время, местоположение). → Оптимально для ✓ Предприятий с сложными и динамическими правилами доступа. 3. Фреймворк авторизации OAuth 2.0 → Определение ✓ Делегированная авторизация, которая позволяет сторонним приложениям получать доступ к ресурсам без раскрытия паролей пользователей. → Как это работает ✓ Аутентификация через провайдера → Выдача токена доступа → API проверяет токен. → Распространённые потоки ✓ Код авторизации (Authorization Code). ✓ Учётные данные клиента (Client Credentials). ✓ Потолок для устройств (Device Flow). → Оптимально для ✓ Приложений, требующих входа через соцсети или безопасного делегированного доступа. 4. OpenID Connect (OIDC) → Определение ✓ Уровень идентификации, построенный на базе OAuth 2.0. ✓ Добавляет проверку личности пользователя с помощью ID‑токенов. → Что предоставляет ✓ Проверенную идентификацию. ✓ Единый вход (SSO, Single Sign‑On). ✓ Стандартные утверждения (имя, электронная почта и т. д.). → Оптимально для ✓ Систем аутентификации и авторизации. 5. Авторизация с помощью JSON‑веб‑токенов (JWT, JSON Web Token) → Определение ✓ Авторизация осуществляется с помощью подписанных JSON‑токенов. → Как это работает ✓ Пользователь входит в систему → Сервер выдаёт JWT, содержащий утверждения → Клиент отправляет токен с каждым запросом. → Преимущества ✓ Отсутствие состояния (stateless). ✓ Идеально для распределённых микросервисов. → Оптимально для ✓ Мобильных приложений, одностраничных приложений (SPA), современных REST API. 6. Управление доступом на основе политик (PBAC, Policy‑Based Access Control) → Определение ✓ Решения о доступе принимаются с использованием централизованных политик. → Как это работает ✓ Механизм политик проверяет правила → Разрешает или отклоняет запрос. → Оптимально для ✓ Государственных систем. ✓ Среды с жёсткими требованиями соответствия. 7. Списки контроля доступа (ACL, Access Control Lists) → Определение ✓ Разрешения настраиваются непосредственно для каждого ресурса. → Как это работает ✓ Ресурс содержит список разрешённых пользователей и действий. → Оптимально для ✓ Файловых систем. ✓ Моделей безопасности на уровне ресурсов. Краткое резюме ✓ RBAC → На основе ролей. ✓ ABAC → На основе атрибутов. ✓ OAuth 2.0 → Делегированный доступ. ✓ OIDC → Уровень идентификации. ✓ JWT → Без состояния, на основе токенов. ✓ PBAC → На основе политик. ✓ ACL → На уровне ресурсов.

Механизмы авторизации API (продолжение в следующем посте)

IT — не латте, смузи и гироскутер, а вызовы и амбиции VK показывает, чем занимаются её команды — от экспериментальных технологий до VK Fest. Переходите по ссылке: смотрите ролики, читайте про проекты и тут же откликайтесь на вакансию, которая по вкусу! Перейти на сайт #реклама 16+ vkteam.ru О рекламодателе

Линус Торвальдс и Линус Себастьян из Linus Tech Tips провели сборку идеального ПК для Linux Для создания мощной рабочей системы Линусы выбрали: - процессор CPU AMD Ryzen Threadripper 9960X с 24 ядрами и 48 потоками; - ОЗУ Kingston 16 ГБ DDR5 х4; - видеокарту Intel Arc B580; - материнскую плату GIGABYTE TRX50 AERO D; - SSD-накопитель Samsung 9100 PRO 2TB; - кулер Noctua NH-U14S TR5-SP6; - блок питания Seasonic PRIME TX-1600 1600W 80+ Titanium; - системный блок Fractal Design Torrent E-ATX Case; - 31.5-дюймовый монитор Asus ProArt PA32QCV (6K HDR). Всю сборку выполнил Линус Себастьян, а Торвальдс только пояснял, какие элементы ему больше нравятся (воздушное охлаждение, ECC-память). https://youtu.be/mfv0V1SxbNA https://linustechtips.com/topic/1627666-building-the-perfect-linux-pc-with-linus-torvalds/

Известный исследователь в области искуственного интеллекта Ян Лекун (Yann LeCun) утверждает, что модели LLM сами по себе не являются пузырем ни в плане стоимости, ни в плане инвестиций — они будут способствовать развитию множества реальных приложений и оправдывать текущие расходы на инфраструктуру. Настоящий пузырь же кроется в предположении, что модели LLM смогут мыслить на уровне человека.

Вкратце структура ядра Linux #linux

Глава Alphabet Сундар Пичаи сравнил вайб-кодинг с ростом популярности блогов и YouTube, но предупредил, что явление не должно затрагивать критически важные системы. Гендиректор Google рассказал о резком росте числа вайб-кодеров, но предупредил, что продукт их работы не подходит для крупных кодовых баз, критически важных с точки зрения безопасности. Пичаи отметил, что инструменты, основанные на больших языковых моделях, делают программирование «более приятным» и «доступным», поскольку люди могут тестировать идеи для приложений и веб-сайтов, не разбираясь сначала в синтаксисе или фреймворках. По его словам, этот сдвиг уже заметен в репозиториях Google. В то же время глава Google подчеркнул, что не применяет вайб-кодинг к обширным кодовым базам, «где действительно нужно сделать всё правильно». https://www.techspot.com/news/110434-google-ceo-vibe-coding-reshaping-who-gets-write.html

Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC) (продолжение предыдущего поста) → MVC разделяет приложение на три основных компонента для разграничения ответственностей и повышения удобства сопровождения: Модель, Представление и Контроллер. → Представление отвечает за отображение, Контроллер — за обработку ввода и управление потоком, Модель — за данные и бизнес‑правила. Компоненты → Представление (UI) → Отображает данные и обрабатывает взаимодействия пользователя (веб‑страницы, экраны мобильных приложений). → Контроллер → Получает ввод от Представления, интерпретирует его, вызывает Модель или обновляет Представление. → Модель → Содержит данные приложения и бизнес‑логику; уведомляет Представление об изменениях состояния. → База данных / Хранилище → Постоянное хранилище, из которого Модель считывает данные и в которое записывает их. Поток данных (упрощённо) → Представление —(ввод пользователя)→ Контроллер —(вызывает)→ Модель —(считывает/записывает)→ База данных → Модель —(уведомляет)→ Представление —(отображает обновлённые данные)→ Пользователь Преимущества → Чёткое разделение ответственностей → упрощение тестирования и параллельной разработки. → Повторное использование компонентов — несколько Представлений могут использовать одну и ту же Модель. → Более чёткая организация логики интерфейса по сравнению с бизнес‑логикой. Недостатки → Может стать избыточным при большом количестве контроллеров/представлений в крупных приложениях. → Возможна тесная связность, если ответственности не разделены чётко. → Не всегда оптимально подходит для высокоинтерактивных клиентских интерфейсов без адаптации (например, MVVM или Flux могут быть предпочтительнее). Распространенные рекомендации по использованию → Делайте Контроллеры «лёгкими» — делегируйте бизнес‑логику Моделям или сервисам. → Представления без бизнес-логики только для отображения данных и передачи событий → Применение шаблона Наблюдатель (observer) или привязки данных, чтобы Представления автоматически обновлялись при изменении Модели. → Отедбные юнит‑тесты для Моделей и Контроллеров → В крупных проектах организуйте код по функциональным возможностям, а не только по уровням MVC.

Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC) (описание в следующем посте)

Вопрос дня

Вкратце об уровнях сетевой модели OSI (продолжение предыдущего поста) 🔌 Уровень 1 — Физический (Physical) Передаёт необработанные биты по физическим каналам связи. Протоколы: 10BASE‑T, DSL, ISDN, USB, RS‑232, SONET/SDH. Устройства: кабели, концентраторы (hubs), повторители (repeaters). 🔗 Уровень 2 — Канальный (Data Link) Обеспечивает передачу данных между узлами, MAC‑адресацию и формирование кадров. Протоколы: Ethernet, PPP, STP, VLAN, LLDP. Устройства: коммутаторы (switches), мосты (bridges). 🗺 Уровень 3 — Сетевой (Network) Отвечает за маршрутизацию и логическую адресацию. Протоколы: IPv4/IPv6, OSPF, EIGRP, RIP, MPLS, ICMP, NAT. Устройства: маршрутизаторы (routers), коммутаторы L3 (L3 switches). ⚙️ Уровень 4 — Транспортный (Transport) Гарантирует надёжную сквозную передачу данных. Протоколы: TCP, UDP, SCTP, DCCP. Ключевые элементы: порты, сегментация, управление потоком (flow control). 📊 Уровень 5 — Сеансовый (Session) Устанавливает, поддерживает и завершает сеансы связи. Протоколы: SIP, SMB, RPC, PPTP, TLS. Ключевые элементы: аутентификация, управление сеансами. 🎛 Уровень 6 — Представительный (Presentation) Форматирует и преобразует данные для приложений. Функции: шифрование, сжатие, кодирование данных. Примеры: шифрование SSL/TLS, JPEG, MP3, ASCII, JSON. 🎨 Уровень 7 — Прикладной (Application) Предоставляет сервисы непосредственно пользовательским приложениям. Протоколы: HTTP/S, DNS, DHCP, SSH, SMTP, FTP, SNMP. Примеры использования: просмотр веб‑страниц, электронная почта, передача файлов.

Сетевые протоколы, которые работают на разных уровнях сетевой модели OSI (описание в следующем посте)

Курс по дизайну от ТОП3 дизайн студии с наставником Забирай бесплатно 🎓 6 кейсов в Figma с нуля: граф,веб,UX/UI дизайн 📊 Готовое Reels Портфолио: сайты, карточки МП, баннеры, презентации 💰 Алгоритм заработка на дизайне: без фриланс-бирж и продаж ✨ В конце: розыгрыш AirPods Попробовать #реклама 16+ study.logomachine.ru О рекламодателе