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

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

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

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

Если запустить множество таких случайных систем и позволить им мутировать и взаимодействовать друг с другом, возникнут ли в итоге “жизнеподобные”, самовоспроизводящиеся программы? Новая статья Блеза Агуэра-и-Аркаса и его соавторов показывает, что ответ, по-видимому, положительный. Это поднимает интересный вопрос: не является ли вычисление аттрактором в пространстве соответствующих динамических процессов? Если это так, последствия могут быть весьма существенными для нашего понимания происхождения жизни и того, насколько широко она распространена во Вселенной.

Блез Агуэра-и-Аркас получил степень бакалавра физики в Принстонском университете. В настоящее время он занимает должность вице-президента по инженерным разработкам в Google, руководит командой Cerebra и входит в команду Paradigms of Intelligence. Он автор книг Ubi Sunt и Who Are We Now?, а также готовящейся к выходу книги What Is Intelligence?

Вступление

ведущий (Шон Кэрролл): Всем привет и добро пожаловать в подкаст Mindscape. Сегодня у нас ситуация из разряда “есть хорошая новость и плохая”. Плохая новость в том, что в этом выпуске будет нецензурная лексика. Не потому, что мы вдруг решили особенно грубо выражаться или ругаться, а потому, что будем обсуждать компьютерные симуляции, написанные и запущенные на языке под названием Brainfuck. Прошу прощения у тех, кого может задеть такое название, но это вполне реальный язык программирования, и он действительно называется Brainfuck. Поэтому слово Brainfuck нам сегодня придется повторять снова и снова. Собственно, поэтому я произношу его уже сейчас - чтобы вы успели привыкнуть и знали, чего ожидать.

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

Часто задаюсь таким вопросами:

• что будет с моими активами через 5 лет, если взять квартиру в ипотеку?

• стану ли я богаче или же беднее от этого?

• смогу ли я выплатить вообще с текущими доходами и расходами всю ипотеку?

• а если не смогу, в какой момент получу кассовый разрыв?

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

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

• снимать квартиру и параллельно гасить ипотеку

• или взять жильё на миллион дороже, сразу заехать и отправлять сэкономленную аренду в досрочное погашение.

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

Считать стоимость использования DeepSeek становится всё менее просто. Токены DeepSeek не одинаково полезны стоят сильно по-разному. В пиковые часы цена в два раза дороже.

Сначала пиковые часы были каждый день с 01:00 до 04:00 и с 06:00 до 10:00 UTC. Желающие экономить научились переводить UTC в MSK. Позже выходные дни стали непиковыми целиком. “Экономисты” выучили, когда начинается суббота по UTC. И когда заканчивается воскресенье.

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

Мне давно было любопытно разобраться, как в RTB (Real Time Bidding — аукционная закупка рекламы в реальном времени) устроена хайлоад часть. Задача выглядит сложной: от площадок идет поток запросов на покупку рекламы (бид-реквестов), на стороне рекламного движка есть каталог рекламных объектов (кампаний и баннеров в них) со своими таргетингами, и на каждый входящий запрос надо успеть найти подходящие объекты, посчитать ставку и ответить. На весь обмен с биржей дается порядка ста миллисекунд, и в них должно поместиться все сразу — сеть в обе стороны, разбор запроса, подбор объекта, расчет ставки, сборка ответа. То есть на сам подбор остается еще меньше времени.

А еще такая система должна быть подвижной в обе стороны по нагрузке. Трафик у поставщиков не постоянен, он гуляет и в течение суток, и от поставщика к поставщику, так что держать максимальный конфиг под пиковую нагрузку круглосуточно нет смысла. Значит нужна возможность добавлять и убирать мощности, понимая при этом, сколько пропускной способности дает каждая добавленная единица. Спроектировать такое — интересная инженерная работа. Ну это я, как продакт работающий в этой сфере, так считаю :-)

В каждой компании где я работал с рекламными движками (DSP – Demand Side Platform) были свои кастомные решения, свое легаси – не везде можно найти обоснование каждому решению, поэтому мне всегда было интересно, как это устроено у других. Так что я решил разобраться, какие вообще бывают решения — чтобы лучше понимать возможности и ограничения, с которыми имеют дело мои разработчики. Это важно, потому что от выбора хранилища напрямую зависит сколько трафика мы физически способны обработать не отъехав, и что случится (а точнее что мы можем быстро сделать), если завтра нужно будет попросить у поставщика (в рекламе он называется SSP - Supply Side Platform) вдвое больше.

В предыдущей статье я писал про [5 вещей, которые не следует делать в LibGDX].

Поэтому логично продолжить тему и поговорить о вещах, которые, наоборот, стоит использовать при разработке 2D-игры на LibGDX.

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

Здесь всё гораздо проще.

Я хочу поговорить о нескольких технических инструментах, которые способны относительно небольшими усилиями заметно улучшить визуальное восприятие игры:

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

В статье разберём типовую архитектуру современного AI PoC на примере моего пет-проекта и ответим на вопрос: если AI умеет писать код, зачем все еще нужен инженер?

Можно ли ввести наблюдателя в математику, избегая умозрительной метафизики и дурного регресса («кто наблюдает за наблюдателем»)?

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

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

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

Формулы, строгие определения и математические разборы вынесены в спойлеры со знаком «▷». При первом чтении их можно пропускать: объяснения в основном тексте читаются самостоятельно.

Материал разделён на 3 маршрута чтения:

Концептуальное ядро (§1–§6): позиция наблюдателя, интерфейс «шаг — контекст» и три фундаментальных запрета. Читается как наглядный общенаучный разбор. (Время чтения без блоков «▷»: ~20–25 мин.)

Полный популярный маршрут (§1–§10): ядро плюс наглядное развёртывание на элементы графов — многомерная геометрия сцены (куб, октаэдр), проекции на звук и цвет. (Время чтения без блоков «▷»: ~35–40 мин.)

Чтение с математическими разборами (статья целиком): полный текст со строгими определениями, обоснованиями и дополнительными результатами. Для блоков «▷» пригодятся основы комбинаторики, линейной алгебры и представление о группах симметрий. (Время чтения: от 60 мин.)

В этой части нашего техно-триллера решил поговорить про календари, почту и адресные книги. Здесь, как и в мессенджерах, прямо сейчас активно разбивают Vendor Lock-in через стандартизацию открытых протоколов и антимономопольные суды. И одновременно, на наших глазах формируется новый узел вендор-лока, и стартует новая борьба, теперь за контекст для корпоративного ИИ. В 2026 году Big Tech начинает продавать бизнесу уже не просто почту и календари, а социальный и когнитивный граф, который мгновенно испаряется при любой попытке миграции. Сможет ли связка открытых протоколов JMAP + Matrix (MSC4496) обеспечить бизнесу владение собственным семантическим контекстом?

После шести месяцев разработки компания Oracle опубликовала платформу Java SE 27 (Java Platform, Standard Edition 27), в качестве эталонной реализации которой используется открытый проект OpenJDK. За исключением удаления некоторых устаревших возможностей в Java SE 27 сохранена обратная совместимость с прошлыми выпусками платформы Java — большинство ранее написанных Java-проектов без изменений будут работоспособны при запуске под управлением новой версии. Готовые для установки сборки Java SE 27 (JDK, JRE и Server JRE) подготовлены для Linux (x86_64, AArch64), Windows (x86_64) и macOS (x86_64, AArch64). Разработанная в рамках проекта OpenJDK эталонная реализация Java SE 27 полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами.

Java SE 27 отнесён к категории выпусков с обычным сроком поддержки, обновления для которого будут выпускаться до следующего релиза. В качестве ветки с длительным сроком поддержки (LTS) следует использовать Java SE 25, Java SE 21 или Java SE 17, обновления для которых будут выпускаться до 2033, 2031 и 2029 годов соответственно (общедоступные — до сентября 2030, 2028 и 2026 годов). Расширенная поддержка LTS-ветки Java SE 8 продлится до 2030 года, а Java SE 11 — до 2032 года.

( читать дальше... )

 java, java se, openjdk, opennet, oracle

Стандартная статья это типо «я использовал ии и навайбкодил сайт за 2 дня»

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

Вот на тему стыка человек — ии я хотел бы и подумать.

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

Джунгли Linux — это не зверинец, а целостная экосистема: у каждого компонента в ней определены роль и место в экосистеме. Ext4 везёт сундук по протоптанной тропе, XFS мчится вперёд, но не может развернуться, ZFS проверяет каждый плод, а без ESP звери не проснулись бы вовсе.

В предыдущей статье мы рассмотрели варианты перехода на Linux. Теперь обсудим следующее решение: какой файловой системе (ФС) доверить свои данные при разметке диска. От этого зависит не только скорость работы, но и надёжность хранения, возможность отката системы при сбое и даже срок службы вашего SSD. Кто готов погрузиться глубже в джунгли инодов, журналов и снапшотов — приглашаю под кат.

Почему одинаковые данные могут давать разные p-value? На простом примере с монетой разбираю, как правило остановки меняет частотный вывод, а затем связываю это с подглядыванием в A/B-тесты и повторными проверками значимости. Заодно становится понятнее, что именно ломается при peeking и почему проблема не в самом просмотре данных, а в том, как промежуточные результаты влияют на решение остановить эксперимент.

Всем привет! Этой весной я искал работу, и в какой-то момент пришел к тому, что на сами отклики у меня уходит минут тридцать, а весь остальной вечер я трачу на то, чтобы просто обойти площадки и посмотреть, не появилось ли чего нового. То есть я не работу искал, я вкладки открывал.

Вечером открываешь hh, листаешь. Потом пару телеграм каналов, где вакансия тонет за час. Потом вспоминаешь компании, куда хотелось бы попасть, и идешь по их карьерным страницам руками, а их штук пятнадцать, и на половине ничего не меняется неделями. Половину ты уже видел вчера. Закрыл вкладки, на завтра все то же самое.

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

Далее две части. Сначала про рынок и про то, что видно из базы, когда вакансии можно посчитать. Потом техническая кухня: что ломалось, что я чинил и какие места, по-моему, полезно знать заранее. Я разработчик, но парсинг, нормализация данных, Postgres, эмбеддинги и инфраструктура были для меня новыми, так что граблей набралось прилично.

И сразу заранее: все цифры ниже про мою базу, а не про рынок целиком. Спорить с ними можно и даже нужно :-)

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

Знать принцип 80/20 в такой ситуации недостаточно. Сложность начинается в тот момент, когда нужно применить его к реальной бизнес-задаче: определить, какие действия действительно сильнее других влияют на результат, сформулировать их конкретно и договориться, на чём стоит сосредоточиться.

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

В России 2026 года нейросетями пользуется каждый четвёртый житель — это примерно 35 миллионов человек, что выше среднемирового показателя. При этом 58% активных пользователей обращаются к ИИ минимум раз в неделю. Но вот парадокс: чем больше моделей появляется, тем сложнее выбрать «ту самую».

В 2026 появилось множество новых нейросетей и ИИ-моделей: GPT-5, Claude Fable, DeepSeek, GLM, Qwen, и интернет уже не ограничен исключительно ChatGPT от OpenAI. Некоторые из них уже создали фурор своими способностями и мощностью интеллекта, некоторые стали популярными за счёт интегрированности и доступности, третьи — за счёт бесплатности и безлимитного общения. Мы поговорим и о глобальных флагманах, и о менее известных нейросетях, и о российских нейросетях.

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

На разработку ушло 16 выходных дней и примерно 250$

Решил я значит разработать свое приложение, начитавшись материалов про ИИ и вайбкодинг, захотелось попробовать самому. Так как я являюсь UX/UI дизайнером, который занимается разработкой дизайна для приложений, я поставил себе несколько целей, которые должны были закрыться в процессе разработки аппы...

Однажды заказчик, которому я разворачивал офисную телефонию спросил меня: "А можно нашим сотрудникам поставить на телефоны SIP клиенты, чтобы их разговоры с клиентами проходили через офис, попадали в CRM и записывались?"

Мысль заказчика понятна: Почему бы просто не поставить софтфон на мобильник и не настроить его на свой сервер?

Но есть несколько причин, почему это работает откровенно плохо.

Я пытался сделать NPC более реалистичными. Получился местами несмешной анекдот, а местами — психологический триллер. Я издевался над NPC, они издевались надо мной. Я запрещал им «думать о белой обезьяне», они меня газлайтили и давили моралью. Если готовы к большому тексту — добро пожаловать.

Иногда мне нужно быстро проверить свой VPS: посмотреть нагрузку, глянуть логи или перезапустить сервис. Каждый раз открывать ноутбук и подключаться по SSH ради пары команд было неудобно, поэтому я решил сделать Telegram‑бота. Сначала думал, что всё будет довольно просто: Telegram → SSH → сервер. Но по ходу разработки выяснилось, что само SSH‑подключение — как раз самая простая часть. В статье расскажу, с какими проблемами я столкнулся и как в итоге их решил.