Бывший главный тренер футбольного клуба «Сочи» испанец Роберт Морено тренировал команду по советам и стратегии от ChatGPT, заявил бывший заместитель гендиректора клуба Андрей Орлов в интервью Sports.ru. При Морено «Сочи» занял последнее место в сезоне 2023/2024 Российской премьер‑лиги.
По словам Орлова, испанский тренер использовал нейросеть масштабно. В частности, Морено составил график выезда в Хабаровск с местным клубом «СКА‑Хабаровск». Помимо этого, ChatGPT посоветовал Морено, чтобы игроки не спали 28 часов перед матчем, а также вставали в пять утра.
Орлов утверждает, что Морено использовал нейросеть и для подбора игроков в состав. Тренер загрузил в ChatGPT данные нападающих Владимира Писарского, Павла Мелешина и Артура Шушеначева, и нейросеть назвала последним лучшим из этой тройки. В итоге Шушеначев провёл 10 игр за «Сочи», в которых не забил ни одного мяча.
https://www.sports.ru/football/1117049863-moreno-fanat-chatgpt-po-odnoj-prezentaczii-poluchalos-chto-pered-xabar.html
По словам Орлова, испанский тренер использовал нейросеть масштабно. В частности, Морено составил график выезда в Хабаровск с местным клубом «СКА‑Хабаровск». Помимо этого, ChatGPT посоветовал Морено, чтобы игроки не спали 28 часов перед матчем, а также вставали в пять утра.
Орлов утверждает, что Морено использовал нейросеть и для подбора игроков в состав. Тренер загрузил в ChatGPT данные нападающих Владимира Писарского, Павла Мелешина и Артура Шушеначева, и нейросеть назвала последним лучшим из этой тройки. В итоге Шушеначев провёл 10 игр за «Сочи», в которых не забил ни одного мяча.
https://www.sports.ru/football/1117049863-moreno-fanat-chatgpt-po-odnoj-prezentaczii-poluchalos-chto-pered-xabar.html
Спортс’’
«Морено – фанат ChatGPT. По одной его презентации получалось, что перед Хабаровском игроки не должны были спать 28 часов». Экс…
Бывший заместитель генерального директора «Сочи» Андрей Орлов рассказал, что экс-тренер клуба Роберт Морено регулярно обращался за помощью к чат-боту ChatGPT.
🤣46🤡12🎃3
20 ключевых концепций системного дизайна
(продолжение предыдущего поста)
1. Client-Server (Клиент-сервер)
Модель, в которой клиенты отправляют запросы, а серверы обрабатывают их и возвращают ответы. Основа большинства современных приложений.
2. DNS (Domain Name System, система доменных имён)
Преобразует доменные имена (например, some.site в IP-адреса (например, 192.168.1.42), позволяя устройствам находить друг друга в сети.
3. Scalability (Масштабируемость)
Способность системы справляться с увеличением нагрузки — например, ростом числа пользователей или объёма данных. Ключевой фактор для роста сервисов.
4. Load Balancing (Балансировка нагрузки)
Распределение входящего трафика между несколькими серверами для оптимизации ресурсов, повышения доступности и предотвращения перегрузки отдельных узлов.
5. APIs (Application Programming Interfaces, программные интерфейсы приложений)
Механизмы, позволяющие клиентам и серверам обмениваться данными и функциями. Обеспечивают взаимодействие между разными системами и сервисами.
6. API Gateway (Шлюз API)
Центральный вход для всех клиентских запросов к сервисам. Упрощает управление доступом, аутентификацию и маршрутизацию запросов.
7. Microservices (Микросервисы)
Архитектура, разбивающая монолитное приложение на независимые сервисы, которые взаимодействуют через API. Упрощает разработку, масштабирование и поддержку.
8. Databases (Базы данных)
Системы для эффективного хранения и извлечения данных. Ключевой компонент для управления информацией в приложениях.
9. Caching (Кэширование)
Сохранение часто используемых данных в быстродоступном хранилище (кэше) для снижения нагрузки на базу данных и уменьшения задержек (latency).
10. Indexing (Индексирование)
Создание структур данных (индексов) для ускорения поиска информации в базе данных. Оптимизирует выполнение запросов.
11. Replication (Репликация)
Создание копий (реплик) данных на нескольких серверах. Повышает доступность и устойчивость к отказам (fault tolerance).
12. Sharding (Шардирование)
Разделение данных на части (шарды) и распределение их по разным базам данных или серверам. Позволяет масштабировать хранилища данных.
13. Object Storage (Хранилище объектов)
Система для хранения больших объектов — изображений, видео, файлов. Обеспечивает высокую доступность и масштабируемость (например, Amazon S3).
14. CDN (Content Delivery Network, сеть доставки контента)
Распределённая сеть серверов, доставляющая статический контент (изображения, CSS, JS) пользователям с ближайших узлов. Снижает задержки и нагрузку на основной сервер.
15. CAP Theorem (Теорема CAP)
Формулирует компромисс между тремя свойствами распределённых систем: согласованностью (consistency), доступностью (availability) и разделённой устойчивостью (partition tolerance). Можно одновременно гарантировать только два из трёх.
16. Consistent Hashing (Согласованное хеширование)
Алгоритм распределения данных по узлам с минимизацией перераспределения при изменении числа узлов. Эффективен для кэширования и шардирования.
17. Message Queues (Очереди сообщений)
Механизм асинхронного обмена сообщениями между компонентами системы. Позволяет обрабатывать задачи в фоновом режиме, снижает нагрузку на сервисы.
18. Rate Limiting (Ограничение частоты запросов)
Контроль количества запросов от клиентов за определённый период. Защищает сервисы от перегрузки и злоупотреблений (например, DDoS-атак).
19. WebSockets (Веб-сокеты)
Протокол для двунаправленной коммуникации в реальном времени между клиентом и сервером. Используется в чатах, играх, биржевых системах.
20. Monitoring (Мониторинг)
Отслеживание состояния и производительности системы — сбор метрик, логирование, оповещение об ошибках. Ключевой инструмент для обеспечения стабильности и быстрого устранения проблем.
(продолжение предыдущего поста)
1. Client-Server (Клиент-сервер)
Модель, в которой клиенты отправляют запросы, а серверы обрабатывают их и возвращают ответы. Основа большинства современных приложений.
2. DNS (Domain Name System, система доменных имён)
Преобразует доменные имена (например, some.site в IP-адреса (например, 192.168.1.42), позволяя устройствам находить друг друга в сети.
3. Scalability (Масштабируемость)
Способность системы справляться с увеличением нагрузки — например, ростом числа пользователей или объёма данных. Ключевой фактор для роста сервисов.
4. Load Balancing (Балансировка нагрузки)
Распределение входящего трафика между несколькими серверами для оптимизации ресурсов, повышения доступности и предотвращения перегрузки отдельных узлов.
5. APIs (Application Programming Interfaces, программные интерфейсы приложений)
Механизмы, позволяющие клиентам и серверам обмениваться данными и функциями. Обеспечивают взаимодействие между разными системами и сервисами.
6. API Gateway (Шлюз API)
Центральный вход для всех клиентских запросов к сервисам. Упрощает управление доступом, аутентификацию и маршрутизацию запросов.
7. Microservices (Микросервисы)
Архитектура, разбивающая монолитное приложение на независимые сервисы, которые взаимодействуют через API. Упрощает разработку, масштабирование и поддержку.
8. Databases (Базы данных)
Системы для эффективного хранения и извлечения данных. Ключевой компонент для управления информацией в приложениях.
9. Caching (Кэширование)
Сохранение часто используемых данных в быстродоступном хранилище (кэше) для снижения нагрузки на базу данных и уменьшения задержек (latency).
10. Indexing (Индексирование)
Создание структур данных (индексов) для ускорения поиска информации в базе данных. Оптимизирует выполнение запросов.
11. Replication (Репликация)
Создание копий (реплик) данных на нескольких серверах. Повышает доступность и устойчивость к отказам (fault tolerance).
12. Sharding (Шардирование)
Разделение данных на части (шарды) и распределение их по разным базам данных или серверам. Позволяет масштабировать хранилища данных.
13. Object Storage (Хранилище объектов)
Система для хранения больших объектов — изображений, видео, файлов. Обеспечивает высокую доступность и масштабируемость (например, Amazon S3).
14. CDN (Content Delivery Network, сеть доставки контента)
Распределённая сеть серверов, доставляющая статический контент (изображения, CSS, JS) пользователям с ближайших узлов. Снижает задержки и нагрузку на основной сервер.
15. CAP Theorem (Теорема CAP)
Формулирует компромисс между тремя свойствами распределённых систем: согласованностью (consistency), доступностью (availability) и разделённой устойчивостью (partition tolerance). Можно одновременно гарантировать только два из трёх.
16. Consistent Hashing (Согласованное хеширование)
Алгоритм распределения данных по узлам с минимизацией перераспределения при изменении числа узлов. Эффективен для кэширования и шардирования.
17. Message Queues (Очереди сообщений)
Механизм асинхронного обмена сообщениями между компонентами системы. Позволяет обрабатывать задачи в фоновом режиме, снижает нагрузку на сервисы.
18. Rate Limiting (Ограничение частоты запросов)
Контроль количества запросов от клиентов за определённый период. Защищает сервисы от перегрузки и злоупотреблений (например, DDoS-атак).
19. WebSockets (Веб-сокеты)
Протокол для двунаправленной коммуникации в реальном времени между клиентом и сервером. Используется в чатах, играх, биржевых системах.
20. Monitoring (Мониторинг)
Отслеживание состояния и производительности системы — сбор метрик, логирование, оповещение об ошибках. Ключевой инструмент для обеспечения стабильности и быстрого устранения проблем.
Telegram
METANIT.COM
20 ключевых концепций системного дизайна
(продолжение в следующем посте)
(продолжение в следующем посте)
🔥9❤4👍4
В комитете Госдумы РФ опровергли СМИ факт использования нейросети ChatGPT при написании законопроекта № 1126815-8.
Ранее СМИ сообщили, что в пояснительной записке к законопроекту в сноске используется ссылка на результаты опроса проекта «Пульс НКО» с UTM‑меткой source=chatgpt․com. Обычно такие метки появляются в ссылках, взятых из чата в ChatGPT. Также существует вероятность, что кто‑то дописал фрагмент source=chatgpt․com вручную. Эта пояснительная записка была опубликована на сайте Госдумы 21 января 2026 года.
«Материалы к законопроекту готовились на протяжении двух лет исключительно депутатами с командой юристов аппарата комитета. Сама пояснительная записка написана человеком, что подтверждает анализ рекомендованным к использованию в государственных органах российским ИИ‑ассистентом GigaChat. А написание законопроекта является настолько сложным и профессиональным делом, что ИИ с этим не сможет справиться в принципе», — указали в пресс‑службе Госдумы РФ.
В комитете Госдумы РФ отметили, что в пояснительной записке (которая не является частью законопроекта) действительно есть ссылка на исследование с UTM‑меткой из ИИ‑ассистента. «[Это] вызвано тем, что сотрудник аппарата комитета, работающий с пояснительной запиской, использовал ИИ как инструмент для быстрого поиска только источника самого исследования. Само исследование и данные корректные, источник существует, и информация подтверждена», — пояснили в пресс‑службе Госдумы РФ.
https://tass.ru/politika/26240293
Ранее СМИ сообщили, что в пояснительной записке к законопроекту в сноске используется ссылка на результаты опроса проекта «Пульс НКО» с UTM‑меткой source=chatgpt․com. Обычно такие метки появляются в ссылках, взятых из чата в ChatGPT. Также существует вероятность, что кто‑то дописал фрагмент source=chatgpt․com вручную. Эта пояснительная записка была опубликована на сайте Госдумы 21 января 2026 года.
«Материалы к законопроекту готовились на протяжении двух лет исключительно депутатами с командой юристов аппарата комитета. Сама пояснительная записка написана человеком, что подтверждает анализ рекомендованным к использованию в государственных органах российским ИИ‑ассистентом GigaChat. А написание законопроекта является настолько сложным и профессиональным делом, что ИИ с этим не сможет справиться в принципе», — указали в пресс‑службе Госдумы РФ.
В комитете Госдумы РФ отметили, что в пояснительной записке (которая не является частью законопроекта) действительно есть ссылка на исследование с UTM‑меткой из ИИ‑ассистента. «[Это] вызвано тем, что сотрудник аппарата комитета, работающий с пояснительной запиской, использовал ИИ как инструмент для быстрого поиска только источника самого исследования. Само исследование и данные корректные, источник существует, и информация подтверждена», — пояснили в пресс‑службе Госдумы РФ.
https://tass.ru/politika/26240293
TACC
В комитете ГД опровергли использование ChatGPT при написании законопроекта
Материалы к законопроекту готовились на протяжении двух лет исключительно депутатами с командой юристов аппарата комитета Госдумы по молодежной политике
🤡52😁13🤣11👌4❤1
Инженеры OpenAI опубликовали статью о том, как PostgreSQL обслуживает ChatGPT — сервис с 800-900 миллионами активных пользователей в неделю.
Главная особенность: компания обходится без шардирования, используя архитектуру с одним основным сервером и примерно 50 репликами для чтения, поскольку в OpenAI решили, что для нагрузки ChatGPT с преобладанием чтения лучше использовать один кластер, чем создавать распределенную архитектуру.
Кластер обрабатывает более миллиона запросов в секунду, обеспечивая время отклика в низкие двузначные миллисекунды на 99-м перцентиле. Все это — на стандартном PostgreSQL без кастомных модификаций, только с грамотной настройкой пулинга соединений, оптимизацией запросов и продуманной индексацией.
Узкое место архитектуры — запись. Все операции записи идут в единственный основной сервер, поэтому команда жестко оптимизирует эту часть: выносят записи куда возможно, сглаживают пики через отложенную запись, контролируют скорость массовой загрузки данных. Изменения схемы тоже под строгим контролем — добавление колонок только с таймаутом 5 секунд, индексы исключительно через CONCURRENTLY, никаких операций с перезаписью таблицы.
Чтение масштабируется проще — реплики распределены по разным регионам, а трафик разделен по приоритетам: для критичных запросов выделены отдельные реплики, чтобы их не тормозили тяжелые аналитические выборки. Результат — за последние девять месяцев только один серьезный инцидент, связанный с PostgreSQL.
https://openai.com/index/scaling-postgresql/
Главная особенность: компания обходится без шардирования, используя архитектуру с одним основным сервером и примерно 50 репликами для чтения, поскольку в OpenAI решили, что для нагрузки ChatGPT с преобладанием чтения лучше использовать один кластер, чем создавать распределенную архитектуру.
Кластер обрабатывает более миллиона запросов в секунду, обеспечивая время отклика в низкие двузначные миллисекунды на 99-м перцентиле. Все это — на стандартном PostgreSQL без кастомных модификаций, только с грамотной настройкой пулинга соединений, оптимизацией запросов и продуманной индексацией.
Узкое место архитектуры — запись. Все операции записи идут в единственный основной сервер, поэтому команда жестко оптимизирует эту часть: выносят записи куда возможно, сглаживают пики через отложенную запись, контролируют скорость массовой загрузки данных. Изменения схемы тоже под строгим контролем — добавление колонок только с таймаутом 5 секунд, индексы исключительно через CONCURRENTLY, никаких операций с перезаписью таблицы.
Чтение масштабируется проще — реплики распределены по разным регионам, а трафик разделен по приоритетам: для критичных запросов выделены отдельные реплики, чтобы их не тормозили тяжелые аналитические выборки. Результат — за последние девять месяцев только один серьезный инцидент, связанный с PostgreSQL.
https://openai.com/index/scaling-postgresql/
Openai
Scaling PostgreSQL to power 800 million ChatGPT users
An inside look at how OpenAI scaled PostgreSQL to millions of queries per second using replicas, caching, rate limiting, and workload isolation.
👏36🔥12👍8❤1🖕1
Разница между Encoding (Кодирование), Encryption (Шифрование) и Tokenization (Токенизация)
(продолжение в следующем посте)
(продолжение в следующем посте)
❤6👍4🔥2
Разница между Encoding (Кодирование), Encryption (Шифрование) и Tokenization (Токенизация)
(продолжение предыдущего поста)
#### 1. Encoding (Кодирование)
Суть: преобразование данных из одного формата в другой для удобства передачи или хранения, без защиты от несанкционированного доступа.
Как работает:
- Encoding: алгоритм преобразует «простой текст» (plain text) в закодированный текст (cipher text).
- Decoding: тот же или аналогичный алгоритм возвращает данные в исходный вид (из cipher text в plain text).
Ключевые особенности:
- Не обеспечивает конфиденциальность — закодированные данные легко обратимы.
- Используется для совместимости форматов (например, ASCII, Base64, Protobuf).
- Основная цель — преобразование, а не защита.
Примеры использования (Use Cases):
- кодировка ASCII и Base64 для передачи данных;
- Protocol Buffers (ProtoBuf) для сериализации данных.
#### 2. Encryption (Шифрование)
Суть: преобразование данных в нечитаемый формат с использованием криптографических алгоритмов для защиты конфиденциальности.
Как работает:
- Encryption: алгоритм с публичным ключом (public key) преобразует plain text в cipher text (зашифрованный текст).
- Decryption: алгоритм с приватным ключом (private key) возвращает cipher text в исходный plain text.
Ключевые особенности:
- Обеспечивает конфиденциальность данных.
- Использует сложные математические алгоритмы (например, RSA, AES).
- Без соответствующего ключа расшифровать данные практически невозможно.
- Применяется там, где важна защита информации.
Примеры использования (Use Cases):
- HTTPS для защищённой передачи данных в интернете;
- шифрование электронной почты (Email Encryption);
- защита кошельков в блокчейне (Blockchain Wallet).
#### 3. Tokenization (Токенизация)
Суть: замена чувствительных данных (например, номеров кредитных карт) на уникальный идентификатор — токен, который не несёт прямой ценности для злоумышленника.
Как работает:
1. Tokenization: сервис токенизации (TSP — Token Service Provider) получает чувствительные данные (например, PAN — Primary Account Number) и выдаёт взамен токен.
2. Look Up PAN: при необходимости оригинальные данные извлекаются из «хранилища» (PAN Vault) по токену.
3. Взаимодействие банков: токен используется в транзакциях, а реальный PAN хранится в защищённом месте (например, у эмитента карты).
Ключевые особенности:
- Не использует шифрование — данные заменяются, а не преобразуются.
- Токен не содержит информации о защищаемых данных и бесполезен без доступа к хранилищу.
- Снижает риски утечки конфиденциальной информации (например, при хранении или передаче).
- Соответствует стандартам безопасности (например, PCI DSS).
Примеры использования (Use Cases):
- токенизация номеров кредитных карт;
- обмен финансовыми данными (Financial Data Sharing);
- соблюдение стандартов PCI DSS для защиты платёжных данных.
### Краткое резюме:
- Encoding — преобразование данных для удобства, без защиты.
- Encryption — защита данных с помощью ключей, обратимое шифрование.
- Tokenization — замена чувствительных данных на токены, данные хранятся в защищённом месте.
(продолжение предыдущего поста)
#### 1. Encoding (Кодирование)
Суть: преобразование данных из одного формата в другой для удобства передачи или хранения, без защиты от несанкционированного доступа.
Как работает:
- Encoding: алгоритм преобразует «простой текст» (plain text) в закодированный текст (cipher text).
- Decoding: тот же или аналогичный алгоритм возвращает данные в исходный вид (из cipher text в plain text).
Ключевые особенности:
- Не обеспечивает конфиденциальность — закодированные данные легко обратимы.
- Используется для совместимости форматов (например, ASCII, Base64, Protobuf).
- Основная цель — преобразование, а не защита.
Примеры использования (Use Cases):
- кодировка ASCII и Base64 для передачи данных;
- Protocol Buffers (ProtoBuf) для сериализации данных.
#### 2. Encryption (Шифрование)
Суть: преобразование данных в нечитаемый формат с использованием криптографических алгоритмов для защиты конфиденциальности.
Как работает:
- Encryption: алгоритм с публичным ключом (public key) преобразует plain text в cipher text (зашифрованный текст).
- Decryption: алгоритм с приватным ключом (private key) возвращает cipher text в исходный plain text.
Ключевые особенности:
- Обеспечивает конфиденциальность данных.
- Использует сложные математические алгоритмы (например, RSA, AES).
- Без соответствующего ключа расшифровать данные практически невозможно.
- Применяется там, где важна защита информации.
Примеры использования (Use Cases):
- HTTPS для защищённой передачи данных в интернете;
- шифрование электронной почты (Email Encryption);
- защита кошельков в блокчейне (Blockchain Wallet).
#### 3. Tokenization (Токенизация)
Суть: замена чувствительных данных (например, номеров кредитных карт) на уникальный идентификатор — токен, который не несёт прямой ценности для злоумышленника.
Как работает:
1. Tokenization: сервис токенизации (TSP — Token Service Provider) получает чувствительные данные (например, PAN — Primary Account Number) и выдаёт взамен токен.
2. Look Up PAN: при необходимости оригинальные данные извлекаются из «хранилища» (PAN Vault) по токену.
3. Взаимодействие банков: токен используется в транзакциях, а реальный PAN хранится в защищённом месте (например, у эмитента карты).
Ключевые особенности:
- Не использует шифрование — данные заменяются, а не преобразуются.
- Токен не содержит информации о защищаемых данных и бесполезен без доступа к хранилищу.
- Снижает риски утечки конфиденциальной информации (например, при хранении или передаче).
- Соответствует стандартам безопасности (например, PCI DSS).
Примеры использования (Use Cases):
- токенизация номеров кредитных карт;
- обмен финансовыми данными (Financial Data Sharing);
- соблюдение стандартов PCI DSS для защиты платёжных данных.
### Краткое резюме:
- Encoding — преобразование данных для удобства, без защиты.
- Encryption — защита данных с помощью ключей, обратимое шифрование.
- Tokenization — замена чувствительных данных на токены, данные хранятся в защищённом месте.
Telegram
METANIT.COM
Разница между Encoding (Кодирование), Encryption (Шифрование) и Tokenization (Токенизация)
(продолжение в следующем посте)
(продолжение в следующем посте)
🔥8❤4👍3
Function chaning (цепочка вызовов) - какой стиль лучше
Anonymous Poll
9%
" hello world" |> trim |> upper
88%
" hello world".trim().upper()
3%
Другое
😁26👀10👎2
Каждый десятый разработчик в крупных IT-компаниях ничего не делает
Исследование учёных Стэнфордского университета показало, что каждый десятый разработчик в крупных IT-компаниях ничего не делает. Они проанализировали данные о производительности более 50 тысяч работников из сотен компаний.
Выяснилось, что 9,5% из них не выполняют никакой полезной работы, хотя и регулярно докладывают об успехах.
Для оценки эффективности программистов использовался специальный алгоритм. Кроме того, учёные изучили данные деловой соцсети LinkedIn. Они анализировали профили сотрудников, работающих в 13 крупнейших корпорациях, в том числе IBM, Microsoft, Oracle, Google, Amazon и других.
Оказалось, что многие программисты просто имитируют работу. Они могут вносить в код пару изменений в месяц, при этом минимально общаясь с коллегами и тратя на работу по 5 часов в неделю. При этом их зарплата может достигать $200–300 тыс. в год.
По данным исследователей, сокращения «сотрудников-призраков» сэкономили бы упомянутым компаниям в сумме $11,6 млрд, а их общая рыночная капитализация могла бы вырасти на $465 млрд.
Больше всего таких сотрудников удалось обнаружить среди удалёнщиков — 14% от их общего числа. Среди офисных сотрудников таких было лишь 6%, а программистов с гибридной занятостью — 9%.
Авторы исследования считают, что аналогичную ситуацию можно обнаружить не только в IT, но и в большинстве других сфер.
https://softwareengineeringproductivity.stanford.edu/
Исследование учёных Стэнфордского университета показало, что каждый десятый разработчик в крупных IT-компаниях ничего не делает. Они проанализировали данные о производительности более 50 тысяч работников из сотен компаний.
Выяснилось, что 9,5% из них не выполняют никакой полезной работы, хотя и регулярно докладывают об успехах.
Для оценки эффективности программистов использовался специальный алгоритм. Кроме того, учёные изучили данные деловой соцсети LinkedIn. Они анализировали профили сотрудников, работающих в 13 крупнейших корпорациях, в том числе IBM, Microsoft, Oracle, Google, Amazon и других.
Оказалось, что многие программисты просто имитируют работу. Они могут вносить в код пару изменений в месяц, при этом минимально общаясь с коллегами и тратя на работу по 5 часов в неделю. При этом их зарплата может достигать $200–300 тыс. в год.
По данным исследователей, сокращения «сотрудников-призраков» сэкономили бы упомянутым компаниям в сумме $11,6 млрд, а их общая рыночная капитализация могла бы вырасти на $465 млрд.
Больше всего таких сотрудников удалось обнаружить среди удалёнщиков — 14% от их общего числа. Среди офисных сотрудников таких было лишь 6%, а программистов с гибридной занятостью — 9%.
Авторы исследования считают, что аналогичную ситуацию можно обнаружить не только в IT, но и в большинстве других сфер.
https://softwareengineeringproductivity.stanford.edu/
😁27❤5🔥4👍3💯2👀1
Анатомия MAC-адреса
(продолжение предыдущего поста)
MAC-адрес (Media Access Control address) — это уникальный идентификатор сетевого интерфейса (например, сетевой карты), состоящий из 6 байтов (48 бит). Он делится на две основные части:
1. Organizationally Unique Identifier (OUI) — 3 байта (первые 24 бита):
* присваивается IEEE каждому производителю сетевых интерфейсов (NIC vendor);
* идентифицирует компанию-производителя устройства;
* на изображении выделен оранжевым цветом (например,
* первый байт OUI содержит два важных бита:
* U/L (Universal/Local) Bit (бит 0):
-
-
2. Network Interface Controller Specific (NIC) — 3 байта (последние 24 бита):
* присваивается самим производителем для каждого отдельного сетевого интерфейса;
* обеспечивает уникальность MAC-адреса среди устройств одного производителя;
* на изображении выделен голубым цветом (например,
Структура битов в MAC-адресе:
* В последнем байте MAC-адреса есть I/G (Individual/Group) Bit (бит групповой/индивидуальный):
*
*
Резюме:
* Длина: 6 байтов (48 бит);
* Состав: OUI (3 байта) + NIC (3 байта);
* Ключевые биты: U/L (определяет уникальность) и I/G (определяет тип адресации — индивидуальный или групповой).
Таким образом, MAC-адрес обеспечивает уникальную идентификацию устройства в локальной сети.
(продолжение предыдущего поста)
MAC-адрес (Media Access Control address) — это уникальный идентификатор сетевого интерфейса (например, сетевой карты), состоящий из 6 байтов (48 бит). Он делится на две основные части:
1. Organizationally Unique Identifier (OUI) — 3 байта (первые 24 бита):
* присваивается IEEE каждому производителю сетевых интерфейсов (NIC vendor);
* идентифицирует компанию-производителя устройства;
* на изображении выделен оранжевым цветом (например,
6C:83:75);* первый байт OUI содержит два важных бита:
* U/L (Universal/Local) Bit (бит 0):
-
0 — адрес глобально уникален (Universal), назначен IEEE;-
1 — адрес локально администрируется (Local), может быть изменён администратором сети.2. Network Interface Controller Specific (NIC) — 3 байта (последние 24 бита):
* присваивается самим производителем для каждого отдельного сетевого интерфейса;
* обеспечивает уникальность MAC-адреса среди устройств одного производителя;
* на изображении выделен голубым цветом (например,
B8:22:1A).Структура битов в MAC-адресе:
* В последнем байте MAC-адреса есть I/G (Individual/Group) Bit (бит групповой/индивидуальный):
*
0 — Unicast (адрес предназначен для одного устройства, используется для точечной передачи данных);*
1 — Multicast (адрес предназначен для группы устройств, используется для широковещательной передачи данных).Резюме:
* Длина: 6 байтов (48 бит);
* Состав: OUI (3 байта) + NIC (3 байта);
* Ключевые биты: U/L (определяет уникальность) и I/G (определяет тип адресации — индивидуальный или групповой).
Таким образом, MAC-адрес обеспечивает уникальную идентификацию устройства в локальной сети.
Telegram
METANIT.COM
Анатомия MAC-адреса
(продолжение в следующем посте)
(продолжение в следующем посте)
👍8❤5🔥4
Мессенджер Telegram могут полностью заблокировать в России к сентябрю 2026 года. Об этом пишет СМИ со ссылкой на заместителя председателя комитета Государственной думы России Михаила Делягина.
По его словам, он ожидает закрытия мессенджера «по схеме YouTube» примерно к выборам, то есть к сентябрю 2026 года. При этом Делягин считает, что часть аудитории все равно останется, как это случилось с другими заблокированными соцсетями.
https://hi-tech.mail.ru/news/141594-v-gosdume-sprognozirovali-blokirovku-telegram-k-sentyabryu/?frommail=1
По его словам, он ожидает закрытия мессенджера «по схеме YouTube» примерно к выборам, то есть к сентябрю 2026 года. При этом Делягин считает, что часть аудитории все равно останется, как это случилось с другими заблокированными соцсетями.
https://hi-tech.mail.ru/news/141594-v-gosdume-sprognozirovali-blokirovku-telegram-k-sentyabryu/?frommail=1
Hi-Tech Mail
В Госдуме спрогнозировали блокировку Telegram к сентябрю
Таким мнением поделился депутат Михаил Делягин.
🤡40🤬7👎4😢1🙏1
6 типов тестирования API
(продолжение предыдущего поста)
1. Workflow Testing (тестирование рабочих процессов)
- Суть: проверяет, что последовательность вызовов API работает корректно и позволяет выполнить определённый процесс от начала до конца.
- Цель: убедиться, что цепочка API-запросов взаимодействует правильно, и бизнес-процесс (например, оформление заказа) завершается успешно.
- Пример на изображении: показан сценарий с сообщением «Thanks for your order!» — иллюстрирует, как несколько API-вызовов объединяются для завершения заказа.
2. Performance Testing (тестирование производительности)
- Суть: оценивает скорость, отзывчивость и стабильность работы API в различных условиях нагрузки.
- Цель: выявить «узкие места» — например, задержки при обработке запросов или сбои при высокой нагрузке.
- Пример на изображении: сервер соединён с облаком API пунктирной линией с точками, символизирующими нагрузку — это отражает проверку работы API под нагрузкой.
3. Security Testing (тестирование безопасности)
- Суть: использует методы пенетрационного (атакующего) и фаззинг-тестирования (подачи некорректных данных) для поиска уязвимостей.
- Цель: обнаружить слабые места в API, которые могут быть использованы злоумышленниками (например, SQL-инъекции, неавторизованный доступ).
- Пример на изображении: два силуэта в капюшонах, символизирующие хакеров, пытаются взаимодействовать с облаком API — это подчёркивает аспект безопасности.
4. Data-driven Testing (тестирование, управляемое данными)
- Суть: подаёт на вход API различные наборы и типы данных, чтобы проверить корректность работы в разных сценариях.
- Цель: убедиться, что API правильно обрабатывает крайние случаи (например, пустые значения, некорректные форматы) и не выдаёт ошибок.
- Пример: тестирование, как API реагирует на разные типы входных данных — числа, строки, JSON-объекты.
5. Contract Testing (тестирование контракта)
- Суть: проверяет, что обмен данными между клиентом и API соответствует заранее оговорённой структуре запросов и ответов.
- Цель: гарантировать, что клиент и сервер «говорят на одном языке» — форматы JSON/XML, HTTP-статусы, заголовки запросов совпадают с документацией.
- Пример на изображении: схема с блоками «Request» (запрос) и «Response» (ответ), соединёнными с облаком API, иллюстрирует проверку структуры обмена данными.
6. Endpoint Testing (тестирование конечных точек)
- Суть: проверяет отдельные конечные точки (endpoints) API — корректно ли они реагируют на запросы и возвращают ожидаемые данные или коды ошибок.
- Цель: выявить неработающие или некорректно настроенные endpoints, например, 404-ошибки, неверные JSON-ответы.
- Пример: отправка GET-запроса к
(продолжение предыдущего поста)
1. Workflow Testing (тестирование рабочих процессов)
- Суть: проверяет, что последовательность вызовов API работает корректно и позволяет выполнить определённый процесс от начала до конца.
- Цель: убедиться, что цепочка API-запросов взаимодействует правильно, и бизнес-процесс (например, оформление заказа) завершается успешно.
- Пример на изображении: показан сценарий с сообщением «Thanks for your order!» — иллюстрирует, как несколько API-вызовов объединяются для завершения заказа.
2. Performance Testing (тестирование производительности)
- Суть: оценивает скорость, отзывчивость и стабильность работы API в различных условиях нагрузки.
- Цель: выявить «узкие места» — например, задержки при обработке запросов или сбои при высокой нагрузке.
- Пример на изображении: сервер соединён с облаком API пунктирной линией с точками, символизирующими нагрузку — это отражает проверку работы API под нагрузкой.
3. Security Testing (тестирование безопасности)
- Суть: использует методы пенетрационного (атакующего) и фаззинг-тестирования (подачи некорректных данных) для поиска уязвимостей.
- Цель: обнаружить слабые места в API, которые могут быть использованы злоумышленниками (например, SQL-инъекции, неавторизованный доступ).
- Пример на изображении: два силуэта в капюшонах, символизирующие хакеров, пытаются взаимодействовать с облаком API — это подчёркивает аспект безопасности.
4. Data-driven Testing (тестирование, управляемое данными)
- Суть: подаёт на вход API различные наборы и типы данных, чтобы проверить корректность работы в разных сценариях.
- Цель: убедиться, что API правильно обрабатывает крайние случаи (например, пустые значения, некорректные форматы) и не выдаёт ошибок.
- Пример: тестирование, как API реагирует на разные типы входных данных — числа, строки, JSON-объекты.
5. Contract Testing (тестирование контракта)
- Суть: проверяет, что обмен данными между клиентом и API соответствует заранее оговорённой структуре запросов и ответов.
- Цель: гарантировать, что клиент и сервер «говорят на одном языке» — форматы JSON/XML, HTTP-статусы, заголовки запросов совпадают с документацией.
- Пример на изображении: схема с блоками «Request» (запрос) и «Response» (ответ), соединёнными с облаком API, иллюстрирует проверку структуры обмена данными.
6. Endpoint Testing (тестирование конечных точек)
- Суть: проверяет отдельные конечные точки (endpoints) API — корректно ли они реагируют на запросы и возвращают ожидаемые данные или коды ошибок.
- Цель: выявить неработающие или некорректно настроенные endpoints, например, 404-ошибки, неверные JSON-ответы.
- Пример: отправка GET-запроса к
/users должна возвращать список пользователей, а POST-запрос к /login — токен аутентификации. Если этого не происходит — endpoint требует доработки.Telegram
METANIT.COM
6 типов тестирования API
(продолжение в следующем посте)
(продолжение в следующем посте)
❤5👍3🔥2
Команда Swift учредила рабочую группу для оптимизации и адаптации языка программирования под Windows
Команда Swift анонсировали создание рабочей группы, которая займётся оптимизацией, адаптацией и поддержкой языка программирования в экосистеме Windows. Благодаря этому разработчики смогут создавать приложения для Windows с помощью Swift и связанных с ним инструментов.
Начальная поддержка Swift в Windows появилась в 2020 году. Теперь команда планирует расширить совместимость и собрала группу, которая будет работать над этим проектом.
В планы входит:
- улучшить поддержку Windows в официальном дистрибутиве Swift;
- адаптировать базовые пакеты Swift (Foundation и Dispatch) под идиомы Windows;
- сформировать рекомендации по поддержке Windows в будущем;
- объединить Swift и Windows API для совместимости Swift-библиотек в приложениях для Windows
https://www.swift.org/blog/announcing-windows-workgroup/
Команда Swift анонсировали создание рабочей группы, которая займётся оптимизацией, адаптацией и поддержкой языка программирования в экосистеме Windows. Благодаря этому разработчики смогут создавать приложения для Windows с помощью Swift и связанных с ним инструментов.
Начальная поддержка Swift в Windows появилась в 2020 году. Теперь команда планирует расширить совместимость и собрала группу, которая будет работать над этим проектом.
В планы входит:
- улучшить поддержку Windows в официальном дистрибутиве Swift;
- адаптировать базовые пакеты Swift (Foundation и Dispatch) под идиомы Windows;
- сформировать рекомендации по поддержке Windows в будущем;
- объединить Swift и Windows API для совместимости Swift-библиотек в приложениях для Windows
https://www.swift.org/blog/announcing-windows-workgroup/
Swift.org
Announcing the Windows Workgroup
We are excited to announce the creation of the Windows workgroup!
❤19💩5😁3🔥1👏1🤡1
Какая из версий Windows быстрее в 2026 году
Автор YouTube-канала TrigrZolt решил проверить, действительно ли новые версии Windows работают быстрее старых на одинаковом железе. Для этого он взял 6 одинаковых ноутбуков Lenovo ThinkPad X220 с процессором Intel Core i5-2520M2, 8 ГБ ОЗУ и HDD на 256 ГБ, на которые установил 6 версий Windows со всеми доступными обновлениями:
Windows XP
Windows Vista
Windows 7
Windows 8.1
Windows 10
Windows 11
Стоит оговориться, что такое оборудование не очень подходит для Windows 11: процессор Intel 2011 года, медленный жесткий диск вместо SSD, полное отсутствие TPM 2.0, и работающий через костыли UEFI - именно то железо, на котором новейшая операционка работать не обязана в принципе. Поэтому ставили ОС в обход официальных требований. Но только на таких ограниченных ресурсах и становится понятно, как система на самом деле справляется с нагрузкой. Тем более, что и тест получился довольно всеобъемлющим.
Автор прогнал все системы по полной программе: замерил время загрузки до рабочего стола, посчитал, сколько места занимает каждая ОС на диске после установки всего софта, измерил потребление памяти в простое и под нагрузкой, проверил, сколько вкладок в браузере можно открыть до того, как система не попытается зависнуть, и много чего еще.
Первым тестом была проверка скорости запуска. Быстрее всех стартовала Windows 8.1. На втором месте почему-то оказалась Windows Vista, которую все постоянно ругали за медлительность. Третье место заняла Windows XP. Семерка расположилась где-то в середине. А дольше всех загружалась Windows 11.
Дальше предстояло выяснить, сколько места на диске занимает каждая система. Здесь в принципе работает простое правило: чем новее ОС, тем больше она весит:
- Windows XP — 6,46 ГБ
- Windows Vista — 15,3 ГБ
- Windows 7 — 17,4 ГБ
- Windows 8.1 — ~18 ГБ
- Windows 10 — ~25 ГБ
- Windows 11 — 29,8 ГБ
Тест на то, сколько ОЗУ требуется разным версиям Windows, выявил следующие результаты:
- Windows XP — 0,8 ГБ
- Windows Vista — ~1,5 ГБ
- Windows 7 — ~1,8 ГБ
- Windows 8.1 — ~1,9 ГБ
- Windows 10 — 2,0 ГБ
- Windows 11 — 3,3 ГБ (пики до 3,7 ГБ)
Также TrigrZolt хотел выяснить, сколько вкладок в браузере можно открыть до того, как общее потребление памяти дойдет до 5 ГБ:
- Windows 8.1 — 252 вкладки
- Windows 7 — >200 вкладок
- Windows Vista — >100 вкладок
- Windows 10 — >100 вкладок
- Windows XP — 50 вкладок (дальше – вылеты из-за paging file)
- Windows 11 — 49 вкладок
ПРи этом синтетические бенчмарки не сильно меняют картину. Так, CPU‑Z в однопоточном тесте первое место отдает Windows XP с 356 очками. Второе место — Windows 7 с результатом 355 баллов. Третье место — Windows 10 (353 балла) и Windows 11 — на четвертом (351 балл). Восьмерка и Vista — замыкающие. В многопотоке ситуация принципиально не поменялась. Лишь выросли цифры, да Vista и XP поменялись местами.
https://www.youtube.com/watch?v=7VZJO-hOT4c
Автор YouTube-канала TrigrZolt решил проверить, действительно ли новые версии Windows работают быстрее старых на одинаковом железе. Для этого он взял 6 одинаковых ноутбуков Lenovo ThinkPad X220 с процессором Intel Core i5-2520M2, 8 ГБ ОЗУ и HDD на 256 ГБ, на которые установил 6 версий Windows со всеми доступными обновлениями:
Windows XP
Windows Vista
Windows 7
Windows 8.1
Windows 10
Windows 11
Стоит оговориться, что такое оборудование не очень подходит для Windows 11: процессор Intel 2011 года, медленный жесткий диск вместо SSD, полное отсутствие TPM 2.0, и работающий через костыли UEFI - именно то железо, на котором новейшая операционка работать не обязана в принципе. Поэтому ставили ОС в обход официальных требований. Но только на таких ограниченных ресурсах и становится понятно, как система на самом деле справляется с нагрузкой. Тем более, что и тест получился довольно всеобъемлющим.
Автор прогнал все системы по полной программе: замерил время загрузки до рабочего стола, посчитал, сколько места занимает каждая ОС на диске после установки всего софта, измерил потребление памяти в простое и под нагрузкой, проверил, сколько вкладок в браузере можно открыть до того, как система не попытается зависнуть, и много чего еще.
Первым тестом была проверка скорости запуска. Быстрее всех стартовала Windows 8.1. На втором месте почему-то оказалась Windows Vista, которую все постоянно ругали за медлительность. Третье место заняла Windows XP. Семерка расположилась где-то в середине. А дольше всех загружалась Windows 11.
Дальше предстояло выяснить, сколько места на диске занимает каждая система. Здесь в принципе работает простое правило: чем новее ОС, тем больше она весит:
- Windows XP — 6,46 ГБ
- Windows Vista — 15,3 ГБ
- Windows 7 — 17,4 ГБ
- Windows 8.1 — ~18 ГБ
- Windows 10 — ~25 ГБ
- Windows 11 — 29,8 ГБ
Тест на то, сколько ОЗУ требуется разным версиям Windows, выявил следующие результаты:
- Windows XP — 0,8 ГБ
- Windows Vista — ~1,5 ГБ
- Windows 7 — ~1,8 ГБ
- Windows 8.1 — ~1,9 ГБ
- Windows 10 — 2,0 ГБ
- Windows 11 — 3,3 ГБ (пики до 3,7 ГБ)
Также TrigrZolt хотел выяснить, сколько вкладок в браузере можно открыть до того, как общее потребление памяти дойдет до 5 ГБ:
- Windows 8.1 — 252 вкладки
- Windows 7 — >200 вкладок
- Windows Vista — >100 вкладок
- Windows 10 — >100 вкладок
- Windows XP — 50 вкладок (дальше – вылеты из-за paging file)
- Windows 11 — 49 вкладок
ПРи этом синтетические бенчмарки не сильно меняют картину. Так, CPU‑Z в однопоточном тесте первое место отдает Windows XP с 356 очками. Второе место — Windows 7 с результатом 355 баллов. Третье место — Windows 10 (353 балла) и Windows 11 — на четвертом (351 балл). Восьмерка и Vista — замыкающие. В многопотоке ситуация принципиально не поменялась. Лишь выросли цифры, да Vista и XP поменялись местами.
https://www.youtube.com/watch?v=7VZJO-hOT4c
YouTube
Windows XP vs Vista vs 7 vs 8.1 vs 10 vs 11 | Speed Test
Windows XP vs Vista vs 7 vs 8.1 vs 10 vs 11 Speed Test. An updated speed test of every generation of Windows, the six major Microsoft operating systems since 2001. How is performance impacted over each release of Windows?
SUBSCRIBE FOR MORE WINDOWS CONTENT:…
SUBSCRIBE FOR MORE WINDOWS CONTENT:…
🔥17👾15👍8🤪4❤1👏1🤡1
This media is not supported in your browser
VIEW IN TELEGRAM
Наглядно как работает шардинг базы данных с прокси
🔥11❤6👍2
В сеть утёк интерфейс Aluminium OS — операционной системы, в которую объединены Android и ChromeOS
В сети оказался внешний вид интерфейса операционной системы Aluminium OS от Google, которая объединяет Android и ChromeOS. Дизайн новой ОС фигурирует в скринкасте отчёта об ошибке, касающейся вкладок в режиме инкогнито браузера Chrome.
Номер сборки ALOS — Aluminium OS, кодовое название настольной версии Android — обозначен как ZL1A.260119.001.A1. В видео также упомянута Android 16.
Название плана по объединению ChromeOS и Android в единую настольную ОС стало известно в ноябре прошлого года. Aluminium OS должны запустить в этом году. Вероятно, публичный релиз ОС будет основан на Android 17, которая также выйдет в 2026 году.
https://9to5google.com/2026/01/27/android-desktop-leak/
В сети оказался внешний вид интерфейса операционной системы Aluminium OS от Google, которая объединяет Android и ChromeOS. Дизайн новой ОС фигурирует в скринкасте отчёта об ошибке, касающейся вкладок в режиме инкогнито браузера Chrome.
Номер сборки ALOS — Aluminium OS, кодовое название настольной версии Android — обозначен как ZL1A.260119.001.A1. В видео также упомянута Android 16.
Название плана по объединению ChromeOS и Android в единую настольную ОС стало известно в ноябре прошлого года. Aluminium OS должны запустить в этом году. Вероятно, публичный релиз ОС будет основан на Android 17, которая также выйдет в 2026 году.
https://9to5google.com/2026/01/27/android-desktop-leak/
💩10❤9🔥2🤨2👏1