How to build this with Jam?

[Drazen D. Babic]

Dear all, 

any opinions about building an home budgeting tool like this one:

https://github.com/Eqonomize/Eqonomize

On the picture it looks like supporting multi currencies! It does not need to support all of this features, but interested to read openions.

Thx

[Drazen D. Babic]

The above software is not usig the DB, but flat xml files.

Some food for thought, this one is from here, and here is the database with the structure:

https://github.com/darcys22/godbledger

What's really interesting is this

Whats really interesting is this:

GoDBLedger is an open source accounting system that aims to make the recording of double entry bookkeeping transactions programmable. It provide users with normal features that most finance systems tend to lack such as api endpoints for your scripts and a database backend with a clear schema so you can analyse your financial data using your software of choice. The ultimate goal is for your whole financial process to be automated from data entry to compilation of financials/tax returns.

How it works:

You are a business or individual wanting a system to record your profits and produce financial reports. You dont want to pay a cloud provider and you want to keep your financial data under your own control. You spin up a linux server (or raspberry pi) choose a database (Currently SQLite3 and MySQL are available) and you set up GoDBLedger to run on that server. You now have a place to send your double entry bookkeeping transactions which get saved into your own database!

[Maxwell Morais]

Hi Drazen, how are you doing?

Drazen, looks promising these projects, rebuild they in jam-py, looks an right decision to increase the popularity, and show success cases in Jam-py, for business applications.

Like I mentioned before to you, I work with ERPNext, that's an accounting software.

So, if you have any questions about accounting in general, it will be my personal pleasure to help you.

Also, if you are looking for interesting accounting/finances projects to rebuild in jam-py, here it go my 2 cents.

Money Manager EX: https://www.moneymanagerex.org/ it's a finance management application, it's powerful, have really nice reports, and all the source code, including the database (in SQLite3) are available in github.

GnuCash https://www.gnucash.org/, it's the reference of accounting software for SMB and for linux users. It have decent features but lacks a better user experience.

Django-Ledger (https://github.com/arrobalytics/django-ledger) it's the smallest accounting software I know, but with an nice UI and set of functions that fit's any budget.

HomeBank (http://homebank.free.fr/en/), initially developed as an apple product, but later released as open source, HomeBank is one of the most pleasant finance desktop applications I already have worked.

Chers

--
You received this message because you are subscribed to the Google Groups "Jam.py Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jam-py+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jam-py/bf9117fc-060f-49ac-b3d4-6dd5f9a9d39an%40googlegroups.com.

--

Best Regards.

Maxwell Morais

Python Developer powered by Frappé frameworks <3

+55 11 947248832

[Drazen D. Babic]

Hi Maxwell,

I'm good, thanks, and you?

Cheers for the links, awesome products.  To be fair, people are interested in Jam as replacement for their desktop, mainly Access apps.

However, I think people do not really know how to start developing an Jam app (or any), because they simply do not know the basics. Not the basics of Jam, but the basics of the Web. Like, quite common is to ask how will Users open the folder and fetch the docs from the server, like Access does! Than, very common question I get is how to deploy.

People have no understanding of how integrated MS Office is, and expect that magic will happen by itself when using Jam! That is the mother of all issues. Developed countries on the West are using integrated solutions by MS and they will never seek for an alternative in general. Because they do not need to. Plus, they need continuity and support.

So what is the solution for giving Jam to masses (many people on the West)?

One is to provide an useful and good App for the masses. I'm still searching for what that might be, two and a half years after posting a pool about it. Books keeping is good example, I like it.

D.

[Maxwell Morais]

Hi Drazen, I fully understand what you mean, here in Brazil, we suffer from a similar problem!

Exhell dominance! (Excel is everywhere, doing what apps with database should do)

I fully understand your POV that people lack the basics, due M$ ecosystem, I was one of these guys 15 years ago, coding MS Access apps!

When I came to Python, it was a nightmare (Where is my GUI builder, what? no drag-and-drop? My gosh, what's event binding? Crisis!)

One thing that made me successful with Python was the great support from the community, like what we have in Jam-py!

Also, an existing deep tutorial for Python (with the Books)  Python para Programadores (pt-BR) [Python for Programmers],

and Aprendendo Django no Planeta Terra v2 [Learning Django on Earth v2], that covered all the aspects and capabilities of

how to deal with common use tasks!

I think, there's no easy recipe for the case of Jam-py, the best approach, is build an whole application, but trying to get

all the basics and the advanced questions from the framework.

In this video https://www.youtube.com/watch?v=qkJvGlgoabU&t=1s, Andrew, showed a really nice application built on top of Jam-py.

I still didn't understand how many things there have been built (like the Order Screen), and the messages on the empty screen.

So, if someone can build an app, it doesn't matter what, using all features of Jam-py, and showing how to solve problems,

it would be a huge introductory point for any community member.

Like this guy! https://www.youtube.com/c/ExcelForFreelancers/videos

He develops one Excel application per week and started with the basics of excel, now, in 1-2 hours, he shows how to develop complex applications, because most of the existing problems are resolved into past videos.

This is the same strategy I'm using here in the company to train noobies into Frappe and ErpNext.

--

You received this message because you are subscribed to the Google Groups "Jam.py Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jam-py+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jam-py/6d740553-61bd-407f-be46-5cb8ac58e6e0n%40googlegroups.com.

[Drazen D. Babic]

Hi Maxwell, 

sorry for the late reply.

Do you have a PDF "Aprendendo Django no Planeta Terra v2"? 

The problem imo is that not many users are keen to or do not want to fiddle with installation of Python, dependencies etc.

The "low code" frameworks are not actually enabling low code, unless everything is hosted at the provider.

And this is not the case with Jam. Even if one spends heaps of time on setting the environment (ha, takes 2 weeks for Windows Dev to set it up with Visual Studio, Cloud, etc), when the App is done, than what? Deploy. But where, and how?

I'm not talking about skilled people here, but average Joe's. That is the core of the problem. 

This is why I packaged Demo as EXE to demonstrate what is possible with no spending time for the average Joe. Imagine Joe using EXE on network with a couple of users accessing it, like a bookkeeping software?

Of course, the DB backup/restore must be addressed before something like this is a useful product.

However, some do not agree with this approach. I would love to learn from others too how to help Jam to become mainstream.

Thx

[Maxwell Morais]

Hi Drazen, I kind understand your POV

But keep in mind that an "Average user" never will be able to produce anything in Jam-py, or even in Frappe Framework (the one I most work)

Low-Code, requires the minimal set of skills from any user, know how to code, and that only by knowing requires a chain of things.

No-Code, is also something that tries to avoid the coding requirements, but letting users, with really poor solutions when we are talking about business rules, do all of that, because some coding is required to turn rules into machine readable code.

Regarding the "Deployment" it's an easy thing to address, we can add an auto-deployment option in the Builder of Jam-py, to PythonAnyWhere and/or Heroku.

Also for average users, we can use a `PEX` https://www.youtube.com/watch?v=NmpnGhRwsu0

But still, we addressed deployment, and a proper packaging system, so now, how do we resolve the incapability of the average user of producing code?

--
You received this message because you are subscribed to the Google Groups "Jam.py Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jam-py+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jam-py/45bdbb0f-900e-4a90-9e40-b0edf40f42een%40googlegroups.com.

[Drazen D. Babic]

  Hi Max,

the idea of having MS Access converted to sqlite was for exactly that. And it is possible (not yet), to completely build Jam App from Access. The reason why I did not go with complete solution is that the effort needed to Import tables from sqlite to Jam is minimal, imo. And user would learn a bit.

However, many people tried to covert the Access Front End! And wondered why it did not work. This is saying quite a lot about the users expectation/knowledge, even when it's clearly stated that it won't work.

I think if we enable a semi-complete App generated from Access, there would be no many people interested. The core of the problem is a brand.

ERPNext is a brand backed by Frappe, as I understand. The decision makers will look at the Frappe as a reputable brand. Jam is not that. Jam desperately needs a company and not a sole trader. A sole trader means nothing in todays world, it is not backed up with a liability insurance, etc.

When decision makers decide to use ERP, they look at the maintenance and support. And the continuity. A sole trader does not provide this unfortunately. Like, I have no idea how many people work for Frappe, but my perception is "a lot". It is all about the perception.

Imo Jam does not need to concentrate on an average user (like an erp). Jam to flourish should concentrate on businesses, just like ERP does. And for that it needs a brand and a product. This was communicated years ago. 

Regarding Excel, I was thinking about that too, infact converted Excel to Jam since there were no formulas in it. It might be possible to do the same with Excel (even normalise the table automatically), as with Access. But again, what are we trying to solve? Nothing really. Users will try it, and continue with Excel, like you've said. Because it is there. 

So let's think of what is NOT there, produce it and hope for the best.

Good conversation tho.

D. 

[Drazen D. Babic]

Just installed django-ledger

Good stuff Max! Looks great as an reference point for building a similar App with Jam. Of course, all steps, as you call a chain of the things, should be documented or just building the App makes no sense.

D.

[Drazen D. Babic]

Hey 

already did "half" of it :)

So guys, this project is missing the core Jam feature, this is the DELETED field. I will explain soon how to fix this since related to below issue:

https://groups.google.com/g/jam-py/c/UYCNb9y5IYo

[Drazen D. Babic]

Hello all, 

the above project is using TEXT as Primary Key for everything. This can be seen on above screenshot for xxx_id fields.

This is not directly portable to Jam, I'm afraid. However, it might be modified for it.

Anyone knows how to do this? Here is the DB. I'm guessing for all uuids, the ID should be created with PK auto increment, and than all lookups should be recreated.

BTW, Jam happily selected TEXT as a Primary Key (as seen in DB), but does not know what to do with it. Plus, do we see the "progress" field above? Looks strange as a field, marked as read-only! It's a bug.

We can see this here:

https://conv.jampyapplicationbuilder.com/django_ledger/

D.

[Drazen D. Babic]

So guys, 

is anyone interested in this? Basically, the idea is to build Jam App on Django App basis. Up to now, no coding at all, just a few adding fields and sql.

On above link, you can see how the App looks. What Jam is missing is the support for UUID (google Django uuid).

Because how PK is constructed in Django, any changes now on Jam App will fail due to that Jam expects auto increment ID as PK. And this are not auto increment ID's at all, but UNIQUE strings. Called uuid.

One solution is to create a DB TRIGGER to create an UUID. For example:

-- Describe AUTOGENERATEGUID_VENDOR

CREATE TRIGGER AutoGenerateGUID_VENDOR

AFTER INSERT ON django_ledger_vendormodel

FOR EACH ROW

WHEN (NEW.uuid IS NULL)

BEGIN

   UPDATE django_ledger_vendormodel SET uuid = (select lower(hex( randomblob(4)) || hex( randomblob(2))

             ||  '4' || substr( hex( randomblob(2)), 2) ||  substr('AB89', 1 + (abs(random()) % 4) , 1)  ||

             substr(hex(randomblob(2)), 2) || hex(randomblob(6))) ) WHERE rowid = NEW.rowid;

END

Because all UUIDs in Django App are 32 chars long, we create random UUID with the trigger for Vendor Table. Once created, this is now PK that can be used everywhere as FK. Django does this on any new record created. So no trigger.

However, this is now only valid for Sqlite3. It gets worse, ALL tables should contain a similar trigger. And once DB is moved to some other DB (non sqlite3), this triggers are not moved and need to be recreated. This is also true for indexes, etc. So not portable.

The good news is once DB is moved, ALL UUIDs are guarantied to stay the same! The App will instantly work since there is no dependency on auto increment, which is different for many DB vendors.

UUID is the future, I think. Because with auto increment ID, the DB can grow only up to an integer size. For really big databases, the ID must be BIGINT, but even that might not be enough. Plus, with auto increment, there is a problem with fragmented indexes (think deleted stuff which fragments the index).

Jam at this stage does not have UUID. But Andrew might advice on creating UUID as Server Task on newly created record. That would remove the need to create triggers, and App would be portable.

It would be very simple to integrate Jam with Django Apps if uuid is supported. 

UUID might as well completely solve Application Import issues. Because UUID is unique every time, all the times, it would be possible to "merge" projects easily, and Jam might become modular (think developing modules for an App). At lest in theory.

More reading about uuid (not relevant to Django at all): 

https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-careful-7b2aa3dcb439

Up to Andrew to advice on the above Server Task....

D.