Михаил Р.

Первый шаг - выявление направленности проекта:

• коммерческий
  
• информационный
  
• энциклопедический
  
• социальная сеть и прочее
  

Далее, после того как определились с типом ресурса, выявляем важнейшие для его оптимизации факторы ранжирования. Так, например, для коммерческих проектов во главе угла стоят коммерческие факторы ранжирования, а вот для информационного проекта необходимо учитывать полноту раскрытия информации, стиль подачи и многое другое, подробнее можно почитать в этой статье на Хабре.
​
Далее есть список факторов которые необходимо учитывать всем ресурсам, это технические, семантические и поведенческие факторы.
​
Для начала необходимо подготовить фундамент - провести подробный анализ техническихфакторов помогут такие программы как Netpeak Spider или Screaming Frog (программ конечно многое множество, но эти используют чаще всего). Но, к сожалению, тулсами можно проверить не все и необходимо будет изучить матчасть и проверять многие технические аспекты руками.
​
Затем переходим к семантике, это очень сложный вопрос который лучше будет описать в другом ответе, но, в двух словах, необходимо убедиться что у всех страниц сайта заполнены важные элементы семантики (title, h1 и прочее) и они соответствуют контенту страницы.
​
После, к UX сайта, четко продумывая взаимодействие пользователя и максимальное для него удобство. Тут же сразу учтем и часть коммерческих факторов, и оформление контента и прочее что напрямую связано с поведением пользователя.
​
В финале мы получим идеально внутренне оптимизированный ресурс и можно будет приступать к внешней оптимизации.
​
Старайтесь делать все максимально полезным для пользователя. Органичность содержимого сайта, реальная польза входящей ссылки для пользователя на стороннем ресурсе и прочее белое SEO это то к чему надо стремиться!
​
Яндекс подсказывает как развивать сайт белыми методами и чтобы он был полезен пользователю. Все материалы можно найти:
В Блоге Вебмастеров
На канале Академии Яндекса
В Хелпе Яндекс Вебмастера

Так себе идея. Вот, для примера, можешь определить, какой диапазон времени в этом примере: 1520155?
15:20 - 1:55 или 1:52 - 0155? Неоднозначно да? Вот для программы это тоже будет неоднозначно. Ты либо загоняешь себя в жесткие рамки, где шаг влево-вправо аврал, либо делаешь полную автоматизацию ввода времени.

Тут достаточно понимать как работают @media и уметь трансформировать отображение элементов. Ничего сложно тут нет.

jsfiddle.net/profesor08/jan8L05t

<nav>
  <button>==</button>
  <ul>
    <li><a href="#">menu item 1</a></li>
    <li><a href="#">menu item 2</a></li>
    <li><a href="#">menu item 3</a></li>
    <li><a href="#">menu item 4</a></li>
  </ul>
</nav>

nav {
  display: flex;
  background: #f5f5f5;
  border-bottom: 1px solid #e2e2e2;
  
  button {
    padding: 10px;
    border: 0;
  }
  
  ul {
    list-style: none;
    margin-left: auto;
    display: flex;

    li a {
      padding: 10px;
      display: inline-block;

      &:hover {
        background: #e2e2e2;
      }
    }
  }
}

@media screen and (min-width: 768px) {
  nav {
    button {
      display: none;
    }
  }
}

@media screen and (max-width: 767.98px) {
  nav {
    position: relative;
    
    button:not(:hover) {
      ~ ul {
        display: none;
      }
    }
    
    ul {
      position: absolute;
      top: 100%;
      left: 0;
      flex-direction: column;
      background: #f5f5f5;
      border: 1px solid #e2e2e2;
    }
  }
  
}

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

Здесь у вас по сути две независимые сборки, если я правильно понимаю замысел.

Это реализуется через multiple compilation, то есть массив конфигов:

var config = [{
  entry: ..
  output: ...
}, {
  entry: ..
  output: ...
}];

module.exports = config;

Как правило, берут один конфиг за базу, и по нему генерируют массив, например, меняя в нём выходные директории, переменные для DefinePlugin или что-то ещё.

Также для webpack-конфигов удобен такой merge: https://github.com/survivejs/webpack-merge.

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

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

Так что забудьте. Либо вы фулл-стек дизайнер, либо QA.

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

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

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

Я не понимаю почему

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

* у которого указано позиционирование отличное от static.