Notatka. przeł.: Artykuł, który stał się hitem na Medium, stanowi przegląd kluczowych (2010-2019) zmian w świecie języków programowania i związanego z nimi ekosystemu technologicznego (ze szczególnym uwzględnieniem Dockera i Kubernetesa). Jego oryginalną autorką jest Cindy Sridharan, która specjalizuje się w narzędziach deweloperskich i systemach rozproszonych – w szczególności napisała książkę „Distributed Systems Observability” – i jest dość popularna w przestrzeni internetowej wśród specjalistów IT, szczególnie zainteresowanych tematem cloud native.
Gdy rok 2019 dobiega końca, chciałem podzielić się przemyśleniami na temat niektórych najważniejszych postępów technologicznych i innowacji ostatniej dekady. Ponadto postaram się spojrzeć trochę w przyszłość i nakreślić główne problemy i szanse nadchodzącej dekady.
Chcę wyraźnie zaznaczyć, że w tym artykule nie omawiam zmian w obszarach takich jak data science (nauka o danych), sztuczna inteligencja, inżynieria frontendowa itp., gdyż osobiście nie mam w nich wystarczającego doświadczenia.
Typizacja kontratakuje
Jednym z najbardziej pozytywnych trendów 2010 roku było odrodzenie języków z typem statycznym. Jednak takie języki nigdy nie zniknęły (dziś jest popyt na C++ i Java; dominowały dziesięć lat temu), ale języki dynamicznie typowane (dynamika) odnotowały znaczny wzrost popularności po pojawieniu się ruchu Ruby on Rails w 2005 roku . Wzrost ten osiągnął szczyt w 2009 r. wraz z pojawieniem się otwartego kodu źródłowego Node.js, dzięki któremu JavaScript na serwerze stał się rzeczywistością.
Z biegiem czasu języki dynamiczne straciły część swojej atrakcyjności w dziedzinie tworzenia oprogramowania serwerowego. Język Go, spopularyzowany podczas rewolucji kontenerowej, wydawał się lepiej przystosowany do tworzenia wydajnych, zasobooszczędnych serwerów z przetwarzaniem równoległym (z którymi sam twórca Node.js).
Rust, wprowadzony w 2010 roku, obejmował postępy w próbując stać się bezpiecznym językiem maszynowym. W pierwszej połowie dekady odbiór Rusta w branży był raczej letni, jednak w drugiej połowie jego popularność znacząco wzrosła. Godne uwagi przypadki użycia Rusta obejmują jego użycie dla , (rozmawialiśmy o tym w - około. tłumacz.), wczesny kompilator WebAssembly od Fastly (obecnie część bytecodealliance) itp. Biorąc pod uwagę, że Microsoft rozważa możliwość przepisania niektórych części systemu operacyjnego Windows w języku Rust, można śmiało powiedzieć, że język ten ma przed sobą świetlaną przyszłość w latach 2020. XX wieku.
Nawet języki dynamiczne otrzymały nowe funkcje, takie jak (opcjonalne typy). Po raz pierwszy zaimplementowano je w TypeScript, języku umożliwiającym tworzenie kodu maszynowego i kompilowanie go do kodu JavaScript. PHP, Ruby i Python mają własne opcjonalne systemy pisania (, ), które z powodzeniem stosuje się w .
Powrót SQL do NoSQL
NoSQL to kolejna technologia, która na początku dekady cieszyła się znacznie większą popularnością niż pod koniec. Myślę, że są ku temu dwa powody.
Po pierwsze, model NoSQL, ze względu na brak schematów, transakcji i słabsze gwarancje spójności, okazał się trudniejszy do wdrożenia niż model SQL. W z tytułem „Dlaczego warto preferować mocną konsystencję, gdy tylko jest to możliwe” (Dlaczego powinieneś wybierać mocną konsystencję, jeśli to możliwe) Google pisze:
Jedną z rzeczy, których nauczyliśmy się w Google, jest to, że kod aplikacji jest prostszy, a czas programowania krótszy, gdy inżynierowie mogą polegać na istniejącej pamięci masowej do obsługi złożonych transakcji i utrzymywania porządku danych. Cytując oryginalną dokumentację Spannera: „Uważamy, że lepiej, aby programiści radzili sobie z problemami z wydajnością aplikacji wynikającymi z nadużyć w transakcjach w miarę pojawiania się wąskich gardeł, niż stale pamiętali o braku transakcji”.
Drugi powód wynika ze wzrostu liczby rozproszonych baz danych SQL „skalowanych w poziomie” (takich jak и ) w przestrzeni chmury publicznej, a także alternatywy typu Open Source, takie jak CockroachDB (o niej też mówimy - około. tłumacz.), które rozwiązują wiele problemów technicznych, które powodowały, że tradycyjne bazy danych SQL „nie skalowały się”. Nawet MongoDB, niegdyś uosobienie ruchu NoSQL, jest teraz transakcje rozproszone.
W sytuacjach, które wymagają niepodzielnych odczytów i zapisów w wielu dokumentach (w jednej lub większej liczbie kolekcji), MongoDB obsługuje transakcje obejmujące wiele dokumentów. W przypadku transakcji rozproszonych transakcje mogą być wykorzystywane w wielu operacjach, kolekcjach, bazach danych, dokumentach i fragmentach.
Totalne przesyłanie strumieniowe
Apache Kafka to bez wątpienia jeden z najważniejszych wynalazków ostatniej dekady. Jego kod źródłowy został otwarty w styczniu 2011 roku i na przestrzeni lat Kafka zrewolucjonizował sposób, w jaki firmy pracują z danymi. Kafka była wykorzystywana w każdej firmie, w której pracowałem, od startupów po duże korporacje. Gwarancje i przypadki użycia, które zapewnia (pub-sub, strumienie, architektury sterowane zdarzeniami) są wykorzystywane w różnych zadaniach, od przechowywania danych po monitorowanie i analitykę przesyłania strumieniowego, co jest pożądane w wielu obszarach, takich jak finanse, opieka zdrowotna, sektor publiczny, sprzedaż detaliczna itp.
Ciągła integracja (i w mniejszym stopniu ciągłe wdrażanie)
Integracja ciągła nie pojawiła się w ciągu ostatnich 10 lat, ale w ciągu ostatniej dekady rozprzestrzeniło się do takiego stopnia, który stał się częścią standardowego przepływu pracy (uruchamiaj testy na wszystkich żądaniach ściągnięcia). Utworzenie GitHuba jako platformy do tworzenia i przechowywania kodu oraz, co ważniejsze, rozwijania przepływu pracy w oparciu o oznacza, że uruchomienie testów przed zaakceptowaniem żądania ściągnięcia do mastera jest pojedynczy przepływ pracy w rozwoju, znany inżynierom, którzy rozpoczynali karierę w ciągu ostatnich dziesięciu lat.
Ciągłe wdrażanie (wdrażanie każdego zatwierdzenia w momencie, gdy trafi ono do wzorca) nie jest tak powszechne jak ciągła integracja. Jednakże wraz z mnóstwem różnych interfejsów API chmury do wdrożenia, rosnącą popularnością platform takich jak Kubernetes (które zapewniają ustandaryzowane API do wdrożeń) oraz pojawieniem się wieloplatformowych narzędzi obsługujących wiele chmur, takich jak Spinnaker (zbudowanych na bazie standardowych narzędzi API), procesy wdrażania stały się bardziej zautomatyzowane, usprawnione i ogólnie bezpieczniejsze.
pojemniki
Kontenery to prawdopodobnie najbardziej popularna, dyskutowana, reklamowana i niezrozumiała technologia 2010 roku. Z drugiej strony jest to jedna z najważniejszych innowacji poprzedniej dekady. Jedną z przyczyn całej tej kakofonii są mieszane sygnały, które otrzymywaliśmy niemal zewsząd. Teraz, gdy szum nieco ucichł, niektóre rzeczy nabrały większej ostrości.
Kontenery stały się popularne nie dlatego, że są najlepszym sposobem na uruchomienie aplikacji, która zaspokaja potrzeby globalnej społeczności programistów. Kontenery stały się popularne, ponieważ z powodzeniem wpasowały się w zapytanie marketingowe dotyczące określonego narzędzia, które rozwiązuje zupełnie inny problem. Okazało się, że Docker fantastyczny narzędzie programistyczne, które rozwiązuje palący problem kompatybilności („działa na moim komputerze”).
Dokładniej, rewolucja się dokonała Obraz Dockera, ponieważ rozwiązał problem parzystości pomiędzy środowiskami i zapewnił prawdziwą przenośność nie tylko pliku aplikacji, ale także całego jej oprogramowania i zależności operacyjnych. Fakt, że to narzędzie w jakiś sposób przyczyniło się do popularności „kontenerów”, które w zasadzie są szczegółami implementacji na bardzo niskim poziomie, pozostaje dla mnie być może główną tajemnicą ostatniej dekady.
Bezserwerowe
Założę się, że pojawienie się przetwarzania „bezserwerowego” jest nawet ważniejsze niż kontenery, ponieważ naprawdę urzeczywistnia marzenie o przetwarzaniu na żądanie (Na żądanie). W ciągu ostatnich pięciu lat widziałem, jak podejście bezserwerowe stopniowo rozszerzało się, dodając obsługę nowych języków i środowisk wykonawczych. Pojawienie się takich produktów jak Azure Durable Functions wydaje się właściwym krokiem w kierunku wdrożenia funkcji stanowych (jednocześnie decydującym związane z ograniczeniami FaaS). Z zainteresowaniem będę obserwował, jak w nadchodzących latach będzie się rozwijał ten nowy paradygmat.
Automatyzacja
Być może największym beneficjentem tego trendu jest społeczność inżynierów operacyjnych, ponieważ umożliwiła ona urzeczywistnienie koncepcji takich jak infrastruktura jako kod (IaC). Ponadto pasja do automatyzacji zbiegła się z powstaniem „kultury SRE”, której celem jest przyjęcie bardziej zorientowanego na oprogramowanie podejścia do operacji.
Uniwersalna fikcja API
Inną interesującą cechą ostatniej dekady była funkcja API różnych zadań programistycznych. Dobre, elastyczne interfejsy API pozwalają programiście tworzyć innowacyjne przepływy pracy i narzędzia, które z kolei pomagają w utrzymaniu i poprawiają doświadczenie użytkownika.
Ponadto, API-fikacja jest pierwszym krokiem w kierunku SaaS-fikacji jakiejś funkcjonalności lub narzędzia. Trend ten zbiegł się także ze wzrostem popularności mikroserwisów: SaaS stał się kolejną usługą, do której można uzyskać dostęp poprzez API. Obecnie dostępnych jest wiele narzędzi SaaS i FOSS w obszarach takich jak monitorowanie, płatności, równoważenie obciążenia, ciągła integracja, alerty, przełączanie funkcji (oznaczanie funkcji), CDN, inżynieria ruchu (np. DNS) itp., które rozwinęły się w ciągu ostatniej dekady.
Obserwowalność
Warto zauważyć, że dziś mamy dostęp do znacznie bardziej zaawansowany narzędzia do monitorowania i diagnozowania zachowania aplikacji niż kiedykolwiek wcześniej. Można chyba nazwać system monitorowania Prometheus, który w 2015 roku otrzymał status Open Source najlepszy systemu monitorowania od tych, z którymi współpracowałem. Nie jest idealnie, ale znaczna część rzeczy jest zaimplementowana dokładnie tak, jak należy (np. obsługa pomiarów [wymiarowość] w przypadku metryk).
Śledzenie rozproszone to kolejna technologia, która weszła do głównego nurtu w 2010 roku dzięki inicjatywom takim jak OpenTracing (i jego następca OpenTelemetry). Chociaż śledzenie jest nadal dość trudne w zastosowaniu, niektóre z najnowszych osiągnięć dają nadzieję, że uwolnimy jego prawdziwy potencjał w latach 2020. XXI wieku. (Uwaga: przeczytaj także na naszym blogu tłumaczenie artykułu „„tego samego autora.)
Patrząc w przyszłość
Niestety, istnieje wiele bolączek, które czekają na rozwiązanie w nadchodzącej dekadzie. Oto moje przemyślenia na ich temat i kilka potencjalnych pomysłów, jak się ich pozbyć.
Rozwiązanie problemu prawa Moore’a
Koniec prawa skalowania Dennarda i opóźnienie w stosunku do prawa Moore'a wymagają nowych innowacji. Johna Hennessy’ego w wyjaśnia, dlaczego problemowi uzależnieni (specyficzne dla domeny) architektury takie jak TPU mogą być jednym z rozwiązań problemu opóźnień w stosunku do prawa Moore'a. Zestawy narzędzi takie jak od Google już wydają się być dobrym krokiem naprzód w tym kierunku:
Kompilatory muszą obsługiwać nowe aplikacje, być łatwo przenoszone na nowy sprzęt, łączyć wiele warstw abstrakcji, od dynamicznych, zarządzanych języków po akceleratory wektorowe i urządzenia pamięci sterowane programowo, zapewniając jednocześnie przełączniki wysokiego poziomu do automatycznego dostrajania, zapewniając po prostu- w zakresie funkcjonalności -czas, diagnostyka i dystrybucja informacji debugowania o działaniu i wydajności systemów na całym stosie, przy jednoczesnym zapewnieniu w większości przypadków wydajności zbliżonej do ręcznie napisanego asemblera. Zamierzamy podzielić się naszą wizją, postępem i planami rozwoju i publicznej dostępności takiej infrastruktury kompilacji.
CI / CD
Chociaż rozwój CI stał się jednym z największych trendów 2010 roku, Jenkins nadal pozostaje złotym standardem dla CI.
Przestrzeń ta pilnie potrzebuje innowacji w następujących obszarach:
- interfejs użytkownika (DSL do kodowania specyfikacji testowych);
- szczegóły wdrożenia, które sprawią, że będzie on naprawdę skalowalny i szybki;
- integracja z różnymi środowiskami (staging, prod itp.) w celu realizacji bardziej zaawansowanych form testowania;
- ciągłe testowanie i wdrażanie.
Narzędzia deweloperskie
Jako branża zaczęliśmy tworzyć coraz bardziej złożone i imponujące oprogramowanie. Jeśli jednak chodzi o narzędzia własne, sytuacja mogłaby być znacznie lepsza.
Wspólna i zdalna edycja (przez ssh) zyskała pewną popularność, ale nigdy nie stała się nowym standardowym sposobem programowania. Jeśli tak jak ja odrzucisz samą ideę konieczność jeśli masz stałe połączenie z Internetem tylko po to, aby móc programować, wówczas praca przez ssh na zdalnym komputerze raczej nie będzie dla Ciebie odpowiednia.
Lokalne środowiska programistyczne, zwłaszcza dla inżynierów pracujących nad dużymi architekturami zorientowanymi na usługi, nadal stanowią wyzwanie. Niektóre projekty próbują rozwiązać ten problem i chciałbym wiedzieć, jak wyglądałby najbardziej ergonomiczny UX w danym przypadku użycia.
Interesujące byłoby również rozszerzenie koncepcji „środowisk przenośnych” na inne obszary rozwoju, takie jak reprodukcja błędów (lub ), które występują w określonych warunkach lub ustawieniach.
Chciałbym także zobaczyć więcej innowacji w obszarach takich jak semantyczne i kontekstowe wyszukiwanie kodu, narzędzia do korelowania incydentów produkcyjnych z określonymi częściami bazy kodu itp.
Informatyka (przyszłość PaaS)
Podążając za szumem wokół kontenerów i rozwiązań bezserwerowych, jaki miał miejsce w 2010 roku, w ciągu ostatnich kilku lat znacznie rozszerzyła się gama rozwiązań w przestrzeni chmury publicznej.
Rodzi to kilka interesujących pytań. Przede wszystkim lista dostępnych opcji w chmurze publicznej stale się powiększa. Dostawcy usług w chmurze dysponują personelem i zasobami, aby z łatwością nadążać za najnowszymi osiągnięciami w świecie Open Source i udostępniać produkty takie jak „bezserwerowe moduły” (podejrzewam, że po prostu zapewniają zgodność własnych środowisk wykonawczych FaaS z OCI) lub inne podobne fantazyjne rzeczy.
Można tylko pozazdrościć tym, którzy korzystają z takich rozwiązań chmurowych. Teoretycznie oferty chmur Kubernetes (GKE, EKS, EKS w Fargate itp.) zapewniają niezależne od dostawcy chmury interfejsy API do uruchamiania obciążeń. Jeśli korzystasz z podobnych produktów (ECS, Fargate, Google Cloud Run itp.), prawdopodobnie korzystasz już z najciekawszych funkcji oferowanych przez usługodawcę. Ponadto w miarę pojawiania się nowych produktów lub paradygmatów obliczeniowych migracja będzie prawdopodobnie prosta i bezstresowa.
Biorąc pod uwagę, jak szybko ewoluuje oferta tego typu rozwiązań (będę bardzo zaskoczony, jeśli w najbliższym czasie nie pojawi się kilka nowych opcji), małe zespoły „platformowe” (zespoły związane z infrastrukturą i odpowiedzialne za tworzenie platform on-premise dla firmy obsługujące obciążenia) będą niezwykle trudne do konkurowania pod względem funkcjonalności, łatwości obsługi i ogólnej niezawodności. W latach 2010-tych Kubernetes był postrzegany jako narzędzie do budowania PaaS (platforma jako usługa), dlatego wydaje mi się całkowicie bezcelowe budowanie wewnętrznej platformy na Kubernetesie, która oferuje ten sam wybór, prostotę i swobodę dostępne publicznie przestrzeń chmur. Traktowanie PaaS opartego na kontenerach jako „strategii Kubernetes” jest równoznaczne ze świadomym unikaniem najbardziej innowacyjnych możliwości chmury.
Jeśli spojrzysz na dostępne dzisiaj mocy obliczeniowych staje się oczywiste, że stworzenie własnego PaaS w oparciu wyłącznie o Kubernetes jest równoznaczne z zakopaniem się w kąt (niezbyt przyszłościowe podejście, co?). Nawet jeśli ktoś dzisiaj zdecyduje się na budowę kontenerowego PaaS na Kubernetesie, za kilka lat będzie on wyglądał na przestarzały w porównaniu z możliwościami chmury. Chociaż Kubernetes zaczynał jako projekt open source, jego przodkiem i inspiracją jest wewnętrzne narzędzie Google. Jednak pierwotnie został opracowany na początku/połowie 2000 roku, kiedy krajobraz komputerowy był zupełnie inny.
Również w bardzo szerokim znaczeniu firmy nie muszą stać się ekspertami w prowadzeniu klastra Kubernetes, ani nie budują i nie utrzymują własnych centrów danych. Zapewnienie niezawodnych podstaw obliczeniowych jest głównym wyzwaniem dostawcy usług w chmurze.
Wreszcie, mam wrażenie, że jako branża cofnęliśmy się nieco pod względem doświadczenie interakcji (). Heroku został wydany w 2007 roku i nadal jest jednym z najbardziej popularnych łatwy w użyciu platformy. Nie można zaprzeczyć, że Kubernetes jest znacznie potężniejszy, rozszerzalny i programowalny, ale brakuje mi łatwości rozpoczęcia i wdrożenia w Heroku. Aby korzystać z tej platformy wystarczy znać Gita.
Wszystko to prowadzi mnie do następującego wniosku: do działania potrzebujemy lepszych abstrakcji wyższego poziomu (jest to szczególnie prawdziwe w przypadku abstrakcje na najwyższym poziomie).
Odpowiednie API na najwyższym poziomie
Docker jest doskonałym przykładem potrzeby lepszego rozdzielania obaw w tym samym czasie poprawna implementacja API najwyższego poziomu.
Problem z Dockerem polega na tym, że (przynajmniej) początkowo projekt miał zbyt szerokie cele: wszystko po to, aby rozwiązać problem kompatybilności („działa na mojej maszynie”) przy użyciu technologii kontenerowej. Docker był formatem obrazu, środowiskiem wykonawczym z własną siecią wirtualną, narzędziem CLI, demonem działającym jako root i wieloma innymi funkcjami. W każdym razie wymiana wiadomości była więcej mylące, nie wspominając o „lekkich maszynach wirtualnych”, grupach cgroup, przestrzeniach nazw, licznych kwestiach bezpieczeństwa i funkcjach w połączeniu z wezwaniem marketingowym do „budowania, dostarczania i uruchamiania dowolnej aplikacji w dowolnym miejscu”.
Jak w przypadku wszystkich dobrych abstrakcji, rozbicie różnych problemów na logiczne warstwy, które można ze sobą łączyć, wymaga czasu (oraz doświadczenia i bólu). Niestety, zanim Docker osiągnął podobną dojrzałość, do walki wkroczył Kubernetes. Zmonopolizowało to cykl szumu do tego stopnia, że teraz wszyscy starali się nadążać za zmianami w ekosystemie Kubernetes, a ekosystem kontenerowy nabrał statusu drugorzędnego.
Kubernetes ma wiele takich samych problemów jak Docker. Za całą tę dyskusję o fajnej i dającej się komponować abstrakcji, rozdzielanie różnych zadań na warstwy niezbyt dobrze obudowany. W swej istocie jest to koordynator kontenerów, który uruchamia kontenery na klastrze różnych maszyn. Jest to zadanie dość niskiego poziomu, mające zastosowanie jedynie do inżynierów obsługujących klaster. Z drugiej strony Kubernetes też jest abstrakcja na najwyższym poziomie, narzędzie CLI, z którym użytkownicy wchodzą w interakcję za pośrednictwem YAML.
Docker był (i nadal jest) Fajny narzędziem programistycznym, pomimo wszystkich jego wad. Próbując dotrzymać kroku wszystkim „zającom” na raz, jego twórcom udało się poprawnie wdrożyć abstrakcja na najwyższym poziomie. Mam na myśli abstrakcję na najwyższym poziomie podzbiór funkcjonalność, którą naprawdę interesowali się docelowi odbiorcy (w tym przypadku programiści, którzy spędzali większość czasu w swoich lokalnych środowiskach programistycznych) i która działała świetnie od razu po wyjęciu z pudełka.
Dockerfile i narzędzie CLI docker powinien być przykładem tego, jak zbudować dobre „doświadczenie użytkownika na najwyższym poziomie”. Zwykły programista może rozpocząć pracę z Dockerem, nie mając zielonego pojęcia o jego zawiłościach wdrożenia, które wnoszą wkład w doświadczenie operacyjnetakie jak przestrzenie nazw, grupy c, limity pamięci i procesora itp. Ostatecznie pisanie pliku Dockerfile nie różni się zbytnio od pisania skryptu powłoki.
Kubernetes przeznaczony jest dla różnych grup docelowych:
- administratorzy klastrów;
- inżynierowie oprogramowania pracujący nad zagadnieniami infrastruktury, rozszerzającymi możliwości Kubernetesa i tworzącymi w oparciu o nie platformy;
- użytkownicy końcowi komunikujący się z Kubernetesem za pośrednictwem
kubectl.
Podejście Kubernetesa „jeden interfejs API pasuje do wszystkich” przedstawia niewystarczająco zamkniętą „górę złożoności” bez wskazówek, jak ją skalować. Wszystko to prowadzi do nieuzasadnionego przedłużania się ścieżki uczenia się. Jak Adam Jacob: „Docker zapewnił użytkownikom przełomowe doświadczenie, które nigdy nie zostało przekroczone. Zapytaj każdego, kto używa K8, czy chciałby, aby działał tak jak ich pierwszy docker run. Odpowiedź będzie brzmiała: tak”:
Twierdzę, że większość dzisiejszych technologii infrastrukturalnych jest na zbyt niskim poziomie (i dlatego jest uważana za „zbyt złożoną”). Kubernetes jest zaimplementowany na dość niskim poziomie. Rozproszone śledzenie w swoim (wiele przęseł połączonych ze sobą, tworząc widok śladu) jest również zaimplementowany na zbyt niskim poziomie. Narzędzia programistyczne, które implementują „abstrakcje najwyższego poziomu”, zwykle odnoszą największe sukcesy. Wniosek ten sprawdza się w zaskakującej liczbie przypadków (jeśli technologia jest zbyt złożona lub trudna w użyciu, wówczas nie odkryto jeszcze „najwyższego poziomu API/UI” dla tej technologii).
W tej chwili ekosystem natywny w chmurze jest zagmatwany ze względu na jego niski poziom skupienia. Jako branża musimy wprowadzać innowacje, eksperymentować i edukować na temat tego, jak wygląda właściwy poziom „maksymalnej, najwyższej abstrakcji”.
Sprzedaż
W 2010 roku doświadczenia w zakresie cyfrowego handlu detalicznego pozostały w dużej mierze niezmienione. Z jednej strony łatwość zakupów online powinna była uderzyć w tradycyjne sklepy detaliczne, z drugiej strony zakupy online zasadniczo pozostały niezmienione od dekady.
Chociaż nie mam konkretnych przemyśleń na temat ewolucji tej branży w ciągu następnej dekady, byłbym bardzo zawiedziony, gdybyśmy w 2030 r. robili zakupy w taki sam sposób, jak w 2020 r.
Dziennikarstwo
Jestem coraz bardziej rozczarowany stanem światowego dziennikarstwa. Coraz trudniej jest znaleźć bezstronne źródła wiadomości, które podają obiektywne i skrupulatne informacje. Bardzo często granica między samymi wiadomościami a opiniami na ich temat zaciera się. Z reguły informacje są prezentowane w sposób stronniczy. Jest to szczególnie prawdziwe w niektórych krajach, w których historycznie nie było rozdziału między wiadomościami i opiniami. W niedawnym artykule opublikowanym po ostatnich wyborach powszechnych w Wielkiej Brytanii Alan Rusbridger, były redaktor The Guardian, :
Najważniejsze jest to, że przez wiele lat przeglądałem amerykańskie gazety i było mi szkoda moich kolegów, którzy ponoszą wyłączną odpowiedzialność za tę wiadomość, zostawiając komentarz zupełnie innym osobom. Jednak z czasem litość przerodziła się w zazdrość. Obecnie uważam, że wszystkie brytyjskie gazety ogólnokrajowe powinny oddzielić odpowiedzialność za wiadomości od odpowiedzialności za komentarze. Niestety, przeciętnemu czytelnikowi – zwłaszcza czytelnikom internetowym – zbyt trudno jest dostrzec różnicę.
Biorąc pod uwagę raczej wątpliwą reputację Doliny Krzemowej, jeśli chodzi o etykę, nigdy nie zaufałbym technologii, która „zrewolucjonizuje” dziennikarstwo. Biorąc to pod uwagę, ja (i wielu moich znajomych) bylibyśmy zadowoleni, gdyby istniało bezstronne, bezinteresowne i godne zaufania źródło wiadomości. Choć nie mam pojęcia, jak taka platforma mogłaby wyglądać, jestem przekonany, że w epoce, w której coraz trudniej jest dostrzec prawdę, potrzeba uczciwego dziennikarstwa jest większa niż kiedykolwiek.
Sieci społeczne
Media społecznościowe i społecznościowe platformy informacyjne są głównym źródłem informacji dla wielu ludzi na całym świecie, a brak dokładności i niechęć niektórych platform do przeprowadzania nawet podstawowego sprawdzania faktów doprowadził do katastrofalnych konsekwencji, takich jak ludobójstwo, ingerencja w wybory i nie tylko .
Media społecznościowe to także najpotężniejsze narzędzie medialne, jakie kiedykolwiek istniało. Radykalnie zmienili praktykę polityczną. Zmienili reklamę. Zmienili popkulturę (m.in. główny wkład w rozwój tzw. kultury anulowania [kultury ostracyzmu – ok. tłumacz.] sieci społecznościowe wnoszą swój wkład). Krytycy twierdzą, że media społecznościowe okazały się podatnym gruntem dla szybkich i kapryśnych zmian w wartościach moralnych, ale zapewniły też członkom grup marginalizowanych możliwość organizowania się w sposób, jakiego nigdy wcześniej nie mieli. Zasadniczo media społecznościowe zmieniły sposób, w jaki ludzie komunikują się i wyrażają siebie w XXI wieku.
Jednak uważam też, że media społecznościowe wyzwalają najgorsze ludzkie impulsy. Rozwaga i rozwaga są często zaniedbywane na rzecz popularności, a wyrażenie uzasadnionego sprzeciwu wobec niektórych opinii i stanowisk staje się prawie niemożliwe. Polaryzacja często wymyka się spod kontroli, w wyniku czego opinia publiczna po prostu nie słucha indywidualnych opinii, podczas gdy absolutyści kontrolują kwestie etykiety i akceptowalności w Internecie.
Zastanawiam się, czy możliwe jest stworzenie „lepszej” platformy promującej dyskusje lepszej jakości? Przecież to właśnie napędza „zaangażowanie”, które często przynosi tym platformom główny zysk. Jak Kara Swisher w „New York Times”:
Można rozwijać cyfrowe interakcje bez wzbudzania nienawiści i nietolerancji. Powodem, dla którego większość serwisów społecznościowych wydaje się tak toksyczna, jest to, że zostały zbudowane z myślą o szybkości, wirusowości i uwadze, a nie o treści i dokładności.
Byłoby naprawdę niefortunnie, gdyby za kilka dekad jedynym dziedzictwem mediów społecznościowych była erozja niuansów i stosowności w dyskursie publicznym.
PS od tłumacza
Przeczytaj także na naszym blogu:
- «";
- «";
- «";
- «".
Źródło: www.habr.com