Как написать веб интерфейс

Как верстать веб-интерфейсы быстро, качественно и интересно

Всем привет! Давно хотел и наконец написал небольшую книжку — бодрое пособие по своей профессиональной области: актуальным подходам к разметке интерфейсов, экранному дизайну и доступности. Она о моем оригинальном подходе к созданию GUI, препроцессорам CSS (для объективности, немного и об альтернативных подходах), и его эффективном практическом использовании с javascript и популярными реактивными компонентными фреймворками Vue и React. Материал представлен аккуратно последовательно, но безумно интенсивно и динамично — ничего лишнего или даже слишком подробного — для того чтобы увлеченный и подготовленный читатель не потерял интереса и «проглотил на одном дыхании». С другой стороны, текст, достаточно сложный ближе к концу, и на всем протяжении — густо насыщенный идеями, ссылками на технологии и подходы — поэтому, очевидно, будет «на вырост» начинающим. Но, в любом случае, как и если вы только начали интересоваться данной тематикой, так и если уже давно занимаетесь веб-дизайном, версткой и программированием фронтенда — вам может быть полезно на него взглянуть.

Мотивация

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

Начну с некоторого огульно обобщающего и, поэтому, несколько провокационного наблюдения, «вброса»: большинство, не только начинающих, но даже опытных программистов испытывают своеобразное предубеждение-стереотип о некой «несерьезности» верстки интерфейса как отрасли деятельности в веб-индустрии — «верстка это не программирование!». Очень многие считают что заниматься разметкой «некруто и скучно» для «серьезного» специалиста. И как следствие — уделяют предмету мало своего внимания и времени, имеют мало реального релевантного опыта. Проще говоря, большинство разработчиков не любит и не умеет верстать. И уже и как причина и как следствие — зачастую сами подходы, технологии и архитектура используемые для организации GUI даже на серьезных коммерческих проектах — отставляют желать лучшего, не отвечают реалиям современной веб-индустрии, устарели и недостаточно эффективны. Неудачные, якобы временные, слабые решения и дальнейшие бесконечные быстрые «фиксы», кривые «кряки» наслаиваются друг-на-друга, кодовая база неоправданно распухает и становится все менее связной и контролируемой. Шаблоны, или ныне — в эру компонентных фреймворков — компоненты, стили и логика для них часто и закономерно превращаются в невнятную и крайне излишнюю по сути «свалку», «густой лес», «джунгли» с очевидно неподъемной ценой рефакторинга и масштабирования. Очевидно, что такое состояние системы может легко приводить к серьезным затруднениям, снижению темпов или даже срыву сроков и, ирония как раз в том, что в реальной коммерческой ситуации, авторам подобной громоздкой и неуклюжей системы, все равно придется потратить еще больше времени на то, чтобы, по крайней мере, исправить все оплошности и несовершенства разметки, оформления и логики для них, но делать это придется в изначально плохо организованном коде, по замкнутому кругу — только увеличивая беспорядок и вероятность сбоев. С того момента как вы перестаете быть «джуном», ваша ответственность состоит не только в том чтобы закрыть все «баги» на трекере и навернуть как можно скорее «фичи», любой ценой. Надежная и легко поддерживаемая система — продукт который вы продаете бизнесу.

Реальный жизненный кейс: будучи начинающим специалистом я работал удаленно в одном приятном стартапе. Когда проект запустили, после презентации многие присутствовавшие на ней высказались о том, что кегль основного текста и полей ввода в интерфейсе — мелковат. Получив задачу в трекере, я потратил всего пару минут, поправив одну переменную своей системы — чтобы поднять кегль на всех нужных полях и контролах, и еще 15 минут чтобы удостовериться что ничего действительно не сломалось ни на одном шаблоне. Ваша система изначально должна быть написана так, и только так, чтобы ее было можно легко скорректировать и улучшить, поддерживать и расширять. По-настоящему лаконичный и выразительный качественный код — невероятно мощно экономит время и нервы даже если вы работаете с проектом в одиночку. Кроме того, уважаемые авторитеты в коммерческом программировании утверждают [см. Роберт Мартин — «Чистая архитектура»] что «то что сделано изначально плохо» — в реальности, не только «никогда не будет переписано», но и приводит к постоянному крутому росту стоимости дальнейшей доставки нового функционала, а в перспективе способно полностью блокировать прогресс по проекту!

Хорошее понимание возможностей и ограничений современных браузерных технологий очень желательно и полезно не только для веб-разработчиков, но и для гуманитариев-дизайнеров проектирующих GUI. Часто даже востребованный специалист, выдающий приятный стиль и не делающих серьезных ошибок по UХ, не может внятно ответить на простейшие технические вопросы о своем дизайне при сдаче макета на верстку, то есть — «не понимает что рисует».

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

Кому будет полезен текст?

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

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

Дизайнерам. Вы веб-дизайнер, но хотите начать верстать.

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

Препроцессор

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

Препроцессор, JavaScript и фреймворки

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

Препроцессор

---

Простейший пример плохого кода

Безобразного кода с каждым днем становится все больше, несмотря на то, что больнее всего страдают от этого сами авторы, горе-разработчики. И если определенную функциональность или рендер можно покрыть тестами, то ошибки оформления выявляются только «ручками».

Также, просто парадоксально, что все программисты слышали о простых основополагающих принципах качественного программирования KISS и SOLID, но подавляющее большинство напрочь забывает о них, когда речь заходит об организации оформления, представления веб-интерфейса.

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

Давайте посмотрим на самый простейший пример плохого кода на CSS:

/* Примитивнейший пример обычного плохого кода на CSS */

/* Где-нибудь в файлах стилей: */

.selector--1 {
  width: 200px;
  height: 200px;
  border: 1px solid #ADADAD;
  border-radius: 3px;
  /* ... и дальше еще огромное количество самых разных правил */
}

.selector--2 {
  width: 200px;
  height: 400px;
  border: 1px solid #ADADAD;
  border-radius: 3px;
  /* ... и дальше еще огромное количество самых разных правил */
}

Не делайте так больше почти никогда! ))) Почему? Код валидный, «в браузере все по макету», да и все именно так обычно и пишут. Но все и не «верстают как бог», правильно? В контексте любого проекта чуть большего чем совсем крохотный, подобный код «плохой и чреват проблемами в будущем». Он конкретен и невыразителен, излишен, его сложно модифицировать и переиспользовать.

А как надо?

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

Справедливости ради, нужно упомянуть, что последние годы, в связи с стремительным ростом популярности компонентных js-фреймворков и их подходов, все больше сторонников набирают также различные «CSS-in-JS»-реализации (например: Styled Components). Скоро, вероятно, можно будет спокойно использовать переменные в самом CSS (CSS Custom Properties). Тема холиварная, существуют контексты и ситуации когда подобный CSS-in-JS подход может оказаться более оправданным и изящным, без сомнения. И даже существует масса реалистичных кейсов когда проще всего будет действительно обойтись несколькими наборами правил на CSS, а любое его расширение будет излишним. Но в общем случае, в реальной коммерческой практике, имхо, для верстки сложных дизайнов и интерфейсов удобнее и эффективнее всего сейчас использовать любой препроцессор, и, шок — даже с компонентным фреймворком, дальше я планирую показать «как именно это лучше всего делать». Препроцессоры дают максимум возможностей и позволяют стремиться к максимальной выразительности и переиспользуемости. Вот во что превратился бы «плохой код» выше в SCSS-синтаксисе, наверное — самого популярного на сегодняшний день препроцессора — Sass:

// В @/src/scss/utils/_variables.scss:

$colors__border: #adadad;

$border-radius: 3px;

// В @/src/scss/utils/_placeholders.scss:
%border-block {
  border: 1px solid $colors__border;
  border-radius: $border-radius;
}

// В @/src/scss/utils/_mixins.scss:
@mixin size($width, $height) {
  width: $width;
  height: $height;
}

// В любом месте проекта:
.selector {
  $selector--1__size: 200px;
  $selector--2__width: 200px;
  $selector--2__height: 400px;

  &--1,
  &--2 {
    @extend %border-block;
    /* ... включение других сущностей препроцессора
      и специфическиих правил общих для селекторов */
  }

  &--1 {
    @include size($selector--1__size, $selector--1__size);
    /* ... включение других сущностей препроцессора
      и специфических правил уникальных для селектора */
  }

  &--2 {
    @include size($selector--2__width, $selector--2__height);
    /* ... включение других сущностей препроцессора
      и специфических правил уникальных для селектора */
  }
}

Точно тоже самое легко сделать и на, кажется, недооцененном, но очень удачном Stylus — совершенно не важно какой именно расширенный синтаксис вы используете, главное как и зачем. Очень много раз мне приходилось видеть плохой чужой код написанный якобы для препроцессора, видимо, «потому что так сейчас модно», но, на самом деле, практически ничем не отличающийся от кода CSS. Не делайте так! Препроцессор дает нам крайне ценную возможность абстрагировать общие качества гайдлайна, стиль и основанные на нем частные стили, организовать их намного более выразительно и лаконично, легко модифицировать и переиспользовать при необходимости.

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

Первый пример демонстрирует что на начальных этапах развития проекта хорошо продуманного кода препроцессора может быть даже визуально несколько больше, чем неорганизованного, внутренне плоского, скучного CSS. Но давайте разберем очень часто встречающийся кейс, в котором мы очевидно сразу сильно экономим много трафика и явно оптимизируем возможную поддержку. Такое очень часто встречается: нам нужно создать большое количество, предположим — 20 штук — модификаторов одного селектора — квадратной иконки размеров в 100 пикселей — и поставить в них нужные картинки в бекграунд. В Sass мы можем написать цикл с интерполяцией для создания селектора модификатора и указания пути до ресурса. И хотя такая синтаксическая возможность не является чем-то идейно решающе важным — на практике она экономит кучу времени и повышает качество жизни на работе:

// В @/src/scss/utils/_variables.scss:

// Paths
$images__path--root: "../../assets/images/";

// Sizes 
$icons__size: 100px;

// Views
$icons: 20;

// В любом месте проекта (в папке В @/src/scss/project/):
.icon {
  // корректируем путь до картинок
  $image-path: $image_path--root + "icons/";

  @include size($icons__size, $icons__size); // эта примесь уже создана выше

  @for $i from 1 through $icons {
    &.icon--#{$i} {
      background: url("#{$image-path}icon--#{$i}.svg") center center no-repeat;
    }
  }
}

Пример предполагает что в вашем проекте следующая структура:

.
└─ src
   ├─ assets
   │  └─ images
   │     └─ icons 
   │        ├─ icon--1.svg
   │        ├─ icon--2.svg
   │        └─ ...
   └─ sscs
      ├─ project
      │  └─ ...
      └─ utils
         ├─ _mixins.scss
         └─ _variables.scss

Теперь в шаблонах мы можем использовать:

<div class="icon icon--1"></div>

Если вы желаете чтобы картинки были с осмысленными именами — можете перебирать список:

.icon {
  $image-path: $image_path--root + "icons/";
  $images: "name1", "name2", "name3"; // Список имен

  @include size($icons__size, $icons__size);

  @each $image in $images {
    &.icon--#{$image} {
      background: url("#{$image-path}#{$image}.svg") center center no-repeat;
    }
  }
}

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

.selector {
  $width: 100px;

  width: calc(100vw - #{$width});
}

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

Абстрагируй все!

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

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

// В @/src/stylus/utils/variables.styl:

$colors = {
  mint: #44c6a8,
  // ... другие конкретные значения цветов
}

// Создаем "основной цвет", абстрагируясь от конкретного цвета
$colors['primary'] = $colors.mint
// ... другие "функциональные" цвета

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

.selector
  color $colors.primary

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

Структура и стилевая база препроцессора

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

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

Но давайте уже организуем препроцессор, если с SCSS:

.
└─ src
   └─ sscs
      ├─ core // обшие и компилируемые сущности препроцессора
      │  ├─ _animations.scss // keyframes
      │  ├─ _base.scss // минимальная нормализация основных HTML-элементов
      │  ├─ _grid.scss // сетки
      │  ├─ _typography.scss // типографика
      │  └─ _utilities.scss // быстрые удобные классы-утилиты для включения прямо в разметку
      ├─ libraries // папка с файлами стилизаций сторонних модулей
      │  └─ _modal.scss - например какая-нибудь готовая модаль
      ├─ project // стили конкретного проекта
      │  ├─ _elements.scss // отдельные простые элементы-компоненты
      │  ├─ _fixes.scss // этот файл всегда должен быть практически пустой, и предназначен только для редких общеизвестных "собственных проблем браузеров"
      │  ├─ _layout.scss - стили общей для всех страниц GUI-обертки над контентом интерфейса
      │  └─ _widgets.scss - сложные составные комбинации простых элементов-компонентов
      ├─ utils // обшие и некомпилируемые основные сущности препроцессора
      │  ├─ _functions.scss // на практике нужны крайне редко
      │  ├─ _mixins.scss // параметризируемые и способные принимать контент примеси-микстуры
      │  ├─ _placeholders.scss // повторяющиеся наборы правил - растворы
      │  └─ _variables.scss // самый важный файл с переменными )
      ├─ _main.scss // точка сборки всех стилей препроцессора
      └─ _stylebase.scss // стилевая база

То есть, на самом деле — порядок сборки всей кухни имеет значение, конечно же:

// В @/src/scss/_stylebase.scss:
// Stylebase
//////////////////////////////////////////////////////
//////////////////////////////////////////////////////

// Uncompiled kitchen
@import "./utils/_functions";
@import "./utils/_variables";
@import "./utils/_mixins";
@import "./utils/_placeholders";

// Core base normal style and common utils
@import "./core/_animations";
@import "./core/_typography";
@import "./core/_base";
@import "./core/_grid";
@import "./core/_utilities";

// В @/src/scss/_main.scss:
// Project styles
//////////////////////////////////////////////////////
//////////////////////////////////////////////////////

// Stylebase for components
@import "_stylebase";

// App styles
@import "./project/_fixes";
@import "./project/_elements";
@import "./project/_widgets";
@import "./project/_layout";

/* External libraries customization */
@import "./libraries/_modal";

Итак, «стилевой базой» мы будем называть некое основное ядро стилей, доступный всем остальным компонентам системы общий код препроцессора. Более детально, он состоит из условно двух разных видов файлов:

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

   1. функции
   2. переменные
   3. параметризуемые примеси
   4. включения-плейсхолдеры

2. Компилируемые глобальные стили:

   1. анимации keyframes
   2. типографика
   3. базовая нормализация основных HTML-элементов
   4. сетки
   5. утилитарные классы-помощники для разметки

В папки @/src/scss/project и @/src/scss/libraries вы можете добавлять файлы по необходимости.

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

У меня вот, например, можно посмотреть — есть различные такие заготовки-«болванки» для быстрого старта на разных комбинациях актуальных технологий:

• React c TypeScript и Stylus;
• Vue c SCSS;
• Webpack c SCSS и Nunjucks.

Читать книжку дальше можно пройдя по ссылке: Как верстать веб-интерфейсы быстро, качественно и интересно.

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

Для примера возьмем задачу, которую решала наша команда по анализу документов различных форматов таких как docx, xlsx, pptx, jpeg, pdf и др. Для удобства последующей обработки данных было решено создать веб-приложение с понятным для пользователя интерфейсом и зашитым внутри кодом. Код Python для обработки документов был готов, и мы не будем на нем останавливаться, а расскажем о том, как решали задачу красиво его «упаковать» в небольшую программу с понятным интерфейсом. Для этого мы использовали инструмент Flask. Это микро-фреймворк со всеми средствами и библиотеками, необходимыми для создания веб-приложения на основе языка Python, его цель – решение базовых задач без излишней нагрузки на сервер. Еще одним преимуществом является то что на его изучение не потребуется много времени.

Установим Flask:

Создадим основной файл с именем app.py в корневом каталоге рабочей папки и пропишем базовый код для приложения:

Посредством файла app.py мы получили возможность доступа ко множеству функций библиотеки Flask, в т.ч. для отслеживания URL-адреса страницы. Для этого используется маршрутизация:

При переходе на главную страницу приложение будет отображать файл index.html – необходимо создать его в каталоге templates. Но сначала создадим шаблон base.html, из которого будем наследовать настройки страниц нашего приложения. В своем примере я пропишу базовую структуру без ввода дополнительных настроек:

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

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

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

Кнопка «Запуск», файл start.html

Кнопка «Итог», файл output_data.html

Теперь вернемся к файлу app.py:

Таким образом, мы познакомились с простым инструментом по созданию веб-приложений. Данный инструмент может быть интересен ИТ-специалистам, в чьи обязанности входят частые запросы коллег на выгрузку и обработку однотипных данных. Flask позволит создать красивую и понятную пользователю «упаковку» для ваших алгоритмов и кода.

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

Spring Boot

Spring Boot — один из самых популярных универсальных фреймворков для построения веб-приложений на Java. Создадим в среде разработки Gradle Project. Для облегчения работы воспользуемся сайтом https://start.spring.io, который поможет сформировать build.gradle.

Для начала нам необходимо выбрать следующие зависимости:

• Spring Web — необходим для создания веб-приложения;
• Spring Data JPA — для работы с базами данных;
• PostgreSQL Driver — драйвер для работы с PostgreSQL;
• Lombok — библиотека, позволяющая уменьшить количество повторяющегося кода.

В результате генерации build.gradle должно получиться что-то похожее:

plugins {
    id 'org.springframework.boot' version '2.4.3'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

group 'org.example'
version '1.0-SNAPSHOT'

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    compileOnly 'org.projectlombok:lombok:1.18.22'
    annotationProcessor 'org.projectlombok:lombok:1.18.22'
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.7.0'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.7.0'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    runtimeOnly 'org.postgresql:postgresql'
}

test {
    useJUnitPlatform()
}

Тот же результат можно получить и в самой IntelliJ Idea: File → New → Project → Spring Initializr.

Объявим Main-класс:

@SpringBootApplication
public class SpringDemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringDemoApplication.class, args);
    }
}

Опишем самый простой контроллер, чтобы удостовериться, что проект работает:

@RestController
public class HelloController {

    @GetMapping("/hello")
    public String hello(@RequestParam(required = false) String name) {
        return "Hello, " + name;
    }
}

Запустим проект в среде разработки или через терминал: ./gradlew bootRun.

Результат работы можно проверить в браузере перейдя по адресу http://localhost:8080/hello?name=World или с помощью консольной утилиты curl:

curl "http://localhost:8080/hello?name=World"
Hello, World

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

Представим, что нам требуется разработать некий сервис для интернет-магазина по продаже книг. Это будет rest-сервис, который будет позволять добавлять, редактировать, получать описание книги. Хранить данные будем в БД Postgres.

Docker

Для хранения данных нам потребуется база данных. Проще всего запустить инстанс БД с помощью Docker. Docker позволяет запускать приложение в изолированной среде выполнения — контейнере. Поддерживается всеми операционными системами.

Выкачиваем образ БД и запускаем контейнер:

docker pull postgres:12-alpine

docker run -d -p 5432:5432 --name db 
    -e POSTGRES_USER=admin 
    -e POSTGRES_PASSWORD=password 
    -e POSTGRES_DB=demo 
    postgres:12-alpine

Lombok

Создадим data-класс «книга». Он будет иметь несколько полей, которые должны иметь getters, конструктор и должна быть неизменяемой (immutable). Среда разработки позволяет автоматически генерировать конструктор и методы доступа к полям, но чтобы уменьшить количество однотипного кода, будем использовать Lombok.

Аннотация @Value при компиляции исходного кода добавит в наш класс getters, конструктор, пометит все поля класса private final, добавит методы hashCode, equals и toString.

@Value
public class Book {
    Long id;
    String author;
    String title;
    Double price;
}

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

javap -private build/classes/java/main/com/example/BookStore/model/Book

public final class com.example.bookstore.model.Book {
  private final java.lang.Long id;
  private final java.lang.String author;
  private final java.lang.String title;
  private final java.lang.Double price;
  public com.example.bookstore.model.Book(java.lang.Long, java.lang.String, java.lang.String, java.lang.Double);
  public java.lang.Long getId();
  public java.lang.String getAuthor();
  public java.lang.String getTitle();
  public java.lang.Double getPrice();
  public boolean equals(java.lang.Object);
  public int hashCode();
  public java.lang.String toString();
}

Lombok очень упрощает читаемость подобного рода классов и очень широко используется в современной разработке.

Spring Data JPA

Для работы с БД нам потребуется Spring Data JPA, который мы уже добавили в зависимости проекта. Дальше нам нужно описать классы Entity и Repository. Первый соответствует таблице в БД, второй необходим для загрузки и сохранения записей в эту таблицу.

@Data
@NoArgsConstructor
@AllArgsConstructor
@Entity
@Table(name = "books")
public class BookEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String author;

    private String title;

    private Double price;
}

Мы также используем аннотации Lombok: @Data добавляет getters и setters, @NoArgsConstructor и @AllArgsConstructor — конструкторы без параметров и со всеми параметрами, соответственно. @Entity, @Table, @Id, @GeneratedValue — аннотации относящиеся к JPA. Здесь мы указываем, что это объект БД, название таблицы, первичный ключ и стратегию его генерации (в нашем случае автоматическую).

Класс Repository будет выглядеть совсем просто — достаточно объявить интерфейс и наследоваться от CrudRepository:

public interface BookRepository extends CrudRepository<BookEntity, Long> {
    
}

Никакой реализации не требуется. Spring всё сделает за нас. В данном случае мы сразу получим функциональность CRUD — create, read, update, delete. Функционал можно наращивать — чуть позже мы это увидим. Мы описали DAO-слой.

Теперь нам нужен некий сервис, который будет иметь примерно следующий интерфейс:

public interface BookService {
    Book getBookById(Long id);// получить книгу по id
    List<Book> getAllBooks();// получить список всех книг
    void addBook(Book book);// добавить книгу
}

Это так называемый сервисный слой. Реализуем этот интерфейс:

@Service
@RequiredArgsConstructor
public class DefaultBookService implements BookService{
    private final BookRepository bookRepository;

    @Override
    public Book getBookById(Long id) {
        BookEntity bookEntity = bookRepository
                .findById(id)
                .orElseThrow(() -> new BookNotFoundException("Book not found: id = " + id));

        return new Book(bookEntity.getId(), 
                        bookEntity.getAuthor(), 
                        bookEntity.getTitle(), 
                        bookEntity.getPrice());
    }

    @Override
    public List<Book> getAllBooks() {
        Iterable<BookEntity> iterable = bookRepository.findAll();
        
        ArrayList<Book> books = new ArrayList<>();
        for (BookEntity bookEntity : iterable) {
            books.add(new Book(bookEntity.getId(), 
                               bookEntity.getAuthor(), 
                               bookEntity.getTitle(), 
                               bookEntity.getPrice()));
        }

        return books;
    }

    @Override
    public void addBook(Book book) {
        BookEntity bookEntity = new BookEntity(null, 
                                               book.getAuthor(), 
                                               book.getTitle(), 
                                               book.getPrice());
        bookRepository.save(bookEntity);
    }
}

Аннотацией @Service мы возлагаем на Spring создание объекта этого класса. @RequiredArgsConstructor — уже знакомая нам аннотация, которая генерирует конструктор с необходимыми аргументами. В нашем случае класс имеет final-поле bookRepository, которое необходимо проинициализировать. Добавив эту аннотацию, мы получим следующую реализацию:

public DefaultBookService(BookRepository bookRepository) {
    this.bookRepository = bookRepository;
}

При создании объекта класса Spring опять всё возьмёт на себя — сам создаст объект BookRepository и передаст его в конструктор. Имея объект репозитория мы можем выполнять операции с БД:

bookRepository.findById(id); //прочитать запись из БД по первичному ключу id
bookRepository.findAll(); //прочитать все записи из БД и вернуть их в виде списка
bookRepository.save(bookEntity); //сохранить объект в БД

Метод findById возвращает объект типа Optional<BookEntity>. Это такой специальный тип который может содержать, а может и не содержать значение. Альтернативный способ проверки на null, но позволяющий более изящно написать код. Метод orElseThrow извлекает значение из Optional, и, если оно отсутствует, бросает исключение, которое создается в переданном в качестве аргумента лямбда-выражении. То есть объект исключения будет создаваться только в случае отсутствия значения в Optional.

MapStruct

Смотря на код может показаться, что класс Book не нужен, и достаточно только BookEntity, но это не так. Book — это класс сервисного слоя, а BookEntity — DAO. В нашем простом случае они действительно повторяют друг друга, но бывают и более сложные случаи, когда сервисный слой оперирует с несколькими таблицами и соответственно DAO-объектами.

Если присмотреться, то и тут мы видим однотипный код, когда мы перекладываем данные из BookEntity в Book и обратно. Чтобы упростить себе жизнь и сделать код более читаемым, воспользуемся библиотекой MapStruct. Это mapper, который за нас будет выполнять перекладывание данных из одного объекта в другой и обратно. Для этого добавим зависимости в build.gradle:

dependencies {
    ...
    implementation 'org.mapstruct:mapstruct:1.4.2.Final'
    annotationProcessor 'org.mapstruct:mapstruct-processor:1.4.2.Final'
}

Создадим mapper, для этого необходимо объявить интерфейс, в котором опишем методы для конвертации из BookEntity в Book и обратно:

@Mapper(componentModel = "spring")
public interface BookToEntityMapper {
    BookEntity bookToBookEntity(Book book);
    Book bookEntityToBook(BookEntity bookEntity);
}

Так как имена полей классов соотносятся один к одному, то интерфейс получился таким простым. Если поля имеют отличающиеся имена, то потребуется аннотацией @Mapping указать какие поля соответствуют друг другу. Более подробно можно найти в документации. Чтобы spring смог сам создавать бины этого класса, необходимо указать componentModel = "spring".

После сборки проекта, в каталоге build/generated/sources/annotationProcessor появится сгенерированный исходный код mapper, избавив нас от необходимости писать однотипные десятки строк кода:

@Component
public class BookToEntityMapperImpl implements BookToEntityMapper {

    @Override
    public BookEntity bookToBookEntity(Book book) {
        if ( book == null ) {
            return null;
        }

        BookEntity bookEntity = new BookEntity();

        bookEntity.setId( book.getId() );
        bookEntity.setAuthor( book.getAuthor() );
        bookEntity.setTitle( book.getTitle() );
        bookEntity.setPrice( book.getPrice() );

        return bookEntity;
    }

    @Override
    public Book bookEntityToBook(BookEntity bookEntity) {
        if ( bookEntity == null ) {
            return null;
        }

        Long id = null;
        String author = null;
        String title = null;
        Double price = null;

        id = bookEntity.getId();
        author = bookEntity.getAuthor();
        title = bookEntity.getTitle();
        price = bookEntity.getPrice();

        Book book = new Book( id, author, title, price );

        return book;
    }
}

Воспользуемся мэппером и перепишем DefaultBookService. Для этого нам достаточно добавить добавить final-поле BookMapper, которое Lombok автоматически подставит в аргумент конструктора, а spring сам инстанциирует и передаст параметром в него:

@Service
@RequiredArgsConstructor
public class DefaultBookService implements BookService{
    private final BookRepository bookRepository;
    private final BookToEntityMapper mapper;

    @Override
    public Book getBookById(Long id) {
        BookEntity bookEntity = bookRepository
                .findById(id)
                .orElseThrow(() -> new BookNotFoundException("Book not found: id = " + id));
        
        return mapper.bookEntityToBook(bookEntity);
    }

    @Override
    public List<Book> getAllBooks() {
        Iterable<BookEntity> iterable = bookRepository.findAll();
        ArrayList<Book> books = new ArrayList<>();
        for (BookEntity bookEntity : iterable) {
            books.add(mapper.bookEntityToBook(bookEntity));
        }

        return books;
    }

    @Override
    public void addBook(Book book) {
        BookEntity bookEntity = bookMapper.bookToBookEntity(book);
        mapper.save(bookEntity);
    }
    ...

Теперь опишем контроллер, который будет позволять выполнять http-запросы к нашему сервису. Для добавления книги нам потребуется описать класс запроса. Это data transfer object, который относится к своему слою DTO.

@Data
public class BookRequest {
    private String author;
    private String title;
    private Double price;
}

Нам также потребуется конвертировать объект AddBookRequest в объект Book. Создадим для этого BookToDtoMapper:

@Mapper(componentModel = "spring")
public interface BookToDtoMapper {
    Book AddBookRequestToBook(BookRequest bookRequest);
}

Теперь объявим контроллер, на эндпоинты которого будут приходить запросы на создание и получение книг, добавив зависимости BookService и BookToDtoMapper. При необходимости аналогично объекту AddBookRequest можно описать Response-объект, добавив соответствующий метод в мэппер, который будет конвертировать Book в GetBookResponse. Контроллер будет содержать 3 метода: методом POST мы будем добавлять книгу, методом GET получать список всех книг и книгу по идентификатору, который будем передавать в качестве PathVariable.

@RestController()
@RequestMapping("/books")
@RequiredArgsConstructor
public class BookController {

    private final BookService bookService;
    private final BookToDtoMapper mapper;

    @GetMapping("/{id}")
    public Book getBookById(@PathVariable Long id) {
        return bookService.getBookById(id);
    }

    @GetMapping
    public List<Book> getAllBooks() {
        return bookService.getAllBooks();
    }
    
    @PostMapping
    public void addBook(@RequestBody AddBookRequest request) {
        bookService.addBook(mapper.AddBookRequestToBook(request));
    }
}

Осталось создать файл настроек приложения. Для Spring boot по умолчанию это application.properties или application.yml. Мы будем использовать формат properties. Необходимо указать настройки для соединения с БД (выше мы задавали пользователя и его пароль при старте docker-контейнера):

spring.datasource.url=jdbc:postgresql://localhost:5432/demo
spring.datasource.username=admin
spring.datasource.password=password
spring.datasource.driver-class-name=org.postgresql.Driver
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true

Настройка spring.jpa.hibernate.ddl-auto=update указывает hibernate необходимость обновить схему когда это нужно. Так как мы не создавали никаких схем, то приложение сделает это автоматически. В процессе промышленной разработки схемы баз данных постоянно меняются, и часто используются инструменты для версионирования и применения этих изменений, например Liquibase.

Запустим наше приложение и выполним запросы на добавление книг:

curl -X POST --location "http://localhost:8080/books" 
    -H "Content-Type: application/json" 
    -d "{
          "author" : "Joshua Bloch",
          "title" : "Effective Java",
          "price" : 54.99
        }"
        
curl -X POST --location "http://localhost:8080/books" 
    -H "Content-Type: application/json" 
    -d "{
          "author" : "Kathy Sierra",
          "title" : "Head First Java",
          "price" : 12.66
        }"
        
curl -X POST --location "http://localhost:8080/books" 
    -H "Content-Type: application/json" 
    -d "{
          "author" : "Benjamin J. Evans",
          "title" : "Java in a Nutshell: A Desktop Quick Reference",
          "price" : 28.14
        }"

После выполнения запросов в таблице books должны появиться записи. Чтобы удостовериться в этом, можно использовать любой удобный клиент БД. Для примера сделаем это, используя консольный клиент, входящий в состав docker-контейнера. При создании контейнера, мы указали его имя ‘db’ (если имя не задавалось, то можно вывести список всех запущенных контейнеров командой docker container ls, и дальше использовать идентификатор нужного контейнера). Для доступа к шелл-оболочке выполним:

docker exec -ti db sh

Запустим клиент БД и выполним sql-запрос:

psql --username=admin --dbname=demo
psql (12.6)
Type "help" for help.

demo=# SELECT * FROM books;
 id |      author       | price |                     title                     
----+-------------------+-------+-----------------------------------------------
  1 | Joshua Bloch      | 54.99 | Effective Java
  2 | Kathy Sierra      | 12.66 | Head First Java
  3 | Benjamin J. Evans | 28.14 | Java in a Nutshell: A Desktop Quick Reference
(3 rows)

Получим список всех книг:

curl -X GET --location "http://localhost:8080/books" 
    -H "Accept: application/json"

[
  {
    "id": 1,
    "author": "Joshua Bloch",
    "title": "Effective Java",
    "price": 54.99
  },
  {
    "id": 2,
    "author": "Kathy Sierra",
    "title": "Head First Java",
    "price": 12.66
  },
  {
    "id": 3,
    "author": "Benjamin J. Evans",
    "title": "Java in a Nutshell: A Desktop Quick Reference",
    "price": 28.14
  }
]

Получим книгу через запрос к api нашего сервиса, указав идентификатор книги:

curl -X GET --location "http://localhost:8080/books/2" 
    -H "Accept: application/json"

{
  "id": 2,
  "author": "Kathy Sierra",
  "title": "Head First Java",
  "price": 12.66
}

Добавим к нашему api более сложную функциональность — поиск по автору книги. Для этого в BookRepository нужно описать метод, который будет делать соответствующий SELECT из БД. Это можно сделать с помощью аннотации @Query, а можно назвать метод в соответствии со специальной нотацией Spring:

List<BookEntity> findAllByAuthorContaining(String author);

В документации можно подробнее прочитать об именовании методов. Здесь мы указываем findAll — найти все записи, ByAuthor — параметр обрамляется %. При вызове этого метода (например с аргументом ‘Bloch’) будет сгенерирован следующий запрос:

SELECT * FROM books WHERE author LIKE '%Bloch%';

Далее добавим метод в BookService и DefaultBookService:

@Override
public List<Book> findByAuthor(String author) {
    Iterable<BookEntity> iterable = bookRepository.findAllByAuthorContaining(author);
    ArrayList<Book> books = new ArrayList<>();
    for (BookEntity bookEntity : iterable) {
        books.add(mapper.bookEntityToBook(bookEntity));
    }

    return books;
}

А в контроллере немного модифицируем метод получения списка книг таким образом, что при передаче get-параметра author мы искали по автору, а если параметр не передётся, то используется старая логика и выводится список всех книг:

@GetMapping
public List<Book> getAllBooks(@RequestParam(required = false) String author) {
    if (author != null)
        return bookService.findByAuthor(author);

    return bookService.getAllBooks();
}

Теперь можно выполнить поиск:

curl -X GET --location "http://localhost:8080/books?author=Bloch" 
    -H "Accept: application/json"
[
  {
    "id": 1,
    "author": "Joshua Bloch",
    "title": "Effective Java",
    "price": 54.99
  }
]

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

Код проекта доступен на GitHub.

Компьютерный код и пиксели — это больше, чем просто кирпичи, — основа экономики XXI века. Если вы когда-либо просматривали «Источник страницы» или «Инструменты разработчика» в своем браузере, вы, скорее всего, столкнулись с беспорядком текста и удивились, как это работает на веб-странице.

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

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

Веб-дизайн против фронт-энда

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

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

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

,

Интерфейс Интернета: разметка, таблица стилей и языки программирования

Большинство веб-страниц построены с использованием трех технологий: языка разметки гипертекста (HTML), каскадных таблиц стилей (CSS) и JavaScript (JS):

• Языки разметки, такие как HTML, помечают документ тегами. Теги разграничивают семантическое содержание и структурируют документ. Структурированные документы могут быть стилизованы.
• CSS является языком таблиц стилей и потомком указателей стиля печати к компоновщику страниц (который создает окончательное печатное изображение для печатного станка); в Интернете CSS диктует представление контента, такого как типография и верстка в целом, а также размещение графики.
• JavaScript, в отличие от двух предыдущих, является языком программирования. JS управляет взаимодействием и пользовательским вводом и фокусируется на событиях, которые производит пользователь. Чтобы заполнить картину немного больше, противоположность парадигме, управляемой событиями, — это та, где программирование выполняется независимо от пользовательского ввода.

HTML

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

Зачем тебе это нужно

Почему HTML все еще важен? Проще говоря, в HTML заключается семантическое значение вашего контента. Это необходимо для машинных читателей, таких как поисковые машины и программы для чтения с экрана (для доступности). Со временем актуальность разделения того, что является семантическим, и того, что является структурным, со временем выросла, а не уменьшилась. В самой последней версии HTML (5) были введены такие теги, как,, и, для уточнения семантики и структуры. Это приносит пользу как читателям, так и людям.

Анатомия элемента HTML

Элементы HTML, как минимум, являются парами

) Скомпилировать

Джейд | Требуется Node.js (введение вы найдете здесь

) Скомпилировать

Slim | Требуется Ruby для компиляции (как указано выше)

CSS

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

Зачем тебе это нужно

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

Обратите внимание на то, что кроме типографики и цвета меню без стилей является вертикальным, потому что это стиль браузера по умолчанию. Маловероятно, что вы захотите воссоздать Интернет 1990-х годов, поэтому вы хотите, чтобы здоровая и непрерывная порция знаний CSS была по-настоящему компетентной. Кроме того, с появлением различных по размеру и подключенных устройств, таких как iPhone, планшеты и т. Д., Одним из наиболее важных навыков стал «Адаптивный дизайн» или веб-страницы, которые адаптируются к экранам разных размеров. Все это выполняется с помощью CSS.

Анатомия правила CSS

Правила CSS написаны в одном из трех мест: а) встроенный в элемент, б) путем создания раздела в теге HTML-документа, в) в отдельной таблице стилей, такой как style.css.

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

Правила CSS начинаются с селектора, написанного зеленым цветом ниже. В этом случае селектором правила будет p для абзаца: правило применяется к элементам абзаца. Правило заключено в {фигурные скобки}, в отличие от. В этом случае правило делает шрифт для текста абзаца нормальным.

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

Дополнительный кредит (продвинутый)

Как и HTML, CSS имеет свои оптимизации для тех, кто хочет достичь большего и быстрее.

• SASS (и SCSS) | Требуется Ruby, как указано выше
• Меньше | Требуется Node.js, как указано выше

JavaScript

Когда многие люди думают о кодировании, они думают об этом как о том, как наставлять компьютер, как что-то делать. Это задача языка программирования, нашего последнего дополнения к внешнему уравнению.

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

Зачем тебе это нужно

Зачем учить JavaScript? Как отмечает мой коллега, в JavaScript есть свои чемпионы и недоброжелатели

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

Тем не менее, vanilla JS не заходит слишком далеко — фреймворки отвечают за современные веб-страницы.

Популярные рамки

• Angular, Google JS Framework для веб-приложений, таких как GMail и другие.
• JQuery

  , уже охваченный MUO здесь

  , который работает WordPress среди других приложений.

• React, созданный техническими легионами Facebook, создан для создания пользовательских интерфейсов.

Дополнительный кредит (продвинутый)

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

• CoffeeScript | Требуется Node.js, как указано выше
• Машинопись | Требуется Node.js, как указано выше

С чего начать обучение

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

• Coursera (Платная)
  Coursera собирает онлайн-курсы от университетов и учебных заведений. Диапазон цен падает от 50-250 долларов США за курс, но они рекламируют высокий уровень знаний и результаты высокой компетентности.
• Dash Генеральной Ассамблеи (бесплатно)
  Генеральная Ассамблея является популярным вариантом платного профессионального образования. Dash является их бесплатным предложением и охватывает HTML / CSS / JS.
• MakeUseOf.com — пакет «Учимся кодировать 2017» (платный, подключаемый модуль)
  Пожизненный доступ к 10 классам, охватывающим всю гамму веб-разработки на передней и задней части, всего за 20 долларов США.
• Сеть разработчиков Mozilla (бесплатно)
  MDN является авторитетным, но больше походит на стиль документации, чем на обучение в стиле классной комнаты или игровые предложения только для онлайн.
• Treehouse (Платный)
  Еще одно онлайн предложение, платное за месяц, а не за курс. Это происходит по рекомендации Карен X Ченг в ее вирусном издании Medium «Как устроиться на работу дизайнером, не посещая школу дизайна».
• Учебные пособия по веб-дизайну от Envato Tuts + (Смешанное бесплатное и платное содержимое одинакового качества)
  Совокупность одноразовых статей и многокомпонентных серий высококачественной, конкретной и целевой информации, обычно по одному предмету.

Начиная

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

• Текстовые редакторы, такие как текстовый редактор Git Atom, Sublime Text (платный) или VS Code от Microsoft
• Браузеры, такие как Mozilla Firefox или Google Chrome
• Полезно, но за рамками этой статьи, настроить хостинг или локальный сервер (например, XAMPP).

Более удобными, но менее постоянными альтернативами являются живые веб-редакторы, такие как:

• Codepen.io
• JSbin.com

Короткие сокращения

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

• Bootstrap, изначально разработанный Twitter, содержит шаблоны HTML, CSS и JS, которые сегодня широко распространены в Интернете. Bootstrap — почти лингва франка в начале веб-разработки.
• Фонд позиционирует себя как наиболее продвинутый фреймворк в мире и построен с акцентом на небольшой размер и скорость.

Справочный материал

• A List Apart — A-list публикация «Для людей, которые делают сайты»
• Могу ли я использовать — «Поддержка таблиц для HTML5, CSS3 и т. Д.»
• CSS-Tricks — центр для сообщества CSS и источник знаний о лучших практиках и совместимости
• Документация HTML Living Standard — «Стандарт жизни — издание для веб-разработчика»
• HTML5 Пожалуйста — «Используйте новые и блестящие ответственно»
• Smashing Magazine — «Для профессиональных веб-дизайнеров и разработчиков»

Заключение

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

Разработчики: Что у вас в стеке переднего плана?

Начинающие: Что еще мы могли бы включить, чтобы сориентировать вас?