IT-стандарты *

За последние три года, посетив более 50 заводов различных отраслей, я всё больше убеждаюсь: система управления на многих из них напоминает вождение автомобиля 1915 года. Завел с ручки, поехал со скоростью 20 км/ч, и неизвестно, доедешь ли сегодня в точку Б в двух кварталах, не говоря уже о более дальних поездках.

Многие директора заводов испытывают острую нехватку оперативных данных о текущем состоянии предприятия. Им нужны данные не за прошлый месяц, не с двухдневной задержкой, а в режиме реального времени. Вместо этого приходится заниматься «посмертным» анализом, выискивая узкие места по устаревшим данным. Ситуация меняется, появляются новые проблемы, а мы всё боремся с «демонами» прошлого.

Особую «радость» вызывают ручные замеры и бумажные инфоцентры завода или цеха. Десятки, а то и сотни человеко-часов в месяц тратятся на, казалось бы, правильную работу. Но вокруг цифровизация, а мы стоим у станка с бумажкой, записывая каждый простой. Пять цехов, 5-10 ключевых станков в каждой из трех смен, 10 тысяч подобных заводов в стране… К армии курьеров маркетплейсов смело можно добавить армию замерщиков.

Сравните: вы садитесь в современный автомобиль. Настраиваете зеркала, кресло, руль, пристегиваетесь, включаете зажигание и быстро оцениваете панель приборов: уровень бензина, давление в шинах, чек двигателя. Начинаете движение, следя за скоростью, температурой двигателя, дорожными знаками. Для этого не нужно техническое образование, чтобы доехать из точки А в точку Б за разумное время.

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

На днях посмотрел подкаст с Валерием Бабушкиным. Как всегда, было очень приятно слушать, и я хочу поделиться с вами основными тезисами, которые я для себя вынес.

Узнаем как быстро вникнуть в ML System Design, чем лего и спорт помогают, и почему важно уметь срезать углы на работе!

После первой статьи про стандарты разработки и зарождение Open vAIR остался резонный вопрос: «А что там под капотом?». Отвечаем.

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

Внутри — модульный backend, изоляция через RabbitMQ, REST API и документация, которая обновляется вместе с кодом, а не спустя квартал.

В этой статье разберём, чем Open vAIR отличается от тяжёлых решений, что умеет прямо сейчас, какие модули в приоритете — и в каких сценариях он уже «заходит в прод».

Эта статья — пошаговое руководство о том, как настроить процесс разработки, где исполнителем выступает LLM-модель. Я делюсь опытом составления понятных и чётких инструкций для моделей, а также описываю, как от начальной идеи дойти до готового продукта. Рассказываю, как выбирать подходящие технологии, структурировать задачи специально под LLM, выстраивать многоуровневую систему тестов и контролировать качество, не погружаясь постоянно в код. Также делюсь инструментами и шаблонами, которые помогают управлять поведением моделей и избегать типичных ошибок и проблем.

USB-C проектировался как универсальный стандарт. Но его возможности, к сожалению, варьируются от устройства к устройству, а это сбивает с толку пользователей. Microsoft решает эту проблему, внедряя строгие требования в рамках Windows Hardware Compatibility Program (WHCP). Сегодня разберем, как компания исправляет путаницу с USB-C-портами на Windows-устройствах, какие проблемы устраняет и что это значит для пользователей и производителей.

В чем разница и когда что использовать? Это был один из вопросов, на которые я пытался получить ответ.

Попытаюсь тут описать ту практику, которую считаю не плохой. С примерами на PHP. Постараюсь описывать на простом языке - без использования сложной терминологии.

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

Всё самое интересное из мира кибербезопасности /** с моими комментариями.

Это уже 20 выпуск моего еженедельного дайджеста! На этой неделе проходил ЦИПР и несколько интересных новостей от туда. WhatsApp всё догоняет, догоняет, но такими темпами никого не догонит. Критическая уязвимость в Auth0, щедрость Microsoft для Европы и другие только самые интересные и важные новости информационной безопасности.

В мире программирования существуют различные идеологии написания кода, которые отвечают за коммуникации (Unix-way), гибкость (Agile), чистоту и читаемость кода (DRY, KISS).

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

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

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

Всё самое интересное из мира кибербезопасности /** с моими комментариями.

На этой неделе новости про: раскрытие секретной сети ЦРУ; как с помощью ИИ нашли 0-day в ядре linux; ценовое исследование darkweb; про тюремные сроки для дропперов и другие только самые важные и интересные новости этой недели.

По своему опыту преподавания информатики и программирования регулярно замечаю, что вдумчивые начинающие программисты, отличающиеся внимательным отношением к различным деталям применяемых в программировании терминов, не редко впадают в ступор, изучая переведённые на русский язык книги известных на Западе программистов: М. Лутц, Дж Гл. Брукшир, М. Саммерфильд, М. Прайс, J.P. Мюллер, J. Албахари и т.д.  Например, чем отличается Statement, Operator, Instruction, и почему они так переводятся на русский язык?

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

Однако для тех начинающих программистов, кто хочет выстроить стройную систему знаний такой ответ явно не подходит. И почему знания должны быть искажёнными, некорректными, если он тратит время на обучение, лучше сразу выучить правильно, чем потом переобучаться. Это культура знаний. Помню, когда ещё был молодым адъюнктом, решил на актуальные для себя темы поговорить (пообсуждать) с учёным со стажем, он послушал меня, рассмеялся и сказал: «Давайте сначала мы договоримся о терминах, а потом пообсуждаем Ваши вопросы. Вы не тушуйтесь, это обычная ситуация, все через это проходят.» Применительно к IT, когда наш специалист в беседе с западными применяет словосочетание, например, if operator, вместо if statement – это режет слух. Но нравоучения вряд ли кому понравятся, поэтому перейдём к нашей теме.

В данной статье представлен авторский подход к унификации и централизации механизма обработки ошибок в HTTP-обработчиках веб-сервисов, разработанных на языке Go. Статья подробно рассматривает ограничения традиционных методов обработки ошибок, ведущие к дублированию кода и снижению поддерживаемости. Предлагается новый архитектурный паттерн, включающий использование специализированной сигнатуры функций-обработчиков, кастомного типа ошибки HTTPError для инкапсуляции статуса ответа, сообщения для клиента и внутренней ошибки для логирования, а также Middleware-адаптера для интеграции с фреймворками net/http и Gin. Данный подход демонстрирует повышение читаемости кода, упрощение отладки и обеспечение консистентности ответов API, что представляет собой значимый вклад в практику разработки бэкенд-сервисов на Go.

Забудьте о том, что Docker — это некий таинственный инструмент исключительно для DevOps-инженеров. В современном мире разработки Docker стал таким же незаменимым швейцарским ножом, как Git или ваш любимый редактор кода. Он позволяет любому разработчику писать код, который будет одинаково работать на машине коллеги, на тестовом стенде и в продакшене, забыв о кошмаре "а у меня на машине все работает". Если вы еще не погрузились в мир контейнеризации или вам нужен удобный источник команд, эта статья — ваш экспресс-билет.

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

Этот фреймворк — не просто очередной чек-лист: он синтезирует лучшие практики мировых стандартов (COBIT, ISO 27001, NIST, DNB/BIO) и позволяет провести оценку по пяти уровням зрелости с однозначными, понятными критериями для каждой практики. 

Приветствую, Хабр! В моей предыдущей статье были описаны принятые в прошлом году стандарты США FIPS (Federal Information Processing Standard — Федеральный стандарт обработки информации — аналог стандартов ГОСТ Р в России) на постквантовые алгоритмы электронной подписи (FIPS 204 и FIPS 205) и инкапсуляции ключей (FIPS 203). Данные криптостандарты были приняты в результате тщательного анализа и отбора алгоритмов в рамках открытого конкурса, проводимого Институтом стандартов и технологий США NIST; данный конкурс также был описан в предыдущей статье.

Стандарты FIPS 203 [1] и FIPS 204 [2] описывают алгоритмы, основанные на применении структурированных алгебраических решеток, тогда как алгоритм, стандартизованный в FIPS 205 [3], базируется на стойкости нижележащих хеш‑функций; данный алгоритм называется Stateless Hash‑Based Digital Signature Algorithm (SLH‑DSA) — алгоритм электронной подписи на основе хеширования без сохранения состояния. Стоит сказать, что данные алгоритмы стали не первыми постквантовыми криптоалгоритмами, стандартизованными в США, — еще в 2020 году в США был издана «специальная публикация» (SP — Special Publication — аналог рекомендаций по стандартизации в России) NIST SP 800–208 [4], описывающая несколько алгоритмов электронной подписи с сохранением состояния, также основанных на хеш‑функциях.

Далее в статье — описание и схемы алгоритмов, описанных в NIST SP 800–208, а также небольшой анализ особенностей алгоритмов данного класса.