Тут какая штука — пока весь состав атрибутов заявления не передан в интегрированную информационную систему образования, заявление не считается поданным и соответственно права "первоорчедености" не возникает.
Сама подача ведь тоже верифицируется на стороне сервера — там есть логика проверки на фронте, а есть и серверая логика верификации значений справочников хотя бы.
Опять же — если то, что вы подали раньше всех не соответствует логике и требования адм.регламента записи — это заявление просто отклонят. Ну например адрес вы не укажите или другой какой-то, не соответствующий школе. Поэтому полное заполнение заявления — это обязательное условие. В идеале (и в практике для ряда услуг) — весь состав данных подписывается эл.подписью для юридической значимости. Но т.к. это сложно организовать для граждан — используется простая эл.подпись, но де факто юридическая значимость обеспечивается статусом информационной системы, логгированием всех запросов и подразумеваемой возможностью инициировать проверку прокуратуры и изъятия всех этих данных для ручной сверки. Происходит редко именно в силу посреднической функции, т.е. доверительной, которую выполняют региональные порталы между гражданами(браузерами) и ведомствами(инф.системами).
Браузер в этой схеме является несертифицированным армом — т.е. логике на его стороне фактически нет никакого доверия — т.к. действительно можно и в скрипты вмешиваться и состав данных подправить прямо в форме, даже в заблокированных для редактирования полей и просто POST запрос сгенерировать. Т.е. важно — идентификтор пользователя в виде сессии авторизации и состав данных по полям. И когда валидация сессии и соответствия состава полей и каких-то формальных требований к содержанию пройденно — именно это и является заявлением и фактом его подачи.
Досылка даных — это уже другой процесс. Такой например есть в госэкспертизе. Там вы подаете заявление, но реальные данные выгружаете (сканы документов проектых) уже после регистрации факта подачи.
Хотя де юре можно сделать простую кнопку — "встать очередь" — так видят услугу многие пользователи и к этому логика развития эл.услуг идет. Только нужно адм.регламенты написать и закрепить их. Тогда нужно передать только сессию пользователя и его "желание получить услугу". А данные дослать или запросить в других ведомствах. Но тогда мы опять же получим δ-функцию в отправке.
И получим кучу других проблем — а действительно он выразил это желание или случайно нажал? Это как в договоре — банку недостаточно вашей подписи, они ещё и ФИО просит написать — чтобы гарантировать, что это вы. А нотариус сколько вопросов задает, чтобы понять дееспособность и осознанность намерения. Ввод доп.данных служит в том числе и этой цели. Ну и растягивает подачу на какое-то время, меняя модель случайно успел нажать, систему случано раньше получила из-за случайных сетевого состояния — на какой-то соревнуемый навык — быстрее печатал, знал как скрипт написать автозаполнения — это вместо быстрого коня на диком западе ))) Иначе можно и просто лотерею ввести. Что будет справедливее?
Так именно родители этого малого числа школ и создают эту нагрузку — их примерно до 10% от общего кол-ва школьников. В остальные школы проще прийти с документами до конца мая без шума и спешки.
Можно по всякому решать. Единственно в услуге запись в первый класс очень критично время подачи — по нему формируется очередь — это юридически значимо — а передать id без минимум ФИО родителя/ребенка — это уже не то, вдруг потом данные не дойдут.
Тем более проблемы на этапе подачи не было — нагрузка растянутая на 3-5 минут уже вполне решаемая на этих объемах. И её протестировать хорошо вполне возможно. Основаня проблема в обновлении в 0:00 минут — этот пик, дельта фукцию, не обойти никак. И её кстати сложно сэмулировать нагрузкой — можно только экстраполяции делать на динамике с разной нагрузкой и выдвигать гипотезы — что вперед будет "выбрано" — канал, производительность коммутационного оборудования, производительность защиты или ошибки в настройках алогоритмов, ресурсы сервера. Кстати канал и коммутаторы не всегда в ЦОДе — ведь есть ещё операторы связи в городах, районах и у некоторых они не с таким уж большим резервом — а трафик из ютуба очень отличается от этой δ-функции.
Про ЕСИА ничего вам не могу допонительно сказать. Не думаю, что Хабаровск создает значимую нагрузку, даже с остальными регионами ДВ — меньше 7ми миллионов на 3 часовых пояса. Но факторы складываются по разному, а внешняя система — есть внешняя система.
По ЕСИА я не могу сказать почему и даже не могу утверждать, что это было так. Это было в 2019 г. В субботу утром — моя гипотеза, что технические работы проводились. Это ночь по Москве — с этим во многих российских сервисах приходится сталкиваться. Кроме того, на мой взгляд — там разные группы серверов для разных макрорегионов. Но тех.ответ — все работает штатно. Кроме того, вылазают и сетевые проблемы периодически, какие-то операторы весть трафик кешируют, что-то не выдерживает. И ещё часто сбоят не сами системы, а системы защиты этих систем. В этом году такой проблемы не было — но услуга подаваль в пятницу вечером по Москве (у нас ночью).
По растягиванию — всё просто. Форма очень простая получилась и фактически полностью заполненная сразу, особенно если черновик предварительно заполнить. Поэтому черновик убрали. И убрали автоподстановку информации о детях и документах в этой услуге. Вбиваение этих данных требует времени. У обычного пользователя на это уходит от минуты (копировать/вставить и перечитать), у того кто вбивает на компьютере руками до 2-4х минут, а с телефонов и того больше.
Но более правильный вариант — форму вообще не показывать до начала подачи, иначе можно сгенерировать скрипты и заполнить всё за 1 секунду или вообще post запрос подготовить. А т.к. спрос есть — это может породить рынок.
Может быть не понял вопрос, но именно это и реализовано? Т.е. документация хранится вся на https://github.com/iondv/docs-ru исходная и переводы на https://github.com/iondv/docs-l18n. При этом к docs-l18n подключена веб-систем для переводов Weblate (это чтобы в обычных редакторах не редактировать и не пушить в репозиторий — хотя это тоже вполне возможно, т.е. веблейт он рядом, а не вместо).
При этом для смотрелки подключена readthedocs которая билдит из файлов rst с помощью sphinx html странички (но кстати и pdf-ки и epub тоже) — это можно и на сервере делать и выкладывать файлы под любой веб-сервер. На readthedocs на каждой страничке есть ссылка на редактирование оригинала на github.
Я к сожалению не знаю, что за системе у docker для документации используется.
Фреймворк — если классифицировать все же ближе к инструментальной цифровой платформе. Студия при этом код не генерирует — только метаданные в формате json описывающие структуры данных, их представления и бизнес-процессы. А также конфигурирует используемые модули приложения.
Функциональность приложения на фрейворке управляется метаданными, а не кодом. Свой код можно подключать на разных уровнях — на фронте в виде шаблонов к готовым модулям, в виде отдельных модулей, в виде инжекций в ядро, в виде кастомных веб-сервисов — но это уже не всегда в студии задается, а либо в метаданных (шаблон для представлений), либо в конфигурации приложения — файл deploy.json в приложениях.
MongoDb 4.2, в планах подключение PostgreSQL.
Для класса систем, которые работают с "коробки" — в практике проблем с транзакциями мы не наблюдали, поэтому отдельные логику не реализовали. Да и если транзакции важны — то скорее уже другую СУБД.
При работе нескольких пользователей с одним объектом, в модуле registry — универсальном модуле представления и работы с объектами, есть уведомление/блокировка об использовании другим пользователем.
Кстати с этим приложением. Его источник про льготные авиабилеты, а не талоны питания. Прокатывалось на одном из хакатонов 36 ч. Там на прототип ушло у двух команд по 5ть человек (2 разработчика, фронт и "мендежер") получается под 100 часов. Одна команда на 1С делала, другая на фронт + бек с нуля. Оба решения уровня демо. У нас прототип занял 8-мь часов. Хотя по проанализированной структуре это конечно за 1 час заводится. Остальное это переделки/переделки/переделки.
Да вы правы, сохранять открытость исходного кода необязательно. Обязательно указывать произведенные изменения и авторство/патенты и т.п. — по-моему это в текущих условиях публикации на гитхаб исходных кодов — в практике равносильно сохранению открытости исходных кодов ))), пусть и до модификации.
Коммерческую лицензия — да конечно же можно пилить. В этом весь смысл лицензии Апаче 2, на мой взгляд — давать развиваться другим командам и другим продуктам, основанном на исходном решении — в том числе в коммерческом смысле.
Это про вот эти две связки — в продукты под Apache 2.0 нельзя включать компоненты с GPL, зато наоборот компоненты под Apache в проекты GPL можно.
И да — Apache 2 позволяет сделать свой коммерческий продукт, это же неплохо? Но полностью закрыть нельзя — т.к. сохраняется требования раскрытия исходного кода и авторства (но с кодом JS — это наверное условное ограничение). А продавать позволяет и GPL v3.0 кстати
Jira это все таки про другое. В проекте для госки (регионального уровня) стартовая проблема — в том что они ворочают 100-страничными вордовскими файлами, собирают статусы мероприятий и показателей по электронной почте — также неструктурированно. И первый этап — это вообще сделать из текстовых документов — структурированные сущности. Потом к ним выстроить процесс ответственности — где можно посмотреть — кто за что отвечает. И фиксировать сроки не в моменты совещаний. А сразу в момент наступления — через систему посредника. И запретить задним числом подправлять. Документы проектные собирать и хранить в одном месте.
Потом вокруг наращивать уже остальное. И визуализацию в т.ч.
А перейти к модели задач из проектного управления — например на мой взгляд — высший пилотаж и я сомневаюсь, что такое где-то запущено. Там ведь и обратная ситуация — становится видна загрузка каждого чиновника (представьте почасовка в госке))). А сейчас модель проще — куча поручений в СЭД или в почте и вперед. Вопрос качества, возможности обработать это — никого особо не интересует. И в ответ показатели от фонаря.
Но в целом в нормативке есть зрелость проектного управления.
Мы все же делали проект на основе данных военкоматов хабаровского края — это действительно лишь один фрагмент. Мемориал — это федеральная система и там больше 20 млн. записей. Но несколько фамилий из случайной выборки не нашел — вот с этого листа например https://dvarchive.ru/files/cjnjoma7a00e705ms1sqn4f0u — лист 25об из книги учета призванных граждан в Красную Армию, составленной Советско-Гаванским городским военным комиссариатом: Ивлев Григорий Федорович или Иконников Иван Никитович. Я знаю, что эта информация во многих региональных архивах до сих пор не оцифрована и подобные проекты есть в других регионах. Не могу ничего сказать, насчет переговоров по передаче этих дел в базу Мемориал. Все таки мы занимались именно программным обеспечением, чтобы эти дела можно было перевести в электронный вид — структурировать данные, обеспечить частичную или полную публикацию сведений, распределить уровни доступа среди занимающихся обработкой волонтеров, сделать внешний поисковый инструмент.
В любом другом проекте — это можно использовать, доработать или переработать, если нужно — код открыт, лицензия открытого ПО — причем доработка самой системы правок кода не требует — в основном описание структур метаданных. Ресурсов система требует совсем не много — ведь кроме создать, ещё надо хранить и предоставлять доступ — текущая конфигурация проекта — это 600-800 рублей в месяц в Яндекс. облаке.
А централизация данных — это все таки чуть другая задача.
Это безусловно вечная проблема социальных проектов, когда они заканчиваются, что с ними делать дальше. И вопрос наверное больше в инициаторах — мы видим, что организаторы и команда — продолжают работать над этой темой и после. Там большие перепетии по проекту. Можно посмотреть в новостях на сайте АНО Дальневосточный центр социальных технологий и в соц.сетях. Кстати самому проекту больше года и к 9-мая — просто хороший повод напрячься и перетащить проект на яндекс.облако — такая уж традиция.
Сами данные маленький кусочек — но то что данные о дальневосточниках, хабаровчанах — вытащены из закрытого хранения архивов, в которые обычные граждане никогда не пойдут — здорово. Сами архивные бумаги, как были так и остались в архивах и работали с ними в самом гос.архиве.
Публикация кода приложения и технологии сборки — для социальных проектов под лицензией GPLv3 — нечастое событие, проектом оно не требовалось.
Спасибо, отличный вопрос, на котором мы немало сломали копий.
Сам фреймворк нацелен на разработчиков приложений, а не на упрощение первичного запуска приложения. Мы обсуждали модель использования npm для сборки приложения и она показалась нам слишком сложной, так как в корне тогда будет приложение, а ядро (сам фреймворк) или модули или другие связанные приложения — будут в папке node_modules.
Первый вопрос в версиях — приложения могут иметь разные версии ядра, а перевыпускать их под новые никто не будет и они соответственно вытащат другие версии зависимостей автоматически при сборке, как и зависимые модули — понятно, что будет все запущено под версиями основного приложения, а остальное будет храниться балластом.
Второй вопрос — приложение и модули собираются gulp, в т.ч. ставятся дополнительные зависимости для фронта — и они не прописаны в package.json самих модулей и приложений, а отдельно прописываются для групп шаблонов — например для war-archive — здесь. Сейчас — они иерархичные и сборка их проходит быстро. Альтернатива — все хранить в репозитории, в том числе минифицированные файлы и т.п.
Третье при запуске ядро подключает модули — т.е. мы ориентируемся на структуру хранения их файловой системе в виде жесткой иерархии, это упрощает разработку и позволяет работать/дорабатывать все приложения, модули раздельно и в раздельных репозиториях.
Само приложение мы собираем автоматически в docker контейнер, т.е. это проходит сборщик приложения в devops, есть подобный для ПК, но недоделанный по причине небольшой нужности.
Но вы натолкнули меня на мысли, или это и имели ввиду, что можно хранить сам фреймворк, модули компоненты в npmjs.org и по той же модели их ставить, т.е. вместо git clone ставить npm install — это сделаем быстро, при выпуске версии. Спасибо.
Какое отношение имеет agile к профессиональным навыкам бизнес-аналитика, позволяющих качественно вытянуть из заказчика его потребности, и исходя из своего собственного опыта и опыта, подчеркнутого из чужих успешных проектов, спроектировать наилучший для заказчика продукт?
Вся разница лишь в том, что с заказчиком обсуждаются модели, построение которых на порядок дешевле, чем программного продукта, внесение изменений, после обсуждений в них дешевле на порядок, чем в готовый продукт.
Часто это уже не так. По крайней мере есть ряд продуктов — на котором первичное макетирование метаданных почти ничего не стоит и при этом это уже будет работоспособный прототип, который выпускается частями и отрабатывается конкретные потребности и ожидания пользователей — пробующих. А объяснить заказчику на пальцах как будет выглядеть система, особенно когда участников множество — предъявляет к заказчику требования сопоставимые к уровню бизнес-аналитика, что просто невыполнимо.
Почитайте пример такого подхода по ссылке приведенной в статье. Заказчику ничего не мешает заключить с Вами договор на 3 коп. а после потребовать, реализации продукта на миллион. Причем все в рамках действующего законодательства.
Зачем мне читать — если я с этим просто работаю постоянно в практике )). Если дошло до законодательства, а это суд — значит проект изначально был непроработан и вовсе не в детализации проектных задач, а в модели управления им и рисками и отношениями с заказчиком.
Проекты с детальной, документированной проектной проработкой предполагают, что оба участника и заказчик и исполнитель находятся в конкурентной позиции. А есть большой класс задач и проектов, где это вовсе не так. В них заказчик также зависим от успешности проекта как и исполнитель. Банально в кастомных системах получить потом поддержку, если система выполнена по плану и формальным признакам с убытком исполнителя — будет крайне затруднительно. А без этого система жить и развиваться не будет дальше — деньги на неё будут просто выброшены. Таких примеров внедрений множество. Более того — задача внедрения ИС часто ведь жизненно необходима для заказчика — нормативно ли как для госки или обусловленная бизнес-убытками, потерей конкурентности. Поэтому если стороны заинтересованы получить результат — проще договориться, чем закрыться документированием.
Но безусловно это не договора на 3 копейки и в такие договора и проекты не входят без управления отношениями с заказчиком, что также является часть проектного управления.
На мой взгляд пропагандисты Scrum явно лукавят.<...>
Вопрос лишь в том, кто будет оплачивать все эти перерождения почти готового продукта? Тут возможно два базовых варианта:
* У заказчика есть неограниченный финансовый кредит.<...>
* Заказчик, заключив договор на определенную сумму<...>
Хм. Странно, а в моей практике наиболее массовый вариант — есть контракт с фиксированным бюджетом, но на входе не детализированное ТЗ. И управление объемом детализации, реализации и качеством — позволяет производить множество изменений на каждом из этапов.
Ведь зачастую, во многих крупных проектах внедрения информационных систем, заказчики не являются экспертами в том, что им нужно и уж тем более состава действий в проекте, т.к. не понимают что делает команда — они эксперты в своей области. И в конечном итоге то они ожидают результат от проработки их задачи, а не ритуального исполнения последовательности действий в диаграмме гантта.
Суть agile заключается в том, что возможность распланировать сложный проект до уровня часов и конкретных задач — это даже не инженерная или управленческая задача, а искусство — т.е. достаточно субъективная вещь. И даже атомарная инженерная задача в рамках проекта не имеет однозначных оценок трудозатрат — так как в том числе упирается в конкретного исполнителя с его системой мотивации, квалификации и готовности окружения с которым он будет работать.
Поэтому вместо того, чтобы самообманываться, что процесс в областях с высокой неопределенностью будет контролируемым на всю глубину — предлагается иметь цель и корректировать средства, методы, а часто и результаты в ходе проекта. А вопрос оценки стоимости оставить все же искусству продавцов.
Мне кажется — разделение на бизнес-презентацию — как КП и публичную — не совсем верно, по крайней мере в конференциях в ИТ среде. Презентация — это то, что остается после выступления у потенциального потребителя. И на многих конференциях — презентации скачивают на флешки. Соответственно — она должна содержать ключевые тезисы выступления. Что опять же помогает докладчику не сбиться с мысли и не пропустить важные вещи, которые хочется отметить.
Посмотрел обновления доки у протрактора — в настройках protractor-a можно поставить подключение к хром-драйверу напрямую без силениума directConnect: true, а также запускать в режиме без окна
Собственно вопрос в том, насколько уместно применять термин и перенос технологии конвейера, решающего задачи тиражирования, к проектированию. Проектирование автомобилей, разве конвейерное производство? Если для технологии разработки ПО, даже массового, притягивать термин конвейера — то это все равно будет совсем другая сущность, и логичнее для неё другой термин и применять.
Переключение специалистов между разными потоками объектов и циклами разработки — мне не кажется даже близко похожим на выполнение одной и той же рудиментной операции на своем участке. Даже противоположной — здесь мы не разные однотипные объекты подаем одному специалисту на один этап. А одного специалиста на разные типы объектов переключаем и зачастую разные задачи он решает, по специализации.
Тут какая штука — пока весь состав атрибутов заявления не передан в интегрированную информационную систему образования, заявление не считается поданным и соответственно права "первоорчедености" не возникает.
Сама подача ведь тоже верифицируется на стороне сервера — там есть логика проверки на фронте, а есть и серверая логика верификации значений справочников хотя бы.
Опять же — если то, что вы подали раньше всех не соответствует логике и требования адм.регламента записи — это заявление просто отклонят. Ну например адрес вы не укажите или другой какой-то, не соответствующий школе. Поэтому полное заполнение заявления — это обязательное условие. В идеале (и в практике для ряда услуг) — весь состав данных подписывается эл.подписью для юридической значимости. Но т.к. это сложно организовать для граждан — используется простая эл.подпись, но де факто юридическая значимость обеспечивается статусом информационной системы, логгированием всех запросов и подразумеваемой возможностью инициировать проверку прокуратуры и изъятия всех этих данных для ручной сверки. Происходит редко именно в силу посреднической функции, т.е. доверительной, которую выполняют региональные порталы между гражданами(браузерами) и ведомствами(инф.системами).
Браузер в этой схеме является несертифицированным армом — т.е. логике на его стороне фактически нет никакого доверия — т.к. действительно можно и в скрипты вмешиваться и состав данных подправить прямо в форме, даже в заблокированных для редактирования полей и просто POST запрос сгенерировать. Т.е. важно — идентификтор пользователя в виде сессии авторизации и состав данных по полям. И когда валидация сессии и соответствия состава полей и каких-то формальных требований к содержанию пройденно — именно это и является заявлением и фактом его подачи.
Досылка даных — это уже другой процесс. Такой например есть в госэкспертизе. Там вы подаете заявление, но реальные данные выгружаете (сканы документов проектых) уже после регистрации факта подачи.
Хотя де юре можно сделать простую кнопку — "встать очередь" — так видят услугу многие пользователи и к этому логика развития эл.услуг идет. Только нужно адм.регламенты написать и закрепить их. Тогда нужно передать только сессию пользователя и его "желание получить услугу". А данные дослать или запросить в других ведомствах. Но тогда мы опять же получим δ-функцию в отправке.
И получим кучу других проблем — а действительно он выразил это желание или случайно нажал? Это как в договоре — банку недостаточно вашей подписи, они ещё и ФИО просит написать — чтобы гарантировать, что это вы. А нотариус сколько вопросов задает, чтобы понять дееспособность и осознанность намерения. Ввод доп.данных служит в том числе и этой цели. Ну и растягивает подачу на какое-то время, меняя модель случайно успел нажать, систему случано раньше получила из-за случайных сетевого состояния — на какой-то соревнуемый навык — быстрее печатал, знал как скрипт написать автозаполнения — это вместо быстрого коня на диком западе ))) Иначе можно и просто лотерею ввести. Что будет справедливее?
Так именно родители этого малого числа школ и создают эту нагрузку — их примерно до 10% от общего кол-ва школьников. В остальные школы проще прийти с документами до конца мая без шума и спешки.
Можно по всякому решать. Единственно в услуге запись в первый класс очень критично время подачи — по нему формируется очередь — это юридически значимо — а передать id без минимум ФИО родителя/ребенка — это уже не то, вдруг потом данные не дойдут.
Тем более проблемы на этапе подачи не было — нагрузка растянутая на 3-5 минут уже вполне решаемая на этих объемах. И её протестировать хорошо вполне возможно. Основаня проблема в обновлении в 0:00 минут — этот пик, дельта фукцию, не обойти никак. И её кстати сложно сэмулировать нагрузкой — можно только экстраполяции делать на динамике с разной нагрузкой и выдвигать гипотезы — что вперед будет "выбрано" — канал, производительность коммутационного оборудования, производительность защиты или ошибки в настройках алогоритмов, ресурсы сервера. Кстати канал и коммутаторы не всегда в ЦОДе — ведь есть ещё операторы связи в городах, районах и у некоторых они не с таким уж большим резервом — а трафик из ютуба очень отличается от этой δ-функции.
Про ЕСИА ничего вам не могу допонительно сказать. Не думаю, что Хабаровск создает значимую нагрузку, даже с остальными регионами ДВ — меньше 7ми миллионов на 3 часовых пояса. Но факторы складываются по разному, а внешняя система — есть внешняя система.
По ЕСИА я не могу сказать почему и даже не могу утверждать, что это было так. Это было в 2019 г. В субботу утром — моя гипотеза, что технические работы проводились. Это ночь по Москве — с этим во многих российских сервисах приходится сталкиваться. Кроме того, на мой взгляд — там разные группы серверов для разных макрорегионов. Но тех.ответ — все работает штатно. Кроме того, вылазают и сетевые проблемы периодически, какие-то операторы весть трафик кешируют, что-то не выдерживает. И ещё часто сбоят не сами системы, а системы защиты этих систем. В этом году такой проблемы не было — но услуга подаваль в пятницу вечером по Москве (у нас ночью).
По растягиванию — всё просто. Форма очень простая получилась и фактически полностью заполненная сразу, особенно если черновик предварительно заполнить. Поэтому черновик убрали. И убрали автоподстановку информации о детях и документах в этой услуге. Вбиваение этих данных требует времени. У обычного пользователя на это уходит от минуты (копировать/вставить и перечитать), у того кто вбивает на компьютере руками до 2-4х минут, а с телефонов и того больше.
Но более правильный вариант — форму вообще не показывать до начала подачи, иначе можно сгенерировать скрипты и заполнить всё за 1 секунду или вообще post запрос подготовить. А т.к. спрос есть — это может породить рынок.
Если хостить Weblate самим, то собирать документацию и хостить статичные html-ки собранные sphinx конечно уже не сложно, больше было про это.
Может быть не понял вопрос, но именно это и реализовано? Т.е. документация хранится вся на https://github.com/iondv/docs-ru исходная и переводы на https://github.com/iondv/docs-l18n. При этом к docs-l18n подключена веб-систем для переводов Weblate (это чтобы в обычных редакторах не редактировать и не пушить в репозиторий — хотя это тоже вполне возможно, т.е. веблейт он рядом, а не вместо).
При этом для смотрелки подключена readthedocs которая билдит из файлов rst с помощью sphinx html странички (но кстати и pdf-ки и epub тоже) — это можно и на сервере делать и выкладывать файлы под любой веб-сервер. На readthedocs на каждой страничке есть ссылка на редактирование оригинала на github.
Я к сожалению не знаю, что за системе у docker для документации используется.
Фреймворк — если классифицировать все же ближе к инструментальной цифровой платформе. Студия при этом код не генерирует — только метаданные в формате json описывающие структуры данных, их представления и бизнес-процессы. А также конфигурирует используемые модули приложения.
Функциональность приложения на фрейворке управляется метаданными, а не кодом. Свой код можно подключать на разных уровнях — на фронте в виде шаблонов к готовым модулям, в виде отдельных модулей, в виде инжекций в ядро, в виде кастомных веб-сервисов — но это уже не всегда в студии задается, а либо в метаданных (шаблон для представлений), либо в конфигурации приложения — файл deploy.json в приложениях.
MongoDb 4.2, в планах подключение PostgreSQL.
Для класса систем, которые работают с "коробки" — в практике проблем с транзакциями мы не наблюдали, поэтому отдельные логику не реализовали. Да и если транзакции важны — то скорее уже другую СУБД.
При работе нескольких пользователей с одним объектом, в модуле registry — универсальном модуле представления и работы с объектами, есть уведомление/блокировка об использовании другим пользователем.
Кстати с этим приложением. Его источник про льготные авиабилеты, а не талоны питания. Прокатывалось на одном из хакатонов 36 ч. Там на прототип ушло у двух команд по 5ть человек (2 разработчика, фронт и "мендежер") получается под 100 часов. Одна команда на 1С делала, другая на фронт + бек с нуля. Оба решения уровня демо. У нас прототип занял 8-мь часов. Хотя по проанализированной структуре это конечно за 1 час заводится. Остальное это переделки/переделки/переделки.
Да вы правы, сохранять открытость исходного кода необязательно. Обязательно указывать произведенные изменения и авторство/патенты и т.п. — по-моему это в текущих условиях публикации на гитхаб исходных кодов — в практике равносильно сохранению открытости исходных кодов ))), пусть и до модификации.
Коммерческую лицензия — да конечно же можно пилить. В этом весь смысл лицензии Апаче 2, на мой взгляд — давать развиваться другим командам и другим продуктам, основанном на исходном решении — в том числе в коммерческом смысле.
Это про вот эти две связки — в продукты под Apache 2.0 нельзя включать компоненты с GPL, зато наоборот компоненты под Apache в проекты GPL можно.
И да — Apache 2 позволяет сделать свой коммерческий продукт, это же неплохо? Но полностью закрыть нельзя — т.к. сохраняется требования раскрытия исходного кода и авторства (но с кодом JS — это наверное условное ограничение). А продавать позволяет и GPL v3.0 кстати
Jira это все таки про другое. В проекте для госки (регионального уровня) стартовая проблема — в том что они ворочают 100-страничными вордовскими файлами, собирают статусы мероприятий и показателей по электронной почте — также неструктурированно. И первый этап — это вообще сделать из текстовых документов — структурированные сущности. Потом к ним выстроить процесс ответственности — где можно посмотреть — кто за что отвечает. И фиксировать сроки не в моменты совещаний. А сразу в момент наступления — через систему посредника. И запретить задним числом подправлять. Документы проектные собирать и хранить в одном месте.
Потом вокруг наращивать уже остальное. И визуализацию в т.ч.
А перейти к модели задач из проектного управления — например на мой взгляд — высший пилотаж и я сомневаюсь, что такое где-то запущено. Там ведь и обратная ситуация — становится видна загрузка каждого чиновника (представьте почасовка в госке))). А сейчас модель проще — куча поручений в СЭД или в почте и вперед. Вопрос качества, возможности обработать это — никого особо не интересует. И в ответ показатели от фонаря.
Но в целом в нормативке есть зрелость проектного управления.
Мы все же делали проект на основе данных военкоматов хабаровского края — это действительно лишь один фрагмент. Мемориал — это федеральная система и там больше 20 млн. записей. Но несколько фамилий из случайной выборки не нашел — вот с этого листа например https://dvarchive.ru/files/cjnjoma7a00e705ms1sqn4f0u — лист 25об из книги учета призванных граждан в Красную Армию, составленной Советско-Гаванским городским военным комиссариатом: Ивлев Григорий Федорович или Иконников Иван Никитович. Я знаю, что эта информация во многих региональных архивах до сих пор не оцифрована и подобные проекты есть в других регионах. Не могу ничего сказать, насчет переговоров по передаче этих дел в базу Мемориал. Все таки мы занимались именно программным обеспечением, чтобы эти дела можно было перевести в электронный вид — структурировать данные, обеспечить частичную или полную публикацию сведений, распределить уровни доступа среди занимающихся обработкой волонтеров, сделать внешний поисковый инструмент.
В любом другом проекте — это можно использовать, доработать или переработать, если нужно — код открыт, лицензия открытого ПО — причем доработка самой системы правок кода не требует — в основном описание структур метаданных. Ресурсов система требует совсем не много — ведь кроме создать, ещё надо хранить и предоставлять доступ — текущая конфигурация проекта — это 600-800 рублей в месяц в Яндекс. облаке.
А централизация данных — это все таки чуть другая задача.
Это безусловно вечная проблема социальных проектов, когда они заканчиваются, что с ними делать дальше. И вопрос наверное больше в инициаторах — мы видим, что организаторы и команда — продолжают работать над этой темой и после. Там большие перепетии по проекту. Можно посмотреть в новостях на сайте АНО Дальневосточный центр социальных технологий и в соц.сетях. Кстати самому проекту больше года и к 9-мая — просто хороший повод напрячься и перетащить проект на яндекс.облако — такая уж традиция.
Сами данные маленький кусочек — но то что данные о дальневосточниках, хабаровчанах — вытащены из закрытого хранения архивов, в которые обычные граждане никогда не пойдут — здорово. Сами архивные бумаги, как были так и остались в архивах и работали с ними в самом гос.архиве.
Публикация кода приложения и технологии сборки — для социальных проектов под лицензией GPLv3 — нечастое событие, проектом оно не требовалось.
Спасибо, отличный вопрос, на котором мы немало сломали копий.
Сам фреймворк нацелен на разработчиков приложений, а не на упрощение первичного запуска приложения. Мы обсуждали модель использования npm для сборки приложения и она показалась нам слишком сложной, так как в корне тогда будет приложение, а ядро (сам фреймворк) или модули или другие связанные приложения — будут в папке node_modules.
Первый вопрос в версиях — приложения могут иметь разные версии ядра, а перевыпускать их под новые никто не будет и они соответственно вытащат другие версии зависимостей автоматически при сборке, как и зависимые модули — понятно, что будет все запущено под версиями основного приложения, а остальное будет храниться балластом.
Второй вопрос — приложение и модули собираются gulp, в т.ч. ставятся дополнительные зависимости для фронта — и они не прописаны в package.json самих модулей и приложений, а отдельно прописываются для групп шаблонов — например для war-archive — здесь. Сейчас — они иерархичные и сборка их проходит быстро. Альтернатива — все хранить в репозитории, в том числе минифицированные файлы и т.п.
Третье при запуске ядро подключает модули — т.е. мы ориентируемся на структуру хранения их файловой системе в виде жесткой иерархии, это упрощает разработку и позволяет работать/дорабатывать все приложения, модули раздельно и в раздельных репозиториях.
Само приложение мы собираем автоматически в docker контейнер, т.е. это проходит сборщик приложения в devops, есть подобный для ПК, но недоделанный по причине небольшой нужности.
Но вы натолкнули меня на мысли, или это и имели ввиду, что можно хранить сам фреймворк, модули компоненты в npmjs.org и по той же модели их ставить, т.е. вместо
git cloneставитьnpm install— это сделаем быстро, при выпуске версии. Спасибо.Часто это уже не так. По крайней мере есть ряд продуктов — на котором первичное макетирование метаданных почти ничего не стоит и при этом это уже будет работоспособный прототип, который выпускается частями и отрабатывается конкретные потребности и ожидания пользователей — пробующих. А объяснить заказчику на пальцах как будет выглядеть система, особенно когда участников множество — предъявляет к заказчику требования сопоставимые к уровню бизнес-аналитика, что просто невыполнимо.
Зачем мне читать — если я с этим просто работаю постоянно в практике )). Если дошло до законодательства, а это суд — значит проект изначально был непроработан и вовсе не в детализации проектных задач, а в модели управления им и рисками и отношениями с заказчиком.
Проекты с детальной, документированной проектной проработкой предполагают, что оба участника и заказчик и исполнитель находятся в конкурентной позиции. А есть большой класс задач и проектов, где это вовсе не так. В них заказчик также зависим от успешности проекта как и исполнитель. Банально в кастомных системах получить потом поддержку, если система выполнена по плану и формальным признакам с убытком исполнителя — будет крайне затруднительно. А без этого система жить и развиваться не будет дальше — деньги на неё будут просто выброшены. Таких примеров внедрений множество. Более того — задача внедрения ИС часто ведь жизненно необходима для заказчика — нормативно ли как для госки или обусловленная бизнес-убытками, потерей конкурентности. Поэтому если стороны заинтересованы получить результат — проще договориться, чем закрыться документированием.
Но безусловно это не договора на 3 копейки и в такие договора и проекты не входят без управления отношениями с заказчиком, что также является часть проектного управления.
Хм. Странно, а в моей практике наиболее массовый вариант — есть контракт с фиксированным бюджетом, но на входе не детализированное ТЗ. И управление объемом детализации, реализации и качеством — позволяет производить множество изменений на каждом из этапов.
Ведь зачастую, во многих крупных проектах внедрения информационных систем, заказчики не являются экспертами в том, что им нужно и уж тем более состава действий в проекте, т.к. не понимают что делает команда — они эксперты в своей области. И в конечном итоге то они ожидают результат от проработки их задачи, а не ритуального исполнения последовательности действий в диаграмме гантта.
Суть agile заключается в том, что возможность распланировать сложный проект до уровня часов и конкретных задач — это даже не инженерная или управленческая задача, а искусство — т.е. достаточно субъективная вещь. И даже атомарная инженерная задача в рамках проекта не имеет однозначных оценок трудозатрат — так как в том числе упирается в конкретного исполнителя с его системой мотивации, квалификации и готовности окружения с которым он будет работать.
Поэтому вместо того, чтобы самообманываться, что процесс в областях с высокой неопределенностью будет контролируемым на всю глубину — предлагается иметь цель и корректировать средства, методы, а часто и результаты в ходе проекта. А вопрос оценки стоимости оставить все же искусству продавцов.
protractor и страницы без ангуляра отлично работает с параметром browser.ignoreSynchronization = true;
Конфигурированием файла protractor.conf.js для автоматического запуска селениума и использования драйвера хрома
+ установка системы тестирования mocha+chai или jasmine.
Но это конечно с окном chrome — надо будет попробовать эту же связку в headless режиме
Переключение специалистов между разными потоками объектов и циклами разработки — мне не кажется даже близко похожим на выполнение одной и той же рудиментной операции на своем участке. Даже противоположной — здесь мы не разные однотипные объекты подаем одному специалисту на один этап. А одного специалиста на разные типы объектов переключаем и зачастую разные задачи он решает, по специализации.