Чем открыть emodelselfextracter module

Обновлено: 02.07.2024

В предыдущей главе мы создали простую модель игрушечного поезда, используя некоторые из встроенных геометрий three.js, и быстро стало ясно, что с их помощью будет сложно построить что-либо сложное или органичное. Для создания красивых 3D-моделей требуется сложная программа моделирования. Вы можете использовать three.js для создания любого 3D-приложения, однако создание приложения для моделирования с нуля потребует огромных усилий. Гораздо более простое решение - использовать существующую программу и экспортировать свою работу для использования в three.js… или, обмануть, и загрузить любую из миллионов удивительных моделей и других ресурсов сцены, которые доступны бесплатно во многих местах в Интернете.

В этой главе мы покажем вам, как загрузить некоторые модели, созданные в Blender, приложении для трехмерной графики с открытым исходным кодом, которое можно использовать для моделирования, построения сцены, создания материалов, создания анимации и многого другого. После того, как вы создали модель в Blender, вы можете экспортировать свою работу, используя 3D-формат, такой как glTF, а затем использовать плагин GLTFLoader, чтобы перенести модель в three.js.

Лучший способ отправки 3D-ресурсов через Интернет: glTF

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

Однако недавно новый формат под названием glTF стал де-факто стандартным форматом для обмена 3D-ресурсами в Интернете. glTF (GL Transmission Format), иногда называемый JPEG для 3D , был создан Kronos Group, теми же людьми, которые отвечают за WebGL, OpenGL и целый ряд других графических API. Первоначально выпущенный в 2017 году, glTF теперь является лучшим форматом для обмена 3D-ресурсами в Интернете и во многих других областях. В этой книге мы всегда будем использовать glTF, и, если возможно, вы должны сделать то же самое. Он предназначен для публикации моделей в Интернете, поэтому размер файла минимален, а модели загружаются быстро.

Однако, поскольку glTF является относительно новым, ваше любимое приложение может еще не иметь экспортера. В этом случае вы можете преобразовать свои модели в glTF перед их использованием или использовать другой загрузчик, такой как FBXLoader или OBJLoader. Все загрузчики three.js работают одинаково, поэтому, если вам действительно нужно использовать другой загрузчик, все из этой главы по-прежнему будет применяться, с небольшими отличиями.

Всякий раз, когда мы упоминаем glTF, мы имеем в виду glTF версии 2. Исходная версия glTF версии 1 так и не нашла широкого распространения и больше не поддерживается three.js.

Файлы glTF могут содержать модели, анимацию, геометрию, материалы, источники света, камеры или даже целые сцены. Это означает, что вы можете создать всю сцену во внешней программе, а затем загрузить ее в three.js.

Типы файлов glTF

Файлы glTF бывают стандартной и двоичной. У них разные расширения:

Стандартные файлы .gltf не сжаты и могут поставляться с дополнительным файлом данных .bin.
Двоичные файлы .glb включают все данные в один файл.

И стандартные, и двоичные файлы glTF могут содержать текстуры, встроенные в файл, или могут ссылаться на внешние текстуры. Поскольку двоичные файлы .glb значительно меньше по размеру, лучше использовать этот тип. С другой стороны, несжатые .gltf легко читаются в текстовом редакторе, поэтому они могут быть полезны для целей отладки.

Бесплатные файлы glTF в репозитории three.js

Вы можете найти эти три файла в редакторе в папке assets / models /. В этой главе мы загрузим Parrot.glb, Flamingo.glb и Stork.glb, а затем добавим сетки в форме птиц, содержащиеся в каждом файле, в нашу сцену. В следующей главе мы покажем вам, как воспроизвести анимацию полета, которая есть у каждой птицы.

Если вы работаете локально, а не используете встроенный редактор кода, вам необходимо настроить веб-сервер. В противном случае из-за ограничений безопасности браузера вы не сможете загружать эти файлы с жесткого диска.

Асинхронный JavaScript

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

В этой главе мы будем использовать асинхронные функции для загрузки моделей и предположим, что вы хоть немного с ними знакомы. Если это для вас в новинку или вам нужно что-то освежить, перейдите к Асинхронный JavaScript.

Плагин GLTFLoader

Чтобы загрузить файлы glTF, сначала вам нужно добавить плагин GLTFLoader в свое приложение. Это работает так же, как добавление плагина OrbitControls. Вы можете найти загрузчик в examples / jsm / loaders / GLTFLoader.js в репозитории, и мы также включили этот файл в редактор. Идите и найдите файл сейчас.

Импорт и создание экземпляра загрузчика работает следующим образом:

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

Методы .load и .loadAsync

Все загрузчики three.js имеют два метода загрузки файлов: старый метод .load на основе обратного вызова и новый метод .loadAsync на основе Promise. Снова обратитесь к главе A.5, где мы подробно рассматриваем разницу между этими двумя подходами. Обещания позволяют нам использовать асинхронные функции, что, в свою очередь, приводит к более чистому коду, поэтому на протяжении всей книги мы всегда будем использовать .loadAsync.

Настройте Main.js и World.js для обработки Async / Await

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

Другая проблема в том, что мы не можем пометить конструктор как асинхронный. Распространенным решением этой проблемы является создание отдельного метода .init.

Таким образом, конструктор может обрабатывать синхронную настройку класса, как обычно, а затем метод init берет на себя асинхронную настройку. Мы будем использовать этот подход, поэтому нам нужно создать новый метод World.init.

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

Программы, которые поддерживают MODULE расширение файла

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

Программы, обслуживающие файл MODULE

Как открыть файл MODULE?

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

Шаг 1. Получить Drupal

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

Шаг 2. Обновите Drupal до последней версии

Если проблемы с открытием файлов MODULE по-прежнему возникают даже после установки Drupal, возможно, у вас устаревшая версия программного обеспечения. Проверьте веб-сайт разработчика, доступна ли более новая версия Drupal. Иногда разработчики программного обеспечения вводят новые форматы вместо уже поддерживаемых вместе с новыми версиями своих приложений. Это может быть одной из причин, по которой MODULE файлы не совместимы с Drupal. Последняя версия Drupal должна поддерживать все форматы файлов, которые совместимы со старыми версиями программного обеспечения.

Шаг 3. Назначьте Drupal для MODULE файлов

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

Процедура изменения программы по умолчанию в Windows

Выберите пункт Открыть с помощью в меню «Файл», к которому можно щелкнуть правой кнопкой мыши файл MODULE.
Нажмите Выбрать другое приложение и затем выберите опцию Еще приложения
Последний шаг - выбрать опцию Найти другое приложение на этом. указать путь к папке, в которой установлен Drupal. Теперь осталось только подтвердить свой выбор, выбрав Всегда использовать это приложение для открытия MODULE файлы и нажав ОК .

Процедура изменения программы по умолчанию в Mac OS

Шаг 4. Убедитесь, что MODULE не неисправен

Вы внимательно следили за шагами, перечисленными в пунктах 1-3, но проблема все еще присутствует? Вы должны проверить, является ли файл правильным MODULE файлом. Проблемы с открытием файла могут возникнуть по разным причинам.

1. Убедитесь, что MODULE не заражен компьютерным вирусом

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

2. Убедитесь, что файл с расширением MODULE завершен и не содержит ошибок

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

3. Проверьте, есть ли у вашей учетной записи административные права

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

4. Проверьте, может ли ваша система обрабатывать Drupal

5. Проверьте, есть ли у вас последние обновления операционной системы и драйверов

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

Вы хотите помочь?

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

Если вы новичок в JavaScript, то такой жаргон как "modle bundlers vs. module loaders", "Webpack vs. Browserify" и "AMD vs. CommonJS" может поставить вас в тупик.

Система модулей в JavaScript может быть пугающей, но её понимание жизненно важно для разработчиков.

В этой статье я постараюсь объяснить всё простыми словами (с несколькими примерами кода). Надеюсь, что для вас эта статья окажется полезной.

Примечание: Для удобства статья будет разделена на две части. В первой части мы рассмотрим, что такое модули и почему мы их используем. Во второй части мы рассмотрим различные способы объединения модулей в единое целое.

Кто-нибудь объясните, что такое модули ещё раз?

Хорошие авторы делят свои книги на разделы и главы. Хорошие программисты делят свои программы на модули.

Также как и главы книги, модули это просто кластеры слов (или кода, в зависимости от обстоятельств).

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

Зачем вообще использовать модули?

На самом деле у модулей есть много преимуществ. Наиболее важными, на мой взгляд, являются следующие:

Удобная поддержка (Maintainability): По определению, модуль является самодостаточным. Хорошо спроектированный модуль призван уменьшить зависимости частей вашей кодовой базы насколько это возможно, чтобы она могла расти и совершенствоваться не зависимо друг от друга. Обновить один модуль гораздо проще, когда он отделён от других частей кода.Возвращаясь к нашей книге, например, если вы захотите внести небольшое изменение в одну главу и это повлечёт за собой изменения какого-то другого раздела вашей книги, это будет кошмар. Поэтому главу нужно писать так, чтобы при внесении правок, не пришлось затрагивать другие главы.
Пространства имён (Namespacing): В JavaScript переменные которые находятся за пределами функций верхнего уровня считаются глобальными (каждый может получить к ним доступ). Поэтому очень распространено "Загрязнение пространства имён (namespace pollution)", где совершенно не связанный между собой код, связывают глобальные переменные.Совместное использование глобальных переменных в коде, который между собой не связан очень плохо в разработке.Дальше в этой статье мы увидим, что модули позволяют избежать загрязнения глобального пространства имён, путём создания приватных пространств для наших переменных.
Повторное использование (Reusability): Давайте будем честными. Все мы копировали код в новые проекты, который писали раньше. Например, давайте представим, что вы скопировали в новый проект некоторые вспомогательные методы из предыдущего проекта.Хорошо, но если вы найдете наиболее хороший способ написать эту часть, вам придётся вспомнить все места где фигурировал этот код чтобы обновить его.Это безусловно огромная трата времени. Намного проще было бы написать модуль и использовать его повторно снова и снова.

Как можно интегрировать модули?

Есть много способов интегрировать модули в свои программы. Давайте рассмотрим некоторые из них:

Паттерн "Модуль"

Паттерн "Модуль" используется для имитации концепции классов (так как изначально JavaScript не поддерживал классы), поэтому мы можем хранить публичные и приватные методы (переменные) внутри одного объекта так, как делается это в классах других языков, таких как Java или Python. Это позволяет нам создать публичный API и предоставить возможность обращаться к публичным методам, в то время как приватные переменные и методы инкапсулированы в замыкании.

Есть несколько способов реализации паттерна "Модуль". В первом примере я буду использовать анонимные замыкания. Помещение кода в анонимную функцию поможет нам достичь цели. (Помните, что в JavaScript функции - это единственный способ чтобы создать новую область видимости).

Пример 1: Анонимные замыкания

Таким образом, у нашей анонимной функции есть своя область видимости или "замыкание" и мы можем сразу её выполнить. Такой способ позволяет нам скрыть переменные из родительской (глобальной) области видимости.

Что действительно хорошо в таком подходе, дак это то что вы можете использовать локальные переменные внутри этой функции и не бояться случайно перезаписать глобальные переменные с таким же именем. Но доступ к глобальным переменным у вас по прежнему остаётся, например так:

Обратите внимание, что круглые скобки вокруг анонимной функции обязательны, потому что инструкция, которая начинается с ключевого слова function всегда считается объявлением функции (помните, что в JavaScript нельзя объявлять функции без имени). Следовательно окружающие инструкцию скобки, вызывают функцию вместо её объявления. Если вам интересно то больше вы сможете прочитать здесь.

Пример 2: Глобальный импорт

Другим популярным подходом, который используют библиотеки такие как jQuery, является глобальный импорт. Он похож на замыкания, которые мы только что видели, только теперь мы передаём глобальные переменные в качестве параметров.

В этом примере GlobalVariable единственная глобальная переменная. Преимущество такого подхода в том, что все глобальные переменные вы объявляете заранее, что делает ваш код прозрачным для остальных.

Пример 3: Объектный интерфейс

Ещё один подход при создании модулей заключается в использовании автономных, объектных интерфейсов, например так:

Как вы могли заметить, такой подход позволяет решать какие переменные (методы) мы хотим сделать приватными (например, myGrades), а какие публичными поместив их в возвращаемый объект (например, average и failing).

Пример 4: Паттерн "Раскрывающийся модуль"

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

Это может показаться большим объёмом информации, но это только верхушка айсберга, когда дело доходит до паттернов модулей. Вот некоторые полезные ресурсы, которые нашёл проводя свои исследования:

от Addy Osmani: это клад с деталями и выразительно кратким содержанием; : полезный обзор с примерам расширенного использования паттерна "Модуль"; : обзор паттерна "Модуль" и ресурсы для других JavaScript паттернов;

CommonJS и AMD

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

Хоть каждый из этих подходов и эффективен по своему, у них есть и свои недостатки.

Вы как разработчик должны знать правильный порядок загрузки файлов. Например, предположим, что вы используете Backbone в своём проекте, поэтому вы подключаете скрипт Backbone'а через тег в своём файле. Так как Backbone напрямую зависит от Underscore.js, вы не можете подключить скрипт Backbone.js перед Underscore.js.

Управление зависимостями для разработчика иногда доставляет головную боль.

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

Исходя из этого возникает интересный вопрос: можем ли мы обращаться к интерфейсу модуля не через глобальную область видимости?

К счастью, ответ да.

Есть два популярных и хорошо реализованных подхода: CommonJS и AMD.

CommonJS

CommonJS - это добровольная группа разработчиков, которая проектируют и реализует JavaScript API для объявления модулей.

Модуль CommonJS - это фрагмент JavaScript кода предназначенный для многократного использования. Он экспортирует специальные объекты, делая их доступными для других модулей, чтобы они могли включать их в свои зависимости. Если вы программировали на Node.js, то вам это будет очень хорошо знакомо.

С CommonJS в каждом JavaScript файле модуль хранится в своём собственном уникальном контексте (так же, как и в замыканиях). В этом пространстве мы используем объект module.exports чтобы экспортировать модули, и require чтобы подключить их.

Определение CommonJS модуля может выглядеть следующим образом:

Мы используем специальный объект module и размещаем ссылку на нашу функцию в module.exports. За счёт этого CommonJS знает, что мы хотим открыть модуль так, чтобы другие файлы могли его использовать.

После этого, когда кто-то захочет использовать наш myModule, он без проблем сможет его подключить следующим образом:

У данного подхода есть два очевидных преимущества над подходами, которые мы обсуждали раньше:

Отсутствие загрязнения глобального пространства имён;
Становление наших зависимостей более явными;

Кроме того, очень компактный синтаксис, я это очень люблю.

Нужно отметить, что CommonJS использует server-first подход и модули загружаются синхронно. Это важно потому что если у нас есть ещё три модуля, которые нам нужно подключить, он будет загружать их один за другим.

Сейчас это прекрасно работает на сервере, но к сожалению, это затрудняет написание браузерного JavaScript. На получение модуля из интернета уходит намного больше времени, чем на получение модуля с жёсткого диска. Пока скрипт загружает модуль, браузер блокируется и вы ничего не можете сделать, до тех пор, пока он не закончит загрузку. Он ведёт себя так потому что JavaScript поток останавливается, пока загружается код (Я расскажу вам как мы может обойти эту проблему во второй части статьи, когда мы будем рассматривать сборку модулей. На данный момент это всё, что нам нужно знать).

CommonJS хорош, но что если нам нужно загружать модули асинхронно? Ответ на этот вопрос "Асинхронное определение модулей (Asynchronous Module Definition)" или просто AMD.

Загрузка модулей с помощью AMD выглядит примерно так:

Функция определения модуля принимает первым аргументом массив зависимостей. Эти зависимости загружаются в фоновом (не блокирующим) режиме и вызывают функцию обратного вызова, которая была передана вторым аргументом.

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

Например, myModule может выглядеть следующим образом:

Итак, давайте пройдёмся ещё раз. В отличии от CommonJS, AMD реализует browser-first подход вместе с асинхронным поведением (Обратите внимание, что достаточно много людей утверждают, что динамическая загрузка файлов не благоприятна при выполнении вашего кода. Об этом мы поговорим больше в следующей части нашей статьи, посвящённой сборке модулей).

Кроме асинхронности, у AMD есть ещё одно преимущество. AMD модули могут быть функциями, конструкторами, строками, JSON'ом и другими типами, в то время как CommonJS в качестве модулей поддерживает только объекты.

Из минусов, AMD не совместим с io, файловой системой и другими серверно-ориентированными особенностями, которые доступны через CommonJS. И синтаксис функции объявления модулей многословен в сравнении с просты require.

Для проектов, которые требуют поддержки функций обеих систем AMD и CommonJS, есть ещё один формат. Универсальное Объявление Модулей (Universal Module Definition), ну или по простому UMD.

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

Быстрый пример того, как работает UMD:

Дополнительные примеры UMD, можно посмотреть в этом GitHub репозитории.

Нативный JS

Фууух. Вы ещё рядом? Я не потерял вас в этом лесу? Хорошо! Потому что у нас есть ещё один тип определения модулей.

Как вы могли заметить выше, ни один из модулей не был родным для JavaScript. Вместо этого мы имитировали систему модулей, используя либо паттерн "Модуль", либо CommonJS, либо AMD.

К счастью умные люди из TC39 (the standards body that defines the syntax and semantics of ECMAScript) добавили встроенные модули в ECMAScript 6 (ES6).

ES6 предлагает разнообразные возможности для импорта и экспорта модулей, про которые рассказывали не один раз. Вот парочка ресурсов:

Что хорошего в ES6 модулях в сравнении с CommonJS и AMD? То, что он собрал лучшее из двух миров: компактность, декларативный синтаксис, асинхронную загрузку, плюс дополнительные преимущества, такие как циклические зависимости.

Вероятно, моя любимая особенность ES6 модулей заключается в том, что импорты это живые read-only виды экспортов (в сравнении с CommonJS, где импорт это просто копия экспорта).

Вот пример того, как это работает:

В этом примере мы сделали две копии базового модуля: первый раз когда экспортировали его, а второй раз когда импортировали.

Кроме того, копия которая находится в main.js теперь отключена от оригинального модуля. Поэтому, даже когда мы увеличиваем наш счётчик, он всё равно возвращает 1, так как counter - это переменная которую мы импортировали из модуля, отключённая от оригинального модуля.

Таким образом, увеличение счётчика будет увеличивать его в модуле, но не будет увеличивать в скопированной версии. Единственный способ изменить скопированную версию, это увеличить её вручную:

А, ES6 при импорте создает живой read-only вид модуля:

Интересно, не правда ли? Что я нахожу действительно убедительным в живых read-only видах, дак это то, что они позволяют разделить ваши модули на более мелкие куски без потери функциональности.

Вы можете развернуть и объединить их заново (в новом проекте), и никаких проблем. Всё будет работать.

Немного заглядывая вперёд: Сборка модулей

Вау! Как быстро пролетело время. Это было крутое путешествие и я искренне надеюсь, что статья дала вам возможность лучше понять модули в JavaScript.

В следующей статье мы рассмотрим связывание модулей, затронем основные темы, включая:

Уже давно обещал поделиться нашим опытом по работе в новой среде разработки. Наконец нашел время и подготовил краткое описание – небольшой отчет и некоторые мысли. В качестве источников информации для осмысления были взяты:

вопросы с партнерского форума;
мнение коллег на основе практики работы;
мнение коллег из сообщества;
интернет;
мои собственные мысли.

Пока сообщество в целом настороженно смотрит в сторону EDT, но постепенно свыкается с мыслью что он есть и будет. Надеемся, что данная статья поможет вам сделать шаг или еще один шаг в сторону начала работы в этом новом инструменте.

О чем мы хотим рассказать (обзорно):

Интерфейс и возможности EDT;
Ключевые моменты при работе с GIT;
Процесс разработки;
Полезные советы.

I) Основное про интерфейс и возможности EDT.

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

Отметим отдельно - работа в EDT это теперь не только «сидеть в конфигураторе», теперь это жизнь в полноценном окружении и в рамках процесса разработки.

Переспективы.

Первое на что следует обратить внимание и то с чем вы сразу сталкиваетесь, когда окажитесь внутри – это переспективы. На них расположены основные рабочие пространства:
• 1С пространство.
• GIT пространство.
• Debug пространство.

1С пространство.

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

Навигатор проекта . В дереве метаданных, мы можем теперь загружать произвольное количество конфигураций, а не одну как ранее. Теперь в навигаторе проекта можно открыть множество конфигураций, внешние обработки и отчеты. К недостатку можно отнести, то что расположено вся эта красота линейно и нет возможности делать какие-либо группировать по папкам. В связи с данным фактом советуем не активные проекты в текущий момент закрыть, чтобы не отъедались лишние ресурсы.

Подсветка ошибок . Большим плюсом можно рассмотреть возможности синтаксис контроля. Теперь проблемы отображаются не только в отдельной вкладке, но и в каждом узле дерева метаданных.

Задачи по коду . Можно создавать мини задачки для себя внутри конфигурации (для полноценного управления задачами все же стоит использовать взрослую систему). Они отображаются на панели вкладки «Задачи». Для их добавления пишем в коде конструкцию:
//TODO: Вот тут позже допилю, сейчас некогда)

Синтаксис помощник автоматически позиционируется по выбранному коду. На мой взгляд стало удобнее.

Сравнение кода, конфигураций . Возможности сравнения гораздо более продвинутые, правда довольно непривычно относительно привычного инструмента из конфигуратора. Теперь вы без труда сможете сравнить текущее состояние конфигурации с конфигурацией в проекте, с конфигурацией из файла или с любой версией в гит. Сравнение с историей теперь выглядит гораздо удобнее и практичнее. Для этого необходимо выбрать проект и в выпадающей командной панели по правому клику мышки ищем «Сравнить с…»(Compare with…) и выбираем один из доступных вариантов.

Горячие клавиши . Клавиши работы в EDT изменились и теперь придется переучиваться или запоминать второй набор. Чтобы вызвать список доступных горячих клавиш нажмите комбинацию «Control+Shift+L». Приведем набор наиболее полезных сочетаний:

Подсказка «Ctrl+Space»
Закомментировать «Ctrl+/»
F3 перейти к определению
F11 отладка и Ctrl+F11 запуск.
И другие.

И еще много чего интересного, устал писать. Попробуйте посмотреть сами.

GIT пространство.

Мы занимаемся командной разработкой, а тут без работы с распределенными хранилищами и вресионированием никуда). Интерфейсно упрощенно и немного спартански местами. Позволяет выполнять стандартный функционал + некоторая специализация по назначению IDE. Интерфейс SourceTree или GitHubDecktop поприятнее и удобнее.

Очень большая плюшка заключается в том, что вы теперь можете в один клик в дереве веток переключиться на другую версию и конфигурация изменится по мгновению) Однако не всегда стоит запускать обновление конфигурации базы, иначе ее можно сломать.

Более подробно про работу с GIT напишем ниже.

Пространство отладка.

Процесс отладки теперь выглядит немного иначе, но основная суть осталась та же. Ждем дальнейших улучшений возможностей в этом направлении в EDT.

Другое.

Авто обновление . В настройках EDT по умолчанию стоит авто обновление конфигурации информационных баз в режиме «Обновление в процессе редактирования». Советую никогда не использовать данный режим.

Что делать, когда пока не поддерживаются некоторые особенности платформы? К примеру, работа с внешними источниками данных в EDT не поддерживается, но в силу обстоятельств работать с данным функционалом необходимо. В этом случае закрываем EDT и открываем конфигуратор (снова здравствуйте) и вносим требуемые правки, а затем снова возвращаемся в EDT и при попытке запуска он нам сообщит, что произошли изменения и предложит один из трех вариантов. Мы выбираем получить изменения в хранилище и наслаждаемся процессом. Весь неподдерживаемый функционал платформа сохраняет в папку рядом с проектом с наименованием «unknown» (неизвестные). Вручную редактировать в блокноте модули не советуем).

Поддержка поставщика. Увы изменять настройки поддержи в EDT пока нет возможности. В данном случае вы или снимаете «замочки», или разрабатываете расширения. И снять «замочки» рекомендуем до импорта проекта в EDT в старом добром конфигураторе.

Оборудование для работы. Конфигурация «Тестирование 3.0» достаточно легковесная поэтому работает достаточно успешно на средненьких мощностях. Мне удалось на ней работать в «VirtualBox» на ноутбуке i7-4500U 2,6 ГГц (3,1 ГГц boost) с 8ГБ, для виртуальной машины я выделил 2 ядра и 4 Гб памяти. На стандартной машине разработчика работа идет комфортно, даже отлично.
ERP запускали на сервере разработки с Xeon E5-16300 3,7 ГГц и 128 Гб памяти. По ощущениям не уступает конфигуратору, но потребляет значительно больше процессорных ресурсов и памяти. И количество одновременно работающих пользователей на этой машине разработки снизилось до 3х-4х человек с временным пожиранием ресурсов процессора до 90-100%.

Что в итоге?

Подведем резюме сравнения с типовым конфигуратором.

Преимущества :
• Новые возможности разработки
• Механизм сравнения в целом, а также сравнение форм, ролей.
• Новое хранилище, основанное на GIT
• Возможность создания плагинов
• Система редактирования запросов и возможность сохранения комментариев после редактирования конструктором
• Более удобная и наглядная отладка
• Есть структура модуля, иерархия вызовов, er-diagram и всякие удобства, которые не планируется на старом конфигураторе

Недостатки :
• Нет пока поддержки части функционала, доступного в старом конфигураторе (приходится использовать сразу две среды)
• Жрет ресурсы, использует Java и пока кажется более медленным
• Более нагруженный интерфейс
• Непривычная среда исполнения
• Новые баги) а также куча мелких надоедливых багов, как разбегающиеся тараканы ночью на кухне)
• Еще не готов к комфортной разработке крупных проектов типа ЕРП.

В целом EDT выглядит обнадеживающе, про недостатки можно сказать так: со временем стерпится и слюбится)

II) Про работу с GIT и процесс разработки

Про GIT.

Надеюсь вы крайне отрицательно воспринимаете утверждение, что «Настоящие гуру не использую хранилище, а правят по живому». Тогда использование этого механизма покажется вам настоящим удовольствием и качественным переходом. Мне нравится следующая мысль: «Может быть это маленький шаг в мире разработки ПО, но это большой скачек для сообщества 1С)»

Сейчас в сообществе поднимается хайп по вопросам, связанным с GIT (смотрим на количество упоминаний слова GIT в рамках предстоящей конференции 2018), но на мой скромный взгляд, использование данного функционала самого по себе без привязки к процессу разработки не полноценно. В связке с EDT это уже выглядит как закономерное и полезное явление.

Хранилище GIT . Используем GIT на GitHub с публичным репозиторием, если хотите приватный, то придется доплатить. Можно получить бесплатный приватный репозиторий на botbucket, только тут другое ограничение – бесплатно можно использовать только на команду в 5 человек.

Инструменты для работы с GIT. Это список из следующих приложений:
• старый добрый GIT GUI. Довольно аскетичен и прост, можно сказать ничего лишнего, а если вам надо что-то более сложное, то берем консоль Git Bush и решаем те задачи, которые не по силам графической части.
• GitHub Desktop. Инструмент, оптимизированный для работы в облаке Git Hub. Если используете хранилище в этом облаке, то это будет хороший выбор.
• Встроенный в EDT. Он есть, и он работает. Его функционала вполне достаточно для реализации поставленных задач по разработке.
• Source Tree. Мощный и популярный бесплатный инструмент от Atlassian. Красив и практичен.
• И последний это TortoiseGit. К его преимуществам можно отнести тот факт, что он хорошо встраивается в контекстное меню проводника. Благодаря этому вы сразу в нем сможете для конкретного файла получить подробную информацию об его изменениях или выгрузить копию из истории.

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

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

Получение изменений (fetch/pull) . Примите за правило получать изменения из облака – fetch+merge или pull!

Передача изменений (push) . Сделали работу и завершили задачку, тогда отправляем наши изменения в основное хранилище.

Тайники (stashes) . Очень удобный инструмент. Необходимость возникает в нем в том случае, когда вы работаете над какой-то задачей и вдруг вынуждены переключиться на блокирующую или срочную, но помещать код в ветку облака не хочется. У нас есть правило не работающий код мы не коммитим и не помещаем. Откатывать свои изменения или делать копию текущего состояния невыход или не удобно. Поэтому смело создаем тайник, в который скроются все изменения. Потом, когда вернетесь к текущей задаче, то смело сможете достать прерванные изменения и продолжить работу.

Про процесс работы.

В качестве процесса разработки для конфигурации "Тестирование 3.0" мы выбрали «Git Hub Flow» (показан на рисунке ниже). Это наиболее простой из существующих процессов разработки, если не сравнивать с анархией. Думаю, еще вас могут заинтересовать «Git Flow» и «Git Lab Flow», но об этом в другой раз.

Процесс разработки «Git Hub Flow» - теория.

Реальная картинка с рассматриваемого проекта – практика)

Что хорошего в этом процессе?

новые возможности добавляются сразу по готовности;
ошибки исправляются довольно оперативно и добавляются в текущий режим;
простой рабочий процесс: минимальное количество правил, наличие одной основной ветки (master).

Рекомендации для успешной работы в рамках процесса:

содержимое ветви master должно быть всегда работоспособно;
любая доработка должна отражаться задачей и формировать ветку из мастера с номером задачи в наименовании. Наименование задачи должно отражать краткую суть происходящего;
всегда создавайте pull-request;
используйте в разработке обязательно код-ревью, вы же команда! Не стоит следовать мыслителю с картинки ниже по тексту.

Как мы перешли с конфигуратора? У нас есть два хранилища релизное и разработческое, или рабочая конфигурация и хранилище разработки:

На первом шаге в ветку мастер выгружаем рабочую конфигурацию;
На втором шаге делаем ветку с именем "Старое хранилище" и туда загружаем хранилище разработки;
Далее при необходимости сливаем изменения из бранча старого хранилища в ветку develop или mater (в зависимости от процесса).

Что в итоге?

Какие плюсы :

Наконец появилась возможность нормального командного процесса работы и разработки;
Это GIT, с конфигуратором это было не реально! Хранилище не считается);
Возможность просмотра истории изменений в один клик и быстро;
Дополнительные бонусные возможности настройки правил работы с репозиторием из облака (github - защита ветки, необходимость pull-request, обязательность code-reviw и др.);
Другие преимущества использования GIT.

Что из минусов :

В некоторых случаях усложняется процесс разработки;
Это не привычно и нужно подстраиваться;
В EDT пока еще баги и это несколько портит впечатление.

А какой процесс использовался при работе с конфигуратором? Некоторые коллеги, с которыми я общался, вообще не использовали хранилища для разработки или в давние времена изменения отправляли прямо в production. В конфигураторе вести разработку с использованием веток или ветвления возможности не было поэтому это огромный плюс, который появляется с приходом EDT в мир разработки 1С.

Читайте также: