Технология CORE

— посмотрите на ваши конструкторы. при усложнении задачи они станут монструозными и в одном месте будет слишком много знаний о разных задачах. это плохо

Не понял, почему при усложнении задачи мое решение должно стать монструознее вашей реализации? Пока 0:0.

— рефакторинг в моей версии сводится к копи-пасте методов, в вашей — ещё и к переорганизации конструкторов. Это дополнительные минуты. зачем эта лишняя трата времени?

Из реорганизации — перенос подписки на событие. В вашем случае, например, при выносе handleCoinClick надо будет перенести и EventPoint, а в моем случае только cut&paste метода, так что паритет, 1:1

— в вашем случае код, относящийся к задаче (подписка на событие и обработка этого события), лежит в двух разных местах, что опять ведёт к трате времени при изучении кода. Зачем? Одна задача — один метод, зачем усложнять?

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

— в вашем случае события — это просто строки. об автодополнении средствами IDE можно забыть. в моём автодополнение есть.

Про IDE — ну, разве что да. Но подобные архитектуры очень завязаны на схему событий, так что в любом случае одной IDE не обойтись, придется вести документацию и с ней сверяться, но ладно, 2:2.

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

В вашем тоже. В этой задаче самое главное — понять, что отображением данных должен заниматься один объект, обработкой баланса другой, а определением выигрыша — третий. Ваш подход показывает только их способ взаимодействия, а найти такой способ не так уж и сложно, что и было показано в моем примере. 2:2

— ваши конструкции вроде «this.showWin.bind» — это ещё одна зависимость от какого-то фреймворка. зачем? в моём случае решение полно и не требует внешних зависимостей, предоставляя полный и удобный стек.

Function.prototype.bind — стандартная функция ECMAScript5, частичное применение и указание контекста. Тут полностью работающее решение, из зависимостей только jQuery, и то не принципиально и легко вырезаемо, т. к. нужно только в UI (к тому же у вас jQuery тоже есть в зависимостях). Так что в моем решении на одну зависимость меньше, что явно лучше, 3:2

Итого, мое наколенное решение ничуть не хуже, а то даже и лучше (как минимум, отсутствием дополнительных зависимостей).

Технология CORE

Ну и про реализацию. Описанный диспетчер зависимостей легко реализуется парой функций subscribe и trigger:

var handlers = {};

function subscribe(evt, handler) {
    if (!handlers[evt]) handlers[evt] = [];
    handlers[evt].push(handler);
}

function trigger(evt, data) {
    if (handlers[evt]) {
        handlers[evt].forEach(function(handler) { handler(data); });
    }
}

Вот пример реализации той же задачи про монетки:

function Balance() {
    this.balance = 0;
    subscribe('UI.coinClicked', this.addCoins.bind(this));
}

Balance.prototype.addCoins = function()  { 
    this.balance += 15;
    trigger('Balance.changed', this.balance);
};

function WinWatcher() {
    subscribe('Balance.changed', this.checkWin.bind(this));
}

WinWatcher.prototype.checkWin = function(balance) {
    if (balance > 20) {
        trigger('WinWatcher.userWins');
    }
};

function UI() {
    $('.coin').click(function() {
        trigger('UI.coinClicked');
    });

    subscribe('WinWatcher.userWins', this.showWin.bind(this));
}

UI.prototype.showWin = function() {
    $('.you_win').animate({opacity: 0});
};

subscribe('DOM.init', function () {
    var ui = new UI(),
        balance = new Balance(),
        winWatcher = new WinWatcher();
});

Тут также несложно добавить новый функционал:

function GatherStat() {
    subscribe('UI.coinClicked', this.sendClick.bind(this));
    subscribe('WinWatcher.userWins', this.sendWin.bind(this));
}

GatherStat.prototype.sendClick = function() {
    $.post('/stat/gather/ajax', {click: 1, date: new Date});
};

GatherStat.prototype.sendWin = function() {
    $.post('/stat/gather/ajax', {win: 1, date: new Date});
};

или разделить UI на два объекта:

function UI() {
    $('.coin').click(function() {
        trigger('UI.coinClicked');
    });
}

function UIWin() {
    subscribe('WinWatcher.userWins', this.showWin.bind(this));
}

UI.prototype.showWin = function() {
    $('.you_win').animate({opacity: 0});
};

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

Технология CORE

Статья у вас об архитектуре, про подход там ничего не сказано, вернее, сказано, что надо «просто описать то, что было в задаче» — и это прекрасно реализуется в примере, который «еще хуже», опровергая ваш же тезис, что «языки программирования не похожи на язык описания задач, которым мы пользуемся при постановке». А далее следует (безо всякого обяснения, почему так надо) описание реализации той же задачи с использованием переименованных MVVM + IoC. Я молчу про спорные моменты конкретной реализации, где обработчик событий знает об источнике, и сам подписывается на соответствующие события (что перечеркивает идею событий как таковую), request (реализация IoC?), не привносящие ничего по сравнению с вызовом метода конкретного объекта и пр.

Технология CORE

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

Технология CORE

Разные подходы — хорошо, но и плодить термины не за чем.

Технология CORE

Поздравляю! Вы описали паттерн MVVM. Две модели — Balance и WinHandler — подписываются на события модели вида UI, и с помощью IoC дергают ее методы. Модель вида, в свою очередь, использует вид (jQuery) для отображения данных пользователю и получения от него обратной связи. Рекомендую посмотреть на AngularJS.

Применение процедурных генераторов в создании контента для real-time 3D приложений: Часть 2. Valley Benchmark

> DOF правда какой-то неестественный
Потому что, похоже, делается с помощью gaussian blur, а реальное боке работает иначе: каждая точка превращаются в круг, шестиугольник или другую форму отверстия диафрагмы, размер которой зависит от удаленности объекта от точки РИП, и аддитивно накладывается на изображение.

Liberator: первый в мире огнестрельный пистолет, полностью отпечатанный на 3D принтере

К вопросу о сложности изготовления оружия без 3D-принтера:
www.youtube.com/watch?v=55oxS4CZtPk

Хотите заблокировать распространённые пароли? Извините, это запатентовано

Было распространено ограничение «минимум 6 символов», ну и набирать на нумпаде удобно.

Javascript умирает или перерождается?

Если в случае «произвольный язык — язык виртуальной машины — машинный код» два уровня виртуализации, то в яве и дотнете тоже тогда два, и я не понимаю, как это изменится в случае появления некоего байт-кода, и как это повлияет на увеличение производительности. Сейчас javascript вполне можно считать языком виртуальной машины (в V8, например, он сразу компилируется в машинный код при первом запуске, минуя байт-код).

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

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

Javascript умирает или перерождается?

А чем Javascript не подходит в качестве своеобразного байт-кода? Пишите компилятор любимого языка в JS — и вперед. Собственно, так и делают — что Coffeescript, что Dart, что Typescript.

Pilot: многофункциональный JavaScript роутер

Думаю, поведение навигации в браузере не должно отличаться для «обычных» приложений и одностраничных — просто из соображений удобства для пользователя, т. к. в таком случае не надо думать, а как себя поведет навигация сейчас. По умолчанию, браузер при переходе по ссылке меняет урл сразу, не дожидаясь загрузки данных, соответственно, поведение роутера (по крайней мере, по умолчанию) должно быть таким же.

У вас много денег? Перестаньте быть снобами

См. ответ выше. Тестовое задание скорее всего не покажет нужного.

У вас много денег? Перестаньте быть снобами

Тут суть — посмотреть работающий код, который был наверняка написан под определенные требования и в ограниченные сроки. На stackoverflow условия немного отличаются от типично рабочих.

Освободи разум от Фотошопа — свежая концепция обработки изображений

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

Освободи разум от Фотошопа — свежая концепция обработки изображений

Видимо, не правильно понял тогда. Я думал, что предлагается отдельно руками в интерфейсе создавать «точку состояния», и потому предлагал создавать эти точки автоматически.

Освободи разум от Фотошопа — свежая концепция обработки изображений

Мне кажется, никто не мешает и снапшоты хранить для растровых слоев. Поправили — снапшот. Еще мазнули — еще снапшот.

У вас много денег? Перестаньте быть снобами

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

Освободи разум от Фотошопа — свежая концепция обработки изображений

А не ваши ли обои «Proud» (вроде так назывались) и остальная серия? Очень крутые!

Освободи разум от Фотошопа — свежая концепция обработки изображений

Ну, их там все таки очень серьезно надо будет углублять и расширять, чтоб до такого состояния довести (как логику, так и интерфейс).