Голосуем в комментариях за самые интересные темы. =)
- Сделать подборку лучших постов о Delphi за 2011 год. Будет обязательно.
- Инструкция для Lazy Delphi Builder
- Lazy Delphi Builder: улучшение работы, исправление ошибок, хранение профилей в SVN.
- Lazy Delphi Builder: Генерация .bat файлов.
- Выявление возможных проблем при установке компонентов. В виде готовой программки или как часть Лэйзи билдера.
- Продолжение перевода серии про Dependency Injection и Delphi Spring.
- Статья: Компиляция сторонних библиотек. Подводные камни. И почему этот процесс нельзя унифицировать.
- Статья: Переход из HelpMaker в Help & Manual. И их сравнение.
- Продолжение заметки о процессе ведения проектов в Delphi на примере использования Redmine. Тут если подумать всё тривиально и кроме прописных истин мне и сказать особо нечего. Разве что только дать несколько советов о хранении Delphi кода в системах контроля версий.
- Описание CnWizards в одном файле.
- Написать программку для извлечения метаданных и данных БД Firebird для удобного хранения в системе контроля версий. Из серии, запустились по расписанию, автоматом извлекли всё что надо и отправили в систему контроля версий. А помимо метаданных извлекать планируется некоторые БЛОБы (например в виде DFM-ок или XML-файлов). Хочу такую для себя написать. Может ещё кому надо/интересно?
- Статья: пишем простенький ORM с помощью Delphi RTTI.
- Продолжение серии постов о переходе на юникод:
- Поверхностный обзор скриптовых движков и дизайнеров форм для Delphi. Ищем замену Dream VCL.
- Статический анализ Delphi кода – мой опыт. Я пробовал Code Healer и Peganza Pascal Analyzer + ещё какую-то программку для поиска повторяющихся фрагментов кода (Copy Paste). Инструмент от Peganza мне очень помог. Могу попробовать вкратце рассказать.
- Firemonkey – ищем/пишем замену DbGird-у.
- Обзоры JVCL. Стоит ли продолжать?
Закрыть блог и больше ничего не писать. Может быть это сделает кого-то счастливым?
p.s. не обещаю что напишу, но обещаю взять на заметку.
С удовольствием почитал бы о: "Программка для извлечения метаданных и данных БД Firebird..." и "статический анализ Delphi кода".
ОтветитьУдалитьЗ.Ы.
По статическому анализу, тоже смотрел Code Healer & Pascal Analyzer, но в итоге остановился на появившихся в Delphi QA инструментах.
> почитал бы о: "Программка для извлечения метаданных и данных БД Firebird..."
УдалитьТут вообще подразумевалось не статья о программке, а процесс написания самой программки. =) Подправил пост.
Интересно было бы посмотреть на альтернативы дбгрида в Firemonkey, а то Девэкспрес пока как то не шевелиться. На сколько она стабильна, по отзывам полный мрак пока еще, да и не отзывам.
ОтветитьУдалить> Интересно было бы посмотреть на альтернативы дбгрида в Firemonkey
УдалитьЭто мне и самому интересно. Именно непонятки с Firemonkey и работой с Firebird-ом через гриды тормозят переход на FMX.
+1 Продолжение перевода серии про Dependency Injection и Delphi Spring
ОтветитьУдалить>>Статья: пишем простенький ORM с помощью Delphi RTTI.
ОтветитьУдалитьОднозначно буду всячески содействовать продуктивным обсуждениям и позитивной критике!!!!
И всё, что касается Lazy Builder-а. Всё-таки брэнд "Алексея Тимохина" прочно ассоциируется с данным проектом. Хочется продолжения темы.
Про статью про ORM ответил в комментарии ниже.
Удалить1й голос за Lazy Delphi Builder. Excellent! =)
1) Продолжение ... Delphi Spring
ОтветитьУдалить2) Статья: ... ORM с помощью Delphi RTTI.
(Может быть некое сравнение различных ORM для Delphi ...)
1) Уже 2 голоса за переводы Delphi Spring.
Удалить2) Статья о своей ORM - будет полезна скорее как простенький пример использования RTTI в Delphi для маппинга датасетов на объекты. Сначала пробовал найти что-то готовое, но не нашёл/не разобрался. Так что сравнение ORM я не потяну. =)
Хотя тут совсем недавно появилось пара библиотек: Тот же DORM. И TMS недавно выпустили какой-то свой ORM: TMS Aurelius.
В порядке убывания значимости:
ОтветитьУдалить1) Обзор скриптовых движков, в т.ч. для форм. Недавно появился Lua4Delphi Simon Stuart http://www.simonjstuart.com/2012/01/20/lua4delphi-implementation-samples-part-1/
2) Компиляция сторонних библиотек и переход на юникод
3) Dependency Injection и Delphi Spring http://www.nickhodges.com/page/Dependency-Injection-Series.aspx
4) ORM на Delphi RTTI
5) Статический анализ Delphi кода
До билд-машины пока не доросли, пожалуйста, не обижайтесь :)
Отрадно знать, что она есть и развивается, но пока командная разработка буксует.
Да, уловить бы разницу между Live Bindings и ORM.
УдалитьПрокомментирую. А то я себя чувствую как человек, который написал "А хотите я вам расскажу про то использовать физику в своих программах", планируя рассказать про ускорения, а в ответ получает комментарий "Да, и покажи как использовать торсионные поля, заодно". =))
Удалить1) О скриптовых движках. Я думал написать о тех, которые рассматривал сам в качестве замены Dream VCL пару лет назад. Т.е. это может быть краткий обзор Dream Scripter, TMS Scripter PRO, и отдельный дизайнер типа JVCL Form Designer или EControl Form Designer + отдельно скриптовые дивжки Fast Script, PaxCompiler + рассмотреть вариант своей реализации дизайнера форм (на базе стандартного МСД-ного IDesigner). Lua4Delphi или использование Windows Scripting я даже не рассматривал.
Насчёт билд-машины и командной разработки: там суть не в командной работе. Идея в том, чтобы проект всегда собирался с одними и теми же настройками (в последних Delphi эта проблема частично решается с помоomю Build Configurations, а вот в ранних версиях, такой штуки не было), чтобы не было такого, что в релизный билд частично собирается из .dcu-шек собранных с разными опциями: часть с оптимизацией, часть без, часть с отладочной информацией, часть без неё и т.п.
Ну и другой Lazy Delphi бонус - это быстрая установка в Delphi из исходников больших наборов компонентов.
> Да, уловить бы разницу между Live Bindings и ORM.
УдалитьНасчёт Live Bindings верна аналогия насчёт физики. Я с ними не работал и не разбирался. Сорри. =)
Написать программку для извлечения метаданных и данных БД Firebird - такая уже есть EMS DB Extractor (стоит всего 1500 руб). Так что не очень интересно. А так в порядке интереса:
ОтветитьУдалить1. Статья: Компиляция сторонних библиотек. Подводные камни. И почему этот процесс нельзя унифицировать.
2. Обзоры JVCL. Там много чего интересного. Периодически нахожу новые фишки.
3. Lazy Delphi Builder
3. Продолжение перевода серии про Dependency Injection и Delphi Spring.
4. Скриптовые движки и дизайнеров форм для Delphi
5. Статический анализ Delphi кода.
--
Почему остальные неинтересны и поэтому не включил:
* cnWizard - пользуюемся, в принципе все и так понятно.
* замена DbGird - аналог Devexpress не найдешь. А на них я сижу давно, и ухудшать дизайн приложения нет никакого желания.
* процесс ведения проектов - Наладал работу в своей компании на Redmine (8-15 разработчиков + тестировщики и внешние пользователи) + SVN. На текущий момент 16 000 Redmine Issue и 13 000 коммитов на основном репозитарии. Тривиальная статья мне будет просто неинтересна.
--
В целом так держать!
Спасибо за развёрнутый комментарий.
УдалитьEMS DB Extractor посмотрел, спасибо. Не совсем то что надо. Метаданные из FB можно извлечь и через isql. На форумах народ говорит, что и IbExpert как-то умеет извлекать метаданные в отдельные файлы (ibeblock).
У меня же идея в том, чтобы извлекать метаданные и опционально (данные) для хранения в SVN. Чтобы удобнее было просматривать историю изменений базы.
В идеале, чтобы покрыть сценарий, когда БД переодически меняют разные люди и можно было удобно посмотреть, что же именно они там наменяли. В принципе это легко реализовать с помощью батника запускающего isql для извлечения данных и после выполняющего svn commit для изменённого файла. Но кроме этого хочется удобств и плюшек. =)
Уточнение:
> замена DbGird - аналог Devexpress не найдешь
Тут речь не о VCL, а о Firemonkey. И идея не в том, чтобы найти замену DevEx-ам, а в том, чтобы посмотреть как можно приспособить Firemonkey + LiveBindings для замены DbAware контролов (гридов). Это то, что мне самому интересно узнать.
>Наладал работу в своей компании на Redmine (8-15 разработчиков + тестировщики и внешние пользователи) + SVN.
А можешь рассказать подробнее как там и что?
1) Мне вот интересно, разделяете ли вы в Redmine на отдельные проекты библиотеку кода/компонентов, сам проект, документацию, БД?
2) Ведёте ли Wiki. Если да, то в каждом проекте своя Wiki или одна общая?
3) Есть ли чисто организационные проекты (типа План, FAQ)?
4) Используете ли версии в Redmine (для RoadMap). Создаёте ли для каждого билда свою версию? Если да, то как живёте с таким огромным количеством версий?
5) Перед коммитом DFM-ок, убираете ли "случайные" изменения, типа случайного изменения ширины формы и контролов или позиции формы т.п.
Если не лень, то было бы здорово рассказать это в виде поста. Я с большим удовольствием его опубликую, или сделаю на него ссылку.
Поделюсь своим опытом по редмайн. Сначала немного о специфике работы.
УдалитьЗанимаемся сопровождением и разработкой и доработкой медицинских системм.
Есть ряд крупных заказчиков (500- 1200 актвных ползователй на объетке за день) , анализаторы, датчики, терминалы, записиь через инет, сопряжение со сторонними ситемами и т.п.
Заказчики работают крглосуточно, остановки БД недоспустимы, поэтому обновления приходится делать "осторожно".
Для каждого из закачика сделан свой проект на Redmine, куда имеют доступ представители заказчика и инженеры по споровождению от нас.
Есть внутренний проект - по системе в целом, и подпроекты по крупным заказчикам.
На внутренние проекты редмайна имеют доступ программисты.
Задача инженера по споровождению переносить тикеты на внутренний (со связкой).
На внутреннем редмайне, каждый день, прогарммисты списывают затарченное время (есть плугин для редмайна - сводная талблица затраченного времени).
Задача руководителя контроллировать отчеты о затраченном времени.
Разделить проекты на внутренний и внешний были вынуждены по следующим причинам:
- программисты своими комментариями в задачах вводили в ступор заказчиков :)
- далеко не всегда заказчику нужно показывать время потраченное по его задаче, отписки программистов и реальные работы.
Вообщем общение с заказчиким это вопрос политики.
Немного под себя подстроили статусы на редмайне. (К основным новая - назначена - решена - закрыта, есть пара нашаих специфичных)
Задачи редмайна:
- упорядочили решение проблем
- контроль времени разработчиков
- поиск по аналогичным проблемам (этакая база зананий)
Стараемся в задачах не мельчить.
Для планирования пользуемся полем "План", куда в определенном формате записываются метка (12-02 - означает что запланирована задача на февраль 2012 года).
Список используемых плугинов:
-Redmine Issue Control Panel plugin
-Redmine Light Box plugin
-Redmine Open Links In New Window plugin
-Redmine Project filtering plugin
-Timesheet Plugin
SVN живет отдельно.
УдалитьКоментарии к коммитам обязательны (стоит запрещающий скрипт). Существует соглашение по формату комментариев (версия exe, ссылка на номер Redmine)
Разработчики бывает шалят в комметриях. Помню даже попадали на башорг какие-то выдержки.
Проекты бывают переходят от одного человека к другому, но это скорее исключение чем правило.
Одно время работала система ночных сборок (консольный dcc32), с контролем варнингов, хинтов и успешной компиляции (велась статисика по по каждому разработчику).
Была возможность собратся проект прям из браузера (заодно и проверить компилиться проект, не забыли ли чего выложить).
Но к моему соожалению, была сейчас не работает.
Неавторизованные пользователи доступа к проектам Redmine не имеют?
УдалитьУ меня Redmine доступен только во внутренней сети. Почти всё можно делать без авторизации. Авторизация нужна только для удаления и доступа к исходникам. При открытии доступа снаружи придётся делать авторизацию обязательной даже для просмотра.
Проектов несколько и они фиксированные - по числу продуктов + несколько организационных проектов (администрирование, база знаний, документация).
> Разделить проекты на внутренний и внешний были вынуждены по следующим причинам:
> - программисты своими комментариями в задачах вводили в ступор заказчиков :)
> - далеко не всегда заказчику нужно показывать время потраченное по его задаче, отписки программистов и реальные работы.
Разумно. В обсуждении задачи с коллегами можно писать проще. А если все обсуждение ведётся на глазах у заказчика, тут уже надо думать что и как писать, а то ведь могут и превратно истолковать.
Я у себя поначалу добавил 2 новых статуса: "требуется тестирование" и "в работе". Как сейчас понимаю, можно было обойтись и без них.
Добавил 2 своих поля:
1) Клиент
2) Тэги - для упрощения поиска. Простой длинный текст.
Помимо bug, feature и support, добавил 2 типа задач: refactoring и idea.
Поля планирования дат используются редко, как и отчёт о потраченном времени. В последнее время всё чаще подумываю о том, что хорошо бы было спрятать поля due date, start date и estimated time, чтобы не пугать пользователей.
Из плагинов используем:
* WikiNg - расширение для Wiki
* Paste Screenshot from Clipboard
Задачи Redmine:
1) bug tracker
2) todo список
3) ведение документации
Что не очень нравится: поиск по Wiki. Чем больше там статей, тем сложнее найти нужную.
Чего не хватает:
1) экспорта всей Wiki/всех Issues в один PDF/Html файл.
2) более разумного поиска по Wiki
> Одно время работала система ночных сборок (консольный dcc32), с контролем варнингов, хинтов и успешной компиляции (велась статисика по по каждому разработчику).
Удалить> Была возможность собратся проект прям из браузера (заодно и проверить компилиться проект, не забыли ли чего выложить).
> Но к моему соожалению, была сейчас не работает.
Я у себя очень давно хочу настроить такую на отдельном серваке, но всё никак не могу выбить себе машину+лицензии для такого сервера.
Пробовал у себя локально настроить через Hudson/Jenkins запускающий Lazy Delphi Builder для сборки - работает нормально. Запуск сборки можно производить из броузера, можно по будильнику, а можно при обновлении SVN.
p.s. большое спасибо за развёрнутый рассказ.
УдалитьWiki есть - основана на медиавики. Встроенной в редмайне одно время пользовались, но уж очень она убога.
ОтветитьУдалитьсейчас 539 страниц, 238 статей. Использвется для внутренней документации, собрана информация по продуктам, заказчиками. особенностям установки, настройки и т.п. Например категории:
-Oracle
-Postgresql
-Delphi
-Subversion
-Технолгии компании
-Анализаторы
-Заказчики
-Проекты компании
- и т.п.
Для каждого продукта заводится своя категория.
А вот, как например,назватся статьи:
- Страница разработчика
- Delphi. Правила формления кода
- Репозитарий_SVN_Delphi._Регламент_использования
- Установка DELPHI и необходимых библиотек
- Алгоритм внедрения новых версий программных модулей
- Новая_авторизация
- Список внутренних БД. (они у нас частенько меняются)
- Страница тестировщика
- Все объекты внедрения
Для часто возникающих пролем в продукте есть странцица "Настройка и особенности"
Из основных плугинов подстветка синтаксиса, семантическая вики.
Используется семаническая вики.
Основная проблема - заставлять разработчиков и тетировщиков создовать статьи в вики, и следить за оформлением.
Админ наш кстати очень активно ей пользуется, - все знают что самая актуальная инфа всегда на медивики и его не достают глупыми вопросами.
Ну и новичками, первым делом даем познакомиться.
Доступ снаружи к медиавики запорлен, но в командировках и из дома всегда можно к ней обратиться.
Я использую встроенный в Redmine Wiki и вот недавно стал всё чаще сталкиваться с тем, что сложно найти нужную статью при большом количестве статей раскиданных по разным проектам. Особенно тяжело, если ищешь информацию наобум, не зная существует ли такая статья вообще.
Удалить> Неавторизованные пользователи доступа к проектам Redmine не имеют?
УдалитьНет. Мы работаем по договорам сопровождения, всем заказчикам предлагаем общение только через redmine.
> Я у себя поначалу добавил 2 новых статуса: "требуется тестирование" и "в работе". Как сейчас понимаю, можно было обойтись и без них.
"В работе" - статус хороший, но нужен только менеджеру, руководителю проекта. Если задачи небольшие, программисты просто не переводят в нужный статус.
Даже плугин ставили, в котором можно было перетаскивать задачи "текущая", "следующие". Но тогда менеджер по сопровождению не успевал ставить приоритеты по задачам всем программистам.
Проще на планерке обсудить приоритеты задач и начать их делать.
>Поля планирования дат используются редко, как и отчёт о потраченном времени.
А вот отчет о пораченном времени зря не используете. Очень полезная вещь. Нужно не линиться и в конце каждого дня уделять 10 минут на написание того что было сделано. У нас программисты тоже вначале ворчали,
а потом сами стали менеджеров тыкать в отчеты, чтобы вопросов не возникало почему у нас еще ничего не рабоатет. Также очень помогает разобраться в проблеме которым более года (т.к. программисты пишут техническую сторону в отчет о потраченном времени - типа добавил новый поля, )
Ну и вики в редмайне убога. В свое время я вел документацию на DokuWiki - уже после него на wiki в Redmine смотрел как только для самых коротких заметок, но когда разобрался в mediawiki + semantic был в полном восторге. Сложно освоить синтаксис шалонов, и динамических стрниц, но возможностей там на порядок больше.
Например у нас есть драйвера к анализаторм. Я в одном месте заполняю карточку анализатора и у меня автомтически информация попрадает на следующие страницы:
- общий список анализоторов
- на стрнице объекта появляется список установленных анализаторов на объекте
- на страце разработчика появляется информация о том что он делал этот анализатор.
При желании можно строить запросы по этим данным используя систаксис вики.
Вообщем рекомендую, но будет не просто.
--
За наводку на jenkins - спасибо, но к сожалению попробовать в ближаешее время не получится
В порядке интересности: Lazy Delphi Builder, Dependency Injection, Delphi Spring, Продолжение серии постов о переходе на юникод, JCL/JVCL.
ОтветитьУдалить