Мог Освободить преимущество Паскаля чего-то как Знаток Apache?

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

Freepascal has been working on a package system of its own in a cross between apt-get and freebsd ports style. (download source/build/install automatically), called fppkg. Однако работа остановилась. Узким местом являются люди, вкладывающие время, а не люди, желающие выбирать инструменты.

Что касается Maven, мне не нравятся вспомогательные инструменты, которые требуют установки огромных внешних сред выполнения. Это может быть хорошо для большого крупного приложения (например, Open Office), но не для служебной программы.

Я также предпочитаю инструмент, который разработан для реальности и рабочего процесса FPC. Инструменты документации, инструменты сборки, системы загрузки, системы тестов - все уже есть, просто нужен человек, который посвятит этому много времени, чтобы это произошло.

Некоторые типичные проблемы при внедрении новой технологии в проект как FPC , и почему он имеет тенденцию создавать свои собственные инструменты:

• необходимо обучить 20+ коммиттеров на неполной ставке.
• Единственный ОБЩИЙ язык программирования, который вы можете себе представить, - это Free Pascal. Даже внутреннюю работу Delphi нельзя считать само собой разумеющейся (многие коммиттеры пришли прямо к FPC или даже через TP или Mac Pascal)
  • Очевидно, что что-то с плагинами на другом языке раздражает.
• На втором месте скрипт Bash. (g) сделать третье, но уже намного меньше.
• Все серверы * nix-подобны (FreeBSD, OS X, Linux), но не все работают с Apache. (например, мое зеркало FreeBSD запускает XSHTTPD)
• кто-то наиболее знающий должен быть посвященным сопровождающим в течение длительного времени. Устранять проблемы, обновлять / выполнять миграции и т. Д. По очевидным причинам желательно более одного.
• основная проблема - это дистрибутивы Linux (и FreeBSD в меньшей степени), большинство разработчиков пакетов * nix не способны на большее, чем "./ configure; make; make install ", и его необходимо дополнить почти готовым репозиторием и вспомогательными файлами.
  • Распространяемая упаковка FPC / Lazarus всегда была важна и продолжает расти
  • Все дистрибутивы имеют свои собственные особые правила относительно метаданных, ограничений и того, как должны публиковаться источники. В частности, Debian / Ubuntu очень бюрократизирован и медлителен.
  • Большинству не нравятся сторонние программы автоматической установки поверх своих систем (так как они обходят их контроль зависимости)

Все это приводит к эффективной практике владения инструментами в Лучше всего работает Паскаль с минимальным количеством сценариев. Некоторые использованные инструменты:

• Gmake в основном используется для параметризации процесса сборки на уровне каталога, его преемник, fpcmake (на самом деле не производная make, несмотря на название), начался, но миграция еще не завершена.
• Латекс и преобразование латекса в HTML (tex4ht, но debian использует hevea) используются в создании документации (небиблиотечная документация)
• Сайт сообщества (сервер сообщества netscape, который использует сценарии TCL, сложный сервер приложений) был проблемой с самого начала, но особенно в последнее время с тех пор, как сопровождающий стал менее активным.
• Mantis был проблемой (особенно модуль электронной почты мог вывести из строя сервер из-за объема), но он был приведен в форму в ходе последовательных обновлений и тяжелой работы нескольких разработчиков lazarus. В настоящее время это достойная рабочая лошадка.
• lazarus.freepascal.org Форум PHPBB OTOH относительно безболезнен, поскольку многие молодые люди знают, как с этим бороться.
• То же самое и с подрывными версиями (хотя более продвинутая шкала требует некоторой настройки, не все глубоко разбираются в тонкостях отслеживания слияний)

Если бы кто-то действительно серьезно относился к Maven, я бы обычно спрашивал его:

• КРИТИЧНО исследовать использование этого проекта. Очень конкретно, с расписанием и оценками времени. Обзоры с высоты птичьего полета "все возможное" по сути бесполезны.
• Подумайте о будущем изменении используемых технологий. Каждая технология, в том числе и собственная, в конечном итоге заменяется в проектах старше 18 лет. Новая технология не должна затруднять или затруднять миграцию других компонентов инфраструктуры. Не существует новой технологии, которая положила бы конец всем новым технологиям.
• Составьте план перехода. Миграцию часто недооценивают и недооценивают.
• И, в конце концов, всегда возникает вопрос о 1000000 евро, Кто будет выполнять ежедневное обслуживание?

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