Сложности и особенности работы в едином проекте ГГИС

П.В. Яковлев — ведущий программист ООО «Майкромайн Рус».





В наше время, когда цифровые технологии распространены повсеместно и призваны сделать наш быт и работу проще, до сих пор встречаются ситуации, когда из-за этих же технологий нам приходится сталкиваться с определенными трудностями, так как человеческие потребности растут значительно быстрее, чем развиваются компьютерные мощности, поэтому приходится работать с теми компьютерными ограничениями, которые мы имеем на данный момент. Однако еще довольно-таки часто можно увидеть, что на производствах вся база данных ведется в виде файлов Excel, и люди только собираются переходить на такие системы управления базами данных как Access, MS SQL или Oracle. Сама по себе база данных подразумевает тщательно продуманную иерархию таблиц, в которой будет храниться вся необходимая информация. Такая структура данных позволяет избегать путаницы, которая возникает периодически при работе с файлами. В отличие от файлов, когда рабочий процесс выстраивается по правилу «кто первый встал, того и тапки», базу данных могут редактировать сразу несколько человек. Это очень удобный инструмент при работе с большим объемом данных. Однако, несмотря на все свои прелести и удобства, базы данных имеют и минусы.

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

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

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

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

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

При определенной настройке скрипт запускается непосредственно при старте программы, что позволяет пользователю сразу увидеть, какие изменения произошли в файловой структуре сетевого проекта. В качестве сетевого проекта можно самому задать любой доступный каталог. Если каталог уже был задан ранее, то он автоматически используется в качестве каталога по умолчанию. На вкладке Изменения скрипт отображает все файлы, которые были созданы, изменены или удалены. В отчете указываются имя файла, его статус, тип и дата изменения. Типы файлов настроены на основные типы внутренних файлов Micromine. В случае, если необходимо распознавание других файлов, то пользователь может это легко настроить. Скрипт позволяет открывать более старые отчеты по дате его создания. Число хранимых отчетов также задается пользователем. По умолчанию оно равняется 30 отчетам. Далее пользователь может выбрать файлы, который он желает скопировать в свой локальный проект.

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

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

Стоит отметить, что новая версия Micromine 2016 уйдет от поддержки какой-то конкретной версии языка Python, как это было раньше, когда сначала поддерживалась только версия 3.3.1, потом только 3.3.4. В грядущей версии будет поддерживаться все линейка версия Python 3.3. Это означает, что переход на новую версию Micromine не подразумевает никаких сложностей с настройкой Python и всех дополнительно установленных и скачанных модулей. Процесс установки модулей также слегка изменился, поэтому если вдруг возникнут какие-то трудности с их установкой, вы всегда можете обратиться в нашу техническую поддержку — мы всегда где-то рядом с вами!

Опубликовано в журнале «Золото и технологии», № 3 (29)/сентябрь 2015 г.