Lənət olsun Google, mən bir daha bloq yazmaq istəmədim. Görməli çox şeyim var. Bloq yazmaq vaxt, enerji və yaradıcılıq tələb edir, mən bundan yaxşı istifadə edə bilərdim: kitablarım, , mənim oyunum və s. Amma sən məni o qədər əsəbiləşdirdin ki, bunu yazmalı oldum.
Beləliklə, gəlin bu işi bitirək.
İcazə verin, Google-da ilk işə başladığım vaxtdan qısa, lakin ibrətamiz bir hekayə ilə başlayım. Bilirəm ki, son vaxtlar Google haqqında çox pis şeylər deyirəm, lakin öz şirkətim mütəmadi olaraq səriştəsiz biznes qərarları qəbul edəndə bu məni əsəbləşdirir. Eyni zamanda, biz buna haqqını verməliyik: Google-un daxili infrastrukturu həqiqətən qeyri-adidir, əminliklə demək olar ki, bu gün bundan yaxşısı yoxdur. Google-un qurucuları mən olacağımdan daha yaxşı mühəndislər idi və bu hekayə yalnız bu həqiqəti təsdiqləyir.
Birincisi, kiçik bir məlumat: Google adlı bir məlumat saxlama texnologiyası var . Bu, diqqətəlayiq texniki nailiyyət idi, ilk (əgər ilk deyilsə) “sonsuz miqyaslana bilən” açar dəyər anbarı (K/V): mahiyyətcə NoSQL-in başlanğıcı idi. Bu günlərdə Bigtable hələ də kifayət qədər izdihamlı K/V saxlama məkanında yaxşı işləyir, lakin o vaxt (2005) heyrətamiz dərəcədə sərin idi.
Bigtable ilə bağlı bir gülməli məqam ondan ibarətdir ki, onların planşet serverləri adlanan, böyük indekslərə malik daxili idarəetmə təyyarəsi obyektləri (həyata keçirmənin bir hissəsi kimi) idi və bir anda sistemin miqyasını genişləndirərkən darboğaz oldular. Bigtable mühəndisləri miqyaslılığın necə həyata keçiriləcəyi üzərində baş sındırırdılar və birdən anladılar ki, onlar planşet serverlərini digər Bigtable yaddaşı ilə əvəz edə bilərlər. Beləliklə, Bigtable Bigtable tətbiqinin bir hissəsidir. Bu anbarlar bütün səviyyələrdə mövcuddur.
Başqa bir maraqlı detal isə odur ki, bir müddət Bigtable Google-da populyarlaşdı və hər yerdə hər komandanın öz deposuna sahib oldu. Beləliklə, cümə görüşlərinin birində Larri Peyc təsadüfən keçərək soruşdu: “Niyə bizdə birdən çox Bigtable var? Niyə yalnız biri yox?” Teorik olaraq, bir yaddaş Google-un bütün saxlama ehtiyacları üçün kifayət etməlidir. Əlbəttə ki, onlar heç vaxt praktiki inkişaf səbəbləri üçün (potensial uğursuzluğun nəticələri kimi) yalnız birinə getmədilər, lakin nəzəriyyə maraqlı idi. Bütün Kainat üçün bir depo (Yeri gəlmişkən, Amazon bunu öz Sable ilə edib-etmədiyini bilən varmı?)
Hər halda mənim hekayəm budur.
O zaman mən Google-da cəmi iki ildən çox idi ki, işləyirdim və bir gün Bigtable mühəndis qrupundan belə bir məktub aldım:
Hörmətli Stiv,
Bigtable komandasından salamlar. Sizə bildirmək istərdik ki, [məlumat mərkəzinin adı] siz çox, çox köhnə Bigtable binar sistemindən istifadə edirsiniz. Bu versiya artıq dəstəklənmir və biz sizə ən son versiyaya yüksəltməkdə kömək etmək istəyirik.
Xahiş edirəm, bu məsələ ilə bağlı birgə işləmək üçün vaxt ayıra bilsəniz, mənə bildirin.
Ən yaxşısı,
Böyük masa komandası
Google-da çoxlu məktublar alırsınız, ona görə də ilk baxışdan belə bir şey oxudum:
Hörmətli alıcı,
Bir komandadan salamlar. Biz bu blah blah bla bla bla ünsiyyət qurmaq istəyirik. Bla bla bla bla bla bla bla bla bla bla dərhal.
Zəhmət olmasa, qiymətli vaxtınızın bir hissəsini blah blah bla üçün planlaşdıra bilsəniz, bizə bildirin.
Ən yaxşısı,
Bir növ əmr
Dərhal demək olar ki, sildim, amma şüurumun kənarında ağrılı, sızıltılı bir hiss hiss etdim ki, həqiqətən deyil rəsmi məktub kimi görünür aydındır, Bigtable istifadə etmədiyim üçün alıcının səhv etdiyini.
Amma qəribə idi.
Günün qalan hissəsini növbə ilə iş və mikromətbəxdə hansı köpək balığı ətini sınayacağım barədə düşünürdüm, onlardan ən azı üçü oturduğum yerdən biskviti sərrast atmaqla vurmağa kifayət qədər yaxın idi, amma yazmaq fikri məni heç vaxt artan bir mülayim narahatlıq hissi ilə tərk etmədi.
Mənim adımı açıq-aydın dedilər. Və e-poçt başqasının yox, mənim e-poçt ünvanıma göndərildi və bu cc: və ya bcc: deyil. Səs çox fərdi və aydındır. Bəlkə bu bir növ səhvdir?
Nəhayət, maraq məni ələ keçirdi və onların qeyd etdikləri məlumat mərkəzində Borg konsoluna baxmağa getdim.
Və əlbəttə ki, idarə altında BigTable yaddaşım var idi. üzr istəyirəm, nə? Mən onun məzmununa baxdım və vay! 2005-ci ilin iyununda Google-da ilk həftəmdə oturduğum Codelab inkubatorundan idi. Codelab sizi orada bəzi dəyərlər yazmaq üçün Bigtable-ı işə salmağa məcbur etdi və yəqin ki, bundan sonra yaddaşı heç vaxt bağlamadım. İki ildən çox vaxt keçməsinə baxmayaraq hələ də işləyirdi.
Bu hekayənin bir neçə diqqətəlayiq tərəfi var. Birincisi, Bigtable-ın işi Google miqyasında o qədər əhəmiyyətsiz idi ki, yalnız iki ildən sonra kimsə əlavə yaddaşı fərq etdi və yalnız binar versiyası köhnəldiyi üçün. Müqayisə üçün bir dəfə istifadə etməyi düşündüm onlayn oyunum üçün. O zaman bu xidmətin qiyməti ildə təxminən 16 dollardır. boş GCP-də böyük masa. Mən demirəm ki, səni aldadırlar, amma mənim şəxsi fikrimcə, bu, boş bir lənət bazası üçün çox puldur.
Diqqət çəkən başqa bir cəhət isə saxlamadır iki ildən sonra hələ də işləyir. WTF? Məlumat mərkəzləri gəlir və gedir; onlar fasilələrlə üzləşirlər, planlı təmirdən keçirlər, hər zaman dəyişirlər. Aparat yenilənir, açarlar dəyişdirilir, hər şey daim təkmilləşdirilir. Bütün bu dəyişikliklərlə mənim proqramımı iki il ərzində necə davam etdirə bildilər? Bu, 2020-ci ildə təvazökar bir nailiyyət kimi görünə bilər, lakin 2005-2007-ci illərdə olduqca təsir edici idi.
Və ən gözəl cəhəti odur ki, başqa bir ştatda olan kənar mühəndis komandası mənə, Bigtable-ın kiçik, demək olar ki, boş nümunəsinin sahibinə yaxınlaşır. sıfır trafik son iki ildə - və onu yeniləmək üçün kömək təklif edirlər.
Onlara təşəkkür etdim, yaddaşı sildim və həyat həmişəki kimi davam etdi. Amma on üç il keçsə də, hələ də o məktub haqqında düşünürəm. Çünki bəzən Google Cloud-dan oxşar məktublar alıram. Onlar belə görünür:
Hörmətli Google Bulud İstifadəçisi,
Xatırladaq ki, biz [istifadə etdiyiniz əsas xidmət] xidmətini 2020-ci ilin avqust ayından etibarən dayandıracağıq, bundan sonra nümunələrinizi təkmilləşdirə bilməyəcəksiniz. Beta testində olan, heç bir sənədi, miqrasiya yolu olmayan və bizim xeyirxah köməyimizlə əvvəllər köhnəlmiş ən son versiyaya təkmilləşdirməyi tövsiyə edirik.
Biz bu dəyişikliyin Google Bulud platformasının bütün istifadəçilərinə minimal təsir göstərməsini təmin etməyə sadiqik.
Əbədi ən yaxşı dostlar,
Google Bulud Platforması
Amma mən demək olar ki, heç vaxt belə məktubları oxumuram, çünki əslində deyirlər:
Hörmətli alıcı,
Cəhənnəm ol. Siksin, siksin, siksin. Etdiyiniz hər şeyi buraxın, çünki əhəmiyyəti yoxdur. Əhəmiyyətli olan vaxtımızdır. Biz öz axmaqlığımızı saxlamaq üçün vaxt və pul itiririk və bundan bezmişik, ona görə də daha onu dəstəkləməyəcəyik. Odur ki, öz lanet planlarınızdan əl çəkin və bizim çirkin sənədlərimizi qazmağa başlayın, forumlarda qırıntılar üçün yalvarın və yeri gəlmişkən, bizim yeni işimiz köhnə şeylərdən tamamilə fərqlidir, çünki biz bu dizaynı olduqca pis pozmuşuq, heh, amma bu sizin problem bizim deyil.
Bütün inkişaflarınızın bir il ərzində yararsız hala düşməsini təmin etmək üçün səy göstərməyə davam edirik.
Xahiş edirəm sikişin
Google Bulud Platforması
Fakt budur ki, ayda bir dəfə belə məktublar alıram. Bu, o qədər tez-tez və o qədər davamlı olur ki, qaçılmazdır itələdi Mən GCP-dən bulud əleyhinə düşərgəyə. Mən artıq onların mülkiyyət inkişaflarından asılı olmağa razı deyiləm, çünki əslində devoplar üçün “köhnəlmiş” məhsulların bağlanması siyasəti ilə Google ilə ayaqlaşmağa çalışmaqdansa, açıq mənbə sistemini çılpaq virtual maşında saxlamaq daha asandır.
Google Cloud-a qayıtmazdan əvvəl, çünki mən yaxın da deyil Onları tənqid etmədik, gəlin şirkətin bəzi digər sahələrdəki fəaliyyətinə baxaq. Google mühəndisləri proqram mühəndisliyi intizamı ilə fəxr edirlər və əslində problemlərə səbəb olan budur. Qürur ehtiyatsızlar üçün tələdir və bu, bir çox Google əməkdaşlarının qərarlarının həmişə doğru olduğunu və haqlı olmağın (bəzi qeyri-səlis təriflə) müştərilərin qayğısına qalmaqdan daha vacib olduğunu düşünməyə vadar edib.
Google xaricindəki digər böyük layihələrdən bəzi təsadüfi nümunələr verəcəyəm, amma ümid edirəm ki, bu nümunəni hər yerdə görəcəksən. Bu aşağıdakı kimidir: geriyə uyğunluq sistemləri onilliklər ərzində canlı və müasir saxlayır.
Geriyə uyğunluq üçün nəzərdə tutulmuş bütün uğurlu sistemlərin dizayn məqsədidir açıq istifadə, yəni açıq mənbə kodu və/və ya açıq standartlarla həyata keçirilir. Mənə elə gəlir ki, çox açıq bir şey deyirəm ki, hamı hətta narahatdır, amma yox. Bu, siyasi məsələdir, ona görə də nümunələrə ehtiyac var.
Seçəcəyim ilk sistem ən köhnə sistemdir: Windows Notepad, OS nüvəsi və Beynəlxalq Kosmik Stansiya arasında bir növ hibrid olan GNU Emacs. Bunu izah etmək bir az çətindir, amma qısaca desək, Emacs sizi daha məhsuldar etmək üçün proqramlaşdırma üçün 1976-cı ildə (bəli, demək olar ki, yarım əsr əvvəl) yaradılmış, lakin mətn redaktoru kimi maskalanan platformadır.
Mən hər gün Emacs istifadə edirəm. Bəli, mən də hər gün IntelliJ-dən istifadə edirəm, o, özlüyündə güclü alət platformasına çevrildi. Ancaq IntelliJ üçün genişləndirmələrin yazılması Emacs üçün genişləndirmələr yazmaqdan daha iddialı və mürəkkəb bir işdir. Və daha da əhəmiyyətlisi, Emacs üçün yazılmış hər şey qorunur sonsuzdur.
Mən hələ 1995-ci ildə Emacs üçün yazdığım proqram təminatından istifadə edirəm. Və əminəm ki, kimsə əvvəllər olmasa da, 80-ci illərin ortalarında Emacs üçün yazılmış modullardan istifadə edir. Onlar zaman zaman bir az düzəliş tələb edə bilər, lakin bu, həqiqətən olduqca nadirdir. Mən Emacs üçün yazdığım (və çox şeylər yazmışam) yenidən arxitektura tələb edən heç nə bilmirəm.
Emacs köhnəlmiş obyektlər üçün köhnəlmiş funksiyaya malikdir. Fundamental kompüter anlayışları üçün Emacs terminologiyası (məsələn, "pəncərə" nədir) tez-tez sənaye konvensiyalarından fərqlənir, çünki Emacs onları çoxdan təqdim etmişdir. Bu, vaxtını qabaqlayanlar üçün tipik bir təhlükədir: bütün şərtləriniz yanlışdır. Lakin Emacs-ın öz jarqonunda adlandırılan köhnəlmə anlayışı var köhnəlmə.
Ancaq Emacs dünyasında fərqli bir iş tərifi var. İstəsəniz, fərqli bir təməl fəlsəfə.
Emacs dünyasında (və aşağıda əhatə edəcəyimiz bir çox başqa sahələrdə) köhnəlmiş API statusu əsasən o deməkdir ki: “Siz həqiqətən bu yanaşmadan istifadə etməməlisiniz, çünki o işləyərkən o, müxtəlif çatışmazlıqlardan əziyyət çəkir ki, bizim burada siyahı. Ancaq günün sonunda bu, sizin seçiminizdir”.
Google dünyasında köhnəlmiş olmaq "sizə qarşı öhdəliyimizi pozmuşuq" deməkdir. Bu doğrudur. Bunun mahiyyət etibarı ilə mənası budur. Bu o deməkdir ki, sizi məcbur edəcəklər müntəzəm olaraq onlara inanmağın cəzası olaraq bəzi iş, bəlkə də çox iş görmək : Ən yaxşı proqram təminatına sahibik. Ən tez! Təlimatlara uyğun olaraq hər şeyi edirsiniz, tətbiqinizi və ya xidmətinizi işə salın və sonra bam, bir-iki ildən sonra pozulur.
1500 km-dən sonra mütləq xarab olacaq işlənmiş maşını satmaq kimidir.
Bunlar “köhnəlmə”nin tamamilə fərqli iki fəlsəfi tərifidir. Google-un qoxu tərifi . Mən buna inanmıram əslində planlaşdırılmış köhnəlmə Apple ilə eyni mənada. Ancaq Google, proqramlarınızı dairəvi şəkildə pozmağı planlaşdırır. Mən bunu bilirəm, çünki orada 12 ildən çox proqram mühəndisi kimi işləmişəm. Onların geriyə uyğunluğun nə qədər izlənilməsi ilə bağlı qeyri-müəyyən daxili təlimatları var, lakin bu, hər bir fərdi komandadan və ya xidmətdən asılıdır. Müəssisə və ya mühəndislik səviyyəsində tövsiyələr yoxdur və köhnəlmə dövrləri baxımından ən cəsarətli tövsiyə "müştərilərə bütün sistemini sındırmazdan əvvəl yeniləmək üçün 6-12 ay vaxt verməyə çalışın".
Problem onların düşündüklərindən qat-qat böyükdür və müştəri qayğısı onların DNT-sində olmadığı üçün bu, uzun illər davam edəcək. Aşağıda bu barədə ətraflı.
Bu nöqtədə mən cəsarətli bir bəyanat verəcəyəm ki, Emacs böyük ölçüdə və hətta uğurludur əsasən çünki onlar geriyə uyğunluğu çox ciddi qəbul edirlər. Əslində məqaləmizin tezisi budur. Uğurlu, uzunömürlü açıq sistemlər uğurlarını onilliklər boyu ətraflarında yaşayan mikro icmalara borcludurlar. uzantılar/pluginlər. Bu ekosistemdir. Mən artıq platformaların təbiəti və onların nə qədər vacib olması və Google-un bütün korporativ tarixində heç vaxt Android və ya Chrome xaricində uğurlu açıq platforma yaratmağın nə olduğunu başa düşmədiyi barədə danışmışam.
Əslində, Android-i qısaca qeyd etməliyəm, çünki yəqin ki, bu barədə düşünürsünüz.
Birincisi, Android Google deyil. Onların bir-biri ilə demək olar ki, heç bir ortaqlığı yoxdur. Android, 2005-ci ilin iyulunda Google tərəfindən satın alınan bir şirkətdir, şirkətə az-çox muxtar işləməyə icazə verildi və keçən illər ərzində faktiki olaraq toxunulmaz qaldı. Android bədnam texnoloji yığın və eyni dərəcədə bədnam tikanlı bir təşkilatdır. Bir Google işçisinin dediyi kimi, "Siz sadəcə Android-ə daxil ola bilməzsiniz."
Əvvəlki məqalədə Android-in bəzi ilkin dizayn qərarlarının nə qədər pis olduğunu müzakirə etdim. Heck, mən o məqaləni yazanda onlar indi (sürpriz!) , və Google-a qulaq asmaq və məzmununuzu bu ani tətbiqlərə köçürmək üçün kifayət qədər axmaq idinizsə, mən sizə rəğbət bəsləyirəm.
Ancaq burada bir fərq var, əhəmiyyətli bir fərq, odur ki, Android insanlar həqiqətən platformaların nə qədər vacib olduğunu başa düşürlər, köhnə Android proqramlarını işləmək üçün əllərindən gələni edirlər. Əslində, onların geriyə uyğun uyğunluğu saxlamaq səyləri o qədər hədsizdir ki, hətta mən bir neçə il əvvəl Android bölməsində qısa müddət ərzində işlədiyim müddətdə onları ən qədim cihazlar və API-lərə dəstəyi dayandırmağa inandırmağa çalışırdım (səhv etmişəm). , keçmişdə və indiki bir çox başqa şeylərdə olduğu kimi. Üzr istəyirik, Android istifadəçiləri! İndi İndoneziyada olduğum üçün onlara nə üçün ehtiyacımız olduğunu başa düşürəm).
Android insanları geriyə uyğunluğu demək olar ki, ağlasığmaz həddə çatdırır, sistemlərində və alət zəncirlərində böyük miqdarda köhnə texniki borc toplayır. Aman tanrım, onların quruluş sistemlərində etməli olduqları bəzi çılğın şeyləri görməlisən, hamısı uyğunluq adına.
Bunun üçün mən Android-ə çox arzulanan "Sən Google deyilsən" mükafatını verirəm. Onlar həqiqətən də Android-dən başqa, davamlı platformalar yaratmağı bilməyən Google olmaq istəmirlər bilir, bunu necə etmək olar. Beləliklə, Google bir baxımdan çox ağıllıdır: insanlara Android-də hər şeyi öz istədikləri kimi etməyə imkan verir.
Bununla belə, Android üçün ani proqramlar olduqca axmaq bir fikir idi. Və bilirsən niyə? Çünki tələb edirdilər tətbiqinizi yenidən yazın və yenidən dizayn edin! Sanki insanlar sadəcə olaraq iki milyon ərizəni yenidən yazacaqlar. Güman edirəm ki, Instant Apps bəzi Google işçilərinin ideyası olub.
Amma bir fərq var. Geriyə uyğunluq yüksək qiymətə başa gəlir. Bu xərclərin yükünü Android özü daşıyır, Google isə bu yükü öz üzərinə götürməkdə israr edir sizsiniz, ödəniş edən müştəri.
Siz API-lərində Android-in geriyə uyğunluq öhdəliyini görə bilərsiniz. Dörd və ya beş müxtəlif alt sisteminiz sözün həqiqi mənasında eyni şeyi edəndə, bu, əsasda geriyə uyğunluq öhdəliyinin olduğuna əmin bir işarədir. Hansı ki, platformalar dünyasında müştərilərinizə və bazarınıza bağlılıq ilə sinonimdir.
Google-un burada əsas problemi onların mühəndislik gigiyenasında qürur duymalarıdır. Eyni şeyi etmək üçün bir çox müxtəlif yollar olduqda, köhnə, daha az arzuolunan yolların yeni, daha həvəskar yolların yanında oturması xoşuna gəlmir. Bu, sistemdə yeni olanlar üçün öyrənmə əyrisini artırır, köhnə API-lərin saxlanması yükünü artırır, yeni funksiyaların sürətini ləngidir və əsas günah odur ki, gözəl deyil. Google - Tim Burtonun Alisa möcüzələr ölkəsindəki Lady Ascot kimi:
Xanım Ascot:
- Alisa, bilirsən ən çox nədən qorxuram?
- Aristokratiyanın tənəzzülü?
- Mən qorxurdum ki, məndə olacaq çirkin nəvələr.
Gözəl və praktiki arasındakı fərqi başa düşmək üçün gəlin üçüncü uğurlu platformaya (Emacs və Android-dən sonra) nəzər salaq və onun necə işlədiyini görək: Java-nın özü.
Java-da bir çox köhnəlmiş API var. Depresiya Java proqramçıları arasında çox populyardır, hətta əksər proqramlaşdırma dillərindən daha populyardır. Java-nın özü, əsas dil və kitabxanalar daim API-ləri ləğv edir.
Minlərlə misaldan yalnız birini götürsək, köhnəlmiş hesab olunur. 1.2-ci ilin dekabrında Java 1998-nin buraxılmasından sonra o, köhnəlmişdir. Bunun köhnəlməsindən 22 il keçdi.
Ancaq istehsaldakı faktiki kodum hələ də ipləri öldürür hər gün. Sizcə, həqiqətən yaxşıdır? Mütləq! Yəni, təbii ki, kodu bu gün yenidən yazsaydım, başqa cür həyata keçirərdim. Ancaq son iki onillikdə yüz minlərlə insanı sevindirən oyunumun kodu çox uzun asılan ipləri bağlamaq funksiyası ilə yazılmışdır və mən heç vaxt dəyişməli deyildi. Mən sistemimi hamıdan yaxşı bilirəm, istehsalda onunla işləmək üçün sözün əsl mənasında 25 illik təcrübəm var və əminliklə deyə bilərəm: mənim vəziyyətimdə bu xüsusi işçi iplərini bağlamaq tamamilə zərərsiz. Bu kodu yenidən yazmağa vaxt və səy sərf etməyə dəyməz və Oracle məni onu yenidən yazmağa məcbur etmədiyi üçün Larri Ellisona (yəqin ki) təşəkkür edirəm.
Oracle yəqin ki, platformaları da başa düşür. Kim bilir.
Kanyondakı buzlaq xətləri kimi köhnəlmə dalğaları ilə dolu olan əsas Java API-lərində sübutlar tapıla bilər. Java Swing kitabxanasında beş və ya altı müxtəlif klaviatura naviqasiya menecerini (KeyboardFocusManager) asanlıqla tapa bilərsiniz. Köhnəlməyən Java API tapmaq həqiqətən çətindir. Ancaq yenə də işləyirlər! Düşünürəm ki, Java komandası yalnız interfeys açıq bir təhlükəsizlik problemi yaratsa, API-ni həqiqətən siləcək.
Məsələ burasındadır, insanlar: Biz proqram tərtibatçıları hamımız çox məşğuluq və proqram təminatının hər sahəsində rəqabətli alternativlərlə qarşılaşırıq. İstənilən vaxt X dilində proqramçılar Y dilini mümkün bir əvəz kimi nəzərdən keçirirlər. Oh, mənə inanmırsan? Siz onu Swift adlandırmaq istəyirsiniz? Hamı Swift-ə köçür və heç kim onu tərk etmir, elə deyilmi? Vay, nə qədər az bilirsən. Şirkətlər ikili mobil inkişaf komandalarının (iOS və Android) xərclərini hesablayır - və onlar Flutter və React Native kimi gülməli adları olan platformalararası inkişaf sistemlərinin həqiqətən işlədiyini və onların ölçüsünü azaltmaq üçün istifadə oluna biləcəyini başa düşməyə başlayırlar. mobil qrupları iki dəfə və ya əksinə, iki dəfə məhsuldar edir. Təhlükədə real pul var. Bəli, kompromislər var, amma digər tərəfdən pul.
Gəlin fərz edək ki, Apple axmaqcasına Guido van Rossum-dan nümunə götürdü və Python 6.0-ün Python 5.0 ilə uyğunsuz olduğu kimi Swift 3-ın Swift 2 ilə geriyə uyğun olmadığını bəyan etdi.
Yəqin ki, mən bu hekayəni təxminən on il əvvəl danışmışam, lakin təxminən on beş il əvvəl Guido ilə O'Reilly's Foo Düşərgəsinə getdim, Paul Graham ilə bir çadırda oturdum və bir dəstə böyük kadr. Biz qaynar istidə oturub Larri Peycin şəxsi vertolyotunda uçmasını gözləyirdik, Guido isə hər kəsin oraya köçməsi üçün lazım olan illərin sayına görə adlandırdığı “Python 3000” haqqında pilotsuz uçuş apararkən. Biz ondan niyə uyğunluğu pozduğunu soruşduq və o cavab verdi: “Unicode”. Və soruşduq ki, kodumuzu yenidən yazmalı olsaq, başqa hansı faydaları görəcəyik? Və "Yooooooooooooooouuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuooooooooooooooooooode cavab verdi."
Google Bulud Platforması SDK (“gcloud”) quraşdırsanız, aşağıdakı bildirişi alacaqsınız:
Hörmətli alıcı,
Sizə xatırlatmaq istərdik ki, Python 2 üçün dəstək ləğv edilib, ona görə də sikin
… və s. Həyat dairəsi.
Amma məsələ ondadır ki, hər bir tərtibatçının seçimi var. Əgər onları tez-tez kodu yenidən yazmağa məcbur etsəniz, onlar düşünə bilərlər digər seçimlər. Onların olmasını nə qədər istəsən də, onlar sənin girovların deyillər. Onlar sizin qonaqlarınızdır. Python hələ də çox populyar proqramlaşdırma dilidir, lakin lənətə gəlsin ki, Python 3(000) özündə, icmalarında və icmalarının istifadəçiləri arasında elə bir qarışıqlıq yaratdı ki, nəticələr on beş il ərzində aradan qaldırılmayıb.
Bu geriyə doğru uyğunsuzluğa görə Go-da (yaxud Ruby və ya başqa bir alternativdə) neçə Python proqramı yenidən yazılmışdır? Python-dan başqa bir şeydə nə qədər yeni proqramlar yazılmış olsa da ola bilər Pythonda yazılmış, Guido bütün kəndi yandırmasaydı? Bunu söyləmək çətindir, lakin Python açıq şəkildə əziyyət çəkdi. Bu, böyük bir qarışıqlıqdır və hamı itirir.
Beləliklə, deyək ki, Apple Guido-dan nümunə götürür və uyğunluğu pozur. Sizcə bundan sonra nə olacaq? Yaxşı, bəlkə tərtibatçıların 80-90% -i mümkünsə proqram təminatını yenidən yazacaq. Başqa sözlə, istifadəçi bazasının 10-20%-i avtomatik olaraq Flutter kimi bəzi rəqabətli dillərə keçir.
Bunu bir neçə dəfə edin və istifadəçi bazanızın yarısını itirəcəksiniz. İdmanda olduğu kimi, proqramlaşdırma dünyasında da cari forma vacibdir. всё. Beş il ərzində istifadəçilərinin yarısını itirən hər kəs Böyük Yağ itirən hesab ediləcək. Platformalar dünyasında dəbdə olmalısınız. Ancaq burada köhnə versiyaları dəstəkləməmək zamanla sizi məhv edəcək. Çünki hər dəfə bəzi tərtibatçılardan qurtulanda siz (a) müqaviləni pozduğunuza görə sizə qəzəbləndikləri üçün onları həmişəlik itirirsiniz və (b) onları rəqiblərinizə verirsiniz.
Qəribədir ki, mən həm də IDE-yə bənzəyən kodun özünü avtomatlaşdırmağı və alətləməyi asanlaşdıran mənbə kodu təhlili və başa düşülmə sistemi olan Grok-u yaradanda Google-a geriyə doğru uyğunluğa məhəl qoymayan prima donna olmağa kömək etdim, lakin burada bulud xidməti böyük məlumat anbarında Google mənbə kodunun bütün milyardlarla sətirlərinin materiallaşdırılmış təsvirləri.
Grok, Google işçilərinə bütün kod bazasında (sözün bütün Google boyu) avtomatlaşdırılmış refaktorinqləri yerinə yetirmək üçün güclü bir çərçivə təqdim etdi. Sistem təkcə yuxarıdakı asılılıqlarınızı deyil (aslı olduğunuz), həm də hesablayır enən (bu sizə bağlıdır) belə ki, siz API-ləri dəyişdirdiyiniz zaman hər kəsi pozduğunuzu bilirsiniz! Beləliklə, siz dəyişikliklər etdikdə, API-nin hər bir istehlakçısının yeni versiyaya yeniləndiyini yoxlaya bilərsiniz və əslində, çox vaxt onların yazdığı Rosie aləti ilə prosesi tamamilə avtomatlaşdıra bilərsiniz.
Bu, Google-un kod bazasının daxili olaraq demək olar ki, fövqəltəbii təmiz olmasına imkan verir, çünki onların bu robot xidmətçiləri evin ətrafında fırlanır və onlar SomeDespicablyLongFunctionName adını SomeDespicablyLongMethodName olaraq dəyişdirsələr, avtomatik olaraq hər şeyi təmizləyirlər, çünki kimsə bunun çirkin nəvə olduğunu və onun yatmağa ehtiyacı olduğunu qərara alır.
Düzünü desəm, bu, Google üçün olduqca yaxşı işləyir... daxildə. Demək istəyirəm ki, bəli, Google-dakı Go icması davamlı refaktorinq vərdişlərinə görə Google-da Java icması ilə yaxşı gülür. Əgər nəyisə N dəfə yenidən işə salsanız, bu o deməkdir ki, siz onu nəinki N-1 dəfə sındırdınız, həm də bir müddət sonra məlum olur ki, yəqin ki, N-ci cəhddə də onu batırmısınız. Lakin, ümumiyyətlə, onlar bütün bu təlaşın üstündə qalırlar və kodu "təmiz" saxlayırlar.
Problem onların bulud müştərilərinə və digər API istifadəçilərinə bu münasibəti tətbiq etməyə çalışdıqları zaman başlayır.
Mən sizi Emacs, Android və Java ilə bir az tanış etdim; ən son uğurlu uzunömürlü platformaya baxaq: Vebin özü. Təsəvvür edə bilərsinizmi ki, 1995-ci ildən biz yanıb-sönən teqlərdən istifadə etdikdən sonra HTTP neçə təkrarlamadan keçib? və veb-səhifələrdə "Tikinti mərhələsində" ikonları.
Ancaq yenə də işləyir! Və bu səhifələr hələ də işləyir! Bəli, uşaqlar, brauzerlər geriyə uyğunluq üzrə dünya çempionlarıdır. Chrome nadir Google platformasının başqa bir nümunəsidir və başları düzgün şəkildə bağlanır və siz də təxmin etdiyiniz kimi, Chrome Google-un qalan hissəsindən ayrı bir sandbox şirkəti kimi effektiv şəkildə fəaliyyət göstərir.
Mən həmçinin əməliyyat sistemi tərtibatçılarında olan dostlarımıza təşəkkür etmək istəyirəm: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD və s. İşin mənfi tərəfi odur ki, onlar heç bir səbəb olmadan hər zaman hər şeyi pozurlar, lakin hər hansı bir şəkildə cəmiyyət hər buraxılışda bunun ətrafında olur və OS X konteynerləri hələ də tamamilə köhnəlməyib... hələ).
Amma gözləyin, deyirsiniz. Biz almaları portağallarla - Emacs/JDK/Android/Chrome kimi bir maşındakı müstəqil proqram sistemləri ilə multiserver sistemləri və bulud xidmətləri kimi API-ləri müqayisə etmirikmi?
Yaxşı, dünən bu barədə tvit yazmışdım, amma Larri Uoll üslubunda (Perl proqramlaşdırma dilinin yaradıcısı – təqribən. per.) “sucks/qaydalar” prinsipi ilə sözü axtardım. Deprecated Google və Amazon developer saytlarında. AWS-də olsa da yüzlərlə GCP-dən dəfələrlə çox xidmət təklifi təqdim edən Google-un tərtibatçı sənədlərində köhnəlmə təxminən yeddi dəfə daha tez-tez qeyd olunur.
Əgər Google-da hər kəs bunu oxuyursa, o, yəqin ki, Donald Trampa bənzər qrafikləri çıxarmağa hazırdır ki, onlar əslində hər şeyi düzgün edirlər və mən “köhnəlmiş sözün xatırladılması ilə müqayisə sayı” kimi ədalətsiz müqayisələr etməməliyəm. xidmətlərin sayı" "
Lakin bütün bu illərdən sonra Google Bulud hələ də 3-cü xidmətdir (2-ci olmaq üçün uğursuz cəhd haqqında heç vaxt məqalə yazmamışam), lakin insayderlərə inanmaq lazımdırsa, onların tezliklə bu xidmətdən çıxa biləcəyi ilə bağlı bəzi narahatlıqlar var. № 4.
Mənim dissertasiyamı “sübut etmək” üçün heç bir tutarlı arqumentim yoxdur. Məndə yalnız bir tərtibatçı kimi 30 il ərzində topladığım rəngli nümunələr var. Mən bu problemin dərin fəlsəfi mahiyyətini artıq qeyd etdim; bəzi yollarla inkişaf etdirici icmalarında siyasiləşdirilir. Bəziləri buna inanır yaradıcılar platformalar uyğunluğa əhəmiyyət verməlidir, digərləri isə bunun narahatlıq doğurduğunu düşünür istifadəçi (inkişafçıların özləri). İkidən biri. Doğrudan da, ümumi problemlərin xərclərini kimin çəkəcəyinə qərar verəndə bu, siyasi məsələ deyilmi?
Deməli, bu siyasətdir. Və yəqin ki, mənim çıxışıma qəzəbli cavablar olacaq.
Kimi istifadəçi Google Bulud Platforması və iki il AWS istifadəçisi olaraq (Grab-da işləyərkən) deyə bilərəm ki, prioritetlərə gəldikdə Amazon və Google-un fəlsəfələri arasında böyük fərq var. Mən AWS-də aktiv şəkildə inkişaf etmirəm, ona görə də köhnə API-ləri nə qədər tez-tez sildiklərini çox yaxşı bilmirəm. Ancaq bunun Google-da olduğu qədər tez-tez baş vermədiyinə dair bir şübhə var. Və mən həqiqətən inanıram ki, GCP-də bu daimi mübahisə və məyusluq mənbəyi platformanın inkişafına mane olan ən böyük amillərdən biridir.
Bilirəm ki, mən artıq dəstəklənməyən GCP sistemlərinin konkret nümunələrini qeyd etməmişəm. Şəbəkələrdən tutmuş yaddaşa (Cloud SQL v1-v2), Firebase (indi tamamilə fərqli API ilə Firestore), Tətbiq Mühərriki (hətta başlayaq) kimi istifadə etdiyim demək olar ki, hər şeyi deyə bilərəm. , bulud son nöqtələri Cloud Endpoint və... Bilmirəm - tamamilə bütün bunlar sizi maksimum 2-3 ildən sonra kodu yenidən yazmağa məcbur etdi və onlar heç vaxt sizin üçün miqrasiyanı avtomatlaşdırmadılar və tez-tez . Sanki belə olmalı idi.
Və hər dəfə AWS-ə baxanda özümdən soruşuram ki, niyə hələ də GCP-dəyəm? Onların müştərilərə ehtiyacı olmadığı aydındır. Onlara ehtiyac var pokupateli. Fərqi başa düşürsən? İcazə ver izah edim.
Google Cloud var , insanların proqram həllərini təklif etdikləri yerlərdə və boş restoran effektinin qarşısını almaq üçün onu bəzi təkliflərlə doldurmalı oldular, buna görə də Bitnami adlı bir şirkətlə müqavilə bağladılar ki, onlar "bir klik" ilə yerləşdirilən və ya tətbiq edilməli olan həllər dəstəsi yaratsınlar. Mən bunu özüm “həlllər” yazıram, çünki bunlar heç bir şeyi həll etmir. Onlar sadəcə olaraq qeyd qutuları kimi, marketinq doldurucusu kimi mövcuddurlar və Google heç vaxt alətlərdən hər hansı birinin həqiqətən işlədiyinə əhəmiyyət verməmişdir. Mən sürücü kreslosunda olan məhsul menecerlərini tanıyıram və sizi əmin edə bilərəm ki, bu insanlar vecinə deyil.
Məsələn, guya “bir kliklə” yerləşdirmə həllini götürək. . Mən Google Cloud SQL şənliyindən canım qurtarmışdı, ona görə də alternativ olaraq öz Percona klasterimi qurmağa başladım. Və bu dəfə Google yaxşı iş görmüş kimi görünürdü, onlar bir düyməni basmaqla mənə bir az vaxt və səy sərf edəcəkdilər!
Əla, gedək. Linki izləyək və bu düyməni klikləyək. Bütün standart parametrlərlə razılaşmaq və klasteri Google bulud layihənizdə yerləşdirmək üçün “Bəli” seçin. Haha, işləmir. Bu cəfəngiyatın heç biri işləmir. Alət heç vaxt sınaqdan keçirilmədi və ilk dəqiqədən çürüməyə başladı və "həlllərin" yarısından çoxu bir kliklə tətbiqlər olsa, məni təəccübləndirməzdi (indi biz sitatların niyə olduğunu anladıq) ümumiyyətlə işləmir. Bu, girməməyin daha yaxşı olduğu tamamilə ümidsiz bir qaranlıqdır.
Ancaq Google haqlıdır təşviq edir siz onlardan istifadə edin. Səndən istəyirlər alıb. Onlar üçün bu, bir əməliyyatdır. Onlar heç nə istəmirlər dəstək. Bu, Google-un DNT-sinin bir hissəsi deyil. Bəli, mühəndislər bir-birlərini dəstəkləyirlər, bunu Bigtable ilə hekayəm sübut edir. Ancaq adi insanlar üçün məhsul və xidmətlərdə onlar həmişə amansız idilər , milyonlarla istifadəçisi olsa belə, gəlirlilik zolağına cavab vermir.
Və bu, GCP üçün əsl problem yaradır, çünki bu, bütün bulud təkliflərinin arxasında duran DNT-dir. Onlar heç nəyi dəstəkləməyə çalışmırlar; Məlumdur ki, onlar hər hansı üçüncü tərəf proqram təminatına sahib olmaqdan (idarə olunan xidmət kimi) imtina edirlər qədər, AWS eyni şeyi edənə və onun ətrafında uğurlu biznes qurana qədər və müştərilər sözün əsl mənasında eyni şeyi tələb edənə qədər. Bununla belə, Google-un nəyisə dəstəkləməsi üçün müəyyən səy tələb olunur.
Bu dəstək mədəniyyətinin olmaması, “gəlin onu daha da gözəlləşdirmək üçün onu sındıraq” düşüncəsi ilə birlikdə tərtibatçıları özündən uzaqlaşdırır.
Uzun ömürlü bir platforma qurmaq istəyirsinizsə, bu yaxşı bir şey deyil.
Google, oyan, lənətə gəl. İndi 2020-dir. Siz hələ də itirirsiniz. Güzgüyə diqqətlə baxmaq və həqiqətən bulud biznesində qalmaq istəyib-istəmədiyinizə cavab verməyin vaxtıdır.
O zaman qalmaq isteyirsen hər şeyi pozmağı dayandırın. Uşaqlar, siz zənginsiniz. Biz tərtibatçılar bunu etmirik. Beləliklə, uyğunluq yükünü kimin üzərinə götürəcəyinə gəldikdə, bunu özünüzə götürməlisiniz. Bizim üçün deyil.
Çünki ən azı daha üç həqiqətən yaxşı bulud var. İşarə edirlər.
İndi mən bütün pozulmuş sistemlərimi düzəltməyə davam edəcəyəm. Eh.
Növbəti dəfəyə qədər!
PS Bu məqalədəki bəzi müzakirələri oxuduqdan sonra yeniləyin (müzakirələr əladır, btw). Firebase dəstəyi dayandırılmayıb və xəbərdar olduğum heç bir plan yoxdur. Bununla belə, onların Java müştərisinin App Engine-də dayanmasına səbəb olan pis axın səhvi var. Onların mühəndislərindən biri mənə bu problemi həll etməyə kömək etdi, Google-da işləyəndə, lakin onlar heç vaxt səhvi düzəldə bilmədilər, buna görə də hər gün GAE tətbiqini yenidən başlatmaq məcburiyyətindəyəm. Və beləliklə, dörd ildir! İndi onların Firestore var. Tamamilə fərqli bir sistem olduğu üçün ona keçmək çox iş tələb edəcək və Firebase səhvi heç vaxt düzəldilməyəcək. Hansı nəticəyə gəlmək olar? yardım ala bilərsiniz bir şirkətdə işləyirsinizsə. Mən yəqin ki, GAE-də Firebase-dən istifadə edən yeganə adamam, çünki mən 100% yerli proqramda 100-dən az açar daxil oluram və məlum səhvə görə o, hər iki gündən bir işləməyi dayandırır. Öz riskinizlə istifadə etməkdən başqa nə deyə bilərəm. Mən Redis-ə keçirəm.
Bəzi daha təcrübəli AWS istifadəçilərinin AWS-nin adətən heç vaxt hər hansı bir xidməti dəstəkləməyi dayandırmadığını və SimpleDB əla nümunə olduğunu söylədiklərini gördüm. AWS-nin Google ilə eyni dəstək xəstəliyinə sahib olmadığına dair fərziyyələrim haqlı görünür.
Əlavə olaraq, 20 gün əvvəl Google App Engine komandasının əsas Go tərtibatçılarından birinin GAE proqramını bağlayaraq, kritik Go kitabxanasının hostinqini pozduğunu gördüm. Bu, həqiqətən axmaq idi.
Nəhayət, Google işçilərinin artıq bu məsələni müzakirə etdiyini və ümumiyyətlə mənimlə razılaşdıqlarını eşitmişəm (sizi sevirəm!). Lakin onlar problemin həlledilməz olduğunu düşünürlər, çünki Google mədəniyyətində heç vaxt düzgün təşviq strukturu olmayıb. Düşündüm ki, Grab-da işləyərkən AWS mühəndisləri ilə işlədiyim tamamilə heyrətamiz təcrübəni müzakirə etmək üçün bir az vaxt ayırsam yaxşı olar. Gələcəkdə bir gün ümid edirəm!
Bəli, 2005-ci ildə 43 saylı binadakı nəhəng bufetdə müxtəlif növ köpəkbalığı əti var idi və mənim ən çox sevdiyim çəkic başlı köpəkbalığı əti idi. Ancaq 2006-cı ilə qədər Larri və Sergey bütün zərərli qəlyanaltılardan qurtuldular. Beləliklə, 2007-ci ildə Bigtable hekayəsi zamanı həqiqətən köpəkbalığı yox idi və mən sizi aldatdım.
Dörd il əvvəl bulud Bigtable-a baxdığımda (ver və ya götür), bu, xərcin olduğu yerdir. Görünür, indi bir az azalıb, lakin bu, hələ də boş məlumat anbarı üçün çox böyükdür, xüsusən mənim ilk hekayəm boş böyük masanın öz miqyasında nə qədər əhəmiyyətsiz olduğunu göstərdiyinə görə.
Apple ictimaiyyətini təhqir etdiyim və Microsoft və s. haqqında xoş söz demədiyim üçün üzr istəyirik. Siz yaxşısınız, mən bu məqalənin yaratdığı bütün müzakirələri çox yüksək qiymətləndirirəm! Ancaq bəzən müzakirəyə başlamaq üçün bir az dalğalandırmaq lazımdır, bilirsinizmi?
Oxuduğunuz üçün təşəkkür edirik.
Yeniləmə 2, 19.08.2020/XNUMX/XNUMX. Zolaq !
Yeniləmə 3, 31.08.2020/2/2. Mənim köhnə dostum olduğu ortaya çıxan Cloud Marketplace-də Google mühəndisi ilə əlaqə saxladım. O, CXNUMXD-nin niyə işləmədiyini anlamaq istədi və biz sonda anladıq ki, bu, mənim şəbəkəmi illər əvvəl qurmuşam və CXNUMXD köhnə şəbəkələrdə işləmir, çünki onların şablonlarında alt şəbəkə parametri yoxdur. Düşünürəm ki, potensial GCP istifadəçiləri üçün Google-da kifayət qədər mühəndis bildiklərinə əmin olmaq daha yaxşıdır...
Mənbə: www.habr.com