hpr-knowledge-base/hpr_transcripts/hpr4477.txt

Episode: 4477
Title: HPR4477: doodoo 3 a deuce plus 1
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4477/hpr4477.mp3
Transcribed: 2025-10-26 01:04:34

---

This is Hacker, public radio episode 4,477 for Tuesday 30 September 2025.
Today's show is entitled Dudo 3 Aduse Plus 1.
It is hosted by Jezera, and is about 10 minutes long.
It carries a clean flag.
The summary is continuing to blather about Dudo a TV app for getting done done.
Hello, my name is Jezera, and this is episode 3 about Dudo creating a Tudu application.
It is incredibly pleasing that I get to say Dudo is in production.
That is to say, I have installed Dudo on my remote server digital ocean, and I'm using
it all the time.
In a sense, however, it also means that I am testing in production, and there are certain
things I should have tested prior to putting Dudo into production.
And importantly, there would be what is the process of starting from scratch.
At some point, I had introduced a bug server side that was causing an issue if the data
file for the items and categories did not exist.
That file is created by the server side code if it doesn't exist, but part of the code
was looking for data in that file before the file was even created.
It was a very catch-22 situation.
That being said, it was also the only major issue I encountered when deploying the software,
which I think is great.
Before getting to the point of deploying the software to production, I really needed
to figure out and implement the process for authentication.
The process described in Dudo Episode 2 is pretty much exactly what I went for.
On the server level server side, that meant I needed to create a file based on the hash
of a string that is entered by the user somewhere.
And in order to do that, I added to my make file, yes, I'm using a make file for this
application.
I added to that file a command, pass-phrase-hash, so that the user has to enter make pass-phrase-hash,
and that will prompt the user to enter a passphrase, at which point that passphrase
then will be converted into a SDA 256-some hash of that passphrase and stored as a text
file.
Upon starting the server, that text file is read into memory, and that is the stored hash
that any incoming passphrase is checked against.
So the server, whenever there is a request for data, will check the included header for
a passphrase, and hash that passphrase, and if that hashed passphrase that was passed
in matches the hash from memory, then all is good and data is returned.
Actually that isn't quite true.
When the user enters the passphrase to generate a hash server side using this make file,
what is hashed is passphrase with a carriage-return newline appended to it.
I haven't figured out how to not get that to be part of the hash, and so the passphrase
that is passed in from the client as part of the request header, before that gets hashed,
I add a backslash and newline to that string, and then get its hash to check to see if
they match.
Through my usage of the application, I have noticed a few issues, primarily with the user
interface, that could be improved.
When I opened this application on my mobile phone, I decided that it would be best if there
was a shortcut on the desktops.
This is on Android, and I was using Firefox and added to the home screen, and there is
not a favicon for the UI, for the web interface, and that means that there is no very specific,
nice button for this on my home screen.
There's no icon.
It doesn't look good, it's just the letter D, I don't like it.
So I need to make a favicon more than likely that will be done as an FG-F-S-VG using Inkscape,
because Inkscape SVGs, or an SVG in general, makes an excellent favicon, and it is a small
file size, which I really like.
Other issues I encountered.
There needs to be some way to show that something is happening when pressing the Submit button
for creating a new item or new category, and along the same lines when deleting an item
or a category.
This became most prevalent to me on a very slow connection.
I was out, remote, and on a very, very poor LTE connection.
And I noticed, significantly, there was a very long delay between pressing a button and
something happening, and that is because the connection was incredibly slow.
The UI shows nothing at all that tells me the user that, yes, I have pressed a button
and something is happening.
And at that point, I'm very tempted to start pressing the button again, and again, and
again, and again.
And what that will end up doing is sending multiple API requests to the backend, which I don't
want.
So there's something that needs to change.
The API itself, that is the server API, needs better error responses.
For the most part, every response is from the API is code 200, which means everything's
hunky-dory, and maybe some data.
But if there's an error at some places, there will be a response of 200, and then a message
about that error, and that's not necessarily the best thing.
In fact, that's terrible.
If there's a specific type of error, then I should be returning the proper HTTP error
code that represents that error.
Another problem is the tab order of the UI.
And this, I find, or I found, most prevalent while using my desktop, in which case, I didn't
want to have to move the mouse to select the new item button.
I wanted to just press the tab button, and get there as soon as possible.
And the new item and new collection buttons are on the bottom.
Because when I'm holding my mobile device, I want those buttons as close to my thumb as
possible.
That's why I put them at the bottom.
Those buttons, being at the top, would be excellent for desktop, maybe not so much for
mobile.
But having to tab through all of the edit and delete buttons that exist for every category
and item is tedious.
So that can be changed by setting the tab order in the HTML.
I am reminded of the following advice from a woodworking book.
In the habit of modifying designs to make them more appealing to your eye.
Obviously, that doesn't apply to just woodworking.
It also applies to software.
It applies to anything where there is a design.
It is an excellent credo for hackers.
Take what exists and change it to make it better.
The final major UI issue I encountered was when I entered as an item under the category
of shopping, a URL to a product that I needed to purchase.
It was a very, very long URL.
And when that was displayed in the interface, it stretched the entire interface very wide.
And it just made Dudu look like Dudu.
And I was not happy with that.
And there is a CSS property to define when an item breaks that should be able to resolve
that issue.
And that is something I need to code.
And I'm going to go do that right now.
On that note, I have got some code to hack and some music to play.
And episode two, to upload.
Have a great day.
Keep on hacking.
And don't be afraid to modify designs to make them more pleasant to your eye.
You have been listening to Hacker Public Radio at HackerPublicRadio.org.
Today's show was contributed by a HBO listener like yourself, if you ever thought of recording
a podcast, then 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 Sync.net.
On the Sadois status, today's show is released under Creative Commons, Attribution 4.0 International
License.