Igor Kalashnikov

с помощью lodash

const obj = _.fromPairs(_.map(data, n => [ n.name, n ]));

на чистом js

const obj = data.reduce((acc, n) => (acc[n.name] = n, acc), {});

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

https://gist.github.com/zmts/802dc9c3510d79fd40f9d...
Отдаешь два токена и время жизни access token, которое обычно минут 30.
Соответственно если угоняют access, то он стухнет через пол часа, а если угонят оба, то юзер не сможет обновить по реврешу, его кинет на перелогин и тогда у угонщика все стухнет.

реально ли вообще заниматься кодингом столько часов (8 часов в день, 5 дней в неделю) на протяжении многих месяцев, лет?

Нет конечно. По крайней мере продуктивно.

на галеры. в смысле в контору.
если контора нормальная:
1. быстрее подростешь в проф.плане
2. увидишь/поймешь как устроена разработка ПО
3. прокачаешь коммуникационный скил

а потом уже можно на фриланс, если захочется свободы.

Весь ваш план обучения никак не годится для получения знаний. Он годится только для ознакомления.
Почему? Потому что в нем ВООБЩЕ нет практики, одно чтение книг.

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

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

Пишите код, читайте требования к вакансиям, пишите код, ходите на интервью, изучайте вопросы, которые были на интервью, ходите на следующие интервью.

Не рекомендую ничего делать с сайтом. Как бы ни было жалко работу, своя репутация дороже - это на случай, если вы хотите навредить.
Но:

1. Вы можете попробовать найти заказчика, для которого написан сайт, написать ему письмо или связаться другим способом и разъяснить, что вся работа по сайту на самом деле была сделана не студией, а лично вами. Можете вкратце пояснить, что студия с вами не расплатилась, и если заказчику нужны будут доработки, то пусть он связывается с Вами напрямую, а не через студию, которая вас "кинула".

2. Сайт смело можно добавлять в свое портфолио и искать другую работу.

3. Деньги жалко, но это всего лишь деньги и всего лишь один из тысяч эпизодов этой жизни. Постарайтесь взять от ситуации больше позитива. Испортить репутацию нехорошей студии можно и позже, когда вы поймете, что никаких других вариантов нет, а вы уже нашли другую работу и там вас оценили.

"Точка следования" - alenacpp.blogspot.ru/2005/11/sequence-points.html
Там есть почти ваш случай - x[i] = ++i;
Значение не то чтобы не определено, компилятор в праве решить что сделать сначала - вычислить адрес x[i] или сделать ++i.
Я так понял.

1) vuejs - простой и ненавязчивый фреймворк который призван максимально просто и тесно взаимодействовать с произвольной версткой, в этом плане он очень похож на angular 1 , только проще, чище и чуть логичнее. При этом оп предоставляет инструменты для компонентного подхода(для фанатов клиента) и даже серверный рендеринг. На мой взгляд vuejs - это идеальное решение для быстрой разработки с допустимым уровнем качества.

2) Backbone - это далеко не библиотека и он в прошлом. Его главный минус - это невозможность управлять поведением dom, если этот dom не был сформирован через backbone-engine. Что делает его почти бесполезным, если только ты не хочешь написать проект , который будет намертво зависеть от выбранного инструмента и в котором будет невероятное множество клинтских шаблонов

3) React - это скорее концепция + движек для ее реализации, чем фреймворк Его существенный плюс в том, что верстка идет с изолированной логикой в паре, но это плюс скорее концептуальный , точно также можно поступать и используя jquery в изолированом скоупе прямо в верстке в html- фалах - виджетах (Я пробовал уже после реакта и это очень просто и надежно, но я fullstack и мне от клиента большего не нужно)
Минус реакта в том, что верстка должна рендериться только через шаблонизатор реакта, это значит что весь проект нужно рендерить через реакт иначе же в проекте будет хаос.

4) Ember - тоже говорят вещь хорошая, но я бы никогда не выбрал Ember по той же причине что и backbone.
5) Riot и еще 50 подобных фреймворков похожи либо на Angular, либо подражают React, либо идут по пути Backbone&Ember или же какие-то "гибридные" со своими фишками.
6) Angular 2 - я пока не понял его фишку.

Если рассматривать весь этот зоопарк с точки зрения бизнеса - то лучше выбрать то, что максимально проще и либеральней

JS:
viewportchecker.js или wow.js на выбор
CSS:
animate.css, есть и другие, но эта самая популярная

Я чаще всего использую связку viewportchecker + animate.css.

$('.bxslider').addClass('hidden').viewportChecker({ // добавляем класс hidden
// ждем появления блока в поле зрения, чтобы применить к нему анимацию
    classToAdd: 'visible animated fadeIn', // меняем классы, выполняем анимацию
    offset: '50%', // доп параметры, когда начинать анимацию
    repeat: true, // повторять при возвращении снизу вверх
});

PS: Классы hidden и visible нужно добавить в css.
Если используете Bootstrap, то лучше классы сделать другие, чтобы не было конфликта.

Преимущество подключения именно viewportchecker для меня.
То, что его можно использовать для любых скриптов вообще, не только для анимации.
Запуск видео, инициализация слайдера, "убийство" слайдера, особенно animateNumber.js ( описание ) удобно привязать, чтобы анимация цифр срабатывала не при загрузке, а именно в момент скролла до блока.
И библиотека весит совсем немного.

Ну делать адаптив вам так никто не мешает и тут ничего такого вы особа и не описали. Есть 2 способа верстать адаптивно - сначала мобильную версию и из неё переходить в десктоп, либо обратно. Только так.

На счет того, как организовать процесс - изучите БЭМ для этого дела. С ним хорошо верстать. Если ещё пользоваться препроцессорами какими-то - шикарно, а ещё если и сборщиками - вообще идеально (ну less/sass/postcss можно по-разному компилить вплоть до плагинов в редакторе).

Как делаю я:
1. Клепаю html полностью, естественно именую классы по БЭМ (можно посекционно делать - сделал секцию шапки, запилил стили, сделал секцию подвала и опять же запилил стили, кому как удобно)
2. Создаю на каждый (ну или почти на каждый) БЭМ-блок свой .less файл.
3. В каждом файле верстаю сначала моб версию, потом в нём же чуть по-ниже пишу нужные media
4. Конечно же сборщиком всё собираю в 1 css файл и всё (сборщик работает, конечно, постоянно, чтоб компилировать из less в css ну и минимизировать сразу и автопрефиксить).

Этап 3 можно делать подругому, к примеру делать отдельно media.block.less под каждый блок и всё это загонять в самый низ сжатого css, либо весь media делать в отдельном файле просто, всё зависит от того, на сколько много вам нужно писать media (у меня бывают простые проекты, где media нужно буквально 2-3 штуки в 50-70 строк кода максимум, для этого не вижу смысла всё в отдельные файлы блоков писать, пихаю просто всё в один).

P.S. Конечно же отдельные файлы less для миксинов и переменных ну и основных стилей страницы.

P.P.S Если вы не знаете препроцессоров - можно всё тоже самое делать и в обычном css, всё равно будет удобно. Раньше я считал дикостью такой подход. Сейчас без него жить не могу.