Слишком формализировано

Popover? Cерьезно?

Хотите сказать, что AngularJS — отбирает у пользователя возможность нажать на кнопку F5? =)

Правильным ходом было бы обработать оба случая.

Не понравилось, что Вы используете свой интерфейс. В Backbone метод инициалиции називается «initialize» a метод удаления — «remove». Предерживайтесь единых стандартов, тогда Ваша библиотека будет более удобна, так как использует общепринятое соглашение.

AAA не противоречит «1 expect», поэтому просто не может быть лучше или хуже:
1. Arrange — для этого и существуют методы before/after/around each и их аналоги (setup, teardown, etc.).
2. Act — не принципиально где вызывать, в setUp-e или в самом тесте, зависит от ситуации.
3. Assert — ожидаемый результат, пишется только в it.

К-во expect-ов — это же часть SOLID. Один тест тестирует, что-то одно. При этом же документация, которая потом создается на базе тестов получается на порядок качественней и детальней.

А я считаю контроллер плохим, если в нем экшен больше 20-30 строк кода. Скажу даже больше, я считаю любой метод плохим, который называется плохо или если метод принимает больше 3 аргументов, или если у метода есть статические зависимости и таких «если» целая куча.

Все конечно же относительно, но есть так называемые «Best Practices», которые помогают делать код лучше. Следовать им или нет — это уже другой вопрос.

Да, именно. Ведь когда Вам дают, например, интернет-магазин на разработку, то Вы начинаете дробить все на модули, модели, контроллеры, вьюхи, фичи и прочее. Это ведь упрощает общее понимание картины, не так ли? Почему бы не делать то же самое в тестах?

есть же jquery.widgetFactory, dojo.widgetFactory + любой шаблонизатор и все будет работать на ура. Замысел в чем? В легковесном коде?

>> Вы хотите сказать, что лучше управляет автомобилем тот, кто знает внутреннюю механику?

Именно.

>> Отчего же тогда мастера сидят на пит-стопах, а не ездят на болидах?

Смотря какие мастера. Как на счет мастеров/архитекторов, которые работают в командах формулы 1, аналогичные ребята есть в тех же Honda и других компаниях. Думаю они «сидят» так нормально и ездят на чем-то нормальном.

Вы правы на счет этого под-под-подпункта, но именно он отличает ХОРОШЕГО менеджера или топ-менеджера от обычного рядового.

>> Ваша фраза равносильна фразе «управление автомобилем — это психология и анализ пассажиров и других водителей».

Не совсем верная перефразировка. Психология — это механика в автомобиле. Учится ездить, более менее адекватно, Вы сможете за 2-3 месяца + права получите. А вот если Вы в глуши и у Вас поломалось что-то внутри, без знаний механики никуда, хоть крути хоть не крути рулем.

Без этого под-под-подпункта Вы не сможете быть ХОРОШИМ менеджером :)

Вообще как-то ни о чем получилось. А слово «Много» в заголовке оказалось 8 :)
Я не менеджер сам, но даже мне понятно, что основная задача — это не отчеты и даже не анализ рисков, а психология и анализ людей.

Хороший менеджер — это тот, который по виду человека может определить, «куда надо двигаться», чтобы заинтересовать человека, будь-то клиент, член команды или кто-то другой.

Единственный дельный совет в менеджменте — это учить психологию. Чем лучше ты понимаешь людей, тем лучше ты можешь ими управлять (т.е. как помогать достигать им своих целей, так и достигать своих собственных). Все остальное (документация, риски, бюджеты и прочее) можно выучить достаточно быстро.

Как-то на статью вообще ни разу не тянет: ни объяснений по коду, ни описанного принципа. Таких примеров на Knockoutjs.com целая куча

Начало статьи реально порадовало ALTER IGNORE TABLE table1 ADD UNIQUE..., но в продолжении описаны методы, которые реально ломают использование индексов — огорчили.
На счет последнего примера я бы написал так:

SELECT ua.uid, ua.amount
FROM (
   SELECT p.uid, p.amount
   FROM payments p
   ORDER BY pay_date DESC
) ua
GROUP BY ua.uid

Не спорю, но одна из задач тимлида — делегировать обязанности. Тимлид должен научится делать работу при помощи 100500 рук, а не 2. Собственно, если он этого не делает, чем же он тогда отличается от программиста того же уровня?

Если тимлид делает работу за свою команду значит он не тимлид.

Неважно что. Главное чтобы оно работало лучше с Вашей точки зрения.

К сожалению не знаю что такое декларативный DSL, но кто-то же его выполняет, переводит в другую структуру за Вас (предположу что этот уровень абстракции выше нежели ООП).
Вы правы — есть другие способы. То же процедурное программирование хорошо подходит для написания небольших утилит.

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

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