IT Заметки. Цифровизируемся.

Хочешь цифровизироваться? Как поступить? На самом деле вариантов не много:

1. Мечта бизнесмена. Купить коробочку, или лучше скачать что-то бесплатное. Это не требует умственных затрат, дешево и быстро. Сотрудники потом сами на рабочем месте разберутся. Вот только эта идиллия разрушается при столкновении с реальностью. Или бизнес-процесс немного не тот, или коробочка не все делает так, как нужно. И начинается процесс долгой настройки. Делается это бессистемно, на коленке и побыстрей. В результате модификация приводит к ошибкам и отказам. Если коробочек несколько, то оказываться, что перенос данных из одного в другой требует сложных ручных алгоритмов. Через несколько лет это всем надоедает и закупается новая коробочка с софтом и все начинается снова.
Метод работал и будет работать, когда бизнес небольшой, быстро не растет и имеет множество стандартных бизнес-процессов (магазин, кафе и т.п), а также в случае автоматизации трудоемких локальных процессов разрабатывать софт для которых слишком затратно (дизайнер, видеомонтажер, архитектор).

2. Инициатива снизу. Найти умного сотрудника, который автоматизирует основные процедуры. У метода один большой плюс - автоматизация не сложного рутинного процесса, для которого нет стандартного коробочного решения. Недостатков много:
- Сотрудников, способных писать не много. Принципы разработки и современные технологии они не знают, в средствах разработки и в обучении они ограничены, самым популярное среди них средство - MS Access.
- Полученная система имеет множество ошибок и ограничений. Бывает невозможно увеличить количество пользователей и количество функций.
Есть недостатки и для сотрудника. Можно быстро достигнуть пределов своих возможностей. Разработка и поддержка ПО начинает занимать все больше времени. В результате сотрудник покидает компанию, так как не имеет сил совмещать два вида деятельности.
10-15 лет назад такая методика цифровизации была распространена. В медленно развивающихся организациях такое ПО работает до сих пор, в других эти модули становятся частью больших информационных систем. Мне кажется, что такая методика цифровизации или умерла или умрет в ближайшее время.

3. Пригласить "варягов". Нанять программиста или группу разработчиков в штат. С точки зрения заказчика, наверное, лучший вариант. Неограниченный доступ к экспертам по бизнес-процессам со стороны команды, возможность контроля со стороны заказчика, оперативная корректировка техзадания. Методика позволяет добиться лучших результатов. Вот только заказчик сам себе все портит:
- Руководство бизнеса должно понимать, что такое разработка программного обеспечения. Традиционная иерархическая система в разработке софта работает плохо. Скрам - лучший вариант для управления, но в обычном бизнесе он применяется редко.
- Не надо экономить. Дешевый или неопытный разработчик пишет плохой код. Бесплатные программные компоненты часто неудобны, работают медленно и содержат много ошибок.
- Жесткие сроки. Непродуманный код - ошибки и проблемы с масштабированием. Особенно это опасно на начальном этапе. Ошибки архитектуры потом крайне сложно исправить.
- Жесткие параметры системы. во-первых, опять проблемы с масштабированием - при изменении условий бизнеса может потребоваться глубокая модернизация системы. Во-вторых, невозможность применения современных средств и практик разработки.
Вот здесь бы и пригодился инициативный рационализатор из второго варианта, он и бизнес знает и немного в разработке ПО разбирается, но его либо выгнали, либо сам ушел. Приходится искать новых, но масса профессионалов уже сталкивались с такой ситуацией и не спешат повторения. Придется выбирать из неопытных, которые не прошли эту школу.

4. Нанять. Оптимальный вариант для разработчиков. Попадает заказчик, так как большой риск получить не то, что заказывал. Причин этого много:
- Заказчик и разработчик не могут написать техническое задание, или ТЗ написано с ошибками. Заказчик раздражается, что разработчик спрашивает о какой-то мелочи, а разработчик раздражается, что заказчик не дает нужную информацию. Проблема в психологии: заказчик думает типовыми (наиболее вероятными) процессами, но при разработке надо лучше учесть все варианты. Может этот случай один из 1000, но если он приведет к краху в самый ответственный момент, то кому-то будет сильно неприятно! Знание исключений хорошо сказывается на масштабировании системы в будущем.
- Разработчик продает типовой продукт. Берется типовой продукт и адаптируется под заказчика. Экономя ресурсы адаптируются и бизнес-процессы заказчика, и сам продукт. - Используемая для разработки "базовая" система очень редкая и поддерживать ее может только разработчик. Результат - вечное общение с разработчиком.
- Заказчику сложно выбрать разработчика. У всех разработчиков отличные сайты, все кому-то что-то делали (и даже некоторые были довольны).

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

IT заметки. Иерархия.

Иерархия встречается часто в реляционных базах данных. Структуры административного деления стран, организационная структура или документооборот по договору - древовидные графы.
Распространенной практикой является хранение сущностей одного уровня иерархии в отдельных таблицах. К примеру, административное деление страны будет иметь три таблицы Страна, Регион и Город. Эта методика хорошо работает пока к сущностям (город, регион, страна) не потребуется привязать какие-то однородные данные (статистику по населению, ВВП и т.п.) или дерево получает еще один сущностный уровень.
Конечно, статистику можно хранить в  XML или JSON самих записей, но это сильно увеличит размер записи и потребует дополнительного индексирования, усложнит ее обработку. Правильнее было сложить статистику в отдельную таблицу, чтобы не увеличивать размер записи и увеличивать время обращения к статистике. Если каждый сущностный уровень хранится в отдельной таблице, то нужно делать отдельные статистические таблицы (для страны, региона, города) или пользоваться полиморфными связями (это когда поле вторичного ключа связано с полем первичного ключа нескольких таблиц). Оба варианта затратны и сложны в масштабировании.
Решить эту задачу поможет хранение иерархии в одной таблице. Известно много вариантов хранения древовидных структур данных в одной таблице. MS SQL Server предлагает типовое решение. Оно появилось ещё в MS SQL Server 2008 R2, но его описание почти не встречается в литературе по MS SQL. Удобен он тем, что для поиска пути от корня к текущему элементу не надо проходить промежуточные узлы по таблице. Речь идет о HIERARCHYID.
HIERARCHYID - системный тип данных для положения представления в иерархии. В нем кодируется путь от корня дерева к узлу. Хранится путь в двоичном виде. Для удобства есть функция ToString(), которая возвращает текстовое представление:
'/' - корень дерева,
'/1/', '/2/' - 1-ый и 2-ой потомки корня
'/1/2/', '/2/1/', '/2/2/' - 2-ой потомок 1-ого потомка корня, 1-ый и 2-ой потомок 2-ого потомка корня.
При операции INSERT можно пользоваться текстовым написанием HIERARCHID, что может сильно упростить множественную вставку, так как IDENTITY не поддерживается и приходится генерировать ключи уровня руками.
Основные функции:
::GetRoot() - возвращает корень (статический метод),
.GetAncestor(N) - возвращает предка N-ого уровня,
.GetDescendant(HID1, HID2) - позволяет вставить узел до HID2, после HID1 или между ними.
.GetLevel() - возвращает глубину узла в дереве,
.IsDescendantOf(HID1) - возвращает true, если элемент (this) является потомком HID1,
.Parse(STR) - переводит STR в HIERARCHID,
.GetReparentedValue(HID1, HID2) - переносит элемент от элемента HID1 к элементу HID2,
.ToString() - преобразует HIERARCHID в текст.

IT заметки. Методы хранения данных в реляционной базе данных.

При разработке реляционных баз данных встречаются ситуации, когда неизвестно количество полей записи или их слишком много и заполнены они не полностью. Лет 20 назад типовым вариантом было создать таблицу заголовков и таблицу, хранящую название или ID названия переменной и ее значение (далее ключ/значение). В современных базах появилась возможность хранения строк в XML и JSON. Я решил попробовать все четыре варианта хранения и сравнить их.

Параметры теста:
Источником данных послужила таблица со сгенерированными записями с 11 значащими полями: 5 числовых, 3 битовых, 3 строчных. В одном дополнительном поле лежало целочисленное ID типа, которое просто копировалось в соответствующее поле во всех вариантах хранения.  Первичный ключ типа BIGINT, генерировался с помощью IDENTITY.

Операции:
• INSERT из таблицы источника (для варианта ключ/значение использовался курсор),
• SELECT из полученной в таблицу со структурой, совпадающей с таблицей источником,
• INSERT в таблицу с помощью курсора.

Варианты хранения:
• Обычное хранение в полях,
• JSON в строке NVARCHAR(2000),
• XML используя тип XML,
• Таблица ключ/значение (были добавлены вторичные ключи и некластеризованный индекс по ID величины и ID записи).

Количество данных в операции:
• От 20 до 80 тыс. записей. С шагом в 20 тыс.

Задержка после каждой операции:
• 2 секунды.

Количество попыток:
• 6.

Программное обеспечение:
• MS SQL Server 2017 Express, Windows 10.

Аппаратное обеспечение:
• ASUS GL533VD Intel i7-7700HQ 2.8 GHz, 12 GByte RAM, 500 GByte, SSD Samsung 970 EVO PCI.

Анализ результатов:

• После нескольких запусков теста было отмечено, что первая операция INSERT, шедшая после операций над обычной таблицей, с таблицами JSON или XML выполнялась значительно дольше остальных тестов. На попытках 2-6 такого не отмечалось. Поэтому из расчета первая попытка была исключена. Предполагаю, что увеличение первой операции INSERT для JSON или XML связано с загрузкой MS SQL Server дополнительных библиотек работы с XML и JSON.

• При просмотре данных до усреднения было замечено, что MS SQL Server от попытки к попытке, которые выполнялись в цикле) увеличивает время исполнения оператора. Рост небольшой – доли процента, но надо знать, что такое возможно.

• INSERT
График зависимости времени выполнения (мс) от размера пакета записей для оператора INSERT

Вариант хранения ключ/значение – худший вариант, хранение в полях таблицы – лучший вариант. Время обработки увеличивается более, чем в 80 раз, при увеличении записей время выполнения растет быстрее остальных вариантов.
Если выбирать XML или JSON, то JSON. Относительно стандартного метода хранения JSON будет только в два раза медленнее.

• SELECT
График зависимости времени выполнения (мс) от размера пакета записей для оператора SELECT

Самый медленный SELECT… для XML. По быстроте выполнения JSON опять второй после стандартного хранения. Странно, но и при росте количества записей в операции время исполнения растет быстрее, чем для всех остальных операций.

• CURSOR
График зависимости времени выполнения (мс) от размера пакета записей для оператора CURSOR

Не зря во всех учебниках не рекомендуют использовать курсоры. По сравнению с INSERT для обычной таблицы JSON и XML время выполнения увеличится от 8 до 30 раз. Но практика показывает, что замена INSERT курсором может сократить количество ошибок исполнения и времени исполнения при обращении к удаленному серверу. MS SQL Server любит загрузить с начала все данные по SELECT в память, а затем выполнить INSERT. Если это в одной базе, то получим кеширование на диск, если данные переносятся с другого сервера, то можно напороться на потерю данных и ошибку.
Что касается технологии хранения, то лучшая скорость выполнения операций у стандартной технологии хранения. Вторая по скорости - JSON, она хуже только на 5%.

Другие выявленные особенности:

• Для JSON важен размер строки, в котором хранятся данные. Если размер NVARCHAR будет 2000 символов, то JSON в операции INSERT будет на 1,81 раза медленнее стандартного хранения, если ограничения нет, то уже 3,4.  Для операции SELECT в 6 и 12 раз соответственно. Для курсоров размер поля не играет практически никакого значения.

• Относительная разница в скорости между технологиями слабо зависит от размера набора данных.

В сухом остатке – если есть возможность храните данные в полях, если нет – формат JSON. XML и таблицы ключ/значение лучше избегать.

Ссылка на проект.

Грузия. 2017. Тбилиси. Ботанический сад.

Немного весенней Грузии и очередной ботанический сад в ленту. Конец марта в Тбилиси напоминает конец мая в средней полосе России. Что-то уже начинает цвести, но листьев на деревьях еще нет.
Тбилисский ботанический сад основан в 1845 году на месте древних садов принадлежащих царскому дому Грузии. Расположился в долине реки Легва-Хеви за крепостью Наринкала и монументом Мать Грузия.

Вид на восточную часть сада с улицы Солонаки.

Речка.

И на скалах цветут деревья.

---

Мать Картли

Оплетенные лианами деревья.

Мост через реку Цавкисисцкали.

Бамбуковая роща. Самое зеленое место в саду.

---

---

Японский сад с небольшим водопадиком.

Дорожка в глубь сада.

Кипарисы.

Беседка над обрывом.

Это растение с желтыми цветами в огромном количестве растет на склонах Мтацминды.

Тут, видимо, предполагались клумбы с цветами, но мы рано пришли.

---

Водопад .

---

Пальмы.

---

Сова.

Маки.

И на скалах растут деревья.

---

Суккуленты

Ажурный мостик под Наринкала перед входом в квартал бань Абанотуани.

Россия. 2016. Санкт-Петербург. Красин.

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

Первым ледоколом арктического класса в Российской империи стал "Ермак".  После тестовой эксплуатации "Ермака" было принято решение о строительстве целого семейства паровых ледоколов для работы на Балтике  и прибрежных водах северной границы России. Первым ледоколом обновленной серии стал "Тармо"(современное название судна), который сохранился и стоит на стоянке в Хельсинки. Об одном из ледоколов этого семейства, я уже рассказывал в 2015 году - это "Сур Тылль" из таллинского морского музея.  В России сохранился последний ледокол из серии - "Святогор", более известный сейчас под названием "Красин". Он стоит в Санкт-Петербурге. Но не пытайтесь найти похожие черты между "Сур Тылль" и "Красиным", в 1950 году судно прошло капитальный ремонт в ГДР и сильно изменило свой облик.
Ледокол, был построен в 1917 году, как и все ледоколы этой серии, за рубежом. Российское правительство тогда решило, что так дешевле. В марте 1917 его спустили на воду в английском городке Ньюкасл. В сентябре 1917 судно окончательно достроили и оно вошло в состав флотилии Северного Ледовитого океана.
Первый этап жизни "Святогора" длился недолго, уже в 1918 году он был затоплен недалеко от Архангельска, но англичане подняли его и увели в 1920 году в Англию. В 1921 году советское правительство предложило выкупить ледокол за 75 тыс. фунтов (общая стоимость корабля была 375 тыс. фунтов стерлингов). Благодаря торгпреду Красину и кораблестроителю Крылову это удалось сделать в 1922 году.
"Красин" трудился ледоколом до 1972 года, затем его передали в морскую арктическую геологоразведочную экспедицию, где он служил до 1989 года уже в качестве научно-исследовательского судна. Сейчас на судне музей.

Ледокол у причала. В 2016 году за ледоколом стояла плавучая атомная электростанция (полосатая коричнево-желтая махина на заднем плане).

На судне проходят экскурсии. Все по расписанию. Нам повезло - попали на последнюю перед праздниками.

Вывеска. Удивительно, но ледокол является филиалом калининградского музея мирового океана.

Фонарь.

Заветный вход в музей, но сначала осмотрим палубу.

Запасной якорь.

Настил палубы.

Рында

Кран.

Надстройка.

"Голова боцмана".

---

Средства спасения левого борта.

Нос. Прямо "по курсу" здание Горного института.

Крыша машинного отделения.

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

Корма. Через это "ушко" протягивают трос для буксировки судов.

Палуба верхнего борта. На дальнем плане - вход в машинное отделение.

Прожектор для освещения кормы.

Первый зал музея. Элементы с поднятой подводной лодки и рассказ о ней.

Нижняя палуба надстройки. На нашей экскурсии прошлись только по надстройке. Есть экскурсия в машинное отделение. Каждая экскурсия оплачивается отдельно и стоит около 500 руб на человека, что недешево. Меня задушила жаба и мы не пошли. Как выглядит машинное отделение до кап. ремонта можно посмотреть в моем посте про "Сур Тылль". На эстонском экспонате вообще больше помещений доступно для осмотра.

Трап на верх.

Кают-компания.

Раритетный плафон.

Стол в кают-компании с делениями, чтобы не ездила посуда при качке.

Вид из окна офицерской кают-компании.

Письменный стол в каюте капитана.

Койка капитана.

Санузел.

Стол штурмана.

Средство связи.

Хронометры и некоторые навигационные приборы.

Устройство для указания курса и расписания вахт на кораблях с неграмотными матросами.

Наверху - сфера гирокомпаса, снизу радиостанция (?)

Наш экскурсовод на ходовом мостике. Экскурсию провел интересную.

Пульт управления судовыми огнями

со смешным названием Елка.

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

Кресло капитана.

Машинный телеграф левого борта.

Пожарная сигнализация.

Корабельный спидометр :) Лаг.

Кстати, о первом ледоколе серии "Ермак". Ледокол усердно трудился на благо Российской империи и Социалистической Родины до 1963 года, когда был списан и разрезан на металл, что жалко.