Max Donchenko

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

Всё это должно быть в игровой форме и максимально быть интересным и простым для понимания.

Например, на прогулке можно спросить:
Как отмерить ровно 2м веревки, если есть длинная верёвка неизвестной длины и рядом столб, диаметром 50 см?

И подобные.

Как только он научится правильно принимать простые логические решения, он - уже программист!

Останется ему (уже без Вашей помощи!) выучить любой язык, чтобы стать кодером и воплотить логику своих мыслей в алгоритм в виде кода.
А 3D, C, OSI или еще что - это уже вопрос десятый...

1. Самое простое - Watermark.
2. Сложнее - частичная доставка с сервера выбранной области изображения с шифрованием и расшифровкой на клиенте, и никогда не отображать изображение целиком. (т.е. типа контейнера со скроллом внутри канваса по аналогии с гугл-мапс).
3. Хардкорный стиль - Adobe Flash Application!
4. "Puzzle" - "хаотичная" (только с виду!) динамическая нарезка в режиме спрайт-карты и сборка через js. Формула - тоже разная каждый раз.
5. "Калька" - многослойное изображение из нескольких с альфа-каналом (с прозрачностью)
6. Класть изображение в JS-контейнер на серверной стороне, помещая в него метод отображения с привязкой к IP и браузеру клиента, и ровно на 15 секунд (чтобы загрузил и всё) и бинарные шифрованные данные, после загрузки скрипта у клиента - запрашивать токен с сервера на расшифровку данных.
(методы можно комбинировать)

Если используете vue.js, и, скорее всего, вам нужна отработка действия пользователя без перезагрузки страницы, тогда попробуйте плагин vue-resource. Чисто технически он отправляет на сервер запрос нужного вам типа (POST, GET итд.) с произвольными данными используя XmlHttpRequest.

this.$http.post('/select-city', {cityId: 1}).then((response) => {
          // success callback
      }, (response) => {
          // error callback
      });

Вышеприведенный сниппет может послужить примером как обрабатывать событие по клику на карточке, при этом на сервер вы можете отослать например ID карточки или что-то другое, а там уже нужно реализовать обработку POST запроса для роута /select-city (если рассматривать данный пример) и переданным ID как этого требует бизнес-логика вашего приложения.

В понятие кроссбраузерности поддержка IE8 не входит. Кроссбраузерность - это поддержка актуальных современных браузеров.
Поддержка IE8 - поддержка устаревших браузеров. За что в обязательном порядке нужно требовать солидную доплату.

Как осуществляется написание платежной системы касательно visa и mastercard или для конкретного банка? что делается в данном случае? (Допустим требуется работа со сбербанком и альфабанком).

Из личного опыта:
a. Приезжаете в офис банка у которого есть услуга "интернет эквайринг", показываете своё юрлицо, уставные документы, бенефициаров, обороты от 50 млн в месяц.
* некоторые работают и с меньшими оборотами, но % будет крайне не выгодным.
** без запущенного и работающего проекта идти в банк бессмысленно.
b. Ждете 2-6 недель пока СБ банка проверит все.
c. Ждете 2-4 недели пока банк подпишет договор
d. Получаете реквизиты и документацию API конкретного банка.
e. Реализуете
f. Ждете 1-2 недели пока банк проверит что у Вас все согласно их протоколу.
g. Получаете боевые реквизиты.

Учтите что:
1. Если Ваши объемы меньше чем 50млн+ в месяц - с вероятностью 99% Вам будет СИЛЬНО выгоднее работать через посредника. Посмотрите на uniteller.ru , payture.com/ru , payler.com - если Вы будете достаточно убедительны на переговорах, вполне реально сторговать их до 2-2.5% даже на маленьких оборотах (1млн-5млн)

2. Прямые API банков мягко говоря не современны. Как правило там не будет ни удобного личного кабинета, ни вменяемой службы поддержки - ничего. Зато будут проверки, требования бумажной отчетности и прочие милые сердцу советского бюрократа вещи.

3. Риски при работе через посредника - по факту минимальны. Все приведенные выше делают выплаты ежесуточно, т.е даже если посредник накроется - Вы максимум рискуете дневным оборотом.

С учетом данных пунктов, по моему мнению прямой договор с банком имеет смысл если у Вас настолько большие обороты - что разница в десятые доли процента окупает весь этот геморрой.
По факту есть море проектов с большими оборотами (mamba, badoo, etc) кто продолжает работать через агрегатор, минимизируя расходы на юристов, бухгалтеров, техническую поддержку работы шлюза итд итп.

Я думаю, что у них оценивается: минимум кода, самый короткий (оптимальный) алгоритм. Здесь нигде не требовали использование ООП.
1. Задание 1 - динамические цепочки (очереди). Надо было "растащить вагоны" и "сцепить" их (конечный с начальным пунктом). Это делается в 1 проход по списку карточек.
2. Задание 2 - проверка знаний нативки JS и логики работы мозга при самопостановке задачи и её реализации: селекторы/regex, деревья: просто перебор нужных с изменением/запросом свойств объектов.
PS: может им на C++ написать и прогнать через LLVM на asm.js?)
хотя, думаю, тоже не прокатит - им же JS-исходник нужен)

Ну давайте я покритикую:

возьмем файлик

1) вы не разобрались как объявлять методы у прототипов с новой нотацией `class`:

class Travelsort {
    constructor() {}
    sortTickets(tickets) {}
}

2) вы не умеете пользоваться исключениями.

if (!Array.isArray(cards)) {
    throw new ValueError('Wrong input');
}

3) использование let там где должен использоваться const

4) в принципе использование переменных там где их быть не должно

5) вы зачем-то реализовали свою функцию сортировки, я не увидел в требованиях отсутствия возможности использовать старый добрый Array.prototype.sort

6) Общие замечания по кодинг стайлу. snake_case там где должен быть camelCase, пишите с большой буквы то что должно быть с маленькой и т.д.

7) нарушения принципа единой ответственности. У вас объеткт умеет и сортировать и писать куда-то. Это категорически плохо.

8) Если исправить 7-ой пункт то наш класс превращается просто в функцию.

Далее... берем следующий файлик

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

2) вы зачем-то тут в прототип объекта строки впихиваете функции для парсинга CSS. Таким образом мы нарушаем принцип единой ответственности. Да и в целом расширять без надобности прототипы объектов как-то не ок.

Чуть дальше проскролил - вы пытаетесь расширить прототип строк для того что бы добиться API jquery? ух, батенька.

3) очень много дублирования.

4) очень плохо с protected variations.

Справедливости ради, ваш код входит в категорию ">50% JS кода", так что не расстраивайтесь. Просто для работы в яндексе нужен чуть более высокий уровень и понимание вещей.

1. вместо /v1.0/ используйте теги гита
2. test | tests | ... - обычно это каталог для авто тестов
3. build | release | ... - это каталоги для собранных (релизных) файлов, тот же jquery.min.js например
4. external | vendor | ... - каталоги с внешними зависимостями текущего проекта
5. src | lib | ... - сам код проекта
6. bin - каталог с исполняемыми файлами для проекта
7. var | tmp | ... - каталог для временных файлов
8. Makefile - настройка для консольной утилиты make
9. bower.json - зависимости bower
10. package.json - зависимости npm
...

Видите ли, сейчас одно-файловые скрипты особо никто не пишет (не берем в расчет тривиальные на полторы строки).