Заблокируют ли WhatsApp в России из-за реестра РКН? Ответил депутат Госдумы
WhatsApp внесли в реестр ОРИ, но блокировка в России маловероятна. Депутат Госдумы заявил, что сервису грозят штрафы, а не отключение
Включение WhatsApp в реестр организаторов распространения информации (ОРИ) вызвало волну слухов о возможной блокировке мессенджера.
Но насколько реальны такие опасения?
Что произошло?
На днях Роскомнадзор добавил 12 иностранных мессенджеров, включая WhatsApp, в реестр ОРИ. Это означает, что теперь сервисы обязаны соблюдать требования закона, включая хранение данных пользователей и предоставление доступа к ним по запросу российских властей.
Ранее компании могли игнорировать эту обязанность, выплачивать штрафы и продолжать работать.
Но в 2023 году РКН получил право самостоятельно вносить сервисы в реестр после двух штрафов. Это нововведение теперь распространяется на всех крупных игроков, включая WhatsApp.
Блокировка неизбежна?
Депутат Госдумы Антон Горелкин заявил, что включение в реестр ОРИ не обязательно ведет к блокировке.
Он подчеркнул, что у WhatsApp были все основания для блокировки еще до этого решения, поскольку его материнская компания *Meta (организация признана экстремистской в РФ) признана экстремистской. Но блокировки не было из-за высокой популярности мессенджера в России.
Скорее всего, WhatsApp будет пытаться найти компромисс с РКН, чтобы продолжить работу на отечественном рынке. Даже если мессенджер не станет выполнять все требования закона, ему грозят новые штрафы, а не немедленная блокировка.
Почему WhatsApp не спешат отключать?
Ситуация с WhatsApp достаточно уникальна. Мессенджер играет ключевую роль в коммуникации для миллионов россиян, включая бизнес и госструктуры.
Полная блокировка приложения может вызвать широкий резонанс, что, возможно, не в интересах властей.
Кроме того, в отличие от социальных сетей своей головной компании, WhatsApp пока не игнорирует запросы российских регуляторов настолько демонстративно, чтобы это стало причиной для немедленных действий.
WhatsApp внесли в реестр ОРИ, но блокировка в России маловероятна. Депутат Госдумы заявил, что сервису грозят штрафы, а не отключение
Включение WhatsApp в реестр организаторов распространения информации (ОРИ) вызвало волну слухов о возможной блокировке мессенджера.
Но насколько реальны такие опасения?
Что произошло?
На днях Роскомнадзор добавил 12 иностранных мессенджеров, включая WhatsApp, в реестр ОРИ. Это означает, что теперь сервисы обязаны соблюдать требования закона, включая хранение данных пользователей и предоставление доступа к ним по запросу российских властей.
Ранее компании могли игнорировать эту обязанность, выплачивать штрафы и продолжать работать.
Но в 2023 году РКН получил право самостоятельно вносить сервисы в реестр после двух штрафов. Это нововведение теперь распространяется на всех крупных игроков, включая WhatsApp.
Блокировка неизбежна?
Депутат Госдумы Антон Горелкин заявил, что включение в реестр ОРИ не обязательно ведет к блокировке.
Он подчеркнул, что у WhatsApp были все основания для блокировки еще до этого решения, поскольку его материнская компания *Meta (организация признана экстремистской в РФ) признана экстремистской. Но блокировки не было из-за высокой популярности мессенджера в России.
Скорее всего, WhatsApp будет пытаться найти компромисс с РКН, чтобы продолжить работу на отечественном рынке. Даже если мессенджер не станет выполнять все требования закона, ему грозят новые штрафы, а не немедленная блокировка.
Почему WhatsApp не спешат отключать?
Ситуация с WhatsApp достаточно уникальна. Мессенджер играет ключевую роль в коммуникации для миллионов россиян, включая бизнес и госструктуры.
Полная блокировка приложения может вызвать широкий резонанс, что, возможно, не в интересах властей.
Кроме того, в отличие от социальных сетей своей головной компании, WhatsApp пока не игнорирует запросы российских регуляторов настолько демонстративно, чтобы это стало причиной для немедленных действий.
Очередная подборка задач от нашей IT поддержки:
- Нужно настроить интернет чтобы не показывал плохие новости.
- Помогите вставить роутер в розетку, только у меня нет роутера.
- Установиться иксель в 1С. Срочно!
- Случайно перепутал и продал рабочий ноутбук. Прошу выдать новый.
- Меня забанили за флуд в рабочем чате. Можете разбанить?
- Установите пожалуйста виндовс на макбук.
- Лампа сильно светит в глаза, выдайте тёмные очки хотя бы
- Коллеги прикрепили дилдо к стулу. Прошу заменить.
- Нужно настроить интернет чтобы не показывал плохие новости.
- Помогите вставить роутер в розетку, только у меня нет роутера.
- Установиться иксель в 1С. Срочно!
- Случайно перепутал и продал рабочий ноутбук. Прошу выдать новый.
- Меня забанили за флуд в рабочем чате. Можете разбанить?
- Установите пожалуйста виндовс на макбук.
- Лампа сильно светит в глаза, выдайте тёмные очки хотя бы
- Коллеги прикрепили дилдо к стулу. Прошу заменить.
😁6😭2
Тим О’Райли: ИИ не заменит программистов, но изменит их работу. Кодинг станет абстрактнее, а ценность инженеров вырастет
Тим О’Райли, создатель O’Reilly Media и идеолог Веб 2.0, выступил с развернутым мнением о будущем программирования.
Он уверен: разработчики никуда не исчезнут, но их работа станет совсем другой.
Сегодня индустрия переживает очередную революцию — теперь под давлением ИИ генераторов кода. Многие задаются вопросом: не заменит ли искусственный интеллект программистов?
О’Райли уверен: нет. Но привычный подход к разработке уйдет в прошлое.
Как менялась работа программистов?
Технологии программирования развиваются волнами.
В 1940-х инженеры вручную соединяли физические цепи, чтобы задать алгоритм.
В 1950-х появились первые языки низкого уровня — разработчики писали код на ассемблере.
В 1960-х–1980-х на смену им пришли языки вроде Fortran, COBOL, C — более абстрактные, но всё ещё сложные.
В 1990-х программисты начали работать с интерпретируемыми языками, такими как JavaScript, Python, PHP.
В 2000-х мир покорили фреймворки и библиотеки, упрощающие работу с кодом.
В 2010-х активно развивалась облачная инфраструктура и интернет-экосистемы API.
Каждый раз разработчики боялись, что их навыки станут ненужными. Но вместо этого количество программистов только росло.
Сейчас мы вступаем в эпоху ИИ-помощников. И снова слышны разговоры: «Теперь код будут писать боты!»
Чем ИИ отличается от прошлых революций?
Ранее автоматизация убирала рутину, но не сам процесс кодинга. Например, программистам больше не нужно вручную управлять памятью или писать драйверы для каждой новой мышки.
Сейчас же ИИ предлагает принципиально новый уровень абстракции:
Можно не писать код, а просто описывать задачу словами.
Можно получать прототипы за секунды, а не вручную разрабатывать архитектуру.
Можно делегировать генерацию, тестирование и даже исправление багов.
Но здесь есть важный нюанс: ИИ пока не заменяет инженеров, а лишь ускоряет их работу.
Что ждёт программистов дальше?
О’Райли считает, что программисты не исчезнут, но их работа изменится.
Новые роли. Разработчики будут не столько писать код, сколько управлять ИИ-системами, став своего рода менеджерами цифровых сотрудников.
Другие навыки. Важно будет не просто знать язык программирования, а уметь правильно ставить задачи ИИ.
Рост требований. Простой код смогут писать и новички с помощью нейросетей, но ценность приобретут архитекторы и инженеры высокоуровневых систем.
Вывод: программирование не умирает, а эволюционирует
ИИ не сделает людей ненужными. Он размоет границы между программистами и пользователями, даст новые инструменты, но потребность в инженерах никуда не денется.
О’Райли считает, что мы сейчас в начале новой технологической эры. И те, кто быстро адаптируются, будут в выигрыше.
Тим О’Райли, создатель O’Reilly Media и идеолог Веб 2.0, выступил с развернутым мнением о будущем программирования.
Он уверен: разработчики никуда не исчезнут, но их работа станет совсем другой.
Сегодня индустрия переживает очередную революцию — теперь под давлением ИИ генераторов кода. Многие задаются вопросом: не заменит ли искусственный интеллект программистов?
О’Райли уверен: нет. Но привычный подход к разработке уйдет в прошлое.
Как менялась работа программистов?
Технологии программирования развиваются волнами.
В 1940-х инженеры вручную соединяли физические цепи, чтобы задать алгоритм.
В 1950-х появились первые языки низкого уровня — разработчики писали код на ассемблере.
В 1960-х–1980-х на смену им пришли языки вроде Fortran, COBOL, C — более абстрактные, но всё ещё сложные.
В 1990-х программисты начали работать с интерпретируемыми языками, такими как JavaScript, Python, PHP.
В 2000-х мир покорили фреймворки и библиотеки, упрощающие работу с кодом.
В 2010-х активно развивалась облачная инфраструктура и интернет-экосистемы API.
Каждый раз разработчики боялись, что их навыки станут ненужными. Но вместо этого количество программистов только росло.
Сейчас мы вступаем в эпоху ИИ-помощников. И снова слышны разговоры: «Теперь код будут писать боты!»
Чем ИИ отличается от прошлых революций?
Ранее автоматизация убирала рутину, но не сам процесс кодинга. Например, программистам больше не нужно вручную управлять памятью или писать драйверы для каждой новой мышки.
Сейчас же ИИ предлагает принципиально новый уровень абстракции:
Можно не писать код, а просто описывать задачу словами.
Можно получать прототипы за секунды, а не вручную разрабатывать архитектуру.
Можно делегировать генерацию, тестирование и даже исправление багов.
Но здесь есть важный нюанс: ИИ пока не заменяет инженеров, а лишь ускоряет их работу.
ИИ делает программистов в 10 раз продуктивнее. Но если возможностей для программирования станет в 20 раз больше, нам всё равно понадобятся люди
Что ждёт программистов дальше?
О’Райли считает, что программисты не исчезнут, но их работа изменится.
Новые роли. Разработчики будут не столько писать код, сколько управлять ИИ-системами, став своего рода менеджерами цифровых сотрудников.
Другие навыки. Важно будет не просто знать язык программирования, а уметь правильно ставить задачи ИИ.
Рост требований. Простой код смогут писать и новички с помощью нейросетей, но ценность приобретут архитекторы и инженеры высокоуровневых систем.
Если ИИ автоматизирует 70% рутинных задач, то останется 30%, с которыми справятся только профессионалы
Вывод: программирование не умирает, а эволюционирует
ИИ не сделает людей ненужными. Он размоет границы между программистами и пользователями, даст новые инструменты, но потребность в инженерах никуда не денется.
О’Райли считает, что мы сейчас в начале новой технологической эры. И те, кто быстро адаптируются, будут в выигрыше.
А давайте проверим насколько глубоко вы шарите в php? )))
Выберите правильное утверждения про GC (Garbage Collector) в php.
Выберите правильное утверждения про GC (Garbage Collector) в php.
Anonymous Quiz
19%
GC очищает память когда количество ссылок на объект достигает максимума
39%
GC очищает память когда количество ссылок на объект достигает нуля
8%
GC очищает память когда группы изолированных объектов хотя бы частично не доступны извне
6%
GC не вызывается при нехватке памяти
11%
GC не всегда вызывается в конце выполнения скрипта
17%
GC нельзя запустить принудлительно
Сегодня у меня немного праздничное событие. Я наконец-то смог перевести один из своих пет-проектов на HttpClient Symfony с Guzzle + смог настроить МокМодуль для Codeception под все это дело.
Но для начала немного предыстории...
На работе в основном используются Symfony версий 4, 5 и 6. 7-ки пока что нигде еще в продуктах нету. Поэтому там везде в Codeception функциональных тестах используется и прекрасно работает Phiremock. И всё бы было бы отлично, если бы не одно НО...
Написал я новый пет-проект на Symfony 7.2 и Codeception 5.2. Весь функционал написал, пошел писать архитектуру автотестов и тут вдруг неожиданно выясняется, что Phiremock не хочет работать с Symfony 7.2. На текущий момент для него максимальная версия - это 6.4 и чтобы его проапгрейдить до состояния совместимости с Symofny 7.2 нужно перелопатить огромное количество репозиториев, больше 7 (кажется) штук.
Попробовал начать это делать... Ну думаю внесу свой вклад.... Ага.... Конечно.... Как только я дошел до 5 репозитория я начал понимать насколько глубока кроличья нора и какая там круговерть зависимостей начинается... В общем... "Я пыталься насяльнике", но моё время мне дороже...
Было решено попробовать замокать внешние запросы как-то иначе... Начал смотреть и разбирать решения, которые есть в интернете по этому поводу. Пробовал разное, примерял и так и сяк и наперекосяк... Но Guzzle упорно отказывался мокаться...
Окей... Мы не сдаемся... Нам нужны автотесты...
В Symfony есть HttpClient как альтернатива Guzzle. Ну окей, попробуем со штатными либами поиграться... Перевел продукт с Guzzle на HttpClient - это заняло буквально 5 минут... Но вот дальше снова начались танцы с бубном... Сначала Symfony отказывалась брать клиента тестового окружения и уперто подсовывала в сервис боевого клиента HttpClient... Через какое-то время я победил эту проблему... Начал цепляться нужный клиент...
Но дальше пошло совсем веселье... По какой-то причине Symfony каждый раз запуская код из контура автотестов во время запуска теста создавала объект клиента, наполняла его данными ожидаемых запросов и ответов, а потом во время выполнения кода приложения просто создавала объект заново.... 😭😭😭😭😭
Видимо на какое-то время глаз уже замылился и только спустя 2 дня я вспомнил про Singleton!... И это стало моим спасением! Наконец-то! Спустя несколько вечеров мучений ЭТО заработало все в совокупности!!! Каково же было мое счастье!
По итогу все оформил в отдельный Модуль для Codeception. Его можно установить через composer.
https://packagist.org/packages/otezvikentiy/codeception-symfony-http-client-mock
Возможно кому-то пригодится. Мне так точно пригодится чувствую и еще и не раз. Так что, буду его дорабатывать и выпускать новые еще более удобные и функциональные версии.
И также еще немного скромной радости на сегодня:
У моего JsonRPCApiBundle появился первый контрибутор.
https://packagist.org/packages/otezvikentiy/json-rpc-api
Казалось бы ничего особенного, но чувство приятное.
В общем... Всем добра ))) Поделился с вами радостью 😂😂😂
Но для начала немного предыстории...
На работе в основном используются Symfony версий 4, 5 и 6. 7-ки пока что нигде еще в продуктах нету. Поэтому там везде в Codeception функциональных тестах используется и прекрасно работает Phiremock. И всё бы было бы отлично, если бы не одно НО...
Написал я новый пет-проект на Symfony 7.2 и Codeception 5.2. Весь функционал написал, пошел писать архитектуру автотестов и тут вдруг неожиданно выясняется, что Phiremock не хочет работать с Symfony 7.2. На текущий момент для него максимальная версия - это 6.4 и чтобы его проапгрейдить до состояния совместимости с Symofny 7.2 нужно перелопатить огромное количество репозиториев, больше 7 (кажется) штук.
Попробовал начать это делать... Ну думаю внесу свой вклад.... Ага.... Конечно.... Как только я дошел до 5 репозитория я начал понимать насколько глубока кроличья нора и какая там круговерть зависимостей начинается... В общем... "Я пыталься насяльнике", но моё время мне дороже...
Было решено попробовать замокать внешние запросы как-то иначе... Начал смотреть и разбирать решения, которые есть в интернете по этому поводу. Пробовал разное, примерял и так и сяк и наперекосяк... Но Guzzle упорно отказывался мокаться...
Окей... Мы не сдаемся... Нам нужны автотесты...
В Symfony есть HttpClient как альтернатива Guzzle. Ну окей, попробуем со штатными либами поиграться... Перевел продукт с Guzzle на HttpClient - это заняло буквально 5 минут... Но вот дальше снова начались танцы с бубном... Сначала Symfony отказывалась брать клиента тестового окружения и уперто подсовывала в сервис боевого клиента HttpClient... Через какое-то время я победил эту проблему... Начал цепляться нужный клиент...
Но дальше пошло совсем веселье... По какой-то причине Symfony каждый раз запуская код из контура автотестов во время запуска теста создавала объект клиента, наполняла его данными ожидаемых запросов и ответов, а потом во время выполнения кода приложения просто создавала объект заново.... 😭😭😭😭😭
Видимо на какое-то время глаз уже замылился и только спустя 2 дня я вспомнил про Singleton!... И это стало моим спасением! Наконец-то! Спустя несколько вечеров мучений ЭТО заработало все в совокупности!!! Каково же было мое счастье!
По итогу все оформил в отдельный Модуль для Codeception. Его можно установить через composer.
https://packagist.org/packages/otezvikentiy/codeception-symfony-http-client-mock
Возможно кому-то пригодится. Мне так точно пригодится чувствую и еще и не раз. Так что, буду его дорабатывать и выпускать новые еще более удобные и функциональные версии.
И также еще немного скромной радости на сегодня:
У моего JsonRPCApiBundle появился первый контрибутор.
https://packagist.org/packages/otezvikentiy/json-rpc-api
Казалось бы ничего особенного, но чувство приятное.
В общем... Всем добра ))) Поделился с вами радостью 😂😂😂
packagist.org
otezvikentiy/codeception-symfony-http-client-mock - Packagist.org
Codeception Module for Mocking HttpClient in Symfony
🔥5👍2🏆2💯1
С опытом понимаешь, что в задаче «могут ли 9 женщин родить ребёнка за месяц» скрывается: 5 из них не женщины; на самом деле срок 3 недели; ребёнок не нужен, а нужен звук детского плача, и пм подумал, что будет проще родить ребёнка для этого.
👍4😁1🤡1