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

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

По данным совместного опроса VK и агентства Prognosis, семь из десяти российских компаний уже внедрили в своей работе те или иные ИИ-инструменты. Они используются в клиентской поддержке, продуктовом маркетинге, работе с внутренними базами данных и вопросах кибербезопасности. В этом случае ИИ-технологии разгружают персонал, берут на себя рутинные задачи и становятся инструментом защиты.

Полина Сокол, менеджер продукта группы развития ML-технологий ГК «Солар», рассказывает, как ИИ усложняет атаки и затрудняет их распознавание, как проявляется влияние ИИ в сфере фишинга, и как нейронные сети используются для обхода антивирусных баз. И главное — что противопоставляет этим технологическим вызовам рынок кибербезопасности.

ИИ в кибератаке: модификация кода в реальном времени для обхода антивирусов

В топе атак с использованием ИИ — АРТ-атаки (усовершенствованная постоянная угроза), вредоносное ПО с внедренным ИИ, дипфейки на базе генерации ИИ, DDoS-атаки и фишинг. Также искусственный интеллект уже используется для создания полиморфных вирусов. Они в реальном времени модифицируют свой код и обходят антивирусные базы. Так, специалистам по кибербезопасности уже хорошо известен вредонос BlackMamba. Он интегрирует языковые модели для изменения своего кода и уклонения от обнаружения. Вредонос подробно описали его создатели, исследователи из компании Hyas. BlackMamba использует безопасный исполняемый файл, который обращается к высокоуровневому API (например, к API ChatGPT от OpenAI). Он возвращает синтезированный вредоносный код для исполнения на зараженном устройстве пользователя с использованием функции Python exec(). Важно, что вредоносная полиморфная часть при этом полностью остается в памяти и не обнаруживается антивирусными решениями. При каждом запуске вредонос повторно синтезирует возможности кейлогинга, при этом основной вредоносный компонент так и не удается обнаружить. Этот вредонос опасен тем, что может собирать конфиденциальную информацию с устройств пользователя. Имена пользователей, номера кредитных карт, пароли и другие чувствительные данные через веб-перехватчик Microsoft Teams отправляется на вредоносный канал, где попадают в распоряжение злоумышленников.

Привет, я Рома, во время поиска работы я часто сталкивался в вакансиях project и product менеджеров с требованиями «технического бэкграунда» или чего‑то более конкретного, например, составления API запросов. Из своего опыта я слабо понимал откуда берутся данные требования, но запросы в Postman направлять научился.

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

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

Бывало ли у кого-нибудь так, что начинаете реализовывать одну идею, а она плавно преобразовывается в другую, а затем ещё в одну, и вот, у вас на выходе уже совершенно свежая история, только лишь отдалённо напоминающая начальную задумку. Думаю, наверняка, бывало!

Этим особенно хороши свои собственные проекты, когда нет чётко прописанных ТЗ, и начальник не стоит за вашей спиной, одёргивая при любом отклонении. А также этим особенно славится "магия программирования", ведь код - потрясающе гибкая магическая субстанция, которая в соединении с железом современных смартфонов, может творить настоящие чудеса.

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

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

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

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

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

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

Так вышло, что кроме России, я работал в Европе, Казахстане и Австралии и немного в США. И мне есть что сказать на тему «чем отличается российский стиль менеджмента от Европейско-американского».

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

Разумеется, можно просто увольняться и не работать там, где кричат. Но, во-первых, это не всегда быстро получается, а, во-вторых, раз это данность рынка, так что стоит проговорить, как с этим разбираться и менять, не убегая.

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

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

Итак начнем с первого и очевидного вопроса:

История этого открытия — это путь от теоретической идеи до ее практической реализации, растянувшийся на десятилетия. Пионером выступил австралиец Ричард Робсон, который еще в 1989 году сконструировал первую модель MOF, используя ионы меди и органические молекулы. Его работа доказала саму возможность такого архитектурного подхода в химии, однако созданные им конструкции были хрупкими и нестабильными, напоминая дом без фундамента.

Прорыв совершили Сусуму Китагава и Омар Яги, чьи исследования, по сути, дополнили друг друга. Китагава из Киотского университета открыл, что металл-органические каркасы могут быть не статичными, а гибкими — они могут «дышать», изменяя свою структуру в зависимости от того, какие молекулы в них проникают.

Просто оставлю свой скрипт дампа пакетов composer тут. Адаптируйте под свои нужны.

Применял для резервного копирования пакетов, из-за нестабильной работы интернета при получении данных с зарубежных сервисов из-за кривых фильтров РосКомПозора (РКН).

Если вы работаете с мониторингом в Prometheus или VictoriaMetrics, то наверняка знаете, как алерты из Alertmanager могут быстро накапливаться, требуя ручного трекинга в Jira. А что если автоматизировать это полностью — с назначением исполнителей, метками, компонентами и даже шаблонами для описаний? Знакомьтесь с alertmanager-jira — классным инструментом для обеспечения интеграции Alertmanager (с Prometheus или VictoriaMetrics). Это Alertmanager (webhook) плагин, который создаёт и управляет задачами в Jira на основе алертов, с акцентом на гибкость. Написан на Quarkus, лёгкий и готов к деплою в docker (podman).

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

Современные микроконтроллеры часто взаимодействуют с периферийными устройствами через SPI‑шину. Проверить корректность работы SPI, отправить произвольные байты и посмотреть ответ бывает не так просто без специального оборудования. В этой статье мы разберём проект SPI DevTool — инструмент, который превращает STM32 в удобный веб‑интерфейс для отладки SPI.

Предлагаю на ваш суд мой промпт, который я разработала специально для ChatGPT-5. Вы можете загрузить свои конспекты или даже фото конспектов и получите материал: с логичной структурой, подзаголовками, списками, выделением ключевых понятий, вводной частью и резюме. Не выдумывает от себя, если что-то написано неразборчиво, пометит в отдельный блок. Cохраняет авторский стиль, поясняет термины, формирует обзор, основную часть, резюме и список вопросов. Результат оформляется в Markdown: удобно читать, редактировать и публиковать.

Введение

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

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

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

Концептуальная основа: ООП (Объектно-ориентированное программирование)

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

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

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

Почему именно такой способ оказался рабочим? И как это открывает новый этап в развитии ИИ для повседневных задач — без огромных затрат и костылей? Разбираемся, как машины начинают учиться «по-взрослому».

В этой публикации я предлагаю взглянуть на языковую модель (LLM) как на вероятностный вычислитель, который при определённой организации контекста способен давать детерминированный результат.

При таком подходе ADSM (Agent-Driven Software Management) становится архитектурой вычислений, где человек задаёт смысловую базу, агент выполняет циклы, а предсказуемость возникает из внутренней согласованности контекста.

Давайте разберем ППРФ № 1300 на молекулы, и разберемся, наконец, что-же там написано. Ниже таблица, в которой разобраны некоторые пункты данного постановления по-отдельности.

Сначала давайте определимся с терминами.

Через весь текст ППРФ речь идет про некое действие (процесс), который называется «передача», и осуществляется над объектом называемом «Информация об инициаторе телефонного вызова» это ни что иное, как «маркировка из 32 символов».

Для начала давайте отдельно разберем пункт 5 постановления, как самый трудночитаемый:

5. В целях передачи информации об инициаторе телефонного вызова на пользовательское оборудование (оконечное оборудование) оператор-инициатор предоставляет оператору связи, оказывающему услуги подвижной радиотелефонной связи, на основании договора об отображении информации, заключенного между инициатором телефонного вызова и оператором-инициатором, сведения, предусмотренные пунктом 6 настоящих Правил, в случае, если инициатор телефонного вызова самостоятельно или по запросу оператора-инициатора уведомил оператора-инициатора об отсутствии договора об отображении информации, заключенного ранее между инициатором телефонного вызова и оператором связи, оказывающим услуги подвижной радиотелефонной связи.

Помните свой первый «вау‑эффект» от LLM?

Я помню. Возможность вести диалог, генерировать код, получать ответы на сложные вопросы — казалось, мы получили идеального партнера по мышлению.
Но эйфория быстро угасла когда я начал использовать LLM для реальных, долгосрочных задач: рефакторинга сложного кода, написания архитектурной документации, анализа бизнес‑задач. И здесь проявилась фундаментальная проблема — «забывание».

Сегодня я хотел бы поделиться опытом поиска работы Java-разработчиком в РФ.

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

Итак, я обычный парень без каких-либо связей. После 9-го класса пошёл в техникум, закончил его на «отлично», затем отдал год службы в армии. После армии, как и у многих, у меня не было возможности учиться очно, поэтому я поступил на заочное отделение в институт. Пошёл работать: перепробовал множество профессий — фильтровал пиво, работал на складах Wildberries, в горячем цеху сети «Сицилия». Всё это время, на протяжении 2–3 лет после армии, я стремился стать разработчиком.

Как и многие ребята, которые не знают, с чего начать, я изучал всё подряд, неструктурированно: то Python, то JS. Потом взял перерыв, потому что потерял веру.

В конце 2023 года я вернулся в IT в попытках найти возможность стать разработчиком. Тогда я прошёл курсы на SQL Academy (понял, что без SQL в бэкенде никуда), кое-как одолел их за 1–2 недели. Потом мне выпал шанс пройти стажировку в ЦФТ. Я успешно прошёл все этапы, и меня взяли на позицию инженера по сопровождению. Там я плотнее познакомился с SQL, начал делать запросы разной сложности в PL/SQL Developer. Затем я понял, что эта позиция мне не симпатизирует и это не тот опыт, который я хотел получить.

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

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

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

Я прожил в Новой Зеландии больше 8 лет уже. На русском я разговариваю где-то раз в месяц, поэтому если допущу ошибки, прошу меня не винить.

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

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

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

Для начала немного теории:

Из книги Д.А. Михалин, И.М. Никонов, Одна задача о нахождении фальшивой монеты, Матем. просв., 2007, выпуск 11, 149–158:

Максимальное число монет Q1, среди которых можно найти фальшивую и определить ее относительный вес за k взвешиваний определяется по формуле:

Q1 = (3k – 3)/2

Максимальное число монет Q2, среди которых можно найти фальшивую, не определяя ее относительный вес за k взвешиваний определяется по формуле:

Q2 = (3k – 1)/2

Максимальное число монет Q3, среди которых можно найти фальшивую, не определяя ее относительный вес за k взвешиваний, когда в распоряжении есть одна настоящая монета определяется по формуле:

Q3 = (3k + 1)/2

Таким образом, Q1, Q2 и Q3 для двух взвешиваний равно, соответственно, 3, 4 и 5 монет. Q1, Q2 и Q3 для трех взвешиваний равно, соответственно, 12, 13 и 14 монет.

Привет, Хабр! Если вы читали мою прошлую статью Сапёр в эпоху LLM: Повайбкодим на ABAP , то уже знаете, что попытка «повайбкодить» на ABAP с помощью LLM — затея, мягко говоря, неоднозначная. Модели «галлюцинируют», выдумывают несуществующие BAPI и таблицы, и в целом чувствуют себя в закрытой экосистеме SAP не очень уверенно. Как говорится, вайбкодинг не задался.
В комментариях к статье прозвучала здравая мысль: будь у модели больше контекста, она бы справилась лучше.Раз появились такие идеи — значит, пора воплощать их в жизнь. На этот раз — новая серия экспериментов: в этот раз займемся переводом вопросов по SAP из обычного языка в SQL-запросы, плюс построим агента с необходимыми для этого инструментами.