Фронтендер это кто: Что должен уметь фронтенд-разработчик / Блог компании Нетология / Хабр

Что умеет выдающийся Frontend разработчик? — Хабр Q&A

> Я могу себе представить требования к backend, потому что backend сложнее.
Нет

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

> Там разного рода масштабирования, linux и sql.
Во фронте много js, json, xml, CS, много зрелых технологий на изучение которых требуется много времении сил, много новых технологий.

> А вот требования к frontend разработчику высокого уровня мне представить сложно. Тут один достаточно простой (по сравнению) ЯП, приходящие модные технологии вроде babel, webpack и TypeScript, которые еще сильнее упрощают работу и какой-нибудь фреймворк.
А как же webassembly, html5, RMTP, и другое медиа? Флэш сейчас уступил место JS и HTML5, но это только расширяет возможности использования.

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

> Фронтенд не масштабируется, не реплицируется.
Так можно говорить, если переложить всю работу на бэкенд. А правильно — грамотно распределять что делает фронтенд, что делает бэкенд и оптимизировать передачу данных. Это оба специалиста должны сотрудничать.

> В целом, если его очень хорошо протестировать, то разработчик уверен на 99.9%, что все работает на всех браузерах и на всех утройствах. Здесь не может быть ситуации, когда пришло слишком много пользователей или память на сервере закончилась.
Ну как это не может? Вы знаете все устройства, где запустится ваше вебприложение? А если на смарттв? А если на нонейм планшете? А если это голосовой чат в веб-приложении на 50 человек?

> Тут нет мониторинг систем.
Зато есть понимание метрик, их сбора, и отправки на бэкенд или куда-то еще?

Вдобавок фронтенд, в отличие от бэкенда, ОЧЕНЬ быстро прогрессировал за последние несколько лет. Настолько быстро, что хороших специалистов крайне сложно найти — они просто не успевают изучить все, что на них падает. Бэкенд постабильнее, там печатные книги успевают выйти в 10-м издании.

Как выжить и стать frontend разработчиком в современном мире? / Хабр

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

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

Речь пойдет о пути (или дорожной карте), который должен пройти начинающий специалист, чтоб «войти» в IT и стать хорошим разработчиком.

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

Рис.1 — Весь секрет успеха просто в трех мониторах.

С чего начать?

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

Конечно многие могут поспорить с тем, а нужны ли алгоритмы или какие-то паттерны во фронтенде, но современные реалии диктуют свои жесткие условия. Многие пытаются сразу же приступать к изучению популярных javascript фреймворков, таких как angular или react не понимая того, что делают. Все это можно сравнить с человеком, который идет в темном туннеле на какой-то свет. Но не очень понятно, к чему этот свет приведет и что вообще там дальше. Гораздо лучше, когда ты знаешь какие подводные камни тебя ожидают в этом туннеле и что у тебя под ногами. И вообще, из чего состоит этот туннель и нужно ли по нему идти. О чем это я? А о том что зная основы программирования, алгоритмы, понимая паттерны проектирования , ты будешь понимать, что «под капотом» у того или иного фреймворка, какие у него есть подводные камни, стоит ли вообще обращать на него внимание. Вот с этого и нужно начать свой путь. На это и нужно обратить свое внимание в самом начале.

Где приткнуть голову?

Далее есть несколько вариантов развития событий. Какой из них лучше — решать вам.

• Школа программирования. Отличное решение для старта вашего развития. И если в курс обучения будут входить вышеописанные вещи, это будет плюсом вам в карму. Но не ожидайте чуда. Потому что за вас никто не будет писать код и составлять алгоритмы. Все, что вам предоставят — это нужную подачу информации, которая будет уже отобрана специально для вас. Еще одни большим плюсом являются практические уроки с ментором. Когда на все твои вопросы ты моментально получаешь наглядный ответ. Всегда стоит задуматься над таким вариантом старта, но при этом держа в голове мысль о том, что нужно самому очень много работать. Все что вам предоставят — это материал и менторство. Минус является то что зачастую весь курс обучения очень растянут и то что можно выучить за месяц можно учить за четыре, а то и полгода, хотя может для Вас это будет наоборот плюс?
• Онлайн курсы. Очень интересный выбор. Большинство таких онлайн курсов проходят в виде интенсивов. Здесь тоже есть личный ментор и даже домашнее задание, а по окончанию курса обязательно парочка выполненных проектов в портфолио. О том, сложно ли найти хорошие онлайн курсы, я умолчу. Есть из чего выбрать.
• Самоучка. Наверное, это один из лучших вариантов развития событий, но не для каждого. Очень прекрасно, когда ты самостоятельно разобрался с материалом, усвоил его и закрепил на практике. От этого можно получить очень много профита и зачастую работодатели ценят такие кадры. Выбрать из мусора алмаз это еще нужно уметь, и если у вас есть в кармане такой навык, вам очень повезло и вы быстро будете расти как специалист. При таких раскладах курсы не нужны, разве что, для того чтоб стать совсем «скилловым». Не открою большой тайны если скажу что в большинстве курсов и видеоуроков малой и средней ценовой категории используют материалы из современных книг программирования. Советую обратить на это внимание и возможно вы не потратите деньги впустую. А знания при прочтении хотя б одной такой книги с пониманием — будет более чем глубокими.
• Стажировка в компании. Здесь дают возможность окунуться в сферу IT с ног до головы. Но не каждому выпадает такая возможность, а только тем у кого уже есть какой-то багаж знаний за плечами. Будьте готовы выполнять тестовые задание, чтоб попасть на стажировку. Но оно того стоит, это прямой путь к приему на работу.

Итак, что выбрать решать вам. А что далее? А далее происходит самое интересное. Работа.

Ожидание. Реальность

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

С чего начать поиск работы

Для frontend разработчика незаменимая вещь для трудоустройства являться его портфолио. Мало того что вы делаете свой реальный проект так вам еще и будет что показать работодателю. Это очень хорошая практика, и после изучения материала сразу же к ней нужно приступить. Здесь и можно «понюхать порох». Если вы добавите в свое портфолио несколько личных проектов, то считайте что вы обречены на успех. Но не нужно надеяться что все так легко, открыв некоторые вакансии понимаешь что еще учиться лет 10 для уровня «Джуна». Порой компании требуют знания языков С++, PHP и С# вместе на позицию верстальщик. Да, и такое бывает. Наверное они просто в поисках разносторонних личностей.

Вернемся во frontend

И вот вы junior frontend developer, сделав портфолио, впервые заполнив свое резюме вступаете в новый челлендж «выжить любой ценой». Angular, React, Redux, Vue.js, EcmaScript 6 и проч. С каждым годом требования к специалисту все больше и больше. И понять на что обращать внимание очень сложно. Для некоторых компаний будет достаточно знаний JavaScript, для иных нужен полный стэк технологий. На все это не нужно обращать внимание если у вас есть цель. Цель стать хорошим разработчиком.

Крепко зная основу, вы сможете овладеть любым современным фреймворком и это главное. Не нужно привязываться к контексту. Каждый фреймворк имеет свой срок и нужно это понимать. Если вы бросите все силы на изучения React а через несколько лет процент его использования будет очень близко приближен к нулю то что тогда делать? Зная и понимая как все устроено «под капотом» вы будете всегда на высоте. Главное не сдаваться и терпеливо идти к своей цели. .

Чем отличается верстальщик от front-end developer? — Хабр Q&A

Верстальщик преобразует графический макет (Photoshop или иной) в набор HTML + CSS + картинки. Иногда к свёрстанному макету может подключить типовые библиотеки Javascript, например, slider для картинок, или всплывающие подсказки (tooltip), или диалоговые окна (dialog/popup).
Знания и навыки:

• работа с графическими программами, чтобы понять, как собран макет
  
• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты и другие технологии
  
• пригодятся знания по HTML-фреймворкам, например, Twitter Bootstrap или Semantic UI
• навыки кроссбраузерной вёрстки, чтобы в разных браузерах выглядело и работало одинаково
  
• навыки отзывчивой вёрстки, чтобы можно было использовать на устройствах с разными возможностями и разрешениями
  
• знание типовых решений javascript, чтобы реализовать простейшие вещи, заложенные в макете
  

Фронтенд-разработчик делает так, чтобы макеты, полученные от верстальщика, были наполнены реальными данными. Если приложение построено как client-side (то есть вся основная логика загружается в виде огромного javascript в браузер, а данные запрашиваются с сервера по AJAX; это называется «толстый клиент»), то фронтенд-разработчику потребуется следующее:

• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты, Comet и другие технологии
• глубокое знание Javascript, включая использование готовых фреймворков, библиотек и написание расширений для них, что подразумевает объектно-ориентированное и событийное программирование
  
• знание AJAX, CORS и навык создания тестовых затычек на стороне сервера, чтобы можно было разрабатывать приложение пока бакенд не готов
  

Если фронтенд строится на стороне сервера, то дополнительно потребуется знать используемый серверный язык программирования (например, Python, Ruby или PHP) и используемый фреймворк (Django, Ruby-on-Rails, Yii). На практике бывало такое, что фронтендер просил в нужной части проекта сделать var_dump от структуры данных, которую надо показать и перечислить серверные методы, которые надо вызвать по нажатию предполагаемых кнопок.

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

И моё личное мнение — фронтенд разработчику не помешают базовые знания про UML. Иногда с ними так тяжело обсуждать обмен данными по AJAX. У них это какой-то непрерывный поток магической энергии, волшебным образом преобразующийся в буковки на экране пользователя, а вот для бакенда это набор отдельных операций, иногда ещё и асинхронный. Диаграммы последовательностей ни читать, ни писать многие не умеют. Таймлайны составлять не умеют.

————

Написал дополнение: copist.ru/blog/2015/08/29/layout-designer-vs-front…

Frontend-разработчики должны быть в теме всего / Хабр

Мысли Криса Койера

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

От переводчика

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

Содержание

1. Frontend-разработчик должен разбираться в дизайне
2. Frontend-разработчик должен разбираться в работе серверной части (backend)
3. Frontend-разработчик должен разбираться в работе сетей
4. Frontend-разработчик должен разбираться в производительности
5. Frontend-разработчик должен разбираться в контент-стратегии
6. Frontend-разработчик должен разбираться в базах данных
7. Frontend-разработчик должен разбираться в тестировании
8. Frontend-разработчик должен разбираться в системах сборки
9. Frontend-разработчик должен разбираться в методологиях разработки
10. Frontend-разработчик должен разбираться в настройке веб-серверов
11. Frontend-разработчик должен разбираться в юзабилити
12. Frontend-разработчик должен разбираться в мобильном дизайне

Frontend-разработчик должен разбираться в дизайне

Если frontend-разработчик не является сам по себе дизайнером, он должен знать, насколько важен дизайн. Он должен иметь хороший вкус. Он должен знать об инструментах, участвующих непосредственно в разработке.

К прочтению:

1. Памятка дизайнеру сайтов
2. Принцип цикады и почему он важен для веб-дизайнеров
3. Стив Круг «Веб-дизайн или Не заставляйте меня думать»
4. Якоб Нильсен «Веб-дизайн»
5. Дональд Норман «Дизайн привычных вещей»
6. Джеф Раскин «Интерфейс»
7. Как за 15 лет изменились главные страницы Apple, Microsoft, IBM, Sony
8. Ководство
9. О дизайне
10. Почему курсор мыши наклонён на 45°?
11. Наберитесь смелости сделать не как все. 12 устаревших интерфейсных и технологических решений
12. Имена людей и интерфейс
13. User experience design: как построить сайт для клиентов, а не для себя
14. Главные особенности китайского веб-дизайна и их истоки

Frontend-разработчик должен разбираться в работе серверной части (backend)

Даже если вы и не backend-разработчик, то вы явно осознаёте всю важность серверной части. Вы понимаете, с чем взаимодействует backend, что передается на сервер, а что нет. Вы знаете об обязанностях backend-разработчика. Вы понимаете, какой язык используется на сервере, и при этом должны уметь объяснить, что должен дать вам backend и что нужно от серверной части frontend-а.

К прочтению:

1. Чему мы научились, разрабатывая backend
2. Собеседование на должность PHP Backend Developer в Германии
3. Пишем backend для мобильного приложения за несколько минут
4. Что должно быть впереди фронтэнд или бекенд?
5. Что нужно знать, чтобы стать Backend разработчиком?
6. Что должен знать «PHP Junior Developer без опыта работы»?
7. Какими технологиями должен обладать backend разработчик (уровень начальных знаний — новичок+)?

Frontend-разработчик должен разбираться в работе сетей

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

К прочтению:

1. Принципы работы сети Интернет
2. Архитектура и принципы работы сети
3. Принцип работы торрент-сетей и как достигается высокая скорость
4. Руководство по TCP/IP для начинающих
5. Domain Name Service — cлужба Доменных Имен

Frontend-разработчик должен разбираться в производительности

Если вы не сосредоточены на производительности, то знаете, что производительность имеет важное место в успехе вашего проекта. Frontend-разработчики знают об этом нелегком мире. Нужные навыки помогут вам одержать быструю победу в долгой борьбе. Необходимо понимать насколько быстрым должен быть backend, а также, что оставшиеся 80% времени это загрузка сайта, т.е. это frontend.

К прочтению:

1. Производительность web: Why Performance Matters
2. Тонкости производительности
3. Выигрыш в производительности для rel=noopener
4. Измерение производительности веб-страниц
5. Улучшаем UX посредством оптимизации
6. Подходы к оптимизации (веб-)приложений
7. Пример веб-производительности
8. Производительность рендеринга картинок в Web
9. 10 Ways to Test Your Website Performance

Frontend-разработчик должен разбираться в контент-стратегии

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

К прочтению:

1. Как создать контент-стратегию, которую будут обсуждать
2. Супер контент-стратегия. 5 успешных примеров
3. Нужна ли контент-стратегия при наполнении сайта?
4. Эрин Киссейн «Основы контентной стратегии»
5. Как построить SMM-стратегию: пошаговый план продвижения в социальных сетях
6. Как оптимизировать контент для SEO и SMM?

Frontend-разработчик должен разбираться в базах данных

Контент хранится в базе данных. База данных должна корректно работать с контентом. А frontend-разработчик должен уметь работать с тем, что приходит ему из этой самой базы данных. Frontend-разработчику при работе с ответом базы данных нужно уметь комбинировать контент с шаблонами на сайте.

К прочтению:

1. Введение в базы данных
2. Базы данных: SQL (DDL/DML)
3. Ускоряем базу данных веб-сайта
4. Веб-интерфейс для баз данных размером в один .php файл
5. Возможности PostgreSQL, которых нет в MySQL, и наоборот
6. HTML 5. Работа с Web SQL базой данных
7. Базы данных и NoSQL
8. Как отобразить 350 миллионов строк из базы данных на Web-форме
9. Встраиваемая JavaScript база данных с прицелом на API совместимость с MongoDB

Frontend-разработчик должен разбираться в тестировании

Существует большое количество видов тестирования. Интеграционное тестирование. Регрессионное тестирование. Пользовательское тестирование!

К прочтению:

1. Тестирование программного обеспечения
2. Зачем нужны тесты?
3. Модульные тесты и интеграционные: в чём разница?
4. Тестирование
5. JavaScript Testing курс (eng)
6. QUnit. Тестирование javascript кода
7. Как развиваться начинающему тестировщику?
8. Повышаем стабильность Front-end
9. Бек Кент. Экстремальное программирование. Разработка через тестирование
10. Пишем свой первый юнит-тест, на примере методологии BDD и библиотеки Jasmine
10. Процесс тестирования мобильных приложений
11. Макгрегор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения
12. Тестирование JS. Кармический Webpack

Frontend-разработчик должен разбираться в системах сборки

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

К прочтению:

1. Webpack – один из самых мощных и гибких инструментов для сборки frontend
2. Grunt — Обзор системы сборки
3. Автоматизация сборки
4. Приятная сборка frontend проекта
5. Сравнение популярных систем сборки для frontend-разработчиков
6. Grunt vs Gulp сравнение систем сборки для front-end разработчика
7. Gulp или Grunt, да всё равно
8. Методология сборки БЭМ-проекта

Frontend-разработчик должен разбираться в методологиях разработки

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

К прочтению:

1. Необходимый минимум для фронтенд-разработчика
2. Методологии фронтенд-разработки
3. Советы front-end разработчику
4. Какими знаниями должен обладать Front-end разработчик в 2015 году
5. Что нужно знать и уметь front end разработчику в 2015/2016
6. Карта развития веб-разработчика
7. Основные навыки фронтенд-разработчика
8. Isobar Front-end Code Standards
9. Front-end Style Guides
10. JavaScript Style Guide
11. Coding style (Mozilla)

Frontend-разработчик должен разбираться в настройке веб-серверов

Без них не было бы веб-сайтов.

К прочтению:

1. Основные типы серверов
2. Что такое веб-сервер
3. Веб-сервер
4. Простым языком об HTTP
5. Веб-сервисы в теории и на практике для начинающих
6. Сравнение веб-серверов
7. Web-сервера и их использование для управления нагрузкой на приложение.
8. PHP. Встроенный web-сервер
9. Локальный веб-сервер
10. Использование преимуществ встроенного PHP сервера
11. Как поднять сервер для python скриптов за 1 минуту

Frontend-разработчик должен разбираться в юзабилити

Если frontend-разработчик не очень хорошо разбирается в юзабилити, в любом случае он должен понимать насколько это важно. Необходимо уметь тестировать и налаживать юзабилити. Frontend-разработчик должен знать, с кем поговорить на эту тему.

К прочтению:

1. Юзабилити
2. Юзабилити сайта
3. 10 советов по юзабилити сайта, основанных на результатах исследований
4. Основы юзабилити (usability) сайтов
5. Юзабилити-тестирование (ИТМО)
6. Usability vs. User Experience
7. What is the difference between UX and UI designer and web designer?

Frontend-разработчик должен разбираться в мобильном дизайне

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

К прочтению:

1. Лучшие практики по мобильному UX от Ника Бабича
2. Адаптивный веб-дизайн
3. Responsive Web Design: What It Is And How To Use It
4. Книга Итана Маркотта «Отзывчивый веб-дизайн»
4. 10 адаптивных фреймворков для веб-дизайна
5. Responsive Web Design Fundamentals курс (eng)

Заключение

Это всего лишь часть того, что должен знать frontend-разработчик. Чем больше, тем лучше. Все это, конечно, познается в работе. HTML, CSS, JavaScript, адаптивный дизайн, библиотеки и фреймворки — этот список может долго не заканчиваться.

Docker для фронтендера. Часть 1. Зачем? / Хабр

Привет, Хабр!

Несколько месяцев назад я выступал на конференции FrontendConf 2019 с докладом Docker для фронтендера и хотел бы сделать небольшую расшифровку доклада для тех, кто больше любит читать, а не слушать.

Приглашаю под кат всех веб-разработчиков, особенно фронтендеров.

1. Docker для фронтендера. Часть 1. Зачем?
2. Docker для фронтендера. Часть 2. Что ты такое?
3. Docker для фронтендера. Часть 3. Немного рецептов

Docker инструмент не новый, он впервые был опубликован ещё в марте 2013 года и с тех пор его популярность только растёт.

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

Вот такая игрушка была на конференции РИТ++ 2019 в рамках DevOps-секции. И по моему опыту ни одна конференция по DevOps не проходит без докладов про Docker, так же, как и фронтендерские конференции не проходят без докладов про сравнение фреймворков, настройку вебпака и профессиональное выгорание.

Давайте и мы во фронтенд-тусовке тоже начнём говорить про эту технологию.

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

Docker тут тоже присутствует, но где в недрах ветки развития DevOps‘а в блоке Infrastructure as a code -> Containers.

Но мы знаем, что Docker — это ещё и отличный инструмент для разработки, а не только для эксплуатации. И, по моему мнению, он имеет все шансы через некоторое время попасть в секцию Required for any path и стать обязательным требованием во многих вакансиях фронтенд-разработчиков.

Можно сказать, что мы сейчас живём в Эру Docker. Поэтому, если вы фронтенд-разработчик и ещё с ним не познакомились, то я расскажу, почему это стОит сделать.

Кейс 1. Поднимаем backend

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

На одном из наших проектов фронтенд-разработчику нужно было поставить на компьютер вот такой набор, чтобы API заработал:

* go1.11
* MySQL
* Redis
* Elasticsearch
* Capistrano
* syslog
* PostgreSQL

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

1. Установить GVM (https://github.com/moovweb/gvm)
2. `gvm install go1.11.13 --binary`
3. `gvm use go1.11.13 --default`
4. В папке с проектом создать ссылку на golang (`gvm linkthis`)
5. Установить `gb` `go get github.com/constabulary/gb/...`
6. Настроить авторизацию `git config --global url."[email protected]:".insteadOf "https://git.example.com/"`
7. Установить зависимости `gb vendor restore`
8. Поднять БД
9. Собрать ассеты `npm run build` (`npm run build:dev` для разработки)
10. Запустить сервер `npm start`

И вот так:

## Elasticsearch
1. Скачать и установить Elasticsearch `brew install elasticsearch` - macOS (предложит установить дистрибутив java)
2. Установка плагина
* выбери в https://github.com/imotov/elasticsearch-analysis-morphology из списка подходящий к твоей версии плагин, и запусти
`/usr/local/Cellar/elasticsearch/2.3.3/libexec/bin/plugin install http://dl.bintray.com/content/imotov/elasticsearch-plugins/org/elasticsearch/elasticsearch-analysis-morphology/2.3.3/elasticsearch-analysis-morphology-2.3.3.zip` - пример
* потом перезапусти эластик `brew services restart elasticsearch`
3. в проекте админки
`rake environment elasticsearch:import:model FORCE=y `
`rake environment elasticsearch:import:model FORCE=y`
индексировать будет долго, но пользоваться можно сразу

## Postgres comments db
1. `psql -U postgres -h localhost`
2. `create database comments_dev;`

## Redis install and start
1. `brew install redis`
2. Перед запуском `brew services start redis`

Как вы думаете, сколько времени требовалось начинающему разработчику, чтобы развернуть у себя проект и начать делать задачи?

Около недели.

Естественно, не все команды терминала проходили с первого раза, довольно часто инструкция устаревала.

Это считалось нормальным и всех устраивало. То есть, чтобы сделать фичу в 1 час работы, требовалось сначала потратить 40 часов на разворачивание всех компонент локально.

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

$ docker-compose up api
...
Listening localhost:8080

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

Кейс 2. Устойчивость

Второй кейс — устойчивость системы нашего рабочего компьютера.

Кому нравится ставить на свой любимый компьютер какой-то сторонний софт? Кому нравится устанавливать несколько разных баз данных, новые компиляторы, интерпретаторы?

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

Более того, вы можете сломать вашу систему и потратить несколько часов на её восстановление.

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

$ docker rm --volumes api
$ docker system prune --all

Кейс 3. Контролируем эксплуатацию

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

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

Фронт: Ребят, я всё сделал. Код в репе. Выкатите, плиз!
Админ: Как оно выкатывается?
Фронт: Собираешь нодой и раздаёшь статику веб-сервером из папки /build
Админ: Какой версией ноды собирать? Какая команда сборки? Каким веб-сервером раздавать?

В итоге для админа развёртывание вашего проекта превращается в не менее увлекательный квест, как для вас развёртывание API на локальной машине из предыдущих кейсов.

Даже если проект будет работать у вас на компьютере, совсем не обязательно, что всё так же будет работать на продакшене. И мы получаем классическую проблему «это работает на моей машине«.

Docker помогает нам и с этим. Решение простое, если мы запаковали наш проект в Docker, тем самым автоматизировав его сборку и настроив запуск, то он будет одинаково работать на всех серверах, которые поддерживают Docker.

А инструкция для админов сведётся к:

Фронт: Ребят, я всё сделал. Собрал для вас Docker-образ. Выкатите, плиз!
Админ: Ок

Уж с чем, а с Docker-образами админы точно должны уметь работать. Не то, что с нашей нодой.

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

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

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

Updated

В чем разница между интерфейсом пользователя и разработчиком пользовательского интерфейса?

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

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

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

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

Работа разработчика пользовательского интерфейса

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

Что касается вспомогательных инструментов, разработчик пользовательского интерфейса может также использовать Microsoft Expression Design и Expression Blend. И последнее, но не менее важное: разработчик должен глубоко погрузиться в рекомендации по пользовательскому интерфейсу для соответствующих операционных систем, под которые он хочет настроить свой интерфейс (рекомендации по пользовательскому интерфейсу Windows, рекомендации по Mac OS). Таким образом, не будет необходимости изобретать велосипед там, где уже существуют проверенные правила, которые можно и нельзя.

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

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

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

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

А как насчет Front-End разработчиков?

Front-End — это разработка клиентской части веб-интерфейса. Front-End разработчик отвечает за запуск и работу интерфейса, в отличие от внешнего вида, разработанного специалистом по пользовательскому интерфейсу.

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

Специалист по Front-End должен обладать гораздо большими навыками программирования, чем UI-дизайнер. Они должны понимать протокол HTTP, принципы работы серверов и браузеров, особенности отображения сети на различных устройствах, которые сейчас представлены на рынке.

Проблема, связанная с разработкой внешнего интерфейса, заключается в том, что инструменты и методы, используемые для создания внешнего интерфейса веб-сайта, постоянно меняются, поэтому разработчик должен постоянно быть в курсе того, как развивается эта область.Сегодня существует три столпа, на которых обычно строится интерфейс. Это HTML, CSS и JavaScript. Как программист, Front-End разработчик также должен иметь образование в области алгоритмов, структурирования данных, шаблонов кодирования, объектно-ориентированного программирования и функционального подхода.

Часто фронтенд-разработчик должен находить решения проблем UI / UX на этапе разработки продукта. Вот почему для них большое преимущество — иметь несколько базовых навыков разработчика пользовательского интерфейса.

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

Подробнее о советах и ​​приемах веб-разработки:

1. Как веб-разработчики проводят тестирование удобства использования
2. Как веб-разработчики проверяют свой код
3. Что нужно, чтобы собрать идеальную команду веб-разработчиков?

,

Фронтенд-разработчик знает

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

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

Front-end разработчик разбирается в дизайне. Если они сами не дизайнер, они знают, насколько важен дизайн. У них хороший вкус в дизайне. Они знают о задействованных инструментах.Они знают, какое место в процессе занимает роль дизайнера.

Front-end разработчик знает о back-end. Если они сами не являются внутренним кодировщиком, они знают, насколько важна внутренняя часть. Они знают, что серверная часть может предоставить, а что нет. Они знают обязанности разработчиков серверной части. Они знают задействованные языки. Они знают, как запрашивать то, что им нужно, во внешнем интерфейсе.

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

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

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

Интерфейсный разработчик знает о базах данных. Содержимое живет там. Содержание должно быть в хорошем состоянии. Интерфейсный разработчик может работать только с тем, что поступает из этих баз данных. Разработчик фронтенда должен объединить то, что c

.