لعنت ګوګل، زه نه غواړم بیا بلاګ وکړم. زه ډیر څه لرم. بلاګ کول وخت، انرژي او خلاقیت اخلي، کوم چې زه کولی شم ښه ګټه پورته کړم: زما کتابونه، زما لوبه او داسې نور. مګر تاسو ما دومره خفه کړل چې زه باید دا لیکم.
نو راځئ چې دا له منځه یوسو.
اجازه راکړئ د یوې لنډې مګر لارښوونې کیسې سره پیل کړم کله چې ما په لومړي ځل په ګوګل کې کار پیل کړ. زه پوهیږم چې زه په دې وروستیو کې د ګوګل په اړه ډیر بد شیان وایم، مګر دا ما خپه کوي کله چې زما خپل شرکت په منظمه توګه د سوداګرۍ غیر مناسب پریکړې کوي. په ورته وخت کې، موږ باید دا د هغې لامل ورکړو: د ګوګل داخلي زیربنا واقعیا غیر معمولي ده، دا خوندي ده چې ووایو چې نن ورځ هیڅ ښه نه دی. د ګوګل بنسټ ایښودونکي زما په پرتله خورا ښه انجینران وو، او دا کیسه یوازې دا حقیقت تاییدوي.
لومړی، یو کوچنی پس منظر: ګوګل د معلوماتو ذخیره کولو ټیکنالوژي لري چې نوم یې دی . دا د پام وړ تخنیکي لاسته راوړنه وه، یو له لومړیو څخه (که لومړی نه وي) د "لامحدود اندازې وړ" کلیدي ارزښت پلورنځی (K/V): په اصل کې د NoSQL پیل. پدې ورځو کې Bigtable لاهم د ډیری ډیری K/V ذخیره کولو ځای کې ښه کار کوي ، مګر په هغه وخت کې (2005) دا په زړه پوري ښه و.
د Bigtable په اړه یوه مسخره خبره دا ده چې دوی د داخلي کنټرول الوتکې توکي درلودل (د پلي کولو برخې په توګه) د ټابلیټ سرور په نوم یادیږي، د لوی شاخصونو سره، او په ځینو وختونو کې دوی د سیسټم اندازه کولو په وخت کې خنډ شو. د Bigtable انجنیران د اندازې وړتیا پلي کولو څرنګوالي په اړه حیران وو، او ناڅاپه پوه شول چې دوی کولی شي د ټابلیټ سرورونه د نورو Bigtable ذخیره کولو سره ځای په ځای کړي. نو Bigtable د Bigtable تطبیق برخه ده. دا ذخیره کولو اسانتیاوې په ټولو کچو کې شتون لري.
بل په زړه پورې توضیحات دا دي چې د یو څه مودې لپاره Bigtable په ګوګل کې مشهور او هر اړخیز شو ، د هرې ډلې سره خپل ذخیره لري. نو د جمعې په یوې غونډې کې ، لیري پیج په ناڅاپي ډول وپوښتل: "ولې موږ له یو څخه ډیر لوی میز لرو؟ ولې یوازې یو نه؟" په تیوري کې، یو ذخیره باید د ګوګل د ذخیره کولو اړتیاو لپاره کافي وي. البته، دوی هیڅکله د عملي پراختیا دلایلو لپاره یوازې یو ته نه دي تللي (لکه د احتمالي ناکامۍ پایلې) ، مګر تیوري په زړه پوري وه. د ټول کائنات لپاره یو ذخیره (په لاره کې، ایا څوک پوهیږي که ایمیزون دا د دوی سیبل سره کړي؟)
په هرصورت، دلته زما کیسه ده.
په هغه وخت کې، ما په ګوګل کې یوازې د دوو کلونو لپاره کار کاوه، او یوه ورځ ما د Bigtable انجینرۍ ټیم څخه یو بریښنالیک ترلاسه کړ چې داسې یو څه و:
ګران سټیو،
د Bigtable ټیم څخه سلام. موږ غواړو تاسو ته خبر درکړو چې په [د ډیټا مرکز نوم] کې تاسو یو خورا زوړ لوی لوی بائنری کاروئ. دا نسخه نور ملاتړ نه کوي او موږ غواړو تاسو سره وروستي نسخې ته لوړولو کې مرسته وکړو.
مهرباني وکړئ ما ته خبر راکړئ که تاسو پدې مسله کې یوځای کار کولو لپاره یو څه وخت تنظیم کولی شئ.
بریالیتوب مو غواړم،
د لوی میز ټیم
په ګوګل کې تاسو ډیری بریښنالیکونه ترلاسه کوئ، نو په لومړي نظر کې ما داسې یو څه لوستل:
ګرانه اخیستونکی،
د ځینې ټیم څخه سلام. موږ غواړو چې دا خبرې وکړو بله بله بله بله. بله بله بله بله بله بله بله بله بلا سمدستي.
مهرباني وکړئ موږ ته خبر راکړئ که تاسو کولی شئ خپل قیمتي وخت د بلا بله بله لپاره مهالویش کړئ.
بریالیتوب مو غواړم،
یو ډول امر
ما دا تقریبا سمدلاسه حذف کړ ، مګر زما د شعور په څنډه کې ما یو دردناک ، ناخوښه احساس احساس کړ چې دا نه که څه هم د رسمي لیک په څیر ښکاري ښکاره ده، چې ترلاسه کوونکی غلط شوی و ځکه چې ما Bigtable نه دی کارولی.
خو عجيبه وه.
ما د ورځې پاتې برخه په بدیل سره د کار په اړه په فکر کې تیره کړه او په مایکرو پخلنځي کې د شارک څه ډول غوښه هڅه وکړم، چې لږترلږه درې یې دومره نږدې وو چې زما له څوکۍ څخه د بسکټ په ښه هدف سره ووهل شو، مګر د لیکلو فکر هیڅکله ما د مخ په زیاتیدونکي احساس لږ اضطراب سره نه پریږدي.
دوی په ښکاره ډول زما نوم وویل. او بریښنالیک زما بریښنالیک ته لیږل شوی و، نه د بل چا، او دا cc: یا bcc: نه دی. ټون خورا شخصي او روښانه دی. شاید دا یو ډول غلطی وي؟
په نهایت کې ، تجسس زما څخه ښه شو او زه د ډیټا مرکز کې د بورګ کنسول لیدو ته لاړم چې دوی یې یادونه کړې.
او البته، ما د مدیریت لاندې BigTable ذخیره درلوده. زه بخښنه غواړم، څه؟ ما د هغې مینځپانګې ته وکتل ، او واه! دا د کوډیلاب انکیوبټر څخه و چې زه د 2005 په جون کې په ګوګل کې زما د لومړۍ اونۍ په جریان کې ناست وم. کوډیلاب دې ته اړ کړ چې Bigtable پرمخ بوځي ترڅو هلته ځینې ارزښتونه ولیکئ، او ما په ښکاره ډول هیڅکله وروسته ذخیره بنده نه کړه. دا لا تر اوسه کار کوي که څه هم دوه کاله تیر شوي.
په دې کیسه کې څو د پام وړ اړخونه شتون لري. لومړی، د Bigtable کار د ګوګل په کچه خورا مهم و چې یوازې دوه کاله وروسته چا د اضافي ذخیره کولو یادونه وکړه، او یوازې د دې لپاره چې د بائنری نسخه پخوانۍ وه. د پرتله کولو لپاره، ما یو ځل د کارولو په اړه فکر وکړ زما د آنلاین لوبې لپاره. په هغه وخت کې، دا خدمت په کال کې نږدې $ 16 لګښت لري. خالي په GCP کې لوی میز. زه دا نه وایم چې دوی تاسو درغلي کوي ، مګر زما په شخصي نظر ، دا د خالي ډک ډیټابیس لپاره ډیرې پیسې دي.
بل د پام وړ اړخ دا دی چې ذخیره کول دوه کاله وروسته هم کار کوي. WTF؟ د معلوماتو مرکزونه راځي او ځي؛ دوی د بندیدو تجربه کوي، دوی د مهال ویش ساتنه کوي، دوی هر وخت بدلوي. هارډویر تازه شوی ، سویچونه بدل شوي ، هرڅه په دوامداره توګه ښه کیږي. دوی څنګه وتوانیدل چې زما برنامه د دې ټولو بدلونونو سره دوه کاله دوام وکړي؟ دا کیدای شي په 2020 کې د یوې معمولي لاسته راوړنې په څیر ښکاري، مګر په 2005-2007 کې دا خورا اغیزمنه وه.
او ترټولو په زړه پوری اړخ دا دی چې په یو بل ایالت کې د انجینرۍ بهرنۍ ډله ما ته نږدې کیږي ، د بیګټبل د یو څه کوچني ، نږدې خالي مثال مالک چې لري. صفر ترافیک د تیرو دوو کلونو لپاره - او د دې تازه کولو لپاره مرسته وړاندیز کوي.
ما له دوی څخه مننه وکړه، ذخیره یې حذف کړه، او ژوند د معمول په څیر روان و. خو ديارلس کاله وروسته بيا هم د هغه ليک په اړه فکر کوم. ځکه چې ځینې وختونه زه د ګوګل کلاوډ څخه ورته بریښنالیکونه ترلاسه کوم. دوی داسې ښکاري:
ګرانه د ګوګل کلاوډ کارونکي،
د یادونې په توګه، موږ به د 2020 تر اګست پورې د [ضروري خدمت چې تاسو یې کاروئ] خدمت بند کړو، له هغې وروسته به تاسو نشئ کولی خپل مثالونه لوړ کړئ. موږ وړاندیز کوو چې وروستي نسخې ته لوړ کړئ، کوم چې د بیټا ټیسټ کې دی، هیڅ اسناد نلري، د مهاجرت لاره نلري او زموږ د مهربانۍ په مرسته مخکې له مخکې زوړ شوی.
موږ ژمن یو چې ډاډ ترلاسه کړو چې دا بدلون د ګوګل کلاوډ پلیټ فارم ټولو کاروونکو باندې لږترلږه اغیزه لري.
ښه ملګري د تل لپاره،
د ګوګل کلاوډ پلیټ فارم
مګر ما تقریبا هیڅکله دا ډول لیکونه ندي لوستلي، ځکه چې دوی واقعیا څه وايي:
ګرانه اخیستونکی،
ورک شه. لعنت په تاسو، لعنت په تاسو، لعنت په تاسو. هرڅه چې تاسو یې کوئ پریږدئ ځکه چې دا مهمه نده. زموږ وخت مهم دی. موږ خپل وخت او پیسې د خپل خندا په ساتلو کې ضایع کوو او موږ له دې څخه ستړي شوي یو نو موږ به یې نور ملاتړ ونه کړو. نو خپل ناوړه پلانونه پریږدئ او زموږ د غلطو اسنادو په کیندلو پیل وکړئ ، په فورمونو کې د سکریپونو غوښتنه وکړئ ، او په هرصورت ، زموږ نوې شیټ له زاړه شیټ څخه په بشپړ ډول توپیر لري ، ځکه چې موږ دا ډیزاین خورا خراب کړی ، هو ، مګر دا ستاسو دی. ستونزه، زموږ نه.
موږ هڅو ته دوام ورکوو ترڅو ډاډ ترلاسه کړو چې ستاسو ټول پرمختګونه په یو کال کې د کار وړ نه دي.
لطفاً وخورئ
د ګوګل کلاوډ پلیټ فارم
او حقیقت دا دی چې زه په میاشت کې یو ځل دا ډول لیکونه ترلاسه کوم. دا ډیری وختونه او په دوامداره توګه پیښیږي چې دوی حتمي دي لرې کړل زه له GCP څخه د بادل ضد کمپ ته. زه نور موافق نه یم چې د دوی ملکیت پرمختګونو باندې تکیه وکړم ، ځکه چې په حقیقت کې د ډیوپس لپاره دا اسانه ده چې په خلاص مجازی ماشین کې د خلاصې سرچینې سیسټم ساتل د دې په پرتله چې د ګوګل سره د "زاړه" محصولاتو بندولو پالیسي سره ساتلو هڅه وکړي.
مخکې له دې چې زه بیرته ګوګل کلاوډ ته لاړ شم ځکه چې زه حتی نږدې نه په دوی نیوکه نه ده شوې، راځئ چې په ځینو نورو برخو کې د شرکت فعالیت وګورو. د ګوګل انجنیران ځان د خپل سافټویر انجینرۍ ډسپلین باندې ویاړي، او دا هغه څه دي چې واقعیا د ستونزو لامل کیږي. غرور د ناپوهانو لپاره یو جال دی، او دا د ګوګل ډیری کارمندان د دې لامل شوي چې فکر وکړي چې د دوی پریکړې تل سمې وي او دا سمه وي (د ځینې مبهم فجی تعریف لخوا) د پیرودونکو په اړه د پاملرنې څخه ډیر مهم دی.
زه به د ګوګل څخه بهر د نورو لویو پروژو څخه ځینې تصادفي مثالونه ورکړم، مګر زه هیله لرم چې تاسو دا نمونه هرچیرې وګورئ. دا په لاندې ډول ده: شاته مطابقت سیسټمونه د لسیزو لپاره ژوندي او تازه ساتي.
شاته مطابقت د ټولو بریالي سیسټمونو ډیزاین هدف دی چې د دې لپاره ډیزاین شوی خلاص کارول، دا د خلاصې سرچینې کوډ او/یا خلاص معیارونو سره پلي کیږي. زه داسې احساس کوم چې زه یو څه ډیر څرګند وایم چې هرڅوک حتی نارامه وي، مګر نه. دا یوه سیاسي مسله ده، نو مثالونو ته اړتیا ده.
لومړی سیسټم چې زه به یې غوره کړم ترټولو زوړ دی: GNU Emacs، کوم چې د وینډوز نوټ پیډ، د OS کرنل، او نړیوال فضا سټیشن ترمنځ یو هایبرډ دی. د دې تشریح کول یو څه سخت دي ، مګر په لنډه توګه ، Emacs یو پلیټ فارم دی چې په 1976 کې رامینځته شوی (هو ، نږدې نیمه پیړۍ دمخه) د برنامو لپاره رامینځته شوی ترڅو تاسو ډیر ګټور کړي ، مګر د متن ایډیټر په توګه نقاب کول.
زه هره ورځ Emacs کاروم. هو ، زه هره ورځ IntelliJ هم کاروم ، دا په خپل حق کې د ځواکمن اوزار کولو پلیټ فارم کې وده کړې. مګر د IntelliJ لپاره توسیع لیکل د Emacs لپاره د توسیع لیکلو په پرتله خورا ډیر هوښیار او پیچلي کار دی. او تر ټولو مهم، د Emacs لپاره لیکل شوي هرڅه خوندي دي تل د.
زه لاهم هغه سافټویر کاروم چې ما په 1995 کې د ایماکس لپاره لیکلی و. او زه ډاډه یم چې څوک د 80s په مینځ کې د Emacs لپاره لیکل شوي ماډلونه کاروي ، که مخکې نه وي. دوی ممکن وخت په وخت یو څه ټیک کولو ته اړتیا ولري ، مګر دا واقعیا خورا نادر دی. زه د هغه څه په اړه نه پوهیږم چې ما کله هم د ایماکس لپاره لیکلی دی (او ما ډیر څه لیکلي دي) چې بیا جوړښت ته اړتیا لري.
Emacs یو فعالیت لري چې د متروک نهادونو لپاره د میک ابسولیټ په نوم یادیږي. د بنسټیز کمپیوټر مفاهیمو لپاره د Emacs اصطلاحات (لکه "کړکۍ" څه شی دی) اکثرا د صنعت کنوانسیونونو سره توپیر لري ځکه چې Emacs دوی ډیر دمخه معرفي کړي. دا د هغو کسانو لپاره یو عام خطر دی چې د خپل وخت څخه مخکې دي: ستاسو ټول شرایط غلط دي. مګر Emacs د تخریب مفهوم لري، کوم چې د دوی په اصطلاح کې ویل کیږي زوړوالی.
مګر د Emacs نړۍ کې داسې بریښي چې مختلف کاري تعریف وي. یو بل بنسټیز فلسفه، که تاسو غواړئ.
د Emacs نړۍ کې (او په ډیری نورو برخو کې ، چې موږ به یې لاندې پوښو) ، د تخریب شوي API حالت اساسا پدې معنی دی: "تاسو واقعیا باید دا طریقه ونه کاروئ ، ځکه چې دا کار کوي ، دا د مختلف نیمګړتیاو سره مخ کیږي چې موږ یې کوو. لیست دلته. مګر د ورځې په پای کې، دا ستاسو انتخاب دی."
د ګوګل په نړۍ کې، د متروک کیدو معنی دا ده، "موږ له تاسو سره زموږ د ژمنې څخه سرغړونه کوو." دا رشتېا ده. دا هغه څه دي چې اصلي معنی لري. دا پدې مانا ده چې دوی به تاسو مجبور کړي په منظمه توګه یو څه کار وکړئ، شاید ډیر کار، د دوی د باور کولو سزا په توګه : موږ غوره سافټویر لرو. تر ټولو چټک! تاسو هر څه د لارښوونو سره سم ترسره کوئ، خپل غوښتنلیک یا خدمت پیل کړئ، او بیا بام، یو یا دوه کاله وروسته دا ماتیږي.
دا د یو کارول شوي موټر پلورلو په څیر دی چې یقینا به 1500 کیلومتره وروسته مات شي.
دا د "متروکتوب" دوه بشپړ مختلف فلسفي تعریفونه دي. د بوی د ګوګل تعریف . زه پدې باور نه لرم په حقیقت کې د ایپل په څیر په ورته معنی کې پلان شوي ناپاکتوب. مګر ګوګل یقینا پلان لري چې ستاسو برنامه مات کړي ، په ګردي لارې کې. زه دا پوهیږم ځکه چې ما هلته د 12 کلونو لپاره د سافټویر انجینر په توګه کار کړی. دوی مبهم داخلي لارښوونې لري چې څومره شاته مطابقت باید تعقیب شي، مګر دا په نهایت کې د هر انفرادي ټیم یا خدمت پورې اړه لري. دلته د تصدۍ یا انجینرۍ کچې وړاندیزونه شتون نلري ، او د ناڅرګندتیا دورې په شرایطو کې ترټولو زړور وړاندیز دا دی چې "هڅه وکړئ پیرودونکو ته 6-12 میاشتې ورکړئ ترڅو د دوی ټول سیسټم ماتولو دمخه نوي کړي."
ستونزه د دوی فکر کولو په پرتله خورا لویه ده، او دا به د راتلونکو کلونو لپاره دوام ومومي ځکه چې د پیرودونکو پاملرنه د دوی په DNA کې ندي. لاندې په دې اړه نور.
پدې مرحله کې زه به یو زړور بیان وکړم چې ایماکس تر ډیره حده بریالی دی او حتی په لومړي سر کې ځکه چې دوی شاته مطابقت په جدي توګه اخلي. په حقیقت کې، دا زموږ د مقالې مقاله ده. بریالي، اوږدمهاله خلاص سیسټمونه د دوی بریالیتوب د کوچنیو ټولنو لپاره دی چې د لسیزو راهیسې د دوی شاوخوا ژوند کوي. تمدیدونه/پلگ ان. دا ایکوسیستم دی. ما دمخه د پلیټ فارمونو طبیعت په اړه خبرې کړې او دا څومره مهم دي ، او څنګه ګوګل هیڅکله په خپل ټول کارپوریټ تاریخ کې نه پوهیږي چې د Android یا کروم څخه بهر د بریالي خلاص پلیټ فارم رامینځته کولو کې څه پیښیږي.
په حقیقت کې ، زه باید په لنډ ډول د Android یادونه وکړم ځکه چې تاسو شاید د دې په اړه فکر کوئ.
لومړی، Android ګوګل نه دی. دوی د یو بل سره تقریبا هیڅ شی نلري. انډرایډ یو شرکت دی چې د 2005 په جولای کې د ګوګل لخوا پیرودل شوی و، شرکت ته اجازه ورکړل شوې وه چې لږ یا لږ په خپلواکه توګه کار وکړي او په حقیقت کې په منځنیو کلونو کې په لویه کچه ناڅرګنده پاتې شوه. انډرایډ یو بدنام ټیک سټیک او په مساوي ډول بدنام کاندي سازمان دی. لکه څنګه چې یو ګوګلر وویل، "تاسو یوازې په Android کې ننوتل نشئ کولی."
په تیره مقاله کې ، ما بحث وکړ چې د Android ځینې لومړني ډیزاین پریکړې څومره خرابې وې. هیک ، کله چې ما دا مقاله لیکلې دوی د "انسټنټ ایپس" په نوم کریپ رامینځته کوي کوم چې اوس دي (حیرانتیا!) ، او زه خواخوږي لرم که تاسو دومره احمق یاست چې ګوګل ته غوږ شئ او خپل مینځپانګه دې فوري ایپسونو ته واړوئ.
مګر دلته یو توپیر شتون لري، د پام وړ توپیر دا دی چې د Android خلک واقعیا پوهیږي چې پلیټ فارمونه څومره مهم دي، دوی هڅه کوي چې زاړه Android ایپسونه کار وکړي. په حقیقت کې ، د شاته مطابقت ساتلو لپاره د دوی هڅې خورا سختې دي چې حتی ما څو کاله دمخه د Android ډیویژن کې زما د لنډې مودې په جریان کې ، ځان وموند چې دوی قانع کړم چې د ځینې پخوانیو وسیلو او APIs ملاتړ پریږدي (زه غلط وم. لکه څنګه چې په تیرو او اوسنیو نورو ډیرو شیانو کې وو. بخښنه د Android ملګرو! اوس چې زه اندونیزیا ته تللی یم، زه پوهیږم چې ولې موږ ورته اړتیا لرو).
د Android خلک شاته مطابقت شاوخوا د تصور وړ حد ته اړوي، د دوی سیسټمونو او اوزار چینونو کې د میراث تخنیکي پورونو لوی مقدار راټولوي. اوه زما خدایه ، تاسو باید ځینې لیوني شیان وګورئ چې دوی یې د دوی په جوړ شوي سیسټم کې کوي ، ټول د مطابقت په نوم.
د دې لپاره، زه Android ته د پام وړ "تاسو ګوګل نه یاست" جایزه ورکړم. دوی واقعیا نه غواړي ګوګل شي ، کوم چې نه پوهیږي چې څنګه دوامداره پلیټ فارمونه رامینځته کړي ، مګر Android پوهيږي، دا څنګه وکړو. او له همدې امله ګوګل په یوه برخه کې خورا هوښیار دی: خلکو ته اجازه ورکوي چې په Android کې خپل کارونه ترسره کړي.
په هرصورت، د Android لپاره فوري ایپس یو ډیر احمقانه نظر و. او پوهېږې ولې؟ ځکه چې دوی غوښتل خپل غوښتنلیک بیا ولیکئ او بیا ډیزاین کړئ! دا داسې ده چې خلک به په ساده ډول دوه ملیونه غوښتنلیکونه بیا لیکي. زه اټکل کوم چې فوري ایپس د ګوګلر نظر و.
مګر یو توپیر شتون لري. شاته مطابقت په لوړ لګښت راځي. انډرایډ پخپله د دې لګښتونو بار په غاړه لري، پداسې حال کې چې ګوګل ټینګار کوي چې دا بار باید واخیستل شي ته یې، د پیرودونکي تادیه کول.
تاسو کولی شئ د دې APIs کې د شاته مطابقت لپاره د Android ژمنتیا وګورئ. کله چې تاسو څلور یا پنځه مختلف فرعي سیسټمونه په لفظي ډول ورته کار کوئ، دا یو ډاډمن نښه ده چې په اصلي کې د شاته مطابقت لپاره ژمنتیا شتون لري. کوم چې د پلیټ فارمونو نړۍ کې ستاسو پیرودونکو او ستاسو بازار ته ژمنتیا سره مترادف دی.
د ګوګل اصلي ستونزه دلته د دوی انجینري حفظ الصحه کې د دوی ویاړ دی. دوی دا نه خوښوي کله چې د ورته کار کولو لپاره ډیری مختلفې لارې شتون ولري ، د زړو ، لږ مطلوب لارو سره د نوي ، غوره لارو تر څنګ ناست وي. دا سیسټم ته د نويو کسانو لپاره د زده کړې وکر زیاتوي، دا د میراث APIs ساتلو بار زیاتوي، دا د نویو ځانګړتیاوو سرعت ورو کوي، او اصلي ګناه دا ده چې دا ښکلی نه دی. ګوګل - لکه لیډي اسکاټ د ټیم برټن ایلیس څخه په ونڈرلینډ کې:
میرمن اسکاټ:
- الیس، ایا ته پوهیږې چې زه له څه څخه ډیر ډارېږم؟
- د اشرافو زوال؟
- زه ډاریدم چې زه به یې لرم بدمرغه لمسیان.
د ښکلي او عملي ترمینځ د سوداګرۍ پوهیدو لپاره ، راځئ چې دریم بریالي پلیټ فارم (د Emacs او Android وروسته) ته یو نظر وګورو او وګورو چې دا څنګه کار کوي: پخپله جاوا.
جاوا ډیری زاړه APIs لري. محرومیت د جاوا پروګرامرانو ترمنځ خورا مشهور دی، حتی د ډیری پروګرامینګ ژبو په پرتله خورا مشهور دی. جاوا پخپله، اصلي ژبه، او کتابتونونه په دوامداره توګه د APIs تخریب کوي.
د زرګونو مثالونو څخه یوازې یو واخلو، متروک ګڼل کیږي. دا د دسمبر په 1.2 کې د جاوا 1998 خوشې کیدو راهیسې له مینځه وړل شوی. دا 22 کاله کیږي چې دا له مینځه وړل شوی.
مګر په تولید کې زما اصلي کوډ لاهم تارونه وژني هره ورځ. ایا تاسو واقعیا فکر کوئ چې دا ښه دی؟ بالکل! زما مطلب دی، البته، که زه نن ورځ کوډ بیا لیکم، زه به یې په بل ډول پلي کړم. مګر زما د لوبې لپاره کوډ، چې په تیرو دوو لسیزو کې یې په سلګونو زره خلک خوښ کړي، د داسې فنکشن سره لیکل شوي ترڅو تارونه بند کړي چې ډیر اوږد ځړیږي، او زه هیڅکله یې بدلون نه درلود. زه خپل سیسټم د هرچا په پرتله ښه پیژنم، زه په حقیقت کې د دې سره په تولید کې د کار کولو 25 کاله تجربه لرم، او زه کولی شم په ډاډ سره ووایم: زما په قضیه کې، د دې ځانګړي کارګر تارونو تړل په بشپړ ډول دي. بې ضرر. دا د دې کوډ د بیا لیکلو لپاره د وخت او هڅو ارزښت نلري، او د لیري ایلیسن (شاید) څخه مننه کوم چې اوریکل ما مجبور نه کړ چې دا بیا لیکم.
اوریکل شاید په پلیټونو هم پوهیږي. څوک پوهیږي.
شواهد د اصلي جاوا APIs په اوږدو کې موندل کیدی شي ، کوم چې د ناپاکۍ څپې سره مخ دي ، لکه په کنیا کې د ګلیشیر کرښې. تاسو کولی شئ په اسانۍ سره د جاوا سوینګ کتابتون کې پنځه یا شپږ مختلف کیبورډ نیویګیشن مدیران (KeyboardFocusManager) ومومئ. دا واقعیا سخته ده چې د جاوا API ومومئ کوم چې له مینځه وړل شوی نه وي. مګر دوی لاهم کار کوي! زه فکر کوم چې د جاوا ټیم به یوازې واقعیا یو API لرې کړي که چیرې انٹرفیس روښانه امنیت مسله رامینځته کړي.
دلته خبره ده، خلک: موږ د سافټویر جوړونکي ټول ډیر بوخت یو، او د سافټویر په هره برخه کې موږ د سیالي بدیلونو سره مخ یو. په هر وخت کې، په X ژبه کې پروګرام کونکي د احتمالي بدیل په توګه ژبه Y په پام کې نیسي. او ته په ما باور نه کوې؟ ایا تاسو غواړئ دې ته سویفټ وایئ؟ لکه، هرڅوک سویفټ ته مهاجرت کوي او هیڅوک یې نه پریږدي، سمه ده؟ واه، تاسو څومره لږ پوهیږئ. شرکتونه د دوه ګوني ګرځنده پرمختیایی ټیمونو (iOS او Android) لګښتونه حسابوي - او دوی په دې پوهیدل پیل کوي چې د کراس پلیټ فارم پراختیایی سیسټمونه د مسخره نومونو سره لکه فلټر او ریکټ اصلي په حقیقت کې کار کوي او د دوی د اندازې کمولو لپاره کارول کیدی شي. ګرځنده ټیمونه دوه ځله یا په برعکس، دوی دوه ځله ګټور جوړوي. ریښتینې پیسې په خطر کې دي. هو، جوړجاړی شتون لري، مګر، له بلې خوا، پیسې.
راځئ په فرضي ډول فرض کړو چې ایپل په احمقانه ډول د ګیډو وان روسم څخه اشاره وکړه او اعلان یې وکړ چې سویفټ 6.0 د سویفټ 5.0 سره شاته مطابقت نلري ، لکه د پایتون 3 په څیر د پایتون 2 سره مطابقت نلري.
ما شاید دا کیسه شاوخوا لس کاله دمخه کړې وه ، مګر شاوخوا پنځلس کاله دمخه زه د ګیډو سره د او ریلي فو کمپ ته لاړم ، په خیمه کې د پاول ګراهام او لویو شاټونو سره ناست وم. موږ په ګرمه تودوخه کې ناست وو چې لیري پیج په خپله شخصي چورلکه کې الوتنه وکړه پداسې حال کې چې ګیډو شاوخوا "پایتون 3000" باندې ډرون وکړ، کوم چې هغه د هغه شمیر کلونو په نوم نومولی چې هرڅوک به هلته مهاجرت وکړي. موږ له هغه څخه وپوښتل چې ولې هغه مطابقت ماتوي، او هغه ځواب ورکړ: "یونیکوډ." او موږ وپوښتل، که موږ خپل کوډ بیا ولیکو، نو نورې کومې ګټې به وګورو؟ او هغه ځواب ورکړ "یوووونیوووUUUUUUUIVOOOOOOOOOOOOODE ځواب ورکړ."
که تاسو د ګوګل کلاوډ پلیټ فارم SDK ("gcloud") نصب کړئ ، نو تاسو به لاندې خبرتیا ترلاسه کړئ:
ګرانه اخیستونکی،
موږ غواړو تاسو ته یادونه وکړو چې د Python 2 ملاتړ له مینځه وړل شوی، نو تاسو لعنت وکړئ
… او همداسی پسی. د ژوند دایره.
مګر ټکی دا دی چې هر پرمخ وړونکی یو انتخاب لري. او که تاسو دوی مجبور کړئ چې ډیری وختونه کوډ بیا ولیکئ، دوی ممکن په اړه فکر وکړي نور اختیارونه دوی ستاسو یرغمل نه دي، مهمه نده چې تاسو څومره وغواړئ دوی وي. دوی ستاسو میلمانه دي. Python که څه هم د پروګرام کولو یوه ډیره مشهوره ژبه ده، مګر افسوس، Python 3 (000) په خپل ځان کې، په خپلو ټولنو کې او د خپلو ټولنو د کاروونکو ترمنځ داسې ګډوډۍ رامینځته کړې چې پایلې یې په پنځلسو کلونو کې نه دي روښانه شوي.
د دې شاته ناانډولۍ له امله په Go (یا روبي یا کوم بل بدیل) کې د Python څومره برنامې بیا لیکل شوي؟ د Python پرته بل څه کې څومره نوي سافټویر لیکل شوي، که څه هم کیدای شي په پیتون کې لیکل شوي، که ګیډو ټول کلی نه سوځولی؟ دا ویل ګران دي، مګر پیتون په ښکاره ډول زیانمن شوی. دا یو لوی ګډوډ دی او هرڅوک له لاسه ورکوي.
نو راځئ چې ووایو ایپل د ګیډو څخه اشاره اخلي او مطابقت ماتوي. تاسو څه فکر کوئ چې راتلونکی به څه وي؟ ښه، شاید 80-90٪ پراختیا کونکي به د امکان په صورت کې خپل سافټویر بیا لیکي. په بل عبارت، د کاروونکي اساس 10-20٪ په اتوماتيک ډول ځینې سیالي ژبې ته ځي، لکه فلټر.
دا څو ځله وکړئ او تاسو به خپل نیمایي کاروونکي اساس له لاسه ورکړئ. لکه څنګه چې په سپورت کې، د پروګرام کولو نړۍ کې، اوسنی بڼه هم مهمه ده. هرڅه. هر هغه څوک چې په پنځو کلونو کې خپل نیم کاروونکي له لاسه ورکړي د لوی غوړ له لاسه ورکوونکي په توګه به وګڼل شي. تاسو باید د پلیټ فارمونو نړۍ کې رجحان ولرئ. مګر دا هغه ځای دی چې د زړو نسخو ملاتړ نه کول به تاسو د وخت په تیریدو سره خراب کړي. ځکه چې هرکله چې تاسو د ځینې پراختیا کونکو څخه لرې شئ، تاسو (الف) دوی د تل لپاره له لاسه ورکوئ ځکه چې دوی د تړون ماتولو له امله تاسو ته په غوسه دي، او (ب) دوی خپلو سیالانو ته ورکوي.
په حیرانتیا سره، ما د ګوګل سره هم مرسته وکړه چې یو داسې لومړني ډونا شي چې د شاته مطابقت له پامه غورځوي کله چې ما Grok رامینځته کړ، د سرچینې کوډ تحلیل او پوهه سیسټم چې دا پخپله د کوډ اتومات کولو او وسیله کول اسانه کوي - د IDE په څیر، مګر دلته د کلاوډ خدمت ذخیره کوي په لوی ډیټا ګودام کې د ګوګل سرچینې کوډ د ټولو ملیارد لینونو مادي نمایش.
گروک ګوګلرز ته د دوی په ټول کوډبیس (په لفظي ډول په ګوګل کې) کې د اتوماتیک ریفکټورینګ ترسره کولو لپاره قوي چوکاټ چمتو کړی. سیسټم نه یوازې ستاسو د اپ سټریم انحصار محاسبه کوي (په کوم چې تاسو تکیه کوئ) ، بلکه هم ښکته کېدل (کوم چې تاسو پورې اړه لري) نو کله چې تاسو APIs بدل کړئ تاسو هرڅوک پوهیږئ چې تاسو مات کوئ! پدې توګه ، کله چې تاسو بدلونونه رامینځته کوئ ، تاسو کولی شئ تصدیق کړئ چې ستاسو د API هر مصرف کونکي نوي نسخه ته تازه کړي ، او په حقیقت کې ، ډیری وختونه د Rosie وسیلې سره چې دوی لیکلي ، تاسو کولی شئ پروسه په بشپړ ډول اتومات کړئ.
دا د ګوګل کوډبیس ته اجازه ورکوي چې په داخلي توګه تقریبا غیر طبیعي پاک وي، ځکه چې دوی دا روبوټیک نوکران لري چې د کور شاوخوا ګرځي او په اتوماتيک ډول هرڅه پاکوي که چیرې دوی د SomeDespicablyLongFunctionName نوم په SomeDespicablyLongMethodName بدل کړي ځکه چې یو چا پریکړه وکړه چې دا یو بدمرغه لمسی دی او د هغه اړتیاوې باید ویده شي.
او په ریښتیا، دا د ګوګل لپاره خورا ښه کار کوي ... په داخلي توګه. زما مطلب دی، هو، په ګوګل کې د Go ټولنه په ګوګل کې د جاوا ټولنې سره ښه خندا لري ځکه چې د دوی د دوامداره بیاکتنې عادت له امله. که تاسو یو څه N ځله بیا پیل کړئ ، پدې معنی چې تاسو نه یوازې دا N-1 ځله خراب کړی ، مګر یو څه وروسته دا خورا روښانه کیږي چې تاسو شاید دا په Nth هڅه کې هم خراب کړی وي. مګر، په لویه کچه، دوی د دې ټولو ګډوډۍ څخه پورته پاتې دي او کوډ "پاک" ساتي.
ستونزه هغه وخت پیل کیږي کله چې دوی هڅه کوي دا چلند په خپلو بادل پیرودونکو او د نورو APIs کاروونکو باندې تحمیل کړي.
ما تاسو ته لږ څه ایماکس، انډرایډ او جاوا ته معرفي کړل؛ راځئ چې وروستي بریالي اوږدمهاله پلیټ فارم ته وګورو: ویب پخپله. ایا تاسو تصور کولی شئ چې د 1995 راهیسې HTTP څومره تکرارونه تیر شوي کله چې موږ د فلش کولو ټاګونه کارولي؟ او په ویب پاڼو کې "د ساختمان لاندې" عکسونه.
مګر دا لاهم کار کوي! او دا پاڼې لاهم کار کوي! هو، هلکان، براوزر په شاته مطابقت کې د نړۍ اتلان دي. کروم د نادر ګوګل پلیټ فارم یوه بله بیلګه ده چې سرونه یې په سمه توګه پیچلي دي، او لکه څنګه چې تاسو اټکل کړی وي، کروم په مؤثره توګه د سینڈ باکس شوي شرکت په توګه کار کوي چې د پاتې ګوګل څخه جلا وي.
زه هم غواړم د اپریټنګ سیسټم جوړونکو کې زموږ د ملګرو څخه مننه وکړم: وینډوز، لینوکس، نه اپل FUCK YOU APPLE، FreeBSD، او داسې نور، د دوی په بریالي پلیټ فارمونو کې د شاته مطابقت دومره عالي دنده ترسره کولو لپاره (ایپل په غوره توګه C ترلاسه کوي. نیمګړتیا دا ده چې دوی هر وخت د ښه دلیل لپاره هرڅه ماتوي ، مګر په یو ډول ټولنه د هرې خوشې کیدو سره شاوخوا ګرځي ، او د OS X کانټینرونه لاهم په بشپړ ډول ناپاک ندي ... لاهم).
مګر انتظار وکړئ، تاسو وایی. ایا موږ مڼې د نارنج سره پرتله نه کوو - په یو واحد ماشین کې د سټنډرډ سافټویر سیسټمونه لکه Emacs/JDK/Android/Chrome په مقابل کې ملټي سرور سیسټمونه او APIs لکه کلاوډ خدمات؟
ښه، ما پرون په دې اړه ټویټ وکړ، مګر د لیري وال (د پروګرام کولو ژبې جوړونکي پرل - نږدې فی.) په سټایل کې ما د "بوک / قواعد" په اصولو کې کلمه وکتله. خراب شوی د ګوګل او ایمیزون پراختیا کونکي سایټونو کې. او که څه هم AWS لري سلګونه د GCP په پرتله څو ځله ډیر خدمت وړاندیزونه، د ګوګل پراختیا کونکي اسناد اوه ځله ډیر ځله د استخراج یادونه کوي.
که چیرې په ګوګل کې څوک دا ولولي، دوی شاید چمتو وي چې د ډونالډ ټرمپ سټایل چارټونه راوباسي چې دا ښیې چې دوی واقعیا هرڅه سم کوي ، او دا چې زه باید غیر عادلانه پرتله ونه کړم لکه "د کلمې د ذکر کولو شمیره په مقابل کې. د خدماتو شمیر ""
مګر د دې ټولو کلونو وروسته ، د ګوګل کلاوډ لاهم د 3 نمبر خدمت دی (ما هیڅکله د 2 نمبر کیدو د ناکامې هڅې په اړه مقاله نه ده لیکلې) ، مګر که د داخلي خلکو باور وشي ، ځینې اندیښنې شتون لري چې دوی به ژر تر ژره ودریږي. ۴ نمبر.
زه زما د مقالې "ثابت کولو" لپاره کوم مجبور دلیل نلرم. ټول هغه رنګین مثالونه دي چې ما د 30 کلونو څخه زیات د پراختیا کونکي په توګه راټول کړي دي. ما مخکې د دې ستونزې ژوره فلسفي ماهیت ته اشاره کړې ده. په ځینو لارو کې دا په پراختیایی ټولنو کې سیاسي کیږي. ځینې په دې باور دي جوړونکي پلیټ فارمونه باید د مطابقت په اړه پاملرنه وکړي، پداسې حال کې چې نور فکر کوي چې دا یوه اندیښنه ده کارنان (په خپله پراختیا کونکي). یو له دوو څخه. په حقیقت کې، دا یوه سیاسي مسله نه ده کله چې موږ پریکړه وکړو چې څوک باید د ګډو ستونزو لګښتونه په غاړه واخلي؟
نو دا سیاست دی. او شاید زما خبرو ته به غوسه ځوابونه وي.
څنګه کارن د ګوګل کلاوډ پلیټ فارم، او د دوو کلونو لپاره د AWS کاروونکي په توګه (په داسې حال کې چې د ګراب لپاره کار کوي)، زه کولی شم ووایم چې د ایمیزون او ګوګل د فلسفې ترمنځ خورا لوی توپیر شتون لري کله چې دا لومړیتوبونو ته راځي. زه په فعاله توګه په AWS کې وده نه کوم، نو زه ډیر ښه نه پوهیږم چې دوی څو ځله زاړه APIs لرې کوي. مګر یو شک شتون لري چې دا تقریبا د ګوګل په څیر واقع نه کیږي. او زه واقعیا باور لرم چې په GCP کې د دوامداره تناقض او مایوسۍ سرچینه یو له لوی فاکتورونو څخه دی چې د پلیټ فارم پراختیا مخه نیسي.
زه پوهیږم چې ما د GCP سیسټمونو ځانګړي مثالونه ندي نومولي چې نور یې ملاتړ نه کیږي. زه کولی شم ووایم چې نږدې هرڅه چې ما کارولي دي ، له شبکو څخه (له زاړه څخه تر VPC پورې) ذخیره کولو پورې (د کلاوډ SQL v1-v2) ، فایربیس (اوس د بشپړ مختلف API سره Firestore) ، د اپل انجن (راځئ چې حتی پیل نه کړو) , cloud endpoints Cloud Endpoint and up to... زه نه پوهیږم - بالکل دا ټول تاسو مجبور کړی چې د اعظمي 2-3 کلونو وروسته کوډ بیا ولیکئ، او دوی هیڅکله ستاسو لپاره مهاجرت اتومات نه کړ، او ډیری وختونه . لکه څنګه چې باید داسې وي.
او هرکله چې زه AWS ته ګورم ، زه له ځانه پوښتنه کوم چې ولې زه لاهم په GCP کې یم. دوی په ښکاره ډول پیرودونکو ته اړتیا نلري. دوی اړتیا لري پېرودونکي. ایا تاسو په توپیر پوهیږئ؟ اجازه راکړئ تشریح کړم.
ګوګل کلاوډ لري ، چیرې چې خلک د دوی سافټویر حلونه وړاندیز کوي ، او د خالي رستورانت اغیزې څخه مخنیوي لپاره ، دوی اړتیا لري دا د ځینې وړاندیزونو سره ډک کړي ، نو دوی د Bitnami په نوم شرکت سره تړون وکړ ترڅو د حلونو یوه ډله رامینځته کړي چې د "یو کلیک" سره ځای په ځای شوي ، یا باید زه دا پخپله "حلونه" لیکم، ځکه چې دا یو لوی شی نه حل کوي. دوی په ساده ډول د چک بکسونو په توګه شتون لري، د بازار موندنې ډکونکي په توګه، او ګوګل هیڅکله پروا نه ده کړې چې آیا کوم وسیله واقعیا کار کوي. زه د محصول مدیران پیژنم چې د موټر چلوونکي څوکۍ کې دي، او زه تاسو ته ډاډ درکوم چې دا خلک پروا نه کوي.
د مثال په توګه، د "یو کلیک" ځای پرځای کولو حل واخلئ. . زه د ګوګل کلاوډ ایس کیو ایل شینانیګین په مرګ ناروغ وم ، نو ما د بدیل په توګه زما د خپل پیرکونا کلستر جوړولو په لټه کې شو. او دا ځل ګوګل داسې بریښي چې ښه کار یې کړی دی، دوی به زما د تڼۍ په کلیک کولو سره یو څه وخت او هڅې خوندي کړي!
ښه ښه، راځئ چې لاړ شو. راځئ چې لینک تعقیب کړو او دا تڼۍ کلیک وکړئ. د ټولو ډیفالټ تنظیماتو سره موافق کیدو لپاره "هو" غوره کړئ او ستاسو د ګوګل کلاوډ پروژې کې کلسټر ځای په ځای کړئ. ها، دا کار نه کوي. له دې خندا څخه هیڅ کار نه کوي. وسیله هیڅکله نه ده ازمول شوې او دا د لومړۍ دقیقې څخه راټیټیدل پیل شوي ، او دا به ما حیران نه کړي که چیرې د "حلونو" نیمایي څخه ډیر د یو کلیک ځای پرځای کول وي (اوس موږ پوهیږو چې ولې نرخونه) په عمومي توګه کار نه کوي. دا بالکل نا امیده تیاره ده ، چیرې چې دا غوره نه ده چې ننوځي.
مګر ګوګل سم دی هڅوي تاسو به یې وکاروئ. دوی تاسو غواړي اخيستل. د دوی لپاره دا معامله ده. دوی هیڅ نه غواړي ملاتړ. دا د ګوګل د DNA برخه نه ده. هو، انجنیران د یو بل ملاتړ کوي، لکه څنګه چې زما د کیسې لخوا د Bigtable سره ثبوت شوی. مګر د عادي خلکو لپاره په محصولاتو او خدماتو کې تل په کې بې رحمه وو ، کوم چې د ګټې لپاره بار نه پوره کوي حتی که دا ملیونونه کارونکي ولري.
او دا د GCP لپاره ریښتینې ننګونه وړاندې کوي ځکه چې دا د ټولو بادل وړاندیزونو ترشا DNA دی. دوی د هیڅ شی ملاتړ کولو هڅه نه کوي؛ دا ښه پوهیږي چې دوی د دریمې ډلې سافټویر کوربه کولو څخه انکار کوي (د مدیریت شوي خدمت په توګه) تر څو، تر هغه چې AWS ورته کار وکړي او د هغې شاوخوا بریالۍ سوداګرۍ رامینځته کړي ، او کله چې پیرودونکي په حقیقت کې ورته غوښتنه کوي. په هرصورت، دا د یو څه مالتړ لپاره د ګوګل ترلاسه کولو لپاره ځینې هڅې اخلي.
دا د ملاتړ کلتور نشتوالی، د "راځئ چې دا مات کړو ترڅو دا نور ښکلی کړو" ذهنیت، پراختیا کونکي له مینځه وړي.
او دا ښه شی ندی که تاسو غواړئ د اوږدمهاله پلیټ فارم جوړ کړئ.
ګوګل، ویښ شه، لعنت دی. دا اوس 2020 دی. تاسو لاهم له لاسه ورکوئ. دا وخت دی چې په عکس کې سخت نظر واخلئ او ځواب ورکړئ چې ایا تاسو واقعیا غواړئ د بادل سوداګرۍ کې پاتې شئ.
که تاسو غواړئ چې پاتې شئ د هرڅه ماتول بند کړئ. هلکانو، تاسو شتمن یاست. موږ پراختیا کونکي نه کوو. نو کله چې دا راځي چې څوک به د مطابقت بار په غاړه واخلي ، تاسو اړتیا لرئ دا په خپل ځان واخلئ. زموږ لپاره نه.
ځکه چې لږترلږه درې نور واقعیا ښه بادونه شتون لري. دوی اشاره کوي.
او اوس به زه خپل ټول مات شوي سیسټمونه سمولو ته لاړ شم. ایه
تر بل وخت پورې!
د دې مقالې په اړه د ځینو بحثونو لوستلو وروسته PS تازه کړئ (بحثونه عالي دي ، btw). د Firebase ملاتړ نه دی بند شوی او داسې کوم پلان شتون نلري چې زه یې خبر یم. په هرصورت، دوی یو ناوړه سټرینګ بګ لري چې د جاوا پیرودونکي د اپل انجن کې د بندیدو لامل کیږي. د دوی یو انجنیر زما سره د دې ستونزې په حل کې مرسته وکړه، کله چې ما په ګوګل کې کار کاوه، مګر دوی هیڅکله واقعیا بګ نه دی حل کړی ، نو زه هره ورځ د GAE اپلیکیشن بیا پیل کولو لپاره یو خراب کار لرم. او دا څلور کاله کیږي! دوی اوس Firestore لري. دا به دې ته د مهاجرت لپاره ډیر کار وکړي ځکه چې دا یو بشپړ مختلف سیسټم دی او د فایربیس بګ به هیڅکله حل نشي. کومه پایله اخیستل کیدی شي؟ تاسو کولی شئ مرسته ترلاسه کړئ که تاسو په یوه شرکت کې کار کوئ. زه شاید یوازینی کس یم چې په GAE کې فایربیس کاروم ځکه چې زه په 100٪ اصلي ایپ کې له 100 څخه لږ کیلي لاګ کوم او دا د پیژندل شوي بګ له امله په هرو څو ورځو کې کار کوي. زه نور څه ویلای شم پرته لدې چې دا په خپل خطر کې وکاروم. زه ریډیس ته ځم.
ما د AWS ځینې نور تجربه لرونکي کاروونکي هم لیدلي چې وايي AWS معمولا هیڅکله د کوم خدماتو ملاتړ نه کوي، او SimpleDB یو ښه مثال دی. زما انګیرنې چې AWS د ملاتړ ناروغۍ ورته پای نلري لکه څنګه چې ګوګل داسې ښکاري چې توجیه کیږي.
سربیره پردې ، ما ولیدل چې 20 ورځې دمخه د ګوګل اپ انجن ټیم د مهم Go کتابتون کوربه توب مات کړ ، د اصلي Go پراختیا کونکو څخه د GAE غوښتنلیک بند کړ. دا واقعیا احمق وه.
په نهایت کې ، ما اوریدلي چې ګوګل کونکي دمخه پدې مسله بحث کوي او عموما زما سره موافق دي (له تاسو سره مینه وکړئ!). مګر دوی داسې ښکاري چې ستونزه د حل وړ نه ده ځکه چې د ګوګل کلتور هیڅکله د هڅونې سمه جوړښت نه درلود. ما فکر کاوه چې دا به ښه وي چې یو څه وخت ونیسئ د هغه حیرانتیا تجربې په اړه بحث وکړئ چې ما په ګراب کې د کار کولو پرمهال د AWS انجینرانو سره کار کړی و. په راتلونکې کې یوه ورځ، زه هیله لرم!
او هو، په 2005 کې دوی د 43 په جوړولو کې په لوی بفټ کې د شارک غوښې مختلف ډولونه درلودل، او زما خوښې د هامر هیډ شارک غوښه وه. په هرصورت، په 2006 کې، لیري او سرګي د ټولو غیر صحي خوړو څخه ځان خلاص کړ. نو په 2007 کې د Bigtable کیسه په جریان کې واقعیا هیڅ شارک نه و او ما تاسو ته دوکه ورکړه.
کله چې ما څلور کاله دمخه بادل Bigtable ته وکتل (ورکړئ یا واخله)، دا هغه ځای دی چې لګښت یې درلود. داسې بریښي چې اوس یو څه راټیټ شوی ، مګر دا لاهم د خالي ډیټا ګودام لپاره خورا ویرونکی دی ، په ځانګړي توګه له هغه وخته چې زما لومړۍ کیسه ښیې چې خالي لوی میز د دوی په کچه څومره غیر ضروري دی.
د ایپل ټولنې ته د سپکاوي لپاره بخښنه غواړم او د مایکروسافټ وغيره په اړه هیڅ ښه نه ویل. تاسو سم یاست، زه واقعیا د ټولو بحثونو ستاینه کوم چې دا مقاله رامینځته کړې! مګر ځینې وختونه تاسو اړتیا لرئ د بحث پیل کولو لپاره لږ څپې رامینځته کړئ ، تاسو پوهیږئ؟
د لوستلو لپاره مننه.
تازه 2، 19.08.2020/XNUMX/XNUMX. پټه !
تازه 3، 31.08.2020/2/2. زه د کلاوډ مارکیټ پلیس کې د ګوګل انجینر لخوا اړیکه ونیولم چې زما پخوانی ملګری و. هغه غوښتل معلومه کړي چې ولې CXNUMXD کار نه کوي، او موږ بالاخره معلومه کړه چې دا ځکه چې ما خپل شبکه کلونه وړاندې جوړه کړې وه، او CXNUMXD په میراثي شبکو کې کار نه کاوه ځکه چې د فرعي نیټ پیرامیټر د دوی په ټیمپلیټونو کې ورک و. زه فکر کوم چې دا د احتمالي GCP کاروونکو لپاره غوره دی ترڅو ډاډ ترلاسه کړي چې دوی په ګوګل کې کافي انجینران پیژني ...
سرچینه: www.habr.com