டெவ் லாக்: MCP, மின்னஞ்சல் கண்காணிப்பு (Email Tracking), மற்றும் மெனு அமைப்பு (Menu Structure)
இன்று நான் MCP சர்வர்கள், தானியங்கி மின்னஞ்சல் கண்காணிப்பு மற்றும் அளவிடக்கூடிய (scalable) அட்மின் மெனுக்களை உருவாக்குவதில் நேரத்தைச் செலவிட்டேன்.
அந்தப் பணியிலிருந்து கிடைத்த முக்கிய பாடங்கள் இதோ.
MCP சர்வர் பாதுகாப்பு
நான் ஒரு பொதுவான MCP டூல் பாக்ஸை (toolbox) உருவாக்கி, பல நிறுவன செயலிகளில் (enterprise apps) சர்வர்களைப் பயன்படுத்தினேன். உங்கள் அமைப்புகளுடன் (systems) தொடர்பு கொள்ளக்கூடிய ஏஜெண்டுகளை (agents) உருவாக்கும்போது, இந்த விதிகளைப் பின்பற்றவும்:
- ஏஜெண்டுகளுக்கு 'read' கருவிகளைத் தாராளமாக வழங்கவும்.
- 'write' கருவிகளை மிகக் குறைவாகவே வழங்கவும்.
- ஒவ்வொரு 'write' செயல்பாட்டையும் மனிதத் தலையீட்டுடன் கூடிய ஒரு ரன்புக்கின் (runbook) மூலம் மட்டுமே செய்யச் செய்யவும்.
- உங்கள்
create-userகருவிகளில் கடவுச்சொற்களை ஹேஷ் (hash) செய்யவும். ஒருபோதும் பிளைன் டெக்ஸ்டாக (plaintext) சேமிக்க வேண்டாம். - ஆடிட் லாக்ஸிற்கு (audit logs) பொதுவான UUID-களைப் பயன்படுத்தவும். உள் தரவுத்தள ஐடிகளை (internal database IDs) ஒருபோதும் வெளிப்படுத்த வேண்டாம்.
- பயனர் சூழலுக்காக (user context) ஒரு ஃபால்பேக் (fallback) முறையைப் பயன்படுத்தவும். ஒரு ஏஜென்ட் HTTP அல்லது STDIO-வைப் பயன்படுத்தலாம். உங்கள் குறியீடு இரண்டையும் கையாளுகிறதா என்பதை உறுதிப்படுத்தவும்.
கைமுறை வேலை இன்றி மின்னஞ்சல் கண்காணிப்பு
மின்னஞ்சல்கள் திறக்கப்படுவதையும் (opens) கிளிக் செய்யப்படுவதையும் (clicks) தானாகவே கண்காணிக்கும் ஒரு அமைப்பை நான் உருவாக்கினேன். ஒவ்வொரு மின்னஞ்சலிலும் டெவலப்பர்களை டிராகிங் பிக்சல்களை (tracking pixels) சேர்க்கச் செய்யாதீர்கள். அதற்குப் பதிலாக, ஒரு மெயில்-செண்டிங் லிசனர் (mail-sending listener)-ஐப் பயன்படுத்தவும்.
- லிசனர் செய்தியை இடைமறிக்கும்.
- அது HTML-க்குள் டிராகிங் பிக்சலைச் சேர்க்கும்.
- கிளிக் கண்காணிப்பிற்காக அது அனைத்து இணைப்புகளையும் (links) மாற்றியமைக்கும்.
- எளிதானத் தொடர்பிற்காக (correlation) அது ஒரு மெட்டாடேட்டா ஹேஷைச் (metadata hash) சேர்க்கும்.
இரண்டு முக்கியமான குறிப்புகள்:
Mail::raw()-ஐத் தவிர்க்கவும். இது HTML மாற்றியமைக்கும் பாதையைத் தவிர்க்கிறது. கண்காணிப்பு சரியாகச் செயல்படுவதை உறுதி செய்ய முறையான HTML Mailables-ஐப் பயன்படுத்தவும்.- கண்காணிப்பை இயல்பாகவே (by default) "on"-இல் வைக்கவும். பயனர்கள் அதைச் செயல்படுத்த வேண்டியிருந்தால், அவர்கள் மறந்துவிடுவார்கள்.
அளவிடக்கூடிய அட்மின் மெனுக்கள்
பல செயலிகளில் மெனுக்களை நிர்வகிக்கும்போது, ஒரே பெரிய கோப்பைப் பயன்படுத்தாதீர்கள். ஒவ்வொரு குழுவிற்கும் சிறிய பில்டர் வகுப்புகளைப் (builder classes) பயன்படுத்தவும்.
- ஒவ்வொரு குழுவிற்கும் ஒரு வகுப்பை உருவாக்கவும் (எ.கா., Settings, User Management).
- ஒவ்வொரு வகுப்பும் அதன் சொந்த உருப்படிகளையும் (items) தேவையான அனுமதிகளையும் (permissions) அறிவிக்கும்.
- இது உங்கள் நேவிகேஷனை (navigation) டெக்ளரேட்டிவ் (declarative) ஆக வைத்திருக்கும்.
- நீண்ட லேபிள்களை (labels) ஒவ்வொரு உருப்படிக்கும் தனித்தனியாகச் செய்யாமல், காம்பொனென்ட் (component) உள்ளேயே சுருக்கவும்.
- கருவிகளை இரண்டு சோதனைகளின் மூலம் கட்டுப்படுத்தவும்: பயனர் அனுமதிகள் மற்றும் குறிப்பிட்ட ஆப் எடிஷன் (app edition).
ஒட்டுமொத்தப் பார்வை
பாதுகாப்பு வலையை (safety net) தானியக்கமாக்குவதே இதன் இலக்காகும்.
ஒரு கண்டறியும் கருவி (diagnostic tool) பயனுள்ளதாக இருந்தால், அதை இயல்பாகவே ஆன் செய்யவும். அதை ஆன் செய்ய நீங்கள் நினைவில் கொள்ள வேண்டும் என்றால், அதிகாலை 2 மணிக்கு ஒரு சிஸ்டம் செயலிழக்கும்போது அது உங்களிடம் இருக்காது. உங்கள் பாடங்களை உங்கள் கருவிகளிலேயே குறியீடாக (encode) இணைத்துவிடுங்கள், அப்போது நீங்கள் அவற்றை மீண்டும் கற்க வேண்டியிருக்காது.