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

Описанная история — не фантазия, а собирательное описание пары событий 2020 года. В крупных компаниях на этот случай всегда под рукой план послеаварийного восстановления, или disaster recovery plan (DRP). В корпорациях за него отвечают специалисты по непрерывности бизнеса. Но в средних и небольших компаниях решение таких задач ложится на ИТ-службы. Нужно самому разобраться в бизнес-логике, понять, что и где может упасть, придумать защиту и внедрить. 

Здорово, если ИТ-специалисту удается провести переговоры с бизнесом и обсудить  необходимость защиты. Но я не раз наблюдал, как компания экономила на решении для disaster recovery (DR), так как считала его избыточным. Когда наступала авария, долгое восстановление грозило убытками, а бизнес оказывался не готов. Можно сколько угодно повторять: «А я же говорил», — восстанавливать сервисы все равно предстоит ИТ-службе.



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

• Что защищаем?
  
• От чего защищаем?
  
• Как сильно защищаем? 
  

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

Наверняка многие из вас листая западные научные издания видели красивые и простые графики. Возможно некоторые из вас задумывались в чём же эти учёные мужи визуализируют свою данные. И вот есть шикарный и очень простой инструмент для построения графиков, который есть практически везде: Windows, linux, android, и прочих, уверен даже есть под ДОС. Он надёжен, прост и позволяет представить в виде красивых графиков любые текстовые-табличные данные.

Гибкий суррогат

Словом «Scrum» называются, как минимум, две сущности: философия и фреймворк.
Философия, или подход к работе, описан в книге Джеффа Сазерленда.
Фреймворк, т.е. алгоритм действий, описан в документе под названием Scrum Guide.
Философия превратилась в фреймворк, потому что авторы философии хотели заработать на ней денег (по их собственным словам).

Фреймворк сильно упрощен, по сравнению с философией. Главное — упрощена, а точнее выкинута, цель.

Цель философии: ускорение достижения результата. Причем, в разы. В книге есть примеры ускорения в 8 раз.

Цель фреймворка: чтобы у вас был Scrum. Там так и написано: делаете по инструкции — у вас Scrum, нарушаете инструкцию — у вас не Scrum.

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

Люди, преподающие или внедряющие Scrum, работают с фреймворком. Рассказывают и внедряют алгоритм, не приводящий ни к каким результатам, кроме «у нас теперь Scrum».

Суть понятна. Философию продавать очень сложно. Фреймворк — проще.

Фреймворк — это продукт. Он, как положено, прошел «упаковку». Он прост, понятен, есть поддержка и много специалистов. Ничего не напоминает?

Всё хорошо, кроме результата — его нет.

Как говорится, если тебе не стыдно за свой старый код, значит, ты не растешь как программист — и я согласна с таким мнением. Я начала программировать для развлечения более 40 лет назад, а 30 лет назад и профессионально, так что ошибок у меня набралось очень много. Будучи профессором информатики, я учу своих студентов извлекать уроки из ошибок — своих, моих, чужих. Думаю, пришло время рассказать о моих ошибках, чтобы не растерять скромность. Надеюсь, кому-то они окажутся полезны.

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

В этом случае дизайнер сталкивается со многими проблемами. Например, сопоставление дизайна с существующими фронт-енд фреймворками или борьба с «неудобными» данными, которые разрушают макет. Мы преодолеем эти проблемы с помощью следующих шагов: систематизируем потребности, станем атомарными и определим взаимодействие.

С недавних пор я снова перешёл на 100% работу из дома и стал использовать стол для работы стоя. Хочу поделиться дампом своего опыта на тему здоровья, призвать закончить прокрастинировать и начать работать стоя.

Сначала, о том, почему стол для работы стоя — не панацея...