Максим Федоров

Я так понял, вам не просто senior backend нужен, а senior backend + senior architect?
Таких людей с горящими глазами нет В ПРИНЦИПЕ.

А мантра по типу "амбициозного программиста-энтузиаста (у которого горят глаза)" - это мантра паршивых галер, где платят копейки, но капают на мозги корпоративной этикой, преданностью, тем, что человек получит опыт и прочим бредом. Вариант того, что вы кого-то бы нашли (только юниора) - у вас есть дельный техлид, который готов обучать юниора в процессе работы. Так действительно можно найти бесплатных программистов, но качество их работы будет сомнительное, да и тимлид работать бесплатно не будет.

У вас вариант только один - искать финансирование. Стартапы, зачастую, дико скучная для обучения сфера. Это не создание игр, где местами весело.

Гуглиться же легко
jsfiddle.net/tpmD4/6

Посмотреть в стилях слоя.

Я бы не назвал ваш уровень Junior. Если вы в состоянии самостоятельно
- развернуть девелоп-среду
- вести гит
- писать код и обкладывать его тестами
- настроить деплой

то значит, в состоянии самостоятельно ставить себе задачи. А это уже на Миддла тянет )
А у Миддла способ развиваться только один - практика. Самообучаемость, как видно, присутствует. Не зацикливайтесь на парадигмах, фреймворках и ЯП - берите проекты и выполняйте их

Да всё у вас в порядке для джуна, дальше только опыт. Всё правильно выше сказали про требования конкретной компании - этого не угадаешь. Где-то mongodb нужен где-то postgresql где-то трейты юзают и php7 а кто-то на 5.3 сидит ещё. Ваших знаний считаю достаточно.

DI именно в вашем случае не при чём. Это способ реализации, а не сама идея. Идея состоит в том, что вам нужно реализовать принцип инверсии зависимостей. То есть начать работать с интерфейсами, а не с конкретными реализациями.

Чтобы быть универсальным и переносимым, модуль не должен знать о моделях извне себя. Вместо этого он должен выражать свои требования в виде интерфейса, а внешние модели этот интерфейс должны реализовывать.

Для вашего примера делаем в модуле Article делаем интерфейсы:

interface ArticleInterface
{
    public function getTitle();
    public function getAuthor();
}

interface ArticleAuthorInterface
{
    public function getName();
    public function getID();
}

Далее в пределах модуля используем только интерфейсы, а не сами модели:

public function renderArticle(ArticleInterface $article)
{
    return $this->renderPartial('_article', [
         'author' => $article->getAuthor(), 
         'title' => $article->getTitle()
    ]);
}

Вне модуля нам придётся реализовать интерфейсы в моделях:

class Article extends ActiveRecord implements ArticleInterface
{
   // ...
}

private function getDsnAttribute($name, $dsn)
    {
        if (preg_match('/' . $name . '=([^;]*)/', $dsn, $match)) {
            return $match[1];
        } else {
            return null;
        }
    }

Использование в любом месте:

$this->getDsnAttribute('dbname', Yii::$app->getDb()->dsn);

Использование в модели:

$this->getDsnAttribute('dbname', static::getDb()->dsn);

$this->getDsnAttribute('dbname', ModelName::getDb()->dsn);

тогда функцию запихнуть в хелпер какой-нибудь, но если вам миграцию написать, тогда зачем вам модель?
В миграции:
$this->getDsnAttribute('dbname', $this->db->dsn);

Как ни странно, в документации монги все это описано.
создать пользователя:

mongo
>>use  "db name"
>>db.createUser(
	{
		user: "user_name",
		pwd: "user_passwd",
		roles: [{role: "readWrite"}]
	}
)

чтобы требовалась авторизация, следует в конфиге монги указать
auth=true

UPDATE: реальные тестовые задания и разборы здесь, ответы на все вопросы из поста в моем блоге об обучении react.

не включая основы js

Извините, но стандартная задача, про "напишите функуцию add, которая при вызове add(1)(2) вернет 3" - многих положила на лопатки =) Поэтому будьте готовы..

React
0) Какую проблему решает react ?
1) Мгновенно ли срабатывает setState? Если нет, то как выполнить код, который 100% выполнится после того, как новый state будет установлен?
2) Зачем многие постоянно пишут в constructor: this.FUNCTION_NAME = this.FUNCTION_NAME.bind(this) и отсюда вопрос вытекает чему равно this в разных местах вашего компонента...
3) в каких методах жизненого цикла стоит выполнять xhr запросы? В каких стоит "обновлять state на основе props"?
4) Что будет если вызвать this.setState в render методе компонента?
5) зачем нужен componenWIllUnmount, приведите пример..
6) Контролируемые, не контролируемые компоненты
7) Как организовать роутинг в реакт приложении? (ответ: взять react-router - подходит, но было бы круто, если бы вы рассказали, как он примерно работает)*
8) Зачем нужны propTypes? Что происходит с ними в production сборке?
9) Как можно удобно "отлаживать" чужой код приложения, написанного на react (намек в сторону React devtools)
...

Redux
0) Какую проблему решает redux?
1) Зачем многие создают типы действий NAME_REQUEST / NAME_SUCCESS ? А заодно, что такое "действие", а что такое "создатель действия"...
2) Что такое редьюсер? Можете написать простой редьюсер без react/redux?*
3) Для чего нужен redux-thunk? Как он работает? Напишите (можно псевдокод) асинхронный создатель действия (либо, если надоело говорить "терминами" - асинхронный aciton)
4) Как компоненты приложения получают "пропсы" из "стора"?*
5) Можно ли (и считается ли это нормальным) использовать state, если используется Redux?
6) Почему в reducer'ax мы возвращаем новые объекты? Приведите пример, когда вы возвращаете новый объект, а когда тот же самый.
6.5) А так же, "как в js вообще это работает?". Например:

let obj1 { name: 'Test', age: 100 }
let obj2 = obj1
obj2.name = 'Test_new'

Что будет в obj1, почему? В каких случаях объекты могут быть равны?
7) Что возвращает функция connect (из react-redux)?
...

Общее:
0) package.json
1) Webpack, gulp, etc...
2) node.js
3) promise

Что-нибудь практическое:
1) Как бы вы валидировали форму, если ошибки валидации приходят после submit'a ее на сервер..
2) Почему не работает следующий код, сделайте чтобы работало
...
На истину не претендую, но такие вопросы имели место быть на собеседованиях. В беседе можно многое разузнать дополнительными вопросами и так далее. Так же, если часть вопросов вам неизвестна - не беда, многие и на половину ответить не могут.

p.s. возможно дополню...
p.p.s. звездочкой отметил, на мой взгляд не самые необходимые для junior-собеседования вопросы.

Его можно и нужно использовать параллельно с джанго.
Чаты, уведомления, обновления страницы инициируемые на стороне сервера, long-polling, websockets, push-уведомления, и т. д. Все для чего плохо подходит традиционный MVC фрэймворк.

"Tornado is a Python web framework and asynchronous networking library, originally developed at FriendFeed. By using non-blocking network I/O, Tornado can scale to tens of thousands of open connections, making it ideal for long polling, WebSockets, and other applications that require a long-lived connection to each user."
www.tornadoweb.org/en/stable

Ох...

Model View Controller. Да ну его, ему уже 45 лет (придумали в 79-ом году). Давайте лучше про Model View Adapter погокорим. это то что все используют в популярных фреймворках последние лет так 10 так точно.



Вообще в этом всем важно не только то, что каждая буква обозначает, а как они друг с дружкой связаны.

View - это не только HTML, но и вообще представление в целом, а так же логика его формирования. Шаблонизаторы, фильтры, различные функции/объекты помогаютщие нам сформировать view (например форматирование дат, сериализаторы и т.д.) В подавляющем большинстве случаев "представление" наших данных - это HTTP запросы и HTTP ответы. HTML - э то лишь часть HTTP ответа.

Model - Это целый слой, который может быть представлен в виде кучи отдельных объектиков, структур и т.д. Его задача - делать дела и хранить/менять состояние системы. Тут легко запутаться потому что термин "модель" много чего значит. Воспринимайте его как "слой логики" а не конкретные объекты. И да - база данных и прочая чушь - это детали реализации этого слоя. "не важные штуки" словом. Туда же и ActiveRecord, ORM-ки всякие. Это деталь реализации и все остальные чуваки (view и controller) о них знать ничего не должны (хотя иногда могут в целях упрощения).

Controller или адаптер. Это опять же не обязательно один объект. это может быть цепочка адаптеров (еще называют фронт-контроллером, middlewares и т.д.). Его задача весьма простая. Получаем представление данных на входе (HTTP запрос), определяем что надо делать, и просим модель что-то сделать (ни в коем случае не меняем ничего самостоятельно в контроллере, он только просит). Потом мы можем попросить модель вернуть нужный нам кусок состояния, и попросить View сформировать представление (HTTP ответ).

Как-то так. В целом же это я сейчас описал "идеальный мир". Вся суть этого подхода - разделение логики презентационной и логики приложения. Зачем это надо? что бы было проще жить! Обычно UI приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

Но на начальной стадии можно слегка нарушать эти правила, делать толстые контроллеры и т.д. В этом случае бизнес логика будет потихоньку "вытекать" из модели. Это не хорошо, и на хоть сколько нибудь больших проектах может привести к проблемам. Потому важно находить баланс.

Прочитал комментарии - фигней вы занимаетесь. Конкретная задача есть? Если нет - тогда к чему сотрясать клавиатуру, накидывая конфиг?
Есть такое понятие - "преждевременная оптимизация". Вам почти любой, кто с этим сталкивался, скажет, что преждевременная оптимизация - это плохо.
Как сказал Игорь Сысоев в одном из докладов - "Фактически настройка nginx сводится к выставлению worker_processes в число железных ядер на машине, или в auto, а дальше надо заниматься тюнингом самой системы".
С моей колокольни, обычно первоначальная настройка выглядит так:
В nginx.conf

worker_processes auto;
worker_rlimit_nofile 65535;
worker_connections 65535;
accept_mutex off;

А потом в conf.d описываем первый виртхост с минимальным конфигом...
Запустили что надо в минимальной конфигурации, посмотрели на все это дело и уже только потом тюнить - включить gzip где надо, выставить опции к сокетам (включая http2, куда ж без него :-) ), выключение sendfile, где не надо, включение aio, где надо, включение thread-pool если ситуация требует, выкручивание буферов в крайних случаях.

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