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

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

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

Команда VK Cloud перевела второй пост из серии трёх частей о том, как Cilium укрепляет свой CI/CD-конвейер. Первая часть рассказывала про управление доступом: кто может запускать сборки и какой CI-код разрешено исполнять. Этот пост про уровень зависимостей: какой код эти сборки подтягивают и как мы убеждаемся, что его не подделали.

В 1990-м Titus выпустила Fire & Forget II: гонку, где спорткар с пулемётом умеет взлетать. Я гонял её ребёнком с одной дискеты, а недавно полез внутрь её бинарника, просто посмотреть, как она устроена. Внутри оказалось неожиданно много: кооперативная многозадачность на голом 8086, собственный скриптовый язык с французскими мнемониками, две виртуальные машины, исполняющие один и тот же байткод, и полминуты игры самого разработчика, спрятанные в демо-записи. Их не видел никто и никогда. По дороге игра пересобралась на C11 и теперь живёт в браузере: не трогайте клавиатуру в меню, и увидите то самое демо. Но статья не про порт:

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

Полгода я жил в одном и том же цикле. Собираешь скрапер, вечером он проходит все страницы, а к обеду следующего дня отдаёт сплошные капчи и 403. Добавляешь puppeteer-stealth, сверху ещё десяток заплаток, гонишь трафик через резидентные прокси, и всё равно на третьи сутки прилетает бан. Я устал чинить симптомы и сел разбираться, что именно нас выдаёт.

Видели ли вы, как пользователи объясняют неудачи в продукте собственной глупостью? Может, слышали в кулуарах, как разработчики соглашаются с пользователями и не знают, чем помочь, — ведь «всё предельно понятно», «для дураков сделано». А бизнес-команда между тем опускает руки и задаётся вопросом, не дураки ли они сами, если не могут донести логику продукта до пользователя?

Меня зовут Анастасия Лестова, и я социальный антрополог с инженерным бэкграундом, а сейчас исследую опыт пользователей в Контур.Маркировка. В своём докладе на CodeFest 2026, опираясь на социальные науки и нейробиологию, я рассказала, что жизненный контекст и плохие интерфейсы делают с психикой и мозгом пользователя (спойлер: буквально снижают его когнитивные способности). А в сегодняшней статье раскрою тему более детально. Понимая психофизиологические механизмы происходящего, мы разберёмся, как всё это лечить с помощью конкретных инструментов в интерфейсе. 

Мозг и сознание человека остаются одними из самых загадочных систем, которые на протяжение многих веков изучают как нейробиологи, так и психоаналитики. Развитие технологий и наук позволило выяснить определенные аспекты работы мозга, установить их связь с окружающей средой и проявление в точки зрения психики человека. Многие теории прошлого оказались либо ошибочны, либо искажены ввиду тогдашних социальных и культурных мнений. Однако есть и те, которые получили подтверждение спустя много лет. Ученые из Университета Осло (Норвегия) провели исследование, в котором сопоставили современную теорию мозга, именуемую «прогнозирующее кодирование», с теориями Зигмунда Фрейда и других его коллег. Детали этого сравнения мы узнаем из доклада ученых.

Что мы знаем о повороте на определённый угол и его удержании в робототехнических системах? 

Думается, что на данный момент, мы все настолько сильно подсели на разнообразные цифровые устройства, алгоритмы и принципы, что нам (наверное, что даже и большинству), зачастую, даже сложно себе представить, что подобная задача может быть решена и кардинально иным способом! :-)  

Тем не менее, в истории существовали (и даже в данный момент существуют!) целый класс абсолютно иных аналоговых устройств, который вполне себе успешно справляется с тем же самым вопросом — и называются подобные устройства «сельсины»…

Всем привет! Меня зовут Олег Джулаев, я автор Projecto.

Я давно выбрал фриланс и в связи с этим часто участвую в разных проектах. Со временем заметил, что какими бы уникальными ни были проекты, я выполняю одну и ту же работу изо дня в день. Зная тип задачи и её примерный объём, я легко могу представить себе время, которое на неё потрачу. Но редко бывает так, что одна задача занимает весь день. Обычно это что-то фиксированное – 3, 4 часа, 5 часов… Но чем занять оставшееся время? Как сбалансировано уделять внимание разным проектам и заказчикам? Так я неосознанно пришёл к работе на основе слотов, о ней и расскажу в статье.

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

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

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

Всем привет! На связи снова Angara Security. И сегодня у нас разговор по-честному. У всех компаний разный уровень зрелости ИБ. Это нормально. Если у вас всё выверено, процессы отлажены, а системы управления уязвимостями (VM) и SIEM слаженно работают в паре — это уже сильный результат. Но даже тогда системы могут не складывать картину: VM знает, где уязвимость, а SIEM видит атаку.

Эта статья будет полезна, если:

1. у вас пока только VM-решение или вы уже начали думать: «А что дальше? Куда двигаться?»;

2. есть и системы классов VM, и SIEM, но они существуют параллельно: данные не пересекаются, корреляции нет, эффект от систем оставляет желать лучшего.

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

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

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

Десять дней разработки — и язык, на котором держится веб. В этой статье — история 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 – под катом расскажем о том, почему мы это сделали, с какими трудностями столкнулись и какие выводы сделали.