Необходимостью любой современной платежной системы является возможность разграничения платежей согласно критериям. Если вам интересно узнать, почему таможенный и родительский контроль - это одно и тоже, а так же почему окрашивание ресурсов не имеет ничего общего с цветом, то добро пожаловать под кат.
Примерно в 23 году, когда LLM с историей ChatGPT полноценно вошли в жизнь, я стал задумываться - а что будет с Open Source? Уже тогда было понятно, что что-то точно поменяется.
Мысль у меня была простая.
LLM меняет игру => стоимость софта будет падать все сильнее => Софт перестает что-либо стоить => А это заставит рынок сильно меняться.
Через какое-то время я встретился с представителем одного очень крупного зеленого банка :)
Из-за моего Open Source стартапа мы долго рассуждали на эту тему, и после разговора я понял - перед нами два стула. На какой сядет реальность, а на какой фантазия - пока непонятно :D
Первый стул - Open Source вымрет как явление. Зачем качать библиотеку, если можно сгенерировать полностью схожую и не связываться с лицензиями и прочими сложными вопросами? Тебе это все становится не нужно.
Мысль интересная, но пока она бьется об одну важную стену. Стена называется "LLM генерит говнокод". Говнокод не в плане, красивый он или некрасивый, а в плане, что он неработоспособный. А скажешь агенту "вот бага, подправь" - он часто сделает еще хуже. И что бы ни говорили про рост когнитивки, без должным образом поставленной цели и объяснения проблемы агенты качественный софт не выдают. Сталкиваюсь с этим прямо сейчас - пилю очередной open source продукт.
Есть второй стул, и пока я больше верю в него. Раз стоимость софта падает, рынок будет меняться в сторону того, что софт скорее должен быть open source. Не open source - меньше доверия. Модель "community edition + платный тариф" - Enterprise, Team, неважно. Тем более что так софт элементарно проще продвигать даже через агентоцентричную экономику. Потому что, будем объективны, ближайший рост экономики в мире обеспечат агенты, а не люди.
Anthropic и AWS выпустили Claude apps gateway — self-hosted control plane для Claude Code и Claude Desktop, который живёт в вашей инфраструктуре и забирает с ноутбуков разработчиков ключи, настройки и учёт расходов. Один stateless-контейнер за внутренним ALB, вход через корпоративный OIDC, managed settings по группам, телеметрия по OTLP и лимиты трат через admin API. Разбираю по конфигам, что он реально контролирует, где проходит граница enforcement и в каких местах я бы притормозил перед раскаткой на сотни рабочих мест.
Мне нужно было оплатить Zoom для команды — годовой Workplace Pro, $169.90. Написал посреднику, которого посоветовали в чате. Ответ пришёл быстро: «Да, по стоимости 18 422 Рубля, оплачиваем?»
По курсу ЦБ $169.90 — это 13 320 ₽. Откуда ещё пять тысяч? «Курс и комиссия», — ответил менеджер. Какой курс, какая комиссия — не ответил.
Я плачу за ChatGPT, Zoom и Steam и переплачиваю непонятно кому непонятно сколько. Поэтому я сделал то, что делает любой инженер, столкнувшийся с чёрным ящиком: запросил стоимость у 13 посредников и виртуальных карт и записал ответы.
В итоге восстановил (реверс-инженернул?) формулу, по которой посредники считают свои «индивидуальные» комиссии. А еще сделал простой калькулятор, где видно, какой способ оплаты лучше подходит для какого сервиса (это в конце).
Хотя многие считают Linux современной операционной системой, она воплощает в себе идеи, которым уже более 50 лет. Рассмотрим некоторые из этих давних концепций и причины, по которым они сохраняются в современных дистрибутивах Linux.
Как мне кажется, старая формула успеха — «сделай хорошо и опубликуй в престижном журнале» — постепенно перестаёт работать. AI не смотрит на статус площадки: он верит тому, что выложено открыто, изложено полно и независимо подтверждено. Почему письмо в публичную рассылку теперь весит больше статьи в закрытом журнале, чем рискуют коммерческие форки PostgreSQL, и при чём здесь борги - об этом я размышляю в этой "отпускной" заметке.
Синяя галочка есть. Ответа нет. Мой собственный бот в MAX игнорирует моё же сообщение: сервер отвечает 200 OK, в логах чисто, а человек на другом конце ничего не видит. Так начались четыре вечера отладки Bot API нового российского мессенджера — четыре грабли, которых нет в документации. Где живёт токен. Почему 404 на чат, в котором ты прямо сейчас переписываешься. Как молча испаряется webhook-подписка. И почему MAX не говорит, которому из твоих ботов написали. Собрал всё, чтобы следующему хватило получаса вместо недели.
В прошлый раз я рассказывал, как в 15 лет с нуля написал российскую соцсеть для учеников, учителей и студентов «Агора» — тогда было 99 пользователей, около сотни SQL-миграций и куча энтузиазма. Статья неожиданно собрала 12 тысяч просмотров и почти 40 комментариев. Часть из них были просто добрыми словами, но был и один разбор — от PyXiion — на несколько экранов, по существу, без скидок на возраст. Отвечать на него сходу я тогда не стал, но за прошедшее время большая часть замечаний либо уже была исправлена, либо стала понятнее, почему сделано именно так.
С тех пор проект вырос — не столько по пользователям (~160 человек, аудитория та же — учащиеся, педагоги, студенты), сколько по тому, что под капотом. Расскажу и про рост, и по порядку разберу, что из той критики было верным, а что — нет.
Уважаемые читатели, в этой статье я хочу рассказать о проверке обещанного регресса LINQ в .NET 10 — и представить свои выводы.
В dotnet/runtime с лета висит issue #117717: после перехода на .NET 10 метод с First(предикат) просел к девятке — у автора issue на Intel 13-го поколения до 19%, у Энди Эйерса из JIT-команды на Zen 4 порядка 10%. Причину команда назвала сама: связка PGO и инлайнинга, делегат предиката перестал инлайниться.
Решение тоже озвучили: в десятке чинить не будем — сломаем другое, переносим в .NET 11. Был частичный фикс (PR #117816), после которого issue переоткрыли как #119425. Десятка при этом LTS, и в комментах закономерный вопрос: обновляться на десятку или ждать одиннадцатую.
Уважаемые читатели, в этой статье я хочу рассказать о том, что происходит внутри values.Sum() в современном .NET — там нашлись векторные инструкции, контроль переполнения и список процессоров, которым рантайм намеренно ограничивает ширину вектора, — и представить свои выводы.
В прошлых статьях серии самописные циклы уже проигрывали BCL в поиске по строке, JIT сам выкидывал проверки границ, а foreach прятал аллокации. Тут случай интереснее: values.Sum() — это LINQ, который при оптимизации первым делом меняют на цикл.
Для крупной федеральной компании из телеком-сектора наша команда разработала закрытую семейную платформу для сотрудников и их детей. Один родительский аккаунт объединяет несколько детских профилей, а внутри находятся тематические районы, викторины, мини-игры, творческие задания, личный прогресс, баллы и общий рейтинг.
Название заказчика и самой платформы я не раскрываю по NDA. Для этого разбора важнее масштаб задачи: речь идёт не об эксперименте с генерацией картинок, а о production-продукте, где AI-механика должна работать вместе с авторизацией, детскими профилями, расписанием контента, очередями, файловым хранилищем и правилами начисления баллов.
Одной из творческих активностей стала «виртуальная роспись» городского здания. Пользователь выбирал фотографию фасада, загружал собственный рисунок, а система превращала его в изображение на стенах. Здание должно было остаться узнаваемым, а рисунок - стать частью реальной архитектуры, а не потеряться в новой генерации.
На уровне интерфейса всё выглядит просто: выбрать основу, загрузить рисунок, дождаться результата. На уровне production-системы задача быстро перестаёт быть «вызовом AI API». Прямого доступа к OpenAI API с российского сервера нет. Сама операция длительная, работает с приватными файлами и может завершиться сетевой ошибкой, ограничением провайдера или отказом модерации.
Ниже - технический разбор этого конкретного потока: от React и очереди Laravel до небольшого собственного proxy-сервиса, встроенного в архитектуру основной платформы.
Это моя первая статья на хабре, потому что хотелось поделиться своим опытом объединения знаний из разных сфер, ну и в целом, рассказать, что вот и такое бывает.
Для начала вводная, я почти всю послеуниверситетскую жизнь работал в энергетике, а конкретно в службе релейной защиты в Ленэнерго. Но ближе к началу 22 года стал задумываться о вечном, ситуация стала ухудшаться и я, как тогда было «модно», тряхнул стариной (благо в школе и универе увлекался программированием) и начал вспоминать как кодить. Довольно быстро попал в коммерческую разработку, специализирующуюся на урбанистике и застройке, где успешно и работаю по сей день.
В определенный момент мне стало жалко, что столько лет накопленного опыта в энергетике улетают в трубу и я решил, что хорошо было бы объединить опыт, полученный в РЗА с опытом, полученным в разработке. Т.к. основной проект на работе был связан с генерацией застройки, работой с картами и алгоритмами генерации, я решил особо не мудрить и сделать что-то похожее, но связанное с подстанциями. В нашем проекте электрические сети были условными и шли из внешней границы территории, из тумана войны. И я подумал, в реальности ведь у нас нет волшебных питающих сетей – городские районы часто питаются через расположенные неподалёку понижающие подстанции. Поэтому хорошо было бы, чтобы пользователь, который задумал какое-то строительство, и который понимает какая мощность ему требуется, чтобы запитать новый район, мог с ходу за пару секунд сгенерировать несколько вариантов расстановки условной и усредненной типовой понижающей подстанции с основным оборудованием, с кабель-каналами, охранными зонами и необходимыми расчетами и прочими штуками, чтобы понимать реально ли это на данной территории и что ему для этого потребуется. Потребуется ли это в действительности меня не очень волновало, хотя я знал, что есть подобные программы для проектантов, но идея уже запустилась в мозге и просто так уже оставить было нельзя. К тому же получив схему подстанции, можно было реализовать другие функции для других сфер. Т.е. первое, что специалист по территориальному планированию мог бы быстро проверить, помещается ли подстанция на разных участках и заранее заметить проблемы. Второе, для сетевой компании или заказчика генератор мог бы быть полезен на стадии обсуждения технического присоединения. Например, чтобы сравнить несколько заранее заданных вариантов класса напряжения и типовой схемы, оценить требуемую площадь, ожидаемые токи КЗ и возможные ограничения по оборудованию. Ещё одно возможное применение (и наверное чуть-ли не главное) - это обучение. На готовой схеме можно показывать и объяснять, как расположение оборудования связано с электрической моделью, что меняется при включении секционного выключателя, откуда берутся токи короткого замыкания, почему для проверки защиты выбирается определённый режим и как первичная схема затем представляется в файле IEC 61850 SCL для каких-нибудь цифровых подстанций.
В статье разберем, как собрать простой DI-контейнер на чистом JavaScript без TypeScript, декораторов и reflect-metadata. Заодно посмотрим, как применить его в небольшом DDD-примере с корзиной, репозиторием, скидками и разными lifetime зависимостей.
Повествование будет идти таким образом: описание архитектуры в целом, потом код по страницам с картинками как это все выглядит. В отличие от черновика, в этом материале отображен весь рабочий код без сокращений с разбором каждой из страниц.
В Wails основными файлами, с которыми проходит 90% работы это index.html, styles.css, main.js, app.go. Остальные файлы мы либо не трогаем, либо настраиваем один раз в самом начале.
Для фронтенда я использовал стандартный html, css, js без современных фреймворков (так как я в них не разбираюсь). Frontend часть подробно рассматривать в этой статье не планируется, a html будет использоваться только чтобы показать, где используются js функции.
Разрыв в зарплатах между российским и международным рынком для IT-специалистов — огромный. Мидл-разработчик в российской компании зарабатывает 180-250 тысяч рублей. Тот же уровень в европейской или американской компании — 4000-8000 долларов в месяц, то есть в 3-5 раз больше. При этом работать можно удалённо и не переезжать.
Международный рынок открыт, но нужны правильный стек, понятное резюме, хороший английский и умение проходить технические интервью по западным стандартам. Хорошая новость: всё это можно освоить.
Сегодня разберём, кого сейчас ищут международные работодатели, где искать вакансии и стажировки, как готовиться к собеседованиям и где учиться навыкам, которых пока не хватает.
Pure.DI — это генератор кода для внедрения зависимостей (Dependency Injection), который работает на этапе компиляции. Pure.DI развивает идею «чистого DI»: вместо контейнера и рефлексии вы получаете обычный C#‑код, который создаёт композиции объектов. В этой статье — новые возможности из релизов 2.3.5–2.5.1: от union types в роли DI‑контрактов до сценариев внедрения зависимостей без лишних аллокаций.
Программисты, работающие с языком C, несомненно, узнают стандартную функцию malloc(). Это главный аллокатор памяти в языке, который тесно связан со всем известными ошибками сегментирования. Функция malloc() – именно то средство, при помощи которого программы приобретают память во время выполнения. Зачастую она также превращается в основной инструмент создания объектов и управления ими. Учитывая такой центральный статус malloc(), удивлён, что большинство программистов обращаются с ней как с чёрным ящиком. Этот пост призван немного исправить ситуацию, и в нём рассказано, что именно происходит под капотом. Также рассмотрим одну из возможных реализаций этой функции.
Уже с первого курса университета — или даже раньше — вы могли догадаться, что писать arr[len(arr)] — плохая затея. И вряд ли так кто-то может ошибиться, правда? Мы тоже так думали, пока не проверили 1000 проектов.
Недавно попался очень внятный материал от Pulumi про ключевые Kubernetes‑практики, которые начинаешь ценить, к сожалению, только после первых инцидентов и неприятных сюрпризов. Решила перевести для себя и коллег, а заодно положить на Хабр, добавив к переводу своих мыслей.
В материале — ключевые практики для 2026 года: задавать requests и limits для каждого контейнера, изолировать нагрузки через namespaces и NetworkPolicy, автоматизировать health checks и еще много всего. Приглашаю под кат.
Всем привет! Меня зовут Юрий, я руковожу группой прикладной разработки в департаменте мультивендорной поддержки YADRO. Мы занимаемся развитием собственного сервисного инструмента «Гегелло», который позволяет работать с диагностическими данными различного оборудования и визуализировать проблемы в системах.
Какую задачу решает платформа, почему это не просто «Grafana у нас дома» и что в основе архитектуры «Гегелло» — читайте в статье.