Основные типы баз данных
(описание к предыдущему посту)
### 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
8 наиболее распространенных типов кибератак
(описание в следующем посте)
(описание в следующем посте)
8 наиболее распространенных типов кибератак:
(описание к предыдущему посту)
1. Фишинговая атака (Phishing Attack)
- Использование обманных писем, сообщений или сайтов для получения конфиденциальной информации.
- Пример: злоумышленник отправляет ссылку, пользователь открывает её, и хакер получает доступ к учётным данным.
2. Программа-вымогатель (Ransomware)
- Программное обеспечение, которое шифрует файлы и требует выкуп за их разблокировку.
- Пример: заражённый USB-накопитель инфицирует устройство, данные блокируются, и злоумышленник требует выкуп.
3. Отказ в обслуживании (DoS)
- Перегрузка системы или сети для нарушения её нормальной работы.
- Пример: бот-сеть атакует сервер, вызывая его недоступность.
4. Атака «человек посередине» (MitM)
- Перехват и изменение коммуникации между двумя сторонами без их ведома.
- Пример: злоумышленник вставляет себя в канал связи между пользователем и веб-приложением.
5. SQL-инъекция (SQL Injection)
- Использование уязвимостей в запросах к базе данных для получения несанкционированного доступа.
- Пример: злоумышленник отправляет вредоносный запрос, и сервер возвращает данные всех пользователей.
6. Межсайтовый скриптинг (XSS)
- Внедрение вредоносных скриптов на веб-сайты, которые просматриваются другими пользователями.
- Пример: вставка скрипта в базу данных, который затем выполняется в браузере жертвы.
7. Эксплойты нулевого дня (Zero-Day Exploits)
- Атака, использующая неизвестные уязвимости до того, как разработчики смогут их устранить.
- Пример: злоумышленник обнаруживает уязвимость, запускает атаку, а разработчики не успевают её устранить.
8. Спуфинг DNS (DNS Spoofing)
- Перенаправление запросов DNS на вредоносные сайты для несанкционированного доступа.
- Пример: злоумышленник вводит фальшивую запись DNS, и запрос пользователя перенаправляется на поддельный сайт.
(описание к предыдущему посту)
1. Фишинговая атака (Phishing Attack)
- Использование обманных писем, сообщений или сайтов для получения конфиденциальной информации.
- Пример: злоумышленник отправляет ссылку, пользователь открывает её, и хакер получает доступ к учётным данным.
2. Программа-вымогатель (Ransomware)
- Программное обеспечение, которое шифрует файлы и требует выкуп за их разблокировку.
- Пример: заражённый USB-накопитель инфицирует устройство, данные блокируются, и злоумышленник требует выкуп.
3. Отказ в обслуживании (DoS)
- Перегрузка системы или сети для нарушения её нормальной работы.
- Пример: бот-сеть атакует сервер, вызывая его недоступность.
4. Атака «человек посередине» (MitM)
- Перехват и изменение коммуникации между двумя сторонами без их ведома.
- Пример: злоумышленник вставляет себя в канал связи между пользователем и веб-приложением.
5. SQL-инъекция (SQL Injection)
- Использование уязвимостей в запросах к базе данных для получения несанкционированного доступа.
- Пример: злоумышленник отправляет вредоносный запрос, и сервер возвращает данные всех пользователей.
6. Межсайтовый скриптинг (XSS)
- Внедрение вредоносных скриптов на веб-сайты, которые просматриваются другими пользователями.
- Пример: вставка скрипта в базу данных, который затем выполняется в браузере жертвы.
7. Эксплойты нулевого дня (Zero-Day Exploits)
- Атака, использующая неизвестные уязвимости до того, как разработчики смогут их устранить.
- Пример: злоумышленник обнаруживает уязвимость, запускает атаку, а разработчики не успевают её устранить.
8. Спуфинг DNS (DNS Spoofing)
- Перенаправление запросов DNS на вредоносные сайты для несанкционированного доступа.
- Пример: злоумышленник вводит фальшивую запись DNS, и запрос пользователя перенаправляется на поддельный сайт.
Telegram
METANIT.COM
8 наиболее распространенных типов кибератак
(описание в следующем посте)
(описание в следующем посте)
Android для ПК появится в следующем году
Генеральный директор Qualcomm Криштиану Амон сообщил в ходе саммита Qualcomm Snapdragon в Мауи, что Google объединит Android и ChromeOS для создания новой операционной системы для компьютеров.
«Это то, чего мы очень ждём в следующем году», — подтвердил глава экосистемы Android Самир Самат.
По его словам, «открывающаяся возможность заключается в том, как ускорить развитие ИИ, которое мы реализуем на Android, и как можно быстрее перенести его в форм-фактор ноутбука, обеспечив при этом бесперебойную работу ноутбука и остальной экосистемы Android».
https://www.youtube.com/live/fpHCkdIg9gU?t=4655s
#android
Генеральный директор Qualcomm Криштиану Амон сообщил в ходе саммита Qualcomm Snapdragon в Мауи, что Google объединит Android и ChromeOS для создания новой операционной системы для компьютеров.
«Это то, чего мы очень ждём в следующем году», — подтвердил глава экосистемы Android Самир Самат.
По его словам, «открывающаяся возможность заключается в том, как ускорить развитие ИИ, которое мы реализуем на Android, и как можно быстрее перенести его в форм-фактор ноутбука, обеспечив при этом бесперебойную работу ноутбука и остальной экосистемы Android».
https://www.youtube.com/live/fpHCkdIg9gU?t=4655s
#android
YouTube
Snapdragon Summit 2025 Product Announcements Keynote
The next generation of mobile and compute platforms has arrived. Join us as Alex Katouzian, General Manager for Mobile, Compute and XR and Kedar Kondap, Senior Vice President and General Manager for Compute and Gaming reveal the latest technology from Snapdragon.…
🤔10🤷♂3🤡3🔥2❤1🤪1
Редакторы журнала IEEE Spectrum опубликовали ежегодный рейтинг языков программирования. В списке популярных языков традиционно лидируют Python, Java, C++ и SQL.
В «Spectrum» отмечают, что самым большим изменением в пятёрке лидеров стало падение JavaScript с 3-его места в прошлом году на 6-ое в этом году. Издатели связывают это падение с тем, что, поскольку JavaScript часто используется для создания веб-страниц, а Vibe-кодинг такэе часто применяется для создания веб-сайтов, то это падение может быть связано с влиянием ИИ.
В рейтинге «Jobs», который учитывает исключительно навыки, востребованные работодателями, Python также занял первое место, поднявшись со второго места в прошлом году, хотя знание SQL остаётся невероятно ценным навыком для резюме.
https://spectrum.ieee.org/top-programming-languages-2025
В «Spectrum» отмечают, что самым большим изменением в пятёрке лидеров стало падение JavaScript с 3-его места в прошлом году на 6-ое в этом году. Издатели связывают это падение с тем, что, поскольку JavaScript часто используется для создания веб-страниц, а Vibe-кодинг такэе часто применяется для создания веб-сайтов, то это падение может быть связано с влиянием ИИ.
В рейтинге «Jobs», который учитывает исключительно навыки, востребованные работодателями, Python также занял первое место, поднявшись со второго места в прошлом году, хотя знание SQL остаётся невероятно ценным навыком для резюме.
https://spectrum.ieee.org/top-programming-languages-2025
👍3❤1
Вкратце по шаблонам проектирования
Почему шаблоны проектирования важны?
1. Возможность повторного использования
* Проверенные решения, которые работают в разных проектах
2. Гибкость
* Способствуют слабой связности компонентов и упрощают поддержку
3. Коммуникация
* Создают общий язык для обсуждения проблем проектирования и их решений
4. Опыт
* Инкапсулируют опыт опытных разработчиков, помогая другим избегать типичных ошибок и создавать более качественное ПО
Рассмотрим основные задачи которые решают шаблоны.
Порождающие шаблоны
1. Абстрактная фабрика
* Создаёт семейства взаимосвязанных объектов через общий интерфейс
2. Строитель
* Разделяет построение сложного объекта от его представления
3. Фабричный метод
* Определяет интерфейс для создания объектов
* Позволяет подклассам выбирать конкретный класс для создания
4. Прототип
* Создаёт новые объекты путём копирования прототипа
5. Одиночка
* Гарантирует, что класс имеет только один экземпляр
Структурные шаблоны
6. Адаптер
* Преобразует один интерфейс в другой, позволяя несовместимым классам работать вместе
7. Мост
* Разделяет абстракцию и реализацию, позволяя им изменяться независимо
8. Компоновщик
* Обрабатывает отдельные объекты и их композиции единообразно, представляя иерархии часть-целое
9. Декоратор
* Динамически добавляет функциональность объекту без использования наследования
10. Фасад
* Предоставляет упрощённый интерфейс к сложной подсистеме
11. Лёгковес
* Разделяет объекты для уменьшения использования памяти при большом количестве мелких объектов
12. Заместитель
* Контролирует доступ к объекту, предоставляя различные возможности, такие как отложенная загрузка или удалённый доступ
Поведенческие шаблоны
13. Цепочка ответственности
* Разделяет отправителей и получателей запросов, позволяя нескольким объектам обрабатывать запрос
14. Команда
* Инкапсулирует запросы в объекты, позволяя вести логирование, создавать очереди и выполнять операции отмены/повтора
15. Интерпретатор
* Определяет грамматику языка и интерпретатор для выполнения выражений
16. Итератор
* Обеспечивает последовательный доступ к элементам агрегата без раскрытия внутреннего представления
17. Посредник
* Инкапсулирует взаимодействие объектов, способствуя слабой связности
18. Хранитель
* Сохраняет и восстанавливает состояние объекта без нарушения инкапсуляции
19. Наблюдатель
* Автоматически уведомляет зависимые объекты при изменении состояния
20. Состояние
* Изменяет поведение объекта при изменении его внутреннего состояния
21. Стратегия
* Инкапсулирует взаимозаменяемые алгоритмы, позволяя клиентам выбирать их динамически
22. Шаблонный метод
* Определяет скелет алгоритма, откладывая шаги реализации на подклассы
23. Посетитель
* Добавляет новые операции к структурам объектов без изменения классов элементов
Почему шаблоны проектирования важны?
1. Возможность повторного использования
* Проверенные решения, которые работают в разных проектах
2. Гибкость
* Способствуют слабой связности компонентов и упрощают поддержку
3. Коммуникация
* Создают общий язык для обсуждения проблем проектирования и их решений
4. Опыт
* Инкапсулируют опыт опытных разработчиков, помогая другим избегать типичных ошибок и создавать более качественное ПО
Рассмотрим основные задачи которые решают шаблоны.
Порождающие шаблоны
1. Абстрактная фабрика
* Создаёт семейства взаимосвязанных объектов через общий интерфейс
2. Строитель
* Разделяет построение сложного объекта от его представления
3. Фабричный метод
* Определяет интерфейс для создания объектов
* Позволяет подклассам выбирать конкретный класс для создания
4. Прототип
* Создаёт новые объекты путём копирования прототипа
5. Одиночка
* Гарантирует, что класс имеет только один экземпляр
Структурные шаблоны
6. Адаптер
* Преобразует один интерфейс в другой, позволяя несовместимым классам работать вместе
7. Мост
* Разделяет абстракцию и реализацию, позволяя им изменяться независимо
8. Компоновщик
* Обрабатывает отдельные объекты и их композиции единообразно, представляя иерархии часть-целое
9. Декоратор
* Динамически добавляет функциональность объекту без использования наследования
10. Фасад
* Предоставляет упрощённый интерфейс к сложной подсистеме
11. Лёгковес
* Разделяет объекты для уменьшения использования памяти при большом количестве мелких объектов
12. Заместитель
* Контролирует доступ к объекту, предоставляя различные возможности, такие как отложенная загрузка или удалённый доступ
Поведенческие шаблоны
13. Цепочка ответственности
* Разделяет отправителей и получателей запросов, позволяя нескольким объектам обрабатывать запрос
14. Команда
* Инкапсулирует запросы в объекты, позволяя вести логирование, создавать очереди и выполнять операции отмены/повтора
15. Интерпретатор
* Определяет грамматику языка и интерпретатор для выполнения выражений
16. Итератор
* Обеспечивает последовательный доступ к элементам агрегата без раскрытия внутреннего представления
17. Посредник
* Инкапсулирует взаимодействие объектов, способствуя слабой связности
18. Хранитель
* Сохраняет и восстанавливает состояние объекта без нарушения инкапсуляции
19. Наблюдатель
* Автоматически уведомляет зависимые объекты при изменении состояния
20. Состояние
* Изменяет поведение объекта при изменении его внутреннего состояния
21. Стратегия
* Инкапсулирует взаимозаменяемые алгоритмы, позволяя клиентам выбирать их динамически
22. Шаблонный метод
* Определяет скелет алгоритма, откладывая шаги реализации на подклассы
23. Посетитель
* Добавляет новые операции к структурам объектов без изменения классов элементов
👍10🔥7🤓5👏1
Cравнение двух методов аутентификации и хранения данных в веб-приложениях: Куки и Сессии.
(продолжение в следующем посте)
(продолжение в следующем посте)