Главный (стартовый) файл проекта


Содержание

С какого документа стартовать проект?

В трех статьях цикла «Что нужно сделать до старта проекта» я описал, что до старта проекта нужно:

  • Сформулировать бизнес-проблемы, цели проекта и результаты проекта, позволяющие достичь целей
  • Собрать и проанализировать требования к результатам проекта
  • Описать допущения проекта
  • Сформулировать ограничения проекта

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

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

Структура Устава проекта

В популярном в мире подходе к управлению проектами – PMBOK – в состав «Устава проекта» входят следующие разделы:

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

Я использовал шаблон Устава проекта, структура которого немного отличалась, от предложенной в PMBOK, но содержала все разделы, кроме списка заинтересованных сторон и описания сферы ответственности и уровня полномочий руководителя проекта. Как правило, компания, которая идет по пути стандартизации проектной деятельности, разрабатывает шаблон Устава проекта под специфику своей деятельности и этот шаблон используется для старта всех проектов.

Кто разрабатывает Устав проекта?

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

Значение Устава проекта для руководителя проекта

Следует отметить, что Устав проекта не является договором, но может прекрасно дополнять его и служить внутренним документом для команды проекта и заказчика проекта.

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

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

Практика внедрения Устава проекта

Мой опыт внедрения этого документа в четырех компаниях показал, что Устав проекта приживается легко и воспринимается топ-менеджерами и акционерами компаний как необходимый для проекта документ. А в некоторых компаниях важность Устава проекта была настолько оценена, что внутренние заказчики и спонсоры проекта с каждым проектом уделяли согласованию Устава проекта все больше внимания при его согласовании.

Выводы

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

Главный (стартовый) файл проекта

Стартовый проект с gulp

  • Именование классов по БЭМ, разметка в pug, стилизация Sass. См. как работать с CSS-препроцессорами и БЭМ
  • Каждый БЭМ-блок в своей папке внутри src/blocks/ . Один БЭМ-блок — один pug-файл, один scss-файл, один js-файл.
  • Список использованных в проекте доп. файлов — в config.js .
  • Есть глобальные файлы: стилевые (стили печати), js (по умолчанию пуст), шрифты, картинки.
  • Список pug-примесей src/pug/mixins.pug генерируется автоматически, содержит include существующих pug-файлов всех блоков.
  • Диспетчер подключения стилей src/scss/style.scss генерируется автоматически, содержит импорты стилевых файлов использованных в разметке блоков и импорты доп. файлов.
  • Входная точка обработки js ( src/js/entry.js ) генерируется автоматически, содержит require js-файлов использованных в разметке блоков и доп. файлов.
  • Используется относительно жёсткий кодгайд.
  • Перед созданием коммита происходит проверка индексированных файлов. При ошибках коммит не происходит, ошибки выводятся в терминал.
  • Есть механизм быстрого создания нового блока: node createBlock.js new-block (создаёт папки и scss-файл). После имени нового блока можно дописать нужные расширения.

Как это работает

При npm start запускается дефолтная задача gulp:

  1. Очищается папка сборки ( build/ ).
  2. Записывается файл src/pug/mixins.pug со всеми pug-файлами блоков.
  3. Компилируются файлы страниц ( src/pages/**/*.pug ).
  4. Из скомпилированных html-файлов извлекаются все классы уровня БЭМ-блока. На основании этого списка будут построены диспетчер подключения стилей и список всех js-файлов проекта.
  5. Генерируются спрайты (если используются), в папку сборки копируются картинки блоков и доп. файлы из секции addAssets файла config.js .
  6. Записывается диспетчер подключения стилей src/scss/style.scss , в котором:
    • Импорты файлов из секции addStyleBefore файла config.js . По умолчанию — SCSS-переменные и примеси.
    • Импорты файлов БЭМ-блоков, упомянутых в секции alwaysAddBlocks файла config.js . Таким образом, можно взять в сборку любой блок, даже если его css-класс не упоминается в разметке страниц.
    • Импорты файлов БЭМ-блоков, использующихся в разметке.
    • Импорты файлов из секции addStyleAfter файла config.js .
  7. Записывается диспетчер подключений скриптов src/js/entry.js , в котором:
    • require файлов из секции addJsBefore файла config.js .
    • require файлов БЭМ-блоков, использующихся в разметке.
    • require файлов БЭМ-блоков, упомянутых в секции alwaysAddBlocks файла config.js .
    • require файлов из секции addJsAfter файла config.js .
  8. Компилируются и обрабатываются PostCSS-ом стили ( src/scss/style.scss ).
  9. Javascript ( src/js/entry.js ) собирается webpack-ом.
  10. Запускается локальный сервер и слежение за файлами для пересборки.

Каждый блок лежит в src/blocks/ в своей папке.

Возможное содержимое блока:

Удобное создание нового блока


Если блок уже существует, файлы не будут затёрты, но создадутся те файлы, которые ещё не существуют.

Если нужно взять в сборку сторонний модуль, то после его установки:

  1. Прописать require в js-файле проектного блока (там же писать всё, что касается работы с этим модулем). Если сторонний модуль нужен без привязки к какому-либо проектому блоку, прописать require в src/js/script.js (см. пример в файле).
  2. Если нужно брать в сборку стилевые файлы модуля, прописать их в секции addStyleBefore файла config.js (пример в файле).
  3. Если нужно брать в сборку дополнительные файлы модуля, прописать их в addAssets файла config.js с указанием в какую папку их копировать (пример в файле).

Все страницы (см. src/pages/index.pug ) являются расширениями шаблонов из src/pug (см. наследование шаблонов), в страницах описывается только содержимое «шапки», «подвала» и контентной области (см. блоки).

Каждый блок (в src/blocks/ ) может содержать одноимённый pug-файл с одноименной примесью, который при старте сервера разработки будет взят includ-ом в файл src/pug/mixins.pug .

Диспетчер подключений ( src/scss/style.scss ) формируется автоматически при старте сервера разработки.

Каждый блок (в src/blocks/ ) может содержать одноимённый scss-файл со стилями этого блока. Если блок используется в разметке (или упомянут в config.js#alwaysAddBlocks ), его scss-файл будет взят в сборку стилей.

Автопроверка с stylelint и плагинами. См. .stylelintrc .

  1. БЭМ-именование: __ — разделитель элемента, — — разделитель модификатора.
  2. Один Блок = один стилевой файл.
  3. Очередность селекторов:
    • Инклуды примесей
    • Стилевые правила сущности
    • Медиаусловия
    • Псевдоселекторы и псевдоэлементы
    • Сторонние вложенные селекторы
    • Элементы блока
    • Модификаторы блока

Точка входа ( src/js/entry.js ) формируется автоматически при старте сервера разработки. Точка входа обрабатывается webpack-ом (с babel-loader).

Для глобальных действий предусмотрен src/js/script.js (см. config.js#addJsAfter и config.js#addJsBefore ).

Каждый блок (в src/blocks/ ) может содержать одноимённый js-файл. Если блок используется в разметке (или упомянут в config.js#alwaysAddBlocks ), его js-файл будет взят в сборку стилей.

Модульная сетка (flexbox)

По умолчанию в сборку берётся файл с примесями, возвращающими правила модульной сетки. Cелекторов в CSS не добавляет, нужно писать семантические селекторы и вызывать примеси. Настройки по умолчанию вынесены в переменные ( $grid-columns: 12; и $grid-gutter-width: 30px; ).

  • Любое кол-во колонок, в т.ч. разная колоночность на разных ширинах вьюпорта.
  • Любые промежутки между колонками, в т.ч. разные на разных ширинах вьюпорта.

Посмотреть примеры и попробовать вживую можно в этом примере с codepen.io.

Ставьте звезду в верхнем правом углу и/или угостите меня кофе, переведя сколь угодно символическую сумму.

Используем CMake и GCC для программирования uC STM32 в линуксе.

Что же такое cmake?

Это кроссплатформенная система автоматизации сборки программного обеспечения из исходного кода. CMake не занимается непосредственно сборкой, a лишь генерирует файлы управления сборкой из файлов CMakeLists.txt

В CMakе используется свой крайне простой макро-язык. Его поймет любой человек, хоть немного знакомый с программированием. Очень много открытых проектов использует его как основную систему сборки.

Из чего состоят исходники проекта для stm32?

Что нам потребуется

  • OS: Любая, которая поддерживается cmake’ом и тулчейном, я проверял только на линуксе
  • CMake: http://cmake.org
  • ARM-GCC toolchain: Я использовал CodeSourcery G++
  • STM32F10x Standart Peripherals Library

Файл тулчейна для cmake

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

TOOLCHAIN_DIR — где лежит ARM Toolchain, STM32_StdPeriphLib_DIR — стандартная библиотека STM.
Далее в файле определены некоторые важные для нас переменные, которые мы будем использовать в проекте:

  • STM32_STARTUP_* — путь к файлу со стартовой программой, * — тип девайса (HD, MD и т.п.)
  • STM32_*_SOURCE — пути к исходникам модулей стд. библитеки периферии, * — SPI, I2C, TIM, etc.

Файл проекта cmake

CMakeLists.txt — самый главный файл, описывающий, что мы, собственно, хотим. Все подбробно описывать не буду, просто быстро пробегусь:

Довольно понятно — проект с именем stm32test, требуем cmake не ниже 2.6 и подключаем файл тулчейна.

Конфигурация памяти, будет нужна для линковщика.

Дерективы препроцессора — серия HD, используем SPL.

Выбираем нужный нам стартовый файл (для HD в моем случае).


Выбираем нужные нам модули.

Собственно, наши исходники

Скрипт для линковщика. Парсим файл stm32_flash.ld.in, подставляем в файле вместо $ соотв. переменную и записываем результат в stm32_flash.ld, потом передаем параметром для линкера.

Директории, где будем искать заголовочные файлы.

Компилируем (из файлов проекта, модулей, стартового кода), преобразуем из формата elf в hex и bin

Как это работает

В архиве: CMakeLists.txt — файл проекта, stm32.cmake — файл тулчейна, stm32_flash.ld.in — параметризуемый скрипт линковщика, stm32f10x_conf.h — конфигурация для SPL. Запускаем терминал, переходим в директорию проекта, запускаем cmake:

Если все правильно, то он сгенирирует Makefile, делаем

Решения в Visual Studio

В отличие от простейших программ, таких как «Hello World», большинство приложений состоит из нескольких исходных файлов. Это обстоятельство порождает массу проблем, в частности, как назвать файлы, где их разместить и можно ли их использовать повторно. В интегрированной среде разработки Visual Studio принята концепция решения (solution), состоящего из ряда проектов, которые в свою очередь состоят из ряда элементов, благодаря которой разработчики могут работать с исходными файлами. Интегрированная среда разработки имеет множество встроенных инструментов, позволяющих упростить этот процесс, обеспечив разработчикам доступ к большей части их приложений. Далее рассматриваются структура решений и проектов, доступные типы проектов и способы настройки их конфигурации.

Структура решения

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

Решение можно интерпретировать как контейнер связанных между собой проектов. Проекты внутри решения не обязательно должны быть написаны на одном и том же языке программирования или иметь одинаковый тип. Например, решение может содержать веб-приложение ASP.NET, написанное на языке Visual Basic, библиотеку на языке F# и WPF-приложение, написанное на языке C#. Решение позволяет пользователю открыть всё эти проекты в интегрированной среде разработки, а также управлять общими настройками для их создания и развертывания.

Наиболее распространенным способом структурирования приложений в среде Visual Studio является одно отдельное решение, содержащее много проектов. Каждый проект можно создать из набора исходных файлов и папок. Главное окно, в котором пользователь работает с решениями и проектами, называется Solution Explorer:

Для организации работы с исходным кодом и предотвращения его ассоциации с приложениями (за исключением веб-приложений, в которых существуют специальные папки, имеющие особое предназначение в данном контексте) используются папки (folders). Некоторые разработчики используют имена папок, соответствующие пространствам имен, которым принадлежат классы. Например, если класс Person находится в папке DataClasses в проекте FirstProject, то полностью квалифицированное имя класса может выглядеть как FirstProject.DataClasses.Person.

Папки решения (solution folders) — полезный способ организации проектов в большом решении. Они отображаются только в окне Solution Explorer — физически в файловой системе их не существует. Такие действия, как Build или Unload, можно легко выполнять над всеми проектами, включенными в папку решения. Для того чтобы разгрузить окно Solution Explorer, папки решения могут быть свернуты или скрыты.

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

Бытует распространенное заблуждение, что отдельный проект обязательно должен соответствовать отдельной .NET-сборке. Хотя в принципе это верно, довольно часто одну сборку могут представлять несколько проектов. Однако эта ситуация системой Visual Studio 2013 не поддерживается, поэтому мы будем считать, что один проект соответствует одной сборке.

Папка Miscellaneous Files — это специальная папка решения, которую можно использовать для того, чтобы следить за тем, какие еще файлы, не являющиеся частью какого-либо проекта в решении, были открыты в системе Visual Studio. По умолчанию папка Miscellaneous Files скрыта. Для того чтобы сделать ее видимой, следует выполнить команду Tools Options Environment Documents Show Miscellaneous Files.

Несмотря на то что формат файла решения, принятый в предыдущих версиях, не изменился, в системе Visual Studio 2010 открыть файл решения, созданный в версии Visual Studio 2013, невозможно.

Кроме информации о файлах, содержащихся в приложении, файлы решения и проектов могут содержать и другие записи, например, о том, как именно должен быть скомпилирован конкретный файл, об установках проекта, о ресурсах и многом другом. Система Visual Studio 2013 имеет немодальное диалоговое окно для редактирования свойств проекта, в то время как свойства решения по-прежнему открываются в отдельном окне. Как и следовало ожидать, свойствами проекта считаются те свойства, которые относятся только к данному проекту, например информация о сборке и связях, а свойства решения определяют общую конфигурацию для сборки приложений.

Илон Маск рекомендует:  Borland delphi 4 0 для начинающих палитры компонентов

Формат файла решения

Система Visual Studio 2013 фактически создает для решения два файла, имеющих расширения .suo и .sln (solution file). Первый — это довольно неинтересный бинарный файл, который сложно редактировать. Он содержит информацию, специфичную для пользователя, например, какие файлы были открыты, когда решение закрывалось в последний раз и где находились контрольные точки. Этот файл скрыт, поэтому он не должен появляться в папке решения при использовании Windows Explorer, если не снять с него соответствующую метку.

Иногда файл .suo оказывается поврежденным, и это вызывает непредсказуемые последствия при сборке и редактировании приложений. Если при работе с конкретным решением система Visual Studio становится нестабильной, необходимо выйти из нее и удалить файл с расширением .suo. Он будет создан заново системой Visual Studio, когда решение будет открыто в следующий раз. Файл решения с расширением .sln содержит информацию о решении, например список проектов, конфигурации сборки и другие настройки, не специфичные для проекта. В отличие от многих файлов, используемых в системе Visual Studio 2013, файл решения не является XML-документом. Он хранит информацию в блоках, как показано в следующем примере:

В этом примере решение состоит из трех проектов (GettingStarted, Information Services и Reference Library), а раздел Global содержит настройки, которые применяются к решению. Например, само решение будет видимым в окне Solution Explorer, потому что настройка HideSolutionNode установлена равной FALSE. Если изменить ее на TRUE, имя решения не будет отображаться в системе Visual Studio.

Если решение состоит из проектов, которые не нацелены на использование платформы .NET Framework версии 4.0, решение можно открыть в системе Visual Studio 2008, выполнив небольшое редактирование файла .sln. Необходимо просто заменить две первые строки файла приведенными ниже, и решение откроется без ошибок.

Свойства решения

Для того чтобы открыть диалоговое окно Properties, необходимо щелкнуть правой кнопкой мыши на узле Solution в окне Solution Explorer и выбрать команду Properties. Это диалоговое окно содержит два узла: Common properties и Configuration properties, как показано на рисунке ниже:

Более подробно узлы Common properties и Configuration properties описываются в следующих разделах.

Узел Common Properties

Определяя проект Startup Project для приложения, пользователь имеет три возможности, которые являются практически очевидными. Выбор Current Selection запускает проект, который в данный момент находится в фокусе окна Solution Explorer. Вариант Single Startup гарантирует, что каждый раз будет запускаться один и тот же проект. Эта установка задается по умолчанию, поскольку большинство приложений имеют только один стартовый проект. Последний вариант, Multiple Startup Projects, позволяет запускать несколько проектов в определенном порядке. Это может быть полезным при работе с приложением клиент/сервер в рамках одного решения, причем требуется, чтобы и клиент, и сервер выполнялись одновременно. При выполнении нескольких проектов важно контролировать порядок их запуска. Для управления порядком запуска проектов можно использовать навигационные кнопки, расположенные после списка проектов.

Раздел Project Dependencies используется для того, чтобы задавать другие проекты, от которых зависит конкретный проект. В большинстве случаев система Visual Studio сама управляет этими свойствами, когда пользователь добавляет или удаляет связи между проектами и данным проектом. Однако иногда пользователь может самостоятельно создать связи между проектами, чтобы они собирались в заданном порядке. Система Visual Studio использует этот список зависимостей, для того чтобы определить порядок сборки проектов. Окно этого раздела предотвращает неосторожное добавление циклических связей и удаление необходимых зависимостей между проектами.

В разделе Debug Source Files можно создать список каталогов, в которых система Visual Studio может искать исходные файлы при отладке. Этот список задается по умолчанию и просматривается перед открытием диалогового окна Find Source. Кроме того, пользователь может перечислить исходные файлы, которые система Visual Studio не должна искать. Если щелкнуть на кнопке Cancel в момент, когда система предлагает найти конкретный исходный файл, то он будет добавлен в этот список.

Раздел Code Analysis Settings доступен только в версии Visual Studio Team Suite. Это позволяет выбирать набор правил статического анализа кода, которые будут применяться к конкретному проекту. Более подробно раздел Code Analysis обсуждается далее.

Узел Configuration Properties

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

Например, может быть создана новая конфигурация решения Test, состоящая из двух проектов: MyClassLibrary и MyClassLibraryTest. Когда пользователь создает свое приложение в конфигурации Test, он хочет, чтобы проект MyClassLibrary был собран в режиме Release, чтобы тестировать его в виде, максимально приближенном к окончательной версии. Однако, чтобы проверить тестируемый код, необходимо собрать тестовый проект в режиме Debug.

Когда пользователь собирает проект в режиме Release, он не хочет, чтобы решение Test было собрано или развернуто вместе с приложением. В данном случае в конфигурации решения Test можно указать, что пользователь хочет, чтобы проект MyClassLibrary был собран в режиме Release, а проект MyClassLibraryTest вообще не собирался.

Пользователь может легко переключаться между этими конфигурациями с помощью меню Configuration стандартной инструментальной панели. Однако, переключаться между платформами не так легко, потому что меню Platform нет ни в одной инструментальной панели. Для того чтобы сделать ее доступной, необходимо выбрать команду View Toolbars Customize. Затем элемент Solution Platforms из категории Build на закладке Command можно перетащить на инструментальную панель.

Следует отметить, что, выбрав узел Configuration Properties в диалоговом окне Solution Properties, как показано на рисунке ниже, можно получить доступ к раскрывающимся спискам Configuration и Platform. Раскрывающийся список Configuration содержит все доступные конфигурации решения: Debug и Release (заданные по умолчанию), Active и All Configurations. Аналогично в раскрывающемся списке Platform перечислены все доступные платформы. Как только пользователь получит доступ к этим раскрывающимся спискам, он может на этой же странице задать настройки для каждой конфигурации и/или платформы. Для того чтобы добавить новые конфигурации и/или платформы для решения, пользователь может также использовать кнопку Configuration Manager.

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


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

В конфигурационном файле решения можно также задать тип центрального процессора, для которого оно собирается. Это особенно удобно, если нужно развернуть приложение для компьютеров с 64-битовой архитектурой. Установить настройки для всех этих решений можно непосредственно в контекстном меню, которое открывается после щелчка правой кнопкой мыши на узле Solution node в окне Solution Explorer. В то время как команда Set Startup Projects открывает окно конфигурации решения, команды Configuration Manager, Project Dependencies и Project Build Order открывают окно Configuration Manager and Project Dependencies. Команды Project Dependencies и Project Build Order отображаются в окне, только если решение состоит из нескольких проектов.

Команда Project Build Order открывает окно Project Dependencies и перечисляет порядок сборки, как показано на рисунке ниже:

Закладка Build Order демонстрирует порядок, в котором должны собираться проекты в соответствии с зависимостями между ними. Это может оказаться полезным, если пользователь поддерживает ссылки на бинарные сборки проектов, а не ссылки на проекты. Кроме того, эту возможность можно использовать для двойной проверки того, что проекты будут собраны в правильном порядке.

Среда разработки Visual Studio.NET

Страницы работы

Содержание работы

Среда разработки Visual Studio .NET

1. Общее понятие об организации программных проектов в среде Visual Studio .NET. Решения, проекты, виртуальные папки. Соответствие логической организации проекта и физического расположения файлов.

2. Свойства и конфигурации.

3. Создание решений и проектов в среде Visual Studio.

4. Управление оконной средой. Общая разметка окна Visual Studio. Окна документов и инструментов и принципы их размещения.

4. Важнейшие элементы и команды среды применительно к проекту C++. Окна Solution Explorer, Code Editor, Properties, Property Pages, Output и др.

Общее понятие об организации программных проектов
в среде
Visual Studio .NET

В MS Visual Studio .NET принята двухуровневая схема организации данных проекта. Двумя главными контейнерами являются Solution и Project.

Solution (решение) является самым вышестоящим контейнером, содержащим все остальные объекты: проекты различных типов (Projects) и отдельные файлы.

Project (проект) представляет собой контейнер второго уровня, содержащий собственно рабочие файлы. Применительно к созданию программ на C++ проект должен содержать все файлы, необходимые для создания одной программы или динамической библиотеки: исходные тексты, файлы ресурсов и пр. С отдельным проектом связан комплекс настроек (в первую очередь компилятора и компоновщика).

Для иллюстрации роли данных контейнеров предположим, что мы создаем проект под названием «Microsoft Office». В этом случае можно создать одно решение с именем «Microsoft Office», содержащее множество проектов, среди которых есть проекты с названиями «Word», «Excel», «Access», соответствующие исполняемым файлам, по одному проекту на каждый файл динамической библиотеки, а также возможно проекты, соответствующие файлам справки и т.д.

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

Контейнеры Solution и Project могут в свою очередь содержать виртуальные контейнеры-папки (предопределенные и/или создаваемые пользователем), предназначенные для удобной визуальной организации файлов проекта. Соответствуют этим папкам реальные каталоги на диске или нет, зависит от типа проекта.

Соотношение виртуальных контейнеров Solution и Project с реальным расположением файлов на диске является во многом произвольным. Решению в целом соответствуют два файла с именами, равными имени решения и следующими расширениями:

*.sln – главный файл, содержащий перечень проектов;

*.suo – файл глобальных настроек решения.

Каталог с этими файлами и является корневым каталогом решения.

В свою очередь каждому проекту, входящему в решение, соответствует файл с расширением, зависящим от типа проекта. Например, для проекта на основе языка C++ расширением будет *.vcproj. Каталог этого файла является корневым каталогом проекта.

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

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

Еще два понятия важны для управления решениями в целом. Во-первых, каждый проект в пределах решения может находиться в активном или выгруженном состоянии. Когда проект выгружен – его файлы недоступны для редактирования, и в целом проект исключен из общего процесса компиляции решения. Во-вторых, один и только один из активных проектов может иметь атрибут StartUp Project (стартовый проект). С этого проекта начинается отладка по команде Debug для всего решения.

Управление всеми описанными структурами осуществляется с помощью интегрированной среды Visual Studio. Необходимые меню, панели инструментов, окна инструментов и диалоги будут описаны в последующих разделах.

Свойства и конфигурации

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

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

Например, можно создать набор настроек уровня решения, предназначенный для создания отладочной версии приложения, и назвать данный набор настроек «Debug». Соответственно, «Release» будет называться конфигурация для создания рабочей версии приложения, «Retail» — конфигурация, предназначенная для версии приложения, передаваемой заказчику, и т.д.

Создание решений и проектов в среде Visual Studio.

Создание нового решения производится по командам главного меню:

File -> New -> Project… или File -> New -> Blank Solution…

Обе команды вызывают следующий диалог:

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

В один момент времени одна копия среды Visual Studio .NET позволяет работать только с одним открытым решением. Чтобы открыть или создать другое решение необходимо сначала закрыть текущее решение командой меню: File -> Close Solution.

Управление оконной средой.

Типовой вид системы с открытым решением с несколькими проектами показан на следующем рисунке.

Автоматизация старта верстки


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

  1. Создание в определенном месте жесткого диска главной папки проекта по принципу site_номер_сайта(название_сайта), например site_49(dota)
  2. Клон стартового шаблона с github в подпапку site
  3. Удаление папки git(чтобы безболезненно залить проект в новый репозиторий)
  4. Создание папки для файлов заказчика(шрифты, макеты, ТЗ)
  5. Линк глобально установленных npm-пакетов для автоматизации(в вашем случае может быть npm install)
  6. Открытие проекта в редакторе(в моем случае IDE PhpStorm)
  7. Запуск галпа(или какого-нибудь npm run start)

Но теперь я просто открываю консоль и пишу:

И вот спустя мгновения проект с нужной структурой открыт в редакторе, а в браузере browsersync открыл мне localhost с главной страницей проекта. О автоматизации и пойдет речь в этой статье.

Установка консоли

  1. Устанавливаем git
  2. Скачиваем cmder(mini-версию) и распаковываем в C:/cmder . Запускаем C:/cmder/Cmder.exe от имени администратора, нажать Win + Alt + P для перехода к настройкам.
  3. Переходим в Startup → Tasks. Нажимаем кнопку Add default tasks… для добавления задач по умолчанию. В списке Predefined tasks должен быть .
  4. В настройках: Startup → выбираем радиокнопку Auto save/restore opened task. Теперь при открытии cmder Вы будете видеть вкладки с теми же консолями, с которыми работали перед закрытием. Сохранить.
  5. В главном окне программы нажать Ctrl + T для создания новой вкладки с консолью и в секции Create new console выбрать . При необходимости, можно поставить флажок «run as Administrator».
  6. Закрыть открытую изначально вкладку (самая первая, почти наверняка, powershell.exe) кликом средней кнопки мыши или из контекстного меню вкладки.

Об основах использования подобной консоли вы можете почитать на блоге Николая Громова, а мы перейдем к автоматизации.

Редактируем .bashrc

Для того чтобы писать алиасы и функции для автоматизации нам нужно создать файл .bashrc по адресу C:/Users/ИМЯ_ПОЛЬЗОВАТЕЛЯ/.bashrc (возможно файл уже создан). В в этом файле напишем первый алиас:

Теперь при запуске команды pro мы будем переходить в папку которую я указал(в ней я храню проекты, вы ставите свою). Далее напишем алиас для запуска проекта в phpstorm, обратите внимание на экранирование символов:

После пути мы указываем $* , чтобы подставлять путь, который надо открыть в редакторе. Далее напишем функцию для создания нового проекта:

Далее делаем алиас и присваиваем ему функцию:

Итоговый файл выглядит так:

Используем

После каждого редактирования .bashrc необходимо перезапустить cmder. После перезапуска пишем

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

Выбор формата проекта

В педагогической литературе проекты классифицируются по самым разным основаниям:

· по объектам: природные, технические (научно-технические) социальные, «человеческие»;

· по субъектам: групповые, коллективные, сетевые;

· по целевому назначению: производственные, учебные, научно-исследовательские, акмеологические;

· по территории охвата: международные, федеральные, региональные, локальные;

· по сферам, в которых осуществляются: социально-педагогические, телекоммуникационные;

· по предметной области: исторические, экологические и др.;

· по срокам исполнения: долговременные, среднесрочные, краткосрочные;

· по степени новизны: рационализаторские, изобретательские, эвристические, новаторские (инновационные) и др.

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

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

Необходимо также «территориальное» самоопределение в проектировании. Пространство проектирования может быть внешним, внутренним, межличностным (межсубъектным). В ходе регламентации предстоящей работы осуществляется выбор следующих параметров:

· физическое пространство проекта (географический и территориальный диапазон исследования проблематики и применения Продукта, распространения влияния проектной деятельности на окружающую среду);

· социальное пространство проекта (возможность охвата проектам влиянием тех или иных групп профессионального сообщества, социальных или возрастных групп);

· парадигмальное пространство проекта (предпочтение технических или гуманитарных характеристик проекта);

· культурное пространство проекта (монокультурное, биполярное, кросскультурное);


· ценностно-смысловое пространство содержания, технологий, диагностики результатов проекта, обусловленное субъективными предпочтениями участников.

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

В рамках педагогического пространства оказываются возможными педагогические преобразования.

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

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

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

Любой образовательный процесс регламентирован во времени. Решение включиться в проектную деятельность в обязательном Порядке предполагает учет этого момента. В рамках «форматирования» проектной деятельности определяются сроки, необходимые для реализации проекта. Задумываясь о временном формате проектной деятельности, следует принимать во внимание три основных варианта выбора.

1. Ориентация на естественный ход событий (неспешное «выращивание» проектного продукта). Временные границы в этом случае зависят от циклов жизнедеятельности (существования) объекта (субъекта) проектирования.

2. Установление регламентированных сроков проекта в целом и каждого из его этапов. (Выбор оснований для той или иной регламентации может быть разным: разнесенность участников в пространстве, потребность установить многосторонние контакты, согласовать ценностные основания, необходимость провести ту или иную проектную процедуру в фиксированные сроки и др.)

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

1.5. Программирование и планирование хода проекта

Первоначально сформулированные в ходе проектирования образ или цель требуют для их реализации дальнейшего представления в виде системы задач и перечня процедур. Они осуществляются в логике «проект — прогноз — план». Прогноз включает в себя формирование представления об изменении ситуации (объекта); характере перспектив развития тенденций, ликвидации белых пятен, перенос опыта в других условиях. Это дает возможность выси троить логику изменений (обоснование этапности, стадийности реализации проекта).

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

· теоретическое моделирование методов и средств решения поставленных задач, позволяющих при заданных исходных данных и условиях получить оптимальный результат;

· оценка условий реализации проекта по срокам с учетом необходимых ограничений и затрат;

· детальная разработка этапов решения конкретных задач проектирования;

· анализ вариантов решения проблемы, выбор наиболее приемлемых из них, исходя из конкретных условий проектирования;

· систематизация и обобщение полученных результатов;

· объединение, насколько это можно, имеющихся вариантов решения;

· конструирование предполагаемого результата.

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

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

· программа деятельности (руководителя, педагога, детского коллектива, подразделения, учреждения) на год;

· программа развития (подразделения, учреждения, объединения, коллектива) на год и более;

· программы деятельности по конкретным направлениям (программа работы с кадрами, программа исследовательской деятельности, воспитательной деятельности и т.д.).

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

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

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

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

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

5. репродуктивную (воспроизводящую): через любой промежуток времени по плану можно восстановить содержание и объем выполненной работы.

Выделяют несколько типов планирования: стратегическое, структурно-содержательное и содержательно-организационное.

Структурно-содержательный планпредставляет собой краткий перечень содержания, отражающий его объем, тематические блоки и порядок изложения (или реализации содержания), т.е. его структуру. В зависимости от содержания можно определить виды плана: план письменной (опубликованной) работы (сочинения, статьи, книги и т.д.) отражает структуру содержания произведения, порядок его изложения; сценарный план — краткое изложение содержания сценария по смысловым блокам; учебный план (учреждения образования или структурного подразделения) — перечень учебных дисциплин, отражающий содержание образовательного процесса и выстроенный по тематическим блокам отдельно для каждой возрастной категории или ступени обучения; учебно-тематический план — перечень тем, выстроенный в логике постепенного усложнения, отражающий объем учебного курса и порядок изложения, преподавания содержания. Форма этих планов, как правило, произвольна и носит описательно-констатирующий характер.

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

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

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

По разным параметрам можно выделить следующие виды организационного плана.

По охвату содержания (масштабу планируемой деятельности):

· комплексный (общий) план: планируется деятельность во всех ее направлениях и видах (план воспитательной работы, план работы педагога дополнительного образования с детским коллективом);

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

· предметный (конкретный) план: планируется одно конкретное дело (план конференции, план занятия, план подготовки и проведения мероприятия и т.д.).

По продолжительности планируемого периода:


· долгосрочный (перспективный) план на длительный период времени (план работы учреждения на год, план профориентационной работы с учащимися старших классов на два года);

· этапный (периодический) план на среднюю перспективу: планируется определенный этап деятельности (план на четверть, полугодие);

· краткосрочный план на ближайшую перспективу (план работы на месяц, на неделю, на декаду);

· оперативный план конкретных ближайших действий (план дня).

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

В зависимости от субъекта планирования:

· индивидуальный план составляет один человек;

· коллективный план разрабатывает коллектив, творческая группа.

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

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

Для осуществления планирования необходимы разбивка на операции всей проектной процедуры и рассмотрение возможностей комплексного (методологического, теоретического, технологического, программно-методического, кадрового, ресурсного) обеспечения по каждому из этапов.

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

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: При сдаче лабораторной работы, студент делает вид, что все знает; преподаватель делает вид, что верит ему. 9338 — | 7293 — или читать все.

Qt/C++ — Урок 063. Добавление окон внутри главного окна приложения с помощью QMdiArea

Многие приложения, наподобие фотошопа умеют открывать проекты (изображения, тексты и т.д.) внутри окон, которые открываются внутри основного окна приложения. Qt предоставляет подобный фукционал в виде класса QMdiArea. В объект данного класса можно помещать объекты классов, наследованных от класса QWidget , и соответственно класса QWidget. Эти объекты будут отображать как окна, только будут расположены внутри QMdiArea.

Посмотрим пример с окном внутри окна.

Структура проекта

В составе проекта следующие файлы:

  • MdiWindow.pro — профайл проекта, создан по умолчанию;
  • main.cpp — стартовый файл программы с main функцией, создан по умолчанию;
  • mainwindow.h — заголовочный файл основного окна приложения;
  • mainwindow.cpp — файл исходных кодов основного окна приложения;
  • mainwindow.ui — форма основного окна приложения;
  • icons.qrc — файл ресурсов, содержит одну иконку.

Файлы MdiWindow.pro и main.cpp рассматривать не будем, поскольку они создаются по умолчанию. Файл icons.qrc содержит одну иконку, которая видна на тулбуре главного окна приложения. Данная кнопка отвечает за создание дополнительного окна приложения и добавляется через графический дизайнер. Данный Action нужен лишь для того, чтобы испускать сигнал на добавление новых окон в QMdiArea.

А теперь перейдём к сути проекта.

mainwindow.h

Заголовочный файл главного окна приложения. Содержит объявление указателя на объект QMdiArea , а также объявление слота для добавления новых окон, который был создан через графический дизайнер.

mainwindow.cpp

Объект QMdiArea устанавливается в качестве центрального виджета главного окна приложения. Также настраиваем скроллбары, чтобы они появлялись только в случае необходимости. В слоте добавления окон добавляем объект QWidget с надписью. Здесь есть один момент. Если QWidget не будет содержать никакого контента, то он будет открываться с минимальными размерами, даже если вы выставите его размеры. И только когда вы попробуете передвинуть окно, этот виджет примет выставленный размер.

Рекомендуем хостинг TIMEWEB

Рекомендуемые статьи по этой тематике

UEngine.Ru

Русскоязычное сообщество Unreal Engine 4

Работа с проектами

Работа с проектами

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

На жестком диске ваш проект представляет папка со всеми ресурсами проекта, так же файлом .uproject, который определяет, какие ресурсы с ним связаны и какие загружать в редактор для последующей работы с ними. Простым языком, это как .exe файл, который загружает ресурсы программы, только специально для редактора UE4.

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

Запаковка проектов

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

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


В File меню вы сможете найти подменю под названием Package Project. Этот раздел отвечает за подготовку и запаковку вашего проекта для тестирования и распространения. Так же в этом разделе имеются дополнительные настройки запаковки.

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

Запаковка проекта

Что бы запаковать ваш проект под конкретную платформу, выберете File > Package Project > [Имя платформы] в редакторе UE4.

Вам будет предложено выбрать путь, куда будет помещен ваш проект, а затем начнется процесс запаковки проекта.

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

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

Для менее опытных пользователей, самые важные сообщения, такие как предупреждения или ошибки, можно посмотреть в отдельном окне Message Log.

Запуск проекта

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

Для каждой платформы, исполняемые файлы для запуска могут различаться. Таким образом для Windows будет файл .exe, а для Android — .apk

Конфигурация Название EXE Расположение
Development [Имя проекта].exe [Путь]WindowsNoEditor[Имя проекта]BinariesWin64
Shipping [Имя проекта]-Win32-Shipping.exe.exe [Путь]WindowsNoEditor[Имя проекта]BinariesWin32

Распространение

Дополнительные настройки

Дополнительные настройки можно найти в File > Package Project > Packaging Settings в главном меню редактора UE4.

Build Configuration Конфигурация проекта. Для отладки режим Debug. Для тестирования больше подойдет режим Development. Для финального распространения — режим Shipping.
Staging Directory Директория, которая будет содержать запакованный проект. Будет автоматически обновлено при выборе другого пути перед запаковкой.
Full Rebuild Определяет, будет ли скомпилирован весь код, или же только измененная часть(Выкл). Это может ускорить время запаковки. При подготовки проекта к распространению(режим Shipping) убедитесь, что данная опция включена, что бы не пропустить ничего лишнего при запаковке.
Use Pak File Определяет, запаковывать ли весь контент в один файл(.pak) для более удобного распространения, или же хранить контент в индивидуальных файлах(Выкл).

Запаковка контента

При обновлении вашего контента, вам может не понадобится перекомпилировать весь проект для того, что бы запустить его и проверить. Вместо этого, в UE4 существует возможность запаковать только сам контент на нужную платформу. Сделать это можно через File > Cook Content > [Платформа].

Project Browser

При первом запуске у вас отобразится «Project Browser».

Project Browser является основным хранилищем ваших проектов. В нем вы можете создать новый проект, так и открыть уже существующий проект с вашего компьютера. Так же имеется поддержка проектов «Примеров», в которых можно оценить возможности и работу Unreal Engine 4.

Открытие проектов

Здесь будет показан весь список ваших проектов, когда хоть один будет создан. Изначально, тут будет приведен список всех проектов в папке установки.

Двойной клик по иконке открывает проект.

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

Что бы найти проект, вы можете ввести текст в поле Filter Projects. Будут показаны все проекты, содержащие введенное имя.

Так же вы можете нажать Browse и выбрать проект на вашем компьютере. Вам нужно выбрать .uproject файл.

В Project Tab вы так же можете поставить галочку на Always load last project on startup, что позволит пропусить окно Project Browser’а и запускать сразу выбранный вами проект.

Что бы вручную задать эту настройку, войдите в настройки редактоа, найдите вкладку «General» > «Load & Saving» и установите настройку «Load the Most Recently Loaded Project at Startup».

Создание новых проектов

Вкладка New Project позволяет вам создать новый проект из существующих заготовок. Blank создает полностью пустой проект.

Всего имеется два типа заготовок: C++ и Blueprint. C++ означают, что логику вашего проекта вы будете писать на C++. Другой типо означает, что для логики вам будет предоставлен визуальный скриптовый язык — Blueprint. В процессе разработки можно совмещать два типа.

  • Blank — чистый проект без какой-либо логики
  • FirstPerson — заготовка под шутеры от первого лица
  • Flying — Заготовка под простые «леталки»
  • Puzzle — Заготовка для логической игры
  • Rolling — Заготовка с катающимся мячиком
  • (2D)Side Scroller — Платформер. 2D создает заготовку для 2х-мерного платформера.
  • Third Person — Заготовка с видом от третьего лица
  • Top Down — Вид сверху и управлением мышью
  • Twin Stick — Заготовка с аркадой видом сверху
  • Vehicle — Заготовка для создания авто-симуляторов. Заготовка Vehicle Advanced создает автомобиль с улучшенной системой подвески

Что бы создать новый проект:

  1. Выберете заготовку из списка
  2. Установите настройки проекта.
  3. Введите название вашего проекта и путь к нему.
  4. Нажмите Create

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

Так же проект можно создать через выпадающеее меню во вкладке File > New Project…

Настройки проекта

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

Быстрый старт с Project Manager


Уже прошли те времена, когда создание и управление проектами выглядело сложным и непонятным. Blend4Web обзавелся отличным менеджером проектов, значительно улучшилась документация. Вот только вопросы, связанные с проектами, все также периодично всплывают на форумах. Итак, посвящается новичкам. Рассматривайте эту статью, как пособие, своеобразное HOW-TO.

Начало-начал

С чего начинается работа над программой. Все, кто читал мои статьи, могут с уверенностью повторить мой тезис «с Идеи!», а еще добавить: «с диздока», «мозгового штурма», «выпитого пива». Давайте добавим сюда еще один пункт — «Папка».

Папка, в которой будут храниться все наши файлы. А в ней еще пара папок:

«Blender» для исходных файлов Blender;

«Assets» для музыки, текстур, видео.

Главная папка с проектом хранится в папке «projects». А «projects», в свою очередь, имеет родителем мега-папку всего SDK.

Запутались? Не страшно! Ибо всю процедуру по созданию и правильному размещению файлов берет на себя менеджер проектов.

Вопрос №1. «А где же этот самый менеджер проектов?»

Предположим, вы уже скачали и настроили SDK. Если нет, то посмотрите видео здесь.

Самый быстрый способ добраться до Project Manager — это перейти в него из Blender

В веб-браузере у вас откроется нечто похожее

По умолчанию SDK фреймворка уже имеет массу приложений и примеров. Все они отражаются в менеджере проектов. Правда количество их зависит от использованного дистрибутива. Если это легкий дистрибутив CE Lite, то вы увидите только пару иконок. Стандартный бесплатный CE уже весит почти полтора гигабайта и содержит несколько десятков проектов, а вот версия PRO занимает в сжатом виде два с половиной гигабайтов. Значит проектов в ней невиданное количество! Впрочем, о дистрибутивах вы более полно узнаете здесь, а то я как-то отвлекся.

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

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

Create New Project. Создание нового проекта;

Import Projects и Export Projects. С их помощью можно махом архивировать и скачать все проекты из SDK, а потом восстановить. Спрашиваете, зачем? Ну, например, перенести их с рабочего компьютера на домашний;

Hide Stock Projects. Пользователи полных версий SDK хором благословляют разработчиков за введение этой архиполезной опции, так как она помогает скрыть все встроенные проекты и оставить для работы только личные.

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

Создание проекта

Все начинается с нажатия на кнопку Create New Project. При этом откроется длиннющее окно со множеством опций. Впрочем, вам достаточно дать имя самому проекту (поле Project Name), выбрать его тип в группе Application Type и нажать кнопку Create Project.

Это не все опции. Я большую часть отрезал, чтобы уместить картинку на экране

Сейчас у вас есть два варианта дальнейшего чтения: для особо ленивых или вдумчивых исследователей. В первом случае, просто нажмите кнопку Create Project и проматывайте смело до следующего раздела, так как разработчики уже позаботились о включении самых удобных опций. Во-втором случае, давайте разберемся, что же все-таки происходит при создании проекта.

С параметрами по-умолчанию, в общей папке SDK/projects появится новая директория с названием вашего проекта, а уже в ней знакомые вам assets и blender. В них вы увидите множество файлов: сцены Blender, HTML, CSS, javascript. По-сути, Project Manager создал рабочую заготовку, которую хоть сейчас можно скомпилировать и залить на сервер.

Это заготовка классического приложения Blend4Web. Именно с его помощью вы можете выжать максимум из API движка и создать программу любой сложности. Но есть и другие варианты.

Эти опции также находятся в окне создания проекта

Blend4Web позволяет создавать более простые приложения (в предыдущем случае проект напоминал небольшой сайт). Такие приложения можно встраивать через код IFRAME в любую веб-страницу. Действие должно быть вам знакомо, например, по вставке видео с YouTube в блог.

Для переключения типа создаваемого приложения служат параметры группы Application Type. По умолчанию включена опция Copy из панели Custom Type, как на иллюстрации выше. Это означает, что будет создаваться классическое приложение, а исполняемые файлы движка добавятся в папку с проектом. Как вариант можно выбрать опции Compile (движок будет объединен с пользовательскими скриптами) или None (забота об исполняемых файлах ложится на плечи самого разработчика).

Для другого типа приложения предлагается еще целых две опции: Web Player JSON и Web Player HTML.

Вопрос №2. «А в чем разница между Web Player JSON и Web Player HTML?»

Blend4Web SDK имеет в своем составе уже готовый веб-плеер для демонстрации 3D-сцены. Причем не просто ее визуализации, а полной поддержки интерактивности, которая создается с помощью визуального редактора логики.

Если вы выберите опцию Web Player HTML, то плеер вместе со сценой и иными ресурсами будет объединен в один HTML-файл. Зато опция Web Player JSON позволяет отделить код плеера от самой сцены. В этом есть свои преимущества и весьма немалые. В свое время я уже написал целый цикл статей по работе с Web Player. Так что, отсылаю желающих на самую первую из них.

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

Управление проектом

Я ранее говорил о том, что менеджер создает полноценную заготовку. Вы даже можете посмотреть приложение в действии!

Найдите в менеджере панель Project Name / Apps и щелкните по ссылке dev:Название Проекта. В соседнем окне веб-браузера будет открыта вкладка с вашим приложением.

Глобальные настройки и запуск приложения

Также в этой панели есть еще несколько полезных функций:

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

Config. Здесь можно изменить параметры, которые влияют на компиляцию проекта. Новичкам лучше туда не лезть.

Edit. Запуск встроенного редактора файлов. Отличная штука! Вы можете быстро отредактировать все текстовые файлы, типа HTML, CSS, JS. Работает подсветка, табуляция. Можно создавать новые файлы. Таким образом, нет необходимости использовать сторонние текстовые редакторы.

Каждый проект Blend4Web должен иметь в составе файл сцены Blender. Он создан по умолчанию, и вы можете его найти в панели Blend Files. Здесь показываются все файлы, которые уже используются. Щелкните по ссылке с названием сцены, и тут же откроется Blender.

Список файлов Blender в проекте

Blend4Web не умеет работать с оригинальными файлами Blender в формате .blend. После изменения сцены в редакторе, ее нужно экспортировать в специальный формат JSON (для экспорта используйте File | Export | Blend4Web(.json) в главном меню Blender).

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

Список экспортированных файлов сцены

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

Вопрос №3. «Я обновил дистрибутив, восстановил проект, а он не работает. »

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

Итак, вот шаги по правильному апдейту проектов:

1. Проверить зависимости. Щелкнуть по ссылке Check Modules в панели Operations. Менеджер проектов проверит все файлы и в случае необходимости выведет сообщение, а также специальную кнопку. Нажмите на нее и файлы автоматически обновятся;

2. Заново экспортировать сцены Blender. Это тоже можно автоматизировать. Щелкните по ссылке Re-export scenes;

3. Запустить приложение для тестирования из панели Project Name/Apps. Затем нажать клавишу F12 для вызова окна консоли браузера. Если в ваших скриптах есть какие-либо нарушения, то сомнительные строки кода будут подсвечены красным.

Также панель Operations позволяет:

Clone. Создание независимой копии проекта;

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

Remove Project. Полное удаление проекта, без возможности восстановления. На Корзину не надейтесь!

А остальные функции рассмотрим дальше.

Публикация проекта

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

Не все так просто. То, с чем вы работает в SDK — это технические файлы. Они не оптимизированы, имеют ссылки на массу зависимостей в самом SDK. Попробуйте, например, открыть файл HTML в проекте и посмотреть его содержимое.

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

1. Собрать проект, щелкнув по ссылке Build Project в панели Operations. Программа скомпилирует скрипты, в соответствии с настройками проекта, оптимизирует стартовый файл HTML, подчистит зависимости и выполнит массу иных полезных действий;

2. Создать пакет для отправки на сервер с помощью функции Deploy Project. Программа подготовит архив со всеми необходимыми файлами и папками. Останется только этот архив залить на сервер и распаковать в нужном месте.

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

Илон Маск рекомендует:  Экспорт товаров в Яндекс.Маркет в формате YML при помощи PHP-класса
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL