Анализ дня: делай сразу, GO и Artifactory

    Весна как известно время перемен. Вот и я сегодня в честь первого дня весны решил попробовать новую для себя штуку.
    Замечаю за собой нежелание подводить итоги недели, просто анализировать прошедший день. Поэтому решил поставить эксперимент. Каждый вечер буду писать о тех новых вещах, которые узнал за день. Ну а, если ничего не узнал, значит так и пишем, а потом ставим в уме минус, пожирнее.
    Вчера слушал интервью Радислава Гандапаса и он сказал, что одной из его сильных сторон является привычка делать все сразу. Не разводить сомнения, не продумывать мега хитрые планы,  а просто действовать ибо "опыт дороже знаний". Попробовал сегодня проследить за собой. Остался недоволен. Даже на протяжении одного дня было много моментов, когда тупил, ленился, и придумывал чтобы такое сотворить, чтобы ничего не делать.
    Уже в конце дня решил прочитать-просмотреть статью о Continuous Delivery, которая висела у меня в браузере несколько дней. Глаза выхватили две тулзы, требующие более пристального внимания. Это GO - сервер для continuous integration от ThoughtWorks Studios и Artifactory от JFrog. По идее Artifactory позволяет сохранять все артефакты билд системы и потом предоставлять к ним доступ всем желающим. Поскольку я сам сейчас активно занимаюсь настройкой continuous delivery то тулзы эти нужно будет рассмотреть более пристально. Кстати сама статья вот: http://java.dzone.com/articles/continuous-delivery-using Тоже рекомендую ознакомится.
    На сегодня все.
    Всем доброй ночи.

Учимся читать заново

Давно понял что чтение, которому нас учили в школе и университете - это только первый шаг. С свое время увлекался скорочтением, но это не мое. 

Сейчас в Google Reade накопилось 1300 непрочитанных статей, которые хотелось бы не просто забыть, а обработать с максимальной пользой для себя. И это послужило стимулом к тому чтобы еще раз задуматься о формировании своего подхода по перевариванию этого водопада из входящей информации.

Потому недавно перечитал еще раз книгу П. Шелли "Фоточтение". Достаточно неплохая книга, хотя сам с достаточно большим скепсисом отношусь к идее читать книгу со скоростью страница за секунду.

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

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

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

Особенно полезными оказались советы по работе сразу с группой книг, когда нужно на вчера перечитать и изучить 10 книг или же насобирать материал из этих же 10 книг.

Всем доброй ночи.

Система юнит тестов - логический компилятор вашего приложения

"A unit test is almost always written using a unit-testing framework" Roy Osherove, The Art of Unit Testing.

Всем привет.

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

Тему эту я решил поднять поскольку был на тренинге "TDD в .NET". Тренинг прошел круто, полезно и об этом можно почитать уже в нескольких отчетах. Просто спросите гугл: TDD в .NET на XPDays и он вам все расскажет.

Но что я вынес для себя и почему выбрал именно такой заголовок статьи, а не другой?
За свои скромные несколько лет работы я вынес одну банальную вещь - программисты народ ленивый, менеджерам всегда не хватает времени, поэтому хватит экспериментов, делайте как работает и не ерзайте. Соответственно, если вы хотите ввести какую-то полезную практику у себя на проекте, то в первую очередь позабодтесь об удобных инструментах для работы. Будь-то ревью кода, continuos integration, continous delivery.

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

Инструменты следующие, очень советую посмотреть всем кто пишет на C#:

• xUnit (NUnit) - фреймворки для юнит тестов
• NSubstitude - фреймворм для создания моков(заглушек, пустышек для тестов)
• Test Driven.NET - плагин, который позволяет запускать тесты под разными тулзами, и под дебагом в том числе
• NCrunch - плагин, который в фоне запускает тесты и выдает вам красивый результат в картинках, визуально показывает покрыт ли ваш код тестами

Конечно следующим шагом стоит поднять все темы касательно написания сложных тестов, сложностей их реального применения и самое главное поддержки актуальности ваших тестов. Я этого делать не буду поскольку не имею такого опыта и могу только повторять чужие слова. Но сейчас мой проект использует .NET технологии, я обязательно попробую TDD и мы сможем похоливорить на эти темы в следующих постах.

Также отдельно постараюсь написать о тестах и инструментах в С++. Все-таки это мой родной язык и жаль, что ситуация там немного хуже. Очень буду рад пообщаться на тему реального, практического использования TDD и юнит тестов в С++. Какие инструменты вы применяли и как настроили воркфлоу?

Всем доброй ночи.