Разработчик из Amazon пожаловался, что уже год работает 30 минут в день. Он рассказывает, что уже год фактически не выполняет никакой реальной работы. Его команда полностью состоит из индийских инженеров, и, по его словам, они систематически избегают поручать ему серьезные задачи. Сначала он был раздражён и хотел перевестись в другую команду, но позже решил смириться и просто «сидеть на попе ровно», выполняя минимальный объём работы - примерно 30 минут в день, при этом продолжая получать полную зарплату.
https://www.teamblind.com/post/havent-done-any-work-in-a-year-at-amazon-ey2vyajr/46747093

Всем бы такие проблемы...

Теорема CAP

Теорема CAP
(объяснение к предыдущему посту)

В распределённой системе невозможно получить всё сразу. Приходится идти на компромиссы.

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

1. C — Согласованность (Consistency)
* Каждое чтение получает самые свежие записи или ошибку. Отсутствия устаревших данных.
* Большинство SQL-баз данных (например, PostgreSQL, MySQL) оптимизированы для строгой согласованности.

2. A — Доступность (Availability)
* Каждый запрос получает ответ, даже если данные могут быть не самыми актуальными.
* NoSQL-базы данных, такие как DynamoDB и Cassandra, часто отдают приоритет доступности над строгой согласованностью.

3. P — Отказоустойчивость при разделении (Partition Tolerance)
* Система продолжает работать даже при разделении сети (то есть при нарушении связи между узлами).
* Все реальные распределённые системы должны быть устойчивы к разделению.

Компромисс: выберите любые два

1. CP (Согласованность + Отказоустойчивость)
* Приоритет отдаётся точности данных. Система может отклонять запросы во время сетевых проблем для поддержания согласованности.

2. AP (Доступность + Отказоустойчивость)
* Приоритет отдаётся доступности. Система продолжает отвечать на запросы, даже если данные могут быть временно несогласованными.

3. CA (Согласованность + Доступность)
* Выглядит отлично на бумаге, но недостижимо в реальных распределённых системах, поскольку сетевые разделения неизбежны.

За пределами CAP: теорема PACELC

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

Здесь на помощь приходит PACELC:
* Если происходит разделение (P) → вы выбираете между доступностью (A) и согласованностью (C)
* В противном случае (E) → вы выбираете между задержкой (L) и согласованностью (C)

Эта теорема признаёт, что даже когда система работает нормально, существует компромисс между задержкой и согласованностью.

Индийский ИТ-специалист Сохам Парекх (Soham Parekh) исполнил мечту любого наемного работника – он научился не работать, но при этом регулярно получать зарплату. Он устраивался в различные компании, где в течение длительного времени не выполнял свои обязанности, но при этом стабильно получал зарплату.

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

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

Также у него было хорошо подготовленное резюме. По мнению ряда его работодателей, оно на 90% состояло из лжи, но, тем не менее, он вполне успешно устраивался во все новые фирмы.
https://timesofindia.indiatimes.com/technology/tech-news/theres-a-guy-named-soham-parekh-in-india-who-silicon-valley-ceo-exposes-the-moonlighting-scam-of-indian-techie/articleshow/122223553.cms

Специалист по работе с данными из консалтинговой компании Capco Мохд Фарааз провёл эксперимент, предложив популярным ИИ-моделям угадать число от 1 до 50. Все они выбрали один и тот же вариант ответа.
Фарааз протестировал модели OpenAI ChatGPT, Anthropic Claude Sonnet 4, Google Gemini 2.5 Flash и Llama 4. Все они назвали в качестве ответа «27».
динственным исключением стал чат-бот Grok компании xAI. Он дал ответ «42»
https://mohdfaraaz.medium.com/llms-and-the-illusion-of-randomness-a-fun-ai-guessing-experiment-60ff82aa5f67

Тестирование: типы и инструменты

Из-за отсутствия финансирования закрылся российский государственный антивирусный сканер
Еще менее года назад - 14 августа 2024 сообщалось, что запущен государственный антивирусный сервис «Мультисканер», который должен быть стать аналогом virustotal. И вот теперь он прекратил свое функционирование из-за отсутствия финансирования.
https://www.cnews.ru/news/top/2025-07-03_iz-za_otsutstviya_finansirovaniya

Что на самом деле происходит при вводе URL в браузере

Что на самом деле происходит при вводе URL в браузере? Разберём этот процесс пошагово (к иллюстрации из предыдущего поста)

1. Вы вводите URL в браузер

Браузер принимает то, что вы ввели (например, http://example.com) и готовится получить этот веб-сайт. Но сначала ему нужно узнать, где находится сайт.

2. Браузер запрашивает IP-адрес у DNS-сервера

DNS работает как телефонная книга интернета. Он сообщает браузеру: «Этот домен находится по этому IP-адресу».

http://example.com → 93.184.216.34

3. Устанавливается TCP-соединение через этот IP

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

4. Браузер отправляет HTTP-запрос

Он отправляет сообщение вроде: «Привет, сервер, дай мне главную страницу этого сайта». Обычно это GET-запрос.

5. Веб-сервер получает данные

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

6. База данных отправляет данные обратно на сервер

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

7. Сервер отвечает браузеру

Сервер отправляет обратно HTML, CSS, JavaScript и другой контент в ответ на запрос.

8. Браузер отображает контент

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

Временная и пространственная сложность популярных алгоритмов сортировки:

1. Сортировка выбором
* Время: Лучшее Ω(n²) | Среднее Θ(n²) | Худшее O(n²)
* Память: O(1)

2. Сортировка вставками
* Время: Лучшее Ω(n) | Среднее Θ(n²) | Худшее O(n²)
* Память: O(1)

3. Сортировка пузырьком
* Время: Лучшее Ω(n) | Среднее Θ(n²) | Худшее O(n²)
* Память: O(1)

4. Сортировка Шелла
* Время: Лучшее Ω(n log n) | Среднее Θ(n log² n) | Худшее O(n²)
* Память: O(1)

5. Сортировка слиянием
* Время: Лучшее Ω(n log n) | Среднее Θ(n log n) | Худшее O(n log n)
* Память: O(n)

6. Быстрая сортировка
* Время: Лучшее Ω(n log n) | Среднее Θ(n log n) | Худшее O(n²)
* Память: O(log n)

7. Пирамидальная сортировка
* Время: Лучшее Ω(n log n) | Среднее Θ(n log n) | Худшее O(n log n)
* Память: O(1)

8. Поразрядная сортировка подсчётом
* Время: Лучшее Ω(n+k) | Среднее Θ(n+k) | Худшее O(n+k)
* Память: O(k)

9. Сортировка распределением (корзинная)
* Время: Лучшее Ω(n+k) | Среднее Θ(n+k) | Худшее O(n²)
* Память: O(n)

10. Поразрядная сортировка
* Время: Лучшее Ω(nk) | Среднее Θ(nk) | Худшее O(nk)
* Память: O(n+k)

Примечание: n = количество элементов, k = диапазон элементов

«Ростелеком» работает над созданием онлайн-магазина видеоигр. Площадка будет ориентирована на российские проекты, адаптированные под ОС «Аврора», используемую в планшетах компании.

По данным собеседников, магазин может быть интегрирован в игровую консоль от FPlus, представленную на «ЦИПР 2025». Однако эксперты сомневаются в успехе: «Авроре» не хватает поддержки современных графических движков, а предыдущие попытки «Ростелекома» в этой сфере (например, «Игровой Маркет» 2019 года) не стали массовыми.

В FPlus подтвердили переговоры с разработчиками «Авроры», но участники рынка отмечают, что без широкого ассортимента магазин рискует повторить судьбу других российских платформ, вынужденных продавать ключи от Steam.

https://www.kommersant.ru/doc/7855350

Представитель ЦБ РФ предложил передать на аутсорсинг в Индию часть российских IT-проектов из-за дефицита квалифицированных кадров и команд разработчиков на рынке России.
Это предложение сделал заместитель начальника Дальневосточного главного управления ЦБ РФ Денис Давыдов на Финансовом конгрессе Банка России.

«Сейчас много говорят у нас, конечно, о существенной нехватке в моменте кадров различных отраслей, особенно о дефиците инженерно‑технических специалистов в России. А вот, например, в Индии уровень безработицы выпускников в технических вузах в последние годы почти достигает 30%. При этом сложившийся на сегодня дифференциал заработных плат, тем более, если говорить о паритете покупательной способности, подталкивает к мысли о том, что здесь могли бы быть какие‑то эффекты кооперации», — рассказал Давыдов.

https://1prime.ru/20250704/indiya-859179950.html

Топ-15 базовых компонентов проектирования систем:

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

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

3. DNS (Domain Name System) — система доменных имён, преобразующая удобочитаемые доменные имена в IP-адреса.

4. Кэш — хранит часто запрашиваемые данные в оперативной памяти. Существенно снижает задержки и нагрузку на базу данных.

5. CDN (Content Delivery Network) — сеть доставки контента, которая распространяет статический контент (изображения, CSS, JS и т. д.) через пограничные серверы, расположенные ближе к пользователям. Снижает задержки и нагрузку на полосу пропускания, особенно в глобальном масштабе.

6. База данных — основное хранилище данных. Может быть SQL или NoSQL в зависимости от потребностей. Поддерживает структурированные запросы, индексацию, транзакции и надёжность хранения.

7. API — определяет, как сервисы взаимодействуют друг с другом, обычно через HTTP или gRPC. Обеспечивает модульное проектирование и чёткое разделение обязанностей.

8. Микросервисы — разбивает монолитное приложение на независимо развёртываемые сервисы. Повышает гибкость, изоляцию сбоев и масштабируемость.

9. Ограничитель частоты запросов — контролирует количество запросов, которые пользователь или сервис может сделать за определённый промежуток времени. Защищает API от злоупотреблений и обеспечивает справедливое использование.

10. Хранилище объектов — хранит большие двоичные объекты (изображения, видео, резервные копии) с высокой доступностью и надёжностью. Примеры: AWS S3, Google Cloud Storage и др.

11. Очередь сообщений — обеспечивает асинхронную коммуникацию между сервисами через очередь (например, Kafka, RabbitMQ). Помогает разделить системы и справляться с пиковыми нагрузками.

12. Шардинг — разбивает большие наборы данных на несколько баз данных или таблиц. Помогает масштабировать хранилище и улучшать производительность запросов.

13. Репликация — копирует данные с одного узла базы данных на другой. Повышает отказоустойчивость и производительность чтения.

14. Согласованное хеширование — метод распределения данных между узлами с минимальными нарушениями при масштабировании. Широко используется в системах кэширования и распределённого хранения.

15. Система мониторинга — отслеживает состояние системы, собирает логи и метрики, отправляет оповещения о сбоях или аномалиях. Критически важна для наблюдения за системой, отладки и обеспечения бесперебойной работы.

Вкратце о том, как происходит перемножение матриц в GPU