Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(описание в следующем посте)
(описание в следующем посте)
❤2👍2💯2
Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(продолжение предыдущего поста)
→ MVC разделяет приложение на три основных компонента для разграничения ответственностей и повышения удобства сопровождения: Модель, Представление и Контроллер.
→ Представление отвечает за отображение, Контроллер — за обработку ввода и управление потоком, Модель — за данные и бизнес‑правила.
Компоненты
→ Представление (UI) → Отображает данные и обрабатывает взаимодействия пользователя (веб‑страницы, экраны мобильных приложений).
→ Контроллер → Получает ввод от Представления, интерпретирует его, вызывает Модель или обновляет Представление.
→ Модель → Содержит данные приложения и бизнес‑логику; уведомляет Представление об изменениях состояния.
→ База данных / Хранилище → Постоянное хранилище, из которого Модель считывает данные и в которое записывает их.
Поток данных (упрощённо)
→ Представление —(ввод пользователя)→ Контроллер —(вызывает)→ Модель —(считывает/записывает)→ База данных
→ Модель —(уведомляет)→ Представление —(отображает обновлённые данные)→ Пользователь
Преимущества
→ Чёткое разделение ответственностей → упрощение тестирования и параллельной разработки.
→ Повторное использование компонентов — несколько Представлений могут использовать одну и ту же Модель.
→ Более чёткая организация логики интерфейса по сравнению с бизнес‑логикой.
Недостатки
→ Может стать избыточным при большом количестве контроллеров/представлений в крупных приложениях.
→ Возможна тесная связность, если ответственности не разделены чётко.
→ Не всегда оптимально подходит для высокоинтерактивных клиентских интерфейсов без адаптации (например, MVVM или Flux могут быть предпочтительнее).
Распространенные рекомендации по использованию
→ Делайте Контроллеры «лёгкими» — делегируйте бизнес‑логику Моделям или сервисам.
→ Представления без бизнес-логики только для отображения данных и передачи событий
→ Применение шаблона Наблюдатель (observer) или привязки данных, чтобы Представления автоматически обновлялись при изменении Модели.
→ Отедбные юнит‑тесты для Моделей и Контроллеров
→ В крупных проектах организуйте код по функциональным возможностям, а не только по уровням MVC.
(продолжение предыдущего поста)
→ MVC разделяет приложение на три основных компонента для разграничения ответственностей и повышения удобства сопровождения: Модель, Представление и Контроллер.
→ Представление отвечает за отображение, Контроллер — за обработку ввода и управление потоком, Модель — за данные и бизнес‑правила.
Компоненты
→ Представление (UI) → Отображает данные и обрабатывает взаимодействия пользователя (веб‑страницы, экраны мобильных приложений).
→ Контроллер → Получает ввод от Представления, интерпретирует его, вызывает Модель или обновляет Представление.
→ Модель → Содержит данные приложения и бизнес‑логику; уведомляет Представление об изменениях состояния.
→ База данных / Хранилище → Постоянное хранилище, из которого Модель считывает данные и в которое записывает их.
Поток данных (упрощённо)
→ Представление —(ввод пользователя)→ Контроллер —(вызывает)→ Модель —(считывает/записывает)→ База данных
→ Модель —(уведомляет)→ Представление —(отображает обновлённые данные)→ Пользователь
Преимущества
→ Чёткое разделение ответственностей → упрощение тестирования и параллельной разработки.
→ Повторное использование компонентов — несколько Представлений могут использовать одну и ту же Модель.
→ Более чёткая организация логики интерфейса по сравнению с бизнес‑логикой.
Недостатки
→ Может стать избыточным при большом количестве контроллеров/представлений в крупных приложениях.
→ Возможна тесная связность, если ответственности не разделены чётко.
→ Не всегда оптимально подходит для высокоинтерактивных клиентских интерфейсов без адаптации (например, MVVM или Flux могут быть предпочтительнее).
Распространенные рекомендации по использованию
→ Делайте Контроллеры «лёгкими» — делегируйте бизнес‑логику Моделям или сервисам.
→ Представления без бизнес-логики только для отображения данных и передачи событий
→ Применение шаблона Наблюдатель (observer) или привязки данных, чтобы Представления автоматически обновлялись при изменении Модели.
→ Отедбные юнит‑тесты для Моделей и Контроллеров
→ В крупных проектах организуйте код по функциональным возможностям, а не только по уровням MVC.
Telegram
METANIT.COM
Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(описание в следующем посте)
(описание в следующем посте)
❤2👍2🔥2
Глава Alphabet (Google) Сундар Пичаи сравнил вайб-кодинг с ростом популярности блогов и YouTube, но предупредил, что явление не должно затрагивать критически важные системы.
Гендиректор Google рассказал о резком росте числа вайб-кодеров, но предупредил, что продукт их работы не подходит для крупных кодовых баз, критически важных с точки зрения безопасности.
Пичаи отметил, что инструменты, основанные на больших языковых моделях, делают программирование «более приятным» и «доступным», поскольку люди могут тестировать идеи для приложений и веб-сайтов, не разбираясь сначала в синтаксисе или фреймворках. По его словам, этот сдвиг уже заметен в репозиториях Google.
В то же время глава Google подчеркнул, что не применяет вайб-кодинг к обширным кодовым базам, «где действительно нужно сделать всё правильно».
https://www.techspot.com/news/110434-google-ceo-vibe-coding-reshaping-who-gets-write.html
Гендиректор Google рассказал о резком росте числа вайб-кодеров, но предупредил, что продукт их работы не подходит для крупных кодовых баз, критически важных с точки зрения безопасности.
Пичаи отметил, что инструменты, основанные на больших языковых моделях, делают программирование «более приятным» и «доступным», поскольку люди могут тестировать идеи для приложений и веб-сайтов, не разбираясь сначала в синтаксисе или фреймворках. По его словам, этот сдвиг уже заметен в репозиториях Google.
В то же время глава Google подчеркнул, что не применяет вайб-кодинг к обширным кодовым базам, «где действительно нужно сделать всё правильно».
https://www.techspot.com/news/110434-google-ceo-vibe-coding-reshaping-who-gets-write.html
TechSpot
Google's CEO says "vibe coding" is reshaping who gets to write code
Pichai made the comments on a Google for Developers podcast with Logan Kilpatrick, who runs Google's AI Studio. The CEO said tools built on large language models...
👍8❤6🤮3🤔2👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Известный исследователь в области искуственного интеллекта Ян Лекун (Yann LeCun) утверждает, что модели LLM сами по себе не являются пузырем ни в плане стоимости, ни в плане инвестиций — они будут способствовать развитию множества реальных приложений и оправдывать текущие расходы на инфраструктуру.
Настоящий пузырь же кроется в предположении, что модели LLM смогут мыслить на уровне человека.
Настоящий пузырь же кроется в предположении, что модели LLM смогут мыслить на уровне человека.
😁24💯18🔥5👍4🖕4🤔2
Линус Торвальдс и Линус Себастьян из Linus Tech Tips провели сборку идеального ПК для Linux
Для создания мощной рабочей системы Линусы выбрали:
- процессор CPU AMD Ryzen Threadripper 9960X с 24 ядрами и 48 потоками;
- ОЗУ Kingston 16 ГБ DDR5 х4;
- видеокарту Intel Arc B580;
- материнскую плату GIGABYTE TRX50 AERO D;
- SSD-накопитель Samsung 9100 PRO 2TB;
- кулер Noctua NH-U14S TR5-SP6;
- блок питания Seasonic PRIME TX-1600 1600W 80+ Titanium;
- системный блок Fractal Design Torrent E-ATX Case;
- 31.5-дюймовый монитор Asus ProArt PA32QCV (6K HDR).
Всю сборку выполнил Линус Себастьян, а Торвальдс только пояснял, какие элементы ему больше нравятся (воздушное охлаждение, ECC-память).
https://youtu.be/mfv0V1SxbNA
https://linustechtips.com/topic/1627666-building-the-perfect-linux-pc-with-linus-torvalds/
Для создания мощной рабочей системы Линусы выбрали:
- процессор CPU AMD Ryzen Threadripper 9960X с 24 ядрами и 48 потоками;
- ОЗУ Kingston 16 ГБ DDR5 х4;
- видеокарту Intel Arc B580;
- материнскую плату GIGABYTE TRX50 AERO D;
- SSD-накопитель Samsung 9100 PRO 2TB;
- кулер Noctua NH-U14S TR5-SP6;
- блок питания Seasonic PRIME TX-1600 1600W 80+ Titanium;
- системный блок Fractal Design Torrent E-ATX Case;
- 31.5-дюймовый монитор Asus ProArt PA32QCV (6K HDR).
Всю сборку выполнил Линус Себастьян, а Торвальдс только пояснял, какие элементы ему больше нравятся (воздушное охлаждение, ECC-память).
https://youtu.be/mfv0V1SxbNA
https://linustechtips.com/topic/1627666-building-the-perfect-linux-pc-with-linus-torvalds/
YouTube
Building the PERFECT Linux PC with Linus Torvalds
Get a free 15-day trial of Odoo’s all-in-one business solution and see how it can make your life easier! Check it out at https://www.odoo.com/ltt
It is finally here, the computer build you have (and possibly the whole world) been waiting for. The Linus Tech…
It is finally here, the computer build you have (and possibly the whole world) been waiting for. The Linus Tech…
🤡24🐳17❤7🤣3🏆3😎3👀1
Механизмы авторизации API
(продолжение к предыдущему посту)
Контроль разрешений пользователей в современных API
1. Управление доступом на основе ролей (RBAC, Role‑Based Access Control)
→ Определение
✓ Назначает разрешения на основе роли пользователя (администратор, редактор, зритель).
→ Как это работает
✓ Пользователи → Назначенные роли → Роли → Предоставление разрешений.
→ Оптимально для
✓ Систем с чётко определёнными группами разрешений.
✓ Панелей управления, SaaS‑приложений, CMS‑платформ.
2. Управление доступом на основе атрибутов (ABAC, Attribute‑Based Access Control)
→ Определение
✓ Принимает решения об авторизации на основе атрибутов.
→ Атрибуты включают
✓ Атрибуты пользователя (возраст, отдел, подписка).
✓ Атрибуты ресурса (тип, владелец).
✓ Атрибуты среды (время, местоположение).
→ Оптимально для
✓ Предприятий с сложными и динамическими правилами доступа.
3. Фреймворк авторизации OAuth 2.0
→ Определение
✓ Делегированная авторизация, которая позволяет сторонним приложениям получать доступ к ресурсам без раскрытия паролей пользователей.
→ Как это работает
✓ Аутентификация через провайдера → Выдача токена доступа → API проверяет токен.
→ Распространённые потоки
✓ Код авторизации (Authorization Code).
✓ Учётные данные клиента (Client Credentials).
✓ Потолок для устройств (Device Flow).
→ Оптимально для
✓ Приложений, требующих входа через соцсети или безопасного делегированного доступа.
4. OpenID Connect (OIDC)
→ Определение
✓ Уровень идентификации, построенный на базе OAuth 2.0.
✓ Добавляет проверку личности пользователя с помощью ID‑токенов.
→ Что предоставляет
✓ Проверенную идентификацию.
✓ Единый вход (SSO, Single Sign‑On).
✓ Стандартные утверждения (имя, электронная почта и т. д.).
→ Оптимально для
✓ Систем аутентификации и авторизации.
5. Авторизация с помощью JSON‑веб‑токенов (JWT, JSON Web Token)
→ Определение
✓ Авторизация осуществляется с помощью подписанных JSON‑токенов.
→ Как это работает
✓ Пользователь входит в систему → Сервер выдаёт JWT, содержащий утверждения → Клиент отправляет токен с каждым запросом.
→ Преимущества
✓ Отсутствие состояния (stateless).
✓ Идеально для распределённых микросервисов.
→ Оптимально для
✓ Мобильных приложений, одностраничных приложений (SPA), современных REST API.
6. Управление доступом на основе политик (PBAC, Policy‑Based Access Control)
→ Определение
✓ Решения о доступе принимаются с использованием централизованных политик.
→ Как это работает
✓ Механизм политик проверяет правила → Разрешает или отклоняет запрос.
→ Оптимально для
✓ Государственных систем.
✓ Среды с жёсткими требованиями соответствия.
7. Списки контроля доступа (ACL, Access Control Lists)
→ Определение
✓ Разрешения настраиваются непосредственно для каждого ресурса.
→ Как это работает
✓ Ресурс содержит список разрешённых пользователей и действий.
→ Оптимально для
✓ Файловых систем.
✓ Моделей безопасности на уровне ресурсов.
Краткое резюме
✓ RBAC → На основе ролей.
✓ ABAC → На основе атрибутов.
✓ OAuth 2.0 → Делегированный доступ.
✓ OIDC → Уровень идентификации.
✓ JWT → Без состояния, на основе токенов.
✓ PBAC → На основе политик.
✓ ACL → На уровне ресурсов.
(продолжение к предыдущему посту)
Контроль разрешений пользователей в современных API
1. Управление доступом на основе ролей (RBAC, Role‑Based Access Control)
→ Определение
✓ Назначает разрешения на основе роли пользователя (администратор, редактор, зритель).
→ Как это работает
✓ Пользователи → Назначенные роли → Роли → Предоставление разрешений.
→ Оптимально для
✓ Систем с чётко определёнными группами разрешений.
✓ Панелей управления, SaaS‑приложений, CMS‑платформ.
2. Управление доступом на основе атрибутов (ABAC, Attribute‑Based Access Control)
→ Определение
✓ Принимает решения об авторизации на основе атрибутов.
→ Атрибуты включают
✓ Атрибуты пользователя (возраст, отдел, подписка).
✓ Атрибуты ресурса (тип, владелец).
✓ Атрибуты среды (время, местоположение).
→ Оптимально для
✓ Предприятий с сложными и динамическими правилами доступа.
3. Фреймворк авторизации OAuth 2.0
→ Определение
✓ Делегированная авторизация, которая позволяет сторонним приложениям получать доступ к ресурсам без раскрытия паролей пользователей.
→ Как это работает
✓ Аутентификация через провайдера → Выдача токена доступа → API проверяет токен.
→ Распространённые потоки
✓ Код авторизации (Authorization Code).
✓ Учётные данные клиента (Client Credentials).
✓ Потолок для устройств (Device Flow).
→ Оптимально для
✓ Приложений, требующих входа через соцсети или безопасного делегированного доступа.
4. OpenID Connect (OIDC)
→ Определение
✓ Уровень идентификации, построенный на базе OAuth 2.0.
✓ Добавляет проверку личности пользователя с помощью ID‑токенов.
→ Что предоставляет
✓ Проверенную идентификацию.
✓ Единый вход (SSO, Single Sign‑On).
✓ Стандартные утверждения (имя, электронная почта и т. д.).
→ Оптимально для
✓ Систем аутентификации и авторизации.
5. Авторизация с помощью JSON‑веб‑токенов (JWT, JSON Web Token)
→ Определение
✓ Авторизация осуществляется с помощью подписанных JSON‑токенов.
→ Как это работает
✓ Пользователь входит в систему → Сервер выдаёт JWT, содержащий утверждения → Клиент отправляет токен с каждым запросом.
→ Преимущества
✓ Отсутствие состояния (stateless).
✓ Идеально для распределённых микросервисов.
→ Оптимально для
✓ Мобильных приложений, одностраничных приложений (SPA), современных REST API.
6. Управление доступом на основе политик (PBAC, Policy‑Based Access Control)
→ Определение
✓ Решения о доступе принимаются с использованием централизованных политик.
→ Как это работает
✓ Механизм политик проверяет правила → Разрешает или отклоняет запрос.
→ Оптимально для
✓ Государственных систем.
✓ Среды с жёсткими требованиями соответствия.
7. Списки контроля доступа (ACL, Access Control Lists)
→ Определение
✓ Разрешения настраиваются непосредственно для каждого ресурса.
→ Как это работает
✓ Ресурс содержит список разрешённых пользователей и действий.
→ Оптимально для
✓ Файловых систем.
✓ Моделей безопасности на уровне ресурсов.
Краткое резюме
✓ RBAC → На основе ролей.
✓ ABAC → На основе атрибутов.
✓ OAuth 2.0 → Делегированный доступ.
✓ OIDC → Уровень идентификации.
✓ JWT → Без состояния, на основе токенов.
✓ PBAC → На основе политик.
✓ ACL → На уровне ресурсов.
Telegram
METANIT.COM
Механизмы авторизации API
(продолжение в следующем посте)
(продолжение в следующем посте)
❤3👍3👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Линус Торвальдс о резервном копировании данных:
«Только слабаки используют резервное копирование на ленту: настоящие мужчины просто загружают свои важные данные на FTP, и пусть остальной мир их копирует" - Линус Торвальдс, 1996 г., LKML
(Оригинал: "Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it")
«Мой подход к хранению данных таков: я загружаю их в интернет, и если они стоят того, чтобы их сохранить, кто-то другой сохранит их для меня». — Линус Торвальдс, 2025 г., Linus Tech Tips
(Оригинал: "My data storage approach is: I upload it to the internet, and if it's worth saving, somebody else will save it for me.")
«Только слабаки используют резервное копирование на ленту: настоящие мужчины просто загружают свои важные данные на FTP, и пусть остальной мир их копирует" - Линус Торвальдс, 1996 г., LKML
(Оригинал: "Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it")
«Мой подход к хранению данных таков: я загружаю их в интернет, и если они стоят того, чтобы их сохранить, кто-то другой сохранит их для меня». — Линус Торвальдс, 2025 г., Linus Tech Tips
(Оригинал: "My data storage approach is: I upload it to the internet, and if it's worth saving, somebody else will save it for me.")
😁49🤡11🔥8❤4🥴3🦄3😱2💯1🤣1
Стратегии работы с базами данных
(продолжение предыдущего поста)
1. Когда нагрузка на чтение и запись высокая (сбалансированная нагрузка):
* Используйте основную базу данных для всех операций записи.
* Передавайте интенсивный трафик чтения на несколько реплик для чтения через асинхронную репликацию.
* Применяйте кэш Redis для обработки «горячих» ключей и снижения нагрузки на базу данных.
* Учитывайте, что иногда могут возникать промахи кэша (cache miss) — в таких случаях обращение будет перенаправлено к основной базе данных.
* Группируйте операции записи и оптимизируйте индексы, чтобы поддерживать стабильную производительность.
2. Когда нагрузка на запись постоянно растёт:
* Разделите базу данных на шарды (сегменты).
* Каждый шард хранит часть набора данных, благодаря чему операции записи распределяются.
* Ваше приложение должно уметь направлять запросы к нужному шарду.
* Подходит для масштабного развёртывания, но может быть сложным при выполнении комплексных запросов или транзакций между шардами.
3. Когда требуется гибридная масштабируемость (NewSQL):
* Системы вроде CockroachDB работают как SQL, но масштабируются как NoSQL.
* Встроенные функции автоматического шардирования и перераспределения нагрузки избавляют от необходимости вручную управлять шардами.
* Обеспечивается глобальная согласованность данных между узлами.
* Подходит для мультирегиональных приложений, где важны строгая согласованность и отказоустойчивость.
4. Когда требуются операции с высокой степенью надёжности (финансовые операции):
* Система разрабатывается специально для эконом. операций, например, бухгалтерского учёта, платежей...
* Очень высокая скорость работы, устойчивость к сбоям и подход, основанный на формальной верификации.
* В первую очередь обеспечивается корректность — предотвращаются двойные списания, условия гонки и частичные записи.
* Идеально подходит для операций с деньгами, когда каждая транзакция должна быть точной, надёжной и безопасной.
(продолжение предыдущего поста)
1. Когда нагрузка на чтение и запись высокая (сбалансированная нагрузка):
* Используйте основную базу данных для всех операций записи.
* Передавайте интенсивный трафик чтения на несколько реплик для чтения через асинхронную репликацию.
* Применяйте кэш Redis для обработки «горячих» ключей и снижения нагрузки на базу данных.
* Учитывайте, что иногда могут возникать промахи кэша (cache miss) — в таких случаях обращение будет перенаправлено к основной базе данных.
* Группируйте операции записи и оптимизируйте индексы, чтобы поддерживать стабильную производительность.
2. Когда нагрузка на запись постоянно растёт:
* Разделите базу данных на шарды (сегменты).
* Каждый шард хранит часть набора данных, благодаря чему операции записи распределяются.
* Ваше приложение должно уметь направлять запросы к нужному шарду.
* Подходит для масштабного развёртывания, но может быть сложным при выполнении комплексных запросов или транзакций между шардами.
3. Когда требуется гибридная масштабируемость (NewSQL):
* Системы вроде CockroachDB работают как SQL, но масштабируются как NoSQL.
* Встроенные функции автоматического шардирования и перераспределения нагрузки избавляют от необходимости вручную управлять шардами.
* Обеспечивается глобальная согласованность данных между узлами.
* Подходит для мультирегиональных приложений, где важны строгая согласованность и отказоустойчивость.
4. Когда требуются операции с высокой степенью надёжности (финансовые операции):
* Система разрабатывается специально для эконом. операций, например, бухгалтерского учёта, платежей...
* Очень высокая скорость работы, устойчивость к сбоям и подход, основанный на формальной верификации.
* В первую очередь обеспечивается корректность — предотвращаются двойные списания, условия гонки и частичные записи.
* Идеально подходит для операций с деньгами, когда каждая транзакция должна быть точной, надёжной и безопасной.
Telegram
METANIT.COM
Стратегии работы с базами данных
(продолжение в следующем посте)
(продолжение в следующем посте)
🔥5🥰1👏1😁1
This media is not supported in your browser
VIEW IN TELEGRAM
Как двоичные данные транслируются в инструкции ассемблера
👍24🤯16🤪4🤣2
Обучение с помощью чат-ботов приводит к поверхностному усваиванию материалов
Исследователи Шири Мелумад и Джин Хо Юн в ходе нескольких экспериментов с участием более 10 тысяч человек выяснили, что обучение с помощью ChatGPT и других чат-ботов приводит к тому, что материал усваивается более поверхностно.
Участников просили изучить определённую тему — например, как вырастить огород. Потом их случайным образом направляли либо к ChatGPT, либо к обычному поиску в Google. Далее испытуемый должен был написать совет «другу», основываясь на полученных знаниях.
Все эксперименты показали примерно одно и то же: участники, которые прибегали к помощи ИИ, чувствовали, что узнали меньше, тратили меньше усилий на последующее задание и писали советы, которые были короче, менее подробны и более общими. Кроме того, независимые читатели оценили такие советы как менее полезные и информативные.
Исследователи решили проверить, в чём кроется причина различий. Они давали один и тот же набор фактов — и в Google, и через ИИ — но те, кто получал готовые синтезированные ответы, демонстрировали более поверхностное понимание темы. Аналогичный тренд наблюдался при работе с поиском Google и его функцией AI Overview.
По мнению авторов, проблема заключается в усилиях, которые человек вынужден приложить при самостоятельном поиске информации. При обычном поиске ему приходится переходить по ссылкам, сравнивать источники, интерпретировать данные, что формирует более глубокие и прочные знания. Чат-боты же превращают этот процесс в пассивный.
https://academic.oup.com/pnasnexus/article/4/10/pgaf316/8303888?login=false
Исследователи Шири Мелумад и Джин Хо Юн в ходе нескольких экспериментов с участием более 10 тысяч человек выяснили, что обучение с помощью ChatGPT и других чат-ботов приводит к тому, что материал усваивается более поверхностно.
Участников просили изучить определённую тему — например, как вырастить огород. Потом их случайным образом направляли либо к ChatGPT, либо к обычному поиску в Google. Далее испытуемый должен был написать совет «другу», основываясь на полученных знаниях.
Все эксперименты показали примерно одно и то же: участники, которые прибегали к помощи ИИ, чувствовали, что узнали меньше, тратили меньше усилий на последующее задание и писали советы, которые были короче, менее подробны и более общими. Кроме того, независимые читатели оценили такие советы как менее полезные и информативные.
Исследователи решили проверить, в чём кроется причина различий. Они давали один и тот же набор фактов — и в Google, и через ИИ — но те, кто получал готовые синтезированные ответы, демонстрировали более поверхностное понимание темы. Аналогичный тренд наблюдался при работе с поиском Google и его функцией AI Overview.
По мнению авторов, проблема заключается в усилиях, которые человек вынужден приложить при самостоятельном поиске информации. При обычном поиске ему приходится переходить по ссылкам, сравнивать источники, интерпретировать данные, что формирует более глубокие и прочные знания. Чат-боты же превращают этот процесс в пассивный.
https://academic.oup.com/pnasnexus/article/4/10/pgaf316/8303888?login=false
OUP Academic
Experimental evidence of the effects of large language models versus web search on depth of learning Open Access
Abstract. The effects of using large language models (LLMs) versus traditional web search on depth of learning are explored. A theory is proposed that when
👍15💯11👏1🤮1
Нейронный процессор (NPU) — это специализированный чип, оптимизированный для быстрых параллельных вычислений, особенно матричных и векторных операций. В теории вероятностей и статистике NPU ускоряют такие задачи, как моделирование методом Монте-Карло и байесовский вывод. В машинном обучении они ускоряют обучение нейронных сетей и вывод при низком энергопотреблении. В реальной жизни NPU обеспечивают работу таких функций, как разблокировка по лицу, распознавание речи, интеллектуальные камеры, автономное вождение и встроенный предиктивный ИИ на телефонах, автомобилях и устройствах Интернета вещей.
👍14🔥3🖕2🌚1
Традиционный обзор по рынку труда по статистике hh
В ноябре ситуация на рынке труда в сфере ИТ в целом продолжила ухудшаться. hh-индекс - показатель соотношения количества активных резюме к количеству активных вакансий снова ухудшился - рост до 19,4 (крайне мегасупервысокий уровень конкуренции соискателей за рабочие места)
А год к году снижение вакансий составило 43%, а по сранению с октябрем - уменьшение на 8%
Но есть и хорошие новости - немного повысились предлагаемые зарплаты - до 94915. При ожидаемой инфляции в районе 6-6,5% есть основания, что рост за год хотя бы перекроет годовую инфляцию - c начала года прирост предлагаемых зарплат составил 11,65%
https://stats.hh.ru/?hhIndexProfArea=information_technology&vacanciesProfArea=information_technology&countrySalaryDynamicChartProfArea=information_technology
В ноябре ситуация на рынке труда в сфере ИТ в целом продолжила ухудшаться. hh-индекс - показатель соотношения количества активных резюме к количеству активных вакансий снова ухудшился - рост до 19,4 (крайне мегасупервысокий уровень конкуренции соискателей за рабочие места)
А год к году снижение вакансий составило 43%, а по сранению с октябрем - уменьшение на 8%
Но есть и хорошие новости - немного повысились предлагаемые зарплаты - до 94915. При ожидаемой инфляции в районе 6-6,5% есть основания, что рост за год хотя бы перекроет годовую инфляцию - c начала года прирост предлагаемых зарплат составил 11,65%
https://stats.hh.ru/?hhIndexProfArea=information_technology&vacanciesProfArea=information_technology&countrySalaryDynamicChartProfArea=information_technology
😭28🤡3❤1🤬1🎉1