Цель статьи — провести классификацию и иерархическое деление требований на группы с конкретными примерами из лабораторной практики. Разделение требований на группы и подгруппы необходимо для правильного построения проектного решения, основанного на анализе требований, а не на "представлениях о хорошем". Особенно это актуально для систем, подчиняющихся строгим стандартам, таким как ГОСТ ISO/IEC 17025-2019, который устанавливает общие требования к компетентности, беспристрастности и стабильной работе лабораторий.

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

Вам когда-нибудь нужно было зайти в BIOS или UEFI, чтобы сменить порядок загрузки, включить виртуализацию или проверить оборудование? Многие пользователи знают лишь один способ — в первые секунды после включения компьютера нажать Del, F2 или другую «волшебную» клавишу. Но что делать, если клавиатура не работает, используется удалённое подключение, или вы просто не успеваете нажать нужную кнопку из-за быстрой загрузки системы?

Оказывается, на современных операционных системах можно программно перезагрузиться прямо в интерфейс прошивки, используя лишь командную строку или терминал. В этой статье мы рассмотрим, как это сделать в Windows, Linux и выясним, какие возможности есть в macOS.

Home Assistant позиционирует себя как локальную систему. Но я столкнулся с ситуацией, когда локальная функция (Samba) не работает из-за облачного сбоя. При этом я вообще не использую облако. В статье описываю как обошёл эту проблему за 5 минут, когда за день разобрался в причине.

Мне очень нравится Home Assistant как система управления умным домом, потому что она позволяет не зависеть от облаков и от падений интернета. Это не просто слова - с 2017 года я использую умный дом в обычной двухкомнатной хрущевке, и в основном всё работает. Но это скорее тестовый полигон для меня - я сам там не живу и поэтому очень ценю то что Home Assistant можно настроить один раз и если не обновлять, то несколько лет всё может спокойно проработать. А на этих новогодних каникулах у меня было время и я решил полностью обновить все дополнения и прошивки. Как оказалось зря - паранойя безопасности ломает определение Home Assistant как автономного сервиса, который можно использовать локально.

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

Хорошие книги подобны жемчугу.

Когда разработчик сталкивается с проблемой (непонятной ошибкой, архитектурным тупиком, неудобным инструментом) — это становится своего рода «песчинкой». Она мешает, раздражает, не дает покоя. Включается защитная реакция (поиск лучших решений, эксперименты, переосмысление). Вокруг проблемы постепенно нарастают слои знаний. И если разработчик решается поделиться ими в книге — появляется та самая жемчужина.

Нажми и забудь: как автоматизировать рутину с PowerShell и GUI

Это руководство пригодится всем, кто устал от рутины и хочет сделать свои PowerShell-скрипты доступными для коллег: системным администраторам, инженерам технической поддержки, DevOps-специалистам. Мы не только разберем основы создания кнопок и окон, но и ответим на ключевые вопросы: Как выбрать между WinForms и WPF, как избежать зависания интерфейса при выполнении долгих операций, и как удобно упаковать ваш скрипт в EXE или ярлык, чтобы любой сотрудник мог запустить его одним кликом.

Древнее и сакраментальное RTFM преследует нас повсюду. Волей-неволей мы вынуждены постоянно читать инструкции: к технике, приборам, приложениям, системам.

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

В статье расскажу о пяти важных блоках информации, которые обязательно должно содержать руководство пользователя (оно же User Guide).

При подготовке специалиста в области проектирования Информационных систем, важно учитывать конъектуру применения навыков в дальнейшем. Это может быть либо роль «Проектировщик» в каком‑то из проектов, либо постоянная профессия «Проектировщик ИТ‑продуктов».

Данный курс является продолжением образовательной программы в области проектирования Информационных систем (далее ИС). В рамках этой части - «Архитектура ИТ решений», мы с Вами рассмотрим вопросы проектирования и организации, применительно к большим глобализационным системам.

Часто, когда отдельные ИТ-системы, по мере развития цифровизации начинают объединять в более крупные, всеобъемлющие решения, команды сталкиваются с проблемами восприятия:

Привет, постоянные и не очень читатели!

Были времена, когда админы дурели от этой прикормки 10 Гбит/c канала, а теперь такая пропускная способность — норма для роутера в прихожей (не у всех, но всё же).

В ЦОДах же и 100 Гбит/c уже давно никого не удивят — у гиперскейлеров (Amazon, Microsoft, Google, Alibaba, экстремистская и запрещённая в России Meta) это дефолт, в энтерпрайзе и бизнесе разных размеров — активно внедряют.

Компании уровня cloud-scale (те, что строят сервисы облачного уровня: Netflix, Spotify, Salesforce, Zoom) и гиперскейлеры уже переходят на 200 Гбит/c и тестируют 400/800 Гбит/c, ну а поскольку 200 мало чем отличается по стоимости инфраструктуры от 400, то некоторые сразу перескакивают, ведь легаси кабельное хозяйство (LC, MPO-12) всё равно не потянет эти апгрейды, надо всё перелопачивать на MPO-16, MPO-32 или новые форматы (QSFP-DD, OSFP).

В общем, накопилось у меня пару идей, как собрать всё это в едином материале: обсудить, где шайба будет через время; подумать, а надо ли оно (апгрейд) вообще — и в довесок затронуть денежные вопросы: всякие CAPEX, TCO/ROI, ₽/(Гбит/c), ($/Gbps) и прочее экономическое непотребство.

Присаживаемся, ложимся или в какой там позе вы читаете — и начинаем.

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

Боитесь, что тесты пропадут, если компьютер сломается? Хотите видеть историю изменений? Вынуждены запускать тесты в отпуске, т.к. у других членов команды нет к ним доступа? Не можете одновременно работать над написанием и прогоном? Знакомы эти проблемы, хотите избавиться от них раз и навсегда? Тогда вам необходимо использовать Vanessa Automation вместе с Gitlab. И я готов показать этот процесс на максимально простом примере. Меня зовут Дмитрий, я занимаюсь тестированием 1С Зуп в команде HR Tech Самолет. В сфере 1С я уже 7 лет, работал консультантом, аналитиком и программистом. А в тестирование я перешел, чтобы уберечь галактику от ошибок ПО. Поехали!

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

При составлении списка я ориентировался на количество стран, в которых возможно заказать наиболее универсальную услугу, а именно виртуальные серверы, а также минимальную цену не выше 300 рублей, 5 долларов или 5 евро в месяц. У большинства хостеров возможен заказ услуг в России, а там, где это возможно, приведена ссылка на точки Looking Glass.

Привет, Хабр! Относительно недавно после пары лет перерыва в айти, потраченных на изучение японского языка, мне пришлось срочно обновлять свои знания на работе. Ну знаете, искать возможности исполнить все хотелки начальника, как и положено эникею. Меня ждало много увлекательных открытий, но при этом, как водится, и немало боли и борьбы с непонятками. Docker, контейнеры, реверс DNS и реверс прокси, получение TLS сертификатов. В какой-то момент я наконец дошёл до удобного решения, которым я теперь хочу поделиться.

В своё время домашний сервер очень облегчил бы мне понимание Docker’а, да и удобство работы с ним неслабо бы повысил. Поэтому возникла идея написать эту статью, после прочтения которой любой человек даже с поверхностными знаниями в информационных технологиях сможет поставить себе постоянно доступный домашний сервер на базе Docker Swarm с удобной веб-мордой, простым получением TLS-сертификатов и Heroku-подобным функционалом (для чего будем использовать PaaS CapRover). 

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

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

В первой статье цикла я хочу начать с базовых понятий, которые пригодятся всем начинающим сетевым инженерам, студентам и тем, кто связан с сетевыми технологиями. Это модель OSI и TCP/IP. Это база, которую необходимо знать. Вначале мне было трудно запомнить и понять суть этих моделей и их связь с настройками обычного коммутатора. Однако понимание модели OSI облегчает понимание работы различных протоколов и позволяет общаться с коллегами на одном языке. Меня раньше часто поправляли из-за того, что я говорил неправильно, не зная базовых понятий.

Итак, давайте разберемся с базовой информацией.

Модель OSI (Open Systems Interconnection) — это эталонная модель, разработанная для описания функций телекоммуникационных или вычислительных систем, необходимых для сетевого взаимодействия. Она разделяет процесс сетевого взаимодействия на семь взаимосвязанных уровней. Каждый уровень выполняет специфические функции и взаимодействует с уровнями непосредственно выше и ниже.

В моей предыдущей статье Запахи технической документации я писала про схожесть применяемых способах познания программирования по отношению к документации. Что я сделаю сейчас? Совершенно то же самое. Напомню, что шаблоны проектирования описывают типичные способы решения часто встречающихся проблем при проектировании программ. Рассмотрим шаблоны проектирования, представленные на ресурсе Refactoring Guru (сейчас он запрещен на территории РФ). Ну, что, начнем?

BPMN — нотация, предназначенная для моделирования бизнес‑процессов. В ней нет эталонного и единственно правильного способа смоделировать процесс. Вариантов описания много. При этом описываемые процессы будут с разными уровнями оптимальности и глубины.

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

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

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

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

Magnit Tech не стал исключением, ведь я пришла в команду, которую только-только сформировали. То есть – ни одной странички в Confluence в нашем разделе.

Звучит пугающе? А меня это заинтересовало. Так что, в этой статье я расскажу:

Зачем –> определение конечной цели
Кому –> распределение ответственности
О чем –> выбор темы для документации
Когда –> выбор времени для написания
Как –> эффективное донесение информации.

А также поделюсь двумя вариантами подхода к написанию документации + как работать над стилистическим оформлением.