Oxoron

Делегаты - это форма существования функтора на платформе .NET. Почитайте про функтор, и поймете (наверное), зачем нужен делегат.

Если коротко и грубо - вызвать напрямую можно всегда только конкретный метод, который будет четко известен еще на стадии компиляции. Если же вы пишете некий обобщенный алгоритм и заранее не знаете, какие КОНКРЕТНО методы у каких КОНКРЕТНО объектов будете вызывать - вам необходимо будет воспользоваться делегатом.
Простейший пример - LINQ-методы. Метод фильтрации Where получает своим параметром функтор, который возвращает true или false, что значит - оставить элемент в коллекции или выкинуть его. В этом методе в цикле foreach вызывается переданный делегат для каждого элемента. Where понятия не имеет, какой конкретно метод (или лямбда-выражение) вы захотите подставить в качестве фильтрующего предиката.

Другой пример - события. События в дотнете - это делегаты с урезанным публичным интерфейсом. Так как, к примеру, кнопка не знает о том, кто захочет подписаться на событие ее нажатия, она никак не может вызвать конкретные методы у конкретных объектов. Чтобы иметь возможность сообщать о своем нажатии, кнопка выставляет событие Click наружу, давая возможность записать туда конкретные методы для вызова.

Кстати, делегат выполняет еще и функцию связывания: для нестатических методов делегат хранит еще и объект, для которого будет вызван instance-метод (т.е. связывает пару объект-метод).

Таким образом,
> Почему методы нельзя передавать в функции без делегатов?
Делегаты - это и есть передача методов в функции.

create table numbers (
    number int not null
        check(number >= 1234 and number <= 4523),
    ...
)

create table numbers (
    number int not null,
    check(number >= 1234 and number <= 4523),
    ...
)

create table numbers (
    number int not null,
    constraint number_range_check
        check(number >= 1234 and number <= 4523),
    ...
)

stackoverflow.com/questions/1736630/sql-constraint...

нужно писать TDD тесты.

Нет, нет такой вещи как "TDD тесты". TDD это одна из методик экстремального программирования (XP). Вам уже привели ссылку на книгу Кента Бэка на эту тему (к слову крайне рекомендую)

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

- Красный - перед тем как написать код, мы должны написать тест который ломается (обычно в консоли сломанные тесты подсвечиваются красным). Согласно этой методологии писать код вы должны строго тогда, когда у вас есть сломанные тесты. Если сломанных тестов нет, то и код писать не нужно.
- Зеленый - когда вы получили красные тесты, вы должны максимально быстро дописать код так. что бы тесты были зелеными. Скажем если вы написали тест который ожидает от функции, что она вернет строку "foo" то в коде у вас должно быть не больше чем сама функция и вывод строки "foo". Как только мы этого добились мы либо рефакторим, либо добавляем еще красных тестов что бы потом дописать код. Конечно настолько примитивные вещи делать по такому циклу избыточно, и у Кента Бэка описывается понятие "длины шага", то есть сколько работы мы можем делать на каждом этапе. Вы всегда должны подключать здравый смысл словом.
- Рефакторинг - на предыдущих фазах мы не загонялись о том насколько наш код красив, насколько мы соблюдали принципы DRY и т.д. так что это фаза отчистки кода. Мы можем делать ее на каждой итерации, а можем раз в пару часов, но важно делать это как можно чаще. На этом этапе мы устраняем дублирование как в коде приложения так и в тестах. Важно отметить что хорошей мыслью будет не рефакторить одновременно и код и тесты, ибо у нас должен быть источник правды. Если мы почистили тесты и при этом они начали фэйлиться, то значит мы что-то сломали пока числити. И наоборот. А если менять и то и то между запусками тестов то не понятно кто виноват.

Обычно TDD практикуют используя unit-тесты (что логично, ибо они выполняются достаточно быстро что бы выполнение тестов не заставляло нас заваривать чай), что подразумевает собой то, что мы тестируем один юнит (один класс или объект), а все его зависимости должны подменяться на моки (фэйковые объекты, которые нужны что бы проверить как наш объект взаимодействует с другими, об этом тоже много написано). Но никто не запрещает использовать интеграционные/функциональные тесты и при этом практиковать TDD (так например делают чуваки практикующие BDD), а Кент Бэк это дело называет ATDD.

Собственно TDD дает нам следующие преимущества:
- вы не тратите время на проектирование системы в микроскопических масштабах, это эволюционный подход, архитектура приложения постоянно меняется и эволюционирует вместе с требованиями. Все требования формализуются в виде тестов.
- код всегда покрыт тестами (пусть и не на 100%, обычно хватает и 20% что бы можно было жить, все зависит от сроков жизни проекта и требуемого уровня надежности)
- если вам становится трудно писать тесты (например много зависимостей, сложно мокать) - то это должно навести вас на мысль о не правильной архитектуре и инициировать более глубокий рефакторинг. А при наличии тестов это не так уж и страшно.
- необходимость покрывать тесты увеличивает потребность в соблюдении всяких принципов типа SOLID и т.д. так как иначе мы начинаем писать тесты очень не эффективно и опять же возвращаемся к тому что с архитектурой что-то не так.

updated

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

Минусы TDD проистекают из плюсов. Это эволюционный подход, который хорошо работает когда мы вносим изменения в систему маленькими порциями и всегда рефакторим наш код, что бы он большую часть времени был красивым и удобным к расширению. Если же вам в руки дали легаси проект и сказали отрефакторить, то TDD тут не подходит или подходит плохо. Но опять же такая задача ставится довольно редко, чаще - добавление функционала. И в этом случае мы возвращаемся к внесению изменений маленькими порциями и эволюционному подходу. Просто на это уйдет довольно много времени, но если сравнивать с "рефакторинг + добавление функционала + регрессионное тестирование" то в зависимости от ситуации TDD может дать как профит так и нет. Все зависит от сложности системы. На простых системах в этом нет смысла.

По поводу области применения... Тут есть несколько точек зрения. Как минимум TDD решает вопрос проектирования архитектуры, а не разработки алгоритмов. Этого мы достигаем тестами. Но опять же через юнит тестирование довольно не удобно разрабатывать определенные типы проектов: комиляторы, трансляторы, различные решения основанные на сложных алгоритмах (например алгоритмы сжатия, шифрования и т.д.), штуки завязанные на сетевом взаимодействии, например клиенты для протоколов. Для этих вещей больше подходят функциональные тесты или же их вовсе сложно покрыть тестами.

Telerik ASP.NET Scheduler ? ну или гуглите аналоги

Это обычный INI файл, гуглите что в вашем языке есть для работы с ним.

ORM-ку сверху накиньте, вместо прямого ADO.Net, и будет вам современные технологии. В тренде, очевидно, Entity Framework, хотя NHibernate - нестареющая классика.
Можете заморочиться над архитектурой, вплоть до разделения на клиент и сервер - тогда будет место и для Web API.
Или другой вариант - подтащить документую БД, хотя для бухгалтерии не факт что это хорошее решение (разве что в пару к реляционной, для хранения характеристик ваших товаров).

Крупные ежегодные (некоторые еще не анонсированы на следующий раз):
www.highload.ru
ritfest.ru
whalerider.ru
https://devconf.ru/ru
2015.russianinternetforum.ru
www.spmconf.ru/ru/index
msk16.agiledays.ru
www.msdevcon.ru

Списки:
runet-id.com/events/2015/9 - не все, в основном мелкие но бывает интересные
https://events.yandex.ru/ - проводит яндекс, но иногда бывает интересно и остальным
rusbase.com/calendar

PS disclaimer: именно по дизайну я затрудняюсь назвать конференции, несколько далек от этой области. Но потоки по UX бывают регулярно.

1. Параллельные потоки загрузки и обработки данных
2. Управление уровнем ошибок для продолжения или прерывания обработки ресурса.
3. Обработка и сегментация данных из ошибочных и неверных структурированных данных (например, HTML/XML).
4. "Решето" (правила) для предотвращения дальнейшей обработки ресурса на основе уже полученных данных (условия алгоритма прописываются в конфиге).
Например, контент размером более 5 кб со словом "toster" или url содержит "toster.ru" - пропустить и перейти к обработке следующего.