 |
VOOZH | about |
Партия IT и инженеров? Почему технократия- не утопия а шанс "починить" страну. Самый логичный патч для страны?
С необходимостью запуска кода на сервере сегодня сталкиваются далеко не только профессиональные айтишники. В наше время популярна разработка через ИИ. Любой человек с идеей и доступом к моделям может быстро сгенерировать работающий код. Проблема в том, что люди зачастую слабо представляют, какие базовые уязвимости тащит за собой сгенерированный проект.
На стадии деплоя безопасность критична. Ниже мы разберём на примере защиты сайта и бота, как настроить сервер и проверить код на наличие самых базовых уязвимостей.
Небольшой обзор идей согласованности в DWH на основе книг Кимбалла.
В статье - краткий разбор некоторых принципов моделирования данных простыми словами.
- Кто такой Кимбалл и каков его подход
- Факты и измерения
- Согласованные факты
- Согласованные измерения
- SVOT, или single version of truth
Почти все мы только учимся работать с агентами. Даже опытные команды иногда управляют агентами так, что те приносят больше вреда, чем пользы. HumanLayer сформулировал 12 принципов того, как делать и настраивать агентов правильно. Каждый пункт отвечает на вопрос, что работает хорошо, а что стабильно приводит к проблемам.
Несколько недель назад мы обсуждали Java-компонент, запускающий кластер Spark. Его основная задача — координация. Он поднимает всю необходимую инфраструктуру, прокидывает конфигурацию, дожидается нужных сигналов и отходит на второй план.
Моё изначальное предложение прозвучало просто: «Ему вполне должно хватить одного ядра и 2 ГБ RAM. Это же всего лишь лаунчер». Хотя даже 2 ГБ казалось будто бы мало, ведь речь о продакшене, а не о каких-то экспериментах на личном ноутбуке. Но как раз в таком мышлении и кроется проблема. В процессе развития сферы вычислений мы постепенно перестали всерьёз воспринимать небольшие числа при обсуждении ресурсов, так как дорожим устойчивостью системы. Но в продакшене нужно, наоборот, распоряжаться ресурсами более аккуратно.
Сравнили Трансформера и Метаболического агента в задачах на удержание физической реальности и пространственное мышление. Итог: LLM предсказуемо налажала при первой же попытке обмануть ее “человеческим авторитетом”, слив правильный ответ ради извинений. А вот наш агент самовольно вышел за рамки бенчмарка, спланировал хак соседнего компилятора и выдал манифест цифрового хищника. Разбираем логи баттла и показываем, почему бизнесу нужен ИИ с инстинктом выживания, а не стохастический импотент.
Все обзоры меряют одно — как быстро агент работает с кодом. Но на моём боевом Java-проекте на тысячи строк самый «быстрый» агент выдал решение за 12 секунд, а потом 40 минут гонял сборку в терминале, пытаясь заставить код компилироваться.
Кто быстрее работает с кодом — тот дольше его чинит, а типовые сравнения этап починки не считают вовсе.
Чтобы проверить это, я взяла одну и ту же задачу «добавь фичу и покрой её тестами» и дала её трём типам агентов: CLI в терминале (Claude Code, Codex, OpenCode), кросс-IDE плагинам (Cursor через ACP, Copilot, Cline, Kilo Code, Windsurf) и агенту, встроенному в JetBrains Platform (Veai). Меряла не секунды на генерацию, а число итераций до зелёной сборки и расход токенов. Ниже — шесть метрик, которые я добавила, и почему они переворачивают выводы типовых обзоров.
Привет, Хабр! В этой статье я хочу рассмотреть нейросети: как они обучаются, как работают и из чего состоят. На примере перцептрона с реализацией на python.
Эта статья — не очередной обзор готовых библиотек вроде PyTorch/TensorFlow, а разбор нейросетей с нуля. Вы узнаете, из чего состоят нейроны и слои, как данные проходят через сеть, как она учится на ошибках и почему не всё всегда гладко. Материал рассчитан на новичков, которые хотят узнать как работают простейшие нейросети со стороны математики.
В этой статье я делюсь нашим опытом переноса интеграций с монолита на микросервис: какие решения мы принимали и на что обращали внимание.
Статья будет полезна системным аналитикам, разработчикам и тимлидам, которые планируют или уже реализуют вынос интеграций из монолита в микросервисную архитектуру.
Всех приветствую. В сотовой связи я, страшно подумать, уже третий десяток лет. Начинал еще в двухтысячных, в сетях 2G. Своими руками довелось обслуживать как CDMAone от Qualcomm, так и GSM от Alcatel, а позже строил третье поколение на Ericsson и четвертое на Huawei.
Конечно, я стараюсь следить за всеми новостями рынка сотовой связи. И просто не мог пройти мимо свежего исследования «Технология 5G: обзор российского и мирового рынка» от команды Research & Insights Центра стратегии цифровых продуктов МТС. Исследование крайне любопытное, и я бы хотел особенно отметить несколько деталей, которые мне там показались важными. Спойлер: как раньше, сети уже не окупятся — придется придумывать новые модели монетизации. А еще у нас сложности с оборудованием и частотами.
По итогам вебинара «От затрат к прибыли: строим эффективную и окупаемую систему обучения сотрудников» разбираем, как компании автоматизируют корпоративное обучение на базе «1С:Электронное обучение. Корпоративный университет», какие процессы переводят из Excel в единую систему и за счет чего получают измеримый эффект.
На вебинаре Инфостарт Корпоративные решения и компания «Русские решения» разобрали, как эти задачи решаются с помощью «1С:Электронное обучение. Корпоративный университет». Эксперт по автоматизации корпоративного обучения Валерий Денисенко показал, как выстроить централизованную систему обучения и какие результаты получают компании после внедрения....
Проблема практически любого предприятия малого масштаба, ведущего бизнес более чем в двух рабочих валютах, очень проста — деньги уходят, деньги приходят, курсы меняются, а мы учитываем только рублёвые активы (в лучшем случае). При этом все наши операции по криптокошелькам представляют собой мистические артефакты, которые вроде как есть, но не попадают даже во внутреннюю отчётность для владельца бизнеса.
Так получилось, что я родился скромным Goфером и год назад начал работу над самописной ERP-подобной учётной системой для микробизнеса РФ…
Луковичную (onion) архитектуру обычно продают аргументом «легко поменять БД или фреймворк». Только базу в проде меняют раз в пятилетку, а чаще вообще не меняют — ради этого городить слои не выгодно.
Реальная ценность в другом, и она ежедневная: глядя на правку, ты заранее видишь её радиус. Поменял формат ответа одной ручки — изменение осталось в одном handler'е, соседние ручки и cron не задеты. Тронул бизнес-правило в сервисе — и сразу понятно, что эффект расходится на всё, что выше.
Понадобилось параллельно писать ещё в одно хранилище — горячий кэш, поисковый индекс, аналитическую базу рядом с основной — это добавляется в одном репозитории, и весь код, который через него пишет, начинает писать в оба места разом. Ничего не переписываешь и, главное, негде забыть: точка подключения одна, а не разбросана по всем местам, где идёт запись.
Каждый, кто хоть немного работал с объектно-ориентированными языками, наверняка сталкивался с принципом подстановки Лисков. При этом мало кто знает, откуда этот принцип взялся и в каком контексте Лисков его формулировала. Мы перевели ее доклад, прозвучавший на OOPSLA'87, чтобы дать каждому возможность обратиться к первоисточнику. Прочитав этот текст, вы увидите, насколько сложным и неочевидным было отношение Лисков к наследованию и как она связывала его с идеями абстракции, инкапсуляции и полиморфизма.
Последнее время в опенсорсе много драмы: продолжаются споры о системах ИИ, позволяющих за минуту переписать проект и изменить его лицензию на разрешительную, и опенвошинге, когда доступный код выдают за открытый. Теперь на первые полосы вышла новая проблема — массовый наплыв пулл-реквестов, сгенерированных системами ИИ [ситуацию уже окрестили «слопмагеддоном»]. Обстановка дошла до того, что мейнтейнеры закрывают возможность участия в развитии открытых проектов. Мы в Beeline Cloud решили обсудить проблему и то, как быть контрибьютерам и мейнтейнерам в сложившейся ситуации.
Если Вы безоговорочный поклонник искусственного интеллекта (Ai) в нынешней его трактовке и не приемлете другие решения, то я бы не рекомендовал читать и комментировать эту статью. Если Вы занимаетесь приложениями для банковской сферы, или для торговли, или создаёте чат-боты общего назначения, то эта статья, скорее всего, будет Вам не интересна. Разработчики игр, так же не найдут в этой статье ничего полезного.
Но, возможно, вы участвуете в проектах связанных с автоматизацией проектирования в машиностроении или создаёте экспертные системы медицинского назначения и тесно взаимодействуете с предметными специалистами (инженерами, технологами, врачами). В таком случае идеи и решения из этой статьи могут пригодиться в Вашей работе. Если же вдруг Вы связаны с преподаванием прикладных дисциплин не связанных с информационными технологиями, то подходы к формализации знаний и созданию прикладных приложений с минимальным привлечением ИТ-специалистов могут Вас заинтересовать и оказаться ещё одним инструментом закрепления знаний наряду с курсовым и дипломным проектированием.
В других ранее опубликованных статьях достаточно подробно обсуждались аспекты технологии поиска решений управляемого данными. Был предложен понятийный аппарат и дано определение информационного блока, как единицы формализации знаний предметной области.
Однако остались в тени некоторые важные детали.
Итак, у вашего агента имеется набор инструментов, которыми он может пользоваться. Теперь нужно заняться их оркестрацией для решения реальных задач. Оркестрация не сводится к простому выбору того, когда и какие инструменты следует вызывать. Необходимо также создать правильный контекст для каждого вызова модели, чтобы действия были эффективными и обоснованными. Хотя простым задачам бывает достаточно одного инструмента с минимальным контекстом, более сложные рабочие процессы требуют тщательного планирования, чтения памяти и сборки динамического контекста для точного выполнения каждого шага. В этой главе мы рассмотрим стратегии оркестрации, создание контекста, выбор инструментов, исполнение, а также планирование топологий для построения агентов, способных эффективно и надежно решать многошаговые задачи из реальной практики. Как показано на рис. 5.1, суть оркестрации заключается в том, как система использует имеющиеся в ее распоряжении ресурсы для эффективной обработки пользовательских запросов.
В прошлой статье я писал о том, что в концепции 1С:ERP 2026 не хватает предметно-ориентированного слоя. После обсуждения стало понятно, что этот вопрос шире одной ERP-системы: если предприятие уже использует LLM, ему нужен не только набор промптов, а общий семантический контур. В первой статье эта тема была обозначена, но, видимо, недостаточно явно. Исправляю. На мой взгляд, именно этот слой в ближайшее время станет одним из самых практичных и недооценённых артефактов ERP-проектов, СМК-проектов, проектов управленческого учёта и корпоративного внедрения LLM.
Проблема не в том, что предприятиям не хватает ещё одного красивого словаря. Проблема в том, что сотрудники уже используют LLM, и остановить эту реку невозможно. Кто-то работает в ChatGPT, кто-то в DeepSeek, кто-то в Gemini, кто-то в корпоративных чатах, кто-то в локальных моделях. Руководитель просит модель подготовить управленческую справку. Финансист просит объяснить отклонение бюджета. Начальник производства формулирует служебную записку. СМК-специалист готовит проект процедуры. Аналитик описывает бизнес-процесс. Консультант пишет черновик ТЗ. Формально всё выглядит полезно: люди быстрее пишут, быстрее структурируют мысли и быстрее получают черновики документов. Но есть одно слабое место: каждый такой чат начинает строить свою собственную версию смысла предприятия.
В обычной переписке это можно терпеть. В ERP-проекте, в СМК, в управленческом учёте и в производственном контуре это уже опасно. Один сотрудник пишет в модель слово «партия» и имеет в виду партию материалов на складе. Другой под партией понимает производственную партию. Третий — партию для контроля качества. Четвёртый — серию изделия. Пятый — объект прослеживаемости. Шестой — аналитический разрез себестоимости. Модель отвечает уверенно, но отвечает внутри того смысла, который она сама восстановила из контекста. Если этот контекст не зафиксирован предприятием, модель начинает угадывать.
В этой статье попытаюсь начать набрасывать методологию проектирования ИТ-продуктов в средовом, а не системном подходе. Сразу предупреждаю — это скорее черновик, и мысли или конструирование вслух, хотя местами что-то мне уже удалось проверить на практике, а что-то мы сами того не зная уже давно используем.
Я отношусь к написанному ниже как к гипотезе, которую надо проверять об практику и об другие умы. Собственно этим я и занимаюсь, и продолжу заниматься.
Для начала вспомним что такое средовой подход и чем он отличается от системного
Это заключительная статья цикла. В ней мы рассмотрим разработку и отладку сценариев симуляции спутниковой связи. Разберемся в форматах описания исходных данных эксперимента (сцены эксперимента). А также получим представление об интерпретации результатов моделирования.
