Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
Для таких случаев обычно в каждой уважающей себя среде разработки есть инструментарий для создания таких мастеров, а каждая уважающая себя библиотека, особенно претендующая на звание фреймворка, поставляет свои мастера-визарды для большинства популярных сред разработки.
Проблема в том, что для каких-то своих задач такие инструменты, предоставляемые средой разработки, обычно слишком сложны — пока разберешься что там к чему, можно уже вручную наколбасить сто раз. Ну, и при переезде на другую среду все наработки пропадают. Не, можно держать и старую систему только ради визардов, и запускать её только ради них, но это перебор. А если сменили хост платформу, и на новой нет предыдущей IDE?
В общем, на мой взгляд, есть такая проблема. Кто как её решает? Ну, если у вас есть аналогичная проблема?
ЗЫ Хотел сначала в "Средства разработки" закинуть, но, наверно, тема больше для холивара
Собственно это всё старо как UI сам по себе. Был такой Dreamweaver которым можно было делать сайты-поделки одно время в режиме WYSIWYG.
Но мы уже давно ушли от ситуации когда у всех были 800x600 экранов с 96dpi и от HTML 3.2 где это имело смысл использовать.
Оказалось что для разработки UI проще всего освоить базовые понятия которые умещаются на страницу печатного текста, например.
Ну 10-20 базовых CSS свойств. CSS более-менее универсален сейчас: Web, QML, GTK, тот же Sciter.
Всяко быстрее результат будет если просто писать дефиниции в notepad каком. Ну и потом это реально полезно — хотя бы понимать как сделать сайт для своего же приложения.
Проблема в том что создание этих самых "визардов" экономически не целесообразно. Профессионалам (кто согласны платить) оно не нужно — им нужно чтобы UI дефиниции были diff`able,
а любители не освоившие базовый набор, которым это нужно на один раз, денег не платят, ибо действительно зачем оно для одного раза-то?
Apple сделал свою среду сугубо для любителей чтобы с них получить те самые 100 баксов которые стоит AppStore publishing subscription.
Т.е. для них эта разработка оправдана. В AppStore 3.06 млн. приложений, т.е. от wizard они получили 300 млн. баксов.
А полезных/популярных приложений, разрабатываемых профессионально (т.е. без этих вот визардов), реально там если 1000 будет то хорошо.
M>>ЗЫ Хотел сначала в "Средства разработки" закинуть, но, наверно, тема больше для холивара
CS>Т.к. я примерно представляю откуда у этого крика души ноги растут. Ну и в качестве иллюстрации проблемы.
Не, не представляешь, похоже
Твоё представление, похоже, инспирировано моими вопросами по скайтеру. Но тут совсем не об этом
CS>Собственно это всё старо как UI сам по себе. Был такой Dreamweaver которым можно было делать сайты-поделки одно время в режиме WYSIWYG. CS>Но мы уже давно ушли от ситуации когда у всех были 800x600 экранов с 96dpi и от HTML 3.2 где это имело смысл использовать.
Я не про UI, не смотри только под этим углом
CS>Такая вот экономика.
Проиллюстрирую.
Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё.
Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры.
В итоге — имеем .h и .cpp для включения в проект
Здравствуйте, Marty, Вы писали:
M>Проиллюстрирую.
M>Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
M>Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё. M>Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры. M>В итоге — имеем .h и .cpp для включения в проект
Здравствуйте, c-smile, Вы писали:
M>>Проиллюстрирую.
M>>Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
M>>Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё. M>>Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры. M>>В итоге — имеем .h и .cpp для включения в проект
CS>В чем проблема? Заплати кому-нибудь — напишут. Для web, sciter, или вообще command line на, скажем, nodejs. Типа этого https://expressjs.com/en/starter/generator.html
Ну, так-то любая проблема решается баблом, не?
И, так-то, я себе накидал такое, просто интересно, как люди живут и решают аналогичные проблемы
Здравствуйте, Marty, Вы писали:
M> Здравствуйте!
M>Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
А можно пример такой задачи, которую предполагается решить универсальным визардом?
M>В общем, на мой взгляд, есть такая проблема. Кто как её решает? Ну, если у вас есть аналогичная проблема?
Не понятно, в чем состоит проблема, и в чем ее универсальность.
Вот все, что ты описал:
что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
Что кликнул, куда кликнул, какие файлики, ничего не понятно
Единственное из моих задач, которые подходят под это описание — это генерация блога. Для этого я взял Hugo. Для каких-то других задач у меня набор шелл-скриптов (например, переключение gcp и kubectl контекстов). Для каких-то третьих задач у меня будет что-то еще.
Как и где мне поможет какой-то «универсальный визард», учитывая, что универсальных задач мало, не понимаю.
Здравствуйте, Marty, Вы писали:
M>Проиллюстрирую.
M>Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
M>Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё. M>Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры. M>В итоге — имеем .h и .cpp для включения в проект
Зачем генерировать файлики-то? С++ вроде довольно мощный ЯП. Там и макросы, и шаблоны. Делаешь либу и реюзаешь... Понимаю ещё UI, там визуально нужно... но ведь это тупо код.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
M>>В итоге — имеем .h и .cpp для включения в проект ·>Зачем генерировать файлики-то? С++ вроде довольно мощный ЯП. Там и макросы, и шаблоны. Делаешь либу и реюзаешь... Понимаю ещё UI, там визуально нужно... но ведь это тупо код.
Потому что целый пласт задач можно закрыть только через рефлексию, а её в плюсах нет.
На макросах и шаблонах из-за отладки и неочевидности (говнокодовости) получается на порядки дольше + больше багов + тяжелее баги отлаживать + уродливее код (это для использования, потому что в либе будет вообще ад) + всё равно не покроет потребности.
К примеру RPC — любое решение на макросах и шаблонах в итоге имеет уродливый синтаксис + всё равно надо контролировать самому и серверную и клиентскую часть. В отличии от генерации.
Здравствуйте, Marty, Вы писали:
M>Есть где на неё посмотреть?
Нигде, у меня часть проектов — личные, являются моим конкурентным преимуществом над остальными.
Но в целом система лёгкая — берёшь смотришь как работают нужные визарды, я к примеру смотрел на msvs. И копируешь, изменяя всё, что тебе надо и делая их интелектуальными.
Если я правильно помню день ушло на систему, день на пачку из десятка визардов. Оно всё простое.
Здравствуйте, AeroSun, Вы писали:
M>>>В итоге — имеем .h и .cpp для включения в проект AS>·>Зачем генерировать файлики-то? С++ вроде довольно мощный ЯП. Там и макросы, и шаблоны. Делаешь либу и реюзаешь... Понимаю ещё UI, там визуально нужно... но ведь это тупо код. AS>Потому что целый пласт задач можно закрыть только через рефлексию, а её в плюсах нет. AS>На макросах и шаблонах из-за отладки и неочевидности (говнокодовости) получается на порядки дольше + больше багов + тяжелее баги отлаживать + уродливее код (это для использования, потому что в либе будет вообще ад) + всё равно не покроет потребности. AS>К примеру RPC — любое решение на макросах и шаблонах в итоге имеет уродливый синтаксис + всё равно надо контролировать самому и серверную и клиентскую часть. В отличии от генерации.
Это какие-то корявые античные RPC-решения. Сейчас принято класть в проект описание протокола (protobuf-файлы, например) и делать шаг в системе билда, который будет на лету создавать файлики и скармливать их компилятору. Включаются в проект только исходники, которые могут правиться человеком, а не результат кодогенерации, который и видеть-то не нужно. Если приходится искать баги в сгенерированном коде, то надо что-то поправить в консерватории.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
AS>>К примеру RPC — любое решение на макросах и шаблонах в итоге имеет уродливый синтаксис + всё равно надо контролировать самому и серверную и клиентскую часть. В отличии от генерации. ·>Это какие-то корявые античные RPC-решения. Сейчас принято класть в проект описание протокола (protobuf-файлы, например) и делать шаг в системе билда, который будет на лету создавать файлики и скармливать их компилятору. Включатся в проект только исходники, которые могут правится человеком, а не результат кодогенерации, который и видеть-то не нужно. Если приходится искать баги в сгенерированном коде, то надо что-то поправить в консерватории.
У городи бузина, а в Киеве — дядько
Ты ж сам спрашивал зачем генерировать, раз макросы и шаблоны в плюсах есть.
Здравствуйте, AeroSun, Вы писали:
AS>>>К примеру RPC — любое решение на макросах и шаблонах в итоге имеет уродливый синтаксис + всё равно надо контролировать самому и серверную и клиентскую часть. В отличии от генерации. AS>·>Это какие-то корявые античные RPC-решения. Сейчас принято класть в проект описание протокола (protobuf-файлы, например) и делать шаг в системе билда, который будет на лету создавать файлики и скармливать их компилятору. Включатся в проект только исходники, которые могут правится человеком, а не результат кодогенерации, который и видеть-то не нужно. Если приходится искать баги в сгенерированном коде, то надо что-то поправить в консерватории. AS>У городи бузина, а в Киеве — дядько AS>Ты ж сам спрашивал зачем генерировать, раз макросы и шаблоны в плюсах есть.
Эээ... Ну про киевского дядку ты начал. У топикстартера было визарде, как я понял, генерирующий "рыбу" исходников, которые он собирался класть в проект. Я считаю, что так делать не надо. А ты привёл пример про RPC. И, как выяснилось, для RPC тоже так не делается. В итоге так никто и раскрыл накой нужен сабж.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, c-smile, Вы писали:
CS>Собственно это всё старо как UI сам по себе. Был такой Dreamweaver которым можно было делать сайты-поделки одно время в режиме WYSIWYG. CS>Но мы уже давно ушли от ситуации когда у всех были 800x600 экранов с 96dpi и от HTML 3.2 где это имело смысл использовать.
CS>Оказалось что для разработки UI проще всего освоить базовые понятия которые умещаются на страницу печатного текста, например. CS>Ну 10-20 базовых CSS свойств. CSS более-менее универсален сейчас: Web, QML, GTK, тот же Sciter. CS>Всяко быстрее результат будет если просто писать дефиниции в notepad каком. Ну и потом это реально полезно — хотя бы понимать как сделать сайт для своего же приложения.
А мне вот не хватает чего-то, что позволяет тупо набросать интерфейс в графическом виде. Мне не нужен сгенеренный код, нужна удобная рисовалка, а код я потом сам напишу. Но самое удобное, что удалось найти — это бумажный лист, однако на нем не задать никакого поведения.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>А мне вот не хватает чего-то, что позволяет тупо набросать интерфейс в графическом виде. Мне не нужен сгенеренный код, нужна удобная рисовалка, а код я потом сам напишу. Но самое удобное, что удалось найти — это бумажный лист, однако на нем не задать никакого поведения. https://www.qt.io/ui-design-tools? Я не пробовал.
Здравствуйте, Skorodum, Вы писали:
Ops>>А мне вот не хватает чего-то, что позволяет тупо набросать интерфейс в графическом виде. Мне не нужен сгенеренный код, нужна удобная рисовалка, а код я потом сам напишу. Но самое удобное, что удалось найти — это бумажный лист, однако на нем не задать никакого поведения. S>https://www.qt.io/ui-design-tools? Я не пробовал.
Примечательно:
А мне как раз хочется просто рисовалку, но с поведением, вроде открытия менюшек, адаптивности и т.п. Может фотошоп что-то такое и умеет, но он действительно сложен, а для простых случаев не так удобен, как лист бумаги.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ·, Вы писали:
M>>Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
M>>Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё. M>>Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры. M>>В итоге — имеем .h и .cpp для включения в проект ·>Зачем генерировать файлики-то? С++ вроде довольно мощный ЯП. Там и макросы, и шаблоны. Делаешь либу и реюзаешь... Понимаю ещё UI, там визуально нужно... но ведь это тупо код.
Ну, код вроде и так написан уже с использованием либы — SPL называется. Только вот незадача — она слегка несовместима между собой для разных семейств MCU. Можно поверх еще оберток написать, или к хренам всё переписать на на регистрах, но это потребует времени, которое не окупится. А так — накидал визардик, он, в зависимости от выбранного семейства выбирает шаблон, и подставляет параметры
Здравствуйте, AeroSun, Вы писали:
AS>Но в целом система лёгкая — берёшь смотришь как работают нужные визарды, я к примеру смотрел на msvs. И копируешь, изменяя всё, что тебе надо и делая их интелектуальными. AS>Если я правильно помню день ушло на систему, день на пачку из десятка визардов. Оно всё простое.
