Александр Кит

Знаю что уже решили вопрос, но навскидку ещё вариант для разнообразия:

console.log(calcSum('.class1'));

function calcSum(selector) {
	return $(selector)
		.toArray()
		.reduce(function(sum, el){ 
			return sum + (el.textContent | 0) 
		}, 0)
		;
}

:) Фасад - это чисто инкапсуляция! Фасадом мы скрываем или изменяем апи к классу/классам/библиотеке и т.д. В фасаде не зазорно перед доступом к ниже лежащим слоям проверять данные и права доступа, аля Баррикада, создавать нужные обьекты, определять конфигурацию и прочее. А Мадиатор нужен для связи множества классов/обьектов, хотя задачи могут быть даже схожими. Грубо говоря (может легче представить будет): фасад как обёртка над "чем-то целым", а медиатор как прослойка между множеством "чем-то целым".

После рефакторинга

window.onload = init;

// === private
function init() {
    var audio = $('#myplayer').get(0);
    audio.src = 'http://radio.at.aknet.kg:8008/radio_record.aac';

    $('#playpause').click(function() {
        if (audio.paused) {
            this.textContent = 'Остановить';
            audio.play();
            return;
        }

        this.textContent = 'Воспроизвести';
        audio.pause();
    });

    $('#volume').change(function() {
        audio.volume = this.value / 100;
    });

    setInterval(updateTrack, 5000);
}
function updateTrack() {
    var url = 'http://www.radiorecord.ru/xml/record_online_v3.txt';

    $.getJSON(url, function(json) {
        var key = json.ARTIST + ' - ' + json.NAME;

        $('#track').text('Сейчас играет: ' + key);
        $('#sg').attr('href', 'https://www.google.ru/search?q=' + key);
        $('#sn').attr('href', 'http://namba.kg/#!/search/mp3/' + key)
    });
}

Не хочу вас переубеждать, но `контекст` и `карринг` - вещи не совместимые, и не из-за невозможности, а в силу идеологии. Первое это обьекты, свойства и методы. А второе это функции и аргументы.
Если хотите смешать, то как написали - через создание делегата. в ес6 немного проще:

function delegate(fn, ...base) {
	return function(...args){
		return fn.call(this, ...base, ...args);
	}
}

var Actions = [first, second, third /* .. */ ],
    index = random(0, Actions.length - 1)
    ;
Actions[index]();

function random(min, max) {
    return Math.floor(Math.random() * (max - min + 1)) + min;
}

Рисуете на канвасе исходную картинку, а поверх нее рисуете текст и другие артефакты. Потом весь канвас сохраняете в Битмап, а далее через компрессор и в файл, или куда-то ещё. В чем загвостка?

"как можно по другому", ну кто такое спрашивает, это же javascript - здесь есть миллионы разных способов. Лучше бы спрашивали "как надо". Вот так точно не надо:

function sum() { return eval([].join.call(arguments, '+')).toString() }

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

- Модули, Слои - делите приложения на слои.

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

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

Рекомендую почитать "50 Tips and Tricks for MongoDB". Текста не много, а информации полно. Здесь в ответах немного напутали - то, что у вас под 1ым пунктом - это денормализованная коллекция. Плюсы в том, что за один запрос имеете всю информацию по обьекту, ну а минусы соответственно, что сложно применять правки. А 2ой пункт, это уже нормализованная - и тут всё наоборот. Но главное, это грамотно балансировать между ними, а не выбирать одну из сторон. Структура очень зависит не только от структуры данных, но и того - как мы используем эти данные (какие выборки делать будем) и на сколько важна их актуальность. Пару советов из разных сторон:
- если идете по первому пути - то можете хранить также все подсущности в отдельных коллекциях. Изменяя подсущность, изменяете её в своей коллекции, и не бойтесь писать скрипты для нормализации, которые по крону будут актуализировать основную коллекцию.
- а если по второму, то храните не только `_id` подсущностей, но также часть обьекта, которая всегда будет нужна, что бы минимизировать запросы.

Если вас правильно понял, вот ~ код:

var slice = Array.prototype.slice,
    filter = Array.prototype.filter
    ;

function findSelector(cssProperty){
    var rules = [];
    
    filter
        .call(document.styleSheets, hasRules)
        .forEach(function(styleSheet){
            
            rules = rules.concat(slice
                .call(styleSheet.rules)
                .filter(hasCssNameDelegate(cssProperty))
            );
        })
    
    return rules.map(function(rule){
        return {
            selector: rule.selectorText,
            value: rule.style[cssProperty]
        };
    });
    
    function hasRules(styleSheets){
        return styleSheets.rules != null
    }
    
    function hasCssNameDelegate(name) {
        return function(cssRule){
            return cssRule.style && slice.call(cssRule.style).indexOf(name) !== -1
        };
    }
}

function findSelectorForElement(element, cssProperty){
    var matchesSelector = HTMLElement.prototype.webkitMatchesSelector
        || HTMLElement.prototype.mozMatchesSelector
        || HTMLElement.prototype.msMatchesSelector
        || HTMLElement.prototype.oMatchesSelector
        ;
        
    return findSelector(cssProperty)
        .filter(function(data){
            return matchesSelector.call(element, data.selector);
        
        }).slice(-1)[0];
}

var tosterSidebar = document.querySelector('.sidebar')
findSelectorForElement(tosterSidebar, 'width');