Архив за месяц: Апрель 2020

Настраиваем Visual Studio Code для работы с Go

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

1. Необходимо установить сам Go: https://golang.org/dl/
2. Прописываем GOPATH (если устанавливали через msi, то он уже будет задан и надо его заменить на более удобный). Это workspace, где будет лежать код и бинарные файлы всего с чем будем работать в Go.
3. В Visual Studo Code открываем терминал (Ctrl + `) и проверяем, что установка прошла нормально, для этого набираем go version:
Ну и должны увидеть версию совпадающую с версией которую мы установили в шаге 1.
4. Устанавливаем расширение для работы с Go:
5. Создаем пустой файл с расширением go и получаем уведомления о том, что у нас не установлен go-outline и Analysis Tool:
Кликаем на Analysis Tool Missing и выбираем установить недостающие пакеты.
После установки должны заработать подсветка, донаборщик и т.д., если нет, то перезапустите VS Code:
6. Для отладки устанавливаем Delve, для этого в терминале (Ctrl + `) выполняем команду: go get github.com/go-delve/delve/cmd/dlv
7. Power Shell в некоторых местах эскейпит больше чем надо, поэтому настраиваем git bash в качестве терминала. Для этого в settings.json прописываем путь к терминалу:
"terminal.integrated.shell.windows""C:\\Program Files\\Git\\bin\\bash.exe"

8. Дальше буду дописывать по мере возникновения потребностей, оставайтесь на связи :)

Настраиваем Visual Studio Code для работы с Go

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

1. Необходимо установить сам Go: https://golang.org/dl/
2. Прописываем GOPATH (если устанавливали через msi, то он уже будет задан и надо его заменить на более удобный). Это workspace, где будет лежать код и бинарные файлы всего с чем будем работать в Go.
3. В Visual Studo Code открываем терминал (Ctrl + `) и проверяем, что установка прошла нормально, для этого набираем go version:
Ну и должны увидеть версию совпадающую с версией которую мы установили в шаге 1.
4. Устанавливаем расширение для работы с Go:
5. Создаем пустой файл с расширением go и получаем уведомления о том, что у нас не установлен go-outline и Analysis Tool:
Кликаем на Analysis Tool Missing и выбираем установить недостающие пакеты.
После установки должны заработать подсветка, донаборщик и т.д., если нет, то перезапустите VS Code:
6. Для отладки устанавливаем Delve, для этого в терминале (Ctrl + `) выполняем команду: go get github.com/go-delve/delve/cmd/dlv
7. Дальше буду дописывать по мере возникновения потребностей, оставайтесь на связи :)

Обработка html в Marp при использовании Visual Studio Code

Интересная штука, в MarkDown по умолчанию html обрабатывается "из коробки", а вот в Marp он по умолчанию выключен, для предотвращения зловредного кода полученного вместе с презентацией. Но если вы захотите включить корректную обработку html тегов, то это можно сделать в File -> Preference -> Settings (Ctrl + ,):


MarkDown для презентаций

Тут как то писал про инструмент построения UML диаграмм при помощи PlantUML. Сегодня поговорим про еще один инструмент на основе плоского текст - Marp. Он позволяет описывать презентации в виде текста (который будет нормально мерджится в том же Git-е) и генерировать на его основе презентацию в pptx, pdf или html.

Итак, начинаем.

Для работы с Marp я буду использовать Visual Studio Code. Устанавливаем расширение для работы с Marp:
Создаем файл с расширением md:
После этого можем включить предварительный просмотр:
В режиме разделенного редактора в правой части будет виден результирующая презентация (напоминаю, все картинки кликабельны):

Пара замечаний:
marptrue
Используется, для пометки что мы используем marp. Если не указать эту строку, или указать значение false, то модуль выключится и мы будем получать стандартное отображение для MarkDown:

--- - используется для разделения страниц. Единственно, не забываем, что перед --- надо оставлять строку. если это не сделать, то разделитель перестает работать:
Если пустые строки раздражают, можно воспользоваться другими разделителями ___ (три подчеркивания), *** (три звездочки) или - - - (те же три минуса, но через пробел).

Что еще есть полезного в Marp? Конечно же директивы. В первом блоке, где у нас был указан marp:true можно указывать директивы в синтаксисе имя_директивы: значение, а если нужно указать директиву на конкретной странице, то используется синтаксис html комментариев. Например:
Фон стал желтым, но на конкретном слайде он был заменен на белый, причем в этом случае у директивы использовался в начале знак подчеркивания:
_backgroundColor: white
Если знак подчеркивания убрать, вот так:
backgroundColor: white
То директива будет действовать не только на текущий слайд, но и на последующие:

Директивы делятся на глобальные и локальные. Глобальных не много, они позволяют задать тему (из набора стандартных), стиль оформления и еще один вариант разделения страницы на слайды. Я немного покажу про стили.
Стили задаются при помощи html элемента style:
Как и в обычном html можно задавать классы и применять стиль к ним, в примере задан стиль для титульной страницы (с классом tiltslide) и для всех остальныз страниц:

Ну и самое главное, экспорт. Для этого, достаточно кликнуть на появившемся в редакторе ярлыке Marp и выбрать экспорт:
Получается, весьма похоже:
Кроме pptx, можно экспортировать в pdf, html и изображения (png и jpg).

MarkDown для презентаций

Тут как то писал про инструмент построения UML диаграмм при помощи PlantUML. Сегодня поговорим про еще один инструмент на основе плоского текст - Marp. Он позволяет описывать презентации в виде текста (который будет нормально мерджится в том же Git-е) и генерировать на его основе презентацию в pptx, pdf или html.

Итак, начинаем.

Для работы с Marp я буду использовать Visual Studio Code. Устанавливаем расширение для работы с Marp:
Создаем файл с расширением md:
После этого можем включить предварительный просмотр:
В режиме разделенного редактора в правой части будет виден результирующая презентация (напоминаю, все картинки кликабельны):

Пара замечаний:
marptrue
Используется, для пометки что мы используем marp. Если не указать эту строку, или указать значение false, то модуль выключится и мы будем получать стандартное отображение для MarkDown:

--- - используется для разделения страниц. Единственно, не забываем, что перед --- надо оставлять строку. если это не сделать, то разделитель перестает работать:
Если пустые строки раздражают, можно воспользоваться другими разделителями ___ (три подчеркивания), *** (три звездочки) или - - - (те же три минуса, но через пробел).

Что еще есть полезного в Marp? Конечно же директивы. В первом блоке, где у нас был указан marp:true можно указывать директивы в синтаксисе имя_директивы: значение, а если нужно указать директиву на конкретной странице, то используется синтаксис html комментариев. Например:
Фон стал желтым, но на конкретном слайде он был заменен на белый, причем в этом случае у директивы использовался в начале знак подчеркивания:
Если знак подчеркивания убрать, вот так:
То директива будет действовать не только на текущий слайд, но и на последующие:

Директивы делятся на глобальные и локальные. Глобальных не много, они позволяют задать тему (из набора стандартных), стиль оформления и еще один вариант разделения страницы на слайды. Я немного покажу про стили.
Стили задаются при помощи html элемента

Архитектор, а какой ты?

Статья подготовлена для корпоративного портала.

Бизнес-правила являются причиной существования 
программной системы. Они составляют основу функционирования. 
Они порождают код, который делает или экономит деньги. 
Они — наши семейные реликвии. 
-- Роберт Мартин

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

Родоначальником формализации архитектуры корпоративных информационных систем можно считать Джона А. Захмана со статьями «A framework for information systems architecture» и «Extending and formalizing the framework for information systems architecture», в которых и было описано то, что получило название модель Захмана.



Данная модель, несмотря на сложный вид, продвигает достаточно простую концепцию. Для разных людей при описании разных частей системы (под системой здесь понимается все предприятие) необходимо использовать разные модели, главное, чтобы они согласовывались между собой. Сам Захман пояснял это на примере строительства загородного дома. Архитектор садится с заказчиком и высокоуровнево обсуждает, что должно быть на участке и в доме. Результатом такой работы является концептуальный план, который в процессе работы архитектора превратиться в план водоснабжения для сантехников, архитектурный план для строителей, план электропроводки для электриков. И задача архитектора следить, чтобы все эти планы были между собой согласованы (чтобы не получилось, что водоснабжение придет в спальню, вместо санузла). 

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

Переходя на более высокий уровень, Togaf предлагает из всех столбцов оставить только 4 домена: бизнес деятельность, данные, приложения и технологии. При этом, ничто не мешает думать про корпоративную архитектуру в тех же уровнях детализации: от контекстного, через концептуальный и логический, к физическому и непосредственной реализации. В этом случае получится следующая модель (картинки кликабельны): 
На этой модели уже будет удобно обсудить, кто и за что отвечает. Большинство архитекторов находятся на трех верхних уровнях, и различаются названием доменом с которым работают. На двух последних уровнях чаще говорят уже про исполнителей: 
До такого разделения на зоны ответственности, может, не с выделением всех ролей, большинство компаний доходит достаточно быстро, но, как мы обсуждали в прошлой статье, максимальной пользы от разрозненных архитектур получить, как правило, не удается. Для этого должны появиться интегрирующие роли: архитектор решений и тот самый корпоративный архитектор. 
Архитектор решений отвечает за результаты работы архитекторов, привлекаемых в рамках конкретного решения (отдельной информационной системы), причем, его должно интересовать все: от бизнес-процессов, в поддержке которых участвует решение, до того, как это решение развернуто. Понятно, что все это ему нужно не в тех деталях как, например, архитектору инфраструктуры, да и не по всей компании. Но то, что касается его решения – нужно. 

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

На этом цикл концептуальных статей про архитектуру можно заканчивать и переходить к самому интересному - к деталям. 

Архитектор, а зачем ты нужен?

Статья подготовлена для корпоративного портала.

Бизнес-правила являются причиной существования программной системы. Они составляют основу функционирования. Они порождают код, который делает или экономит деньги. Они — наши семейные реликвии.
                -- Роберт Мартин

Чем занимаются архитекторы, мы с вами в прошлый раз поговорили, но вот какая от этой деятельности польза? Давайте взглянем на взаимосвязь архитектурных артефактов, предлагаемую Togaf (можно и в модель Захмана посмотреть, и в следующий раз даже посмотрим, но для текущей темы картинка из Togaf нагляднее):
Широта охвата нас пока не интересует, а вот основные домены и уровень погружения в компанию очень даже.

Если взять небольшую компанию или небольшой проект/продукт, то о вопросах архитектуры там говорить сложно, как правило есть некий сотрудник, у которого все в голове. Это может быть основатель стартапа, опытный программист, занимающийся автоматизацией деятельности с основания компании, или еще кто-то. Затраты на поддержание целостной картины минимальны, но и получить плюсы от этих знаний бывает проблематично, особенно когда человек в отпуске или после его ухода из компании. Чтобы подстелить соломку, возникает потребность в документации архитектуры (текущего состояния и принимаемых решений). А вот эта работу уже начинает требовать инвестиций. Пусть на первом этапе и небольших, но кто-то вместо того, чтобы работу работать, начинает заполнять какие-то таблички, строить диаграммы, рисовать схемы. И именно в этот момент наблюдается странный парадокс: затраты видны сразу, а видимость эффекта очень сильно зависит от домена, на котором начинается эта активность.

Когда за работу берутся IT специалисты, - не важно: разработчики, описывающие архитектуру приложений, или системные администраторы, описывающие технологический слой, - то эффекта на первых порах как такового нет. Ну появились какие-то документы, так чем читать описания и разбираться в диаграммах, проще подойти к знающему человеку и спросить у него: т.е. абстрактный архитектор тратит время на фиксацию архитектурных артефактов и, как и раньше, на ответы. Пользы от диаграмм нет. Чтобы польза появилась, команда должна стать достаточно большой или должно пройти значительное время. При большой команде времени архитектора на всех не хватает, и люди вынуждены обращаться к другим источникам знаний. А время расставляет все по местам, помним про отпуска? Что делать, когда знающего человека нет на месте? Правильно: искать документы. А после того, как первый раз получил ответ в документации, второй… Да еще не надо ждать, пока занятый другими коллегами архитектор ответит… Люди начинают этим пользоваться. Бизнес, как правило, эффект не очень видит, но, с точки зрения IT специалистов, наблюдается снижение сложности новых доработок.

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

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

Архитекторы, как и менеджеры, любят матрицы 2 на 2. Не откажу себе в удовольствии и основное содержимое статьи отображу именно в виде такой матрицы:

Главное, не забывайте, что перейти из «Отсутствия архитектуры» в «Корпоративную архитектуру» за один прием не получится. Это долгий процесс, который, возможно, какое-то время будет идти двумя отдельными ветками бизнес- и IT-архитектур с последующим их объединением, а, может быть, и подтягивание недостающей IT-архитектуры к тому, что уже есть в бизнес-архитектуре. У каждой компании в этом процессе может быть свой путь.


Возвращаясь к вопросу, а при чем здесь архитекторы? Как раз при том, что это их задача помочь компании осознать этот путь и объединить разрозненные кусочки информации, которые известны бизнесу, IT, другим заинтересованным лицам в единую картинку, которая в итоге и получит название корпоративная архитектура. О том, какими бывают архитекторы в этом процессе, мы поговорим в другой раз.