Ivan Bogachev

согласно БЭМ

Ради ясности стоит отметить, что если почитать первоисточник, то окажется, что БЭМ - это не только про названия классов и разделение всего по файлам, там целый набор инструментов идет в комплекте. Если вы хотите именно использовать весь их стек - то начать стоит оттуда.

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

Было бы логично использовать модули (гугл -> es6 modules).

P.S.: И почитайте про то, как сейчас скрипты собираются - это не просто склейка всего в один файл, там все немного сложнее.

Что делает frontend разработчик кроме создание внешнего вида сайта?

Пьет смузи, катается по офису на гироскутере, делает умное лицо на конференциях.

Скучно ли быть фронтендером? Эта однотипная работа?

Кто-то клепает однотипные магазины на потоке, а кто-то делает замороченные рекламные сайты с кучей анимаций, интерактивные 3d-презентации и другую дичь. Это очень разные вещи. Но рутина наступает везде. Любая сложная область в конечном счете разбивается на набор известных задач, и все, дальше нужно делать почти одно и то же много раз. Принципиально новые проекты - большая редкость в программировании, лишь единицы что-то изобретают, большинство же решает задачи бизнеса. А они особо не меняются. Таков мир. А интерес - понятие очень субъективное. На вкус и цвет фломастеры разные.

Я натыкаюсь на такие блоги случайно и редко... Где и как искать... с раскрытием инфы на острие... на кого вы подписаны и не нарадуетесь?

Подписался в твиттере на ~50 аккаунтов людей и компаний, постящим по интересующим меня направлениям и все, больше ничего делать не надо (большее количество подписок не имеет особого смысла, там все повторяться начинает, подписался грубо говоря только на тех, о ком знал, кто это вообще). Как в отрасли происходит что-то действительно "на острие" и имеющее хоть какую-то практическую значимость - это сразу появляется в ленте. Статьи, инструменты, просто интересные идеи - все там. Можно пару раз в неделю заходить и узнавать, что в мире происходит. Такой своеобразный агрегатор всего стоящего получается.

Горизонтальная прокрутка - transform: translate для контейнера, привязанный к скроллу.
Косые блоки - transform: skew для блока, skew обратно для контента.
Размер косого блока удобно выразить через единицы vh.
Картинкам - object-fit: cover.
При наведении на блок меняем его opacity до 1, плюс transform: translate для текста и scale для картинки.
Переходы между страницами - немного css-трансформаций + что-нибудь вроде barba.js.

Авторы сего шедевра вместо CSS решили все рассчитывать на JS. Не удивительно, что все тормозит.

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

Добавлю еще пару слов про эту задачу в целом (не про сайт по ссылке в вопросе, а вообще). Если нужно делать такую статичную штуку с выбором цвета стен, обоев, полов и.т.д., особенно если нужно дать пользователю возможность выбирать свой вариант, то можно поиспользовать SVG. Это немного внезапно, но тем не менее. Основная часть комнаты, тени и рефлексы - это обычная картинка с прозрачностью в нужных местах (ее можно встроить в SVG через тег image), стены, полы - это простые прямоугольники, на которые наложены 3D-трансформации. Дальше их можно заливать как угодно - цветами, текстурами... и не нужно будет ломать себе мозг вопросом о том, как на лету повернуть "нормальную" текстуру и сделать из нее пол с перспективой. Мебель заливается цветом не намного сложнее - делается SVG-маска в форме предмета мебели и применяется фильтр hue-rotate. Таким образом можно "на коленке" соорудить работающий вариант такой презентации.

Что посоветуете? Брать тестера? Менять разработчиков? Менять процессы?

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

А как придет понимание, что есть пользователи и нужно о них заботиться, уже можно говорить о внедрении планок качества или об автоматизации тестирования. Можно начать не с хардкорного TDD, а с более мягкого подхода, соответствующего этой идее: взять что-нибудь вроде codecept.js и по-быстрому описывать сценарии взаимодействия пользователя с системой. Сначала основные, которые обязательно должны работать, потом альтернативные, где обработка ошибок происходит. Собственно и изначальное ТЗ формулировать в виде сценария взаимодействия. Можно отвести под тесты отдельный сервер (ненужное железо всегда можно где-нибудь найти). Потом, как привыкнут, попробовать покрывать все юнит тестами или еще что-то внедрять, своим примером показывая, что это и правда может экономить время на поиск багов или давать какие-то еще полезности. Иными словами стоит сначала перестраивать мышление, а потом уже улучшать технические моменты.

Ваши работы на пару секунд попадают в ленту /pens/recent/. Это тысячи демок каждый день. А может и десятки тысяч. Может быть кто-то увидит ваши в этом потоке безумия, но в лучшем случае это будет пара человек.

Если ваши работы снабжены релевантным заголовком/описанием/тегами, то другие люди могут их нагуглить (или в местном поиске найти). Будет немного просмотров. Но не сразу и не факт.

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

Если контент стоящий и он попадет на глаза модераторов (Chris Coyier, Marie Mosley, Gabi, Alex Vazquez, вроде еще кто-то был), то его могут отправить в очередь в ленту /pens/picks/. Полезно шарить свои работы в твиттер - они мониторят упоминания @CodePen. Вам придет оповещение со звездочкой и как очередь дойдет, ваш проект появится там. Путь к известности на СodePen начинается где-то в этой ленте, от нее всего шаг до главной ленты с популярными демками. Там просмотры растут очень быстро.

Какие языки для его написания необходимы?

HTML, CSS, JS, GLSL. В целом тут все строится на WebGL (Three.js будет хорошим подспорьем) и CSS-анимациях (которые можно по-быстрому вкрутить туда через CSS3DRenderer). Есть любители делать все на WebGL, но это сложно, ведет к костылям и тормозам. Дальше нужно сделать 3D-модели для всего, долго расставлять все по сцене, добавить немного физики, написать пару фрагментных шейдеров, которые размылят картинку где это необходимо, и двигать камеру по сцене. Самое главное тут - производительность, которая сильно зависит от прямых рук разработчика и его способностей к написанию алгоритмов своими руками и последующей оптимизации. Большинство таких сайтов имеют проблемы с производительностью, но обычно это следствие горы скриптов, которые принесли в проект тупой копипастой (часто это чьи-то эксперименты с CodePen, которые никто и не начинал доводить до ума - они показывают идею, но аццки тормозят). Ну и про замысел не стоит забывать - с этим обычно сложнее всего.

Из популярных вариантов еще можно посмотреть на three.js. Есть raycaster для определения наведения мыши на определенные объекты, вращение камеры вокруг точки делается в пару строк (или можно мышкой прикрутить через OrbitControls), c помощью CSS3DRenderer для этой библиотеки можно интегрировать сверстанные элементы интерфейса прямо в трехмерную сцену, что может быть довольно удобно в некоторых случаях.

Что и как тестируют ???.... простым языком.... смотрю про тестирование, мне кажется там больше заумной терминологии чем реальной работы

Да нет, там как раз все просто. Грубо говоря есть три уровня:

• "Делает ли эта функция то, что должна?": Мы (как тестировщики) знаем, что функция делает внутри себя, и убеждаемся, что она продолжает это делать и в будущем. Это именуют модульным или юнит-тестированием. В маленьких проектах обычно его не делают или покрывают такими тестами только определенные части проекта. Помогает оперативно находить изменения в поведении существующих модулей, которые так могут долго оставаться незамеченными и потом не понятно, что вызвало поломку. По идее такие тесты должны в автоматическом режиме проходить перед сборкой кода для продакшена.
  
• "Работают ли несколько модулей вместе так, как задумано?": Мы не знаем, что происходит внутри связки, но знаем, что есть на входе и что должно быть на выходе. Это именуют интеграционным тестированием. По идее оно помогает находить проблемы на стыке модулей, когда поведение одного модуля поменяли, а про другой забыли. В реальном мире встречается не так часто, т.к. требует включения мозгов для написания тестов.
  
• "Решает ли система задачи пользователя?": Это по-разному называют. Тут идет работа от ТЗ. Мы знаем, что должен получить пользователь от готовой системы в ответ на свои действия, но как она работает внутри нам фиолетово. Наиболее понятный сценарий такого тестирования - заранее написать кейсы, примеры того, как пользователь решает какую-то задачу, а потом перед каждым релизом "прокликивать" нужные последовательности кнопок или что-то вроде того. Это могут делать руками (студенты-обезьянки) или можно автоматизировать. Посмотрите примеры использования CodeceptJS и все станет ясно. По-хорошему это стоит делать на проектах любого размера, но на практике...
  

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

disqus

Этим все сказано. Запрос делает он. Несколько месяцев назад кто-то на сайте самого disqus жаловался на проблему с долгой загрузкой и как раз запросами на vanillavalue, но видимо так и не решили этот вопрос.

Что эта за шалапань?

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

Как его победить?

Никак. Если есть такая возможность, то можно поиграться с CSP на ваших сайтах. Люди говорят, что с помощью этой штуки можно уменьшить количество запросов и немного ускорить загрузку disqus. Но от зомби серебряная пуля может и не спасти. Будьте готовы к тому, чтобы со временем перейти на другую систему комментирования.