ਪਿਆਰੇ ਗੂਗਲ ਕਲਾਉਡ, ਪਿੱਛੇ ਵੱਲ ਅਨੁਕੂਲ ਨਾ ਹੋਣਾ ਤੁਹਾਨੂੰ ਮਾਰ ਰਿਹਾ ਹੈ।

ਡੈਮ ਗੂਗਲ, ​​ਮੈਂ ਦੁਬਾਰਾ ਬਲੌਗ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ। ਮੇਰੇ ਕੋਲ ਕਰਨ ਲਈ ਬਹੁਤ ਕੁਝ ਹੈ। ਬਲੌਗਿੰਗ ਵਿੱਚ ਸਮਾਂ, ਊਰਜਾ ਅਤੇ ਰਚਨਾਤਮਕਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਿਸਦੀ ਮੈਂ ਚੰਗੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹਾਂ: ਮੇਰੀਆਂ ਕਿਤਾਬਾਂ, ਸੰਗੀਤ, ਮੇਰੀ ਖੇਡ ਅਤੇ ਹੋਰ. ਪਰ ਤੁਸੀਂ ਮੈਨੂੰ ਬਹੁਤ ਪਰੇਸ਼ਾਨ ਕਰ ਦਿੱਤਾ ਹੈ ਕਿ ਮੈਨੂੰ ਇਹ ਲਿਖਣਾ ਪਿਆ.

ਇਸ ਲਈ ਦੇ ਨਾਲ ਇਸ ਨੂੰ ਖਤਮ ਕਰੀਏ.

ਮੈਨੂੰ ਇੱਕ ਛੋਟੀ ਪਰ ਸਿੱਖਿਆਦਾਇਕ ਕਹਾਣੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਦਿਓ ਜਦੋਂ ਮੈਂ ਪਹਿਲੀ ਵਾਰ Google ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ। ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ Google ਬਾਰੇ ਬਹੁਤ ਸਾਰੀਆਂ ਮਾੜੀਆਂ ਗੱਲਾਂ ਕਹਿ ਰਿਹਾ ਹਾਂ, ਪਰ ਇਹ ਮੈਨੂੰ ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹੈ ਜਦੋਂ ਮੇਰੀ ਆਪਣੀ ਕੰਪਨੀ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਅਯੋਗ ਕਾਰੋਬਾਰੀ ਫੈਸਲੇ ਲੈਂਦੀ ਹੈ। ਉਸੇ ਸਮੇਂ, ਸਾਨੂੰ ਇਸਦਾ ਕਾਰਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: ਗੂਗਲ ਦਾ ਅੰਦਰੂਨੀ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸੱਚਮੁੱਚ ਅਸਾਧਾਰਣ ਹੈ, ਇਹ ਕਹਿਣਾ ਸੁਰੱਖਿਅਤ ਹੈ ਕਿ ਅੱਜ ਕੁਝ ਵੀ ਬਿਹਤਰ ਨਹੀਂ ਹੈ. ਗੂਗਲ ਦੇ ਸੰਸਥਾਪਕ ਮੇਰੇ ਨਾਲੋਂ ਕਿਤੇ ਬਿਹਤਰ ਇੰਜੀਨੀਅਰ ਸਨ, ਅਤੇ ਇਹ ਕਹਾਣੀ ਸਿਰਫ ਇਸ ਤੱਥ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ.

ਪਹਿਲਾਂ, ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਪਿਛੋਕੜ: ਗੂਗਲ ਕੋਲ ਇੱਕ ਡੇਟਾ ਸਟੋਰੇਜ ਤਕਨਾਲੋਜੀ ਹੈ ਜਿਸ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਬਿਗਟੇਬਲ. ਇਹ ਇੱਕ ਸ਼ਾਨਦਾਰ ਤਕਨੀਕੀ ਪ੍ਰਾਪਤੀ ਸੀ, ਪਹਿਲੀਆਂ ਵਿੱਚੋਂ ਇੱਕ (ਜੇਕਰ ਪਹਿਲੀ ਨਹੀਂ) “ਅਨੰਤ ਸਕੇਲੇਬਲ” ਕੁੰਜੀ-ਮੁੱਲ ਸਟੋਰ (K/V): ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ NoSQL ਦੀ ਸ਼ੁਰੂਆਤ। ਅੱਜਕੱਲ੍ਹ ਬਿਗਟੇਬਲ ਅਜੇ ਵੀ ਭੀੜ-ਭੜੱਕੇ ਵਾਲੇ ਕੇ/ਵੀ ਸਟੋਰੇਜ ਸਪੇਸ ਵਿੱਚ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਉਸ ਸਮੇਂ (2005) ਇਹ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਠੰਡਾ ਸੀ।

ਬਿਗਟੇਬਲ ਬਾਰੇ ਇੱਕ ਮਜ਼ੇਦਾਰ ਗੱਲ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਕੋਲ ਅੰਦਰੂਨੀ ਨਿਯੰਤਰਣ ਪਲੇਨ ਆਬਜੈਕਟ (ਲਾਗੂ ਕਰਨ ਦੇ ਹਿੱਸੇ ਵਜੋਂ) ਸਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਟੈਬਲੇਟ ਸਰਵਰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਵੱਡੇ ਸੂਚਕਾਂਕ ਦੇ ਨਾਲ, ਅਤੇ ਕਿਸੇ ਸਮੇਂ ਉਹ ਸਿਸਟਮ ਨੂੰ ਸਕੇਲ ਕਰਨ ਵੇਲੇ ਇੱਕ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦੇ ਹਨ। ਬਿਗਟੇਬਲ ਇੰਜਨੀਅਰ ਇਸ ਗੱਲ 'ਤੇ ਪਰੇਸ਼ਾਨ ਸਨ ਕਿ ਕਿਵੇਂ ਸਕੇਲੇਬਿਲਟੀ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਹੈ, ਅਤੇ ਅਚਾਨਕ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਉਹ ਟੈਬਲੇਟ ਸਰਵਰਾਂ ਨੂੰ ਹੋਰ ਬਿਗਟੇਬਲ ਸਟੋਰੇਜ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਬਿਗਟੇਬਲ ਬਿਗਟੇਬਲ ਲਾਗੂ ਕਰਨ ਦਾ ਹਿੱਸਾ ਹੈ। ਇਹ ਸਟੋਰੇਜ ਸੁਵਿਧਾਵਾਂ ਹਰ ਪੱਧਰ 'ਤੇ ਮੌਜੂਦ ਹਨ।

ਇਕ ਹੋਰ ਦਿਲਚਸਪ ਵਿਸਤਾਰ ਇਹ ਹੈ ਕਿ ਕੁਝ ਸਮੇਂ ਲਈ ਬਿਗਟੇਬਲ ਗੂਗਲ ਦੇ ਅੰਦਰ ਪ੍ਰਸਿੱਧ ਅਤੇ ਸਰਵ ਵਿਆਪਕ ਹੋ ਗਿਆ, ਹਰੇਕ ਟੀਮ ਦੀ ਆਪਣੀ ਰਿਪੋਜ਼ਟਰੀ ਹੈ। ਇਸ ਲਈ ਸ਼ੁੱਕਰਵਾਰ ਦੀ ਇੱਕ ਮੀਟਿੰਗ ਵਿੱਚ, ਲੈਰੀ ਪੇਜ ਨੇ ਅਚਨਚੇਤ ਤੌਰ 'ਤੇ ਪੁੱਛਿਆ: "ਸਾਡੇ ਕੋਲ ਇੱਕ ਤੋਂ ਵੱਧ ਬਿਗਟੇਬਲ ਕਿਉਂ ਹਨ? ਸਿਰਫ਼ ਇੱਕ ਹੀ ਕਿਉਂ ਨਹੀਂ?” ਸਿਧਾਂਤ ਵਿੱਚ, ਇੱਕ ਸਟੋਰੇਜ Google ਦੀਆਂ ਸਾਰੀਆਂ ਸਟੋਰੇਜ ਲੋੜਾਂ ਲਈ ਕਾਫੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਬੇਸ਼ੱਕ, ਉਹ ਕਦੇ ਵੀ ਵਿਹਾਰਕ ਵਿਕਾਸ ਦੇ ਕਾਰਨਾਂ ਕਰਕੇ (ਜਿਵੇਂ ਕਿ ਸੰਭਾਵੀ ਅਸਫਲਤਾ ਦੇ ਨਤੀਜੇ) ਲਈ ਸਿਰਫ਼ ਇੱਕ ਕੋਲ ਨਹੀਂ ਗਏ, ਪਰ ਸਿਧਾਂਤ ਦਿਲਚਸਪ ਸੀ। ਪੂਰੇ ਬ੍ਰਹਿਮੰਡ ਲਈ ਇੱਕ ਭੰਡਾਰ (ਤਰੀਕੇ ਨਾਲ, ਕੀ ਕਿਸੇ ਨੂੰ ਪਤਾ ਹੈ ਕਿ ਐਮਾਜ਼ਾਨ ਨੇ ਆਪਣੇ ਸੇਬਲ ਨਾਲ ਅਜਿਹਾ ਕੀਤਾ ਹੈ?)

ਵੈਸੇ ਵੀ, ਇੱਥੇ ਮੇਰੀ ਕਹਾਣੀ ਹੈ.

ਉਸ ਸਮੇਂ, ਮੈਂ ਗੂਗਲ 'ਤੇ ਸਿਰਫ ਦੋ ਸਾਲਾਂ ਤੋਂ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ, ਅਤੇ ਇੱਕ ਦਿਨ ਮੈਨੂੰ ਬਿਗਟੇਬਲ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਤੋਂ ਇੱਕ ਈਮੇਲ ਮਿਲੀ ਜੋ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਸੀ:

ਪਿਆਰੇ ਸਟੀਵ,

ਬਿਗਟੇਬਲ ਟੀਮ ਵੱਲੋਂ ਹੈਲੋ। ਅਸੀਂ ਤੁਹਾਨੂੰ ਸੂਚਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ [ਡੇਟਾ ਸੈਂਟਰ ਨਾਮ] 'ਤੇ ਤੁਸੀਂ ਇੱਕ ਬਹੁਤ ਹੀ ਪੁਰਾਣੀ ਬਿਗਟੇਬਲ ਬਾਈਨਰੀ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ। ਇਹ ਸੰਸਕਰਣ ਹੁਣ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ ਅਤੇ ਅਸੀਂ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਵਿੱਚ ਅਪਗ੍ਰੇਡ ਕਰਨ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਕਿਰਪਾ ਕਰਕੇ ਮੈਨੂੰ ਦੱਸੋ ਕਿ ਕੀ ਤੁਸੀਂ ਇਸ ਮੁੱਦੇ 'ਤੇ ਇਕੱਠੇ ਕੰਮ ਕਰਨ ਲਈ ਕੁਝ ਸਮਾਂ ਨਿਯਤ ਕਰ ਸਕਦੇ ਹੋ।

ਸ਼ੁਭਕਾਮਨਾਵਾਂ,
ਬਿਗਟੇਬਲ ਟੀਮ

ਗੂਗਲ 'ਤੇ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਮੇਲ ਮਿਲਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ ਮੈਂ ਇਸ ਤਰ੍ਹਾਂ ਪੜ੍ਹਿਆ:

ਪਿਆਰੇ ਪ੍ਰਾਪਤਕਰਤਾ,

ਕਿਸੇ ਟੀਮ ਵੱਲੋਂ ਹੈਲੋ। ਅਸੀਂ ਉਸ ਬਲਾ ਬਲਾਹ ਬਲਾ ਬਲਾ ਬਲਾਹ ਨੂੰ ਸੰਚਾਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਬਲਾ ਬਲਾ ਬਲਾ ਬਲਾ ਬਲਾ ਬਲਾ, ਅਤੇ ਬਲਾ ਬਲਾ ਬਲਾ ਤੁਰੰਤ।

ਕਿਰਪਾ ਕਰਕੇ ਸਾਨੂੰ ਦੱਸੋ ਕਿ ਕੀ ਤੁਸੀਂ ਆਪਣੇ ਕੀਮਤੀ ਸਮੇਂ ਵਿੱਚੋਂ ਕੁਝ ਬਲਾ ਬਲਾ ਬਲਾਹ ਲਈ ਨਿਯਤ ਕਰ ਸਕਦੇ ਹੋ।

ਸ਼ੁਭਕਾਮਨਾਵਾਂ,
ਕਿਸੇ ਕਿਸਮ ਦਾ ਹੁਕਮ

ਮੈਂ ਲਗਭਗ ਇਸਨੂੰ ਤੁਰੰਤ ਮਿਟਾ ਦਿੱਤਾ, ਪਰ ਮੇਰੀ ਚੇਤਨਾ ਦੇ ਕਿਨਾਰੇ 'ਤੇ ਮੈਂ ਇੱਕ ਦਰਦਨਾਕ, ਦੁਖਦਾਈ ਭਾਵਨਾ ਮਹਿਸੂਸ ਕੀਤੀ ਕਿ ਇਹ ਸਚਮੁਚ ਨਹੀਂ ਹਾਲਾਂਕਿ ਇੱਕ ਰਸਮੀ ਪੱਤਰ ਵਰਗਾ ਲੱਗਦਾ ਹੈ ਸਪੱਸ਼ਟ ਹੈ, ਕਿ ਪ੍ਰਾਪਤਕਰਤਾ ਗਲਤ ਸੀ ਕਿਉਂਕਿ ਮੈਂ ਬਿਗਟੇਬਲ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਸੀ।

ਪਰ ਇਹ ਅਜੀਬ ਸੀ.

ਮੈਂ ਬਾਕੀ ਸਾਰਾ ਦਿਨ ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ ਕੰਮ ਬਾਰੇ ਸੋਚਣ ਵਿੱਚ ਬਿਤਾਇਆ ਅਤੇ ਮਾਈਕ੍ਰੋ-ਕਿਚਨ ਵਿੱਚ ਕਿਸ ਕਿਸਮ ਦਾ ਸ਼ਾਰਕ ਮੀਟ ਅਜ਼ਮਾਉਣਾ ਹੈ, ਜਿਸ ਵਿੱਚੋਂ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਬਿਸਕੁਟ ਦੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਾਲ ਸੁੱਟਣ ਨਾਲ ਮੇਰੀ ਸੀਟ ਤੋਂ ਹਿੱਟ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਨੇੜੇ ਸਨ, ਪਰ ਲਿਖਣ ਦੇ ਵਿਚਾਰ ਨੇ ਮੈਨੂੰ ਕਦੇ ਵੀ ਹਲਕੀ ਜਿਹੀ ਚਿੰਤਾ ਦੀ ਭਾਵਨਾ ਨਾਲ ਨਹੀਂ ਛੱਡਿਆ।

ਉਨ੍ਹਾਂ ਨੇ ਸਾਫ਼-ਸਾਫ਼ ਮੇਰਾ ਨਾਂ ਕਿਹਾ। ਅਤੇ ਈਮੇਲ ਮੇਰੇ ਈਮੇਲ ਪਤੇ 'ਤੇ ਭੇਜੀ ਗਈ ਸੀ, ਕਿਸੇ ਹੋਰ ਦੇ ਨਹੀਂ, ਅਤੇ ਇਹ cc: ਜਾਂ bcc: ਨਹੀਂ ਹੈ। ਸੁਰ ਬਹੁਤ ਨਿੱਜੀ ਅਤੇ ਸਪਸ਼ਟ ਹੈ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਕਿਸੇ ਕਿਸਮ ਦੀ ਗਲਤੀ ਹੈ?

ਅੰਤ ਵਿੱਚ, ਉਤਸੁਕਤਾ ਮੇਰੇ ਵਿੱਚ ਬਿਹਤਰ ਹੋ ਗਈ ਅਤੇ ਮੈਂ ਉਹਨਾਂ ਦੁਆਰਾ ਜ਼ਿਕਰ ਕੀਤੇ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਬੋਰਗ ਕੰਸੋਲ ਨੂੰ ਵੇਖਣ ਗਿਆ।

ਅਤੇ ਬੇਸ਼ੱਕ, ਮੇਰੇ ਕੋਲ ਪ੍ਰਬੰਧਨ ਅਧੀਨ ਬਿਗਟੇਬਲ ਸਟੋਰੇਜ ਸੀ. ਮੈਨੂੰ ਮਾਫ਼ ਕਰਨਾ, ਕੀ? ਮੈਂ ਇਸਦੀ ਸਮੱਗਰੀ ਨੂੰ ਦੇਖਿਆ, ਅਤੇ ਵਾਹ! ਇਹ ਕੋਡਲੈਬ ਇਨਕਿਊਬੇਟਰ ਤੋਂ ਸੀ ਜਿਸ ਵਿੱਚ ਮੈਂ ਜੂਨ 2005 ਵਿੱਚ ਗੂਗਲ ਵਿੱਚ ਆਪਣੇ ਪਹਿਲੇ ਹਫ਼ਤੇ ਦੌਰਾਨ ਬੈਠਾ ਸੀ। ਕੋਡਲੇਬ ਨੇ ਤੁਹਾਨੂੰ ਉੱਥੇ ਕੁਝ ਮੁੱਲ ਲਿਖਣ ਲਈ ਬਿਗਟੇਬਲ ਨੂੰ ਚਲਾਉਣ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ, ਅਤੇ ਮੈਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਸਟੋਰੇਜ ਨੂੰ ਕਦੇ ਬੰਦ ਨਹੀਂ ਕੀਤਾ. ਦੋ ਸਾਲ ਤੋਂ ਵੱਧ ਸਮਾਂ ਬੀਤ ਜਾਣ ਦੇ ਬਾਵਜੂਦ ਵੀ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ।

ਇਸ ਕਹਾਣੀ ਦੇ ਕਈ ਧਿਆਨ ਦੇਣ ਯੋਗ ਪਹਿਲੂ ਹਨ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਬਿਗਟੇਬਲ ਦਾ ਕੰਮ ਗੂਗਲ ਦੇ ਪੈਮਾਨੇ 'ਤੇ ਇੰਨਾ ਮਾਮੂਲੀ ਸੀ ਕਿ ਸਿਰਫ ਦੋ ਸਾਲਾਂ ਬਾਅਦ ਕਿਸੇ ਨੇ ਵਾਧੂ ਸਟੋਰੇਜ ਵੱਲ ਧਿਆਨ ਦਿੱਤਾ, ਅਤੇ ਸਿਰਫ ਇਸ ਲਈ ਕਿਉਂਕਿ ਬਾਈਨਰੀ ਦਾ ਸੰਸਕਰਣ ਪੁਰਾਣਾ ਸੀ। ਤੁਲਨਾ ਲਈ, ਮੈਂ ਇੱਕ ਵਾਰ ਵਰਤਣ ਬਾਰੇ ਵਿਚਾਰ ਕੀਤਾ ਗੂਗਲ ਕਲਾਉਡ 'ਤੇ ਬਿਗਟੇਬਲ ਮੇਰੀ ਔਨਲਾਈਨ ਗੇਮ ਲਈ. ਉਸ ਸਮੇਂ, ਇਸ ਸੇਵਾ ਦੀ ਕੀਮਤ ਲਗਭਗ $16 ਪ੍ਰਤੀ ਸਾਲ ਹੈ। ਖਾਲੀ GCP 'ਤੇ ਬਿਗਟੇਬਲ। ਮੈਂ ਇਹ ਨਹੀਂ ਕਹਿ ਰਿਹਾ ਹਾਂ ਕਿ ਉਹ ਤੁਹਾਡੇ ਨਾਲ ਧੋਖਾ ਕਰ ਰਹੇ ਹਨ, ਪਰ ਮੇਰੀ ਨਿੱਜੀ ਰਾਏ ਵਿੱਚ, ਇਹ ਇੱਕ ਖਾਲੀ ਡਾਟਾਬੇਸ ਲਈ ਬਹੁਤ ਸਾਰਾ ਪੈਸਾ ਹੈ.

ਇਕ ਹੋਰ ਧਿਆਨ ਦੇਣ ਯੋਗ ਪਹਿਲੂ ਇਹ ਹੈ ਕਿ ਸਟੋਰੇਜ ਦੋ ਸਾਲਾਂ ਬਾਅਦ ਵੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ. WTF? ਡਾਟਾ ਸੈਂਟਰ ਆਉਂਦੇ ਅਤੇ ਜਾਂਦੇ ਹਨ; ਉਹ ਆਊਟੇਜ ਦਾ ਅਨੁਭਵ ਕਰਦੇ ਹਨ, ਉਹ ਨਿਯਤ ਰੱਖ-ਰਖਾਅ ਤੋਂ ਗੁਜ਼ਰਦੇ ਹਨ, ਉਹ ਹਰ ਸਮੇਂ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ। ਹਾਰਡਵੇਅਰ ਅੱਪਡੇਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਸਵਿੱਚਾਂ ਦੀ ਅਦਲਾ-ਬਦਲੀ ਕੀਤੀ ਗਈ ਹੈ, ਹਰ ਚੀਜ਼ ਵਿੱਚ ਲਗਾਤਾਰ ਸੁਧਾਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਇਨ੍ਹਾਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਨਾਲ ਉਹ ਮੇਰੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਦੋ ਸਾਲਾਂ ਤੱਕ ਕਿਵੇਂ ਚਲਾਉਂਦੇ ਰਹਿਣ ਦੇ ਯੋਗ ਸਨ? ਇਹ 2020 ਵਿੱਚ ਇੱਕ ਮਾਮੂਲੀ ਪ੍ਰਾਪਤੀ ਜਾਪਦੀ ਹੈ, ਪਰ 2005-2007 ਵਿੱਚ ਇਹ ਕਾਫ਼ੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸੀ।

ਅਤੇ ਸਭ ਤੋਂ ਸ਼ਾਨਦਾਰ ਪਹਿਲੂ ਇਹ ਹੈ ਕਿ ਕਿਸੇ ਹੋਰ ਰਾਜ ਵਿੱਚ ਇੱਕ ਬਾਹਰੀ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਮੇਰੇ ਕੋਲ ਪਹੁੰਚਦੀ ਹੈ, ਬਿਗਟੇਬਲ ਦੇ ਕੁਝ ਛੋਟੇ, ਲਗਭਗ ਖਾਲੀ ਉਦਾਹਰਣ ਦੇ ਮਾਲਕ, ਜਿਸ ਨੇ ਜ਼ੀਰੋ ਆਵਾਜਾਈ ਪਿਛਲੇ ਦੋ ਸਾਲਾਂ ਤੋਂ - ਅਤੇ ਇਸਨੂੰ ਅਪਡੇਟ ਕਰਨ ਲਈ ਮਦਦ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰ ਰਹੇ ਹਨ।

ਮੈਂ ਉਨ੍ਹਾਂ ਦਾ ਧੰਨਵਾਦ ਕੀਤਾ, ਸਟੋਰੇਜ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ, ਅਤੇ ਜ਼ਿੰਦਗੀ ਆਮ ਵਾਂਗ ਚਲੀ ਗਈ. ਪਰ ਤੇਰਾਂ ਸਾਲਾਂ ਬਾਅਦ, ਮੈਂ ਅਜੇ ਵੀ ਉਸ ਚਿੱਠੀ ਬਾਰੇ ਸੋਚਦਾ ਹਾਂ. ਕਿਉਂਕਿ ਕਈ ਵਾਰ ਮੈਨੂੰ ਗੂਗਲ ਕਲਾਉਡ ਤੋਂ ਸਮਾਨ ਈਮੇਲਾਂ ਮਿਲਦੀਆਂ ਹਨ। ਉਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ:

ਪਿਆਰੇ Google ਕਲਾਉਡ ਉਪਭੋਗਤਾ,

ਇੱਕ ਰੀਮਾਈਂਡਰ ਦੇ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਅਗਸਤ 2020 ਤੋਂ [ਤੁਹਾਡੇ ਦੁਆਰਾ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਜ਼ਰੂਰੀ ਸੇਵਾ] ਸੇਵਾ ਨੂੰ ਬੰਦ ਕਰ ਦੇਵਾਂਗੇ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਆਪਣੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੋਗੇ। ਅਸੀਂ ਨਵੀਨਤਮ ਸੰਸਕਰਣ 'ਤੇ ਅਪਗ੍ਰੇਡ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ, ਜੋ ਕਿ ਬੀਟਾ ਟੈਸਟਿੰਗ ਵਿੱਚ ਹੈ, ਕੋਈ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਹੈ, ਕੋਈ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਾਰਗ ਨਹੀਂ ਹੈ ਅਤੇ ਸਾਡੀ ਕਿਸਮ ਦੀ ਮਦਦ ਨਾਲ ਪਹਿਲਾਂ ਤੋਂ ਪੁਰਾਣਾ ਹੈ।

ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਵਚਨਬੱਧ ਹਾਂ ਕਿ ਇਸ ਤਬਦੀਲੀ ਦਾ Google ਕਲਾਊਡ ਪਲੇਟਫਾਰਮ ਦੇ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ 'ਤੇ ਘੱਟ ਤੋਂ ਘੱਟ ਪ੍ਰਭਾਵ ਪਵੇ।

ਸਦਾ ਲਈ ਸਭ ਤੋਂ ਚੰਗੇ ਦੋਸਤ,
ਗੂਗਲ ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ

ਪਰ ਮੈਂ ਲਗਭਗ ਕਦੇ ਵੀ ਅਜਿਹੇ ਪੱਤਰ ਨਹੀਂ ਪੜ੍ਹਦਾ, ਕਿਉਂਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਕੀ ਕਹਿੰਦੇ ਹਨ:

ਪਿਆਰੇ ਪ੍ਰਾਪਤਕਰਤਾ,

ਨਰਕ ਵਿੱਚ ਜਾਓ. ਫੱਕ ਯੂ, ਫੱਕ ਯੂ, ਫੱਕ ਯੂ। ਉਹ ਸਭ ਕੁਝ ਛੱਡ ਦਿਓ ਜੋ ਤੁਸੀਂ ਕਰਦੇ ਹੋ ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ। ਕੀ ਮਾਇਨੇ ਸਾਡਾ ਸਮਾਂ ਹੈ। ਅਸੀਂ ਆਪਣੀ ਬਕਵਾਸ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਵਿੱਚ ਸਮਾਂ ਅਤੇ ਪੈਸਾ ਬਰਬਾਦ ਕਰਦੇ ਹਾਂ ਅਤੇ ਅਸੀਂ ਇਸ ਤੋਂ ਥੱਕ ਗਏ ਹਾਂ ਇਸਲਈ ਅਸੀਂ ਇਸਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਾਂਗੇ। ਇਸ ਲਈ ਆਪਣੀਆਂ ਭੈੜੀਆਂ ਯੋਜਨਾਵਾਂ ਨੂੰ ਛੱਡ ਦਿਓ ਅਤੇ ਸਾਡੇ ਘਟੀਆ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਖੋਦਣਾ ਸ਼ੁਰੂ ਕਰੋ, ਫੋਰਮਾਂ 'ਤੇ ਸਕ੍ਰੈਪ ਦੀ ਭੀਖ ਮੰਗੋ, ਅਤੇ ਤਰੀਕੇ ਨਾਲ, ਸਾਡੀ ਨਵੀਂ ਗੰਦਗੀ ਪੁਰਾਣੀ ਗੰਦਗੀ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀ ਹੈ, ਕਿਉਂਕਿ ਅਸੀਂ ਇਸ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਹੁਤ ਖਰਾਬ ਕਰ ਦਿੱਤਾ ਹੈ, ਹੇ, ਪਰ ਇਹ ਤੁਹਾਡਾ ਹੈ ਸਮੱਸਿਆ, ਸਾਡੀ ਨਹੀਂ।

ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਯਤਨ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ ਕਿ ਤੁਹਾਡੇ ਸਾਰੇ ਵਿਕਾਸ ਇੱਕ ਸਾਲ ਦੇ ਅੰਦਰ ਵਰਤੋਂ ਯੋਗ ਨਾ ਹੋ ਜਾਣ।

ਕਿਰਪਾ ਕਰਕੇ ਬੰਦ fuck
ਗੂਗਲ ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ

ਅਤੇ ਤੱਥ ਇਹ ਹੈ ਕਿ ਮੈਨੂੰ ਮਹੀਨੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਅਜਿਹੇ ਪੱਤਰ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ. ਇਹ ਇੰਨੀ ਵਾਰ ਅਤੇ ਇੰਨਾ ਲਗਾਤਾਰ ਹੁੰਦਾ ਹੈ ਕਿ ਉਹ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਦੂਰ ਧੱਕ ਦਿੱਤਾ ਮੈਂ ਜੀਸੀਪੀ ਤੋਂ ਕਲਾਉਡ ਵਿਰੋਧੀ ਕੈਂਪ ਤੱਕ। ਮੈਂ ਹੁਣ ਉਹਨਾਂ ਦੇ ਮਲਕੀਅਤ ਦੇ ਵਿਕਾਸ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਲਈ ਸਹਿਮਤ ਨਹੀਂ ਹਾਂ, ਕਿਉਂਕਿ ਅਸਲ ਵਿੱਚ ਡਿਵੌਪਸ ਲਈ "ਪੁਰਾਣੇ" ਉਤਪਾਦਾਂ ਨੂੰ ਬੰਦ ਕਰਨ ਦੀ ਆਪਣੀ ਨੀਤੀ ਨਾਲ Google ਨਾਲ ਜਾਰੀ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲੋਂ ਇੱਕ ਬੇਅਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨ 'ਤੇ ਇੱਕ ਓਪਨ ਸੋਰਸ ਸਿਸਟਮ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਆਸਾਨ ਹੈ।

ਗੂਗਲ ਕਲਾਉਡ 'ਤੇ ਵਾਪਸ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਉਂਕਿ ਮੈਂ ਨੇੜੇ ਵੀ ਨਹੀਂ ਉਨ੍ਹਾਂ ਦੀ ਆਲੋਚਨਾ ਨਹੀਂ ਕੀਤੀ, ਆਓ ਕੁਝ ਹੋਰ ਖੇਤਰਾਂ ਵਿੱਚ ਕੰਪਨੀ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀਏ। ਗੂਗਲ ਇੰਜੀਨੀਅਰ ਆਪਣੇ ਸੌਫਟਵੇਅਰ ਇੰਜਨੀਅਰਿੰਗ ਅਨੁਸ਼ਾਸਨ 'ਤੇ ਮਾਣ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਅਸਲ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਹੰਕਾਰ ਅਣਜਾਣ ਲੋਕਾਂ ਲਈ ਇੱਕ ਜਾਲ ਹੈ, ਅਤੇ ਇਸਨੇ ਬਹੁਤ ਸਾਰੇ Google ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਇਹ ਸੋਚਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦੇ ਫੈਸਲੇ ਹਮੇਸ਼ਾ ਸਹੀ ਹੁੰਦੇ ਹਨ ਅਤੇ ਇਹ ਕਿ ਸਹੀ ਹੋਣਾ (ਕੁਝ ਅਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਦੁਆਰਾ) ਗਾਹਕਾਂ ਦੀ ਦੇਖਭਾਲ ਕਰਨ ਨਾਲੋਂ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਮੈਂ ਗੂਗਲ ਤੋਂ ਬਾਹਰ ਹੋਰ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਤੋਂ ਕੁਝ ਬੇਤਰਤੀਬੇ ਉਦਾਹਰਣਾਂ ਦੇਵਾਂਗਾ, ਪਰ ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਤੁਸੀਂ ਹਰ ਜਗ੍ਹਾ ਇਹ ਪੈਟਰਨ ਦੇਖੋਗੇ. ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ: ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਸਿਸਟਮਾਂ ਨੂੰ ਦਹਾਕਿਆਂ ਤੱਕ ਜਿੰਦਾ ਅਤੇ ਨਵੀਨਤਮ ਰੱਖਦੀ ਹੈ.

ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਾਰੇ ਸਫਲ ਸਿਸਟਮਾਂ ਦਾ ਡਿਜ਼ਾਈਨ ਟੀਚਾ ਹੈ ਖੁੱਲਾ ਵਰਤੋਂ, ਜੋ ਕਿ ਓਪਨ ਸੋਰਸ ਕੋਡ ਅਤੇ/ਜਾਂ ਓਪਨ ਸਟੈਂਡਰਡਾਂ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ। ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਮੈਂ ਕੁਝ ਅਜਿਹਾ ਸਪੱਸ਼ਟ ਕਹਿ ਰਿਹਾ ਹਾਂ ਜਿਸ ਨਾਲ ਹਰ ਕੋਈ ਬੇਚੈਨ ਹੈ, ਪਰ ਨਹੀਂ। ਇਹ ਸਿਆਸੀ ਮੁੱਦਾ ਹੈ, ਇਸ ਲਈ ਉਦਾਹਰਣਾਂ ਦੀ ਲੋੜ ਹੈ।

ਪਹਿਲਾ ਸਿਸਟਮ ਜੋ ਮੈਂ ਚੁਣਾਂਗਾ ਉਹ ਸਭ ਤੋਂ ਪੁਰਾਣਾ ਹੈ: GNU Emacs, ਜੋ ਕਿ ਵਿੰਡੋਜ਼ ਨੋਟਪੈਡ, OS ਕਰਨਲ, ਅਤੇ ਅੰਤਰਰਾਸ਼ਟਰੀ ਸਪੇਸ ਸਟੇਸ਼ਨ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਹਾਈਬ੍ਰਿਡ ਦੀ ਤਰ੍ਹਾਂ ਹੈ। ਇਹ ਸਮਝਾਉਣਾ ਥੋੜਾ ਔਖਾ ਹੈ, ਪਰ ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, Emacs ਇੱਕ ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ 1976 ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਹੈ (ਹਾਂ, ਲਗਭਗ ਅੱਧੀ ਸਦੀ ਪਹਿਲਾਂ) ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਲਾਭਕਾਰੀ ਬਣਾਉਣ ਲਈ ਪ੍ਰੋਗਰਾਮਿੰਗ ਲਈ, ਪਰ ਇੱਕ ਟੈਕਸਟ ਐਡੀਟਰ ਦੇ ਰੂਪ ਵਿੱਚ ਛੁਪਾਉਣਾ।

ਮੈਂ ਹਰ ਰੋਜ਼ Emacs ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ। ਹਾਂ, ਮੈਂ ਹਰ ਰੋਜ਼ IntelliJ ਦੀ ਵਰਤੋਂ ਵੀ ਕਰਦਾ ਹਾਂ, ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਟੂਲਿੰਗ ਪਲੇਟਫਾਰਮ ਬਣ ਗਿਆ ਹੈ. ਪਰ IntelliJ ਲਈ ਐਕਸਟੈਂਸ਼ਨ ਲਿਖਣਾ Emacs ਲਈ ਐਕਸਟੈਂਸ਼ਨ ਲਿਖਣ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਉਤਸ਼ਾਹੀ ਅਤੇ ਗੁੰਝਲਦਾਰ ਕੰਮ ਹੈ। ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, Emacs ਲਈ ਲਿਖੀ ਗਈ ਹਰ ਚੀਜ਼ ਸੁਰੱਖਿਅਤ ਹੈ ਹਮੇਸ਼ਾ ਲਈ.

ਮੈਂ ਅਜੇ ਵੀ ਉਹ ਸੌਫਟਵੇਅਰ ਵਰਤਦਾ ਹਾਂ ਜੋ ਮੈਂ 1995 ਵਿੱਚ Emacs ਲਈ ਲਿਖਿਆ ਸੀ। ਅਤੇ ਮੈਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਕੋਈ ਵਿਅਕਤੀ 80 ਦੇ ਦਹਾਕੇ ਦੇ ਮੱਧ ਵਿੱਚ Emacs ਲਈ ਲਿਖੇ ਮੋਡਿਊਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹੈ, ਜੇਕਰ ਪਹਿਲਾਂ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਸਮੇਂ ਸਮੇਂ ਤੇ ਥੋੜਾ ਜਿਹਾ ਟਵੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਅਸਲ ਵਿੱਚ ਬਹੁਤ ਘੱਟ ਹੁੰਦਾ ਹੈ। ਮੈਨੂੰ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਬਾਰੇ ਨਹੀਂ ਪਤਾ ਜੋ ਮੈਂ ਕਦੇ Emacs ਲਈ ਲਿਖਿਆ ਹੈ (ਅਤੇ ਮੈਂ ਬਹੁਤ ਕੁਝ ਲਿਖਿਆ ਹੈ) ਜਿਸ ਲਈ ਮੁੜ-ਆਰਕੀਟੈਕਚਰ ਦੀ ਲੋੜ ਸੀ।

Emacs ਦਾ ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ ਜਿਸਨੂੰ ਮੇਕ-ਓਬਸੋਲੇਟ ਕਹਿੰਦੇ ਹਨ ਪੁਰਾਣੀਆਂ ਇਕਾਈਆਂ ਲਈ। ਬੁਨਿਆਦੀ ਕੰਪਿਊਟਰ ਸੰਕਲਪਾਂ (ਜਿਵੇਂ ਕਿ "ਵਿੰਡੋ" ਕੀ ਹੈ) ਲਈ Emacs ਸ਼ਬਦਾਵਲੀ ਅਕਸਰ ਉਦਯੋਗ ਸੰਮੇਲਨਾਂ ਤੋਂ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ Emacs ਨੇ ਉਹਨਾਂ ਨੂੰ ਬਹੁਤ ਸਮਾਂ ਪਹਿਲਾਂ ਪੇਸ਼ ਕੀਤਾ ਸੀ। ਇਹ ਉਹਨਾਂ ਲਈ ਇੱਕ ਖਾਸ ਖ਼ਤਰਾ ਹੈ ਜੋ ਆਪਣੇ ਸਮੇਂ ਤੋਂ ਅੱਗੇ ਹਨ: ਤੁਹਾਡੀਆਂ ਸਾਰੀਆਂ ਸ਼ਰਤਾਂ ਗਲਤ ਹਨ। ਪਰ Emacs ਕੋਲ ਨਾਪਸੰਦ ਦੀ ਧਾਰਨਾ ਹੈ, ਜਿਸਨੂੰ ਉਹਨਾਂ ਦੇ ਸ਼ਬਦ-ਜੋੜ ਵਿੱਚ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਅਪ੍ਰਚਲਿਤਤਾ.

ਪਰ Emacs ਸੰਸਾਰ ਵਿੱਚ ਇੱਕ ਵੱਖਰੀ ਕਾਰਜਕਾਰੀ ਪਰਿਭਾਸ਼ਾ ਜਾਪਦੀ ਹੈ। ਇੱਕ ਵੱਖਰਾ ਅੰਤਰੀਵ ਦਰਸ਼ਨ, ਜੇ ਤੁਸੀਂ ਕਰੋਗੇ।

Emacs ਦੀ ਦੁਨੀਆ ਵਿੱਚ (ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਖੇਤਰਾਂ ਵਿੱਚ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ ਹੇਠਾਂ ਕਵਰ ਕਰਾਂਗੇ), ਨਾਪਸੰਦ API ਸਥਿਤੀ ਦਾ ਮੂਲ ਰੂਪ ਵਿੱਚ ਮਤਲਬ ਹੈ: "ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਇਸ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ, ਕਿਉਂਕਿ ਜਦੋਂ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਕਈ ਕਮੀਆਂ ਤੋਂ ਪੀੜਤ ਹੈ ਜੋ ਅਸੀਂ ਕਰਾਂਗੇ। ਇੱਥੇ ਸੂਚੀ. ਪਰ ਦਿਨ ਦੇ ਅੰਤ ਵਿੱਚ, ਇਹ ਤੁਹਾਡੀ ਮਰਜ਼ੀ ਹੈ।"

ਗੂਗਲ ਦੀ ਦੁਨੀਆ ਵਿੱਚ, ਪੁਰਾਣੇ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ, "ਅਸੀਂ ਤੁਹਾਡੇ ਪ੍ਰਤੀ ਸਾਡੀ ਵਚਨਬੱਧਤਾ ਦੀ ਉਲੰਘਣਾ ਕਰ ਰਹੇ ਹਾਂ।" ਇਹ ਸੱਚ ਹੈ. ਇਹ ਅਸਲ ਵਿੱਚ ਇਸਦਾ ਮਤਲਬ ਹੈ. ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਹ ਤੁਹਾਨੂੰ ਮਜਬੂਰ ਕਰਨਗੇ ਬਾਕਾਇਦਾ ਕੁਝ ਕੰਮ ਕਰੋ, ਸ਼ਾਇਦ ਬਹੁਤ ਸਾਰਾ ਕੰਮ, ਉਹਨਾਂ ਵਿੱਚ ਵਿਸ਼ਵਾਸ ਕਰਨ ਦੀ ਸਜ਼ਾ ਵਜੋਂ ਰੰਗੀਨ ਵਿਗਿਆਪਨ: ਸਾਡੇ ਕੋਲ ਸਭ ਤੋਂ ਵਧੀਆ ਸਾਫਟਵੇਅਰ ਹੈ। ਸਭ ਤੋਂ ਤੇਜ! ਤੁਸੀਂ ਨਿਰਦੇਸ਼ਾਂ ਅਨੁਸਾਰ ਸਭ ਕੁਝ ਕਰਦੇ ਹੋ, ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਸੇਵਾ ਨੂੰ ਲਾਂਚ ਕਰੋ, ਅਤੇ ਫਿਰ ਬੈਮ, ਇੱਕ ਜਾਂ ਦੋ ਸਾਲ ਬਾਅਦ ਇਹ ਟੁੱਟ ਜਾਂਦਾ ਹੈ.

ਇਹ ਇੱਕ ਵਰਤੀ ਹੋਈ ਕਾਰ ਨੂੰ ਵੇਚਣ ਵਾਂਗ ਹੈ ਜੋ ਯਕੀਨੀ ਤੌਰ 'ਤੇ 1500 ਕਿਲੋਮੀਟਰ ਤੋਂ ਬਾਅਦ ਟੁੱਟ ਜਾਵੇਗੀ।

ਇਹ "ਅਪ੍ਰਚਲਿਤਤਾ" ਦੀਆਂ ਦੋ ਬਿਲਕੁਲ ਵੱਖਰੀਆਂ ਦਾਰਸ਼ਨਿਕ ਪਰਿਭਾਸ਼ਾਵਾਂ ਹਨ। ਗੰਧ ਦੀ Google ਦੀ ਪਰਿਭਾਸ਼ਾ ਯੋਜਨਾਬੱਧ ਅਪ੍ਰਚਲਤਾ. ਮੈਨੂੰ ਇਹ ਵਿਸ਼ਵਾਸ ਨਹੀਂ ਹੈ ਵਾਸਤਵ ਵਿੱਚ ਐਪਲ ਦੇ ਸਮਾਨ ਅਰਥਾਂ ਵਿੱਚ ਯੋਜਨਾਬੱਧ ਅਪ੍ਰਚਲਤਾ. ਪਰ ਗੂਗਲ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਇੱਕ ਗੋਲਾਕਾਰ ਤਰੀਕੇ ਨਾਲ ਤੋੜਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਿਹਾ ਹੈ। ਮੈਂ ਇਹ ਜਾਣਦਾ ਹਾਂ ਕਿਉਂਕਿ ਮੈਂ ਉੱਥੇ 12 ਸਾਲਾਂ ਤੋਂ ਇੱਕ ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰ ਵਜੋਂ ਕੰਮ ਕੀਤਾ ਹੈ। ਉਹਨਾਂ ਕੋਲ ਅਸਪਸ਼ਟ ਅੰਦਰੂਨੀ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਹਨ ਕਿ ਕਿੰਨੀ ਪਿੱਛੇ ਦੀ ਅਨੁਕੂਲਤਾ ਦੀ ਪਾਲਣਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਪਰ ਇਹ ਆਖਰਕਾਰ ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਟੀਮ ਜਾਂ ਸੇਵਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਕੋਈ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਜਾਂ ਇੰਜੀਨੀਅਰਿੰਗ-ਪੱਧਰ ਦੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਨਹੀਂ ਹਨ, ਅਤੇ ਅਪ੍ਰਚਲਿਤ ਚੱਕਰ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਸਭ ਤੋਂ ਦਲੇਰ ਸਿਫ਼ਾਰਸ਼ "ਗਾਹਕਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਤੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਅੱਪਗਰੇਡ ਕਰਨ ਲਈ 6-12 ਮਹੀਨੇ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ।"

ਸਮੱਸਿਆ ਉਹਨਾਂ ਦੇ ਸੋਚਣ ਨਾਲੋਂ ਬਹੁਤ ਵੱਡੀ ਹੈ, ਅਤੇ ਇਹ ਆਉਣ ਵਾਲੇ ਸਾਲਾਂ ਤੱਕ ਜਾਰੀ ਰਹੇਗੀ ਕਿਉਂਕਿ ਗਾਹਕ ਦੇਖਭਾਲ ਉਹਨਾਂ ਦੇ ਡੀਐਨਏ ਵਿੱਚ ਨਹੀਂ ਹੈ. ਹੇਠਾਂ ਇਸ ਬਾਰੇ ਹੋਰ.

ਇਸ ਬਿੰਦੂ 'ਤੇ ਮੈਂ ਇੱਕ ਦਲੇਰਾਨਾ ਬਿਆਨ ਦੇਣ ਜਾ ਰਿਹਾ ਹਾਂ ਕਿ Emacs ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਸਫਲ ਹੈ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਜਿਆਦਾਤਰ ਕਿਉਂਕਿ ਉਹ ਪਿੱਛੇ ਦੀ ਅਨੁਕੂਲਤਾ ਨੂੰ ਇੰਨੀ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਂਦੇ ਹਨ। ਅਸਲ ਵਿੱਚ, ਇਹ ਸਾਡੇ ਲੇਖ ਦਾ ਥੀਸਿਸ ਹੈ. ਸਫਲ, ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਖੁੱਲੇ ਸਿਸਟਮਾਂ ਦੀ ਸਫਲਤਾ ਉਹਨਾਂ ਸੂਖਮ ਭਾਈਚਾਰਿਆਂ ਲਈ ਹੈ ਜੋ ਦਹਾਕਿਆਂ ਤੋਂ ਉਹਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਰਹਿੰਦੇ ਹਨ। ਐਕਸਟੈਂਸ਼ਨ/ਪਲੱਗਇਨ. ਇਹ ਈਕੋਸਿਸਟਮ ਹੈ। ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਪ੍ਰਕਿਰਤੀ ਅਤੇ ਉਹ ਕਿੰਨੇ ਮਹੱਤਵਪੂਰਨ ਹਨ ਬਾਰੇ ਗੱਲ ਕਰ ਚੁੱਕਾ ਹਾਂ, ਅਤੇ ਕਿਵੇਂ ਗੂਗਲ ਨੇ ਆਪਣੇ ਪੂਰੇ ਕਾਰਪੋਰੇਟ ਇਤਿਹਾਸ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਸਮਝਿਆ ਕਿ ਐਂਡਰੌਇਡ ਜਾਂ ਕਰੋਮ ਤੋਂ ਬਾਹਰ ਇੱਕ ਸਫਲ ਓਪਨ ਪਲੇਟਫਾਰਮ ਬਣਾਉਣ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ।

ਅਸਲ ਵਿੱਚ, ਮੈਨੂੰ Android ਦਾ ਸੰਖੇਪ ਵਿੱਚ ਜ਼ਿਕਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਸ਼ਾਇਦ ਇਸ ਬਾਰੇ ਸੋਚ ਰਹੇ ਹੋ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਐਂਡਰਾਇਡ ਗੂਗਲ ਨਹੀਂ ਹੈ. ਉਹਨਾਂ ਦਾ ਇੱਕ ਦੂਜੇ ਨਾਲ ਲਗਭਗ ਕੁਝ ਵੀ ਸਾਂਝਾ ਨਹੀਂ ਹੈ। ਐਂਡਰੌਇਡ ਇੱਕ ਕੰਪਨੀ ਹੈ ਜੋ ਕਿ ਜੁਲਾਈ 2005 ਵਿੱਚ ਗੂਗਲ ਦੁਆਰਾ ਖਰੀਦੀ ਗਈ ਸੀ, ਕੰਪਨੀ ਨੂੰ ਘੱਟ ਜਾਂ ਘੱਟ ਖੁਦਮੁਖਤਿਆਰੀ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਗਈ ਸੀ ਅਤੇ ਅਸਲ ਵਿੱਚ ਦਖਲਅੰਦਾਜ਼ੀ ਦੇ ਸਾਲਾਂ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਛੂਤ ਰਹੀ ਹੈ। ਐਂਡਰੌਇਡ ਇੱਕ ਬਦਨਾਮ ਤਕਨੀਕੀ ਸਟੈਕ ਹੈ ਅਤੇ ਇੱਕ ਬਰਾਬਰ ਬਦਨਾਮ ਪ੍ਰਿੰਕਲੀ ਸੰਸਥਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਇੱਕ ਗੂਗਲਰ ਨੇ ਕਿਹਾ, "ਤੁਸੀਂ ਸਿਰਫ਼ ਐਂਡਰੌਇਡ ਵਿੱਚ ਲੌਗਇਨ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ।"

ਪਿਛਲੇ ਲੇਖ ਵਿੱਚ, ਮੈਂ ਚਰਚਾ ਕੀਤੀ ਸੀ ਕਿ ਐਂਡਰੌਇਡ ਦੇ ਸ਼ੁਰੂਆਤੀ ਡਿਜ਼ਾਈਨ ਫੈਸਲੇ ਕਿੰਨੇ ਮਾੜੇ ਸਨ। ਹੇਕ, ਜਦੋਂ ਮੈਂ ਉਹ ਲੇਖ ਲਿਖਿਆ ਸੀ ਤਾਂ ਉਹ "ਤਤਕਾਲ ਐਪਸ" ਨਾਮਕ ਬਕਵਾਸ ਪੇਸ਼ ਕਰ ਰਹੇ ਸਨ ਜੋ ਹੁਣ ਹਨ (ਹੈਰਾਨੀ!) ਪੁਰਾਣੀ, ਅਤੇ ਮੈਨੂੰ ਹਮਦਰਦੀ ਹੈ ਜੇਕਰ ਤੁਸੀਂ Google ਨੂੰ ਸੁਣਨ ਅਤੇ ਤੁਹਾਡੀ ਸਮੱਗਰੀ ਨੂੰ ਇਹਨਾਂ ਤਤਕਾਲ ਐਪਾਂ ਵਿੱਚ ਲਿਜਾਣ ਲਈ ਕਾਫ਼ੀ ਮੂਰਖ ਸੀ।

ਪਰ ਇੱਥੇ ਇੱਕ ਅੰਤਰ ਹੈ, ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ, ਜੋ ਕਿ ਇਹ ਹੈ ਕਿ ਐਂਡਰੌਇਡ ਲੋਕ ਅਸਲ ਵਿੱਚ ਸਮਝਦੇ ਹਨ ਕਿ ਪਲੇਟਫਾਰਮ ਕਿੰਨੇ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਉਹ ਪੁਰਾਣੇ ਐਂਡਰੌਇਡ ਐਪਸ ਨੂੰ ਕੰਮ ਕਰਦੇ ਰਹਿਣ ਲਈ ਆਪਣੀ ਪੂਰੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਵਾਸਤਵ ਵਿੱਚ, ਪਿੱਛੇ ਵੱਲ ਅਨੁਕੂਲਤਾ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਉਹਨਾਂ ਦੇ ਯਤਨ ਇੰਨੇ ਅਤਿਅੰਤ ਹਨ ਕਿ ਮੈਂ, ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ ਐਂਡਰੌਇਡ ਡਿਵੀਜ਼ਨ ਵਿੱਚ ਆਪਣੇ ਸੰਖੇਪ ਕਾਰਜਕਾਲ ਦੌਰਾਨ, ਆਪਣੇ ਆਪ ਨੂੰ ਕੁਝ ਪੁਰਾਣੀਆਂ ਡਿਵਾਈਸਾਂ ਅਤੇ APIs (ਮੈਂ ਗਲਤ ਸੀ) ਲਈ ਸਮਰਥਨ ਛੱਡਣ ਲਈ ਉਹਨਾਂ ਨੂੰ ਯਕੀਨ ਦਿਵਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ। , ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਅਤੇ ਵਰਤਮਾਨ ਦੀਆਂ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਵਿੱਚ ਸੀ। ਮਾਫ ਕਰਨਾ Android ਦੋਸਤੋ! ਹੁਣ ਜਦੋਂ ਮੈਂ ਇੰਡੋਨੇਸ਼ੀਆ ਗਿਆ ਹਾਂ, ਮੈਂ ਸਮਝ ਗਿਆ ਹਾਂ ਕਿ ਸਾਨੂੰ ਉਹਨਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ)।

ਐਂਡਰੌਇਡ ਲੋਕ ਅਨੁਕੂਲਤਾ ਨੂੰ ਲਗਭਗ ਕਲਪਨਾਯੋਗ ਹੱਦਾਂ ਵੱਲ ਧੱਕਦੇ ਹਨ, ਉਹਨਾਂ ਦੇ ਸਿਸਟਮਾਂ ਅਤੇ ਟੂਲਚੇਨਾਂ ਵਿੱਚ ਵਿਰਾਸਤੀ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਦੀ ਵੱਡੀ ਮਾਤਰਾ ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹਨ। ਹੇ ਮੇਰੇ ਰੱਬ, ਤੁਹਾਨੂੰ ਕੁਝ ਪਾਗਲ ਚੀਜ਼ਾਂ ਦੇਖਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜੋ ਉਹਨਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਬਿਲਡ ਸਿਸਟਮ ਵਿੱਚ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ ਹਨ, ਸਭ ਅਨੁਕੂਲਤਾ ਦੇ ਨਾਮ ਤੇ.

ਇਸਦੇ ਲਈ ਮੈਂ ਐਂਡਰਾਇਡ ਨੂੰ "ਯੂ ਆਰ ਨਹੀਂ ਗੂਗਲ" ਅਵਾਰਡ ਨਾਲ ਸਨਮਾਨਿਤ ਕਰਦਾ ਹਾਂ। ਉਹ ਅਸਲ ਵਿੱਚ ਗੂਗਲ ਨਹੀਂ ਬਣਨਾ ਚਾਹੁੰਦੇ, ਜੋ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਟਿਕਾਊ ਪਲੇਟਫਾਰਮ ਕਿਵੇਂ ਬਣਾਉਣਾ ਹੈ, ਪਰ ਐਂਡਰੌਇਡ ਜਾਣਦਾ ਹੈ, ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ। ਅਤੇ ਇਸ ਲਈ Google ਇੱਕ ਪੱਖੋਂ ਬਹੁਤ ਚੁਸਤ ਹੋ ਰਿਹਾ ਹੈ: ਲੋਕਾਂ ਨੂੰ Android 'ਤੇ ਆਪਣੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਹਾਲਾਂਕਿ, ਐਂਡਰੌਇਡ ਲਈ ਤਤਕਾਲ ਐਪਸ ਇੱਕ ਬਹੁਤ ਹੀ ਮੂਰਖ ਵਿਚਾਰ ਸਨ। ਅਤੇ ਕੀ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕਿਉਂ? ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਨੇ ਮੰਗ ਕੀਤੀ ਸੀ ਆਪਣੀ ਅਰਜ਼ੀ ਨੂੰ ਮੁੜ-ਲਿਖੋ ਅਤੇ ਮੁੜ-ਡਿਜ਼ਾਇਨ ਕਰੋ! ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ ਜਿਵੇਂ ਲੋਕ ਸਿਰਫ਼ ਦੋ ਮਿਲੀਅਨ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਗੇ. ਮੈਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਰਿਹਾ ਹਾਂ ਕਿ ਤਤਕਾਲ ਐਪਸ ਕੁਝ Googler ਦਾ ਵਿਚਾਰ ਸੀ।

ਪਰ ਇੱਕ ਫਰਕ ਹੈ. ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਉੱਚ ਕੀਮਤ 'ਤੇ ਆਉਂਦੀ ਹੈ। ਐਂਡਰਾਇਡ ਖੁਦ ਇਨ੍ਹਾਂ ਖਰਚਿਆਂ ਦਾ ਬੋਝ ਝੱਲਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਗੂਗਲ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ ਕਿ ਬੋਝ ਝੱਲਿਆ ਜਾਵੇ ਤੁਸੀਂ ਹੋ, ਗਾਹਕ ਦਾ ਭੁਗਤਾਨ.

ਤੁਸੀਂ ਇਸਦੇ API ਵਿੱਚ ਪਿੱਛੇ ਵੱਲ ਅਨੁਕੂਲਤਾ ਲਈ Android ਦੀ ਵਚਨਬੱਧਤਾ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਚਾਰ ਜਾਂ ਪੰਜ ਵੱਖ-ਵੱਖ ਸਬ-ਸਿਸਟਮ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਇੱਕੋ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਇਹ ਇੱਕ ਪੱਕਾ ਸੰਕੇਤ ਹੈ ਕਿ ਮੂਲ ਵਿੱਚ ਪਿੱਛੇ ਵੱਲ ਅਨੁਕੂਲਤਾ ਲਈ ਵਚਨਬੱਧਤਾ ਹੈ। ਜੋ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਤੁਹਾਡੇ ਗਾਹਕਾਂ ਅਤੇ ਤੁਹਾਡੀ ਮਾਰਕੀਟ ਪ੍ਰਤੀ ਵਚਨਬੱਧਤਾ ਦਾ ਸਮਾਨਾਰਥੀ ਹੈ।

ਇੱਥੇ ਗੂਗਲ ਦੀ ਮੁੱਖ ਸਮੱਸਿਆ ਉਨ੍ਹਾਂ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਸਫਾਈ ਵਿੱਚ ਉਨ੍ਹਾਂ ਦਾ ਮਾਣ ਹੈ। ਉਹ ਇਸ ਨੂੰ ਪਸੰਦ ਨਹੀਂ ਕਰਦੇ ਜਦੋਂ ਇੱਕੋ ਚੀਜ਼ ਨੂੰ ਕਰਨ ਦੇ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਹੁੰਦੇ ਹਨ, ਪੁਰਾਣੇ, ਘੱਟ ਫਾਇਦੇਮੰਦ ਤਰੀਕਿਆਂ ਦੇ ਨਾਲ ਨਵੇਂ, ਸ਼ਾਨਦਾਰ ਤਰੀਕਿਆਂ ਦੇ ਨਾਲ ਬੈਠਦੇ ਹਨ। ਇਹ ਸਿਸਟਮ ਵਿੱਚ ਨਵੇਂ ਲੋਕਾਂ ਲਈ ਸਿੱਖਣ ਦੀ ਵਕਰ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ, ਇਹ ਵਿਰਾਸਤੀ APIs ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਦੇ ਬੋਝ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ, ਇਹ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਗਤੀ ਨੂੰ ਹੌਲੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਮੁੱਖ ਪਾਪ ਇਹ ਹੈ ਕਿ ਇਹ ਸੁੰਦਰ ਨਹੀਂ ਹੈ। ਗੂਗਲ - ਟਿਮ ਬਰਟਨ ਦੀ ਐਲਿਸ ਇਨ ਵੰਡਰਲੈਂਡ ਤੋਂ ਲੇਡੀ ਐਸਕੋਟ ਵਾਂਗ:

ਲੇਡੀ ਅਸਕੋਟ:
- ਐਲਿਸ, ਕੀ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਮੈਂ ਸਭ ਤੋਂ ਵੱਧ ਕਿਸ ਗੱਲ ਤੋਂ ਡਰਦਾ ਹਾਂ?
- ਕੁਲੀਨ ਵਰਗ ਦਾ ਪਤਨ?
- ਮੈਨੂੰ ਡਰ ਸੀ ਕਿ ਮੇਰੇ ਕੋਲ ਹੋਵੇਗਾ ਬਦਸੂਰਤ ਪੋਤੇ-ਪੋਤੀਆਂ.

ਸੁੰਦਰ ਅਤੇ ਵਿਹਾਰਕ ਵਿਚਕਾਰ ਵਪਾਰ ਨੂੰ ਸਮਝਣ ਲਈ, ਆਓ ਤੀਜੇ ਸਫਲ ਪਲੇਟਫਾਰਮ (Emacs ਅਤੇ Android ਤੋਂ ਬਾਅਦ) 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ ਅਤੇ ਦੇਖੋ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ: ਜਾਵਾ ਖੁਦ.

Java ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਪੁਰਾਣੇ API ਹਨ। ਜਾਵਾ ਪ੍ਰੋਗਰਾਮਰਾਂ ਵਿੱਚ ਬਰਬਾਦੀ ਬਹੁਤ ਮਸ਼ਹੂਰ ਹੈ, ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਨਾਲੋਂ ਵੀ ਵਧੇਰੇ ਪ੍ਰਸਿੱਧ ਹੈ। ਜਾਵਾ ਖੁਦ, ਕੋਰ ਭਾਸ਼ਾ, ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਲਗਾਤਾਰ API ਨੂੰ ਬਰਤਰਫ਼ ਕਰ ਰਹੀਆਂ ਹਨ।

ਹਜ਼ਾਰਾਂ ਉਦਾਹਰਣਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਲੈਣ ਲਈ, ਬੰਦ ਥਰਿੱਡ ਪੁਰਾਣਾ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਦਸੰਬਰ 1.2 ਵਿੱਚ Java 1998 ਦੇ ਰਿਲੀਜ਼ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਬਰਤਰਫ਼ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਨੂੰ ਬਰਤਰਫ਼ ਕੀਤੇ ਹੋਏ 22 ਸਾਲ ਹੋ ਗਏ ਹਨ।

ਪਰ ਉਤਪਾਦਨ ਵਿੱਚ ਮੇਰਾ ਅਸਲ ਕੋਡ ਅਜੇ ਵੀ ਥਰਿੱਡਾਂ ਨੂੰ ਮਾਰ ਰਿਹਾ ਹੈ ਹਰ ਰੋਜ਼. ਕੀ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਸੋਚਦੇ ਹੋ ਕਿ ਇਹ ਚੰਗਾ ਹੈ? ਬਿਲਕੁਲ! ਮੇਰਾ ਮਤਲਬ ਹੈ, ਬੇਸ਼ੱਕ, ਜੇ ਮੈਂ ਅੱਜ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਸੀ, ਤਾਂ ਮੈਂ ਇਸਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਾਂਗਾ। ਪਰ ਮੇਰੀ ਖੇਡ ਲਈ ਕੋਡ, ਜਿਸ ਨੇ ਪਿਛਲੇ ਦੋ ਦਹਾਕਿਆਂ ਵਿੱਚ ਲੱਖਾਂ ਲੋਕਾਂ ਨੂੰ ਖੁਸ਼ ਕੀਤਾ ਹੈ, ਬਹੁਤ ਲੰਬੇ ਲਟਕਣ ਵਾਲੇ ਥਰਿੱਡਾਂ ਨੂੰ ਬੰਦ ਕਰਨ ਲਈ ਇੱਕ ਫੰਕਸ਼ਨ ਨਾਲ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਅਤੇ ਮੈਂ ਇਸ ਨੂੰ ਕਦੇ ਨਹੀਂ ਬਦਲਣਾ ਪਿਆ. ਮੈਂ ਆਪਣੇ ਸਿਸਟਮ ਨੂੰ ਕਿਸੇ ਨਾਲੋਂ ਬਿਹਤਰ ਜਾਣਦਾ ਹਾਂ, ਮੇਰੇ ਕੋਲ ਉਤਪਾਦਨ ਵਿੱਚ ਇਸਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ 25 ਸਾਲਾਂ ਦਾ ਤਜਰਬਾ ਹੈ, ਅਤੇ ਮੈਂ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਕਹਿ ਸਕਦਾ ਹਾਂ: ਮੇਰੇ ਕੇਸ ਵਿੱਚ, ਇਹਨਾਂ ਖਾਸ ਵਰਕਰ ਥਰਿੱਡਾਂ ਨੂੰ ਬੰਦ ਕਰਨਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੈ. ਨੁਕਸਾਨਦੇਹ. ਇਸ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਸਮਾਂ ਅਤੇ ਮਿਹਨਤ ਦੀ ਕੀਮਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਲੈਰੀ ਐਲੀਸਨ (ਸ਼ਾਇਦ) ਦਾ ਧੰਨਵਾਦ ਕਰੋ ਕਿ ਓਰੇਕਲ ਨੇ ਮੈਨੂੰ ਇਸਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕੀਤਾ।

ਓਰੇਕਲ ਸ਼ਾਇਦ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਵੀ ਸਮਝਦਾ ਹੈ। ਕੌਣ ਜਾਣਦਾ ਹੈ.

ਸਬੂਤ ਸਾਰੇ ਕੋਰ Java APIs ਵਿੱਚ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ, ਜੋ ਕਿ ਇੱਕ ਘਾਟੀ ਵਿੱਚ ਇੱਕ ਗਲੇਸ਼ੀਅਰ ਦੀਆਂ ਲਾਈਨਾਂ ਵਾਂਗ, ਅਪ੍ਰਚਲਿਤਤਾ ਦੀਆਂ ਲਹਿਰਾਂ ਨਾਲ ਭਰੀਆਂ ਹੋਈਆਂ ਹਨ। ਤੁਸੀਂ ਜਾਵਾ ਸਵਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਪੰਜ ਜਾਂ ਛੇ ਵੱਖ-ਵੱਖ ਕੀਬੋਰਡ ਨੈਵੀਗੇਸ਼ਨ ਮੈਨੇਜਰ (ਕੀਬੋਰਡ ਫੋਕਸਮੈਨੇਜਰ) ਆਸਾਨੀ ਨਾਲ ਲੱਭ ਸਕਦੇ ਹੋ। ਜਾਵਾ API ਨੂੰ ਲੱਭਣਾ ਅਸਲ ਵਿੱਚ ਔਖਾ ਹੈ ਜੋ ਬਰਤਰਫ਼ ਨਹੀਂ ਹੈ। ਪਰ ਉਹ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੇ ਹਨ! ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਜਾਵਾ ਟੀਮ ਸੱਚਮੁੱਚ ਹੀ ਇੱਕ API ਨੂੰ ਹਟਾ ਦੇਵੇਗੀ ਜੇਕਰ ਇੰਟਰਫੇਸ ਇੱਕ ਸਪਸ਼ਟ ਸੁਰੱਖਿਆ ਮੁੱਦਾ ਪੈਦਾ ਕਰਦਾ ਹੈ.

ਇੱਥੇ ਗੱਲ ਇਹ ਹੈ, ਲੋਕ: ਅਸੀਂ ਸੌਫਟਵੇਅਰ ਡਿਵੈਲਪਰ ਸਾਰੇ ਬਹੁਤ ਰੁੱਝੇ ਹੋਏ ਹਾਂ, ਅਤੇ ਸਾਫਟਵੇਅਰ ਦੇ ਹਰ ਖੇਤਰ ਵਿੱਚ ਸਾਨੂੰ ਪ੍ਰਤੀਯੋਗੀ ਵਿਕਲਪਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ। ਕਿਸੇ ਵੀ ਸਮੇਂ, ਭਾਸ਼ਾ X ਵਿੱਚ ਪ੍ਰੋਗਰਾਮਰ ਭਾਸ਼ਾ Y ਨੂੰ ਇੱਕ ਸੰਭਾਵੀ ਬਦਲ ਵਜੋਂ ਵਿਚਾਰ ਰਹੇ ਹਨ। ਓ, ਤੁਸੀਂ ਮੇਰੇ ਤੇ ਵਿਸ਼ਵਾਸ ਨਹੀਂ ਕਰਦੇ? ਕੀ ਤੁਸੀਂ ਇਸਨੂੰ ਸਵਿਫਟ ਕਹਿਣਾ ਚਾਹੁੰਦੇ ਹੋ? ਜਿਵੇਂ ਕਿ, ਹਰ ਕੋਈ ਸਵਿਫਟ ਵੱਲ ਪਰਵਾਸ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕੋਈ ਵੀ ਇਸ ਨੂੰ ਨਹੀਂ ਛੱਡ ਰਿਹਾ, ਠੀਕ? ਵਾਹ, ਤੁਸੀਂ ਕਿੰਨਾ ਘੱਟ ਜਾਣਦੇ ਹੋ। ਕੰਪਨੀਆਂ ਦੋਹਰੀ ਮੋਬਾਈਲ ਡਿਵੈਲਪਮੈਂਟ ਟੀਮਾਂ (ਆਈਓਐਸ ਅਤੇ ਐਂਡਰੌਇਡ) ਦੀਆਂ ਲਾਗਤਾਂ ਦੀ ਗਿਣਤੀ ਕਰ ਰਹੀਆਂ ਹਨ - ਅਤੇ ਉਹ ਇਹ ਮਹਿਸੂਸ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਨ ਕਿ ਫਲਟਰ ਅਤੇ ਰੀਐਕਟ ਨੇਟਿਵ ਵਰਗੇ ਮਜ਼ਾਕੀਆ ਨਾਵਾਂ ਵਾਲੇ ਉਹ ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਵਿਕਾਸ ਪ੍ਰਣਾਲੀ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਕਾਰ ਨੂੰ ਘਟਾਉਣ ਲਈ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਮੋਬਾਈਲ ਟੀਮਾਂ ਦੋ ਵਾਰ ਜਾਂ, ਇਸਦੇ ਉਲਟ, ਉਹਨਾਂ ਨੂੰ ਦੋ ਵਾਰ ਲਾਭਕਾਰੀ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਦਾਅ 'ਤੇ ਅਸਲ ਪੈਸਾ ਹੈ. ਹਾਂ, ਉੱਥੇ ਸਮਝੌਤੇ ਹਨ, ਪਰ, ਦੂਜੇ ਪਾਸੇ, ਪੈਸਾ.

ਚਲੋ ਕਲਪਨਾਤਮਕ ਤੌਰ 'ਤੇ ਇਹ ਮੰਨ ਲਓ ਕਿ ਐਪਲ ਨੇ ਮੂਰਖਤਾ ਨਾਲ ਗਾਈਡੋ ਵੈਨ ਰੋਸਮ ਤੋਂ ਇੱਕ ਸੰਕੇਤ ਲਿਆ ਅਤੇ ਘੋਸ਼ਣਾ ਕੀਤੀ ਕਿ ਸਵਿਫਟ 6.0 ਸਵਿਫਟ 5.0 ਦੇ ਨਾਲ ਪਿੱਛੇ ਵੱਲ ਅਸੰਗਤ ਹੈ, ਜਿਵੇਂ ਕਿ ਪਾਇਥਨ 3 ਪਾਇਥਨ 2 ਨਾਲ ਅਸੰਗਤ ਹੈ।

ਮੈਂ ਸ਼ਾਇਦ ਇਹ ਕਹਾਣੀ ਲਗਭਗ ਦਸ ਸਾਲ ਪਹਿਲਾਂ ਦੱਸੀ ਸੀ, ਪਰ ਲਗਭਗ ਪੰਦਰਾਂ ਸਾਲ ਪਹਿਲਾਂ ਮੈਂ ਗਾਈਡੋ ਦੇ ਨਾਲ ਓ'ਰੀਲੀ ਦੇ ਫੂ ਕੈਂਪ 'ਤੇ ਗਿਆ ਸੀ, ਪਾਲ ਗ੍ਰਾਹਮ ਅਤੇ ਵੱਡੇ ਸ਼ਾਟਾਂ ਦੇ ਝੁੰਡ ਦੇ ਨਾਲ ਇੱਕ ਤੰਬੂ ਵਿੱਚ ਬੈਠਾ ਸੀ। ਅਸੀਂ ਤੇਜ਼ ਗਰਮੀ ਵਿੱਚ ਲੈਰੀ ਪੇਜ ਦੇ ਆਪਣੇ ਨਿੱਜੀ ਹੈਲੀਕਾਪਟਰ ਵਿੱਚ ਉੱਡਣ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਸੀ ਜਦੋਂ ਕਿ ਗਾਈਡੋ ਨੇ ਲਗਭਗ "ਪਾਈਥਨ 3000" 'ਤੇ ਡਰੋਨ ਕੀਤਾ, ਜਿਸਦਾ ਨਾਮ ਉਸਨੇ ਉਨ੍ਹਾਂ ਸਾਲਾਂ ਦੀ ਸੰਖਿਆ ਦੇ ਨਾਮ 'ਤੇ ਰੱਖਿਆ ਜੋ ਹਰ ਕਿਸੇ ਨੂੰ ਉੱਥੇ ਪਰਵਾਸ ਕਰਨ ਵਿੱਚ ਲੱਗਣਗੇ। ਅਸੀਂ ਉਸਨੂੰ ਪੁੱਛਦੇ ਰਹੇ ਕਿ ਉਹ ਅਨੁਕੂਲਤਾ ਨੂੰ ਕਿਉਂ ਤੋੜ ਰਿਹਾ ਸੀ, ਅਤੇ ਉਸਨੇ ਜਵਾਬ ਦਿੱਤਾ: "ਯੂਨੀਕੋਡ।" ਅਤੇ ਅਸੀਂ ਪੁੱਛਿਆ, ਜੇਕਰ ਸਾਨੂੰ ਆਪਣਾ ਕੋਡ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪਿਆ, ਤਾਂ ਅਸੀਂ ਹੋਰ ਕਿਹੜੇ ਫਾਇਦੇ ਦੇਖਾਂਗੇ? ਅਤੇ ਉਸਨੇ ਜਵਾਬ ਦਿੱਤਾ, "ਯੋਓੂਓੂਓੂਓੂਯੂਯੂਯੂਯੂਨੀਆਈਆਈਆਈਆਈਸੀਕੂਓੂਡ."

ਜੇਕਰ ਤੁਸੀਂ Google ਕਲਾਊਡ ਪਲੇਟਫਾਰਮ SDK (“gcloud”) ਨੂੰ ਸਥਾਪਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਅੱਗੇ ਦਿੱਤੀ ਸੂਚਨਾ ਪ੍ਰਾਪਤ ਹੋਵੇਗੀ:

ਪਿਆਰੇ ਪ੍ਰਾਪਤਕਰਤਾ,

ਅਸੀਂ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ Python 2 ਲਈ ਸਮਰਥਨ ਨੂੰ ਬਰਤਰਫ਼ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਭੜਕਾਓ

… ਇਤਆਦਿ. ਜੀਵਨ ਦਾ ਚੱਕਰ.

ਪਰ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਹਰੇਕ ਡਿਵੈਲਪਰ ਕੋਲ ਇੱਕ ਵਿਕਲਪ ਹੁੰਦਾ ਹੈ. ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਅਕਸਰ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਇਸ ਬਾਰੇ ਸੋਚ ਸਕਦੇ ਹਨ ਹੋਰ ਵਿਕਲਪ। ਉਹ ਤੁਹਾਡੇ ਬੰਧਕ ਨਹੀਂ ਹਨ, ਭਾਵੇਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿੰਨਾ ਚਾਹੋ। ਉਹ ਤੁਹਾਡੇ ਮਹਿਮਾਨ ਹਨ। ਪਾਈਥਨ ਅਜੇ ਵੀ ਇੱਕ ਬਹੁਤ ਹੀ ਪ੍ਰਸਿੱਧ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਹੈ, ਪਰ ਹਾਏ, ਪਾਈਥਨ 3(000) ਨੇ ਆਪਣੇ ਆਪ ਵਿੱਚ, ਇਸਦੇ ਭਾਈਚਾਰਿਆਂ ਵਿੱਚ ਅਤੇ ਇਸਦੇ ਭਾਈਚਾਰਿਆਂ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਵਿੱਚ ਅਜਿਹੀ ਗੜਬੜ ਪੈਦਾ ਕੀਤੀ ਹੈ ਕਿ ਨਤੀਜੇ ਪੰਦਰਾਂ ਸਾਲਾਂ ਤੋਂ ਸਾਫ਼ ਨਹੀਂ ਹੋਏ ਹਨ।

ਇਸ ਪਿੱਛੇ ਦੀ ਅਸੰਗਤਤਾ ਦੇ ਕਾਰਨ ਗੋ (ਜਾਂ ਰੂਬੀ, ਜਾਂ ਕੋਈ ਹੋਰ ਵਿਕਲਪ) ਵਿੱਚ ਕਿੰਨੇ ਪਾਈਥਨ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਹੈ? ਪਾਈਥਨ ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਵਿੱਚ ਕਿੰਨਾ ਨਵਾਂ ਸਾਫਟਵੇਅਰ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਹੋ ਸਕਦਾ ਪਾਈਥਨ ਵਿੱਚ ਲਿਖਿਆ, ਜੇ ਗਾਈਡੋ ਨੇ ਸਾਰਾ ਪਿੰਡ ਨਾ ਸਾੜਿਆ ਹੁੰਦਾ? ਇਹ ਕਹਿਣਾ ਔਖਾ ਹੈ, ਪਰ ਪਾਈਥਨ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨੁਕਸਾਨ ਹੋਇਆ ਹੈ. ਇਹ ਇੱਕ ਵੱਡੀ ਗੜਬੜ ਹੈ ਅਤੇ ਹਰ ਕੋਈ ਹਾਰਦਾ ਹੈ।

ਇਸ ਲਈ ਮੰਨ ਲਓ ਕਿ ਐਪਲ ਗਾਈਡੋ ਤੋਂ ਇੱਕ ਸੰਕੇਤ ਲੈਂਦਾ ਹੈ ਅਤੇ ਅਨੁਕੂਲਤਾ ਨੂੰ ਤੋੜਦਾ ਹੈ. ਤੁਸੀਂ ਕੀ ਸੋਚਦੇ ਹੋ ਕਿ ਅੱਗੇ ਕੀ ਹੋਵੇਗਾ? ਠੀਕ ਹੈ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ 80-90% ਡਿਵੈਲਪਰ ਆਪਣੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਗੇ. ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਉਪਭੋਗਤਾ ਅਧਾਰ ਦਾ 10-20% ਆਪਣੇ ਆਪ ਹੀ ਕਿਸੇ ਮੁਕਾਬਲੇ ਵਾਲੀ ਭਾਸ਼ਾ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਫਲਟਰ।

ਇਸ ਨੂੰ ਕਈ ਵਾਰ ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਆਪਣਾ ਅੱਧਾ ਉਪਭੋਗਤਾ ਅਧਾਰ ਗੁਆ ਦੇਵੋਗੇ। ਜਿਵੇਂ ਖੇਡਾਂ ਵਿੱਚ, ਪ੍ਰੋਗਰਾਮਿੰਗ ਦੀ ਦੁਨੀਆ ਵਿੱਚ, ਮੌਜੂਦਾ ਰੂਪ ਵੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਸਭ ਕੁਝ. ਕੋਈ ਵੀ ਜੋ ਪੰਜ ਸਾਲਾਂ ਵਿੱਚ ਆਪਣੇ ਅੱਧੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਗੁਆ ਦਿੰਦਾ ਹੈ ਉਸਨੂੰ ਇੱਕ ਵੱਡਾ ਮੋਟਾ ਘਾਟਾ ਮੰਨਿਆ ਜਾਵੇਗਾ। ਤੁਹਾਨੂੰ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਟਰੈਡੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਰ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਦਾ ਸਮਰਥਨ ਨਾ ਕਰਨਾ ਸਮੇਂ ਦੇ ਨਾਲ ਤੁਹਾਨੂੰ ਬਰਬਾਦ ਕਰ ਦੇਵੇਗਾ। ਕਿਉਂਕਿ ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਡਿਵੈਲਪਰਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ (ਏ) ਉਹਨਾਂ ਨੂੰ ਹਮੇਸ਼ਾ ਲਈ ਗੁਆ ਦਿੰਦੇ ਹੋ ਕਿਉਂਕਿ ਉਹ ਇਕਰਾਰਨਾਮੇ ਨੂੰ ਤੋੜਨ ਲਈ ਤੁਹਾਡੇ 'ਤੇ ਗੁੱਸੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ (ਬੀ) ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੇ ਪ੍ਰਤੀਯੋਗੀਆਂ ਨੂੰ ਦੇ ਦਿੰਦੇ ਹਨ।

ਵਿਅੰਗਾਤਮਕ ਤੌਰ 'ਤੇ, ਮੈਂ ਗੂਗਲ ਦੀ ਅਜਿਹੀ ਪ੍ਰਾਈਮਾ ਡੋਨਾ ਬਣਨ ਵਿੱਚ ਵੀ ਮਦਦ ਕੀਤੀ ਜੋ ਪਿੱਛੇ ਦੀ ਅਨੁਕੂਲਤਾ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀ ਹੈ ਜਦੋਂ ਮੈਂ ਗ੍ਰੋਕ ਬਣਾਇਆ, ਇੱਕ ਸਰੋਤ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਸਮਝ ਪ੍ਰਣਾਲੀ ਜੋ ਕੋਡ ਨੂੰ ਸਵੈਚਲਿਤ ਅਤੇ ਸਾਧਨ ਬਣਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ - ਇੱਕ IDE ਦੇ ਸਮਾਨ, ਪਰ ਇੱਥੇ ਕਲਾਉਡ ਸੇਵਾ ਸਟੋਰ ਕਰਦੀ ਹੈ. ਇੱਕ ਵੱਡੇ ਡੇਟਾ ਵੇਅਰਹਾਊਸ ਵਿੱਚ ਗੂਗਲ ਸੋਰਸ ਕੋਡ ਦੀਆਂ ਅਰਬਾਂ ਲਾਈਨਾਂ ਦੇ ਅਸਲ ਰੂਪ ਵਿੱਚ ਪੇਸ਼ਕਾਰੀ।

Grok ਨੇ Googlers ਨੂੰ ਉਹਨਾਂ ਦੇ ਪੂਰੇ ਕੋਡਬੇਸ (ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਪੂਰੇ Google) ਵਿੱਚ ਸਵੈਚਲਿਤ ਰੀਫੈਕਟਰਿੰਗ ਕਰਨ ਲਈ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਫਰੇਮਵਰਕ ਪ੍ਰਦਾਨ ਕੀਤਾ ਹੈ। ਸਿਸਟਮ ਨਾ ਸਿਰਫ਼ ਤੁਹਾਡੀ ਅੱਪਸਟਰੀਮ ਨਿਰਭਰਤਾ (ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਨਿਰਭਰ ਕਰਦੇ ਹੋ), ਸਗੋਂ ਇਹ ਵੀ ਉਤਰਦੇ ਹੋਏ (ਜੋ ਤੁਹਾਡੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ) ਇਸ ਲਈ ਜਦੋਂ ਤੁਸੀਂ API ਬਦਲਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਹਰ ਕਿਸੇ ਨੂੰ ਜਾਣਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਤੋੜ ਰਹੇ ਹੋ! ਇਸ ਤਰੀਕੇ ਨਾਲ, ਜਦੋਂ ਤੁਸੀਂ ਤਬਦੀਲੀਆਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਤੁਹਾਡੇ API ਦੇ ਹਰੇਕ ਖਪਤਕਾਰ ਨੇ ਨਵੇਂ ਸੰਸਕਰਣ ਵਿੱਚ ਅੱਪਡੇਟ ਕੀਤਾ ਹੈ, ਅਤੇ ਅਸਲ ਵਿੱਚ, ਅਕਸਰ ਉਹਨਾਂ ਦੁਆਰਾ ਲਿਖੇ ਰੋਜ਼ੀ ਟੂਲ ਨਾਲ, ਤੁਸੀਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਵੈਚਲਿਤ ਕਰ ਸਕਦੇ ਹੋ।

ਇਹ Google ਦੇ ਕੋਡਬੇਸ ਨੂੰ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਲਗਭਗ ਅਲੌਕਿਕ ਤੌਰ 'ਤੇ ਸਾਫ਼ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਕੋਲ ਇਹ ਰੋਬੋਟਿਕ ਨੌਕਰ ਘਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਘੁੰਮਦੇ ਹਨ ਅਤੇ ਆਪਣੇ ਆਪ ਸਭ ਕੁਝ ਸਾਫ਼ ਕਰ ਦਿੰਦੇ ਹਨ ਜੇਕਰ ਉਹਨਾਂ ਨੇ SomeDespicablyLongFunctionName ਦਾ ਨਾਮ ਬਦਲ ਕੇ SomeDespicablyLongMethodName ਰੱਖਿਆ ਹੈ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਇਹ ਇੱਕ ਬਦਸੂਰਤ ਪੋਤਾ ਹੈ ਅਤੇ ਉਸਨੂੰ ਸੌਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ।

ਅਤੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇਹ ਗੂਗਲ ਲਈ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ... ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ. ਮੇਰਾ ਮਤਲਬ ਹੈ, ਹਾਂ, ਗੂਗਲ 'ਤੇ ਗੋ ਕਮਿਊਨਿਟੀ ਦਾ ਗੂਗਲ 'ਤੇ ਜਾਵਾ ਕਮਿਊਨਿਟੀ ਨਾਲ ਚੰਗਾ ਹੱਸਦਾ ਹੈ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਦੀ ਲਗਾਤਾਰ ਰੀਫੈਕਟਰਿੰਗ ਦੀ ਆਦਤ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ N ਵਾਰ ਰੀਸਟਾਰਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ N-1 ਵਾਰ ਹੀ ਖਰਾਬ ਨਹੀਂ ਕੀਤਾ, ਪਰ ਕੁਝ ਸਮੇਂ ਬਾਅਦ ਇਹ ਬਿਲਕੁਲ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸ਼ਾਇਦ Nth ਕੋਸ਼ਿਸ਼ 'ਤੇ ਵੀ ਇਸ ਨੂੰ ਖਰਾਬ ਕੀਤਾ ਹੈ। ਪਰ, ਆਮ ਤੌਰ 'ਤੇ, ਉਹ ਇਸ ਸਾਰੇ ਗੜਬੜ ਤੋਂ ਉੱਪਰ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਕੋਡ ਨੂੰ "ਸਾਫ਼" ਰੱਖਦੇ ਹਨ.

ਸਮੱਸਿਆ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਉਹ ਆਪਣੇ ਕਲਾਉਡ ਕਲਾਇੰਟਸ ਅਤੇ ਹੋਰ API ਦੇ ਉਪਭੋਗਤਾਵਾਂ 'ਤੇ ਇਸ ਰਵੱਈਏ ਨੂੰ ਥੋਪਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ.

ਮੈਂ ਤੁਹਾਨੂੰ Emacs, Android ਅਤੇ Java ਨਾਲ ਥੋੜਾ ਜਿਹਾ ਜਾਣੂ ਕਰਵਾਇਆ ਹੈ; ਆਉ ਨਵੀਨਤਮ ਸਫਲ ਲੰਬੇ ਸਮੇਂ ਦੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀਏ: ਵੈੱਬ ਖੁਦ। ਕੀ ਤੁਸੀਂ ਕਲਪਨਾ ਕਰ ਸਕਦੇ ਹੋ ਕਿ 1995 ਤੋਂ ਜਦੋਂ ਅਸੀਂ ਫਲੈਸ਼ਿੰਗ ਟੈਗਸ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ ਤਾਂ HTTP ਕਿੰਨੀਆਂ ਦੁਹਰਾਅ ਵਿੱਚੋਂ ਲੰਘਿਆ ਹੈ? ਅਤੇ ਵੈੱਬ ਪੰਨਿਆਂ 'ਤੇ "ਨਿਰਮਾਣ ਅਧੀਨ" ਆਈਕਨ।

ਪਰ ਇਹ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ! ਅਤੇ ਇਹ ਪੰਨੇ ਅਜੇ ਵੀ ਕੰਮ ਕਰ ਰਹੇ ਹਨ! ਹਾਂ, ਦੋਸਤੋ, ਬ੍ਰਾਊਜ਼ਰ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਵਿੱਚ ਵਿਸ਼ਵ ਚੈਂਪੀਅਨ ਹਨ। ਕਰੋਮ ਇੱਕ ਦੁਰਲੱਭ ਗੂਗਲ ਪਲੇਟਫਾਰਮ ਦਾ ਇੱਕ ਹੋਰ ਉਦਾਹਰਨ ਹੈ ਜਿਸ ਦੇ ਸਿਰ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਪੇਚ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ ਹੋਵੇਗਾ, ਕ੍ਰੋਮ ਇੱਕ ਸੈਂਡਬੌਕਸਡ ਕੰਪਨੀ ਦੇ ਤੌਰ ਤੇ ਬਾਕੀ Google ਤੋਂ ਵੱਖਰਾ ਕੰਮ ਕਰਦਾ ਹੈ।

ਮੈਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਡਿਵੈਲਪਰਾਂ ਵਿੱਚ ਆਪਣੇ ਦੋਸਤਾਂ ਦਾ ਵੀ ਧੰਨਵਾਦ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, ਆਦਿ, ਉਹਨਾਂ ਦੇ ਸਫਲ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਪਿੱਛੇ ਵੱਲ ਅਨੁਕੂਲਤਾ ਦਾ ਇੰਨਾ ਵਧੀਆ ਕੰਮ ਕਰਨ ਲਈ (ਐਪਲ ਨੂੰ ਵਧੀਆ ਨਾਲ ਇੱਕ C ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ। ਨਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਉਹ ਬਿਨਾਂ ਕਿਸੇ ਚੰਗੇ ਕਾਰਨ ਦੇ ਹਰ ਸਮੇਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਤੋੜ ਦਿੰਦੇ ਹਨ, ਪਰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਕਮਿਊਨਿਟੀ ਹਰ ਰੀਲੀਜ਼ ਦੇ ਨਾਲ ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ OS X ਕੰਟੇਨਰ ਅਜੇ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪੁਰਾਣੇ ਨਹੀਂ ਹਨ... ਅਜੇ ਤੱਕ).

ਪਰ ਉਡੀਕ ਕਰੋ, ਤੁਸੀਂ ਕਹਿੰਦੇ ਹੋ. ਕੀ ਅਸੀਂ ਸੇਬਾਂ ਦੀ ਸੰਤਰੇ ਨਾਲ ਤੁਲਨਾ ਨਹੀਂ ਕਰ ਰਹੇ ਹਾਂ - ਇੱਕ ਸਿੰਗਲ ਮਸ਼ੀਨ ਜਿਵੇਂ ਕਿ Emacs/JDK/Android/Chrome ਬਨਾਮ ਮਲਟੀ-ਸਰਵਰ ਸਿਸਟਮ ਅਤੇ ਏਪੀਆਈ ਜਿਵੇਂ ਕਿ ਕਲਾਉਡ ਸੇਵਾਵਾਂ?

ਖੈਰ, ਮੈਂ ਕੱਲ੍ਹ ਇਸ ਬਾਰੇ ਟਵੀਟ ਕੀਤਾ ਸੀ, ਪਰ ਲੈਰੀ ਵਾਲ (ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਪਰਲ ਦੇ ਸਿਰਜਣਹਾਰ - ਲਗਭਗ ਪ੍ਰਤੀ.) ਦੀ ਸ਼ੈਲੀ ਵਿੱਚ "ਸਕਸ/ਰੂਲਸ" ਦੇ ਸਿਧਾਂਤ 'ਤੇ ਮੈਂ ਸ਼ਬਦ ਨੂੰ ਦੇਖਿਆ। ਨਾਪਸੰਦ ਕੀਤਾ ਗੂਗਲ ਅਤੇ ਐਮਾਜ਼ਾਨ ਡਿਵੈਲਪਰ ਸਾਈਟਾਂ 'ਤੇ. ਅਤੇ ਹਾਲਾਂਕਿ AWS ਕੋਲ ਹੈ ਸੈਂਕੜੇ GCP ਨਾਲੋਂ ਕਈ ਗੁਣਾ ਜ਼ਿਆਦਾ ਸੇਵਾ ਪੇਸ਼ਕਸ਼ਾਂ, Google ਦੇ ਡਿਵੈਲਪਰ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਸੱਤ ਗੁਣਾ ਜ਼ਿਆਦਾ ਵਾਰ ਬਰਬਾਦੀ ਦਾ ਜ਼ਿਕਰ ਹੈ।

ਜੇਕਰ ਗੂਗਲ 'ਤੇ ਕੋਈ ਵੀ ਇਸ ਨੂੰ ਪੜ੍ਹ ਰਿਹਾ ਹੈ, ਤਾਂ ਉਹ ਸ਼ਾਇਦ ਡੋਨਾਲਡ ਟਰੰਪ-ਸ਼ੈਲੀ ਦੇ ਚਾਰਟ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਲਈ ਤਿਆਰ ਹਨ ਜੋ ਇਹ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਸਭ ਕੁਝ ਸਹੀ ਕਰ ਰਹੇ ਹਨ, ਅਤੇ ਇਹ ਕਿ ਮੈਨੂੰ ਗਲਤ ਤੁਲਨਾ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਿਵੇਂ ਕਿ "ਬਨਾਮ ਵਰਜਿਤ ਸ਼ਬਦ ਦੇ ਜ਼ਿਕਰ ਦੀ ਗਿਣਤੀ ਸੇਵਾਵਾਂ ਦੀ ਗਿਣਤੀ" "

ਪਰ ਇੰਨੇ ਸਾਲਾਂ ਬਾਅਦ, ਗੂਗਲ ਕਲਾਉਡ ਅਜੇ ਵੀ ਨੰਬਰ 3 ਸੇਵਾ ਹੈ (ਮੈਂ ਕਦੇ ਵੀ ਨੰਬਰ 2 ਬਣਨ ਦੀ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ ਬਾਰੇ ਕੋਈ ਲੇਖ ਨਹੀਂ ਲਿਖਿਆ), ਪਰ ਜੇ ਅੰਦਰੂਨੀ ਲੋਕਾਂ ਦੀ ਮੰਨੀਏ ਤਾਂ, ਕੁਝ ਚਿੰਤਾਵਾਂ ਹਨ ਜੋ ਜਲਦੀ ਹੀ ਹੇਠਾਂ ਆ ਸਕਦੀਆਂ ਹਨ. ਨੰ. 4.

ਮੇਰੇ ਕੋਲ ਮੇਰੇ ਥੀਸਿਸ ਨੂੰ "ਸਾਬਤ" ਕਰਨ ਲਈ ਕੋਈ ਮਜਬੂਰ ਕਰਨ ਵਾਲੀਆਂ ਦਲੀਲਾਂ ਨਹੀਂ ਹਨ। ਮੇਰੇ ਕੋਲ ਉਹ ਰੰਗੀਨ ਉਦਾਹਰਣ ਹਨ ਜੋ ਮੈਂ ਇੱਕ ਡਿਵੈਲਪਰ ਵਜੋਂ 30 ਸਾਲਾਂ ਤੋਂ ਵੱਧ ਇਕੱਠੀਆਂ ਕੀਤੀਆਂ ਹਨ। ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਸਮੱਸਿਆ ਦੇ ਡੂੰਘੇ ਦਾਰਸ਼ਨਿਕ ਸੁਭਾਅ ਦਾ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ; ਕੁਝ ਤਰੀਕਿਆਂ ਨਾਲ ਵਿਕਾਸਕਾਰ ਭਾਈਚਾਰਿਆਂ ਵਿੱਚ ਇਸ ਦਾ ਸਿਆਸੀਕਰਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਮੰਨਦੇ ਹਨ ਕਿ ਸਿਰਜਣਹਾਰ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਅਨੁਕੂਲਤਾ ਦੀ ਪਰਵਾਹ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਦੂਸਰੇ ਸੋਚਦੇ ਹਨ ਕਿ ਇਹ ਇੱਕ ਚਿੰਤਾ ਹੈ ਉਪਭੋਗੀ ਨੂੰ (ਡਿਵੈਲਪਰ ਖੁਦ). ਦੋ ਵਿੱਚੋਂ ਇੱਕ। ਅਸਲ ਵਿੱਚ, ਕੀ ਇਹ ਇੱਕ ਸਿਆਸੀ ਮੁੱਦਾ ਨਹੀਂ ਹੈ ਜਦੋਂ ਅਸੀਂ ਇਹ ਫੈਸਲਾ ਕਰਦੇ ਹਾਂ ਕਿ ਆਮ ਸਮੱਸਿਆਵਾਂ ਦਾ ਖਰਚਾ ਕਿਸ ਨੂੰ ਚੁੱਕਣਾ ਚਾਹੀਦਾ ਹੈ?

ਇਸ ਲਈ ਇਹ ਰਾਜਨੀਤੀ ਹੈ। ਅਤੇ ਮੇਰੇ ਭਾਸ਼ਣ 'ਤੇ ਸ਼ਾਇਦ ਗੁੱਸੇ ਭਰੇ ਜਵਾਬ ਹੋਣਗੇ।

ਕਰਨਾ ਯੂਜ਼ਰ ਗੂਗਲ ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ, ਅਤੇ ਦੋ ਸਾਲਾਂ ਲਈ ਇੱਕ AWS ਉਪਭੋਗਤਾ ਵਜੋਂ (ਗਰੈਬ ਲਈ ਕੰਮ ਕਰਦੇ ਹੋਏ), ਮੈਂ ਕਹਿ ਸਕਦਾ ਹਾਂ ਕਿ ਐਮਾਜ਼ਾਨ ਅਤੇ ਗੂਗਲ ਦੇ ਫ਼ਲਸਫ਼ਿਆਂ ਵਿੱਚ ਬਹੁਤ ਵੱਡਾ ਅੰਤਰ ਹੈ ਜਦੋਂ ਇਹ ਤਰਜੀਹਾਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ. ਮੈਂ AWS 'ਤੇ ਸਰਗਰਮੀ ਨਾਲ ਵਿਕਾਸ ਨਹੀਂ ਕਰਦਾ ਹਾਂ, ਇਸ ਲਈ ਮੈਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਪਤਾ ਕਿ ਉਹ ਕਿੰਨੀ ਵਾਰ ਪੁਰਾਣੇ API ਨੂੰ ਹਟਾਉਂਦੇ ਹਨ। ਪਰ ਇੱਕ ਸੰਦੇਹ ਹੈ ਕਿ ਇਹ ਲਗਭਗ ਓਨੀ ਵਾਰ ਨਹੀਂ ਹੁੰਦਾ ਜਿੰਨਾ ਗੂਗਲ 'ਤੇ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਮੈਂ ਸੱਚਮੁੱਚ ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹਾਂ ਕਿ GCP ਵਿੱਚ ਲਗਾਤਾਰ ਵਿਵਾਦ ਅਤੇ ਨਿਰਾਸ਼ਾ ਦਾ ਇਹ ਸਰੋਤ ਪਲੇਟਫਾਰਮ ਦੇ ਵਿਕਾਸ ਨੂੰ ਰੋਕਣ ਵਾਲੇ ਸਭ ਤੋਂ ਵੱਡੇ ਕਾਰਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।

ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਮੈਂ GCP ਪ੍ਰਣਾਲੀਆਂ ਦੀਆਂ ਖਾਸ ਉਦਾਹਰਣਾਂ ਦਾ ਨਾਮ ਨਹੀਂ ਲਿਆ ਜੋ ਹੁਣ ਸਮਰਥਿਤ ਨਹੀਂ ਹਨ। ਮੈਂ ਕਹਿ ਸਕਦਾ ਹਾਂ ਕਿ ਨੈੱਟਵਰਕ (ਸਭ ਤੋਂ ਪੁਰਾਣੇ ਤੋਂ VPC ਤੱਕ) ਤੋਂ ਸਟੋਰੇਜ (Cloud SQL v1-v2), ਫਾਇਰਬੇਸ (ਹੁਣ ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰੇ API ਦੇ ਨਾਲ ਫਾਇਰਸਟੋਰ), ਐਪ ਇੰਜਣ (ਆਓ ਸ਼ੁਰੂ ਵੀ ਨਾ ਕਰੀਏ) ਤੱਕ, ਲਗਭਗ ਹਰ ਚੀਜ਼ ਜੋ ਮੈਂ ਵਰਤੀ ਹੈ। , ਕਲਾਉਡ ਐਂਡਪੁਆਇੰਟ ਕਲਾਉਡ ਐਂਡਪੁਆਇੰਟ ਅਤੇ ਇਸ ਤੱਕ... ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ - ਬਿਲਕੁਲ ਇਹ ਸਭ ਤੁਹਾਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ 2-3 ਸਾਲਾਂ ਬਾਅਦ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ, ਅਤੇ ਉਹਨਾਂ ਨੇ ਕਦੇ ਵੀ ਤੁਹਾਡੇ ਲਈ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਸਵੈਚਲਿਤ ਨਹੀਂ ਕੀਤਾ, ਅਤੇ ਅਕਸਰ ਇੱਥੇ ਕੋਈ ਦਸਤਾਵੇਜ਼ੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਾਰਗ ਬਿਲਕੁਲ ਨਹੀਂ ਸੀ. ਜਿਵੇਂ ਕਿ ਅਜਿਹਾ ਹੋਣਾ ਹੀ ਸੀ।

ਅਤੇ ਹਰ ਵਾਰ ਜਦੋਂ ਮੈਂ AWS ਨੂੰ ਦੇਖਦਾ ਹਾਂ, ਮੈਂ ਆਪਣੇ ਆਪ ਨੂੰ ਪੁੱਛਦਾ ਹਾਂ ਕਿ ਮੈਂ ਅਜੇ ਵੀ GCP 'ਤੇ ਕਿਉਂ ਹਾਂ। ਉਨ੍ਹਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਗਾਹਕਾਂ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ. ਉਹਨਾਂ ਦੀ ਲੋੜ ਹੈ ਖਰੀਦਦਾਰ. ਕੀ ਤੁਸੀਂ ਫਰਕ ਸਮਝਦੇ ਹੋ? ਮੈਨੂੰ ਸਮਝਾਉਣ ਦਿਓ.

ਗੂਗਲ ਕਲਾਉਡ ਕੋਲ ਹੈ ਬਾਜ਼ਾਰ, ਜਿੱਥੇ ਲੋਕ ਆਪਣੇ ਸੌਫਟਵੇਅਰ ਹੱਲਾਂ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦੇ ਹਨ, ਅਤੇ ਖਾਲੀ ਰੈਸਟੋਰੈਂਟ ਪ੍ਰਭਾਵ ਤੋਂ ਬਚਣ ਲਈ, ਉਹਨਾਂ ਨੂੰ ਇਸ ਨੂੰ ਕੁਝ ਪ੍ਰਸਤਾਵਾਂ ਨਾਲ ਭਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਇਸਲਈ ਉਹਨਾਂ ਨੇ "ਇੱਕ ਕਲਿੱਕ" ਨਾਲ ਤੈਨਾਤ ਕੀਤੇ ਗਏ ਹੱਲਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਬਣਾਉਣ ਲਈ Bitnami ਨਾਮ ਦੀ ਇੱਕ ਕੰਪਨੀ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ, ਜਾਂ ਮੈਂ ਇਸਨੂੰ ਆਪਣੇ ਆਪ "ਹੱਲ" ਲਿਖਦਾ ਹਾਂ, ਕਿਉਂਕਿ ਇਹ ਕਿਸੇ ਮਾੜੀ ਚੀਜ਼ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਉਹ ਸਿਰਫ਼ ਚੈਕਬਾਕਸ ਦੇ ਤੌਰ 'ਤੇ ਮੌਜੂਦ ਹਨ, ਮਾਰਕੀਟਿੰਗ ਫਿਲਰ ਵਜੋਂ, ਅਤੇ ਗੂਗਲ ਨੇ ਕਦੇ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕੀਤੀ ਹੈ ਕਿ ਕੋਈ ਵੀ ਟੂਲ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਮੈਂ ਉਨ੍ਹਾਂ ਉਤਪਾਦ ਪ੍ਰਬੰਧਕਾਂ ਨੂੰ ਜਾਣਦਾ ਹਾਂ ਜੋ ਡਰਾਈਵਰ ਦੀ ਸੀਟ 'ਤੇ ਬੈਠੇ ਹਨ, ਅਤੇ ਮੈਂ ਤੁਹਾਨੂੰ ਯਕੀਨ ਦਿਵਾ ਸਕਦਾ ਹਾਂ ਕਿ ਇਹ ਲੋਕ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੇ।

ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਮੰਨਿਆ "ਇੱਕ-ਕਲਿੱਕ" ਤੈਨਾਤੀ ਹੱਲ ਲਵੋ। ਪਰਕੋਨਾ. ਮੈਂ ਗੂਗਲ ਕਲਾਉਡ SQL ਸ਼ੈਨੀਗਨਸ ਦੀ ਮੌਤ ਤੋਂ ਬਿਮਾਰ ਸੀ, ਇਸਲਈ ਮੈਂ ਇੱਕ ਵਿਕਲਪ ਵਜੋਂ ਆਪਣਾ ਪਰਕੋਨਾ ਕਲੱਸਟਰ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਅਤੇ ਇਸ ਵਾਰ ਗੂਗਲ ਨੇ ਇੱਕ ਚੰਗਾ ਕੰਮ ਕੀਤਾ ਜਾਪਦਾ ਸੀ, ਉਹ ਇੱਕ ਬਟਨ ਦੇ ਕਲਿੱਕ ਨਾਲ ਮੇਰਾ ਕੁਝ ਸਮਾਂ ਅਤੇ ਮਿਹਨਤ ਬਚਾਉਣ ਜਾ ਰਹੇ ਸਨ!

ਬਹੁਤ ਵਧੀਆ, ਚਲੋ। ਆਓ ਲਿੰਕ ਦੀ ਪਾਲਣਾ ਕਰੀਏ ਅਤੇ ਇਸ ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰੀਏ। ਸਾਰੀਆਂ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਸੈਟਿੰਗਾਂ ਨਾਲ ਸਹਿਮਤ ਹੋਣ ਲਈ "ਹਾਂ" ਨੂੰ ਚੁਣੋ ਅਤੇ ਆਪਣੇ Google ਕਲਾਉਡ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਕਲੱਸਟਰ ਨੂੰ ਲਾਗੂ ਕਰੋ। ਹਾਹਾ, ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਬਕਵਾਸ ਦਾ ਕੋਈ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ. ਟੂਲ ਦੀ ਕਦੇ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ ਇਹ ਪਹਿਲੇ ਮਿੰਟ ਤੋਂ ਸੜਨਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ ਸੀ, ਅਤੇ ਇਹ ਮੈਨੂੰ ਹੈਰਾਨ ਨਹੀਂ ਕਰੇਗਾ ਜੇਕਰ "ਹੱਲ" ਵਿੱਚੋਂ ਅੱਧੇ ਤੋਂ ਵੱਧ ਇੱਕ-ਕਲਿੱਕ ਤੈਨਾਤੀ ਹਨ (ਹੁਣ ਅਸੀਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਹਵਾਲੇ ਕਿਉਂ ਹਨ) вообще ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਬਿਲਕੁਲ ਨਿਰਾਸ਼ਾਜਨਕ ਹਨੇਰਾ ਹੈ, ਜਿੱਥੇ ਦਾਖਲ ਨਾ ਹੋਣਾ ਬਿਹਤਰ ਹੈ.

ਪਰ ਗੂਗਲ ਸਹੀ ਹੈ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ. ਉਹ ਤੁਹਾਨੂੰ ਚਾਹੁੰਦੇ ਹਨ ਖਰੀਦਿਆ. ਉਹਨਾਂ ਲਈ ਇਹ ਇੱਕ ਲੈਣ-ਦੇਣ ਹੈ। ਉਹ ਕੁਝ ਨਹੀਂ ਚਾਹੁੰਦੇ ਸਹਾਇਤਾ. ਇਹ Google ਦੇ DNA ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹੈ। ਹਾਂ, ਇੰਜੀਨੀਅਰ ਇਕ ਦੂਜੇ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਬਿਗਟੇਬਲ ਨਾਲ ਮੇਰੀ ਕਹਾਣੀ ਦੁਆਰਾ ਸਬੂਤ ਦਿੱਤਾ ਗਿਆ ਹੈ. ਪਰ ਆਮ ਲੋਕਾਂ ਲਈ ਉਤਪਾਦਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਵਿੱਚ ਉਹ ਹਮੇਸ਼ਾ ਵਿੱਚ ਬੇਰਹਿਮ ਸਨ ਕਿਸੇ ਵੀ ਸੇਵਾ ਨੂੰ ਬੰਦ ਕਰਨਾ, ਜੋ ਕਿ ਮੁਨਾਫੇ ਲਈ ਬਾਰ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ ਭਾਵੇਂ ਇਸਦੇ ਲੱਖਾਂ ਉਪਭੋਗਤਾ ਹਨ।

ਅਤੇ ਇਹ ਜੀਸੀਪੀ ਲਈ ਇੱਕ ਅਸਲ ਚੁਣੌਤੀ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਾਰੀਆਂ ਕਲਾਉਡ ਪੇਸ਼ਕਸ਼ਾਂ ਦੇ ਪਿੱਛੇ ਡੀਐਨਏ ਹੈ। ਉਹ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦਾ ਸਮਰਥਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ ਹਨ; ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹ ਕਿਸੇ ਵੀ ਤੀਜੀ ਧਿਰ ਦੇ ਸੌਫਟਵੇਅਰ ਦੀ ਮੇਜ਼ਬਾਨੀ (ਪ੍ਰਬੰਧਿਤ ਸੇਵਾ ਵਜੋਂ) ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰਦੇ ਹਨ ਜਦ ਤੱਕ, ਜਦੋਂ ਤੱਕ AWS ਅਜਿਹਾ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਇਸਦੇ ਆਲੇ ਦੁਆਲੇ ਇੱਕ ਸਫਲ ਕਾਰੋਬਾਰ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਗਾਹਕ ਅਸਲ ਵਿੱਚ ਇਹੀ ਮੰਗ ਕਰਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਗੂਗਲ ਨੂੰ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਕੁਝ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਪੈਂਦੀ ਹੈ.

"ਆਓ ਇਸਨੂੰ ਹੋਰ ਸੁੰਦਰ ਬਣਾਉਣ ਲਈ ਇਸ ਨੂੰ ਤੋੜੀਏ" ਮਾਨਸਿਕਤਾ ਦੇ ਨਾਲ ਸਹਿਯੋਗੀ ਸੱਭਿਆਚਾਰ ਦੀ ਇਹ ਘਾਟ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਦੂਰ ਕਰ ਦਿੰਦੀ ਹੈ।

ਅਤੇ ਇਹ ਚੰਗੀ ਗੱਲ ਨਹੀਂ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਲੰਬੇ ਸਮੇਂ ਲਈ ਪਲੇਟਫਾਰਮ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ।

ਗੂਗਲ, ​​ਜਾਗੋ, ਲਾਹਨਤ। ਇਹ ਹੁਣ 2020 ਹੈ। ਤੁਸੀਂ ਅਜੇ ਵੀ ਹਾਰ ਰਹੇ ਹੋ। ਇਹ ਸ਼ੀਸ਼ੇ ਵਿੱਚ ਸਖ਼ਤ ਨਜ਼ਰ ਮਾਰਨ ਅਤੇ ਜਵਾਬ ਦੇਣ ਦਾ ਸਮਾਂ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕਲਾਉਡ ਕਾਰੋਬਾਰ ਵਿੱਚ ਰਹਿਣਾ ਚਾਹੁੰਦੇ ਹੋ।

ਜੇ ਤੁਸੀਂ ਰਹਿਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਸਭ ਕੁਝ ਤੋੜਨਾ ਬੰਦ ਕਰੋ. ਦੋਸਤੋ, ਤੁਸੀਂ ਅਮੀਰ ਹੋ। ਅਸੀਂ ਡਿਵੈਲਪਰ ਨਹੀਂ ਕਰਦੇ। ਇਸ ਲਈ ਜਦੋਂ ਇਹ ਗੱਲ ਆਉਂਦੀ ਹੈ ਕਿ ਅਨੁਕੂਲਤਾ ਦਾ ਬੋਝ ਕੌਣ ਚੁੱਕੇਗਾ, ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਆਪਣੇ ਉੱਤੇ ਲੈਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਸਾਡੇ ਲਈ ਨਹੀਂ।

ਕਿਉਂਕਿ ਇੱਥੇ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਹੋਰ ਅਸਲ ਚੰਗੇ ਬੱਦਲ ਹਨ। ਉਹ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ।

ਅਤੇ ਹੁਣ ਮੈਂ ਆਪਣੇ ਸਾਰੇ ਟੁੱਟੇ ਹੋਏ ਸਿਸਟਮਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਅੱਗੇ ਵਧਾਂਗਾ। ਏਹ.

ਅਗਲੀ ਵਾਰ ਤੱਕ!

ਇਸ ਲੇਖ 'ਤੇ ਕੁਝ ਵਿਚਾਰ ਵਟਾਂਦਰੇ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਪੀਐਸ ਅਪਡੇਟ (ਚਰਚਾ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਬੀਟੀਡਬਲਯੂ). ਫਾਇਰਬੇਸ ਸਹਾਇਤਾ ਨੂੰ ਬੰਦ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਅਜਿਹੀਆਂ ਕੋਈ ਯੋਜਨਾਵਾਂ ਨਹੀਂ ਹਨ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਮੈਂ ਜਾਣੂ ਹਾਂ। ਹਾਲਾਂਕਿ, ਉਹਨਾਂ ਕੋਲ ਇੱਕ ਗੰਦਾ ਸਟ੍ਰੀਮਿੰਗ ਬੱਗ ਹੈ ਜੋ ਜਾਵਾ ਕਲਾਇੰਟ ਨੂੰ ਐਪ ਇੰਜਨ ਵਿੱਚ ਸਟਾਲ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਦੇ ਇੱਕ ਇੰਜੀਨੀਅਰ ਨੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮੇਰੀ ਮਦਦ ਕੀਤੀ, ਜਦੋਂ ਮੈਂ Google 'ਤੇ ਕੰਮ ਕੀਤਾ, ਪਰ ਉਹਨਾਂ ਨੇ ਅਸਲ ਵਿੱਚ ਕਦੇ ਵੀ ਬੱਗ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕੀਤਾ, ਇਸਲਈ ਮੇਰੇ ਕੋਲ ਹਰ ਰੋਜ਼ GAE ਐਪ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰਨ ਦਾ ਇੱਕ ਖਰਾਬ ਹੱਲ ਹੈ। ਅਤੇ ਇਸ ਲਈ ਇਸ ਨੂੰ ਚਾਰ ਸਾਲ ਲਈ ਕੀਤਾ ਗਿਆ ਹੈ! ਉਹਨਾਂ ਕੋਲ ਹੁਣ ਫਾਇਰਸਟੋਰ ਹੈ। ਇਸ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਲੱਗੇਗਾ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਸਿਸਟਮ ਹੈ ਅਤੇ ਫਾਇਰਬੇਸ ਬੱਗ ਨੂੰ ਕਦੇ ਵੀ ਠੀਕ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ। ਕੀ ਸਿੱਟਾ ਕੱਢਿਆ ਜਾ ਸਕਦਾ ਹੈ? ਤੁਸੀਂ ਮਦਦ ਲੈ ਸਕਦੇ ਹੋ ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਕੰਪਨੀ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹੋ. ਮੈਂ ਸ਼ਾਇਦ GAE 'ਤੇ ਫਾਇਰਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲਾ ਇਕੱਲਾ ਵਿਅਕਤੀ ਹਾਂ ਕਿਉਂਕਿ ਮੈਂ 100% ਮੂਲ ਐਪ ਵਿੱਚ 100 ਤੋਂ ਘੱਟ ਕੁੰਜੀਆਂ ਲੌਗ ਕਰਦਾ ਹਾਂ ਅਤੇ ਇਹ ਕਿਸੇ ਜਾਣੇ-ਪਛਾਣੇ ਬੱਗ ਕਾਰਨ ਹਰ ਦੋ ਦਿਨਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਮੈਂ ਇਸਨੂੰ ਆਪਣੇ ਜੋਖਮ 'ਤੇ ਵਰਤਣ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੀ ਕਹਿ ਸਕਦਾ ਹਾਂ। ਮੈਂ Redis 'ਤੇ ਜਾ ਰਿਹਾ/ਰਹੀ ਹਾਂ।

ਮੈਂ ਕੁਝ ਹੋਰ ਤਜਰਬੇਕਾਰ AWS ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇਹ ਵੀ ਕਿਹਾ ਹੈ ਕਿ AWS ਆਮ ਤੌਰ 'ਤੇ ਕਦੇ ਵੀ ਕਿਸੇ ਸੇਵਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਬੰਦ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ SimpleDB ਇੱਕ ਵਧੀਆ ਉਦਾਹਰਣ ਹੈ. ਮੇਰੀਆਂ ਧਾਰਨਾਵਾਂ ਕਿ AWS ਕੋਲ ਸਹਾਇਤਾ ਦੀ ਬਿਮਾਰੀ ਦਾ ਉਹੀ ਅੰਤ ਨਹੀਂ ਹੈ ਜਿਵੇਂ ਕਿ ਗੂਗਲ ਜਾਇਜ਼ ਜਾਪਦਾ ਹੈ.

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮੈਂ ਦੇਖਿਆ ਕਿ 20 ਦਿਨ ਪਹਿਲਾਂ Google ਐਪ ਇੰਜਨ ਟੀਮ ਨੇ ਇੱਕ ਨਾਜ਼ੁਕ ਗੋ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਮੇਜ਼ਬਾਨੀ ਨੂੰ ਤੋੜ ਦਿੱਤਾ ਸੀ, ਇੱਕ ਕੋਰ ਗੋ ਡਿਵੈਲਪਰਾਂ ਵਿੱਚੋਂ ਇੱਕ GAE ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਬੰਦ ਕਰ ਦਿੱਤਾ ਸੀ। ਇਹ ਅਸਲ ਵਿੱਚ ਮੂਰਖ ਸੀ.

ਅੰਤ ਵਿੱਚ, ਮੈਂ Googlers ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਇਸ ਮੁੱਦੇ 'ਤੇ ਚਰਚਾ ਕਰਦੇ ਹੋਏ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਮੇਰੇ ਨਾਲ ਸਹਿਮਤ ਹੁੰਦੇ ਸੁਣਿਆ ਹੈ (ਤੁਹਾਨੂੰ ਲੋਕ ਪਿਆਰ ਕਰਦੇ ਹਨ!)। ਪਰ ਉਹ ਸੋਚਦੇ ਹਨ ਕਿ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਗੂਗਲ ਦੇ ਸੱਭਿਆਚਾਰ ਵਿੱਚ ਕਦੇ ਵੀ ਸਹੀ ਪ੍ਰੋਤਸਾਹਨ ਢਾਂਚਾ ਨਹੀਂ ਸੀ। ਮੈਂ ਸੋਚਿਆ ਕਿ ਗ੍ਰੈਬ 'ਤੇ ਕੰਮ ਕਰਦੇ ਸਮੇਂ AWS ਇੰਜੀਨੀਅਰਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਬਿਲਕੁਲ ਅਦਭੁਤ ਅਨੁਭਵ ਬਾਰੇ ਚਰਚਾ ਕਰਨ ਲਈ ਕੁਝ ਸਮਾਂ ਲੈਣਾ ਚੰਗਾ ਹੋਵੇਗਾ। ਭਵਿੱਖ ਵਿੱਚ ਕਿਸੇ ਦਿਨ, ਮੈਨੂੰ ਉਮੀਦ ਹੈ!

ਅਤੇ ਹਾਂ, 2005 ਵਿੱਚ ਉਨ੍ਹਾਂ ਕੋਲ ਬਿਲਡਿੰਗ 43 ਵਿੱਚ ਵਿਸ਼ਾਲ ਬੁਫੇ 'ਤੇ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਸ਼ਾਰਕ ਮੀਟ ਸਨ, ਅਤੇ ਮੇਰਾ ਮਨਪਸੰਦ ਹੈਮਰਹੈੱਡ ਸ਼ਾਰਕ ਮੀਟ ਸੀ। ਹਾਲਾਂਕਿ, 2006 ਤੱਕ, ਲੈਰੀ ਅਤੇ ਸਰਗੇਈ ਨੇ ਸਾਰੇ ਗੈਰ-ਸਿਹਤਮੰਦ ਸਨੈਕਸਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾ ਲਿਆ। ਇਸ ਲਈ 2007 ਵਿੱਚ ਬਿਗਟੇਬਲ ਕਹਾਣੀ ਦੇ ਦੌਰਾਨ ਅਸਲ ਵਿੱਚ ਕੋਈ ਸ਼ਾਰਕ ਨਹੀਂ ਸਨ ਅਤੇ ਮੈਂ ਤੁਹਾਨੂੰ ਧੋਖਾ ਦਿੱਤਾ.

ਜਦੋਂ ਮੈਂ ਚਾਰ ਸਾਲ ਪਹਿਲਾਂ ਕਲਾਉਡ ਬਿਗਟੇਬਲ ਨੂੰ ਦੇਖਿਆ (ਦੇਵੋ ਜਾਂ ਲਓ), ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਲਾਗਤ ਸੀ. ਇਹ ਹੁਣ ਥੋੜਾ ਘਟਿਆ ਜਾਪਦਾ ਹੈ, ਪਰ ਇਹ ਖਾਲੀ ਡੇਟਾ ਵੇਅਰਹਾਊਸ ਲਈ ਅਜੇ ਵੀ ਬਹੁਤ ਭਿਆਨਕ ਹੈ, ਖ਼ਾਸਕਰ ਕਿਉਂਕਿ ਮੇਰੀ ਪਹਿਲੀ ਕਹਾਣੀ ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਇੱਕ ਖਾਲੀ ਵੱਡੀ ਟੇਬਲ ਉਨ੍ਹਾਂ ਦੇ ਪੈਮਾਨੇ 'ਤੇ ਕਿੰਨੀ ਬੇਲੋੜੀ ਹੈ।

ਐਪਲ ਕਮਿਊਨਿਟੀ ਨੂੰ ਠੇਸ ਪਹੁੰਚਾਉਣ ਅਤੇ ਮਾਈਕ੍ਰੋਸੌਫਟ ਆਦਿ ਬਾਰੇ ਕੁਝ ਵੀ ਚੰਗਾ ਨਾ ਕਹਿਣ ਲਈ ਮੁਆਫੀ। ਤੁਸੀਂ ਠੀਕ ਹੋ, ਮੈਂ ਇਸ ਲੇਖ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀ ਗਈ ਸਾਰੀ ਚਰਚਾ ਦੀ ਸੱਚਮੁੱਚ ਪ੍ਰਸ਼ੰਸਾ ਕਰਦਾ ਹਾਂ! ਪਰ ਕਦੇ-ਕਦੇ ਤੁਹਾਨੂੰ ਚਰਚਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਥੋੜਾ ਜਿਹਾ ਲਹਿਰਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ?

ਪੜ੍ਹਨ ਲਈ ਧੰਨਵਾਦ।

ਅੱਪਡੇਟ 2, 19.08.2020/XNUMX/XNUMX। ਧਾਰੀ API ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ!

ਅੱਪਡੇਟ 3, 31.08.2020/2/2। ਮੇਰੇ ਨਾਲ ਕਲਾਉਡ ਮਾਰਕਿਟਪਲੇਸ 'ਤੇ ਇੱਕ Google ਇੰਜੀਨੀਅਰ ਦੁਆਰਾ ਸੰਪਰਕ ਕੀਤਾ ਗਿਆ ਸੀ ਜੋ ਮੇਰਾ ਪੁਰਾਣਾ ਦੋਸਤ ਨਿਕਲਿਆ। ਉਹ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ ਕਿ CXNUMXD ਕੰਮ ਕਿਉਂ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ, ਅਤੇ ਅਸੀਂ ਆਖਰਕਾਰ ਇਹ ਸਮਝ ਲਿਆ ਕਿ ਇਹ ਇਸ ਲਈ ਸੀ ਕਿਉਂਕਿ ਮੈਂ ਆਪਣਾ ਨੈੱਟਵਰਕ ਕਈ ਸਾਲ ਪਹਿਲਾਂ ਬਣਾਇਆ ਸੀ, ਅਤੇ CXNUMXD ਪੁਰਾਤਨ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ ਕਿਉਂਕਿ ਸਬਨੈੱਟ ਪੈਰਾਮੀਟਰ ਉਹਨਾਂ ਦੇ ਟੈਂਪਲੇਟਾਂ ਵਿੱਚ ਗੁੰਮ ਸੀ। ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਸੰਭਾਵੀ GCP ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਕਿ ਉਹ Google 'ਤੇ ਲੋੜੀਂਦੇ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਜਾਣਦੇ ਹਨ...

ਸਰੋਤ: www.habr.com