Комментарии 17
А есть подобные OpenSource проекты?
Собственно, сам проект вполне open-source — используйте и модифицируйте как хотите. Платформа с открытыми исходниками, но с несвободной лицензией, ограничивающей количество одновременно работающих в приложении пользователей (5 бесплатно).
А вообще систему учета персональных финансов думаю и полностью свободную можно найти.
А вообще систему учета персональных финансов думаю и полностью свободную можно найти.
У вас помимо пользователей там ещё некие «процессы» (которых также должно быть не больше 5 при начальной лицензии) на сайте упомянуты.
Что есть процессы, здесь?
Что есть процессы, здесь?
Лицензией ограничивается количество одновременных «пользовательских сессий». Сессии создается при логине пользователей-людей, а также могут создаваться для работы асинхронных процессов. Например запускаете механизм выполнения задач по расписанию — одна сессия создается шедулером. Можно все таски запускать от одного пользователя, тогда они будут пользоваться той же сессией. Иногда удобно каждой таске дать своего пользователя, тогда они будут создавать дополнительные сессии.
В этом приложении никаких асинхронных процессов пока нет. Можете зайти в Administration -> User Sessions — увидите одну свою сессию.
В этом приложении никаких асинхронных процессов пока нет. Можете зайти в Administration -> User Sessions — увидите одну свою сессию.
Проект MyFin habrahabr.ru/post/108046 автор Pozadi
Это круто! Пользуюсь drebedengi, хотел одно время переехать на zenmoney, но не удалось перенести данные из одной системы в другую.
Есть же множество англоязычных аналогов. Например, zenmoney делался по подобию mint.com.
Сам хочу начат учет финансов. Хотелось бы узнать чем англоговорящие пользуются.
Сам хочу начат учет финансов. Хотелось бы узнать чем англоговорящие пользуются.
Поэтому использую Google Docs. Специализированный софт слишком не надежный, импорт/экспорт данных отсутствует как класс…
Конечно, не так удобно, как спец софт, но зато можно не бояться потерять данные.
Конечно, не так удобно, как спец софт, но зато можно не бояться потерять данные.
У вас упоминаются 2 типа веб-интерфейса, в чем их функциональные различия? Какие технологии используются?
Основной UI — предоставляет все функции приложения. Быстро пишется на XML+Java, можно использовать WYSIWYG-редактор экранов Студии. Рендерится для веб с помощью Vaadin, для десктоп с помощью Swing. Веб работает на всех устройствах, но, во-первых, тыкать в него пальцами неудобно, а во-вторых он non-responsive, т.е. не умеет меняться в зависимости от размеров экрана.
Поэтому сделан второй UI на чистом JavaScript+Bootstrap. Через него не все можно сделать, зато удобно пользоваться на мобилках. Трудозатраты на него конечно на порядок выше чем на основной UI.
Визуальная разница надеюсь понятна из скриншотов в начале статьи.
Этот подход используется нами во многих коммерческих приложениях — основной полнофункциональный UI для сотрудников предприятия, пользующихся системой, а на классических веб-технологиях красивые веб-сайты для внешних пользователей.
Поэтому сделан второй UI на чистом JavaScript+Bootstrap. Через него не все можно сделать, зато удобно пользоваться на мобилках. Трудозатраты на него конечно на порядок выше чем на основной UI.
Визуальная разница надеюсь понятна из скриншотов в начале статьи.
Этот подход используется нами во многих коммерческих приложениях — основной полнофункциональный UI для сотрудников предприятия, пользующихся системой, а на классических веб-технологиях красивые веб-сайты для внешних пользователей.
Чего нельзя сделать через JavaScript+Bootstrap и как это обходить, если хочется и сделать все, и чтоб красиво было?
А почему для вытаскивания старых значений сущностей вы поднимаете отдельную транзакцию со своим EntityManager'ом? Не многовато накладных расходов, если количество таких listner'ов будет расти?
У вас же в OpenJPA в enhance'нутых классах сущностей старые значения храняться. Наверняка есть API для получения старых значений. К примеру в EclipseLink'е это делается путём приведения EntityManager'а к o.e.p.s.UnitOfWork в котором есть метод getCurrentChanges(), из которого можно потом получить список изменений по объекту сущности.
У вас же в OpenJPA в enhance'нутых классах сущностей старые значения храняться. Наверняка есть API для получения старых значений. К примеру в EclipseLink'е это делается путём приведения EntityManager'а к o.e.p.s.UnitOfWork в котором есть метод getCurrentChanges(), из которого можно потом получить список изменений по объекту сущности.
В OpenJPA нет публичного API для доступа к старым значениям. Чтобы добраться до атрибута Operation.amount1, в листенере придется написать такое:
Однако спасибо за идею, возможно мы сделаем удобную обертку для такой операции.
На всякий случай отмечу, что это будет работать только для managed-экземпляра, для которого уже выполнен merge. В detached-экземплярах старых значений нет, там только список номеров измененных полей. И значений там быть не должно, иначе будет дополнительная нагрузка на память и на сериализацию, в то время как нужны эти старые значения в 0.1% случаев.
((Operation) ((StateManagerImpl) ((PersistenceCapable) entity).pcGetStateManager()).getSaveFieldManager().getState()).getAmount1()
Однако спасибо за идею, возможно мы сделаем удобную обертку для такой операции.
На всякий случай отмечу, что это будет работать только для managed-экземпляра, для которого уже выполнен merge. В detached-экземплярах старых значений нет, там только список номеров измененных полей. И значений там быть не должно, иначе будет дополнительная нагрузка на память и на сериализацию, в то время как нужны эти старые значения в 0.1% случаев.
Очень понравилась данная платформа, но дороговато. С одной стороны это можно понять, ведь лучше поддерживать 10 клиентов которые заплатят 150к. чем сто которые заплатят 15к. :) Но с другой стороны был бы более привлекательным полностью свободный продукт у которого платная только поддержка.
Мы серьезно рассматривали вариант Open Source. Но вы совершенно правы, значительно легче поддерживать ограниченный круг клиентов. Ведь всегда останется бесплатная поддержка в виде ответов на форуме и т.п., и она требует много сил если делать качественно. По ценам мы ориентировались в первую очередь на стоимость разработки — если платформа поможет уменьшить трудозатраты на проект и дальнейшее развитие даже на 2-3 человеко-месяца, это уже выгодно. По нашим оценкам, уже для средних проектов экономия в разы выше. Для небольших проектов есть бесплатная лицензия (до 5 конкурентных) или достаточно дешевая до 20 конкурентных пользователей — что вполне может означать 50 и более уникальных. Поэтому мне кажется, что ценовая политика вполне разумная.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Домашняя бухгалтерия на платформе CUBA