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

В отчёте должны быть все клиенты, включая тех, у кого нет оплаченных заказов. Запрос использует LEFT JOIN, загрузка проходит без ошибок, но часть клиентов всё равно исчезает.

Причина может быть в одной строке: условие по правой таблице поставили в WHERE. А попытка исправить его через OR … IS NULL возвращает не всех, кого ожидали.

Разберём учебный пример: четыре клиента, заказы в двух статусах и витрина с одной строкой на клиента. Посмотрим, где теряются строки, почему COUNT(*) показывает несуществующий заказ и как проверить не только сумму, но и состав результата. Все SQL-примеры ниже проверены в SQLite. Это пример логики данных, а не история из проекта.

Вторая часть про скоринг email-адресов.

В первой я обучил CatBoost отличать живые адреса вроде ivan.ivanov@gmail.com от сгенерированного мусора. Теперь подключаю модель к Node.js-бэкенду, без отдельного Python-сервиса.

Сама модель в ONNX запускается быстро, но основная работа в другом - переписать все признаки на TypeScript так, чтобы они совпадали с Python до последнего бита. Пришлось разбираться с длиной строк в UTF-16, \d в регулярках и прототипами у JS-объектов.

Однажды мне надоело платить за VPS, ресурсов которого едва хватало для запуска Chrome. В поисках альтернативы я вспомнил про без дела лежащий CMF Phone 1 и решил превратить его в полноценный сервер для личных сервисов. Рассказываю, как удалось запустить Linux-приложения на Android, автоматизировать развёртывание и обеспечить доступ из любой сети — и с какими неожиданными проблемами столкнулся в процессе.

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

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

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

Всё начинается довольно невинно.

У вас дома стоит растение. Его нужно поливать, но вспоминаете вы об этом либо слишком поздно, либо после того, как полили «на всякий случай» несколько дней назад. В какой-то момент вы покупаете ESP32, датчик влажности, небольшой насос, открываете несколько роликов на YouTube и понимаете: это же можно собрать за вечер.

И правда можно. Несколько проводов, немного кода: если почва сухая — включить насос. Через час на столе стоит первая система автополива, а в голове появляется приятное чувство, что теперь растение под контролем.

У Slidy есть отличный слоган — «Самая быстрая нейросеть для презентаций». Как выяснилось, в компании довольно быстро могут меняться и предлагаемые должности. Причем кандидат узнает об этом уже из оффера.

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

Представляем вам колонку, написанную Сооснователем компании Битрикс24 Сергеем Рыжиковым.

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

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

21 октября 2026 года мир PHP вздрогнул от анонса двух критических RCE-уязвимостей (CVSS 9.2), получивших общее имя PHP2Shell (CVE-2026-109618 и CVE-2026-109619). Опасность этих брешей в том, что они срабатывают на уровне ядра интерпретатора еще до того, как управление дойдет до первой строчки вашего index.php. Достаточно, чтобы сервер просто принимал HTTP-запросы.

Разработчики PHP оперативно выпустили патчи для поддерживаемых веток (8.2.35, 8.3.36, 8.4.27, 8.5.12) и заявили: «Единственный 100% способ защиты - обновление, а сценарий наивысшего риска - это Apache с mod_php».

Звучит отлично, если у вас свежий проект. А что делать, если в продакшене крутится суровый высоконагруженный энтерпрайз-легаси на PHP 5.6 в связке с Apache 2.4 (mpm_prefork + mod_php), переписать который за ночь невозможно, а официальных патчей для ветки 5.6 не выйдет никогда?

Под катом - практический разбор того, как устроены обе уязвимости, почему именно mod_php оказался под главным ударом и как я выстроил эшелонированную оборону на уровне Varnish → Apache → PHP → Docker cgroups, не сломав легаси-монолит и проверив каждый рубеж боем (с разбором подводных камней HTTP keep-alive).

Я дал Claude Code (Opus 5.5) тестовое задание: нарисовать в SVG сцену из «Бегущего по лезвию 2049». Агенты, которые я пробовал, провалили его одинаково: на настоящий кадр никто не посмотрел, рисовали по памяти и сообщали бездумно, что готово. Тогда я начал подсказывать агенту вопросы: есть ли документация, с чем сравнивать результат, когда остановиться. Из этих вопросов вырос AutoHarness — скилл, который заставляет агента подготовиться к задаче до того, как он начнёт её делать.

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

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

Мы сделали Lumio, чтобы больше так не работать. Это бесплатное приложение для Mac, которое превращает чёлку MacBook в пульт для ИИ-агентов. В версии 1.2 к Claude Code и Codex добавились Cursor и GitHub Copilot в VS Code. Теперь все четыре видны в одном месте, и почти на всё можно ответить, не открывая редактор.

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

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

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

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

«П‑с-с‑с, хочешь, чтобы функция очистки массива была на 49% быстрее? Сдвинь массив на 4 байта».

Рассмотрим следующий код на Go:

const words = 1 << 19

type block struct {
n uint32
data [words]uint32
}
func (b *block) reset() {
b.data = [words]uint32{}
}

Что, если я скажу вам, что всего лишь добавив 4 байта заполнения (padding) между n и data, вы ускорите функцию reset на 49% (по крайней мере, на машинах с Intel)? Звучит безумно?

Привет, Хабр! Я Владимир Лушин, делаю ИИ-агенты и инструменты для работы с кодом. Статья, вроде, серьёзная, но с пуделями. Так уж вышло, что дрессировка собаки объясняет внимание в LLM понятнее любых формул с softmax.

В карточках свежих open-source моделей везде написано «1 млн контекста». Внутри при этом точно читается совсем другое количество токенов: GLM-5.3 выбирает для каждого шага 2048 токенов из истории, DeepSeek-V4-Pro — 1024 сжатых блока, а у Qwen3.8 и Kimi K3 всю историю целиком видит лишь каждый четвёртый слой.

Для агента это быстро становится вполне практической проблемой: правило из AGENTS.md к сотому вызову инструмента тихо перестаёт работать, и «ну вот же оно, в контексте!» уже не аргумент. Я полез разбираться, как устроено внимание в открытых моделях 2026 года и что с этим делать в обвязке, чтобы агент не забывал правила к середине сессии.

Примечание:

- Все свежие открытые модели читают длинный контекст выборочно. Три семейства: разрежённое top-k (GLM-5.x, DeepSeek-V4, MiniMax M3), гибриды «3 линейных + 1 полный» (Qwen3.5—3.8, Kimi K3, GLM-5.3-Flash), скользящее окно + глобальные слои (Gemma 4).

- Гарантированно точно читаются только последние сотни токенов. Всё остальное должно либо «выиграть отбор» по релевантности, либо дожить в сжатом виде.

- У большинства моделей качество ломается где-то в районе 128—256 тыс., а Kimi K3 с компактизацией на 300 тыс. обгоняет саму себя с полным окном в 1 млн.

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

- А то, что нельзя нарушать никогда, закрывайте хуками и правами доступа, вниманию такое доверять не стоит.

Сразу поясню: часть конфигураций я читал прямо из config.json на Hugging Face, часть — из карточек и техотчётов. Где данные вторичные, я это помечаю. А всё про «что модель читает» я вывожу сам из архитектуры, разработчики такого нигде не заявляли.

150 откликов, ноль интервью. Но виноват, конечно, рынок труда.

В IT принято автоматизировать процессы, искать узкие места и разбираться, почему система не работает.

Но когда дело доходит до собственного трудоустройства, вся аналитика куда‑то исчезает. Отправили 150 откликов, не получили ни одного интервью? Значит, надо отправить ещё 150.

Если бы так работал отдел продаж, у руководителя давно возникли бы вопросы. А у соискателя обычно один вывод: «Работы нет».

Я больше восьми лет занимаюсь IT‑рекрутингом, и у меня для вас неприятная новость: 150 откликов — это не 150 работодателей, которые изучили ваш опыт и решили отказать. Разбираю, что происходит по другую сторону вакансии и почему, пока одни кандидаты считают отклики, другие выходят на рекрутеров и руководителей напрямую.

Заодно покажу, как собрать собственную исходящую воронку поиска работы. Без волшебных ботов и надежды, что на 151-м отклике наконец повезёт.

В октябре пострадали три площадки одного из крупнейших российских провайдеров: на первой после пожара остановились все системы, на второй несколько модулей вышли из строя полностью, а третью остановили целиком, и облако перешло в аварийный режим (разбор на Хабре, «Коммерсантъ»). Весь рунет спрашивал когда всё заработает. А вот ИТ-службы куда реже спрашивали себя, что придётся восстанавливать, если такое случится у них.

Я написал self-hosted мониторинг для Linux- и Windows-серверов на Go и Next.js, потому что готовые варианты были либо слишком тяжёлыми в настройке, либо выглядели и настраивались как из прошлого десятилетия. После первого релиза я пересмотрел три решения: перевёл хранилище с JSONL на SQLite в режиме WAL, заменил текстовое поле permissions у модулей на явные разрешения и защитил подключение каталога модулей от SSRF. Рассказываю, что и почему менял, и что всё ещё сырое.

Привет, Хабр! Меня зовут Антон Ивахненко, я глава по технологиям группы Рунити. Последний год ко мне всё чаще приходят с одним и тем же вопросом, только в разных формулировках. «А действительно ли команде нужно столько людей?», «Давайте сделаем ее меньше, но будем успевать больше», «Как нам сделать команду эффективнее?». Обычно это звучит от нетехнического топ-менеджмента, и за этим стоит понятное давление: рынок с одной стороны, новые технологии с другой, и от ИТ ждут оптимизаций.

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

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

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