Noat. transl.: Dit artikel, dat in hit waard op Medium, is in oersjoch fan wichtige (2010-2019) feroarings yn 'e wrâld fan programmeartalen en it byhearrende technology-ekosysteem (mei in spesjale fokus op Docker en Kubernetes). De orizjinele auteur is Cindy Sridharan, dy't spesjalisearre is yn ûntwikkelersark en ferspraat systemen - se skreau benammen it boek "Distributed Systems Observability" - en is frij populêr yn 'e ynternetromte ûnder IT-spesjalisten, foaral ynteressearre yn it ûnderwerp fan cloud native.
As 2019 oan in ein komt, woe ik myn gedachten diele oer guon fan 'e wichtichste technologyske foarútgong en ynnovaasjes fan' e ôfrûne desennia. Dêrnjonken sil ik besykje in bytsje yn 'e takomst te sjen en de wichtichste problemen en kânsen fan it kommende desennia te sketsen.
Ik wol dúdlik meitsje dat ik yn dit artikel gjin feroarings yn gebieten lykas datawittenskip dekke (data wittenskip), keunstmjittige yntelliginsje, frontend engineering, ensfh., om't ik persoanlik net genôch ûnderfining yn haw.
Typifikaasje slacht werom
Ien fan de meast positive trends fan de jierren 2010 wie it oplibjen fan statysk typte talen. Sokke talen ferdwûnen lykwols nea (C++ en Java binne hjoed yn 'e fraach; se dominearren tsien jier lyn), mar dynamysk typte talen (dynamyk) ûnderfûnen in signifikante tanimming fan populariteit nei it ûntstean fan' e Ruby on Rails-beweging yn 2005 . Dizze groei berikte in hichtepunt yn 2009 mei de iepen boarne fan Node.js, dy't Javascript-op-de-tsjinner in realiteit makke.
Yn 'e rin fan' e tiid hawwe dynamyske talen wat fan har oantreklikens ferlern op it mêd fan it meitsjen fan serversoftware. De Go-taal, popularisearre tidens de kontenerrevolúsje, like better geskikt foar it meitsjen fan hege prestaasjes, boarne-effisjinte, parallelle ferwurkingsservers (wêrmei de makker fan Node.js sels).
Rust, yntrodusearre yn 2010, omfette foarútgong yn yn in besykjen in feilige en typte taal te wurden. Yn 'e earste helte fan' e desennia wie de ûntfangst fan Rust yn 'e yndustry nochal lulk, mar syn populariteit naam yn 'e twadde helte flink ta. Opmerklike gebrûk gefallen foar Rust omfetsje it gebrûk foar , (wy hawwe it der oer yn - ca. oerset.), in betide WebAssembly-kompiler fan Fastly (no ûnderdiel fan 'e bytecodealliance) en oaren. Yn in situaasje wêr't Microsoft beskôget it opnij skriuwen fan guon dielen fan it OS Windows Rust, it is feilich om te sizzen dat de taal in ljochte takomst hat yn 'e 2020's.
Sels dynamyske talen krigen nije funksjes lykas (opsjonele soarten). Se waarden earst ymplementearre yn TypeScript, in taal wêrmei jo typearre koade kinne oanmeitsje en kompilearje yn JavaScript. PHP, Ruby en Python hawwe har eigen opsjonele typsystemen (, ), dy't mei súkses wurde brûkt yn .
SQL werom nei NoSQL
NoSQL is in oare technology dy't oan it begjin fan 'e desennia folle populêrder wie as oan 'e ein. Ik tink dat d'r twa redenen foar binne.
Earst, it NoSQL-model, mei syn gebrek oan skema, transaksjes, en swakkere konsistinsjegarânsjes, die bliken te wêzen lestiger te ymplementearjen dan it SQL-model. YN mei de titel "Wêrom jo moatte leaver sterke konsistinsje wannear mooglik" (Wêrom moatte jo sterke konsistinsje kieze, wannear mooglik) Google skriuwt:
Ien fan 'e dingen dy't wy by Google hawwe leard is dat applikaasjekoade ienfâldiger is en ûntwikkelingstiid koarter is as yngenieurs kinne fertrouwe op besteande opslach om komplekse transaksjes te behanneljen en gegevens yn oarder te hâlden. Om de orizjinele Spanner-dokumintaasje te sitearjen, "Wy leauwe dat it better is foar programmeurs om te gean mei problemen mei applikaasjeprestaasjes fanwegen misbrûk fan transaksjes as knelpunten ûntsteane, ynstee fan konstant it ûntbrekken fan transaksjes yn gedachten te hâlden."
De twadde reden komt troch de opkomst fan "skaal-out" ferspraat SQL-databases (lykas и ) yn 'e iepenbiere wolkromte, lykas Open Source-alternativen lykas CockroachDB (wy hawwe it ek oer har — ca. oerset.), dy't in protte fan 'e technyske problemen oplosse dy't tradysjonele SQL-databases feroarsake "net skaal". Sels MongoDB, eartiids it toaniel fan 'e NoSQL-beweging, is no ferdield transaksjes.
Foar situaasjes dy't atoomlêzen en skriuwt oer meardere dokuminten (oer ien of mear kolleksjes) fereaskje, stipet MongoDB transaksjes mei meardere dokuminten. Yn it gefal fan ferdielde transaksjes kinne transaksjes brûkt wurde oer meardere operaasjes, kolleksjes, databases, dokuminten en shards.
Totale streaming
Apache Kafka is sûnder mis ien fan 'e wichtichste útfinings fan 'e ôfrûne desennia. De boarnekoade waard iepene yn jannewaris 2011, en yn 'e rin fan' e jierren hat Kafka de manier wêrop bedriuwen wurkje mei gegevens revolúsjonearre. Kafka is brûkt yn elk bedriuw wêrfoar ik haw wurke, fan startups oant grutte bedriuwen. De garânsjes en gebrûksgefallen dy't it leveret (pub-sub, streamen, evenemint-oandreaune arsjitektuer) wurde brûkt yn in ferskaat oan taken, fan gegevensopslach oant tafersjoch en streaminganalytyk, yn fraach yn in protte gebieten lykas finânsjes, sûnenssoarch, publike sektor, retail en ensfh.
Trochrinnende yntegraasje (en yn mindere mjitte trochgeande ynset)
Trochrinnende yntegraasje ferskynde net yn 'e lêste 10 jier, mar yn' e ôfrûne desennia hat ferspraat yn sa'n mjitte, dy't diel wurden is fan 'e standert workflow (tests útfiere op alle pull-oanfragen). GitHub oprjochtsje as platfoarm foar it ûntwikkeljen en opslaan fan koade en, wichtiger, it ûntwikkeljen fan in workflow basearre op betsjut dat it útfieren fan tests foar it akseptearjen fan in pull fersyk om te master is allinnich workflow yn ûntwikkeling, bekend foar yngenieurs dy't har karriêre begûnen yn 'e lêste tsien jier.
Continuous Deployment (it ynsetten fan elke commit as en wannear't it master treft) is net sa wiidferspraat as trochgeande yntegraasje. Mei de oerfloed fan ferskate wolk API's foar ynset, de groeiende populariteit fan platfoarms lykas Kubernetes (dy't in standerdisearre API foar ynset leverje), en it ûntstean fan multi-platfoarm, multi-wolk ark lykas Spinnaker (boud boppe op dy standerdisearre API's), binne ynsetprosessen mear automatisearre, streamlined en, yn 't algemien, feiliger wurden.
Containers
Containers binne faaks de meast hyped, besprutsen, advertearre en ferkeard begrepen technology fan 'e 2010's. Oan 'e oare kant is it ien fan' e wichtichste ynnovaasjes fan 'e foarige desennia. In part fan de reden foar al dizze kakofonie leit yn 'e mingde sinjalen dy't wy hast oeral krigen. No't de hype wat ferstoarn is, binne guon dingen skerper yn 'e fokus kommen.
Containers binne populêr wurden, net om't se de bêste manier binne om in applikaasje út te fieren dy't foldocht oan 'e behoeften fan' e wrâldwide ûntwikkeldersmienskip. Containers waarden populêr om't se mei súkses passe yn in marketingfersyk foar in bepaald ark dat in folslein oar probleem oplost. Docker die bliken te wêzen fantastysk in ûntwikkelingsark dat it driuwende kompatibiliteitsprobleem oplost ("wurket op myn masine").
Mear krekter waard de revolúsje makke Docker ôfbylding, om't it it probleem fan pariteit tusken omjouwings oploste en wiere portabiliteit net allinich fan it applikaasjebestân levere, mar ek fan al har software- en bestjoeringsôfhinklikens. It feit dat dit ark op ien of oare manier de populariteit fan "containers" stimulearre, dy't yn wêzen in ymplemintaasjedetail op heul leech nivo binne, bliuwt foar my miskien it wichtichste mystearje fan 'e ôfrûne desennia.
Tsjinnerleas
Ik soe wedzje dat de komst fan "serverless" komputer noch wichtiger is dan konteners, om't it wirklik de dream fan berekkenjen op oanfraach in realiteit makket (op oanfraach). Yn 'e ôfrûne fiif jier haw ik sjoen dat de serverless oanpak stadichoan útwreide yn omfang troch it tafoegjen fan stipe foar nije talen en runtimes. It ûntstean fan produkten lykas Azure Durable Functions liket de goeie stap te wêzen nei de ymplemintaasje fan steatlike funksjes (tagelyk in beslissende relatearre oan FaaS-beheiningen). Ik sil mei belangstelling sjen hoe't dit nije paradigma de kommende jierren ûntwikkelet.
Automatisearring
Miskien is de grutste begunstigde fan dizze trend de operaasje-technykmienskip, om't it konsepten lykas ynfrastruktuer as koade (IaC) ynskeakele hat om in realiteit te wurden. Derneist is de passy foar automatisearring gearfallen mei de opkomst fan 'e "SRE-kultuer", dy't as doel hat in mear software-sintraal oanpak fan operaasjes te nimmen.
Universele API-fikaasje
In oar nijsgjirrich skaaimerk fan 'e ôfrûne desennia wie de API-fikaasje fan ferskate ûntwikkelingstaken. Goede, fleksibele API's kinne de ûntwikkelder ynnovative workflows en ark meitsje, dy't op har beurt helpe mei ûnderhâld en ferbetterje de brûkersûnderfining.
Derneist is API-fikaasje de earste stap nei SaaS-fikaasje fan guon funksjonaliteit of ark. Dizze trend foel ek oerien mei de opkomst yn populariteit fan mikrotsjinsten: SaaS is gewoan in oare tsjinst wurden dy't tagonklik wurde kin fia API. D'r binne no in protte SaaS- en FOSS-ark beskikber yn gebieten lykas tafersjoch, betellingen, load balancing, trochgeande yntegraasje, warskôgings, funksje-wikseling (funksje flagge), CDN, ferkearstechnyk (bygelyks DNS), ensfh., dy't yn 'e ôfrûne tsien jier bloeie.
observabiliteit
It is de muoite wurdich opskriuwen dat hjoed wy hawwe tagong ta folle mear avansearre ark om tapassingsgedrach te kontrolearjen en te diagnostearjen dan ea earder. It Prometheus-kontrôlesysteem, dat yn 2015 de Open Source-status krige, kin miskien neamd wurde de bêste tafersjochsysteem fan dyjingen dêr't ik haw wurke. It is net perfekt, mar in signifikant oantal dingen wurde op krekt de goede manier ymplementearre (bygelyks stipe foar mjittingen [dimensjonaliteit] yn it gefal fan metriken).
Ferspraat tracing wie in oare technology dy't yn 'e 2010's yn 'e mainstream kaam, troch inisjativen lykas OpenTracing (en har opfolger OpenTelemetry). Hoewol tracing noch altyd frij lestich is om oan te passen, jouwe guon fan 'e lêste ûntjouwings hope dat wy it wiere potensjeel yn' e 2020's sille ûntsluten. (Opmerking: Lês ek yn ús blog de oersetting fan it artikel ""troch deselde skriuwer.)
Op syk nei de takomst
Spitigernôch binne d'r in protte pinepunten dy't wachtsje op resolúsje yn 'e kommende desennia. Hjir binne myn gedachten oer har en wat potinsjele ideeën oer hoe't jo se kwyt kinne.
It probleem fan 'e wet fan Moore oplosse
It ein fan 'e skaalfergrutting fan Dennard en de efterstân efter Moore's wet fereaskje nije ynnovaasjes. John Hennessy yn ferklearret wêrom probleem ferslaafden (domein spesifyk) arsjitektueren lykas TPU kinne ien fan 'e oplossingen wêze foar it probleem fan efterbliuwend efter Moore's wet. Toolkits lykas fan Google liket al in goede stap foarút te wêzen yn dizze rjochting:
Kompilators moatte nije applikaasjes stypje, maklik wurde porteare nei nije hardware, meardere lagen fan abstraksje keppelje, fariearjend fan dynamyske, behearde talen oant fektorversnellers en software-kontroleare opslachapparaten, wylst se heechnivo-skeakels leverje foar auto-tuning, krekt- yn funksjonaliteit -tiid, diagnostyk, en it fersprieden fan debuggen ynformaasje oer it funksjonearjen en prestaasjes fan systemen yn 'e steapel, wylst yn' e measte gefallen prestaasjes leverje dy't ridlik tichtby de hân skreaune assembler is. Wy binne fan doel om ús fyzje, foarútgong en plannen te dielen foar de ûntwikkeling en publike beskikberens fan sa'n kompilaasje-ynfrastruktuer.
CI / CD
Wylst de opkomst fan CI is wurden ien fan de grutste trends fan de 2010s, Jenkins is noch altyd de gouden standert foar CI.
Dizze romte is yn driuwend ferlet fan ynnovaasje op 'e folgjende gebieten:
- brûkersynterface (DSL foar kodearring testspesifikaasjes);
- ymplemintaasjedetails dy't it wirklik skalberber en fluch meitsje sille;
- yntegraasje mei ferskate omjouwings (staging, prod, ensfh.) Om mear avansearre foarmen fan testen út te fieren;
- trochgeande testen en ynset.
Developer Tools
As yndustry binne wy begon te meitsjen hieltyd kompleksere en yndrukwekkende software. As it lykwols giet om ús eigen ark, kin de situaasje folle better wêze.
Gearwurking en bewurkjen op ôfstân (fia ssh) krigen wat populariteit, mar waard nea de nije standertwize fan ûntwikkeling. As jo, lykas my, ôfwize it tige idee fan needsaak in permaninte ferbining mei it ynternet gewoan om programmearje te kinnen, dan sil wurkje fia ssh op in masine op ôfstân net wierskynlik by jo passe.
Lokale ûntwikkelingsomjouwings, foaral foar yngenieurs dy't wurkje oan grutte tsjinst-rjochte arsjitekten, binne noch altyd in útdaging. Guon projekten besykje te lossen dit, en ik soe wêze ynteressearre om te witten hoe't de meast ergonomische UX soe útsjen foar in opjûn gebrûk gefal.
It soe ek nijsgjirrich wêze om it konsept fan "draachbere omjouwings" út te wreidzjen nei oare gebieten fan ûntwikkeling, lykas bugreproduksje (of ) dy't foarkomme ûnder bepaalde betingsten of ynstellings.
Ik wol ek mear ynnovaasje sjen yn gebieten lykas semantyske en kontekstgefoelige koadesykjen, ark om produksjeynsidinten te korrelearjen mei spesifike dielen fan 'e koadebase, ensfh.
Computing (de takomst fan PaaS)
Nei de hype om konteners en serverless yn 'e 2010's, is it oanbod fan oplossingen yn' e iepenbiere wolkromte de lêste jierren flink útwreide.
Dit ropt ferskate nijsgjirrige fragen op. Alderearst groeit de list mei beskikbere opsjes yn 'e iepenbiere wolk konstant. Oanbieders fan wolktsjinsten hawwe it personiel en middels om maklik by te hâlden mei de lêste ûntjouwings yn 'e Open Source-wrâld en produkten frij te jaan lykas "serverless pods" (ik fermoedzje gewoan troch har eigen FaaS-runtimes OCI-kompatibel te meitsjen) of oare ferlykbere fancy dingen.
Men kin allinich oergeunstich wêze op dyjingen dy't dizze wolkoplossingen brûke. Yn teory biede Kubernetes-wolkoffers (GKE, EKS, EKS op Fargate, ensfh.) Cloud-oanbieder-ûnôfhinklike API's foar it útfieren fan workloads. As jo ferlykbere produkten brûke (ECS, Fargate, Google Cloud Run, ensfh.), Hawwe jo wierskynlik al it measte út 'e meast nijsgjirrige funksjes oanbean troch de tsjinstferliener. Derneist, as nije produkten of komputerparadigma's opkomme, sil migraasje wierskynlik ienfâldich en stressfrij wêze.
Yn betinken nommen hoe fluch it berik fan sokke oplossingen evoluearret (ik sil tige ferrast wêze as in pear nije opsjes net ferskine yn 'e heine takomst), lytse "platfoarm" teams (teams ferbûn mei ynfrastruktuer en ferantwurdlik foar it meitsjen fan on-premise platfoarms foar bedriuwen mei wurkdruk) sil ongelooflijk lestich wêze om te konkurrearjen yn termen fan funksjonaliteit, gebrûksgemak en algemiene betrouberens. De 2010's hawwe Kubernetes sjoen as in ark foar it bouwen fan PaaS (platfoarm-as-a-tsjinst), dus it liket my folslein sinleas om in ynterne platfoarm boppe op Kubernetes te bouwen dat deselde kar, ienfâld en frijheid biedt beskikber yn it publyk wolk romte. It framen fan container-basearre PaaS as in "Kubernetes-strategy" is gelyk oan it bewust foarkommen fan 'e meast ynnovative mooglikheden fan' e wolk.
As jo sjogge nei de beskikbere hjoed komputermooglikheden, wurdt it dúdlik dat it meitsjen fan jo eigen PaaS allinich basearre op Kubernetes is gelyk oan it skilderjen fan josels yn in hoeke (net in heul foarútstribjende oanpak, huh?). Sels as immen beslút hjoed in containerized PaaS op Kubernetes te bouwen, sil it oer in pear jier ferâldere útsjen yn ferliking mei wolkmooglikheden. Hoewol Kubernetes begon as in iepen boarne-projekt, is har foarfaar en ynspiraasje in ynterne Google-ark. It waard lykwols oarspronklik ûntwikkele yn 'e iere / mids 2000's doe't it komputerlânskip folslein oars wie.
Ek hoege bedriuwen yn in heul brede sin gjin saakkundigen te wurden yn it útfieren fan in Kubernetes-kluster, noch bouwe en ûnderhâlde se har eigen datasintra. It leverjen fan in betroubere komputerbasis is in kearnútdaging wolk tsjinstferlieners.
Uteinlik fiel ik dat wy as yndustry in bytsje weromrûn binne yn termen fan ynteraksje ûnderfining (). Heroku waard lansearre yn 2007 en is noch altyd ien fan de meast maklik te brûken platfoarms. D'r is net te ûntkennen dat Kubernetes folle machtiger, útwreiberber en programmeerber is, mar ik mis hoe maklik it is om te begjinnen en yn te setten nei Heroku. Om dit platfoarm te brûken, moatte jo allinich Git witte.
Dit alles liedt my ta de folgjende konklúzje: wy hawwe bettere abstraksjes op heger nivo nedich om te wurkjen (dit is benammen wier foar abstraksjes op it heechste nivo).
De juste API op it heechste nivo
Docker is in geweldich foarbyld fan de needsaak foar bettere skieding fan soargen tagelyk korrekte útfiering fan it heechste nivo API.
It probleem mei Docker is dat (op syn minst) de doelen fan it projekt yn earste ynstânsje te breed wiene: alles om it kompatibiliteitsprobleem op te lossen ("wurket op myn masine") mei kontenertechnology. Docker wie in byldformaat, in runtime mei in eigen firtuele netwurk, in CLI-ark, in daemon dy't rint as root, en folle mear. Yn alle gefallen wie de útwikseling fan berjochten mear as betiizjend, net te hawwen oer "ljochtgewicht VM's", cgroups, nammeromten, tal fan feiligensproblemen en funksjes mingd mei de marketingoprop om "bouwe, leverje, útfiere elke applikaasje oeral".
Lykas by alle goede abstraksjes kostet it tiid (en ûnderfining en pine) om ferskate problemen op te brekken yn logyske lagen dy't mei-inoar kombinearre wurde kinne. Spitigernôch, foardat Docker ferlykbere folwoeksenheid koe berikke, kaam Kubernetes yn 'e striid. It monopolisearre de hype-syklus sa folle dat no elkenien besocht te hâlden mei feroaringen yn it Kubernetes-ekosysteem, en it kontener-ekosysteem krige in sekundêre status.
Kubernetes dielt in protte fan deselde problemen as Docker. Foar al it praat oer koele en komponearjende abstraksje, ferskate taken skieden yn lagen net hiel goed ynkapsele. Yn har kearn is it in kontenerorkestrator dy't konteners op in kluster fan ferskate masines rint. Dit is in frijwat leech-nivo taak, allinich fan tapassing op yngenieurs dy't it kluster betsjinje. Oan 'e oare kant is Kubernetes ek abstraksje fan it heechste nivo, in CLI-ark wêrmei brûkers ynteraksje mei fia YAML.
Docker wie (en is noch altyd) koel ûntwikkeling ark, nettsjinsteande al syn tekoartkommingen. Yn in besykjen om te hâlden mei alle "hazen" tagelyk, syn ûntwikkelders slagge om korrekt útfiere abstraksje op it heechste nivo. Mei abstraksje op it heechste nivo bedoel ik in subset funksjonaliteit dêr't it doelpublyk (yn dit gefal, ûntwikkelders dy't de measte fan har tiid yn har pleatslike ûntwikkelingsomjouwing trochbrocht hawwe) echt ynteressearre wiene en dy't geweldich wurke út 'e doaze.
Dockerfile en CLI-hulpprogramma docker moat in foarbyld wêze fan hoe't jo in goede "brûkersûnderfining op it heechste nivo" bouwe kinne. In gewoane ûntwikkelder kin begjinne te wurkjen mei Docker sûnder wat te witten oer de yngewikkeldheden ymplemintaasjes dy't bydrage oan operasjonele ûnderfininglykas nammeromten, cgroups, ûnthâld en CPU-grinzen, ensfh. Uteinlik is it skriuwen fan in Dockerfile net folle oars as it skriuwen fan in shell-skript.
Kubernetes is bedoeld foar ferskate doelgroepen:
- klusterbehearders;
- software-yngenieurs dy't wurkje oan ynfrastruktuerproblemen, de mooglikheden fan Kubernetes útwreidzje en dêrop basearre platfoarms meitsje;
- ein brûkers dy't ynteraksje mei Kubernetes fia
kubectl.
Kubernetes syn "ien API fits all" oanpak presintearret in net genôch ynkapsele "berch fan kompleksiteit" sûnder begelieding oer hoe't it skaaljen. Dit alles liedt ta in ûnrjochtfeardich langere leartrajekt. Hoe Adam Jacob, "Docker brocht in transformative brûkersûnderfining dy't noait is oertroffen. Freegje elkenien dy't in K8's brûkt as se wolle dat it wurke as har earste docker run. It antwurd sil ja wêze":
Ik soe stelle dat de measte ynfrastruktuertechnology hjoed te leech is (en dêrom beskôge as "te kompleks"). Kubernetes wurdt ymplementearre op in frij leech nivo. Ferspraat tracing yn syn (in protte oerspanten stitched tegearre foar in foarm fan in traceview) wurdt ek útfierd op in te leech nivo. Untwikkeldersynstruminten dy't de "abstraksjes op it heechste nivo" ymplementearje binne de meast suksesfolle. Dizze konklúzje jildt yn in ferrassend oantal gefallen (as de technology te kompleks of lestich is om te brûken, dan moat de "API / UI op it heechste nivo" foar dy technology noch ûntdutsen wurde).
Op it stuit is it natuerlik wolkekosysteem betiizjend troch syn fokus op leech nivo. As yndustry moatte wy ynnovearje, eksperimintearje en opliede oer hoe't it juste nivo fan "maksimum, heechste abstraksje" derút sjocht.
Retail
Yn 'e 2010's bleau de digitale retailûnderfining foar in grut part net feroare. Oan 'e iene kant soe it gemak fan online winkeljen tradisjonele retailwinkels moatte berikke, oan' e oare kant is online winkeljen yn in desennium yn prinsipe hast net feroare bleaun.
Hoewol ik gjin spesifike gedachten haw oer hoe't dizze sektor de kommende desennia sil evoluearje, soe ik heul teloarsteld wêze as wy yn 2030 winkelje op deselde manier as yn 2020.
Sjoernalistyk
Ik bin hieltyd mear desyllúzjearre mei de steat fan wrâldwide sjoernalistyk. It wurdt hieltyd dreger om ûnbidige nijsboarnen te finen dy't objektyf en sekuer rapportearje. Hiel faak is de grins tusken it nijs sels en de mieningen deroer wazig. As regel, ynformaasje wurdt presintearre op in biased wize. Dit is benammen wier yn guon lannen dêr't histoarysk gjin skieding west hat tusken nijs en miening. Yn in resint artikel publisearre nei de lêste algemiene ferkiezings yn it Feriene Keninkryk, Alan Rusbridger, eardere redakteur fan The Guardian, :
It wichtichste punt is dat ik jierrenlang nei Amerikaanske kranten seach en meilijen fielde foar myn kollega's dêr, dy't allinnich ferantwurdlik wiene foar it nijs, it kommentaar oerlitten oan folslein oare minsken. Lykwols, nei ferrin fan tiid, meilijen feroare yn oergeunst. Ik tink no dat alle Britske nasjonale kranten har ferantwurdlikens foar nijs skiede moatte fan har ferantwurdlikens foar kommentaar. Spitigernôch is it te lestich foar de gemiddelde lêzer - benammen online lêzers - om it ferskil te ûnderskieden.
Sjoen de nochal dubieuze reputaasje fan Silicon Valley as it giet om etyk, soe ik technology nea fertrouwe om sjoernalistyk te "revolúsjonearje". Dat wurdt sein, ik (en in protte fan myn freonen) soe bliid wêze as d'r in ûnpartidige, belangeleas en betroubere nijsboarne wie. Wylst ik gjin idee haw hoe't sa'n platfoarm der útsjen kin, bin ik der wis fan dat yn in tiidrek dêr't de wierheid hieltyd dreger wurdt om te ûnderskieden, de needsaak foar earlike sjoernalistyk grutter is dan ea.
sosjale Networking
Sosjale media en mienskipsnijsplatfoarms binne de primêre boarne fan ynformaasje foar in protte minsken oer de hiele wrâld, en it gebrek oan krektens en weromhâldendheid fan guon platfoarms om sels basale feitkontrôle te dwaan hat laat ta desastreuze gefolgen lykas genoside, ferkiezingsinterferinsje, en mear .
Sosjale media is ek it machtichste media-ark dat ea bestien hat. Se hawwe de politike praktyk yngripend feroare. Se feroare de reklame. Se feroare popkultuer (bygelyks de wichtichste bydrage oan 'e ûntwikkeling fan' e saneamde cancel-kultuer [kultueren fan útstrieling - ca. oers.] sosjale netwurken bydrage). Kritisy beweare dat sosjale media bewiisd hawwe fruchtbere grûn te wêzen foar rappe en grillige feroaringen yn morele wearden, mar it hat ek leden fan marginalisearre groepen de kâns jûn om te organisearjen op manieren dy't se nea earder hienen. Yn essinsje hawwe sosjale media de manier feroare wêrop minsken kommunisearje en har uterje yn 'e 21e ieu.
Ik leau lykwols ek dat sosjale media de slimste minsklike ympulsen nei bûten bringe. Beskôging en yntinsiteit wurde faak negeare yn it foardiel fan populariteit, en it wurdt hast ûnmooglik om redeneare ûnienens mei bepaalde mieningen en posysjes út te sprekken. Polarisaasje komt faaks út 'e kontrôle, wat resulteart yn it publyk gewoan gjin yndividuele mieningen te hearren, wylst absolutisten problemen kontrolearje fan online etikette en akseptabiliteit.
Ik freegje my ôf oft it mooglik is om in "better" platfoarm te meitsjen dat diskusjes fan bettere kwaliteit befoarderet? It is ommers wat "engagement" driuwt dy't faaks de wichtichste winst nei dizze platfoarms bringt. Hoe Kara Swisher yn 'e New York Times:
It is mooglik om digitale ynteraksjes te ûntwikkeljen sûnder haat en yntolerânsje út te lokjen. De reden dat de measte sosjale mediasites sa giftig lykje, is om't se boud binne foar snelheid, viraliteit en oandacht, ynstee fan ynhâld en krektens.
It soe wirklik spitich wêze as, yn in pear desennia, de ienige neilittenskip fan sosjale media de eroazje fan nuânse en passendheid yn it iepenbier diskusje wie.
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «";
- «".
Boarne: www.habr.com
