[GoLUG] DRY in my 444domains.com system

[Steve Litt]

Ron / BCLUG said on Thu, 12 Dec 2024 13:27:10 -0800

>Steve Litt wrote on 2024-12-11 22:50:

[snip]

>> My 444domains.com website...  
>
>... eschews DRY by repeating domain info once for every sortation
>option.

You're right. Thank you. On my bike ride yesterday, based on the
preceding suggestion, I got the idea of having a YAML data file with
key being domain name and children being price, URL and comment. Python
with a YAML parser can put this straight into a Python array of hashes.
Although a YAML parser isn't yet in the Python Standard Library (shame
on you Python), Void Linux generously gives me a YAML parser for Python.
From there it's trivial to create index arrays for domain name and for
price. Thank you!

>> Yet I still need the price in the conversion script in order to sort
>> by price.  
>
>The sortation should be *within* the page, which fixes the DRY problem.

I don't understand the preceding sentence. If you mean sorting in real
time when clicking a column header, I doubt this can be done without
Javascript, which I don't want to use. I specifically want
444domains.com to be static HTML created on my computer by a script on
my computer and sftp'ed up to my server.

>
>
>
>> Of course, the easy way would have been to make a fourth column with 
>> an (optional) URL.  
>
>Or a fourth column with a boolean flag indicating the already-existing 
>domain name should be a hyperlink to itself (normalization!).

I think testing for the URL starting with "http" is sufficient.

>
>> But then there would have been a price in the 
>> Moretime.Com website and in the 444domains.com data file, and they 
>> would have needed to be kept in sync  
>
>Both the build tools *and* the moretime.com should be pulling the price
>from a central, canonical store.

Yes! Both you, Kyle and now I agree.

>
>Then a price change requires zero rebuild and redeploy, just an update
>to a field in a DB or file.

Because I specifically want all these files to be static HTML, they'll
require running the script, and sftp'ing 444domains.com's index.html
and Kyle's CSS file to 444domain.com's html directory. This is
something I can rely on myself to do.

>
>
>
>> I need each domain's price in exactly one place, either in the
>> 444domains.Com data file or in the Moretime.Com website  
>
>Those are not the only options, just bad ones.
>
>How about storing them like this JSON? (complementary `curl` added):
>
>curl http://bclug.ca:3010/golug/list/

I prefer YAML because it's more human friendly, and they taught me in
programming school not to force the user to do stuff the computer could
do.

But you bring up an interesting point: Your Json is an array of
nameless dicts, whereas the YAML I had envisioned was a dict of dicts,
with the outer dict using URLs as its names. With a tiny program like
this, performance/efficiency is absolutely not an issue, so I need to
decide, within YAML, whether to do it as an array of dicts or a dict of
dicts. I think your way would be a little easier to program and would
better facilitate future additions of fields.

>> Having it in the data file would have necessitated my remembering to
>> run Moretime.Com's index.html through the script every time I changed
>> the price, and I didn't like it.  
>
>Yeah, that is far from optimal.

After talking to you and Kyle, the putting the one and only copy of
price in Moretime.Com or Jobsecurity.Com is now a non-starter.

>> So what I plan to do is have the possibility of a URL instead of a 
>> price in the URL field.  
>
>Wait, URLs go in URL fields, prices go in price fields. Very basic DB 
>stuff here.

Yes. Also, I need to change the column name from URL to Domain, because
in the future it's possible that I might need to add a URL column to
facilitate a web address that can't be calculated algorithmically from
the domain name.


>Generally also a consideration for semantic web sites (navigation in
>nav tags, not div tags, etc.).

I don't understand your preceding sentence.


>
>
>> Then my 444domains builder script will look 
>> inside Moretime.Com's index.html file for the price, and use it to 
>> sort.  
>
>Please, no.

Kyle talked me out of that.

>> Which isn't so simple  
>
>I believe that is an "understatement".

I could program it easy enough, but having to upload Moretime.Com or
Jobsecurity.Com every time I change prices is an error prone hassle. 

>> So I need the price in exactly one place in 
>> index.html  
>
>In one place, yes.

Yes!

>
>That one place being index.html? Hell no!

Hell no!

>> and stated in a way that it can easily be parsed out.  
>
>Parse prices *into* HTML, not *out from* HTML.

X-actly!


>Each index.html could <script src=...> which points to the JSON file 
>like above, with a slight modification to the JSON to "export myList = 
>...", then each site can easily use its location info to parse from
>the array of objects its price (and description), then insert it
>anywhere in the page.

I don't understand the preceding. Could you please elaborate?

>> So the one and only place the price is quantified is in the line:
>> 
>> span.bux::before{content: "$54,321.00";}  
>
>Oh. My. Gawd.
>
>As far back as the early 2000s, maybe even the late 90s, it was common 
>to complain about people using spreadsheets as databases.
>
>In 2024 someone's going to use *CSS* inside HTML files?!?

I see no problem with it, but if you see a better way that can be done
with static HTML, I'm all ears.

>
>
>
>
>> Once the preceding CSS line is stated, anywhere I want to put the 
>> price can be displayed simply by the following HTML tag sequence:
>> 
>> <span class="bux"></span>
>> 
>> And as far as the 444domains.com builder script, all it needs to do 
>> is look in the Moretime.Com (or whatever domain I'm selling with a 
>> website) index.html for "span.bux::before{content:", and then
>> capture the string that follows. In the 444domains.com builder script
>> I can strip out the dollar sign and commas and turn it into a number
>> for sorting.
>> 
>> Kinda slick, huh?  
>
>No!
>
>It's all a horrific Gordian knot of kludges.

Here's my definition of "Kludge", written (I think) before I even knew
you:

https://troubleshooters.com/linux/init/manjaro_experiments.htm#the_four_definitions_of_kludge

>
>It breaks rules of databases, web pages, the Geneva Convention, UN
>UDHR, all Articles of the US Constitution, and worst of all, still
>leaves 444domains.com with the Don't Repeat Yourself problem.
>
>
>It's like a database where each person's name is stored in its own 
>table, but somehow even worse.
>
>
>
>> PS: I don't use Javascript except where it's needed  
>
>This is exactly what it's designed for, and superior to a hack of some 
>combo of curl, sed, awk, bash, and / or whatever.
>
>
>It seems like an ideological dislike of JS that makes this whole
>project ridiculously more complicated.
>
>
>JS would let you keep a central store of all data - maybe even in a 
>proper DB like PostgreSQL if you want, or at least a JSON file (see my 
>link above).

I think my dislike of Javascript, *in situations where static HTML
suffices*, is a lot more than ideological. It's practical. Some folks
turn off Javascript on  their browsers.

What I find ideological is your dislike for the (kludge, by all means)
of using ::before(content: $54,321.00;) . It's harmless, nobody turns
off their CSS, and almost all widely used browsers can interpret CSS
well and are up to date enough to render ::before .


>Something like this is how it could be done:
>
> > https://ronaldbarnes.ca/react/444domains.com/  

1. Your page is much better looking than mine. When I have time, I
   might tailor 444domains.com to look like yours.

2. There is no universe in which a shopping cart would be part of the
   domain buying/selling process. The process requires a lot of back
   and forth, coming to an agreement on price, escrow and other things,
   so a shopping cart isn't necessary and would be a detriment in this
   particular use case. The way I know this is I've sold several
   domains, and so has my wife. The haggle and back and forth is like
   buying a used car: Each car is different and there's no reliable
   market price.

3. Clicking headers to sort is very nice, but for my purposes not nice
   enough to bring in Javascript. I reserve Javascript for things
   requiring calculations or intelligent realtime responses to user
   input.


>
>Normalized, centrally stored, non-repeated data, sortable, searchable, 
>sends a formatted email of the items in the shopping cart with a sum
>of the prices,...
>
>One could add URL links to the domain names (keeping the prices in the 
>price column) with the simple addition of one boolean field to the 
>central store (JSON in this case), and a couple simple lines of code.

I don't understand the preceding paragraph.

>This all feels like a prank of some kind.

No, that's systemd :-)

(Litt ducks and runs)


SteveT

Steve Litt 

http://444domains.com