Ivan Bogachev

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

Возьмите animate.css и добавляйте нужные классы к элементам. Или, что еще лучше, достаньте из нее только необходимые вам анимации (postcss-animation может это дело автоматизировать) или посмотрите идеи в исходниках и сами их напишите, чтобы не тащить всю библиотеку ради пары десятков строк. Если хотите что-то совсем кастомное и необычное - идите на codepen, смотрите идеи там и адаптируйте под свои нужды. Тут главное не переборщить, все-таки сильно нестандартные или длинные анимации интересны первые пару-тройку раз, потом начинают раздражать.

Расположить круглые кнопки по кругу можно примерно так. На маленьких экранах можно убрать все трансформации и поставить кнопки в столбик/строчку. Логику переключения стоит делать на JS, чистый CSS - это интересно, но не практично.

Какие цели вы преследуете при создании мини/пет-проектов?

• Попробовать инструмент, который хочется попробовать, но не стоит тащить в основной проект, или спроектировать что-то относительно крупное самостоятельно, что очень полезно для начинающих.
  
• Создать какой-то источник дохода из этого проекта в отдаленой перспективе.
  
• Just for fun. Иногда можно сделать что-то совсем небольшое, что еще никто не делал, просто чтобы посмотреть, что из этого получится. Например я недавно пытался адаптировать уже существующую верстку одного из проектов для отображения в очках виртуальной реальности. Просто было интересно посмотреть, можно ли это сделать. Первую часть эксперимента описал в статье.
  

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

Это по какой-то системе делается или дизайнер просто так по красоте на глазок подбирает отступы?

Эта система в народе называется стайлгайд. В долгоживущих проектах иметь его в оформленном виде очень полезно. В нем есть и все размеры, и все цвета, и шрифты, а часто и компоненты по отдельности. Если у вас есть стайлгайд - то вы работаете по нему, макет страницы - это скорее для понимания "что в какое место поставить". Он может быть кривым/косым, хоть на бумажке нарисованным.

Надо ли именно такие отступы соблюдать или можно, например, просто в бутстраповский контейнер запихнуть секцию и не париться?

А вот если у вас нет стайлгайда и при этом кривой макет, то стоит спросить дизайнера/заказчика об этом и действовать исходя из их объяснений. Единственное, что стоит серьезно обсуждать - так это ситуацию, когда заказчик хочет pixel-perfect, до дизайнера уже не достучаться, а весь макет кривой настолько, что аж в глазах рябит. Там нужно или увеличивать сроки и цену или убеждать, что плюс-минус пара пикселей не имеют великого смысла и вы выиграете и по срокам и в перспективе при поддержке всего этого.

На постоянной основе - anime.js или делаю анимации на CSS, иногда использую D3.js.

как сделать cron, чтобы он вносил изменения в файл js

Это очень плохая идея, которая создает неявную логику работы фронтенда, ломает его сборку, и из-за которой можно очень крупно влипнуть в перспективе. Если на JS совсем никак нельзя эти точки генерировать - то лучше не в скриптах что-то менять, а сделать отдельный json файл, в котором будут храниться точки и потом его аяксом загружать на клиента. В таком случае вам нужно просто вставлять нужную строку перед последней строкой этого json файла (google->php insert string before last line), это будет очень простой скрипт, а для того, чтобы добавить его в cron вам понадобится (google->cron php script). Ответы на оба вопроса есть по первой ссылке на stackoverflow. Про то, как можно загрузить на клиента можно почитать здесь, там и пример есть и пояснения.

Слишком большой зоопарк технологий... После приема на работу менять область не хочу

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

какой нибудь шанс, что меня возьмут без портфолио

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

Какую именно примерно сумму называть в моем случае?

Есть три подхода:
- Назвать сумму. Вероятность не попасть в ожидания работодателя очень высокая. Как вести переговоры в случае непопадания - не понятно, нужно импровизировать.
- Сказать, что деньги не важны, важен опыт. Но какая-то минимальная планка все равно должна быть. Если вакансия стажерская - может подойти.
- Сказать что-то в духе "у вас есть вакансия, у нее определена зарплатная вилка, я готов согласиться на минимальную зарплату из этой вилки при условии ее пересмотра через месяц/три/шесть по результатам моего труда". Хороший вариант если вы все-таки что-то умеете. Фишка в том, что вы уменьшаете риск для работодателя, но при этом со временем все равно приходите к желаемой зарплате.

Если вопрос о компонентах - то скорее всего особой пользы от такого не будет. Если о каких-то глобальных вещах (даже вы сразу приводите пример с html) - может иметь смысл деление глобальных стилей на смысловые части: стандартная нормализация (например normalize.css), дополнительная нормализация (например дать всему box-sizing: border-box), все, что связано с текстами (размеры, шрифты), хаки и куски полифилов, которые со временем было бы хорошо убрать и.т.д. В случае крупного проекта вы можете думать не селекторами, а смысловыми группами - это не обязательно, но довольно удобно.

Ну и, разумеется, есть вариант "10 фрилансеров, каждый что-то добавил, получилось чудовище франкенштейна - куча швов и заплаток, но вроде работает". Там никакого смысла не будет, просто "так получилось".

Cобственно проблемы описаны тут. Решения там тоже описаны. Также проблемы решаются ограничением использования флексбоксов (дабы не мучать свой мозг и не тестировать каждый чих во всех браузерах). Ну и postcss-flexbugs-fixes в составе postcss-fixes тоже лишним не будет.