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

Часто на вопрос «Как у вас организован учет ИТ-активов?» компании отвечают: Excel-таблицы и инвентаризация ежеквартально. Однако, если у вас несколько офисов, сотни единиц оборудования и тысяч лицензий, точно ли вы знаете, где что находится и сколько это реально стоит? По моему опыту работы с крупными заказчиками, отсутствие системного подхода к управлению ИТ-активами приводит к незапланированным расходам и потере контроля над бюджетом на обслуживание и обновление оборудования.

Меня зовут Евгения Асоскова, я владелец продукта SimpleOne ITAM. В этой статье я расскажу, почему так происходит и как этого избежать.

Привет, Хабр. На связи Сергей Пушкарёв, я руковожу отделом разработки BIOS в YADRO. Расскажу об устройстве UEFI и его применении в компании. Мы разрабатываем и выпускаем разные аппаратные платформы: серверы, системы хранения данных, клиентское и телеком-оборудование. 

Один из «кирпичиков», который обеспечивает инициализацию и функционирование оборудования, — это BIOS (но правильнее говорить UEFI 🙂). В статье кратко разберем историю этой системы и ее современную реализацию — UEFI. Также поговорим о подходе к разработке и отладке этого ПО в YADRO.

Вы узнаете, зачем нам нужна «синяя коробка» Intel, как мы прошиваем BIOS и проводим диагностику «в полях».

Бизнес сталкивается с вызовом: как согласовать работу десятков подразделений — от IT до бухгалтерии — чтобы каждый отдел не просто выполнял задачи, но создавал ценность для коллег и клиентов. Ответом становится Enterprise Service Management (ESM) — подход, который превращает внутренние процессы компании в сервисы, где сотрудники выступают как «потребители», а отделы — как «поставщики услуг».

В этом материале мы рассказали и показали с помощью каких инструментов ESM-платформа SimpleOne помогает реализовать сервисный подход во всей компании.

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

В статье я рассказываю о процессе сдачи экзамена ISTQB Foundation Level в удаленном формате. Поделюсь опытом подготовки, регистрации, проверки оборудования и самих экзаменационных шагов. Узнаете, как проходит экзамен, какие были нюансы и как удалось успешно сдать тест.

Представьте: вы долго и напряженно внедряли вашу ИТ-систему и наконец запускаете ее в эксплуатацию. Но вместо радости от успешного старта, пользователи сталкиваются с проблемами из-за неправильно настроенных прав доступа. Бывало такое? Надеюсь, что нет, ведь это не просто неудобства — это серьезные риски для бизнеса: утечки данных, нарушения безопасности, остановки процессов.

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

1. Причины трансформации рабочей силы

• 1.1 Технологический прогресс

Взгляните на эти два QR-кода. Отсканируйте их, если хотите: обещаю, в них нет ничего опасного.

Слева HTTPS://EDENT.TEL/ в верхнем регистре, а справа — https://edent.tel/ в нижнем.

Можно чётко заметить, что слева QR-код «меньше», то есть в нём меньше битов данных. Оба ведут на один и тот же URl, единственное различие заключается в регистре.

Что здесь происходит?

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

В этой статье я делюсь своим опытом подготовки к экзамену ISTQB® Certified Tester Foundation Level (версия 4.0). Я расскажу, какие методы оказались неэффективными, а какие, наоборот, существенно ускорили процесс и помогли успешно сдать экзамен. Если вы тоже планируете получить этот сертификат, надеюсь, мой опыт будет полезен!

На технологических площадках обсуждается потенциальная альтернатива HTTP для передачи крупных файлов. Мы решили обсудить, о чем идет речь и что может предложить новый протокол, который только начинает «обрастать» спецификацией.

На днях читала очень интересную статью об опыте медицинских клиник Mayo в США, и вследствие этого углубилась в чтение книги "Практика управления Mayo Clinic", Леонарда Берри и Кента Селтмана. Медицина с IT во многом похожи, возможно я провожу такие параллели, потому что работала в медицине более 10 лет, а сейчас работаю в IT (тоже надо сказать в медицинской компании).

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

• std::hive
• Constexpr, ещё больше constexpr
• Безопасность, контракты, hardening, профили, UB и std::launder
• Relocate
• #embed

Как понять, что мы проектируем REST API правильно? Никак. Смотреть на публичную API‑документацию крупных систем, диссертацию Роя Филдинга, или на то, что уже есть в проекте. И исходя из этого принимать решения о том, как будут выглядеть новые REST API методы.

В этой статье я хочу представить результаты исследований REST API сервисов управления задачами Trello и Todoist, чтобы показать, какие решения являются хорошими стандартами проектирования, а какие нет, но всё равно применяются на практике.

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

Меня заинтриговал комментарий GuB-42 на Hacker News:

При помощи последовательностей ZWJ (Zero Width Joiner) теоретически можно закодировать в один эмодзи неограниченный объём данных.

Действительно ли можно закодировать в один эмодзи произвольные данные?

tl;dr: да, однако я нашёл решение и без ZWJ. На самом деле, можно закодировать данные в любой символ Unicode. Например, в этом предложении есть скрытое послание: This sentence has a hidden message󠅟󠅘󠄐󠅝󠅩󠄜󠄐󠅩󠅟󠅥󠄐󠅖󠅟󠅥󠅞󠅔󠄐󠅤󠅘󠅕󠄐󠅘󠅙󠅔󠅔󠅕󠅞󠄐󠅝󠅕󠅣󠅣󠅑󠅗󠅕󠄐󠅙󠅞󠄐󠅤󠅘󠅕󠄐󠅤󠅕󠅨󠅤󠄑. (Попробуйте вставить его в декодер.)