Алексей Уколов

Даны 2 слова, определить можно ли из 1 слова составить 2, при условии что каждую букву из строки 1 можно использовать только один раз?

Если это читается как "определить можно ли из первого слова составить второе", то алгоритм прост:

1. Собрать все буквы первого слова в массив.
   
2. Собрать все буквы второго слова в массив.
   
3. Найти разницу первого массива со вторым - если ничего не вернулось, значит второе слово можно составить из первого.
   

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

Обработчики событий устанавливаются только на те элементы, которые были на странице в тот момент. В момент инициализации обработчиков на странице нет элемента с классом "class2" (он появится в неопределенном будущем, после клика по ".class1") - обработчик не установился.
Для того, чтобы обрабатывать события на динамически добавляемых элементах, необходимо делегировать эту обработку какому-то неизменяемому родителю:

$(document).on('click', '.class1', function() {
	alert("click .class1");		
    $(this).removeClass("class1").addClass("class2");
});

$(document).on('click', '.class2', function() {
	alert("click .class2");		
    $(this).removeClass("class2").addClass("class1");
});

А вообще, ваш код можно упростить:

$(document).on('click', '.class1, .class2', function() {
    $(this).toggleClass("class1").toggleClass("class2");
});

Как на css скрыть под многоточие длинный текст, учитывая высоту блока в котором текст расположен?

Это два отдельных инструмента, которые выполняют одну задачу?

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

Или это два инструмента, которые всегда должны работать вместе?

Эти инструменты можно использовать вместе, но это не обязательно. Нужно ли это делать, зависит от дизайна.

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

По большому счету, у вас два варианта:

1. Использовать mailto-ссылки с get-параметрами, чтобы при отправке формы открывался почтовый клиент пользователя.
   
2. Использовать API стороннего сервиса, который предоставляет возможность отправлять письма.
   

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

Подробнее: про mailto, про API.

Раз у вас бутстрап, значит, вероятно, и jQuery подключена, тогда можно сделать просто:
$('.multiplier:visible').text()

На ванильном js получается многословнее, но итог такой же:

var options = document.querySelectorAll('.multiplier'),
    multiplier;

[].forEach.call(options, function (option) {
    if (option.style.display == 'block')
    {
        multiplier = option.innerText;
    }
});

alert(multiplier);

P.S. Для получения числа из текста можно использовать parseFloat(), если есть такая необходимость.

Я бы сказал, что это вообще антипаттерн - зачем Foo знать о каких-то аргументах и функциях, если всё, что она делает - это выводит сообщение в консоль.
Правильно было бы сделать так:

function log (message){
  console.log(message);
}
function sum (arg1, arg2){
  return arg1+arg2;
}
function mult (arg1, arg2){
  return arg1*arg2;
}

log(sum(2, 3));
log(mult(2, 3));

Попробуйте привести более реальный пример, где такое поведение может понадобиться.

Это модель. В реальном примере функция Foo могла бы быть единственно экспортируемой из модуля. И конечно в ней была бы не одна инструкция, плюс вызовы других функций и тд. Пользователь модуля мог-бы менять его внутреннюю реализацию отправляя на вход свою функцию (sum, mult или что-то совершенно иное). Если учитывать что функции в JS тоже являются объектами, то получается что мы меняем реализацию методов объекта не имея доступа к его коду. Это полиморфизм?

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

Вроде, всё довольно ясно написано:
1. Неограниченное количество пользователей может использовать Community-edition для проведения обучения, open-source разработки или научных исследований (и только для этого, "доля научных исследований" сюда не попадает, если она не равна 100%).
2. Если у вас не больше 250 компьютеров и меньше миллиона долларов оборота в год, вы можете использовать Community-edition для любых целей для 5 пользователей.
3. Если вы большой энтерпрайз - будьте любезны купить лицензии.

Из вашего вопроса непонятно, что именно вы пытаетесь сделать.
Возможно, что-то вроде этого?

$('select#f-select').append('<option value="1">Пункт</option>');

listActions =
  cartUpKey: (it) ->
    alert('UP')
  cartDownKey: (it) ->
    alert('DOWN')

На будущее - js2.coffee

[filtersCheck]

var arr = [];
arr.push(filtersCheck)