cloudmato.com हे एक संशोधन-आधारित तंत्रज्ञान ब्लॉग आहे. प्रत्येक लेख थेट वेब स्रोतांद्वारे संशोधन करून, उद्धृत संदर्भांसह लिहिला जातो — वेब डेव्हलपमेंट, ब्राउझर इंटर्नल्स, नेटवर्किंग, सुरक्षा, डेटाबेस, डिस्ट्रिब्युटेड सिस्टम्स आणि सॉफ्टवेअर तयार करण्याची पद्धत बदलणारी AI साधने व मॉडेल्स यांचा समावेश करत.

लेख इंग्रजी, हिंदी आणि मराठीत प्रकाशित केले जातात, जेणेकरून एकच संशोधन अधिक वाचकांपर्यंत त्यांच्या आवडत्या भाषेत पोहोचेल.

खाली सर्व लेख पाहा, किंवा विषय सुचवा.

Chrome DevTools स्टोरेज: प्रत्येक यंत्रणा सोप्या भाषेत (वापराच्या उदाहरणांसह)
DevTools उघडा, Application वर क्लिक करा, आणि डाव्या बाजूच्या साइडबारकडे पाहा. Cookies, Local Storage, Session Storage, IndexedDB, Cache Storage, Shared Storage, Background Services… खूप काही आहे. मी अनुभवी डेव्हलपर्सनासुद्धा प्रत्येक गोष्टीसाठी localStorage वापरताना पाहिलं आहे — मग ते ऑथ टोकन्स असोत, शॉपिंग कार्ट असो, किंवा मेगाबाइट्समधले API रिस्पॉन्स — फक्त त्यांना तेच एक माहीत आहे म्हणून. हे नेहमीच चुकीचं नसतं, पण क्वचितच ते सर्वोत्तम निवड असते. चला, या प्रत्येक यंत्रणेचं काम काय आहे, DevTools मध्ये ती कुठे सापडते, आणि — सर्वात महत्त्वाचं म्हणजे — शेजारी असलेल्या इतर सहा पर्यायांऐवजी ती तुम्ही केव्हा वापरावी, हे प्रत्यक्षात जाऊन पाहूया.
फक्त HTTP च्या ऐवजी प्रत्येक पानासाठी एकच WebSocket का वापरू नये?
हा प्रश्न वारंवार का विचारला जातो हे मला समजतं. WebSocket उघडं राहतं, तुम्ही कोण आहात हे लक्षात ठेवतं, आणि सर्व्हरला तुम्ही पुन्हा पुन्हा विचारल्याशिवाय डेटा पाठवू देतं. मग एकच सतत चालू राहणारी पाईप उघडून काम भागत असताना आपण अजूनही एका पान लोडसाठी शेकडो वेगवेगळे HTTP रिक्वेस्ट का पाठवतो? खरं सांगायचं तर हा प्रश्न लोक समजतात त्यापेक्षा जास्त हुशार आहे — आणि उत्तर “कारण HTTP जास्त चांगलं आहे” असं नाही. ते यापेक्षा बरंच गुंतागुंतीचं आहे.
वेबसॉकेट्स म्हणजे काय आणि ते HTTP पेक्षा कसे वेगळे आहेत?
“रिअल-टाइम गोष्टींसाठी वेबसॉकेट्स वापरा” हे मी सतत ऐकत होतो, पण प्रत्यक्षात वायरवर काय घडतं हे कोणीच नीट सांगत नव्हतं. म्हणून मी RFC वाचलं, काही सर्व्हर्स तपासले आणि जे समजलं ते लिहून काढायचं ठरवलं — यात मला सर्वात जास्त गोंधळात टाकणारा भाग म्हणजे: वेबसॉकेट हा स्वतःचा एक स्वतंत्र प्रोटोकॉल आहे की HTTP वर केलेली एक चलाख युक्ती? तर वेबसॉकेट म्हणजे नक्की काय? वेबसॉकेट म्हणजे ब्राउझर (किंवा कोणताही क्लायंट) आणि सर्व्हर यांच्यातील, एकाच TCP कनेक्शनवरून उघडलेला, टिकून राहणारा, फुल-डुप्लेक्स संवाद-मार्ग आहे [1]. फुल-डुप्लेक्स म्हणजे दोन्ही बाजू कधीही, हवं तेव्हा संदेश पाठवू शकतात — फक्त विनंतीला उत्तर म्हणून नाही. हाच भाग वेबबद्दलची आपली नेहमीची मानसिक रचना मोडतो.
AI मधील लूप्स: ते काय आहेत आणि सगळेच का बोलत आहेत
सध्या AI मध्ये “लूप” म्हणजे काय असं तीन लोकांना विचारा आणि तुम्हाला तीन वेगवेगळी उत्तरं मिळतील. एक जण एजेंट लूप सांगेल. दुसरा मॉडेल कोलॅप्स आणि फीडबॅक लूप्सबद्दल बोलायला लागेल. तिसरा एखाद्या कम्प्लायन्स मीटिंगमधल्या ह्युमन-इन-द-लूपचा उल्लेख करेल. ते सगळेच बरोबर आहेत, आणि नेमकं याच कारणामुळे हा शब्द इतका गोंधळात टाकणारा झाला आहे. मी ८ वर्षांहून अधिक काळ सॉफ्टवेअर लिहितोय, आणि भरपूर शब्दजंजाळ पुन्हा पुन्हा वापरला जाताना मी पाहिलं आहे. पण “लूप” हा खास आहे कारण तो एकच ट्रेंड नाही — त्या किमान चार वेगवेगळ्या कल्पना आहेत ज्यांना नेमका एकच शब्द लागू होतो, आणि त्या सगळ्या साधारण एकाच वेळी लोकप्रिय झाल्या. तर मग या सगळ्याचा गुंता सोडवूया.
Amazon वरील सामान्य HTTP Headers समजून घेणे
तुम्ही एखाद्या वेबसाइटला पाठवलेल्या प्रत्येक request सोबत तुम्हाला कधीही न दिसणारा metadata चा एक छोटा ढीग असतो. Headers. तुमचे connection encrypted आहे की नाही, एखादे page iframe मध्ये embed करता येईल की नाही, कोणत्या CDN edge ने तुम्हाला serve केले, आणि browser ने एखादे cookie वर्षभर लक्षात ठेवावे की नाही — हे सगळे तेच ठरवतात. एखादी खरीखुरी, गजबजलेली production site काय पाठवते हे मला बघायचे होते, म्हणून मी curl एका Amazon endpoint कडे रोखले आणि response headers बाहेर काढले. लक्षात आले की उलगडण्यासारखे बरेच काही आहे.
प्रत्येक नियम न पाळताही तुम्ही API ला RESTful म्हणू शकता का?
प्रत्येकजण आपल्या API वर “RESTful” असा शिक्का मारतो. कोणतीही docs पेज उघडा, मार्केटिंग मजकूर स्क्रोल करा, आणि तिथे ते असतेच — “आमचे स्वच्छ, RESTful API.” पण इथे अडचणीची गोष्ट अशी आहे: काटेकोर व्याख्येनुसार, त्यांपैकी जवळपास एकही प्रत्यक्षात तसे नसते. म्हणून तुम्ही जो खरा प्रश्न विचारत आहात तो असा की काही नियम मोडले तर हा शब्द अजूनही काही अर्थ राखतो का. खरे सांगायचे तर, इथेच गोष्ट किचकट बनते. आधी थोडक्यात उत्तर, कारण उत्तर शेवटी दडवून ठेवणारे लेख मला आवडत नाहीत: हो, रोजच्या संभाषणात तुम्ही त्याला अजूनही RESTful म्हणू शकता, पण नाही, रॉय फिल्डिंगच्या मूळ व्याख्येनुसार ते REST API नाही — जोपर्यंत ते hypertext-driven नसेल. या दोन्ही गोष्टी एकाच वेळी खऱ्या आहेत, आणि त्यांच्यातील अंतर हीच संपूर्ण कथा आहे.
Git कमिट मेसेज सर्वोत्तम कसा लिहावा
एक वर्षाहून जुन्या असलेल्या कोणत्याही प्रोजेक्टवर git log चालवा आणि तुम्हाला एखाद्या टीमबद्दलचे सत्य सापडेल. निम्मे मेसेज म्हणतात “fix”, “update”, “wip”, “asdf”, किंवा माझे वैयक्तिक आवडते — “stuff”. आणि मग एक दिवस प्रोडक्शन बिघडते, तुम्ही त्या त्रासदायक ओळीवर git blame चालवता, आणि ज्या कमिटने ती ओळ आणली त्यात फक्त “minor changes” असे लिहिलेले असते. छान. खूपच उपयुक्त. धन्यवाद, भूतकाळातील मी. मी एका दशकाहून अधिक काळ कोड लिहीत आलो आहे आणि मी प्रामाणिक राहतो: पहिल्या काही वर्षांत माझे कमिट मेसेज कचरा होते. जोपर्यंत मला दुसऱ्याच्या सहा महिने जुन्या कोडचे डीबगिंग करावे लागले नाही (आणि मग लक्षात आले की तो दुसरा कोणी नसून मीच होतो), तोपर्यंत मला हे उमजले नाही. एखादा diff तुम्हाला सांगतो की काय बदलले. फक्त कमिट मेसेज तुम्हाला सांगू शकतो की का. हाच तर खरा खेळ आहे.
TLS टर्मिनेशन समजावून घेणे (आणि SSL खरंच ट्रान्सपोर्ट लेयर आहे का?)
दोन प्रश्न सतत एकत्र मिसळले जातात: “TLS टर्मिनेशन म्हणजे काय” आणि “SSL ही ट्रान्सपोर्ट लेयरची गोष्ट आहे का?” लोक गृहीत धरतात की दुसऱ्या प्रश्नाचं उत्तर अर्थातच होय आहे — त्याला अक्षरशः Transport Layer Security म्हणतात ना? बरं. या नावाने अनेक हुशार लोकांना फसवलं आहे, आणि हा गोंधळ थेट लोक टर्मिनेशनबद्दल कसा विचार करतात त्यात उतरतो. तर मला दोन्ही उलगडून दाखवू द्या, कारण एकदा लेयरचा प्रश्न नीट समजला की टर्मिनेशन हे जादूसारखं वाटणं थांबतं.
सॉफ्टवेअर टेस्टिंगचे सर्व प्रकार समझाया
मी ज्या बर्‍याच डेव्हलपर्सशी बोलतो त्यांना टेस्टिंगबद्दल एक अस्पष्ट समज आहे — त्यांना माहित आहे की त्यांनी ते करावे, परंतु त्यांना नेहमी हे स्पष्ट नसते की कोण त्या टेस्ट्स काय करतात आणि हे का महत्वाचे आहे. तर तुम्ही येथे एक युनिट टेस्ट लिहा, तेथे काही मॅन्युअल क्लिक्स चला करा, आणि संपूर्ण गोष्ट काम करेल अशी आशा करा. हा एक धोरण नाही. टेस्टिंगमध्ये विविध उद्देशांसाठी विविध प्रकार आहेत. मला तुम्हाला प्रत्येक टेस्टिंग प्रकार खरेतर काय करतो हे समजवून द्या आणि अधिक महत्वाचे म्हणजे कोण त्या कंपन्या खरेतर लागू करतात विरुद्ध कोण सिद्धांतात सुंदर असतात हे आहेत.
SOLID तत्व का महत्वाचे आहेत आणि विकासकर्ते ते का वगळतात
सर्वजण SOLID तत्वांबद्दल बोलतात. तुमचे सिनियर डेव्हलपर कोड रिव्यूमध्ये त्यांचा उल्लेख करतात. तुमचे आर्किटेक्चर डॉक्युमेंटेशन त्यांचा संदर्भ देते. पण वास्तविक प्रकल्प SOLID समजून घेणार्‍या संघ असूनही का अव्यवस्थित बकवास बनतात? उत्तर: SOLID समजणे आणि त्याच्या साथ खरोखर बांधणे हे पूर्णपणे वेगळ्या गोष्टी आहेत [1]. बहुतेक विकासकर्ते SOLID लवकर शिकतात, डोके हलवतात, आणि नंतर ज्या क्षणी अंतिम मुदत येते तेव्हा या तत्वांचे उल्लंघन करतात. मला तुम्हाला दाखवू द्या जिथे रबर रस्त्यावर टेकला - आणि ते का कठीण असते.