Glorious Cat

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

Читаем про git flow, восхищаемся и интегрируем.
Читаем PSR-ы, восхищаемся и интегрируем. Не помешает: Попросили проверить код, на что смотреть нужно?
Читаем про vagrant. На базе вот этого вот строим dev окружение. Можете поиграть с https://puphpet.com/. До docker все же стоит дорасти.
Постигаем Phpstorm, и радуемся жизни.
Можете посмотреть так же: https://github.com/index0h/php-conventions

Тестирование

Читаем про phpunit, восхищаемся и интегрируем.

Документирование

Рекомендую взять за правило: документирование алгоритмов нужно только в крайнем случае, когда используются некие хаки. Говнокод лучше переписать на что-то очевидное, чем объяснять, какая муха вас укусила и где.
Что касается docblock-ов для помощи ide - это отличная идея.

Деплой

Самый простой и надежный способ: root у вашего nginx/apache указывать как ссылку на каталог текущей прод версии. При релизе - заливать код с помощью rsync в новый каталог, а далее менять ссылку на новый релиз.
Например у вас каталог с версиями кода:
production -> v1.0.2 - текущая версия
v1.0.1 - старый релиз
v1.0.2 - текущая версия
v1.0.3 - новый релиз
Когда подготовка завершена - вы только меняете симлинк production на v1.0.3. Если что не так - можно быстро откатиться на предыдущую версию.

Если нас помимо undefined не устраивает null, 0 и "" (что неявно приводится к false), то обычно применяют такой паттерн:
const value = currentValue || defaultValue;
Например:

const productCategory = categoryInput.value || "N/A";

Рекомендую тестировать письма вот этим сервисом https://putsmail.com, письма будет приходить как и должны, будут нативно открываться во всех почтовиках.

1. Для удобства пересчета px to rem - 1rem равен 10px
2. В процентах для того, чтобы изменив базовый размер в настройках браузера (обычно 16px) rem пропорционально увеличивался в отличие от абсолютных 10px
3. Проще размеры задавать в пикселах, а затем с помощью https://github.com/cuth/postcss-pxtorem переводить нужные в rem

Идея/концепция к проектированию не относится, это отдельный предварительный этап. Для проектов побольше, и в общем случае, проектирование включает такие шаги, многие из которых, конечно, можно пропустить или сократить до минимума, если задача не сложная:
1. Системный анализ и изучение предметной области
2. Формирование требований к разрабатываемой системе
3. Архитектуная задача, которая сводится к простой формуле: разделять, называть и связывать подсистемы
3.1. Декомпозиция сложных задач
3.2. Слои (построение слоев абстракций)
3.3. Планирование топологии системы, программной и серверной инфраструктур
3.4. Решение вопроса интеграции подсистем, программные интерфейсы, контракты и связывание
3.5. Интеграция с унаследованными приложениями
3.6. Минимизация изменений, для случаев, когда постоянно происходят изменения в предметной области
4. Выбор инструментов решения
4.1. Выбор парадигм программирования и языков
4.2. Выбор технологий и платформ
4.3. Выбор моделей данных, алгоритмов и библиотек
4.4. Выбор топологий и протоколов
4.5. Выбор паттернов программирования
5. Предварительные исследования
5.1. Проверка гипотез, эксперименты
5.2. Изучение особенностей технологий
5.3. Прототипирование
6. Задачи обеспечения надежности
6.1. Планирование безопасности и защиты от несанкционированного доступа
6.2. Планирование отказоустойчивости
6.3. Планирование мер по обслуживанию системы в режиме эксплуатации
6.4. Задачи высоких нагрузок, балансировки и масштабирования, если таковые предполагаются
7. Организация процесса разработки
7.1. Жизненный цикл программной системы
7.2. Конвенции кода, соглашения и стандарты
7.3. Оценка необходимых временных и финансовых ресурсов для разработки системы
7.4. Календарный план
7.5. Анализ и минимизация рисков, выявление слабых мест технологий и коллектива
7.6. Закрепление принципов управления процессом разработки и корректировки задания в процессе
8. Сборка технического задания из результатов всех предыдущих пунктов

Моя проба пера.

P.S. Ну и дальше оптимизировать.

1-3)@media (max-width: 500px) {} - все
4)

Устройство в 320 рх подходит под все три запроса?

да

как CSS разбирает из этих запросов что применять?

применится правило, которое ниже в коде. Как если бы не было никакого медиа, а был обычный css.
4)

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

Если верстаешь сначала для монитора, потом для мобилок адаптируешь, то с наименьшим будет снизу, т.к ему надо перекрывать правила больших расрешений.
Если mobile first, то стили для телефона без медиа, а под большие разрешения ниже пишешь медиа запросы.
5) если стиль не меняется никогда (цвет например), медиазапрос для него не нужен.
6) Не удобно искать стили в разных местах.
хорошо, если один класс встречается 1 раз в css. Так лучше для поддержки кода
sass позволяет писать медиа внутри правила

.elem {
    color: red;
    @media () {
        color: red;
     }
}

7) это вопрос удобства. Главное не смешивай 2 этих случая.

prodengiblog.ru/optimizaciya/mikrorazmetka-xlebnyx...

schema.org/BreadcrumbList

Masonry - самое очевидное решение

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

Какие задачи нужно уметь решать на чистом JS, перед тем как переходить к изучению библиотек и фреймворков?

Кроме синтаксических конструкций, математических и логических выражений, нужно знать:

• Область видимости переменных
  
• Замыкания
  
• Объектно-ориентированное программирование, в частности наследование через прототипы
  
• Шаблон проектирования "модуль"
  
• Операции над DOM
  
• Понимание принципов событийно-ориентированного программирования
  

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

Важно - инструменты программиста JavaScript
У тебя должен быть удобный инструмент для разработки (IDE, Integrated Development Environment), чтобы он тебе подсвечивал код (syntax highlight) и подсказывал о синтаксических ошибках (syntax check), о формальных параметрах функций (type hinting), о стиле кодирования (code style), помогал писать код (live templates).
Ты должен знать, как отлаживать скрипты в популярных браузерах (Firebug, Chrome Developer Tools и другое). Что такое точки останова, как управлять исполнением во время останова, как посмотреть и поменять содержимое переменных, как настроить останов по условию.

Хотелось бы узнать что это за задачи(упомянутые вами 80%)

Реальные задачи джунов:

1. Возьми из сборника задач по javascript любой скрипт случайно и вслух расскажи, что он делает.
   Важно - читать и понимать чужой код намного важнее, чем писать свой. И на работе тебе это приддётся делать чаще, чем ты думаешь. Чтобы подключить к своему проекту чужую JS либу, нужно понимать что она делает, как она конфигурируется, как управлять её поведением. Скажу точно, что написать свой скрипт, который строит графики, намного сложнее, чем понять, как настраивается highcharts.
   
   
2. Напиши скрипт на JS, который в заданном тексте удалит один или два символа, выбранных случайно
   
   1. Усложнение: удалять можно только буквы в словах, а знаки пунктуации и цифры удалять нельзя
      
   2. Усложнение: принять, что этот текст является программной на Javascript, удалить одну-две команды JS, но только если они не в строковых литерах (break как команду удалить можно, а в строке "break my heart" нельзя)
      
   3. Усложнение: воспользуйся этим скриптом и "попорти" код какого-нибудь другого скрипта на Javascript, а потом отладь, найди ошибку и восстанови работоспособность
      
   Важно - этим обычно все и занимаются - ищут баги. Только в реальной жизни они и без этого скрипта появляются. И не по одному, а прям пачками.
   
   
3. На страницу HTML нужно встроить график курса доллара по отношению к рублю. Формат входного массива значений курса определи сам, исходя из своего скрипта для построения графиков.
   
   1. Усложнение: на одном графике должны быть два курса, по разным шкалам. Наприме, курс доллара к евро и курс юаня к рублю
      
   2. Усложнение: первоначально график вывести в детализации по месяцам, но чтобы можно было "приблизить" (drilldown) детализацию до дней
      
   3. Усложнение: первоначально график вывести текущем месяце, но чтобы можно было загрузить данные для предыдущего месяца без перезагрузки страницы (AJAX)
      
   
   
4. При клике по картинкам, вставленным в текст HTML, показывать всплывающее окно для просмотра увеличенной картинки.
   
   1. Усложнение: в всплывающем окне сделать навигацию по картинкам, вперёд/назад и к нужной картинке
      
   2. Усложнение: в всплывающем окне вместо картинки показать видео-ролик с Youtube
      
   3. Усложнение: в всплывающем окне показать текст HTML
      
   
   
5. По клику на кнопку "Click me" показать всплывающую форму.
   
   1. Усложнение: реализовать проверку данных на корректность перед отправкой формы (непустое значение, минимальное количество символов, максимальное количество символов, минимальное числовое значение, максимальное числовое значение)
      
   2. Усложнение: если в значении текстового поля встретилась гиперссылка, то считать её за 22 символа при любой длине этой ссылки (как в твитере)
      
   3. Усложнение: реализовать отправку формы на сервер через AJAX, без перезагрузки страницы
      
   4. Усложнение: саму форму в виде HTML загрузить с сервера через AJAX, в момент клика по кнопке "Click me", правила проверок данных должны как-нибудь "извлечься" из самой загруженной формы, например из аттрибутов полей ввода
      
   
   
6. К форме ввода данных на поле ввода даты "навешать" всплывающий календарь для выбора даты.
   
   1. Усложнение: сделать форму календаря мультиязычной. Хотя бы через настройки на том же JavaScript
      
   2. Усложнение: сделать так, чтобы с помощью календаря можно было выбрать диапазон дат, чтобы она была привязана к двум полям формы "дата начала" и "дата окончания", и чтобы значение в поле "дата начала" обязательно была меньше чем в поле "дата окончания"
      
   3. Усложнение: сделать так, чтобы с помощью в календаре можно было видно визуально этот диапазон
      
   4. Усложнение: диапазон может быть открытым, но не пустым, то есть пользователь должен задать хотя бы дату начала или дату окончания.
      
   
   
7. Сделать пред-просмотр веб-страницы HTML с разными темами. Тему страницы выбирать через селектор на javascript, а показывать в фрейме.
   
   1. Усложнение: сделать селектор "тип устройства", чтобы менять размер фрейма (например, "iPhone 5c 1136x640") и "чекбокс" для смены ориентации страницы "горизонтальная" или "вертикальная" (соответственно 1136x640 или 640x1136)
      
   2. Усложнение: в селекторе тем предусмотреть поиск тем по подстроке, и аналогично поиск устройств по части названия (авто-дополнение, auto-complete)
      
   3. Усложнение: тема страницы должна меняться без перезагрузки фрейма
      
   
   

Задачи повышенной сложности, исходя из личного интереса

1. Реализовать форму для многошагового мастера: форма должна состоять из нескольких страниц (шагов), пользователь может переключать страницы через какие-нибудь элементы управления "вперёд/назад" или "перейти на страницу".
   
   1. Усложнение: реализовать функциональную связь значений, когда некоторые данные зависят друг от друга (ввёл число в поле "количество" и в поле "сумма" значение пересчиталось)
      
   2. Усложение: доступность некоторых полей ввода должна зависеть от данных (например, если указал "есть личный самолёт", то значит можно ввести "марка самолёта")
      
   3. Усложение: видимость некоторых страниц должна зависеть от данных из предыдущих страниц (например, если указал "есть личный самолёт", значит появилась страница "ТТХ самолёта"; иначе страница должна скрыться)
      
   
   
2. Реализовать однопользовательскую браузерную игру "змейка", "тетрис", "найди пару"
   
3. Реализовать многопользовательскую браузерную игру "крестики-нолики", "морской бой" на два игрока в режиме "hot seat"
   
   1. Усложнение: два игрока на разных компьютерах, ходы передаются по websocket
      
   2. Усложнение: ограничение на ожидания окончания хода 15 секунд, по окончании ожидания автоматически делается случайный ход
      
   
   
4. Реализовать todo-list. Пользователь вводит список, затем он превращается в строки с "чек-боксами". Когда "чекбокс" включен, строка зачёркивается.
   
   1. Усложнение: пользователь может переименовывать, удалять, добавлять строки
      
   2. Усложнение: список хранить в localStorage браузера, чтобы при перезагрузке страницы он восстанавливался
      
   3. Усложнение: пользователь может иметь несколько независимых списков todo
      
   
   
5. Реализовать простой графический редактор. Пусть рисуется точка в месте, где пользователь кликнул.
   
   1. Усложнение: добавить переключатель режимов "точка"/"линия", в режиме "линия" рисуются линии между двумя последовательно кликнутыми точками
      
   2. Усложнение: можно менять толщину, цвет линий, размер точек
      
   3. Усложнение: последовательность кликов можно воспроизвести ещё раз с самого начала, равномерно или с реальной задержкой между кликами, с обычной скоростью или ускоренно
      
   4. Усложнение: можно выгрузить получившийся рисунок в формате PNG или SVG, причём SVG c анимацией воспроизведения
      
   
   

Можно использовать любую существующую библиотеку.
Например,
для построения графиков www.highcharts.com
для загрузки и передачи данных через AJAX: jquery.com + что-нибудь на сервере
для всплывающих диалогов с картиками, видео и формами: fancyapps.com/fancybox и https://jqueryui.com/dialog/
для валидации форм rickharrison.github.io/validate.js
для календаря https://jqueryui.com/datepicker/
для автодополнения https://jqueryui.com/autocomplete/
для передачи данных между несколькими пользователями socket.io или обычный AJAX

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

В первом случае всё просто, приблизительно так:

<div class="container">
	<div class="container__header"> ... </div>
	<div class="container__body"> ... </div>
	<div class="container__footer"> ... </div>
</div

.container {
	display: flex;
	...
}
.container__header {
	flex: 1 1 auto;
}
.container__body {
	flex: 1 1 auto;
}
.container__footer {
	flex: 1 1 auto;
}

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

<div class="container">
	<div class="container__header">
		<div class="some-header-block"> ... </div>
	</div>
	<div class="container__body">
		<div class="some-body-block"> ... </div>
	</div>
	<div class="container__footer">
		<div class="some-footer-block"> ... </div>
	</div>
</div

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

https://anchorcms.com/ - простая как три копейки
https://pyrocms.com/ - сложноватая
tinyadmin.net - слишком простая и платная, но в ряде случаев подходит