Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ioan Eugen Stan
    @ieugen_gitlab
    personally I use flatpak quite a lot and I find it refreshing for installing packages that are not yet part of distributions or evolve faster than Debian releases (which is what I am using)
    35V LG84
    @35VLG84_gitlab

    Hi, here are some answers and comments to your comments and questions:

    The community of Tackler is next to non-existing, that's true. However Tackler is actually used based on OSS-repository statistics and stats are increasing over time. So there is some traction of it e.g. e257/accounting/tackler#2

    Tackler core itself is actually really small, few thousand lines of code, so with all the tests it should be fairly easy to take over it. Also used Scala code is pretty straightforward. These should provide some insurance against small community.

    It would be ok-ish to have some java code with Tackler, if reason is good and well justified. One example would be in-memory Git repository writer: GitDB On the other hand, Scala is really nice language and it's possible to move from Java to Scala in gentle way (I did that - Tackler isn't very die-hard Scala).

    Separate reporter and/or web-server project based on Tackler would be really cool thing to have. I have a prototype done with Play Framework for server side and scalajs-react + ScalaJS + Tackler Client API on client side. Sprint Boot is also an interesting option. At the moment I think it would make most sense to have the server as separate project, but that is not set in stone. As about languages, I won't accept Node.JS or heavily Javascript based solutions for Tackler, because of untyped nature of the Javascript. Same goes for Python.Python utilities are totally ok, but core functionality of Tackler can't be implemented with Python.

    If you could point worst places where documentation is lacking or provide patches, that would be really awesome.

    Easy requirements for contributions are that everything is signed-off (e.g. every single commit) and it would be really nice if you could also PGP sign commits. Please see CONTRIBUTING, it has some information.

    Then the more difficult and vague stuff about contributing:
    There are some reason why tackler exists in first place and some high level goals in README. At the moment aim of Tackler is to have really narrow focus, but that minimal feature set should be done extremely well and trustworthy.

    Also all features must be tested really well. This is unbreakable rule for Tackler. I won't accept any changes (my own or someone's else) if it degrades seriously test coverage. There might be exceptions if it's truly too difficult to test reasonably, but it should be exceptional situation.

    I also like to see Tackler developed DDD/TDD way, so that all features are defined to some extend first, as are test cases for those features. Please see list of TEPs, e.g.: TEP-1009 and TEP-1010

    Tackler's idea is to be minimal core and cli interface is "reference implementation" of those features of core, but not necessesary full CLI UI. For example, I have several applications where all kind of business domain specific filters are defined in shell script and fed to tackler via --api-filter-def as base64 armored ascii strings. But those filter combinations are not implemented as CLI options for above reason.

    On the other hand, if the idea is cool, then by all mean let's have it in the Tackler (e.g. accounting checksums and geo location).

    My plans for tackler are: It will be maintained and extended as needed. (ATM I have tag support on the pipeline). Tackler's README has some high level ideas for future. I typically work with Tackler during nothern hemisphere winter and not so much during summer. However, this winter has been exception. Tackler probably won't ever have as many options and features as ledger, hledger or beancount. And it won't have ledger-compatible format.

    GraalVM would be really cool. I have had it on my list, but haven't had time to take look of it.
    If you think it would make sense, we could create a separate, more relaxed repo for tackler examples, like jgit Cookbook
    Ioan Eugen Stan
    @ieugen_gitlab
    Hi, I think your points are valid and reasonable. If they are written down so that new people have a reference point it would be great.
    I like processes and some rules to go by - too much freedom is not good - things get side tracked.
    I don't have such strong opinion on JavaScript and node.js . I know they are not perfect but I find they do their job sometimes. Of course I would not use them in core except with some waivers :)
    For example, antlr has a JavaScript target that I would love to use and also expose the ledger format to JS world
    I have some experience with create-react-app
    Ioan Eugen Stan
    @ieugen_gitlab
    I also tend to favor tools with a bigger user base. I started learning Scala a few years back and tooling was missing and for me the language is very expressive but also dense. You can write a lot of stuff in a just a few characters and that is good for writing but bad for reading and understanding. In my experience you write code once and then read it multiple times.
    Anyway, I'm not here to change your mind or anything, just ranting a bit :)
    I think a lot of stuff that is not core can live outside the main repo - it will make testing out new things maybe a bit slower (it's always easier in the same repo but maybe with git subtree or submodule things can seem in the same place),
    Having them separate makes it easier to handle contributions and we can have different policies regarding tests and stuff
    core should be ~ 80%-90%+ covered with tests, in the UI things might not be that easy
    Ioan Eugen Stan
    @ieugen_gitlab
    I would like to take on some of the management/ documentation / community building part once we settle on some goals for the project, something like https://hledger.org/ROADMAP.html#milestones
    I like the hledger project organization / website - I thing it's a good model to have. They managed to cover most of the stuff a good project needs in their website. I also like this chart - It's very useful for getting an overview https://hledger.org/_static/images/data-model.png
    regarding the docs - I would love more examples on how to get things done - and what are the API concepts.
    I was looking for some java docs to find out how to put things together, where is the entry point.
    I ended up loking over the code - core and cli to figure stuff out
    Ioan Eugen Stan
    @ieugen_gitlab
    anyway, once I have some time I will push the sample on my repo and make a PR - so we can start a discussion
    again regarding the repos - in my experience having lots of repositories has the tendency of slowing things down and confusing people - it is a bit of a mental effort for people, including me
    I think a lot of things can be done as we go

    If you think it would make sense, we could create a separate, more relaxed repo for tackler examples, like jgit Cookbook

    I like this one, yes

    Ioan Eugen Stan
    @ieugen_gitlab
    some updates regarding what we discussed:
    • I've been learning more about how hledger works and double accounting in ledger style
    • I'm working on some code to convert a custom / multi line (ugly) transaction report from ING to ledger - going to publish that
    • I have a plan to convince the a client to use tackelr / ledger style accounting so I can spend more time on this
    • I've played around with typescript - to build a CLI (with oclif) and I'm quite pleased how that turned out very good - there is also antlr4 typescript project . Do you think we could compile the scala code to a typescript library as well ?
    Ioan Eugen Stan
    @ieugen_gitlab
    I'm working with a friend on an react app that will allow us to assign transactions exported from the bank to a list of accounts
    that will allow me to import with some manual work bank translations to the ledger format
    35V LG84
    @35VLG84_gitlab

    Do you think we could compile the scala code to a typescript library as well ?

    I honestly don't know from technical point of view. From project's point of view, probably not. Tackler's core has few quite big java depencies which have non-trivial functionalities (e.g. JGit), so those might not translate to Typescript or Javascript so well. It would be also be a substantial amount of work to maintain core in two different implementation language, even when the translation would be done by compiler/plugins (all command line test, unit and integration tests would have to be duplicated for Typescript target).

    I'm working with a friend on an react app that will allow us to assign transactions exported from the bank to a list of accounts

    That sounds really cool. Especially if you have feedback how handy or not git storage backend is for your use case, that would be interesting to hear.

    Ioan Eugen Stan
    @ieugen_gitlab
    thanks, we are going to develop the app client side entierly - you copy paste /download the result locally - no server interaction yet
    it's a set of components for the future
    regarding the dependency on git, from your statement above, it does not seem to me that I can't OPT-OUT of git storage
    I do like the idea but I believe that storage / persistence should be plugable.
    while tackler library should not care where the data comes from, something like tackler-cli and tackler-web-api should care about that
    Ioan Eugen Stan
    @ieugen_gitlab
    hi, some updates: I've started learning clojure and I quite like it. I'm going to try to write some tooling around plaintextaccounting using it
    Eugen Stan
    @ieugen
    This message was deleted
    35V LG84
    @35VLG84_gitlab
    Hi, there is a new Tackler release v0.33.0. Now there could be custom timestamps in reports. It has support for Scala-JS 1.x and Scala 2.12, 2.13, see: https://tackler.e257.fi/news/2020/12/20/tackler-0-33-0/
    This will be probably the last release to support Scala 2.12
    oli
    @olimination
    Hi, Tackler looks very interesting. Do you have any real-life examples where the software is used? Maybe you could add a section on the homepage for some "customer real-life" examples...?
    35V LG84
    @35VLG84_gitlab

    Hi, Thanks, nice to hear that! I don't have any real customer or usage stories to be shared, but based on OSSRH stats, it is used to some extend. I have private systems which are based on Tackler, but I can not share details about those.

    In general, there are several features which makes Tackler really well suited to client-server systems (kind of CQRS setups), imho:

    For example the client can update "account" state by sending transactions as single message (txn-file) to server. This transaction will internally be coherent (guaranteed by accounting equation e.g. sum is zero), and it can be delivered to server either as a file/message or as part of git commit. If it's delivered as file/message, then it can be verified by server string2Txns (https://gitlab.com/e257/accounting/tackler/-/blob/main/core/src/main/scala/fi/e257/tackler/parser/TacklerTxns.scala#L326) before it will be inserted into storage (be it on filesystem or git).

    There is possible to generate proof of used (by server) accounting data to the client, and client (system) can run reports by themselves and verify that server has used correct transactions for the report https://tackler.e257.fi/docs/auditing/ and https://gitlab.com/e257/accounting/tackler/blob/main/contrib/txn-set-checksum.sh

    Lastly Tackler data model is designed and tested to withstand a lot of transactions (not in VISA scale, but in scale of smaller system), it is routinely tested with integration tests with 100_000 txn sets, and performance tested with 1_000_000 tnx sets. One transaction every minute over year is around 500_000 txns. Or 1000 persons, 10 txns per person per day for one month, that's around 300_000 txns. Git itself will have some problems when there are many objects, but there are workarounds for those problems. If you like to play with git as db, check out this demo/proto: (https://gitlab.com/e257/proto/gitdb)

    If you are after personal finances and don't need strong auditing capabilities, then you could be better of with ledger, hledger or beancount. On the other hand, if you have system, which is (semi) autonomously producing transactions, then tackler could be something which is worth of investigation.

    So in summary, there are many features in Tackler which supports Event/Message based accounting. The major question is how well plain text accounting concept fits with your business domain.
    35V LG84
    @35VLG84_gitlab
    One thing more, with ledger / hledger / beancount there is no way to proof what was the state of journal, when reporting was done. With Tackler's transaction checksum, it is possible to attach that information e.g. into printed or externally stored report. It's possible to run different reports, with different parameters and validate easily (by comparing txn checksum) that the same set of transactions is used with all reports. If that feature is needed, then it's really valuable thing to have.
    oli
    @olimination
    Thanks @35VLG84_gitlab for the info. I'm currently thinking of using it for a small/medium enterprise setup. But first I think of using it privately to make some experience with it, checking how it works, etc. I like it because it uses Scala :) and Git as a storage possibility. Are there already any web-gui projects for Tackler? I'm just thinking of having some webapplication with an easy UI for entering transactions and generating/displaying reports for the users. This could for example be achieved by using the "Play framework" or Akka/HTTP for implementing an API and having some separate Frontend app using it. What do you think?
    35V LG84
    @35VLG84_gitlab
    That's interesting. It would be really good idea to explore it and the idea first with tackler, because it doesn't have as much features e.g. hlegder. It is as small as possible by purpose.
    Please check out this PoC: https://gitlab.com/e257/proto/reporter It's PoC of reporter done with play, ScalaJS, ScalaJS-React, etc. it has some basic reporting functionality and gatling test setup for load testing. It isn't much more than exploration framework to test ideas, and it's not even a poc of real reporting server, but it can be used to play around the concepts.
    The Frontend app should definintely be a separate thing, imho. it would be interesting to have Frontend App done with rust + wasm =)
    35V LG84
    @35VLG84_gitlab
    There server is configured to run txns-1E5 (100_000 txns) set, other options with available samples are (1E1, and 1E2). With txns-1E5, when data is pre-read and parsed into memory, reporter responds in ~100ms or under for balance and balance-group reports.
    Last thing: if you decide to play directly with audit-repo.git, e.g. clone it, run following command before you do that: mkdir -p tackler/tests/audit/audit-repo.git/refs/{tags,heads}
    35V LG84
    @35VLG84_gitlab
    Have fun and good luck!
    Yohanes Yuen
    @yohanesyuen
    Is this project still active?
    35V LG84
    @35VLG84_gitlab
    Yes it is and it's in production use. However, typically the most of the changes happen during Northern Hemisphere winter time. And on top of that, if there are no real need for changes, then it won't be updated just for fun. I try to keep it as simple and small as possible.
    35V LG84
    @35VLG84_gitlab
    And the latest release is v0.35.0, details are here: https://tackler.e257.fi/news/2021/03/07/tackler-0-35-0/