Сайт какого-то музея ЮФУ

Оглавление

1. Оглавление
2. Используемые средства разработки
3. Начало работы
   • VS Code
   • WSL
   • Загрузка проекта и установка зависимостей
   • Файловая структура проекта
   • Основные принципы разработки
4. Подробнее об инструментах

---

Используемые средства разработки

• VS Code
  • Remote WSL
  • GitLens
  • Prettier
• WSL
  • Git
  • NodeJS
    • Gulp
      • PUG
      • Sass
      • Babel

Начало работы

VS Code

Объяснять, как установить VS Code не буду, но пару слов сказать стоит.

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

Во-вторых - папка ".vscode". В ней находятся мои настройки редактора именно для этого проекта. Использовать их необязательно (эту папку можно просто удалить), но как минимум необходимо установить размер таба в 2 пробела (да, по умолчанию в VS Code символ таба заменяется пробелами, это связано с тем, что на разных системах размер таба разный, а пробелы везде одинаковые).

WSL

WSL (аббревиатура от Windows Substyem for Linux) - это подсистема, позволяющая запускать среду GNU/Linux и использовать большинство программ доступных в ней прямо из винды.

Установка. Если версия винды 2004 или любая Windows 11 (проверить можно нажав Win + R и введя winver), достаточно открыть PowerShell от имени админа, ввести wsl --install и перезагрузить компьютер. В противном случае ситуация сложнее. Тут порядок действий следующий:

1. Открываем PowerShell от админа.
2. Вводим dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
3. Перезагружаемся, снова открываем PowerShell.
4. Вводим dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
5. Перезагружаемся.
6. Скачиваем, устанавливаем, перезагружаемся.
7. Снова PowerShell, вводим wsl --set-default-version 2
8. Тык, устанавливаем.

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

1. Запускаем Ubuntu (можно в поиске системы найти)

2. После загрузки будет такая шняга

3. Вводим свой ник, и два раза пароль (пароль никак не отображается, то есть вообще никак, ни чёрточек, ни точек)

4. Вводим sudo apt-get update && sudo apt-get upgrade, когда попросит подтвердить, вводим y, жмём enter

5. Вводим sudo apt-get install npm, если просит подтвердить - y и enter

6. Теперь терминал можно закрыть, открываем VS Code

Загрузка проекта и установка зависимостей

При первом открытии VS Code после установки WSL справа должно появиться уведомление, предлагающее установить Remote WSL, если не предлагает, ставим ручками. После установки слева снизу должна появиться жёлтая кнопка, типа вот такой:

Жмём на неё, в выпадающем меню выбираем "Open folder in WSL"...

Тут немножко отвлечемся, чтобы открыть папку подсистемы Ubuntu в Проводнике, нужно в поиске системы вбить \\wsl$, там уже можно просто создать ярлык, на любую из папок линУкса и поместить его на рабочий стол. Советую по пути \\wsl$\Ubuntu\home\<ник>\ (домашняя папка пользователя) создать папку projects (или что-то типа того) и работать уже в ней. Я дальше везде буду ссылаться именно на эту папку.

находим папку projects, открываем.

Теперь качаем сам проект, вводим команду git clone https://github.com/darktau21/sarmat.git. После скачивания появится папка sarmat. Далее в терминале VS Code переходим в папку с проектом (cd sarmat) и пишем npm i, это установит все нужные пакеты (Типа Gulp, PUG, Sass, Babel). Далее вводим sudo npm i --global gulp-cli. Теперь, наконец-то, можно работать.

Файловая структура проекта

.
├── dist                 - папка, куда будет собираться сайт
├─┬ src                  - папка с исходниками сайта
│ ├── fonts              - папка со шрифтами
│ ├── includes           - папка с БЭМ блоками
│ ├── pages              - папка со всеми страницами
│ ├── uploads            - папка с контентными файлами*
│ └── sass               - папка с SASS файлами
├── package.json         - файл настроек Node.js
├──.browserslist         - файл, указывающий какие версии браузеров поддерживаем**
├──.gitignore            - файл, в котором указываем гиту какие файлы нужно игнорировать
└── gulpfile.js          - файл настроек Gulp

* В папке uploads хранятся только те файлы (картинки, документы и т.д.), которые нужны для наполнения сайта контентом. Почему так? Это банально удобнее, например, картинки, которые нужны для дизайна самого сайта (допустим лого юфу), будет лежать где-то в отдельной папке, а здесь картинки статей, которые могут 100500 раз измениться, добавиться, удалиться. Таким образом мы исключаем удаление файлов (да тех же картинок), которые нужны именно для дизайна интерфейса

** В этом файлеописаны поддерживаемые версии браузеров. Это нужно для плагинов, которые обрабатывают код. Например autoptrefixer, который мы испульзуем, ссылается на этот файл, чтобы знать, какие вендорные префиксы нужно вставлять в CSS. Такой же принцип работы и у Babel.

Основные принципы разработки

• Адаптивность Максимальная отзывчивость верстки. Она не должна распадаться и съезжать при отсутвсии каких либо блоков или контента (текста, картинок). Верстка должна выглядеть вменяемо и при бОльшем количестве контента, чем задумывалось изначально (в рамках разумного конечно). Например, изначально задумано 5 пунктов меню, при добавлении 6 и 7 пункта шапка должна отреагировать вменяемо - растянуться или перенести пункты на другую строку, а не создать горизонтальный скролл, выехать за экран или наехать на следующий блок. И такие требования должны соблюдаться для всех элементов на странице. Так же не должно быть никаких проблем при изменении ширины экрана, блоки должны растягиваться, равномерно размещая контент. При сжатии - сжиматься до минимума и потом уже перестраиваться.

• Кроссбраузерность К сожалению, разработчики браузеров далеко не всегда следуют официальной спецификации W3C (консорциум, который занимается поддержкой и развитием HTML и CSS, именно они решают какие HTML теги и CSS свойства добавлять в новых версиях, и именно они описывают, как это всё должно работать), поэтому одна и та же верстка в разных браузерах может выглядеть совершенно по разному, нужно стараться приводить верстку к одному виду во всех браузерах (но в пределах разумного, идельной точности в разных браузерах добиться практически невозможно, да и в 99,9% случаев - бессмысленно). Тут можно посмотреть некоторые примеры различий работы одних и тех же CSS свойств в разных браузеров и способы их пофиксить.

• Олды тоже люди Поддержка старых браузеров, в частности последних версий Internet Explorer. Идеальной поддержки не нужно, сайт просто должен не сыпаться. Если всё совсем плохо, то выводим плашку с просьбой зайти с более нового браузера

• БЭМ (Блок Элемент Модификатор) Это метолодология, согласно которой каждая страница разделяется на блоки и элементы. Именно для этого мы и используем PUG и Sass. Для каждого блока создаётся отдельная папка, в которой хранится всё, что с ним связано (HTML код, стили, скрипты, картинки и т.д.) и уже отдельные блоки просто подключаются к странице. Подробнее тут и тут и вот тут (вот это прям обязательно для прочтения)

• Mobile First Сначала для мобилок. Верстка делается сначала под мобильные устройства, потом уже под большие размеры экранов. Усложнять простое легче, чем написать сначала сложный код, потом его обнулять и снова писать уже под мобилки. Но не факт, что с нашим макетом этого прицнипа получится придерживаться

• Максимальное упрощение В первую очередь это касается стилей. Если на макете есть текст, то и в верстке это должен быть текст (а не картинка с текстом), простейшие геометрические фигуры (кружочки квадратики, палочки) - на чистом CSS и т.д. и т.п. Думаю, принцип понятен

Подробнее об инструментах

Есть две основные консольные команды, которые нам понадобятся: gulp (она же npm run dev) и gulp build (она же npm run build). Первая запускает веб сервер, открывает страницу в браузере, и следит за всеми изменениями фалов в автоматическом режиме для автообновления страницы в браузере. Вторая собирает проект в папку dist.

Теперь подробнее об инструментах. Gulp - таскраннер. Его задача управлять всеми остальными инструментами и следить за изменениями файлов. Например. Есть Sass. Это препроцессор, его задача компилировать код из одного синтаксиса в другой (задача PUG, кстати, точно такая же) и по идее каждый файл со стилями мы должны передавать вручную, то есть прописывать в консоли команду, путь до исходного файла и куда класть скомпилированный файл, но это не очень удобно. Тут в дело вступает Gulp, который следит за всеми файлами стилей и при любых изменениях автоматически, без какого либа вмешательства компилирует их и кладёт куда мы указали. И так во всём. PUG, Sass и JavaScript код автоматически компилируются, сжимаются, стилям добавляются вендорные префиксы, JavaScript переводится в старый синтаксис (который куда более громостский и неудобный), который поддерживается старыми браузерами и после всего этого все файлы кладутся в папочки на выходе. Что касается картинок и шрифтов: картинки - сжимаются, удаляются метаданные (например дата съёмки, эти данные тоже занимают место), шрифты - преобразуются в различные форматы, которые поддерживают и старые и новые браузеры. Без Gulp все вышеперечисленные действия пришлось бы делать ручками, используя сторонние интернет-сервисы и программы.

В конфиге достаточно подробно описано, что для чего нужно и как что пишется.