Poznámka. přel.: Tento článek, který se stal hitem Medium, je přehledem klíčových změn (2010–2019) ve světě programovacích jazyků a souvisejícího technologického ekosystému (se zvláštním zaměřením na Docker a Kubernetes). Jeho původní autorkou je Cindy Sridharan, která se specializuje na vývojářské nástroje a distribuované systémy – konkrétně napsala knihu „Distributed Systems Observability“ – a je v internetovém prostoru poměrně populární mezi IT specialisty, kteří se zajímají zejména o téma cloud nativní.
Když se rok 2019 blíží ke konci, chtěl jsem se podělit o své myšlenky na některé z nejdůležitějších technologických pokroků a inovací za poslední desetiletí. Navíc se pokusím nahlédnout trochu do budoucnosti a nastínit hlavní problémy a příležitosti nadcházející dekády.
Chci objasnit, že v tomto článku se nebudu zabývat změnami v oblastech, jako je datová věda (datová věda), umělá inteligence, frontend engineering atd., jelikož s nimi osobně nemám dostatečné zkušenosti.
Typizace vrací úder
Jedním z nejpozitivnějších trendů roku 2010 bylo oživení staticky typovaných jazyků. Takové jazyky však nikdy nezmizely (C++ a Java jsou dnes žádané; dominovaly před deseti lety), ale dynamicky typované jazyky (dynamika) zaznamenaly výrazný nárůst popularity po vzniku hnutí Ruby on Rails v roce 2005. . Tento růst vyvrcholil v roce 2009 s otevřeným zdrojem Node.js, díky kterému se Javascript-on-the-server stal realitou.
V průběhu času dynamické jazyky ztratily část své přitažlivosti v oblasti vytváření serverového softwaru. Jazyk Go, popularizovaný během kontejnerové revoluce, se zdál být vhodnější pro vytváření vysoce výkonných serverů s paralelním zpracováním a efektivním využíváním zdrojů (se kterými samotný tvůrce Node.js).
Rust, představený v roce 2010, zahrnoval pokroky v ve snaze stát se bezpečným a psaným jazykem. V první polovině dekády bylo přijetí Rustu v tomto odvětví spíše vlažné, ale jeho obliba v druhé polovině výrazně vzrostla. Pozoruhodné případy použití pro Rust zahrnují jeho použití pro , (mluvili jsme o tom v - Cca. překlad.), raný kompilátor WebAssembly od Fastly (nyní součást bytecodealliance) atd. Vzhledem k tomu, že Microsoft zvažuje možnost přepsání některých částí operačního systému Windows v Rust, lze s jistotou říci, že tento jazyk má ve dvacátých letech 2020. století jasnou budoucnost.
Dokonce i dynamické jazyky získaly nové funkce, jako je (volitelné typy). Poprvé byly implementovány v TypeScriptu, což je jazyk, který umožňuje vytvářet napsaný kód a kompilovat jej do JavaScriptu. PHP, Ruby a Python mají své vlastní volitelné systémy psaní (, ), které se úspěšně používají v .
Vrácení SQL do NoSQL
NoSQL je další technologie, která byla na začátku dekády mnohem populárnější než na konci. Myslím, že to má dva důvody.
Za prvé, model NoSQL s nedostatkem schématu, transakcí a slabšími zárukami konzistence se ukázal být obtížněji implementovatelný než model SQL. V s názvem „Proč byste měli preferovat silnou konzistenci, kdykoli je to možné“ (Proč byste měli zvolit silnou konzistenci, kdykoli je to možné) Google píše:
Jednou z věcí, které jsme se v Google naučili, je, že aplikační kód je jednodušší a doba vývoje je kratší, když se inženýři mohou spolehnout na stávající úložiště při zpracování složitých transakcí a udržování pořádku v datech. Abychom citovali původní dokumentaci Spanner: „Jsme přesvědčeni, že pro programátory je lepší řešit problémy s výkonem aplikací v důsledku zneužívání transakcí, když se objeví úzká místa, než mít neustále na paměti absenci transakcí.“
Druhým důvodem je nárůst „scale-out“ distribuovaných databází SQL (jako např и ) ve veřejném cloudovém prostoru, stejně jako alternativy Open Source, jako je CockroachDB (mluvíme o ní také - Cca. překlad.), které řeší mnoho technických problémů, které způsobily, že se tradiční databáze SQL „neškálovaly“. Dokonce i MongoDB, kdysi ztělesnění hnutí NoSQL, je nyní distribuované transakce.
Pro situace, které vyžadují atomické čtení a zápis do více dokumentů (v rámci jedné nebo více kolekcí), MongoDB podporuje transakce s více dokumenty. V případě distribuovaných transakcí lze transakce použít napříč více operacemi, kolekcemi, databázemi, dokumenty a fragmenty.
Totální streamování
Apache Kafka je bezesporu jedním z nejdůležitějších vynálezů posledního desetiletí. Jeho zdrojový kód byl otevřen v lednu 2011 a v průběhu let Kafka způsobil revoluci ve způsobu, jakým firmy pracují s daty. Kafka byl použit v každé společnosti, pro kterou jsem pracoval, od startupů po velké korporace. Záruky a případy použití, které poskytuje (pub-sub, streamy, architektury řízené událostmi), se používají v různých úkolech, od ukládání dat po monitorování a analýzu streamování, které jsou požadovány v mnoha oblastech, jako jsou finance, zdravotnictví, veřejný sektor, maloobchod atd.
Průběžná integrace (a v menší míře průběžné zavádění)
Kontinuální integrace se neobjevila v posledních 10 letech, ale v posledním desetiletí ano se rozšířila do takové míry, který se stal součástí standardního pracovního postupu (spouštět testy u všech požadavků na stažení). Zřízení GitHubu jako platformy pro vývoj a ukládání kódu, a co je důležitější, vývoj pracovního postupu založeného na znamená, že spuštění testů před přijetím požadavku na vytažení na master je jediný pracovní postup ve vývoji, známý inženýrům, kteří zahájili svou kariéru v posledních deseti letech.
Nepřetržité zavádění (nasazení každého odevzdání, jakmile narazí na hlavní server) není tak rozšířené jako průběžná integrace. Avšak s množstvím různých cloudových API pro nasazení, rostoucí popularitou platforem jako Kubernetes (které poskytují standardizované API pro nasazení) a vznikem multiplatformních, multi-cloudových nástrojů, jako je Spinnaker (postavený nad těmi standardizovanými). API), procesy nasazení se staly automatičtějšími, efektivnějšími a obecně bezpečnějšími.
kontejnery
Kontejnery jsou možná nejvíce medializovanou, diskutovanou, inzerovanou a nepochopenou technologií roku 2010. Na druhou stranu jde o jednu z nejdůležitějších novinek předchozí dekády. Část důvodu této kakofonie spočívá ve smíšených signálech, které jsme přijímali téměř odkudkoli. Nyní, když humbuk trochu utichl, některé věci se dostaly do ostřejšího zaměření.
Kontejnery se staly populární ne proto, že jsou nejlepším způsobem, jak spustit aplikaci, která uspokojí potřeby globální vývojářské komunity. Kontejnery se staly populární, protože úspěšně zapadly do marketingového požadavku na určitý nástroj, který řeší úplně jiný problém. Ukázalo se, že Docker je fantastický vývojový nástroj, který řeší naléhavý problém s kompatibilitou („funguje na mém počítači“).
Přesněji řečeno, revoluce byla provedena Obrázek dockeru, protože vyřešil problém parity mezi prostředími a poskytl skutečnou přenositelnost nejen aplikačního souboru, ale také všech jeho softwarových a provozních závislostí. Skutečnost, že tento nástroj nějakým způsobem podnítil popularitu „kontejnerů“, které jsou v podstatě implementačním detailem na velmi nízké úrovni, pro mě zůstává možná hlavní záhadou posledního desetiletí.
Serverless
Vsadil bych se, že nástup „bezserverového“ počítání je ještě důležitější než kontejnery, protože skutečně mění sen o počítání na vyžádání ve skutečnost. (On-demand). Za posledních pět let jsem viděl, jak se bezserverový přístup postupně rozšiřuje o podporu nových jazyků a běhových prostředí. Vznik produktů jako Azure Durable Functions se zdá být správným krokem k implementaci stavových funkcí (současně rozhodujícím související s omezeními FaaS). Se zájmem budu sledovat, jak se toto nové paradigma vyvine v následujících letech.
Automatizace
Snad největším přínosem z tohoto trendu je komunita provozních inženýrů, protože umožnila, aby se koncepty jako infrastruktura jako kód (IaC) staly realitou. Kromě toho se vášeň pro automatizaci shodovala se vzestupem „kultury SRE“, jejímž cílem je zaujmout přístup k operacím více zaměřený na software.
Univerzální API-fikce
Další zajímavou vlastností poslední dekády byla API-fikace různých vývojových úloh. Dobrá, flexibilní rozhraní API umožňují vývojářům vytvářet inovativní pracovní postupy a nástroje, které zase pomáhají s údržbou a zlepšují uživatelskou zkušenost.
Kromě toho je API-fikace prvním krokem k SaaS-fikaci některé funkce nebo nástroje. Tento trend se také shodoval s nárůstem popularity mikroslužeb: SaaS se stal jen další službou, ke které lze přistupovat přes API. Nyní je k dispozici mnoho nástrojů SaaS a FOSS v oblastech, jako je monitorování, platby, vyrovnávání zátěže, nepřetržitá integrace, upozornění, přepínání funkcí (označení funkce), CDN, dopravní inženýrství (např. DNS) atd., které v posledním desetiletí vzkvétaly.
pozorovatelnost
Stojí za zmínku, že dnes máme přístup k mnohem pokročilejší nástroje pro sledování a diagnostiku chování aplikací než kdykoli předtím. Lze snad nazvat monitorovací systém Prometheus, který v roce 2015 získal status Open Source nejlepší monitorovací systém od těch, se kterými jsem pracoval. Není to dokonalé, ale značné množství věcí je implementováno přesně správným způsobem (například podpora měření [rozměrnost] v případě metrik).
Distribuované sledování bylo další technologií, která vstoupila do hlavního proudu v roce 2010 díky iniciativám, jako je OpenTracing (a jeho nástupce OpenTelemetry). Ačkoli je sledování stále poměrně obtížné aplikovat, některé z nejnovějších vývojů dávají naději, že jeho skutečný potenciál odemkneme v roce 2020. (Poznámka: Přečtěte si také na našem blogu překlad článku “"od stejného autora.)
Pohled do budoucnosti
Bohužel existuje mnoho bolestivých bodů, které čekají na vyřešení v nadcházejícím desetiletí. Zde jsou mé myšlenky na ně a některé potenciální nápady, jak se jich zbavit.
Řešení problému Moorova zákona
Konec Dennardova škálovacího zákona a zpoždění za Moorovým zákonem vyžadují nové inovace. John Hennessy dovnitř vysvětluje, proč problémoví závislí (specifická pro doménu) architektury jako TPU mohou být jedním z řešení problému zaostávání za Moorovým zákonem. Sady nástrojů jako od Google se již zdá být dobrým krokem v tomto směru:
Kompilátory musí podporovat nové aplikace, musí být snadno portovatelné na nový hardware, propojovat více vrstev abstrakce od dynamických, spravovaných jazyků po vektorové akcelerátory a softwarově řízená úložná zařízení a zároveň poskytovat vysokoúrovňové přepínače pro automatické ladění, které poskytují pouze- ve funkcionalitě -time, diagnostice a distribuci ladicích informací o fungování a výkonu systémů v rámci zásobníku, přičemž ve většině případů poskytuje výkon, který se přiměřeně blíží ručně psanému assembleru. Máme v úmyslu sdílet naši vizi, pokrok a plány rozvoje a veřejné dostupnosti takovéto kompilační infrastruktury.
CI / CD
Zatímco vzestup CI se stal jedním z největších trendů roku 2010, Jenkins je stále zlatým standardem pro CI.
Tento prostor nutně potřebuje inovace v následujících oblastech:
- uživatelské rozhraní (DSL pro kódovací testovací specifikace);
- implementační detaily, díky nimž bude skutečně škálovatelný a rychlý;
- integrace s různými prostředími (staging, prod atd.) pro implementaci pokročilejších forem testování;
- průběžné testování a nasazení.
Vývojářské nástroje
Jako průmysl jsme začali vytvářet stále složitější a působivější software. Pokud však jde o naše vlastní nástroje, situace by mohla být mnohem lepší.
Kolaborativní a vzdálená (přes ssh) editace si získala určitou oblibu, ale nikdy se nestala novým standardním způsobem vývoje. Pokud, stejně jako já, odmítáte samotnou myšlenku nezbytnost trvalé připojení k internetu jen proto, abyste mohli programovat, pak vám práce přes ssh na vzdáleném počítači pravděpodobně nebude vyhovovat.
Místní vývojová prostředí, zejména pro inženýry pracující na velkých architekturách orientovaných na služby, jsou stále výzvou. Některé projekty se to snaží řešit a zajímalo by mě, jak by vypadalo nejergonomičtější UX pro daný případ použití.
Bylo by také zajímavé rozšířit koncept „přenosných prostředí“ do dalších oblastí vývoje jako je reprodukce chyb (resp. ), které se vyskytují za určitých podmínek nebo nastavení.
Také bych rád viděl více inovací v oblastech, jako je sémantické a kontextové vyhledávání kódu, nástroje pro korelaci produkčních incidentů s konkrétními částmi kódové základny atd.
Computing (budoucnost PaaS)
Po humbuku kolem kontejnerů a bez serverů v roce 2010 se řada řešení ve veřejném cloudovém prostoru v posledních několika letech výrazně rozšířila.
To vyvolává několik zajímavých otázek. Za prvé, seznam dostupných možností ve veřejném cloudu neustále roste. Poskytovatelé cloudových služeb mají personál a zdroje, aby mohli snadno držet krok s nejnovějším vývojem ve světě Open Source a vydávat produkty, jako jsou „bezserverové moduly“ (tuším jednoduše tím, že vytvoří jejich vlastní běhové prostředí FaaS kompatibilní s OCI) nebo jiné podobné vymyšlené věci.
Těm, kteří tato cloudová řešení využívají, lze jen závidět. Teoreticky cloudové nabídky Kubernetes (GKE, EKS, EKS na Fargate atd.) poskytují API pro spouštění úloh nezávislá na cloudovém poskytovateli. Pokud používáte podobné produkty (ECS, Fargate, Google Cloud Run atd.), pravděpodobně již využíváte ty nejzajímavější funkce, které poskytovatel služby nabízí. Navíc, jak se objevují nové produkty nebo výpočetní paradigmata, migrace bude pravděpodobně jednoduchá a bez stresu.
Vzhledem k tomu, jak rychle se nabídka takových řešení vyvíjí (budu velmi překvapen, pokud se v blízké budoucnosti neobjeví několik nových možností), malé „platformové“ týmy (týmy spojené s infrastrukturou a odpovědné za vytváření on-premise platforem pro společnosti provozující pracovní zátěž) bude neuvěřitelně obtížné konkurovat, pokud jde o funkčnost, snadnost použití a celkovou spolehlivost. Rok 2010 viděl Kubernetes jako nástroj pro budování PaaS (platforma jako služba), takže se mi zdá zcela zbytečné stavět na Kubernetes interní platformu, která nabízí stejný výběr, jednoduchost a svobodu dostupnou pro veřejnost. cloudový prostor. Rámování PaaS založené na kontejnerech jako „strategie Kubernetes“ se rovná záměrnému vyhýbání se nejinovativnějším možnostem cloudu.
Pokud se podíváte na dostupné dnes výpočetních schopností, je zřejmé, že vytváření vlastního PaaS založeného výhradně na Kubernetes se rovná zamačkávání se do kouta (není to příliš pokrokový přístup, co?). I když se dnes někdo rozhodne postavit kontejnerové PaaS na Kubernetes, za pár let bude ve srovnání s cloudovými možnostmi vypadat zastarale. Přestože Kubernetes začínal jako open source projekt, jeho předchůdcem a inspirací je interní nástroj Google. Původně však byl vyvinut na počátku/v polovině roku 2000, kdy byla počítačová krajina zcela odlišná.
Ve velmi širokém slova smyslu se společnosti také nemusí stát odborníky na provoz clusteru Kubernetes, ani nevybudují a neudržují svá vlastní datová centra. Poskytování spolehlivého výpočetního základu je klíčovou výzvou poskytovatelé cloudových služeb.
Konečně mám pocit, že jsme jako průmysl trochu ustoupili interakční zkušenost (). Heroku bylo uvedeno na trh v roce 2007 a stále je jedním z nejvíce snadné použití platformy. Nelze popřít, že Kubernetes je mnohem výkonnější, rozšiřitelný a programovatelný, ale chybí mi, jak snadné je začít a nasadit do Heroku. Chcete-li používat tuto platformu, musíte znát pouze Git.
To vše mě vede k následujícímu závěru: potřebujeme, aby fungovaly lepší abstrakce vyšší úrovně (to platí zejména pro abstrakce nejvyšší úrovně).
Správné API na nejvyšší úrovni
Docker je skvělým příkladem potřeby lepšího oddělení obav zároveň správná implementace API nejvyšší úrovně.
Problém s Dockerem je, že (alespoň) zpočátku měl projekt příliš široké cíle: to vše kvůli vyřešení problému kompatibility („funguje na mém počítači“) pomocí technologie kontejnerů. Docker byl obrazový formát, běhové prostředí s vlastní virtuální sítí, nástroj CLI, démon běžící jako root a mnoho dalšího. V každém případě výměna zpráv byla více matoucí, nemluvě o „odlehčených virtuálních počítačích“, cgroups, jmenných prostorech, četných bezpečnostních problémech a funkcích smíchaných s marketingovým voláním „vytvářet, dodávat, spouštět jakoukoli aplikaci kdekoli“.
Jako u všech dobrých abstrakcí je potřeba času (a zkušeností a bolesti), než rozložit různé problémy do logických vrstev, které lze vzájemně kombinovat. Bohužel, než mohl Docker dosáhnout podobné zralosti, vstoupil do boje Kubernetes. To monopolizovalo cyklus humbuku natolik, že se nyní všichni snažili držet krok se změnami v ekosystému Kubernetes a ekosystém kontejnerů získal druhotný status.
Kubernetes sdílí mnoho stejných problémů jako Docker. Přes všechny ty řeči o cool a složitelné abstrakci, rozdělení různých úkolů do vrstev nepříliš dobře zapouzdřeno. Ve svém jádru je to kontejnerový orchestrátor, který spouští kontejnery na clusteru různých strojů. Jedná se o poměrně nízkoúrovňový úkol, který lze použít pouze pro inženýry obsluhující cluster. Na druhou stranu, Kubernetes je také abstrakce nejvyšší úrovně, nástroj CLI, se kterým uživatelé komunikují prostřednictvím YAML.
Docker byl (a stále je) chladný vývojový nástroj, přes všechny jeho nedostatky. Ve snaze držet krok se všemi „zajíci“ najednou se jeho vývojářům podařilo správně implementovat abstrakce na nejvyšší úrovni. Mám na mysli abstrakci na nejvyšší úrovni podmnožina funkce, která cílové publikum (v tomto případě vývojáři, kteří trávili většinu času ve svém místním vývojovém prostředí) skutečně zajímala a která fungovala skvěle hned po vybalení.
Dockerfile a nástroj CLI docker by měl být příkladem toho, jak vybudovat dobrou „uživatelskou zkušenost na nejvyšší úrovni“. Běžný vývojář může začít pracovat s Dockerem, aniž by věděl cokoli o složitosti implementace, které přispívají k provozním zkušenostemjako jmenné prostory, cgroups, limity paměti a CPU atd. Nakonec se psaní Dockerfile příliš neliší od psaní shellového skriptu.
Kubernetes je určen pro různé cílové skupiny:
- správci clusteru;
- softwaroví inženýři pracující na problémech s infrastrukturou, rozšiřující možnosti Kubernetes a vytváření platforem na něm založených;
- koncoví uživatelé interagující s Kubernetes prostřednictvím
kubectl.
Přístup Kubernetes „jedno API vyhovuje všem“ představuje nedostatečně zapouzdřenou „horu složitosti“ bez návodu, jak jej škálovat. To vše vede k neoprávněně protahované trajektorii učení. Jak Adam Jacob, „Docker přinesl transformativní uživatelský zážitek, který nebyl nikdy překonán. Zeptejte se kohokoli, kdo používá K8, jestli si přeje, aby fungoval jako jejich první docker run. Odpověď bude ano":
Tvrdil bych, že většina infrastrukturních technologií je dnes příliš nízkoúrovňová (a proto je považována za „příliš složitou“). Kubernetes je implementován na poměrně nízké úrovni. Distribuované trasování v jeho (mnoho polí sešitých dohromady, aby vytvořilo traceview) je také implementováno na příliš nízké úrovni. Vývojářské nástroje, které implementují „abstrakce nejvyšší úrovně“, bývají nejúspěšnější. Tento závěr platí v překvapivém počtu případů (pokud je technologie příliš složitá nebo obtížně použitelná, pak „nejvyšší úroveň API/UI“ pro tuto technologii musí být teprve objevena).
Právě teď je cloudový nativní ekosystém matoucí kvůli svému nízkoúrovňovému zaměření. Jako průmysl musíme inovovat, experimentovat a vzdělávat se v tom, jak vypadá správná úroveň „maximální, nejvyšší abstrakce“.
Maloobchod
V roce 2010 zůstal digitální maloobchodní zážitek z velké části nezměněn. Na jedné straně měla snadnost online nakupování zasáhnout tradiční maloobchodní prodejny, na straně druhé se online nakupování v podstatě za desetiletí téměř nezměnilo.
I když nemám žádné konkrétní myšlenky na to, jak se toto odvětví bude vyvíjet v příštím desetiletí, byl bych velmi zklamán, kdybychom v roce 2030 nakupovali stejným způsobem jako v roce 2020.
Žurnalistika
Jsem stále více rozčarován stavem globální žurnalistiky. Je stále obtížnější najít nezaujaté zpravodajské zdroje, které informují objektivně a pečlivě. Velmi často se stírá hranice mezi samotnými zprávami a názory na ně. Informace jsou zpravidla prezentovány neobjektivním způsobem. To platí zejména v některých zemích, kde historicky neexistovalo oddělení zpráv a názorů. V nedávném článku zveřejněném po posledních všeobecných volbách ve Spojeném království Alan Rusbridger, bývalý redaktor The Guardian, :
Jde hlavně o to, že jsem se dlouhá léta díval do amerických novin a litoval jsem tamních kolegů, kteří byli výhradně zodpovědní za zprávy a komentáře přenechávali úplně jiným lidem. Soucit se však postupem času změnil v závist. Nyní si myslím, že všechny britské národní noviny by měly oddělit svou odpovědnost za zprávy od odpovědnosti za komentáře. Pro běžného čtenáře – zejména pro online čtenáře – je bohužel příliš obtížné tento rozdíl rozeznat.
Vzhledem k dosti pochybné pověsti Silicon Valley, pokud jde o etiku, bych nikdy nevěřil technologiím, že „revolucionizují“ žurnalistiku. Jak již bylo řečeno, já (a mnoho mých přátel) bych byl rád, kdyby existoval nestranný, nezaujatý a důvěryhodný zdroj zpráv. I když netuším, jak by taková platforma mohla vypadat, jsem si jist, že v době, kdy je stále obtížnější rozeznat pravdu, je potřeba poctivé žurnalistiky větší než kdy jindy.
Sociální sítě
Sociální média a komunitní zpravodajské platformy jsou primárním zdrojem informací pro mnoho lidí na celém světě a nedostatek přesnosti a neochota některých platforem provádět i základní ověřování faktů vedly ke katastrofálním následkům, jako je genocida, vměšování do voleb a další. .
Sociální média jsou také nejmocnějším mediálním nástrojem, který kdy existoval. Radikálně změnili politickou praxi. Změnili reklamu. Změnili popkulturu (například hlavní příspěvek k rozvoji tzv. zrušení kultury [kultury ostrakismu - cca. překlad] sociální sítě přispívají). Kritici tvrdí, že sociální média se ukázala jako úrodná půda pro rychlé a vrtošivé změny v morálních hodnotách, ale také poskytla členům marginalizovaných skupin příležitost organizovat se způsoby, které nikdy předtím neměli. Sociální média v podstatě změnila způsob, jakým lidé komunikují a vyjadřují se v 21. století.
Jsem však také přesvědčen, že sociální média přinášejí ty nejhorší lidské impulsy. Ohleduplnost a ohleduplnost jsou často opomíjeny ve prospěch popularity a je téměř nemožné vyjádřit odůvodněný nesouhlas s určitými názory a postoji. Polarizace se často vymkne kontrole, což vede k tomu, že veřejnost jednoduše neslyší individuální názory, zatímco absolutisté kontrolují otázky online etikety a přijatelnosti.
Zajímalo by mě, zda je možné vytvořit „lepší“ platformu, která podporuje kvalitnější diskuse? Koneckonců je to právě to, co pohání „angažovanost“, co těmto platformám často přináší hlavní zisk. Jak Kara Swisher v New York Times:
Je možné rozvíjet digitální interakce, aniž by to vyvolalo nenávist a nesnášenlivost. Důvodem, proč se většina stránek sociálních médií jeví tak toxických, je to, že byly vytvořeny pro rychlost, viralitu a pozornost, spíše než pro obsah a přesnost.
Bylo by opravdu nešťastné, kdyby za pár desetiletí bylo jediným dědictvím sociálních médií eroze nuancí a vhodnosti ve veřejném diskurzu.
PS od překladatele
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com