Комментарии 7
Почему бы не дистрибьютить зависимости через npm?
А то ходить руками клонить все зависимости и чекаутить — ну такое себе
Спасибо, отличный вопрос, на котором мы немало сломали копий.
Сам фреймворк нацелен на разработчиков приложений, а не на упрощение первичного запуска приложения. Мы обсуждали модель использования npm для сборки приложения и она показалась нам слишком сложной, так как в корне тогда будет приложение, а ядро (сам фреймворк) или модули или другие связанные приложения — будут в папке node_modules.
Первый вопрос в версиях — приложения могут иметь разные версии ядра, а перевыпускать их под новые никто не будет и они соответственно вытащат другие версии зависимостей автоматически при сборке, как и зависимые модули — понятно, что будет все запущено под версиями основного приложения, а остальное будет храниться балластом.
Второй вопрос — приложение и модули собираются gulp, в т.ч. ставятся дополнительные зависимости для фронта — и они не прописаны в package.json самих модулей и приложений, а отдельно прописываются для групп шаблонов — например для war-archive — здесь. Сейчас — они иерархичные и сборка их проходит быстро. Альтернатива — все хранить в репозитории, в том числе минифицированные файлы и т.п.
Третье при запуске ядро подключает модули — т.е. мы ориентируемся на структуру хранения их файловой системе в виде жесткой иерархии, это упрощает разработку и позволяет работать/дорабатывать все приложения, модули раздельно и в раздельных репозиториях.
Само приложение мы собираем автоматически в docker контейнер, т.е. это проходит сборщик приложения в devops, есть подобный для ПК, но недоделанный по причине небольшой нужности.
Но вы натолкнули меня на мысли, или это и имели ввиду, что можно хранить сам фреймворк, модули компоненты в npmjs.org и по той же модели их ставить, т.е. вместо git clone ставить npm install — это сделаем быстро, при выпуске версии. Спасибо.
Это безусловно вечная проблема социальных проектов, когда они заканчиваются, что с ними делать дальше. И вопрос наверное больше в инициаторах — мы видим, что организаторы и команда — продолжают работать над этой темой и после. Там большие перепетии по проекту. Можно посмотреть в новостях на сайте АНО Дальневосточный центр социальных технологий и в соц.сетях. Кстати самому проекту больше года и к 9-мая — просто хороший повод напрячься и перетащить проект на яндекс.облако — такая уж традиция.
Сами данные маленький кусочек — но то что данные о дальневосточниках, хабаровчанах — вытащены из закрытого хранения архивов, в которые обычные граждане никогда не пойдут — здорово. Сами архивные бумаги, как были так и остались в архивах и работали с ними в самом гос.архиве.
Публикация кода приложения и технологии сборки — для социальных проектов под лицензией GPLv3 — нечастое событие, проектом оно не требовалось.
у https://obd-memorial.ru 4 млн записей
35к записей как-то не серьезно
Поэтому наша позиция — это взять и изменить ситуацию. Что получилось? Доки отсканированы, создана база, работа с ней продолжается, люди находят вехи истории своих родных.
Отзыв техдиректора ресурсов «ОБД-Мемориал», «Память народа», «Подвиг народа», одного из ключевых консультантов нашего проекта по ссылке. Частью миссии проекта была как раз передача цифровых копий в Минобороны.
Вообще в выполнении рутины, как правило, успешны не общественные движения, а упертые инициативные группы или одиночки. Вот это свободное по — оно в том числе и для них.
А про количество. Гора, конечно, не должна рождать мышь, но эффект от этой работы — это истории тех, кто находит своих. Или позже найдет.
Единицы, десятки, тысячи кусочков истории, появляющиеся из военкоматов, личных, иностранных архивов — это шансы определить судьбу без вести пропавшего или веху истории людей, которых уже нет рядом.
И тут нужны технологии. например, распознавания текстов — иначе эта работа и будет двигаться очень и очень медленно.
Есть еще задачи, когда поисковики подняли останки бойца, архивисты или энтузиасты опубликовали новые документы — а ныне живущих родных найти крайне трудно — современные законы и обилие неупорядоченной информации.
Мы все же делали проект на основе данных военкоматов хабаровского края — это действительно лишь один фрагмент. Мемориал — это федеральная система и там больше 20 млн. записей. Но несколько фамилий из случайной выборки не нашел — вот с этого листа например https://dvarchive.ru/files/cjnjoma7a00e705ms1sqn4f0u — лист 25об из книги учета призванных граждан в Красную Армию, составленной Советско-Гаванским городским военным комиссариатом: Ивлев Григорий Федорович или Иконников Иван Никитович. Я знаю, что эта информация во многих региональных архивах до сих пор не оцифрована и подобные проекты есть в других регионах. Не могу ничего сказать, насчет переговоров по передаче этих дел в базу Мемориал. Все таки мы занимались именно программным обеспечением, чтобы эти дела можно было перевести в электронный вид — структурировать данные, обеспечить частичную или полную публикацию сведений, распределить уровни доступа среди занимающихся обработкой волонтеров, сделать внешний поисковый инструмент.
В любом другом проекте — это можно использовать, доработать или переработать, если нужно — код открыт, лицензия открытого ПО — причем доработка самой системы правок кода не требует — в основном описание структур метаданных. Ресурсов система требует совсем не много — ведь кроме создать, ещё надо хранить и предоставлять доступ — текущая конфигурация проекта — это 600-800 рублей в месяц в Яндекс. облаке.
А централизация данных — это все таки чуть другая задача.
Опыт вывода программной реализации социального проекта «Вспомнить каждого» в опенсорс