Ivan Bogachev

Как вы прокачивались?

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

На что стоит сделать упор в обучении именно верстки и малого количества js-а?

Методы зависят от наличия времени и изначального уровня обучаемых. В целом для развития понимания CSS полезно "рисовать" на нем. Грубо говоря один автопортрет или зверушка, сделанная самостоятельно от начала и до конца, даст опыта как десяток лендингов. В таких песочницах концентрация хитрых задач на верстку в разы выше, чем на обычных сайтах, и обучение идет быстрее. Ну и просто прикольные штуки получаются, можно внести элементы игры с плюшками за успехи. В последние годы эта тема стала очень популярной на CodePen в виде ежедневных разминок для ума.

Как обучали людей? У меня нет опыта в обучении людей

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

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

function compareCalories(colaA, colaB) {
    if (colaA.name > colaB.name) {
        return 1;
    } else if (colaA.name === colaB.name) {
        // . . .

Может тут нужно сравнивать calories, а не name у продуктов?

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

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

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

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

Нормально ли использовать сейчас эти технологии

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

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

Так вот, можно ли его использовать в своих проектах?

Вообще исходники этой штуки лежат на гитхабе, лицензия - MIT. Так что да, используйте на здоровье.

Вариантов много. По-хорошему, если вы пишете много простых компонетнов руками на чистом JS, то очень имеет смысл организовать систему классов для них. Один компонент - один класс. Организовать их можно по-разному (мне вот такая структура нравится). Для вашего примера можно начать с простого:

class MySlider {
    constructor(element, options) {
        const manager = new Hammer.Manager(element);
        
        manager.add(new Hammer.Pan({ threshold: 0, pointers: 0 }));
        manager.on('pan', (e) => {
            const percentage = 100 / options.numberOfSlides * e.deltaX / window.innerWidth;
            
            element.style.transform = `translateX(${percentage}%)`;
        });
    }
}

[].forEach.call(document.querySelectorAll('.slider-wrapper'), (element) => {
    const slider = new MySlider(element, { numberOfSlides: 2 });
});

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

Если не смотреть на то, как это там реализовано, а подумать своей головой, то я бы сказал, что это в разы проще сделать с помощью SVG. Раскраска - это по сути векторная картинка с большим количеством замкнутых контуров (элементы path), которые еще на этапе рисования объединены в группы (элемент g), которые потом будут краситься в один цвет, клик на группу легко делается стандартным addEventListener('click' ..., а заливка - это атрибут fill с цветом. Ну а выбор карандашей - это стандартная карусель, только не с картинками, а с кучей кружков, на которые можно кликать и выбирать цвет для заливки.

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

• Есть несколько секций с overflow: hidden
  
• Иконки дублируются в каждой секции, но с разными цветами
  
• В процессе скролла двигаем иконки, чтобы они оказывались на одном и том же месте относительно экрана
  

Прототип для изучения:

Вариант сделать это на position: fixed - не вариант, т.к. в сочетании с overflow: hidden может происходить неведомая магия.

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

Каких-то конкретных преимуществ этого подхода по сравнению с одним кадром на все я не вижу. Использовать ли для этого WebGL? Ну можно. Точно также, как и обычный canvas. Как выводить картинки на него вы легко загуглите, остается только посчитать координаты расположения кадров в картинке (по идее дизайнер должен их там аккуратно по сеточке расставлять) и выводить их по очереди.

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

Попробовал набросать свой вариант без jQuery:

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

какие паттерны применяются чаще всего на практике и где

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

1. Модули (делим код на независимые части)
   
2. Фабрики (для компонентов интерфейса)
   
3. Синглтоны (для хранилищ, точек сбора полифиллов / утилит и.т.д.)
   
4. Адаптеры (для зависимостей и полифилов, которые могут измениться / выпилиться)
   
5. Наблюдатели (для сбора происходящих событий в одном месте)
   
6. Хранители (для сохранения действий пользователя и "Ctrl-Z")
   
7. Стратегии (если действуем в зависимости от прилетевших данных)
   

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

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

result.hasOwnProperty(i) не может быть false. Во всяком случае я не придумал подходящего "кейса".

Может быть и false, если какое-то свойство определено в прототипе:

class Test {
    constructor() {
        this.foo = 'foo';
    }
};

Test.prototype.bar = 'bar';

const test = new Test();

console.log('foo' in test); // true
console.log('bar' in test); // true
console.log(test.hasOwnProperty('foo')); // true
console.log(test.hasOwnProperty('bar')); // false

Раз используется p5.js, то было бы логично взять функцию clear и в начале рисования кадра анимации очищать canvas:

function draw() {
    clear();
    // . . .
}

Если я все правильно понял:

function getRandoms(n, min, max, range) {
    let possibleNumbers = Array.from(
        Array(max - min + 1).keys(), x => x + min);
    
    let randoms = [];
    
    for (let i = 0; i < n; i++) {
        if (possibleNumbers.length === 0) {
            break;
        }
        
        const index = Math.floor(Math.random() * possibleNumbers.length);
        const value = possibleNumbers[index];
        
        randoms.push(value);
        
        for (let j = index + range; j > index - range; j--) {
            if (possibleNumbers[j] && Math.abs(possibleNumbers[j] - value) < range) {
                possibleNumbers.splice(j, 1);
            }
        }
    }
    
    return randoms;
}

$.ajax({
    type: 'POST',
    cache: false,
    url: '//woobl.ru/php/api/apiMusic/chat.php',
    success: function(data){
        console.log($.parseJSON(data.substr(1)));
    }
});

Можно округлить значение вручную:

format: {
    to: function (value) {
        return Math.ceil(value) + ' руб.';
    },
    // ...

В чем моя ошибка?

Вы изобретаете Array.slice:

function getPaginatedProducts(products, page) {
    const productsPerPage = 3;
    const begin = page * productsPerPage;
    const end = begin + productsPerPage;
    
    return products.slice(begin, end);
}

console.log(getPaginatedProducts(products, 0)); // 1,2,3
console.log(getPaginatedProducts(products, 1)); // 4,5,6
console.log(getPaginatedProducts(products, 2)); // 7,8,9