ជូនចំពោះ Google Cloud ការមិនត្រូវគ្នាថយក្រោយកំពុងសម្លាប់អ្នក។

អាក្រក់ Google ខ្ញុំមិនចង់សរសេរប្លុកម្តងទៀតទេ។ ខ្ញុំ​មាន​អ្វី​ច្រើន​ដែល​ត្រូវ​ធ្វើ។ ការសរសេរប្លុកត្រូវការពេលវេលា ថាមពល និងការច្នៃប្រឌិត ដែលខ្ញុំអាចប្រើប្រាស់បានយ៉ាងប្រសើរ៖ សៀវភៅរបស់ខ្ញុំ, តន្ត្រីហ្គេមរបស់ខ្ញុំជាដើម។ ប៉ុន្តែ​អ្នក​បាន​ខឹង​ខ្ញុំ​គ្រប់គ្រាន់​ដែល​ខ្ញុំ​ត្រូវ​សរសេរ​នេះ​។

ដូច្នេះសូមបញ្ចប់រឿងនេះជាមួយ។

ខ្ញុំសូមចាប់ផ្តើមជាមួយនឹងរឿងខ្លីៗ ប៉ុន្តែមានការណែនាំពីពេលដែលខ្ញុំចាប់ផ្តើមធ្វើការនៅ Google ដំបូង។ ខ្ញុំដឹងថាខ្ញុំបាននិយាយរឿងមិនល្អជាច្រើនអំពី Google នាពេលថ្មីៗនេះ ប៉ុន្តែវាធ្វើឱ្យខ្ញុំខកចិត្តនៅពេលដែលក្រុមហ៊ុនរបស់ខ្ញុំផ្ទាល់ធ្វើការសម្រេចចិត្តអាជីវកម្មដែលគ្មានសមត្ថភាពជាទៀងទាត់។ ក្នុងពេលជាមួយគ្នានេះ យើងត្រូវផ្តល់ឱ្យវាដល់ពេលកំណត់៖ ហេដ្ឋារចនាសម្ព័ន្ធខាងក្នុងរបស់ Google គឺពិតជាមិនធម្មតា វាមានសុវត្ថិភាពក្នុងការនិយាយថាមិនមានអ្វីប្រសើរជាងថ្ងៃនេះទេ។ ស្ថាបនិក Google គឺជាវិស្វករល្អជាងខ្ញុំទៅទៀត ហើយរឿងនេះគ្រាន់តែបញ្ជាក់ការពិតប៉ុណ្ណោះ។

ទីមួយ ផ្ទៃខាងក្រោយតិចតួច៖ Google មានបច្ចេកវិទ្យាផ្ទុកទិន្នន័យហៅថា តុបុណ្យ. វាគឺជាសមិទ្ធិផលបច្ចេកទេសដ៏គួរឱ្យកត់សម្គាល់មួយ ក្នុងចំណោមហាងដំបូង (ប្រសិនបើមិនមែនដំបូង) "អាចធ្វើមាត្រដ្ឋានបាន" (K/V)៖ សំខាន់ជាការចាប់ផ្តើមនៃ NoSQL ។ ប៉ុន្មានថ្ងៃនេះ Bigtable នៅតែដំណើរការបានល្អនៅក្នុងទំហំផ្ទុក K/V ដែលមានមនុស្សច្រើន ប៉ុន្តែនៅពេលនោះ (2005) វាពិតជាអស្ចារ្យមែនទែន។

រឿងគួរឱ្យអស់សំណើចមួយអំពី Bigtable គឺថាពួកគេមានវត្ថុយន្តហោះគ្រប់គ្រងខាងក្នុង (ជាផ្នែកនៃការអនុវត្ត) ដែលហៅថាម៉ាស៊ីនមេថេប្លេត ជាមួយនឹងសន្ទស្សន៍ធំ ហើយនៅចំណុចខ្លះពួកគេបានក្លាយជាឧបសគ្គនៅពេលធ្វើមាត្រដ្ឋានប្រព័ន្ធ។ វិស្វករ Bigtable មានការងឿងឆ្ងល់អំពីវិធីអនុវត្តការធ្វើមាត្រដ្ឋាន ហើយភ្លាមៗនោះបានដឹងថាពួកគេអាចជំនួសម៉ាស៊ីនមេកុំព្យូទ័របន្ទះជាមួយនឹងទំហំផ្ទុក Bigtable ផ្សេងទៀត។ ដូច្នេះ Bigtable គឺជាផ្នែកមួយនៃការអនុវត្ត Bigtable ។ កន្លែងផ្ទុកទាំងនេះមាននៅគ្រប់កម្រិតទាំងអស់។

ព័ត៌មានលម្អិតគួរឱ្យចាប់អារម្មណ៍មួយទៀតគឺថាមួយរយៈ Bigtable បានក្លាយជាការពេញនិយម និងគ្រប់ទីកន្លែងនៅក្នុង Google ដោយក្រុមនីមួយៗមានឃ្លាំងផ្ទាល់ខ្លួន។ ដូច្នេះនៅក្នុងកិច្ចប្រជុំមួយកាលពីថ្ងៃសុក្រ Larry Page បានសួរយ៉ាងសាមញ្ញថា "ហេតុអ្វីបានជាយើងមាន Bigtable ច្រើនជាងមួយ? ហេតុអ្វីមិនមែនតែមួយ?” តាមទ្រឹស្តី ទំហំផ្ទុកមួយគួរតែគ្រប់គ្រាន់សម្រាប់តម្រូវការផ្ទុកទាំងអស់របស់ Google ។ ជាការពិតណាស់ ពួកគេមិនដែលទៅតែម្ខាងសម្រាប់ហេតុផលអភិវឌ្ឍន៍ជាក់ស្តែងទេ (ដូចជាផលវិបាកនៃការបរាជ័យដែលអាចកើតមាន) ប៉ុន្តែទ្រឹស្តីគឺគួរឱ្យចាប់អារម្មណ៍។ ឃ្លាំងមួយសម្រាប់សកលលោកទាំងមូល (និយាយអីញ្ចឹងតើមានអ្នកណាដឹងទេថាតើ Amazon បានធ្វើរឿងនេះជាមួយ Sable របស់ពួកគេដែរឬទេ?)

ទោះយ៉ាងណាក៏ដោយ នេះជារឿងរបស់ខ្ញុំ។

នៅពេលនោះ ខ្ញុំបានធ្វើការនៅ Google ជាង XNUMX ឆ្នាំ ហើយថ្ងៃមួយខ្ញុំបានទទួលអ៊ីមែលពីក្រុមវិស្វករ Bigtable ដែលមានលក្ខណៈដូចនេះ៖

សួស្តី Steve!

សួស្តីពីក្រុម Bigtable ។ យើងសូមជូនដំណឹងដល់អ្នកថានៅ [ឈ្មោះមជ្ឈមណ្ឌលទិន្នន័យ] អ្នកកំពុងប្រើប្រព័ន្ធគោលពីរ Bigtable ចាស់ខ្លាំងណាស់។ កំណែនេះមិនត្រូវបានគាំទ្រទៀតទេ ហើយយើងចង់ជួយអ្នកឱ្យដំឡើងកំណែទៅកំណែចុងក្រោយបំផុត។

សូមប្រាប់ខ្ញុំថាតើអ្នកអាចកំណត់ពេលវេលាខ្លះដើម្បីធ្វើការជាមួយគ្នាលើបញ្ហានេះ។

គ្រប់យ៉ាង​គឺ​ល្អ​ប្រ​សើ,
ក្រុម Bigtable

នៅលើ Google អ្នកទទួលបានសំបុត្រជាច្រើន ដូច្នេះនៅ glance ដំបូងខ្ញុំបានអានអ្វីមួយដូចនេះ៖

អ្នកទទួលជាទីគោរព!

សួស្តីពីក្រុមមួយចំនួន។ យើងចង់ទំនាក់ទំនងថា blah blah blah blah blah ។ Blah blah blah blah blah blah blah blah blah blah ភ្លាម។

សូមប្រាប់ពួកយើងឱ្យដឹង ប្រសិនបើអ្នកអាចកំណត់ពេលវេលាដ៏មានតម្លៃរបស់អ្នកខ្លះសម្រាប់ blah blah blah។

គ្រប់យ៉ាង​គឺ​ល្អ​ប្រ​សើ,
ប្រភេទនៃពាក្យបញ្ជាមួយចំនួន

ខ្ញុំស្ទើរតែលុបវាចោលភ្លាមៗ ប៉ុន្តែនៅគែមនៃស្មារតីរបស់ខ្ញុំ ខ្ញុំមានអារម្មណ៍ឈឺចាប់ និងងឿងឆ្ងល់ មិនពិត វាមើលទៅដូចជាលិខិតផ្លូវការ ច្បាស់ណាស់ដែលអ្នកទទួលច្រឡំ ដោយសារខ្ញុំមិនបានប្រើ Bigtable។

ប៉ុន្តែវាចម្លែកណាស់។

ខ្ញុំបានចំណាយពេលពេញមួយថ្ងៃដោយឆ្លាស់គ្នាគិតអំពីការងារ និងសាច់ត្រីឆ្លាមប្រភេទណាដែលត្រូវសាកល្បងនៅក្នុងផ្ទះបាយខ្នាតតូច ដែលក្នុងនោះយ៉ាងហោចណាស់មានបីនាក់ជិតល្មមនឹងវាយចេញពីកន្លែងអង្គុយរបស់ខ្ញុំដោយបោះនំប៊ីសឃីសមួយ ប៉ុន្តែ គំនិតនៃការសរសេរមិនដែលធ្វើឱ្យខ្ញុំមានអារម្មណ៍ថប់បារម្ភស្រាលទេ។

ពួកគេនិយាយឈ្មោះខ្ញុំយ៉ាងច្បាស់។ ហើយអ៊ីមែលត្រូវបានផ្ញើទៅកាន់អាសយដ្ឋានអ៊ីមែលរបស់ខ្ញុំ មិនមែនជារបស់អ្នកផ្សេងទេ ហើយវាមិនមែនជា cc: ឬ bcc: ។ សម្លេងគឺមានលក្ខណៈផ្ទាល់ខ្លួន និងច្បាស់ណាស់។ ប្រហែលជានេះជាកំហុសមួយចំនួន?

ទីបំផុត ការចង់ដឹងចង់ឃើញបានប្រសើរឡើងពីខ្ញុំ ហើយខ្ញុំបានទៅមើលកុងសូល Borg នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដែលពួកគេបាននិយាយ។

ហើយជាការពិតណាស់ ខ្ញុំមានកន្លែងផ្ទុក BigTable ក្រោមការគ្រប់គ្រង។ ខ្ញុំសុំទោស អ្វី? ខ្ញុំបានមើលខ្លឹមសាររបស់វាហើយ អីយ៉ា! វាមកពីកន្លែងបង្កើត Codelab ដែលខ្ញុំបានអង្គុយក្នុងអំឡុងសប្តាហ៍ដំបូងរបស់ខ្ញុំនៅ Google ក្នុងខែមិថុនា ឆ្នាំ 2005។ Codelab បានបង្ខំអ្នកឱ្យដំណើរការ Bigtable ដើម្បីសរសេរតម្លៃមួយចំនួននៅទីនោះ ហើយតាមមើលទៅ ខ្ញុំមិនដែលបិទកន្លែងផ្ទុកទេបន្ទាប់ពីនោះ។ វានៅតែដំណើរការទោះបីជាជាងពីរឆ្នាំបានកន្លងផុតទៅក៏ដោយ។

មានទិដ្ឋភាពគួរឱ្យកត់សម្គាល់ជាច្រើនចំពោះរឿងនេះ។ ទីមួយ ការងាររបស់ Bigtable គឺមិនសូវសំខាន់នៅលើមាត្រដ្ឋានរបស់ Google ដែលត្រឹមតែពីរឆ្នាំក្រោយមកមាននរណាម្នាក់កត់សម្គាល់ទំហំផ្ទុកបន្ថែម ហើយដោយសារតែកំណែរបស់ប្រព័ន្ធគោលពីរគឺហួសសម័យ។ សម្រាប់ការប្រៀបធៀបខ្ញុំធ្លាប់ពិចារណាប្រើ Bigtable នៅលើ Google Cloud សម្រាប់ហ្គេមអនឡាញរបស់ខ្ញុំ។ នៅពេលនោះ សេវាកម្មនេះមានតម្លៃប្រហែល $16 ក្នុងមួយឆ្នាំ។ ទទេ Bigtable នៅលើ GCP ។ ខ្ញុំមិននិយាយថាពួកគេកំពុងបោកប្រាស់អ្នកទេ ប៉ុន្តែនៅក្នុងគំនិតផ្ទាល់ខ្លួនរបស់ខ្ញុំ នោះគឺជាប្រាក់ជាច្រើនសម្រាប់មូលដ្ឋានទិន្នន័យ fucking ទទេ។

ទិដ្ឋភាពគួរឱ្យកត់សម្គាល់មួយទៀតគឺការផ្ទុក នៅតែធ្វើការបន្ទាប់ពីពីរឆ្នាំ. WTF? មជ្ឈមណ្ឌលទិន្នន័យមកនិងទៅ; ពួកគេជួបប្រទះនឹងការដាច់ភ្លើង ពួកគេទទួលការថែទាំតាមកាលវិភាគ ពួកគេផ្លាស់ប្តូរគ្រប់ពេលវេលា។ ផ្នែករឹងត្រូវបានអាប់ដេត កុងតាក់ត្រូវបានប្តូរ អ្វីគ្រប់យ៉ាងត្រូវបានកែលម្អឥតឈប់ឈរ។ តើ​ពួក​គេ​អាច​រក្សា​កម្មវិធី​របស់​ខ្ញុំ​ឱ្យ​ដំណើរការ​បាន​រយៈពេល​ពីរ​ឆ្នាំ​ដោយ​ការ​ផ្លាស់​ប្តូរ​ទាំង​អស់​នេះ​ដោយ​របៀប​ណា? នេះអាចហាក់ដូចជាសមិទ្ធិផលតិចតួចក្នុងឆ្នាំ 2020 ប៉ុន្តែនៅឆ្នាំ 2005-2007 វាពិតជាគួរអោយចាប់អារម្មណ៍ណាស់។

ហើយទិដ្ឋភាពដ៏អស្ចារ្យបំផុតនោះគឺថាក្រុមវិស្វករខាងក្រៅនៅក្នុងរដ្ឋផ្សេងទៀតមករកខ្ញុំ ដែលជាម្ចាស់នៃឧទាហរណ៍តូចស្ទើរតែទទេនៃ Bigtable ដែលមាន សូន្យចរាចរណ៍ អស់រយៈពេលពីរឆ្នាំកន្លងមកហើយកំពុងផ្តល់ជំនួយដើម្បីធ្វើបច្ចុប្បន្នភាពវា។

ខ្ញុំបានអរគុណពួកគេ លុបកន្លែងផ្ទុក ហើយជីវិតនៅតែបន្តដូចធម្មតា។ ប៉ុន្តែដប់បីឆ្នាំក្រោយមក ខ្ញុំនៅតែគិតអំពីសំបុត្រនោះ។ ដោយសារតែពេលខ្លះខ្ញុំទទួលបានអ៊ីមែលស្រដៀងគ្នាពី Google Cloud ។ ពួកគេមើលទៅដូចនេះ៖

ជូនចំពោះអ្នកប្រើប្រាស់ Google Cloud!

ជា​ការ​រំលឹក យើង​នឹង​ឈប់​បន្ត​សេវាកម្ម [សេវាកម្ម​សំខាន់​ដែល​អ្នក​ប្រើ] គិត​ត្រឹម​ខែ​សីហា ឆ្នាំ 2020 បន្ទាប់​ពី​នោះ​អ្នក​នឹង​មិន​អាច​ធ្វើ​បច្ចុប្បន្នភាព​ករណី​របស់​អ្នក​បាន​ទេ។ យើងសូមណែនាំឱ្យធ្វើបច្ចុប្បន្នភាពទៅកំណែចុងក្រោយបំផុត ដែលស្ថិតក្នុងការសាកល្បងបែតា មិនមានឯកសារ គ្មានផ្លូវធ្វើចំណាកស្រុក និងហួសសម័យពីមុន ដោយមានជំនួយដ៏ល្អរបស់យើង។

យើងប្តេជ្ញាធានាថាការផ្លាស់ប្តូរនេះមានផលប៉ះពាល់តិចតួចបំផុតលើអ្នកប្រើប្រាស់ទាំងអស់នៃវេទិកា Google Cloud ។

មិត្តល្អបំផុតជារៀងរហូត,
Google Cloud Platform

ប៉ុន្តែខ្ញុំស្ទើរតែមិនដែលអានអក្សរបែបនេះទេ ព្រោះអ្វីដែលពួកគេនិយាយគឺ៖

អ្នកទទួលជាទីគោរព!

ទៅ​នរក។ Fuck អ្នក, fuck អ្នក, fuck អ្នក។ ទម្លាក់អ្វីគ្រប់យ៉ាងដែលអ្នកធ្វើព្រោះវាមិនសំខាន់។ អ្វីដែលសំខាន់គឺពេលវេលារបស់យើង។ យើងខ្ជះខ្ជាយពេលវេលា និងថវិកាដើម្បីរក្សាភាពខ្ជិលរបស់យើង ហើយយើងធុញទ្រាន់នឹងវា ដូច្នេះយើងនឹងមិនគាំទ្រវាទៀតទេ។ ដូច្នេះឈប់ធ្វើផែនការដ៏អាក្រក់របស់អ្នក ហើយចាប់ផ្តើមជីកកកាយតាមរយៈឯកសារដ៏អាក្រក់របស់យើង សុំរើសសំរាមនៅលើវេទិកា ហើយដោយវិធីនេះ លាមកថ្មីរបស់យើងគឺខុសគ្នាទាំងស្រុងពីរឿងចាស់ ពីព្រោះយើងបង្កើតការរចនានេះអាក្រក់ណាស់ ហេ ប៉ុន្តែនោះជារបស់អ្នក បញ្ហាមិនមែនជារបស់យើងទេ។

យើងបន្តខិតខំប្រឹងប្រែងដើម្បីធានាថារាល់ការអភិវឌ្ឍន៍របស់អ្នកមិនអាចប្រើបានក្នុងរយៈពេលមួយឆ្នាំ។

សូមអោប
Google Cloud Platform

ហើយការពិតគឺថាខ្ញុំទទួលបានសំបុត្របែបនេះប្រហែលមួយដងក្នុងមួយខែ។ រឿងនេះកើតឡើងជាញឹកញាប់ និងឥតឈប់ឈរ ដែលពួកគេជៀសមិនរួច រុញចេញ ខ្ញុំពី GCP ទៅជំរុំប្រឆាំងពពក។ ខ្ញុំលែងយល់ព្រមក្នុងការពឹងផ្អែកលើការអភិវឌ្ឍន៍ដែលមានកម្មសិទ្ធិរបស់ពួកគេទៀតហើយ ពីព្រោះតាមពិតវាងាយស្រួលជាងសម្រាប់ devops ក្នុងការថែរក្សាប្រព័ន្ធប្រភពបើកចំហនៅលើម៉ាស៊ីននិម្មិតទទេ ជាជាងការព្យាយាមតាម Google ជាមួយនឹងគោលការណ៍បិទផលិតផល "ហួសសម័យ" របស់ខ្លួន។

មុនពេលខ្ញុំត្រលប់ទៅ Google Cloud ដោយសារតែខ្ញុំ មិនជិត មិន​បាន​ធ្វើ​ការ​រិះគន់​ពួក​គេ សូម​មើល​ការ​អនុវត្ត​របស់​ក្រុមហ៊ុន​ក្នុង​ផ្នែក​មួយ​ចំនួន​ផ្សេង​ទៀត. វិស្វករ Google មានមោទនភាពចំពោះវិន័យវិស្វកម្មផ្នែកទន់របស់ពួកគេ ហើយនេះគឺជាអ្វីដែលបណ្តាលឱ្យមានបញ្ហា។ មោទនភាពគឺជាអន្ទាក់សម្រាប់អ្នកដែលមិនប្រុងប្រយ័ត្ន ហើយបាននាំឱ្យបុគ្គលិក Google ជាច្រើនគិតថាការសម្រេចចិត្តរបស់ពួកគេតែងតែត្រឹមត្រូវ ហើយការដែលត្រឹមត្រូវ (តាមនិយមន័យមិនច្បាស់លាស់មួយចំនួន) គឺសំខាន់ជាងការយកចិត្តទុកដាក់ចំពោះអតិថិជន។

ខ្ញុំនឹងផ្តល់ឧទាហរណ៍ចៃដន្យមួយចំនួនពីគម្រោងធំៗផ្សេងទៀតនៅខាងក្រៅ Google ប៉ុន្តែខ្ញុំសង្ឃឹមថាអ្នកនឹងឃើញគំរូនេះនៅគ្រប់ទីកន្លែង។ វាមានដូចខាងក្រោម៖ ភាពឆបគ្នាថយក្រោយរក្សាប្រព័ន្ធនៅរស់ និងទាន់សម័យអស់ជាច្រើនទសវត្សរ៍.

ភាពឆបគ្នាថយក្រោយគឺជាគោលដៅរចនានៃប្រព័ន្ធជោគជ័យទាំងអស់ដែលបានរចនាឡើងសម្រាប់ បើក ប្រើ នោះគឺបានអនុវត្តជាមួយកូដប្រភពបើកចំហ និង/ឬស្តង់ដារបើកចំហ។ ខ្ញុំ​មាន​អារម្មណ៍​ថា​ខ្ញុំ​កំពុង​តែ​និយាយ​អ្វី​មួយ​ច្បាស់​ពេក​ដែល​អ្នក​រាល់​គ្នា​មិន​ស្រួល​ខ្លួន ប៉ុន្តែ​អត់​ទេ។ នេះជាបញ្ហានយោបាយ ដូច្នេះត្រូវការឧទាហរណ៍។

ប្រព័ន្ធដំបូងដែលខ្ញុំនឹងជ្រើសរើសគឺចាស់ជាងគេ៖ GNU Emacs ដែលជាប្រភេទកូនកាត់រវាង Windows Notepad, OS kernel និងស្ថានីយ៍អវកាសអន្តរជាតិ។ វាពិបាកបន្តិចក្នុងការពន្យល់ ប៉ុន្តែនិយាយឱ្យចំទៅ Emacs គឺជាវេទិកាមួយដែលត្រូវបានបង្កើតឡើងក្នុងឆ្នាំ 1976 (បាទ ស្ទើរតែពាក់កណ្តាលសតវត្សមុន) សម្រាប់សរសេរកម្មវិធីដើម្បីធ្វើឱ្យអ្នកកាន់តែមានផលិតភាព ប៉ុន្តែការក្លែងបន្លំជាអ្នកកែអត្ថបទ។

ខ្ញុំប្រើ Emacs ជារៀងរាល់ថ្ងៃ។ បាទ/ចាស ខ្ញុំក៏ប្រើ IntelliJ ជារៀងរាល់ថ្ងៃដែរ វាបានរីកចម្រើនទៅជាវេទិកាឧបករណ៍ដ៏មានអានុភាពនៅក្នុងសិទ្ធិផ្ទាល់ខ្លួនរបស់វា។ ប៉ុន្តែការសរសេរផ្នែកបន្ថែមសម្រាប់ IntelliJ គឺជាការងារដែលមានមហិច្ឆតា និងស្មុគស្មាញជាងការសរសេរផ្នែកបន្ថែមសម្រាប់ Emacs ។ ហើយសំខាន់ជាងនេះទៅទៀត អ្វីគ្រប់យ៉ាងដែលសរសេរសម្រាប់ Emacs ត្រូវបានរក្សាទុក ជារៀងរហូត.

ខ្ញុំនៅតែប្រើកម្មវិធីដែលខ្ញុំបានសរសេរសម្រាប់ Emacs វិញក្នុងឆ្នាំ 1995។ ហើយខ្ញុំប្រាកដថានរណាម្នាក់កំពុងប្រើម៉ូឌុលដែលសរសេរសម្រាប់ Emacs នៅពាក់កណ្តាលទសវត្សរ៍ទី 80 ប្រសិនបើមិនមែនមុននេះទេ។ ពួកវាអាចត្រូវការការកែប្រែបន្តិចបន្តួចពីពេលមួយទៅពេលមួយ ប៉ុន្តែនេះពិតជាកម្រណាស់។ ខ្ញុំមិនដឹងពីអ្វីដែលខ្ញុំធ្លាប់សរសេរសម្រាប់ Emacs (ហើយខ្ញុំបានសរសេរច្រើន) ដែលទាមទារស្ថាបត្យកម្មឡើងវិញ។

Emacs មានមុខងារហៅថា make-obsolete សម្រាប់អង្គភាពដែលលែងប្រើ។ វាក្យស័ព្ទ Emacs សម្រាប់គោលគំនិតកុំព្យូទ័រជាមូលដ្ឋាន (ដូចជាអ្វីជា "បង្អួច") ជារឿយៗខុសពីអនុសញ្ញាឧស្សាហកម្ម ដោយសារ Emacs បានណែនាំពួកវាតាំងពីយូរយារណាស់មកហើយ។ នេះ​ជា​គ្រោះថ្នាក់​ធម្មតា​សម្រាប់​អ្នក​ដែល​នៅ​មុន​ពេល​វេលា៖ លក្ខខណ្ឌ​ទាំងអស់​របស់​អ្នក​មិន​ត្រឹមត្រូវ។ ប៉ុន្តែ Emacs មានគំនិតនៃការបដិសេធ ដែលនៅក្នុងភាសារបស់ពួកគេត្រូវបានគេហៅថា ភាពហួសសម័យ.

ប៉ុន្តែនៅក្នុងពិភព Emacs ហាក់ដូចជាមាននិយមន័យការងារខុសគ្នា។ ទស្សនវិជ្ជាមូលដ្ឋានផ្សេងគ្នា ប្រសិនបើអ្នកនឹង។

នៅក្នុងពិភពនៃ Emacs (និងនៅក្នុងតំបន់ជាច្រើនទៀតដែលយើងនឹងរៀបរាប់ខាងក្រោម) ស្ថានភាព API ដែលមិនគាំទ្រមានន័យថា៖ "អ្នកពិតជាមិនគួរប្រើវិធីសាស្រ្តនេះទេ ពីព្រោះខណៈពេលដែលវាដំណើរការ វាទទួលរងនូវការខ្វះខាតផ្សេងៗដែលយើងនឹង បញ្ជីនៅទីនេះ។ ប៉ុន្តែ​នៅ​ចុង​ថ្ងៃ​នេះ វា​ជា​ជម្រើស​របស់​អ្នក»។

នៅក្នុងពិភពលោករបស់ Google ការលែងប្រើមានន័យថា "យើងបំពានលើការប្តេជ្ញាចិត្តរបស់យើងចំពោះអ្នក"។ វា​ជា​ការពិត។ នេះគឺជាអ្វីដែលវាមានន័យយ៉ាងសំខាន់។ នេះមានន័យថាពួកគេនឹងបង្ខំអ្នក។ ជាទៀងទាត់ ធ្វើការងារខ្លះ ប្រហែលជាការងារច្រើន ជាការដាក់ទណ្ឌកម្មចំពោះការជឿលើពួកគេ។ ការផ្សាយពាណិជ្ជកម្មចម្រុះពណ៌៖ យើងមានកម្មវិធីល្អបំផុត។ លឿនបំផុត! អ្នកធ្វើអ្វីៗគ្រប់យ៉ាងតាមការណែនាំ បើកដំណើរការកម្មវិធី ឬសេវាកម្មរបស់អ្នក ហើយបន្ទាប់មក bam បន្ទាប់ពីមួយឆ្នាំ ឬពីរឆ្នាំវាដាច់។

វា​ដូច​ជា​ការ​លក់​ឡាន​ជជុះ​ដែល​ច្បាស់​ជា​ខូច​ក្រោយ 1500 គីឡូម៉ែត្រ។

ទាំងនេះគឺជានិយមន័យទស្សនវិជ្ជាខុសគ្នាទាំងស្រុងនៃ "ភាពអស់កល្ប"។ និយមន័យរបស់ Google នៃក្លិន ភាពយឺតយ៉ាវដែលបានគ្រោងទុក. ខ្ញុំមិនជឿរឿងនេះទេ។ ជាការពិត បានគ្រោងទុកភាពហួសសម័យក្នុងន័យដូចគ្នានឹង Apple ។ ប៉ុន្តែ Google ប្រាកដជាមានគម្រោងបំបែកកម្មវិធីរបស់អ្នក តាមរបៀបរង្វង់មូល។ ខ្ញុំ​ដឹង​រឿង​នេះ​ព្រោះ​ខ្ញុំ​ធ្វើ​ការ​នៅ​ទី​នោះ​ក្នុង​នាម​ជា​វិស្វករ​កម្មវិធី​អស់​រយៈ​ពេល​ជាង ១២ ឆ្នាំ។ ពួកគេមានគោលការណ៍ណែនាំខាងក្នុងមិនច្បាស់លាស់អំពីចំនួនភាពឆបគ្នាថយក្រោយគួរតែត្រូវបានអនុវត្តតាម ប៉ុន្តែនៅទីបំផុតវាអាស្រ័យលើក្រុម ឬសេវាកម្មនីមួយៗ។ មិនមានការណែនាំកម្រិតសហគ្រាស ឬវិស្វកម្មទេ ហើយអនុសាសន៍ដ៏អង់អាចបំផុតក្នុងលក្ខខណ្ឌនៃវដ្តនៃការលែងដំណើរការគឺ "ព្យាយាមផ្តល់ឱ្យអតិថិជន 12-6 ខែដើម្បីធ្វើឱ្យប្រសើរឡើង មុនពេលបំបែកប្រព័ន្ធទាំងមូលរបស់ពួកគេ។

បញ្ហាគឺធំជាងអ្វីដែលពួកគេគិត ហើយវានឹងបន្តកើតមានជាច្រើនឆ្នាំទៅមុខទៀត ដោយសារតែការថែទាំអតិថិជនមិនមាននៅក្នុង DNA របស់ពួកគេ។ បន្ថែមលើនេះខាងក្រោម។

នៅចំណុចនេះ ខ្ញុំនឹងធ្វើសេចក្តីថ្លែងការណ៍ដិតថា Emacs ទទួលបានជោគជ័យក្នុងកម្រិតធំ និងសូម្បីតែ ជាមូលដ្ឋាន ដោយសារតែពួកគេយកភាពឆបគ្នាថយក្រោយយ៉ាងខ្លាំង។ តាមពិតនេះគឺជានិក្ខេបបទនៃអត្ថបទរបស់យើង។ ប្រព័ន្ធបើកចំហដែលជោគជ័យ និងយូរអង្វែង ជំពាក់ភាពជោគជ័យរបស់ពួកគេចំពោះមីក្រូសហគមន៍ដែលរស់នៅជុំវិញពួកគេអស់ជាច្រើនទសវត្សរ៍ ផ្នែកបន្ថែម/កម្មវិធីជំនួយ. នេះគឺជាប្រព័ន្ធអេកូឡូស៊ី។ ខ្ញុំបាននិយាយរួចមកហើយអំពីលក្ខណៈនៃវេទិកា និងរបៀបដែលវាមានសារៈសំខាន់ និងរបៀបដែល Google មិនដែលមាននៅក្នុងប្រវត្តិសាជីវកម្មទាំងមូលរបស់ខ្លួនបានយល់ពីអ្វីដែលចូលទៅក្នុងការបង្កើតវេទិកាបើកចំហដែលទទួលបានជោគជ័យនៅខាងក្រៅប្រព័ន្ធប្រតិបត្តិការ Android ឬ Chrome ។

តាម​ពិត​ទៅ ខ្ញុំ​គួរ​និយាយ​អំពី​ប្រព័ន្ធ​ប្រតិបត្តិការ Android ដោយ​សង្ខេប ព្រោះ​អ្នក​ប្រហែល​ជា​គិត​អំពី​វា។

ជាបឋម, Android មិនមែន Google ទេ។. ពួកគេស្ទើរតែគ្មានអ្វីដូចគ្នាទេ។ ប្រព័ន្ធប្រតិបត្តិការ Android គឺជាក្រុមហ៊ុនមួយដែលត្រូវបានទិញដោយ Google ក្នុងខែកក្កដា ឆ្នាំ 2005 ក្រុមហ៊ុននេះត្រូវបានអនុញ្ញាតឱ្យធ្វើប្រតិបត្តិការដោយស្វ័យភាពតិច ឬច្រើន ហើយតាមពិតនៅតែមិនមានផលប៉ះពាល់ច្រើននៅក្នុងឆ្នាំអន្តរាគន៍។ ប្រព័ន្ធប្រតិបត្តិការ Android គឺជាជង់បច្ចេកវិទ្យាដ៏ល្បីឈ្មោះ និងជាអង្គការដ៏ល្បីឈ្មោះដូចគ្នា។ ដូចដែល Googler ម្នាក់បាននិយាយថា "អ្នកមិនអាចគ្រាន់តែចូលទៅក្នុងប្រព័ន្ធប្រតិបត្តិការ Android បានទេ។

នៅក្នុងអត្ថបទមុន ខ្ញុំបានពិភាក្សាថាតើការសម្រេចចិត្តរចនាដំបូងរបស់ Android អាក្រក់ប៉ុណ្ណា។ Heck នៅពេលដែលខ្ញុំសរសេរអត្ថបទនោះ ពួកគេបានបញ្ចេញនូវកម្មវិធីដែលហៅថា "កម្មវិធីបន្ទាន់" ដែលឥឡូវនេះ (ភ្ញាក់ផ្អើល!) ហួសសម័យហើយខ្ញុំអាណិតប្រសិនបើអ្នកល្ងង់គ្រប់គ្រាន់ក្នុងការស្តាប់ Google និងផ្លាស់ទីមាតិការបស់អ្នកទៅកម្មវិធីភ្លាមៗទាំងនេះ។

ប៉ុន្តែមានភាពខុសប្លែកគ្នានៅទីនេះ ភាពខុសគ្នាសំខាន់នោះគឺថាមនុស្ស Android ពិតជាយល់ពីរបៀបដែលវេទិកាមានសារៈសំខាន់ ពួកគេព្យាយាមអស់ពីសមត្ថភាពដើម្បីរក្សាកម្មវិធី Android ចាស់ៗដំណើរការ។ ជាការពិត ការខិតខំប្រឹងប្រែងរបស់ពួកគេដើម្បីរក្សាភាពត្រូវគ្នាពីក្រោយគឺខ្លាំងពេក ដែលសូម្បីតែខ្ញុំក្នុងអំឡុងពេលខ្លីរបស់ខ្ញុំនៅផ្នែក Android កាលពីប៉ុន្មានឆ្នាំមុន បានរកឃើញថាខ្ញុំព្យាយាមបញ្ចុះបញ្ចូលពួកគេឱ្យទម្លាក់ការគាំទ្រសម្រាប់ឧបករណ៍ និង APIs ចាស់បំផុតមួយចំនួន (ខ្ញុំខុស ដូចនៅក្នុងរឿងជាច្រើនទៀតកាលពីអតីតកាល និងបច្ចុប្បន្ន។ សូមអភ័យទោសចំពោះ Android! ឥឡូវនេះខ្ញុំបានទៅប្រទេសឥណ្ឌូនេស៊ីហើយ ខ្ញុំយល់ថាហេតុអ្វីបានជាយើងត្រូវការវា)។

ប្រជាជន Android ជំរុញភាពឆបគ្នាថយក្រោយទៅនឹងភាពធ្ងន់ធ្ងរស្ទើរតែមិនអាចនឹកស្មានដល់ ដោយប្រមូលផ្តុំនូវបំណុលបច្ចេកទេសដ៏ច្រើនសន្ធឹកសន្ធាប់នៅក្នុងប្រព័ន្ធ និងខ្សែសង្វាក់ឧបករណ៍របស់ពួកគេ។ ឱព្រះជាម្ចាស់អើយ អ្នកគួរតែឃើញរឿងឆ្កួតៗមួយចំនួនដែលពួកគេត្រូវធ្វើនៅក្នុងប្រព័ន្ធស្ថាបនារបស់ពួកគេ ទាំងអស់ក្នុងនាមនៃភាពឆបគ្នា។

សម្រាប់រឿងនេះ ខ្ញុំផ្តល់រង្វាន់ដល់ Android នូវពានរង្វាន់ "You're Not Google" ដែលចង់បាន។ ពួកគេពិតជាមិនចង់ក្លាយជា Google ដែលមិនដឹងពីរបៀបបង្កើតវេទិកាប្រើប្រាស់បានយូរនោះទេ ប៉ុន្តែប្រព័ន្ធប្រតិបត្តិការ Android ដឹង, របៀបធ្វើវា។ ដូច្នេះហើយ Google មានភាពឆ្លាតវៃក្នុងន័យមួយ៖ អនុញ្ញាតឱ្យមនុស្សធ្វើអ្វីៗតាមវិធីផ្ទាល់ខ្លួនរបស់ពួកគេនៅលើ Android ។

ទោះយ៉ាងណាក៏ដោយ កម្មវិធីភ្លាមៗសម្រាប់ Android គឺជាគំនិតឆោតល្ងង់ណាស់។ ហើយ​តើ​អ្នក​ដឹង​ទេ​ថា​ហេតុអ្វី​? ដោយសារតែពួកគេបានទាមទារ សរសេរឡើងវិញ និងរចនាកម្មវិធីរបស់អ្នកឡើងវិញ! វាហាក់ដូចជាមនុស្សនឹងសរសេរឡើងវិញនូវកម្មវិធីចំនួនពីរលាន។ ខ្ញុំគិតថា Instant Apps គឺជាគំនិតរបស់ Googler ។

ប៉ុន្តែមានភាពខុសគ្នាមួយ។ ភាពឆបគ្នាថយក្រោយមកក្នុងការចំណាយខ្ពស់។ Android ខ្លួន​ឯង​ទទួល​បន្ទុក​នៃ​ការ​ចំណាយ​ទាំង​នេះ ខណៈ Google ទទូច​ថា​បន្ទុក​ត្រូវ​បាន​ទទួល អ្នកគឺជា, អតិថិជនបង់ប្រាក់។

អ្នកអាចឃើញការប្តេជ្ញាចិត្តរបស់ Android ចំពោះភាពឆបគ្នាថយក្រោយនៅក្នុង APIs របស់វា។ នៅពេលដែលអ្នកមានប្រព័ន្ធរងចំនួន XNUMX ឬ XNUMX ផ្សេងគ្នាដែលធ្វើរឿងដូចគ្នាយ៉ាងពិតប្រាកដ វាជាសញ្ញាប្រាកដថាមានការប្តេជ្ញាចិត្តចំពោះភាពឆបគ្នាថយក្រោយនៅស្នូល។ ដែលនៅក្នុងពិភពនៃវេទិកាគឺមានន័យដូចនឹងការប្តេជ្ញាចិត្តចំពោះអតិថិជន និងទីផ្សាររបស់អ្នក។

បញ្ហាចម្បងរបស់ Google នៅទីនេះគឺមោទនភាពរបស់ពួកគេចំពោះអនាម័យផ្នែកវិស្វកម្មរបស់ពួកគេ។ ពួកគេមិនចូលចិត្តវានៅពេលដែលមានវិធីផ្សេងគ្នាជាច្រើនដើម្បីធ្វើរឿងដដែលជាមួយនឹងវិធីចាស់ដែលមិនសូវចង់បានអង្គុយក្បែរវិធីថ្មីដែលគួរឱ្យចាប់អារម្មណ៍។ វាបង្កើនខ្សែកោងការរៀនសូត្រសម្រាប់អ្នកថ្មីចំពោះប្រព័ន្ធ វាបង្កើនបន្ទុកក្នុងការថែរក្សា APIs ចាស់ វាបន្ថយល្បឿននៃមុខងារថ្មីៗ ហើយអំពើបាបសំខាន់គឺវាមិនស្អាតទេ។ Google - ដូចជា Lady Ascot ពី Tim Burton's Alice in Wonderland៖

Lady Ascot៖
- អាលីស តើអ្នកដឹងថាខ្ញុំខ្លាចអ្វីជាងគេទេ?
- ការធ្លាក់ចុះនៃអភិជន?
- ខ្ញុំខ្លាចថាខ្ញុំនឹងមាន ចៅអាក្រក់.

ដើម្បីយល់ពីការដោះដូររវាងភាពស្រស់ស្អាត និងជាក់ស្តែង សូមមើលវេទិកាជោគជ័យទីបី (បន្ទាប់ពី Emacs និង Android) ហើយមើលពីរបៀបដែលវាដំណើរការ៖ Java ខ្លួនវាផ្ទាល់។

Java មាន API ហួសសម័យជាច្រើន។ ការបដិសេធគឺមានប្រជាប្រិយភាពយ៉ាងខ្លាំងក្នុងចំណោមអ្នកសរសេរកម្មវិធី Java សូម្បីតែពេញនិយមជាងភាសាសរសេរកម្មវិធីភាគច្រើន។ Java ខ្លួនឯង ភាសាស្នូល និងបណ្ណាល័យកំពុងបដិសេធជានិច្ច APIs ។

ដើម្បីយកឧទាហរណ៍មួយក្នុងចំណោមឧទាហរណ៍រាប់ពាន់។ ខ្សែស្រឡាយបិទ ចាត់ទុកថាលែងប្រើ។ វាត្រូវបានបដិសេធចាប់តាំងពីការចេញផ្សាយ Java 1.2 ក្នុងខែធ្នូ ឆ្នាំ 1998។ វាមានរយៈពេល 22 ឆ្នាំហើយចាប់តាំងពីវាត្រូវបានបដិសេធ។

ប៉ុន្តែកូដពិតប្រាកដរបស់ខ្ញុំនៅក្នុងផលិតកម្មនៅតែសម្លាប់ខ្សែស្រឡាយ រាល់ថ្ងៃ. តើអ្នកពិតជាគិតថាវាល្អមែនទេ? ដាច់ខាត! ខ្ញុំចង់មានន័យថា ប្រសិនបើខ្ញុំសរសេរកូដឡើងវិញនៅថ្ងៃនេះ ខ្ញុំនឹងអនុវត្តវាខុសគ្នា។ ប៉ុន្តែកូដសម្រាប់ហ្គេមរបស់ខ្ញុំ ដែលបានធ្វើឱ្យមនុស្សរាប់សែននាក់សប្បាយចិត្តក្នុងរយៈពេល XNUMX ទស្សវត្សកន្លងមកនេះ ត្រូវបានសរសេរជាមួយនឹងមុខងារមួយដើម្បីបិទខ្សែស្រឡាយដែលព្យួរយូរពេក ហើយខ្ញុំ មិនដែលមានដើម្បីផ្លាស់ប្តូរវាទេ។. ខ្ញុំស្គាល់ប្រព័ន្ធរបស់ខ្ញុំបានល្អជាងអ្នកណាម្នាក់ ខ្ញុំមានបទពិសោធន៍ 25 ឆ្នាំក្នុងការធ្វើការជាមួយវានៅក្នុងផលិតកម្ម ហើយខ្ញុំអាចនិយាយបានថា: ក្នុងករណីរបស់ខ្ញុំ ការបិទខ្សែស្រឡាយបុគ្គលិកជាក់លាក់ទាំងនេះគឺទាំងស្រុង។ គ្មានគ្រោះថ្នាក់. វាមិនសមនឹងពេលវេលា និងការខិតខំប្រឹងប្រែងដើម្បីសរសេរកូដនេះឡើងវិញទេ ហើយសូមអរគុណ Larry Ellison (ប្រហែលជា) ដែល Oracle មិនបានបង្ខំខ្ញុំឱ្យសរសេរវាឡើងវិញ។

Oracle ប្រហែលជាយល់អំពីវេទិកាផងដែរ។ អ្នកណាដឹង។

ភ័ស្តុតាងអាចត្រូវបានរកឃើញនៅទូទាំង Java APIs ស្នូល ដែលត្រូវបានប្រេះឆាជាមួយនឹងរលកនៃភាពលែងដំណើរការ ដូចជាបន្ទាត់នៃផ្ទាំងទឹកកកនៅក្នុងអន្លង់។ អ្នកអាចស្វែងរកបានយ៉ាងងាយស្រួលនូវកម្មវិធីគ្រប់គ្រងការរុករកក្តារចុចប្រាំ ឬប្រាំមួយផ្សេងគ្នា (KeyboardFocusManager) នៅក្នុងបណ្ណាល័យ Java Swing ។ តាមពិតវាពិបាកក្នុងការស្វែងរក Java API ដែលមិនត្រូវបានបដិសេធ។ ប៉ុន្តែពួកគេនៅតែធ្វើការ! ខ្ញុំ​គិត​ថា​ក្រុម Java នឹង​ដក API ចេញ​យ៉ាង​ពិត​ប្រាកដ ប្រសិន​បើ​ចំណុច​ប្រទាក់​បង្ក​បញ្ហា​សុវត្ថិភាព​មិន​ច្បាស់។

នេះ​ជា​រឿង​ដែល​មនុស្ស​ទូទៅ៖ យើង​អ្នក​បង្កើត​កម្មវិធី​គឺ​រវល់​ខ្លាំង​ណាស់ ហើយ​នៅ​គ្រប់​ផ្នែក​នៃ​កម្មវិធី​យើង​ត្រូវ​ប្រឈម​មុខ​នឹង​ជម្រើស​ដែល​ប្រកួតប្រជែង។ នៅពេលណាមួយ អ្នកសរសេរកម្មវិធីជាភាសា X កំពុងពិចារណាភាសា Y ជាការជំនួសដែលអាចធ្វើទៅបាន។ អូ អ្នកមិនជឿខ្ញុំទេ? តើអ្នកចង់ហៅវាថា Swift ទេ? ដូចដែរ គ្រប់គ្នាកំពុងធ្វើចំណាកស្រុកទៅ Swift ហើយគ្មាននរណាម្នាក់បោះបង់ចោលវាទេមែនទេ? អីយ៉ាស់ អ្នកដឹងតិច។ ក្រុមហ៊ុនកំពុងរាប់តម្លៃនៃក្រុមអភិវឌ្ឍន៍ទូរស័ព្ទពីរ (iOS និង Android) ហើយពួកគេចាប់ផ្តើមដឹងថាប្រព័ន្ធអភិវឌ្ឍន៍ឆ្លងវេទិកាទាំងនោះដែលមានឈ្មោះគួរឱ្យអស់សំណើចដូចជា Flutter និង React Native ពិតជាដំណើរការ និងអាចប្រើដើម្បីកាត់បន្ថយទំហំរបស់ពួកគេ។ ក្រុមចល័តពីរដង ឬផ្ទុយទៅវិញ ធ្វើឱ្យពួកគេមានផលិតភាពពីរដង។ មានលុយពិតប្រាកដនៅក្នុងភាគហ៊ុន។ បាទ មានការសម្របសម្រួល ប៉ុន្តែផ្ទុយទៅវិញ លុយកាក់។

ចូរសន្មតថា Apple បានយកតម្រុយពី Guido van Rossum ដោយល្ងង់ ហើយបានប្រកាសថា Swift 6.0 គឺមិនឆបគ្នាជាមួយ Swift 5.0 ដូច Python 3 មិនឆបគ្នាជាមួយ Python 2 ដែរ។

ខ្ញុំប្រហែលជាបានប្រាប់រឿងនេះកាលពីដប់ឆ្នាំមុន ប៉ុន្តែប្រហែលដប់ប្រាំឆ្នាំមុនខ្ញុំបានទៅជំរុំ Foo របស់ O'Reilly ជាមួយ Guido អង្គុយក្នុងតង់ជាមួយ Paul Graham និងការបាញ់ប្រហារជាច្រើន។ យើងបានអង្គុយក្នុងកំដៅដ៏ក្តៅគគុករង់ចាំ Larry Page ដើម្បីហោះហើរចេញតាមឧទ្ធម្ភាគចក្រផ្ទាល់ខ្លួនរបស់គាត់ ខណៈដែល Guido ជិះលើយន្តហោះប្រហែល "Python 3000" ដែលគាត់បានដាក់ឈ្មោះតាមចំនួនឆ្នាំដែលវានឹងត្រូវការសម្រាប់មនុស្សគ្រប់គ្នាដើម្បីធ្វើចំណាកស្រុកនៅទីនោះ។ យើង​បាន​បន្ត​សួរ​គាត់​ថា​ហេតុ​អ្វី​បាន​ជា​គាត់​បំបែក​ភាព​ត្រូវ​គ្នា ហើយ​គាត់​បាន​ឆ្លើយ​ថា៖ «យូនីកូដ»។ ហើយ​យើង​សួរ​ថា បើ​យើង​ត្រូវ​សរសេរ​កូដ​ឡើង​វិញ តើ​យើង​នឹង​ឃើញ​អត្ថប្រយោជន៍​អ្វី​ទៀត? ហើយ​គាត់​បាន​ឆ្លើយ​តប​ថា "យូយូ​អូ​អូ​អូ​អូ​អូ​ហូ​វូ​យូ​នី​កូ​អូ​អូ​អូ​អូ​" ។

ប្រសិនបើអ្នកដំឡើង Google Cloud Platform SDK (“gcloud”) អ្នកនឹងទទួលបានការជូនដំណឹងដូចខាងក្រោម៖

អ្នកទទួលជាទីគោរព!

យើង​ចង់​រំលឹក​អ្នក​ថា​ការ​គាំទ្រ​សម្រាប់ Python 2 ត្រូវ​បាន​គេ​បដិសេធ ដូច្នេះ​សូម​កុំ​ឱ្យ​អ្នក​អស់​សង្ឃឹម

… ល​ល។ រង្វង់នៃជីវិត។

ប៉ុន្តែចំណុចនោះគឺថាអ្នកអភិវឌ្ឍន៍គ្រប់រូបមានជម្រើស។ ហើយប្រសិនបើអ្នកបង្ខំពួកគេឱ្យសរសេរកូដឡើងវិញឱ្យបានញឹកញាប់គ្រប់គ្រាន់ ពួកគេប្រហែលជាគិតអំពី ផ្សេងទៀត ជម្រើស។ ពួកគេមិនមែនជាចំណាប់ខ្មាំងរបស់អ្នកទេ ទោះបីជាអ្នកចង់ឱ្យពួកគេក្លាយជាចំណាប់ខ្មាំងប៉ុណ្ណាក៏ដោយ។ ពួកគេគឺជាភ្ញៀវរបស់អ្នក។ Python នៅតែជាភាសាសរសេរកម្មវិធីដ៏ពេញនិយមមួយ ប៉ុន្តែអាក្រក់ណាស់ Python 3(000) បានបង្កើតភាពរញ៉េរញ៉ៃបែបនេះនៅក្នុងខ្លួនវា នៅក្នុងសហគមន៍របស់វា និងក្នុងចំណោមអ្នកប្រើប្រាស់សហគមន៍របស់វា ដែលផលវិបាកមិនត្រូវបានលុបចោលអស់រយៈពេលដប់ប្រាំឆ្នាំមកហើយ។

តើកម្មវិធី Python ប៉ុន្មានត្រូវបានសរសេរឡើងវិញនៅក្នុង Go (ឬ Ruby ឬជម្រើសផ្សេងទៀត) ដោយសារតែភាពមិនឆបគ្នាថយក្រោយនេះ? តើកម្មវិធីថ្មីប៉ុន្មានត្រូវបានសរសេរនៅក្នុងអ្វីមួយក្រៅពី Python ទោះបីជាវាក៏ដោយ។ អាច​ជា សរសេរជាភាសា Python បើ Guido មិនដុតបំផ្លាញភូមិទាំងមូលទេ? វាពិបាកក្នុងការនិយាយ ប៉ុន្តែ Python បានរងទុក្ខយ៉ាងច្បាស់។ វាជាការរញ៉េរញ៉ៃដ៏ធំ ហើយគ្រប់គ្នាចាញ់។

ដូច្នេះសូមនិយាយថា Apple យកតម្រុយពី Guido ហើយបំបែកភាពឆបគ្នា។ តើអ្នកគិតថានឹងមានអ្វីកើតឡើងបន្ទាប់? ជាការប្រសើរណាស់, ប្រហែលជា 80-90% នៃអ្នកអភិវឌ្ឍន៍នឹងសរសេរកម្មវិធីរបស់ពួកគេឡើងវិញប្រសិនបើអាចធ្វើទៅបាន។ និយាយម្យ៉ាងទៀត 10-20% នៃមូលដ្ឋានអ្នកប្រើប្រាស់ដោយស្វ័យប្រវត្តិទៅកាន់ភាសាប្រកួតប្រជែងមួយចំនួនដូចជា Flutter ជាដើម។

ធ្វើបែបនេះច្រើនដង ហើយអ្នកនឹងបាត់បង់មូលដ្ឋានអ្នកប្រើប្រាស់របស់អ្នកពាក់កណ្តាល។ ដូចនៅក្នុងកីឡាដែរ នៅក្នុងពិភពនៃការសរសេរកម្មវិធី ទម្រង់បច្ចុប្បន្នក៏សំខាន់ដែរ។ អ្វីគ្រប់យ៉ាង. នរណាម្នាក់ដែលបាត់បង់អ្នកប្រើប្រាស់ពាក់កណ្តាលក្នុងរយៈពេល XNUMX ឆ្នាំនឹងត្រូវបានចាត់ទុកថាជាអ្នកចាញ់ខ្លាញ់ធំ។ អ្នកត្រូវតែមានភាពទាន់សម័យនៅក្នុងពិភពនៃវេទិកា។ ប៉ុន្តែនេះជាកន្លែងដែលមិនគាំទ្រកំណែចាស់នឹងបំផ្លាញអ្នកតាមពេលវេលា។ ដោយសារតែរាល់ពេលដែលអ្នកកម្ចាត់អ្នកអភិវឌ្ឍន៍មួយចំនួន អ្នក (ក) បាត់បង់ពួកគេជារៀងរហូត ដោយសារតែពួកគេខឹងនឹងអ្នកចំពោះការបំពានកិច្ចសន្យា ហើយ (ខ) បាត់បង់ពួកគេទៅដៃគូប្រកួតប្រជែងរបស់អ្នក។

គួរឱ្យអស់សំណើចផងដែរ ខ្ញុំក៏បានជួយ Google ឱ្យក្លាយជាដូនណា prima ដែលមិនអើពើនឹងភាពឆបគ្នាថយក្រោយ នៅពេលដែលខ្ញុំបង្កើត Grok ដែលជាប្រព័ន្ធវិភាគប្រភព និងការយល់ដឹងដែលធ្វើឱ្យវាងាយស្រួលក្នុងការធ្វើស្វ័យប្រវត្តិកម្ម និងឧបករណ៍កូដដោយខ្លួនឯង ដែលស្រដៀងទៅនឹង IDE ប៉ុន្តែនៅទីនេះ សេវាកម្មពពក តំណាង​ឱ្យ​បាន​ក្លាយ​ជា​តំណាង​នៃ​ជួរ​រាប់​ពាន់​លាន​នៃ​កូដ​ប្រភព Google ក្នុង​ឃ្លាំង​ទិន្នន័យ​ធំ។

Grok បានផ្តល់ឲ្យ Googlers នូវក្របខ័ណ្ឌដ៏មានអានុភាពសម្រាប់អនុវត្តការកែលម្អដោយស្វ័យប្រវត្តិនៅទូទាំងមូលដ្ឋានកូដរបស់ពួកគេ (តាមន័យត្រង់នៅទូទាំង Google) ។ ប្រព័ន្ធ​គណនា​មិន​ត្រឹម​តែ​ការ​អាស្រ័យ​លើ​ចរន្ត​របស់​អ្នក​ប៉ុណ្ណោះ​ទេ (ដែល​អ្នក​អាស្រ័យ​) ​ប៉ុន្តែ​ក៏​ដែរ។ ចុះក្រោម (ដែលអាស្រ័យលើអ្នក) ដូច្នេះនៅពេលអ្នកផ្លាស់ប្តូរ APIs អ្នកដឹងថាអ្នកកំពុងបំបែក! វិធីនេះ នៅពេលអ្នកធ្វើការផ្លាស់ប្តូរ អ្នកអាចផ្ទៀងផ្ទាត់ថារាល់អ្នកប្រើប្រាស់ API របស់អ្នកបានធ្វើបច្ចុប្បន្នភាពទៅកំណែថ្មី ហើយតាមពិត ជាញឹកញាប់ជាមួយឧបករណ៍ Rosie ដែលពួកគេបានសរសេរ អ្នកអាចធ្វើឱ្យដំណើរការដោយស្វ័យប្រវត្តិទាំងស្រុង។

នេះអនុញ្ញាតឱ្យមូលដ្ឋានកូដរបស់ Google មានភាពស្អាតស្អំខាងក្នុងស្ទើរតែគ្មានធម្មជាតិ ព្រោះពួកគេមានអ្នកបម្រើមនុស្សយន្តទាំងនេះដើរលេងជុំវិញផ្ទះ ហើយសម្អាតអ្វីៗគ្រប់យ៉ាងដោយស្វ័យប្រវត្តិ ប្រសិនបើពួកគេប្តូរឈ្មោះ SomeDespicablyLongFunctionName ទៅ SomeDespicablyLongMethodName ពីព្រោះមាននរណាម្នាក់បានសម្រេចចិត្តថាវាជាចៅដ៏អាក្រក់ ហើយគាត់ត្រូវការឱ្យគាត់ដេក។

ហើយនិយាយដោយត្រង់ទៅ វាដំណើរការល្អណាស់សម្រាប់ Google... ខាងក្នុង។ ខ្ញុំចង់និយាយថា បាទ សហគមន៍ Go នៅ Google មានការសើចសប្បាយជាមួយសហគមន៍ Java នៅ Google ដោយសារតែទម្លាប់របស់ពួកគេក្នុងការបន្តជួសជុលឡើងវិញ។ ប្រសិនបើអ្នកចាប់ផ្តើមអ្វីមួយ N ដង នោះមានន័យថាអ្នកមិនត្រឹមតែចុច N-1 ដងប៉ុណ្ណោះទេប៉ុន្តែបន្ទាប់ពីមួយរយៈក្រោយមកវាច្បាស់ណាស់ថាអ្នកប្រហែលជាវីសវានៅលើ Nth ផងដែរ។ ប៉ុន្តែដោយ និងធំ ពួកគេនៅតែស្ថិតនៅពីលើភាពច្របូកច្របល់ទាំងអស់នេះ ហើយរក្សាលេខកូដ "ស្អាត" ។

បញ្ហាចាប់ផ្តើមនៅពេលដែលពួកគេព្យាយាមដាក់ឥរិយាបថនេះលើអតិថិជនពពករបស់ពួកគេ និងអ្នកប្រើប្រាស់ APIs ផ្សេងទៀត។

ខ្ញុំបានណែនាំអ្នកបន្តិចអំពី Emacs, Android និង Java; សូមក្រឡេកមើលវេទិកាដែលប្រើប្រាស់បានយូរបំផុតដែលទទួលបានជោគជ័យបំផុត៖ គេហទំព័រខ្លួនឯង។ អ្នកអាចស្រមៃមើលថាតើ HTTP បានឆ្លងកាត់ប៉ុន្មានដងចាប់តាំងពីឆ្នាំ 1995 នៅពេលដែលយើងប្រើស្លាក ភ្លឹបភ្លែតៗ និងរូបតំណាង "កំពុងសាងសង់" នៅលើទំព័របណ្តាញ។

ប៉ុន្តែវានៅតែដំណើរការ! ហើយទំព័រទាំងនេះនៅតែដំណើរការ! បាទ, មនុស្ស, កម្មវិធីរុករកគឺជាជើងឯកនៃភាពឆបគ្នាថយក្រោយនៃពិភពលោក។ Chrome គឺជាឧទាហរណ៍មួយផ្សេងទៀតនៃវេទិកា Google ដ៏កម្រដែលមានក្បាលរបស់វាវីសត្រឹមត្រូវ ហើយដូចដែលអ្នកបានទាយថា Chrome ដំណើរការប្រកបដោយប្រសិទ្ធភាពជាក្រុមហ៊ុន sandbox ដាច់ដោយឡែកពី Google ដែលនៅសល់។

ខ្ញុំក៏ចង់ថ្លែងអំណរគុណដល់មិត្តភ័ក្តិរបស់យើងនៅក្នុងអ្នកបង្កើតប្រព័ន្ធប្រតិបត្តិការ៖ Windows, Linux, Not APPLE FUCK You APPLE, FreeBSD, etc. សម្រាប់ការធ្វើការងារដ៏អស្ចារ្យបែបនេះនៃភាពឆបគ្នាថយក្រោយនៅលើវេទិកាជោគជ័យរបស់ពួកគេ (Apple ទទួលបាន C ល្អបំផុតជាមួយ គុណវិបត្តិគឺថាពួកគេបំបែកអ្វីៗគ្រប់យ៉ាងគ្រប់ពេលដោយគ្មានហេតុផលល្អ ប៉ុន្តែដូចម្ដេចដែលសហគមន៍ទទួលបានជុំវិញវាជាមួយនឹងការចេញផ្សាយនីមួយៗ ហើយធុងផ្ទុក OS X នៅតែមិនទាន់អស់សុពលភាពនៅឡើយ...)។

ប៉ុន្តែរង់ចាំអ្នកនិយាយ។ តើយើងមិនប្រៀបធៀបផ្លែប៉ោមទៅនឹងផ្លែក្រូចទេ - ប្រព័ន្ធកម្មវិធីដាច់ដោយឡែកនៅលើម៉ាស៊ីនតែមួយដូចជា Emacs/JDK/Android/Chrome ដែលមានប្រព័ន្ធម៉ាស៊ីនមេច្រើន និង APIs ដូចជាសេវាកម្មពពក?

ជាការប្រសើរណាស់, ខ្ញុំបាន tweeted អំពីរឿងនេះកាលពីម្សិលមិញ, ប៉ុន្តែនៅក្នុងរចនាប័ទ្មរបស់ Larry Wall (អ្នកបង្កើតភាសាកម្មវិធី Perl - ប្រហែល per ។ ) នៅលើគោលការណ៍នៃ "sucks / ច្បាប់" ខ្ញុំបានរកមើលពាក្យ មិនពេញចិត្ត នៅលើគេហទំព័រអ្នកអភិវឌ្ឍន៍ Google និង Amazon ។ ហើយទោះបីជា AWS មាន រាប់រយនាក់ ការផ្តល់ជូនសេវាកម្មច្រើនជាង GCP ឯកសារអ្នកអភិវឌ្ឍន៍របស់ Google និយាយអំពីការបដិសេធប្រហែល XNUMX ដងញឹកញាប់ជាង។

ប្រសិនបើអ្នកណាម្នាក់នៅ Google កំពុងអានរឿងនេះ ពួកគេប្រហែលជាត្រៀមខ្លួនរួចជាស្រេចដើម្បីដកគំនូសតាងតាមបែប Donald Trump ដែលបង្ហាញថាពួកគេពិតជាកំពុងធ្វើអ្វីគ្រប់យ៉ាងត្រឹមត្រូវ ហើយថាខ្ញុំមិនគួរធ្វើការប្រៀបធៀបអយុត្តិធម៌ដូចជា "ចំនួននៃការលើកឡើងនៃពាក្យដែលមិនគាំទ្រធៀបនឹង ចំនួនសេវាកម្ម ""

ប៉ុន្តែបន្ទាប់ពីប៉ុន្មានឆ្នាំមកនេះ Google Cloud នៅតែជាសេវាកម្មលេខ 3 (ខ្ញុំមិនដែលសរសេរអត្ថបទអំពីការបរាជ័យក្នុងការក្លាយជាលេខ 2 ទេ) ប៉ុន្តែប្រសិនបើមានអ្នកខាងក្នុងត្រូវជឿ វាមានការព្រួយបារម្ភខ្លះថាពួកគេអាចនឹងធ្លាក់ចុះក្នុងពេលឆាប់ៗនេះ។ លេខ 4 ។

ខ្ញុំមិនមានអំណះអំណាងគួរឱ្យទាក់ទាញណាមួយដើម្បី "បញ្ជាក់" និក្ខេបបទរបស់ខ្ញុំទេ។ អ្វីទាំងអស់ដែលខ្ញុំមានគឺជាឧទាហរណ៍ចម្រុះពណ៌ដែលខ្ញុំបានប្រមូលផ្តុំជាង 30 ឆ្នាំជាអ្នកអភិវឌ្ឍន៍។ ខ្ញុំបានរៀបរាប់រួចហើយអំពីលក្ខណៈទស្សនវិជ្ជាយ៉ាងជ្រាលជ្រៅនៃបញ្ហានេះ។ នៅក្នុងវិធីមួយចំនួនវាត្រូវបានធ្វើនយោបាយនៅក្នុងសហគមន៍អ្នកអភិវឌ្ឍន៍។ អ្នកខ្លះជឿថា អ្នកបង្កើត វេទិកាគួរយកចិត្តទុកដាក់ចំពោះភាពឆបគ្នា ខណៈពេលដែលអ្នកផ្សេងទៀតគិតថានេះជាកង្វល់ អ្នកប្រើប្រាស់ (អ្នកអភិវឌ្ឍន៍ខ្លួនឯង) ។ មួយក្នុងចំនោមពីរ។ ជាការពិត វាមិនមែនជាបញ្ហានយោបាយទេ នៅពេលដែលយើងសម្រេចចិត្តថាអ្នកណាគួរទទួលបន្ទុកនៃបញ្ហាទូទៅ?

ដូច្នេះ​នេះ​ជា​នយោបាយ។ ហើយ​ប្រហែល​ជា​នឹង​មាន​ការ​ឆ្លើយ​តប​ដោយ​កំហឹង​ចំពោះ​ការ​និយាយ​របស់​ខ្ញុំ។

តើធ្វើដូចម្តេច អ្នកប្រើ។ Google Cloud Platform និងក្នុងនាមជាអ្នកប្រើប្រាស់ AWS អស់រយៈពេលពីរឆ្នាំ (ពេលធ្វើការឱ្យ Grab) ខ្ញុំអាចនិយាយបានថាមានភាពខុសប្លែកគ្នាយ៉ាងខ្លាំងរវាងទស្សនវិជ្ជារបស់ Amazon និង Google នៅពេលនិយាយអំពីអាទិភាព។ ខ្ញុំ​មិន​បាន​អភិវឌ្ឍ​យ៉ាង​សកម្ម​លើ AWS ទេ ដូច្នេះ​ខ្ញុំ​មិន​ដឹង​ច្បាស់​ថា​តើ​ពួកគេ​លុប APIs ចាស់​ញឹកញាប់​ប៉ុណ្ណា​ទេ។ ប៉ុន្តែមានការសង្ស័យថារឿងនេះមិនកើតឡើងញឹកញាប់ដូចនៅ Google ទេ។ ហើយខ្ញុំពិតជាជឿថាប្រភពនៃភាពចម្រូងចម្រាស និងការខកចិត្តឥតឈប់ឈរនៅក្នុង GCP គឺជាកត្តាដ៏ធំបំផុតមួយដែលរារាំងការអភិវឌ្ឍន៍របស់វេទិកានេះ។

ខ្ញុំដឹងថាខ្ញុំមិនបានដាក់ឈ្មោះឧទាហរណ៍ជាក់លាក់នៃប្រព័ន្ធ GCP ដែលលែងត្រូវបានគាំទ្រ។ ខ្ញុំអាចនិយាយបានថាស្ទើរតែគ្រប់អ្វីៗទាំងអស់ដែលខ្ញុំបានប្រើចាប់ពីបណ្តាញ (ពីបណ្តាញចាស់បំផុតរហូតដល់ VPC) ដល់ការផ្ទុក (Cloud SQL v1-v2), Firebase (ឥឡូវនេះ Firestore ជាមួយ API ខុសគ្នាទាំងស្រុង), App Engine (កុំឱ្យចាប់ផ្តើម) Cloud Endpoints Cloud Endpoint និងរហូតដល់... ខ្ញុំមិនដឹងទេ - ទាំងអស់នេះយ៉ាងពិតប្រាកដ បង្ខំអ្នកឱ្យសរសេរកូដឡើងវិញបន្ទាប់ពីរយៈពេលអតិបរមា 2-3 ឆ្នាំ ហើយពួកគេមិនដែលធ្វើចំណាកស្រុកដោយស្វ័យប្រវត្តិសម្រាប់អ្នកទេ ហើយជារឿយៗ មិនមានផ្លូវធ្វើចំណាកស្រុកដែលមានឯកសារទាល់តែសោះ. ដូចជាប្រសិនបើវាត្រូវបានសន្មត់ថាដូច្នេះ។

ហើយរាល់ពេលដែលខ្ញុំក្រឡេកមើល AWS ខ្ញុំសួរខ្លួនឯងថាហេតុអ្វីបានជាខ្ញុំនៅតែនៅលើ GCP? ពួកគេច្បាស់ជាមិនត្រូវការអតិថិជនទេ។ ពួកគេ​ត្រូវការ អ្នកទិញ. តើអ្នកយល់ពីភាពខុសគ្នាទេ? អនុញ្ញាតឱ្យខ្ញុំពន្យល់។

Google Cloud មាន ទីផ្សារដែលជាកន្លែងដែលមនុស្សស្នើដំណោះស្រាយកម្មវិធីរបស់ពួកគេ និងដើម្បីជៀសវាងផលប៉ះពាល់ភោជនីយដ្ឋានទទេ ពួកគេត្រូវការបំពេញវាជាមួយនឹងសំណើមួយចំនួន ដូច្នេះពួកគេបានចុះកិច្ចសន្យាជាមួយក្រុមហ៊ុនមួយដែលមានឈ្មោះថា Bitnami ដើម្បីបង្កើតដំណោះស្រាយជាច្រើនដែលត្រូវបានដាក់ឱ្យប្រើប្រាស់ដោយ "ចុចតែម្តង" ឬគួរតែ ខ្ញុំសរសេរវាដោយខ្លួនឯង "ដំណោះស្រាយ" ពីព្រោះវាមិនអាចដោះស្រាយរឿងអាក្រក់បានទេ។ ពួកវាមានជាធម្មតាជាប្រអប់ធីក ជាការបំពេញទីផ្សារ ហើយ Google មិនដែលខ្វល់ថាតើឧបករណ៍ណាមួយពិតជាដំណើរការឬអត់។ ខ្ញុំស្គាល់អ្នកគ្រប់គ្រងផលិតផលដែលមានកៅអីអ្នកបើកបរ ហើយខ្ញុំអាចធានាអ្នកថាមនុស្សទាំងនេះមិនខ្វល់ទេ។

ជាឧទាហរណ៍ សូមយកដំណោះស្រាយដាក់ឱ្យប្រើដោយសន្មត់ថា "ចុចតែម្តង"។ percona. ខ្ញុំឈឺរហូតដល់ស្លាប់នៃ Google Cloud SQL shenanigans ដូច្នេះខ្ញុំចាប់ផ្តើមសម្លឹងមើលការកសាងចង្កោម Percona ផ្ទាល់ខ្លួនរបស់ខ្ញុំជាជម្រើសមួយ។ ហើយលើកនេះ Google ហាក់បីដូចជាបានធ្វើការងារល្អ ពួកគេនឹងសន្សំពេលវេលា និងការខំប្រឹងប្រែងខ្លះៗរបស់ខ្ញុំដោយការចុចប៊ូតុង!

ល្អណាស់ តោះទៅ។ តោះធ្វើតាមតំណហើយចុចលើប៊ូតុងនេះ។ ជ្រើសរើស “បាទ/ចាស” ដើម្បីយល់ព្រមលើការកំណត់លំនាំដើមទាំងអស់ ហើយដាក់ពង្រាយចង្កោមនៅក្នុងគម្រោង Google Cloud របស់អ្នក។ ហាហា វាមិនដំណើរការទេ។ គ្មាន​រឿង​អាស្រូវ​នេះ​ដំណើរការ​ទេ។ ឧបករណ៍នេះមិនដែលត្រូវបានសាកល្បងទេ ហើយវាចាប់ផ្តើមរលួយតាំងពីនាទីដំបូង ហើយវានឹងមិនធ្វើឱ្យខ្ញុំភ្ញាក់ផ្អើលទេ ប្រសិនបើច្រើនជាងពាក់កណ្តាលនៃ "ដំណោះស្រាយ" គឺជាការដាក់ឱ្យប្រើប្រាស់ដោយចុចតែម្តង (ឥឡូវនេះយើងយល់ពីមូលហេតុដែលដកស្រង់) ជាទូទៅ មិន​ដំណើរការ។ នេះ​ជា​ភាព​ងងឹត​ដែល​គ្មាន​សង្ឃឹម ជា​កន្លែង​ដែល​មិន​ចូល​ទៅ​វិញ​ល្អ​ជាង។

ប៉ុន្តែ Google ត្រឹមត្រូវ។ លើកទឹកចិត្ត អ្នកអាចប្រើពួកវា។ ពួកគេចង់ឱ្យអ្នក។ បានទិញ. សម្រាប់ពួកគេវាគឺជាប្រតិបត្តិការមួយ។ ពួកគេមិនចង់បានអ្វីទេ។ គាំទ្រ. វាមិនមែនជាផ្នែកនៃ DNA របស់ Google ទេ។ បាទ វិស្វករគាំទ្រគ្នាទៅវិញទៅមក ដូចដែលបានបង្ហាញដោយរឿងរបស់ខ្ញុំជាមួយ Bigtable ។ ប៉ុន្តែនៅក្នុងផលិតផល និងសេវាកម្មសម្រាប់មនុស្សសាមញ្ញគេ តែងតែ មានភាពឃោរឃៅនៅក្នុង បិទសេវាកម្មណាមួយ។ដែលមិនបំពេញតាមរបារសម្រាប់ប្រាក់ចំណេញ ទោះបីជាវាមានអ្នកប្រើប្រាស់រាប់លាននាក់ក៏ដោយ។

ហើយនេះបង្ហាញពីបញ្ហាប្រឈមពិតប្រាកដសម្រាប់ GCP ពីព្រោះនេះគឺជា DNA នៅពីក្រោយការផ្តល់ពពកទាំងអស់។ ពួកគេមិនព្យាយាមគាំទ្រអ្វីទាំងអស់; វាត្រូវបានគេស្គាល់យ៉ាងច្បាស់ថាពួកគេមិនព្រមធ្វើជាម្ចាស់ផ្ទះ (ជាសេវាកម្មគ្រប់គ្រង) កម្មវិធីភាគីទីបីណាមួយ។ រហូតដល់រហូតដល់ AWS ធ្វើដូចគ្នា និងបង្កើតអាជីវកម្មជោគជ័យជុំវិញវា ហើយនៅពេលដែលអតិថិជនទាមទារដូចគ្នានោះ។ ទោះយ៉ាងណាក៏ដោយ វាត្រូវការការខិតខំប្រឹងប្រែងខ្លះដើម្បីឱ្យ Google គាំទ្រអ្វីមួយ។

ការខ្វះខាតនៃវប្បធម៌គាំទ្រនេះ រួមជាមួយនឹងគំនិត "តោះបំបែកវាដើម្បីធ្វើឱ្យវាកាន់តែស្រស់ស្អាត" ធ្វើឱ្យអ្នកអភិវឌ្ឍន៍មានភាពប្លែកពីគេ។

ហើយនោះមិនមែនជារឿងល្អទេ ប្រសិនបើអ្នកចង់បង្កើតវេទិកាដែលមានអាយុកាលយូរ។

Google, ភ្ញាក់ឡើង, ខូចវា។ វាជាឆ្នាំ 2020 ឥឡូវនេះ។ អ្នកនៅតែចាញ់។ វាដល់ពេលដែលត្រូវមើលកញ្ចក់ហើយឆ្លើយថាតើអ្នកពិតជាចង់ស្នាក់នៅក្នុងអាជីវកម្មពពកឬអត់។

ប្រសិនបើអ្នកចង់ស្នាក់នៅបន្ទាប់មក ឈប់បំបែកអ្វីៗទាំងអស់។. បុរសអ្នកគឺជាអ្នកមាន។ យើងជាអ្នកអភិវឌ្ឍន៍មិនមែនទេ។ ដូច្នេះ​នៅពេល​ដែល​អ្នក​ណា​នឹង​ទទួលបន្ទុក​នៃភាព​ត្រូវ​គ្នា​នោះ អ្នក​ត្រូវ​យក​វា​មក​ដាក់​លើ​ខ្លួន​អ្នក​ផ្ទាល់។ មិនមែនសម្រាប់យើងទេ។

ព្រោះយ៉ាងហោចណាស់មានពពកល្អពិតចំនួនបីទៀត។ ពួកគេ​បន្ទរ។

ហើយឥឡូវនេះខ្ញុំនឹងបន្តជួសជុលប្រព័ន្ធដែលខូចទាំងអស់របស់ខ្ញុំ។ អេ។

រហូតដល់​ពេលក្រោយ!

P.S. ធ្វើបច្ចុប្បន្នភាពបន្ទាប់ពីអានការពិភាក្សាមួយចំនួនលើអត្ថបទនេះ (ការពិភាក្សាគឺអស្ចារ្យណាស់ btw)។ ការគាំទ្រ Firebase មិនត្រូវបានបញ្ឈប់ទេ ហើយមិនមានគម្រោងដែលខ្ញុំដឹងនោះទេ។ ទោះយ៉ាងណាក៏ដោយ ពួកគេមានកំហុសក្នុងការផ្សាយដ៏អាក្រក់ដែលបណ្តាលឱ្យម៉ាស៊ីនភ្ញៀវ Java ជាប់គាំងនៅក្នុង App Engine ។ វិស្វកររបស់ពួកគេម្នាក់បានជួយខ្ញុំដោះស្រាយបញ្ហានេះ នៅពេលដែលខ្ញុំធ្វើការនៅ Googleប៉ុន្តែពួកគេមិនដែលបានជួសជុលកំហុសទេ ដូច្នេះខ្ញុំមានការដោះស្រាយដ៏អាក្រក់ដែលត្រូវតែចាប់ផ្តើមកម្មវិធី GAE ឡើងវិញជារៀងរាល់ថ្ងៃ។ ដូច្នេះហើយ វាមានរយៈពេលបួនឆ្នាំហើយ! ឥឡូវនេះពួកគេមាន Firestore ។ វានឹងត្រូវការការងារជាច្រើនដើម្បីផ្ទេរទៅវា ដោយសារវាជាប្រព័ន្ធខុសគ្នាទាំងស្រុង ហើយកំហុស Firebase នឹងមិនដែលត្រូវបានជួសជុលនោះទេ។ តើការសន្និដ្ឋានអ្វីអាចទាញបាន? អ្នកអាចទទួលបានជំនួយ ប្រសិនបើអ្នកធ្វើការនៅក្នុងក្រុមហ៊ុន. ខ្ញុំប្រហែលជាតែមួយគត់ដែលប្រើ Firebase នៅលើ GAE ពីព្រោះខ្ញុំចូលតិចជាង 100 keys នៅក្នុងកម្មវិធីដើម 100% ហើយវាឈប់ដំណើរការរៀងរាល់ពីរបីថ្ងៃម្តង ដោយសារបញ្ហាដែលគេស្គាល់។ តើខ្ញុំអាចនិយាយអ្វីក្រៅពីប្រើវាដោយហានិភ័យផ្ទាល់ខ្លួនរបស់អ្នក។ ខ្ញុំកំពុងប្តូរទៅ Redis ។

ខ្ញុំក៏ធ្លាប់ឃើញអ្នកប្រើប្រាស់ AWS ដែលមានបទពិសោធន៍ខ្លះនិយាយថា ជាធម្មតា AWS មិនដែលឈប់គាំទ្រសេវាកម្មណាមួយឡើយ ហើយ SimpleDB គឺជាឧទាហរណ៍ដ៏អស្ចារ្យមួយ។ ការសន្មត់របស់ខ្ញុំដែលថា AWS មិនមានការបញ្ចប់នៃជំងឺគាំទ្រដូចដែល Google ហាក់ដូចជាមានភាពយុត្តិធម៌។

លើសពីនេះទៀត ខ្ញុំបានកត់សម្គាល់ឃើញថា កាលពី 20 ថ្ងៃមុន ក្រុម Google App Engine បានបំបែកការបង្ហោះបណ្ណាល័យ Go ដ៏សំខាន់ ដោយបិទកម្មវិធី GAE ពីអ្នកអភិវឌ្ឍន៍ Go ស្នូលមួយ។ វាពិតជាល្ងង់មែន។

ទីបំផុត ខ្ញុំបានលឺ Googlers ពិភាក្សាអំពីបញ្ហានេះរួចហើយ ហើយជាទូទៅយល់ព្រមជាមួយខ្ញុំ (ស្រឡាញ់អ្នក!)។ ប៉ុន្តែពួកគេហាក់ដូចជាគិតថាបញ្ហាមិនអាចដោះស្រាយបានទេព្រោះវប្បធម៌របស់ Google មិនដែលមានរចនាសម្ព័ន្ធលើកទឹកចិត្តត្រឹមត្រូវ។ ខ្ញុំ​គិត​ថា​វា​ជា​ការ​ល្អ​ក្នុង​ការ​ចំណាយ​ពេល​ខ្លះ​ដើម្បី​ពិភាក្សា​អំពី​បទពិសោធន៍​ដ៏​អស្ចារ្យ​ដែល​ខ្ញុំ​បាន​ធ្វើ​ការ​ជាមួយ​វិស្វករ AWS ពេល​ធ្វើ​ការ​នៅ Grab។ ថ្ងៃណាមួយនៅថ្ងៃអនាគតខ្ញុំសង្ឃឹម!

មែនហើយ ក្នុងឆ្នាំ 2005 ពួកគេមានសាច់ត្រីឆ្លាមជាច្រើនប្រភេទនៅលើអាហារប៊ូហ្វេដ៏ធំនៅក្នុងអគារ 43 ហើយអ្វីដែលខ្ញុំចូលចិត្តជាងគេគឺសាច់ត្រីឆ្លាមក្បាលញញួរ។ ទោះយ៉ាងណាក៏ដោយនៅឆ្នាំ 2006 Larry និង Sergei បានកម្ចាត់អាហារសម្រន់ដែលមិនល្អទាំងអស់។ ដូច្នេះក្នុងអំឡុងពេលរឿង Bigtable ក្នុងឆ្នាំ 2007 ពិតជាគ្មានត្រីឆ្លាមទេ ហើយខ្ញុំបានបញ្ឆោតអ្នក។

នៅពេលខ្ញុំក្រឡេកមើល cloud Bigtable កាលពីបួនឆ្នាំមុន (ផ្តល់ឱ្យឬយក) នេះគឺជាកន្លែងដែលការចំណាយ។ វាហាក់បីដូចជាបានធ្លាក់ចុះបន្តិចហើយឥឡូវនេះ ប៉ុន្តែនោះនៅតែជារឿងដ៏អាក្រក់សម្រាប់ឃ្លាំងទិន្នន័យទទេ ជាពិសេសចាប់តាំងពីរឿងដំបូងរបស់ខ្ញុំបង្ហាញពីរបៀបដែលតារាងធំទទេដែលមិនមានផលវិបាកនៅក្នុងទំហំរបស់វា។

សូមអភ័យទោសចំពោះការប្រមាថដល់សហគមន៍ Apple និងមិនបាននិយាយអ្វីដែលល្អអំពី Microsoft ជាដើម។ អ្នកពិតជាត្រឹមត្រូវ ខ្ញុំពិតជាពេញចិត្តក្នុងការពិភាក្សាទាំងអស់ដែលអត្ថបទនេះបានបង្កើត! ប៉ុន្តែពេលខ្លះអ្នកត្រូវបង្កើតរលកបន្តិច ដើម្បីចាប់ផ្តើមការពិភាក្សា តើអ្នកដឹងទេ?

អរគុណសម្រាប់ការអាន។

អាប់ដេតថ្ងៃទី 2, 19.08.2020/XNUMX/XNUMX។ ឆ្នូត ធ្វើបច្ចុប្បន្នភាព API ឱ្យបានត្រឹមត្រូវ!

អាប់ដេតថ្ងៃទី 3, 31.08.2020/2/2។ ខ្ញុំត្រូវបានទាក់ទងដោយវិស្វករ Google នៅ Cloud Marketplace ដែលបានក្លាយជាមិត្តចាស់របស់ខ្ញុំ។ គាត់ចង់ស្វែងយល់ថាហេតុអ្វីបានជា CXNUMXD មិនដំណើរការ ហើយនៅទីបំផុតយើងបានរកឃើញថាវាគឺដោយសារតែខ្ញុំបានបង្កើតបណ្តាញរបស់ខ្ញុំកាលពីឆ្នាំមុន ហើយ CXNUMXD មិនដំណើរការលើបណ្តាញកេរ្តិ៍ដំណែលទេ ដោយសារប៉ារ៉ាម៉ែត្របណ្តាញរងបានបាត់នៅក្នុងគំរូរបស់ពួកគេ។ ខ្ញុំគិតថាវាល្អបំផុតសម្រាប់អ្នកប្រើប្រាស់ GCP ដែលអាចប្រាកដថាពួកគេស្គាល់វិស្វករគ្រប់គ្រាន់នៅ Google...

ប្រភព: www.habr.com