Вкратце как создавать AI-агентов

Pandas (Python) vs SQL: сравнение некоторых операций

CORS (Cross-Origin Resource Sharing)
(продолжение в следующем посте)

CORS (Cross-Origin Resource Sharing)
(продолжение предыдущего поста)

CORS (Cross-Origin Resource Sharing) — это HTTP-механизм, который позволяет запрашивать данные с одного URL на другой URL, обходя ограничения политики одинакового происхождения (Same-Origin Policy).
CORS обеспечивает баланс между безопасностью и возможностью взаимодействия между ресурсами разных источников, предотвращая несанкционированный доступ к данным.

Как работает CORS:

1. Клиент (a.com) хочет отправить запрос (например, POST /products) на сервер с другим источником (b.com).
2. Браузер обнаруживает, что источник отличается, и перед отправкой основного запроса отправляет предварительный (preflight) запрос с методом OPTIONS на сервер (b.com). Это делается для проверки, разрешены ли такие запросы.
3. В preflight-запросе браузер указывает:
- метод основного запроса (например, POST);
- заголовки, которые будут использоваться.
4. Сервер (b.com) отвечает на preflight-запрос кодом 204 No Content и включает специальные заголовки:
- Access-Control-Allow-Origin: указывает, какой источник (origin) может отправлять запросы (в примере — a.com);
- Access-Control-Allow-Methods: перечисляет разрешённые HTTP-методы (в примере — POST).
5. Если сервер разрешает запрос, браузер отправляет основной запрос (POST /products).
6. Сервер обрабатывает основной запрос и возвращает ответ, если всё корректно.

Ключевые моменты:
- CORS работает как на стороне браузера, так и на стороне сервера.
- Без правильной настройки CORS браузер блокирует запросы к ресурсам с других доменов.
- Заголовки Access-Control-Allow-Origin и Access-Control-Allow-Methods критически важны для разрешения запросов.
- Предварительные (OPTIONS) запросы помогают убедиться, что основной запрос безопасен.

Компания Hynix - один из крупнейших производителей чипов памяти прогнозирует, что проблема на рынке памяти не будет решена до 2028 года.

Hynix отмечает, что запасы памяти сокращаются, а заметный рост поставок памяти DRAM, который сможет избавить рынок от дефицита, ожидается лишь в 2028 году, поскольку для наращивания объёмов производства нужны новые фабрики или расширение существующих объектах, а это долгий процесс. Исключением являются лишь чипы HBM и SOCAMM.
Тем не менее в Hynix считают, что продажи ПК в 2026 году останутся примерно на уровне текущего года.

К слову, на Amazon уже появилась оперативная память (Lexar 8GB DDR5-5600 UDIMM) доступная для предзаказа с датой релиза 31 августа 2027 года.

https://videocardz.com/newz/sk-hynix-outlook-points-to-tight-consumer-memory-supply-through-2028-as-a-lexar-ddr5-listing-shows-a-2027-ship-date

Вполне валидные выражения в C++:

    [](){};
    [](){}();;
    []{};
    []{}();

Краткий совет по Linux:

У вас есть файлы логов, сжатые в формат .gz? Вам не нужно распаковывать их, чтобы прочитать или выполнить поиск по содержимому.

Используйте инструменты с префиксом «z» напрямую:

* `zcat` — просмотр файла;
* `zless` — прокрутка содержимого;
* `zgrep` — поиск внутри файла;
* `zegrep` — поиск с использованием расширенных регулярных выражений;
* `zfgrep` — поиск фиксированных строк;
* `zcmp`/`zdiff` — сравнение файлов.

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

Covering indexes (Покрывающие индексы)
(описание в следующем посте)

Covering indexes (Покрывающие индексы)
(описание к предыдущему посту)

Покрывающие индексы позволяют ускорить выполнение SQL-запросов за счёт исключения обращений к основной таблице, если все нужные данные уже есть в индексе. Они применябтся в базах данных для оптимизации запросов.

#### 1. Сравнение: Без покрывающего индекса vs с покрывающим индексом

Без покрывающего индекса (Without Covering Index):
- Система выполняет запрос, собирает все необходимые столбцы для запроса, но вынуждена обращаться к основной таблице базы данных
- Это менее эффективно, так как требует дополнительных операций чтения данных из таблицы.

С покрывающим индексом (With a Covering Index):
- Аналогичный процесс поиска активных пользователей, но теперь все необходимые столбцы для запроса уже включены в индекс.
- Система не нуждается в обращении к основной таблице, что значительно ускоряет выполнение запроса.
- Данные извлекаются напрямую из индекса, минуя основную таблицу.

#### 2. Пример создания покрывающего индекса (Covering Index)

В нижней правой части показан синтаксис создания покрывающего индекса:

CREATE INDEX IX_Users_Search
ON Users (Status, LastName, FirstName)
INCLUDE (Email);

Разъяснение элементов:
- Index Name (имя индекса): IX_Users_Search — название созданного индекса.
- Key Columns (ключевые столбцы): Status, LastName, FirstName — используются для фильтрации (WHERE) и сортировки (ORDER BY) в запросе.
- Included Column (включённый столбец): Email — добавлен через INCLUDE для того, чтобы избежать обращения к основной таблице при извлечении email-адресов.

#### 3. Пример SQL-запроса (Query)

SELECT
    Status, LastName, FirstName, Email
FROM
    Users
WHERE
    Status = 'Active'
ORDER BY
    LastName, FirstName;

Этот запрос выбирает статус, фамилию, имя и email пользователей, у которых статус равен «Active», и сортирует результаты по фамилии и имени.

Добавлены вводные статьи по фреймворку PyTorch и Deep Learning
https://metanit.com/python/pytorch/
#python #pytorch #deeplearning

Краткий совет по Linux:

Если вы хотите очистить пустые директории, команда find значительно упростит эту задачу:

find . -type d -empty -exec rmdir -v {} +

Опция -type d осуществляет поиск директорий, -empty выбирает именно пустые из них, а -exec rmdir {} запускает команду rmdir для их удаления.

Команда rmdir перед удалением проверяет, что директория действительно пуста.

В качестве альтернативы для выполнения той же задачи можно использовать следующую команду:

find . -type d -empty -delete

В Anthropic 27% работы выполняет ИИ, однако работники боятся потерять квалификацию

Согласно последнему отчету Anthropic, 27% работы в компании теперь выполняется ИИ. Около 60% инженеров-программистов Anthropic обращаются к ИИ почти каждый день. Чаще всего за отладкой кода, разбором незнакомых проектов и помощью в улучшении архитектуры. ИИ активно используется и для решения более сложных задач. Так, в участие ИИ в проектировании и планировании выросло с 1% до 10%, во внедрении новых функций — с 14% до 37%. Производительность труда, по оценке сотрудников, выросла примерно наполовину. Более того, Claude позволил решить задачи, которые без ИИ вообще не были бы решены: их сочли бы избыточным по затратам, отмечают в компании.

Однако работники компании утверждают, что это снижает их квалификацию. Многие сотрудники Anthropic указывают, что из-за привычки полагаться на ИИ они стали меньше тренировать базовые навыки. Один специалист отметил, что «70% времени теперь уходит на проверку и редактирование кода вместо написания». Другой предположил, что в будущем программисты будут «контролировать работу сразу нескольких Claude» вместо прямого участия в разработке.

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

https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic

Руководство как выиграть в крестики-нолики

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

Как выбрать базу данных
(продолжение предыдущего поста)

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

1. Определение типа данных («What type of data do you have?»):
* Структурированные (Structured) — данные с чёткой схемой (таблицы, столбцы, строки). Примеры: транзакции, аналитика.
* Полуструктурированные (Semistructured) — данные с некоторой структурой, но без жёсткой схемы (например, JSON, XML).
* Неструктурированные (Unstructured) — данные без явной структуры (текст, изображения, видео).

2. Выбор базы данных в зависимости от типа данных:
* Для структурированных данных:
* OLTP (Transactions) — используйте Relational DB (например, PostgreSQL, MySQL) для транзакционных операций (быстрые вставки, обновления, удаления).
* OLAP (Analytics) — выбирайте Columnar DB (например, Amazon Redshift, Vertica) для аналитических запросов (агрегации, сложные выборки).
* Для неструктурированных данных — используйте Object Store (хранилище объектов, например, Amazon S3) для хранения файлов, медиа.
* Для полуструктурированных данных — переходите к следующему шагу («Semistructured»).

3. Для полуструктурированных данных («Semistructured») — уточните сценарий использования:
* Dictionary-style (словарный стиль) — данные представлены в виде пар «ключ-значение».
* Если используется как кэш («Is it used as a cache?») — выбирайте In-memory DB (например, Redis) для быстрого доступа.
* Если не используется как кэш — переходите к следующему варианту.
* Nested Objects (вложенные объекты) — выбирайте Document Store (например, MongoDB, Couchbase) для хранения документов с вложенной структурой.
* Text Search (поиск по тексту) — используйте Text Search DB (например, Elasticsearch) для полнотекстового поиска.
* Entity / Relationships (сущности и связи) — выбирайте Graph DB (например, Neo4j) для моделирования графовых структур (социальные сети, маршруты).
* Two Dimensional Key Value (двумерные пары «ключ-значение») — используйте специализированные Key-Value DB (например, Riak).

4. Уточнение по паттерну доступа («What is the access pattern?») для некоторых типов:
* Time-based (временные ряды) — выбирайте Time-series DB (например, InfluxDB) для хранения и анализа временных данных (логи, метрики).
* Location data (данные о местоположении) — используйте Geospatial DB (например, PostGIS) для геоданных (карты, маршруты).
* Wide schema (широкая схема) — выбирайте Wide-column DB (например, Cassandra) для хранения больших объёмов данных с переменной структурой.

Итог: выбор базы данных зависит от:
* типа данных (структурированные, полуструктурированные, неструктурированные);
* сценария использования (транзакции, аналитика, кэш, поиск и т. д.);
* паттерна доступа к данным (временные ряды, геоданные, широкая схема и др.).

Внедрение ИИ приведет к найму специалистов начального уровня, считают руководители компаний

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

В исследовании приняли участие более 350 генеральных директоров публичных компаний с годовой выручкой свыше $1 млрд, а также около 400 крупных институциональных инвесторов. 67% респондентов заявили, что внедрение ИИ приведёт к росту найма на начальные позиции уже в следующем году. При этом 58% опрошенных сообщили о планах по найму специалистов на сеньорские и управленческие позиции.

Согласно докладу Teneo, рост найма может быть обусловлен стремлением компаний увеличить число сотрудников, непосредственно работающих с технологиями искусственного интеллекта. Кроме того, по мере внедрения ИИ и автоматизации процессов происходит трансформация и перераспределение существующих ролей. В результате ИИ не уничтожает рабочие места, а скорее видоизменяет их, отмечают в Teneo.

https://www.businessinsider.com/ai-hiring-comeback-entry-level-jobs-ceo-teneo-survey-2025-12?IR=T

Сравнение Rust vs C++