Episode: 4445
Title: HPR4445: doodoo one
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4445/hpr4445.mp3
Transcribed: 2025-10-26 00:45:55

---

This is Hacker Public Radio Episode 4445, for Friday 15th of August 2025.
Today's show is entitled Due to One.
It is hosted by Jezre and is about 10 minutes long.
It carries a clean flag.
The summary is Episode 1 of a miniseries about creating it to do app.
Hello, my name is Jezre and this is Episode 1 in a mini-series on software development
where I am making an application called Due to a to-do list to help me get the Dung Dung
that I need done or something along those lines.
In Episode 0, I laid out the basic premise of why I needed to write this software and
a few aspects of how I was going to create it as well as my goals in recording the audio
for HPR and, of course, things never go the way I want them to go but they went the way
they went and I am here now to talk about how they went when they were going.
As soon as I stopped recording Episode 0, I started hacking on some code and got to the
point that evening where I was ready to make a git commit and it wasn't anything spectacular.
I had created an API that allowed me to create a collection and create a item and an item
is something that needs to be done.
A collection is a way to group all of the items.
Originally, I had called them categories.
I did not like categories because the plural of categories ends with IES and it's not
something that one can pluralize by just adding an S to the end and I really didn't
like that.
The reason being, I found myself doing a lot of copy paste and then slight modify, modification
of methods and functions so I would have the function to create a new item.
I would copy that function, find all instances of item and replace it with category and
anything where it was items would get replaced with categories but it would not be correctly
plural.
So that is why I changed category to collection because collection, collections, you just
add the S on the end, oh man, so much easier, wow English, what a pain in the, took us.
The next morning with Dudu still on my mind, I woke up, had some coffee and then I started
refactoring and modifying the code and again, I found myself copying and pasting methods
and functions for the editing of an item and changing it so that instead of just adding
an item, I copy the paste code and then modify that new code so that it's not items but
it's collections and that started to bother me because I was having this duplication of
code with just very minor changes to it and at that point I decided that as a refactor
I should make a single method to handle the creation of an item or category, single method
to edit a item or a category, sorry, not categories, collections, wow, really confusing, I should
have just used the word groups anyhow, I use an if statement and I pass in a data type
is the data type and item, then handle this one line difference because that's all it
really was just one line of difference and that really reduced the amount of code that
I was writing, it made it a lot easier to find bugs and fix them in the code because there
was only one method to check, so if I changed in the previous iteration where there was
a separate method for editing a collection and a separate method for editing an item,
if I made a mistake in one and copied and pasted that mistake into the other function, then
I had to go fix that mistake twice, so by refactoring I managed to put all of my mistakes
in one place, basically putting all of my eggs in one basket, there's only one place
to look for where the bug could be and that made the process quite a bit easier.
The way the code currently works, there is an API endpoint for the CRU of CRUD, create,
read, update, destroy, I have not yet made the API endpoints for deleting or destroying
an item from the list once I have completed the task and in the application I can say yes
it's done, I haven't gotten that far yet, but I can create, I can read, and I can update,
and what the API does, there's a class I made called a data manager, this would be sort
of the data abstraction layer if you will, I am not using any sort of database, I'm not
using my SQL, PostgreSQL, or even SQL Lite for this, I am storing the data in a flat file,
the data is represented in the software as a dictionary, I'm using Python, so it's a
Python dictionary, and there is a list of collections, and there is a list of items, and
that's it, it's just, and that is stored in a JSON file, and every time a new item is added
or edited, and same with a collection, once that's added or edited, then the data file itself
is updated, and that means I am storing that entire amount of data in memory in this application,
is that terrible? No, not really, it's not going to be a lot of things, maybe it won't scale well,
perhaps at one point I will have a thousand items to do, wow, that would be absolutely terrible,
shame on me for not getting that done, done. Anyway, that is currently where the application stands,
what is next to do, the destroy part of crud in the API, and after that, really it's move on
to the user interface. Because there is currently no interface for me to interact with the API,
I have been using an add-on to Firefox called RESTID, R-E-S-T-E-D, that sends commands I can
open the interface of the RESTID add-on, and say, oh, I'm going to make a JSON payload and send
it to this API end point, and I will see right away whether or not I get a response of 200,
and that response will also include the full JSON representation of what the data is like
for the application. Basically, everything in the stored JSON file gets returned,
any time an item is updated or added or a category is updated or added, sorry, a collection,
not a category. Again, I should have just called them groups. Perhaps I will refactor everything
after this recording has ended to change collections to groups, because if I don't keep it simple,
then it is going to be difficult for me to explain what I am doing, and I'd like to keep
things simple and easy to explain because I find that is the best way to share things,
keeping them simple, keeping it small. Because the UI for DoDo is written in HTML JavaScript and CSS,
or I should say, because the interface is expected to be deployed into a web browser,
it has to be HTML JavaScript and CSS. It is going to be necessary for me to start writing JavaScript,
so this project, although it is primarily Python, also includes JavaScript, and I am going to be
using JavaScript to read the JSON data file and create tabs. I think I'm going to use tabs
for the collections, and then within each collection, there will be a list of items,
and all of that will be generated dynamically using JavaScript based on the content
of the data.json file that represents all of the collections and items in the ToDo list.
Well, that's all for now. I've got some sheep to attend to, some noise to make, and some code
to hack. Have yourself an excellent day, and I will see you in the next episode.
You have been listening to Hacker Public Radio, as Hacker Public Radio does work. Today's show was
contributed by a HBR listener like yourself. If you ever thought of recording podcasts,
you click on our contribute link to find out how easy it really is. Hosting for HBR has been
kindly provided by an honesthost.com, the internet archive, and our syncs.net. On the Sadois
stages, today's show is released under Creative Commons, Attribution, 4.0 International License.