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

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

• ਨਿਕੋਲੇ ਮੋਲਚਨੋਵ - JUG Ru ਗਰੁੱਪ ਦੇ ਤਕਨੀਕੀ ਨਿਰਦੇਸ਼ਕ;
• ਵਲਾਦੀਮੀਰ ਕ੍ਰਾਸਿਲਸ਼ਚਿਕ ਇੱਕ ਵਿਹਾਰਕ ਜਾਵਾ ਪ੍ਰੋਗਰਾਮਰ ਹੈ ਜੋ ਬੈਕਐਂਡ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ (ਤੁਸੀਂ ਸਾਡੀਆਂ ਜਾਵਾ ਕਾਨਫਰੰਸਾਂ ਵਿੱਚ ਉਸਦੀਆਂ ਰਿਪੋਰਟਾਂ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ);
• Artyom Nikonov ਸਾਡੀ ਸਾਰੀ ਵੀਡੀਓ ਸਟ੍ਰੀਮਿੰਗ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।

ਤਰੀਕੇ ਨਾਲ, ਪਤਝੜ-ਸਰਦੀਆਂ ਦੀਆਂ ਕਾਨਫਰੰਸਾਂ ਵਿੱਚ ਅਸੀਂ ਉਸੇ ਪਲੇਟਫਾਰਮ ਦੇ ਇੱਕ ਸੁਧਰੇ ਹੋਏ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ - ਇਸ ਲਈ ਬਹੁਤ ਸਾਰੇ ਹਾਬਰਾ ਪਾਠਕ ਅਜੇ ਵੀ ਇਸਦੇ ਉਪਭੋਗਤਾ ਹੋਣਗੇ.

ਵੱਡੀ ਤਸਵੀਰ

- ਟੀਮ ਦੀ ਰਚਨਾ ਕੀ ਸੀ?

ਨਿਕੋਲੇ ਮੋਲਚਾਨੋਵ: ਸਾਡੇ ਕੋਲ ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਕ, ਇੱਕ ਡਿਜ਼ਾਈਨਰ, ਇੱਕ ਟੈਸਟਰ, ਤਿੰਨ ਫਰੰਟ-ਐਂਡਰ, ਅਤੇ ਇੱਕ ਬੈਕ-ਐਂਡ ਹੈ। ਅਤੇ, ਬੇਸ਼ਕ, ਇੱਕ ਟੀ-ਆਕਾਰ ਦਾ ਮਾਹਰ!

- ਪ੍ਰਕਿਰਿਆ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀ ਦਿਖਾਈ ਦਿੰਦੀ ਸੀ?

ਨਿਕੋਲਯ: ਮਾਰਚ ਦੇ ਅੱਧ ਤੱਕ, ਸਾਡੇ ਕੋਲ ਔਨਲਾਈਨ ਲਈ ਬਿਲਕੁਲ ਵੀ ਤਿਆਰ ਨਹੀਂ ਸੀ। ਅਤੇ 15 ਮਾਰਚ ਨੂੰ, ਪੂਰਾ ਔਨਲਾਈਨ ਕੈਰੋਸਲ ਸਪਿਨ ਕਰਨਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ। ਅਸੀਂ ਕਈ ਰਿਪੋਜ਼ਟਰੀਆਂ ਸਥਾਪਤ ਕੀਤੀਆਂ, ਯੋਜਨਾ ਬਣਾਈ, ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਬਾਰੇ ਚਰਚਾ ਕੀਤੀ ਅਤੇ ਤਿੰਨ ਮਹੀਨਿਆਂ ਵਿੱਚ ਸਭ ਕੁਝ ਕੀਤਾ।

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

- ਕੀ ਅਸੀਂ ਉਸ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦਾ ਪ੍ਰਬੰਧ ਕੀਤਾ ਜਿਸ ਲਈ ਅਸੀਂ ਵਚਨਬੱਧ ਸੀ?

ਨਿਕੋਲਯ: ਕਿਉਂਕਿ ਅਸੀਂ ਹੁਣ DevOops ਕਾਨਫਰੰਸ ਵਿੱਚ ਔਨਲਾਈਨ ਹਿੱਸਾ ਲੈ ਰਹੇ ਹਾਂ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ। ਮੈਂ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਮੁੱਖ ਗੱਲ ਲਈ ਵਚਨਬੱਧ ਹਾਂ: ਮੈਂ ਗਾਹਕਾਂ ਨੂੰ ਇੱਕ ਸਾਧਨ ਲਿਆਵਾਂਗਾ ਜਿਸ ਨਾਲ ਉਹ ਇੱਕ ਔਨਲਾਈਨ ਕਾਨਫਰੰਸ ਕਰ ਸਕਦੇ ਹਨ.

ਚੁਣੌਤੀ ਇਹ ਸੀ: ਸਾਨੂੰ ਇੱਕ ਸਾਧਨ ਦਿਓ ਜਿਸ ਨਾਲ ਅਸੀਂ ਟਿਕਟ ਧਾਰਕਾਂ ਨੂੰ ਆਪਣੀਆਂ ਕਾਨਫਰੰਸਾਂ ਦਾ ਪ੍ਰਸਾਰਣ ਕਰ ਸਕੀਏ।

ਸਾਰੀ ਯੋਜਨਾਬੰਦੀ ਨੂੰ ਕਈ ਪੜਾਵਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (ਲਗਭਗ 30 ਗਲੋਬਲ) ਨੂੰ 4 ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਸੀ:

• ਜੋ ਅਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕਰਾਂਗੇ (ਅਸੀਂ ਉਨ੍ਹਾਂ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਰਹਿ ਸਕਦੇ),
• ਜੋ ਅਸੀਂ ਦੂਜਾ ਕਰਾਂਗੇ,
• ਜੋ ਅਸੀਂ ਕਦੇ ਨਹੀਂ ਕਰਾਂਗੇ,
• ਅਤੇ ਜੋ ਅਸੀਂ ਕਦੇ ਨਹੀਂ ਕਰਾਂਗੇ।

ਅਸੀਂ ਪਹਿਲੀਆਂ ਦੋ ਸ਼੍ਰੇਣੀਆਂ ਤੋਂ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਣਾਈਆਂ ਹਨ।

— ਮੈਨੂੰ ਪਤਾ ਹੈ ਕਿ ਕੁੱਲ 600 JIRA ਮੁੱਦੇ ਬਣਾਏ ਗਏ ਸਨ। ਤਿੰਨ ਮਹੀਨਿਆਂ ਵਿੱਚ, ਤੁਸੀਂ 13 ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਬਣਾਏ, ਅਤੇ ਮੈਨੂੰ ਸ਼ੱਕ ਹੈ ਕਿ ਉਹ ਨਾ ਸਿਰਫ਼ ਜਾਵਾ ਵਿੱਚ ਲਿਖੇ ਗਏ ਸਨ. ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਐਮਾਜ਼ਾਨ ਵਿੱਚ ਤਿੰਨ ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਅਤੇ 5 RTMP ਸਟ੍ਰੀਮਾਂ ਵਿੱਚ ਦੋ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਹਨ।

ਆਉ ਹੁਣ ਸਿਸਟਮ ਦੇ ਹਰੇਕ ਹਿੱਸੇ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵੇਖੀਏ।

ਸਟ੍ਰੀਮਿੰਗ

- ਆਓ ਉਦੋਂ ਸ਼ੁਰੂ ਕਰੀਏ ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਵੀਡੀਓ ਚਿੱਤਰ ਹੈ, ਅਤੇ ਇਹ ਕੁਝ ਸੇਵਾਵਾਂ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਆਰਟਿਓਮ, ਸਾਨੂੰ ਦੱਸੋ ਕਿ ਇਹ ਸਟ੍ਰੀਮਿੰਗ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ?

ਆਰਟਿਓਮ ਨਿਕੋਨੋਵ: ਸਾਡੀ ਆਮ ਸਕੀਮ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ: ਕੈਮਰੇ ਤੋਂ ਚਿੱਤਰ -> ਸਾਡੇ ਕੰਟਰੋਲ ਰੂਮ -> ਸਥਾਨਕ RTMP ਸਰਵਰ -> Amazon -> ਵੀਡੀਓ ਪਲੇਅਰ। ਹੋਰ ਜਾਣਕਾਰੀ ਇਸ ਬਾਰੇ ਲਿਖਿਆ ਜੂਨ ਵਿੱਚ ਹਾਬਰੇ 'ਤੇ.

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

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

ਇਹਨਾਂ ਡਿਵਾਈਸਾਂ ਤੋਂ ਸਿਗਨਲ ਕੈਪਚਰ ਕਾਰਡਾਂ, ਇਨਪੁਟ/ਆਊਟਪੁੱਟ ਕਾਰਡਾਂ, ਅਤੇ ਸਾਊਂਡ ਕਾਰਡਾਂ ਨਾਲ ਕੰਪਿਊਟਰਾਂ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੇ ਹਨ। ਉੱਥੇ ਸਿਗਨਲ ਮਿਲਾਏ ਜਾਂਦੇ ਹਨ ਅਤੇ ਲੇਆਉਟ ਵਿੱਚ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ:

4 ਸਪੀਕਰਾਂ ਲਈ ਲੇਆਉਟ ਦੀ ਉਦਾਹਰਨ

4 ਸਪੀਕਰਾਂ ਲਈ ਲੇਆਉਟ ਦੀ ਉਦਾਹਰਨ

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

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

ਅੱਗੇ, ਕੰਪਿਊਟਰਾਂ ਤੋਂ ਸਟ੍ਰੀਮਾਂ ਇੱਕ ਸਥਾਨਕ ਸਰਵਰ 'ਤੇ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਦੇ ਦੋ ਕੰਮ ਹਨ: RTMP ਸਟ੍ਰੀਮ ਨੂੰ ਰੂਟ ਕਰਨਾ ਅਤੇ ਰਿਕਾਰਡ ਬੈਕਅੱਪ। ਇਸ ਲਈ ਸਾਡੇ ਕੋਲ ਕਈ ਰਿਕਾਰਡਿੰਗ ਪੁਆਇੰਟ ਹਨ। ਵੀਡੀਓ ਸਟ੍ਰੀਮਾਂ ਨੂੰ ਫਿਰ Amazon SaaS ਸੇਵਾਵਾਂ 'ਤੇ ਬਣੇ ਸਾਡੇ ਸਿਸਟਮ ਦੇ ਹਿੱਸੇ ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਅਸੀਂ ਵਰਤਦੇ ਹਾਂ ਮੀਡੀਆਲਾਈਵ, S3, ਕਲਾਉਡਫਰੰਟ।

ਨਿਕੋਲਯ: ਵੀਡੀਓ ਦੇ ਦਰਸ਼ਕਾਂ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਉੱਥੇ ਕੀ ਹੁੰਦਾ ਹੈ? ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਕੱਟਣਾ ਪਏਗਾ, ਠੀਕ ਹੈ?

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

- ਕੀ ਅਸੀਂ 1080p ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਾਂ?

ਆਰਟਿਓਮ: ਸਾਡੇ ਵੀਡੀਓ ਦੀ ਚੌੜਾਈ 1080p - 1920 ਪਿਕਸਲ ਦੇ ਬਰਾਬਰ ਹੈ, ਅਤੇ ਉਚਾਈ ਥੋੜੀ ਘੱਟ ਹੈ, ਤਸਵੀਰ ਜ਼ਿਆਦਾ ਲੰਬੀ ਹੈ - ਇਸਦੇ ਕੁਝ ਕਾਰਨ ਹਨ।

ਖਿਡਾਰੀ

- ਆਰਟਿਓਮ ਨੇ ਦੱਸਿਆ ਕਿ ਵੀਡੀਓ ਕਿਵੇਂ ਸਟ੍ਰੀਮ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਕਿਵੇਂ ਇਸਨੂੰ ਵੱਖ-ਵੱਖ ਸਕ੍ਰੀਨ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਲਈ ਵੱਖ-ਵੱਖ ਪਲੇਲਿਸਟਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਟੁਕੜਿਆਂ ਵਿੱਚ ਕੱਟਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪਲੇਅਰ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਕੋਲਿਆ, ਹੁਣ ਮੈਨੂੰ ਦੱਸੋ ਕਿ ਇਹ ਕਿਸ ਤਰ੍ਹਾਂ ਦਾ ਖਿਡਾਰੀ ਹੈ, ਇਹ ਸਟ੍ਰੀਮ ਨੂੰ ਕਿਵੇਂ ਖਪਤ ਕਰਦਾ ਹੈ, ਕਿਉਂ HLS?

ਨਿਕੋਲਯ: ਸਾਡੇ ਕੋਲ ਇੱਕ ਖਿਡਾਰੀ ਹੈ ਜਿਸਨੂੰ ਸਾਰੇ ਕਾਨਫਰੰਸ ਦਰਸ਼ਕ ਦੇਖ ਸਕਦੇ ਹਨ।

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

ਇਹ ਰੂਟ ਕਾਰਜਕੁਸ਼ਲਤਾ ਹੈ, ਇਸਲਈ ਇਸਨੂੰ ਲਗਭਗ ਪਹਿਲਾਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਤੇ ਫਿਰ ਸਭ ਕੁਝ ਇਸਦੇ ਆਲੇ ਦੁਆਲੇ ਵਧਿਆ.

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

ਟਾਈਮਲਾਈਨ ਉਦਾਹਰਨ

- ਸਾਰੀਆਂ ਰਿਪੋਰਟਾਂ ਦੀ ਟਾਈਮਲਾਈਨ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਪਲੇਅਰ ਵਿੱਚ ਇੱਕ ਬਟਨ ਬਣਾਇਆ ਗਿਆ ਹੈ...

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

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

- ਕੀ ਇਸ ਵਿੱਚ ਕੋਈ ਤਕਨੀਕੀ ਮੁਸ਼ਕਲ ਸੀ?

ਨਿਕੋਲਯ: ਉਹਨਾਂ ਕੋਲ ਇੱਕ ਸਕ੍ਰੋਲ ਬਾਰ ਸੀ ਜਿਸ ਉੱਤੇ ਵੱਖ-ਵੱਖ ਰਿਪੋਰਟਾਂ ਦੇ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂਆਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਸੀ।

- ਅੰਤ ਵਿੱਚ, ਕੀ ਤੁਸੀਂ YouTube ਦੁਆਰਾ ਅਜਿਹਾ ਕੁਝ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਕ੍ਰੋਲ ਬਾਰ 'ਤੇ ਇਹਨਾਂ ਚਿੰਨ੍ਹਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਸੀ?

ਆਰਟਿਓਮ: ਉਹਨਾਂ ਕੋਲ ਇਹ ਉਦੋਂ ਬੀਟਾ ਵਿੱਚ ਸੀ। ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਗੁੰਝਲਦਾਰ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਪਿਛਲੇ ਸਾਲ ਤੋਂ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨਾਲ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਇਸਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹਨ. ਅਤੇ ਹੁਣ ਇਹ ਵਿਕਰੀ ਤੱਕ ਪਹੁੰਚ ਗਿਆ ਹੈ.

ਨਿਕੋਲਯ: ਪਰ ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵੇਚਣ ਲਈ ਪ੍ਰਾਪਤ ਕੀਤਾ. ਇਮਾਨਦਾਰੀ ਨਾਲ, ਇਸ ਸਧਾਰਨ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਪਿੱਛੇ ਪਲੇਅਰ ਦੇ ਅੰਦਰ ਬੈਕਐਂਡ, ਫਰੰਟਐਂਡ, ਗਣਨਾ ਅਤੇ ਗਣਿਤ ਦੀ ਇੱਕ ਵੱਡੀ ਮਾਤਰਾ ਹੈ.

ਅਗਰਾਂਤ

— ਆਓ ਇਹ ਪਤਾ ਕਰੀਏ ਕਿ ਇਹ ਸਮਗਰੀ ਜੋ ਅਸੀਂ ਦਿਖਾਉਂਦੇ ਹਾਂ (ਸਪੀਚ ਕਾਰਡ, ਸਪੀਕਰ, ਵੈਬਸਾਈਟ, ਸਮਾਂ-ਸਾਰਣੀ) ਸਾਹਮਣੇ ਵਾਲੇ ਸਿਰੇ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦੀ ਹੈ?

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

ਇਸ ਤਰ੍ਹਾਂ ਸਪੀਕਰ ਪਾਈਪਲਾਈਨ ਨੂੰ ਵੇਖਦਾ ਹੈ

ਇਹ ਪ੍ਰਣਾਲੀ ਸਾਡਾ ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਹੈ।

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

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

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

ਨਿਕੋਲਯ: ਇੱਥੇ ਇਹ ਸਪੱਸ਼ਟ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਸਾਡੀ ਸਾਈਟ ਇੱਕ ਕਲਾਸਿਕ SPA ਐਪਲੀਕੇਸ਼ਨ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਖਾਕਾ-ਆਧਾਰਿਤ, ਰੈਂਡਰਡ ਵੈੱਬਸਾਈਟ ਅਤੇ ਇੱਕ SPA ਦੋਵੇਂ ਹੈ। ਗੂਗਲ ਅਸਲ ਵਿੱਚ ਇਸ ਸਾਈਟ ਨੂੰ ਰੈਂਡਰਡ HTML ਦੇ ਰੂਪ ਵਿੱਚ ਵੇਖਦਾ ਹੈ. ਇਹ ਐਸਈਓ ਲਈ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਸਮੱਗਰੀ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਚੰਗਾ ਹੈ. ਇਹ ਪੰਨੇ ਨੂੰ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ 1,5 ਮੈਗਾਬਾਈਟ JavaScript ਲੋਡ ਹੋਣ ਦਾ ਇੰਤਜ਼ਾਰ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਰੈਂਡਰ ਕੀਤੇ ਪੰਨੇ ਨੂੰ ਤੁਰੰਤ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਵੀ ਤੁਸੀਂ ਰਿਪੋਰਟ ਬਦਲਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ। ਹਰ ਚੀਜ਼ ਅੱਧੇ ਸਕਿੰਟ ਵਿੱਚ ਵਾਪਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਸਮੱਗਰੀ ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਹੈ ਅਤੇ ਸਹੀ ਥਾਂ 'ਤੇ ਪੋਸਟ ਕੀਤੀ ਗਈ ਹੈ।

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

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

- ਫਿਰ ਇਹ ਸਭ ਬੈਕਐਂਡ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਲੇਅਰ ਵਿੱਚ ਜਾਂਦਾ ਹੈ। ਸਾਡੇ ਪਲੇਅਰ ਵਿੱਚ TypeScript, React, Next.JS ਹੈ। ਅਤੇ ਬੈਕਐਂਡ 'ਤੇ ਸਾਡੇ ਕੋਲ C#, Java, Spring Boot ਅਤੇ Node.js ਵਿੱਚ ਕਈ ਸੇਵਾਵਾਂ ਹਨ। ਇਹ ਸਭ Yandex.Cloud ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਕੇ Kubernetes ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੈਨਾਤ ਕੀਤਾ ਗਿਆ ਹੈ।

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

ਵਪਾਰਕ ਪਾਬੰਦੀਆਂ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ

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

ਨਿਕੋਲਯ: ਸ਼ੁਰੂ ਵਿੱਚ, ਅਸੀਂ ਵੀਡੀਓ ਲੋੜਾਂ ਤੋਂ ਸ਼ੁਰੂਆਤ ਕੀਤੀ। ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਗਾਹਕ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਡਿਲੀਵਰੀ ਲਈ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਵਿਡੀਓ ਸਟੋਰੇਜ ਵੰਡੀ ਗਈ ਹੈ. ਹੋਰਾਂ ਵਿੱਚ 1080p ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਦੇ ਨਾਲ-ਨਾਲ ਰੀਵਾਈਂਡ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਜਿਸ ਨੂੰ ਕਈ ਹੋਰ ਲਾਈਵ ਮੋਡ ਵਿੱਚ ਲਾਗੂ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਬਾਅਦ ਵਿੱਚ ਅਸੀਂ 2x ਸਪੀਡ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਜੋੜਿਆ, ਇਸਦੀ ਮਦਦ ਨਾਲ ਤੁਸੀਂ ਲਾਈਵ ਦੇ ਨਾਲ "ਕੈਚ ਅੱਪ" ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਕਾਨਫਰੰਸ ਦੇਖਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ। ਅਤੇ ਰਸਤੇ ਵਿੱਚ, ਟਾਈਮਲਾਈਨ ਮਾਰਕਿੰਗ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦਿਖਾਈ ਦਿੱਤੀ। ਨਾਲ ਹੀ, ਸਾਨੂੰ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਹੋਣਾ ਪਿਆ ਅਤੇ 10 ਕੁਨੈਕਸ਼ਨਾਂ ਦੇ ਲੋਡ ਦਾ ਸਾਮ੍ਹਣਾ ਕਰਨਾ ਪਿਆ। ਬੈਕਐਂਡ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਲਗਭਗ 000 ਕੁਨੈਕਸ਼ਨ ਹਨ ਜੋ ਹਰੇਕ ਪੰਨੇ ਨੂੰ ਤਾਜ਼ਾ ਕਰਨ ਲਈ 10 ਬੇਨਤੀਆਂ ਨਾਲ ਗੁਣਾ ਕਰਦੇ ਹਨ। ਅਤੇ ਇਹ ਪਹਿਲਾਂ ਹੀ 000 RPS/sec. ਕਾਫ਼ੀ ਦਾ ਇੱਕ ਬਿੱਟ.

— ਕੀ ਭਾਈਵਾਲਾਂ ਦੇ ਔਨਲਾਈਨ ਸਟੈਂਡਾਂ ਦੇ ਨਾਲ "ਵਰਚੁਅਲ ਪ੍ਰਦਰਸ਼ਨੀ" ਲਈ ਕੋਈ ਹੋਰ ਲੋੜਾਂ ਸਨ?

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

- ਅਸਲ-ਸਮੇਂ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਅਤੇ ਅੰਕੜਿਆਂ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਵੀ ਲੋੜਾਂ ਸਨ। ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਅਸੀਂ ਇਸਦੇ ਲਈ ਪ੍ਰੋਮੀਥੀਅਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਪਰ ਸਾਨੂੰ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸੋ: ਅਸੀਂ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਕਿਹੜੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇਹ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ?

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

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

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

ਧੋਖਾਧੜੀ

- ਕੀ ਸਾਡੇ ਕੋਲ ਧੋਖਾਧੜੀ ਵਿਰੋਧੀ ਵਿਧੀ ਹੈ?

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

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

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

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

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

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

ਵਲਾਦੀਮੀਰ: ਇੱਕ ਪਾਸੇ, ਅਸੀਂ ਇਸਨੂੰ ਹੋਰ OLAP ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਡਾਊਨਲੋਡ ਕਰਦੇ ਹਾਂ। ਅਤੇ OLTP ਲਈ, ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਮੀਥੀਅਸ, ਗ੍ਰਾਫਾਨਾ ਲਈ ਪੂਰੀ ਚੀਜ਼ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਦੀ ਹੈ ਅਤੇ ਗ੍ਰਾਫ ਵੀ ਇਕਸਾਰ ਹੋ ਜਾਂਦੇ ਹਨ!

- ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਗ੍ਰਾਫ ਇਕਸਾਰ ਹੁੰਦੇ ਹਨ।

ਗਤੀਸ਼ੀਲ ਤਬਦੀਲੀਆਂ

— ਸਾਨੂੰ ਦੱਸੋ ਕਿ ਗਤੀਸ਼ੀਲ ਤਬਦੀਲੀਆਂ ਕਿਵੇਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: ਜੇਕਰ ਰਿਪੋਰਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ 6 ਮਿੰਟ ਪਹਿਲਾਂ ਰੱਦ ਕਰ ਦਿੱਤੀ ਗਈ ਸੀ, ਤਾਂ ਕਾਰਵਾਈਆਂ ਦੀ ਲੜੀ ਕੀ ਹੈ? ਕਿਹੜੀ ਪਾਈਪਲਾਈਨ ਕੰਮ ਕਰਦੀ ਹੈ?

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

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

ਨਿਕੋਲਯ: ਪੰਨੇ ਨੂੰ ਤਾਜ਼ਾ ਕੀਤੇ ਬਿਨਾਂ ਸਭ ਕੁਝ ਵਾਪਰਦਾ ਹੈ। ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਕਲਾਇੰਟ ਲਈ ਬਿਲਕੁਲ ਨਿਰਵਿਘਨ ਹੁੰਦੀਆਂ ਹਨ। ਰਿਪੋਰਟਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਵੀ ਇਹੀ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਸਮਾਂ ਆਉਂਦਾ ਹੈ, ਰਿਪੋਰਟ ਅਤੇ ਇੰਟਰਫੇਸ ਬਦਲ ਜਾਂਦੇ ਹਨ.

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

ਤੈਨਾਤੀ

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

ਨਿਕੋਲਯ: ਤਕਨੀਕੀ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਸਾਡੇ ਕੋਲ ਸ਼ੁਰੂ ਵਿੱਚ ਕਿਸੇ ਵੀ ਵਿਕਰੇਤਾ ਤੋਂ ਉਤਪਾਦ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸੰਖੇਪ ਹੋਣ ਦੀ ਲੋੜ ਸੀ। ਖਾਸ ਤੌਰ 'ਤੇ AWS ਤੋਂ, ਜਾਂ ਖਾਸ ਤੌਰ 'ਤੇ Yandex, ਜਾਂ Azure, ਆਦਿ ਤੋਂ Terraform ਸਕ੍ਰਿਪਟਾਂ ਬਣਾਉਣ ਲਈ AWS 'ਤੇ ਆਓ। ਅਸਲ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਸੀ. ਸਾਨੂੰ ਕਿਸੇ ਸਮੇਂ ਕਿਤੇ ਜਾਣਾ ਪੈਂਦਾ ਸੀ।

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

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

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

ਟੈਸਟਾਂ ਬਾਰੇ

- ਤੁਸੀਂ ਲਗਭਗ ਹਰ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹੋ, ਇਹ ਵਿਸ਼ਵਾਸ ਕਰਨਾ ਔਖਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਭ ਕੁਝ ਕਿਵੇਂ ਲਿਖਿਆ ਹੈ। ਕੀ ਤੁਸੀਂ ਸਾਨੂੰ ਬੈਕਐਂਡ ਟੈਸਟਾਂ ਬਾਰੇ ਦੱਸ ਸਕਦੇ ਹੋ: ਹਰ ਚੀਜ਼ ਕਿੰਨੀ ਕੁ ਕਵਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਕਿਹੜੇ ਟੈਸਟ?

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

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

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

ਨਿਕੋਲਯ: ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ, ਕਿਸੇ ਫੰਕਸ਼ਨ ਨੂੰ ਬਦਲਣ ਵੇਲੇ ਪੂਰੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਰਿਗਰੈਸ਼ਨ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਦੋ ਦਿਨਾਂ ਲਈ ਹਰ ਜਗ੍ਹਾ ਬੈਠਣ ਅਤੇ ਪੋਕ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ।

ਵਲਾਦੀਮੀਰ: ਇਸ ਲਈ, ਇਹ ਇੱਕ ਬਹੁਤ ਵੱਡੀ ਸਫਲਤਾ ਹੈ ਕਿ ਜਦੋਂ ਮੈਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਂਦਾ ਹਾਂ, ਮੈਂ ਕਹਿੰਦਾ ਹਾਂ ਕਿ ਮੈਨੂੰ ਦੋ ਸਧਾਰਨ ਪੈਨ ਅਤੇ 4 ਵੈਬਸਾਕੇਟ ਲਈ 1 ਦਿਨ ਦੀ ਲੋੜ ਹੈ, ਕੋਲਿਆ ਇਸਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ. ਉਹ ਪਹਿਲਾਂ ਹੀ ਇਸ ਤੱਥ ਦਾ ਆਦੀ ਹੈ ਕਿ ਇਹਨਾਂ 4 ਦਿਨਾਂ ਵਿੱਚ 2 ਕਿਸਮਾਂ ਦੇ ਟੈਸਟ ਸ਼ਾਮਲ ਹਨ, ਅਤੇ ਫਿਰ, ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਇਹ ਕੰਮ ਕਰੇਗਾ.

ਨਿਕੋਲਯ: ਮੇਰੇ ਕੋਲ 140 ਟੈਸਟ ਵੀ ਲਿਖੇ ਹੋਏ ਹਨ: ਕੰਪੋਨੈਂਟ + ਫੰਕਸ਼ਨਲ, ਜੋ ਉਹੀ ਕੰਮ ਕਰਦੇ ਹਨ। ਉਤਪਾਦਨ ਵਿੱਚ, ਟੈਸਟ ਵਿੱਚ, ਅਤੇ ਉਤਪਾਦਨ ਵਿੱਚ ਸਾਰੇ ਇੱਕੋ ਜਿਹੇ ਦ੍ਰਿਸ਼ਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਅਸੀਂ ਹਾਲ ਹੀ ਵਿੱਚ ਕਾਰਜਸ਼ੀਲ ਬੁਨਿਆਦੀ UI ਟੈਸਟ ਵੀ ਸ਼ਾਮਲ ਕੀਤੇ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਸਭ ਤੋਂ ਬੁਨਿਆਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਾਂ ਜੋ ਵੱਖ ਹੋ ਸਕਦੀ ਹੈ।

ਵਲਾਦੀਮੀਰ: ਬੇਸ਼ਕ, ਇਹ ਲੋਡ ਟੈਸਟਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨ ਯੋਗ ਹੈ. ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਸਭ ਕੁਝ ਕਿਵੇਂ ਹੈ, ਰੈਬਿਟ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਜੇਵੀਐਮਜ਼ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਅਸਲ ਵਿੱਚ ਕਿੰਨੀ ਮੈਮੋਰੀ ਦੀ ਲੋੜ ਹੈ, ਇਹ ਸਮਝਣ ਲਈ ਪਲੇਟਫਾਰਮ ਨੂੰ ਅਸਲ ਦੇ ਨੇੜੇ ਇੱਕ ਲੋਡ ਦੇ ਹੇਠਾਂ ਟੈਸਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ।

- ਮੈਨੂੰ ਪੱਕਾ ਪਤਾ ਨਹੀਂ ਹੈ ਕਿ ਅਸੀਂ ਸਟ੍ਰੀਮ ਸਾਈਡ 'ਤੇ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹਾਂ, ਪਰ ਮੈਨੂੰ ਯਾਦ ਹੈ ਕਿ ਜਦੋਂ ਅਸੀਂ ਮੁਲਾਕਾਤ ਕੀਤੀ ਸੀ ਤਾਂ ਟ੍ਰਾਂਸਕੋਡਰਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਸਨ. ਕੀ ਅਸੀਂ ਸਟਰੀਮ ਦੀ ਜਾਂਚ ਕੀਤੀ ਹੈ?

ਆਰਟਿਓਮ: ਦੁਹਰਾਈ ਨਾਲ ਟੈਸਟ ਕੀਤਾ. ਮੀਟਿੰਗਾਂ ਦਾ ਆਯੋਜਨ ਕਰਨਾ। ਮੀਟਿੰਗਾਂ ਦੇ ਆਯੋਜਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ, ਲਗਭਗ 2300 JIRA ਟਿਕਟਾਂ ਸਨ। ਇਹ ਸਿਰਫ਼ ਆਮ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਲੋਕਾਂ ਨੇ ਮੁਲਾਕਾਤਾਂ ਕਰਨ ਲਈ ਕੀਤੀਆਂ ਸਨ। ਅਸੀਂ ਪਲੇਟਫਾਰਮ ਦੇ ਕੁਝ ਹਿੱਸਿਆਂ ਨੂੰ ਮੀਟਿੰਗਾਂ ਲਈ ਇੱਕ ਵੱਖਰੇ ਪੰਨੇ 'ਤੇ ਲਿਆ, ਜਿਸ ਨੂੰ ਕਿਰਿਲ ਟੋਲਕਾਚੇਵ ਦੁਆਰਾ ਚਲਾਇਆ ਗਿਆ ਸੀ (talkkv).

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

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

ਉਪਕਰਣ

- ਮੈਨੂੰ ਯਾਦ ਹੈ ਕਿ ਕਾਨਫਰੰਸਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਪਹਿਲਾਂ ਅਸੀਂ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਵਾਧੂ ਉਪਕਰਣ ਖਰੀਦੇ ਸਨ।

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

— ਸਾਡੇ ਕੋਲ ਇੰਟਰਨੈੱਟ ਨਾਲ ਵੀ ਅਜਿਹੀ ਹੀ ਕਹਾਣੀ ਹੈ। ਜਿਸ ਦਫਤਰ ਵਿਚ ਸਾਡੇ ਸਟੂਡੀਓ ਸਥਿਤ ਹਨ, ਅਸੀਂ ਫਰਸ਼ਾਂ ਦੇ ਵਿਚਕਾਰ ਇਕ ਭਿਆਨਕ ਜਾਲ ਵਿਛਾਇਆ।

ਆਰਟਿਓਮ: ਸਾਡੇ ਕੋਲ ਫਰਸ਼ਾਂ ਦੇ ਵਿਚਕਾਰ 20 Gbit ਫਾਈਬਰ ਹੈ। ਫਰਸ਼ਾਂ ਦੇ ਨਾਲ-ਨਾਲ, ਕਿਤੇ ਓਪਟਿਕਸ ਹੈ, ਕਿਤੇ ਕੋਈ ਆਪਟਿਕਸ ਨਹੀਂ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਗੀਗਾਬਾਈਟ ਨਾਲੋਂ ਘੱਟ ਚੈਨਲ ਹਨ - ਅਸੀਂ ਕਾਨਫਰੰਸ ਦੇ ਟਰੈਕਾਂ ਦੇ ਵਿਚਕਾਰ ਉਹਨਾਂ 'ਤੇ ਵੀਡੀਓ ਚਲਾਉਂਦੇ ਹਾਂ। ਆਮ ਤੌਰ 'ਤੇ, ਤੁਹਾਡੇ ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਕੰਮ ਕਰਨਾ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ; ਤੁਸੀਂ ਸਾਈਟਾਂ 'ਤੇ ਔਫਲਾਈਨ ਕਾਨਫਰੰਸਾਂ ਵਿੱਚ ਅਜਿਹਾ ਘੱਟ ਹੀ ਕਰ ਸਕਦੇ ਹੋ।

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

ਉਤਸੁਕਤਾ ਅਤੇ ਸਮੱਸਿਆਵਾਂ

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

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

ਵਲਾਦੀਮੀਰ: ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਸਿਰਫ ਪਿਛਲੇ ਤਿੰਨ ਮਹੀਨਿਆਂ ਤੋਂ ਹੋਇਆ ਹੈ. ਨਿੱਤ. ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਮੇਰੇ ਸਾਰੇ ਵਾਲ ਬਾਹਰ ਕੱਢੇ ਗਏ ਹਨ.

ਵਲਾਦੀਮੀਰ ਕ੍ਰਾਸਿਲਸ਼ਿਕ 3 ਮਹੀਨਿਆਂ ਬਾਅਦ, ਜਦੋਂ ਕਿਸੇ ਕਿਸਮ ਦੀ ਖੇਡ ਨਿਕਲੀ ਅਤੇ ਕੋਈ ਨਹੀਂ ਸਮਝਿਆ ਕਿ ਇਸ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ

ਹਰ ਰੋਜ਼ ਅਜਿਹਾ ਕੁਝ ਹੁੰਦਾ ਸੀ, ਜਦੋਂ ਕੋਈ ਅਜਿਹਾ ਪਲ ਹੁੰਦਾ ਸੀ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਲੈ ਕੇ ਆਪਣੇ ਵਾਲਾਂ ਨੂੰ ਪਾੜਦੇ ਹੋ, ਜਾਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਕਿ ਕੋਈ ਹੋਰ ਨਹੀਂ ਹੈ, ਅਤੇ ਸਿਰਫ ਤੁਸੀਂ ਹੀ ਕਰ ਸਕਦੇ ਹੋ. ਸਾਡੀ ਪਹਿਲੀ ਵੱਡੀ ਘਟਨਾ TechTrain ਸੀ। 6 ਜੂਨ ਨੂੰ ਦੁਪਹਿਰ 2 ਵਜੇ ਅਸੀਂ ਅਜੇ ਉਤਪਾਦਨ ਦੇ ਮਾਹੌਲ ਨੂੰ ਰੋਲਆਊਟ ਨਹੀਂ ਕੀਤਾ ਸੀ, ਕੋਲਿਆ ਇਸਨੂੰ ਰੋਲ ਆਊਟ ਕਰ ਰਿਹਾ ਸੀ। ਅਤੇ ਨਿੱਜੀ ਖਾਤਾ OAuth2.0 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪ੍ਰਮਾਣੀਕਰਨ ਸਰਵਰ ਵਜੋਂ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਪਲੇਟਫਾਰਮ ਨੂੰ ਇਸ ਨਾਲ ਜੋੜਨ ਲਈ ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ OAuth2.0 ਪ੍ਰਦਾਤਾ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਹੈ। ਮੈਂ ਸ਼ਾਇਦ 18 ਘੰਟਿਆਂ ਤੋਂ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ, ਮੈਂ ਕੰਪਿਊਟਰ ਵੱਲ ਦੇਖਿਆ ਅਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਦੇਖਿਆ, ਮੈਨੂੰ ਸਮਝ ਨਹੀਂ ਆਇਆ ਕਿ ਇਹ ਕੰਮ ਕਿਉਂ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ, ਅਤੇ ਕੋਲਿਆ ਨੇ ਰਿਮੋਟ ਤੋਂ ਮੇਰੇ ਕੋਡ ਨੂੰ ਦੇਖਿਆ, ਬਸੰਤ ਸੰਰਚਨਾ ਵਿੱਚ ਇੱਕ ਬੱਗ ਲੱਭਿਆ। , ਇਹ ਪਾਇਆ, ਅਤੇ LC ਨੇ ਕੰਮ ਕੀਤਾ, ਅਤੇ ਉਤਪਾਦਨ ਵਿੱਚ ਵੀ।

ਨਿਕੋਲਯ: ਅਤੇ TechTrain ਦੇ ਰਿਲੀਜ਼ ਹੋਣ ਤੋਂ ਇੱਕ ਘੰਟਾ ਪਹਿਲਾਂ.

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

ਪ੍ਰਦਰਸ਼ਨ ਬਾਰੇ

- ਕੀ ਤੁਸੀਂ ਮੈਨੂੰ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ ਟਰੈਕ 'ਤੇ ਸਾਈਟ 'ਤੇ ਕਿੰਨੇ ਲੋਕ ਸਨ? ਕੀ ਕੋਈ ਪ੍ਰਦਰਸ਼ਨ ਮੁੱਦੇ ਸਨ?

ਨਿਕੋਲਯ: ਇੱਥੇ ਕੋਈ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਸਨ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਹੈ. ਇੱਕ ਰਿਪੋਰਟ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਵਾਲੇ ਲੋਕਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ 1300 ਲੋਕ ਸੀ, ਇਹ ਹੈਜ਼ਨਬੱਗ 'ਤੇ ਹੈ।

- ਕੀ ਸਥਾਨਕ ਦੇਖਣ ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਸੀ? ਅਤੇ ਕੀ ਇਹ ਸਭ ਕੁਝ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਦੇ ਚਿੱਤਰਾਂ ਦੇ ਨਾਲ ਤਕਨੀਕੀ ਵਰਣਨ ਕਰਨਾ ਸੰਭਵ ਹੈ?

ਨਿਕੋਲਯ: ਅਸੀਂ ਇਸ ਬਾਰੇ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਲੇਖ ਬਣਾਵਾਂਗੇ।

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

ਵਲਾਦੀਮੀਰ: ਜਿਵੇਂ ਕਿ ਮੈਂ ਇਸਨੂੰ ਸਮਝਦਾ ਹਾਂ, ਫਰੰਟ-ਐਂਡ ਡਿਵੈਲਪਰਾਂ ਨੇ ਮਖੌਲਾਂ ਨਾਲ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕੰਮ ਕੀਤਾ, ਅਤੇ ਫਿਰ, ਕਿਉਂਕਿ ਫਰੰਟ ਵਿੱਚ devs ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨ ਦਾ ਸਮਾਂ ਵੀ ਛੋਟਾ ਹੈ (5 ਮਿੰਟ), ਸਰਟੀਫਿਕੇਟਾਂ ਦੇ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ.

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

ਵਲਾਦੀਮੀਰ: ਤੁਸੀਂ ਇਸਨੂੰ ਲੈ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਦੁਹਰਾ ਸਕਦੇ ਹੋ।

- 3 ਮਹੀਨਿਆਂ ਵਿੱਚ.

ਨਤੀਜਾ

- ਇਕੱਠੇ ਵਰਣਿਤ ਹਰ ਚੀਜ਼ ਵਧੀਆ ਲੱਗਦੀ ਹੈ, ਇਸ ਗੱਲ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਹੋਏ ਕਿ ਇਹ ਤਿੰਨ ਮਹੀਨਿਆਂ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਟੀਮ ਦੁਆਰਾ ਕੀਤਾ ਗਿਆ ਸੀ।

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

- ਜਦੋਂ ਗਰਮੀਆਂ ਦੀਆਂ ਕਾਨਫਰੰਸਾਂ ਪਹਿਲਾਂ ਹੀ ਹੋ ਚੁੱਕੀਆਂ ਸਨ ਤਾਂ ਤੁਹਾਡੇ ਅਗਲੇ ਕੰਮਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਕੀ ਸੀ?

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

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

- ਦੋਸਤੋ, ਤੁਹਾਡੇ ਜਵਾਬਾਂ ਲਈ ਤੁਹਾਡਾ ਬਹੁਤ ਧੰਨਵਾਦ!

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

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

ਸਰੋਤ: www.habr.com