My praatjie by PostgresConfZA

Ek het vandag ’n praatjie aangebied oor PostgreSQL-werkverrigting in die amaGama-projek by Suid-Afrika se Postgres-kongres. Die praatjie het agtergrond gegee oor vertaalgeheuestelsels en ook bespreek hoe die amaGama-projek PostgreSQL se volteksfunksionaliteit gebruik.

Soos mens in die opsomming kan lees, kon ek ’n reuseverbetering aan die databasis se werkverrigting maak. Gebruikers van die weergawe wat ons huisves, baat al reeds vir die afgelope paar weke by die verbeterde werkverrigting.

’n Interessante aspek van hierdie werk is hoe die gedeeltelik oorvleuelende parsiële indekse gekomplementeer word deur die beter fisiese uitleg op die skyf (bereik met die CLUSTER-opdrag). Die werkverrigting is beter in beide die geval van warm of koue kasgeheue.

Ek glo ’n video sal mettertyd beskikbaar gemaak word. Geluk aan die organiseerders vir ’n baie aangename geleentheid!

Fris en vars amaGama

Ek het onlangs weer begin werk om die bediener en diens van die amaGama-vertaalgeheue te verbeter. Die projek verskaf ’n vertaalgeheuestelsel wat deur vertaalprogramme soos Pootle en Virtaal gebruik word. Die webdiens wat die Translate-projek huisves, bevat vertalings van verskeie populêre vry en oopbronsagtewarepakkette. Dit verskaf aan vertalers in meer as ’n honderd tale voorstelle vanuit vorige vertaalwerk in die lokalisering van vry en oopbronsagteware. Verskeie areas van amaGama benodig werk en ek wou mooi prioritiseer sodat ek ’n redelike aantal doelwitte bereik.

Eerstens het die bediener self nie die nodige aandag geniet die afgelope ruk nie. Die diens het glad nie gereageer nie, en ’n klomp bywerkings was nodig. Ek het reeds die bedryfstelsel opgegradeer, maar die stelselkonfigurasie moes ook hersien word. Gebruikers van Virtaal sal bly wees om te hoor dat ek die nodige veranderinge geïmplementeer het sodat die amaGama-inprop in Virtaal weer werk. Op die bediener werk dinge nou ten minste so goed as vantevore, en beter in ’n paar opsigte.

Werkverrigting van die diens was vir baie jare al inkonsekwent. Daar is verskeie redes, insluitend die bedieneropstelling en die kode self. Ek het al verskeie kere versoeke gesien wat meer as tien sekondes neem. ’n Vertaalgeheueantwoord wat só laat kom sal nie sommer nuttig wees nie. Teen daardie tyd het ek waarskynlik al die hele segment van nuuts af vertaal en aanbeweeg. Ek glo meeste gebruikers wil ’n antwoord in minder as ’n sekonde hê. Aangesien netwerkwagtyd op sigself langer as dit kan neem, moet die webdiens self regtig so vinnig as moontlik wees.

Ek hoop om binnekort te skryf oor interessante veranderinge aan die kode vir beter werkverrigting, maar ek het reeds dinge verbeter met eenvoudige veranderinge aan die opstelling. Terwyl sekere databasisnavrae stadig is, help die gelyktydige hantering van ander navrae dat ander gebruikers meestal ongeaffekteerd is, en daardeur word die impak van swak werkverrigting in een versoek beperk. Voorheen het die bediener slegs een versoek op ’n slag hanteer—ek het geen idee hoekom dit so opgestel is nie. Sommige versoeke neem steeds meer as 10 sekondes, maar dit gebeur nie meer so gereeld nie. Die stadige antwoorde verdien ’n skryfstuk of twee op sigself, en ek werk nog hieraan. (Bywerking: Ek het intussen hieroor gepraat by PostgresConfZA.)

Die huidige databasis (die geheue van vertalings) op die bediener is nou al redelik oud. Ek het ook begin werk aan vars data. Dit is amper ’n hele projek op sigself! Baie projekte het hulle weergawebeheerstelsels in die afgelope paar jare geskuif, en in ’n paar gevalle kan ek sommige dinge wat ons vantevore ingesluit het in die databasis nie meer maklik kry nie. As daar spesifieke projekte is wat iemand dink in amaGama ingesluit moet word, kontak my gerus.

Nog ’n doel van al my werk is om te belê in dinge wat toekomstige bydraes vergemaklik. Die bedieneropstelling is eenvoudiger, die opstelling van die webdiens is uit die kode geskuif, ens. Hopelik beteken dit dat ’n klein groep vrywilligers (al is dit so klein as net ekke) hierdie vir nog ’n hele ruk aan die gang kan hou.

Django compression middleware ondersteun nou Zstandard

Ek dink ek het die eerste keer van Zstandard (zstd) gehoor in ’n joernaalinskrywing deur Gregory Szorc. Ek sien toe op ’n stadium dat zstd ook in IANA se content coding registry vir HTTP geregistreer is, en ek probeer toe uit te vind hoeveel van die web-ekosisteem reeds daarvoor ondersteuning het. Soos ek onthou was daar op daardie stadium slegs aanvanklike steun vir zstd in Nginx, en niks anders nie.

Dinge lyk nog nie veel beter nie, maar zstd het steeds verbeter en is deur heelwat projekte opgeneem vir toepassings buite die web. Toe ek onlangs kyk, sien ek een HTTP-kliënt, wget2, wat sê dat dit zstd ondersteun. Ek besluit toe om Django compression middleware uit te brei met ondersteuning vir zstd en dit te toets met wget2. Met wget2 kan ek seker maak dat ten minste een webkliënt die middelware se afvoer kan hanteer.

Ek het ’n paar dae gelede weergawe 0.3.0 van Django compression middleware vrygestel met ondersteuning vir zstd. Aangesien ek nie van enige webblaaiers weet wat dit al ondersteun nie verwag ek nie dat veel mense hieroor opgewonde sal wees nie. Daar is nog nie eens inligting op die Can I use …-webwerf oor zstd nie (github-verslag). Ek sien hierdie egter as my klein bydrae tot die ekosisteem.

Dit is nie duidelik dat Zstandard ’n aansienlike verbetering oor die alternatiewe is in alle gevalle nie, maar my toetswerk op verskeie HTML- en JSON-lêers dui daarop dat dit meestal die selfde of beter as Brotli is, en eintlik altyd beter as gzip (met die verstekwaardes wat ek tans gebruik). “Beter” beteken in hierdie geval ’n kleiner afvoer wat in die selfde of korter tyd gelewer word.

Django compression middleware ondersteun nou zstd, Brotli en gzip.

Verstaan die internet jou taal?

Ek het vanoggend ’n advertensie op die radio gehoor waar ’n seun met sy pa praat oor een of ander besigheid. Hy verwys sy pa na die webadres, en—aangesien die advertensie in Afrikaans is en hy die adres in Engels spel—noem hy “Die internet verstaan nie Afrikaans nie”. Ek probeer te dink hoekom die skrywer van die advertensie gedink het dit sal dinge verbeter om daardie stukkie in die dialoog in te sluit.

Ek moet natuurlik meestal saamstem—die Internet verstaan nie Afrikaans nie, maar dit verstaan ook nie Engels of enige ander taal nie. Miskien het die organisasie bloot sleg gevoel omdat hulle nie ’n Afrikaanse teenwoordigheid op die web het nie, of weet dalk nie hoe maklik dit is om nog ’n domein te registreer as ’n alias vir die hoofwerf nie.

Uit ’n ander hoek gesien, programme wat inligting op die web verwerk kan ongelooflike dinge doen met die inligting op die web—in Engels, Afrikaans en ander tale. Ek ignoreer nie die feit dat tegnologiesteun vir tale nie gelyk is nie, maar domeinname is net karakters—mens kan daar intik net wat mens wil (ek ignoreer natuurlik die kompleksiteite van Internasionale Domeinname).

Ek werk met taaldata vir my brood en botter, dus was dit ’n jammer herinnering aan die algemene persepsies oor taal en tegnologie. Ek hoop luisteraars kon dit bevraagteken, of ten minste begin dink oor hoe dit verander kan word.

My referaat by OLC / DEASA

Ek het gister ’n referaat gelewer by die Open Learning Conference van Distance Education Association of Southern Africa. Die titel van my artikel is “Re-evaluation of multilingual terminology”. Ek het die punt probeer maak dat terminologiehulpbronne as meer as blote verwysingsbronone kan dien. Ek het konkrete voorbeelde gegee van hoe dit ook kan help met konsepsuele modellering.

Ontologie-ingenieurswese is ’n belangrike deel van die veld van natuurliketaalverwerking, maar ek ontmoet steeds gereeld akademici wat dink die hoogste doel waarna ons moet streef is terme met vertalings (moontlik met definisies). My voorlegging was ’n poging om ’n breër visie te gee.