ಬ್ರೌಸರ್ ಆಧಾರಿತ ಪೈಥಾನ್ ಪ್ಲೇಗ್ರೌಂಡ್ (Python playground) 5.5 MB ರ ರನ್-ಟೈಮ್ ಅನ್ನು ಬಳಸುತ್ತಿತ್ತು, ಆದರೆ ನಿಧಾನಗತಿಯ ಇಂಟರ್ನೆಟ್ ಇರುವ ಬಳಕೆದಾರರಿಗೆ ಇದು ಯಾವುದೇ ಸೂಚನೆ ಇಲ್ಲದೆ ವಿಫಲವಾಗತೊಡಗಿತು. ಇದಕ್ಕೆ ಕಾರಣ ತಪ್ಪಾಗಿ ಬಳಸಲಾದ Network Information API ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ತಪ್ಪಾಗಿ ವರ್ಗೀಕರಿಸಿದ ಎರರ್-ಗ್ರೂಪಿಂಗ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್. ಈ ದೋಷವು ವಾರಗಟ್ಟಲೆ ಅಡಗಿದ್ದರಿಂದ, ಡೆವಲಪರ್‌ಗಳ ಸಮಯ ವ್ಯರ್ಥವಾಯಿತು ಮತ್ತು ಬಳಕೆದಾರರ ಒಂದು ವರ್ಗಕ್ಕೆ ಕೋಡ್ ರನ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

ಸಮಸ್ಯೆ ಹೇಗೆ ಎದುರಾಯಿತು

ಪ್ಲೇಗ್ರೌಂಡ್‌ನ ಎರರ್ ಟ್ರ್ಯಾಕರ್ ಒಂದೇ ಒಂದು ಗಮನ ಸೆಳೆಯುವ ಸಂದೇಶವನ್ನು ತೋರಿಸಿತು: “undefined is not an object.” ಈ ಶೀರ್ಷಿಕೆಯು ಕೇವಲ ಒಂದು ಸಣ್ಣ JavaScript ಟೈಪೋ (typo) ಎಂದು ಸೂಚಿಸಿತು, ಹಾಗಾಗಿ ತಂಡವು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಕೋಡ್ ಪಾತ್ ಅನ್ನು ಹುಡುಕುತ್ತಾ ಸಮಯ ವ್ಯರ್ಥ ಮಾಡಿತು. ಅವರು ಮೆಟಾಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸಿದಾಗ, ಆ ಘಟನೆಗಳಲ್ಲಿ ಶೇಕಡಾ 89 ರಷ್ಟು ವಾಸ್ತವವಾಗಿ ನೆಟ್‌ವರ್ಕ್ ಟೈಮೌಟ್‌ಗಳಾಗಿದ್ದವು (network timeouts) ಎಂದು ಕಂಡಿತು. ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಮೊದಲು ಬಂದ ತಪ್ಪನ್ನು ಮಾತ್ರ ನೋಡಿ, ಇಡೀ ಗುಂಪಿಗೆ ಅದೇ ಹೆಸರನ್ನು ನೀಡಿದ್ದರಿಂದ, ನಿಜವಾದ ವೈಫಲ್ಯದ ವಿಧವು ಮರೆಯಾಗಿತ್ತು.

ಪಾಠ 1 – ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಶೀರ್ಷಿಕೆಗಳು ದಾರಿತಪ್ಪಿಸಬಹುದು

ಘಟನೆಗಳನ್ನು ಕ್ರೋಢೀಕರಿಸುವ (aggregates) ಡ್ಯಾಶ್‌ಬೋರ್ಡ್, ಅದರ ತರ್ಕವು (logic) ಪ್ರತಿ ಘಟನೆಯ ನಿಜವಾದ ಕಾರಣವನ್ನು ಪ್ರತಿಬಿಂಬಿಸಿದರೆ ಮಾತ್ರ ಉಪಯುಕ್ತವಾಗುತ್ತದೆ. ಇಲ್ಲಿ, ತಪ್ಪಿನ ಕಾರಣದ ಬದಲಿಗೆ ಸ್ಥಳದ (location) ಆಧಾರದ ಮೇಲೆ ಗುಂಪು ಮಾಡಿದ್ದರಿಂದ, ಅದು ಕ್ಲೈಂಟ್-ಸೈಡ್ ಬಗ್ ಎಂದು ತಪ್ಪಾಗಿ ತೋರಿಸಿತು. ಇಲ್ಲಿನ ಮುಖ್ಯ ಅಂಶವೆಂದರೆ: ಕೇವಲ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಶೀರ್ಷಿಕೆಯನ್ನು ನೋಡಿ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಲು ಹೋಗಬೇಡಿ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುವ ಮೊದಲು, ಮೂಲ ಘಟನೆಗಳ ಮಾದರಿಯನ್ನು (sample) ಪಡೆದು, ನಿಜವಾಗಿಯೂ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ಪಾಠ 2 – ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ (Placeholder) ಮೌಲ್ಯಗಳು ಅಳತೆಗಳಲ್ಲ

ನಿಧಾನಗತಿಯ ಇಂಟರ್ನೆಟ್ ಇರುವ ಬಳಕೆದಾರರಿಗೆ ದೊಡ್ಡದಾದ ರನ್-ಟೈಮ್ ಲೋಡ್ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಲು, ಕೋಡ್ Network Information API ಅನ್ನು ಬಳಸಿಕೊಂಡು downlink ಪ್ರಾಪರ್ಟಿಯನ್ನು ಓದುತ್ತಿತ್ತು, ಇದು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಮೆಗಾಬಿಟ್‌ಗಳನ್ನು (megabits per second) ವರದಿ ಮಾಡುತ್ತದೆ. ಮೊದಲ ಭೇಟಿಯ ಸಮಯದಲ್ಲಿ, Chrome ಹೆಚ್ಚಾಗಿ ನಿಜವಾದ ಅಳತೆಯ ಬದಲಿಗೆ ಒಂದು ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ಈ ತರ್ಕವು ಆ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಅನ್ನು ವೇಗದ ಸಂಪರ್ಕವೆಂದು ಭಾವಿಸಿ, ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿತು, ಇದರಿಂದಾಗಿ ಸಹಾಯ ಮಾಡಬೇಕಿದ್ದ ಬಳಕೆದಾರರೇ ಅಡಚಣೆಯನ್ನು ಎದುರಿಸಬೇಕಾಯಿತು.

ಯಾವುದೇ ಡಿಫಾಲ್ಟ್ ಅಥವಾ ಸೆಂಟಿನೆಲ್ (sentinel) ಮೌಲ್ಯವನ್ನು "ಡೇಟಾ ಇಲ್ಲ" ಎಂದು ಪರಿಗಣಿಸಿ. ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಅನ್ನು ನಿಜವಾದ ವೇಗದ ಅಳತೆಯೆಂದು ಭಾವಿಸುವ ಬದಲು, ಅದನ್ನು ಬಳಸಿಕೊಂಡು ಪರ್ಯಾಯ ಕಾರ್ಯತಂತ್ರವನ್ನು (fallback strategy) ಅನುಸರಿಸಬೇಕು.

ಪಾಠ 3 – ನೆಟ್‌ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳು ಬದಲಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಒಂದೇ ಒಂದು ಸ್ನಾಪ್‌ಶಾಟ್ ನಂಬಲರ್ಹವಲ್ಲ

downlink ಸಮಸ್ಯೆಯ ನಂತರ, ತಂಡವು effectiveType ಅನ್ನು ಪರಿಶೀಲಿಸಲು ಬದಲಾಯಿಸಿತು, ಇದು ಸಂಪರ್ಕಗಳನ್ನು “4g”, “3g” ಇತ್ಯಾದಿ ಎಂದು ವರ್ಗೀಕರಿಸುತ್ತದೆ. ಒಂದು ಸಣ್ಣ ಪ್ರಯೋಗದಲ್ಲಿ ಇದು ಯಶಸ್ವಿಯಾಯಿತು, ಆದರೆ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಅದೇ ಪ್ರಯೋಗವು ವಿಫಲವಾಯಿತು. ಮೊಬೈಲ್ ಸಂಪರ್ಕಗಳು ಏರಿಳಿತಗೊಳ್ಳುತ್ತಿರುತ್ತವೆ; ಬಳಕೆದಾರರು ಒಂದು ಕ್ಷಣ ವೇಗದ 4G ಸಂಪರ್ಕದಲ್ಲಿರಬಹುದು ಮತ್ತು ಮುಂದಿನ ಕ್ಷಣವೇ ನಿಧಾನಗತಿಯ 3G ಗೆ ಬದಲಾಗಬಹುದು. ಕೇವಲ ಪೇಜ್ ಲೋಡ್ ಆಗುವಾಗ ಮಾತ್ರ ಸಂಪರ್ಕವನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅಪಾಯಕಾರಿ.

ಸರಿಯಾದ ವಿಧಾನವೆಂದರೆ, ಕೇವಲ ಒಂದು ಬಾರಿಯ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವ ಬದಲು, Network Information ಆಬ್ಜೆಕ್ಟ್‌ನಲ್ಲಿನ change ಇವೆಂಟ್‌ಗೆ ಸಬ್‌ಸ್ಕ್ರೈಬ್ (subscribe) ಮಾಡುವುದು ಮತ್ತು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನಲ್ಲಿ ಆಗುವ ಯಾವುದೇ ಬದಲಾವಣೆಗೆ ತಕ್ಕಂತೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದು.

ತಂಡವು ಮಾಡಿದ ಬದಲಾವಣೆಗಳು

  • ದ್ವಿ-ಹಂತದ ಡೌನ್‌ಲೋಡ್ (Two-stage download) – ರನ್-ಟೈಮ್ ಈಗ ಒಂದು ಸಣ್ಣ ಬೂಟ್‌ಸ್ಟ್ರಾಪ್ (bootstrap) ಫೈಲ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಸಂಪರ್ಕವು ನಿಧಾನಗತಿಯದ್ದು ಎಂದು ಕಂಡುಬಂದಲ್ಲಿ, ಬೂಟ್‌ಸ್ಟ್ರಾಪ್ ಉಳಿದ ರನ್-ಟೈಮ್ ಅನ್ನು ಸಣ್ಣ ತುಣುಕುಗಳಾಗಿ (chunks) ಪಡೆಯುತ್ತದೆ, ಇದರಿಂದ ಡೌನ್‌ಲೋಡ್ ಪೂರ್ಣವಾಗಿ ಸ್ಥಗಿತಗೊಳ್ಳುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
  • ಲೈವ್ ಮಾನಿಟರಿಂಗ್ (Live monitoring) – ಕೇವಲ ಒಂದು ಬಾರಿಯ downlink ಓದಿನ ಬದಲಿಗೆ, ಕೋಡ್ ಈಗ change ಇವೆಂಟ್‌ಗಳನ್ನು ಗಮನಿಸುತ್ತದೆ ಮತ್ತು ಡೌನ್‌ಲೋಡ್ ತಂತ್ರವನ್ನು ತಕ್ಷಣವೇ ಬದಲಾಯಿಸುತ್ತದೆ.
  • ಸ್ಥಿರ ಮೂಲದ ಆಯ್ಕೆ (Stable source selection) – ಈ ಮೊದಲು, ವೇಗವಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸಿಕ್ಕಾಗ ಡೌನ್‌ಲೋಡ್ ನಡೆಯುತ್ತಿರುವಾಗಲೇ ಸಿಸ್ಟಮ್ CDNಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತಿತ್ತು. ನಿಧಾನಗತಿಯ ಸಂಪರ್ಕದಲ್ಲಿ ಇದು ಡೌನ್‌ಲೋಡ್ ಅನ್ನು ಮೊದಲಿನಿಂದಲೇ ಮರುಪ್ರಾರಂಭಿಸುವಂತೆ ಮಾಡಿ ಸಮಸ್ಯೆಯನ್ನು ಮತ್ತಷ್ಟು ಹೆಚ್ಚಿಸುತ್ತಿತ್ತು. ಹೊಸ ತರ್ಕವು ಡೌನ್‌ಲೋಡ್ ಮುಗಿಯುವವರೆಗೆ ಮೂಲವನ್ನು (source) ಸ್ಥಿರವಾಗಿರಿಸುತ್ತದೆ.
  • ವಿಳಂಬಿತ ಕ್ಯಾಶ್ ಬರವಣಿಗೆಗಳು (Deferred cache writes) – ಅಪ್ಲಿಕೇಶನ್ ಬಳಸಲು ಸಿದ್ಧವಾಗುವ ಮೊದಲೇ ನಡೆಯುತ್ತಿದ್ದ ಭಾರೀ ಕ್ಯಾಶ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಈಗ ರನ್-ಟೈಮ್ ಪ್ರಾರಂಭವಾದ ನಂತರಕ್ಕೆ ಮುಂದೂಡಲಾಗಿದೆ, ಇದರಿಂದ ಪ್ರಮುಖ ಡೌನ್‌ಲೋಡ್‌ಗೆ ಹೆಚ್ಚಿನ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಲಭ್ಯವಾಗುತ್ತದೆ.

ವಿಶಾಲವಾದ ಪರಿಣಾಮಗಳು

ವೆಬ್ ಆಧಾರಿತ ಪರಿಕರಗಳನ್ನು ನಿರ್ಮಿಸುವ ಡೆವಲಪರ್‌ಗಳಿಗೆ, ನೆಟ್‌ವರ್ಕ್ ಏರಿಳಿತಗಳು ಒಂದು ಪ್ರಮುಖ ವಿಷಯವಾಗಿದೆ. ನಿಧಾನಗತಿಯ ಸಂಪರ್ಕದಲ್ಲಿ ಯಾವುದೇ ಸೂಚನೆ ಇಲ್ಲದೆ ವಿಫಲವಾಗುವುದು ಬಳಕೆದಾರರನ್ನು ಬೇಸರಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಟೆಲಿಮೆಟ್ರಿ (telemetry) ದತ್ತಾಂಶವನ್ನು ತಪ್ಪಾಗಿ ತೋರಿಸುತ್ತದೆ, ಇದು ತಂಡಗಳನ್ನು ತಪ್ಪು ಡಿಬಗ್ಗಿಂಗ್ ಹಾದಿಯಲ್ಲಿ ನಡೆಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ದತ್ತಾಂಶವನ್ನು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಂಡಿದ್ದರಿಂದ ವಾರಗಟ್ಟಲೆ ಫಲಿತಾಂಶವಿಲ್ಲದ ತನಿಖೆ ನಡೆಯಿತು.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು

ಮುಖ್ಯ ಅಂಶ: ದತ್ತಾಂಶವು ಅತಿಯಾಗಿ ಸುಲಲಿತವಾಗಿ (clean) ಕಂಡರೆ, ಅದು ಬಹುಶಃ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಆಗಿರಬಹುದು; ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಶೀರ್ಷಿಕೆಯು ಕೇವಲ ಒಂದು ಬಗ್ ಅನ್ನು ತೋರಿಸುತ್ತಿದ್ದರೆ, ಅದರ ಬಗ್ಗೆ ಆಳವಾಗಿ ತನಿಖೆ ಮಾಡಿ; ಮತ್ತು ನೀವು ಕೇವಲ ಒಂದು ಬಾರಿಯ ನೆಟ್‌ವರ್ಕ್ ರೀಡಿಂಗ್ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದ್ದರೆ, ನೀವು ಅಸ್ಥಿರವಾದ ಗುರಿಯ ಮೇಲೆ ಪಣ ತೊಡುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ. ಈ ವಾಸ್ತವಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ಬದಲಾವಣೆ ಮಾಡಿಕೊಳ್ಳುವುದು, ಅನಿರೀಕ್ಷಿತ ವೈಫಲ್ಯಗಳನ್ನು ಮುನ್ಸೂಚಿಸಬಹುದಾದ ಮತ್ತು ಸರಿಪಡಿಸಬಹುದಾದ ಘಟನೆಗಳನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.