Märge. tõlge: See artikkel, millest sai Mediumi hitt, on ülevaade peamistest (2010–2019) muudatustest programmeerimiskeelte maailmas ja sellega seotud tehnoloogilises ökosüsteemis (eriti Dockeril ja Kubernetesil). Selle algne autor on Cindy Sridharan, kes on spetsialiseerunud arendajatööriistadele ja hajutatud süsteemidele - eelkõige kirjutas ta raamatu "Hajutatud süsteemide jälgitavus" - ja on Interneti-ruumis IT-spetsialistide seas üsna populaarne, eriti pilvepõhise teema vastu huvi tundev.
Kuna 2019. aasta on lõppemas, soovisin jagada oma mõtteid viimase kümnendi olulisemate tehnoloogiliste edusammude ja uuenduste kohta. Lisaks püüan vaadata veidi tulevikku ning visandada tulevase kümnendi peamised probleemid ja võimalused.
Tahan selgitada, et selles artiklis ma ei käsitle muutusi sellistes valdkondades nagu andmeteadus (andmeteadus), tehisintellekt, frontend engineering jne, kuna mul isiklikult pole nendega piisavalt kogemusi.
Tüpistamine lööb vastu
2010. aastate üks positiivsemaid suundi oli staatiliselt trükitud keelte taaselustamine. Sellised keeled ei kadunud aga kunagi (tänapäeval on nõudlus C++ ja Java; need domineerisid kümme aastat tagasi), kuid dünaamiliselt trükitud keeled (dünaamika) kasvasid pärast Ruby on Railsi liikumise tekkimist 2005. aastal märkimisväärselt populaarsust. . See kasv saavutas haripunkti 2009. aastal avatud lähtekoodiga Node.js, mis muutis Javascript-on-the-server reaalsuseks.
Aja jooksul on dünaamilised keeled serveritarkvara loomise valdkonnas kaotanud osa oma veetlusest. Konteinerevolutsiooni ajal populaarseks saanud keel Go tundus paremini sobivat suure jõudlusega, ressursitõhusate paralleeltöötlusega serverite loomiseks (millega Node.js looja ise).
2010. aastal tutvustatud Rust hõlmas edasiminekuid püüdes muutuda turvaliseks ja trükitud keeleks. Kümnendi esimesel poolel oli Rusti vastuvõtt tööstuses üsna leige, kuid teisel poolel tõusis selle populaarsus märgatavalt. Rooste märkimisväärsed kasutusjuhtumid hõlmavad selle kasutamist , (me rääkisime sellest - u. tõlge.), varajane WebAssembly kompilaator Fastlyst (nüüd on osa bytecodealliance'ist) jne. Kuna Microsoft kaalub võimalust Windowsi OS-i mõned osad Rustis ümber kirjutada, võib kindlalt väita, et sellel keelel on 2020. aastatel helge tulevik.
Isegi dünaamilised keeled said uusi funktsioone, nagu (valikulised tüübid). Neid rakendati esmakordselt TypeScriptis, keeles, mis võimaldab teil luua trükitud koodi ja kompileerida selle JavaScripti. PHP-l, Rubyl ja Pythonil on oma valikulised tippimissüsteemid (, ), mida kasutatakse edukalt .
SQL-i tagastamine NoSQL-ile
NoSQL on veel üks tehnoloogia, mis oli kümnendi alguses palju populaarsem kui selle lõpus. Ma arvan, et sellel on kaks põhjust.
Esiteks osutus NoSQL-i mudel oma skeemi, tehingute ja nõrgemate järjepidevuse garantiidega raskemini rakendatavaks kui SQL-mudelit. IN pealkirjaga "Miks eelistada võimalusel tugevat järjepidevust" (Miks peaksite võimaluse korral valima tugeva konsistentsi) Google kirjutab:
Üks asi, mida oleme Google'is õppinud, on see, et rakenduse kood on lihtsam ja arendusaeg lühem, kui insenerid saavad keerukate tehingute haldamiseks ja andmete korrashoidmiseks tugineda olemasolevale salvestusruumile. Tsiteerides mutrivõtme originaaldokumentatsiooni: "Usume, et programmeerijatel on parem tegeleda tehingute kuritarvitamisest tulenevate rakenduste jõudlusprobleemidega, kui ilmnevad kitsaskohad, selle asemel, et pidevalt tehingute puudumist meeles pidada."
Teine põhjus on "mahutatavate" hajutatud SQL-andmebaaside (nt и ) avalikus pilveruumis, aga ka avatud lähtekoodiga alternatiive nagu CockroachDB (me räägime ka temast - u. tõlge.), mis lahendavad paljud tehnilised probleemid, mis põhjustasid traditsiooniliste SQL-andmebaaside „mitte skaleerimise”. Isegi MongoDB, mis kunagi oli NoSQL-i liikumise kehastus, on nüüdseks hajutatud tehingud.
Olukordades, mis nõuavad aatomi lugemist ja kirjutamist mitme dokumendi vahel (ühes või mitmes kogus), toetab MongoDB mitme dokumendi tehinguid. Jaotatud tehingute korral saab tehinguid kasutada mitme toimingu, kogude, andmebaaside, dokumentide ja tükkide lõikes.
Täielik voogesitus
Apache Kafka on kahtlemata üks viimase kümnendi olulisemaid leiutisi. Selle lähtekood avati 2011. aasta jaanuaris ja aastate jooksul on Kafka muutnud ettevõtete andmetega töötamise viisi. Kafkat on kasutatud igas ettevõttes, kus olen töötanud, alustades idufirmadest kuni suurkorporatsioonideni. Selle pakutavaid garantiisid ja kasutusjuhtumeid (pub-sub, voogud, sündmustepõhised arhitektuurid) kasutatakse mitmesugustes ülesannetes, alates andmete salvestamisest kuni jälgimise ja voogedastusanalüütikani, nõudes paljudes valdkondades, nagu rahandus, tervishoid, avalik sektor, jaemüük jne.
Pidev integreerimine (ja vähemal määral pidev juurutamine)
Pidev integratsioon ei ilmnenud viimase 10 aasta jooksul, küll aga viimase kümnendi jooksul on sellisel määral levinud, millest sai standardse töövoo osa (käivitage kõigi tõmbamistaotluste testid). GitHubi loomine platvormina koodi arendamiseks ja salvestamiseks ning, mis veelgi olulisem, töövoo arendamiseks, mis põhineb tähendab, et testide käivitamine enne tõmbetaotluse vastuvõtmist masterile on üksi arenduse töövoog, mis on tuttav inseneridele, kes alustasid oma karjääri viimase kümne aasta jooksul.
Pidev juurutamine (iga kinnituse juurutamine siis, kui see saavutab peamise) ei ole nii laialt levinud kui pidev integreerimine. Arvestades aga juurutamiseks mõeldud erinevate pilve API-de rohkusega, selliste platvormide nagu Kubernetes (mis pakuvad juurutamiseks standardiseeritud API-d) populaarsuse kasvu ning mitme platvormi ja mitme pilvetööriistade, nagu Spinnaker (ehitatud standardiseeritud platvormide peale). API-d), juurutusprotsessid on muutunud automatiseeritumaks, sujuvamaks ja üldiselt turvalisemaks.
Konteinerid
Konteinerid on võib-olla 2010. aastate kõige rohkem reklaamitud, arutatud, reklaamitud ja valesti mõistetud tehnoloogia. Teisalt on see eelmise kümnendi üks olulisemaid uuendusi. Osa kogu selle kakofoonia põhjustest peitub segatud signaalides, mida saime peaaegu kõikjalt. Nüüd, kui hüpe on veidi vaibunud, on mõned asjad teravamalt fookusse sattunud.
Konteinerid pole muutunud populaarseks mitte sellepärast, et need oleksid parim viis ülemaailmse arendajate kogukonna vajadustele vastava rakenduse käitamiseks. Konteinerid muutusid populaarseks, kuna need sobivad edukalt turundustaotlusega teatud tööriista jaoks, mis lahendab hoopis teistsuguse probleemi. Docker osutus selleks fantastiline arendustööriist, mis lahendab pakilise ühilduvusprobleemi ("töötab minu masinas").
Täpsemalt, revolutsioon tehti Dockeri pilt, sest see lahendas keskkondade vahelise pariteedi probleemi ja tagas mitte ainult rakendusfaili, vaid ka kogu selle tarkvara ja töösõltuvuste tõelise kaasaskantavuse. Asjaolu, et see tööriist mingil moel õhutas "konteinerite" populaarsust, mis on sisuliselt väga madala taseme rakendusdetailid, jääb minu jaoks võib-olla viimase kümnendi peamiseks mõistatuseks.
Serverita
Vean kihla, et "serverita" andmetöötluse tulek on isegi olulisem kui konteinerid, sest see muudab unistuse tellitavast andmetöötlusest reaalsuseks (On-demand). Viimase viie aasta jooksul olen näinud serverivaba lähenemise ulatust järk-järgult laienemas, lisades toe uutele keeltele ja käitusaegadele. Selliste toodete nagu Azure Durable Functions ilmumine näib olevat õige samm olekupõhiste funktsioonide rakendamise suunas (samal ajal otsustav. seotud FaaS-i piirangutega). Jälgin huviga, kuidas see uus paradigma lähiaastatel areneb.
Automaatika
Võib-olla on selle suundumuse suurim kasu operatiivinseneride kogukond, kuna see on võimaldanud sellistel kontseptsioonidel nagu infrastruktuur koodina (IaC) saada reaalsuseks. Lisaks on kirg automatiseerimise vastu langenud kokku "SRE kultuuri" tõusuga, mille eesmärk on läheneda operatsioonidele tarkvarakesksemalt.
Universaalne API-fiktsioon
Veel üks viimase kümnendi huvitav omadus on olnud erinevate arendusülesannete API-fiktsioon. Head, paindlikud API-d võimaldavad arendajal luua uuenduslikke töövooge ja tööriistu, mis omakorda aitavad hooldusel ja parandavad kasutajakogemust.
Lisaks on API-fication esimene samm mõne funktsiooni või tööriista SaaS-i kujundamise suunas. See trend langes kokku ka mikroteenuste populaarsuse kasvuga: SaaS-ist on saanud lihtsalt üks teenus, millele pääseb ligi API kaudu. Nüüd on saadaval palju SaaS-i ja FOSS-i tööriistu sellistes valdkondades nagu jälgimine, maksed, koormuse tasakaalustamine, pidev integreerimine, hoiatused, funktsioonide vahetamine (funktsiooni märgistamine), CDN, liikluskorraldus (nt DNS) jne, mis on viimasel kümnendil õitsele jõudnud.
jälgitavus
Väärib märkimist, et täna on meil juurdepääs palju arenenum tööriistad rakenduste käitumise jälgimiseks ja diagnoosimiseks kui kunagi varem. 2015. aastal avatud lähtekoodiga staatuse saanud seiresüsteemi Prometheus võib ehk nimetada parim seiresüsteem neilt, kellega olen töötanud. See pole täiuslik, kuid märkimisväärne hulk asju on rakendatud täpselt õigel viisil (näiteks mõõtmiste tugi [mõõtmelisus] mõõdikute puhul).
Hajutatud jälgimine oli teine tehnoloogia, mis jõudis 2010. aastatel peavoolu tänu sellistele algatustele nagu OpenTracing (ja selle järglane OpenTelemetry). Kuigi jälgimist on endiselt üsna raske rakendada, annavad mõned viimased arengud lootust, et 2020. aastatel avame selle tõelise potentsiaali. (Märkus: lugege meie ajaveebis ka artikli tõlget ""samalt autorilt.)
Tulevikku vaadates
Kahjuks on palju valupunkte, mis ootavad järgmisel kümnendil lahendust. Siin on minu mõtted nende kohta ja mõned võimalikud ideed, kuidas neist lahti saada.
Moore'i seaduse probleemi lahendamine
Dennardi skaleerimisseaduse lõpp ja mahajäämus Moore'i seadusest nõuavad uusi uuendusi. John Hennessy sisse selgitab, miks probleemsed sõltlased (domeenipõhine) arhitektuurid nagu TPU võivad olla üks lahendusi Moore'i seadusest mahajäämise probleemile. Tööriistakomplektid nagu Google'ilt näib juba olevat hea samm selles suunas:
Kompilaatorid peavad toetama uusi rakendusi, olema hõlpsasti teisaldatavad uuele riistvarale, siduma mitut abstraktsioonikihti alates dünaamilistest hallatavatest keeltest kuni vektorkiirendite ja tarkvaraga juhitavate salvestusseadmeteni, pakkudes samal ajal kõrgetasemelisi lüliteid automaatseks häälestamiseks, pakkudes lihtsalt funktsionaalsuses – ajas, diagnostikas ja süsteemide toimimise ja jõudluse silumisinfo levitamises kogu virna ulatuses, pakkudes samal ajal enamikul juhtudel jõudlust, mis on piisavalt lähedane käsitsi kirjutatud assemblerile. Kavatseme jagada oma nägemust, edusamme ja plaane sellise koostamise infrastruktuuri arendamiseks ja avalikuks kättesaadavaks tegemiseks.
CI / CD
Kuigi CI tõusust on saanud 2010. aastate üks suurimaid trende, on Jenkins endiselt CI kullastandard.
See ruum vajab hädasti uuendusi järgmistes valdkondades:
- kasutajaliides (DSL testi spetsifikatsioonide kodeerimiseks);
- rakendamise üksikasjad, mis muudavad selle tõeliselt skaleeritavaks ja kiireks;
- integreerimine erinevate keskkondadega (lavastus, toode jne), et rakendada täiustatud testimise vorme;
- pidev testimine ja juurutamine.
Arendaja tööriistad
Tööstusena oleme hakanud looma üha keerukamat ja muljetavaldavamat tarkvara. Kui aga rääkida meie enda tööriistadest, siis võiks olukord palju parem olla.
Koostöö ja kaugredigeerimine (ssh-i kaudu) saavutasid teatava populaarsuse, kuid ei muutunud kunagi uueks standardseks arendusviisiks. Kui teie, nagu mina, lükkate tagasi selle idee vajalik püsiühendus Internetiga, et saaks programmeerida, siis tõenäoliselt ei sobi kaugmasinas ssh kaudu töötamine.
Kohalikud arenduskeskkonnad, eriti suurte teenustele orienteeritud arhitektuuridega töötavate inseneride jaoks, on endiselt väljakutseks. Mõned projektid püüavad seda lahendada ja ma tahaksin teada, milline näeks välja kõige ergonoomilisem UX antud kasutusjuhul.
Samuti oleks huvitav laiendada "kaasaskantavate keskkondade" mõistet teistele arendusvaldkondadele, nagu vigade taastootmine (või ), mis ilmnevad teatud tingimustel või seadetes.
Samuti sooviksin näha rohkem uuendusi sellistes valdkondades nagu semantiline ja kontekstitundlik koodiotsing, tööriistad tootmisjuhtumite seostamiseks koodibaasi konkreetsete osadega jne.
Arvutustehnika (PaaS-i tulevik)
Pärast 2010. aastatel toimunud hüpet konteinerite ja serveriteta on avalikus pilveruumis pakutavate lahenduste valik viimastel aastatel oluliselt laienenud.
See tõstatab mitmeid huvitavaid küsimusi. Esiteks täieneb pidevalt avalikus pilves saadaolevate valikute loend. Pilveteenuste pakkujatel on töötajaid ja ressursse, et olla kursis avatud lähtekoodiga maailmas toimuvate viimaste arengutega ja lasta välja selliseid tooteid nagu "serverita taskud" (ma kahtlustan, et lihtsalt muutes nende enda FaaS-i käitusajad OCI-ühilduvaks) või muid sarnaseid uhkeid asju.
Võib ainult kadestada neid, kes neid pilvelahendusi kasutavad. Teoreetiliselt pakuvad Kubernetese pilvepakkumised (GKE, EKS, EKS Fargate'is jne) töökoormuste käitamiseks pilveteenuse pakkujast sõltumatuid API-sid. Kui kasutate sarnaseid tooteid (ECS, Fargate, Google Cloud Run jne), kasutate tõenäoliselt juba teenusepakkuja pakutavaid huvitavamaid funktsioone. Lisaks on uute toodete või andmetöötluse paradigmade ilmnemisel migratsioon tõenäoliselt lihtne ja stressivaba.
Arvestades, kui kiiresti selliste lahenduste valik areneb (olen väga üllatunud, kui paar uut võimalust lähiajal ei ilmu), väikesed "platvormi" meeskonnad (meeskonnad, mis on seotud infrastruktuuriga ja vastutavad kohapealsete platvormide loomise eest töökoormusega ettevõtted) on funktsionaalsuse, kasutuslihtsuse ja üldise töökindluse osas uskumatult raske konkureerida. 2010. aastad on näinud Kubernetest PaaS-i (platvorm-as-a-service) loomise tööriistana, mistõttu tundub mulle täiesti mõttetu ehitada Kubernetese peale siseplatvorm, mis pakub sama valikut, lihtsust ja avalikkusele kättesaadavat vabadust. pilveruum. Konteineripõhise PaaS-i raamimine Kubernetese strateegiaks on samaväärne pilve kõige uuenduslikumate võimaluste tahtliku vältimisega.
Kui vaadata saadaolevaid täna arvutusvõimalusi, saab ilmselgeks, et ainult Kubernetesel põhineva oma PaaS-i loomine võrdub enda nurka maalimisega (pole väga tulevikku vaatav lähenemine, ah?). Isegi kui keegi otsustab täna Kubernetesile konteineris PaaS-i ehitada, näeb see paari aasta pärast pilvevõimalustega võrreldes iganenud välja. Kuigi Kubernetes sai alguse avatud lähtekoodiga projektist, on selle esivanem ja inspiratsioon Google'i sisemine tööriist. Kuid see töötati algselt välja 2000. aastate alguses/keskpaigas, kui andmetöötlusmaastik oli täiesti erinev.
Samuti ei pea ettevõtted väga laias plaanis olema Kubernetese klastri juhtimise eksperdid, samuti ei ehita ja hooldavad nad oma andmekeskusi. Usaldusväärse andmetöötluse aluse loomine on peamine väljakutse pilveteenuse pakkujad.
Lõpuks tunnen, et oleme tööstusena veidi taandunud suhtlemiskogemus (). Heroku käivitati 2007. aastal ja on siiani üks enim lihtne kasutada platvormid. Ei saa eitada, et Kubernetes on palju võimsam, laiendatavam ja programmeeritavam, kuid ma tunnen puudust, kui lihtne on alustada ja Herokus kasutusele võtta. Selle platvormi kasutamiseks peate teadma ainult Giti.
Kõik see viib mind järgmise järelduseni: me vajame töötamiseks paremaid, kõrgema taseme abstraktsioone (see kehtib eriti kõrgeima taseme abstraktsioonid).
Õige API kõrgeimal tasemel
Docker on suurepärane näide murede parema eraldamise vajadusest samal ajal kõrgeima taseme API õige rakendamine.
Dockeri probleem seisneb selles, et (vähemalt) oli projektil algselt liiga laiad eesmärgid: kõik selleks, et konteinertehnoloogiat kasutades lahendada ühilduvusprobleem (“töötab minu masinas”). Docker oli pildivorming, oma virtuaalse võrguga käituskeskkond, CLI-tööriist, juurfunktsiooniga deemon ja palju muud. Sõnumivahetus igal juhul oli rohkem segadust tekitavad, rääkimata "kergetest VM-idest", c-rühmadest, nimeruumidest, paljudest turbeprobleemidest ja -funktsioonidest, mis on segatud turunduskutsega "ehitada, tarnida, käivitada mis tahes rakendust kõikjal".
Nagu kõigi heade abstraktsioonide puhul, kulub aega (ja kogemusi ja valu) erinevate probleemide jaotamine loogilisteks kihtideks, mida saab omavahel kombineerida. Kahjuks astus Kubernetes võitlusse enne, kui Docker jõudis sarnase küpsuseni. See monopoliseeris hüppetsükli nii palju, et nüüd püüdsid kõik Kubernetese ökosüsteemi muutustega sammu pidada ja konteineri ökosüsteem sai teisejärgulise staatuse.
Kubernetes jagab paljusid samu probleeme nagu Docker. Kõigi lahedast ja komponeeritavast abstraktsioonist rääkides, erinevate ülesannete eraldamine kihtideks ei ole väga hästi kapseldatud. Selle tuumaks on konteinerite orkestraator, mis juhib konteinereid erinevate masinate klastris. See on üsna madala tasemega ülesanne, mida saab rakendada ainult klastrit haldavatele inseneridele. Teisest küljest on ka Kubernetes kõrgeima taseme abstraktsioon, CLI tööriist, millega kasutajad suhtlevad YAML-i kaudu.
Docker oli (ja on siiani) lahe arendustööriist, hoolimata kõigist selle puudustest. Püüdes kõigi "jänestega" korraga sammu pidada, õnnestus selle arendajatel õigesti rakendada abstraktsioon kõrgeimal tasemel. Abstraktsiooni all pean silmas kõrgeimal tasemel alamhulk funktsionaalsus, mis sihtrühmale (antud juhul arendajatele, kes veetsid suurema osa ajast oma kohalikus arenduskeskkonnas) tõesti huvi pakkus ja mis töötas juba karbist välja võttes suurepäraselt.
Dockerfile ja CLI utiliit docker peaks olema näide hea "kõrgeima taseme kasutajakogemuse" loomisest. Tavaline arendaja võib Dockeriga tööd alustada, teadmata selle keerukusest midagi teostused, mis aitavad kaasa töökogemuselenagu nimeruumid, c-rühmad, mälu- ja protsessoripiirangud jne. Lõppkokkuvõttes ei erine Dockerfile'i kirjutamine palju kestaskripti kirjutamisest.
Kubernetes on mõeldud erinevatele sihtrühmadele:
- klastri administraatorid;
- taristuküsimustega tegelevad tarkvarainsenerid, Kubernetese võimaluste laiendamine ja selle baasil platvormide loomine;
- lõppkasutajad, kes suhtlevad Kubernetesiga
kubectl.
Kubernetese lähenemine "üks API sobib kõigile" kujutab endast ebapiisavalt kapseldatud "keerukuse mäge" ilma juhisteta, kuidas seda skaleerida. Kõik see toob kaasa õigustamatult veniva õpitrajektoori. Kuidas Adam Jacob: „Docker tõi kaasa muutliku kasutajakogemuse, mida pole kunagi ületatud. Küsige kõigilt, kes kasutavad K8-sid, kas nad soovivad, et see töötaks nagu nende esimene docker run. Vastus on jah":
Ma väidan, et enamik infrastruktuuritehnoloogiaid on tänapäeval liiga madala tasemega (ja seetõttu peetakse seda "liiga keeruliseks"). Kubernetes on rakendatud üsna madalal tasemel. Jaotatud jälgimine selle (palju vahemikke kokku õmmeldud, et moodustada jäljevaade) on samuti rakendatud liiga madalal tasemel. Kõige edukamad on tavaliselt arendustööriistad, mis rakendavad "kõrgeima taseme abstraktsioone". See järeldus kehtib üllatavalt paljudel juhtudel (kui tehnoloogia on liiga keeruline või raskesti kasutatav, tuleb selle tehnoloogia kõrgeima taseme API/UI-d veel avastada).
Praegu on pilve natiivne ökosüsteem oma madala fookuse tõttu segane. Tööstusena peame uuendusi tegema, katsetama ja harima, milline näeb välja õige "maksimaalse ja kõrgeima abstraktsiooni" tase.
Jaemüük
2010. aastatel jäi digitaalse jaemüügi kogemus suures osas muutumatuks. Ühelt poolt oleks pidanud e-ostlemise lihtsus tabama traditsioonilisi jaekauplusi, teisalt on e-ostlemine kümnendiga põhimõtteliselt peaaegu muutumatuna püsinud.
Kuigi mul pole konkreetseid mõtteid selle kohta, kuidas see tööstus järgmise kümnendi jooksul areneb, oleksin väga pettunud, kui ostleme 2030. aastal samamoodi nagu 2020. aastal.
ajakirjandus
Olen globaalse ajakirjanduse olukorras üha enam pettunud. Üha raskem on leida erapooletuid uudisteallikaid, mis kajastaksid objektiivselt ja hoolikalt. Väga sageli on piir uudise enda ja selle kohta avaldatud arvamuste vahel hägune. Teavet esitatakse reeglina kallutatud viisil. See kehtib eriti mõne riigi kohta, kus ajalooliselt pole uudiste ja arvamuse vahel olnud vahet. Hiljutises artiklis, mis avaldati pärast eelmisi Ühendkuningriigi üldvalimisi, ütles The Guardiani endine toimetaja Alan Rusbridger, :
Põhiline on see, et ma vaatasin aastaid Ameerika ajalehti ja tundsin kahju sealsetest kolleegidest, kes ainuisikuliselt vastutasid uudiste eest, jättes kommentaariumi täiesti erinevate inimeste hooleks. Aja jooksul muutus haletsus aga kadeduseks. Nüüd arvan, et kõik Briti riiklikud ajalehed peaksid eraldama vastutuse uudiste ja kommentaaride eest. Kahjuks on keskmisel lugejal – eriti veebilugejatel – liiga raske erinevust märgata.
Arvestades Silicon Valley üsna kahtlast mainet eetika vallas, ei usaldaks ma kunagi tehnoloogiat ajakirjanduse "revolutsiooni muutmiseks". Nagu öeldud, oleks mul (ja paljudel mu sõpradel) hea meel, kui oleks erapooletu, mittehuvitav ja usaldusväärne uudisteallikas. Kuigi mul pole õrna aimugi, milline selline platvorm välja näha võiks, olen ma kindel, et ajastul, mil tõde on üha raskem eristada, on vajadus ausa ajakirjanduse järele suurem kui kunagi varem.
Sotsiaalsed võrgustikud
Sotsiaalmeedia ja kogukonna uudisteplatvormid on paljude inimeste jaoks üle maailma peamine teabeallikas ning mõnede platvormide täpsuse puudumine ja vastumeelsus isegi elementaarsete faktide kontrollimise suhtes on viinud katastroofiliste tagajärgedeni, nagu genotsiid, valimistesse sekkumine ja palju muud. .
Sotsiaalmeedia on ka kõige võimsam meediatööriist, mis kunagi eksisteerinud on. Nad muutsid radikaalselt poliitilist praktikat. Nad muutsid reklaami. Nad muutsid popkultuuri (näiteks peamine panus nn tühistamiskultuuri arengusse [ostratsismi kultuurid – u. tõlge] sotsiaalsed võrgustikud). Kriitikud väidavad, et sotsiaalmeedia on osutunud soodsaks pinnaseks kiireteks ja kapriisseteks muutusteks moraalsetes väärtustes, kuid see on andnud ka marginaliseeritud rühmade liikmetele võimaluse organiseeruda viisil, mida neil kunagi varem polnud. Sisuliselt on sotsiaalmeedia muutnud inimeste suhtlemis- ja väljendusviisi 21. sajandil.
Usun aga ka, et sotsiaalmeedia toob esile inimlikud kõige hullemad impulsid. Kaalutlus ja läbimõeldus jäetakse populaarsuse kasuks sageli tähelepanuta ning teatud arvamuste ja seisukohtadega on peaaegu võimatu väljendada põhjendatud eriarvamust. Polarisatsioon väljub sageli kontrolli alt, mille tulemuseks on see, et avalikkus lihtsalt ei kuule individuaalseid arvamusi, samas kui absolutistid kontrollivad veebietiketi ja vastuvõetavuse küsimusi.
Huvitav, kas on võimalik luua “paremat” platvormi, mis edendaks kvaliteetsemaid arutelusid? Lõppude lõpuks toob nendele platvormidele sageli peamise kasumi just see, mis juhib kaasamist. Kuidas Kara Swisher New York Timesis:
Digitaalset suhtlust on võimalik arendada ilma vihkamist ja sallimatust esile kutsumata. Põhjus, miks enamik sotsiaalmeedia saite tundub nii mürgine, on see, et need on loodud kiiruse, viraalsuse ja tähelepanu, mitte sisu ja täpsuse jaoks.
Oleks tõeliselt kahetsusväärne, kui paarikümne aasta pärast oleks sotsiaalmeedia ainsaks pärandiks nüansside ja kohasuse vähenemine avalikus diskussioonis.
PS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com