Всем привет!
Сегодня я расcкажу вам о своем опыте написания ORM для Delphi с использованием RTTI под влиянием практик работы с Doctrine и Java EE.

Зачем?

Под мою власть недавно попал старый проект на Delphi7 в котором ведется активная работа с базой данных под Interbase 2009. Код в этом проекте радовал, но ровно до тех пор, пока речь не заходила о самом взаимодействии с бд. Выборка данных, обновление, внесение новых записей, удаление — все это занимало немало строк в логике приложения, отчего разобраться в коде порой становилось довольно сложно (спасение в добросовестном разработчике, который круглосуточно отвечал на мои глупые вопросы). В мои руки проект был передан с целью устранения старых бед и добавления в него нового модуля, задача которого — покрыть новые таблицы БД.

Мне нравится MVC подход и очень хотелось разделить код логики с кодом модели. Да и если уж на чистоту — я не захотел для каждой новой таблицы переписывать по новой все get/set методы. Пару лет назад я познакомился с понятием ORM и мне это понравилось. Мне понравился принцип и я был в восторге, применяя его в своей работе.
В тот же момент я ринулся искать в Delphi7 хоть что-нибудь похожее на Doctrine или может генераторы Entity/Facade классов для таблиц… Ни того ни другого. Зато в поисковой выдаче нашлось несколько готовых решений. Например DORM. В целом, отличная штука и, по сути, то что нужно!

UICloud — это база бесплатных пользовательских интерфейсов с поисковой системой, рейтингом и каталогизатором в которой собрано все от исходников в формате PSD, до готовых решений на HTML, CSS или jQuery: формы, слайдеры, кнопки, календари, элементы и полноценные интерфейсы для мобильных и веб приложений. В проекте уже сейчас можно найти практически все что нужно для облегчения процесса разработки дизайнерам и разработчикам.

На данный момент в базе 23586 элементов и почти тысяча UI-сэтов включающие в себя готовые решения в едином стиле. Проект создан Британской студией Double-J Design целью проекта является создание самой обширной UI базы.

Единственный интуитивно-понятный интерфейс — это женская грудь, всему остальному нужно учиться. Эта народная мудрость пришла ко мне сегодня утром, когда я в деталях и красках рассказывал третьему по счету коллеге, чем resolved отличается от closed и как делать log work, чтобы руководству не было потом мучительно больно. В этой статье я попробую на примере нескольких зарисовок обрисовать возможные варианты использования системы управления задачами на примере популярной Jira при ежедневной работе. Приемы, конечно, не единственно возможные — но они достаточно просты, универсальны и применимы не только к Jira, но и к большинству популярных систем управления задачами — Redmine, Trac, Bugzilla и прочим.

Предисловие

Я капризный. Я жалуюсь о многих вещах. Многое в мире технологий мне не нравится и это предсказуемо: программирование — шумная молодая дисциплина, и никто из нас не имеет ни малейшего представления, что он делает. Учитывая закон Старджона, у нас достаточно вещей для постижения на всю жизнь.

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

PHP — единственное исключение. Фактически каждая деталь PHP в какой-то мере поломана. Язык, структура, экосистема: всё плохо. И даже нельзя указать на одну убийственную вещь, настолько дефект систематичный. Каждый раз, когда я пытаюсь систематизировать недостатки PHP, я теряюсь в поиске в глубину обнаруживая всё больше и больше ужасных мелочей(отсюда фрактал).

PHP — препятствие, отрава моего ремесла. Я схожу с ума от того, насколько он сломан и насколько воспеваем каждым уполномоченным любителем нежелающим научиться чему-либо ещё. У него ничтожно мало оправдывающих положительных качеств и я бы хотел забыть, что он вообще существует.

Теория

Для начала, давайте разберемся, что же такое Behavior Driven Development(в дальнейшем BDD) и чем данная техника отличается от Test-Driven Development(в дальнейшем TDD)

Разрабо́тка че́рез тести́рование (англ. test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (англ. test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования.

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

О проблеме внесения изменений в БД в ходе разработки приложения писали на Хабре много раз.
Версионная миграция БД — удобный подход к решению проблемы.

Уже долгое время я участвую в разработке ECM7.Migrator — инструмента для автоматизации изменений БД. О том, как его использовать и почему это удобно, мы писали здесь.

8 месяцев назад мы выпустили версию 2.0, а на этой неделе вышла версия 2.6. По сравнению с версией 2.0 многое изменилось.

• Полностью переписаны классы всех провайдеров: API стал проще и удобнее, все методы работают адекватно (а для проверки адекватности было написано большое количество модульных тестов);
  
• Поддержка SQL Azure и Firebird;
• Методы Up и Down переименованы в Apply и Revert, реализовывать Revert не обязательно;
• Обработка разделителей запросов (например, «GO» для MSSQL);
• Возможность работы со схемами БД (отличающимися от схемы по умолчанию);
• … и много других мелких доработок.

Попробуйте наш новый мигратор и, возможно, он понравится вам так же, как нравится нам!
Взять новую версию можно в google code и в галерее пакетов nuget.

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

Прочитал пост "Проблемы при внедрении Agile" хабрапользователя adnotum, захотелось предложить несколько решений описанных проблем. Поскольку решения достаточно универсальные, решил оформить их в виде отдельного поста.
Большинство описанных проблем появляется, потому что Scrum является гибким фреймворком, а не полноценной методологией. Это является его недостатком и преимуществом одновременно. «Ванильный» или «кошерный» Scrum описан кратко в официальном авторитетном руководстве от Сазерленда и Шваббера. «Кошерный» Scrum — это когда ты все делаешь по правилам, а получается не очень вкусно, да и сам процесс не доставляет удовольствия. Такой сферический Scrum будет работать только идеальном вакууме, но его можно и нужно адаптировать, чем собственно этот фреймворк и хорош.

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

• Убедитесь, что срок действительно жесткий
• Не берите на себя проекты с нереальными сроками
• Планируйте методом «набегающей волны»
• Периодически пересматривайте оценку проекта
• Оценивайте проект эмпирически
• Привлекайте к первоначальной оценке команду

Как и многие сейчас, мы решили попробовать внедрить agile для развития одного из наших решений. Точнее, поскольку в мире разработки ПО нет «черного» и «белого», мы решили «не внедрить agile», а перейти от использования менее гибких подходов к использованию более гибких.

В данном топике я хотел бы описать проблемы, с которыми мы столкнулись, а также привести соображения, как некоторых из этих проблем можно было бы избежать. Написание топика продиктовано желанием способствовать переводу дискуссии про agile из плоскости «как наконец заставить этих старомодных менеджеров перейти к прогрессивным методологиям» в плоскость «как работать по agile наиболее эффективно».

На Хабре недавно была поднята очень важная тема — соблюдение сроков проектов. В качестве метафоры автор, Михаэль Вольф, использует метафору путешествия и прогнозирования сроков прибытия, но не дает практических советов по завершению проектов в срок. Чтобы раскрыть советы в более понятной форме, я вставлю несколько презентаций и слайдкастов в пост.
Позволю себе привести ряд конкретных рекомендаций, которые будут полезны для большинства проектов:

• Грамотно обрабатывайте запросы на изменение требований
• Урезайте лишний функционал
• Управляйте рисками
• Используйте гибкие методологии
• Научитесь управлять Death March проектами

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