Catatan. terjemah: Artikel ini, yang menjadi popular di Medium, ialah gambaran keseluruhan perubahan utama (2010-2019) dalam dunia bahasa pengaturcaraan dan ekosistem teknologi yang berkaitan (dengan tumpuan khusus pada Docker dan Kubernetes). Pengarang asalnya ialah Cindy Sridharan, yang pakar dalam alat pembangun dan sistem yang diedarkan - khususnya, dia menulis buku "Kebolehcerapan Sistem Teragih" - dan agak popular dalam ruang Internet di kalangan pakar IT, terutamanya yang berminat dengan topik asal awan.
Menjelang penghujung tahun 2019, saya ingin berkongsi pendapat saya tentang beberapa kemajuan dan inovasi teknologi yang paling penting dalam dekad yang lalu. Di samping itu, saya akan cuba melihat sedikit masa depan dan menggariskan masalah dan peluang utama dekad yang akan datang.
Saya ingin menjelaskan bahawa dalam artikel ini saya tidak merangkumi perubahan dalam bidang seperti sains data (sains data), kecerdasan buatan, kejuruteraan bahagian hadapan, dsb., kerana saya secara peribadi tidak mempunyai pengalaman yang mencukupi dalam mereka.
Tipifikasi menyerang kembali
Salah satu trend paling positif pada tahun 2010-an ialah kebangkitan semula bahasa yang ditaip secara statik. Walau bagaimanapun, bahasa sedemikian tidak pernah hilang (C++ dan Java dalam permintaan hari ini; mereka menguasai sepuluh tahun yang lalu), tetapi bahasa yang ditaip secara dinamik (dinamik) mengalami peningkatan populariti yang ketara selepas kemunculan pergerakan Ruby on Rails pada tahun 2005. . Pertumbuhan ini memuncak pada tahun 2009 dengan sumber terbuka Node.js, yang menjadikan Javascript-on-the-server menjadi kenyataan.
Lama kelamaan, bahasa dinamik telah kehilangan beberapa tarikan mereka dalam bidang mencipta perisian pelayan. Bahasa Go, yang dipopularkan semasa revolusi kontena, nampaknya lebih sesuai untuk mencipta pelayan berprestasi tinggi, cekap sumber dengan pemprosesan selari (yang mana pencipta Node.js sendiri).
Rust, yang diperkenalkan pada tahun 2010, termasuk pendahuluan dalam dalam usaha untuk menjadi bahasa yang selamat dan ditaip. Pada separuh pertama dekad, penerimaan industri terhadap Rust agak suam, tetapi popularitinya meningkat dengan ketara pada separuh kedua. Kes penggunaan yang ketara untuk Rust termasuk penggunaannya untuk , (kami bercakap mengenainya dalam - lebih kurang terjemah.), penyusun WebAssembly awal daripada Fastly (kini sebahagian daripada bytecodealliance) dan lain-lain. Dalam situasi di mana Microsoft sedang mempertimbangkan untuk menulis semula beberapa bahagian OS Windows Rust, boleh dikatakan bahawa bahasa ini mempunyai masa depan yang cerah pada tahun 2020-an.
Malah bahasa dinamik mendapat ciri baharu seperti (jenis pilihan). Ia pertama kali dilaksanakan dalam TypeScript, bahasa yang membolehkan anda membuat kod ditaip dan menyusunnya ke dalam JavaScript. PHP, Ruby dan Python mempunyai sistem menaip pilihan mereka sendiri (, ), yang berjaya digunakan dalam .
Mengembalikan SQL kepada NoSQL
NoSQL ialah satu lagi teknologi yang lebih popular pada awal dekad berbanding pada penghujungnya. Saya rasa ada dua sebab untuk ini.
Pertama, model NoSQL, dengan kekurangan skema, transaksi, dan jaminan konsistensi yang lebih lemah, ternyata lebih sukar untuk dilaksanakan daripada model SQL. DALAM dengan tajuk "Mengapa anda harus memilih konsistensi yang kuat apabila boleh" (Mengapa anda perlu memilih konsistensi yang kuat, apabila boleh) Google menulis:
Salah satu perkara yang kami pelajari di Google ialah kod aplikasi lebih mudah dan masa pembangunan lebih singkat apabila jurutera boleh bergantung pada storan sedia ada untuk mengendalikan transaksi yang rumit dan memastikan data teratur. Untuk memetik dokumentasi Spanner asal, "Kami percaya bahawa adalah lebih baik untuk pengaturcara menangani masalah prestasi aplikasi akibat penyalahgunaan transaksi apabila kesesakan timbul, daripada sentiasa mengingati ketiadaan transaksi."
Sebab kedua adalah disebabkan oleh peningkatan pangkalan data SQL yang diedarkan "scale-out" (seperti и ) dalam ruang awan awam, serta alternatif Sumber Terbuka seperti CockroachDB (kita bercakap tentang dia juga - lebih kurang terjemah.), yang menyelesaikan banyak masalah teknikal yang menyebabkan pangkalan data SQL tradisional "tidak berskala." Malah MongoDB, yang pernah menjadi lambang pergerakan NoSQL, kini urus niaga yang diedarkan.
Untuk situasi yang memerlukan pembacaan dan penulisan atom merentas berbilang dokumen (merentas satu atau lebih koleksi), MongoDB menyokong transaksi berbilang dokumen. Dalam kes urus niaga yang diedarkan, urus niaga boleh digunakan merentas berbilang operasi, koleksi, pangkalan data, dokumen dan serpihan.
Jumlah penstriman
Apache Kafka tidak diragukan lagi merupakan salah satu ciptaan paling penting dalam dekad yang lalu. Kod sumbernya dibuka pada Januari 2011, dan selama ini, Kafka telah merevolusikan cara perniagaan bekerja dengan data. Kafka telah digunakan di setiap syarikat tempat saya bekerja, dari syarikat permulaan hingga syarikat besar. Jaminan dan kes penggunaan yang disediakannya (pub-sub, strim, seni bina dipacu peristiwa) digunakan dalam pelbagai tugas, daripada penyimpanan data kepada pemantauan dan analisis penstriman, dalam permintaan dalam banyak bidang seperti kewangan, penjagaan kesihatan, sektor awam, runcit dan sebagainya.
Integrasi Berterusan (dan pada tahap yang lebih rendah Penggunaan Berterusan)
Integrasi Berterusan tidak muncul dalam tempoh 10 tahun yang lalu, tetapi sepanjang dekad yang lalu ia telah merebak sebegitu rupa, yang telah menjadi sebahagian daripada aliran kerja standard (jalankan ujian pada semua permintaan tarik). Menubuhkan GitHub sebagai platform untuk pembangunan dan penyimpanan kod dan, yang lebih penting, membangunkan aliran kerja berdasarkan bermakna menjalankan ujian sebelum menerima permintaan tarik untuk menguasai adalah tunggal aliran kerja dalam pembangunan, biasa kepada jurutera yang memulakan kerjaya mereka dalam sepuluh tahun yang lalu.
Penerapan Berterusan (mengerahkan setiap komit apabila ia mencecah induk) tidak begitu meluas seperti penyepaduan berterusan. Walau bagaimanapun, dengan banyaknya API awan yang berbeza untuk penggunaan, peningkatan populariti platform seperti Kubernetes (yang menyediakan API piawai untuk penggunaan), dan kemunculan alat berbilang platform, berbilang awan seperti Spinnaker (dibina di atas alat yang diseragamkan. API), proses penggunaan telah menjadi lebih automatik, diperkemas dan, secara amnya, lebih selamat.
Kontena
Bekas mungkin merupakan teknologi yang paling digembar-gemburkan, dibincangkan, diiklankan dan disalahfahamkan pada tahun 2010-an. Sebaliknya, ia adalah salah satu inovasi paling penting dalam dekad sebelumnya. Sebahagian daripada sebab semua kecoh ini terletak pada isyarat bercampur yang kami terima dari hampir semua tempat. Sekarang gembar-gembur telah mereda sedikit, beberapa perkara telah menjadi tumpuan yang lebih tajam.
Bekas telah menjadi popular bukan kerana ia adalah cara terbaik untuk menjalankan aplikasi yang memenuhi keperluan komuniti pembangun global. Bekas menjadi popular kerana ia berjaya memenuhi permintaan pemasaran untuk alat tertentu yang menyelesaikan masalah yang sama sekali berbeza. Docker ternyata hebat alat pembangunan yang menyelesaikan isu keserasian yang mendesak ("berfungsi pada mesin saya").
Lebih tepat lagi, revolusi dibuat Imej Docker, kerana ia menyelesaikan masalah pariti antara persekitaran dan menyediakan kemudahalihan sebenar bukan sahaja pada fail aplikasi, tetapi juga semua perisian dan kebergantungan pengendaliannya. Hakikat bahawa alat ini entah bagaimana mendorong populariti "bekas", yang pada asasnya merupakan perincian pelaksanaan peringkat rendah, masih menjadi misteri utama bagi saya sedekad yang lalu.
Tanpa pelayan
Saya bertaruh bahawa kemunculan pengkomputeran "tanpa pelayan" adalah lebih penting daripada bekas kerana ia benar-benar menjadikan impian pengkomputeran atas permintaan menjadi kenyataan (permintaan). Sepanjang lima tahun yang lalu, saya telah melihat pendekatan tanpa pelayan secara beransur-ansur berkembang dalam skop dengan menambah sokongan untuk bahasa dan masa jalan baharu. Kemunculan produk seperti Azure Durable Functions nampaknya merupakan langkah tepat ke arah pelaksanaan fungsi stateful (pada masa yang sama penentu berkaitan dengan had FaaS). Saya akan menonton dengan penuh minat bagaimana paradigma baharu ini berkembang pada tahun-tahun akan datang.
Automasi
Mungkin penerima terbesar aliran ini ialah komuniti kejuruteraan operasi, kerana ia telah membolehkan konsep seperti infrastruktur sebagai kod (IaC) menjadi kenyataan. Di samping itu, keghairahan untuk automasi telah bertepatan dengan kebangkitan "budaya SRE," yang bertujuan untuk mengambil pendekatan yang lebih mengutamakan perisian kepada operasi.
Fiksyen API sejagat
Satu lagi ciri menarik dalam dekad yang lalu ialah rekaan API pelbagai tugas pembangunan. API yang baik dan fleksibel membolehkan pembangun mencipta aliran kerja dan alatan yang inovatif, yang seterusnya membantu dengan penyelenggaraan dan meningkatkan pengalaman pengguna.
Selain itu, rekaan API ialah langkah pertama ke arah rekaan SaaS bagi beberapa fungsi atau alat. Aliran ini juga bertepatan dengan peningkatan populariti perkhidmatan mikro: SaaS telah menjadi satu lagi perkhidmatan yang boleh diakses melalui API. Kini terdapat banyak alat SaaS dan FOSS yang tersedia dalam bidang seperti pemantauan, pembayaran, pengimbangan beban, penyepaduan berterusan, makluman, penukaran ciri (ciri pembenderaan), CDN, kejuruteraan trafik (cth. DNS), dsb., yang telah berkembang pesat dalam dekad yang lalu.
Kebolehlihatan
Perlu diingat bahawa hari ini kita mempunyai akses kepada jauh lebih maju alat untuk memantau dan mendiagnosis tingkah laku aplikasi berbanding sebelum ini. Sistem pemantauan Prometheus, yang menerima status Sumber Terbuka pada 2015, mungkin boleh dipanggil yang terbaik sistem pemantauan daripada mereka yang saya telah bekerja. Ia tidak sempurna, tetapi sebilangan besar perkara dilaksanakan dengan cara yang betul (contohnya, sokongan untuk pengukuran [dimensi] dalam kes metrik).
Pengesanan teragih ialah satu lagi teknologi yang memasuki arus perdana pada 2010-an, terima kasih kepada inisiatif seperti OpenTracing (dan pengganti OpenTelemetry). Walaupun pengesanan masih agak sukar untuk diterapkan, beberapa perkembangan terkini memberi harapan bahawa kami akan membuka potensi sebenar pada tahun 2020-an. (Nota: Baca juga dalam blog kami terjemahan artikel “"oleh pengarang yang sama.)
Melihat ke masa hadapan
Malangnya, terdapat banyak titik kesakitan yang menunggu penyelesaian dalam dekad yang akan datang. Berikut adalah pemikiran saya tentang mereka dan beberapa idea berpotensi tentang cara untuk menyingkirkannya.
Menyelesaikan Masalah Hukum Moore
Penamatan undang-undang penskalaan Dennard dan ketinggalan di belakang undang-undang Moore memerlukan inovasi baharu. John Hennessy dalam menerangkan mengapa penagih masalah (khusus domain) seni bina seperti TPU mungkin merupakan salah satu penyelesaian kepada masalah ketinggalan di belakang Undang-undang Moore. Toolkit seperti daripada Google nampaknya merupakan satu langkah ke hadapan yang baik ke arah ini:
Penyusun mesti menyokong aplikasi baharu, mudah dipindahkan ke perkakasan baharu, memautkan berbilang lapisan abstraksi daripada bahasa dinamik, terurus kepada pemecut vektor dan peranti storan yang dikawal perisian, sambil menyediakan suis peringkat tinggi untuk penalaan automatik, memberikan just- dalam kefungsian -masa, diagnostik dan pengedaran maklumat penyahpepijatan tentang fungsi dan prestasi sistem di seluruh tindanan, manakala dalam kebanyakan kes memberikan prestasi yang hampir hampir dengan pemasang tulisan tangan. Kami berhasrat untuk berkongsi visi, kemajuan dan rancangan kami untuk pembangunan dan ketersediaan awam bagi infrastruktur kompilasi sedemikian.
CI / CD
Walaupun peningkatan CI telah menjadi salah satu trend terbesar pada tahun 2010-an, Jenkins masih menjadi standard emas untuk CI.
Ruang ini sangat memerlukan inovasi dalam bidang berikut:
- antara muka pengguna (DSL untuk spesifikasi ujian pengekodan);
- butiran pelaksanaan yang akan menjadikannya benar-benar berskala dan pantas;
- penyepaduan dengan pelbagai persekitaran (pementasan, prod, dll.) untuk melaksanakan bentuk ujian yang lebih maju;
- ujian dan penggunaan berterusan.
Alat Pembangun
Sebagai sebuah industri, kami telah mula mencipta perisian yang semakin kompleks dan mengagumkan. Walau bagaimanapun, apabila ia berkaitan dengan alat kami sendiri, keadaan mungkin lebih baik.
Penyuntingan kolaboratif dan jauh (melalui ssh) mendapat sedikit populariti, tetapi tidak pernah menjadi cara pembangunan standard baharu. Jika anda, seperti saya, menolak idea itu keperluan sambungan kekal ke Internet hanya untuk dapat melakukan pengaturcaraan, kemudian bekerja melalui ssh pada mesin jauh tidak mungkin sesuai dengan anda.
Persekitaran pembangunan tempatan, terutamanya untuk jurutera yang bekerja pada seni bina berorientasikan perkhidmatan yang besar, masih menjadi cabaran. Sesetengah projek cuba menyelesaikannya, dan saya berminat untuk mengetahui rupa UX yang paling ergonomik untuk kes penggunaan tertentu.
Ia juga menarik untuk memperluaskan konsep "persekitaran mudah alih" ke kawasan pembangunan lain seperti pembiakan pepijat (atau ) yang berlaku di bawah keadaan atau tetapan tertentu.
Saya juga ingin melihat lebih banyak inovasi dalam bidang seperti carian kod semantik dan sensitif konteks, alat untuk mengaitkan kejadian pengeluaran dengan bahagian tertentu pangkalan kod, dsb.
Pengkomputeran (masa depan PaaS)
Berikutan gembar-gembur tentang kontena dan tanpa pelayan pada tahun 2010-an, rangkaian penyelesaian dalam ruang awan awam telah berkembang dengan ketara dalam beberapa tahun kebelakangan ini.
Ini menimbulkan beberapa persoalan yang menarik. Pertama sekali, senarai pilihan yang tersedia dalam awan awam sentiasa berkembang. Pembekal perkhidmatan awan mempunyai kakitangan dan sumber untuk dengan mudah mengikuti perkembangan terkini dalam dunia Sumber Terbuka dan mengeluarkan produk seperti "pod tanpa pelayan" (saya mengesyaki hanya dengan menjadikan masa jalan FaaS mereka sendiri mematuhi OCI) atau perkara lain yang serupa.
Seseorang hanya boleh iri kepada mereka yang menggunakan penyelesaian awan ini. Secara teorinya, tawaran awan Kubernetes (GKE, EKS, EKS pada Fargate, dll.) menyediakan API bebas pembekal awan untuk menjalankan beban kerja. Jika anda menggunakan produk yang serupa (ECS, Fargate, Google Cloud Run, dll.), anda mungkin sudah memanfaatkan sepenuhnya ciri paling menarik yang ditawarkan oleh pembekal perkhidmatan. Selain itu, apabila produk baharu atau paradigma pengkomputeran muncul, penghijrahan mungkin menjadi mudah dan bebas tekanan.
Memandangkan betapa cepatnya rangkaian penyelesaian sedemikian berkembang (saya akan sangat terkejut jika beberapa pilihan baharu tidak muncul dalam masa terdekat), pasukan "platform" kecil (pasukan yang dikaitkan dengan infrastruktur dan bertanggungjawab untuk mencipta platform di premis untuk menjalankan syarikat beban kerja) akan menjadi sangat sukar untuk bersaing dari segi kefungsian, kemudahan penggunaan dan kebolehpercayaan keseluruhan. Tahun 2010-an telah melihat Kubernetes sebagai alat untuk membina PaaS (platform-as-a-service), jadi nampaknya tidak ada gunanya bagi saya untuk membina platform dalaman di atas Kubernetes yang menawarkan pilihan, kesederhanaan dan kebebasan yang sama yang tersedia di khalayak ramai. angkasa awan. Membingkai PaaS berasaskan kontena sebagai "strategi Kubernetes" adalah sama dengan sengaja mengelakkan keupayaan paling inovatif awan.
Jika dilihat pada yang ada hari ini keupayaan pengkomputeran, menjadi jelas bahawa mencipta PaaS anda sendiri berdasarkan Kubernetes adalah sama dengan melukis diri anda ke sudut (bukan pendekatan yang sangat berfikiran ke hadapan, ya?). Walaupun seseorang memutuskan untuk membina PaaS kontena pada Kubernetes hari ini, dalam beberapa tahun ia akan kelihatan ketinggalan zaman berbanding dengan keupayaan awan. Walaupun Kubernetes bermula sebagai projek sumber terbuka, nenek moyang dan inspirasinya ialah alat dalaman Google. Walau bagaimanapun, ia pada asalnya dibangunkan pada awal/pertengahan 2000-an apabila landskap pengkomputeran adalah berbeza sama sekali.
Selain itu, dalam erti kata yang sangat luas, syarikat tidak perlu menjadi pakar dalam menjalankan gugusan Kubernetes, dan mereka juga tidak membina dan menyelenggara pusat data mereka sendiri. Menyediakan asas pengkomputeran yang boleh dipercayai adalah cabaran teras pembekal perkhidmatan awan.
Akhirnya, saya rasa kita telah mundur sedikit sebagai industri dari segi pengalaman interaksi (). Heroku telah dilancarkan pada tahun 2007 dan masih merupakan salah satu yang paling banyak mudah untuk digunakan platform Tidak dapat dinafikan bahawa Kubernetes jauh lebih berkuasa, boleh diperluaskan dan boleh diprogramkan, tetapi saya terlepas betapa mudahnya untuk memulakan dan menggunakan Heroku. Untuk menggunakan platform ini, anda hanya perlu mengetahui Git.
Semua ini membawa saya kepada kesimpulan berikut: kita memerlukan abstraksi peringkat tinggi yang lebih baik untuk berfungsi (ini terutama berlaku untuk abstraksi peringkat tertinggi).
API yang betul pada tahap tertinggi
Docker ialah contoh yang bagus tentang keperluan untuk pemisahan kebimbangan yang lebih baik pada masa yang sama pelaksanaan yang betul bagi API peringkat tertinggi.
Masalah dengan Docker ialah (sekurang-kurangnya) pada mulanya matlamat projek itu terlalu luas: semuanya demi menyelesaikan masalah keserasian (“berfungsi pada mesin saya”) menggunakan teknologi kontena. Docker ialah format imej, masa jalan dengan rangkaian mayanya sendiri, alat CLI, daemon berjalan sebagai root, dan banyak lagi. Walau apa pun, pertukaran mesej adalah lebih mengelirukan, apatah lagi "VM ringan", cgroup, ruang nama, pelbagai isu keselamatan dan ciri bercampur dengan panggilan pemasaran untuk "membina, menghantar, menjalankan sebarang aplikasi di mana-mana sahaja".
Seperti semua abstraksi yang baik, ia memerlukan masa (dan pengalaman dan kesakitan) untuk memecahkan pelbagai masalah ke dalam lapisan logik yang boleh digabungkan antara satu sama lain. Malangnya, sebelum Docker boleh mencapai kematangan yang sama, Kubernetes memasuki pergaduhan. Ia memonopoli kitaran gembar-gembur sehingga semua orang kini cuba mengikuti perubahan dalam ekosistem Kubernetes, dan ekosistem kontena mengambil status kedua.
Kubernetes berkongsi banyak masalah yang sama seperti Docker. Untuk semua perbincangan tentang abstraksi yang sejuk dan boleh digubah, mengasingkan tugas yang berbeza ke dalam lapisan tidak terkapsul dengan baik. Pada terasnya, ia adalah pengatur kontena yang menjalankan kontena pada sekumpulan mesin yang berbeza. Ini adalah tugas peringkat rendah, hanya terpakai kepada jurutera yang mengendalikan kluster. Sebaliknya, Kubernetes juga abstrak tahap tertinggi, alat CLI yang berinteraksi dengan pengguna melalui YAML.
Docker dahulu (dan masih ada) sejuk alat pembangunan, walaupun semua kekurangannya. Dalam usaha untuk bersaing dengan semua "arnab" sekaligus, pemajunya berjaya melaksanakan dengan betul abstrak pada tahap tertinggi. Dengan abstrak pada tahap tertinggi yang saya maksudkan subset fungsi yang sangat diminati oleh khalayak sasaran (dalam kes ini, pembangun yang menghabiskan sebahagian besar masa mereka dalam persekitaran pembangunan tempatan mereka) dan ia berfungsi dengan baik di luar kotak.
Dockerfile dan utiliti CLI docker harus menjadi contoh cara membina "pengalaman pengguna tahap tertinggi" yang baik. Pembangun biasa boleh mula bekerja dengan Docker tanpa mengetahui apa-apa tentang selok-belok pelaksanaan yang menyumbang kepada pengalaman operasiseperti ruang nama, cgroup, memori dan had CPU, dsb. Akhirnya, menulis Dockerfile tidak jauh berbeza dengan menulis skrip shell.
Kubernetes bertujuan untuk kumpulan sasaran yang berbeza:
- pentadbir kluster;
- jurutera perisian bekerja pada isu infrastruktur, mengembangkan keupayaan Kubernetes dan mencipta platform berdasarkannya;
- pengguna akhir berinteraksi dengan Kubernetes melalui
kubectl.
Pendekatan "satu API sesuai untuk semua" Kubernetes membentangkan "gunung kerumitan" yang tidak terkapsul dengan cukup tanpa panduan tentang cara menskalakannya. Semua ini membawa kepada trajektori pembelajaran yang tidak wajar. Bagaimana Adam Jacob, "Docker membawa pengalaman pengguna transformatif yang tidak pernah diatasi. Tanya sesiapa sahaja yang menggunakan K8 jika mereka berharap ia berfungsi seperti yang pertama docker run. Jawapannya ialah ya":
Saya berpendapat bahawa kebanyakan teknologi infrastruktur hari ini adalah terlalu rendah (dan oleh itu dianggap "terlalu kompleks"). Kubernetes dilaksanakan pada tahap yang agak rendah. Pengesanan yang diedarkan di dalamnya (banyak rentang dicantum untuk membentuk traceview) juga dilaksanakan pada tahap yang terlalu rendah. Alat pembangun yang melaksanakan "abstraksi tahap tertinggi" cenderung menjadi yang paling berjaya. Kesimpulan ini berlaku dalam beberapa kes yang mengejutkan (jika teknologi terlalu kompleks atau sukar untuk digunakan, maka "API/UI peringkat tertinggi" untuk teknologi itu masih belum ditemui).
Pada masa ini, ekosistem asli awan mengelirukan kerana tumpuan peringkat rendahnya. Sebagai sebuah industri, kita mesti berinovasi, bereksperimen dan mendidik tentang rupa tahap "abstraksi maksimum dan tertinggi" yang betul.
Perdagangan runcit
Pada tahun 2010-an, pengalaman runcit digital sebahagian besarnya kekal tidak berubah. Di satu pihak, kemudahan membeli-belah dalam talian sepatutnya melanda kedai runcit tradisional, sebaliknya, membeli-belah dalam talian pada asasnya kekal hampir tidak berubah dalam satu dekad.
Walaupun saya tidak mempunyai pemikiran khusus tentang bagaimana industri ini akan berkembang sepanjang dekad yang akan datang, saya akan sangat kecewa jika kita membeli-belah pada 2030 dengan cara yang sama seperti yang kita lakukan pada 2020.
Kewartawanan
Saya semakin kecewa dengan keadaan kewartawanan global. Ia menjadi semakin sukar untuk mencari sumber berita yang tidak berat sebelah yang melaporkan secara objektif dan teliti. Selalunya garis antara berita itu sendiri dan pendapat mengenainya kabur. Sebagai peraturan, maklumat dibentangkan dengan cara yang berat sebelah. Ini adalah benar terutamanya di beberapa negara yang dari segi sejarah tidak ada pemisahan antara berita dan pendapat. Dalam artikel terbaru yang diterbitkan selepas pilihan raya umum UK yang lalu, Alan Rusbridger, bekas editor The Guardian, :
Perkara utama ialah selama bertahun-tahun saya melihat akhbar Amerika dan berasa kasihan kepada rakan sekerja saya di sana, yang bertanggungjawab sepenuhnya untuk berita itu, meninggalkan ulasan kepada orang yang sama sekali berbeza. Namun, lama kelamaan rasa kasihan bertukar menjadi iri hati. Saya kini berpendapat bahawa semua akhbar nasional British harus memisahkan tanggungjawab mereka untuk berita daripada tanggungjawab mereka untuk ulasan. Malangnya, terlalu sukar untuk pembaca biasa—terutamanya pembaca dalam talian—untuk membezakan perbezaannya.
Memandangkan reputasi Silicon Valley yang agak meragukan dalam hal etika, saya tidak akan pernah mempercayai teknologi untuk "merevolusikan" kewartawanan. Oleh itu, saya (dan ramai rakan saya) akan gembira jika ada sumber berita yang tidak berat sebelah, tidak berminat dan boleh dipercayai. Walaupun saya tidak tahu bagaimana rupa platform sedemikian, saya yakin bahawa dalam era di mana kebenaran menjadi semakin sukar untuk dilihat, keperluan untuk kewartawanan yang jujur adalah lebih besar daripada sebelumnya.
Rangkaian Sosial
Media sosial dan platform berita komuniti ialah sumber utama maklumat untuk ramai orang di seluruh dunia, dan kekurangan ketepatan dan keengganan sesetengah platform untuk melakukan walaupun semakan fakta asas telah membawa kepada akibat buruk seperti pembunuhan beramai-ramai, campur tangan pilihan raya dan banyak lagi. .
Media sosial juga merupakan alat media paling berkuasa yang pernah wujud. Mereka secara radikal mengubah amalan politik. Mereka menukar pengiklanan. Mereka mengubah budaya pop (contohnya, sumbangan utama kepada pembangunan budaya batal yang dipanggil [budaya pengasingan - lebih kurang. terjemah] rangkaian sosial menyumbang). Pengkritik berpendapat bahawa media sosial telah terbukti menjadi tanah yang subur untuk perubahan pantas dan berubah-ubah dalam nilai moral, tetapi ia juga telah memberikan ahli kumpulan terpinggir peluang untuk mengatur dengan cara yang tidak pernah mereka lakukan sebelum ini. Pada dasarnya, media sosial telah mengubah cara orang berkomunikasi dan mengekspresikan diri mereka pada abad ke-21.
Walau bagaimanapun, saya juga percaya bahawa media sosial mengeluarkan dorongan manusia yang paling teruk. Pertimbangan dan bertimbang rasa sering diabaikan memihak kepada populariti, dan menjadi hampir mustahil untuk menyatakan ketidaksetujuan yang beralasan dengan pendapat dan pendirian tertentu. Polarisasi sering menjadi tidak terkawal, menyebabkan orang ramai tidak mendengar pendapat individu manakala golongan mutlak mengawal isu etika dan penerimaan dalam talian.
Saya tertanya-tanya adakah mungkin untuk mencipta platform "lebih baik" yang menggalakkan perbincangan berkualiti lebih baik? Lagipun, itulah yang mendorong "penglibatan" yang sering membawa keuntungan utama kepada platform ini. Bagaimana Kara Swisher dalam New York Times:
Ia adalah mungkin untuk membangunkan interaksi digital tanpa menimbulkan kebencian dan sikap tidak bertoleransi. Sebab kebanyakan tapak media sosial kelihatan sangat toksik adalah kerana ia dibina untuk kelajuan, viral dan perhatian, bukannya kandungan dan ketepatan.
Adalah benar-benar malang jika, dalam beberapa dekad, satu-satunya warisan media sosial ialah penghakisan nuansa dan kesesuaian dalam wacana awam.
PS daripada penterjemah
Baca juga di blog kami:
- «»;
- «»;
- «»;
- «'.
Sumber: www.habr.com
