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

Десятилетиями мы искали жизнь не там.

Астрономы всего мира молились на один показатель — ESI (Earth Similarity Index). Если планета имела размер как у Земли и находилась в «зоне Златовласки», заголовки трубали: «Открыта Вторая Земля!». NASA радовалось, пресса ликовала, гранты выделялись.

Но всё это было иллюзией.

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

Сегодня я представляю Закон Экзолоджики — новый фундаментальный принцип, который математически перечёркивает старые списки и вводит жёсткий физический фильтр для поиска жизни. На основе анализа 42 экзопланет через систему ExoLogica AI мы доказали: обитаемость зависит не от температуры, а от плотности.

И результаты шокируют. Знаменитый Kepler-452 b («кузен Земли») вылетает из списка обитаемых миров мгновенно. Ross 508 b, Teegarden's b — тоже. Но есть и хорошие новости: настоящие кандидаты наконец-то найдены.

Приготовьтесь. Эпоха наивного поиска закончилась.

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

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

Год назад METR доказали что AI замедляет разработчиков на 19%. В феврале 2026 обновили данные - похоже на разворот к ускорению. Но об этом почти не написали. Зато «AI уволит 50% разработчиков» - в каждом втором заголовке. Полез разбираться, кому выгодна AI-паника. Нашёл CEO, которые увольняют тысячи и тихо нанимают обратно. Нашёл вендоров, которые пугают увольнениями и одновременно открывают вакансии. И курсы «защити карьеру от AI» за $23 000.

Однажды утром вы открываете задачу и понимаете: единственный человек, который знал, как это работает, вчера уволился. Знания ушли вместе с ним.

Сегодня (2026.04.01) прошло ровно 9731 день с тех пор, как сообщество Python узнало об изъяне в работе со строками.

Это было так давно, что у Python еще не было мажорных версий (для холиваров приходилось использовать PHP).

Так давно, что еще не существовало ни pythonchallenge.com, ни его прародителя notpron.com - легендарных убийц времени программистов.

Это было в прошлом тысячелетии. А именно - 1999 году, когда, согласно летописям, реализовали тип string. В том же году ведущий разработчик Jim Fulton опубликовал исследование, где без купюр указал на проблему.

Как ни странно, она не решена до сих пор.

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

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

В конце прошлого года лауреатами премии стали сразу три человека: Джоэль Мокир, Филипп Агион и Питер Хоуитт. Мокир получил половину премии за выявление предпосылок устойчивого роста через технологический прогресс, Агион и Хоуитт — вторую половину на двоих за теорию устойчивого роста через созидательное разрушение.

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

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

И после возникает логичный вопрос: Если привязанность — это протокол, то кто его настроил?

Если у вас стоит Always On Availability Groups, вы наверняка бывали в такой ситуации: в SSMS всё зелёное, дашборд показывает «Synchronized», а пользователи звонят с жалобами на тормоза. Смотришь на secondary — а там redo_queue_size 600 МБ, реплика отстаёт на полчаса. Ни одного алерта.

У нас это случилось на продуктивном кластере с 1С: secondary молча отвалился в SYNCHRONIZING, а мы узнали только при плановом переключении. Полтора часа redo queue. Стало понятно, что встроенный дашборд SSMS — это не мониторинг. Дальше — как мы это закрыли Zabbix'ом за вечер.

Это - третья статья цикла про функцию ограничения скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей функции друг с другом) описание классов универсального компонента ограничения скорости .NET. Функция ограничения скорости обработки запросов в ASP.NET Core, которая является предметом рассмотрения всего цикла, базируется именно на этом универсальном компоненте. В этой статье я собираюсь завершить описание универсального компонента ограничения в .NET: описать входящие в его состав базовые (неселективные) ограничители.

Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.

Ну, а если вам пришлось разбираться (потому что эта функция не работает так, как вы ожидали) или, как мне, просто захотелось разобраться для себя, как работает функция ограничения скорости обработки запросов в ASP.NET Core - читайте дальше.

Всем привет! Меня зовут Егор, я аудитор по информационной безопасности в Selectel. Мы как провайдер IT-инфраструктуры работаем с компаниями из разных отраслей и часто сталкиваемся с одним вопросом, когда речь заходит о безопасности: кто именно отвечает за безопасность в облаке — провайдер или клиент?

Вторая часть серии по PostgreSQL из моих внутренних докладов. В этот раз — индексы: откуда берётся cost в EXPLAIN и почему это «попугаи», а не миллисекунды. Почему PostgreSQL игнорирует ваш индекс при высоком покрытии таблицы. Как физическое расположение данных на диске влияет на скорость даже при наличии индекса. Плюс GiST для нечёткого поиска с триграммами, GIN для полнотекстового поиска и EXCLUDE constraints для задач типа бронирования. Всё на примере таблицы с 4 миллионами строк.

Сегодня в моем блоге история на стыке проектного управления и спортивных метафор от одного моего знакомого ИТ-шника со стажем. Он из тех, кто не умеет просто “делать таски из Jira”. Он копает глубже: что за проблему мы решаем, кому это нужно и почему система устроена так. Недавно он пришел ко мне на кухню с неожиданной, но на мой взгляд, очень интересной идеей: возможно, на парадигму управления проектами, которую исповедует человек, влияет спорт, которым он занимался в детстве. 

Да, звучит как теория из TEDx районного ДК. Но мысль-то очень интересная. Так не без некоторой самоиронии он объяснил, почему на одном из последних проектов ему не подошел классический подход к командной работе в ИТ “как будто от профессионального борца”.

Сам он в детстве играл в футбол. Это было не просто про “побегать за мячиком”. Скорее про видение поля, понимание ролей, взаимную подстраховку, умение вовремя передать пас, ответственность за общий результат и способность действовать вне своей формальной роли, если того требует ситуация. А именно этого на том проекте в итоге и не хватало.

Практически все в природе связано друг с другом либо напрямую, либо опосредованно. Межвидовое взаимодействие проявляется как в пищевых цепочках, так и в симбиотических отношениях. Проще говоря, какой-то конкретный вид существ является источником пользы для другого вида. Даже паразиты, которые по существу своему являться, грубо говоря, эгоистами, также несут некую пользу в контроле популяции. Существа, которые человеком считаются вредителями, также имеют значение, но это понимания этого их вред не становиться менее ощутимым. Это утверждение подходит и для комаров, которые служат пищей для многих организмов (рыбы, птицы, летучие мыши, стрекозы и т. д.). Для нас же комар — это назойливый кровосос, который может быть разносчиком крайне опасных заболеваний. Чтобы лучше бороться с комарами, необходимо полностью понимать их поведение, в частности то, как они «видят» цель, т. е. нас в процессе полета. Ученые из Технологического института Джорджии (Атланта, Джорджия, США) провели исследование, в котором определили параметры, влияющие на поведение комаров, и расшифровали их полет. Как ученые получили эти данные, о чем они говорят, и как могут помочь в сокращении риска заражения переносимыми комарами заболеваниями. Ответы на эти вопросы мы найдем в докладе ученых.

Полтора года назад я писал статью “Я тебя найду и позвоню”, которая начиналась с кейса угона клиентов, но затрагивала возможность пробива любого абонента. Статья вызвала резонанс, и благодаря этому сервис, показанный в статье, закрыл дыру!

И вот прошло 1,5 года, а что теперь? А теперь мы посмотрим на другие сервисы, но тоже связанные с операторами связи и таргетированной рекламой. Они выводы не сделали. Ведь как оказалось, у них все ГОРАЗДО хуже. Проще пробивать, достаточно звонка или клика по безобидной ссылке, а найти можно гораздо больше. А главное, это по прежнему бесплатно!

Ваши данные доступны всем, бесплатно и в удобной форме. Почему? Читайте ниже!

Внимание, это НЕ шутка на 1 апреля.

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

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

Новый фреймворк тестирования Testo готов к испытаниям.

В статье: причины появления Testo; его фичи в краткой форме и в примерах; быстрый старт; что дальше.

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

Источники называют 1 апреля датой возможной полной блокировки Telegram. Но абсолютная блокировка технически почти невозможна — и вот почему. Разбираю 7 причин: от MTProxy, который перегружает ТСПУ мусорным трафиком, до collateral damage при блокировке CDN и парадокса, при котором более агрессивная фильтрация ломает систему блокировок изнутри.

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

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