DOCBOOK WINDOWS
Что есть DocBook? Это просто исходный код вашей документации (или книги) в прямом смысле этого слова, который априори не зависит ни от платформы, ни от компилятора (правильнее трансформатора), ни от формата конечного результата. Потому что это простой текстовый файл с особой разметкой в стиле XML. Собственно, DocBook-ом и называется этот самый набор специальных тегов для разметки документов, а сам документ является самым настоящим XML-документом со всеми из этого вытекающими.
Важно, на мой взгляд то, что это простой текст, а следовательно он идеально подходит для постановки на учет в какую-нибудь систему управления версиями кода (рекламирую в качестве таковой – Git), что обеспечит максимально комфортную работу над исходным кодом документации коллективом разработчиков, в каком бы географическом месте последние ни находились. Также имеет место быть полная свобода в инструментарии для работы над файлами – от умолчательного блокнота или любимого FAR до текстового редактора среды разработки на одном из языков программирования или специализированного XML-редактора. Круглосуточно и всепогодно.
Как информацию для размышления привожу скомпилированный по материалам из Сети список положительных характеристик технологии DocBoook:
- Бесплатное распространение
- Поддержка принципа единого источника, унифицированное форматирование с разделением контента от дизайна
- Поддержка различных выходных форматов
- Нативная работа с системами контроля версий
- Профайлинг и гибкое управление контентом, например, создание различных версий документа для различных групп пользователей
- Поддержка документов больших объемов
- Модульность и возможность повторного использования текста
- Легкая модификация шаблонов выходных документов
- Перспективный внутренний формат (XML)
- Мощный набор стандартов (XSL)
С точки зрения разработчика, работа в DocBook ничем не отличается от процесса создания программы: также надо думать над архитектурой документации, также надо разбивать код на логические модули и физические файлы, также надо думать о возможных зависимостях в коде между файлами, также надо набирать текст… Схема работы с DocBook аналогична таковой при создании программ:
XML (source code) >> XSLT-processor (script.xsl) >> Output (pdf|rtf|html|chm...)
Установка DocBook в Windows своими руками:
- Скачать DocBook XML последней версии (docbook-5.x.zip) и распаковать в C:\DOCBOOK.
- Скачать XSLT Stylesheets последней версии (docbook-xsl-ns) и распаковать в C:\DOCBOOK\xsl-ns.
- Скачать XSLT Proc Binary последней версии (iconv, libxml2, libxslt, zlib) и распаковать (bin) в C:\DOCBOOK\xsltproc.
- Необходимо использовать online документацию или же загрузить себе offline вариант.
Ссылки:
ДЕЖА ВЮ
Все совпадения случайны (с), только и успел подумать я, падая под стол на странице 56 книги Джоэла про найм программистов:
Еще в 1999 году, до того как основать компанию Fog Creek Software, я увольнялся со своей работы в городе Джуно и прошел собеседование с кадровиком, которое обычно проводят со всеми увольняемыми. И тут я попал в ловушку, рассказав ему все, что было не так с управлением компанией. Мне было точно известно, что из-за этого я не получу ничего хорошего, а могу только пострадать, но, тем не менее, я это сделал, и главное, на что жаловался, – на стиль руководства “наскоками”. Видите ли, большую часть времени начальники оставляли людей в покое, чтобы те спокойно делали свою работу, но время от времени они вмешивались по мелочам, требуя сделать что-то именно так, как они говорят, и не иначе, а затем, не ожидая результатов этого фарса, довольно быстро переключались на мелочное руководство какой-то другой задачей. Например, я помню особенно надоедливые два-три дня, когда все, от моего начальника до генерального директора, занимались тем, что указывали мне, как именно вводятся данные в анкету при приеме на работу. У них не было опыта работы в качестве разработчиков пользовательских интерфейсов, и они уделили не слишком много времени на разговор со мной, чтобы понять, почему в том конкретном случае я все-таки был прав. Впрочем, дело здесь в том, что начальство просто “уперлось” в этом вопросе и даже не удосужилось выслушать мои доводы. Вывод, сделанный после разговора с генеральным директором, состоял в том, что не надо было болтать.
Обычно, если вы собираетесь нанимать способных людей, позвольте им применять свою квалификацию в работе. Начальники могут советовать, и это правильно, но им следует быть крайне осторожными, что бы их “совет” не воспринимался как команда, так как по любому конкретному техническому вопросу начальство, скорее всего, знает меньше, чем сотрудники “на передовой”, особенно если вы, как я уже сказал, нанимаете способных людей.
Разработчикам хочется, чтобы их нанимали за их квалификацию, относились к ним как к экспертам и разрешали принимать самостоятельные решения в рамках их собственного опыта.
Ссылки:
CODEBASE GIT HOSTING
Даешь распределенную систему контроля версий исходного кода!
Прошел год, как мы используем для коллективизации нашей офисной работы сервис Assembla, который предоставляет качественный SVN в купе с кучей сопутствующих прибамбасов по управлению проектами. Столько же времени в голове прорастало семя, посеянное из поста в одном из блогов, в котором утверждалось, что сам Линус Торвальдс называет дураками тех, кто использует SVN (ясен хуй, ведь он непосредственный автор Git). Как говорится, понял – не дурак, дурак бы не понял (с) и начал готовиться к переходу в Git…
Непонятная политика, которую начала проводить Assembla относительно ранее зарегистрированных пользователей, вынудила через год вспомнить о Git и тех возможностях, а главное их себестоимости (!), которые нам откроются при внедрении распределенной системы контроля за версиями кода для решения стоящих перед нами задач. Так как меня в первую очередь интересовали сервисы, предосталяющие закрытый доступ, то после некоторого субъективного анализа я остановился на британском Codebase. Для свободно распространяемого софта Github – вне конкуренции.
Codebase – это рельсовое приложение со всеми вытекающими, как по дизайну, так и по приципам работы. Регистрация требует минимум информации. Можно создавать проекты по числу, предоставляемым из выбранного вами плана работы с сервисом, дисковое пространство тарифицируется только местом, занимаемым репозиториями. Тикеты и прочий шлак, если я все правильно понял, не учитываются.
Codebase – это проект-ориентированная система. Каждый проект содержит неограниченное количество репозиториев, к каждому из которых может быть подключено неограниченное количество пользователей. Вы платите только за количество логических проектов и дисковое пространство. Пользователи подключаются элементарно – достаточно ввести их адрес электронной почты, с которого они зарегистрировались в системе самостоятельно. В каждом проекте также есть тикетная система, возможность проработки этапов (milestone-ов), которые в свою очередь деребанятся между версиями проекта, а рубильники и рубироиды будут рады Codebase Gem.
Все это есть радикальное отличие от Assembla, где один проект равен одному репозитарию и что хочешь, то и делай. Есть беспланый аккаунт на 1 проект и 20 метров дискового пространства. Первый месяц можно работать бесплатно для платных аккаунтов. Все хорошо, за исключением, что мне не нравится вот этот пидор, которого они рисуют:
Помолясь, начинаем подготовку к перемещению проектов из Assemla-SVN в Codebase-Git…
Ссылки:
DELPHI 2009, ТРУДНОСТИ ПЕРЕВОДА
В 2009 год шагнули тотальным переводом исходного кода всех проектов в CodeGear Delphi 2009. Теперь, через месяц после этого события, можно подвести некоторый итог и сообщить о багофичах, на которые пришлось нарваться уже в процессе.
Сам итог таков: все работает, редактор среды наконец-то перестал отличать русский текст в комментариях запредельными бросками курсора, новые возможности среды и языка уже давно пошли вход – все пребывают в радости или заставляют себя в ней быть 
На что хотелось бы обратить особое внимание:
- Файлы групп *.groupproj не подвергаются конвертации, поэтому все те, кто живет правильно и собирает проекты из командной строки при помощи msbuild.exe рискуют нарваться на неработоспособность, потому что старая строка $(MSBuildBinPath)\Borland.Group.Targets не будет заменена на новую $(BDS)\Bin\CodeGear.Group.Targets, ибо наконец-то файл целей находится вместе со средой, а не закидывается к msbuild, как раньше.
- Функция CreateProcess теперь вызывает по умолчанию CreateProcessW, которая имеет отличие от своей сестры CreateProcessA – параметр lpCommandLine не может быть константой (!) – возможно будет необходимость переписать места вызова первой с учетом этого.
- В 2009 исправили ошибку в TCategoryButtons, которая заключалась в том, что если к кнопке был присоединен TAction, то происходил вызов его события OnExecute, а не метода Execute (!) – оказывается у нас существовал сам того не ведая код, который перестал работать из-за этого в 2009.
Следующий шаг – предстоит сделать важный переход из Subversion в Git и изменить психологию разработки проектов с учетом возможностей распределенной системы контроля версий исходного кода.
Ссылки:
ИЗМЕНА ТОЧКИ ЗРЕНИЯ
Иногда, только посмотрев глазами пользователя на возникшую проблему, можно определить ее настоящую причину…
Ссылки:
- А ссылок на сегодня нет…
ДВЕ БОЛЬШИЕ РАЗНИЦЫ
На рисунке отчетливо видна пропасть между образом жизни мышления этих двух замечательных людей:
Ссылки:
ДИЗАЙН ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА 2
Планируйте как можно меньше, начинайте проектировать интерфейс как можно раньше, зато переделывайте почаще.
Влад В. Головач опубликовал свою вторую электронную книгу о дизайне пользовательских интерфейсов. “Перманентная переделка” – это по-нашему. Автор достаточно хорошо разобрался в колбасных обрезках. Доходчивое изложение, простые и понятные примеры. Имеет смысл читать.
Ссылки:
GOOGLE CHROME
Они поняли. А ты хоть что-то из этого понял?
“Мы поняли, что нужно заново придумать браузер”, – таково откровение Сундара Пичаи, вице-президента компании Google по развитию программных продуктов, в своем блоге. Напомню, что когда-то они уже осуществили точно такой же подход к проблеме – по сути, “заново придумали” процесс (и внутри механизм) поиска в Интернет.
Хромой, как успел его уже окрестить народ, успешно вышел из стадии бета-тестирования и прямо движется к своей цели – в головы миллионов пользователей, которые хотят более удобно и проще, быстро и безопасно работать в сети Интернет.
Борьба за светлое будущее Интернет продолжается, а ее методы от компании Google достойны того, чтобы обратить на себя внимание простых смертных разработчиков с целью использования оных в своей повседневной работе. Зри в корень и делай проще.
Ссылки:
GRIDYZONE.COM
Новый сервис хостинга проектов с заявленной поддержкой закрытых проектов на русском языке. Налетай, пока еще бесплатно
Ссылки:
ASSEMBLA.COM 2.0
Бесплатный сыр бывает только в мышеловке.
С марта месяца сего года, когда я впервые зарегистрировался в теме, произошло следующее:
- Значительно улучшен/упрощен дизайн, еще более продуманы общие возможности платформы
- Заявленные 500 Мб на один репозитарий тихо превратились всего в 200 Мб, как для новых так и для уже работающих пользователей
- Бесплатные репозитарии угрожают быть насильно переведенными в состояние READ ONLY, если их владелец откажется платить $2.00 в месяц за каждого подключенного к репозитарию пользователя + $3.00 за 1 Гб пространства и не соизволит самостоятельно перевести первые в общедоступный режим
Не смотря на сомнительные деловые методы сервиса, а это зверское изменение правил игры по ходу оной для старых пользователей, я по-прежнему остаюсь его пользователем и даже намерен платить за свой личный репозитарий. Хотя, если меня в основе своей (для личных целей) интересует только закрытый хостинг с SVN, то можно поискать и других поставщиков аналогичных услуг.
Ссылки:
ЗАКОН МЕРФИ И ЕГО ПОСЛЕДСТВИЯ
Если какая-нибудь неприятность может произойти, она обязательно случится.
Следствия:
- Всё не так легко, как кажется
- Всякая работа требует больше времени, чем вы думаете
- Изо всех возможных неприятностей произойдёт именно та, ущерб от которой больше
- Если четыре причины возможных неприятностей заранее устранены, то всегда найдётся пятая
- Предоставленные сами себе, события имеют тенденцию развиваться от плохого к худшему
- Как только вы принимаетесь делать какую-то работу, находится другая, которую надо сделать ещё раньше
- Всякое решение плодит новые проблемы
Последствия:
- Да ебись оно все конем…
Ссылки:
ОБРАТНАЯ ПИРАМИДА ЛЕБЕДЕВА
Если хочешь сделать что-то хорошо – сделай это сам.
Существуют такие компании, для которых в процессе реализации задуманного, приходится постоянно испытывать давление в соотношении, проиллюстрированном в диаграмме:
Ссылки:
СОГЛАШЕНИЯ В КОДЕ DELPHI
Важно давать правильные имена и важно правильно оформлять исходный код.
Все без исключения программисты, которые приходят к нам работать, в той или иной степени имеют отклонения от стиля оформления исходного кода относительно исходного кода VCL. Приходится заставлять себя править консерваторию, потому что придерживаться стандартов всегда выгодно. Это первый пункт для начала работы в команде.
Ссылки:
КАЧЕСТВО ГДЕ-ТО ВНУТРИ
Качество – есть часть самого человека.
Возьмем к рассмотрению разработку программного обеспечения в компании. Топ менеджменту хочется качества и надолго, хочется это сделать всегда за дешево, а идеально совсем за бесплатно. А делать-то его кто будет? Ага, правильно, Дед Мороз, сцуко. Но моя мысль совсем не про холивар, когда разработчик въебывает за троих, а денег ему платят неадекватно или, наоборот, нифига не делает и постоянно чего-то требует все больше и больше.
Мысль о том у меня, что качество – есть часть самого человека и никакими улучшениями условий и повышениями зарплат его кардинально не поднять у того, в котором сия сущность отсутствует. Без вопросов, что вышеперечисленные меры являются благоприятными условиями для произрастания качества, как культуры, но оно не зацветет никогда, если сам человек не будет оное культивировать в себе самостоятельным образом.
Ссылки:
КАЙДЗЕН – ЭТО ТОЖЕ НЕ ФАМИЛИЯ
Непрерывное усовершенствование является ключевым принципом для достижения абсолютного качества.
Есть такое слово и понятие ‘кайдзен’, которое для нас звучит почти как ‘банзай’. Еще до того, как оно мне попалось на глаза, спинным мозгом чувствовал, что всю разработку в проектах надо акцентировать на процесс, а не на результат.
Может показаться на первый взгляд полной ересью, но это работает. Результат происходит сам собой, о нем не надо как-то особенно заботиться. Но для такого фокуса нужны, если хотите, особенные люди, потому как кадры решают все. Эти люди должны разделять такую точку зрения на уровне своей консерватории.
Человек естественным образом должен разделять философию постоянного усовершенствования. По всей видимости, у японца это закодировано на уровне ДНК, в нашем же континууме полного распиздяйства тяжело отыскать таких людей. Отсюда и хуева гора разных методик управления людьми для реализации программных проектов…
А ведь все гениальное просто, например, гарантия качества Toyota прямо говорит что:
Ничто не является настолько хорошим, чтобы его нельзя было сделать лучше. Вот почему мы прилагаем все усилия для постоянного улучшения всего, что мы делаем. Это не девиз или изложение нашей цели, которое мы вешаем на стену и забываем про него. Это просто наш образ действия. У нас есть для него слово: ‘kaizen’ (кайдзен). Оно означает непрерывное усовершенствование и является ключевым принципом, которым мы руководствуемся для достижения абсолютного качества.
Эта приверженность к качеству дает бесспорный результат – результат, который улучшает качество вашей жизни. Мы знаем это, так как об этом свидетельствует большое количество голосов, которые вы постоянно отдаете Toyota в независимых исследованиях удовлетворенности покупателя. Для Toyota качество не является лишь обещанием – это наш образ жизни.
РЕФАКТОРИНГ – ЭТО НЕ ФАМИЛИЯ
Старайтесь постоянно следить за состоянием кода.
Сколько раз каждый из вас, участвуя в разработке программного обеспечения, мог слышать нечто подобное такому: “работает – не трогай” или “лучшее враг хорошего” и т.п.? А кто из вас сам такое любит постоянно приговаривать?
Итак, я не разделяю уже ставший, к моему сожалению, “классическим” принцип о том, что если что-то работает, то ничего не надо трогать. Вроде все здраво, однако, я бы хотел обратить внимание на следующее.
Если пристальнее рассмотреть этот постулат на фоне процессов разработки программного проекта, то моя практика показывает, что некоторые люди просто скрываются за ним, чтобы не делать продукт, который они производят, еще более лучшим, а в некоторых особо запущенных случаях это может быть прикрытием банальной лени и/или нежелания что-либо делать вообще и даже профессиональной некомпетентности в особо запущенных случаях.
По моим наблюдениям, очень все похоже на то, что все дело просто в сложившейся ментальности человеков, так как они ведут себя по этому вопросу одинаковым раздолбайским образом, как к корпоративному продукту, где они в наемниках, так и к своим собственным проектам, где они считают себя вольными ковбоями.
Практически всегда есть, что можно улучшить. И даже в том случае, если люди понимают это, они выкладывают свой последний козырь – на это у меня нет времени! Тогда я спрашиваю, а на разбор скопившегося говна в коде потом будет время?
Все считают свое время прямо сейчас, а это, как минимум, недальновидно с точки зрения жизненного цикла программного продукта. Сколько будет времени потрачено завтра предпочитается тупо не задумываться. И вот когда в один прекрасный день в программу начинает стучаться новая выгодная функциональность или какое другое улучшение, что мы слышим? От “это слишком долго”, до “это невозможно, проще переписать все с нуля”. Знакомо? Не обидно за бесцельно прожитые годы? (с)
Программы, которые мы с вами разрабатываем очень похожи на живые организмы. В том плане, что как и последние, если не будут внутри себя постоянно регенирировать живые клетки (код), то будут обречены на процессы старения, распада и в результате полное исчезновение с жестких дисков пользователей.
Мое решение: всегда надо стараться постоянно следить за состоянием кода, начиная от его оформления согласно принятым соглашениям и заканчивая уничтожением зависимостей в нем. Если не знаете с чего начать рабочий день – начните его с проверки и последующим рефакторингом существующего кода!
В заключение, позволю себе процитировать Роберта К.Мартина из его книги “Быстрая разработка программ”. Слова в верхнем регистре выделены самим автором.
Настоятельно рекомендуется ВСЕГДА применять процедуру рефакторинга к КАЖДОМУ написанному разработчиком модулю, а также ко ВСЕМ сопровождаемым вами модулям. Затраты времени будут поистине смехотворными по сравнению с теми трудозатратами, которых избежите вы и ваши компаньоны в ближайшем будущем.
Целью рефакторинга является ежедневная “уборка” кода. Не следует допускать накопления беспорядка. Необходимо сохранить возможности для расширения и изменения системы с минимальными усилиями. Во главу угла всегда следует ставить цель, заключающуюся в обеспечении “чистоты” кода.
Автору, имеющему большой опыт работы в качестве программиста, надоели бесконечные стрессы. Все принципы и шаблоны, описанные в этой книге, превращаются в ничто, если код остается неупорядоченным. Поэтому прежде всего стремитесь к достижению “чистоты” исходного кода.
Ссылки:
ОСНОВНОЙ ПОСТУЛАТ РАЗРАБОТКИ
Хочешь правильную систему – готовься к ее изменениям.
Обратил внимание, что со временем проекты, в которых мне приходится непосредственно участвовать, все больше трансформируются в механизм для возможных их будущих изменений. Как-то в одной внутренней дискуссии по вопросам методологии разработки пришлось защищать свою позицию таким образом:
Ясно сейчас и потом только следующее:
- Требования неизмеримы в пространстве, стремятся к абстрактности и еще имеют свойство меняться во времени
- Необходимо вырабатывать в себе методологию и средства для относительно успешного противодействия такому положению вещей в зависимости от ситуации (эволюционная теория Дарвина
Известное изречение “хочешь мира – готовься к войне” (с) в нашем понимании должно звучать как “хочешь хорошую систему – готовься к ее изменениям”
Поэтому меня нисколько не удивило то, что я потом прочитал у товарища Мартина, который в его книге “Быстрая разработка программ” буквально пишет следующее (выделено самим автором):
Один из основных постулатов разработки ПО: требования всегда изменяются. Не следует забывать о том, что самый непостоянный фактор почти во всех проектах разработки ПО – это требования. Требования находятся в состоянии постоянного изменения. Это факт, которым мы, разработчики, не должны пренебрегать! Мы живем в мире изменяющихся требований, поэтому наша задача состоит в том, чтобы гарантировать выживание наших программ в потоке изменений. Если проект программ разрушается из-за изменяющихся требований, значит, мы недостаточно проворны.
Что еще здесь добавить? Пуля дура, Мартин – молодец.
Ссылки:
ПРАВИЛО МАРТИНА-ТУПОЛЕВА
Неаккуратно написанная программа летать не будет.
Согласно Мартину, а также просто здравому смыслу, неаккуратно написанная программа приводит к значительному усложнению процесса технического сопровождения. А еще рассказывают, что однажды к Андрею Туполеву подошел молодой конструктор и показал свои чертежи нового самолета. Туполев едва взглянул на них и сказал: “Эта машина летать не будет”. “Почему? – удивился тот. – Я все просчитал – сопротивление, аэродинамику…” “Потому что она некрасивая”, – ответил Туполев.
Ссылки:
ASSEMBLA.COM
Настоятельно рекомендую обратить внимание на вебдванольный сервис (мегасервис) для объединения разработчиков правильным образом. Для каждого вашего репозитария (workspace-ы) вы получите такой перечень возможностей: Wiki, Flow, Team, Files, Alerts, Admin, Milestones, Chat, Scrum, Staffing, Images, Manager, Tickets, Trac/SVN.
До 500 Мб на один репозитарий бесплатно, а под одним логином вы можете сделать N таковых. В отличие от SourceForge хранение вашего кода по умолчанию приватно. Размер команды участников неограничен.
Наконец-то офисный код покидает пределы локальной сети и сливается в экстазе с личными наработками на основе единого пространства для разработки. Я уже там, всем привет!
Ссылки:
7 ПРИЗНАКОВ ПЛОХОГО ПРОЕКТА
С признаками плохого проекта по Мартину из его книги “Быстрая разработка программ” встречался каждый разработчик, но не каждый может действительно в должной мере противостоять этой зловещей семерке. Более того, даже сам Мартин не в силах на все сто противостоять этой семикратной коррозии, которая пожирает строку исходного кода за строкой, проект за проектом. К сожалению, это вопрос лишь времени.
Вот, что неизбежно в той или иной степени ожидает проект на оси времени (выделено автором):
- Закрепощенность: система с трудом поддается изменениям, поскольку любое минимальное изменение вызывает эффект “снежного кома”, затрагивающего другие компоненты системы.
- Неустойчивость: в результате осуществляемых изменений система разрушается в тех местах, которые не имеют прямого отношения к непосредственно изменяемому компоненту.
- Неподвижность: достаточно трудно разделить систему на компоненты, которые могли бы повтроно использоваться в других системах.
- Вязкость: сделать что-то правильно намного сложнее, чем выполнить какие-либо некорректные действия.
- Неоправданная сложность: проект включает инфраструктуру, применение которой не влечет непосредственной выгоды.
- Неоправданные повторения: проект содержит повторяющиеся стуктуры, которые могут унифицироваться с применением простой абстракции.
- Неопределенность: проект трудно читать и понимать, недостаточно четко выражено содержимое проекта.
Но у меня есть и хорошие новости. Мы можем упешно минимизировать вышеуказанные признаки и их последствия. Все в наших руках и все зависит от нас, ибо кадры решают все, а не Мартины со своими признаками. Для этого лишь надо заставлять себя постоянно аудировать исходный код проекта по этим признакам. Днем и ночью. При малейшем сомнении стараться выправить ситуацию.
Плохое имя у функции – вот так будет лучше. Криво написан цикл – уже переписал. Неправильно отформатирован текст процедуры – исправил. Неудачный заголовок – новый лучше. Пакет зависит от другого – подумал как надо и устранил зависимость. Хотелось бы использовать вот такой вот компонент, но он в библиотеке, в которой три сотни компонентов – отказался от его использования вообще! И так далее…
Но самое главное на мой взгляд – априори думать о предстоящих в проекте изменениях, а не о требуемой функциональности на текущий момент.
Ссылки:
GETTING REAL
Все, кому не лень, уже давно сообщили о русском переводе главной концептуальной книги компании 37signals. Я его напрямую использую в качестве учебного пособия для новых программистов и тестировщиков, приходящих к нам в проект, как демонстрацию основных философских подходов, которые мной в той или иной степени разделяемы на данный момент.
У дураков мысли сходятся (с)
Ссылки:
DELPHIFEEDS.COM
Откройте свой Google Reader и подпишитесь на один единственный RSS-канал для всех Delphi новостей вместе взятых. Enjoy!
Ссылки:
БИТВА ИНТЕРФЕЙСОВ
Когда-то разработчики выбирали для концептов своих приложений между однодокументным и многодокументным типом интерфейса в парадигме от MS, а теперь в Википедии их таких выделяется аж четыре вида: SDI (Single document interface), MDI (Multiple document interface), TDI (Tabbed document interface) и IDE (IDE-style interface).
Как и все явления в этом мире, каждый из этих типов имеет свои преимущества и недостатки относительно других и в основном применяется для решения определенного круга задач. Следовательно, каждый разработчик с учетом первых и последних в праве выбирать под конкретную задачу любой из этих четырех.
За себя скажу: предпочитаю простую схему TDI.
Ссылки:
DELPHI DISTILLER
Есть шанс избавиться в исходниках своих новых Delphi проектов от папок __history, файлов с расширениями .local, которые теперь надо еще не забыть включать в список игнорируемых системами ревизий кода, вернуть нормальный вид тулбаров в среде вместо градиентно-гламурно-педерастических (ужоснах), а также простым образом решить еще несколько проблем, включая продление срока службы ознакомительной версии версии под вашу, ессно, отвественность.
Ссылки:
