Архив за месяц: Апрель 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. 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 + ,):


Обработка 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:
После этого можем включить предварительный просмотр:
В режиме разделенного редактора в правой части будет виден результирующая презентация (напоминаю, все картинки кликабельны):

Пара замечаний:
marp: true
Используется, для пометки что мы используем 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:
После этого можем включить предварительный просмотр:
В режиме разделенного редактора в правой части будет виден результирующая презентация (напоминаю, все картинки кликабельны):

Пара замечаний:
marp: true
Используется, для пометки что мы используем 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:
После этого можем включить предварительный просмотр:
В режиме разделенного редактора в правой части будет виден результирующая презентация (напоминаю, все картинки кликабельны):

Пара замечаний:
marp: true
Используется, для пометки что мы используем 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 домена: бизнес деятельность, данные, приложения и технологии. При этом, ничто не мешает думать про корпоративную архитектуру в тех же уровнях детализации: от контекстного, через концептуальный и логический, к физическому и непосредственной реализации. В этом случае получится следующая модель (картинки кликабельны): 
На этой модели уже будет удобно обсудить, кто и за что отвечает. Большинство архитекторов находятся на трех верхних уровнях, и различаются названием доменом с которым работают. На двух последних уровнях чаще говорят уже про исполнителей: 
До такого разделения на зоны ответственности, может, не с выделением всех ролей, большинство компаний доходит достаточно быстро, но, как мы обсуждали в прошлой статье, максимальной пользы от разрозненных архитектур получить, как правило, не удается. Для этого должны появиться интегрирующие роли: архитектор решений и тот самый корпоративный архитектор. 
Архитектор решений отвечает за результаты работы архитекторов, привлекаемых в рамках конкретного решения (отдельной информационной системы), причем, его должно интересовать все: от бизнес-процессов, в поддержке которых участвует решение, до того, как это решение развернуто. Понятно, что все это ему нужно не в тех деталях как, например, архитектору инфраструктуры, да и не по всей компании. Но то, что касается его решения – нужно. 

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

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

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

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

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

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

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



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

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

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

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

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