Как проверить, что знаешь на базовом уровне JavaScript?

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

Плюсы и минусы двух связок для php7 - nginx/apache/mod_php vs nginx/php-fpm?

Разница на самом деле довольно большая:
1) FPM - пул обслуживающих процессов PHP регулируется отдельно от пула HTTP процессов. Для Apache с mod_php - каждый запрос в т.ч. с картинкой всё равно будет обрабатывать полновесный процесс с поддержкой PHP. Да, расход памяти не очень большой, т.к. PHP в этом раскладе - разделяемая библиотека. Но оверхед выше. В противовес - нет затрат на прокидывание запроса к процессу PHP и ответа обратно (хотя сейчас там вроде всё довольно оптимально).
2) PHP-FPM может стартовать интерпретатор от разных пользователей, что позволяет гибче разрулить безопасность. Apache + mod_php выполняет всё от одного пользователя (обычно www).
3) Как уже говорили, .htaccess для многих легаси-продуктов всё еще важен, связка nginx + php-fpm его не умеет обрабатывать.
4) Для сложных конфигураций nginx может использовать интерпретаторы и php-fpm с разных физических машин - может быть оправданным, если скрипты "тяжёлые". Apache + mod_php такого лишен.
5) В связке nginx + apache + mod_php получается много звеньев, т.е. надёжность потенциально ниже, нежели в nginx + php-fpm. Сложность администрирования nginx + apache vs nginx-only опять же не в пользу первого варианта.

Нет файлов composer json и phar, как установить?

и почему в каталоге domains? обычно у вас есть подкаталог в нём, где хранится конкретный файл.

PS не забудьте, что в openserver - composer как правило старый, перед его использованием не лишним будет выполнить composer selfupdate

Из массива сгенерить массив последовательно выполняющихся Promise?

Шашечки или ехать? Форматируйте, как вам хочется.

Из массива сгенерить массив последовательно выполняющихся Promise?

Но согласен, решение Николая более очевидно и легче (что важно) читается. Тем более из-за push в моем случае иммутабельность потерялась, а сделать чисто - развезётся код совсем. Но, кстати, не стоит забывать, что async/await транспайлится через генераторы, т.е. код, прошедший через Babel - будет вообще не узнать.

Из массива сгенерить массив последовательно выполняющихся Promise?

тогда можно модифицировать seqPromises так:

seqPromises = (arr, out = []) => arr.reduce((a,v) => a.then(r => {out.push(r); return makePromise(v);}), Promise.resolve()).then(r => out.slice(1).concat(r));

Как влиться в тренд современной веб разработки в контексте FULL STACK?

Ну да, как и везде :)
По срокам - наверное, тяжело въехать в PHP с нуля. Фреймворк (основы) учится одной неделей. Не надо только сразу бросаться на сложные задачи. Еще можно взять специализацию фронт или бэк - фуллстек сейчас гораздо тяжелее, чем скажем 10 лет назад. Писать сразу на 2х языках плюс пара фреймворков плюс тонны библиотек и тулзов на каждом - сложно очень. И это за скобками остались HTML/CSS/DOM. Я лично слегка опасаюсь флексов - т.к. начинал верстать еще табличками под IE4 / NN4, а сейчас верстка мне достается довольно редко. Нативный API в JS тоже из памяти быстро улетучивается, если постоянно не пользуешься. И так со всем - что-то выучил, год-два не попользовался активно - и либо подзабыл, либо паровоз ушел далеко вперед, а у тебя уже неактуальные знания.

Как правильно получать параметры и реагировать на их изменения?

Из такого кода я бы сказал, что иерархия компонентов не очень корректно спроектирована. Лучше прогружайте данные уровнем выше, а в этот компонент их спускайте через свойство value. И реализовывайте v-model для этого компонента. Это может быть сложно на первых порах, но гибкость выше и в дальнейшем вам же будет проще.

Еще рекомендую сделать loadPosts() чистой функцией, возвращающей ошибку или данные в промисе, на входе аргументом - id. Вызов будет такой -

this.loadPosts(this.ownerId)
        .then(res => { this.posts = res; })
        .catch(err => alert('Что-то пошло не так: ' + err));

Чем не очень хорош Vue.js - так это тем, что структурированию приложений в официальной документации не уделено должного внимания. В отличие, например, от React (где поднятие состояния и различие между "глупыми" компонентами и контейнерами четко объясняется). Пока новичок созреет ножкой пощупать воду во vuex - может много времени пройти.

Валидация на сервере каждого поля формы с использованием Vue. Оптимальное решение?

А что мешает так же воспользоваться _.throttle и _.debounce, коль все равно валидация асинхронная? Если у вас фронт собирается, вы можете импортировать конкретно только нужную функцию, и не волочь всю библиотеку. Кастомный инпут-компонент в вашем случае мне тоже кажется предпочтительным вариантом.

Как правильно прописать свойства у компонента vue.js?

эмм, у вас ошибка в ключе в v-for, вы и Евгений некорректно присваиваете объект в качестве ключа. Надо так:

<map-point v-for="point in points" :key="point.id" :point="point"></map-point>

Как правильно получать параметры и реагировать на их изменения?

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

PS Для наблюдающих за темой, компоненты иногда вынужденно приходится клеить в одно и получать огромных монстров - так, в IE 11 наблюдали очень серьезные утечки памяти при использовании множества инстансов vue-multiselect (крэш браузера через 4-5 обновлений страницы).

Как корректно вывести вложенный массив json на страницу в Vue 2?

Ну смотрите, вычисляемое свойство уже делает отсечение от общего массива нужной вам страницы заданного в this.perPage размера. Осталось только вывести данные:

<div v-for="image in dataOnPage">
    <img :src="image.path" :alt="image.name" :title="image.name">
</div>

И поискать решение для пагинации.
Или вот так:

<button @click="currentPage > 1 && currentPage--">туда</button>
Текущая - {{currentPage }} из {{ Math.ceil(images.length / perPage) }}
<button @click="currentPage*perPage < images.length && currentPage++">сюда</button>

Как совместить VueJS, vue-router и flask?

Увы, не подскажу, у нас особо отдельный случай, авторизация через PAM на бэкенде (и директивку @requires_auth) и Basic Auth заголовок на фронте.

Как решить задачу?

function* numberQuiz(number) {
  let x = yield 'Назовите число:';
  do {
    if (x >=7) {
      x = yield 'AAA, x < 7';
    } else if (x <=4) {
      x = yield 'BBB, x > 4';
    }
  } while (x != 5);

  return 'success, x = 5';
}

Как переделать этот код из jQuery в JS?

Эмм, последний штрих - return избыточный, и третий параметр уже дефолтно false:

window.addEventListener('scroll', (bluringElement => () => bluringElement.style.opacity = window.pageYOffset / 240)(document.querySelector('.blur')));

Куда подевалось значение?

const rarr = arr => arr.slice(0).reverse() - не?

Как agile выглядит на практике?

Ну у нас гибрид :) В общем, I've got your point, у нас работа начинается с проработки, задачи тоже в скрам процессе, когда мы прорабатываем ТЗ и делаем планинг на много спринтов вперед, формируя бэклог начерно на полгода-год вперед. После этой стадии у нас есть оценка, сколько надо времени для завершения проекта (т.к. производительность команды уже известна) - и заказчик либо соглашается, либо режет фичи. Первые пару спринтов текущим составом работали да, с неизвестным всем - и по ним считали скорость, нормировали СП - фактически, строили процесс работы. Сейчас всё плюс-минус гладко и предсказуемо. По всяким форсмажорам менеджер закладывает для заказчика оверхед 20+ %.

Как отформатировать числа в js?

NikiRyhti:

function formatNum(str) {
  return str
      .slice(0, -3)
      .split('')
      .reduceRight((a, v, i, s) => 
            v + ((s.length - i - 1) % 3 !== 0 || (i === s.length - 1) ? '' : ' ') + a
      , '');
}

Для ES5 синтаксиса надо стрелочную функцию обернуть так:

function(a, v, i, s) {
    return  v + ((s.length - i - 1) % 3 !== 0 || (i === s.length - 1) ? '' : ' ') + a
}

Как agile выглядит на практике?

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

Как agile выглядит на практике?

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