ಸೈಟ್ನ ಪ್ರಕಟಣಾ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನಲ್ಲಿ ಚಲಾಯಿಸಲಾದ ಕ್ಲೀನಪ್ ಸ್ಕ್ರಿಪ್ಟ್, ಕೋಡ್ ಸ್ನಿಪ್ಪೆಟ್ಗಳನ್ನು ತಪ್ಪಾದ Liquid ವೇರಿಯೇಬಲ್ಗಳೆಂದು ತಪ್ಪಾಗಿ ಗುರುತಿಸಿ, ಅವುಗಳನ್ನು ಒಳಗೊಂಡಿದ್ದ ಪ್ರತಿಯೊಂದು ಲೇಖನದಿಂದಲೂ ತೆಗೆದುಹಾಕಿತು. ಈ ತಾಂತ್ರಿಕ ದೋಷವು ಓದುಗರು ಅವಲಂಬಿಸುವ ಉದಾಹರಣೆ ಕೋಡ್ ಇಲ್ಲದಂತೆ ಡಜನ್ಗಟ್ಟಲೆ ತಾಂತ್ರಿಕ ಲೇಖನಗಳನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿತು, ಇದು ತುರ್ತು ರೋಲ್ಬ್ಯಾಕ್ ಮತ್ತು ಕಂಟೆಂಟ್ ಮೈಗ್ರೇಷನ್ಗಳನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸಬೇಕು ಎಂಬ ಬಗ್ಗೆ ಮರುಪರಿಶೀಲನೆಗೆ ಪ್ರೇರೇಪಿಸಿತು.
ಈ ಬಗ್ ಹೇಗೆ ತಪ್ಪಿಹೋಯಿತು
ಈ ಪ್ಲಾಟ್ಫಾರ್ಮ್ Liquid ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದು {{ … }} ನಂತಹ ಟ್ಯಾಗ್ಗಳೊಂದಿಗೆ ಡೈನಾಮಿಕ್ ಕಂಟೆಂಟ್ ಅನ್ನು ಮಾರ್ಕ್ ಮಾಡುವ ಒಂದು ಟೆಂಪ್ಲೇಟಿಂಗ್ ಭಾಷೆಯಾಗಿದೆ. ರೆಂಡರಿಂಗ್ ಅನ್ನು ಹಾಳುಮಾಡಬಹುದಾದ ಬಾಕಿ ಉಳಿದಿರುವ ಟ್ಯಾಗ್ಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಒಂದು ನಿಯಮಿತ ನಿರ್ವಹಣಾ ಕೆಲಸವನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿತ್ತು. ಸ್ಕ್ರಿಪ್ಟ್ನ ಪಾರ್ಸರ್, ಹೊಂದಿಕೆಯಾಗುವ ಕ್ಲೋಸಿಂಗ್ ಟ್ಯಾಗ್ ಇಲ್ಲದ ಓಪನಿಂಗ್ ಟ್ಯಾಗ್ಗಳಿಗಾಗಿ ಹುಡುಕಿತು ಮತ್ತು ಯಾವುದಾದರೂ ಕಂಡುಬಂದಾಗ, ದೋಷವನ್ನು "ಸರಿಪಡಿಸಲು" ಇಡೀ ಬ್ಲಾಕ್ ಅನ್ನು ಅಳಿಸಿಹಾಕಿತು.
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಪಾರ್ಸರ್ ಕೋಡ್ ಬ್ಲಾಕ್ಗಳನ್ನು ಸುತ್ತುವರಿಯುವ {% raw %} ಮತ್ತು {% endraw %} ಟ್ಯಾಗ್ಗಳನ್ನು ಗುರುತಿಸಲು ವಿಫಲವಾಯಿತು. ಆ ಟ್ಯಾಗ್ಗಳು ಒಳಗಿರುವ ಎಲ್ಲವನ್ನೂ ಲಿಟರಲ್ ಟೆಕ್ಸ್ಟ್ ಎಂದು ಪರಿಗಣಿಸಲು Liquid ಗೆ ಸೂಚಿಸುತ್ತವೆ, ಆದರೆ ದೋಷಪೂರಿತ ಸ್ಕ್ರಿಪ್ಟ್ ಓಪನಿಂಗ್ {% raw %} ಅನ್ನು ಮುಚ್ಚದ ವೇರಿಯೇಬಲ್ ({{% raw %}) ಎಂದು ಪರಿಗಣಿಸಿ ಸುತ್ತಲಿನ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿತು. ಲಾಗ್ ಮಾಡಲಾದ ದೋಷ ಸಂದೇಶ ಹೀಗಿತ್ತು:
Liquid syntax error: Variable '{{% raw %}' was not properly terminated.
ಸ್ಕ್ರಿಪ್ಟ್ ಲೈವ್ ಕಂಟೆಂಟ್ ರೆಪೊಸಿಟರಿಯ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಿದ್ದರಿಂದ, ಈ ತೆಗೆದುಹಾಕುವಿಕೆಯು ಬೃಹತ್ ಪ್ರಮಾಣದಲ್ಲಿ ಸಂಭವಿಸಿತು ಮತ್ತು ಒಂದೇ ಹಂತದಲ್ಲಿ ಎಲ್ಲಾ ಬಾಧಿತ ಲೇಖನಗಳಿಂದ ಕೋಡ್ ಉದಾಹರಣೆಗಳನ್ನು ಅಳಿಸಿಹಾಕಿತು.
ಅಪಾಯದಲ್ಲಿ ಏನಿದೆ
ತಾಂತ್ರಿಕ ಲೇಖನಗಳು ಪರಿಕಲ್ಪನೆಗಳನ್ನು ವಿವರಿಸಲು, ಫಲಿತಾಂಶಗಳನ್ನು ಪುನರಾವರ್ತಿಸಲು ಮತ್ತು ಓದುಗರಿಗೆ ಹಂತ-ಹಂತದ ಪ್ರಕ್ರಿಯೆಗಳ ಮೂಲಕ ಮಾರ್ಗದರ್ಶನ ನೀಡಲು ಕೋಡ್ ಸ್ನಿಪ್ಪೆಟ್ಗಳನ್ನು ಅವಲಂಬಿಸಿವೆ. ಆ ಬ್ಲಾಕ್ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು ಲೇಖನಗಳನ್ನು ಬಹುತೇಕ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿಸುತ್ತದೆ, ಲೇಖಕರು ಕಂಟೆಂಟ್ ಅನ್ನು ಮರುಬರೆಯುವಂತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಮೇಲಿನ ನಂಬಿಕೆಯನ್ನು ಕುಗ್ಗಿಸುತ್ತದೆ. ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಡೆವಲಪರ್ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಮೂಲಕ ತನ್ನ ಖ್ಯಾತಿಯನ್ನು ಕಟ್ಟಿಕೊಂಡಿರುವ ಸೈಟ್ಗೆ, ಈ ಘಟನೆಯು ಓದುಗರು ಮತ್ತು ಸಹಯೋಗಿಗಳ ಸದ್ಭಾವನೆ ಎರಡನ್ನೂ ಬೆದರಿಸುತ್ತದೆ.
ಹೆಚ್ಚಿನ ಓದುಗರು ಗಮನಿಸದ ವಿವರಗಳು
- ಸ್ಯಾಂಡ್ಬಾಕ್ ಇಲ್ಲದ ಬ್ಯಾಚ್ ಪ್ರೊಸೆಸಿಂಗ್ – ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸ್ಟೇಜಿಂಗ್ ಕಾಪಿಯ ಬದಲಿಗೆ ನೇರವಾಗಿ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾದ ಮೇಲೆ ಚಲಾಯಿಸಲಾಯಿತು.
- ಅಪೂರ್ಣ ಟ್ಯಾಗ್ ನಿರ್ವಹಣೆ – ಕೇವಲ ಕೆಲವು Liquid ಟ್ಯಾಗ್ಗಳನ್ನು ಮಾತ್ರ ಪರಿಗಣಿಸಲಾಗಿತ್ತು; ವೈಟ್ಲಿಸ್ಟ್ನಿಂದ
{% raw %}ಅನ್ನು ಹೊರತುಪಡಿಸಲಾಗಿತ್ತು. - ಹಂತ ಹಂತದ ಪರೀಕ್ಷೆಯ ಕೊರತೆ – ಸಣ್ಣ ಮಾದರಿಯ ಮೇಲೆ ಪೈಲಟ್ ರನ್ ನಡೆಸದೆ ಇಡೀ ಡೇಟಾಸೆಟ್ ಮೇಲೆ ಕೆಲಸವನ್ನು ಜಾರಿಗೆ ತರಲಾಯಿತು.
ಇದನ್ನು ಏನನ್ನು ತಡೆಯಬಹುದಿತ್ತು
- ಕಾಪಿಯ ಮೇಲೆ ಮೈಗ್ರೇಷನ್ಗಳನ್ನು ಚಲಾಯಿಸಿ – ಯಾವುದೇ ಬಲ್ಕ್ ಟ್ರಾನ್ಸ್ಫರ್ಮೇಶನ್ ಅನ್ನು ಮೊದಲು ಡೇಟಾಬೇಸ್ನ ಸ್ಯಾಂಡ್ಬಾಕ್ಡ್ ಆವೃತ್ತಿಗೆ ಅನ್ವಯಿಸಿ.
- ಎಲ್ಲಾ ಟ್ಯಾಗ್ ವೈರಿಯೇಷನ್ಗಳ ವಿರುದ್ಧ ಪಾರ್ಸರ್ಗಳನ್ನು ಯೂನಿಟ್-ಟೆಸ್ಟ್ ಮಾಡಿ – ರೊ (raw) ಬ್ಲಾಕ್ಗಳು, ಕಾಮೆಂಟ್ ಟ್ಯಾಗ್ಗಳು ಮತ್ತು ನೆಸ್ಟೆಡ್ ಸ್ಟ್ರಕ್ಚರ್ಗಳಂತಹ ಎಡ್ಜ್ ಕೇಸ್ಗಳನ್ನು ಸೇರಿಸಿ.
- ಹಂತ ಹಂತವಾಗಿ ಜಾರಿಗೆ ತರುವುದು – ಸೀಮಿತ ಸಂಖ್ಯೆಯ ಲೇಖನಗಳನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡಿ, ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ವಿಸ್ತರಿಸಿ.
ವಿರೋಧಾತ್ಮಕ ವಾದ
ವೇಗವಾಗಿ ಬೆಳೆಯುವ ಸೈಟ್ಗಳಿಗೆ ಪ್ರತಿ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಪೂರ್ಣ ಬ್ಯಾಕಪ್ನಲ್ಲಿ ಪರೀಕ್ಷಿಸುವುದು ಅಪ್ರಾಯೋಗಿಕ ಮತ್ತು ಡೇಟಾ ನಷ್ಟದ ಅಪಾಯಕ್ಕಿಂತ ತ್ವರಿತ ಪರಿಹಾರಗಳ ಅಗತ್ಯತೆ ದೊಡ್ಡದು ಎಂದು ಕೆಲವರು ವಾದಿಸುತ್ತಾರೆ. ವೇಗವು ಮುಖ್ಯವಾಗಿದ್ದರೂ, ಬೃಹತ್ ಪ್ರಮಾಣದ ಅಳಿಸುವಿಕೆಯನ್ನು ಹಿಂಪಡೆಯುವ ವೆಚ್ಚವು – ಡೆವಲಪರ್ ಸಮಯ ಮತ್ತು ಖ್ಯಾತಿಗೆ ಆಗುವ ಹಾನಿ ಎರಡನ್ನೂ ಒಳಗೊಂಡಂತೆ – ಎಚ್ಚರಿಕೆಯ ರೋಲ್ಔಟ್ನಿಂದ ಉಂಟಾಗುವ ವಿಳಂಬಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
ತಂಡವು ಬ್ಯಾಕಪ್ಗಳಿಂದ ಕಳೆದುಹೋದ ಕೋಡ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಿದೆ ಮತ್ತು ಎಲ್ಲಾ Liquid ರಚನೆಗಳನ್ನು ಗುರುತಿಸಲು ಕ್ಲೀನಪ್ ಟೂಲ್ ಅನ್ನು ಪರಿಷ್ಕರಿಸುತ್ತಿದೆ. ಅವರು ನವೀಕರಿಸಿದ ಪರೀಕ್ಷಾ ಕಾರ್ಯವಿಧಾನವನ್ನು ವಿವರಿಸುವ ಪೋಸ್ಟ್-ಮೋರ್ಟಮ್ ಅನ್ನು ಪ್ರಕಟಿಸಲು ಮತ್ತು ಇತರ ಪ್ರಕಾಶಕರು ಇದೇ ತಪ್ಪು ಮಾಡದಂತೆ ತಡೆಯಲು ಪರಿಷ್ಕೃತ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿ ಹಂಚಿಕೊಳ್ಳಲು ಯೋಜಿಸಿದ್ದಾರೆ. ಈ ಘಟನೆಯು ಒಂದು ನೆನಪಿನ ಪಾಠವಾಗಿದೆ: ಒಂದು ಸಣ್ಣ ಪಾರ್ಸಿಂಗ್ ದೋಷವು ಲೇಖಕರ ವಾರಗಟ್ಟಲೆ ಶ್ರಮವನ್ನು ಅಳಿಸಿಹಾಕಬಲ್ಲದು, ಆದ್ದರಿಂದ ಕಟ್ಟುನಿಟ್ಟಾದ ಪರೀಕ್ಷೆಯು ಕಡ್ಡಾಯವಾಗಿದೆ.