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

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

А вы бы включили в список стейкхолдеров хакеров и мошенников – у них интерес к системе существует по определению? Разумеется, речь не идёт об «АРМе хакера», в котором они были бы пользователями.

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

ISO/IEC/IEEE 12207-2017

Вот что говорит стандарт ISO/IEC/IEEE 12207-2017 «Systems and software engineering — Software life cycle processes» - см. примечание к п. 2.3. радела 6.4.

«Некоторые заинтересованные стороны имеют интересы, которые противоречат интересам заказчика (например, рыночные конкуренты, хакеры, террористы) или противоречат друг другу. 

Когда интересы заинтересованных сторон противоречат друг другу, но не противоречат программной системе, этот процесс направлен на достижение консенсуса среди классов заинтересованных сторон для установления общего набора приемлемых требований. 

Намерения или желания тех, кто противостоит заказчикам или является противниками системы, решаются через 

·      процесс управления рисками, 

·      процесс анализа угроз в рамках системного анализа или 

·      cистемные/программные требования по безопасности, адаптируемости или устойчивости. 

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

Публикую интервью с Александром.

Александр работает электромехаником по ремонту и обслуживанию вычислительной техники в Новополоцке (Беларусь).

Опытные разработчики каждый день пишут тонны кода (а еще более опытные не пишут его совсем), и если ты хочешь быть продуктивным — нужно учиться писать быстрее. Сегодня на связи — Даниил Лихачев, python-разработчик в ДАЛЕЕ. Делюсь известными и не очень способами по ускорению написания кода. 

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

Всем привет, меня зовут Антон Малафеев, я руководитель группы инженеров IT‑инфраструктуры в СберМаркете. Моя команда вот уже больше 3-х лет занимается разработкой деплоя для PaaS и сопутствующих инструментов.

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

Но сначала немного цифр. Ниже на рисунке — наша статистика использования канареечного деплоя. На момент написания статьи у нас в проде 200+ сервисов, 5300 подов PaaS, ежемесячно мы делаем 2 тысячи деплоев в продакшн и 11 тысяч деплоев в стейдж, которые проходят через канарейку.

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

Долгожданный стандарт RFC9562 "Universally Unique IDentifiers (UUID)" с тремя новыми версиями идентификаторов UUID (6, 7 и 8) вместо малопригодного RFC4122 наконец-то вступил в силу. Я участвовал в разработке нового стандарта. Обзор стандарта можно посмотреть в статье.

Введенные новым стандартом идентификаторы седьмой версии UUIDv7 — это лучшее, что теперь есть для ключей баз данных и распределенных систем. Они обеспечивают такую же производительность, как и bigint. UUIDv7 уже реализованы в том или ином виде в основных языках программирования и в некоторых СУБД.

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

Черновик стандарта активно обсуждался на Хабре в апреле 2022 года в комментариях к статье "Встречайте UUID нового поколения для ключей высоконагруженных систем".

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

Предложенная мной ниже спецификация UUIDv7 с дополнительной функциональностью описывает максимально надежный и удобный вариант структуры UUIDv7 для самых сложных и высоконагруженных информационных систем. Функциональность упорядочена по приоритету реализации

В чём принципиальное отличие джуна от мидла, а мидла от сеньора? На какие навыки поднажать, чтобы не задерживаться на одной ступеньке? Эти темы актуальны в ИТ-сообществе всегда. 

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

Привет всем! Меня зовут Юля, я фронтенд-разработчик, наставник на курсах по JS и React и организатор профессионального сообщества Tbilisi JS. В Практикуме я помогаю студентам на курсе «React-разработчик».

За время работы в разных компаниях и над разными проектами я поняла, что Git — это не только (и не столько!) знание самой технологии и конкретных команд, но и определённая культура взаимодействия, практики, подходы, договорённости. Всё это помогает участникам команды лучше понимать друг друга и работать быстрее и чётче.

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

Как создать эффективное резюме и сопроводительное письмо для успешного поиска работы в IT сфере?

Обсудим важность правильного форматирования и структурирования резюме, а также на что обращают внимание работодатели. Раскроем советы по написанию сопроводительного письма, обсудим его структуру и способы выделить свои профессиональные навыки.

Привет, Я Бохан Дмитрий — руководитель отдела инновационных проектов компании ПГК Диджитал. Сегодня поговорим про ретроспективу, зачем проводить ретро, а самое главное посмотрим с помощью каких игр, можно сделать ретро ярким и незабываемым.

Зачем проводить ретроспективы с командой? 

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

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

2. Вовлечение команды: с участие членов команды в процессе принятия решений  дает им новые возможности и увеличивает их чувство владения проектом.

3. Решение проблем: выявление проблем и препятствий своевременно не позволяет им расти и сорвать проект.

Инструменты для ретро

Подготовка и проведение эффективных ретроспектив требует некоторых важных инструментов и методов:

Собственно, сабж.

На это указывает ряд моментов в существующих решениях.

Прежде всего, давайте вспомним, какими важными характеристиками обладает файл?

При разработке приложения, сервиса, системы и тп возникает один из главных вопросов: как мне хранить данные (какую БД выбрать). В связи с тем, что чаще всего в получите ответ “зависит” (it depends), предлагаю рассмотреть несколько стратегий, которые будут работать почти всегда.

В России на разные виды деятельности нужны лицензии. Например, чтобы производить и продавать алкоголь и табачные изделия, требуется разрешение. Это касается и защиты конфиденциальной информации, разрешение на работу с которой выдает Федеральная служба по техническому и экспортному контролю (ФСТЭК России).

В этой статье не будет захватывающих кейсов из практики наших SRE-инженеров. Мы погрузимся в бюрократический мир, с которым столкнулись при получении лицензий ФСТЭК России. Мы расскажем, лицензии каких видов бывают и как определить, какие из них необходимы. Также пройдёмся по основным требованиям к получению лицензий и рассмотрим, как мы приводили компанию в соответствие с ними и с какими проблемами столкнулись.

Открываю исходники очередного enterprise-проекта: о да-а-а, вот они, старые знакомые, лучшие друзья разработчика — first name и last name.

Каждый из нас проходил собеседования. В разных компаниях процессы трудоустройства могут сильно отличаться друг от друга. Например, в ряде случаев вас ожидает часовой прогон по теории Frontend'a, а где-то вы столкнетесь с кучей этапов проверок: алгоритмы, теория, софт-часть и т.д. За свою 4-летнюю карьеру Frontend-разработчика я собрал конструктор самого худшего собеседование по-моему мнению.

P.S. Далее вы столкнетесь с субъективным мнением автора, которое может не соответствовать вашим ожиданиям

• запрет возврата из функции ссылок на временное значение,
• [[indeterminate]] и уменьшение количества Undefined Behavior,
• диагностика при =delete;,
• арифметика насыщения,
• линейная алгебра (да-да! BLAS и немного LAPACK),
• индексирование variadic-параметров и шаблонов ...[42],
• вменяемый assert(...),
• и другие приятные мелочи.

Привет, Хабр! Меня зовут Олег Бондарь, я архитектор решений в CDEK. В этой статье расскажу о стандартах — сводах правил и требований, которые позволяют всем участникам процесса быть в общем контексте, действовать единообразно и совершать меньше ошибок. Кроме того делают взаимодействие между людьми и системами немного проще.

Статья будет полезна менеджерам проектов, разработчикам, тестировщикам, аналитикам и другим IT‑специалистам. Поговорим о способах выработки и применении стандартов, их влиянии на проектирование, разработку, тестирование и стабильность системы в целом. Для примера возьмем ERP CDEK, которая ежедневно обеспечивает работу десятков тысяч пользователей, нескольких сотен тысяч клиентов и позволяет нам обрабатывать до полумиллиона заказов в день.

Часто слышим «это целый процесс!», «это настоящий проект!» или смесь типа: Наш «проект - это целый процесс, который начинается с создания уникальной идеи».

Однако, отличие процесса от проекта – простое, проект это один из видов процесса, поэтому противопоставлять их некорректно. А вот с процессным подходом все очень сложно и запутано, поэтому требует отдельного исследования. В целом для процесса, процессного подхода и самого ВРМ нужна онтологизация, концептуализация «управления бизнес-процессами».

Если мы хотим управлять бизнес-процессами (Business Process Management) или проектами, то нужно понять, а чем таким управлять то мы собрались.