Nanogram is designed for the enthusiest who wants complete data sovereignty on their social media platform.
Spin up your own instance on termux for Android.
Demo here.
Install instructions are at the bottom of the readme.
Nanogram is designed for the enthusiest who wants complete data sovereignty on their social media platform.
Spin up your own instance on termux for Android.
Demo here.
Install instructions are at the bottom of the readme.
I’m not saying it’s the correct or proper way to do things; it was just the eaisist way for me to keep track of everything. This entire thing was created on mobile and I found it was quicker to keep things in one copy pastable format.
The work flow was: ponder new features, discuss ways to implement, implement and generate the monolith with the implementation, copy paste into the terminal, test to see if it’s what I wanted, tweak stuff until I’m happy, rinse and repeat. It wasn’t like this was a one liner prompt into a LLM.
not to be rude but as someone who has no coding background I feel like I can read and understand what’s going on in this raw source pretty well at this point after watching each portion generating 100’s of times. Why can’t you read and understand it you are a 20y senior dev?
It is not structured in a way that is easily understandable, or quick to get an overview over.
It’s one big mess of code, all piled together.
Why? Because it’s long and complex? It would be the same exact thing just separated. What’s the difference honestly?
Here is a overview.
It starts with defining environment variables, app directory, file permissions for the directory.
Then it assembles/installs or updates the dependencies.
Then is concatenates the python app. The python app is big because it’s complex with all the game logic of three mini games.
The python app grabs all it’s dependency packages it needs, creates the database, defines all the functions I wanted such as… What’s a like, what does a comment button do, what does a login button do, what’s a Scrabble game, what’s a chess game, what’s a read receipt… All these functions define when and where to interact with the memory of the database.
Then the html templates are concatenated. This is shell of what is served to the client so they can interact with the database.
Next the CSS file is born. This is just a skin to make it all look nice.
Finally, it finishes with the CLI server manager. It provides the operator admin functions. Turn the server on, off, networking on and off, backups, invites to server, uninstall the whole app and more.
There are many ways to bundle, package, release, update, build, develop and publish software.
The one your AI has chosen for you, is definitely not one that I would recommend.
You could take a look at other open source software, and see how those projects are developed and packaged, and maybe find some inspiration.
If you at some point want to contribute to other pieces of software, or have others contribute to yours, it would be beneficial to have a shared understanding on how to properly do stuff.
Thanks, that’s actually the first constructive comment here. I do realize it’s a completely unconventional release format and if I want others to contribute I’ll have to reformat the way the repo is structured. I just hope you at least understand why it is the way it is. That’s was not the LLM’s choice. I specifically asked for the monolithic format because my development environment is a mobile device…it was too complicated to split the program into its expanded file directory and have to update each individual file before testing an iteration and feature I added.
For example; to add a notification dot, I would have needed to touch the python app routing, the html, database classes, css. It was to much to keep track on for a mobile environment. The single file script allowed for a faster feedback loop because I can just swap the script in the terminal and it will overwrite and the existing directory in a snap.
Then maybe what you have made is a mobile IDE (integrated development environment), where that is how you might be able to do development on a small-screen device. But the actual code should probably be split up. That way the git diff stuff will also be way easier.