[Наброс] Почему нам так нравится разрабатывать фреймворки и платформы? - Философия программирования

Здравствуйте, vdimas, Вы писали:

V>Просто весь этот WiX, которым тычут как адовым адом — это как ассемблер. Но отсюда некоторые горячие головы делают далеко идущие выводы.

Про WiX тут ни слова не сказалось еще, это своя отдельная песня.

V>А если рассмотреть отношения внутри самой базы MSI — там не так уж много таблиц (в сравнении со средней прикладной базой), я не вижу особой сложности изучить её тем, кто делает инструментарий под MSI. Любые рассуждения о сложности отношений внутри пакета MSI — натуральный детсад. У нас с этим разбирались даже вчерашние студенты.

Сама по себе идея декларативного описания целевого состояния системы вполне имеет право на жизнь. "Слышь, Windows Installer, сделай так, чтобы вот тут появилась папка с файлами, необходимыми для того, чтобы работали выбранные пользователем Feature'ы, чтобы в реестре были вот такие ключи и в меню Start появились вот эти ярлыки. Как ты этого добьешься -- мне не интересно".

Идея, повторюсь, здравая. Но вот реализация подвела.

Индусы-астронавты, которым поручили написать установщик для Офиса, нашли новый энтерпрайз-молоток: COM Structured Storage и кровного брата его, Compound File. И решили они сочинить на этой почве подобие БД, да не абы какое, а Column-Oriented, чтоб с подвыподвертом. И все заверте...

Установщик должен делать что? Правильно, устанавливать. А что ему надо устанавливать? О, это вопрос очень сложный и к нему надо подойти ответственно. Значицца, сначала надо перекопать весь реестр на предмет наличия предыдущих версий, затем запустить процесс File Costing'а, чтобы покомпонентно понять, сколько же места займет неведомое нечто, только потом спросить у пользователя, что и куда он будет устанавливать, потом еще похрустеть шпинделями, выполняя совершенно логично именованные Custom Action Type 35, 36, 37 и 38, подготовить скрипт и торжественно его накатить. В пылу совершенно забыли о зависимостях, ну да с кем не бывает.

Всю информацию для выполнения этих священных пассов архитекторы в мудрости своей решили растолкать по таблицам, структуру и имена которым придумывал самый экономный индус: CCPSearch, CompLocator, DrLocator, SFPCatalog. Поведение задавалось декларативно.

Как уже стало понятно из емкого названия "DrLocator", каждый байт был на счету. Поэтому придумали Install-On-Demand (потому что без этого инсталлятор получался слишком понятным, недостаточно сложным и там было слишком мало ошибок), патчи, Merge Module'ы и прочие захватывающие вещи.

После того, как достаточно хорошо запутали сам процесс установки, настало время переходить к UI.

Вместо того, чтобы хранить описание пользовательского интерфейса в, например Resource-файлах, для которых уже есть нормальные существующие редакторы (или в XML; энтерпрайз же), его решили хранить в таблице. А поскольку у них не Монго какое-нибудь, а настоящая база данных, то для каждого типа элемента управления запилили свою таблицу: Dialog, Control, Checkbox, RadioButton, ListBox, Billboard, BBControl, ListView и т.д.

А потом выяснилось, что кнопочки-то надо включать-отключать в зависимости от внешних пендалей, и появилась таблица ControlCondition, где на птичьем языке Condition Statement'ов декларативно, черт побери, задаются всяческие условия.

Почетное право Condition Statement'ы доверили какому-то укурку, потому что тот ад, который творится и в синтаксисе, и в семантике, ничем иным объяснить нельзя.

Затем стало понятно, что нажатие на кнопочки должно к чему-то осязаемому приводить, и придумали декларативную подписку на события, где в экстазе сошлись Condition Statement'ы вида "(OutOfDiskSpace = 1 AND OutOfNoRbDiskSpace = 1) OR (OutOfDiskSpace = 1 AND PROMPTROLLBACKCOST="F")" и гигантский список событий, доступный не абы как, а с различными оговорками. Чтобы все это вместе связать пришлось синей изолентой прикрутить декларативную же этих событий публикацию.

Чтобы все это сооружение из говна и палок не рассыпалось под собственным весом, были сочинены сто с лишним ICE-проверок, потому что а ну как же иначе?

И вот эту священную корову и выкатили на потеху публике.

"Что делают программисты, когда собираются вместе? Правильно — пишут фреймворк"
(с) Волков, Танки Онлайн, неточная цитата.

Я неоднократно видел одну и ту же ситуацию — вместо разработки решения для конкретной бизнес-задачи команда начинает пилить обобщенное техническое решение, платформу или каркас. Обычно это подается под соусом снижения затрат на будущие разработки, дескать, сейчас "наработаем технологию" (или даже "наработаем архитектуру"), а потом на ее основе за три дня слепим конечный продукт. А потом и еще десяток, если надо будет.

Я лично участвовал в пяти проектах, которые развивались по этой схеме. Вот результаты:
1. Три полностью провалились (т.е. были отменены после того, как сожрали изрядно денег и не дали никакого полезного результата).
2. Один еле вытащили до состояния shippable-продукта (т.е. все обещанные плюшки от разработки платформы пошли лесом, оставив переусложненную и нестабильную кодовую базу, в которую были зарыты крупные деньги).
3. Один, участником которого я являюсь сейчас, так же борется за жизнь, но есть сильный риск того, что он повторит первый или второй сценарий.
Про случаи, о которых я знаю по наслышке, я рассказывать не буду, но их ещё больше.

"Тенденция, однако" (с)

Моя скромная гипотеза, объясняющая этот феномен, состоит в том, что типичным технарям просто психологически комфортнее делать технологию, а не конечный продукт, обладающий business-value. Разработчики — эгоцентристы, им некомфортно влезать в шкуру пользователя, учиться смотреть на мир его глазами, понимать его проблемы, получать от него негативный фидбек. Им гораздо проще и интересное заниматься технологией ради нее самой, потому что там не надо выходить из своей зоны комфорта. Технология делается не для пользователей, а для самих себя (или же других разработчиков), так что можно обойтись привычной картиной мира критериями оценки результата, да и общаться с потребителем проще.

Поэтому, они стараются максимально оттянуть тот момент, когда им потребуется решать реальные проблемы клиента. Но, делать что-то надо, вот и появляется такая уловка — мол, клиентскими проблемами мы займемся завтра, а сейчас мы подготовим для этого солидную техническую базу. Истинная цель этой стратегии — оправдать в своих глазах и в глазах руководства замыкание в своей зоне комфорта, изолированной от реальных целей проекта, продиктованных бизнесом. Получить возможность избежать неприятных коммуникаций о бизнес-проблеме и принятия решений, основанных не на привычных критериях (техническое совершенство), а на чуждых среднему разработчику критериях бизнеса. То же самое, в миниатюре, можно видеть, когда при обсуждении трудного и неоднозначного вопроса проектирования, команда дружно и с улыбкой решает "заложить гибкость", вместо того, чтобы разобраться в проблеме и выбрать оптимальный вариант.

Я не говорю, что фреймворки и платформы — это зло и их не надо разрабатывать в принципе. Есть ситуации, когда такой подход к разработке полностью оправдан. Но ни в одном из упомянутых мною пяти проектов не было сделано никакого серьёзного анализа для выбора стратегии разработки. Все оправдания для выбранного пути сводились к чисто устному "бла-бла-бла, снижение затртат, бла-бла-бла". Никто не посчитал, насколько затраты снизятся, никто не посчитал ни одной цифры, не провёл анализ рисков такого подхода и т.п.

Зло, о котором я говорю — это именно такой подход, а не результат.

Вообщем, наброс сделан, жду ваших мнений

Здравствуйте, 0x7be, Вы писали:
0>Я неоднократно видел одну и ту же ситуацию — вместо разработки решения для конкретной бизнес-задачи команда начинает пилить обобщенное техническое решение, платформу или каркас. Обычно это подается под соусом снижения затрат на будущие разработки, дескать, сейчас "наработаем технологию" (или даже "наработаем архитектуру"), а потом на ее основе за три дня слепим конечный продукт. А потом и еще десяток, если надо будет.
Была такая тема некоторое время назад — что все ошибки проектирования — это результат каких-то фобий.
То есть, к примеру, программист Паша однажды обжогся на том, что его программа численного моделирования работала медленно. Он потратил три месяца на то, чтобы разобраться в том, как устроен компьютер внутри, и с ужасом обнаружил, что Borland C++ 3.01 при target CPU = Blend генерирует совершенно отвратительный код с плавающей запятой. Если сравнивать его с вручную выпиленным ассемблером, заточенным под SSE3.
С тех пор прошло 25 лет, но Паша по прежнему не доверяет компиляторам без директивы asm.

Программист Валера однажды обжогся на том, что студенты первые четыре месяца лабораторного практикума борются с тем, чтобы заставить компилироваться Hello World на языке C. А потом за оставшиеся три дня им нужно сдать десять лабораторок для получения допуска к экзамену. С тех пор прошло 25 лет, среды разработки стали гораздо умнее, но Валера по-прежнему считает, что ручной набор — корень всех зол, и продолжает мечтать о среде графического проектирования синтаксических деревьев.

А программист Дима однажды обжогся на том, что его чудо-программа всё время находится в 1 шаге от успешного запуска у заказчика, и всё время мешаются какие-то мелочи. То винда у заказчика находится не на диске С:\; то надо кнопку "Выход" переименовать в "Завершение сеанса", то ещё что. И Дима, устав ездить обратно к машине с компилятором, уже 25 лет пилит приложение, которое можно полностью переконфигурировать без компиляции, путём простой правки строчек данных в таблицах. При условии, что база с именем project1 лежит в в дефолтном инстансе SQL Server, задеплоенном на текущей машине.
(Если Дима в детстве начинал работать не на ФоксПро, то вместо базы будет набор конфиг-файлов).
В итоге Дима получает ещё один Тьюринг-полный язык программирования для "конфигурирования приложения". Теперь ему надо чинить баги не только в самой программе, но и в "конфигурации", объем которой вскоре начинает превышать объем исходников "платформы" (если Дима начал до 2000х) или "фреймворка" (если Дима начал после 2000).
Пример проекта, который преодолел испытание "реляционной конфигурируемостью" и был сквозь зубовный скрежет навязан целевой аудитории, каждый может наблюдать в лице Windows Installer. Это как бы показывает, что overarchitecting не является специализацией провинциальных кулибиных, а запросто может процветать и в корпоративном секторе.

Здравствуйте, vdimas, Вы писали:

V>Да че за бред-то???
V>Есть некий АПИ инсталлера, а есть к нему "движок", в котором можно закодировать вызовы этого АПИ декларативным способом. Классика декларативного подхода — описание зависимостей. Всё.
Я вот когда-то писал визуальную обёртку на Дельфи для MSI, которая позволяла делать простые инсталляторы. Ну то есть, чтобы тупо скопировать файлы, создать иконки на рабочем столе и, возможно, файловые ассоциации.

Это был АДЪ.

Через пару лет я ещё пытался сделать инсталлятор для промышленной утиллиты, которая ставила драйвера и в которой нужно было на этапе установки проверить наличие и лицензированность железки. Ну и там были мелочи типа зависимости от Embedded MSSQL (или как он там называется).

Это был АДЪ^3.

V>Ну и изначально расчет был на высокоуровневый инструментарий и этого инструментария хватает, удобного. Другое дело, что он платный. Дык, это другая тема уже.
Нету вообще никакого нормального инструментария, хотя за стоштукобаксов. СОВСЕМ.

При том, что на вражеских платформах типа Линукса это же делается без особых проблем.

Здравствуйте, Artifact, Вы писали:

A>Здравствуйте, 0x7be, Вы писали:

0>>Я не говорю, что фреймворки и платформы — это зло и их не надо разрабатывать в принципе.
A>У вас была одна проблема. Для её разработки вы решили сделать/использовать платформу/фреймворк — теперь у вас две проблемы

А потому что не надо "брать и делать фреймворк". Фреймворк должен появляться постепенно как результат ежеминутного рефакторинга существующего работающего кода.

Здравствуйте, Sinclair, Вы писали:

S>Пример проекта, который преодолел испытание "реляционной конфигурируемостью" и был сквозь зубовный скрежет навязан целевой аудитории, каждый может наблюдать в лице Windows Installer. Это как бы показывает, что overarchitecting не является специализацией провинциальных кулибиных, а запросто может процветать и в корпоративном секторе.

Да че за бред-то???
Есть некий АПИ инсталлера, а есть к нему "движок", в котором можно закодировать вызовы этого АПИ декларативным способом. Классика декларативного подхода — описание зависимостей. Всё.

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

Здравствуйте, vdimas, Вы писали:

V>Прежде чем отвечать, тебе следовало бы ответить на самый первый вопрос того поста, на который ты отвечаешь. Само АПИ инсталлера очень удобное и очень последовательное. Движок проигрывания MSI-файлов можно рассматривать как надстройку.

То есть, ты хочешь сказать, что есть некие "альтернативные движки", которые хранят данные в каком-то своем чистом и непорочном формате, а какие-то розовые пони просто дергают функции MsiXXX?

Извини, но не поверю. Весь API MSI, во-первых, пронизан MSIHANDLE hInstall'ами и прочими LPCTSTR szProduct'ами, которые какбэ намекают на то, что кроме как с пакетами MSI все это добро работать не умеет, а, во-вторых, представляет собой такую же непродираемую кашу из висящих где-то там в эфире сессий, транзакций, хэндлов, текстовых названий Feature'ов и прочего хлама.

Здравствуйте, vdimas, Вы писали:

V>Это для любой более-менее большой программы так, при чем тут Линух?

При том, что в традиции Линукса "инсталляция" — это ровно копирование файлов + разрешение зависимостей. Всё остальное — "настройка". Это снижает планку требований к инсталлятору.

V>Смешно, ведь это выполняется утилитами и скриптами, входящими в состав пакета. Ты можешь позапускать их ручками при надобности. Всё это можно отнести к этапу конфигурирование/настройка. И это в ЛЮБОЙ ОС так.
Домашнее задание: сравнить функциональность инсталлятора MS SQL Server и пакета MySQL для дистрибутива по вашему выбору.

V>Обалденная новость! Вот теперь уже мне охота спросить — что ты знаешь об установке сервисов в других ОС? ))) Как ты вообще себе представляешь что-либо иное, если что-то куда-то необходимо прописать, зачастую в уже имеющийся конфиг (грубо говоря, аналог некоей ветки реестра)?
Я знаю, что ни в одной другой ОС архитекторам подсистемы деплоймента не пришло в голову засовывать информацию о продукте в реляционную БД. И, кстати, сама Microsoft везде, кроме десктопа, для деплоймента прекрасно обходится без аналогов MSI. Оказалось, что, скажем, дешевле разработать новый формат пакетов для плагинов Office 2013, чем допилить Windows Installer.

V>Ты уверен, что обсуждаешь то, что надо обсуждать?
Отож.

V>Может быть я ошибаюсь, но я не помню, чтобы SQL Server можно было установить через запуск какого-то отдельного пакета MSI. Последний раз плотно работал с 2003-м, мог запамятовать, но вроде бы запускается экзешник-программа установки, которая ставит как необходимые компоненты, так и конфигурирует/настраивает результат установки программы.
2003 версии SQL Server не существует. Конечно же, вы запускали екзешник — setup.exe, оболочку инсталляции. Её задача — выбрать нужные MSI файлы для запуска.

V>Ну и описанное — не реальный мир, а нелепые бока самого SQL Server, тупое наследие шестерки.
Прекратите позориться. В шестёрке, как и в семёрке, не было никаких инстансов вообще. Side-by-side режим появился только с 2000й версии.

V>Кароч, в кривой архитектуре инстансов MS SQL виноват MSI. Молодца!
К архитектуре инстансов MS SQL претензий нет. А вот в том, что команде SQL Server пришлось упасть и отжаться, чтобы втиснуть потребности продукта в кривую архитектуру WI, виновата исключительно кривая архитектура WI.

Здравствуйте, Sinclair, Вы писали:

S>Пример проекта, который преодолел испытание "реляционной конфигурируемостью" и был сквозь зубовный скрежет навязан целевой аудитории, каждый может наблюдать в лице Windows Installer.

Да, да, тысячу раз да! Я готов истоптать семь пар лаптей, но дойти-таки до Редмонда и с неизбывной русской тоской посмотреть в глаза тому индусу, который это чудо спроектировал.

CC>Ой ребе, не начинайте.
CC>Это работает и в обратную сторону: надо сделать какую нибудь простую штукенцию, но для этого надо создать фабрику фабрик синглтонов фабрик объектов, написать несколько XML, которые это всё описывают и с подвыподвертом это всё вызывать.
Это не "работает в обратную сторону, а просто "не работает". Вместо замены ручного труда на автомат — заменили на такой же ручной труд, только в другом месте. DRY-принцип как не соблюдался, так и не соблюдается. Можно пример "простой штукенции", для большей предметности?

Здравствуйте, Sinclair, Вы писали:

V>>Кста, вот причина этого бестолкового спора. В непонимании, что есть инсталляция ПО с т.з. ОС.
V>>Для ОС установка SQL-сервера — это установка, грубо говоря, бинарных файлов (и вспомогательных для их работы). Поэтому во время установки надо обыграть лишь существование различных бинарных версий сервера, а это прекрасно обыгрывается.
S>Это вы, наверное, с Linux перепутали. Для windows установка SQL-сервера — это, грубо говоря, установка бинарных файлов, прописывание большого количества данных в реестр, регистрация сервисов и их зависимостей,

Это для любой более-менее большой программы так, при чем тут Линух?

S>переаттач существующих баз данных, настройка w3c сервисов и правил windows firewall и много чего ещё.

Смешно, ведь это выполняется утилитами и скриптами, входящими в состав пакета. Ты можешь позапускать их ручками при надобности. Всё это можно отнести к этапу конфигурирование/настройка. И это в ЛЮБОЙ ОС так.

V>>Создание и удаление инстансов вовсе не требует переустановки бинарного образа программы SQL-сервака.
S>Неважно, чего она требует или не требует. "Установка бинарного образа" — это, простите, копирование файлов, и оно прекрасно делается при помощи шелл-команды copy.

Это даже в Линухах не делается простым copy.

Твоя попытка держать всех за идиотов превращает обсуждение в цирк.

S>А инсталлятор в windows обязан привести систему в рабочее состояние — т.е. сделать все те вещи, которые по-вашему делаются "после" инсталляции.

Обалденная новость! Вот теперь уже мне охота спросить — что ты знаешь об установке сервисов в других ОС? ))) Как ты вообще себе представляешь что-либо иное, если что-то куда-то необходимо прописать, зачастую в уже имеющийся конфиг (грубо говоря, аналог некоей ветки реестра)?

Ты уверен, что обсуждаешь то, что надо обсуждать?

V>>То бишь, по классике жанра это может быть сделано ПОСЛЕ инсталляции. Автоматом запустить утилиту конфигурирования инстансов сервака после его установки не сложно, ИМХО.
S>Добро пожаловать в реальный мир, Нео. В настоящем инсталляторе настоящего SQL Server (а не того, который вы себе смело вообразили) пришлось прятать 16 product keys, чтобы обеспечить возможность ставить/удалять инстансы независимо друг от друга.

Может быть я ошибаюсь, но я не помню, чтобы SQL Server можно было установить через запуск какого-то отдельного пакета MSI. Последний раз плотно работал с 2003-м, мог запамятовать, но вроде бы запускается экзешник-программа установки, которая ставит как необходимые компоненты, так и конфигурирует/настраивает результат установки программы.

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

Кароч, в кривой архитектуре инстансов MS SQL виноват MSI. Молодца!

(Зная твои манеры, если полезешь рассуждать в область регистрации windows service и прочие тривиально-решаемые вещи — пойдешь в игнор, без обид)

Здравствуйте, Sinclair, Вы писали:

V>> Можно лишь поспорить относительно отдельных таблиц и связей. Я соглашусь только с иронией по поводу представления UI, но блин, в сотый раз оговорюсь, что эта ирония бессмыслена изначально, бо с выходом самой первой версии инсталлера в его SDK был тул по визуальному редактированию и тестированию UI.
S>Тул здесь совершенно ни при чём. Речь о том, что негодна сама идея реляционного описания UI.

И опять и снова — не о том аргументируешь.
Это UI не надо рисовать ручками, поэтому его низкоуровневое представление абсолютно не принципиально.

S>Во-первых, это новый стандарт, требующий разработки отдельного тула, который стоит денег.

Тул идёт в SDK.

S>Во-вторых, этот стандарт сразу ещё более ограниченный, чем даже dialog templates, т.к. не допускает расширения.

Любое расширение означает некий "левый" работающий код. Я уже указывал, что это будет дыра в безопасности.

S>Хорошая платформа — это та, где для объём рукописного кода линеен относительно "площади поверхности".

Забудь про рукописность UI.

S>А в MSI для того, чтобы добавить на форму один контрол, не предусмотренный реляционной структурой, надо полностью отказаться от стандартного UI и воспроизводить и тестировать весь boilerplate руками.
S>С точки зрения пользователя такое решение — спорно. С точки зрения архитектуры — некомпететно.

Бла-бла-бла.
MSI создавался для установки продуктов офиса.
Там полно сложных сценариев и они все покрыты. Если тебе надо указать конкретный инстанс SQL-сервака, то под это дело заводится "символ", т.е. переменная и указывается как параметр, либо, если не указана, то можно дернуть CustomAction для демонстрации юзверю любого диалога. Например, в нашей инсталляхе диалоги были вообще нейтивные, а не дотнетные. Диалогов было несколько и с нетривиальной логикой — вот как раз для указания настроек сервака приложения, с возможностью проверки этих настроек. А для сервака приложений в инсталляхе — указать адрес/инстанс SQL-сервака.

Кароч, ВСЕ, ну т.е. вообще все приведённые тобой контр-примеры — это какой-то детский лепет, который у разработчика занимает не более рабочего дня.

А строить свой пост так, что в каждом абзаце сначала восклицать: "а вы ВООБЩЕ это в ГЛАЗА ВИДЕЛИ?" — это пффф... никогда такого не понимал.

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

V>>Аналогично языка представления зависимостей. Он полон в декларативном смысле в терминах ВСЕХ объектов, описываемых базой инсталлера. Поэтому, да, некие вещи, выходящие за рамки информации, оперируемой инсталлерами, в нем описать нереально. Но это и хорошо — иначе бы это была дыра в безопасности.
S>Вы сегодня решили побить рекорд плотности чуши на одно сообщение?

Во-во. ЧТД.
АргументЪ!

S>Включение custom action, которые выполняются под elevated privileges — это не дыра в безопасности, а описание в Condition "вещей, выходящих за рамки информации, оперируемой инсталлерами" — дыра? Поздравляю.

Спасибо.
Тут стоило включить воображение. Хакнуть на лету некий бинарный код custom action какого-нить полученнго из надёжного источника продукта — это сложно. А если добавить фичу описания ЛЮБЫХ проверок — то это будет некий язык программирования. Скриптовый, скорее всего. который еще и текст сможет исполнять, скорее всего. А ему подсунул что-то левое из окружения (например, перехват некоторых консольных команд) — и делай что хочешь из тех самых elevated privileges, под которыми бедный админ запустил инсталляху, полученную из надёжного источника.

V>>Мы используем Wise для чего-то уникального и только для совсем типовых пакетов — WiX, так что ничего сказать не могу. Последний раз, когда я пользовался InstallShield в 2003-м, он полностью удовлетворял всем моим нуждам.
S>Это много говорит о ваших нуждах.

Это много говорит о твоей внимательности. Я же предлагал уже решение для твоих проблем с установкой сервиса (у нас была такая же задача) — создаешь проект-заглушку в дотнете с установкой сервиса и перегоняешь полученный пакет в WiX. И вот как раз один из типовых кусков таким образом и нарисовался.

S>Кроме того, в 2003 вы запросто могли использовать InstallShield в режиме wrapper. Был у них такой подход одно время: их самопальный инсталлер тупо заворачивался в один transient компонент в MSI, который был, фактически, только запускальщиком инсталляции.

Ага, и это ты написал после обсуждения сценария установки сервиса в процессе инсталляхи. Прикольно. ))

V>>Я изучал подробно, но для чуть других целей — для целей генерирования скриптов автоматической установки софта.
S>В прошлый раз вы, помнится, "подробно изучали исходники SQL Server".

И?

S>На этот раз вы решили изучить устройство MSI, чтобы научиться писать скрипт, вызывающий msiexec.exe с нужными ключами? Похвально, похвально.

Зачем msiexec.exe? АПИ инсталлера полон, ты можешь сам написать утилиту-аналог msiexec.exe за пару вечеров под основные сценарии. Причем, эту утилиту можно написать на каком-нить скриптовом VBS.

V>>Нет, это ты спросил, как обойтись без ВСЕЙ "наркоманской" базы, я тебе подсказал. Тебе достаточно использовать ту её часть, где реляционное представление как нельзя к месту. Ну вот подыграл твоему "чувству прекрасного", не более того.
S>Ну, безо всей, как выясняется, обойтись нельзя.

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

Кароч, ты начал не оттуда. К стадии WiX надо было подходить только освоив все предыдущие стадии. Горе тому, кто пытается пользоваться инструментом под некую предметную область, не понимая самой предметной области. Обезъяна с гранатой, как грится.

S>Вы же в курсе, что если у ваших компонентов есть понятие версии, то без файлов обойтись никак не удастся? Или этот уровень подробностей остался за пределами вашего "подробного изучения"?

Во-во. Нубство как оно есть.

Компонентом может быть что угодно, например, запись в реестре или параметр, который достаётся через кастомную акцию.
Кароч, курить, что есть "компонент".
Понятно, что схватившись сразу за WiX вот эти базовые вещи MSI АПИ остались, как ты там попытался уколоть собеседника?

Или этот уровень подробностей остался за пределами вашего "подробного изучения"?

А ведь "компонент" — это ключевое понятие MSI. Вся остальная шелуха пляшет вокруг "компонента". ))

Версии надо присваивать продуктам, а не компонентам. Ну и все танцы вокруг т.н. "кода обновления" или уникального нового кода, чтобы разные версии жили одновременно, не мешая друг другу.

V>>Ну тогда опять и снова для особо одарённых — я подсказал простой способ получения достоверно работающего результата на имеющемся почти у всех девелоперов инструментарии. Это был ответ на "ай-ай, проблемы с custom actions". )))
S>Вы подсказали простой способ написать hello world. Спасибо, конечно, но этот этап я давно прошёл.

Дык, ты как раз и описывал сложности уровня "hello world", ругая при этом не свои руки, а инструмент. А теперь пытаешься сделать вид, что притворялся. Ты уж определись. ))

V>>Можно подробнее — в чем именно геморрой?
S>В том, чтобы написать custom action, который корректно отрабатывает все режимы.
S>Вы почитайте немножко вот здесь: http://msdn.microsoft.com/en-us/library/aa368070(v=vs.85).aspx

Это не ответ. Тем более это не ответ от тебя, т.к. если ты ручками MSI АПИ не дергал, то не тебе отсылать к доке по нему. ))
Попробуешь еще раз?
Итак, в чем именно геморрой?
Я же описал, как получить "скелет" для грамотно описанной custom actions. Понятное дело, что породить подобный скелет с 0-ля ручками — это застрелиться. А зачем ты так делаешь?

V>>Я понимаю для чего нужен WiX, но вижу непонимание у тебя. Этот DSL всё еще низкоуровневый, он плохо маскирует низлежащую платформу, поэтому пользоваться им напрямую для чего-то повторяемого — глупо.
S>Как раз им и пользуются. В MSI сделать повторно используемый custom action практически невозможно. А в WiX их дофига, и можно добавлять свои: http://wixtoolset.org/documentation/manual/v3/customactions/

Ну ясно. А строил из себя спеца. ))
Я как раз предлагал сваять скелет на MSI и перегнать его в WiX, вычленив необходимое.

Мне этот характер работ очень напоминал мои первые работы в вебе в начале 2000-х, когда только-только начал набирать обороты клиентский скриптинг. Я тогда тупо "тырил" скриптовые снипеты у понравившихся сайтов. Это было быстро и ненапряжно. ))

Аналогично с MSI — точно так тырил из третьесторонних пакетов MSI понравившуюся функциональность.

Пример про скелет установщика сервиса — это было просто пример такого подхода, ес-но.
Но ты намек не понял.

Здравствуйте, vdimas, Вы писали:

V>И опять и снова — не о том аргументируешь.
О, очередной приступ некрофилии?
V>Это UI не надо рисовать ручками, поэтому его низкоуровневое представление абсолютно не принципиально.
Ну конечно же надо. Дефолтный UI устраивает чуть меньше, чем никого. А механизмов расширения — упс, нету.
S>>Во-первых, это новый стандарт, требующий разработки отдельного тула, который стоит денег.
V>Тул идёт в SDK.
Если уж захотелось откопать мёртвую тему, потрудитесь ознакомиться с предметом дискуссии. Речь идёт о принятии архитектурных решений — на момент проектирования WI никакого SDK и тула не было.
Зато был тул для рисования Dialog Templates. То есть неизвестный нам архитектор спустил в унитаз значительный объём корпоративных ресурсов — без малейшей к тому причины.
Просто потому, что ему так захотелось.
V>Любое расширение означает некий "левый" работающий код. Я уже указывал, что это будет дыра в безопасности.
От повторения чуши она не становится более умной. В любом инсталлере есть дофига "левого" работаюшего кода, и никого это не беспокоит. Чем код UI хуже, чем код custom actions?
А если мы уж допустили чужой код в одном месте, то какой смысл запрещать его в другом?
Тем более, что код гуя, в отличие от кода custom actions, работает под ограниченными привилегиями текущего пользователя, а не в контексте сервиса windows installer.
V>Забудь про рукописность UI.
C чего это вдруг? Глаза откройте — 99% инсталляторов используют рукописный UI. То есть мы имеем мега-дорогой, переусложнённый, неудобный инструмент, который ещё и не покрывает потребности целевой аудитории.
Это даёт нам просто канонический пример архитектурного факапа.
V>Бла-бла-бла.
V>MSI создавался для установки продуктов офиса.
О, у вас появилась новая идея, как оправдать идиотскую точку зрения "windows installer архитектурно оправдан".
Вообще-то — нет. WI позиционировался как штатный инструмент для установки чего угодно.
Да, многие сценарии в нём были навязаны офисной командой. Но office team не диктовала, как реализовать всё это внутри. Можно было принимать любые архитектурные решения, а не только идиотские.

V>Там полно сложных сценариев и они все покрыты. Если тебе надо указать конкретный инстанс SQL-сервака, то под это дело заводится "символ", т.е. переменная и указывается как параметр, либо, если не указана, то можно дернуть CustomAction для демонстрации юзверю любого диалога.
То есть это уже не дыра в безопасности?
V>Например, в нашей инсталляхе диалоги были вообще нейтивные, а не дотнетные. Диалогов было несколько и с нетривиальной логикой — вот как раз для указания настроек сервака приложения, с возможностью проверки этих настроек. А для сервака приложений в инсталляхе — указать адрес/инстанс SQL-сервака.
Дело не в указании адреса/инстанса, а в том, что ломается весь механизм проверки наличия предыдущих версий софта — потому что их может быть одновременно много.
V>Кароч, ВСЕ, ну т.е. вообще все приведённые тобой контр-примеры — это какой-то детский лепет, который у разработчика занимает не более рабочего дня.
Это просто вы, как обычно, выступаете на незнакомую вам тему.
V>Не видел бы, не давал советов. Я ведь увидел еще тогда, что все советы прошли мимо уха не задерживаясь. Такое ощущение, что или я плохо объясняю, или кого-то совершенно не интересует обсуждаемый предмет, а интересует исключительно подвергнуть MSI обструкции любыми способами. ))
Вы не понимаете сути. Речь не о том, что убогость MSI нельзя обойти — конечно можно! Ведь продукты-то ставятся! Я разработчик — я вообще любую разрешимую проблему могу решить.
Мы сейчас обсуждаем не применение WI на практике — тем более, что с этой темой вы очень поверхностно знакомы. Мы обсуждаем архитектуру этого продукта. И если бы разработчики WI думали головой, а не тем местом, которым они думали, то этих "легко разрешимых" проблем бы не было вообще. Конечно, если убогая технология не позволяет мне подменять один контрол — то я перерисую весь диалог. Ну, будет это в 10 раз дороже — так я ж не бесплатно это делаю, зарплату получаю.
Ок, диалог плохо сочетается с остальными шагами визарда — давайте весь визард заменим на кастомный код. Ещё впятеро дороже получилось — но чего уж там, деньги-то не мои.

Вы посмотрите на это со стороны производителя — выброшены мега-деньги; кто-то сидел, ночей не спал, придумывая структуру табличек с контролами. Кто-то писал тул. QA гоняло всю эту чушь туда-сюда. Документация писалась и переводилась на разные языки. А на практике — нихрена это никому не помогает: всё уехало в помойку. Все, даже признанные знатоки MSI типа vdimas, пишут нативные диалоги вместо реляционного убожества.

V>Спасибо.
V>Тут стоило включить воображение. Хакнуть на лету некий бинарный код custom action какого-нить полученнго из надёжного источника продукта — это сложно. А если добавить фичу описания ЛЮБЫХ проверок — то это будет некий язык программирования. Скриптовый, скорее всего. который еще и текст сможет исполнять, скорее всего. А ему подсунул что-то левое из окружения (например, перехват некоторых консольных команд) — и делай что хочешь из тех самых elevated privileges, под которыми бедный админ запустил инсталляху, полученную из надёжного источника.
ОМГ. Вы сегодня положительно в ударе. А что вам мешает включить воображение и представить себе бинарный код, который запускает wscript.exe с перехватом некоторых консольных команд? Ну, если уж задача стоит упороться в дым?
А если вы думаете, что бинарный код так делать "просто не будет, потому что ему незачем", то, простите, и скрипт вычисления custom condition тоже "просто не будет".

V>Это много говорит о твоей внимательности. Я же предлагал уже решение для твоих проблем с установкой сервиса (у нас была такая же задача) — создаешь проект-заглушку в дотнете с установкой сервиса и перегоняешь полученный пакет в WiX. И вот как раз один из типовых кусков таким образом и нарисовался.
Речь не о моих проблемах. Я все свои проблемы с инсталляторами решил ещё до 2010 года. Речь о причинах, по которым эти проблемы возникли. В нормально спроектированной системе таких проблем быть не должно вообще, от слова совсем.
V>И?
И напороли такой чуши, что я работать не мог от смеха.
V>Зачем msiexec.exe? АПИ инсталлера полон, ты можешь сам написать утилиту-аналог msiexec.exe за пару вечеров под основные сценарии. Причем, эту утилиту можно написать на каком-нить скриптовом VBS.

Вы дома посмотрите, какой процесс у вас кушает CPU в процессе исполнения вызовов этого API.

V>Пока что выяснилось, что ты за деревьями не увидел леса. Выбрав в кач-ве основного фокуса приложения усилий WiX, ты не потратил должного времени на изучение структуры таблиц инсталляхи, на изучение COM-АПИ инсталлера, на понимание правил многократного разыменования референсов.
V>Кароч, ты начал не оттуда. К стадии WiX надо было подходить только освоив все предыдущие стадии. Горе тому, кто пытается пользоваться инструментом под некую предметную область, не понимая самой предметной области. Обезъяна с гранатой, как грится.
Опять мимо. WiX — это было последнее, к чему мы пришли. Наевшись и стандартного тулчейна, и купленного InstallShield, и ручного разбора с Orca, и всего остального.

V>Во-во. Нубство как оно есть.

V>Компонентом может быть что угодно, например, запись в реестре или параметр, который достаётся через кастомную акцию.
Садитесь, два.
V>Кароч, курить, что есть "компонент".
"Что угодно", my ass. Ну, покажите мне, как описать компонент, который имеет версию, определяемую через custom action, и никак не отражён в файловой системе. Что будем писать в KeyPath?

V>Версии надо присваивать продуктам, а не компонентам. Ну и все танцы вокруг т.н. "кода обновления" или уникального нового кода, чтобы разные версии жили одновременно, не мешая друг другу.
Это кто вам такое сказал?
S>>Вы почитайте немножко вот здесь: http://msdn.microsoft.com/en-us/library/aa368070(v=vs.85).aspx
V>Это не ответ. Тем более это не ответ от тебя, т.к. если ты ручками MSI АПИ не дергал, то не тебе отсылать к доке по нему. ))
Это не MSI API. Там про API ничего нету. Там рассказано, как писать custom action.

V>Я же описал, как получить "скелет" для грамотно описанной custom actions. Понятное дело, что породить подобный скелет с 0-ля ручками — это застрелиться. А зачем ты так делаешь?
Нет, ничего про скелет custom action написано не было. Кроме упоминания про многократное разыменование — это, надо полагать, единственное, что вы делали реально в инсталлере.

V>Я как раз предлагал сваять скелет на MSI и перегнать его в WiX, вычленив необходимое.
Вы путаете custom action со структурой пакета. "А строил из себя спеца." (TM)
Чтобы вы примерно поняли, о чём речь: допустим, один из компонентов вашего продукта — это служебный SSL сертификат, который ставится на backend-сайт. Ваша задача — описать custom action, который его поставит, если его не было, заменит, если он был, но старый, и не будет трогать, если он уже заменён на более новый. Под "ставится" мы подразумеваем регистрацию в IIS и активацию для соединений по порту 8443. При деинсталляции фичи, в которую входит этот компонент, нужно его снести. Какие шаги вы предпримете для написания custom action? Где вы возьмёте "скелет"?

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

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

Добавляем, выпрямляем, дальше используем.

Лучше сначала задачу решить и возможно не одну, а уже потом придумывать под это дело фреймворк.

Здравствуйте, 0x7be, Вы писали:

0>Я лично участвовал в пяти проектах, которые развивались по этой схеме.
Да мы с вами коллеги

0>"Тенденция, однако" (с)

Подтверждаю.

0>Я не говорю, что фреймворки и платформы — это зло и их не надо разрабатывать в принципе.
У вас была одна проблема. Для её разработки вы решили сделать/использовать платформу/фреймворк — теперь у вас две проблемы

0>Есть ситуации, когда такой подход к разработке полностью оправдан. Но ни в одном из упомянутых мною пяти проектов не было сделано никакого серьёзного анализа для выбора стратегии разработки. Все оправдания для выбранного пути сводились к чисто устному "бла-бла-бла, снижение затртат, бла-бла-бла". Никто не посчитал, насколько затраты снизятся, никто не посчитал ни одной цифры, не провёл анализ рисков такого подхода и т.п.
Собственно выделенное.

0>Зло, о котором я говорю — это именно такой подход, а не результат.
+100500

Ну, и как бы, вот https://medium.com/p/db854689243

Здравствуйте, Osaka, Вы писали:

O>Появляется, например, бизнес-задача поменять 1 слово в 100 похожих экранных форм. С фреймворком эта задача решается изменением 1 места в коде, а без фреймворка — долгим и внимательным ручным тиражированием этого изменения в 100 откопипастенных-с-изменениями мест, и последующим отловом ошибок, сделанных при тиражировании.

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

Здравствуйте, 0x7be, Вы писали:
0>

0>"Что делают программисты, когда собираются вместе? Правильно — пишут фреймворк"
0>(с) Волков, Танки Онлайн, неточная цитата.

0>Я неоднократно видел одну и ту же ситуацию — вместо разработки решения для конкретной бизнес-задачи команда начинает пилить обобщенное техническое решение, платформу или каркас. Обычно это подается под соусом снижения затрат на будущие разработки, дескать, сейчас "наработаем технологию" (или даже "наработаем архитектуру"), а потом на ее основе за три дня слепим конечный продукт. А потом и еще десяток, если надо будет.
0>Вообщем, наброс сделан, жду ваших мнений

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

0>технарям просто психологически комфортнее делать технологию, а не конечный продукт
Всё гораздо проще, программистам некомфортно делать бесполезную работу (которую можно автоматизировать и переложить на машину). Для кого эта разница в "написании кода за деньги" незаметна, тот, скорее всего, не программист, а простой клерк-делопроизводитель.
http://ru.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself
Появляется, например, бизнес-задача поменять 1 слово в 100 похожих экранных форм. С фреймворком эта задача решается изменением 1 места в коде, а без фреймворка — долгим и внимательным ручным тиражированием этого изменения в 100 откопипастенных-с-изменениями мест, и последующим отловом ошибок, сделанных при тиражировании.

0>Вообщем
"Нутыпонел".

Здравствуйте, Географ, Вы писали:

Г>Тем не менее, любое успешное решение, пережившее не одну версию, изначально создавалось на какой-либо платформе. Просто поток кода, склёпанный быстро, решает только одну задачу, на вторую его уже не согнуть.

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

Здравствуйте, Нахлобуч, Вы писали:

Прежде чем отвечать, тебе следовало бы ответить на самый первый вопрос того поста, на который ты отвечаешь. Само АПИ инсталлера очень удобное и очень последовательное. Движок проигрывания MSI-файлов можно рассматривать как надстройку. Что-то типа как XML описание UI для некоего UI-движка. Вполне можно писать самим или генерировать императивный скрипт. Некоторые инсталляторы используют свои собственные форматы мета-описания.

Здравствуйте, vdimas, Вы писали:

V>Да че за бред-то???
Спасибо за то, что вы, коллега, как обычно влезли в тему, в которой плохо разбираетесь.

V>Есть некий АПИ инсталлера,
Это вы, надо полагать, имеете в виду вот это: http://msdn.microsoft.com/en-us/library/aa369426(v=vs.85).aspx
V>а есть к нему "движок", в котором можно закодировать вызовы этого АПИ декларативным способом
Это вы, надо полагать, имеете в виду вот это: http://msdn.microsoft.com/en-us/library/aa369398(v=vs.85).aspx

V>Ну и изначально расчет был на высокоуровневый инструментарий и этого инструментария хватает, удобного. Другое дело, что он платный. Дык, это другая тема уже.
На какой "высокоуровневый инструментарий" вы намекаете? На WiX что ли? Или на Orca?

Весь "API инсталлера" — высокоуровневый, он полагается на содержимое базы данных. Рассматривать его в отрыве от MSI не имеет смысла.
А устройство базы данных является вполне наглядной иллюстрацией моего тезиса: авторы замахнулись на то, что прикладным программистам не нужно будет писать код инсталлятора (чтобы понять, что такое "код инсталлятора", можно посмотреть на более-менее старый InstallShield. Там пацаны ударились в другую крайность: в 2005 примерно году они на полном серьёзе предлагали писать цикл обработки очереди сообщений вручную), а достаточно будет просто "корректно заполнить таблички в базе".
Про то, что "заполнить таблички в базе" даже для примитивного случая CD-ejector представляет собой нетривиальную задачу, уже написал коллега Нахлобуч. Оказывается, что в таких случаях даже инсталлер на bat-файлах будет проще в разработке и поддержке.
А во всех остальных случаях разработчики вынуждены бороться с этой адовой наркоманией, чтобы заставить свои custom actions корректно работать. Вместо того, чтобы просто написать логику инсталляции на каком-нибудь приемлемом языке программирования.

Здравствуйте, Sinclair, Вы писали:

V>>Ну и изначально расчет был на высокоуровневый инструментарий и этого инструментария хватает, удобного. Другое дело, что он платный. Дык, это другая тема уже.
S>На какой "высокоуровневый инструментарий" вы намекаете? На WiX что ли? Или на Orca?

Любой, где можно накидать пакет мышкой, навроде InstallShield, Wise, VisualInstaller и т.д.
А так же компонент студии, который вернули в VS 2013.

S>Весь "API инсталлера" — высокоуровневый, он полагается на содержимое базы данных. Рассматривать его в отрыве от MSI не имеет смысла.

Имеет аж бегом.
Основная польза от MSI-АПИ в иерархии продукт -> компонент.
В автоматическом учете компонентов (счетчики), при пользовании ими из разных продуктов.
В транзакционности инсталляции.
В возможности инсталляции по-требованию.
В стандартизации основных сценариев инсталляции.
В учете сырцов-медиа инсталляций.
И т.д.

S>А устройство базы данных является вполне наглядной иллюстрацией моего тезиса: авторы замахнулись на то, что прикладным программистам не нужно будет писать код инсталлятора (чтобы понять, что такое "код инсталлятора", можно посмотреть на более-менее старый InstallShield. Там пацаны ударились в другую крайность: в 2005 примерно году они на полном серьёзе предлагали писать цикл обработки очереди сообщений вручную), а достаточно будет просто "корректно заполнить таблички в базе".

Еще раз для особо одаренных. Изначально был расчет на коммерческие приложения, где это, действительно, несложно. Уже в 7-й студии шли встроенные проекты-инсталлеры (урезанный вариант платного). До семерки были аналогичные платные плагины. Т.е. я вообще не понимаю, о чем тут заламывание рук, если еще в 2000-м году это было де-факто было элементарно на имеющемся инструментарии.

S>Про то, что "заполнить таблички в базе" даже для примитивного случая CD-ejector представляет собой нетривиальную задачу, уже написал коллега Нахлобуч.

Он фигню написал, ваще-то. Это как призывы писать программы на ассемблере. ))
Пишите, если нравится.
А если он из тех, кто разрабатывает эти самые VisualInstaller и Co, то он вас просто злобно троллит. Это не бог весь какая сложная область для написания инструментария к ней.

S>Оказывается, что в таких случаях даже инсталлер на bat-файлах будет проще в разработке и поддержке.
S>А во всех остальных случаях разработчики вынуждены бороться с этой адовой наркоманией, чтобы заставить свои custom actions корректно работать.

Мдее...
Опиши в MSI только продукты и компоненты. Не возись с файлами, зависимостями и прочей "наркоманией", если не хочешь.
Перехвати требуемые custom actions и пусть в них работают твои bat-скрипты.

Если у кого-то проблемы с руками и custom actions... блин, пусть создадут пустое приложение Windows Service на дотнете в студии, добавят к нему инсталлер сервиса, потом сделают пакет с ним и разберут получившийся MSI каким-нить просмотрщиком или экспортером в WiX. Это порядка 5-10 мин всех делов.

Это я к тому, что инсталлеры сервисов вызываются когда надо — можно бы один раз посмотреть, если уж тупик. Высосали проблему из пальца.

S>Вместо того, чтобы просто написать логику инсталляции на каком-нибудь приемлемом языке программирования.

Там не одна логика, а целый букет:
— инсталляция
— реинсталляция/восстановление
— инсталляция по-требованию
— деинсталляция
— добавить компонент
— убрать компонент
— собрать инфо о пользователе
— ...

"Просто описать логику" можно лишь по каждой отдельной строчке. Дык, опиши! Твоя задача будет лишь дать имя/ключ продукту/компонентам и назначить всю ту "простую логику инсталляции" по соотв событиям. А если ты потратил хотя бы день-два на эту тему, то в твоём "просто описании" будет ветвление по пропертям, например, учет того факта: UI-инсталляция или silent, а так же уровень этого UI, административная инсталляция или локальная, на текущего юзера или на всех и т.д. и т.п.

=========
Как по мне, то наркоманией является WiX. Если писать в базу MSI — это как программировать в кодах, то WiX — ассемблер. Его можно использовать исключительно как бэкенд какого-нить высокоуровневого тулза/скрипта (например, в цепочке: высокоуровневое представление -> промежуточное представление WiX -> бинарный образ) и никак иначе.

Здравствуйте, 0x7be, Вы писали:

0>Я лично участвовал в пяти проектах, которые развивались по этой схеме. Вот результаты:
0>1. Три полностью провалились (т.е. были отменены после того, как сожрали изрядно денег и не дали никакого полезного результата).
0>2. Один еле вытащили до состояния shippable-продукта (т.е. все обещанные плюшки от разработки платформы пошли лесом, оставив переусложненную и нестабильную кодовую базу, в которую были зарыты крупные деньги).
0>3. Один, участником которого я являюсь сейчас, так же борется за жизнь, но есть сильный риск того, что он повторит первый или второй сценарий.
0>Про случаи, о которых я знаю по наслышке, я рассказывать не буду, но их ещё больше.

Компания А., фреймворк Ф.?

По сути вопроса, фреймворк писать прикольно, кажется, что делаешь большое дело, которое, когда выстрелит, все сразу поможет и все оценят. Гораздо интереснее, чем пилить боковой винтик какого-нибудь продукта, о котором, возможно, никто и не вспомнит.
С другой стороны, по опыту с фреймворком очень просто ошибиться в оценке трудоемкости. Обычно кажется, что все не так уж сложно

И в третьих, больше вероятность, что пригодятся знания темных уголков ЯП, которые в обычных прикладных задачах обычно не нужны. Например, С++ шаблоны хитрозавернутые. Я же их знаю, книжку читал. Но в прикладных задачах они обычно ни к чему. Вот сейчас напишем фреймворк, заодно и шаблоны применим.

Здравствуйте, Ikemefula, Вы писали:

I>

единожды установленный SQL сервер практически невозможно снести, что бы начисто. Это регистрация, читай патч, чуть не всего что есть в системе — конфиги, реестры и все подряд.

Многие программы гадят в реестре и что?

Для того и нужен MSI, чтобы система достоверно знала, какие ветки реестра грохать. А SQL-севак лишь отчасти ставится через MSI, а еще приличную часть работы выполняется вне MSI, рукописным его экзешником-инсталлятором. Т.е. ты сам же привел хороший пример того, что бывает, когда установка идет "ручками" — получается хаос, как в эпоху до MSI.

Здравствуйте, LaptevVV, Вы писали:

LVV>А если чел не анализирует опыт, то этот эффект у него проявляется постоянно — программисты по натуре люди творченские.
LVV>Это заметил еще Дональд Кнут в соей книжке...

Это диалектическая сильно-слабая сторона программистов

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

Звиняйте за подъем старой темы.
Но как-то я пропустил, а тут Синклер высказался эпично!

0>"Что делают программисты, когда собираются вместе? Правильно — пишут фреймворк"
0>(с) Волков, Танки Онлайн, неточная цитата.

Отмечаю:
1. Программист даже один норовит писать фреймворк даже не имея опыты "обжигания"...

Неоднократно наблюдал в прежние времена у дипломников.
Вместо решения КОНКРЕТНОЙ задачи, норовит написать более ОБЩУЮ прогу.
Образно говоря, вместо вычисления синуса 30 градусов пишет универсальную функцию для вычисления синуса от любого угла.
Естественно, не справляется и к диплому приносит то самое, что можно видеть на известной картинке...
Качели, подпертые кривыми рогатинами...

Справедливости ради замечу, что в настоящее время таких практически не попадается — тямы у студентов не хватает или просто прагматичнее стали...
2. Настоящие программисты достаточно ленивы. И готовы потрудиться, чтобы ПОТОМ плевать в потолок.
Это не мои слова — это Мартин Фаулер про себя в книжке Рефакторинг написал...

3. Эффект второй системы. Это отмечал еще Фредерик Брукс в книжке Мифический человеко-месяц.
Именно при разработке 2 системы наблюдается расцвет "творчества" программистов.
А если чел не анализирует опыт, то этот эффект у него проявляется постоянно — программисты по натуре люди творченские.
Это заметил еще Дональд Кнут в своей книжке...

Здравствуйте, vdimas, Вы писали:
V>Любой, где можно накидать пакет мышкой, навроде InstallShield, Wise, VisualInstaller и т.д.
Практика показывает, что ни в чём из этого "накидать пакет мышкой" невозможно. Кроме случаев, когда продукт вообще поддерживает copy deployment, и никакой "инсталлятор" ему вообще не нужен.
V>Имеет аж бегом.
Вы для начала его запустите без MSI-файла, а потом поговорим о беге и прочем.

V>Основная польза от MSI-АПИ в иерархии продукт -> компонент.
И от этой же иерархии — основной вред. Вы в курсе, как устроен инсталлятор MS SQL Server, начиная примерно с 8.0? Если нет — то вот вам домашнее задание: выразить в терминах Windows Installer сосуществование нескольких инстансов SQL Server, при этом они могут быть как различных версий, так и одинаковых.

V>В автоматическом учете компонентов (счетчики), при пользовании ими из разных продуктов.
V>В транзакционности инсталляции.
V>В возможности инсталляции по-требованию.
V>В стандартизации основных сценариев инсталляции.
V>В учете сырцов-медиа инсталляций.
V>И т.д.
Это всё здорово, если бы в нагрузку не шла реляционная база данных.

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

V>Он фигню написал, ваще-то. Это как призывы писать программы на ассемблере. ))
Фигню пока что пишете исключительно вы. Вы сами-то хоть раз installshield запускали?
Там все эти install condition-ы пишутся точно так же, как в Orca — только не надо наизусть названия табличек знать. Вы попробуйте написать инсталлятор для веб-приложения, которое может ставиться в нескольких экземплярах на одном сервере, требует в зависимостях определённых фич IIS и наличия SQL Server Reporting Services, в который деплоятся (или апгрейдятся) репорты.
Я вас уверяю — коробку с InstallShield вы отнесёте на помоечку, и поставите себе WiX. И будете изучать структуру MSI, а вашим лучшим другом станет Orca.
V>Опиши в MSI только продукты и компоненты. Не возись с файлами, зависимостями и прочей "наркоманией", если не хочешь.
V>Перехвати требуемые custom actions и пусть в них работают твои bat-скрипты.
Круто. Вот это как раз и есть требование писать на асемблере. То есть все эти чудо-таблицы, получается, не нужны. Весь GUI делается в custom action на привычном нам языке, да? Все реальные действия по деплойменту компонентов делаются в custom action, да? Прекрасное подтверждение моего же тезиса.

Сразу видно человека, который custom action никогда в жизни не писал.

V>Если у кого-то проблемы с руками и custom actions... блин, пусть создадут пустое приложение Windows Service на дотнете в студии, добавят к нему инсталлер сервиса, потом сделают пакет с ним и разберут получившийся MSI каким-нить просмотрщиком или экспортером в WiX. Это порядка 5-10 мин всех делов.

В отличие от вас, коллега, я (и, судя по всему, коллега Нахлобуч) провели немало часов "разбирая получившийся MSI" от разных инсталлер-генераторов. И от студийного, и от инсталлшилдовского, и от викса.

V>Там не одна логика, а целый букет:
V>- инсталляция
V>- реинсталляция/восстановление
V>- инсталляция по-требованию
V>- деинсталляция
V>- добавить компонент
V>- убрать компонент
V>- собрать инфо о пользователе
V>- ...
Дупа в том, что встроенные действия, которые поддерживают всё вот это, крайне ограничены. А кастомные писать — геморрой. Как раз потому, что про них авторы мегаархитектуры думали меньше всего.

V>"Просто описать логику" можно лишь по каждой отдельной строчке. Дык, опиши! Твоя задача будет лишь дать имя/ключ продукту/компонентам и назначить всю ту "простую логику инсталляции" по соотв событиям. А если ты потратил хотя бы день-два на эту тему, то в твоём "просто описании" будет ветвление по пропертям, например, учет того факта: UI-инсталляция или silent, а так же уровень этого UI, административная инсталляция или локальная, на текущего юзера или на всех и т.д. и т.п.
В моём "просто описании" будет ветвление по тем пропертям, которые мне нужны. Если оно вообще нужно.
И в моём "просто описании" не будет этого колоссального разрыва между встроенной и продукто-специфичной логикой.
Собственно, WiX и есть попытка сделать DSL для платформы с идиотским дизайном. А то, что вы его не понимаете, показывает только то, что вы в жизни не сталкивались с разработкой инсталляторов для более-менее массовых продуктов.

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, 0x7be, Вы писали:

0>> Им гораздо проще и интересное заниматься технологией ради нее самой, потому что там не надо выходить из своей зоны комфорта.

J>Зоны комфорта, бла-бла...
J>Просто фреймворки

и платформы

гораздо прикольнее

разрабатывать

, вот и всё.

Тавтология. Вот 0x7be и пытается объяснить, почему "прикольнее".

Здравствуйте, Географ, Вы писали:

Г>Тем не менее, любое успешное решение, пережившее не одну версию, изначально создавалось на какой-либо платформе. Просто поток кода, склёпанный быстро, решает только одну задачу, на вторую его уже не согнуть.

История и Unix, и Windows — история успеха того, что началось как "склёпанный быстро поток кода", превращённый в платформу, пережил несколько десятилетий.

0>Вообщем, наброс сделан, жду ваших мнений

Программисты начиная с Hello World используют уже готовые фреймворки. Как следствие понимание что какое-то количество обобщённого кода может решать спектр задач и это лучше чем лепить уникальное решение для каждой в отдельности, приходит очень-очень быстро. Собственно без выделения общих участков (функции, классы, компоненты), программистом стать нереально. Исключения конечно есть, например тут код РАБОЧЕЙ игры, но всё-таки нереально.

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

Здравствуйте, vdimas, Вы писали:

V>Есть некий АПИ инсталлера, а есть к нему "движок", в котором можно закодировать вызовы этого АПИ декларативным способом. Классика декларативного подхода — описание зависимостей. Всё.

Начнем издали: насколько плотно ты работал с MSI и видел ли, как он устроен изнутри?

Здравствуйте, 0x7be, Вы писали:

0>Моя скромная гипотеза, объясняющая этот феномен, состоит в том, что типичным технарям просто психологически комфортнее делать технологию, а не конечный продукт, обладающий business-value.

Я бы добавил еще недооценку сложности проблемы и переоценку собственных сил.

Ну и мозг подставляет подножку своим умением натягивать сову на глобус. Изучив 5-10% описания проекта, мозг подгоняет оставшееся под уже привычные шаблоны, в результате чего возникает ощущение, что создание framework-а это просто самый рациональный быстрый способ создания программного продукта. А потом оказывается, что абстракции, которые в первом приближении так идеально отвечали всем потребностям проекта, ни фига не работают. Попытка решить одним потоком управления несколько разных задачи приводит к классической дилемме "хвост вытащишь — нос воткнешь, нос вытащишь — хвост воткнешь".

Здравствуйте, 0x7be, Вы писали:

0>Вообщем, наброс сделан, жду ваших мнений

У меня несколько противоположный опыт.
Все успешные и серьезные компании которые имеют какой-нибудь успех используют свои собственные frameworks и platforms.
Например из тех что я знаю достоверно Amazon, Google, Twitter, Facebook, Microsoft и т.д.
Это все про Web UI frameworks.

Здравствуйте, c-smile, Вы писали:

CS>Например из тех что я знаю достоверно Amazon, Google, Twitter, Facebook, Microsoft и т.д.

Сначала продукт, потом фреймворк. Все без исключения.

Здравствуйте, Нахлобуч, Вы писали:

V>>Есть некий АПИ инсталлера, а есть к нему "движок", в котором можно закодировать вызовы этого АПИ декларативным способом. Классика декларативного подхода — описание зависимостей. Всё.

Н>Начнем издали: насколько плотно ты работал с MSI и видел ли, как он устроен изнутри?

Начнем издали: насколько плотно ты знаешь АПИ инсталлера? Работал ли с ним напрямую (например, через скриптинг), или только через "проигрывание" MSI-пакета?
Какими высокоуровневыми инструментами пользовался?

Просто весь этот WiX, которым тычут как адовым адом — это как ассемблер. Но отсюда некоторые горячие головы делают далеко идущие выводы.

А если рассмотреть отношения внутри самой базы MSI — там не так уж много таблиц (в сравнении со средней прикладной базой), я не вижу особой сложности изучить её тем, кто делает инструментарий под MSI. Любые рассуждения о сложности отношений внутри пакета MSI — натуральный детсад. У нас с этим разбирались даже вчерашние студенты.

Ясен пень, прикладной программист, т.е. который использует MSI, а не пишет под неё инструментарий, не обязан в этом разбираться, путь берет что-то высокоуровневое — и вперед, делает пакет как грится "парой щелчков мышкой".

Здравствуйте, Ikemefula, Вы писали:

I>Есть общая тендеция — уход от реальности

В большинстве случаев это не уход от реальности, а просто изначальное отсутствие контакта с ней.
Культ карго. Копируют в меру своего понимания действия профи, а поскольку понимание убогое, то и результат соответствующий.

Здравствуйте, Ikemefula, Вы писали:

V>>Опиши в MSI только продукты и компоненты. Не возись с файлами, зависимостями и прочей "наркоманией", если не хочешь.
V>>Перехвати требуемые custom actions и пусть в них работают твои bat-скрипты.

I>И для чего тогда этот инсталер ?

Чтобы эти скрипты руками не писать, вестимо.
Накидал мышкой в каком-нить визуальном редакторе пакета, проставил галочки — и всё отлично работает.

Ну и более подробно отвечал уже — на нем высокоуровневая логика, учет зависимостей продуктов -> компонентов, типовые сценарии и т.д.

Здравствуйте, Sinclair, Вы писали:

S>Это всё здорово, если бы в нагрузку не шла реляционная база данных.

Ну, право, это как критиковать сегодня морально устаревший набор кодов Интел-совместимых процессоров, со всеми их расширениями SSEx, где итоговая бинарная кодировка одна из САМЫХ НЕОПТИМАЛЬНЫХ В ИНДУСТРИИ! И чё??? Да ничё. Все понимают, никто и не спорит, но это никого не парит.

V>>Еще раз для особо одаренных. Изначально был расчет на коммерческие приложения, где это, действительно, несложно.
S>Ещё раз для особо одарённых: это несложно для того сценария, в котором база данных не нужна вообще, от слова совсем.

Ну, вообще-то, в той информации достоверно прослеживаются уникальные ключи и связи. Таки стоит взглянуть на схему базы — она относительно несложная. Т.е. реляции предоставляются предметной областью, поэтому огульно высмеять её не получится никак, увы. Можно лишь поспорить относительно отдельных таблиц и связей. Я соглашусь только с иронией по поводу представления UI, но блин, в сотый раз оговорюсь, что эта ирония бессмыслена изначально, бо с выходом самой первой версии инсталлера в его SDK был тул по визуальному редактированию и тестированию UI. Более того, диалоги из разных пакетов можно склеивать в один целевой, то бишь некая контора вполне может хранить однажды разработанные диалоги в кач-ве библиотек.

Аналогично языка представления зависимостей. Он полон в декларативном смысле в терминах ВСЕХ объектов, описываемых базой инсталлера. Поэтому, да, некие вещи, выходящие за рамки информации, оперируемой инсталлерами, в нем описать нереально. Но это и хорошо — иначе бы это была дыра в безопасности.

Кароч, извините за самоповтор, но вся эта критика пока на уровне критики объектных кодов Интел-совместимых процессоров.

V>>Он фигню написал, ваще-то. Это как призывы писать программы на ассемблере. ))
S>Фигню пока что пишете исключительно вы. Вы сами-то хоть раз installshield запускали?
S>Там все эти install condition-ы пишутся точно так же, как в Orca — только не надо наизусть названия табличек знать. Вы попробуйте написать инсталлятор для веб-приложения, которое может ставиться в нескольких экземплярах на одном сервере, требует в зависимостях определённых фич IIS и наличия SQL Server Reporting Services, в который деплоятся (или апгрейдятся) репорты.
S>Я вас уверяю — коробку с InstallShield вы отнесёте на помоечку, и поставите себе WiX.

Мы используем Wise для чего-то уникального и только для совсем типовых пакетов — WiX, так что ничего сказать не могу. Последний раз, когда я пользовался InstallShield в 2003-м, он полностью удовлетворял всем моим нуждам.

S>И будете изучать структуру MSI, а вашим лучшим другом станет Orca.

Я изучал подробно, но для чуть других целей — для целей генерирования скриптов автоматической установки софта.

V>>Опиши в MSI только продукты и компоненты. Не возись с файлами, зависимостями и прочей "наркоманией", если не хочешь.
V>>Перехвати требуемые custom actions и пусть в них работают твои bat-скрипты.
S>Круто. Вот это как раз и есть требование писать на асемблере. То есть все эти чудо-таблицы, получается, не нужны. Весь GUI делается в custom action на привычном нам языке, да? Все реальные действия по деплойменту компонентов делаются в custom action, да? Прекрасное подтверждение моего же тезиса.

Нет, это ты спросил, как обойтись без ВСЕЙ "наркоманской" базы, я тебе подсказал. Тебе достаточно использовать ту её часть, где реляционное представление как нельзя к месту. Ну вот подыграл твоему "чувству прекрасного", не более того.

S>Сразу видно человека, который custom action никогда в жизни не писал.

Сразу видно человека с проблемной самооценкой.

V>>Если у кого-то проблемы с руками и custom actions... блин, пусть создадут пустое приложение Windows Service на дотнете в студии, добавят к нему инсталлер сервиса, потом сделают пакет с ним и разберут получившийся MSI каким-нить просмотрщиком или экспортером в WiX. Это порядка 5-10 мин всех делов.
S>

В отличие от вас, коллега, я (и, судя по всему, коллега Нахлобуч) провели немало часов "разбирая получившийся MSI" от разных инсталлер-генераторов. И от студийного, и от инсталлшилдовского, и от викса.

Ну тогда опять и снова для особо одарённых — я подсказал простой способ получения достоверно работающего результата на имеющемся почти у всех девелоперов инструментарии. Это был ответ на "ай-ай, проблемы с custom actions". )))

Более того, именно так я когда-то сделал себе "скелет" пакета, когда надо было накидать по-быстрому инсталляшку нейтивного сервиса. Всё получилось за считанные минуты.

V>>Там не одна логика, а целый букет:
V>>- инсталляция
V>>- реинсталляция/восстановление
V>>- инсталляция по-требованию
V>>- деинсталляция
V>>- добавить компонент
V>>- убрать компонент
V>>- собрать инфо о пользователе
V>>- ...
S>Дупа в том, что встроенные действия, которые поддерживают всё вот это, крайне ограничены. А кастомные писать — геморрой. Как раз потому, что про них авторы мегаархитектуры думали меньше всего.

Можно подробнее — в чем именно геморрой?
Основной геммор как по мне — это в довольно большом кол-ве пропертей (некоторые из которых необходимо "разыменовать" как указатели, иногда более одного раза), но ими НЕОБХОДИМО оперировать, если пишешь вменяемый custom action. Дык, это как бы часть предметной области, не? Например, писал пакеты под RPM — там тоже дохренищща подобной предметной области. Се ля ви. И тут уже реляционность или объектность базы до одного места. ИМХО, наоборот, в реляционной базе доставать/разыменовывать пропертя удобнее, бо однотипнее, автоматизируется несложной однажды написанной либой.

V>>"Просто описать логику" можно лишь по каждой отдельной строчке. Дык, опиши! Твоя задача будет лишь дать имя/ключ продукту/компонентам и назначить всю ту "простую логику инсталляции" по соотв событиям. А если ты потратил хотя бы день-два на эту тему, то в твоём "просто описании" будет ветвление по пропертям, например, учет того факта: UI-инсталляция или silent, а так же уровень этого UI, административная инсталляция или локальная, на текущего юзера или на всех и т.д. и т.п.
S>В моём "просто описании" будет ветвление по тем пропертям, которые мне нужны. Если оно вообще нужно.
S>И в моём "просто описании" не будет этого колоссального разрыва между встроенной и продукто-специфичной логикой.
S>Собственно, WiX и есть попытка сделать DSL для платформы с идиотским дизайном. А то, что вы его не понимаете, показывает только то, что вы в жизни не сталкивались с разработкой инсталляторов для более-менее массовых продуктов.

Я понимаю для чего нужен WiX, но вижу непонимание у тебя. Этот DSL всё еще низкоуровневый, он плохо маскирует низлежащую платформу, поэтому пользоваться им напрямую для чего-то повторяемого — глупо. У нас, например, WiX генерится с помощью своих скриптов для однотипных пакетов. Дарю идею, как грится. )))

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

Здравствуйте, Sinclair, Вы писали:

V>>Основная польза от MSI-АПИ в иерархии продукт -> компонент.
S>И от этой же иерархии — основной вред. Вы в курсе, как устроен инсталлятор MS SQL Server, начиная примерно с 8.0? Если нет — то вот вам домашнее задание: выразить в терминах Windows Installer сосуществование нескольких инстансов SQL Server, при этом они могут быть как различных версий, так и одинаковых.

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

А всякие "инстансы", сидящие на разных портах или разных ключах именованных каналов (или еще на каком транспорте) — это сугубо прикладная хрень, которая обыгрывается утилитами администрирования SQL-сервера. Создание и удаление инстансов вовсе не требует переустановки бинарного образа программы SQL-сервака.

То бишь, по классике жанра это может быть сделано ПОСЛЕ инсталляции. Автоматом запустить утилиту конфигурирования инстансов сервака после его установки не сложно, ИМХО.

Здравствуйте, Cyberax, Вы писали:

C>При том, что на вражеских платформах типа Линукса это же делается без особых проблем.

Давай конкретней, что вызывает проблемы в MSI и что делается легко в том же RPM?
А то, сдается мне, что ты пытаешься простой сценарий в RPM сравнить со сложным в MSI.
Как по мне, то что-то более-менее нетривиальное в RPM — еще больший ад.

Здравствуйте, Cyberax, Вы писали:

C>>>При том, что на вражеских платформах типа Линукса это же делается без особых проблем.
V>>Давай конкретней, что вызывает проблемы в MSI и что делается легко в том же RPM?
C>Да банально сделать галочки "установить сервис"/"запускать сервис при запуске"/"запустить сейчас" с полем ввода для имени сервиса. С валидацией и возможностью unattended installation. Потом ещё указание каталога для файлов лога и настройки уровня логгирования.

Через пропертя это всё делается и в MSI. Запусти себе инсталляху с явным указанием св-в.
Просто имено с unattended installation пакетов MSI я и возился очень плотно, ничего сверхъестественного не увидел.

C>Это то что я лично делал, в обоих системах.

Согласен только насчет установки сервиса. Но подобный "скелет" пакета MSI для установки сервисов можно сделать лишь однажды и использовать затем. Просто в MSI есть крайне удобная фишка — слияние нескольких пакетов в один. Этим стоит пользоваться.

V>>А то, сдается мне, что ты пытаешься простой сценарий в RPM сравнить со сложным в MSI.
V>>Как по мне, то что-то более-менее нетривиальное в RPM — еще больший ад.
C>В DEB всё просто — берёшь и пишешь простой shell-код. Вопросы задаются с помощью удобной и простой диалоговой системы, ответы которой могут скриптоваться.

Не разбирался с DEB, я спросил про RPM. Это де-факто самый популярный формат для серверных линухов, а мне тут как раз серверными сценариями и тыкали. Так вот, там такой же АД, но этот ад не структурный, а навязан предметной областью — много всяких подробностей и соглашений. В MSI тоже АД не из-за структуры (она тривиальна, ваще-то), а из-за огромного кол-ва пропертей и соглашений, которыми надо уметь оперировать.

Здравствуйте, Sinclair, Вы писали:

Антон, это бесполезно.

Здравствуйте, vladimir_i, Вы писали:

_>В основе — потребность ощущать себя творцом, а не ремесленником.

Это ерунда, потому что не даёт ответа на первый же встречный вопрос: почему такой "ощущает себя творцом" только когда написал фреймворк, а не радуется творению конкретного программного продукта, соответствующего своей цели и удовлетворяющего пользователей?

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

> Почему нам так нравится разрабатывать фреймворки и платформы?

Сколько бы не говорилось о том, что "настоящий программист должен получать удовольствие от самого процесса программирования", этого всё же мало, для программиста важен и результат его работы.
А чтобы получить удовлетворение от результата, нужно самому ощутить его красоту, полезность, эффективность и продуманность, а для этого нужно хоть немного побыть его пользователем (дольше — лучше). При этом не натягивать на себя роль пользователя через силу, как это бывает нужно в целях предварительного ручного тестирования, когда его делает сам программист, а оказываться в ней по своей доброй воле и желанию. А это проще всего достигается в процессе программирования инструментальных средств, нужных самому программисту, в том числе фреймворков и платформ.

Короче, чтобы быть довольным сделанной работой, нужно убедиться в том, что она хороша, а это проще всего сделать, будучи её заинтересованным пользователем.

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

Программисты-"системщики", пишущие фреймворк/платформу для своей конторы (для кодеров-"прикладников"), даже сами с ней не работая, так же могут получать плотный фидбэк от неподалёку сидящих конечных пользователей своего труда и быть вполне удовлетворенными.
А вот прикладники, обычно в крупной конторе надежно изолированные от конечных пользователей системы толстым слоем аналитиков/внедренцев/техподдержки, с большой вероятностью будут от этой изоляции страдать (и рваться в системщики, а то и в аналитики — да хоть куда-нибудь). Это плюсом к однообразию задач кодирования бизнес-логики. И к малому соотношению "трудность средней задачи"/"количество задач", что тоже не всем по вкусу.

Ну и, во-вторых, при разработке фреймворков и платформ у программиста гораздо больше шансов поучаствовать в постановке задачи и принятии решений о необходимых компромиссах, и, соответственно, меньше шансов необходимости наступать на собственное чувство прекрасного и скрежетать зубами на тему "какого хрена они (без меня) решили, что это нужно делать именно так, а не иначе?!" (Еще одна перманентная боль бизнес-лоджик-кодеров — прикладников. В "они" попадают и системщики, и бизнес-аналитики.)

Здравствуйте, vdimas, Вы писали:

V>Конечно есть — это официальный пресс-релиз Ms Office-2000, где впервые упоминается новый инсталлятор.
Вот этот пресс-релиз: https://news.microsoft.com/1999/06/07/microsoft-office-2000-an-essential-tool-for-all-knowledge-workers-is-available-this-week/#sm.0000k2gfry19ipcx7ycv15b09qwvy
Никаких описаний инсталлятора, естественно, нету.
V>Неверующие могут скачать с MSDN-подписки (ну или с торрентов) оригинальный образ дисков этой версии офиса и дополнительно лично убедиться.
Муа-ха-ха. Ждём от вас цитату в студию. На всякий случай напомню, что речь не о том, что офис ставился через Windows Installer — это, конечно же, правда.
А о том, что он проектировался для офиса, и решение его использовать для чего-то ещё было принято потом.

V>Ну вот я так и думал, что полезных предложений не будет.
V>Во-первых, давно существуют дизайнеры диалогов WI, они ничуть не уступает дизайнеру диалогов Dialog Templates.
Да что за бред-то! Я же вам на этот аргумент уже отвечал трижды! Повторю ещё раз: это сейчас существуют дизайнеры диалогов. А мы говорим о решениях, принятых 1997 году, когда изобреталась технология WI.
Не было никаких дизайнеров! Была Visual Studio 6.0.

V>А если ты рассуждал о неких "массовых продуктах", то можно было вообще взять что-нить типа этого:
V>http://www.advancedinstaller.com/download.html
Вы полностью подтверждаете мою точку зрения. Я вам говорю — архитектура говённая. А вы мне перечисляете коммерческие средства по замазыванию проблем этой архитектуры.
Ога, типа "самсунги взрываются" — "а вы его в портативном сейфе носите".

V>Во-вторых, о совместимости говорить нелепо хотя бы потому, что к контролам в WI можно привязывать некие стандартные действия, а в случае Dialog Templates — нельзя.

Это всё равно не оправдывает реляционную базу данных для контролов.
Для сравнения можете изучить архитектуру Delphi — как устроен DFM, как привязываются действия, как описываются контролы, стандартные и нестандартные. Чисто для справки — на момент начала проектирования WI Delphi уже был третьей версии.
V>Ну и набор контролов чуть другой, местами пересекается, местами нет.
Ну так в том-то и дело, что набор контролов WI прошит гвоздями, а в Dialog Template можно указывать любые контролы.

V>В-третьих, сама попытка утверждать, что загвоздка в дизайнере диалогов — это заведомо слить спор. ))
V>Их было более одного сразу же.
"Сразу же" их было ровно 0. Загвоздка — не в дизайнере. Загвоздка — в попытке хранить описание UI в реляционных таблицах. Через это проходят все начинающие разработчики — лично я этим занимался в 1991 году. На клиппере.

V>Сам не видишь разве, что такие рассуждения попахивают тем, что ты "сабклассил" ручками уникально каждый диалог в нейтивных приложениях, т.е. перехватывал события на стороне parent, без reflection? Не, пару раз и я таким макаром упал-отжался, но исключительно для удовлетворения собственного любопытства.
Всё наоборот — reflection отражает евенты на сторону parent, и делается для того, чтобы можно было обойтись без сабклассинга контролов для привязки обработчиков. Вижу, что с темой разработки гуя на чистой нативной винде вы тоже знакомы только по разговорам в курилке.

V>А если по-делу, то некий GUI-контрол пишется один раз и затем многократно используется.
Совершенно верно. И именно это невозможно сделать в WI — нет возможности импортировать сторонний GUI-контрол, разработанный не в рамках этого проекта. Приходится полностью подменять весь UI.

V>Но и этого НЕ надо. Когда тебе кажется, что гуйный визард установщика листает некие "вложенные" страницы внутри одного "объемлющего" окошка верхнего уровня — это подлый обман зрения. Каждый диалог создаётся абсолютно с 0-ля, это новый оконный хендл, т.е. новое независимое окно. Общего у них — только хендл текущей инсталляхи.
Конечно, совершенно верно. Более того, половина, а то две трети инсталляций изображают "листание" вообще выводя отдельный диалог поверх текущего — запуская отдельный екзешник.
Не знаю, с чего вы взяли, что мне что-то кажется. Я прекрасно знаю, как устроены вот эти "страницы".
V>А суть этой простой вещи в том, что возьми, создай свой любой диалог на любой знакомой тебе технологии и дёргай АПИ инсталлера.

Вы произносите слова, смысла которых не понимаете. Ну вот нарисовал я, допустим, "диалог". Для простоты предположим, что это форма на Delphi — то есть там у нас есть бинарное описание структуры, плюс все нужные обработчики скомпилированы. Всё это лежит у меня в .bpl — то есть скомпилированное и готовое к работе. Пусть это будет развесистая форма terms and conditions, которая в конце устраивает устанавливаюшему экзамен на предмет того, правильно ли он прочёл EULA. Её надо показать между стандартным component selection и progress dialog.
Что мне нужно сделать, чтобы "дёргать API инсталлера"?
Там объём работы будет такой, что мне проще вообще всё переписать на PowerShell скрипт, и не трахаться с WI вообще.

V>В наличии есть даже упрощенный вариант COM-библиотеки инсталлера, которую можно юзать из VBScript, основной объект — Session. Вот прямо из этого объекта можно читать некие property, устанавливать их (по результатам работы своих диалогов) и т.д. А эти property потом уже используют последующие custom actions. Т.е. важно отделять действия, которые можно охарактеризовать как install/commit/rollback от действий, которые являются просто "collect some data".

V>Я как-то просто из VB-скрипта рисовал кастомные диалоги через стандартную ActiveX-библиотеку Microsoft Forms 2.0.

Это не имеет отношения к делу.

V>Там одна проблема в том, что твои диалоги должны рисоваться уже неким установленным кодом, т.е. нельзя на них "вытащить самого себя за волосы". ))
Это тоже заблуждение — можно рисовать диалоги безо всякого установленного кода.
V>Ну, дык, уж как минимум один диалог (приветственный) можно сваять на предоставляемой технологии.
То есть её ценность равна примерно 0. А себестоимость — как у авианосца.

V>Фишка в том, повторюсь — а откуда должен исполняться этот твой кастомный код? Где в этот момент будет располагаться та программа, которая исполняет этот код? Причем, "сабклассить" ограничивает нас нейтивом, пральна?
Программа будет располагаться там же, где располагается код custom actions. Вы не замечаете, как противоречите сами себе? То у вас "да пиши любой GUI и исполняй в процессе установки", то "ой, нет, кастомный код в UI взять неоткуда".

V>Именно через написание своих скриптовых утилит я потом перегонял в WiX и обратно понравившиеся куски других пакетов инсталляций, рефакторил и мёржил их, как тырил когда-то на сайтах клиентский скриптинг, тоже рефакторил и допиливал напильником.
А можно было просто открыть пакет оркой.
V>Я ничего не путал. Я говорил о сетевых принципах работы Skype. Ты можешь заходить в конференцию Skype For Business с обычного скайпа. Сюрпрайз? Не знал?

Нет, не можешь. Сетевые принципы у этих двух скайпов совершенно разные. for Business — это SIP/RTP, которые кое-кто в том топике ругал как непригодные для жизни. А обычный скайп использует тот самый proprietary протокол, который кое-кто превозносил до небес.
Даже если к обычному скайпу прикрутить SIP, то это никак ему не поможет — свою архитектуру супернод он не сможет использовать. С вашими претензиями на знание сетевых технологий писать такую чушь должо быть стыдно.

V>Компонент имеет версию...

А вы как думали? Всё имеет версию.

V>Я же говорил тебе — курить, что есть component.
Булшит поскипан.

V>Да, файл может быть частью компонента, но может и не быть. Важно, что у компонента НЕТ версий. Вот нет и всё. Любая твоя "версия" — это чисто прикладная хрень. И если ты способен хоть каким-либо образом закодировать/представить эту "версию" — ну так представь.

V>И почему именно как файл? А что мешает в виде сетевого запроса твоего сертификата?
Архитектура WI. Курить, что есть component.
V>Прикручивать версию к единице транзакции — ну это сильно, ИМХО. ))
Ну, авторы WI это сделали.
V>Компонент же может быть сугубо виртуальный, т.е. не существующий в каком-нить реальном воплощении (по крайней мере в таком воплощении, о котором знает WI), т.к. install, commit и rollback могут быть какими-нить сетевыми запросами или запросами в БД.
Я по прежнему жду каких-то подтверждений этого смелого тезиса. Что нужно написать в табличке Component для того, чтобы install, commit и rollback были "какими-нить сетевыми запросами или запросами в БД.". Хрен с ним с версией — хотя бы пусть детектирование наличия компонента при repair было кастомным кодом, а?

V>Но лучше пользоваться встроенными сущностями инсталлера по-делу, а именно — там, где речь идёт о версиях/апгрейдах и кодах совместимости, использовать сущность Продукт, потому что у него есть ProductCode, в рамках которого уже можно организовать произвольную версионность. Да, иногда удобно, в случае когда один и тот же файл входит в разные продукты, пользоваться понятием версионности этого файла. Но тут сразу твои доводы превращаются в маразм, уж извини — если у нас такой сценарий возможен только для файла, то не стоило пенять на то, что для такого сценария обязательно нужен файл. Тем самым ты показываешь, что ты не программист. Логика того-с. :xz;
В разные продукты может входить не только "файл". Произвольный компонент может входить.

V>Или ты заламывал руки, что вот "а там, ПРЕДСТАВЛЯЕТЕ, несколько ключей продуктов зашито". ))
V>Это, надо понимать, проявление "продуктофобии"? Да какая тебе разница, сколько ключей продукта зашито?
Простая разница — бывает прямая архитектура, которая предлагает прямые решения прямых задач. А бывает — наркоманская архитектура, в которой Hello World пишется за 10 минут, а Hello Vdimas требует 160 часов девелопмента и 80 часов QA.

V>Ты ты сообщил вслух (и очень зря), что SSL-сертификат у тебя "компонент".
V>А с какой радости ты, как разработчик, вдруг решил рассматривать его как "компонент"?
А как что мне его рассматривать, стесняюсь спросить? Есть иерархия — продукт/фича/компонент.

V>"Я гарантирую" что ты подошел к инсталлеру вообще не с той стороны. НЕ понял ни его философии, ни для чего нужны основные сущности инсталлера.
Да я всё прекрасно понял. Философия — претенциозная, основные сущности — выделены криво. Предположения, на которые опирались авторы, — неверны. Реализация — неудобная ни для чего. Что я забыл?

V>В большинстве случаев задачей custom actions не является копирование чего-то куда-то или установкой флагов в реестре и проч — это даже вредно, потому что в таком случае "чистота" транзакционности инсталлера ложится на плечи автора этих действий.
Рекомендую почитать документацию на custom actions из WiX. Ну, чтобы просто иметь представление о том, что является их задачей "в большинстве случаев".

V>В большинстве случаев тебе надо породить и установить значение некоего текстового property для сессии, продукта, фичи и т.д., которое (значение св-ва) невозможно породить встроенными ср-вами инсталлера. Ну вот, строку подключения к какому-нить кастомному приложению или к БД, например.
Да, это ровно один из случаев. Как правило решаемый как раз в Custom UI. Потому что в процессе инсталляции свойство уже есть — а в админской инсталляции все connection strings и server urls уже прошиты, там не надо никакой код исполнять. А речь идёт про custom install actions — внесение изменений в систему, не сводящихся к хардкодным "скопировать файл", "записать значение в реестр", или "зарегистрировать сервис".

V>Для твоей задачи одно кастомное действие должно было сравнить некую "прикладную версию" SSL сертификата (предположим, его expiration date) с неким встроенным в инсталляху св-вом и в кач-ве результата установить еще какое-нить прикладное св-во, типа "NeedToUpgradeSertificate", по которому далее ветвиться в других шагах инсталляции.
А кто будет регистрировать сам сертификат? Кто будет настраивать правила Windows Firewall? Кто будет загружать репорты в SSRS? Кто будет биндинг веб-сайта править? Где вы собрались ветвиться?

Здравствуйте, jazzer, Вы писали:

J>Зоны комфорта, бла-бла...
J>Просто фреймворки

и платформы

гораздо прикольнее

разрабатывать

, вот и всё.

Вот взял и всё опошлил

Здравствуйте, Географ, Вы писали:

Г>Тем не менее, любое успешное решение, пережившее не одну версию, изначально создавалось на какой-либо платформе.
Прямо таки любое?

Г>Просто поток кода, склёпанный быстро, решает только одну задачу, на вторую его уже не согнуть.
Это уже другая крайность Между работающим говнокодом и разработкой платформы есть промежуточные варианты.

В любом случае, я критикую не идею разработки платформы в принципе, я критикую метод принятия решения.

Здравствуйте, 0x7be, Вы писали:

0>Вообщем, наброс сделан, жду ваших мнений

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

Здравствуйте, andyag, Вы писали:

A>Как только программист глядя на описание новой фичи задаёт вопрос "зачем?", его тут же выгоняют в тимлиды, а потом в менеджеры проектов. Программистами остаются только те, кого интересует только написание кода за деньги

Да, примерно так оно и есть

Толковых лидов и менеджеров не хватает

Здравствуйте, 0x7be, Вы писали:

0>Про случаи, о которых я знаю по наслышке, я рассказывать не буду, но их ещё больше.
про ехель знаете? на его примере можно проследить всю судьбу винды. очень многое из того, что есть в винде было реализовано в ехеле, ну или в офисе.

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

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

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

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

ЗЫ. когда я начинал изучать JS, то первое что я стал писать -- это логгер. шеф покрутил пальцем и виска и показал на готовый, которым до сих пор пользуюсь.

Здравствуйте, мыщъх, Вы писали:

М>примеры провалившихся проектов неинтересны, потому что завалить проект можно и без фреймворка.
Они как раз очень интересны с точки зрения предотвращения хождения по тем же граблям.

М>ЗЫ. когда я начинал изучать JS, то первое что я стал писать -- это логгер. шеф покрутил пальцем и виска и показал на готовый, которым до сих пор пользуюсь.
Боюсь, есть недопонимание. Я ничего не имею против фреймворков в принципе, я имею кое-что против определённого ущербного мыслительного процесса, который приводит к появлению нежизнеспособных фреймворков.

Что характерно, в моём сообщении уже не первый раз видят наезд на концепцию плафтормы/каркаса в принципе. Либо я так неудачно выразился, либо это тоже особенность мышления нашего брата-программиста

Здравствуйте, Osaka, Вы писали:

0>>технарям просто психологически комфортнее делать технологию, а не конечный продукт
O>Всё гораздо проще, программистам некомфортно делать бесполезную работу (которую можно автоматизировать и переложить на машину). Для кого эта разница в "написании кода за деньги" незаметна, тот, скорее всего, не программист, а простой клерк-делопроизводитель.
O>http://ru.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself
O>Появляется, например, бизнес-задача поменять 1 слово в 100 похожих экранных форм. С фреймворком эта задача решается изменением 1 места в коде, а без фреймворка — долгим и внимательным ручным тиражированием этого изменения в 100 откопипастенных-с-изменениями мест, и последующим отловом ошибок, сделанных при тиражировании.
Ты описываешь ситуацию оправданного внедрения обобщенного решения. Я же говорю о тех мыслительных процессах, которые приводят к появлению мертворожденных фреймворков и платформ, чему я был свидетелем неоднократно.

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

В чем причина такого положения дел?
Я предложил гипотезу

0>городят огромные и нестабильные решения, которые потом на практике ещё и с трудом решают прикладные задачи под которые создавались. То есть на поверку получается та же самая бесполезна работа, которая обходится намного дороже.
0>В чем причина такого положения дел?
В том, что иногда видят только одну крайность, и игнорируют другую. Необходим баланс между решением сиюминутной задачи и созданием задела на будущее. И для тех, кто сегодняшнюю задачу сдал/премию получил/а дальше хоть трава не расти, и для тех, кто тратит время на создание расширяемости, которая потом не будет использоваться.

Здравствуйте, Osaka, Вы писали:

O>В том, что иногда видят только одну крайность, и игнорируют другую. Необходим баланс между решением сиюминутной задачи и созданием задела на будущее. И для тех, кто сегодняшнюю задачу сдал/премию получил/а дальше хоть трава не расти, и для тех, кто тратит время на создание расширяемости, которая потом не будет использоваться.
Ок, к моей "психологической гипотезе" добавим банальные недостаток компетенций

Видимо, так же можно говорить и про несовпадение целей проекта и его исполнителей.

Здравствуйте, hi_octane, Вы писали:

_>Программисты начиная с Hello World используют уже готовые фреймворки. Как следствие понимание что какое-то количество обобщённого кода может решать спектр задач и это лучше чем лепить уникальное решение для каждой в отдельности, приходит очень-очень быстро. Собственно без выделения общих участков (функции, классы, компоненты), программистом стать нереально. Исключения конечно есть, например тут код РАБОЧЕЙ игры, но всё-таки нереально. Опыт по созданию обобщённого кода приходит годами позже. Иногда отсутствие опыта на одних уровнях (архитектура, бд, использование готовых решений), удаётся компенсировать опытом на других уровнях. А иногда получается то что ты наблюдаешь.
Одно дело — обобщать код в работающей (хотя бы частично) программе, другое дело — вместо работающей программы писать неработающий фреймворк.
Я говорю именно о втором феномене.

0>Ок, к моей "психологической гипотезе" добавим банальные недостаток компетенций

Это самый простой способ "решить вопрос для себя" — объявить всех некомпетентными психами, но работать-то в таком случае с кем, и договариваться как?
0>Видимо, так же можно говорить и про несовпадение целей проекта и его исполнителей.
Смысла в этом столько же, как если каждый раз, заходя в магазин, говорить про несовпадение целей продавца и покупателя.
И раз уж зашла речь о компетенциях, распространена ситуация, когда заказчик не совсем понимает, чего он хочет. "Здесь же всего одну кнопку добавить для расчёта баланса, любой студент за полчаса сделает". Или как в хрестоматийном примере про "выстрелить себе в ногу". Наверно, здесь нужен подход, типичный для ситуации, когда специалист лучше разбирается в предмете (как врач по сравнению с пациентом): заказчик варьирует "наружные" параметры (функционал, сроки, бюджет), специалист предлагает решение, заказчик целиком принимает или целиком отвергает, но во внутренние технические детали не вмешивается.

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

Но я видел и другие проекты — где просто не давали ничего сделать на перспективу.
Итог — куча гвнокода, и тоже ничего не работает толком.

Здравствуйте, barn_czn, Вы писали:

_>Опыт программиста в том и заключается — насколько далеко надо пустится в написание фреймворков, чтобы выполнить проект.
_>Вы, по рассказу, увлекались этим чрезмерно. Это опасно, да.
Ну, на моей совести один из описанных проектов. Тот как раз, который еле вытащили до состояния shippable-продутка

_>Но я видел и другие проекты — где просто не давали ничего сделать на перспективу.
_>Итог — куча гвнокода, и тоже ничего не работает толком.
Согласен, крайности опасны.

Я участвовал в одном проекте, где было сделано на мой взгляд разумно. Там писался один продукт, но планировалось писать другой, в целом аналогичный по структуре.
По ходу работы все компоненты "на глазок" делились на общие и специфичные, но заранее дорогих закладок на второй продукт не делалось.
Потом, когда начали делать второй продукт, общий функционал стали агрессивно выделять в разделяемый код и так "вырос" небольшой framework, реально позволивший сэкономить время при разработке второго продукта.

Здравствуйте, 0x7be, Вы писали:

0>Моя скромная гипотеза, объясняющая этот феномен, состоит в том, что типичным технарям просто психологически комфортнее делать технологию, а не конечный продукт, обладающий business-value. Разработчики — эгоцентристы, им некомфортно влезать в шкуру пользователя, учиться смотреть на мир его глазами, понимать его проблемы, получать от него негативный фидбек. Им гораздо проще и интересное заниматься технологией ради нее самой, потому что там не надо выходить из своей зоны комфорта. Технология делается не для пользователей, а для самих себя (или же других разработчиков), так что можно обойтись привычной картиной мира критериями оценки результата, да и общаться с потребителем проще.

"Технология" это обычно слишком громкое слово для большинства фреймверков. Язык не поворачивается их так назвать

Здравствуйте, Lazin, Вы писали:

L>"Технология" это обычно слишком громкое слово для большинства фреймверков. Язык не поворачивается их так назвать

я примерно об этом вот — https://github.com/search?q=framework&ref=cmdform

большинство перечисленных "фреймверков" делают какую-нибудь простую хрень, достойную библиотеки, но никак не громкого слова "фреймверк", субъективно конечно

Простите моему вбросу некоторые терминологические вольности

Здравствуйте, Osaka, Вы писали:

0>>Ок, к моей "психологической гипотезе" добавим банальные недостаток компетенций

O>Это самый простой способ "решить вопрос для себя" — объявить всех некомпетентными психами, но работать-то в таком случае с кем, и договариваться как?
Я не собираюсь развешивать ярлыки

Тему поднял и исключительно благими целями — понять, почему люди по одним и тем же граблям систематически ходят.

O>Смысла в этом столько же, как если каждый раз, заходя в магазин, говорить про несовпадение целей продавца и покупателя.
Не до конца уловил смысл предложения.

O>И раз уж зашла речь о компетенциях, распространена ситуация, когда заказчик не совсем понимает, чего он хочет. "Здесь же всего одну кнопку добавить для расчёта баланса, любой студент за полчаса сделает". Или как в хрестоматийном примере про "выстрелить себе в ногу". Наверно, здесь нужен подход, типичный для ситуации, когда специалист лучше разбирается в предмете (как врач по сравнению с пациентом): заказчик варьирует "наружные" параметры (функционал, сроки, бюджет), специалист предлагает решение, заказчик целиком принимает или целиком отвергает, но во внутренние технические детали не вмешивается.
Это называется "выстраивание отношение с клиентами". Есть даже такая отдельная компетенция, про неё очень любят говорить во всяком консалтинге. Понять клиента, сделать не то, что он хочет, а то что ему надо, сформировать у него реалистичные ожидания насчет стоимости его хотелок и т.п..

У нас же клиента часто априори считают дебилом, т.к. он не рубит в разработке, а его потребности, не вписывающиеся в красивую архитектуру программы, вызывают раздражение.
Мне один архитектор (главный, между прочим!) не так давно выдал мысль, мол, лучше бы проектировать всё без специалистов по взаимодействию с пользователем, а их позвать только в самый последний момент. Дескать мешаются, гады, творить и ваять.

Всё это я понимаю, как проявление эгоцентризма разработчиков, о котором я в оригинальном посте написал.

Здравствуйте, Sinclair, Вы писали:

S>Была такая тема некоторое время назад — что все ошибки проектирования — это результат каких-то фобий.
Не, ну я не про фобии, я про эгоцентризм

S>Пример проекта, который преодолел испытание "реляционной конфигурируемостью" и был сквозь зубовный скрежет навязан целевой аудитории, каждый может наблюдать в лице Windows Installer. Это как бы показывает, что overarchitecting не является специализацией провинциальных кулибиных, а запросто может процветать и в корпоративном секторе.
Люто, бешено плюсую.
Желание придушить разработчиков этой фигни у меня возникает минимум раз в день

Здравствуйте, 0x7be, Вы писали:

0>Ты описываешь ситуацию оправданного внедрения обобщенного решения. Я же говорю о тех мыслительных процессах, которые приводят к появлению мертворожденных фреймворков и платформ, чему я был свидетелем неоднократно.

Еще одна причина в боязни, что кто-то назовет твое творение говнокодом.

Здравствуйте, Mystic, Вы писали:

M>В жизни я чаще наблюдаю ситуацию, когда и в случае framework-а все равно приходится менять ручками одно слово на сотне экранных форм.

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

Здравствуйте, 0x7be, Вы писали:

0>Желание придушить разработчиков этой фигни у меня возникает минимум раз в день

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

Все обобщенные высказывания не соответствуют действительности.
В том числе и это.

Здравствуйте, Mystic, Вы писали:

M>Я бы добавил еще недооценку сложности проблемы и переоценку собственных сил.
+500

M>Ну и мозг подставляет подножку своим умением натягивать сову на глобус. Изучив 5-10% описания проекта, мозг подгоняет оставшееся под уже привычные шаблоны, в результате чего возникает ощущение, что создание framework-а это просто самый рациональный быстрый способ создания программного продукта. А потом оказывается, что абстракции, которые в первом приближении так идеально отвечали всем потребностям проекта, ни фига не работают. Попытка решить одним потоком управления несколько разных задачи приводит к классической дилемме "хвост вытащишь — нос воткнешь, нос вытащишь — хвост воткнешь".
Увы, есть такое. Желание творить часто искушает неокрепшие души

Здравствуйте, c-smile, Вы писали:

CS>У меня несколько противоположный опыт.
CS>Все успешные и серьезные компании которые имеют какой-нибудь успех используют свои собственные frameworks и platforms.
Заметь, это успешные компании и успешные фреймворки

Я же говорил не о них, а о том мыслительном процессе, который приводит к появлению провальных фреймворков и проектов.

Здравствуйте, Muxa, Вы писали:

M>Все обобщенные высказывания не соответствуют действительности.
M>В том числе и это.
Абсолютно согласен.
Как это относится к моей гипотезе?

Здравствуйте, Lazin, Вы писали:

L>Ну ведь можно не писать "фреймверк", а писать библиотеки, решающие только одну задачу, а гибкость получать за счет комбинирования таких библиотек.

+1, буквально недавно это обсуждали:

EP>Мне вот интересно, как и откуда появился феномен тяги Java'истов к framework'ам? Поясню:
EP>Есть библиотеки — наборы готовых компонент, функций, структур данных, алгоритмов и т.п. Их легко применять — они не влияют на общую структуру приложения, полностью ортогональны, т.е. никак не мешают друг на другу. Это, грубо говоря, рабочие инструменты — как молоток или пила.
EP>А есть фрейморки — в буквальном смысле типовой "каркас" приложения (или его часть). Фрейморки более тяжёлые, громоздкие, неповоротливые и зачастую несовместимые. Но если вся структура приложения, либо его часть, достаточно типовое — то тут действительно применение готового каркаса, по "типовому проекту" — вполне оправданно.

M>>Все обобщенные высказывания не соответствуют действительности.
M>>В том числе и это.
0>Абсолютно согласен.
0>Как это относится к моей гипотезе?

К гипотезе — никак. Относится к заголовку.
Мне, например (а под "нам" в заголовке я понял и себя в том числе), не нравится.

Здравствуйте, vdimas, Вы писали:

V>Мдее...
V>Опиши в MSI только продукты и компоненты. Не возись с файлами, зависимостями и прочей "наркоманией", если не хочешь.
V>Перехвати требуемые custom actions и пусть в них работают твои bat-скрипты.

И для чего тогда этот инсталер ?

Здравствуйте, Muxa, Вы писали:

M>К гипотезе — никак. Относится к заголовку.
M>Мне, например (а под "нам" в заголовке я понял и себя в том числе), не нравится.
Ну так это же наброс, тут так положено

Здравствуйте, vdimas, Вы писали:

V>Ну, право, это как критиковать сегодня морально устаревший набор кодов Интел-совместимых процессоров, со всеми их расширениями SSEx, где итоговая бинарная кодировка одна из САМЫХ НЕОПТИМАЛЬНЫХ В ИНДУСТРИИ! И чё??? Да ничё. Все понимают, никто и не спорит, но это никого не парит.
Это должно парить разработчиков CPU, нет?
На всякий случай напомню вам посмотреть в заголовок топика и перечитать моё сообщение, на которое вы отвечаете.

V>Ну, вообще-то, в той информации достоверно прослеживаются уникальные ключи и связи. Таки стоит взглянуть на схему базы — она относительно несложная.
О да. Какие-то 100 таблиц.

V>Т.е. реляции предоставляются предметной областью, поэтому огульно высмеять её не получится никак, увы.
Конечно же получится. Из "предметной области" там только две таблицы (плюс одна со связями). Всё остальное — чистая придумка мегаархитекторов.

V> Можно лишь поспорить относительно отдельных таблиц и связей. Я соглашусь только с иронией по поводу представления UI, но блин, в сотый раз оговорюсь, что эта ирония бессмыслена изначально, бо с выходом самой первой версии инсталлера в его SDK был тул по визуальному редактированию и тестированию UI.
Тул здесь совершенно ни при чём. Речь о том, что негодна сама идея реляционного описания UI.
Во-первых, это новый стандарт, требующий разработки отдельного тула, который стоит денег. Во-вторых, этот стандарт сразу ещё более ограниченный, чем даже dialog templates, т.к. не допускает расширения.
Хорошая платформа — это та, где для объём рукописного кода линеен относительно "площади поверхности". А в MSI для того, чтобы добавить на форму один контрол, не предусмотренный реляционной структурой, надо полностью отказаться от стандартного UI и воспроизводить и тестировать весь boilerplate руками.
С точки зрения пользователя такое решение — спорно. С точки зрения архитектуры — некомпететно.

V>Аналогично языка представления зависимостей. Он полон в декларативном смысле в терминах ВСЕХ объектов, описываемых базой инсталлера. Поэтому, да, некие вещи, выходящие за рамки информации, оперируемой инсталлерами, в нем описать нереально. Но это и хорошо — иначе бы это была дыра в безопасности.
Вы сегодня решили побить рекорд плотности чуши на одно сообщение? Включение custom action, которые выполняются под elevated privileges — это не дыра в безопасности, а описание в Condition "вещей, выходящих за рамки информации, оперируемой инсталлерами" — дыра? Поздравляю.

V>Мы используем Wise для чего-то уникального и только для совсем типовых пакетов — WiX, так что ничего сказать не могу. Последний раз, когда я пользовался InstallShield в 2003-м, он полностью удовлетворял всем моим нуждам.
Это много говорит о ваших нуждах. Кроме того, в 2003 вы запросто могли использовать InstallShield в режиме wrapper. Был у них такой подход одно время: их самопальный инсталлер тупо заворачивался в один transient компонент в MSI, который был, фактически, только запускальщиком инсталляции.

V>Я изучал подробно, но для чуть других целей — для целей генерирования скриптов автоматической установки софта.
В прошлый раз вы, помнится, "подробно изучали исходники SQL Server". На этот раз вы решили изучить устройство MSI, чтобы научиться писать скрипт, вызывающий msiexec.exe с нужными ключами? Похвально, похвально.

V>Нет, это ты спросил, как обойтись без ВСЕЙ "наркоманской" базы, я тебе подсказал. Тебе достаточно использовать ту её часть, где реляционное представление как нельзя к месту. Ну вот подыграл твоему "чувству прекрасного", не более того.
Ну, безо всей, как выясняется, обойтись нельзя. Вы же в курсе, что если у ваших компонентов есть понятие версии, то без файлов обойтись никак не удастся? Или этот уровень подробностей остался за пределами вашего "подробного изучения"?

V>Ну тогда опять и снова для особо одарённых — я подсказал простой способ получения достоверно работающего результата на имеющемся почти у всех девелоперов инструментарии. Это был ответ на "ай-ай, проблемы с custom actions". )))
Вы подсказали простой способ написать hello world. Спасибо, конечно, но этот этап я давно прошёл.

V>Можно подробнее — в чем именно геморрой?
В том, чтобы написать custom action, который корректно отрабатывает все режимы.
Вы почитайте немножко вот здесь: http://msdn.microsoft.com/en-us/library/aa368070(v=vs.85).aspx

V>Я понимаю для чего нужен WiX, но вижу непонимание у тебя. Этот DSL всё еще низкоуровневый, он плохо маскирует низлежащую платформу, поэтому пользоваться им напрямую для чего-то повторяемого — глупо.
Как раз им и пользуются. В MSI сделать повторно используемый custom action практически невозможно. А в WiX их дофига, и можно добавлять свои: http://wixtoolset.org/documentation/manual/v3/customactions/

Здравствуйте, vdimas, Вы писали:

C>>При том, что на вражеских платформах типа Линукса это же делается без особых проблем.
V>Давай конкретней, что вызывает проблемы в MSI и что делается легко в том же RPM?
Да банально сделать галочки "установить сервис"/"запускать сервис при запуске"/"запустить сейчас" с полем ввода для имени сервиса. С валидацией и возможностью unattended installation. Потом ещё указание каталога для файлов лога и настройки уровня логгирования.

Это то что я лично делал, в обоих системах.

V>А то, сдается мне, что ты пытаешься простой сценарий в RPM сравнить со сложным в MSI.
V>Как по мне, то что-то более-менее нетривиальное в RPM — еще больший ад.
В DEB всё просто — берёшь и пишешь простой shell-код. Вопросы задаются с помощью удобной и простой диалоговой системы, ответы которой могут скриптоваться.

Здравствуйте, vdimas, Вы писали:

V>Кста, вот причина этого бестолкового спора. В непонимании, что есть инсталляция ПО с т.з. ОС.
V>Для ОС установка SQL-сервера — это установка, грубо говоря, бинарных файлов (и вспомогательных для их работы). Поэтому во время установки надо обыграть лишь существование различных бинарных версий сервера, а это прекрасно обыгрывается.
Это вы, наверное, с Linux перепутали. Для windows установка SQL-сервера — это, грубо говоря, установка бинарных файлов, прописывание большого количества данных в реестр, регистрация сервисов и их зависимостей, переаттач существующих баз данных, настройка w3c сервисов и правил windows firewall и много чего ещё.

V>Создание и удаление инстансов вовсе не требует переустановки бинарного образа программы SQL-сервака.
Неважно, чего она требует или не требует. "Установка бинарного образа" — это, простите, копирование файлов, и оно прекрасно делается при помощи шелл-команды copy. А инсталлятор в windows обязан привести систему в рабочее состояние — т.е. сделать все те вещи, которые по-вашему делаются "после" инсталляции.

V>То бишь, по классике жанра это может быть сделано ПОСЛЕ инсталляции. Автоматом запустить утилиту конфигурирования инстансов сервака после его установки не сложно, ИМХО.
Добро пожаловать в реальный мир, Нео. В настоящем инсталляторе настоящего SQL Server (а не того, который вы себе смело вообразили) пришлось прятать 16 product keys, чтобы обеспечить возможность ставить/удалять инстансы независимо друг от друга.

единожды установленный SQL сервер практически невозможно снести, что бы начисто. Это регистрация, читай патч, чуть не всего что есть в системе — конфиги, реестры и все подряд.

Здравствуйте, eugene0, Вы писали:

E>Компания А., фреймворк Ф.?

Оно самое.
Это, наверное, самый эпичный пример из моей личной практики.

E>По сути вопроса, фреймворк писать прикольно, кажется, что делаешь большое дело, которое, когда выстрелит, все сразу поможет и все оценят. Гораздо интереснее, чем пилить боковой винтик какого-нибудь продукта, о котором, возможно, никто и не вспомнит.
E>С другой стороны, по опыту с фреймворком очень просто ошибиться в оценке трудоемкости. Обычно кажется, что все не так уж сложно

E>И в третьих, больше вероятность, что пригодятся знания темных уголков ЯП, которые в обычных прикладных задачах обычно не нужны. Например, С++ шаблоны хитрозавернутые. Я же их знаю, книжку читал. Но в прикладных задачах они обычно ни к чему. Вот сейчас напишем фреймворк, заодно и шаблоны применим.
По-моему, всё очень точно подмечено

Здравствуйте, vdimas, Вы писали:

I>>

единожды установленный SQL сервер практически невозможно снести, что бы начисто. Это регистрация, читай патч, чуть не всего что есть в системе — конфиги, реестры и все подряд.

V>Многие программы гадят в реестре и что?

V>Для того и нужен MSI, чтобы система достоверно знала, какие ветки реестра грохать. А SQL-севак лишь отчасти ставится через MSI, а еще приличную часть работы выполняется вне MSI, рукописным его экзешником-инсталлятором. Т.е. ты сам же привел хороший пример того, что бывает, когда установка идет "ручками" — получается хаос, как в эпоху до MSI.

Хаос не потому,что руками, а потому что типичная инсталяция сервера это несколько инстанцев одной или разных версий на одной тачке и каждая из которых патчит столько, сколько никому даже в страшном сне не приснится.

"business-value" "KPI" "product launch" "sales boost" и вот это всё прочее "говна пирога"...
Это всё не о технической части, на это всем пофиг. Буизнесс вэлью ога)))

Здравствуйте, TimurSPB, Вы писали:

TSP>"business-value" "KPI" "product launch" "sales boost" и вот это всё прочее "говна пирога"...
TSP>Это всё не о технической части, на это всем пофиг. Буизнесс вэлью ога)))
Окей, а почему оно так?

Здравствуйте, 0x7be, Вы писали:

0>...

В основе — потребность ощущать себя творцом, а не ремесленником.

Здравствуйте, Sinclair, Вы писали:

S>Добро пожаловать в реальный мир, Нео. В настоящем инсталляторе настоящего SQL Server (а не того, который вы себе смело вообразили) пришлось прятать 16 product keys, чтобы обеспечить возможность ставить/удалять инстансы независимо друг от друга.

О как. А можно чуть больше этнографических подробностей? Мне уже просто интересно, чего там такого навернули.

А то у нас всё как-то очень тривиально — таким зверям, как mysql или postgres, даёшь 2-5 простых командных ключей (хотя и их можно было бы свести в один плоский конфиг) и он начинает работать полностью независимо от такого же соседа. В некоторых местах типа Debian это ещё и автоматизировано на уровне стартапа.

Здравствуйте, netch80, Вы писали:

N>О как. А можно чуть больше этнографических подробностей? Мне уже просто интересно, чего там такого навернули.
Я не всё помню, за давностью лет, но ЕМНИП они подменяют PRODUCT KEY в зависимости от выбора пользователя — апгрейдить существующий продукт или ставить side-by-side. Ну и при апгрейдах примерно то же самое происходит.

Здравствуйте, Sinclair, Вы писали:

S>А программист Дима [...] То винда у заказчика находится не на диске С:\

Не правда, не было такого!!!

Здравствуйте, andyag, Вы писали:

A>А потому что не надо "брать и делать фреймворк". Фреймворк должен появляться постепенно как результат ежеминутного рефакторинга существующего работающего кода.

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

Здравствуйте, dimgel, Вы писали:

D>Не правда, не было такого!!!
Повезло, значит, с заказчиками

У меня есть объяснение проще. Люди в детстве ненаигрались/переигрались в детскую железную дорогу и теперь гоняют вагончики фабрик классов, делегатов и прочих прикольненьких абстракций

Здравствуйте, netch80, Вы писали:

N>История и Unix, и Windows — история успеха того, что началось как "склёпанный быстро поток кода", превращённый в платформу, пережил несколько десятилетий.

Винда срисовывалась с VMS.

Здравствуйте, 0x7be, Вы писали:

CS>>У меня несколько противоположный опыт.
CS>>Все успешные и серьезные компании которые имеют какой-нибудь успех используют свои собственные frameworks и platforms.
0>Заметь, это успешные компании и успешные фреймворки

0>Я же говорил не о них, а о том мыслительном процессе, который приводит к появлению провальных фреймворков и проектов.

Процитирую то, что было выше: "Amazon, Google, Twitter, Facebook, Microsoft и т.д. "

Google — проект ЦРУ.
Facebook — проект АНБ.
Microsoft — IBM поделилась надвое.
Twitter — охблин, какой продукт-то мощный, чвик-чвик. Chatroulette примерно того же класса.
Amazon — не знаю достоверно, прибыльность у них около нуля, зато акции растут. Откуда такая магия? Особая финансовая магия?

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

Здравствуйте, Cyberax, Вы писали:

C>При том, что на вражеских платформах типа Линукса это же делается без особых проблем.

Оооо! Расскажите мне про инсталлеры на линуксе. Как их делать? Подразумевается создание .deb?

Здравствуйте, netch80, Вы писали:

N>Это ерунда, потому что не даёт ответа на первый же встречный вопрос: почему такой "ощущает себя творцом" только когда написал фреймворк, а не радуется творению конкретного программного продукта, соответствующего своей цели и удовлетворяющего пользователей?

Мне задают вопрос — в чем ценность твоей программы? Я отвечаю — она работает и выполняет свою задачу. В ответ я слышу смех.

Здравствуйте, ononim, Вы писали:

O>У меня есть объяснение проще. Люди в детстве ненаигрались/переигрались в детскую железную дорогу и теперь гоняют вагончики фабрик классов, делегатов и прочих прикольненьких абстракций
Те же яйца, вид сбоку

Игра потому и игра, что в неё играть приятно.

Здравствуйте, Слава, Вы писали:

С>Успешность вашего проекта не зависит от уровня вас, как программистов, от уровня менеджмента, от вашей работы вообще. Если у вас есть источник неограниченного финансирования, как у вышеперечисленных, вы будете успешны. Иначе — работать будете в поте лица, автоматизировать склад, с которого маслом и сыром торгуют, вам даже денег дадут — в сумме, сколько стоит газелька-тент, доверху груженная сыром. Могучая сумма, ага, на всю контору если поделить. А ваше конкурентное преимущество будет состоять в том, что хозяину склада градиент на кнопочках понравился.
Успешность компании, конечно, зависит не только от работы программистов. А зачастую, она от них не зависит почти никак.
Например, значительная часть российского ИБ работает по схеме "откаты и сертификаты", здесь качество продукта влияет на порядок меньше правильных связей.
Впрочем, я в дебри бизнеса в этой теме залезать и не планировал, слишком богатая тема

Здравствуйте, Слава, Вы писали:

C>>При том, что на вражеских платформах типа Линукса это же делается без особых проблем.
С>Оооо! Расскажите мне про инсталлеры на линуксе. Как их делать? Подразумевается создание .deb?
DEB/RPM делаются по мануалам. Если хочется что-то более новое — Flatpak и Snap.

Здравствуйте, Слава, Вы писали:

N>>История и Unix, и Windows — история успеха того, что началось как "склёпанный быстро поток кода", превращённый в платформу, пережил несколько десятилетий.
С>Винда срисовывалась с VMS.
С VAX была срисована NT. Винда к ней отношения не имела, к моменту создания NT уже был Win16 API и DOS.

Здравствуйте, Privalov, Вы писали:

P>Раз уж тему подняли...
P>На самом деле™, если команда получает готовый фреймворк, она не начинает делать с его помощью целевую задачу. Вместо этого во фреймворке находят кучу недостатков и начинают активно их исправлять.
Ну, конечно же, ведь в готовом фреймворке, очевидно, есть фатальный недостаток™

P>Я тоже участвовал. Проект в конечном итоге запустили. Но времени это затребовало на 2.5 года больше, чем планировалось. Мне в результате все эти 2.5 года пришлось параллельно тащить старый проект, что-то в нем постоянно допиливая и исправляя.

Знакомая картина.
Кстати, проект из п.3. примерно так и завернул — решено спешно реанимировать прошлую версию, чтобы было что продавать

Здравствуйте, 0x7be, Вы писали:

0>Зло, о котором я говорю — это именно такой подход, а не результат.
Видел тоже самое.
0>Вообщем, наброс сделан, жду ваших мнений

Это сродни графомании, т.е. проблема в конкретных людях которые потакают конкретным проблемам своей психики. Возможно, такое связано с идеалистическими и/или перфекционистическими взглядами, либо банальной прокрастинацией и неуменеим завершать задачу. Возможно, под этим соусом подаётся неумение показать реальный рещультат, ведь всегда на вопрос "что ты делаешь" можно ответить "пилю фреймворк", а в реальности ничего что работало бы и не видно, ха-ха!

Здравствуйте, Kernan, Вы писали:

K>Это сродни графомании, т.е. проблема в конкретных людях которые потакают конкретным проблемам своей психики. Возможно, такое связано с идеалистическими и/или перфекционистическими взглядами, либо банальной прокрастинацией и неуменеим завершать задачу. Возможно, под этим соусом подаётся неумение показать реальный рещультат, ведь всегда на вопрос "что ты делаешь" можно ответить "пилю фреймворк", а в реальности ничего что работало бы и не видно, ха-ха!
По моему мнению, это в первую очередь узость картины мира, куда не попадает ответ на вопрос "зачем это вообще делается?"
Подобные извороты всегда я наблюдал именно тогда, когда разработка варилась в собственном соку, выдумывая себе критерии успеха, а не соотнося их с потребностями бизнеса.

Здравствуйте, andyag, Вы писали:

0>>Вообщем, наброс сделан, жду ваших мнений

A>Как только программист глядя на описание новой фичи задаёт вопрос "зачем?", его тут же выгоняют в тимлиды, а потом в менеджеры проектов. Программистами остаются только те, кого интересует только написание кода за деньги

Это работает только в супермелких конторах, где все и всё на виду.

Здравствуйте, Artifact, Вы писали:

0>>Я не говорю, что фреймворки и платформы — это зло и их не надо разрабатывать в принципе.
A>У вас была одна проблема. Для её разработки вы решили сделать/использовать платформу/фреймворк — теперь у вас две проблемы

две обычно меньше чем одна большая

Здравствуйте, 0x7be, Вы писали:

М>>ЗЫ. когда я начинал изучать JS, то первое что я стал писать -- это логгер. шеф покрутил пальцем и виска и показал на готовый, которым до сих пор пользуюсь.
0>Боюсь, есть недопонимание. Я ничего не имею против фреймворков в принципе, я имею кое-что против определённого ущербного мыслительного процесса, который приводит к появлению нежизнеспособных фреймворков.

Жизнеспособные фрэймворки могут появиться только как обобщённое решение уже когда-то решённых проблем. Если решать общую задачу вместо частной, то да, появится нежизнеспособный фрэймворк.

Здравствуйте, Философ, Вы писали:

Ф>Жизнеспособные фрэймворки могут появиться только как обобщённое решение уже когда-то решённых проблем. Если решать общую задачу вместо частной, то да, появится нежизнеспособный фрэймворк.
Это понимание приходит с потом и кровью после наивных попыток сделать наоборот.

Здравствуйте, 0x7be, Вы писали:

0>Вообщем, наброс сделан, жду ваших мнений

Фреймфорики и "общие шины" это попытка не только решить проблему заказчика, но и построить за его счет тиражируемое решение которое будет кормить программиста долгие годы. Фактически удочка vs рыба.

Здравствуйте, pestis, Вы писали:

P>Фреймфорики и "общие шины" это попытка не только решить проблему заказчика, но и построить за его счет тиражируемое решение которое будет кормить программиста долгие годы. Фактически удочка vs рыба.
Я с этим полностью согласен. Другое дело, что в описываемых случаях за такую разработку берутся необоснованно. Зря тратят время и деньги, получают в итоге кучу сверхсложного легаси с огромной стоимостью владения.

Здравствуйте, 0x7be, Вы писали:

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

В смысле необоснованно? За разработку платит заказчик, а результат получают программисты. Это ли не счастье?

Здравствуйте, Sinclair, Вы писали:

S>Если уж захотелось откопать мёртвую тему, потрудитесь ознакомиться с предметом дискуссии.

Недержание?

S>Речь идёт о принятии архитектурных решений — на момент проектирования WI никакого SDK и тула не было.

MSI SDK шел изначально с MSI и уж тем более на дату начала этого обсуждения уже давно как был.
Остальные заламывания рук скипнул.

Здравствуйте, Sinclair, Вы писали:

V>>MSI создавался для установки продуктов офиса.
S>О, у вас появилась новая идея, как оправдать идиотскую точку зрения "windows installer архитектурно оправдан".
S>Вообще-то — нет. WI позиционировался как штатный инструмент для установки чего угодно.
S>Да, многие сценарии в нём были навязаны офисной командой.

Для особо упоротых — этот продукт под офис и разрабатывался. А потом стал позиционироваться "для всего".

Вот тут совсем поржал:
S>Вы посмотрите на это со стороны производителя — выброшены мега-деньги; кто-то сидел, ночей не спал, придумывая структуру табличек с контролами. Кто-то писал тул. QA гоняло всю эту чушь туда-сюда. Документация писалась и переводилась на разные языки. А на практике — нихрена это никому не помогает: всё уехало в помойку. Все, даже признанные знатоки MSI типа vdimas, пишут нативные диалоги вместо реляционного убожества.

По-сути, ты предлагаешь ограничить возможность разработки кастомных контролов. Т.е. надо было дать некую UI-библиотеку сугубо для инсталлера. А если у меня есть свои контролы (в дотнете, нейтиве, в другой какой-нить технологии — не важно), то, вместо их повторного использования в кастомных своих диалогах/визардах, я должен буду портировать их реализацию на вот эту прибитую к MSI гвоздями технологию. И кто-то тут еще рассуждает о "грамотном дизайне"...

Кароч, пару лет прошло, а ты до сих пор за деревьями леса не видишь. WI — это, в первую очередь, движок.
Ты можешь вообще всё ГУИ инсталлера нарисовать самому и пользоваться MSI API сугубо для того, чтобы дергать ф-ии этого АПИ.

S>Дело не в указании адреса/инстанса, а в том, что ломается весь механизм проверки наличия предыдущих версий софта — потому что их может быть одновременно много.

Т.е. ты НИ РАЗУ не передавал как параметр своим custom actions инстанс текущей инсталляхи и НИ РАЗУ не дергал MSI API из своих кастомных акций?
Какой ужас... ))
А как ты вообще эти кастомные действия пишешь? Что ты в них можешь полезного сделать без инстанса текущей инсталляхи?

Здравствуйте, vdimas, Вы писали:

V>MSI SDK шел изначально с MSI и уж тем более на дату начала этого обсуждения уже давно как был.
ОМГ, вы совсем неспособны понять предмет дискуссии?
Мы говорим не о времени начала дискуссии. А о моменте, когда Installer Team была сформирована и ей была поставлена задача разработать архитектуру Windows Installer.
Я думаю, что это эпохальное событие произошло когда-то в девяностых.

Здравствуйте, vdimas, Вы писали:
V>Для особо упоротых — этот продукт под офис и разрабатывался. А потом стал позиционироваться "для всего".
У вас есть какое-то подтверждение этой забавной теории?

V>По-сути, ты предлагаешь ограничить возможность разработки кастомных контролов. Т.е. надо было дать некую UI-библиотеку сугубо для инсталлера.
Нет. Надо было
1. Обеспечить совместимость с Dialog Templates для максимизации использования тулчейна
2. Обеспечить возможность subclassing и superclassing так же, как в стандартных диалогах — чтобы объём работы зависел от количества нестандартных требований линейно, а не скачкообразно.

Ваши предложения по возможной архитектуре UI в Windows Installer я поскипал — там нечего комментировать.

V>Ты можешь вообще всё ГУИ инсталлера нарисовать самому и пользоваться MSI API сугубо для того, чтобы дергать ф-ии этого АПИ.
При чём здесь MSI API? Я вам о том, что вся структура пакета — бред наркомана.
V>Т.е. ты НИ РАЗУ не передавал как параметр своим custom actions инстанс текущей инсталляхи
Что вы называете "инстанс текущей инсталляхи"? hInstall ? Это совсем не то же самое, что инстанс SQL Server. Просто называется похоже.
Впрочем, от человека, который путает Skype со Skype for Business, я иного и не ожидал.

V>А как ты вообще эти кастомные действия пишешь? Что ты в них можешь полезного сделать без инстанса текущей инсталляхи?
Я так понимаю, что за вот этими модными словами скрывается банальный вызов MsiGetProperty()?
Потому что другого способа передать инфу в custom action и нету.

Здравствуйте, pestis, Вы писали:

P>В смысле необоснованно? За разработку платит заказчик, а результат получают программисты. Это ли не счастье?
Что-то программисты там особо счастливыми не выглядели...

Здравствуйте, Sinclair, Вы писали:

V>>MSI SDK шел изначально с MSI и уж тем более на дату начала этого обсуждения уже давно как был.
S>ОМГ, вы совсем неспособны понять предмет дискуссии?

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

S>Мы говорим не о времени начала дискуссии. А о моменте, когда Installer Team была сформирована и ей была поставлена задача разработать архитектуру Windows Installer.
S>Я думаю, что это эпохальное событие произошло когда-то в девяностых.

Это эпохальное событие произошло одновременно с выпуском MS Office 2000, когда в папке с пререквизитами к нему впервые засветился WI и его надо было самому ручками устанавливать перед установкой офиса.

Здравствуйте, Sinclair, Вы писали:

V>>Для особо упоротых — этот продукт под офис и разрабатывался. А потом стал позиционироваться "для всего".
S>У вас есть какое-то подтверждение этой забавной теории?

Конечно есть — это официальный пресс-релиз Ms Office-2000, где впервые упоминается новый инсталлятор.
Неверующие могут скачать с MSDN-подписки (ну или с торрентов) оригинальный образ дисков этой версии офиса и дополнительно лично убедиться.

V>>По-сути, ты предлагаешь ограничить возможность разработки кастомных контролов. Т.е. надо было дать некую UI-библиотеку сугубо для инсталлера.
S>Нет. Надо было
S>1. Обеспечить совместимость с Dialog Templates для максимизации использования тулчейна

Ну вот я так и думал, что полезных предложений не будет.
Во-первых, давно существуют дизайнеры диалогов WI, они ничуть не уступает дизайнеру диалогов Dialog Templates.
А если ты рассуждал о неких "массовых продуктах", то можно было вообще взять что-нить типа этого:
http://www.advancedinstaller.com/download.html
Это копейки, если продукт действительно массовый.

Я уже молчу о куче продуктов попроще, включая тот же WixEdit.

Во-вторых, о совместимости говорить нелепо хотя бы потому, что к контролам в WI можно привязывать некие стандартные действия, а в случае Dialog Templates — нельзя. Ну и набор контролов чуть другой, местами пересекается, местами нет.

В-третьих, сама попытка утверждать, что загвоздка в дизайнере диалогов — это заведомо слить спор. ))
Их было более одного сразу же.

S>2. Обеспечить возможность subclassing и superclassing так же, как в стандартных диалогах — чтобы объём работы зависел от количества нестандартных требований линейно, а не скачкообразно.

Сам не видишь разве, что такие рассуждения попахивают тем, что ты "сабклассил" ручками уникально каждый диалог в нейтивных приложениях, т.е. перехватывал события на стороне parent, без reflection? Не, пару раз и я таким макаром упал-отжался, но исключительно для удовлетворения собственного любопытства.

А если по-делу, то некий GUI-контрол пишется один раз и затем многократно используется.

Но и этого НЕ надо. Когда тебе кажется, что гуйный визард установщика листает некие "вложенные" страницы внутри одного "объемлющего" окошка верхнего уровня — это подлый обман зрения. Каждый диалог создаётся абсолютно с 0-ля, это новый оконный хендл, т.е. новое независимое окно. Общего у них — только хендл текущей инсталляхи. И ты меня что пару лет назад удивлял, что сегодня, показывая непонимание этой простой вещи.

А суть этой простой вещи в том, что возьми, создай свой любой диалог на любой знакомой тебе технологии и дёргай АПИ инсталлера.

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

В наличии есть даже упрощенный вариант COM-библиотеки инсталлера, которую можно юзать из VBScript, основной объект — Session. Вот прямо из этого объекта можно читать некие property, устанавливать их (по результатам работы своих диалогов) и т.д. А эти property потом уже используют последующие custom actions. Т.е. важно отделять действия, которые можно охарактеризовать как install/commit/rollback от действий, которые являются просто "collect some data".

Я как-то просто из VB-скрипта рисовал кастомные диалоги через стандартную ActiveX-библиотеку Microsoft Forms 2.0.

Т.е. разговор ни о чем, проблемы де-факто нет.
Там одна проблема в том, что твои диалоги должны рисоваться уже неким установленным кодом, т.е. нельзя на них "вытащить самого себя за волосы". ))
Ну, дык, уж как минимум один диалог (приветственный) можно сваять на предоставляемой технологии.

S>Ваши предложения по возможной архитектуре UI в Windows Installer я поскипал — там нечего комментировать.

Э, нет, ты ничего не скипал, потому что я НИЧЕГО не предлагал. Я лишь попытался выудить из тебя хоть какой-то конструктив, тип — а что в замен-то? Какую-нить уникальную технологию? Ну вот ты предложил сабкласить окна визарда. Как по мне, то это бред, хотя... кто мешает делать это прямо сейчас? )) Никогда раньше не садился сверху "чужого" диалога, не сабклассил его контролы и не добавлял в диалог установки своих контролов на лету?

Фишка в том, повторюсь — а откуда должен исполняться этот твой кастомный код? Где в этот момент будет располагаться та программа, которая исполняет этот код? Причем, "сабклассить" ограничивает нас нейтивом, пральна?

V>>Ты можешь вообще всё ГУИ инсталлера нарисовать самому и пользоваться MSI API сугубо для того, чтобы дергать ф-ии этого АПИ.
S>При чём здесь MSI API? Я вам о том, что вся структура пакета — бред наркомана.

А уж какой бред наркомана машинный код x86...

Я уже отвечал тебе на это — ты не о том рассуждаешь. Тебе ручками в структуре пакета ковырять не надо, как не надо программировать в машинных кодах. Есть полно высокоуровневых инструментов — SDK, WiX а так же возможность автоматизировать шаги по созданию инсталляхи через COM-скриптинг, что типа:
var installer = new Installer();
var db = installer.OpenDatabase(); // OpenProduct и т.д.
db.Export("Table", "Folder", "File");
db.EnableUIPreview().ViewDialog("Confirm Installation");

А так же можно делать слияние и разделение инсталлях.

Именно через написание своих скриптовых утилит я потом перегонял в WiX и обратно понравившиеся куски других пакетов инсталляций, рефакторил и мёржил их, как тырил когда-то на сайтах клиентский скриптинг, тоже рефакторил и допиливал напильником. )) Потому что в деле программирования "пример использования технологии" — это наипервейшая весчь.

Может, я поэтому с трудостями так и не столкнулся, хотя пришлось обыгрывать сценарии всяко сложнее, озвученных тобой до сих пор. Я всё жду от тебя настоящего challenge. ))

V>>Т.е. ты НИ РАЗУ не передавал как параметр своим custom actions инстанс текущей инсталляхи
S>Что вы называете "инстанс текущей инсталляхи"? hInstall ? Это совсем не то же самое, что инстанс SQL Server. Просто называется похоже.

Угу, способ ухода от прямого ответа — начать разговаривать с самим собой.
"инстанс SQL Server" — это вообще просто строковое св-во в рамках Session.

S>Впрочем, от человека, который путает Skype со Skype for Business, я иного и не ожидал.

Ы? ))
Так ты так и не понял как ты тогда сам себя утопил?

Я ничего не путал. Я говорил о сетевых принципах работы Skype. Ты можешь заходить в конференцию Skype For Business с обычного скайпа. Сюрпрайз? Не знал?

В общем, ты как всегда включил в том споре загадочное лицо и сообщил, что речь у тебя была о веб-версии скайпа. Ну типа уничтожил оппонентов, угу. Правда, тут же сам себя утопил, вспомнив о ссылке-активации на бинарное установленное приложение магазина, что решает проблему доступа в конференцию Скайпа прямо с сайта. Мне осталось лишь поржать и поставить тебе смайл...

А вообще, ты странный тип на этом сайте.
Вроде бы порой говоришь весьма умные вещи. Но чаще даёшь понять, что ты, всё-таки, нифига не программист и никогда им всерьёз не был.

Ну типа как вот эти твои комменты:

Ну, покажите мне, как описать компонент, который имеет версию, определяемую через custom action, и никак не отражён в файловой системе. Что будем писать в KeyPath?

Компонент имеет версию...

Я же говорил тебе — курить, что есть component.
Ну, блин, опытный программист быстро составит себе представление об основных сущностях любой технологии, которой оперирует.
Потому что программист — это циник. А ты не циник, ты мечтатель. Ты любую вещь будешь делать не как надо, не быстро и эффективно, а как тебе внутренне красиво, приятно и вообще "так и должно быть".

Детсад, как по мне.

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

Да, файл может быть частью компонента, но может и не быть. Важно, что у компонента НЕТ версий. Вот нет и всё. Любая твоя "версия" — это чисто прикладная хрень. И если ты способен хоть каким-либо образом закодировать/представить эту "версию" — ну так представь.

И почему именно как файл? А что мешает в виде сетевого запроса твоего сертификата?

$ echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Jun 19 12:44:04 2013 GMT
notAfter=Oct 31 23:59:59 2013 GMT

А компонент — это всего-навсего минимальная единица транзакции MSI.
Прикручивать версию к единице транзакции — ну это сильно, ИМХО. ))

Компонент же может быть сугубо виртуальный, т.е. не существующий в каком-нить реальном воплощении (по крайней мере в таком воплощении, о котором знает WI), т.к. install, commit и rollback могут быть какими-нить сетевыми запросами или запросами в БД.

Т.е. версию компонента можно сделать и без файла . В любом случае, понятие "версия" здесь получится сугубо прикладное, никак не связанное с иерархией сущностей WI.

Но лучше пользоваться встроенными сущностями инсталлера по-делу, а именно — там, где речь идёт о версиях/апгрейдах и кодах совместимости, использовать сущность Продукт, потому что у него есть ProductCode, в рамках которого уже можно организовать произвольную версионность. Да, иногда удобно, в случае когда один и тот же файл входит в разные продукты, пользоваться понятием версионности этого файла. Но тут сразу твои доводы превращаются в маразм, уж извини — если у нас такой сценарий возможен только для файла, то не стоило пенять на то, что для такого сценария обязательно нужен файл. Тем самым ты показываешь, что ты не программист. Логика того-с. :xz;

Или ты заламывал руки, что вот "а там, ПРЕДСТАВЛЯЕТЕ, несколько ключей продуктов зашито". ))
Это, надо понимать, проявление "продуктофобии"? Да какая тебе разница, сколько ключей продукта зашито?

Ты ты сообщил вслух (и очень зря), что SSL-сертификат у тебя "компонент".
А с какой радости ты, как разработчик, вдруг решил рассматривать его как "компонент"?

Или тут:

Весь GUI делается в custom action на привычном нам языке, да? Все реальные действия по деплойменту компонентов делаются в custom action, да? Прекрасное подтверждение моего же тезиса.

Рука-лицо опять.

"Я гарантирую" что ты подошел к инсталлеру вообще не с той стороны. НЕ понял ни его философии, ни для чего нужны основные сущности инсталлера.

В большинстве случаев задачей custom actions не является копирование чего-то куда-то или установкой флагов в реестре и проч — это даже вредно, потому что в таком случае "чистота" транзакционности инсталлера ложится на плечи автора этих действий. В большинстве случаев тебе надо породить и установить значение некоего текстового property для сессии, продукта, фичи и т.д., которое (значение св-ва) невозможно породить встроенными ср-вами инсталлера. Ну вот, строку подключения к какому-нить кастомному приложению или к БД, например.

Для твоей задачи одно кастомное действие должно было сравнить некую "прикладную версию" SSL сертификата (предположим, его expiration date) с неким встроенным в инсталляху св-вом и в кач-ве результата установить еще какое-нить прикладное св-во, типа "NeedToUpgradeSertificate", по которому далее ветвиться в других шагах инсталляции.

Здравствуйте, vdimas, Вы писали:

V>Я не могу понять, чего ты бегаешь от простых аргументов, прямых вопросов и той самой конструктивной критики, когда не озвучиваешь собственные предложения по критикуемым вещам.
Я как раз не бегаю. "Аргументы" у вас к теме дискуссии не относятся, и построены в стиле ботов из поддержки Микрософта. Это которые мне пересказывают мой же вопрос другими словами.
Я говорю "архитектура UI — отвратительная, использовать её невозможно, приходится полностью реализовывать свой UI вместо расширения коробочного". Вы мне в ответ "да там вообще весь UI можно самому переписать".
А вот вы бегаете от прямых вопросов, в трудных местах отделываясь намёками. Вы уже придумали способ задетектировать версию кастом-компонента, который не представлен дисковым файлом?

S>>Мы говорим не о времени начала дискуссии. А о моменте, когда Installer Team была сформирована и ей была поставлена задача разработать архитектуру Windows Installer.
S>>Я думаю, что это эпохальное событие произошло когда-то в девяностых.
V>Это эпохальное событие произошло одновременно с выпуском MS Office 2000, когда в папке с пререквизитами к нему впервые засветился WI и его надо было самому ручками устанавливать перед установкой офиса.
То есть вы думаете, что они сначала выпустили офис 2000, а потом была разработана архитектура WI? Выделенное болдом перечитайте.

Здравствуйте, Sinclair, Вы писали:

V>>Конечно есть — это официальный пресс-релиз Ms Office-2000, где впервые упоминается новый инсталлятор.
S>Вот этот пресс-релиз: https://news.microsoft.com/1999/06/07/microsoft-office-2000-an-essential-tool-for-all-knowledge-workers-is-available-this-week/#sm.0000k2gfry19ipcx7ycv15b09qwvy

Нет, не этот.

S>Никаких описаний инсталлятора, естественно, нету.

Кто бы сомневался, что простейшие вещи вызовут у тебя трудности.
Неужели сложно было поискать по ключевым словам?

V>>Неверующие могут скачать с MSDN-подписки (ну или с торрентов) оригинальный образ дисков этой версии офиса и дополнительно лично убедиться.
S>Муа-ха-ха. Ждём от вас цитату в студию. На всякий случай напомню, что речь не о том, что офис ставился через Windows Installer — это, конечно же, правда.

Офис был первой программой и долгое время единственной, которая ставилась через инсталлер.

S>А о том, что он проектировался для офиса, и решение его использовать для чего-то ещё было принято потом.

Ожидаемо простейшие вещи снова вызывают трудности.
Когда появилась первая ДРУГАЯ программа, использующая инсталлер?

V>>Ну вот я так и думал, что полезных предложений не будет.
V>>Во-первых, давно существуют дизайнеры диалогов WI, они ничуть не уступает дизайнеру диалогов Dialog Templates.
S>Да что за бред-то! Я же вам на этот аргумент уже отвечал трижды! Повторю ещё раз: это сейчас существуют дизайнеры диалогов. А мы говорим о решениях, принятых 1997 году, когда изобреталась технология WI.

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

S>Не было никаких дизайнеров! Была Visual Studio 6.0.

И где ты там увидел редактор диалогов для инсталяхи?
Там можно было выбрать лишь один из предопределённых диалогов, но не рисовать свой.

V>>А если ты рассуждал о неких "массовых продуктах", то можно было вообще взять что-нить типа этого:
V>>http://www.advancedinstaller.com/download.html
S>Вы полностью подтверждаете мою точку зрения.

Влажные фантазии. Я цинично высмеиваю твою точку зрения.

S>Я вам говорю — архитектура говённая.

Мнение. К тому же НЕ конструктивное, т.к. от конструктива ты упорно бегаешь.
Человека с техническим складом ума должен больше интересовать список возможностей технологии, а не тонкости её реализации.

S>А вы мне перечисляете коммерческие средства по замазыванию проблем этой архитектуры.

Да пиши на ассемблере, хосподя. Зачем тебе высокоуровневые языки программирования?
А зачем тебе базы данных? Пиши сразу в файл и каждый раз ручками разруливай целостность данных.
Вот такие у тебя аргументы.

S>Ога, типа "самсунги взрываются" — "а вы его в портативном сейфе носите".

Пока что ты пытаешься позвонить с отдельно взятого аккумулятора. А я предлагаю тебе пользоваться девайсом в сборе.

И да, самсунги пока взрывались только в США, что как бэ намекает, что этот мем еще рано выпускать в тираж. Сдаётся мне, что корейцев цинично разводят на бабки.

V>>Во-вторых, о совместимости говорить нелепо хотя бы потому, что к контролам в WI можно привязывать некие стандартные действия, а в случае Dialog Templates — нельзя.
S>

Это всё равно не оправдывает реляционную базу данных для контролов.

Да ты издеваешься? Вместо ответа на КОНКРЕТНЫЙ аргумент выдаёшь "а у вас негров линчуют!".
Мы можем обсудить тонкости представления диалогов отдельно. Здесь пока речь шла о том, можно некий редактор GUI использовать для другого сценария или нельзя.

S>Для сравнения можете изучить архитектуру Delphi

Хамишь.
Ладно бы твой оппонент утверждал нечто, на что можно возразить отсылом к хелпу по некоей технологии или к аналогичной статье. Ты посылаешь людей в ровно противоположных случаях — когда сам оказываешься в беспомощной ситуации.
Эдакое правило: "первым делом всех посылай, потом разбирайся!".

Кароч, я хорошо в курсе, как оно в Дельфи.
И заодно хорошо в курсе, как оно в виндовых DialogTemplates.
И там и там имеем некое текстовое представление + парсер сверху.
Очевидно, что реляционное представление имеет шанс обойтись вовсе без парсера, а значит, там может быть простейший код по построению такого UI, который (код) можно реализовать даже на коленках на каком-нить скриптовом языке.
Более того, АПИ, работающее с базой, автоматически достаточно и для GUI.
Более того, связь диалогов и стадий инсталляхи (или способов инсталляхи — административная, например) выражается через реляционное отношение самым естественным образом.

V>>Ну и набор контролов чуть другой, местами пересекается, местами нет.
S>Ну так в том-то и дело, что набор контролов WI прошит гвоздями, а в Dialog Template можно указывать любые контролы.

Можно указать любое имя оконного класса, а не любой контрол. Это разные вещи, потому что для известного контрола можно установить его св-ва, а для неизвестного — только его местоположение и размер.

V>>В-третьих, сама попытка утверждать, что загвоздка в дизайнере диалогов — это заведомо слить спор. ))
V>>Их было более одного сразу же.
S>"Сразу же" их было ровно 0.

С выходом SDK их появилось сразу несколько. "Сразу" — это примерно 2-3 месяца.
Я и сам простейший визуальный редактор как-то накидал за пару вечеров на дотнете.
Правда, генерил из него XML-WiX, но для генерацию в базу надо было бы еще буквально пару вечеров сверху.

Я НАСТОЯТЕЛЬНО тебе рекомендую хотя бы раз в жизни попробовать накидать такой дизайнер самому, чтобы ты ОСОЗНАЛ всю сложность проблемы, ы-ы-ы. Вернее, увидел отсутствие всяких сложностей.

Порядок работы такой:
— берешь какую-нить библиотеку дизайнера из Сети (я их сразу три штуки нарыл тогда);
— допилил 4 нужных мне на тот момент контрола (кнопку, чек-бок, радиобокс, текстовое поле)
— сделал код сериализации "формы" в XML.
На сегодня это заняло бы у меня один вечер, а не два.

Это как решают проблемы профи из реальной жизни.
Если бы мне было надо что-то совсем серьезное, я бы купил готовый тул, ес-но. (Они стоят обычно 300-500 уе, т.е. порядка двух/трехдневного заработка программиста, т.е. если работы больше, чем на ~3 дня, то надо брать готовый инструмент, а не изобретать свой).

S>Загвоздка — не в дизайнере. Загвоздка — в попытке хранить описание UI в реляционных таблицах.

Э, нет. Загвоздка — это использовать всей индустрией x86-й морально устаревший код. Вот это действительно проблема. А ты о какой-то фигне говоришь.

То, что НЕ создаёт проблем, не является помехой/загвоздкой и прочим.

S>Через это проходят все начинающие разработчики — лично я этим занимался в 1991 году. На клиппере.

Да у тебя на лбу написана "тяга к прекрасному". ))
И я даже одобряю такой перфекционизм, потому что программист и должен быть перфекционистом. Где-то там, глубоко внутри. Особенно на этапе обучения ремеслу. Но после 20-тилетнего стажа даже просто пытаться обсуждать такие вещи — это расписываться в профнепригодности.

V>>Сам не видишь разве, что такие рассуждения попахивают тем, что ты "сабклассил" ручками уникально каждый диалог в нейтивных приложениях, т.е. перехватывал события на стороне parent, без reflection? Не, пару раз и я таким макаром упал-отжался, но исключительно для удовлетворения собственного любопытства.
S>Всё наоборот — reflection отражает евенты на сторону parent

а-а-а-а-а-а-а (еще много раз)
"Я отражаю своё изображение в зеркало!" — примерно так это прозвучало.

(Неожиданно, прямо скажем)

S>и делается для того, чтобы можно было обойтись без сабклассинга контролов для привязки обработчиков. Вижу, что с темой разработки гуя на чистой нативной винде вы тоже знакомы только по разговорам в курилке.

Классный залёт. ))

========
Залёт-то — он особенный. Почему? Потому что фиг с ним даже, если ты не писал нейтивные ГУИ прямо на вынь-АПИ по характеру своей работы. Я тоже такие не писал, я писал на MFC/ATL и чуть позже на WTL. Но я, блин, более одного раза делал это (т.е. брал тупо WinAPI) сугубо в самообразовательных целях. Ведь винды были долгое время единственной вменяемой настольной операционкой. Неужели тебе было не любопытно, как оно там устроено и работает?

Кароч, программист здорового человека обязательно обладает развитым любопытством. Иначе он НЕ программист. Потому что даже в MFC, обладая знаниями о принципах работы оконной подсистемы, можно задёшево решать кучу вещей — например, накладывать стиль не на каждый контрол в отдельности, а на весь диалог. К примеру, если мы кешируем какую-нить сложную кисть и применяем её для кучи разных контролов на одной форме, то на слабой технике тех лет это давало неплохой профит в плане эффективности прорисовки. Таких примеров мильоны, ес-но, фиг с ней, с прорисовкой, но все вместе они составляют самый общий принцип — эдакий способ подхода к делу, по которому (по подходу) можно отличить профи от случайного в отрасли человека.

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

всё вместе это оч-чень странно)

Здравствуйте, Sinclair, Вы писали:

S>А вот вы бегаете от прямых вопросов, в трудных местах отделываясь намёками. Вы уже придумали способ задетектировать версию кастом-компонента, который не представлен дисковым файлом?

Я-то придумал. Меня удивляет, что ты еще не придумал. Ты столько раз спросил "что писать в keypath", что можно было потратить в 10 раз меньше времени и узнать, что keypath — это имя "ресурса", а "ресурс" — это не только файл.

И что определять версию файла автоматом — это лишь некая дополнительная функциональность, но не основная, потому что полноценно проверить можно лишь версию EXE или DLL-файлов, которые содержат внутри себя ресурс с типом VERSION. Т.е., даже при наличии файла, для бесконечного кол-ва типов файлов проверить его "версию" будет автоматом невозможно. И вот как раз для таких вещей чудесно работают custom actions, которые чаще всего нужны как раз для формирования значений неких св-в, участвующих затем в conditions.

И, с моей колокольни, "знания" подобного рода — это даже не знания, а уровень ноль.
Но ты этот уровень так и не прошел.

S>>>Мы говорим не о времени начала дискуссии. А о моменте, когда Installer Team была сформирована и ей была поставлена задача разработать архитектуру Windows Installer.
S>>>Я думаю, что это эпохальное событие произошло когда-то в девяностых.
V>>Это эпохальное событие произошло одновременно с выпуском MS Office 2000, когда в папке с пререквизитами к нему впервые засветился WI и его надо было самому ручками устанавливать перед установкой офиса.
S>То есть вы думаете, что они сначала выпустили офис 2000, а потом была разработана архитектура WI? Выделенное болдом перечитайте.

Я думаю, что ты несерьёзный и беспринципный.

Потому что нет ничего смертельного в том, что ты никогда до этого спора не знал историю разработки Windows Installer. Ну не знал и не знал, фиг с ним. Это не важно и вовсе не принципиально. Но то, что ты в ответ на НОВУЮ для тебя инфу реагируешь натурально неадекватно — в этом весь ты.

Я всё-равно никогда не пойму людей в подобных ситуациях — вот что тебе помешало САМОСТОЯТЕЛЬНО поинтересоваться, зачем и почему был разработан Windows Installer? Это к вопросу о серьёзности. Т.е., если ты так настойчиво возражаешь, если для тебя это (непонятно с чего) важно — ну, дык, прояви серьезность. Сделай всё по-взрослому.

И почему бы тебе не предположить очевиднейшую весчь, а именно — если оппонент утверждает нечто, то он эту инфу откуда-то взял — ну блог там программиста из MS почитал или книгу непосредственно от непосредственно автора MSI (книгу рекомендую, кста)...

Вместо этого ты предпочитаешь лить гадости на оппонента, будто тот человек виноват в твоём незнании.

Это уже из области полнейшей беспринципности.

Ну и возражать тоже надо уметь, например, ЕСЛИ у тебя есть ДРУГАЯ информация, то ей принято делиться. Ты же пока поделился лишь той информацией, что никакой ДРУГОЙ информации на этот счёт у тебя НЕТ. Т.е. ты донимаешь оппонента подколками сугубо развлечения ради. Ну или проявляешь инфантильность, требуя ссылок на блюдечке. Ну молоток, чо!

Но вообще всё вместе — утомительно. Думаю, в реальной разработке обсуждать с тобой технические вопросы банально невозможно. Продвижения ноль.

Упорство ради упорства на фоне бесконечного самолюбования.

От:	jazzer	Skype: enerjazzer
Дата:	02.05.14 09:40
Оценка:	18 (1) +9

От:	Нахлобуч	https://hglabhq.com
Дата:	10.05.14 08:52
Оценка:	78 (7) +1 -2

	От:	0x7be
	Дата:	02.05.14 09:09
	Оценка:	44 (8) +7

От:	Sinclair	https://github.com/evilguest/
Дата:	06.05.14 10:33
Оценка:	108 (9) +3

	От:	Cyberax
	Дата:	13.05.14 05:31
	Оценка:	+3 -2

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	12.05.14 13:43
Оценка:	12 (1) +1

	От:	CreatorCray
	Дата:	04.05.14 07:20
	Оценка:	2 (1) +1

От:	Mystic	http://mystic2000.newmail.ru
Дата:	09.05.14 21:46
Оценка:	2 (1) +1

От:	Географ	нет
Дата:	02.05.14 10:34
Оценка:	+1 -1

От:	Lazin	http://evgeny-lazin.blogspot.com
Дата:	04.05.14 20:54
Оценка:	+2

От:	netch80	http://netch80.dreamwidth.org/
Дата:	03.05.14 13:56
Оценка:	+1

От:	c-smile	http://terrainformatica.com
Дата:	10.05.14 02:36
Оценка:

От:	мыщъх	http://nezumi-lab.org
Дата:	03.05.14 03:35
Оценка:

	От:	Evgeny.Panasyuk
	Дата:	11.05.14 14:37
	Оценка:

От:	dimgel	https://github.com/dimgel
Дата:	31.05.14 16:04
Оценка:

	От:	vdimas
	Дата:	14.05.14 15:07
	Оценка:	-2

	От:	Privalov
	Дата:	07.11.16 12:30
	Оценка:	+1

	От:	vdimas
	Дата:	17.11.16 15:38
	Оценка:

	От:	eugene0
	Дата:	14.05.14 13:46
	Оценка:	+1

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	07.11.16 17:33
Оценка:

От:	Философ	http://vk.com/id10256428
Дата:	12.11.16 00:13
Оценка: