சனிக்கிழமை மதியம். நீங்கள் காபியுடன் அமர்ந்து, ஒரு புதிய வசதியை (feature) விரைவாக முடிப்பதாகவோ அல்லது ஒரு பக்கத் திட்டத்தை (side project) இறுதியாக மெருகேற்றுவதாகவோ முழு மனதுடன் திட்டமிடுகிறீர்கள். பத்து நிமிடங்களில் எல்லாம் நின்றுவிடுகிறது. தர்க்கம் (logic) மிகவும் சிக்கலானதாலோ அல்லது நீங்கள் அந்த கட்டமைப்பை (framework) புரிந்து கொள்ளாததாலோ அல்ல. ஒரு டேக் (tag) மட்டும் சரியாக மூடப்படாததால் முன்னேற்றம் முடங்குகிறது.

இந்த வார இறுதி சவாலில் நடந்தது இதுதான். ஒரு Liquid தொடரியல் பிழை (syntax error). அந்த டேக் சரியாக மூடப்படவில்லை. பார்ஸர் (parser) கோப்பைச் சரிபார்த்தபோது, ஒரு மூடும் வரிசையை (closing sequence) எதிர்பார்த்த இடத்தில் எதையும் காணவில்லை. அவ்வளவுதான், பில்ட் (build) தோல்வியடைந்தது. இது அனுபவம் வாய்ந்த டெவலப்பர்களையும் பணிவடையச் செய்யும், மேலும் இதைக் கண்டறிந்தவுடன் சரிசெய்ய சில வினாடிகள் மட்டுமே ஆனாலும், ஆரம்பநிலை டெவலப்பர்களை சுய சந்தேகத்தில் ஆழ்த்தும் ஒரு வகை பிழை.

பின்னணியில் என்ன நடந்தது

Liquid என்பது Shopify உருவாக்கிய ஒரு டெம்ப்ளேட்டிங் மொழி (templating language), இது இ-காமர்ஸ் ஸ்டோர்ஃபிரண்ட்கள் முதல் GitHub Pages-ல் உள்ள Jekyll அடிப்படையிலான பிளாக்குகள் வரை அனைத்தையும் இயக்குகிறது. இது இரண்டு முக்கிய தொடரியல் முறைகளைச் சார்ந்துள்ளது. {{ page.title }} போன்ற இரட்டை வளைவு அடைப்புக்குறிகள் (double curly braces) வெளியீட்டைக் கையாளுகின்றன. {% if user %} அல்லது {% for item in list %} போன்ற வளைவு அடைப்புக்குறி மற்றும் சதவீத குறிகள் (curly brace percent signs) தர்க்கம் மற்றும் ஓட்டக் கட்டுப்பாட்டை (logic and flow control) கையாளுகின்றன.

ஒவ்வொரு தொடக்க டேக்கிற்கும் (opening tag) ஒரு ஜோடி தேவை. ஒரு {% if %}-க்கு {% endif %} தேவை. ஒரு {% for %} லூப்பிற்கு (loop) {% endfor %} தேவை. ஒரு கேப்சர் பிளாக்கிற்கு (capture block) {% endcapture %} தேவை. இவை வெறும் பரிந்துரைகள் அல்ல. Liquid என்ஜின் (engine) உங்கள் டெம்ப்ளேட்டை வரிசையாகப் படிக்கிறது. ஒரு தொடக்கக் கட்டமைப்பைக் காணும்போது, அது தனது உள் ஸ்டாக்கில் (internal stack) ஒரு பிரேமைச் சேர்த்து காத்திருக்கும். கோப்பு முடிந்துவிட்டாலோ, அல்லது எதிர்பார்க்கப்பட்ட டேக் தோன்றுவதற்கு முன்பே மற்றொரு முக்கிய பிளாக் (block) மூடப்பட்டாலோ, என்ஜின் பிழையைக் காட்டும். செய்தி பெரும்பாலும் நேரடியாக இருக்கும்: tag was not closed correctly. சிஸ்டம் ஒரு மூடும் வரிசையை எதிர்பார்த்தது. சில நேரங்களில் ஒரு வரி எண் (line number) கிடைக்கும். சில நேரங்களில் அந்த வரி எண் தவறான இடத்தைக் காட்டலாம், ஏனெனில் பார்ஸர் அனைத்தையும் படித்து முடித்த பின்னரே அந்தத் துணை டேக் விடுபட்டுள்ளது என்பதை உணர்கிறது.

ஒரு நிஜமான உதாரணத்தைப் பார்ப்போம். நீங்கள் இப்படி எழுதலாம்:

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

மூன்று டேக்குகளும் மூடப்பட்டுள்ளன. இப்போது நீங்கள் வேகமாகச் செயல்படும்போது, ஆவணங்களிலிருந்து (documentation) துணுக்குகளை (snippets) நகலெடுத்து ஒட்டும்போது, தவறுதலாக கடைசி 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 சூழலில், இது முழு தீமும் (theme) கம்பைல் (compile) ஆவதைத் தடுக்கும். Jekyll-ல், GitHub Pages உங்களுக்கு பில்ட் தோல்வி குறித்த மின்னஞ்சலை அனுப்பும். லோக்கல் டெவலப்மெண்டில் (Local development) ஒரு புரியாத ஸ்டாக் ட்ரேஸ் (stack trace) வரலாம். ஒரு மறக்கப்பட்ட டேக் முழுத் தொடர்வினையையும் (pipeline) நிறுத்திவிடும்.

சிறிய தவறுகளின் கொடுமை

இந்தத் தவறுகள் எவ்வளவு எரிச்சலூட்டுகின்றன என்றால், பிழையின் அளவு சிறியதாக இருந்தாலும் அதன் பாதிப்பு பெரியதாக இருக்கும். நீங்கள் தரவுத்தளத்தை (database) தவறாக வடிவமைக்கவில்லை. நீங்கள் தவறான அல்காரிதத்தைத் (algorithm) தேர்ந்தெடுக்கவில்லை. நீங்கள் ஒரு எழுத்தைத் தவறிவிட்டீர்கள். சிறிய தவறுகள் பெரிய பிழைகளை உண்டாக்குகின்றன. அந்த விடுபட்ட {% endif %} ஒரு வரியை மட்டும் பாதிக்காது. அது ஒரு தொடர் விளைவை (cascade) ஏற்படுத்தும். நிபந்தனை (conditional) எங்கு முடிகிறது என்பதில் பார்ஸர் குழப்பமடைந்து, அதற்கு கீழே உள்ள ஒவ்வொரு வரியையும் தவறானதாகக் கருதலாம். இருபது வரிகள் கொண்ட ஒரு டெம்ப்ளேட் திடீரென அறுபது வரிகள் கொண்ட பிழை வெளியீட்டை உருவாக்கும், அதில் பெரும்பாலானவை தவறான திசையைக் காட்டும்.

நீங்கள் ஒரு எழுத்தைத் தவவிடும்போது இத்தகைய பிழைகளைச் சந்திக்கிறீர்கள், உங்கள் மூளை அந்தத் தற்போதைய நிலைக்குத் தயாராக இருப்பதில்லை. மனிதர்கள் குறியீட்டை (code) வடிவ அங்கீகாரத்தின் (pattern recognition) மூலம் படிக்கிறார்கள். நாம் நோக்கத்தைப் பார்க்கிறோம். if மற்றும் அதற்குப் பொருத்தமான தர்க்கத்தைப் பார்த்து, அதன் எல்லையை நாம் ஊகித்து விடுகிறோம். கணினி அவ்வாறு ஊகிப்பதில்லை. அது ஒவ்வொரு எழுத்தாக, மேலிருந்து கீழாக, எந்தத் தெளிவற்ற தன்மையையும் (ambiguity) அனுமதிக்காமல் படிக்கிறது. ஒரு ஜோடி டேக்கிற்காகக் காத்திருக்கும் நிலையில் கோப்பின் முடிவை எட்டும்போது, அது

உங்கள் டேக்குகளை (tags) துல்லியமாகப் பொருத்துங்கள். கோப்பை முழுமையாகப் பார்த்து, ஒவ்வொரு தொடக்க டேக்கையும் (opening tag) சத்தமாகவோ அல்லது காகிதத்திலோ குறித்துக் கொள்ளுங்கள். for-க்கு endfor தேவை. if-க்கு endif தேவை. unless-க்கு endunless தேவை. capture-க்கு endcapture தேவை. நீங்கள் பிளாக்குகளை (blocks) ஒன்றன் மேல் ஒன்றாக அடுக்குகிறீர்கள் (nesting) என்றால், மனதிற்குள் ஒரு எண்ணாட்டியை (counter) அதிகரித்துக் கொண்டே இருங்கள். ஒரு for-க்குள் நான் ஒரு if-ஐத் தொடங்கினால், கோப்பு முடிவதற்குள் நான் முடிக்க வேண்டிய இரண்டு கடமைகள் உள்ளன என்று அர்த்தம்.

உங்கள் எடிட்டரைப் பயன்படுத்துங்கள். நீங்கள் வழக்கமாக Liquid-உடன் பணிபுரிபவர் என்றால், அதன் இலக்கணத்தை (grammar) அடையாளம் காணும் ஒரு syntax highlighter-ஐ நிறுவுங்கள். Visual Studio Code-இல் Liquid டேக்குகளை மங்கலாக்க அல்லது வண்ணக் குறியீடாக மாற்ற உதவும் extensions உள்ளன. ஒரு முடிவு டேக் (closing tag) தவறாக இருக்கும்போது, வண்ண அமைப்பு மாறிவிடும். சில linters-கள் நீங்கள் compile செய்வதற்கு முன்பே முடிக்கப்படாத பிளாக்குகளைக் கண்டறிய முடியும். Vim அல்லது Neovim பயன்படுத்துபவர்கள், vim-liquid போன்ற ஒரு plugin-ஐப் பயன்படுத்தலாம் அல்லது பொருத்தமான டேக்குகளை முன்னிலைப்படுத்த Tree-sitter-ஐ உள்ளமைக்கலாம் (configure). இந்தத் கருவிகள் நீங்கள் சிந்திக்க வேண்டிய அவசியத்தை நீக்கிவிடாது, ஆனால் பிழைகளைத் தெளிவாகக் காட்டும்.

உங்கள் டெம்ப்ளேட்டை பைனரி சர்ச் (binary search) செய்யுங்கள். பிழைச் செய்தி 200-வது வரியைக் காட்டுகிறது, ஆனால் அங்கு எதுவும் தவறாகத் தெரியவில்லை என்றால், உண்மையான காரணம் அதற்கு மேலே இருக்கலாம். டெம்ப்ளேட்டின் கீழ் பாதியை கமெண்ட் (comment out) செய்துவிடுங்கள். அது சரியாக இயங்குகிறதா? ஆம் என்றால், பிழை கமெண்ட் செய்யப்பட்ட பாதியில் உள்ளது. அதில் பாதியை மட்டும் அன்-கமெண்ட் (uncomment) செய்யுங்கள். பிழையுள்ள பகுதியைத் தனிமைப்படுத்தும் வரை இதைத் தொடருங்கள். இது மெதுவாகத் தோன்றலாம், ஆனால் உங்கள் விரக்தி அதிகரித்துக் கொண்டே இருக்கும்போது, அதே இருநூறு வரிகளை ஆறு முறை வாசிப்பதை விட இது வேகமானது.

உங்கள் includes-களைச் சரிபார்க்கவும். Liquid, {% include %} அல்லது {% render %} மூலம் மாடுலர் துண்டுகளை (modular fragments) ஆதரிக்கிறது. முடிக்கப்படாத டேக் முக்கிய கோப்பிலேயே இல்லாமல் இருக்கலாம். அது முதன்மை டெம்ப்ளேட் கொண்டு வரும் ஒரு ஸ்னிப்பட் (snippet)-க்குள் இருக்கலாம். இங்கேயே version control உங்கள் மன அமைதியைக் காப்பாற்றுகிறது. ஒரு diff-ஐ இயக்கவும். கடைசியாக வெற்றிகரமாகப் பதிவேற்றியதிலிருந்து (build) என்ன மாறியுள்ளது என்று பாருங்கள். பெரும்பாலும் விடை சிவப்பு மற்றும் பச்சை நிறங்களில் பளிச்சென்று தெரியும்.

இண்டன்டேஷன் (Indentation) என்பது ஒரு ஆவணம் போன்றது. உங்கள் {% if %} பூஜ்ஜியக் கட்டத்தில் (column zero) தொடங்கி, அதற்கு இணையான {% endif %} ஒரு நெஸ்டட் கட்டமைப்பிற்குள் (nested structure) இண்டன்டேஷன் செய்யப்பட்டிருந்தால், காட்சித் தொடர்ச்சி (visual alignment) மூலம் அந்தப் பொருத்தமின்மையைக் கண்டறிய முடியும். உங்கள் HTML மற்றும் Liquid டேக்குகள் ஒரே இண்டன்டேஷன் முறையைப் பின்பற்றினால், தவறான ஆழத்தில் (depth) இருக்கும் டேக்கை உங்கள் கண்கள் எளிதில் கண்டுபிடித்துவிடும்.

உண்மையான பாடத்திட்டம்

வார இறுதி சவால்கள் (Weekend challenges) முக்கியமானவை, ஏனெனில் அவை நீங்கள் உண்மையில் பணிபுரியும் அதே சூழலையே மீண்டும் உருவாக்குகின்றன. எந்த மேலாளரும் உங்களைக் கண்காணிக்கவில்லை. எந்த காலக்கெடுவும் (deadline) நெருங்கவில்லை. நீங்கள் திறனுக்காகவோ அல்லது பொழுதுபோக்கிற்காகவோ குறியீடு (coding) செய்கிறீர்கள், அப்போது ஒரு மிகச்சிறிய பிழை உங்களை அப்படியே நிறுத்திவிடுகிறது. அந்தத் தருணமே ஒரு பாடம். பிழைத்திருத்தம் (debugging) பற்றிப் படிப்பதன் மூலம் நீங்கள் அதைத் கற்றுக்கொள்ள முடியாது. நீங்கள் வெளியே சென்று விளையாட விரும்பும் நேரத்தில், ஒரு தோல்வியடைந்த பில்டையே (broken build) உற்று நோக்கி, பிழைச் செய்தியை ஒரு விமர்சனமாகப் பார்க்காமல் தரவாக (data) மாற்றத் தொடங்கும் போதுதான் நீங்கள் அதைக் கற்கிறீர்கள்.

இந்தத் தவறுகளைச் சரிசெய்யக் கற்றுக்கொள்ளுங்கள், ஏனெனில் அவை ஒருபோதும் முழுமையாக மறைந்துவிடாது. பத்து வருட அனுபவம் பெற்ற பிறகும், ஒரு வெள்ளிக்கிழமை இரவு டெப்ளாய் (deploy) செய்யும் போது நீங்கள் ஒரு முடிவு டேக்கை மறக்கலாம். ஒரு ஜூனியர் மற்றும் சீனியர் டெவலப்பருக்கு இடையிலான வேறுபாடு தவறுகள் செய்யாமல் இருப்பது அல்ல; மாறாக, பிழையிலிருந்து மீண்டு வரும் வேகம் தான். சீனியர் அந்தச் தொடரியல் பிழையை (syntax error) பார்த்து, அதன் முறையை (pattern) அடையாளம் கண்டு, சந்தேகிக்கக்கூடிய விஷயங்களைச் சரிபார்த்துவிட்டு அடுத்த கட்டத்திற்குச் செல்வார். ஜூனியர், முழு டூல்செயினே (toolchain) உடைந்துவிட்டதோ என்று குழம்புவார். பயிற்சியே அந்தத் திறனை (reflex) வளர்க்கும்.

சமூகத் தொடர்பு (community aspect) இதை வேகப்படுத்துகிறது. வார இறுதியில் பலரும் ஒரே பிழையுள்ள டெம்ப்ளேட்டைச் சரிசெய்ய முயலும்போது, ஒரு தனி டெவலப்பரால் காண முடியாத புதிய முறைகள் வெளிப்படும். ஒரு பிழை நெஸ்டட் for லூப்களுக்குள் மட்டுமே நிகழ்கிறது என்பதை ஒருவர் கவனிக்கலாம். மற்றொருவர் பொதுவான Liquid டேக் பொருத்தமின்மைகளைக் கண்டறிய உதவும் ஒரு shell script-ஐப் பகிரலாம். அறிவு என்பது சேமித்து வைப்பதல்ல, பகிர்ந்து கொள்வதே அதன் பலம். குறிப்பிட்ட சவாலின் முழு விவரங்களையும் மற்றவர்கள் அதை எவ்வாறு அணுகினார்கள் என்பதையும் நீங்கள் இந்த Dev.to பதிவில் படிக்கலாம். இதே போன்ற சிக்கல்களைத் தீர்க்கும் மற்றவர்களுடன் கலந்துரையாட விரும்பினால், டெலிகிராமில் ஒரு விருப்பத்தேர்வு கற்றல் சமூகம் உள்ளது, அங்கு இந்த விவாதங்கள் வார இறுதிக்குப் பிறகும் தொடரும்.

சுருக்கம்

தொடரியல் பிழைகளை (syntax errors) உங்கள் உண்மையான வேலைக்கான இடையூறாகக் கருதாதீர்கள். அவை அடிப்படை வேலைகளே. இந்த வார இறுதியில் பில்டைப் பாதித்த Liquid டேக் என்பது டெம்ப்ளேட் என்ஜின் பற்றியது மட்டுமல்ல. உங்கள் மூளை யூகிக்க நினைக்கும் போது, துல்லியமாக வாசிக்க உங்களை நீங்களே பயிற்றுவிப்பதே அதன் நோக்கம். கடந்த வாரம் நீங்கள் எழுதிய ஒரு கோப்பைத் திறக்கவும். நீங்கள் தொடங்கிய டேக்குகளைத் தேடிப் பாருங்கள். ஒவ்வொன்றும் சரியாக முடிக்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். உங்கள் லூப்களை (loops) மூடுங்கள். உங்கள் கண்டிஷனல்களை (conditionals) சரிசெய்யுங்கள். பிறகு, ஒவ்வொரு சரியான எழுத்தையும் கொண்டு மீண்டும் உருவாக்கத் தொடங்குங்கள்.