Delphi. Как указать папку "по умолчанию" для новых проектов

Надоело мне, что Delphi предлагает каждый новый проект сохранить в папке My documents. И задался я вопросом, а как бы эту папку изменить. Оказалось – очень просто. Настолько просто, что даже и рассказывать тут не о чем. Но я всё-таки расскажу так как я (почему-то) долгое время считал, что такой опции просто нет.

Главное меню –> Tools –> Options –> Environment Options –> Default Project

Или, с помощью IDE insight: Ctrl+. ввести default project + Enter

В Delphi XE-XE5 эти настройки хранятся в реестре:

HKEY_CURRENT_USER\Software\Embarcadero\BDS\12.0\Globals\DefaultProjectsDirectory

Тип данных: REG_SZ

Читать дальше..

Головокружительные возможности DI и Delphi Spring. Часть 9. Один интерфейс – несколько реализаций.

Это последний перевод из серии про внедрение зависимостей на примере использования Delphi Spring.
Это перевод публикации Ника Ходжеса от 07 ноября 2011 года: Getting Giddy with Dependency Injection and Delphi Spring #9 – One Interface, Many Implementations. (перевод сделан с разрешения автора).

Все переводы по Spring

• Я не переводил части с 1й по 5ю, потому что мне было лень - там очень много текста, и, по моему скромному мнению, эти части не содержат конкретной информации об использовании Delphi Spring, а постепенно подводят к необходимости использования Dependency Injection. Причём, Ник ведёт к этому слишком длинным и запутанным путём. См. Ссылки по теме.
• DI и Delphi Spring. Часть 5. Основы Delphi Spring.
• DI и Delphi Spring. Часть 6. Обойдёмся без конструктора.
• DI и Delphi Spring. Часть 7. Контроль над созданием.
• DI и Delphi Spring. Часть 8. Разное.
• DI и Delphi Spring. Часть 9. Один интерфейс несколько реализаций.

---

Как обычно, Delphi Spring Framework можно скачать с GoogleCode
До сих пор мы регистрировали интерфейсы и их реализации в соотношении один к одному. Для каждого интерфейса регистрировался только один реализующий класс. Но что, если мы хотим реализовать интерфейс разными способами, выбирая реализацию в зависимости от выбора пользователя или других внешних факторов?
К счастью для нас, контейнер Spring предоставляет такую возможность. Система регистрации контейнера в фреймворке Delphi Spring позволяет при каждой регистрации указать имя предоставляемой реализации, давая таким образом возможность отличать одну регистрацию от другой, даже если они регистрируют разные реализации для одного и того же интерфейса.
При регистрации нескольких реализаций одного интерфейса без указания имени «победит последний».

Читать дальше..

Головокружительные возможности Dependency Injection и Delphi Spring. Часть 8. Разное.

Это перевод публикации Ника Ходжеса от 5 ноября 2011 года: Getting Giddy with Dependency Injection and Delphi Spring #8 – Miscellanea. (перевод сделан с разрешения автора).

---

Все переводы по Spring

• Я не переводил части с 1й по 5ю, потому что мне было лень - там очень много текста, и, по моему скромному мнению, эти части не содержат конкретной информации об использовании Delphi Spring, а постепенно подводят к необходимости использования Dependency Injection. Причём, Ник ведёт к этому слишком длинным и запутанным путём. См. Ссылки по теме.
• DI и Delphi Spring. Часть 5. Основы Delphi Spring.
• DI и Delphi Spring. Часть 6. Обойдёмся без конструктора.
• DI и Delphi Spring. Часть 7. Контроль над созданием.
• DI и Delphi Spring. Часть 8. Разное.
• DI и Delphi Spring. Часть 9. Один интерфейс несколько реализаций.

---

Как обычно, Delphi Spring Framework можно скачать с GoogleCode.

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

• Как вы наверно заметили, я призываю вас использовать интерфейсы при кодировании и регистрировать классы, реализующие эти интерфейсы в фреймворке. О чём я забыл упомянуть явно, это о том, что все интерфейсы, зарегистрированные в фреймворке Spring должны иметь GUID. GUID легко добавить, нажав CTRL+SHIFT+G в редакторе кода Delphi. А если же вы попробуете использовать интерфейс, у которого нет GUID-а, то получите ошибку: “Project <НазваниеПроекта>.exe raised exception class ERegistrationException with message 'Non-Guid Interface Services are not supported.” («Интерфейсы без Guid не поддерживаются»).
   
• Если внимательно посмотреть на код в демонстрационных проектах, то можно заметить, что прежде чем что-либо делать с контейнером Spring, необходимо вызвать GlobalContainer.Build. Этот метод должен быть вызван до того, как что-либо может быть получено из ServiceLocator. Метод Build это код, который собирает воедино все зарегистрированные классы, создаёт экземпляры классов или подготавливает их к созданию по запросу, с учётом указанного времени жизни. Если при запуске приложения вы получаете ошибку 'LifetimeTypeManager was expected.', то это с большой вероятностью означает, что вам необходимо вызвать Build для вашего контейнера. И в самом деле, метод Build является основой вашего контейнера Внедрения Зависимостей. Вы должны один раз вызвать метод Build в корне вашего приложения. Для Delphi разработчиков это означает, что он должен быть вызван одной из первых строчек в вашем DPR-файле. Это также означает, что классы лучше регистрировать как можно раньше.
   
• Вы не обязаны использовать Global Container и Service Locator предоставляемые вам фреймворком. Создание своих собственных вариантов более чем приветствуется. У нас в Gateway Ticketing мы сделали следующее: мы объявили интерфейс, являющийся полной абстракцией понятия Контейнер DI (DI Container = Контейнер Обращения Зависимостей), а затем реализовали этот интерфейс самостоятельно, используя наследника от Tcontainer из фреймворка Delphi Spring. Таким образом, если в фреймворке что-то изменяется (а он действительно меняется с тех самых пор, как мы начали его использовать) или, если мы решим использовать другой контейнер, наш код полностью отделён от какой-либо конкретной реализации. Ещё один хороший пример следования правилу «Пиши код для абстракций, а не реализации». :)
   
• Я вынужден отметить, что некоторые считают концепцию Service Locator анти-паттерном . Сам я пока что ещё не пришёл к твёрдому заключению по этому вопросу. Да, Service Locator почти всегда является Одиночкой, но я лично и не рассматриваю одиночек только для чтения как что-то плохое, в отличие от некоторых. (Одиночка для чтения и для записи, по сути, является глобальной переменной, и я думаю, что все согласятся с тем, что глобальные переменные являются Порождением Сатаны.) Однако существуют некоторые разногласия в том, является ли использование контейнера реализацией Service Locator. Кроме того, если все зависимости определены до того, как результат выполнения станет доступным пользователю, то можно ли вообще считать контейнер переменной? Это остается предметом дискуссий. В конечном счете, для меня ценность и польза от Service Locator с лихвой перевешивает все возможные недостатки.
   
• Существует один недостаток, возвращающий нас к предыдущему пункту, который заключается в том, что когда вещи настолько отделены друг от друга и позднее связывание настолько ярко выражено, то становится возможным успешно собрать программу и до самого её запуска так и не узнать о том, что мы забыли зарегистрировать необходимый реализующий класс. В сложной системе, может пройти немало времени, прежде чем кто-либо заметит, что отсутствует реализующий класс для какого-нибудь редко используемого интерфейса. Если вы следуете предложенному мной образцу регистрации реализации в initialization секции модуля, то вы обязаны использовать этот модуль где-нибудь в программе (примечание переводчика: включить в uses), чтобы регистрация сработала. Как уже говорилось, если вы забыли его добавить, и не включили этот модуль в свою программу, то компилятор вам ничего не скажет, и узнаете вы об этом только во время работы программы. Это слабое место, и вам следует быть очень внимательным, чтобы не попасться в эту ловушку. В качестве стратегии можно рассматривать выделение всех регистраций в единый модуль, или использовать что-то типа статического анализа кода, который проверит, что для каждого вызова GetService есть соответствующий вызов RegisterService (или как там эти методы у вас называются). Просто, чтобы вы были в курсе.

Это всего лишь несколько вещей, на которые стоит обратить внимание, при использовании Dependency Injection в вашем коде. Я говорил это раньше, я скажу это снова: Если вы не используете Dependency Injection, значит, вы работаете неправильно.

---

Ссылки по теме

• Singleton — паттерн или антипаттерн – обсуждение на Хабрахабре.

Читать дальше..

Головокружительные возможности Dependency Injection и Delphi Spring. Часть 7. Контроль над созданием.

Это перевод публикации Ника Ходжеса от 08 октября 2011 года: Getting Giddy with Dependency Injection and Delphi Spring #7 – Controlling Construction.

---

Все переводы по Spring

• Я не переводил части с 1й по 5ю, потому что мне было лень - там очень много текста, и, по моему скромному мнению, эти части не содержат конкретной информации об использовании Delphi Spring, а постепенно подводят к необходимости использования Dependency Injection. Причём, Ник ведёт к этому слишком длинным и запутанным путём. См. Ссылки по теме.
• DI и Delphi Spring. Часть 5. Основы Delphi Spring.
• DI и Delphi Spring. Часть 6. Обойдёмся без конструктора.
• DI и Delphi Spring. Часть 7. Контроль над созданием.
• DI и Delphi Spring. Часть 8. Разное.
• DI и Delphi Spring. Часть 9. Один интерфейс несколько реализаций.

---

Как обычно, Delphi Spring Framework можно скачать с GoogleCode.

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

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

Вы правы на этот счёт – там действительно много всего происходит. Delphi Spring Framework делает за вас кучу работы – в основном за счёт создания экземпляров классов используя RTTI (информацию о типах времени выполнения).­ Spring контролирует создание, но при этом, оставляет программисту возможность управлять жизненным циклом объектов.

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

Хорошая новость здесь в том, что вам и не придётся. Фреймворк, при желании, позволяет управлять созданием объектов. В большинстве случаев если классы хорошо спроектированы, то их конструкторы просты, и в них не происходит ничего, кроме присвоения значений. Но иногда возникает нужда сделать при создании объекта что-то особенное. Иногда, классу требуется динамический параметр – объект, чьё состояние будет известно только при выполнении. (Примечание переводчика: мне очень не нравится слово динамический в этом контексте и примеры Ника, но я не придумал лучшего объяснения. Есть идеи, читатель? Пиши в комментарии!) Например, у нас может быть класс Клиент, и у этого Клиента могут быть Счета. И у нас есть класс, который мы хотим передать этому клиенту, но при этом мы не хотим связывать эти классы. Наш Клиент динамический – мы можем запускать запрос и выполнять эту операцию на каждом клиенте в нашей базе данных. Или Клиент может что-то делать на нашем сайте, и таким образом наш объект Клиента будет относиться именно к этому конкретному клиенту. В любом случае, данные нашего Клиента динамичны во время выполнения, и поэтому мы не можем загнать создание объекта в жёсткие рамки. Он должен быть уникальным, каждый раз, когда нам нужен экземпляр объекта, который выполняет действие над данным клиентом.

Читать дальше..

Головокружительные возможности Dependency Injection и Delphi Spring. Часть 6. Обойдёмся без конструктора.

Это перевод публикации Ника Ходжеса от 24-09-2011: Getting Giddy with Dependency Injection and Delphi Spring #6 – Don’t even have a constructor.

---

Все переводы по Spring

• Я не переводил части с 1й по 5ю.
• DI и Delphi Spring. Часть 5. Основы Delphi Spring.
• DI и Delphi Spring. Часть 6. Обойдёмся без конструктора.
• DI и Delphi Spring. Часть 7. Контроль над созданием.
• DI и Delphi Spring. Часть 8. Разное.
• DI и Delphi Spring. Часть 9. Один интерфейс несколько реализаций.

---

Вступление

В четвёртой статье этой серии я озвучил пару правил, одним из которых было “Делайте Конструкторы Простыми”.(примечание переводчика: я не переводил части 1-4.) В последней статье мы узнали, как использовать контейнер Spring для хранения интерфейсов и реализаций и как запросить у контейнера Spring готовую реализацию интерфейса, вместо создания объекта вручную с помощью конструктора.

В этой статье мы продвинемся ещё на один шаг и посмотрим, как Delphi Spring Framework умеет самостоятельно создавать объекты и автоматически вставлять реализацию в нужных местах, и нам для этого не придется даже вызывать конструктор.

Читать дальше..

Головокружительные возможности Dependency Injection и Delphi Spring. Часть 5. Основы Delphi Spring.

Это перевод публикации Ника Ходжеса: Getting Giddy with Dependency Injection and Delphi Spring #5 – Delphi Spring Basics.

---

Все переводы по Spring

• Я не переводил части с 1й по 5ю.
• DI и Delphi Spring. Часть 5. Основы Delphi Spring.
• DI и Delphi Spring. Часть 6. Обойдёмся без конструктора.
• DI и Delphi Spring. Часть 7. Контроль над созданием.
• DI и Delphi Spring. Часть 8. Разное.
• DI и Delphi Spring. Часть 9. Один интерфейс несколько реализаций.

---

Вступительное слово

Я много слышал о фреймворке Spring для Java. И даже знал, что аналогичный фреймворк был создан и для Delphi. Но у меня не хватало терпения сесть и разобраться. Также, как и с терминами “Внедрение зависимости” (Dependency Injection) и “Обращение управления” (Inversion of Control). Я часто встречал упоминания о них в разных статьях, но так и не смог уложить в своей голове, как применить эти знания к Delphi. И вот, наконец, я наткнулся на публикацию Ника. То, что я прочитал в этой публикации, запросто расставило всё по своим местам. Это было настолько потрясающе, что я решил обязательно перевести этот материал и опубликовать перевод у себя в блоге. Ник дал добро, и процесс пошёл.

Переводить было легко и просто. Всё-таки чувствуется разница между переводом материала, написанного носителем языка, и материала, написанного человеком для которого английский - не родной. Помню, как я мучился с переводом материалов по дженерикам в Delphi, пытаясь уловить, что же хотел сказать автор. Периодически даже пытался уловить смысл, заглядывать в оригинал материала на французском языке. Представляю, каково приходится переводчикам, чья основная специальность - локализация компьютерных игр, и кому приходится переводить не только текст, но и загадки и стихи. Бррр!

На самом деле, это уже 5я часть в серии публикаций, посвящённых Dependency Injection в блоге Ника (полный список ищите по ссылке). Но первые четыре публикации просто подводят читателя к необходимости писать код, используя как можно меньше зависимостей между классами. Я не стал их переводить. На мой взгляд, там не так много много полезной и уникальной информации, чтобы тратить время на перевод. Пятая часть представляет собой совершенно уникальный материал, рассказывающий об основах использования Delphi Spring Framework.

Читать дальше..

Переход на юникод 3. С Ehlib 3.6 на Ehlib 5.x

Продолжаю делиться опытом по переводу своего проекта на юникод. В этот раз я остановлюсь на обновлении библиотеки Ehlib с версии 3.6 на версию 5.2. Как я уже говорил, я проводил обновление стараясь сделать так, чтобы большая часть кода могла компилироваться и в Delphi 6 и в Delphi 2010.

С Ehlib-ом было всё просто. Мы без раздумий решили покупать обновление, тем более что версия 5.х содержит в себе массу отличных фич. Т.е. конечно, порядка ради мы с коллегами обсудили вариант обновить самим. Но решили, что новые фичи Ehlib-а, нам будут более чем полезны. Тем более, что по соотношению цена/качество/удобство - это самый лучший DbGrid для Delphi. Ещё рассматривался вариант с покупкой DevExpress, но высокая цена и необходимость переделывать те наработки, что уже сделаны для Ehlib-а убедили нас пока не связываться с TcxGrid.

Настройка Delphi для работы разными версиями библиотек.

Пятая версия Ehlib была распакована в отдельную папку Ehlib5. Также, в виде отдельной папки она была внесена в систему контроля версий. Папку с исходниками Ehlib 3.6 (предположим, что она называлась Ehlib3) я не трогал, ведь мне необходимо собирать проект и с 3й и с 5й версией библиотеки.

На данном этапе вся работа проходила в Delphi 6. Следующим пунктом встал вопрос, а как объяснить Delphi,  какую из версий Ehlib-а использовать? Для исходного кода проблема разрешилась с помощью введения в свой код новой директивы компилятора WANT_EHLIB5.

Но что же делать с dcu-файлами, и с настройками путей до исходных файлов Ehlib? Ведь и Ehlib 3 и Ehlib 5 содержат юниты с одинаковыми именами. Как объяснить Delphi, что когда я собираю проект с директивой WANT_EHLIB5 она должна искать исходники в папке Ehlib5, а когда без этой директивы, то исходники должны браться из папки Ehlib3?

Идеального решения я не нашёл.

Читать дальше..

Переход на юникод 2. План перехода и сторонние библиотеки.

Как я уже писал, я выбрал для перехода стратегию, требующую того, чтобы код приложения собирался как в Delphi 6, так и в Delphi 2010. Эта стратегия была выбрана как наиболее универсальная и позволяющая в любой момент переключиться на стратегию 3 и продолжить работу с копией кода программы заточенной только под одну юникодную версию Delphi.

Исследование ситуации

Итак, начинать надо с пакетов. Без них всё-равно не собрать программу. Первым делом я запустил Lazy Delphi Builder, просканировал папки с исходниками и стал пробовать компилировать каждый из пакетов, поочерёдно выписывая в блокнот имена пакетов, отказывавшихся собираться на Delphi 2010. Получился первый список проблемных пакетов. Конечно, на самом деле я не компилировал каждый из пакетов. Ведь понятно, что если пакет X не скомпилировался, то и все пакеты, которые зависят от пакета X также не компилироваться не будут.

Большая часть самописных библиотек зависела от сторонних библиотек, так что переход на юникод надо было начинать со сторонних либ.

Общий план перехода

1. Обновить все библиотеки от сторонних производителей.
2. Добиться, чтобы программа стабильно работала на Delphi 6 после завершения работы над первым пунктом.
3. Если сторонние пакеты больше не поддерживаются, перевести их на юникод собственноручно или заменить аналогами поддерживающими юникод.
4. Добиться, чтобы программа компилировалась и стабильно работала после завершения работы над третьим пунктом.
5. Сделать необходимые изменения в коде самописных пакетов, чтобы они могли собираться как в Delphi 6 так и в Delphi 2010 и продолжали стабильно работать в Delphi 6.
6. Сделать необходимые изменения в коде приложения, чтобы его можно было собрать и в Delphi 6 и в Delphi 2010.
7. После сборки в Delphi 2010 протестировать работу, и начать исправлять ошибки связанные с переходом на Delphi 2010. При каждом исправлении проверять, что приложение собирается и работает и 6й и в 2010й версии Delphi.

Сторонние библиотеки

Из сторонних библиотек у меня использовались:

Читать дальше..

Переход на юникод 1: Поиск стратегии.

Обещанная статья о переводе большой программы с Delphi 6 на Delphi 2010 (для Delphi 2009 и Delphi XE (2011), ситуация будет аналогичной). Материала получилось довольно много, поэтому я разобью его на несколько постов.

Дано

Большое приложение, с большой базой данных и большой историей. Приложение, которое начали разрабатывать ещё на Delphi 3, потом портировали на Delphi 6. Теперь надо ввести поддержку юникода, и собрать в Delphi 2010. Приложение использует кучу пакетов как самописных, так и от сторонних производителей. Проект большой, комментариев в коде практически нет. Юнит-тесты написаны только для очень маленькой части кода общих библиотек.

Что надо получить?

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

Необходимо поддерживать и развивать существующую версию (на Delphi 6), исправляя найденные баги и расширяя функционал. А баги будут на сто процентов. Всё-таки баги в программах появляются также ожидаемо как глисты у собак летом.

Стратегии перехода

Стратегии для перехода на Юникод:

1. Сделать так, чтобы один и тот же код мог собираться как в Delphi 6, так и в Delphi 2010 и чтобы программа работала стабильно и без ошибок.
2. Начать проект с нуля только на Delphi 2010, частями перенося код из версии для D6.
3. Сделать копию стабильной версии проекта и вести работу по переходу на юникод на копии, оставляя нетронутой стабильную версию для Delphi 6.

Плюсы и минусы стратегий

Читать дальше..

Чего не хватает в Delphi

Публикация для конкурса проводимого агрегатором Delphi новостей DelphiFeeds.ru.

Интеграция с SVN

Я говорю не просто о добавлении комманд Update/Commit в какие либо меню. Всё это возможно и в варианте интеграции SVN в Delphi для бедных. Я говорю о широкой визуальной поддержке. Чтобы на Tab-ах редактора и в дереве проекта отображался значок как в TortoiseSVN.

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

Мне понравилось, как сделана интеграция SVN в NetBeans.

SVN команды доступны в отдельном субменю при правом клике как на файле в дереве так по заголовку таба в редакторе.

Читать дальше..

Delphi 2010: Open Tools API интерфейсы для интеграции системы контроля версий в IDE.

Embarcadero уже долгое время обещает интегрировать поддержку систем контроля версий в Delphi. И эта функция довольно востребована. Официально даже было объявлено, что эта поддержка доступна уже в Delphi 2010. Давайте посмотрим, что приготовила для нас Embarcadero.

Для работы с VCS (Version Control System - системами контроля версий) в файле ToolsApi.pas добавлены 3 интерфейса:

1. IOTAVersionControlNotifier - интерфейс отвечающий непосредственно за реализацию связи с VCS.
2. IOTANotifier - базовый интерфейс для уведомлений. Содержит методы позволяющие получать уведомления при изменении файла, его сохранении и закрытии редактора.
3. IOTAVersionControlServices - сервисный интерфейс, позволяющий подключить и отключить свою реализацию VCS.

Читать дальше..

Заметки о процессе ведения проектов в Delphi. Мой опыт.

Это старый пост из архива, который почему-то не был опубликован. Он немного устарел, и описывает то как я видел процесс разработки 1,5 года назад. Если интересно, то позже я напишу о том, как я вижу этот процесс сейчас.

Как-то так получилось, что в основном, мне приходилось заниматься сопровождать и развивать чужие проекты. А характерным признаком всех моих мест работ было одно – бардак. На всех работах, одним проектом занимался только один программист. У проекта обычно есть руководитель, который формулирует задания. Руководитель кода не знает, и программировать не умеет. В проекте могут участвовать люди, занимающиеся поддержкой и развитием базы данных, тестированием продукта, общением с клиентами и установкой новых версий. Практически все проекты, с которыми я работал, относились к бухгалтерским программам, и напрямую работали с базой данных(Firebird). Обычно в фирме таких проектов было несколько, но общего кода, не считая сторонних компонентов, у них почти не было. Так что у меня нет опыта работы в команде. И практически нет опыта следования процессу разработки. Только на одной из моих работ, для программистов была написана инструкция о том, как правильно работать. Там были как разумные вещи, так и не очень(in my humble opinion). Но, полностью инструкции не следовал ни один из программистов. Поэтому большинство моих рассуждений – это отчаянная попытка придумать велосипед навести порядок и превратить бардак в процесс так, чтобы это не сильно напрягало ни меня, ни других программистов и позволило навести и сохранить порядок в проекте.

Процесс выглядит так:

Читать дальше..

Итоги недели: первый шаг к созданию команды

Вопрос о том, работают ли Delphi программисты в команде волнует меня давно. И если работают то как? Причина в том, что во всех местах где мне доводилось работать, Delphi программисты работали поодиночке. Каждый над своим проектом. Максимум – один из программистов заведовал общей библиотекой компонентов.

На текущей моей работе точно такая же ситуация. Все программисты находятся в одной комнате, но каждый работает над своим проектом и даже не в курсе того, какие проблемы решает его сосед. Более того, все проекты когда-то были основаны на одном и том же базовом коде, но этот код просто копировался между проектами. В результате сейчас мы пришли к тому, что в каждом проекте этот код немного (иногда даже сильно) отличается. Типичная ситуация в духе worse than failure.

Читать дальше..

Давайте знакомиться? :) Несколько вопросов читателям.

Image by Squonk11 via Flickr

Я хочу составить примерное представление о читателях этого блога. Пожалуйста, потратьте пару минут, чтобы кратко рассказать о себе и ответить на следующие вопросы. (достаточно и кратких ответов: да/нет. Хотя, конечно, интереснее читать развёрнутые=) ). Заранее спасибо.

1. Как давно Вы занимаетесь программированием вообще?
2. Как давно Вы занимаетесь программированием на Delphi?
3. Приносит ли программирование вам какой-нибудь доход?
4. Доводилось ли Вам участвовать в командной разработке на Delphi?
5. Если не секрет, то сколько человек было в команде?
6. Если не секрет, каким образом разделялись обязанности?
7. Занимаетесь ли вы проектированием?
8. Сколько примерно времени в процентах вы тратите на проектирование? (например, 100% – время выполнения проекта (или задания), из них 10% на проектирование, 90% написание кода.)
9. Оцениваете ли Вы время выполнения задания перед началом работы?
10. Как часто Вы укладываетесь в установленный срок?
11. Отслеживаете ли Вы время работы над заданием?

p.s. мои ответы в комментариях.

Читать дальше..

О переходе крупного проекта на Delphi 2009(перевод)

Перевод статьи: “Upgrading a major project to Delphi 2009”,  Lars B. Dybdahl.

Вот и закончен перевод на Delphi 2009 крупного проекта, который в течении нескольких лет разрабатывался довольно большой командой программистов. Теперь я готов поделиться опытом.

Если Вы хотите оценить объём работ, которые потребуется для конвертации проекта, примите во внимание, что объём строк в проекте не является таким уж и значимым показателем. Более важно, какой код у Вас есть, насколько он сегментирован, и насколько согласованно написаны сегменты. Вещи относящиеся к пользовательскому интерфейсу, бизнес логике и т.п. очень легко конвертировать. Я бы даже сказал, что достаточно просто перекомпилировать и запустить. А вот с другими частями, всё будет не так просто.

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

Читать дальше..

Ссылки на хорошие ИТ-блоги о Delphi(и не только)

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

• http://gunsmoker.blogspot.com/  - Gun Smoker's blog – статьи, баги Delphi, новости проекта TaskEx.pas
• http://www.delphilab.ru/ – проект Snowy - новости, know how, книги, статьи, ссылки
• http://kazav.blogspot.com/ - блог Алексея Казанцева - конкретные решения, код, баги
• http://ins911.blogspot.com/  - блог Юрия Спектора - конкретные решения, код, баги
• http://delphisex.blogspot.com/ - блог Михаила Мохова - заметки, обзоры, мысли, ссылки
• http://romanvbabenko.blogspot.com/search/label/Delphi - несколько заметок о Delphi
• http://vingrad.ru/blogs/romkin/ - Romkin блог(выглядит заброшенным)
• http://delphist.ru/ - блог aktuba - мысли о программировании

Отдельным пунктом хочу упомянуть удивительнейший портал посвящённый Delphi -Королевство Delphi

Помимо огромного количества разнообразнейшего материала(иногда мне кажется что там есть ответы на ВСЕ возможные вопросы по Дельфи), портал удивителен ещё и своеобразной навигацией. К своему, стыду я до сих пор не разобрался что и где там найти. Поэтому, хочу отдельно упомянуть разделы со статьями: Подземелье Магов и Сокровищница

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

• http://transl-gunsmoker.blogspot.com/ – переводы от GunSmoker – переводы уникальный статей от создателей Windows описывающих почему некоторые вещи в Windows сделаны именно так а не иначе. Настоятельно рекомендую.
• http://itblogs.ru/ – агрегатор русскоязычных it блогов. Много хороших авторов. Мне особенно импонируют
  • блог Анатолия Тенцера Анатомия CIO
  • блог Михаила Елашкина Несвоевременные мысли об ИТ
• http://ibsurgeon.blogspot.com/ – блог Алексея Ковязина

Читать дальше..

Настройка папок для выходных файлов в Delphi

Обещанный пост о настройке выходных папок в Delphi.

По умолчанию Delphi 7 помещает выходные файлы в C:\Program Files\Borland\Delphi7\Projects\, а Delphi 2009 в C:\Users\Public\Documents\RAD Studio\6.0\. Это что касается bpl и dcp-файлов. Dcu-шки и exe создаются в папке с исходниками. Такая организация мне не нравится, поэтому я перенастраиваю всё под себя.

Краткое содержание:

1. Добавить переменную окружения содержащую путь до рабочей папки
2. Добавить в Path путь до новой папки с BPL-ками
3. Добавить относительные пути до BPL, DCP, RES, DCU папок в Delphi в Library Path
4. В Default Project Options указать в качестве выходных папок относительные пути до BIN, BPL, DCP, RES, DCU папок.

Подробная инструкция с картинками под катом. =)

Читать дальше..

Цель проекта: Lazy Delphi Builder. И небольшой FAQ по теме.

Целью проекта в том, чтобы создать инструмент для:
1) Быстрой перекомпиляции проектов с большим количеством связанных библиотек, без возни с файлами настроек.
2) Для быстрой компиляции чужих проектов и компонент без их установки в IDE. (Например, чтобы быстро собрать демки из исходников)
3) Для быстрой установки в IDE компонент из исходников, без необходимости прописывать кучу путей в Library Path.
4) Для интеграции с другими build-инструментами. (будет версия для работы в командной строке)
5) И главный плюс - это возможность жёстко указать папки для всех типов выходных файлов (exe, bpl, dcp, dcu, res). Чтобы в папках с исходниками не оставалось никакого мусора.

Может ли Lazy Delphi Builder заменить want ?

Да, но только ту часть want-a которая отвечает за компиляцию проектов. Я начл писать Lazy Delphi Builder именно потому что мне не нравится редактировать xml-файлы размером в несколько десятков килобайт. =) Я не планирую реализовывать остальной функционал want-a, такой как: работа с файлами, папками, архивами, ftp, http, e-mail-ами и т.п. Однако, если возникнет идея, которая функционально украсит Lazy Delphi Builder, то с удовольствием её выслушаю. ;-)

Что лучше изучать: ant, want, rake или что-то ещё.

Выбор инструмента во многом зависит от поставленных целей. Не стоит также забывать и про стандартные инструменты, доступные в каждой инсталляции Delphi: msbuild и make ;) Инструментов разных полно, и каждый со своими уникальными особенностями и ограничениями.

Для создания билда из исходников с нуля вполне достаточно Lazy Delphi Builder-a. Я планирую в скором будущем сделать версию для командной строки. Тогда Lazy Delphi Builder можно будет легко вызвать из .bat-файлов, сценариев ant-а, want-а и и.п.

А пока что, мне самому вполне достаточно иметь возможность, не напрягаясь, получить билд из исходников, с нужными мне директивами и включенной оптимизацией. И я для себя не вижу смысла в установке, например, ant-а для выполнения действий, которые легко реализуются с помощью .bat-файлов.

=)

Ещё можно почитать по теме

• Обзор средств для автоматической компиляции и установки библиотек в Delphi
• Мечты об идеальной билд-машине
• Delphi. Автоматизация сборки проектов в блоге Романа В. Бабенко
• Delphi. Использование Apache Ant для сборки проектов в блоге Романа В. Бабенко

Читать дальше..

Обзор средств для автоматической компиляции и установки библиотек в Delphi

На работе у меня установлена 6я версия Delphi, и для перекомпиляции всех библиотек и проектов использую первую версию want. Дома же у меня стоит BDS 2007, и при попытке воспользоваться want-ом, выяснилось, что эту версию Delphi want просто не видит.

Я подумал: ага! появился повод взглянуть на продвигаемый Codegear-ом MsBuild. Но, немного поизучав документацию и справку в Дельфи на эту тему, решил, что с MsBuild-ом для меня всё не так просто. Точнее, всё довольно просто когда в комплекте с .dpk файлами поставляются и .dproj файлы, но во многих библиотеках их просто нет. Единственный способ создать .dproj файл - это открыть .dpk-файл в IDE. Но подобное вмешательство в файлы чужих библиотек меня не устраивало.

Следующим инструментом был Silverpoint MultiInstaller. MultiInstaller умеет распаковывать исходники из .zip файла, компилировать и регистрировать в Delphi. Настраивается через ini файл, в котором должны быть прописаны названия zip-файлов с исходниками, можно также задать пути для поиска нужных файлов. Для каждой версии Дельфи можно задать свои пути. К сожалению MultiInstaller не умеет просто перекомпилировать исходники в указанных папках.


Читать дальше..

Мечты об идеальной билд-машине

Вот было бы здорово, чтобы для перекомпиляции всех установленных библиотек и проектов для Delphi, достаточно было указать входную папку, директивы компилятора, указать выходные папки для Bpl, Dcu и нажав на большую кнопку Go! получить результат в лучшем виде. Да так, чтобы в папках с исходниками не осталось никакого мусора типа .dcu и .res файлов. А все Bpl и Dcu попали именно туда куда надо, а не по тому адресу что вписан в свойствах проекта.

В принципе, такие мысли появились у меня только после работы в N, где к первому проекту, который мне достался, прилагался скрипт для WANT(A Pascal-Friendly Build Tool). Не чудо ли, набираешь в командной строке "want all" и получаешь полностью скомпилированный проект, в котором все файлы разложены по своим местам. Тогда мне это показалось чудом, особенно после предыдущей работы в Б, где по словам одного из коллег, для поднятия рабочего места с нуля требовалось больше 2х-дней, большая часть из которых уходила на установку в нужном порядке всех необходимых компонент. Вероятно, коллега малость преувеличивал, но тем не менее, рядом с его столом стояли 3 системных блока, на каждом из которых хранились исходники своей версии проекта.

Читать дальше..