Никита Геннадич

Link от Next.js принимает только один параметр, поэтому пришлось всё содержимое в Link обернуть в React.Fragment.

import React, { Component } from 'react';
import { withRouter } from 'react-router-dom';

class Example extends Component {
  handler = () => {
    this.props.history.push('/cources');
  };
  
  render() { /* ... */ }
}

export default withRouter(Example);

Возможно, вам подойдет простой вариант с компонентом Link:

import React, { Component } from 'react';
import { Link } from 'react-router-dom';

class Example extends Component {
  render() {
    return <Link to="/cources" />;
  }
}

export default Example;

{Object.keys(cities).map(cityId => (
  <div key={cityId} className="card-panel">
    {cities[cityId]}
  </div>
))}

• super(props) - вызвать конструктор наследуемого класса, те React.Component
  
• .bind(this) - возвращает функцию с жесткой привязкой контекста
  

Проблемы решены:
первая из них решилась из подсказки самого окна
sc.exe query vboxdrv
в моем случае сервис был выключен. Далее сервис/службы -> включение. Перебираем типы запуска и пытаемся запустить.

вторая из них решилась выполнением первой из рекомендации с официального форума https://forums.virtualbox.org/
а именно:
sfc /scannow
1. Выполняем ждем -> нашлись ошибки -> перезагрузка.
2. Повтор шага 1.
3. Профит

Выполнив второй раз виртуал бокс был в списке удаления. Но вдруг потыкав на кнопке включения, неожиданно все заработало...

Доброго времени суток!

У компонента Route есть параметр render.

<Route
  render = { props => logged ? <Product /> : <Redirect to='/' /> }
  exact
  path='/products/:id'
/>

И важно, в доках об этом конечно сказанно, но я повторюсь.
component имеет приоритет над render, так что использовать их вместе не стоит.

На сколько я помню, блютус не очень любит столько подключений

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

В качестве кодека берите VS1003
В качестве приемника и передатчика сойдет NRF24L01

На передатчик антенну по лучше, на приемниках можете развести с керамической SMD, зависит от расстояний и местности, но должно хватить, в крайнем случае на передатчик можно влепить усилитель

На счет каналов, тут надо ставить на 2 колонки один NRF24L01, в формате MP3 записано где R и L, а VS1003 сам умеет выдавать звук куда надо

Я увидел в Вашем вопросе две части.

Как правильно организовать деплой (выкладку работоспособного кода на сервер)?

В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.

Если хочется автоматизировать процесс, что похвально, то я вижу три доступных инструмента для этого: Capistrano, Mina (мой персональный фаворит) и Vlad the Deployer. Все три проекта схожи по сути. Принцип их работы таков:

1. Подключиться к целевому серверу.
2. Залить обновление кода из репозитория.
3. Выполнить предписанные Вами инструкции (перезапуск демонов, сброс индексов, обновление структуры БД и прочее).
4. ...
5. PROFIT!

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

Как организовать процесс тестирования?

Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.

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

В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.

Таким образом

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

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

https://jsfiddle.net/space2pacman/0f9ug7r3/1/