IT Weekly Pro
72 subscribers
55 photos
1 video
60 links
Download Telegram
**Linux всё чаще выигрывает не за счёт кастомизации, а вопреки ей.** Между нами говоря, это заметный сдвиг: раньше дистрибутив был только отправной точкой, а дальше начиналась сборка своей рабочей среды — от оконного менеджера до десятков скриптов и конфигов.

Теперь для многих задач достаточно Fedora с GNOME «как есть»: код, браузер, видео для демо — всё поднимается без ритуалов и допиливания. И это не про лень, а про зрелость стека. Когда базовая система уже закрывает типовые сценарии, выигрывают не те, кто накрутил больше всего `dotfiles`, а те, кто быстрее дошёл до результата.

Инсайдерски это хорошо видно по enterprise-практике: ценность смещается от «идеального окружения» к **предсказуемости, поддерживаемости и скорости онбординга**. Для CTO и platform-команд это важнее любого эстетического i3.
Между нами говоря, в начале июня снова всплыла знакомая картина: у части пользователей внезапно перестали жить `xray + VLESS + REALITY` и похожие связки. Это не выглядело как обычный «упал сервер» — проблема шла волной и била по довольно типовой конфигурации.

Что важно: речь не про единичные банальные блокировки, а про _схему ограничений_, где ломается не один домен или IP, а сама работоспособность популярного класса обходных решений. Для команд, которые держали инфраструктуру на стандартных пресетах, это означало быструю переоценку модели риска.

Практический вывод простой: если у вас антиблок работает только на одной технологической тропинке, это уже не защита, а точка отказа. Нужны запасные маршруты, разнос по протоколам и мониторинг признаков деградации не по факту падения, а по ранним симптомам.
И да, такие волны обычно проверяют не только технику, но и готовность процессов.


Хочешь больше битрикс? @BitrixStackPro
Вижу это всё почти в каждой второй крупной команде: сверху прилетает установка «нужно внедрить ИИ в разработку», снизу — воркшопы, гайды, агенты, плагины и отдельные инструкции, как теперь _правильно_ писать код.

И между нами говоря, раздражение тут не про сам ИИ. Проблема в другом: его часто продают как универсальный ускоритель, хотя в реальности он просто переносит узкое место из `написания` в `проверку` и `интеграцию`.

Если у команды слабые тесты, размытые требования и хаос в ревью, ИИ это не лечит. Он лишь быстрее генерирует тот же хаос. Для CTO и техлидов это важный сигнал: считать надо не «сколько кода создал агент», а **сколько времени ушло на доведение результата до production-grade**.

Похоже, следующий этап зрелости рынка — не «всем срочно AI-first», а нормальная дисциплина: где ИИ реально помогает, где ускоряет, а где только создаёт новый слой шума.
Между нами говоря, у части людей «усталость после ковида» уже давно не про недосып и не про дедлайны.

Копятся данные, что у переболевших SARS-CoV-2 может тянуться **сосудистое воспаление** — отсюда неочевидный набор жалоб: постоянная разбитость, туман в голове, скачки давления, странная метеочувствительность, кровоточивость дёсен по утрам. Не у всех, но достаточно часто, чтобы это перестало выглядеть как совпадение.

Технически это неприятная история: вирус ушёл, а следы в эндотелии и микроциркуляции остаются. И тогда человек месяцами лечит «стресс», меняет режим, пьёт кофе литрами — а проблема никуда не девается.

Вывод простой: если после ковида или очередной «лёгкой простуды» симптомы держатся неделями, это уже не повод геройствовать. Тут нужен не самообман, а нормальная диагностика. И да, списывать всё на возраст — слишком удобная, но слабая версия.
Между нами говоря, сейчас в локальном ИИ чаще упираются не в FLOPS, а в **VRAM**. И вот здесь начинается интересное: один энтузиаст собрал на обычном игровом ПК связку из RTX 4080 и серверного GPU из датацентра, подключив его через адаптер — без нормального PCIe-коннектора, зато с **32 ГБ видеопамяти** на борту.

Итог практический, без маркетинга: локальная модель на **27B** параметров запускается и выдаёт около `32 tok/s`. За всё про всё — примерно `£200` за вторую карту. Для CTO и архитекторов это хороший маркер: рынок б/у и датацентровых GPU всё ещё может быть самым дешёвым способом добрать память под inference, если вас не пугают совместимость, питание и инженерный зоопарк.

Вывод простой: **для локальных LLM память по-прежнему важнее “красивой” игровой карты**. И, кажется, этот трюк ещё не раз всплывёт в продакшн-экспериментах.
Похоже, вокруг RuStore снова всплыл очень неприятный разбор: в APK нашли поведение, которое слабо укладывается в роль обычного магазина приложений. Если верить декомпиляции, там есть скрытый трекинг GPS с записью в локальную БД каждые несколько минут, фоновые установки пакетов по команде с сервера, сбор экранного времени, попытки обхода ограничений Android 10+ по идентификаторам устройства и отдельные интеграции, которые могут отдавать токены авторизации без явного согласия пользователя.

Что важно для тех, кто смотрит на это как на инфраструктурный риск, а не как на скандал: предустановленный стор — это уже не «ещё одно приложение», а точка системного доверия. Если в ней реально есть такие механики, речь не про UX, а про контроль над устройством на уровне платформы.

Я бы здесь ждал не эмоций, а внятной реакции в коде и документации: что именно собирается, где хранится, как отключается, и кто это аудировал. Пока же выглядит так, будто национальный стор ведёт себя слишком уверенно для продукта, который должен просто ставить приложения.
Внутри Yandex Infrastructure сделали полезный сетевой инструмент, который обычно появляется только у тех, кто регулярно ездит по удалённым точкам. Павел Семенищев из NOC рассказал о WiProber для Android и WiFi Prober для iOS — приложениях для быстрой диагностики Wi‑Fi на месте.

Контекст тут важнее самого релиза: у команды на попечении не только магистрали и дата-центры, но и офисы, склады, дарксторы. То есть много локаций, где проблему надо понять за минуты, а не ждать выезд «настоящего» сетевика. Поэтому сканер собрали как внутренний комбайн для полевого инженера, а затем вытащили в общий доступ. 📶

Интересен не сам факт «ещё одного app», а то, как под мобильные ограничения выжимали максимум из iOS и Android, чтобы увидеть сетевую картину быстро и без лишней магии. Для инфраструктурных команд это редкий класс инструментов: не мониторинг из дата-центра, а диагностика последней мили на месте.
Китай сейчас делает редкую для отрасли вещь: не ставит на одну “главную” ракету, а ведёт сразу несколько программ, которые все так или иначе целятся в класс Falcon 9. И это не просто копирование формы — у проектов разные двигатели, топливо, схема посадки и уровень участия государства.

С инженерной точки зрения логика понятна: параллельные ветки позволяют быстро проверить, что реально работает в китайской экосистеме — от многоразовости первой ступени до повторного использования узлов и наземной инфраструктуры. Похоже, ставка не на красивый единичный запуск, а на накопление опыта через серию конкурирующих решений 🚀

Инсайд здесь в том, что китайский рынок пусков, вероятно, уже перешёл от фазы “догнать SpaceX” к фазе “выбрать рабочий стандарт”. И когда у тебя несколько команд одновременно бьют в одну задачу, победит не самый громкий проект, а тот, который быстрее даст стабильную экономику запусков.
Рекламный рынок уходит от «покажи баннер и надеемся на охваты» к модели, где платят за результат. И это уже не просто тренд у инфлюенсеров — я бы смотрел на это как на сдвиг в том, как вообще будут продаваться digital-интеграции.

По данным исследования VK AdBlogger, каждый второй блогер ожидает, что процент с продаж станет основной схемой монетизации в ближайшие годы. Для 69% главным KPI рекламы уже стали именно продажи, а не просмотры или клики. Оптимальной вилкой вознаграждения называют 10–20% от заказа.

Что это меняет для рынка:
— брендам проще считать ROMI и защищать бюджет;
— авторам приходится брать на себя часть коммерческого риска;
— платформам нужны нормальные трекинг, атрибуция и антифрод, иначе процентная модель быстро ломается.

Системно это похоже на переход от медиаразмещения к performance-партнёрству. И, как обычно, выигрывают те, у кого лучше аналитика, а не громче охваты 🙂
Похоже, ковид оставил не только память в статистике, но и след в сосудистой системе. Я слышал этот набор жалоб уже не раз: хроническая усталость, «туман» в голове, скачки давления, странная метеочувствительность, утренние кровотечения при чистке зубов. Раньше это легко списывали на стресс, недосып и возраст. Сейчас картина выглядит менее случайной.

За последние годы накопилось уже достаточно данных: примерно треть переболевших отмечают стойкие симптомы спустя месяцы, а среди пациентов с постковидным синдромом усталость и когнитивные сбои встречаются почти у всех. Важный нюанс — речь не про драматический редкий сценарий, а про массовый, но плохо узнаваемый эффект.

Технически проблема не в «слабом иммунитете», а в долгом повреждении эндотелия — внутренней выстилки сосудов. Отсюда и размытая симптоматика: мозг не включается как раньше, давление ведет себя нервно, нагрузка переносится хуже. И да, это уже не выглядит как просто выгорание 😐

Что важно для бизнеса и команд: если у человека месяцами падает концентрация и выносливость, это влияет не только на самочувствие, но и на качество решений. А значит, постковид — это уже не только медицинская тема, но и фактор производительности.
C++ снова напоминает старый корпоративный монолит: внешне всё знакомо, но под капотом — несколько поколений решений, которые до сих пор живут бок о бок. Многие «классические» идиомы родились ещё до C++11, когда не было ни `unique_ptr` и `shared_ptr`, ни move-семантики, ни `constexpr`, ни концептов. Тогда шаблоны и перегрузки закрывали то, что сейчас язык даёт почти из коробки.

Интересно, что эти приёмы не ушли в музей. В движках, играх и высоконагруженной инфраструктуре они до сих пор работают там, где абстракция начинает стоить дороже, чем польза. И да, это тот редкий случай, когда легаси — не ругательство, а накопленный опыт, зашитый в код.

Если смотреть на C++ не как на «сложный язык», а как на слой исторических решений, картина становится понятнее: почему старый код выглядит именно так, какие паттерны действительно живы, и где знание пары идиом до сих пор отличает сильного инженера от просто уверенного пользователя компилятора ⚙️
Redmine жив и, судя по тому, что слышу от команд, будет жить ещё долго — не потому что «любят старое», а потому что он банально закрывает базовую задачу без лишней магии. Для небольших команд с отлаженным процессом это часто рациональный выбор: бесплатно, на своём сервере, предсказуемо, без сюрпризов в лицензиях и апдейтах.

Но у этой экономии есть цена. Как только проект начинает обрастать плагинами, интеграциями, кастомными статусами и ручными обходными сценариями, Redmine превращается не в систему управления задачами, а в коллекцию технического долга. И тогда считать нужно уже не «сколько стоит SaaS», а сколько человеко-часов сгорает на поддержку старой схемы.

Здравый критерий простой: если команда до 15 человек, процесс стабилен и систему не трогают руками каждую неделю — можно не трогать и Redmine. Если же нужен нормальный workflow-движок, аналитика, интеграции и меньше самописной боли — пора сравнивать альтернативы не по интерфейсу, а по цене миграции, данным и сохранению процессов. ⚙️
Онлайн-звонки выглядят просто, пока не начинаешь разбирать, как именно браузер вообще находит другой браузер за NAT и корпоративными фаерволами.

Здесь на сцену выходят WebRTC, STUN и TURN. Если упростить: STUN помогает клиентам понять свой внешний адрес, а TURN подхватывает трафик, когда прямой маршрут не складывается. В реальной продовой среде это не «приятный бонус», а базовая механика, без которой часть звонков просто не взлетит.

Интересно другое: поверх этого слоя уже строят не только видеосвязь, но и сценарии с ИИ — от транскрибации до живых ассистентов в конференции. И тут критично не просто «собрать видео», а держать latency, качество и устойчивость под нагрузкой 📡

LiveKit в этой схеме выглядит как практичный слой для сборки такой платформы: меньше самописной боли, больше контроля над медиа-пайплайном и интеграциями. Для команд, которые делают enterprise-решение, это уже не про «модный стек», а про скорость вывода и эксплуатацию.
Похоже, классический roadmap «по фичам» всё хуже живёт в реальности. Я слышал это уже не только от продактов, но и от CTO: когда рынок дёргается каждые пару месяцев, список релизов быстро превращается в иллюзию контроля.

Сценарный roadmap — это не про «что именно мы успеем сделать к Q3», а про набор развилок: если меняется спрос, регуляторика, стоимость инфраструктуры или поведение конкурента, у команды уже есть готовый план переключения. Вместо жёсткой очереди фич — приоритеты, триггеры и варианты действий.

Это особенно полезно для enterprise и платформенных продуктов: там почти всегда есть внешние ограничения — безопасность, compliance, облачные бюджеты, зависимость от вендоров. И чем сложнее стек, тем опаснее планировать как будто мир стабилен.

Интересно, что такой подход дисциплинирует лучше обычного roadmap: он заставляет заранее отвечать не только на вопрос «что делаем», но и на «что будем резать, если сценарий не сойдётся» 🧭
На Python backend-собеседованиях я всё чаще вижу один и тот же паттерн: джунов валят не на «сложных алгоритмах», а на базовых вещах, которые должны быть у них в мышечной памяти.

10 типовых вопросов обычно крутятся вокруг:
— разницы между list и tuple;
— mutable/immutable и почему это важно для аргументов функций;
— GIL и что он реально ограничивает;
— как работают генераторы и чем они полезны в backend;
— декораторы и порядок их применения;
— context manager’ы;
— `*args` / `**kwargs`;
— исключения и когда их ловить;
— различия между `is` и `==`;
— как устроен async и где он уместен.

Инсайд тут простой: интервьюер смотрит не на заученный ответ, а на то, умеет ли кандидат объяснить поведение Python на уровне эксплуатации сервиса, а не учебника. Особенно ценят, когда человек сразу связывает ответ с продом: память, конкурентность, читаемость, ошибки в рантайме.

Если готовитесь к интервью, учите не список, а причинно-следственные связи. На Python backend это обычно и есть разделитель между «читал» и «работал».
У платного трафика есть неприятная особенность: лиды вроде бы есть, а в CRM — мусор. Номер 123, 1111111, пустое имя, одноразовая почта. Клик оплачен, форма отправлена, а дальше — тишина.

На практике это обычно не «плохие пользователи», а смесь из случайных отправок, тестов формы и банального нежелания светить реальные контакты. Для бизнеса разницы почти нет: бюджет сгорает, а отдел продаж тратит время на фантомы.

Что обычно помогает:
— валидация телефона и email на входе;
— антифрод-сигналы: скорость заполнения, повторяющиеся паттерны, подозрительные IP;
— отдельная логика для платного трафика, а не общий лендинг для всех;
— сверка не только по лидам, но и по качеству до сделки.

Я слышал, что у нескольких команд резкое улучшение дало не «ещё один лид-магнит», а именно жёсткая фильтрация формы и пересмотр атрибуции. Меньше заявок на бумаге, но выше доля тех, с кем реально можно работать.
Forwarded from AffPapa! Клуб спящих бизнесменов! Потрачено!
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 aff.top — вся индустрия арбитража в одном месте
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
На практике самые дорогие ошибки в найме почти никогда не выглядят как авария. Команда укомплектована, релизы выходят, отчёты сходятся — и именно поэтому потери замечают поздно.

Я слышал этот сюжет не раз: на критическую роль берут «сильного универсала», но профиль не совпадает с задачей. В итоге страдают не только сроки. Проседают качество решений, скорость согласований, стоимость ошибок в инфраструктуре и даже стабильность продуктовых метрик. 📉

Для CTO и PM здесь важен не сам факт найма, а точность попадания в контекст: зрелость команды, уровень неопределённости, зона ответственности, цена промаха. На таких позициях дешевле потратить больше времени на верификацию, чем потом месяцами разгребать скрытый ущерб.

Вывод простой: прибыль часто утекает не на рынке и не в облаке, а в людях на узких местах системы. И это одна из тех проблем, которые видно только по накопленному эффекту, а не по одному провальному интервью.
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
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
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