Kurgan-Telecom Ru | Информационные технологии

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

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

Это само по себе печально, но я бы хотел поговорить кое о чём ещё более прискорбном: назовём это теорией мёртвой экономики.

Десять дней разработки — и язык, на котором держится веб. В этой статье — история JavaScript и инструментов, которые привели его к этому.

Кратко

SEO для SaaS — это не одна механика, а три разные: контентный подход (растём на статьях и длинном хвосте), продуктовый (выводим в топ и докручиваем сами страницы сервиса) и массовый (программно генерируем тысячи похожих страниц под низкочастотку). Они дают разный результат, разную скорость и разные риски. Большинство сервисов сжигают бюджет не потому, что делают SEO плохо, а потому что взяли подход не под свою структуру спроса. Ниже — как они устроены под капотом, на реальных дашбордах Метрики и Топвизора, и как выбрать свой.

Привет, на связи Дмитрий, основатель агенства Сайткрафт. За последние годы мы вели поиск для десятков SaaS и онлайн-сервисов, и почти на каждом старте слышим один и тот же запрос: «сделайте нам SEO, нужен трафик и заявки». Проблема в том, что под этой фразой прячутся три совершенно разных проекта. Их легко перепутать на старте, и тогда полгода уходит впустую: трафик вроде растёт, а заявок нет, или позиции есть, а индекс выкашивает фильтр. В этой статье разберу три подхода к SEO для онлайн-сервиса инженерно — что внутри каждого, на каких данных видно, что он работает, и как не выбрать чужой.

Содержание

1. Почему один и тот же SEO у двух SaaS даёт разный результат

2. Подход 1 — контентный: рост на статьях и длинном хвосте

3. Подход 2 — продуктовый: заявки дают сами страницы сервиса

4. Подход 3 — массовый: тысячи похожих страниц под низкочастотку

5. Три подхода в одной таблице

6. Как понять, какой подход ваш

7. Сколько ждать результата и чем мерить

8. Частые вопросы

Вторая пачка глав из "Книги среднего уровня", которая для руководителей среднего звена, действующих и начинающих. Книга живёт и пишется в тг.

Есть некоторые привычки, от которых придётся избавиться, вползая на руководящий пост. Первая – перфекционизм, т.е. обязательное стремление сделать всё хорошо. И всё, и хорошо.

Когда ты работаешь специалистом, быть перфекционистом – нормально. Это не единственный, и не всегда лучший путь (к тому же зависит от профессии), но он вполне себе допустим. Некоторые высоко поднимаются благодаря перфекционизму, или занимают особую, уникальную нишу.

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

Так вот, быть перфекционистом в собственных делах для начальника – ещё куда ни шло, это допустимо. Хотя и будет создавать ненужное напряжение у подчинённых – они всегда невольно сравнивают себя с руководителем. Если тебе ну вот совсем никак без перфекционизма – будь им, но хотя бы не выпячивай, не тыкай подчинённых носом в «смотрите, как я аккуратно веду список задач, хорошо бы все так делали».

А вот командный перфекционизм – «вся команда должна делать и всё, и хорошо» - стоит напрочь выбросить и забыть. Иначе, совершенно точно, тебя ждёт большой медный таз (кроме каких-то совсем исключительных случаев, вроде сплошных перфекционистов в отделе).

В 2002 году новая компания SpaceX поставила перед собой цель, которая казалась почти нереалистичной: создать более дешёвую ракету с нуля и выйти на орбиту. В «Космос ближе» журналист Ars Technica Эрик Бергер рассказывает реальную историю этого проекта — без глянца и без попытки превратить её в легенду про «одного гения».

Это не сухой технический отчёт, но и не мифология Кремниевой долины. Скорее, это хроника выживания: серия рискованных решений, инженерных ошибок и быстрых итераций, которые в итоге сложились в прорыв.

Главное достижение Бергера — фокус не на сегодняшнем успехе, а на ранних годах компании, с 2002 по 2008. Это период, когда SpaceX балансировала на грани закрытия, а её ракеты взрывались одна за другой. Автор получил доступ к ключевым сотрудникам и подробно восстановил историю запусков Falcon 1 — с инженерными деталями и человеческим фактором.

Привет! Я Ольга Матушевич, преподаватель курса «Нейросети для бизнеса», а в прошлом ментор Мастерской Яндекс Практикума. В e-commerce и маркетинге есть множество наработанных методик. Но как применить их там, где цель — не прибыль, а спасение жизней? 

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

Мы выбрали необычное решение — применить RFM-анализ, классический инструмент из маркетинга. В статье я расскажу:

— почему мы отказались от машинного обучения в пользу с-анализа,
— как переосмыслили классическое определение метода под некоммерческую задачу,
— чем заменили «деньги», «покупки» и «покупателей» в RFM-анализе,
— и к каким семи классам доноров в итоге пришли.

Статья будет интересна тем, кто работает с некоммерческими проектами: у кого часто есть данные, но нет готовых методологий. А ещё — тем, кто хочет посмотреть, как переосмыслить классические бизнес-инструменты для нестандартных задач.

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

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

Эта усталость идёт с оттенком отвращения к инструменту, предсказуемость которого пока далека от совершенства, а детерминированностью он вообще не обладает. А так как всем нам по природе очень важна определённость, то я и пытался разобраться, где её стоит ждать, а где нет.

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

Уже несколько лет мы занимаемся развитием клиентского приложения на Flutter: начинали с мобильных платформ, когда веб и десктоп вышли в бету – портировали его и на эти платформы. Последние два года PWA крутится в проде и в некоторых регионах является самой популярной платформой для нашего приложения.

Недавно мы попробовали мигрировать наше приложение с Flutter Web на Jaspr – под катом расскажем о том, почему мы это сделали, с какими трудностями столкнулись и какие выводы сделали.

Интернет-соединения не будет, если роутер не включен в розетку, смартфон разрядится, GPS-приемник потеряет сигнал без источника питания — все прорывные изобретения завязаны на свете, настолько глубоко встроенном в современную цивилизацию.Очень сложно вообразить, каким был мир всего 150 лет назад, до изобретения электрического уличного освещения. И что такое по-настоящему темная ночь. 

Много тысячелетий — всю историю человечества — именно ночь ограничивала рабочий день, диктовала ритм жизни городов, формировала культурные практики, религиозные представления и даже научные открытия. 

Сегодня уже несколько поколений городских жителей выросли, видя Млечный Путь только на фотографиях — и, может быть, пора подумать, стоила ли жертва того? Особенно если учесть, что мы про эту жертву даже не в курсе. 

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

В ходе анализа одного из подобных образцов была исследована полная цепочка заражения — от письма с вложением Excel до запуска LuaJIT-загрузчика и последующего инфостилера. Интересной особенностью является использование файлов с нестандартными расширениями (.PIF и .TTF), которые на самом деле не являются ни ярлыком, ни шрифтом.

Давайте рассмотрим каждый этап работы вредоносной цепочки.

Этой статьей я постараюсь логично завершить эксперимент с ханипотом и рассказать про анализ вредоносного ПО силами ИИ. Идея проекта простая: проверить, может ли связка из изолированной виртуальной машины, классических инструментов анализа ВПО и LLM-агента дать не только красивый отчет, как было в прошлый раз, а реально полезный материал для борьбы с вредоносами.

Всем привет. Наверное, это боль многих за последнее время, кто пытается завести «бесплатный прокси из бота», что последнее время рилсы зависают на 5-й секунде, в Telegram бесконечное соединение, а Gemini даже под VPN говорит тебе идти лесом

Проблема в том, что в нынешних реалиях окончательно перешли на Behavioral Analysis и Flow-based Blocking. Больше не нужно расшифровывать ваш трафик достаточно смотреть на размеры пакетов, тайминги и энтропию.

Разберем три самые болезненные проблемы и варианты их решения, если ищите более простые варианты в конце статьи привел их примеры:

Всем привет! Хочу поделиться выходным проектом, который вырос из чистой вкусовщины: мне надоело смотреть на бегущие строчки в терминале, и я сделал так, чтобы мои ИИ-агенты сидели в пиксельном офисе, пили кофе и приносили ответы лично. Подробнее — под катом.

Мы запускаем семейство моделей GPT-5.6 в общий доступ после ограниченного предварительного тестирования: наш новый флагман Sol, сбалансированную модель для повседневной работы Terra и Luna — нашу самую экономичную модель.

GPT-5.6 Sol задаёт новый стандарт одновременно в интеллекте и эффективности: модель показывает лучшие в своём классе результаты в программировании, работе со знаниями, кибербезопасности и науке, превосходя предыдущие и конкурирующие передовые модели при меньшем числе токенов и более низкой расчётной стоимости. В итоге пользователи получают более высокую отдачу на каждый потраченный доллар: больше успешно выполненной работы за тот же бюджет или сопоставимые результаты при меньших общих затратах. Мы также представляем новый способ ускорить самые сложные задачи: ultra — наш режим максимальных возможностей, который координирует несколько агентов в параллельных рабочих потоках, чтобы быстрее завершать комплексные проекты. Более уверенное использование компьютера и более точное дизайнерское чутьё делают GPT-5.6 Sol нашим самым отточенным партнёром на сегодняшний день: модель помогает проверять, дорабатывать и выдавать готовые к использованию результаты.

Всех приветствую! Когда речь идет о мобильных играх, то сразу все говорят: Unity, Unreal Engine, Godot. Большинство разработчиков тянут эти огромные комбайны просто " по привычке", априори считая что "сделать по другому" или писать "свой движок" это нереально, да что там... просто невозможно. Лично я никогда не встречал игру сделанную на Unity, которая сразу прекрасно работает. У телефона 3 гига оперативки? Пф, умри, несчастный, ты и так тупишь, кладбище вон там, могила вот тут. А почему так происходит? А потому что индустрия всех приучила что это "Абсолютный золотой стандарт". Люди, при этом, выбирают такие подходы, либо из за желания сделать быстрее, либо по незнанке, что можно сделать не так.
Когда, простигоспаде... геймдизайнер, выбирает подобного рода движки он автоматом закрывает глаза на следующие проблемы:

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

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

Ранее мы уже предпринимали всевозможные ухищрения, чтобы ускорить компиляцию: стирали типы, активно продавливали дедупликацию кода, сокращали строки, связанные с генерацией кода. В этом мы достаточно преуспели. Но недавно мы стали осваивать работу с крупным новым клиентом (энтерпрайз), у которого оказалась масса сложного SQL-кода. Они написали при помощи наших инструментов много больших программ. Например, там был образец размером в 8562 строк на SQL, который наш компилятор в итоге превращал примерно в ~100k строк на Rust.

Июль 2026 года для OpenAI оказался выходит насыщенным: она одновременно обновила два разных уровня своей платформы: базовый слой языковых моделей и слой голосового взаимодействия. GPT-5.6 вышла как новое семейство моделей для API и Codex, а GPT-Live стала новой голосовой системой ChatGPT Voice. В сумме это выглядит не как косметический релиз, а как заметный сдвиг в архитектуре продуктовой линейки OpenAI.

Если упростить до одной фразы, то GPT-5.6 отвечает на вопрос «какую текстовую модель выбрать под конкретную задачу», а GPT-Live — на вопрос «как вообще должен выглядеть голосовой интерфейс с ИИ в 2026 году». И именно поэтому эти анонсы стоит рассматривать вместе.

Привет, Хабр. Я уже не тот беззаботный парнишка, что собирал 486-й компьютер. Время бежит, я скуф успел поработать с C++, C#, Java и Kotlin, последние 10 лет занимаюсь мобильной разработкой. Программирование я до сих пор люблю потому что больше ничего не умею. Но чем дольше работаешь, тем чаще ловишь себя на мысли, что от некоторых вещей начинает подгорать. Сегодня я расскажу, как я попытался избавиться хотя бы от части таких вещей.

Сайт на Тильде может получать поисковый трафик.

В 2026 году это уже странно доказывать: в выдаче достаточно проектов на конструкторах, у которых индексируются страницы, растут запросы, приходят заявки.

Поэтому вопрос лучше ставить практичнее: в каких случаях Тильда выдерживает SEO-задачу, а в каких начинает мешать работе.

Регулярные выражение обладают возможностями отслеживания пройденного пути и рефлексией. Разберемся, как использовать эти возможности для захвата фрагментов текста, как применить к ним цвет и вывести в консоль с помощью AutoHotkey.