Comments 21
Довольно узко-специфичная штука конечно.
В последнем сафари не работает отображение дерева. Просто не грузится. При переключении вкладок показывает ошибку загрузки.
Не работает таким же образом на Edge 120 (Windows 10).
Ещё интересно было бы узнать, если я не проглядел, а есть ли поддержка импорта/экспорта GEDCOM файлов?
Дело не в браузере - видимо, какая-то проблема с демо-режимом, из-за которой дерево не просчитывается при рестарте контейнера. Если поменять настройки туда-сюда, все отображается. Поправлю :)
В тексте везде используется слово "дерево", поэтому у меня возник вопрос: а что, если не дерево? Есть случай, когда у мужчины были дети от собственной дочери. Справится ли приложение? Что, если в него ввести династию Габсбургов?
Со стороны отрисовки никаких проблем нет: библиотека поддерживает любые графы, хоть с циклами, поэтому можно будет отрисовать и Габсбургов, и персонажей сериала Dark. Однако в текущей версии это сознательно запрещено валидацией, поскольку с куда большей вероятностью это не реальная ситуация в семье, а просто ошибка ввода данных админом. Возможно стоит сделать для этого настройку
Пользуюсь bonsai с ранних версий.
После GRAMPS эмоции исключительно положительные, нет лишнего (GRAMPS создан для глубоких исследований, процентов 90 функций мешают для "домашних" деревьев, плюс много багов и легаси). Есть баги по UI, но не напрягают.
А почему не специализированная БД типа Neo4j Graph Database?
Потому что Bonsai - не хайлоад-проект. Скольких родственников вы можете вспомнить и скольким хотите предоставить доступ? По моему опыту, эти цифры равны примерно 100 и 10 соответственно. Ну даже если у вас будет 500 страниц в базе, она все равно будет занимать от силы 10 мегабайт и легко умещаться в оперативку целиком. Вы предлагаете это хранить в базе энтерпрайз-уровня, где только контейнер занимает ~500 метров - чтобы что?
Чтобы не было вот тех проблем с производительностью, на которые были жалобы. Я сильно в вопрос не вдавался, но наверняка есть и более легковесные решения, если прям хочется место сэкономить.
Проблема с производительностью была при отображении дерева, т.е. при вычислении визуального расположения карточек на плоскости так, чтобы связи между ними были как можно короче и как можно меньше пересекались. Я только очень бегло прочитал про Neo4J, но кажется что она про хранение, а не про расположение, или ошибаюсь?
https://habr.com/ru/articles/650623/
Встроенный механизм есть, так что в теории возможно. Но я не спец в этой области, просто по описанию проблемы сделал предположение, что очень вероятно, что она давно решена где-то. И графовые БД выглядят вполне себе кандидатом на эту роль.
Такие диаграммы, как в иллюстрациях к статье, не совсем подходят для отображения фамильного дерева: Нужно, чтобы карточки располагались на горизонтальных уровнях, а соединительные линии были ортогональными. Кроме того, судя по документации к Neo4J, база просто хранит данные, а визуализацией занимаются отдельные инструменты, интеграция с которыми сулит дополнительный геморрой.
Иронично, что первый же комментарией под статьей про Neo4J задает вопрос "а почему не PostgreSQL" :)
Интересная штука, спасибо за информацию, посмотрю! Но очень нужен GEOCOM, ведь начинать ведение дерева с нуля мало кто захочет. А штука действительно узкоспециализированная.
Спасибо. Я как раз искал подобную штуку как раз чтобы поставить на домашний сервер и дать доступы всей семье. Судя по статье это прям то, что я искал!
Автору ещё раз респект. Развернул приложение на своем домашнем NAS, и начал отправлять ссылки всем родственникам. Вопросы по функционалу у них конечно появляться, но учитывая насколько приложение концептуально простое не думаю, что адаптация займет много времени.
Вернулся к статье и перечитал более вдумчиво (не по заголовкам), и увидел что и взгляд автора я разделяю. Жаль, конечно, что написано на C#, т.к. по религиозным убеждениям тяжело себя заставить контрибьютить, но как найдется что-то, заслуживающее этого, обязательно создам пулл реквест.
Особенно импонируют мысли автора о простоте (sqlite топ, все аргументы будто сам писал), и мысли о долгой жизни проекта. Отсюда, приходит идея, почему ты не реализовать проект на языке который в своей идеологией ставит обратную совместимость (например go), или язык который пережил большинство своих сверстников, и здравствует до сих пор - lisp (например clojure, или common lisp), чтобы как раз не пришлось часто обновлять и переписывать проект каждые n лет. Не знаю, конечно, насколько эта идея жизнеспособна. Покажет только время.
В любом случае, большое спасибо за проект. Второй проект как галерея также интересен, т.к. родственники первыми делом начали отправлять фотографии природы, что на мой взгляд не совсем то, для чего нужен bonsai.
Спасибо за отзыв!
Насчет технологического стека - выбрал то, что знаю лучше всего. Изучать новый язык в процессе написания такого проекта, имхо, было бы неправильно - легко можно наделать глупых ошибок, с которыми придется потом жить.
Насчет обратной совместимости у C#, кстати, все очень хорошо: если говорить про собственные исходники, то она идет вплоть до самой первой версии 2002 года. Опасения по поводу переписывания вызывают скорее сторонние библиотеки, которые могут перестать поддерживаться авторами, или невозможность реализовать какой-то новый функционал на существующем фундаменте. Я периодически обновляю рантайм до актуальной версии и никаких проблем, занявших бы больше получаса времени на решение, пока не встретил.
На тему фотогаллереи могу также посоветовать Photoprism - тоже self-hosted решение, только с куда большим функционалом (например, есть распознавание лиц).
Фамильный вики-движок Bonsai: 6 лет спустя