@laacz tvītu arhīvs

Lielākais piedzīvojums būs http://nekur.lv atdzīvināt uz PHP 8.1. Tas knapi uz 7.4 dzīvo. Pēdējās izmaiņas 2017. gadā. Tur vēl PEAR:DB, veca HTMLPurifier versija (ar __autoload), viss spagetti.. Viss slikti, īsāk sakot. Varētu pārtaisīt pavisam, bet nav vīzijas - uz ko.

@laacz Ir jēga to turēt dzīvu?

@laacz Biju uztaisījis https://zinas.news, kur ievācu portālu RSS fīdus un atspoguļoju tos tā, lai pārskatāmi varētu iegūt informāciju par aktuālo, bet @Valsts_policija par to uzsāka resorisko pārbaudi, jo @TVNET_zinas nepatika. Kamēr @guardian ir atvērtais ziņu API, mums ir šādi.

@EdgKu Nav iemesla neturēt.

@laacz Tu teici, ka tev nepatīk spageti :)

@EdgKu Tas jau tā kā neskaitās.

@laacz Uz flask ar rest api :D

@laacz Bet ja nopietni, tad nesen nospļāvos un pārnesu blogu uz statisko ģenerātoru http://www.aigarius.com/blog/2021/06/30/keeping-it-as-simple-as-possible/ - ievadā mape ar rakstiem (saimportēts no vecā bloga RSS), izvadā visi vajadzīgie HTML un JS. Komentāri ārējā servisā, kā Disqus. Ģenerācija notiek no github commit hook vai crona

@aigarius Izskatīju tādu variantu. Bet ārējais komentāru serviss neuzrunāja. Self hosted analogi nedeva nekādus ieguvumus pret paša rakstītu dzinēju.

@aigarius Pirms pāris mēnešiem pieļāvu kļūdu, viena projekta ietvaros izvēloties tornado, nevis flask. Nācās pārrakstīt. Baiss barebones tas tornado :)

@EdgKu @laacz Es reizēm atveru, domāju, ka neesmu tāds viens.

@laacz @aigarius Man arī vienu brīdi blogs bija statisks, bet komentāri ir problēma. Disqus ir mēsls, liek reklāmas iekšā

@normis @aigarius Jep.

@normis @laacz Ja tiešām vajag komentus, tad ir vērts papētīt Nikola pluginu sarakstu. Tagad ir daudz komentu servisu sistēmu. Un ir arī static comment plugins - vajag tikai vienkāršu formu, kas saņem komentāra postu, izveido failu un triggero rebuild.

@aigarius @normis Moderācija arī ir?

@laacz @normis To jau var pievīlēt, piemēram rakstīt komentāru failus pagaidu mapē un tie parādās saitā tikai tad, ja tu tos pāmet galvenajā komentu mapē (un iekommito tā triggerojot rebuild)

@laacz @normis Pārnest saturu no datubāzes uz struktūru git repozitorijā ir baigi interesanta štelle ļoti daudzos pielietojumos. Tā var to iemēģināt.

@laacz Nevar atstāt kā ir - iekapsulēt kādā konteinerī vai virtuālajā mašīnā un uz āru barot caur Apache proxy vai tamlīdzīgi?

@Rauhvargers @laacz Nu es arī reizēm atveru, ikreiz nobrīnos, ka vēl dzīvs. Bet reāli jau nekā prātīga lielākoties tajos blogos nav.

@ArnisRG Enkapsulēšana konteinerī nozīmētu mūžīgu palikšanu tanī stāvoklī. Patlaban vismaz ir ilūzija, ka kādreiz kaut ko iesākšu ar to visu :D

@aigarius @normis Nedaudz par daudz upkeep parastam blogam...

@EdgKu @Rauhvargers OK. Bija vienkāršāk nekā šķita, ka būs. Pāris šimi, nedaudz vienkāršošanas un darīts. 20min darbiņš. Acis darba nobijās, rokas darba nebijās, kā saka :)

@laacz @normis Mazāk par datubāzi, kurai visu laiku jārukā un php kam jāatbild uz pieprasījumu

@aigarius @normis Ne gluži. Datubāze var būt parasts sqlite fails, php neko daudz neēd.

@laacz @normis Ja padomā cik daudz dažādu detaļu un koda tiek darbināts katru reizi, kad ienāk pieprasījums. Ilgtermiņā katrs tas gabals jāatjauno un var prasīt izmaiņas. SQL arī jābackapo. Statikā git source faili *ir* backups undarbojas tikai nginx un kommentu forma, kas raksta Markup failā

@aigarius @normis Par šo var padiskutēt. Vai buildot tikai to, ko pieprasa, ir efektīvāk kā rebuildot visu, pamainot, piemēram, markupu. Un sqlite backups ir faila kopija.

@laacz @normis Mani ir satraumējuši korruptēti SQL faili. Tagad backup tikai formātos, ko es varu izlasīt un parediģēt. Ja tev viss saits reģenerējas no nulles ~3 sekundēs, vai ir vērts kaut ko darbināt katram pieprasījumam?

@laacz @normis SQL konceptuāli ir ļoti lēna lieta - tu nosūti strukturētu pieprasījumu, datubāze to apstrādā, lasa indeksus vai datu laukus no faila, pārformatē datus, atgriež tos tev, tu tos atkal pārformatē un tikai tad vari turpināt renderēt rezultātu.

@aigarius @normis Tad ti nedara. Pirms SPP meklēju variantus ar statistiem vai pa pusei statistiem ģeneratoriem. Es uz savu blogu neatradu riku, kurš to izdarītu ātrāk par 2min. Daudz postu, vēl vairāk komentāru.

@aigarius @normis Nepārspīlēsim, lūdzu. Sqlite overhead ir smieklīgi niecīgs, salīdzinot ar visu pārējo weblapas dzīves ciklā.

@laacz @normis Nav runa par overhead, ir runa par to, ka notiek request-response vispār. Latency. Savukārt sporta pēc taisīju mobīlo sarunu rēķinu ģenerātoru līdzīgu kā LMT darbojas. Ar SQL viņiem ~3M€ datori dienas laikā grieza mēneša rēķinus. Man laptops 15 min. Sequential processing.

@laacz @normis Kā kurš ģenerātors. Daži strādā tā, ka uz ne-NVME SSD viņu ātrumam ierobežojošais faktors ir cietā diska sekvenciālais lasīšanas/rakstīšanas ātrums. Ja postu/komentu kontents nav gigabaitos, tad jābūt daudz ātrāk par minūtēm. Bet source arī nedrīkst būt datubāze ;)

@aigarius @normis Vai tu domā ikmēneša rēķinu rindu ģenerēšanu, nevis PDFu?

@aigarius @normis Tad es tos dažus neatradu, jo izmēģināju populāros.

@laacz @normis Rēķinu rindu un summu katram no pāris miljoniem lietotāju. Miljons PDFu ģenerācija no tā jau būtu tikai cietā diska ātruma jautājums.

@aigarius @normis Tad sanāk, ka Tev ir bijusi piekļuve LMT tarifikācijas datiem?

@laacz @normis Hugo piemēram dižojas ar "<0.1 ms per post" ātrumu. https://yasoob.me/posts/running_staticman_on_static_hugo_blog_with_nested_comments/ ir piemērs kā cilvēks to dabūja ar komentiem strādāt, ar moderāciju. Viss statiski un controlēts gitā. Man tas tik svarīgi nav tāpēc lietoju vienkāršu Nikola.

@laacz @normis Īstajiem nē. Bet cilvēkiem, kas to taisīja, bija arī jāuztaisa ģenerātors, kas spļāva ātrā ļoti līdzīgu datu straumi tam, kas reālitātē notiek tīklā ikdienā.

@aigarius @normis Kā reizi Hugo bija visilgākais no visiem, kad testēju.

@aigarius @normis Raw tīkla notikumi ir pavisam tālu no tarificētiem notikumiem, kuri jau ir agregēti, kuriem jau ir piemēroti visi iespējamie modifikatori, utt.

@aigarius @normis Aizmirsu pierakstīt, ka pat ratificēti tikla notikumi vēl aizvien ir tāli no gala rēķiniem.

@laacz @normis Juridisku vai organizātorisku iemeslu radītas komplikācijas ir viena lieta. Bet tīrā datu apstrādē izlaist raw tīkla notikumu straumi caur nelielu moduli, kas RAMā saskaita visu vajadzīgo var būt daudz ātrak kā ieimportēt to visu Orāklā un tad taisīt super kompleksus kverijus.

@aigarius @normis Ļoti vispārināts apgalvojums. Vienkāršos gadījumos tas ir patiess, bet ne šajā. Piekritu, ka ir daudz kas reinženierējams, bet Tu pašlaik trivializē uzdevumu, kurš ir daudz sarežģītāks.