Запустить тесты и собрать проект — одной командой

Если не запускать тесты регулярно — они бесполезны. Частота запусков тестов обратно пропорциональна сложности этой процедуры — чем больше кнопочек надо нажать, тем реже будут запускаться тесты. А если для этого еще надо поднимать IDE…

Сегодня немного обновил свой пример на GitHub, добавил небольшой shell-скрипт build.cmd который:

  1. Компилирует набор тестов
  2. Запускает тесты в консольном окружении
  3. Если все ОК — собирает главный проект

(Обратите внимание, что для того, что бы в пункте 3 проверить, успешно ли выполнились тесты, надо немного подправить dpr файл. Я не знаю почему Embarcadero не сделала rxbHaltOnFailures параметром по умолчанию).

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

В любом случае, потратить немного времени на build/test скрипт — очень выгодная инвестиция.

Delphi TDD: Результаты

Прошло 2 месяца с начала моего экспериментального курса по TDD в Delphi. Он состоял с 2-х частей:

  1. Введение в DUnit и базовые принципы TDD
  2. Написание кода, который легко тестировать

Мне кажется, первая часть получилась намного интересней. Она была намного проще и не требовала много времени, фокусировалась на основном наборе навыков. Вторая часть более серьезная, особенно трудно было «заставить» участников писать код по-другому, не так как они привыкли. Вот одна из цитат из переписки:

Это у меня привычка такая, думать наперёд… тесты я выполнял последовательно.. и в конце уже начал понимать, что действительно, в тестах есть такой плюс. Ведь думая, а как оно будет в будущем: а) отвлекаешься б) чем больше объём, тем тяжелее это удержать в голове. Тесты рулят.

Участники использовали Git и приватные репозитории на BitBucket для отправки кода, там же я давал им задания (через Issues) и мы обсуждали код (через комментарии к коммитам). В целом это был очень богатый и позитивный опыт.

На курс подписалось 14 человек, все задания выполнили только 5. Сейчас в свободное время я работаю над DUnit Exercises. Это будет автоматизированая первая часть курса. Подписаться можно здесь.

Никогда не находили времени попробовать TDD?

Вот она — возможность попробовать Test Driven Development в Delphi. Для этого не надо много времени.

Алгоритм очень простой — вы подписываетесь на рассылку, я отправляю вам 2-3 письма в неделю с небольшими заданиями. Так как TDD — это практика, теории много не будет. А точнее ее вообще не будет. Выполняя задания вы будете отправлять код в облако, где я смогу его смотреть и комментировать. Если вы не выполняете задания, я убираю ваш email из рассылки и продолжаю работать с теми, кому интересно.

Требования: желание прокачать свой programming level, 60-90 мин. времени в неделю, Delphi 2010+

Знать путь и пройти его — не одно и тоже.

Подписаться К сожалению, подписка временно закрыта. Т.к. курс практический, я буду активно работать с подписавшимися. Если все пройдет как я задумал (или лучше) — можно будет повторить. Stay tuned!

TTrackLabel

Все началось с проекта по захвату и обработке изображения с камеры. Специфика предметной области требовала задания кучи разных параметров, в итоге окно настроек разрослось множеством табов с десятками TTrackBar’ов, TEdit’ов, TUpDown’ов и т.д. Самое плохое в том, что разобраться во всех этих опциях с каждым днем ставало все труднее.

Недавно подсмотрел способ, как можно более эффективно/красиво/функционально, а главное — просто, сделать окно настроек. Подсмотрел здесь.

Суть метода заключается в том, что бы организовать параметры в виде простых осмысленных предложений. Например, «если количество пикселей с яркостью больше 250 составляет не менее 5% общей площади, уменьшить экспозицию на 0.5 мс». Это намного понятней, чем 3 TTrackBar/TEdit «яркость», «минимальная площадь», «смещение экспозиции». Второй шаг — сделать ключевые значения в этом предложении изменяемыми. Что бы лучше понять, о чем речь, очень рекомендую посмотреть пример (в конце статьи) или взглянуть на источник вдохновения.

А теперь немного деталей реализации…

Read the full post »

Delphi + Git

В этой статье хочу познакомить вас с системой контроля версий Git и поделиться опытом работы с ним в работе над Delphi проектами. Если Вы уже знакомы с Git — начинайте с третьей части статьи.

1. Init

Git — распределенная (distributed) система контроля версий. Ее разработал небезызвестный Линус Торвальдс для управления исходным кодом ядра Linux. Git — это не улучшение, а переосмысление контроля версий.

Многие считают Git сложным, особенно после SVN. Вся проблема в том, что Git построен на совсем других принципах, и просто заменить команду svn на git не получится. Очень важно понимать суть git, тогда он станет для Вас простым и понятным. Совет — забудьте все, что Вы знали о системах контроля версий на 10 минут. Начнем….

Read the full post »

Разработка через тестирование (TDD) и Delphi

No matter how slow you are writing clean code, you will always be slower if you make a mess.
— Uncle Bob Martin

Большое спасибо всем, кто принял участие в голосовании! Судя по результатам и комментариям — тема актуальна, и многие не используют автоматическое тестирование потому, что в Интернете очень мало информации по этому вопросу. Недостаток вводных статей по тестированию кода, на мой взгляд, в том, что они очень поверхностны. Читателю предлагают сферический пример калькулятора в вакууме, который с реальными проектами никак не связан.

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

Приятного чтения!

Read the full post »

10 причин перестать программировать на Delphi

Мне очень нравится Delphi и я не призываю вас бросать работу. Просто мысли, в случайном порядке:
  1. Delphi на несколько лет отстает от других технологий. Да, Embarcadero развивают свой продукт, но ведь их конкуренты тоже! По версии TIOBE не похоже, что популярность языка активно возрастает.
  2. Исходя из опросов (а также банального пролистывания вакансий), Delphi-разработчикам платят меньше, нежели специалистам по другим технологиям с тем же опытом.
  3. Стереотип, что Delphi (и PHP) разработчики — ничего не умеющие школьники. Возможно, виной всему легендарные темы на форумах («как написать вирус на делфи срочно!!!!», «памагите с алгоритмом сортировки» и т.д.).
  4. Процесс разработки приложений с использованием VCL подталкивает жестко связать UI и логику, в итоге получается такой себе монолит, который тяжело сопровождать. Даже если Вы достаточно опытны, чтобы этого не сделать, никто не застрахован от получения legacy-приложения на доработку.
  5. RAD Studio — не слишком удобная IDE, а Delphi — не самый интересный и гибкий ЯП . Конечно, тем кто не «пробовал» других сред разработки приложений (которые намного тесней интегрируются с языком и технологиями и предоставляют на порядок больше возможностей) и не писал на чем-то вроде Ruby или Haskell этот аргумент может показаться несправедливым.
  6. Выйти из зоны комфорта и бороться со своей привязанностью к языку, платформе и технологии.
  7. Учить новые языки программирования и технологии, ведь мир не стоит на месте, а информационный мир развивается экспоненциально. Чтобы оставаться хорошим специалистом необходимо постоянно чему-то учиться (надеюсь, у вас в памяти остались воспоминания о том, как вы изучали свой первый ЯП, как радовались что программа компилируется, как хотелось изучать и познавать новое?)
  8. Desktop-приложения постепенно уходят, а современный web с HTML5 идет ему на замену. Delphi не готов к этому.
  9. Delphi-разработчики не проводят веселых и интересных конференций.
  10. Забросить работу в ІТ, кардинально сменить жизнь и заняться любимым делом (если Вы программист только ради денег, money-driven-developer).

Что думаете по этому поводу?

Кстати, легендарный http://www.isdelphidead.com/ что-то не открывается🙂 К чему бы это?

Из Delphi в FreePascal под Mac OSX

Уже больше года прошло с того момента, как заказчик попросил меня сделать «то же самое, только под мак». Хочу рассказать о своем опыте портирования с Delphi/Windows на Lazarus/MacOS.

(Я надеюсь все знают что такое Lazarus/FreePascal)

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

Read the full post »

DelphiPlus.org и RSS

Последнее время сайты delphifeeds.ru/delphifeeds.com совсем не радуют содержимым. Очень много оффтопика.

Есть такой замечательный ресурс в Интернете — http://www.delphiplus.org/, сборник интересных статей и событий в мире Delphi, который обновляется каждый (!!) день. На мой взгляд, единственный его недостаток — отсутствие RSS для удобного отслеживания обновлений. Автор сообщил мне, что сайт планируется перевести на движок, после чего появится масса удобных функций, включая RSS.

…А пока можно воспользоваться моим костылем: добавляем в Google Reader (или другой любимый RSS-reader) следующий URL: http://delphi.frantic.im/delphi_plus.xml

Как это работает? На сервере Ruby скрипт, который несколько раз в день парсит delphiplus.org и формирует из его контента файл в формате RSS-XML. Предложения приветствуются (в виде комментариев к топику).

О разбитых окнах

Суть правила такова: «Если в здании появилось разбитое окно, вероятность появления следующего очень возрастает». Подробнее об этом можно прочитать здесь.

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

Очевидно, что после некоторого времени код превращается в помойку с кучей разбитого стекла. И глядя на всё это нету никакого желания исправлять ситуацию, т.к. это будет очень сложно; возникает резонная мысль: «А не переписать бы всё заново?..»

Как не допустить такой ситуации?

Read the full post »