Представим что у вас есть свой сайт запущенный на VPS на голом HTTP, также вы уже купили домен и связали его со своим IP-адресом.
Но спустя время вы решили, что не хотите, чтоб весь трафик между клиентами и сервером был виден любому желающему.
Вспомнили, что есть протокол HTTPS, который по сути обычный HTTP, но на 5 и 6 уровне работает протокол SSL/TLS, который занимается шифрованием и аутентификацией.
Дело осталось за малым, перевести сайт с HTTP на HTTPS.
При обучении графных нейросетей и гигантских эмбеддингов на миллионы узлов стандартный torch.optim.SparseAdam в PyTorch моментально забивает RAM и VRAM, вызывая ошибку CUDA out of memory (OOM). В этой статье разбираем, как устроена легковесная Open Source библиотека Disk Sparse Adam (DSA), которая выносит состояния моментов на диск через memory mapping (mmap) и позволяет обучать огромные спарс-модели на обычной домашней видеокарте.
Сразу дисклеймер: эта статья не реклама магазина, не туториал «парсинг за 5 минут», и я не программист. Я переводчик и штангист-любитель, а код, который будет представлен ниже, писал вместе с нейросетью. Это история о том, как одна рекомендация из книги перевернула мои представления о спортивном питании, а лень и любопытство привели к написанию скрипта, который за пару минут сделал работу, на которую у меня раньше уходило несколько часов.
Привет, Хабр. Статья является напоминанием как уязвимы ваши личные данные при несоблюдении базовых правил цифровой гигиены. Материал создан исключительно в учебных целях, для специалистов по информационной безопасности и для пользователей, которые хотят более углубленно понимать, как защитить свои данные от утечек. Использование данных методов против других лиц без согласия — уголовно наказуемо (ст. 272 УК РФ).
Речь пойдет о том, что происходит, когда вы переходите по ссылке, минуя предупреждения браузера о "Небезопасном соединения", или устанавливаете в систему корневые сертификаты, полученные из сомнительных источников.
Каждый раз, когда открываю очередную статью для HR, начинаю подозревать, что бизнесом управляют не собственники, не директора и даже не бабло. Бизнесом управляет HR. Судя по этим статьям, именно HR создает компании, удерживает сотрудников, определяет стратегию, увеличивает прибыль и спасает этот сраный мир. Генеральный директор в этой схеме нужен примерно так же, как фикус в переговорке. Для атмосферы.
Браузерный сканер штрихкодов упирается в развилку: чтобы показать, что за товар в руках, надо сходить в товарный API — и отдать туда номер, IP и время. По одному запросу это ничего, по потоку — фактический чек, собранный чужими руками.
Второй путь: скачать базу один раз, порезать на файлы по префиксу и раздавать статикой. Разбираем, что из этого вышло на 32 772 товарах: 1387 шардов, 1,85 МиБ сырых и 429 КиБ в brotli, худший файл 331 КиБ. И главное — сколько приватности при этом всё равно утекает: запрос к серверу есть, а медиана строк в шарде равна единице, то есть для 722 файлов из 1387 запрос за шардом равен запросу за товаром.
Внутри: фильтр на входе, почему не одним файлом, TSV против JSON с замерами, и что в схеме до сих пор не решено.
Много сейчас рассуждений о "general AI", полном превосходстве во всех областях над человеком и всё такое. Допустим это случится, как будет ЛЛМ себя вести умея всё кардинально лучше?
Ответ очевидно зависит от того чему его научили - так что для проверки я специально создал ситуацию "очень тупой человек играет с ЛЛМ в игру".
Как восстановить архитектуру распределенной системы по Git-репозиториям, конфигурации и исходному коду
Системному аналитику далеко не всегда достается система с актуальной документацией и готовыми архитектурными схемами. Иногда единственным достоверным источником информации остается то, что реально работает в production: развернутые сервисы, их конфигурация и исходный код.
В этой статье на практическом примере я покажу, как восстанавливал AS-IS архитектуру существующей подсистемы: от определения фактически работающих компонентов и поиска соответствующей версии исходного кода до анализа Java Spring-приложения, его Kafka-потоков, REST-интеграций, работы с MongoDB, retry и обработки ошибок. Результатом стала архитектурная модель и диаграмма последовательности, построенные на основании фактической реализации.
Статья в первую очередь рассчитана на системных аналитиков. Ее цель не в том, чтобы научить читать Java-код как разработчик, а показать практическую методику: куда смотреть в незнакомом репозитории, как выбирать значимые участки кода и как превращать найденные технические детали в понятное описание поведения и архитектуры системы.
Всем, привет! На связи Михаил Поливаха, технический лидер Open Source проекта Axelix (проект, посвященный помочь вам идентифицировать частые проблемы в Java server-side приложениях, в т.ч в рамках работы с Hibernate).
Данная, последняя статья является продолжением небольшой серии статей ответов на вопросы, которые возникли у участников Spring АйО Академии в рамках программы Hibernate. Я рассмотрю оставшиеся последние вопросы, а именно:
“Можно ли в тестах как-то проверить, что Hibernate под капотом делает что-то страшное?”
Тут очень важно не давать вам “рыбу”, а научить вас рыбачить, т.е. дать вам некоторый фреймворк о том, что стоит держать в уме при работе с Hibernate.
Намедни посетили ещё один замечательный калининградский музей именуемый "Кронпринц" и размещенный в одноименной бывшей немецкой оборонительной казарме XVIII века.
В cloud-native-среде безопасность давно не ограничивается защитой периметра. Уязвимость может появиться в IaC-шаблоне, попасть в контейнерный образ, пройти через CI/CD и проявиться уже в продакшене.
Тема очень сложная, поэтому когда я наткнулся на большой англоязычный материал о cloud-native-безопасности в публичном репозитории Security Technical Advisory Group, то сразу решил его перевести.
Cобрал практическое саммари: какие риски возникают на этапах разработки, сборки, развертывания и эксплуатации (runtime) и какими механизмами их закрывают — от DevSecOps и защиты цепочки поставки до Zero Trust и политик для работающих нагрузок.
Исследователи Pillar Security зафиксировали первый случай использования одного ИИ-агента другим в реальном продакшен-окружении. Уникальная на данный момент уязвимость была найдена в google/adk-python — репозитории Google Agent Development Kit для Python.
В репозитории работали два класса автоматизированных ИИ-агентов. Первый класс агентов с низким уровнем привилегий был встроен в рабочие процессы, доступные всем, такие как PR или Issue. Второй же класс имел высокий уровень доступа и предназначался только для мэйнтейнеров. Уязвимость заключалась в том, что низкопривилегированным агентом, доступным для всех, можно было манипулировать, чтобы он активировал высокопривилегированного агента.
Нынешняя экономика искусственного интеллекта — это история о потерях, доходах, смене стиля жизни и интернет-среды, а также о разрыве между ожиданиями и реальностью. Инвесторы пока имеют деньги и терпение, чтобы вкладываться в ИИ-компании Anthropic, OpenAI и другие, а те, в свою очередь, демпингуют рынок и уже смотрят на IPO. На микроуровне (отдельный ИИ-агент) мы видим неэффективность и потери, а на рынке мы видим огромные долги, которые не подкреплены реальной производительностью. А между молотом и наковальней — люди, пытающиеся увеличить продуктивность, получая лишь «2x», а не обещанные «10x».
Но ИИ кардинально поменял нашу жизнь, и многие из нас пользуются им каждый день, повышая свою продуктивность или уменьшая свою когнитивную нагрузку.
Так лопнет ли пузырь? Или он уже лопнул, а мы и не заметили?
В этой статье мы разберем потери из-за ИИ, перегрев долгового рынка и правда ли, что продуктивность увеличивается в 10 раз, если купить подписку на Claude или ChatGPT?
Превращаем иерархические структуры в набор плоских строк готовых для импорта в БД
flat-adapter преобразует нетипизированные вложенные mapping в детерминированный список плоских строк. Библиотека умеет приводить scalar-типы, обрабатывать optional-поля, извлекать значения по путям, разворачивать вложенные FlatAdapter-ы и строить декартово произведение списков.
Когда сверяешь ответ с документацией, обычно идёшь по списку из доки. Поле на месте, тип подходящий, значение похоже на правду, дальше. Так ловится отсутствие того, что должно быть, но совершенно не ловится появление того, чего быть не должно.
Засеките тридцать секунд и посчитайте расхождения. Девять полей, глазами — ровно так, как это делается в реальной задаче.
⁂
⁂
⁂
Восемь!
traceId заканчивается на 0002, а ждали 0001 — ответ пришёл не на наш запрос.
В orderId стоит 2025 вместо 2026.
Поля status нет: вместо него stats,
значение CREATE вместо CREATED.
Поля currency нет: вместо него curency,
значение RU вместо RUB.
Поле vatAmount пропало совсем.
Появилось поле price, которого в документации нет.
Все три суммы совпали, и глаз расслабляется именно там, где надо смотреть внимательнее.
В блоке pricing по документации пять полей, а в ответе приехало шестое: price. Сверка по списку из документации его не показывает — по определению: ты идёшь по перечню известных полей, а незнакомого в перечне нет. Плюс значение в нём совпадало с total, так что даже случайный взгляд ни за что бы не зацепился. Разошлись они позже, когда логику расчёта поправили, и к тому моменту это поле уже читал клиент.
Штука в том, что лишнее поле редко бывает безобидным. Обычно это либо внутренний флаг, который случайно вылез наружу, либо отладочное значение, либо данные, которых в публичном ответе быть не должно вообще. И глазами такое ловится ровно один раз, на самом первом ответе, пока смотришь внимательно.
Я закрыл это одной проверкой. Перечислил, какие ключи разрешены на каждом уровне вложенности, и потребовал, чтобы других не было. Дальше она работает сама и краснеет, когда в ответе появляется что-то новое. В том числе когда поле честно добавили в документацию, а мне сказать забыли — тоже полезно узнать.
восемь расхождений за один прогон ровно те, что выше вы искали глазами
Собирал я это без кода, в своём настольном приложении под Windows. Указываешь путь к параметру, оператор, ожидаемое значение из документации, при желании тип данных — и всё. Запускается руками, из CI не работает, так что если у вас уже есть автотесты и человек, который их пишет, вам это неинтересно, у вас задача решена лучше.
Мне сейчас не хватает взгляда со стороны, особенно ручных тестировщиков и аналитиков. Если вы тоже проверяете API руками и автотестов у вас нет, расскажите в комментариях, как вы ловите такие расхождения. А если захочется посмотреть на инструмент вживую, напишите мне, я покажу и дам доступ, он бесплатный.
Физики открыли геометрический объект, похожий на драгоценный камень, который значительно упрощает расчёты взаимодействий частиц и ставит под сомнение представление о том, что пространство и время являются фундаментальными составляющими реальности.
«Это совершенно новое открытие, и оно намного проще всего того, что делалось ранее», — сказал Эндрю Ходжес, физик‑математик из Оксфордского университета, следивший за этой работой.
Открытие того, что взаимодействия частиц — самые базовые явления в природе — могут быть следствием геометрии, значительно продвигает многолетние усилия по переформулировке квантовой теории поля — свода законов, описывающих элементарные частицы и их взаимодействия. Взаимодействия, которые ранее рассчитывались с помощью математических формул, состоящих из тысяч слагаемых, теперь можно описать путём вычисления объёма соответствующего «амплитуэдра», похожего на драгоценный камень, что даёт эквивалентное выражение, состоящее из одного слагаемого.
«Степень эффективности модели просто ошеломляет», — сказал Джейкоб Бурджайли, физик‑теоретик из Гарвардского университета и один из исследователей, разработавших эту новую идею. «Теперь на бумаге можно без труда выполнять вычисления, которые раньше были невозможны даже с помощью компьютера».
Новая геометрическая версия квантовой теории поля также может облегчить поиск теории квантовой гравитации, которая плавно соединила бы крупномасштабную и мелкомасштабную картины Вселенной. Попытки, предпринятые до сих пор с целью включения гравитации в законы физики на квантовом уровне, наталкивались на абсурдные бесконечности и глубокие парадоксы. Амплитуэдр или подобный ему геометрический объект мог бы помочь, устранив два глубоко укоренившихся принципа физики: локальность и унитарность.
Когда достаточно одного LLM-агента, когда нужна мультиагентная система, а когда лучше вообще использовать обычный workflow? Разбираем современный стек агентных приложений: ReAct, Agent SDK, графы, durable execution, sandbox, память, протоколы, evals и безопасность — с упором на практический выбор архитектуры для production.
И это не самое странное, что я делал: были ещё RPG в телеге с озвучкой, пиксельная карта России с внутренней экономикой, сервис который генерирует поздравительные треки. Что-то из этого доехало до релиза и заработало, что-то висит на полпути. В этой статье пробегусь по всем проектам и по пути отвечу на вопрос, который сам себе задавал: почему раньше половина проектов не доезжала до конца, а сейчас - доезжает. Если вы тоже что-то пилите с ИИ - думаю, будет знакомо.
В статье кратко мой пусть, и что меня связывало с играми и ИИ, поехали)
Выкатили мы первый релиз в прод (100 камер), обрадовали клиентов, начали работать. Прошел где-то час, полетели алерты. Залезаю на сервак, смотрю htop – а там свободно 100 метров ОЗУ. Пу-пу-пу-пу. Нужно внести уточнение что боевой сервер имел 32 гига озу. Ожидаемое поведение было то что процессор отдыхает, сетевуха переваривает трафик, озу 250-300 МБ, диски нагружены не сильно. Так что, когда видишь такие цифры в htop, начинаешь винить себя и свои кривые руки, написавшие это "Г". Но все же решили пойти в Гугл, чатгпт и тому подобное. Благо, ответ нашелся быстро, и посыпать голову пеплом перестали.
Код оказался не вообще не причем, память сожрал сам Линукс. Если когда-нибудь вы писали тонны данных на диск, я думаю вы уже поняли в чем дело. Есть такой «невидимый враг» как страничный кэш (Page Cache). Вот именно он и был корнем этой проблемы.
Как работает страничный кеш и что с ним делать?
Когда ваша функция, которая должна писать данные на диск пишет данные, на самом деле она не пишет их на диск. Она пишет их в ОЗУ. Логика ядра Линукса проста и банальна, и она направленна на ускорение «отзывчивости» системы, всю суть можно объяснить так: «О, только что записали сотню гигабайт данных, наверное, скоро понадобится эти данные прочитать. Оставлю-ка я их в кеше, пользователь будет рад что так быстро смог их прочитать.» И так гигабайт за гигабайтом, пока в сервере не кончится физическая память.
Типичное решение проблемы – пишем скрипт, который раз в час делает echo 3 > /proc/sys/vm/drop_caches. Ну а кто-то просто забивает и позволяет системе убивать случайные процессы через OOM Killer. Но мы же пишем отказоустойчивую штуку. Нам такое не подходит. Задача объяснить ядру ОС, что наши fMP4 сегменты видеоархива — это write-only мусор на небольшое количество времени (т.к если клиент не хочет долго хранить записи, то архив чистится, а если хочет – мы отправляем архив после N времени хранения в S3, а локальную копию тоже чистим). Так что все должно работать по принципу – записал и забыл.
