Здравствуйте, StandAlone, Вы писали:

SA>Открываем консоль, видим что валится emoji.js:1129, смотрим этот код.
SA>И испытываем истинное наслаждение от знаменитого качества прославленных разработчиков сайта-идеала для апологетов JS

И давно vk стал идеалом для апологетов JS ? Ты андройдом пользуешься ? Если так, то ты почти каждый день пользуешь софт, который писан на жеэсе и даже не подозреваешь этого.

SA>Предвосхищая твой вопрос, Ikemfula "А чё не так-то, што случаицца", отвечу сразу.
SA>С этим кодом все так. Он прекрасен. Он совершенен в своей форме свернутой на донышке унитаза вонючей личинки. Так же как твоя реализация Визитора или событий через браузерную очередь событий от UI.

С жеэсом только одна проблема — его слишком много и повсюду, потому возникает ощущение, что глючит именно он. Хоть что нибудь, да будет глючить.

Здравствуйте, gandjustas, Вы писали:

SA>>Опишите, пожалуйста, как бы Вы решали с использованием JavaScript одну из типичных задач программирования.

G>думаешь там что-то удивительное будет?
...
G>Вообще в JS не принято много писать. Обычно все что надо можно найти в npm\bower\тупо в интернетах.

Здравствуйте, Ikemefula, Вы писали:

I>С жеэсом только одна проблема — его слишком много и повсюду, потому возникает ощущение

Здравствуйте, elmal, Вы писали:

E>Попросить бекенд отсортировать за тебя! Фронтэнд должен заботитьсы об эффективности, ибо он выполняется на крайне малопроизводительных ресурсах.

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

E> Потому сортировка, даже если это 10 элементов — должна выполняться на бекэнде. Там сервер мощный, не то что мобила на 2 гигагерца и 4 гига памяти.

Уже на десятке-другом одновременных пользователей на каждого из них приходится меньше ресурсов, чем даже на кетайском андроедофоне. С другой стороны, отдельные любители ангуляров умудряются добиться конкретных тормозов в банальном интернет-магазине на полноценном Core M, а на смарте таким суперсайтом пользоваться просто невозможно.
Вобщем, все как обычно — крайности в инженерном деле не работают. И, кстати, к вопросу о full stack из соседнего топика.

Здравствуйте, StandAlone, Вы писали:

SA>3) Реализуйте паттер Visitor.

В динамических языках полностью бессмысленный паттерн. Смысл визитора — динамическая диспетчеризация по типу вне собственно типов-аргументов. В JS можно извне подвесить любому прототипу любой метод, так что визитор не нужен.

Здравствуйте, sharpman, Вы писали:

S>Ты учитель информатики в школе?

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

Здравствуйте, Kesular, Вы писали:

K>Один тимлид и/или архитектор, один старший программист и один "просто программист". И я не преувеличиваю, сам видел такие примеры в реальности.

И что с ними не так? По сути три разработчика, просто разного уровня. К ним еще, обычно, полагается PM и product owner. Совершенно типовая структура, применяемая в куче вполне успешных софтовых компаний.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС> В JS можно извне подвесить любому прототипу любой метод, так что визитор не нужен.

===

function B() {} // базовый конструктор
function A() {} // производный конструктор

b = new B();
A.prototype = b;

var sv = A.prototype;
delete A.prototype;
a = new A(); // создаём объект-экземпляр с помощью A;
A.prototype = sv;

alert(a.constructor) // (?)
alert(a.constructor.prototype.constructor) // (?)
...
// ???
// ??????
// W !!!! T !!!! F !!!!!!

Здравствуйте, Vetal_ca, Вы писали:

V_>Пособеседовался в одной компании. Все очень понравилось, не большая, динамичная, открытая.

Тут и дальше по ссылкам в блог есть хорошее описание проблем Node.js.
Главное понять, что в некоторых случаях node.js будет выбором похуже чем другие системы.
Всё нужно применять с умом.

Здравствуйте, StandAlone, Вы писали:

SA>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>> В JS можно извне подвесить любому прототипу любой метод, так что визитор не нужен.

SA>===
SA>

SA>function B() {} // базовый конструктор
SA>function A() {} // производный конструктор

SA>b = new B();
SA>A.prototype = b;

Это JS образца пятнадцатилетней давности.

Вот современный JS, вставь его себе в браузер и убедись:

var _someProperty = Symbol();

class A_ES6 {
    constructor(value) {
        this[_someProperty] = value;
    }

    get someProperty() {
        return this[_someProperty];
    }

    set someProperty(value) {
        this[_someProperty] = value;
    }

    doSomething() {
        console.log(`A_ES6 ${this.someProperty}`);
    }
}

class B_ES6 extends A_ES6 {
    constructor(name) {
        super(name);
    }

    doSomething() {
        console.log(`B_ES6 ${this.someProperty}`);
    }
}

new B_ES6('xxx').doSomething()

Если хочешь изврата, то открой для себя хотя бы Object.create()

function ctorA(value) {
    this.value = value;
}

ctorA.prototype.method = function () {console.log('ctorA',this.value)}

function ctorB(value) {
   ctorA.call(this, value);
}

ctorB.prototype = Object.create(ctorA.prototype)
ctorB.prototype.constructor = ctorB;

ctorB.prototype.method = function () {console.log('ctorB', this.value)}

new ctorB('xxx').method()

Здравствуйте, StandAlone, Вы писали:

НС>> В JS можно извне подвесить любому прототипу любой метод, так что визитор не нужен.

SA>===
SA>

SA>function B() {}
SA>function A() {}

SA>b = new B();
SA>A.prototype = b; <-----------

SA>var sv = A.prototype;
SA>delete A.prototype; <-----------
SA>a = new A();
SA>A.prototype = sv; <-----------

SA>alert(a.constructor) // (?)
SA>alert(a.constructor.prototype.constructor) // (?)

1 prototype — нативное свойство. Свойства, особенно нативные, удалить не получится. Потому выделенные строчки ничего не меняют.

2 Теперь, если ты в консоли укажешь вот такое A.prototype.constructor === a.constructor, то увидишь true. Почему так ? Это ожидаемое поведение, как и должно быть. А вот a.constructor === B даёт true тебе кажется странным. Объяснение простое — ты сам перезаписал прототип A.

Если это трудно понять, то достаточно вывести console.dir(C.prototype.constructor) где C новая функция, ничем не запомоеная.
С.prototype.constructor === C !
Теперь если сделать c = new C() то экземпляр C получит в качестве значения constructor именно C.prototype.constructor.

Надо ли объяснять, что в твоём случае с А ровно так же, только ты запомоил прототип и указал там B. Т.е. всё просто — именно прототип определяет объект. Собственно это следует из того факта, что JS это прототипное ООП.

В сумме получается так — для тебя в новинку это самое прототипное ООП, но ты продолжаешь его насиловать и ждёшь, что оно станет привычной тебе симуловской разновидностью.

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

Здравствуйте, mgu, Вы писали:

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

mgu>Для троих кодировщиков уже требуются ведущий, менеджер и политрук срам-мастер. Так что получается уже 6 голов.

И это правильно. Всё как и везде. Ремонт в квартире доверь исполнителям, что бы никто их не контролировал, не руководил и убедись.

Если ремонт делается силами одного человека, то строитель, бригадир и прораб это один человек и это просто роли, которые этот человек совмещает.
Если ремонт посложнее и строителей несколько, то самый минимум — выделяется бригадир и он же выполняет роль прораба.
Если ремонт еще сложнее, то бригадир уже не справится и роль прораба лучше доверить отдельному человеку.
При этом с заказчиком коммуницируют все еще бригадир и/или прораб.
А если ремонт еще сложнее, то коммуникацию с заказчиком лучше доверить отдельному человеку.

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

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

Здравствуйте, Ikemefula, Вы писали:

I>И это правильно. Всё как и везде. Ремонт в квартире доверь исполнителям, что бы никто их не контролировал, не руководил и убедись.

Интересное сравнение.

I>В разработке все идет примерно к такой же модели. Для троих кодировщиков нужен ведущий(бригадир), менеджер(прораб) и коммуникатор, частный случай которого есть скрам-мастер. В идеальном случае роли могут быть распределены между троими кодерами. Но в большинстве случаев это уже не так.

Коммуникатор -- это, скорее, продукт-говнер. Я при всей своей фантазии не могу себе представить личность, которая каждое утро допрашивает строителей по поводу того, что им мешало танцевать.

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

Плавали, знаем. Если кратко, то кадры решают всё. А уж как они садятся, не имеет значения.

Здравствуйте, mgu, Вы писали:

I>>В разработке все идет примерно к такой же модели. Для троих кодировщиков нужен ведущий(бригадир), менеджер(прораб) и коммуникатор, частный случай которого есть скрам-мастер. В идеальном случае роли могут быть распределены между троими кодерами. Но в большинстве случаев это уже не так.

mgu>Коммуникатор -- это, скорее, продукт-говнер. Я при всей своей фантазии не могу себе представить личность, которая каждое утро допрашивает строителей по поводу того, что им мешало танцевать.

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

Здравствуйте, Ikemefula, Вы писали:

I>Коммуникатор нужен не для контроля исполнителей. Для этого у них бригадир-тимлид. Коммуникатор говорит с заказчиком, что бы у заказчика была полная информация о состоянии дел и что бы у заказчика узнавать все необходимые требования, уточнения и тд.

Так и я о том же:

Владелец продукта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.

https://ru.wikipedia.org/wiki/Scrum

Здравствуйте, mgu, Вы писали:

I>>Коммуникатор нужен не для контроля исполнителей. Для этого у них бригадир-тимлид. Коммуникатор говорит с заказчиком, что бы у заказчика была полная информация о состоянии дел и что бы у заказчика узнавать все необходимые требования, уточнения и тд.

mgu>Так и я о том же:

mgu>

mgu>Владелец продукта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.

Ты совсем о другом.

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

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