Classic Season 1

В этой серии мы поговорим о статистике по репозиториям Git, построим RSpec с нуля, будем делать быстрые тесты с и без рельсов (Rails), обсудим навигацию по файлам в Vim и разберем еще много интересного.

Обзор серии:

• 1. Статистика по репозиториям Git. Мы будем использовать оболочку и инструменты командной строки git, вычисляя статистику для каждой ревизии.
  
• 2. Как и зачем избегать нуля. Мы посмотрим на ноль со многих сторон. Почему в ваших программах появляются нули? Какие проблемы они могут вызвать, когда они выходят из-под контроля?
• 3. Строим RSpec с Нуля. RSpec заманил многих программистов в мир Ruby с его красивым синтаксисом. Для некоторых его работа остается загадкой. Давайте развеяем это. Мы построим базовый синтаксис RSpec с нуля, проверим его, используя Test :: Unit. Конечно, это сделано в Ruby. Основные знания Ruby определенно помогут.
• 4. Source Code History Integrity. История исходного кода - это хорошая тема. Должны ли мы когда-либо редактировать историю? Это безопасно? Мы посмотрим, что может измениться при редактировании истории и как избежать потенциальных проблем. Мы также кратко поговорим о сообществах Mercurial и Git.
• 5. Extracting Domain Objects. В современных веб-фреймворках легко наследовать модель и объекты контроллера, что может вас оставить потом с очень огромными обьектами. Чтобы этого избежать, вы можете извлекать мелкие кусочки в свои классы. У этого есть много преимуществ, таких как: намного более быстрое выполнение теста, концепции именования в системе, которые ранее были неявными, и добавление явных уровней абстракции. Мы рассмотрим пример из самого Destroy All Software, приложение Rails и потянем кусочек логики модели, встроенный в контроллер, в свой класс с изолированными тестами.
• 6. Conflicting Principles. Существует множество объектно-ориентированных принципов проектирования. Заманчиво рассматривать их как абсолютные правила, но нам также нужно понимать компромиссы между ними.
• 7. Growing a Test Suite. При создании системы легко добавлять тесты в свой пакет без учета взаимосвязи между ними. Создав свой тестовый пакет более преднамеренно, вы можете писать более четкие тесты, а также повышать проектное давление на вашу систему. Мы создадим небольшой фрагмент кода в обоих направлениях: сначала просто добавляя тесты, затем расширяя существующие тесты и думая о последствиях.
• 8. Processes and Jobs. Процессы и рабочие процессы, выполняемые в вашей оболочке, являются ядром рабочего процесса разработки Unix. В первой половине этого скринкаста мы рассмотрим механизмы управления работой оболочки, как работает GNU Screen и как я использую их вместе для моего рабочего процесса разработки. Затем мы рассмотрим расширенное использование управления процессами, которое позволяет использовать мощную композицию инструментов Unix.
• 9. Exceptions and Control Flow. Мантра «не используй исключения для контроля» часто повторяется, но ее реальные последствия, как правило, не такие серьезные. Используя пример, я покажу вам, что я думаю об этом, и почему я в порядке с использованием исключений в некоторых случаях.
• 10. Fast Tests With and Without Rails. Rails startup может запускать тесты и особенно делать TDD болезненным. Вы можете избежать этого для большинства тестов, переместив код в каталог lib и проверив его вне Rails. Мы рассмотрим производительность тестов с Rails и без них. Сценарий, упомянутый в конце этого скринкаста, доступен для скачивания.
• 11. Git Workflow. Многие люди спрашивали о моем рабочем процессе git, так что вот он. 
• 12. Packaging in Ruby and Python. За последние несколько лет произошел взрыв в упаковочных инструментах. Создание и установка уже не являются жесткими: теперь мы управляем несколькими версиями во время выполнения, изолируем комплекты пакетов для разных приложений и задаем зависимости повторяемым образом. Этот скринкаст смотрит на ландшафты в Ruby и Python, сравнивая их решения с этими проблемами. 
• 13. File Navigation in Vim. Возможности навигации в Vim слабые, поэтому настройка может значительно ускорить работу. Мы рассмотрим поиск и открытие файлов, включая Rails-специфические хаки, которые помогут вам избежать проблемы поиска одного файла среди многих с похожими именами. Затем мы рассмотрим настройки, которые я использую, чтобы обеспечить эффективное управление окнами с помощью рабочего процесса TDD.
• 14. Extracting Objects in Django. Это сиквел Extracting Domain Objects. Еще раз, мы рассмотрим логику каталога Destroy All Software, вытащив ее из Django View (эквивалентно контроллеру Rails) и переместив ее в свой собственный класс, соответствующий домену. Затем мы изолируем и упростим тесты как для представления, так и для нового класса Catalog. Наконец, мы будем использовать новые изолированные тесты, чтобы расширить поведение Каталога, не изменяя или не нарушая представление и его тесты.
• 15. Quick and Easy Perf Tests.  В этом скринкасте мы рассмотрим простой метод для постоянного анализа производительности: запуск небольших тестов по всем элементам контроля версий. С помощью нескольких строк сценариев оболочки и RSpec мы сможем получить визуальное представление о производительности нашей системы с течением времени, что позволит нам уловить проблемы с производительностью до их производства. Скрипт run-command-on-git-revisions, используемый здесь, доступен в GitHub.
• 16. A Refactoring Story. Размышляя о скринкасте на этой неделе, мне удалось сделать довольно большой рефакторинг на одном из контроллеров Destroy All Software. Я перевел путаницу беспорядка, спасая более разумное действие, подталкивая валидацию и специальные случаи к классам более низкого уровня. Мы рассмотрим предыдущую картину, изменения, которые я сделал, а затем изображение после. Есть изменения имен, структурные изменения и некоторые важные поведения Rails, которые были немного удивительными. Это отход от обычного стиля Destroy All Software, поэтому, пожалуйста, сообщите нам, что вы думаете!
• 17. Wrapping Third Party APIs. Сторонние API могут быть источником плохого дизайна в ваших приложениях. Когда вы смешиваете логику своего приложения с вызовами в API, вы скрываете обе обязанности. В этом скринкасте мы рассмотрим класс, где я это сделал. Затем мы извлечем доступ API в оболочку, упростив исходный класс и добавив ясность как для производственного кода, так и для тестов.
• 18. Clarity via Isolated Tests. Несколько Destroy All Software screencasts коснулись изолированного тестирования, но никогда не обращались к нему напрямую. Тема этого скринкаста: почему мы заботимся о том, чтобы изолировать тестируемый класс от других классов? Мы рассмотрим фактический пример, на котором я столкнулся: я начал TDD класс, позволяя ему интегрироваться с некоторыми другими простыми классами. Поняв, что тест стал беспорядочным, я удалил его, переписал его изолированным способом, и он был гораздо читабельнее. Мы вернемся к этим шагам, чтобы увидеть разницу в изолированном тестировании.