ಶನಿವಾರ ಮಧ್ಯಾಹ್ನ. ನೀವು ಕಾಫಿಯೊಂದಿಗೆ ಕುಳಿತುಕೊಳ್ಳುತ್ತೀರಿ, ಯಾವುದಾದರೂ ಒಂದು ಸಣ್ಣ ಫೀಚರ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಅಥವಾ ನಿಮ್ಮ ಸೈಡ್ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಅಂತಿಮವಾಗಿ ಅಚ್ಚುಕಟ್ಟಾಗಿಸಲು ಸಂಪೂರ್ಣ ಉದ್ದೇಶ ಹೊಂದಿದ್ದೀರಿ. ಹತ್ತು ನಿಮಿಷಗಳ ನಂತರ, ಎಲ್ಲವೂ ನಿಂತುಹೋಗುತ್ತದೆ. ಲಾಜಿಕ್ ತುಂಬಾ ಸಂಕೀರ್ಣವಾಗಿರುವುದರಿಂದ ಅಲ್ಲ. ನಿಮಗೆ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ ಎಂದೂ ಅಲ್ಲ. ಕೇವಲ ಒಂದು ಟ್ಯಾಗ್ ತೆರೆದ ಸ್ಥಿತಿಯಲ್ಲೇ (hanging open) ಉಳಿದಿದ್ದರಿಂದ ಪ್ರಗತಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ.

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

ಅದರ ಹಿಂದಿನ ತಾಂತ್ರಿಕ ಕಾರಣಗಳೇನು?

Liquid ಎಂಬುದು Shopify ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಟೆಂಪ್ಲೇಟಿಂಗ್ ಭಾಷೆಯಾಗಿದ್ದು, ಇದು ಇ-ಕಾಮರ್ಸ್ ಸ್ಟೋರ್‌ಫ್ರಂಟ್‌ಗಳಿಂದ ಹಿಡಿದು GitHub Pages ನಲ್ಲಿರುವ Jekyll-ಆಧಾರಿತ ಬ್ಲಾಗ್‌ಗಳವರೆಗೆ ಎಲ್ಲವನ್ನೂ ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಇದು ಎರಡು ಪ್ರಮುಖ ಸಿಂಟ್ಯಾಕ್ಸ್ ಮಾದರಿಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಡಬಲ್ ಕರ್ಲಿ ಬ್ರೇಸ್‌ಗಳು (Double curly braces) ಔಟ್‌ಪುಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ, ಉದಾಹರಣೆಗೆ {{ page.title }}. ಕರ್ಲಿ ಬ್ರೇಸ್ ಪರ್ಸೆಂಟ್ ಸೈನ್ಸ್‌ಗಳು ({% %}) ಲಾಜಿಕ್ ಮತ್ತು ಫ್ಲೋ ಕಂಟ್ರೋಲ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ, ಉದಾಹರಣೆಗೆ {% if user %} ಅಥವಾ {% for item in list %}.

ಪ್ರತಿಯೊಂದು ಓಪನಿಂಗ್ ಟ್ಯಾಗ್ ಒಂದು ಜೋಡಿಯನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. {% if %} ಗೆ {% endif %} ಅಗತ್ಯವಿದೆ. {% for %} ಲೂಪ್‌ಗೆ {% endfor %} ಅಗತ್ಯವಿದೆ. ಕ್ಯಾಪ್ಚರ್ ಬ್ಲಾಕ್‌ಗೆ {% endcapture %} ಅಗತ್ಯವಿದೆ. ಇವು ಕೇವಲ ಸಲಹೆಗಳಲ್ಲ. Liquid ಎಂಜಿನ್ ನಿಮ್ಮ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಕ್ರಮಬದ್ಧವಾಗಿ ಓದುತ್ತದೆ. ಅದು ಒಂದು ಓಪನಿಂಗ್ ರಚನೆಯನ್ನು ಕಂಡಾಗ, ತನ್ನ ಆಂತರಿಕ ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ (internal stack) ಒಂದು ಫ್ರೇಮ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಕಾಯುತ್ತದೆ. ಫೈಲ್ ಮುಗಿದುಹೋದರೆ, ಅಥವಾ ನಿರೀಕ್ಷಿತ ಟ್ಯಾಗ್ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮೊದಲೇ ಇನ್ನೊಂದು ಪ್ರಮುಖ ಬ್ಲಾಕ್ ಮುಚ್ಚಲ್ಪಟ್ಟರೆ, ಎಂಜಿನ್ ದೋಷವನ್ನು ತೋರಿಸುತ್ತದೆ. ಸಂದೇಶವು ಸಾಮಾನ್ಯವಾಗಿ ನೇರವಾಗಿರುತ್ತದೆ: tag was not closed correctly. ಸಿಸ್ಟಮ್ ಒಂದು ಕ್ಲೋಸಿಂಗ್ ಸೀಕ್ವೆನ್ಸ್ ಅನ್ನು ನಿರೀಕ್ಷಿಸಿತ್ತು. ಕೆಲವೊಮ್ಮೆ ನಿಮಗೆ ಲೈನ್ ನಂಬರ್ ಸಿಗುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ ಆ ಲೈನ್ ನಂಬರ್ ತಪ್ಪಾದ ಸ್ಥಳವನ್ನು ತೋರಿಸಬಹುದು, ಏಕೆಂದರೆ ಪಾರ್ಸರ್ ಅದರ ಕೆಳಗಿರುವ ಎಲ್ಲವನ್ನೂ ಓದಿದ ನಂತರವಷ್ಟೇ ತನ್ನ ಜೋಡಿ ಟ್ಯಾಗ್ ಕಾಣೆಯಾಗಿದೆ ಎಂದು ಅರಿತುಕೊಳ್ಳುತ್ತದೆ.

ಒಂದುជាក់ಾತ್ಮಕ ಉದಾಹರಣೆಯನ್ನು ಗಮನಿಸಿ. ನೀವು ಈ ಕೆಳಗಿನಂತೆ ಬರೆಯಬಹುದು:

{% for product in collections.all.products %}
  <div class="card">
    <h2>{{ product.title }}</h2>
    {% if product.available %}
      <span>In stock</span>
    {% endif %}
  </div>
{% endfor %}

ಮೂರೂ ಟ್ಯಾಗ್‌ಗಳು ಮುಚ್ಚಲ್ಪಟ್ಟಿವೆ. ಈಗ ನೀವು ಬಹಳ ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ, ಡಾಕ್ಯುಮೆಂಟೇಶನ್‌ನಿಂದ ಸ್ನಿಪ್ಪಟ್‌ಗಳನ್ನು ಕಾಪಿ ಮತ್ತು ಪೇಸ್ಟ್ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸಿ, ಆಕಸ್ಮಿಕವಾಗಿ ಕೊನೆಯ r ಅನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟರೆ:

{% for product in collections.all.products %}
  <div class="card">
    <h2>{{ product.title }}</h2>
    {% if product.available %}
      <span>In stock</span>
  </div>
{% endfo %}

ಅಥವಾ ಬಹುಶಃ ನೀವು HTML ನ ದೊಡ್ಡ ಭಾಗದ ಕೆಳಗೆ ಇರುವುದರಿಂದ {% endfor %} ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮರೆತುಬಿಟ್ಟಿರಬಹುದು. ಎಂಜಿನ್ {% for % ಅನ್ನು ನೋಡುತ್ತದೆ, ಲೂಪ್ ಅನ್ನು ನೋಂದಾಯಿಸುತ್ತದೆ, ಆದರೆ ಅದರ ಜೋಡಿಯನ್ನು ಎಂದಿಗೂ ಕಂಡುಕೊಳ್ಳುವುದಿಲ್ಲ. Shopify ಸಂದರ್ಭದಲ್ಲಿ, ಇದರರ್ಥ ಇಡೀ ಥೀಮ್ ಕಂಪಿಲ್ ಆಗಲು ವಿಫಲವಾಗುತ್ತದೆ. Jekyll ನಲ್ಲಿ, GitHub Pages ನಿಮಗೆ ಬಿಲ್ಡ್ ಫೇಲ್ಯೂರ್ ಇಮೇಲ್ ಕಳುಹಿಸುತ್ತದೆ. ಲೋಕಲ್ ಡೆವಲಪ್‌ಮೆಂಟ್‌ನಲ್ಲಿ ಗೊಂದಲಮಯವಾದ ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್ (stack trace) ಕಾಣಿಸಿಕೊಳ್ಳಬಹುದು. ಮರೆತುಹೋದ ಒಂದು ಟ್ಯಾಗ್ ಇಡೀ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.

ಸಣ್ಣ ತಪ್ಪುಗಳ ಅಟ್ಟಹಾಸ

ಈ ದೋಷಗಳು ಅತ್ಯಂತ ಕಿರಿಕಿರಿ ಉಂಟುಮಾಡುತ್ತವೆ ಏಕೆಂದರೆ ಅವು ತಪ್ಪು的大小ಕ್ಕೆ ಅನುಗುಣವಾಗಿರುವುದಿಲ್ಲ. ನೀವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ತಪ್ಪಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿಲ್ಲ. ನೀವು ತಪ್ಪು ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಆರಿಸಿಲ್ಲ. ನೀವು ಕೇವಲ ಒಂದು ಅಕ್ಷರವನ್ನು ಮರೆತಿದ್ದೀರಿ. ಸಣ್ಣ ತಪ್ಪುಗಳು ದೊಡ್ಡ ಬಗ್‌ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ. ಆ ಮರೆತುಹೋದ {% endif %} ಕೇವಲ ಒಂದು ಸಾಲನ್ನು ಮಾತ್ರ ಹಾಳು ಮಾಡುವುದಿಲ್ಲ. ಅದು ಸರಪಳಿ ಪರಿಣಾಮವನ್ನು (cascade) ಉಂಟುಮಾಡುತ್ತದೆ. ಕಂಡಿಷನಲ್ ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಎಂಬ ಗೊಂದಲದಲ್ಲಿರುವ ಪಾರ್ಸರ್, ಅದರ ಕೆಳಗಿರುವ ಪ್ರತಿಯೊಂದು ಸಾಲನ್ನು ತಪ್ಪಾದದ್ದು ಎಂದು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಬಹುದು. ಇಪ್ಪತ್ತು ಸಾಲುಗಳ ಟೆಂಪ್ಲೇಟ್ ಇದ್ದರೂ, ಅದು ಅನಿರೀಕ್ಷಿತವಾಗಿ ಅರವತ್ತು ಸಾಲುಗಳ ದೋಷದ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಸೃಷ್ಟಿಸಬಹುದು, ಅದರಲ್ಲಿ ಹೆಚ್ಚಿನವು ದಾರಿ ತಪ್ಪಿಸುವಂತಿರುತ್ತವೆ.

ನೀವು ಕೇವಲ ಒಂದು ಅಕ್ಷರವನ್ನು ಮರೆತಾಗ ಇಂತಹ ದೋಷಗಳನ್ನು ಎದುರಿಸುತ್ತೀರಿ, ಮತ್ತು ನಿಮ್ಮ ಮೆದುಳು ಅಂತಹ ವಾಸ್ತವಕ್ಕೆ ಸಿದ್ಧವಿರುವುದಿಲ್ಲ. ಮನುಷ್ಯರು ಪ್ಯಾಟರ್ನ್ ಗುರುತಿಸುವಿಕೆಯ ಮೂಲಕ ಕೋಡ್ ಅನ್ನು ಓದುತ್ತಾರೆ. ನಾವು ಉದ್ದೇಶವನ್ನು ನೋಡುತ್ತೇವೆ. ನಾವು if ಮತ್ತು ಅದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ಲಾಜಿಕ್ ಅನ್ನು ನೋಡಿ ಅದರ ಗಡಿಯನ್ನು ಅಂದಾಜಿಸುತ್ತೇವೆ. ಆದರೆ ಕಂಪ್ಯೂಟರ್ ಅಂದಾಜಿಸುವುದಿಲ್ಲ. ಅದು ಅಂಬಿಗ್ಯುಟಿ (ambiguity) ಅಥವಾ ಅಸ್ಪಷ್ಟತೆಗೆ ಅವಕಾಶ ನೀಡದೆ, ಮೇಲಿನಿಂದ ಕೆಳಕ್ಕೆ ಅಕ್ಷರದಿಂದ ಅಕ್ಷರಕ್ಕೆ ಓದುತ್ತದೆ. ಪಾರ್ಟ್ನರ್ ಟ್ಯಾಗ್ ಕಾಯುತ್ತಲೇ ಫೈಲ್‌ನ ಅಂತ್ಯಕ್ಕೆ ತಲುಪಿದಾಗ, ಅದು ಸೋಲೊಪ್ಪಿಕೊಳ್ಳುತ್ತದೆ. ಆ ಅಂತರವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಪಾರ್ಸರ್‌ನಂತೆ ಯೋಚಿಸುವಂತಹ ಡೆವಲಪರ್ ಆಗುವುದು ನಿಮ್ಮ ಕೆಲಸ.

ಇದು ಕೇವಲ Liquid ಗೆ ಮಾತ್ರ ಸೀಮಿತವಾಗಿಲ್ಲ. Python ನಲ್ಲಿ ಮುಚ್ಚದ ಪ್ಯಾರೆಂಥೆಸಿಸ್ (parenthesis), Markdown ನಲ್ಲಿ ಮರೆತುಹೋದ ಬ್ಯಾಕ್‌ಟಿಕ್ (backtick), JavaScript ನಲ್ಲಿ ಮರೆತುಹೋದ ಬ್ರೇಸ್ (brace), ಅಥವಾ HTML ನಲ್ಲಿ ಬಾಕಿ ಉಳಿದ ಆಂಗಲ್ ಬ್ರಾಕೆಟ್ (angle bracket). ವಾರಾಂತ್ಯದ ಸವಾಲು ಕಲಿಕಾ ಉದ್ದೇಶಕ್ಕಾಗಿ Liquid ಅನ್ನು ಬಳಸಿದೆ, ಆದರೆ ಇದರ ಹಿಂದಿರುವ ಪಾಠ ನೀವು ಬಳಸುವ ಪ್ರತಿಯೊಂದು ಭಾಷೆಗೂ ಅನ್ವಯಿಸುತ್ತದೆ. ಸಿಂಟ್ಯಾಕ್ಸ್ ಎಂಬುದು ವ್ಯಾಕರಣವಿದ್ದಂತೆ, ಮತ್ತು ವ್ಯಾಕರಣವು ಎಂದಿಗೂ ಕ್ಷಮಿಸುವುದಿಲ್ಲ.

ಇವುಗಳನ್ನು ಹೇಗೆ ಪತ್ತೆಹಚ್ಚುವುದು

ನೀವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದಾಗ, ಮೊದಲ ಪ್ರವೃತ್ತಿ ಇಡೀ ಫೈಲ್ ಅನ್ನು ಗಾಬರಿಯಿಂದ ಓದುವುದಾಗಿರುತ್ತದೆ. ಅದನ್ನು ತಡೆಯಿರಿ. ಗಾಬರಿಯಿಂದ ಓದುವುದರಿಂದ ನಿಮ್ಮ ಮೆದುಳು ತಾನಾಗಿಯೇ ಅದನ್ನು ಸರಿಪಡಿಸಿಕೊಂಡು (autocorrect) ನೀವು ಮರೆತ ಅಕ್ಷರವನ್ನು ಗಮನಿಸದಂತೆ ಮಾಡುತ್ತದೆ. ಬದಲಾಗಿ, ವ್ಯವಸ್ಥಿತವಾಗಿ ಕೆಲಸ ಮಾಡಿ.

ನಿಮ್ಮ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸಿ. ಫೈಲ್ ಅನ್ನು ಪೂರ್ತಿಯಾಗಿ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಓಪನಿಂಗ್ ಟ್ಯಾಗ್ ಅನ್ನು ಜೋರಾಗಿ ಅಥವಾ ಕಾಗದದ ಮೇಲೆ ಬರೆದು ಹೆಸರಿಸಿಕೊಳ್ಳಿ. for ಗೆ endfor ಬೇಕು. if ಗೆ endif ಬೇಕು. unless ಗೆ endunless ಬೇಕು. capture ಗೆ endcapture ಬೇಕು. ನೀವು ಬ್ಲಾಕ್‌ಗಳನ್ನು ನೆಸ್ಟಿಂಗ್ (nesting) ಮಾಡುತ್ತಿದ್ದರೆ, ಮಾನಸಿಕವಾಗಿ ಒಂದು ಕೌಂಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತಾ ಹೋಗಿ. ನಾನು ಒಂದು for ಒಳಗಡೆ if ಅನ್ನು ತೆರೆದಾಗ, ಫೈಲ್ ಮುಗಿಯುವ ಮೊದಲು ನಾನು ಎರಡು ಬಾಧ್ಯತೆಗಳನ್ನು (obligations) ಪೂರೈಸಬೇಕಾಗುತ್ತದೆ.

ನಿಮ್ಮ ಎಡಿಟರ್ ಅನ್ನು ಬಳಸಿ. ನೀವು ನಿಯಮಿತವಾಗಿ Liquid ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ವ್ಯಾಕರಣವನ್ನು (grammar) ಗುರುತಿಸುವ ಸಿಂಟ್ಯಾಕ್ಸ್ ಹೈಲೈಟರ್ (syntax highlighter) ಅನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿಕೊಳ್ಳಿ. Visual Studio Code ನಲ್ಲಿ Liquid ಟ್ಯಾಗ್‌ಗಳನ್ನು ಮಸುಕುಗೊಳಿಸುವ ಅಥವಾ ಬಣ್ಣದ ಕೋಡ್ ಮಾಡುವ ಎಕ್ಸ್‌ಟೆನ್ಶನ್‌ಗಳಿವೆ. ಕ್ಲೋಸಿಂಗ್ ಟ್ಯಾಗ್ ತಪ್ಪಾಗಿದ್ದಾಗ, ಬಣ್ಣದ ಮಾದರಿಯು ಬದಲಾಗುತ್ತದೆ. ಕೆಲವು ಲಿಂಟರ್‌ಗಳು (linters) ನೀವು ಕಾಂಪೈಲ್ ಮಾಡುವ ಮೊದಲೇ ಮುಚ್ಚದ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬಲ್ಲವು. Vim ಅಥವಾ Neovim ನಲ್ಲಿ, vim-liquid ನಂತಹ ಪ್ಲಗಿನ್ ಅನ್ನು ಬಳಸಿ ಅಥವಾ ಹೊಂದಾಣಿಕೆಯ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡಲು Tree-sitter ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. ಈ ಪರಿಕರಗಳು ಯೋಚಿಸುವ ಅಗತ್ಯವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ, ಆದರೆ ಅವು ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿದ್ದಾಗ ಅದನ್ನು ದೃಶ್ಯೀಕರಿಸುತ್ತವೆ.

ನಿಮ್ಮ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಬೈನರಿ ಸರ್ಚ್ (Binary search) ಮಾಡಿ. ಎರರ್ ಮೆಸೇಜ್ ಲೈನ್ 200 ಅನ್ನು ತೋರಿಸುತ್ತಿದ್ದರೆ ಮತ್ತು ಅಲ್ಲಿ ಏನೂ ತಪ್ಪಾಗಿ ಕಾಣದಿದ್ದರೆ, ನಿಜವಾದ ಕಾರಣ ಬಹುಶಃ ಅದಕ್ಕಿಂತ ಮೇಲಿರುತ್ತದೆ. ಟೆಂಪ್ಲೇಟ್‌ನ ಕೆಳಭಾಗವನ್ನು ಕಾಮೆಂಟ್ (comment out) ಮಾಡಿ. ಅದು ಬಿಲ್ಡ್ ಆಗುತ್ತದೆಯೇ? ಹೌದಾದರೆ, ಎರರ್ ಕಾಮೆಂಟ್ ಮಾಡಿದ ಭಾಗದಲ್ಲಿದೆ. ಅದರ ಅರ್ಧ ಭಾಗವನ್ನು ಅನ್‌ಕಾಮೆಂಟ್ (uncomment) ಮಾಡಿ. ಕೆಟ್ಟುಹೋದ ಬ್ಲಾಕ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುವವರೆಗೆ ಇದನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಇದು ನಿಧಾನವೆಂದು ಅನಿಸಬಹುದು, ಆದರೆ ನಿಮ್ಮ ಹತಾಶೆ ಹೆಚ್ಚಾಗುತ್ತಿರುವಾಗ ಒಂದೇ ನೂರಾರು ಸಾಲುಗಳನ್ನು ಆರು ಬಾರಿ ಓದುವುದಕ್ಕಿಂತ ಇದು ವೇಗವಾಗಿರುತ್ತದೆ.

ನಿಮ್ಮ ಇನ್‌ಕ್ಲೂಡ್‌ಗಳನ್ನು (includes) ಪರಿಶೀಲಿಸಿ. Liquid {% include %} ಅಥವಾ {% render %} ಮೂಲಕ ಮಾಡ್ಯುಲರ್ ಫ್ರಾಗ್ಮೆಂಟ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಮುಚ್ಚದ ಟ್ಯಾಗ್ ಮುಖ್ಯ ಫೈಲ್‌ನಲ್ಲೇ ಇರಬೇಕೆಂದಿಲ್ಲ. ಅದು ಪೇರೆಂಟ್ ಟೆಂಪ್ಲೇಟ್ ಬಳಸುವ ಸ್ನಿಪ್ಪೆಟ್‌ನಲ್ಲೇ ಇರಬಹುದು. ಇಲ್ಲಿ ವರ್ಷನ್ ಕಂಟ್ರೋಲ್ (version control) ನಿಮ್ಮ ನೆಮ್ಮದಿಯನ್ನು ಉಳಿಸುತ್ತದೆ. ಒಂದು 'diff' ರನ್ ಮಾಡಿ. ಕೊನೆಯ ಯಶಸ್ವಿ ಬಿಲ್ಡ್‌ನಿಂದಾಗಿ ಏನಾದರೂ ಬದಲಾಗಿದೆಯೇ ಎಂದು ನೋಡಿ. ಹೆಚ್ಚಾಗಿ ಉತ್ತರವು ಕೆಂಪು ಮತ್ತು ಹಸಿರು ಬಣ್ಣಗಳಲ್ಲಿ ಎದ್ದು ಕಾಣುತ್ತದೆ.

ಇಂಡೆಂಟೇಶನ್ (Indentation) ಎಂಬುದು ಒಂದು ಡಾಕ್ಯುಮೆಂಟೇಶನ್. ನಿಮ್ಮ {% if %} ಕಾಲಂ ಸೊನ್ನೆಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ {% endif %} ನೆಸ್ಟೆಡ್ ಸ್ಟ್ರಕ್ಚರ್‌ನ ಒಳಗಡೆ ಎಲ್ಲಿಯೋ ಇಂಡೆಂಟ್ ಆಗಿದ್ದರೆ, ದೃಶ್ಯ ಜೋಡಣೆಯು (visual alignment) ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿದ್ದಾಗ ಅದನ್ನು ಗಮನಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ HTML ಮತ್ತು Liquid ಟ್ಯಾಗ್‌ಗಳು ಒಂದೇ ಇಂಡೆಂಟೇಶನ್ ಸ್ಕೀಮ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ತಪ್ಪಾದ ಆಳದಲ್ಲಿರುವ ಟ್ಯಾಗ್ ಅನ್ನು ನಿಮ್ಮ ಕಣ್ಣುಗಳು ಸುಲಭವಾಗಿ ಪತ್ತೆಹಚ್ಚುತ್ತವೆ.

ನಿಜವಾದ ಪಠ್ಯಕ್ರಮ (The Real Curriculum)

ವೀಕೆಂಡ್ ಚಾಲೆಂಜ್‌ಗಳು ಮುಖ್ಯವಾಗಿವೆ ಏಕೆಂದರೆ ಅವು ನೀವು ನಿಜವಾಗಿಯೂ ಕೆಲಸ ಮಾಡುವ ಪರಿಸ್ಥಿತಿಗಳನ್ನೇ ಮರುಸೃಷ್ಟಿಸುತ್ತವೆ. ಯಾವುದೇ ಮ್ಯಾನೇಜರ್ ಗಮನಿಸುತ್ತಿರುವುದಿಲ್ಲ. ಯಾವುದೇ ಡೆಡ್‌ಲೈನ್ ಒತ್ತಡವಿರುವುದಿಲ್ಲ. ನೀವು ಕೌಶಲ್ಯಕ್ಕಾಗಿ ಅಥವಾ ಮೋಜಿಗಾಗಿ ಕೋಡಿಂಗ್ ಮಾಡುತ್ತಿದ್ದೀರಿ, ಮತ್ತು ಆಗ ಒಂದು ಸೂಕ್ಷ್ಮ ದೋಷವು ನಿಮ್ಮನ್ನು ತಡೆಹಿಡಿಯುತ್ತದೆ. ಆ ಕ್ಷಣವೇ ಪಾಠ. ನೀವು ಡಿಬಗ್ ಮಾಡುವುದರ ಬಗ್ಗೆ ಓದಿದ ಮಾತ್ರಕ್ಕೆ ಡಿಬಗ್ ಮಾಡುವುದನ್ನು ಕಲಿಯುವುದಿಲ್ಲ. ನೀವು ಹೊರಗಡೆ ಇರಲು ಬಯಸುವಾಗ, ಒಂದು ಕೆಟ್ಟುಹೋದ ಬಿಲ್ಡ್ ಅನ್ನು ದಿಟ್ಟಿಸಿ ನೋಡುವುದರ ಮೂಲಕ ಕಲಿಯುತ್ತೀರಿ; ಅಲ್ಲಿ ಎರರ್ ಮೆಸೇಜ್ ಅನ್ನು ಟೀಕೆಯಾಗಿ ನೋಡುವ ಬದಲು ಡೇಟಾವಾಗಿ ಪರಿಗಣಿಸಲು ನಿಮ್ಮನ್ನು ನೀವು ಒತ್ತಾಯಿಸಿಕೊಳ್ಳುತ್ತೀರಿ.

ಈ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಲು ಕಲಿಯಿರಿ ಏಕೆಂದರೆ ಅವು ಎಂದಿಗೂ ಸಂಪೂರ್ಣವಾಗಿ ಮಾಯವಾಗುವುದಿಲ್ಲ. ವೃತ್ತಿಜೀವನದ ಹತ್ತು ವರ್ಷಗಳ ನಂತರವೂ, ಶುಕ್ರವಾರ ರಾತ್ರಿಯ ಡಿಪ್ಲಾಯ್ ಸಮಯದಲ್ಲಿ ನೀವು ಕ್ಲೋಸಿಂಗ್ ಟ್ಯಾಗ್ ಅನ್ನು ಮರೆಯಬಹುದು. ಜೂನಿಯರ್ ಮತ್ತು ಸೀನಿಯರ್ ಡೆವಲಪರ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ತಪ್ಪುಗಳಿಲ್ಲದಿರುವುದಲ್ಲ, ಬದಲಾಗಿ ತಪ್ಪುಗಳನ್ನು ಸರಿಪಡಿಸುವ ವೇಗವಾಗಿದೆ. ಸೀನಿಯರ್ ಸಿಂಟ್ಯಾಕ್ಸ್ ಎರರ್ ಅನ್ನು ನೋಡಿ, ಮಾದರಿಯನ್ನು ಗುರುತಿಸಿ, ಸ್ಪಷ್ಟವಾದ ಸಂಶಯಾಸ್ಪದ ಅಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಮುಂದೆ ಸಾಗುತ್ತಾರೆ. ಜೂನಿಯರ್ ಇಡೀ ಟೂಲ್‌ಚೈನ್ (toolchain) ಕೆಟ್ಟುಹೋಗಿದೆಯೇ ಎಂದು ಯೋಚಿಸುತ್ತಾ ಕುಳಿತುಕೊಳ್ಳುತ್ತಾರೆ. ಪುನರಾವರ್ತನೆಯು ಅಂತಹ ಪ್ರತಿಫಲವನ್ನು (reflex) ಬೆಳೆಸುತ್ತದೆ.

ಸಮುದಾಯದ ಅಂಶವು ಇದನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ. ವೀಕೆಂಡ್‌ನಲ್ಲಿ ಅನೇಕ ಜನರು ಒಂದೇ ಕೆಟ್ಟುಹೋದ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಎದುರಿಸಿದಾಗ, ಒಬ್ಬಂಟಿ ಡೆವಲಪರ್‌ಗೆ ಕಾಣದ ಮಾದರಿಗಳು ಹೊರಹೊಮ್ಮುತ್ತವೆ. ನೆಸ್ಟೆಡ್ for ಲೂಪ್‌ಗಳ ಒಳಗೆ ಮಾತ್ರ ಈ ಎರರ್ ಉಂಟಾಗುತ್ತದೆ ಎಂದು ಯಾರಾದರೂ ಗಮನಿಸಬಹುದು. ಸಾಮಾನ್ಯ Liquid ಟ್ಯಾಗ್ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿದ್ದಾಗ ಅದನ್ನು ಪತ್ತೆಹಚ್ಚಲು (grep) ಯಾರೋ ಶೆಲ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳಬಹುದು. ಜ್ಞಾನವನ್ನು ಸಂಗ್ರಹಿಸುವುದಕ್ಕಿಂತ ಹಂಚಿಕೊಂಡಾಗ ಅದು ವೃದ್ಧಿಯಾಗುತ್ತದೆ. ನೀವು ನಿರ್ದಿಷ್ಟ ಸವಾಲಿನ ಸಂಪೂರ್ಣ ವಿವರಗಳನ್ನು ಓದಬಹುದು ಮತ್ತು ಇತರರು ಅದನ್ನು ಹೇಗೆ ಎದುರಿಸಿದರು ಎಂಬುದನ್ನು Dev.to ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನೋಡಬಹುದು. ನೀವು ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿರುವ ಜನರೊಂದಿಗೆ ಚರ್ಚಿಸಲು ಬಯಸಿದರೆ, Telegram ನಲ್ಲಿ ಒಂದು ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯವಿದೆ, ಅಲ್ಲಿ ಈ ಚರ್ಚೆಗಳು ವೀಕೆಂಡ್ ನಂತರವೂ ಮುಂದುವರಿಯುತ್ತವೆ.

ಸಾರಾಂಶ (The Takeaway)

ಸಿಂಟ್ಯಾಕ್ಸ್ ಎರರ್‌ಗಳನ್ನು ನಿಮ್ಮ ನಿಜವಾದ ಕೆಲಸಕ್ಕೆ ಅಡ್ಡಿ ಎಂದು ಪರಿಗಣಿಸಬೇಡಿ. ಅವು ಮೂಲಭೂತ ಕೆಲಸಗಳೇ ಆಗಿವೆ. ಈ ವೀಕೆಂಡ್ ಬಿಲ್ಡ್ ಅನ್ನು ಕೆಡಿಸಿದ Liquid ಟ್ಯಾಗ್ ಕೇವಲ ಟೆಂಪ್ಲೇಟ್ ಇಂಜಿನ್ ಬಗ್ಗೆ ಇರಲಿಲ್ಲ. ಅದು ನಿಮ್ಮ ಮೆದುಳು ಊಹಿಸಲು ಬಯಸುವಾಗ, ನಿಖರವಾಗಿ ಓದಲು ನಿಮ್ಮನ್ನು ನೀವು ತರಬೇತುಗೊಳಿಸುವುದರ ಬಗ್ಗೆ ಇತ್ತು. ನೀವು ಕಳೆದ ವಾರ ಬರೆದ ಫೈಲ್ ಅನ್ನು ತೆರೆಯಿರಿ. ನೀವು ತೆರೆದ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಹುಡುಕಿ. ಪ್ರತಿಯೊಂದೂ ಸರಿಯಾಗಿ ಮುಚ್ಚಲ್ಪಟ್ಟಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ ಲೂಪ್‌ಗಳನ್ನು ಮುಚ್ಚಿ. ನಿಮ್ಮ ಕಂಡೀಷನಲ್‌ಗಳನ್ನು (conditionals) ಪೂರ್ಣಗೊಳಿಸಿ. ನಂತರ, ಒಂದೊಂದೇ ಸರಿಯಾದ ಅಕ್ಷರಗಳೊಂದಿಗೆ ಮತ್ತೆ ಬಿಲ್ಡ್ ಮಾಡುವುದಕ್ಕೆ ಮರಳండి.