30 минут против месяца — это не про скорость, а про цену процесса.
Я это хорошо вижу на проектах, где разработка живёт между «сделаем быстро» и «согласуем правильно». На бумаге второй путь всегда выглядит тяжелее: больше встреч, больше статусов, больше регламентов. В реальности именно он спасает от ночных правок, конфликтов в ТЗ и бесконечного отката в прод.
Типовой кейс из проекта: задача на 30 минут у разработчика превращается в месяц согласований, потому что не зафиксированы права, не описан сценарий интеграции, не определён владелец данных. Итог простой: код давно готов, а бизнес ещё спорит, кто должен был это принять.
Я в таких историях всегда смотрю на одно: процесс нужен не ради порядка как такового, а ради снижения стоимости ошибки. Если архитектура, роли и точки контроля собраны заранее — команда работает спокойно. Если нет — любое «быстро» заканчивается пожаром. 🔧
И да, идеальные процессы тоже могут тормозить. Но отсутствие процессов почти всегда тормозит сильнее.
Я это хорошо вижу на проектах, где разработка живёт между «сделаем быстро» и «согласуем правильно». На бумаге второй путь всегда выглядит тяжелее: больше встреч, больше статусов, больше регламентов. В реальности именно он спасает от ночных правок, конфликтов в ТЗ и бесконечного отката в прод.
Типовой кейс из проекта: задача на 30 минут у разработчика превращается в месяц согласований, потому что не зафиксированы права, не описан сценарий интеграции, не определён владелец данных. Итог простой: код давно готов, а бизнес ещё спорит, кто должен был это принять.
Я в таких историях всегда смотрю на одно: процесс нужен не ради порядка как такового, а ради снижения стоимости ошибки. Если архитектура, роли и точки контроля собраны заранее — команда работает спокойно. Если нет — любое «быстро» заканчивается пожаром. 🔧
И да, идеальные процессы тоже могут тормозить. Но отсутствие процессов почти всегда тормозит сильнее.
Я всё чаще ловлю одну и ту же мысль: в вебе много контента, но мало механики.
В истории с SEBERD IT Base мне зацепил не сам факт «ещё одного сайта про ИБ», а подход. Не очередной набор лозунгов про угрозы, а разбор того, как атака устроена внутри: по шагам, по протоколам, по логике действий.
Это очень похоже на типовой корпоративный проект, когда заказчик приносит «надо сделать безопасность», а на деле нужен не баннер, а схема: где источник данных, как они обновляются, что считается актуальным, кто отвечает за доверие к этим данным. ⚙️
Отдельно нормально смотрится решение с главной страницей. Не маркетинговая витрина, а живая лента с RSS/API. Без ручного парсинга HTML, без лишней магии — обычная интеграционная дисциплина: тянем структурированные источники, собираем, показываем.
Для меня это хороший пример того, как сайт перестаёт быть «страницей» и становится системой. Именно там обычно и начинается интересная архитектура.
В истории с SEBERD IT Base мне зацепил не сам факт «ещё одного сайта про ИБ», а подход. Не очередной набор лозунгов про угрозы, а разбор того, как атака устроена внутри: по шагам, по протоколам, по логике действий.
Это очень похоже на типовой корпоративный проект, когда заказчик приносит «надо сделать безопасность», а на деле нужен не баннер, а схема: где источник данных, как они обновляются, что считается актуальным, кто отвечает за доверие к этим данным. ⚙️
Отдельно нормально смотрится решение с главной страницей. Не маркетинговая витрина, а живая лента с RSS/API. Без ручного парсинга HTML, без лишней магии — обычная интеграционная дисциплина: тянем структурированные источники, собираем, показываем.
Для меня это хороший пример того, как сайт перестаёт быть «страницей» и становится системой. Именно там обычно и начинается интересная архитектура.
В проектах я часто смотрю на QR-коды как на чисто утилитарный артефакт: ссылка, токен, оплата, и хватит. Но бывают решения, где сама форма уже часть коммуникации. NoiR Code — как раз из таких.
Схема простая: текст кодируется не в привычную матрицу блоков, а в изображение с нуарной визуализацией — тени, силуэты, ночной город. Считывание при этом не ломается: нужен поддерживающий сканер или веб-сервис, который понимает этот формат. То есть это не «картинка вместо кода», а код, замаскированный под картинку.
🔎 Если смотреть с инженерной точки зрения, здесь интересен баланс между эстетикой и машинной читаемостью. Обычно при попытке «сделать красиво» первым страдает именно распознавание. Здесь задача решена наоборот: визуальный слой добавлен поверх, но логика декодирования сохранена.
Для интегратора это хороший пример: формат может быть не только транспортом данных, но и носителем бренда. Вопрос только один — кто будет это сканировать и чем. Если на входе нет совместимого клиента, вся магия остаётся декоративной.
Схема простая: текст кодируется не в привычную матрицу блоков, а в изображение с нуарной визуализацией — тени, силуэты, ночной город. Считывание при этом не ломается: нужен поддерживающий сканер или веб-сервис, который понимает этот формат. То есть это не «картинка вместо кода», а код, замаскированный под картинку.
🔎 Если смотреть с инженерной точки зрения, здесь интересен баланс между эстетикой и машинной читаемостью. Обычно при попытке «сделать красиво» первым страдает именно распознавание. Здесь задача решена наоборот: визуальный слой добавлен поверх, но логика декодирования сохранена.
Для интегратора это хороший пример: формат может быть не только транспортом данных, но и носителем бренда. Вопрос только один — кто будет это сканировать и чем. Если на входе нет совместимого клиента, вся магия остаётся декоративной.
В проектах по Битрикс я регулярно вижу одну и ту же картину: команду нельзя «выключить» на месяц ради обучения. Производство идёт, интеграции горят, релизы стоят в очереди.
Поэтому гибридный формат обучения — рабочая схема, а не компромисс. У нас это выглядит так: базовые материалы уходят в СДО, сложные вопросы разбираются на консультациях, а затем знания сразу проверяются на реальном проекте. Без отрыва от задач, без паузы в SLA, без иллюзии, что всё запомнится с первого просмотра.
Для enterprise-команды это особенно важно. Когда люди осваивают не абстрактный инструмент, а конкретный стек в боевых условиях, результат обычно лучше: меньше ошибок в архитектуре, быстрее принятие решений, аккуратнее работа с интеграциями и правами доступа.
Собственно, типовой кейс из проекта: сначала обучение, потом внедрение, потом уже нормальная эксплуатация. Именно такой порядок обычно экономит и время, и бюджет. ⚙️
Поэтому гибридный формат обучения — рабочая схема, а не компромисс. У нас это выглядит так: базовые материалы уходят в СДО, сложные вопросы разбираются на консультациях, а затем знания сразу проверяются на реальном проекте. Без отрыва от задач, без паузы в SLA, без иллюзии, что всё запомнится с первого просмотра.
Для enterprise-команды это особенно важно. Когда люди осваивают не абстрактный инструмент, а конкретный стек в боевых условиях, результат обычно лучше: меньше ошибок в архитектуре, быстрее принятие решений, аккуратнее работа с интеграциями и правами доступа.
Собственно, типовой кейс из проекта: сначала обучение, потом внедрение, потом уже нормальная эксплуатация. Именно такой порядок обычно экономит и время, и бюджет. ⚙️
Хороший код не спасает, если архитектура уже поплыла.
У меня это чаще всего видно на старых формах и самописных обработчиках: по отдельности всё выглядит аккуратно, но вместе — плотная связка из условий, глобальных переменных и скрытых зависимостей. Формально код читается. Практически — любое изменение превращается в раскопки.
Типовой кейс из проекта: форму делали быстро, потом к ней добавили CRM, уведомления, проверку прав, кеш, ещё одну валидацию, потом «маленькое» поле для маркетинга. В итоге один submit тянет за собой полсистемы. И вот уже не код плохой — плоха схема, по которой он собран.
Я обычно смотрю на такие вещи просто: если модуль нельзя заменить без страданий, значит архитектура держится на памяти команды, а не на границах ответственности.
Хорошая архитектура — это когда файл можно открыть через три года и понять не только «что здесь написано», но и «почему именно так собрано». 🧩
У меня это чаще всего видно на старых формах и самописных обработчиках: по отдельности всё выглядит аккуратно, но вместе — плотная связка из условий, глобальных переменных и скрытых зависимостей. Формально код читается. Практически — любое изменение превращается в раскопки.
Типовой кейс из проекта: форму делали быстро, потом к ней добавили CRM, уведомления, проверку прав, кеш, ещё одну валидацию, потом «маленькое» поле для маркетинга. В итоге один submit тянет за собой полсистемы. И вот уже не код плохой — плоха схема, по которой он собран.
Я обычно смотрю на такие вещи просто: если модуль нельзя заменить без страданий, значит архитектура держится на памяти команды, а не на границах ответственности.
Хорошая архитектура — это когда файл можно открыть через три года и понять не только «что здесь написано», но и «почему именно так собрано». 🧩
У «Почты России» теперь свой MVNO — «Почта России Мобайл». Пилот уже пошёл в Тверской и Калининградской областях, а также в Якутии. Сеть обеспечивает Билайн, тарифы — от 100 до 300 рублей.
Я такие запуски обычно читаю не как новость про связь, а как про архитектуру распределённой инфраструктуры. Смысл у MVNO простой: бренд и биллинг — у заказчика, радиосеть и часть операционных рисков — у партнёра.
Схема здесь знакомая:
бизнес-контур → свои тарифы и ЛК
оператор-партнёр → транспорт и покрытие
интеграции → активация, SIM/eSIM, баланс, поддержка
Для крупных экосистем это логичный ход: можно привязать связь к доставке, уведомлениям, сервисным кабинетам и CRM. Но на практике всё упирается в интеграции, а не в пресс-релиз: кто держит NPS, как стыкуются биллинг и поддержка, где ломается верификация, и кто отвечает за SLA 📎
Типовой кейс из проекта один и тот же: на бумаге сервис «свой», а по факту критические процессы завязаны на внешнего провайдера. И чем сложнее продукт, тем важнее заранее считать права доступа, обмен данными и точки отказа.
Я такие запуски обычно читаю не как новость про связь, а как про архитектуру распределённой инфраструктуры. Смысл у MVNO простой: бренд и биллинг — у заказчика, радиосеть и часть операционных рисков — у партнёра.
Схема здесь знакомая:
бизнес-контур → свои тарифы и ЛК
оператор-партнёр → транспорт и покрытие
интеграции → активация, SIM/eSIM, баланс, поддержка
Для крупных экосистем это логичный ход: можно привязать связь к доставке, уведомлениям, сервисным кабинетам и CRM. Но на практике всё упирается в интеграции, а не в пресс-релиз: кто держит NPS, как стыкуются биллинг и поддержка, где ломается верификация, и кто отвечает за SLA 📎
Типовой кейс из проекта один и тот же: на бумаге сервис «свой», а по факту критические процессы завязаны на внешнего провайдера. И чем сложнее продукт, тем важнее заранее считать права доступа, обмен данными и точки отказа.
Два часа ночи. Релиз горит. Разработчик уже подключил ваш API, получил в ответ голое `invalid_request` и дальше начинает не интеграцию, а археологию: что сломалось, где именно, что ожидалось.
Я в таких кейсах всегда смотрю не на код ошибки, а на то, сколько работы вы переложили на человека.
Нормальная ошибка в API — это не «что-то пошло не так», а структура:
- что не так;
- в каком поле;
- какое значение ждём;
- как исправить;
- можно ли повторить запрос.
По-хорошему, это уже уровень RFC 9457: единый формат проблемы, пригодный и для логов, и для клиента, и для поддержки. Но даже без формального стандарта можно сделать по-человечески.
Схема простая:
`error_code` → стабильный код
`message` → коротко и по делу
`details` → список полей/причин
`request_id` → чтобы искать в логах
`hint` → что попробовать дальше
И да, «предсказуемый» API — это комплимент. Скучный API интегрируется быстро, не ломается внезапно и не заставляет писать в поддержку в три часа ночи. А время до первого успешного вызова я бы вообще ставил в KPI онбординга.
Я в таких кейсах всегда смотрю не на код ошибки, а на то, сколько работы вы переложили на человека.
Нормальная ошибка в API — это не «что-то пошло не так», а структура:
- что не так;
- в каком поле;
- какое значение ждём;
- как исправить;
- можно ли повторить запрос.
По-хорошему, это уже уровень RFC 9457: единый формат проблемы, пригодный и для логов, и для клиента, и для поддержки. Но даже без формального стандарта можно сделать по-человечески.
Схема простая:
`error_code` → стабильный код
`message` → коротко и по делу
`details` → список полей/причин
`request_id` → чтобы искать в логах
`hint` → что попробовать дальше
И да, «предсказуемый» API — это комплимент. Скучный API интегрируется быстро, не ломается внезапно и не заставляет писать в поддержку в три часа ночи. А время до первого успешного вызова я бы вообще ставил в KPI онбординга.
Хайп — плохой фундамент для платформы. В проектах я это вижу регулярно: пока технология “в тренде”, вокруг неё собираются деньги, интеграторы, вендоры, красивые презентации. Потом волна спадает — и внезапно выясняется, что устойчивость не у продукта, а у экосистемы.
В свежем разборе про XR это хорошо видно на трёх ролях: поставщик технологии, разработчики дополнений и компании, которые реально внедряют решение в бизнес. У каждого своя логика спасения. Одни докручивают платформу, вторые ищут новые use-case, третьи считают ROI и режут всё лишнее.
Для нас в Bitrix-проектах схема та же:
платформа → интеграции → бизнес-процесс → метрика
Если на первом этапе был только “вау-эффект”, а дальше не собрали сценарий, права, кеш, нагрузку и нормальную поддержку — проект начинает проседать сразу после запуска.
Типовой кейс из практики: клиент хочет “быстро внедрить CRM”, потом выясняется, что без нормальной модели данных, очередей, интеграций с 1С и контроля доступов система превращается в дорогую витрину. И именно тогда становится видно, кто строил архитектуру, а кто продавал ощущение движения.
В свежем разборе про XR это хорошо видно на трёх ролях: поставщик технологии, разработчики дополнений и компании, которые реально внедряют решение в бизнес. У каждого своя логика спасения. Одни докручивают платформу, вторые ищут новые use-case, третьи считают ROI и режут всё лишнее.
Для нас в Bitrix-проектах схема та же:
платформа → интеграции → бизнес-процесс → метрика
Если на первом этапе был только “вау-эффект”, а дальше не собрали сценарий, права, кеш, нагрузку и нормальную поддержку — проект начинает проседать сразу после запуска.
Типовой кейс из практики: клиент хочет “быстро внедрить CRM”, потом выясняется, что без нормальной модели данных, очередей, интеграций с 1С и контроля доступов система превращается в дорогую витрину. И именно тогда становится видно, кто строил архитектуру, а кто продавал ощущение движения.
Forwarded from Потрачено! Клуб спящих бизнесменов!
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 aff.top — вся индустрия арбитража в одном месте
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
В одном производственном проекте я видел типичную ошибку: сначала внедрили 1С, потом начали разбираться, что именно автоматизируют.
Схема была красивая:
цех → мастер → бумага → 1С → отчёт → руководство.
На бумаге — цифровизация.
По факту — тот же ручной процесс, только с новым интерфейсом.
Когда мы пришли с задачей по бережливому производству, сначала сделали диагностику и карту потока. И там всплыло неприятное: около 30% операций вообще не добавляли ценности. Это были передачи данных между подразделениями, дублирование, согласования ради согласований. 🧩
Проблема не в 1С и не в коде. Проблема в том, что автоматизируют уже существующий хаос. А если процесс кривой, система лишь законсервирует его в цифровом виде.
В IT это встречается постоянно: проект сдан в срок, интеграция работает, отчёты формируются — а результата для бизнеса нет. Потому что сначала надо описать поток, роли и точки принятия решения. И только потом садиться писать ТЗ на автоматизацию.
Иначе получаем не оптимизацию, а дорогую оцифровку беспорядка.
Схема была красивая:
цех → мастер → бумага → 1С → отчёт → руководство.
На бумаге — цифровизация.
По факту — тот же ручной процесс, только с новым интерфейсом.
Когда мы пришли с задачей по бережливому производству, сначала сделали диагностику и карту потока. И там всплыло неприятное: около 30% операций вообще не добавляли ценности. Это были передачи данных между подразделениями, дублирование, согласования ради согласований. 🧩
Проблема не в 1С и не в коде. Проблема в том, что автоматизируют уже существующий хаос. А если процесс кривой, система лишь законсервирует его в цифровом виде.
В IT это встречается постоянно: проект сдан в срок, интеграция работает, отчёты формируются — а результата для бизнеса нет. Потому что сначала надо описать поток, роли и точки принятия решения. И только потом садиться писать ТЗ на автоматизацию.
Иначе получаем не оптимизацию, а дорогую оцифровку беспорядка.
This media is not supported in your browser
VIEW IN TELEGRAM
Алиса AI будет конкурировать с Google AI Studio
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
В Zennoposter добавили ИИ-помощник
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
Новую Google reCapcha прошли статичной картинкой
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Иногда в проектах ловлю одну и ту же ошибку мышления: если нужна динамика, значит без JavaScript никак. На практике это не всегда так.
Недавно встретил показательный кейс: браузерный IRC-клиент без JS. Идея звучит как упражнение ради упражнения, но технически там интересна сама схема: HTTP streaming держит живое соединение, HTML отвечает за структуру, CSS — за состояния и часть интерактива. То есть часть «логики интерфейса» уезжает из JS в сервер и разметку.
Это не про отказ от JavaScript как религию. Это про архитектурную дисциплину. Когда у вас чат, админка или личный кабинет, не стоит автоматически тащить тяжёлый фронтовый стек туда, где достаточно:
— постоянного канала на сервере,
— предсказуемых состояний,
— аккуратной верстки,
— минимальной клиентской логики.
В Битриксе такой подход тоже полезен: меньше лишнего JS — проще кеширование, меньше точек отказа, легче сопровождение. Не везде уместно, но как антиошибка — очень рабочая мысль.
Недавно встретил показательный кейс: браузерный IRC-клиент без JS. Идея звучит как упражнение ради упражнения, но технически там интересна сама схема: HTTP streaming держит живое соединение, HTML отвечает за структуру, CSS — за состояния и часть интерактива. То есть часть «логики интерфейса» уезжает из JS в сервер и разметку.
Это не про отказ от JavaScript как религию. Это про архитектурную дисциплину. Когда у вас чат, админка или личный кабинет, не стоит автоматически тащить тяжёлый фронтовый стек туда, где достаточно:
— постоянного канала на сервере,
— предсказуемых состояний,
— аккуратной верстки,
— минимальной клиентской логики.
В Битриксе такой подход тоже полезен: меньше лишнего JS — проще кеширование, меньше точек отказа, легче сопровождение. Не везде уместно, но как антиошибка — очень рабочая мысль.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
DeepSeek представит последнюю версию v4
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Anthropic выпустили Sonnet 5
30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…
➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5
🧠 Ещё больше инсайтов → в канале AFF.top
30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…
➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5
🧠 Ещё больше инсайтов → в канале AFF.top
В работе с Bitrix я регулярно упираюсь в одну и ту же проблему: код вроде «правильный», а на проде начинает вести себя как UB в C++. Формально всё собрано, а на уровне движка, кеша, ORM и интеграций появляются странные эффекты — от неочевидных гонок данных до состояния «вчера работало, сегодня нет».
Алиасинг памяти в C++ — хороший пример того, как язык постепенно ужесточал правила, пытаясь сохранить и производительность, и предсказуемость. Сначала разработчики жили на неявных допущениях, потом пришли ограничения, затем — попытки стандарта аккуратно описать, что именно можно считать одной и той же областью памяти. И каждый шаг был компромиссом между скоростью и безопасностью.
Для Bitrix-проектов здесь есть прямая параллель: чем сложнее стек — CRM, обмены, кастомные компоненты, очереди, кеширование — тем опаснее опираться на «ну оно же обычно так работает». В архитектуре я всегда закладываю явные границы: кто владеет данными, где проходит копия, где допустим shared state, а где нужен изолированный слой. Это скучно. Зато потом не приходится охотиться за фантомными багами 🧩
Алиасинг памяти в C++ — хороший пример того, как язык постепенно ужесточал правила, пытаясь сохранить и производительность, и предсказуемость. Сначала разработчики жили на неявных допущениях, потом пришли ограничения, затем — попытки стандарта аккуратно описать, что именно можно считать одной и той же областью памяти. И каждый шаг был компромиссом между скоростью и безопасностью.
Для Bitrix-проектов здесь есть прямая параллель: чем сложнее стек — CRM, обмены, кастомные компоненты, очереди, кеширование — тем опаснее опираться на «ну оно же обычно так работает». В архитектуре я всегда закладываю явные границы: кто владеет данными, где проходит копия, где допустим shared state, а где нужен изолированный слой. Это скучно. Зато потом не приходится охотиться за фантомными багами 🧩
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Clickstar прекращает работу
Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.
Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.
Что это означает для арбитражников — разбираемся в ста…
➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu
🧠 Ещё больше инсайтов → в канале AFF.top
Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.
Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.
Что это означает для арбитражников — разбираемся в ста…
➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Facebook запретил рекламу онлайн-казино Mr Vegas
Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.
➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas
🧠 Ещё больше инсайтов → в канале AFF.top
Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.
➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas
🧠 Ещё больше инсайтов → в канале AFF.top
Я видел несколько таких попыток: человек не хочет собирать классическую связку «дизайнер → верстальщик → интегратор → правки → снова верстальщик» и идёт в Claude за экономией времени.
Схема обычно одна и та же:
1) делаем черновую структуру сайта;
2) просим ИИ собрать фронт и админку;
3) потом добиваем реальную логику — формы, инфоблоки, права, кеш, интеграции.
И вот тут начинается самое интересное. ИИ неплохо помогает на уровне каркаса, но очень быстро упирается в типовые битриксовые вещи: компоненты, шаблоны, наследование, хранение данных, поведение в админке. То, что на демо выглядит как «готовый сайт», в проекте превращается в набор мест, где нужно руками фиксить архитектуру.
На практике это может быть полезно для прототипа или внутреннего проекта. Для боевого сайта я бы считал экономию только после проверки: кто будет поддерживать код, как обновляться, где лежит логика и не развалится ли всё на первом же изменении.
ИИ не отменяет разработку. Он просто переносит боль в другое место. И это тоже нужно уметь считать.
Схема обычно одна и та же:
1) делаем черновую структуру сайта;
2) просим ИИ собрать фронт и админку;
3) потом добиваем реальную логику — формы, инфоблоки, права, кеш, интеграции.
И вот тут начинается самое интересное. ИИ неплохо помогает на уровне каркаса, но очень быстро упирается в типовые битриксовые вещи: компоненты, шаблоны, наследование, хранение данных, поведение в админке. То, что на демо выглядит как «готовый сайт», в проекте превращается в набор мест, где нужно руками фиксить архитектуру.
На практике это может быть полезно для прототипа или внутреннего проекта. Для боевого сайта я бы считал экономию только после проверки: кто будет поддерживать код, как обновляться, где лежит логика и не развалится ли всё на первом же изменении.
ИИ не отменяет разработку. Он просто переносит боль в другое место. И это тоже нужно уметь считать.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Whatsapp скамят пользователей с помощью поддельных никнеймов
WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.
Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.
Похоже, п…
➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov
🧠 Ещё больше инсайтов → в канале AFF.top
WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.
Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.
Похоже, п…
➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov
🧠 Ещё больше инсайтов → в канале AFF.top