Практические советы по использованию индексов в базе данных
(продолжение предыдущего поста)
Индексируйте столбцы в WHERE
* Если столбец используется в WHERE, он должен быть проиндексирован.
* Начинайте с высокоселективных столбцов (например, user_id, email, status).
Покрывайте запрос
* Используйте покрывающие индексы, включающие все столбцы, используемые в запросе.
* Это позволяет избежать возврата к таблице (ускоряет чтение).
Индексируйте соединения и внешние ключи
* Если по столбцу выполняется в JOIN, индексируйте его.
* Отсутствие индекса на внешних ключах = медленные соединения, гарантировано.
Используйте частичные индексы (Postgres) или фильтрованные индексы (SQL Server)
* Индексируйте только те строки, которые имеют значение.
* Пример: индексируйте только активных пользователей.
Удаляйте неиспользуемые индексы
* Индексы замедляют запись.
* Используйте pg_stat_user_indexes, sys.dm_db_index_usage_stats или эквивалент для удаления лишнего.
Используйте составные индексы (правильно)
* Порядок имеет значение: индекс (user_id, created_at) ≠ (created_at, user_id).
* Подбирайте индекс под фильтры и сортировки запросов.
Избегайте низкоселективных индексов
* Не индексируйте булевы значения или столбцы с малым количеством уникальных значений.
* Они не фильтруют данные, а только занимают место.
Следите за функциями в WHERE
* WHERE YEAR(created_at) = 2024 = полное сканирование таблицы.
* Вместо этого: created_at BETWEEN '2024-01-01' AND '2024-12-31'.
Измеряйте, а не угадывайте
* Используйте EXPLAIN, ANALYZE или планы запросов, чтобы увидеть, что происходит.
* Не доверяйте интуиции; доверяйте плану выполнения.
Тестируйте до и после
* Измеряйте время выполнения запросов до и после изменений индексов.
* Если улучшение менее 80%, пересмотрите дизайн.
(продолжение предыдущего поста)
Индексируйте столбцы в WHERE
* Если столбец используется в WHERE, он должен быть проиндексирован.
* Начинайте с высокоселективных столбцов (например, user_id, email, status).
Покрывайте запрос
* Используйте покрывающие индексы, включающие все столбцы, используемые в запросе.
* Это позволяет избежать возврата к таблице (ускоряет чтение).
Индексируйте соединения и внешние ключи
* Если по столбцу выполняется в JOIN, индексируйте его.
* Отсутствие индекса на внешних ключах = медленные соединения, гарантировано.
Используйте частичные индексы (Postgres) или фильтрованные индексы (SQL Server)
* Индексируйте только те строки, которые имеют значение.
* Пример: индексируйте только активных пользователей.
Удаляйте неиспользуемые индексы
* Индексы замедляют запись.
* Используйте pg_stat_user_indexes, sys.dm_db_index_usage_stats или эквивалент для удаления лишнего.
Используйте составные индексы (правильно)
* Порядок имеет значение: индекс (user_id, created_at) ≠ (created_at, user_id).
* Подбирайте индекс под фильтры и сортировки запросов.
Избегайте низкоселективных индексов
* Не индексируйте булевы значения или столбцы с малым количеством уникальных значений.
* Они не фильтруют данные, а только занимают место.
Следите за функциями в WHERE
* WHERE YEAR(created_at) = 2024 = полное сканирование таблицы.
* Вместо этого: created_at BETWEEN '2024-01-01' AND '2024-12-31'.
Измеряйте, а не угадывайте
* Используйте EXPLAIN, ANALYZE или планы запросов, чтобы увидеть, что происходит.
* Не доверяйте интуиции; доверяйте плану выполнения.
Тестируйте до и после
* Измеряйте время выполнения запросов до и после изменений индексов.
* Если улучшение менее 80%, пересмотрите дизайн.
Telegram
METANIT.COM
Практические советы по использованию индексов в базе данных
(описание в следующем посте)
(описание в следующем посте)
🔥9💯5🤔2👨💻2❤1
Библиотекари в США начали жаловаться, что их просят найти несуществующие книги, которые на самом деле стали результатом галлюцинаций искусственного интеллекта. Этот тренд нарастает с момента выхода GPT-3.5 в конце 2022 года.
Проблема обострилась летом, когда посетители начали запрашивать несуществующие книги, но от реальных авторов. Такие списки для летнего чтения распространялись в специальных выпусках изданий Chicago Sun-Times и The Philadelphia Inquirer. Автор такой подборки признался, что использовал ИИ для составления списка, не проверяя факты.
«К нам приходили люди в библиотеку и спрашивали об этих авторах. Это действительно очень раздражает и серьёзно отбрасывает нас назад в плане информационной грамотности сообщества», — рассказал один из сотрудников учреждения.
«Библиотекари сообщают об общей атмосфере замешательства и недоверия, которую они испытывают со стороны своих читателей. Они видят, что у читателей, по-видимому, снизился уровень критического мышления и любопытства. Они определённо сталкиваются с некоторыми типами психозов и другими проблемами психического здоровья».
https://www.404media.co/librarians-are-being-asked-to-find-ai-hallucinated-books/
Проблема обострилась летом, когда посетители начали запрашивать несуществующие книги, но от реальных авторов. Такие списки для летнего чтения распространялись в специальных выпусках изданий Chicago Sun-Times и The Philadelphia Inquirer. Автор такой подборки признался, что использовал ИИ для составления списка, не проверяя факты.
«К нам приходили люди в библиотеку и спрашивали об этих авторах. Это действительно очень раздражает и серьёзно отбрасывает нас назад в плане информационной грамотности сообщества», — рассказал один из сотрудников учреждения.
«Библиотекари сообщают об общей атмосфере замешательства и недоверия, которую они испытывают со стороны своих читателей. Они видят, что у читателей, по-видимому, снизился уровень критического мышления и любопытства. Они определённо сталкиваются с некоторыми типами психозов и другими проблемами психического здоровья».
https://www.404media.co/librarians-are-being-asked-to-find-ai-hallucinated-books/
404 Media
Librarians Are Being Asked to Find AI-Hallucinated Books
It’s a trippy time to have a library card.
🤓16😁11😭5🤡2👎1
Гендиректор Nvidia: электрики, сантехники и плотники — главные профессии ближайшего будущего для развития ИИ-технологий
Генеральный директор Nvidia Дженсен Хуан в интервью британскому каналу Channel 4 заявил, что для развития ИИ‑технологий самыми ценными кадрами станут те, кто умеют работать руками. Обслуживание ИИ‑систем требует большого количества рабочей силы и сложнейших систем, включая охлаждение, сетевые соединения и электропитание, а также строительства новых ЦОД.
Глава Nvidia считает, что в ближайшие 10–20 лет будет высокий спрос на строительство таких ИИ‑кластеров, а поэтому и зарплаты у электриков, сантехников, плотников и специалистов подобных профессий резко взлетят вверх. Хуан не исключил, что мир стоит на пороге новой промышленной революции — и одной из главных проблем этого перехода станет именно острая нехватка квалифицированных рабочих кадров.
«Если вы электрик, сантехник, плотник, нам понадобятся сотни тысяч таких людей, чтобы построить все эти ИИ‑заводы. И сектор квалифицированных рабочих каждой экономики переживёт бум. Вам придётся строить, вам придётся продолжать удваивать каждый год. И я думаю, что вы будете строить инфраструктуру ИИ здесь, в Великобритании, в течение десятилетия», — пояснил Дженсен Хуан.
https://www.channel4.com/news/electricians-and-plumbers-will-triumph-in-ai-race-nvidia-boss
Генеральный директор Nvidia Дженсен Хуан в интервью британскому каналу Channel 4 заявил, что для развития ИИ‑технологий самыми ценными кадрами станут те, кто умеют работать руками. Обслуживание ИИ‑систем требует большого количества рабочей силы и сложнейших систем, включая охлаждение, сетевые соединения и электропитание, а также строительства новых ЦОД.
Глава Nvidia считает, что в ближайшие 10–20 лет будет высокий спрос на строительство таких ИИ‑кластеров, а поэтому и зарплаты у электриков, сантехников, плотников и специалистов подобных профессий резко взлетят вверх. Хуан не исключил, что мир стоит на пороге новой промышленной революции — и одной из главных проблем этого перехода станет именно острая нехватка квалифицированных рабочих кадров.
«Если вы электрик, сантехник, плотник, нам понадобятся сотни тысяч таких людей, чтобы построить все эти ИИ‑заводы. И сектор квалифицированных рабочих каждой экономики переживёт бум. Вам придётся строить, вам придётся продолжать удваивать каждый год. И я думаю, что вы будете строить инфраструктуру ИИ здесь, в Великобритании, в течение десятилетия», — пояснил Дженсен Хуан.
https://www.channel4.com/news/electricians-and-plumbers-will-triumph-in-ai-race-nvidia-boss
Channel 4 News
Electricians and plumbers will triumph in AI race – Nvidia boss
We took a closer look at the potential economic benefits of this trip for the UK, with those promises from US tech firms to invest £31 billion in Britain. Our economics correspondent Helia Ebrahimi has been talking to the CEO of US chip giant Nvidia about…
😁12🖕9🆒4🤡3🤔1😭1
Основные типы баз данных
(описание к предыдущему посту)
### SQL (Реляционные базы данных)
- Особенности: Индексирование и оптимизация, функции безопасности, поддержка SQL, структурированные данные, транзакции и ACID.
- Примеры: MySQL, Oracle, Microsoft SQL Server, PostgreSQL.
### NoSQL
- Особенности: Горизонтальное масштабирование, высокая доступность, распределенная архитектура.
- Типы:
- Columnar Database: Apache Cassandra, ClickHouse, Druid.
- NewSQL Database: SingleStoreDB, TIDB, CockroachDB.
- Spatial Database: Topology & Network Analysis, интеграция с GIS.
- Graph Database: Neo4j, GraphDB, OrientDB, Amazon Neptune.
- Document Database: MongoDB, CouchDB, MarkLogic, Elasticsearch.
- Key-Value Database: Redis, DynamoDB, BoltDB, Aerospike.
- Time-Series Database: InfluxDB, Prometheus, TimescaleDB, ClickHouse.
### Key-Value Database
- Особенности: Простая модель данных, высокая производительность записи и запросов, политика хранения данных.
- Примеры: Redis, DynamoDB, BoltDB, Aerospike.
### Time-Series Database
- Особенности: Эффективное хранение данных, политики хранения, агрегация по временным окнам.
- Примеры: InfluxDB, Prometheus, TimescaleDB, ClickHouse.
### Graph Database
- Особенности: Глубокий анализ, фокус на отношениях, интеграция с ГИС.
- Примеры: Neo4j, GraphDB, OrientDB, Amazon Neptune.
### Document Database
- Особенности: Гибкая схема, эффективная производительность запросов, управление версиями документов.
- Примеры: MongoDB, CouchDB, MarkLogic, Elasticsearch.
### Object-Oriented Database
- Особенности: Наследование и полиморфизм, инкапсуляция и абстракция данных.
- Примеры: ZODB, ObjectDB, Cache, db4o.
### Spatial Database
- Особенности: Топология и сетевой анализ, интеграция с ГИС.
- Примеры: ArangoDB, CouchDB, Snowflake.
(описание к предыдущему посту)
### SQL (Реляционные базы данных)
- Особенности: Индексирование и оптимизация, функции безопасности, поддержка SQL, структурированные данные, транзакции и ACID.
- Примеры: MySQL, Oracle, Microsoft SQL Server, PostgreSQL.
### NoSQL
- Особенности: Горизонтальное масштабирование, высокая доступность, распределенная архитектура.
- Типы:
- Columnar Database: Apache Cassandra, ClickHouse, Druid.
- NewSQL Database: SingleStoreDB, TIDB, CockroachDB.
- Spatial Database: Topology & Network Analysis, интеграция с GIS.
- Graph Database: Neo4j, GraphDB, OrientDB, Amazon Neptune.
- Document Database: MongoDB, CouchDB, MarkLogic, Elasticsearch.
- Key-Value Database: Redis, DynamoDB, BoltDB, Aerospike.
- Time-Series Database: InfluxDB, Prometheus, TimescaleDB, ClickHouse.
### Key-Value Database
- Особенности: Простая модель данных, высокая производительность записи и запросов, политика хранения данных.
- Примеры: Redis, DynamoDB, BoltDB, Aerospike.
### Time-Series Database
- Особенности: Эффективное хранение данных, политики хранения, агрегация по временным окнам.
- Примеры: InfluxDB, Prometheus, TimescaleDB, ClickHouse.
### Graph Database
- Особенности: Глубокий анализ, фокус на отношениях, интеграция с ГИС.
- Примеры: Neo4j, GraphDB, OrientDB, Amazon Neptune.
### Document Database
- Особенности: Гибкая схема, эффективная производительность запросов, управление версиями документов.
- Примеры: MongoDB, CouchDB, MarkLogic, Elasticsearch.
### Object-Oriented Database
- Особенности: Наследование и полиморфизм, инкапсуляция и абстракция данных.
- Примеры: ZODB, ObjectDB, Cache, db4o.
### Spatial Database
- Особенности: Топология и сетевой анализ, интеграция с ГИС.
- Примеры: ArangoDB, CouchDB, Snowflake.
❤11🔥3👍2
This media is not supported in your browser
VIEW IN TELEGRAM
В любом треугольнике отношение длины стороны к синусу противолежащего ей угла одинаково для всех трех сторон.
🤓39👍12🆒5🤯3👏2👎1
По данным консалтинговой компании Baringa, британские банки до сих пор используют программное обеспечение, написанное в 1960-х и 1970-х годах. В нём разбираются лишь немногие старшие сотрудники.
Согласно опросу 200 банков, 16% из них используют ПО 1960-х годов, а почти 40% поддерживают код 1970-х годов.
При этом 50% представителей банков признались, что используют софт, который понимают лишь один или два сотрудника пенсионного возраста или приближающегося к нему. Ещё 31,5% заявил, что полагаются на одного или двух сотрудников, пока не достигших пенсионного возраста, для понимания устаревших систем.
Около 38 представителей банков ответили, что они до сих пор применяют код, разработанный для работы на физических системах, таких как перфокарты, а 15% — код, написанный для мэйнфреймов размером с комнату.
Один из респондентов отметил, что его банк работает с программным обеспечением Microsoft 1993 года. Сеть банкоматов банка использует устаревшие серверы Windows NT.
Другой отметил, что основные банковские системы были созданы в 1970-х годах и до сих пор используют язык программирования Cobol. Именно он был основной технологией для финансовых и административных систем.
Один из ведущих IT-специалистов в банковском секторе Великобритании, пожелавший остаться анонимным, рассказал, что работал над многими системами, созданными в 1960-х, 1970-х и 1980-х годах.
«Существует много устаревших систем, и причина их долговечности в том, что они были очень простыми, работали корректно и позволяли проводить большие объёмы простых транзакций. Банки отказываются от этих систем, потому что люди, которые их понимают, уходят, а молодые специалисты не хотят изучать такие языки, как Cobol», — добавил он.
Аналогичная ситуация наблюдается не только в Великобритании. В США по состоянию на 2021 год более 80% личных операций в финансовых учреждениях проводили с использованием COBOL. Bank of New York Mellon в 2012 году обнаружил, что использует 112500 отдельных программ COBOL, составляющих почти 350 миллионов строк.
https://www.computerweekly.com/news/366631494/UK-banks-still-run-software-code-written-more-than-60-years-ago
Согласно опросу 200 банков, 16% из них используют ПО 1960-х годов, а почти 40% поддерживают код 1970-х годов.
При этом 50% представителей банков признались, что используют софт, который понимают лишь один или два сотрудника пенсионного возраста или приближающегося к нему. Ещё 31,5% заявил, что полагаются на одного или двух сотрудников, пока не достигших пенсионного возраста, для понимания устаревших систем.
Около 38 представителей банков ответили, что они до сих пор применяют код, разработанный для работы на физических системах, таких как перфокарты, а 15% — код, написанный для мэйнфреймов размером с комнату.
Один из респондентов отметил, что его банк работает с программным обеспечением Microsoft 1993 года. Сеть банкоматов банка использует устаревшие серверы Windows NT.
Другой отметил, что основные банковские системы были созданы в 1970-х годах и до сих пор используют язык программирования Cobol. Именно он был основной технологией для финансовых и административных систем.
Один из ведущих IT-специалистов в банковском секторе Великобритании, пожелавший остаться анонимным, рассказал, что работал над многими системами, созданными в 1960-х, 1970-х и 1980-х годах.
«Существует много устаревших систем, и причина их долговечности в том, что они были очень простыми, работали корректно и позволяли проводить большие объёмы простых транзакций. Банки отказываются от этих систем, потому что люди, которые их понимают, уходят, а молодые специалисты не хотят изучать такие языки, как Cobol», — добавил он.
Аналогичная ситуация наблюдается не только в Великобритании. В США по состоянию на 2021 год более 80% личных операций в финансовых учреждениях проводили с использованием COBOL. Bank of New York Mellon в 2012 году обнаружил, что использует 112500 отдельных программ COBOL, составляющих почти 350 миллионов строк.
https://www.computerweekly.com/news/366631494/UK-banks-still-run-software-code-written-more-than-60-years-ago
ComputerWeekly.com
UK banks still run software code written more than 60 years ago
Over half of UK banks still rely on computer code written in or before the 1970s which is understood by only a few of their staff
🤯21👍13🔥6😁6❤1😐1
Основные модели контроля доступа
(продолжение предыдущего поста)
### Role-Based Access Control (RBAC)
RBAC используется для управления доступом на основе ролей. На примере показано, как пользователь Alice пытается выполнить действие (например, слить запрос на слияние в GitHub). Процесс включает:
- Определение роли пользователя (например, Maintainer).
- Проверка разрешений, связанных с этой ролью (например, Merge Pull Request, Push Code, Manage Issues).
- Если разрешения удовлетворяют требованиям, доступ разрешается.
### Attribute-Based Access Control (ABAC)
ABAC основан на атрибутах пользователей, ресурсов и контекста. На примере показано:
- Пользователь Dana пытается открыть файл Budget.xlsx.
- Система проверяет атрибуты пользователя (например, отдел, уровень доступа), атрибуты ресурса (например, классификация) и контекст (например, IP-адрес, время).
- Если все условия удовлетворены, доступ разрешается.
### Access Control List (ACL)
ACL определяет доступ к ресурсам через списки контроля доступа. На примере показано:
- Пользователь Evan пытается отредактировать файл Budget.xlsx.
- Система проверяет ACL для файла, чтобы определить, имеет ли пользователь права на редактирование.
- Если права есть, доступ разрешается.
Эти модели помогают управлять доступом к ресурсам в зависимости от ролей, атрибутов и конкретных правил.
(продолжение предыдущего поста)
### Role-Based Access Control (RBAC)
RBAC используется для управления доступом на основе ролей. На примере показано, как пользователь Alice пытается выполнить действие (например, слить запрос на слияние в GitHub). Процесс включает:
- Определение роли пользователя (например, Maintainer).
- Проверка разрешений, связанных с этой ролью (например, Merge Pull Request, Push Code, Manage Issues).
- Если разрешения удовлетворяют требованиям, доступ разрешается.
### Attribute-Based Access Control (ABAC)
ABAC основан на атрибутах пользователей, ресурсов и контекста. На примере показано:
- Пользователь Dana пытается открыть файл Budget.xlsx.
- Система проверяет атрибуты пользователя (например, отдел, уровень доступа), атрибуты ресурса (например, классификация) и контекст (например, IP-адрес, время).
- Если все условия удовлетворены, доступ разрешается.
### Access Control List (ACL)
ACL определяет доступ к ресурсам через списки контроля доступа. На примере показано:
- Пользователь Evan пытается отредактировать файл Budget.xlsx.
- Система проверяет ACL для файла, чтобы определить, имеет ли пользователь права на редактирование.
- Если права есть, доступ разрешается.
Эти модели помогают управлять доступом к ресурсам в зависимости от ролей, атрибутов и конкретных правил.
Telegram
METANIT.COM
Основные модели контроля доступа
(продолжение в следующем посте)
(продолжение в следующем посте)
👍5👏3🔥2
Микросервисная архитектура
(описание предыдущего поста)
Представьте город с множеством специализированных магазинов вместо одного гигантского супермаркета. Каждый магазин специализируется на чём-то одном: пекарня, мясная лавка, аптека, магазин одежды и так далее. Вместе они обслуживают весь город, но каждый может работать независимо.
Компоненты
* Пользовательский интерфейс = Карта города / Навигационное приложение → Помогает клиентам находить нужный магазин.
* Бизнес-сервисы = Отдельные магазины → Каждый выполняет определённую задачу (платежи, заказы, доставка и т.д.).
* Коммуникации = Дороги и грузовики доставки → Позволяют магазинам обмениваться товарами (API).
* База данных = Складские помещения магазинов → Каждый магазин управляет собственным хранилищем и запасами.
Принцип работы
* Клиент посещает карту → Находит магазин → Магазин обрабатывает запрос → Использует свой склад → Клиент получает услугу/продукт.
Преимущества
* Гибкость → Каждый магазин может выбирать собственные инструменты и стиль работы.
* Масштабируемость → Популярные магазины могут расширяться, не влияя на работу других.
* Изоляция сбоев → Если один магазин закрывается, остальные продолжают работу.
* Быстрые инновации → Новые магазины могут открываться без изменения всей системы.
Недостатки
* Сложность → Чем больше магазинов, тем сложнее логистика.
* Сетевые издержки → Доставки (API-запросы) требуют времени.
* Согласованность данных → Каждый магазин управляет собственными запасами, что усложняет синхронизацию.
* Сложность мониторинга → Требуются системы управления всем городом.
Лучшие практики
* Используйте чёткие правила движения (стандарты API) для бесперебойной коммуникации.
* Добавьте управление трафиком (балансировщики нагрузки, обнаружение сервисов).
* Поддерживайте порядок на складах (базах данных) и создавайте резервные копии.
* Контролируйте работу магазинов с помощью централизованных инструментов (наблюдаемость, логирование).
* Проектируйте с учётом отказоустойчивости (запасные варианты, повторные попытки).
Когда использовать
* Крупномасштабные «города» (системы) с множеством различных потребностей.
* Команды, способные управлять независимыми сервисами (магазинами).
* Бизнес, которому требуется быстрое масштабирование или частые обновления функций.
(описание предыдущего поста)
Представьте город с множеством специализированных магазинов вместо одного гигантского супермаркета. Каждый магазин специализируется на чём-то одном: пекарня, мясная лавка, аптека, магазин одежды и так далее. Вместе они обслуживают весь город, но каждый может работать независимо.
Компоненты
* Пользовательский интерфейс = Карта города / Навигационное приложение → Помогает клиентам находить нужный магазин.
* Бизнес-сервисы = Отдельные магазины → Каждый выполняет определённую задачу (платежи, заказы, доставка и т.д.).
* Коммуникации = Дороги и грузовики доставки → Позволяют магазинам обмениваться товарами (API).
* База данных = Складские помещения магазинов → Каждый магазин управляет собственным хранилищем и запасами.
Принцип работы
* Клиент посещает карту → Находит магазин → Магазин обрабатывает запрос → Использует свой склад → Клиент получает услугу/продукт.
Преимущества
* Гибкость → Каждый магазин может выбирать собственные инструменты и стиль работы.
* Масштабируемость → Популярные магазины могут расширяться, не влияя на работу других.
* Изоляция сбоев → Если один магазин закрывается, остальные продолжают работу.
* Быстрые инновации → Новые магазины могут открываться без изменения всей системы.
Недостатки
* Сложность → Чем больше магазинов, тем сложнее логистика.
* Сетевые издержки → Доставки (API-запросы) требуют времени.
* Согласованность данных → Каждый магазин управляет собственными запасами, что усложняет синхронизацию.
* Сложность мониторинга → Требуются системы управления всем городом.
Лучшие практики
* Используйте чёткие правила движения (стандарты API) для бесперебойной коммуникации.
* Добавьте управление трафиком (балансировщики нагрузки, обнаружение сервисов).
* Поддерживайте порядок на складах (базах данных) и создавайте резервные копии.
* Контролируйте работу магазинов с помощью централизованных инструментов (наблюдаемость, логирование).
* Проектируйте с учётом отказоустойчивости (запасные варианты, повторные попытки).
Когда использовать
* Крупномасштабные «города» (системы) с множеством различных потребностей.
* Команды, способные управлять независимыми сервисами (магазинами).
* Бизнес, которому требуется быстрое масштабирование или частые обновления функций.
Telegram
METANIT.COM
Микросервисная архитектура
(описание в следующем посте)
(описание в следующем посте)
🤔8❤3👏1
Все, кто ранее называл MAX православным менеджером, оказались неправы. Теперь в России заработал действительно православный мессенджер - «Зосима»
Новый мессенджер для верующих уже можно скачать в Google Play.
В «Зосиме» блокируются мат и непристойные сообщения, мемы, оскорбления, черный юмор и другой контент, не соответствующий тематике мессенджера. В «Зосиме» священники могут вести свои блоги, а пользователи создавать групповые чаты, организовывать церковные приходы, публиковать проповеди, делиться новостями из жизни церквей, а также сообщать о проблемах с храмами.
Приложение сочетает в себе все возможности современных социальных сетей:
- Поиск друзей и единомышленников;
- Создание чатов и групп;
- Общение через мгновенные сообщения;
- Подписки на интересующие сообщества;
- Обмен документами и медиафайлами.
https://hi-tech.mail.ru/news/134353-v-rossii-zarabotal-pravoslavnyj-messendzher-zosima/
Новый мессенджер для верующих уже можно скачать в Google Play.
В «Зосиме» блокируются мат и непристойные сообщения, мемы, оскорбления, черный юмор и другой контент, не соответствующий тематике мессенджера. В «Зосиме» священники могут вести свои блоги, а пользователи создавать групповые чаты, организовывать церковные приходы, публиковать проповеди, делиться новостями из жизни церквей, а также сообщать о проблемах с храмами.
Приложение сочетает в себе все возможности современных социальных сетей:
- Поиск друзей и единомышленников;
- Создание чатов и групп;
- Общение через мгновенные сообщения;
- Подписки на интересующие сообщества;
- Обмен документами и медиафайлами.
https://hi-tech.mail.ru/news/134353-v-rossii-zarabotal-pravoslavnyj-messendzher-zosima/
🤣47👍7🤮6❤4🙈4👏2😇1
6 основных типов тестирования API:
(описание к предыдущей статье)
1. Stress Testing (Стресс-тестирование)
- Цель: Проверка устойчивости API при высоких нагрузках.
- Процесс: Использование тестовых движков для создания высоких нагрузок и анализ работы приложения.
2. Integration Testing (Интеграционное тестирование)
- Цель: Проверка взаимодействия между различными компонентами системы.
- Процесс: Создание тестового плана, ввод данных, сравнение результатов с ожидаемыми.
3. Load Testing (Нагрузочное тестирование)
- Цель: Оценка производительности API при различных нагрузках.
- Процесс: Использование тестовых движков и инструментов, таких как Apache JMeter, для симуляции нагрузок.
4. Regression Testing (Регрессионное тестирование)
- Цель: Убедиться, что новые изменения не нарушают существующую функциональность.
- Процесс: Сравнение результатов старого и нового приложений с использованием входных данных.
5. Functional Testing (Функциональное тестирование)
- Цель: Проверка соответствия функциональности API заявленным требованиям.
- Процесс: Использование функциональной спецификации, ввод данных, сравнение результатов с ожидаемыми.
6. Smoke Testing (Дымовое тестирование)
- Цель: Быстрая проверка основных функций API после разработки.
- Процесс: Ввод данных и проверка, работает ли приложение без ошибок.
(описание к предыдущей статье)
1. Stress Testing (Стресс-тестирование)
- Цель: Проверка устойчивости API при высоких нагрузках.
- Процесс: Использование тестовых движков для создания высоких нагрузок и анализ работы приложения.
2. Integration Testing (Интеграционное тестирование)
- Цель: Проверка взаимодействия между различными компонентами системы.
- Процесс: Создание тестового плана, ввод данных, сравнение результатов с ожидаемыми.
3. Load Testing (Нагрузочное тестирование)
- Цель: Оценка производительности API при различных нагрузках.
- Процесс: Использование тестовых движков и инструментов, таких как Apache JMeter, для симуляции нагрузок.
4. Regression Testing (Регрессионное тестирование)
- Цель: Убедиться, что новые изменения не нарушают существующую функциональность.
- Процесс: Сравнение результатов старого и нового приложений с использованием входных данных.
5. Functional Testing (Функциональное тестирование)
- Цель: Проверка соответствия функциональности API заявленным требованиям.
- Процесс: Использование функциональной спецификации, ввод данных, сравнение результатов с ожидаемыми.
6. Smoke Testing (Дымовое тестирование)
- Цель: Быстрая проверка основных функций API после разработки.
- Процесс: Ввод данных и проверка, работает ли приложение без ошибок.
Telegram
METANIT.COM
6 основных типов тестирования API
(описание в следующей статье)
(описание в следующей статье)
🔥6👍3❤2