Comments 19
В PHP, например, да и не тоьлко такая мода уже давно прошла и генерация форм доступна на любом уровне, в моделях любого фреймворка.
По сему не вижу ничего «инновационного» в этом.
Еще и с XSLT — зачем, когда можно просто писать чистый код, на том же PHP, а на выходе получаешь все готовые элементы формы.
По сему не вижу ничего «инновационного» в этом.
Еще и с XSLT — зачем, когда можно просто писать чистый код, на том же PHP, а на выходе получаешь все готовые элементы формы.
Всё правильно сделали — задача клепать формы — много и недорого. Чистый код = дорогой программист * много времени. Результата нужного не добиться.
Жаль, что поняли вы это не на этапе проектирования, а уже когда запустились.
У нас на работе есть похожая тема — сначала сделали прогу, которая заполняла 10форм и вроде бы больше не требовалось. Но со временем появилась целая куча документов (около 100) и когда происходит массовое обновление — так и хочется застрелиться, потому-что надо было изначьно делать универсальный заполнитель форм, основанный на шаблонах, которые можно было бы легко менять обычным сотрудникам, а не звать программистов по каждому чиху.
Жаль, что поняли вы это не на этапе проектирования, а уже когда запустились.
У нас на работе есть похожая тема — сначала сделали прогу, которая заполняла 10форм и вроде бы больше не требовалось. Но со временем появилась целая куча документов (около 100) и когда происходит массовое обновление — так и хочется застрелиться, потому-что надо было изначьно делать универсальный заполнитель форм, основанный на шаблонах, которые можно было бы легко менять обычным сотрудникам, а не звать программистов по каждому чиху.
По тексту статьи непонятно: вы разработали портал gosuslugi.ru? Или какой-то другой портал, где также много форм как на gosuslugi.ru?
Почему не ипользовали готовые решения? Form builder'ов пруд пруди, например: www.alpacajs.org/demos/form-builder/form-builder.html Будете ли делиться наработками в open source или эта статья только маркетинг и пиар?
Сколько данных проходит через формы? Т.е. это 300 форм в месяц для сбора трех отзывов в месяц о работе корпоративного сайта? Или вы по 15 млн записей в день пропускаете через заполнение этих форм? Сделайте скриншот, чтоб посмотреть на уровень сложности форм, которые можно реализовать на вашем новом фреймворке.
Почему не ипользовали готовые решения? Form builder'ов пруд пруди, например: www.alpacajs.org/demos/form-builder/form-builder.html Будете ли делиться наработками в open source или эта статья только маркетинг и пиар?
Сколько данных проходит через формы? Т.е. это 300 форм в месяц для сбора трех отзывов в месяц о работе корпоративного сайта? Или вы по 15 млн записей в день пропускаете через заполнение этих форм? Сделайте скриншот, чтоб посмотреть на уровень сложности форм, которые можно реализовать на вашем новом фреймворке.
antirek, да инструмент разрабатывался в рамках создания портала gosuslugi.ru, и является одним из его модулей, используемым для создания форм получения государственных услуг.
Насколько часто используются те или иные формы зависит от популярности услуги. Есть услуги по которым более миллиона обращений в месяц, а есть непопулярные — по 2-3 обращения. Но нагрузка на формы это отдельная история, и стоит в стороне от непосредственно разработки услуг.
Готовые решения нам не подошли по нескольким причинам:
— на момент начала проекта (2012 г) таких решений было не так много
— большинство из них платные и не opensource
— мы знали, что потребуются очень кастомные вещи (типа виджета ввода трудовой деятельности при подаче заявления на загранпаспорт), а затраты на кастомизацию доступных на тот момент решений были сравнимы с написанием своего решения
— «зоопарк» технологий в чужих решениях. Мы ограничились стеком технологий, который уже был использован при разработке личного кабинета и каталога услуг портала gosuslugi.ru
Самое главное, из-за чего решили делать самостоятельно — помимо создания/исполнения самих форм, фреймворк должен был соответствовать ряду бизнес-процессов, принятых для построении систем электронного правительства. Например, как я писал в статье — формирование XML определенного формата, подписание электронной подписью, взаимодействие с внешними системами через СМЭВ и так далее. Ни одно существующее решение out-of-the-box нельзя без доработок встроить в эти бизнес-процессы, а доработки = затраты, сопоставимые с разработкой своего.
Объясню на примере формы записи ко врачу
www.awesomescreenshot.com/image/432244/b6860bea12e58cdc6a1df5b25747fa0b
www.gosuslugi.ru/service/10000020298/-10000000603
Сложность этой услуги заключается в том, что в зависимости от введенных пользователем данных выполняются запросы во ИС Минздрава и запрашиваются списки значений для других полей. Вроде бы ничего сложного, но по задумке ни одного разработчика не должно участвовать в создании услуги, и все эти взаимодействия должен настроить аналитик.
Какое из доступных решений позволяет это сделать? Либо никакое либо мы плохо искали.
Мы же смогли все эти настройки вынести в пользовательский интерфейс и с такого рода задачами справляются аналитики за пол-дня.
Что касается opensource — нет, пока не планируем. Возможно в будущем
Насколько часто используются те или иные формы зависит от популярности услуги. Есть услуги по которым более миллиона обращений в месяц, а есть непопулярные — по 2-3 обращения. Но нагрузка на формы это отдельная история, и стоит в стороне от непосредственно разработки услуг.
Готовые решения нам не подошли по нескольким причинам:
— на момент начала проекта (2012 г) таких решений было не так много
— большинство из них платные и не opensource
— мы знали, что потребуются очень кастомные вещи (типа виджета ввода трудовой деятельности при подаче заявления на загранпаспорт), а затраты на кастомизацию доступных на тот момент решений были сравнимы с написанием своего решения
— «зоопарк» технологий в чужих решениях. Мы ограничились стеком технологий, который уже был использован при разработке личного кабинета и каталога услуг портала gosuslugi.ru
Самое главное, из-за чего решили делать самостоятельно — помимо создания/исполнения самих форм, фреймворк должен был соответствовать ряду бизнес-процессов, принятых для построении систем электронного правительства. Например, как я писал в статье — формирование XML определенного формата, подписание электронной подписью, взаимодействие с внешними системами через СМЭВ и так далее. Ни одно существующее решение out-of-the-box нельзя без доработок встроить в эти бизнес-процессы, а доработки = затраты, сопоставимые с разработкой своего.
Объясню на примере формы записи ко врачу
www.awesomescreenshot.com/image/432244/b6860bea12e58cdc6a1df5b25747fa0b
www.gosuslugi.ru/service/10000020298/-10000000603
Сложность этой услуги заключается в том, что в зависимости от введенных пользователем данных выполняются запросы во ИС Минздрава и запрашиваются списки значений для других полей. Вроде бы ничего сложного, но по задумке ни одного разработчика не должно участвовать в создании услуги, и все эти взаимодействия должен настроить аналитик.
Какое из доступных решений позволяет это сделать? Либо никакое либо мы плохо искали.
Мы же смогли все эти настройки вынести в пользовательский интерфейс и с такого рода задачами справляются аналитики за пол-дня.
Что касается opensource — нет, пока не планируем. Возможно в будущем
Спасибо за развернутый ответ. ГосУслуги — да, это круто! (без тени сарказма и чего-то еще) Реальный проект, делающий взаимодействие с государством проще, пользовался уже неоднократно. В том числе, видимо, и делом рук ваших: )
Но немного не понимаю посыла (темы, идеи) статьи. Сначала вы делаете интригу насчет инструмента:
>> Сколько нужно программистов, чтобы сделать форму для пользователя? Ни одного!
>> Для этого достаточно создать инструмент, с помощью которого создавать формы для web-решений
>> смогут даже домохозяйки.
Затем рассказываете про ваш тернистый путь, а в выводах предлагаете традиционный набор из 3-х блюд из статьи про стартапы. Я лично надеялся получить в конце ссылки на гитхаб на ваш инструмент.
Я понимаю, что пост на Хабре — это не выпускное сочинение, но «завязка-кульминация-развязка» — основа хорошей истории во все времена.
Но все равно было интересно прочитать, особенно от человека, имеющего непосредственное отношение к проекту. Вы, случаем, не знаете разработчиков ГосМонитора и сайта Федерального агентства связи? А то была тут у меня одна история.
Но немного не понимаю посыла (темы, идеи) статьи. Сначала вы делаете интригу насчет инструмента:
>> Сколько нужно программистов, чтобы сделать форму для пользователя? Ни одного!
>> Для этого достаточно создать инструмент, с помощью которого создавать формы для web-решений
>> смогут даже домохозяйки.
Затем рассказываете про ваш тернистый путь, а в выводах предлагаете традиционный набор из 3-х блюд из статьи про стартапы. Я лично надеялся получить в конце ссылки на гитхаб на ваш инструмент.
Я понимаю, что пост на Хабре — это не выпускное сочинение, но «завязка-кульминация-развязка» — основа хорошей истории во все времена.
Но все равно было интересно прочитать, особенно от человека, имеющего непосредственное отношение к проекту. Вы, случаем, не знаете разработчиков ГосМонитора и сайта Федерального агентства связи? А то была тут у меня одна история.
> в зависимости от введенных пользователем данных выполняются запросы во ИС Минздрава и запрашиваются списки значений для других полей. Вроде бы ничего сложного, но по задумке ни одного разработчика не должно участвовать в создании услуги, и все эти взаимодействия должен настроить аналитик.
А аналитик — он программировать совсем не умеет, а умеет только контролы на формы набрасывать и свойства им выставлять? Или всё же он должен быть способен изучить API внешних сервисов, и, если нужно, написать адаптеры, валидаторы и конвертеры данных (возможно выходящие за рамки XML/XSLT) и прочую обвязку? В общем, какой уровень компетенции ожидается от аналитика?
Как у вас обстоят дела с локализацией форм? Дизайнить формы в WISIWYG за пол-дня — это приятно, но однажды наступает момент, когда нужно переводить формы на разные языки и приспосабливать к разным культурам, и тут вдруг оказывается, что после дизайнера контент и вид склеены между собой намертво, и на перевод приходится отдавать не тексты, а полный фарш из разметки, текстов, правил валидации, байндингов, и назад он возвращается нередко в слегка помятом виде (там спецсимволы не заескейпили, там кодировку файла подменили, там служебное слово перевели и тому подобные шутки, которые могут вылезти уже в продакшене). В общем, локализация — это целый процесс, и занимает он уже далеко не пол-дня и требует определённой квалификации. Кто у вас за него отвечает? Аналитики?
А аналитик — он программировать совсем не умеет, а умеет только контролы на формы набрасывать и свойства им выставлять? Или всё же он должен быть способен изучить API внешних сервисов, и, если нужно, написать адаптеры, валидаторы и конвертеры данных (возможно выходящие за рамки XML/XSLT) и прочую обвязку? В общем, какой уровень компетенции ожидается от аналитика?
Как у вас обстоят дела с локализацией форм? Дизайнить формы в WISIWYG за пол-дня — это приятно, но однажды наступает момент, когда нужно переводить формы на разные языки и приспосабливать к разным культурам, и тут вдруг оказывается, что после дизайнера контент и вид склеены между собой намертво, и на перевод приходится отдавать не тексты, а полный фарш из разметки, текстов, правил валидации, байндингов, и назад он возвращается нередко в слегка помятом виде (там спецсимволы не заескейпили, там кодировку файла подменили, там служебное слово перевели и тому подобные шутки, которые могут вылезти уже в продакшене). В общем, локализация — это целый процесс, и занимает он уже далеко не пол-дня и требует определённой квалификации. Кто у вас за него отвечает? Аналитики?
Аналитик программировать по-умолчанию совсем не умеет, но изучить формат взаимодействия внешних сервисов должен уметь.
Универсальные адаптеры, обработчики запроса/ответа, механизмы валидации, заложены в ядре фреймворка. Для настройки внешних запросов аналитику достаточно написать XSLT описывающие преобразование запросов, ответов, и с помощью графического интерфейса настроить маппинг полученных снаружи значений на поля формы.
Что касается локализации — да, это известная головная боль. Пока такие возможности во фреймворк не заложены, то есть он — одноязычный.
Но если добавлять такую фичу, то сначала переработка ядра — локализация набора виджетов, визуальных элементов, добавление новых свойств к объектам. Это работа группы разработки ядра.
Затем донастройка самих форм — заполнение добавленных языковых атрибутов. С этим уже легко справятся аналитики
Универсальные адаптеры, обработчики запроса/ответа, механизмы валидации, заложены в ядре фреймворка. Для настройки внешних запросов аналитику достаточно написать XSLT описывающие преобразование запросов, ответов, и с помощью графического интерфейса настроить маппинг полученных снаружи значений на поля формы.
Что касается локализации — да, это известная головная боль. Пока такие возможности во фреймворк не заложены, то есть он — одноязычный.
Но если добавлять такую фичу, то сначала переработка ядра — локализация набора виджетов, визуальных элементов, добавление новых свойств к объектам. Это работа группы разработки ядра.
Затем донастройка самих форм — заполнение добавленных языковых атрибутов. С этим уже легко справятся аналитики
«Написать XSLT» — это ведь тоже программирование, причём на достаточно вырвиглазном языке с довольно убогими (в сравнении с другими языками) средствами. Мы сейчас тоже занимаемся похожей проблемой, и довольно странно мне, почему считается, что кастомизировать с помощью XSLT — это ок, написать свой собственный зубодробительный XSD для конфигурации с логическими конструкциями, по сути изобретая ещё один недоLISP упакованый в XML и заставляя людей изучать этот псевдо-язык-однодневку — тоже ок, а вот попросить писать подключаемые модули кастомизации на каком-нибудь традиционном языке с богатым синтаксисом и библиотеками (тот же С#, например), с юнит-тестами, блэкджеком и девицами — это ни-ни, аналитик испугается и убежит. Непонятна мне эта предвзятость к обычным языкам и любовь к изобретению собственных.
Человека без подготовки гораздо проще научить писать XSLT-преобразования, чем писать код на любом из языков высокого уровня. Чтобы писать нормальный код надо хорошо знать теорию ООП, паттернов разработки, API живущих рядом модулей итд.
Для написания XSLT всего этого не нужно знать. К тому же, отладка гораздо проще, не надо никаких IDE устанавливать, не надо никаких vcs настраивать, ну и всех остальных разработческих штук.
И все-таки в нашей системе XSLT используется скорее не для кастомизации, а для описания преобразования нашего входного/выходного формата данных к API внешних систем, а они априори различны в нашем случае.
Для написания XSLT всего этого не нужно знать. К тому же, отладка гораздо проще, не надо никаких IDE устанавливать, не надо никаких vcs настраивать, ну и всех остальных разработческих штук.
И все-таки в нашей системе XSLT используется скорее не для кастомизации, а для описания преобразования нашего входного/выходного формата данных к API внешних систем, а они априори различны в нашем случае.
Чтобы написать модуль кастомизации, нужно знать лишь основы ЯП и библиотеку, предоставляемую разработчиками. Скажем, нужно поменять логику валидации данных; можно мучаться с XML, а можно использовать какой-нибудь .NET FluentValidator, где такая логика описывается в разы проще. Или написать функцию на JavaScript, если используется node.js. От этапа сборки можно избавиться, если использовать динамическую компиляцию (как в ASP) или интерпретируемый язык (как в ноде).
По поводу «не надо IDE и VCS»: эти аналитики работают «с колёс», т.е. фиксят конфиги в Блокноте на рабочей системе в продакшине? Или они всё же ставят себе рабочее окружение, инструменты, заботятся об организации файлов в проекты, о версионировани, о тестировании и его автоматизации? Если верно второе утверждение, то IDE и VCS — не аргумент, они им по-любому нужны, и аналитик — такой же девелопер, только пожиже. Если же верно первое — я бы такого аналитика гнал бы от проекта ссаными тряпками, ибо это обезьяна с гранатой.
По поводу «не надо IDE и VCS»: эти аналитики работают «с колёс», т.е. фиксят конфиги в Блокноте на рабочей системе в продакшине? Или они всё же ставят себе рабочее окружение, инструменты, заботятся об организации файлов в проекты, о версионировани, о тестировании и его автоматизации? Если верно второе утверждение, то IDE и VCS — не аргумент, они им по-любому нужны, и аналитик — такой же девелопер, только пожиже. Если же верно первое — я бы такого аналитика гнал бы от проекта ссаными тряпками, ибо это обезьяна с гранатой.
Статья интересная, но однобокая несколько — форму создать это не хмл править — её учитывать надо, регистрировать, данные с неё куда-то идут, по ним отчёт надо выдать; потом каждая форма это, обычно, начало процесса… да и саму форму разрабатывает не один человек от «нечего делать» а группа какая-то. 1000 заказчиков — это уже кошмар. 10.000 форм — если в них есть смысл, то это очень очень много. И тогда 100-200 технарей это нормально. только к ним ещё надо менеджеров 300+ добавить…
itur форма — один из элементов функции «электронная государственная услуга». Перевод услуги в электронный вид и есть цель создания в том числе формы.
Наше решение покрывает 2 элемента — экранная форма и настройка части бизнес-процесса, которая должна выполняться на портале госуслуг — заполнение и отправка заявления гражданина на получение услуги. Остальная часть — регистрация, обработка данных, подготовка ответа — выполняется уже в информационной системе ведомства, оказывающего услугу.
Каждый человек, разрабатывающий формы общался напрямую с представителем заказчика и сам потом настраивал все как надо на форме. Это сократило издержки на «сломанный телефон» заказчик -> аналитик -> разработчик
Наше решение покрывает 2 элемента — экранная форма и настройка части бизнес-процесса, которая должна выполняться на портале госуслуг — заполнение и отправка заявления гражданина на получение услуги. Остальная часть — регистрация, обработка данных, подготовка ответа — выполняется уже в информационной системе ведомства, оказывающего услугу.
И тогда 100-200 технарей это нормально. только к ним ещё надо менеджеров 300+ добавитьОдной из целей создания решения как раз и было минимизировать количество технарей, сохраняя при этом производительность.
Каждый человек, разрабатывающий формы общался напрямую с представителем заказчика и сам потом настраивал все как надо на форме. Это сократило издержки на «сломанный телефон» заказчик -> аналитик -> разработчик
Статья подтверждает старый тезис о том, что только закончив проект, понимаешь, как его надо было делать. Далее уже стоит сложный выбор — или продолжать пилить то, что получилось, или переписать проект с нуля. Ваш случай — это удачный пример второго пути.
Век живи — век учись ))
Бывает так, что когда решаешь какую-то задачу даже не представляешь во что она трансформируется через год, два, итд.
Так и было в этом случае — сначала надо было сделать-то порядка 100 услуг, но со временем количество возрастало, а сроки уменьшались. И мы следом за спросом/рынком оптимизировали наши инструменты чтобы оставаться конкурентоспособными.
Бывает так, что когда решаешь какую-то задачу даже не представляешь во что она трансформируется через год, два, итд.
Так и было в этом случае — сначала надо было сделать-то порядка 100 услуг, но со временем количество возрастало, а сроки уменьшались. И мы следом за спросом/рынком оптимизировали наши инструменты чтобы оставаться конкурентоспособными.
Всё уже украдено до нас. www.orbeon.com
Вообще, для меня это очень странно. На рынке уйма решений для проектирования и заполнения форм. Разработка собственного фрэймворка, в большинстве случаев, приводит к печальным последствиям для компании. Так что решение о разработке такого фрэймворка крайне опасное и глупое.
Вообще, для меня это очень странно. На рынке уйма решений для проектирования и заполнения форм. Разработка собственного фрэймворка, в большинстве случаев, приводит к печальным последствиям для компании. Так что решение о разработке такого фрэймворка крайне опасное и глупое.
Согласен, что надо пользоваться готовым если если есть возможность, а не изобретать велосипеды. Но в нашем случае задача была слишком специфичная и существовавшие на тот момент решения нам не подошли.
Прямо дежавю какое-то
habrahabr.ru/company/ultima/blog/256527
habrahabr.ru/company/ultima/blog/256527
Sign up to leave a comment.
Автоматизируй это