Я давно занимаюсь Enterprise-программированием и мне часто приходится иметь дело со сложными бизнес-правилами. Так что решить такую простую задачку, как FizzBuzz, для меня будет несложно.
Я хочу у вас спросить, как у специалиста по FizzBuzz: какое ваше мнение по поводу моего решения для FizzBuzz? Если бы я у вас собеседовался и представил свое решение этой задачи. Удовлетворяет ли оно вашим требованиям?
Теперь само решение:
Сначала проведем анализ задачи и представим логику получения результата для числа N в виде таблицы решений:
+---------------------------------+-----------------+
| Conditions | Actions |
+----------------+----------------+-----------------+
| N is divisible | N is divisible | What to print |
| by 3 | by 5 | |
+================+================+=================+
| Yes | Yes | 'FizzBuzz' |
| +----------------+-----------------+
| | No + 'Fizz' |
+----------------+----------------+-----------------+
| No | Yes | 'Buzz' |
| +----------------+-----------------+
| | No + N |
+----------------+----------------+-----------------+
Теперь напишем реализацию таблицы решений на языке Python:
'''
FizzBuzz demonstration
'''
def fizz_buzz(n):
''' Evaluate FizzBuzz for the given n '''
isDivBy3 = n%3 == 0
isDivBy5 = n%5 == 0
if(isDivBy3 and isDivBy5):
result = 'FizzBuzz'
elif(isDivBy3 and not isDivBy5):
result = 'Fizz'
elif(not isDivBy3 and isDivBy5):
result = 'Buzz'
elif(not isDivBy3 and not isDivBy5):
result = str(n)
else:
raise Exception(f'Error processing number {n}')
return result
max_number = 100
for n in range(1, max_number + 1):
print(fizz_buzz(n))
Это напоминает мне прохождение ежегодного техосмотра машины в Голландии. Он у нас обязательный и для его успешного прохождения надо устранить все неисправности.
Лет 15 назад я прочитал статью в журнале общества автолюбителей. Они провели эксперимент: взяли машину, для которой были точно известны все ее неисправности, и отдали ее для прохождения техосмотра в 100 разных автосервисов. Результат: в большинстве гаражей нашли несуществующие неисправности и взяли деньги за их устранение.
То-то я удивлялся, что у меня каждый раз при прохождении техосмотра у дилера находили кучу проблем. Потом друзья посоветовали честный автосервис и я сразу стал платить меньше.
Я работаю с PowerDesigner много лет, и это действительно очень мощный инструмент. До этого я использовал Microsoft Visio, но он обладает меньшими возможностями.
Два года назад у меня была возможность поработать в крупном проекте где используется PowerDesigner, в банке De Volksbank (четвертый по величине банк в Голландии). PowerDesigner там является стандартным инструментом моделирования баз данных.
PowerDesigner имеет как свои достоинства, так и недостатки.
2 Преимущества
Что нравится лично мне?
2.1 Поддержка многих типов моделей
Для проектирования БД в основном используются логическая и физическая модели, но есть также множество других типов моделей.
2.2 Поддержка Reverse Engineering
Можно подкючитья к уже существующей базе данных, прочитать ее метаданные и на их основе создать модель.
2.3 Поддержка больших моделей
Диаграмму, состоящую из большого числа таблиц (например, нескольких сотен), можно разбить на несколько диаграмм меньшего размера (которые при этом все входят в одну модель).
2.4 Поддержка разных баз данных
Поддержка многих типов баз данных (например, в банке De Volksbank используется Teradata) и генерация скриптов создания БД для них.
2.5 Возможность валидации
Например, контроль наличия первичных ключей у всех таблиц, обнаружение аномальных связей между таблицами и т.д. (десятки разных проверок). Можно добавлять свои собственные валидации.
2.6 Возможность автоматизации
Очень мощная черта PowerDesigner - это возможность его расширения, добавления новой функциональности.
Например, можно добавить новый атрибут к таблице базы данных. Затем добавить поле для редактирования этого атрибута на соответствующую форму GUI. Затем добавить код, который на основе значения этого атрибута выполняет какое-то действие. Например, генерирует файл с кодом для создания хранимой процедуры. Или выполняет для этой таблицы какую-нибудь специфическую валидацию.
Код пишется на языке VBScript. Текст (например, код хранимой процедуры) можно сгенерировать на основе шаблона. Шаблоны создаются при помощи специального языка разметки GTL (Generation Template Language). Из VBScript, как и из GTL, есть доступ к объектной модели, содержащей метаданные разрабатываемой базы данных.
Одна маленькая, да удаленькая голландская компания разработала по заказу банка плагин для упрощения работы с их хранилищами данных (data warehouses). В банке использовались би- и тритемпоральные базы данных, в которых хранилась полная история изменений всех данных (для проектирования этих баз, по крайней мере некоторых, использовался паттерн проектирования Data Vault). Нужно было обеспечить получение информации по состоянию на любой конкретный момент времени в прошлом, по запросу пользователей.
Это было реализовано в виде плагина для PowerDesigner. Разработчики баз данных при создании моделей добавляли в них дополнительную метаинформацию для таблиц и баз данных. После этого можно было сгенерировать код для автоматического создания всей необходимой инфраструктуры - таблиц для хранения промежуточных данных, представлений (view), хранимых процедур и т.д.
Этот плагин был впечатляющим продуктом (я немного поучаствовал в его разработке).
3 Недостатки
3.1 Контроль версий
Описание модели хранится в одном большом XML-файле. Из-за этого очень неудобно контролировать изменения с использованием системы контроля версий (например, Git). Особенно когда несколько человек работают с одной и той же моделью (проблемы с merge).
Вышеупомянутая компания частично решила этот вопрос, создав инструмент под названием DeComposer. С его помощью можно разбить файл модели на множество мелких XML-файлов (а также собрать все эти отдельные файлы обратно в один файл). Скажем, определение каждой таблицы базы данных сохраняется в своем файле и т.д. После чего все эти отдельные файлы можно сохранить в системе контроля версий.
Процесс работы с моделью при этом выглядит так:
Выгрузить все файлы из системы контроля версий
Собрать файл модели при помощи DeComposer
Поработать с моделью
Разбить файл модели на отдельные файлы при помощи DeComposer
3.2 Трудности программирования
Объектная модель для представления метаданных базы данных (таблицы, их колонки, связи между таблицами и т.д.) усложненная и запутанная.
Программирование возможно только на языке VBScript, который совершенно примитивен. В документации где-то упоминается, что можно также использовать C#, но я не смог найти никакой информации по этому поводу.
Нет отладчика.
Сам процесс программирования непонятный и запутанный. С одной стороны, пишутся отдельные скрипты на VBScript и шаблоны на языке GTL. Потом эти разрозненные кусочки кода хитрым образом компонуются вместе путем конфигурирования в специальном визуальном редакторе. С другой стороны, дополнительные атрибуты, элементы GUI и др. не программируются, а конфигурируются в этом же редакторе (то, что сейчас называется No Code). Пока с этим разберешься, голову можно сломать. Эта методика при этом обеспечивает меньшую гибкость, чем давало бы использование обычного традиционного программирования.
Так что написание вышеупомянутого плагина было в некотором роде подвигом (учитывая его сложность).
3.3 Ручные действия
Валидация модели и генерация кода (скрипт создания базы данных и др.) производится вручную (путем выбора пункта из меню), то есть нельзя встроить это в процессы CI/CD.
3.4 Плохая поддержка
PowerDesigner в последние годы практически не развивается (наверное, из-за того, что SAP - очень большая и неповоротливая компания). Служба поддержки возникающие проблемы решает тоже очень медленно.
4 Заключение
Резюмируя вышесказанное: PowerDesigner - инструмент очень мощный, но расширять и автоматизировать его очень неудобно.
Я задумывался о том, чтобы разработать свой инструмент для проектирования баз данных, лишенный этих недостатков.
Этот инструмент должен по крайней мере поддерживать следующую функциональность:
XML не подходит для описание моделей. Вместо этого лучше разработать специализированный DSL (Domain Specific Language). При этом описание модели можно разбивать на отдельные файлы. Например, описание каждой таблицы хранить в отдельном файле подобно тому как при написании кода на C# или Java мы помещаем код каждого класса в отдельный файл.
Удобная для использования объектная модель для представления метаданных базы данных. Это я уже разработал (по другому поводу) с использованием C#.
Использование более мощного языка для программирования расширений вместо VBScript (например, C#).
Все действия (валидация, генерация) должны выполняться из командной строки для облегчения интеграции с CI/CD.
Но пока из-за отсутствия и финансирования, и свободного времени пришлось этот проект отложить.
Не знаю, как в вашей стране, а у нас в Голландии COBOL до сих пор используется достаточно широко.
Что я видел сам:
1999 - Авиакомпания KLM. К счастью, мне самому не пришлось там сталкиваться с COBOL-ом - я писал на другом устаревшем языке - PL-1. Там же использовалась и СУБД IMS, разработка IBM родом из 1960-х годов.
Кстати, в конце 1990х годов KLM рассматривала возможность использования системы планирования полетов других авиакомпаний вместо своей. Одна из кандидаток - система одной из американских авиакомпаний родом из 1960-х, написанная на FORTRAN вообще без использования СУБД (все данных хранились в файлах).
2010 - Центробанк. Прямо-таки заповедник COBOL.
2017 - Металлургический комбинат Tata Steel. Основная программа, собственная ERP-cистема для управления всем производством (на первом уровне согласно 5-уровневой архитектуре управления индустриальными процессами), написана на COBOL. (Там, правда, еще использовались Java и Python, но основная часть реализована на COBOL). Там же использовалась и СУБД IMS.
Сейчас COBOL все еще широко используется в банках, страховых компаниях, крупных предприятиях типа Gasuine (местный "Газпром").
Сейчас заглянул в LinkedId - в Голландии 64 открытых вакансий по COBOL. Довольно много для такого устаревшего языка.
Кстати, в Голландии в 2000-х годах увеличились продажи мейнфреймов.
Чтобы написать книгу (техническую), не нужно знать язык очень хорошо. Гораздо важнее иметь, что сказать. Я в 2000 году написал много документации на работе и несколько статей по программированию на голландском, хотя знал этот язык в то время довольно посредственно. После исправления грамматических ошибок редактором (имеется в виду человек) статьи были опубликованы в журнале нашей компании.
Я не думаю, что эта статья выйдет в каком-либо серьезном журнале, потому что она не отвечает принятым стандартам. У меня вызывает большие сомнения возможность реализации сверхпроводимости в соединении с такой формулой.
.
Да
Это сделано специально. Догадываетесь почему?
Я давно занимаюсь Enterprise-программированием и мне часто приходится иметь дело со сложными бизнес-правилами. Так что решить такую простую задачку, как FizzBuzz, для меня будет несложно.
Я хочу у вас спросить, как у специалиста по FizzBuzz: какое ваше мнение по поводу моего решения для FizzBuzz? Если бы я у вас собеседовался и представил свое решение этой задачи. Удовлетворяет ли оно вашим требованиям?
Теперь само решение:
Сначала проведем анализ задачи и представим логику получения результата для числа N в виде таблицы решений:
Теперь напишем реализацию таблицы решений на языке Python:
Что вы думаете по поводу моего решения?
.
Это напоминает мне прохождение ежегодного техосмотра машины в Голландии. Он у нас обязательный и для его успешного прохождения надо устранить все неисправности.
Лет 15 назад я прочитал статью в журнале общества автолюбителей. Они провели эксперимент: взяли машину, для которой были точно известны все ее неисправности, и отдали ее для прохождения техосмотра в 100 разных автосервисов. Результат: в большинстве гаражей нашли несуществующие неисправности и взяли деньги за их устранение.
То-то я удивлялся, что у меня каждый раз при прохождении техосмотра у дилера находили кучу проблем. Потом друзья посоветовали честный автосервис и я сразу стал платить меньше.
Точно, с полом не все так просто. Вот, например, как определены коды для пола в стандарте ISO-5218 Representation of human sexes:
А в базах данных американского ФБР (Федеральное бюро расследований) используются следующие коды:
Информация взята из книги Ханс Ладани "SQL. Энциклопедия пользователя", 1998 год, издательство "Диасофт".
.
Замена ENUM на внешний ключ не влияет на нормализацию аж никак. Иными словами, в какой нормальной форме была таблица, в той и осталась.
Статья не имеет никакого отношения к нормализации.
Не требует. Но удобнее завести отдельную таблицу.
1 Введение
Я работаю с PowerDesigner много лет, и это действительно очень мощный инструмент. До этого я использовал Microsoft Visio, но он обладает меньшими возможностями.
Два года назад у меня была возможность поработать в крупном проекте где используется PowerDesigner, в банке De Volksbank (четвертый по величине банк в Голландии). PowerDesigner там является стандартным инструментом моделирования баз данных.
PowerDesigner имеет как свои достоинства, так и недостатки.
2 Преимущества
Что нравится лично мне?
2.1 Поддержка многих типов моделей
Для проектирования БД в основном используются логическая и физическая модели, но есть также множество других типов моделей.
2.2 Поддержка Reverse Engineering
Можно подкючитья к уже существующей базе данных, прочитать ее метаданные и на их основе создать модель.
2.3 Поддержка больших моделей
Диаграмму, состоящую из большого числа таблиц (например, нескольких сотен), можно разбить на несколько диаграмм меньшего размера (которые при этом все входят в одну модель).
2.4 Поддержка разных баз данных
Поддержка многих типов баз данных (например, в банке De Volksbank используется Teradata) и генерация скриптов создания БД для них.
2.5 Возможность валидации
Например, контроль наличия первичных ключей у всех таблиц, обнаружение аномальных связей между таблицами и т.д. (десятки разных проверок). Можно добавлять свои собственные валидации.
2.6 Возможность автоматизации
Очень мощная черта PowerDesigner - это возможность его расширения, добавления новой функциональности.
Например, можно добавить новый атрибут к таблице базы данных. Затем добавить поле для редактирования этого атрибута на соответствующую форму GUI. Затем добавить код, который на основе значения этого атрибута выполняет какое-то действие. Например, генерирует файл с кодом для создания хранимой процедуры. Или выполняет для этой таблицы какую-нибудь специфическую валидацию.
Код пишется на языке VBScript. Текст (например, код хранимой процедуры) можно сгенерировать на основе шаблона. Шаблоны создаются при помощи специального языка разметки GTL (Generation Template Language). Из VBScript, как и из GTL, есть доступ к объектной модели, содержащей метаданные разрабатываемой базы данных.
Одна маленькая, да удаленькая голландская компания разработала по заказу банка плагин для упрощения работы с их хранилищами данных (data warehouses). В банке использовались би- и тритемпоральные базы данных, в которых хранилась полная история изменений всех данных (для проектирования этих баз, по крайней мере некоторых, использовался паттерн проектирования Data Vault). Нужно было обеспечить получение информации по состоянию на любой конкретный момент времени в прошлом, по запросу пользователей.
Это было реализовано в виде плагина для PowerDesigner. Разработчики баз данных при создании моделей добавляли в них дополнительную метаинформацию для таблиц и баз данных. После этого можно было сгенерировать код для автоматического создания всей необходимой инфраструктуры - таблиц для хранения промежуточных данных, представлений (view), хранимых процедур и т.д.
Этот плагин был впечатляющим продуктом (я немного поучаствовал в его разработке).
3 Недостатки
3.1 Контроль версий
Описание модели хранится в одном большом XML-файле. Из-за этого очень неудобно контролировать изменения с использованием системы контроля версий (например, Git). Особенно когда несколько человек работают с одной и той же моделью (проблемы с merge).
Вышеупомянутая компания частично решила этот вопрос, создав инструмент под названием DeComposer. С его помощью можно разбить файл модели на множество мелких XML-файлов (а также собрать все эти отдельные файлы обратно в один файл). Скажем, определение каждой таблицы базы данных сохраняется в своем файле и т.д. После чего все эти отдельные файлы можно сохранить в системе контроля версий.
Процесс работы с моделью при этом выглядит так:
Выгрузить все файлы из системы контроля версий
Собрать файл модели при помощи DeComposer
Поработать с моделью
Разбить файл модели на отдельные файлы при помощи DeComposer
3.2 Трудности программирования
Объектная модель для представления метаданных базы данных (таблицы, их колонки, связи между таблицами и т.д.) усложненная и запутанная.
Программирование возможно только на языке VBScript, который совершенно примитивен. В документации где-то упоминается, что можно также использовать C#, но я не смог найти никакой информации по этому поводу.
Нет отладчика.
Сам процесс программирования непонятный и запутанный. С одной стороны, пишутся отдельные скрипты на VBScript и шаблоны на языке GTL. Потом эти разрозненные кусочки кода хитрым образом компонуются вместе путем конфигурирования в специальном визуальном редакторе. С другой стороны, дополнительные атрибуты, элементы GUI и др. не программируются, а конфигурируются в этом же редакторе (то, что сейчас называется No Code). Пока с этим разберешься, голову можно сломать. Эта методика при этом обеспечивает меньшую гибкость, чем давало бы использование обычного традиционного программирования.
Так что написание вышеупомянутого плагина было в некотором роде подвигом (учитывая его сложность).
3.3 Ручные действия
Валидация модели и генерация кода (скрипт создания базы данных и др.) производится вручную (путем выбора пункта из меню), то есть нельзя встроить это в процессы CI/CD.
3.4 Плохая поддержка
PowerDesigner в последние годы практически не развивается (наверное, из-за того, что SAP - очень большая и неповоротливая компания). Служба поддержки возникающие проблемы решает тоже очень медленно.
4 Заключение
Резюмируя вышесказанное: PowerDesigner - инструмент очень мощный, но расширять и автоматизировать его очень неудобно.
Я задумывался о том, чтобы разработать свой инструмент для проектирования баз данных, лишенный этих недостатков.
Этот инструмент должен по крайней мере поддерживать следующую функциональность:
XML не подходит для описание моделей. Вместо этого лучше разработать специализированный DSL (Domain Specific Language). При этом описание модели можно разбивать на отдельные файлы. Например, описание каждой таблицы хранить в отдельном файле подобно тому как при написании кода на C# или Java мы помещаем код каждого класса в отдельный файл.
Удобная для использования объектная модель для представления метаданных базы данных. Это я уже разработал (по другому поводу) с использованием C#.
Использование более мощного языка для программирования расширений вместо VBScript (например, C#).
Все действия (валидация, генерация) должны выполняться из командной строки для облегчения интеграции с CI/CD.
Но пока из-за отсутствия и финансирования, и свободного времени пришлось этот проект отложить.
.
.
А ссылку дать можете?
Это не тот Серл. В статье упоминается Джордж, и диск изобрел Джон.
Не знаю, как в вашей стране, а у нас в Голландии COBOL до сих пор используется достаточно широко.
Что я видел сам:
1999 - Авиакомпания KLM. К счастью, мне самому не пришлось там сталкиваться с COBOL-ом - я писал на другом устаревшем языке - PL-1. Там же использовалась и СУБД IMS, разработка IBM родом из 1960-х годов.
Кстати, в конце 1990х годов KLM рассматривала возможность использования системы планирования полетов других авиакомпаний вместо своей. Одна из кандидаток - система одной из американских авиакомпаний родом из 1960-х, написанная на FORTRAN вообще без использования СУБД (все данных хранились в файлах).
2010 - Центробанк. Прямо-таки заповедник COBOL.
2017 - Металлургический комбинат Tata Steel. Основная программа, собственная ERP-cистема для управления всем производством (на первом уровне согласно 5-уровневой архитектуре управления индустриальными процессами), написана на COBOL. (Там, правда, еще использовались Java и Python, но основная часть реализована на COBOL). Там же использовалась и СУБД IMS.
Сейчас COBOL все еще широко используется в банках, страховых компаниях, крупных предприятиях типа Gasuine (местный "Газпром").
Сейчас заглянул в LinkedId - в Голландии 64 открытых вакансий по COBOL. Довольно много для такого устаревшего языка.
Кстати, в Голландии в 2000-х годах увеличились продажи мейнфреймов.
Чтобы написать книгу (техническую), не нужно знать язык очень хорошо. Гораздо важнее иметь, что сказать. Я в 2000 году написал много документации на работе и несколько статей по программированию на голландском, хотя знал этот язык в то время довольно посредственно. После исправления грамматических ошибок редактором (имеется в виду человек) статьи были опубликованы в журнале нашей компании.
А пока физики выражают сомнения:
Источник: https://nplus1.ru/news/2023/07/27/superconductivity-at-room-temperature-but-is-it-real
Я и не знал, что Владимир Владимирович интересуется вопросами сверхпроводимости :-)