Märk. tõlge.: See artikkel, mis sai Mediumis menuks, on ülevaade 2010-2019 aasta olulistest muudatustest programmeerimiskeelte maailmas ja sellega seotud tehnoloogiate ökosüsteemis (eriti tähelepanu pööratakse Dockerile ja Kubernetes'ile). Selle originaalautor on Cindy Sridharan, kes spetsialiseerub arendustööriistadele ja hajutatud süsteemidele — eriti on ta kirjutanud raamatu "Distributed Systems Observability" — ning on veebis IT-ekspertide seas suhteliselt populaarne, eriti nende seas, kes huvituvad cloud native teemadest.
2019. aasta on lõppenud, seega sooviksin jagada mõtteid mõnedest kõige olulisematest tehnoloogilistest saavutustest ja uuendustest möödunud kümnendis. Samuti püüan natuke pilku heita tulevikku ning tuua välja peamised probleemid ja võimalused lähenevaks kümnendiks.
Tahan kohe selg rootsustada, et selles artiklis ei käsitle ma muutusi valdkondades nagu andmete teadus, (data science), tehisintellekt, frontend engineering jne, kuna mul puudub isiklikult nende osas piisav kogemus.
Tüüpimine teeb vastulöögi
Üheks positiivseks trendiks 2010. aastatel oli staatiliselt tüübistatud keelte taassünd. Tõsi, sellised keeled ei ole kuskile kadunud (C++ ja Java on täna nõutud; nad domineerisid ka kümme aastat tagasi), kuid dünaamiliselt tüübistatud keeled (dünaamilised) on pärast Ruby on Railsi liikumise algust 2005. aastal märkimisväärselt populaarsust kogunud. See kasv jõudis haripunkti 2009. aastal, kui Node.js-i avatud lähtekood sai reaalsuseks, muutes Javascripti serveritehnoloogiasse integreerituks.
Aja jooksul on dünaamilised keeled kaotanud osa oma atraktiivsusest serveri tarkvara loomisel. Go keel, mis sai populaarsust konteinerite revolutsiooniga, tundus paremini kohandatuna suure jõudlusega, ressursitõhusate serverite loomiseks, millel on paralleelne teabe töötlemine (millega Node.js-i looja ise).
Rust, mis tutvustati 2010. aastal, sisaldas saavutusi püüdes saada turvaliseks ja tüpiseeritud keeleks. Esimese kümnendi poole ettevõtte suhtumine Rusti oli üsna külm, kuid teise poole jooksul kasvas selle populaarsus märkimisväärselt. Tuntud näidete seas Rusti kasutamisest võib välja tuua selle rakenduse , (rääkisime sellest — kt. tõlge), varajases WebAssembly kompilaatoris Fastly poolt (mis on nüüd bytecodealliance'i osa) jne. Olukordades, kus Microsoft kaalub võimalust kirjutada mõned Windowsi OS osad Rustis ümber, võib julgelt öelda, et 2020-ndatel ootab seda keelt helge tulevik.
I isegi dünaamilised keeled on saanud uusi võimalusi nagu (optional types). Esmakordselt rakendati neid TypeScriptis – keeles, mis võimaldab luua tüpiseeritud koodi ja kompileerida selle JavaScriptiks. PHP, Ruby ja Python on saanud oma valikuliste tüpiseerimise süsteemid (, ), mida kasutatakse edukalt .
SQL-i naasmine NoSQL-i
NoSQL – veel üks tehnoloogia, mis kümnendi alguses oli palju populaarsem kui lõpus. Arvan, et sellel on kaks põhjust.
Esiteks on NoSQL mudel, millel puuduvad skeemid, tehingud ja nõrgemad kooskõlastamise garantii, keerulisem rakendada kui SQL mudel. pealkirjaga „Miks tuleks igal võimalikul juhul eelistada tugevat kooskõlastamist“ (Why you should pick strong consistency, whenever possible) Google kirjutab:
Üks asju, millele me Google’is tähelepanu pöörasime, on see, et rakenduste kood on lihtsam ja arendusaeg lühem, kui insenerid saavad toetuda olemasolevatele salvestustele keeruliste tehingute töötlemisel ja andmete järjekorra säilitamisel. Tsitaat originaaldokumendist Spanneri kohta: „usume, et on parem, kui programmeerijad tegelevad rakenduse jõudlusprobleemidega, mis tulenevad tehingute ületäitmisest kitsaskohtade ilmnemisel, kui et nad peaksid pidevalt meeles pidama tehingute puudumist.“
Teine põhjus on seotud „skaalautuvate“ jaotatud SQL andmebaaside (nt ja ) kasvu avalikus pilves ja avatud lähtekoodiga alternatiivide nagu CockroachDB (mille kohta me samuti — tõlke märk.), mis lahendavad paljusid tehnilisi probleeme, mille tõttu traditsioonilised SQL-andmebaasid ei "skaaleerinud". Isegi MongoDB, mis kunagi oli NoSQL liikumise kehastus, on nüüd jaotatud tehingud.
Situatsioonides, kus on vajalik lugemise ja kirjutamise operatsioonide aatomilisus mitmes dokumendis (ühes või mitmes kollektsioonis), toetab MongoDB mitme dokumendi tehinguid. Jaotatud tehingute korral saab tehinguid kasutada paljude operatsioonide, kollektsioonide, andmebaaside, dokumentide ja shardide jaoks.
Kogumine
Apache Kafka on kahtlemata üks tähtsamaid leiutisi viimase kümnendi jooksul. Selle allikakood avati 2011. aasta jaanuaris ning nende aastate jooksul on Kafka tõeliselt revolutsiooniliselt muutnud andmete töötlemise viise. Kafka on olnud kasutusel kõigis ettevõtetes, kus olen töötanud, alates idufirmadest kuni suurkorporatsioonideni. Selle pakutavad tagatised ja kasutusvõimalused (pub-sub, voog, sündmustele orienteeritud arhitektuurid) on laialdaselt rakendatavad erinevates ülesannetes: andmete salvestamise korraldamisest kuni jälgimise ja vooganalüüsini, mis on nõutud mitmes valdkonnas, nagu finantsid, tervishoid, riigisektor, jaekaupandus jne.
Jätkuv integreerimine (ja vähemal määral jätkuv juurutamine)
Jätkuv integreerimine (Continuous Integration) ei ole viimase 10 aasta jooksul välja kujunenud, kuid just möödunud kümnendi jooksul on see levinud sellises ulatuses, et see on saanud osa standardsest tööprotsessist (testide käitamine kõigi pull request’ide puhul). GitHubi kujunemine koodivälja arendamise ja salvestamise platvormiks ning mis veelgi olulisem, töökäikude arendamine selle alusel tähendab, et testide läbiviimine enne pull request'i tegemist põhiharudesse on ainus töötasu arenduses, mida tunnevad insenerid, kes on oma karjääri alustanud viimase kümne aasta jooksul.
Jätkuv juurutamine (Continuous Deployment; iga pühendumise juurutamine sellisena ja sel hetkel, kui see jõuab põhiharusse) pole nii laialt levinud kui pidev integreerimine. Siiski, tänu paljudele erinevatele pilve-API-dele juurutamiseks, platvormide, nagu Kubernetes (mis pakub standardiseeritud API-d juurutamiseks) tõusvale populaarsusele ning mitme platvormi ja mitme pilve tööriistade, nagu Spinnaker (mis on üles ehitatud eelpool mainitud standardiseeritud API-dele), arendamisele on juurutamisprotsessid muutunud automaatsemateks, organiseeritumateks ja üldiselt turvalisemateks.
Konteinerid
Konteinerid on kindlasti 2010. aastate kõige enam arutletud, reklaamitud ja vale tõlgendusega tehnoloogia. Kuid samas on see ka üks eelmise kümnendi tähtsamaid uuendusi. Osaliselt on kogu selle kaosetausta põhjuseks segased signaalid, mida me praktiliselt igalt poolt saime. Nüüd, kui sära on pisut vaibunud, on mõned aspektid selgemaks muutunud.
Konteinerid ei ole populaarsed mitte sellepärast, et see oleks parim viis rakenduse käivitamiseks, mis vastab globaalsete arendajate vajadustele. Nad on populaarsed, kuna nad sobisid hästi turunduslikesse nõudmiste, mis otsisid mingit tööriista täiesti teise ülesande lahendamiseks. Docker osutus fantastiliseks arendustööriistaks, mis lahendab hädavajaliku ühilduvuse probleemi ("töötab minu masinal").
Tõepoolest, revolutsiooni tõi kaasa Docker-image, kuna see lahendas pariteedi probleemid keskkondade vahel ja tagas tõelise kaasaskantavuse mitte ainult rakenduse failile, vaid ka kõigile selle programmeerimis- ja operatsioonisõltuvustele. Tõsiasi, et see tööriist mingil moel suurendas „konteinerite“ populaarsust, mis on põhimõtteliselt üsna madala tasandi rakendusdetail, jääb mulle tõenäoliselt möödunud kümnendi peamiseks müsteeriumiks.
Serverless
Julgen väita, et „serveritut“ arvutust tagavate lahenduste tekkimine on isegi olulisem kui konteinerite tulek, kuna see tõeliselt võimaldab realiseerida nõudmise alusel arvutamise unistust. (on-demand). Viimase viie aasta jooksul olen jälginud serveritute lähenemise järkjärgulist laienemist (toetust on lisatud uutele programmeerimiskeeltele ja käituskeskkondadele). Selliste toodete nagu Azure Durable Functions ilmumine tundub õigesti suunatud samm stateful-funktsioonide realiseerimiseks (samuti lahendades , mis on seotud FaaS-i piirangutega). Oleks huvitav jälgida, kuidas see uus paradigma järgmiste aastate jooksul arenevad.
Automatiseerimine
Tõenäoliselt on sellest trendist kõige rohkem kasu saanud operatsioonitehnika inseneride kogukond, kuna see on võimaldanud ellu viia sellised kontseptsioonid nagu «infrastruktuur koodina» (IaC). Lisaks kattub automatiseerimise kirg «SRE kultuuri» kasvuga, mille eesmärk on suunata lähenemist operatsioonidele rohkem programmeerimisele.
Üldine API-ks muutmine
Teine huvitav joon möödunud kümnendist on erinevate arendustegevuste API-ks muutmine. Häid, paindlikke API-sid kasutades saavad arendajad luua uuenduslikke töövooge ja tööriistu, mis omakorda aitavad hooldusel ja muudavad töö mugavamaks.
Lisaks on API-ks muutmine esimene samm teatud funktsionaalsuse või tööriista SaaS-iks muutmiseks. See trend on samuti seotud mikroteenuste populaarsuse kasvuga: SaaS on muutunud lihtsalt üheks teenuseks, millega saab API kaudu töötada. Praegu on saadaval palju SaaS- ja FOSS-tööriistu sellistes valdkondades nagu monitooring, maksed, koormuse tasakaalustamine, pidev integreerimine, teavitamine ja funktsionaalsuse lülitamine. (funktsionaalsuse lülitamine), CDN, liikluse inseneritehing (nt DNS) jne, mis on olnud edukad viimase kümnendi jooksul.
Jälgimine
Oluline on märkida, et täna on meil saadaval märksa arenenumad rakenduste käitumise jälgimise ja diagnostika tööriistad kui kunagi varem. Prometheuse jälgimisse süsteem, mis sai avatud lähtekoodiga staatuse 2015. aastal, võib olla üks parimaid jälgimisse süsteeme, millega olen töötanud. See ei ole täiuslik, kuid paljuski on asjad selles teostatud täiesti õigetel viisidel (nt mõõtmiste toe osas jälgimisseadmest, millega olen töötanud. See ei ole täiuslik, kuid suurem osa asjadest on selles teostatud täiesti õigesti (näiteks mõõtmiste tugi [dimensionality] mõõdikute puhul).
Jaotatud jälgimine on saanud veel üheks tehnoloogiaks, mis jõudis peavoolu 2010. aastatel, tänu sellistele algatustele nagu OpenTracing (ja selle järglasena OpenTelemetry). Kuigi jälgimine on endiselt üsna keeruline, pakuvad mõned viimased arendused lootust, et 2020. aastatel suudame avada selle tõelise potentsiaali. (Märkus tõlkijalt: Vaadake ka meie blogist artikli tõlget «« sama autori poolt.)
Vaadates tulevikku
Kahjuks on palju probleemseid valdkondi, mis ootavad lahendust järgmistel kümnenditel. Siin on minu mõtted nende kohta ja mõned potentsiaalsed ideed, kuidas neist vabaneda.
Moore'i seaduse probleemi lahendamine
Denardi skaleerituse seaduse lõpp ja mahajäämus Moore'i seadusest nõuavad uut innovatsiooni. John Hennessy oma selgitab, miks probleemide lõikes sõltuvad (domain specific) arhitektuurid nagu TPU võivad olla üks lahendus Moore'i seaduse mahajäämusele. Tööriistakomplektid nagu Google'ilt näivad juba olevat hea edasiminek selles suunas:
Kompilaatorid peavad toetama uusi rakendusi, mis on kergesti ülekantavad uuele riistvarale, siduma erinevaid abstraktsiooni tasandeid, alustades dünaamilistest, hallatavatest keeltest ja lõpetades vektori kiirenditega ning tarkvaraliselt hallatavate mäluseadmetega, samas pakkudes kõrgetasemelisi lüliteid automaatsete seadete jaoks, tagades just-in-time funktsionaalsuse, diagnostika ning levitades tõrkeotsimise teavet süsteemide töö ja jõudluse kohta kogu kihis, ja samal ajal tagama enamasti jõudluse, mis on piisavalt lähedane käsitsi kirjutatud assemblerile. Kavatseme jagada oma visioonist, edusammudest ja plaanidest sarnase kompileerimise infrastruktuuri arendamise ja avalikustamise osas.
CI/CD
Kuigi CI populaarsuse kasv sai üheks peamiseks trendiks 2010. aastatel, jääb Jenkins endiselt CI kuldstandardiks.
See valdkond vajab tugevalt innovatsiooni järgmistes valdkondades:
- kasutajaliides (DSL testimis spetsifikatsioonide kodeerimiseks);
- rakenduse üksikasjad, mis muudavad selle tõeliselt skaleeritavaks ja kiireks;
- integreerimine erinevate keskkondadega (staging, prod jne), et toetada keerukamaid testimise vorme;
- katkematu kontrollimine ja juurutamine.
Arendustööriistad
Tööstusena oleme hakanud looma üha keerukamat ja muljetavaldavat tarkvara. Siiski, kui rääkida meie endi tööriistadest, võiks olukord olla palju parem.
Koostööline ja kaugjuhtimine (ssh kaudu) on saavutanud teatava populaarsuse, kuid ei ole saanud uuteks arendamise standarditeks. Kui sina, nagu mina, lükkad tagasi mõtte vajadusest pidevalt internetiühenduse järele vaid selleks, et programmeerida, on ssh kaudu kaugmasinal töötamine tõenäoliselt ebasobiv.
Paiksed arenduskeskkonnad, eriti inseneride jaoks, kes töötavad suurte teenusel põhinevate arhitektuuride kallal, on jätkuvalt probleemiks. Mõned projektid püüavad seda lahendada ja mind huvitaks, milline näeks välja kõige ergonoomilisem UX antud kasutusjuhtumi jaoks.
Samuti oleks huvitav arendada „kantavaid keskkondi“ teistesse arenduse valdkondadesse, näiteks tõrgete taasesitusse (või ), mis esinevad teatud tingimustes või teatud seadistustega.
Sooviksin ka näha rohkem uuendusi sellistes valdkondades nagu semantiline ja kontekstitundlik koodi otsing, tööriistad, mis seovad produktsioonis toimuvaid sündmusi konkreetsete koodibaasi osadega jne.
Kalkulatsioonid (PaaSi tulevik)
Konteinerite ja serverless lahenduste üldise buumi taustal on avaliku pilve ruumis lahenduste spekter viimastel aastatel märgatavalt laienenud.
Seetõttu tekib mitmeid huvitavaid küsimusi. Esiteks suureneb avalikus pilves saadaval olevate valikute nimekiri pidevalt. Pilveteenuste pakkujatel on töötajad ja ressursid, mis võimaldavad neil hõlpsasti sammu pidada Open Source'i uusimate saavutustega ning välja anda tooteid nagu „serverless pod'id” (kahtlustan, et nad lihtsalt teevad oma FaaS runtime'id OCI-ga ühilduvaks) või teisi sarnaseid veidraid asju.
Neile, kes kasutavad neid pilvelahendusi, võib vaid kadestada. Teoorias pakuvad Kubernetes'e (GKE, EKS, EKS Fargatel jne) pilveteenused pakkujatest sõltumatuid API-sid töökoormuste käitamiseks. Kui kasutate selliseid tooteid nagu ECS, Fargate, Google Cloud Run jne, siis tõenäoliselt olete juba maksimaalselt ära kasutanud teenusepakkuja pakutavaid huvitavaid funktsioone. Lisaks, kui ilmuvad uued tooted või arvutusparadigmad, siis on migratsioon tõenäoliselt lihtne ja muretu.
Arvestades, kui kiiresti sarnased lahendused arenevad (ma oleks üllatunud, kui lähitulevikus ei ilmuks paar-kolm uut varianti), on väikestel „platvormi“ meeskondadel (meeskonnad, mis tegelevad infrastruktuuriga ja vastutavad on-premise platvormide loomise eest ettevõtete töökoormuse käivitamiseks) äärmiselt raske konkureerida funktsioonide, kasutusmugavuse ja üldise usaldusväärsuse osas. 2010. aastad möödusid Kubernetes'e märgiga, kui tööriista PaaS (platform-as-a-service) loomiseks, seega ei tundu mulle mõttekas luua sisemist platvormi Kubernetes'e baasil, mis pakub samu valikuvõimalusi, lihtsust ja vabadust, mis on saadaval avalikus pilves. Tõstatada konteineripõhise PaaS kui „Kubernetes'i strateegia“ on sama, mis tahtlikult loobuda kõige uuenduslikumate pilvetehnoloogiate kasutamisest.
Kui vaadata praegu saadaval olevaid lahendusi arvutusvõimalused, on ilmne, et oma PaaS-i loomine pelgalt Kubernetesel on nagu iseenda nurka ajamine (mitte just kaugelt nägev lähenemine, eks?). Isegi kui keegi otsustab täna luua konteineripõhise PaaS-i Kubernetesel, näeb see paariaasta pärast välja nagu vananenud võrreldes pilvevõimalustega. Kuigi Kubernetes alustas oma elu avatud lähtekoodiga projektina, on tema eelkäijaks ja ideede generaatoriks vastav sisemine tööriist Google'is. Siiski, seda arendati alguses/ keskpaiku 2000. aastaid, mil arvutusmaastik oli täiesti erinev.
Lisaks sellele ei peaks ettevõtted ühes laias mõttes olema ekspertidena Kubernetes-klastrite haldamise alal, samas kui nad ei tegele oma andmekeskuste loomise ja hooldamisega. Usaldusväärse arvutusaluse tagamine on põhieesmärk pilveteenuse pakkujad.
Lõpuks on mul tunne, et oleme oma valdkonnas kogemuste osas veidi regressiooni teinud koostöökogemuste osas (). Heroku käivitati 2007. aastal ja on endiselt üks kõige lihtsamatest kasutamiseks platvormidest. Ilma kahtluseta on Kubernetes palju võimsam, laiendatav ja programmeeritav, kuid ma igatsen, kui lihtne oli Herokuga alustada ja rakendust juurutada. Selle platvormi kasutamiseks piisab Git'i tundmisest.
Kõik see viib mind järgmise järelduseni: meil on vaja parimaid, kõrgema taseme abstraktsioone (see on eriti tõene kõrgeima taseme abstraktsioonide kohta.).
Õige kõrgeima taseme API
Docker on suurepärane näide vajadusest paremate ülesannete jagamise järele, samal ajal kui õige kõrgeima taseme API rakendamine..
Docker'i probleem on see, et (vähemalt) algusest peale olid projekti jaoks seatud liiga suured eesmärgid: kõik selleks, et lahendada ühilduvuse probleem («töötab minu masinas») konteineritehnoloogia abil. Docker oli nii piltide formaat kui ka runtime, oma virtuaalne võrk, CLI tööriist, ja deemon, mis töötab root'i all, ning palju muud. Igatahes, sõnumite vahetamine oli üle keeruline, rääkimata „kergetest VM-idest“, kontrollgruppidest, nimede ruumidest, paljudest turvaprobleemidest ja funktsioonidest, mis on segi aetud turundusliku üleskutsega „loo, tarnige, käivitage mis tahes rakendus igal pool“.
Nagu iga hea abstraktsiooniga, kulub aega (ja samuti kogemusi ja valu), et jagada erinevad probleemid loogilisteks kihtideks, mida omavahel kombineerida. Kahjuks, enne kui Docker suutis sarnasele küpsusele jõuda, astus mängu Kubernetes. See monopoliseeris nii palju tähelepanu, et nüüd püüdsid kõik mitte maha jääda Kubernetes'i ökosüsteemi muutustest, samas kui konteinerite ökosüsteem sai teisejärguliseks.
Kubernetes jagab paljuski samu probleeme, mis Docker. Olenemata kõigist keskustest suurepärasest ja moodustatavast (composable) abstraktsioonist, ülesannete jagamine kihtideks ei ole liiga hästi kapseldatud. Selle tuum on konteinerite orkestraator, mis käivitab konteinerid klastris, mis koosneb erinevatest masinatest. See on üsna madala taseme ülesanne, mida rakendavad ainult insenerid, kes haldavad klastrit. Teisest küljest on Kubernetes ka kõrgeima taseme abstraktsioon, CLI-tööriist, millega kasutajad suhtlevad YAML-i kaudu.
Docker oli (ja on endiselt) äge tööriist arendamiseks, vaatamata kõigile oma puudustele. Üritades samal ajal jõuda kõikide „küülikutega” on selle arendajatel õnnestunud õigesti ellu viia kõrgeima taseme abstraktsioon. Kõrgeima taseme abstraktsiooni all mõtlen ma alamkogumi funktsionaalsust, milles sihtrühm (antud juhul arendajad, kes veedavad suure osa oma ajast oma kohalikes arenduskeskkondades) oli tõeliselt huvitatud ja mis töötas suurepäraselt „karbist välja”.
Dockerfile ja CLI-utility docker peavad olema hea „kõrge taseme kasutajaliidese” loomise näide. Tavaline arendaja saab alustada Dockeriga, teadmata midagi nüanssidest rakenduste elluviimine, mis aitavad parandada kasutuskogemust, nagu nimed, kontrollgrupid, mälu ja CPU piirangud jne. Lõppkokkuvõttes ei erine Dockerfile'i kirjutamine oluliselt shell-skripti kirjutamisest.
Kubernetes on suunatud erinevatele sihtrühmadele:
- klastrihalduritele;
- inseneridele, kes tegelevad infrastruktuuriga, laiendavad Kubernetes'i võimalusi ja loovad platvorme selle põhjal;
- lõppkasutajatele, kes suhtlevad Kubernetes'ega läbi
kubectl.
Kubernetes'i rakendatud „ühe API sobib kõigile” lähenemine kujutab endast erakordselt halvasti kapseldatud „keerukuse mäge”, ilma selgitamata, kuidas seda skaleerida. See kõik viib põhjendamatult pika õppimiskõverani. Kuidas Adam Jacob, „Docker tõi kasutajatele transformaalse kogemuse, mida pole siiani suudetud ületada. Küsige kelleltki, kes kasutab K8s, kas nad sooviksid, et see toimiks nagu nende esimene docker run. Vastus on jah:
Ütleksin, et tänapäeva infrastruktuuritehnoloogia peamine osa on liiga madalal tasemel (ja seetõttu peetakse seda "liiga keeruliseks"). Kubernetes on rakendatud üsna madalal tasemel. Jaotatud jälgimine oma (palju span'e, mis on kokku ühendatud, et moodustada traceview) on samuti rakendatud liiga madalal tasemel. Arendajatele suunatud tööriistad, mis rakendavad "kõrgeima taseme abstraktsioone", osutuvad tavaliselt kõige edukamateks. See järeldus kehtib üllataval arvul juhtudel (kui tehnoloogia on liiga keeruline või keeruline kasutada, on "kõrgeima taseme API/UI" selle tehnoloogia jaoks veel avastamata).
Praegu häirib cloud native ökosüsteem oma madalal tasemel ringluses. Tööstusena peame me uuendama, eksperimenteerima ja õpetama, millega näeb välja õige "maksimaalse, kõrgeima abstraktsiooni" tase.
Jaekaubandus
2010. aastatel ei ole jaemüügis digitaalne kogemus praktiliselt muutunud. Ühest küljest pidi veebipoe lihtsus klassikalisele jaemüügile tugevalt mõjuma, teisest küljest on veebikauplemine põhimõtteliselt peaaegu kümne aasta jooksul muutumatuks jäänud.
Kuigi mul ei ole konkreetseid mõtteid selle tööstusharu tuleviku kohta järgmise kümnendi jooksul, oleksin väga pettunud, kui 2030. aastal teeme oste endiselt nii, nagu me seda teeme 2020. aastal.
Ajjournalistika
Ma olen üha rohkem pettunud maailma ajakirjanduse seisukorras. Üha raskem on leida erapooletuid uudisteallikaid, mis edastavad objektiivset ja täpset teavet. Väga sageli hägustuvad piirid uudise ja arvamuse vahel. Üldiselt esitatakse teave kallutatult. See kehtib eriti mõnede riikide puhul, kus ajalooliselt ei ole uudise ja arvamuse vahel eristust olnud. Viimasel ajal avaldatud artiklis, mis ilmus pärast Ühendkuningriigi viimaseid üldvalimisi, ütles Alan Rusbridger, endine The Guardian'i peatoimetaja, :
Peamine mõte seisneb selles, et olen juba aastaid jälginud Ameerika ajalehti ja kahetsenud sealsete kolleegide üle, kes vastutavad ainult uudiste eest, jättes kommentaarid teiste inimeste hoolde. Aja jooksul on kahetsus muutunud kadeduseks. Nüüd arvan, et kõikide Briti rahvuslike ajalehtede tuleks eraldada vastutus uudiste eest ja vastutus kommentaaride eest. Kahjuks on tavaline lugeja – eriti veebilugeja – liiga raske vahet teha.
Arvestades Silicon Valley kahtlast mainet eetika osas, ei usaldaks ma mingil juhul tehnoloogiate 'revolutsiooni' ajakirjanduses. Sellegipoolest oleksin mina (ja paljud mu tuttavad) rõõmsad, kui tekiks erapooletu, altruistlik ja usaldusväärne uudisteallikas. Siiani ei suuda ma ette kujutada, kuidas selline platvorm võiks välja näha, kuid olen kindel, et ajal, mil tõde muutub järjest raskemini nähtavaks, on vajadus ausa ajakirjanduse järele ikka suurem kui kunagi varem.
Sotsiaalmeedia
Sotsiaalsed võrgustikud ja kollektiivsed uudisteplatvormid on paljude inimeste jaoks erinevates maailma nurkades peamine teabeallikas. Täpsuse puudumine ja soovimatus mõnel platvormil teha vähemalt põhjalikku faktide kontrolli toovad kaasa traagilisi tagajärgi, nagu genotsiid, sekkumine valimistesse jne.
Sotsiaalsed võrgustikud on ka kõige võimsamad meedia vahendid, mis kunagi olemas on olnud. Need on drastiliselt muutnud poliitilist praktikat, reklaami ja popkultuuri. (Näiteks on sotsiaalmeedia oluline panus nii-öelda cancel culture'i arengusse. [kultuurid, mis välistavad — tõlkija märk.] oluliselt mõjutavad just sotsiaalmeedia). Kriitikud väidavad, et sotsiaalsed võrgustikud on viljakas pinnas kiirete ja "kapriisiliste" muutuste tekkimiseks moraalsetes väärtustes, kuid samas on nad andnud marginaalsetele gruppidele võimaluse ühiselt tegutseda, mida enne ei olnud. Sisuliselt on sotsiaalsed võrgustikud muutnud suhtlemise ja eneseväljendamise viisi 21. sajandil.
Kuid ma olen samas veendunud, et sotsiaalmeedia soodustab halvimate inimimpulsside ilmnemist. Tihti unustatakse tähelepanelikkus ja mõtlemine populaarsuse nimel, mistõttu on peaaegu võimatu esitada argumenteeritud eri arvamusi. Polaariseeritus võib minna üle pea, mistõttu publik ei kuule lihtsalt üksikuid arvamusi, samas kui absoluutsed seisukohad dikteerivad online-etiketti ja vastuvõetavust.
Ma küsin endalt, kas on võimalik luua „parim” platvorm, mis aitaks tõsta arutelude kvaliteeti? Sest just see, mis ajendab „kaasatust”, toob sageli nendele platvormidele ka peamise kasumi. Kuidas Kara Swisher New York Timesis:
Digitaalset suhtlemist on võimalik arendada, ilma et see provotseeriks vihkamist ja sallimatust. Põhjus, miks enamik sotsiaalmeediat tundub nii mürgine, on see, et need loodi kiirusest, viiruslikkusest ja tähelepanu püüdmisest, mitte aga sisust ja täpsusest.
Tõeliselt kurb oleks, kui mõned aastakümned hiljem jääks sotsiaalmeede ainukeseks pärandiks toonus ja adekvaatsuse hajutamine avalikus arutelus.
P.S. tõlkija märkused
Lugege ka meie blogist:
- «»;
- «»;
- «»;
- «».
Allikas: habr.com
