Module Federation हा एक असा विषय आहे जो कोणत्याही बैठकीत “micro frontends” चा उल्लेख होताच सगळे बोलू लागतात. छान, runtime वर कोड शेअर करा, टीम्स स्वतंत्रपणे deploy करा, हे ऐकायला खूप चांगले वाटते. पण मग टीममधला कोणीतरी म्हणतो “आपण Vite वापरतो, webpack नाही” आणि संपूर्ण संभाषण अवघड होऊन जाते. मग खरोखर काय होते जेव्हा तुम्ही Vite प्रोजेक्टमध्ये Module Federation आणण्याचा प्रयत्न करता? काही भाग खूप चांगला काम करतो. काही भाग… खरोखरच करत नाही, निदान अजून तरी नाही.
दर काही आठवड्यांनी कोणती ना कोणती AI लॅब एक नवीन मॉडेल लाँच करते आणि लगेच दावा करते की हे पृथ्वीवरचं सर्वात स्मार्ट मॉडेल आहे. मग एका आठवड्यानंतर दुसरी लॅब तेच करते. खरंच कोणतं मॉडेल चांगलं आहे हे शोधण्याचरा प्रयत्न तुम्ही कधी केला असेल, तर तुम्ही नक्कीच MMLU, GPQA आणि SWE-bench सारख्या नावांच्या चार्ट्सच्या भिंतीकडे बघत राहिला असाल आणि डोकं गरगरलं असेल. मी अलीकडेच या रॅबिट होलमध्ये उतरलो, आणि याची थोडक्यात गोष्ट अशी आहे: इथे एकच स्कोअरबोर्ड नाही. “चांगलं” मोजण्यासाठी लोक किमान चार पूर्णपणे वेगळ्या पद्धती वापरतात, आणि एकदा तुम्हाला प्रत्येक पद्धत नेमकं काय करते हे समजलं, की संपूर्ण AI लीडरबोर्ड सर्कस खूप जास्त अर्थपूर्ण वाटायला लागते.
मागच्या आठवड्यात कुणीतरी मला हाच प्रश्न विचारला, आणि तो चांगला प्रश्न आहे कारण दोन्ही रचना डोळे बारीक करून पाहिल्या तर सारख्याच दिसतात. काही मशीन्स, मधे थोडं शेअर्ड स्टोरेज, आणि नोड्सवर पसरलेलं काम. मग एकाला “बिग डेटा” आणि दुसऱ्याला “मायक्रोसर्व्हिसेस” का म्हणतात? हे एकाच क्लस्टरसाठी दोन शब्द आहेत का? खरं सांगायचं तर, नाही. ते एकाच गोष्टीबद्दलच्या अगदी विरुद्ध गृहीतकांवर उभे आहेत: डेटा कुठे राहतो आणि कोण कुणाकडे जातो.
आधी Hadoop प्रत्यक्षात काय आहे ते उलगडून सांगतो, मग आपण दोन्ही गोष्टी शेजारी-शेजारी ठेवू.
प्रत्येक जण ChatGPT आणि Claude बद्दल असं बोलतो जणू ती एखाद्या दिवशी अचानक प्रकट झाली. तुम्ही काहीतरी टाइप करता, तुम्हाला उत्तर मिळतं, जादू. पण तुम्ही कधी थांबून विचारलंय का की यांच्यापैकी एक गोष्ट बनवायला प्रत्यक्षात काय लागतं? चॅट इंटरफेस नाही — मॉडेल स्वतः. ती गोष्ट जिला महिने लागले, कोट्यवधी डॉलर लागले, आणि एका छोट्या गावाला वीज पुरवण्याइतकी वीज खर्च झाली.
मला बऱ्याच काळापासून याबद्दल कुतूहल आहे, काही प्रमाणात कारण हे आकडे जोपर्यंत तुम्ही त्यांच्यासोबत बसत नाही तोपर्यंत खरंच विश्वास ठेवण्यासारखे वाटत नाहीत. म्हणून मी प्रत्यक्षात जे ज्ञात आहे त्यात खोदकाम केलं — लीक झालेले आर्किटेक्चर तपशील, हार्डवेअर घोषणा, डेटा सेंटर उभारणी. यातील काही सार्वजनिक आहे, काही उत्तम स्रोत असलेले अंदाज आहेत, आणि काही गोष्टी लॅब्स मुद्दाम अस्पष्ट ठेवतात. चला मी तुम्हाला सांगतो की आपल्याला प्रत्यक्षात काय माहीत आहे.
प्रत्येकजण HTTP/3 बद्दल असं बोलतो की जणू ती एक फुकटची स्पीड अपग्रेड आहे जी तुम्ही चालू करता आणि विसरून जाता. बहुतांश वेळा तसंच असतं — पण त्या वाक्यातला “बहुतांश” हा शब्द खूप काही सांगून जातो. HTTP/3 आता जगभरात साधारण ३५% वेब रिक्वेस्ट्ससाठी वापरलं जातं [1], त्यामुळे हे आता संशोधनातलं खेळणं राहिलेलं नाही. खरी गोष्ट अशी आहे की जवळपास कोणीच समजावून सांगत नाही की ते का वेगवान आहे, ते प्रत्यक्षात HTTP/2 कडून कुठे हरतं, आणि — जो प्रश्न कोणीच विचारत नाही — तुमच्या स्वतःच्या साइटला त्याचा खरंच काही फायदा होतो का. चला, मी हे एखाद्या मित्राला चहावर समजावून सांगेन तसं समजावून सांगतो.
तुम्ही कधी React app मध्ये एखादं button क्लिक केलं आहे आणि फक्त… विश्वास ठेवला आहे की UI बरोबर update होईल? हो, मीही, वर्षानुवर्षे. setState आणि स्क्रीनवर pixels बदलणे यांच्यामध्ये नक्की काय घडतं याचा मी कधी विचारच केला नाही — जोपर्यंत मी असा एक component debug करायला लागलो जो एका क्लिकवर पाच वेळा re-render होत होता. त्या rabbit hole मुळे मी सरळ Fiber, lanes, आणि React तुमचं app कधी re-render करायचं हे कसं ठरवतं याच्या आश्चर्यकारकरित्या मोठ्या history मध्ये पोहोचलो.
जेव्हा कोणी मला विचारतं “मी session वापरू की JWT?”, तेव्हा या प्रश्नामागे नेमकं काय आहे ते मला माहीत असतं. त्यांनी काही blog posts वाचलेले असतात, “stateless” हा शब्द जणू आपोआप चांगला असतो असा वापरला जाताना पाहिलेला असतो, आणि आता ते गोंधळलेले असतात. तर चला, हे नीट समजून घेऊया - buzzwords ने नाही, तर wire वर आणि तुमच्या सर्व्हरवर प्रत्यक्षात काय घडतं त्याद्वारे.
Session: “फ्रंट डेस्कवर रेकॉर्ड ठेवतो” पद्धत session-based auth ला हॉटेलमध्ये चेक-इन करण्यासारखं समजा. तुम्ही फ्रंट डेस्कवर एकदाच तुमचं ID दाखवता, स्टाफ ते verify करतो, आणि तुम्हाला एक रूम की कार्ड देतो. त्या कार्डमध्ये तुमचं नाव, पासपोर्ट नंबर किंवा बुकिंग डिटेल्स नसतात - ते फक्त एक रँडम नंबर असतं. तुमची खरी सगळी माहिती हॉटेलच्या कॉम्प्युटर सिस्टीममध्ये, त्यांच्या डेटाबेसमध्ये, त्या कार्ड नंबरशी लिंक करून साठवलेली असते.
“हे फक्त Redis मध्ये कॅश करा” — हे तुम्ही कोड रिव्ह्यूमध्ये, सिस्टम डिझाइन इंटरव्ह्यूमध्ये किंवा Stack Overflow च्या कमेंटमध्ये नक्कीच ऐकलं असेल. आता हे जवळपास एक प्रतिक्षिप्त क्रिया बनली आहे. पण Redis च का? चांगल्या इंडेक्ससह एखाद्या सामान्य डेटाबेसने का नाही, किंवा इतर कोणत्याही इन-मेमरी स्टोअरने? मी त्याचा इतिहास, आर्किटेक्चर आणि पर्यायांचं सध्याचं चित्र खोलवर तपासलं — आणि ही गोष्ट खरोखरच मेमपेक्षा कितीतरी जास्त रंजक आहे.
Redis खरोखर काय आहे आधी एक गोष्ट स्पष्ट करूया. Redis फक्त एक कॅश नाही. ही तीच गैरसमज आहे जी लोकांना अडकवते. Redis म्हणजे REmote DIctionary Server [1], आणि हे एक इन-मेमरी डेटा स्ट्रक्चर स्टोअर आहे — म्हणजे ते डिस्कऐवजी RAM मध्ये डेटा ठेवतं. हाच एक निर्णय त्याच्या वेगाचं बहुतांश कारण स्पष्ट करतो.
तुमची अॅप कालांतराने हळू होत आहे. स्क्रोल पोझिशन उडी घेते. टॅब्स ८०० MB RAM वापरत आहेत. तुम्ही Task Manager उघडता आणि Chrome ला मेमरी बफे दिवसासारखी खाताना पाहता. काहीतरी leak होत आहे — पण कुठे? Chrome DevTools Memory tab समोरच आहे, आणि बहुतेक डेव्हलपर्स एकतर ते दुर्लक्षित करतात किंवा एकदा उघडतात, “Shallow Size” आणि “Retainers” पाहून गोंधळतात, आणि शांतपणे बंद करतात. हे मार्गदर्शक त्यांच्यासाठी आहे जे ते खरोखरच वापरायला शिकू इच्छितात.
तुमचे वेब अॅप कदाचित अशा गोष्टी करत आहे ज्या तुम्ही कधी प्रत्यक्षात डीबग केल्या नाहीत. वापरकर्त्याने काही क्लिक करण्यापूर्वीच पेजेस प्री-रेंडर होत आहेत, ऑफलाइन असताना फॉर्म सबमिशन्स शांतपणे रांगेत लावल्या जात आहेत, झोपलेल्या सर्व्हिस वर्कर कडे पुश नोटिफिकेशन्स येत आहेत, सेशन्स हार्डवेअर कीजना क्रिप्टोग्राफिकली बांधल्या जात आहेत — हे सर्व Chrome च्या background service APIs द्वारे होते, पूर्णपणे अदृश्यपणे. Chrome DevTools मधील Background Services पॅनेल म्हणजे तुम्हाला हे सर्व शेवटी पाहता येण्याची जागा.
DevTools उघडा, Application वर क्लिक करा, आणि डाव्या बाजूच्या साइडबारकडे पाहा. Cookies, Local Storage, Session Storage, IndexedDB, Cache Storage, Shared Storage, Background Services… खूप काही आहे. मी अनुभवी डेव्हलपर्सनासुद्धा प्रत्येक गोष्टीसाठी localStorage वापरताना पाहिलं आहे — मग ते ऑथ टोकन्स असोत, शॉपिंग कार्ट असो, किंवा मेगाबाइट्समधले API रिस्पॉन्स — फक्त त्यांना तेच एक माहीत आहे म्हणून. हे नेहमीच चुकीचं नसतं, पण क्वचितच ते सर्वोत्तम निवड असते. चला, या प्रत्येक यंत्रणेचं काम काय आहे, DevTools मध्ये ती कुठे सापडते, आणि — सर्वात महत्त्वाचं म्हणजे — शेजारी असलेल्या इतर सहा पर्यायांऐवजी ती तुम्ही केव्हा वापरावी, हे प्रत्यक्षात जाऊन पाहूया.
हा प्रश्न वारंवार का विचारला जातो हे मला समजतं. WebSocket उघडं राहतं, तुम्ही कोण आहात हे लक्षात ठेवतं, आणि सर्व्हरला तुम्ही पुन्हा पुन्हा विचारल्याशिवाय डेटा पाठवू देतं. मग एकच सतत चालू राहणारी पाईप उघडून काम भागत असताना आपण अजूनही एका पान लोडसाठी शेकडो वेगवेगळे HTTP रिक्वेस्ट का पाठवतो? खरं सांगायचं तर हा प्रश्न लोक समजतात त्यापेक्षा जास्त हुशार आहे — आणि उत्तर “कारण HTTP जास्त चांगलं आहे” असं नाही. ते यापेक्षा बरंच गुंतागुंतीचं आहे.
“रिअल-टाइम गोष्टींसाठी वेबसॉकेट्स वापरा” हे मी सतत ऐकत होतो, पण प्रत्यक्षात वायरवर काय घडतं हे कोणीच नीट सांगत नव्हतं. म्हणून मी RFC वाचलं, काही सर्व्हर्स तपासले आणि जे समजलं ते लिहून काढायचं ठरवलं — यात मला सर्वात जास्त गोंधळात टाकणारा भाग म्हणजे: वेबसॉकेट हा स्वतःचा एक स्वतंत्र प्रोटोकॉल आहे की HTTP वर केलेली एक चलाख युक्ती?
तर वेबसॉकेट म्हणजे नक्की काय? वेबसॉकेट म्हणजे ब्राउझर (किंवा कोणताही क्लायंट) आणि सर्व्हर यांच्यातील, एकाच TCP कनेक्शनवरून उघडलेला, टिकून राहणारा, फुल-डुप्लेक्स संवाद-मार्ग आहे [1]. फुल-डुप्लेक्स म्हणजे दोन्ही बाजू कधीही, हवं तेव्हा संदेश पाठवू शकतात — फक्त विनंतीला उत्तर म्हणून नाही. हाच भाग वेबबद्दलची आपली नेहमीची मानसिक रचना मोडतो.
सध्या AI मध्ये “लूप” म्हणजे काय असं तीन लोकांना विचारा आणि तुम्हाला तीन वेगवेगळी उत्तरं मिळतील. एक जण एजेंट लूप सांगेल. दुसरा मॉडेल कोलॅप्स आणि फीडबॅक लूप्सबद्दल बोलायला लागेल. तिसरा एखाद्या कम्प्लायन्स मीटिंगमधल्या ह्युमन-इन-द-लूपचा उल्लेख करेल. ते सगळेच बरोबर आहेत, आणि नेमकं याच कारणामुळे हा शब्द इतका गोंधळात टाकणारा झाला आहे.
मी ८ वर्षांहून अधिक काळ सॉफ्टवेअर लिहितोय, आणि भरपूर शब्दजंजाळ पुन्हा पुन्हा वापरला जाताना मी पाहिलं आहे. पण “लूप” हा खास आहे कारण तो एकच ट्रेंड नाही — त्या किमान चार वेगवेगळ्या कल्पना आहेत ज्यांना नेमका एकच शब्द लागू होतो, आणि त्या सगळ्या साधारण एकाच वेळी लोकप्रिय झाल्या. तर मग या सगळ्याचा गुंता सोडवूया.
तुम्ही एखाद्या वेबसाइटला पाठवलेल्या प्रत्येक request सोबत तुम्हाला कधीही न दिसणारा metadata चा एक छोटा ढीग असतो. Headers. तुमचे connection encrypted आहे की नाही, एखादे page iframe मध्ये embed करता येईल की नाही, कोणत्या CDN edge ने तुम्हाला serve केले, आणि browser ने एखादे cookie वर्षभर लक्षात ठेवावे की नाही — हे सगळे तेच ठरवतात. एखादी खरीखुरी, गजबजलेली production site काय पाठवते हे मला बघायचे होते, म्हणून मी curl एका Amazon endpoint कडे रोखले आणि response headers बाहेर काढले. लक्षात आले की उलगडण्यासारखे बरेच काही आहे.
प्रत्येकजण आपल्या API वर “RESTful” असा शिक्का मारतो. कोणतीही docs पेज उघडा, मार्केटिंग मजकूर स्क्रोल करा, आणि तिथे ते असतेच — “आमचे स्वच्छ, RESTful API.” पण इथे अडचणीची गोष्ट अशी आहे: काटेकोर व्याख्येनुसार, त्यांपैकी जवळपास एकही प्रत्यक्षात तसे नसते. म्हणून तुम्ही जो खरा प्रश्न विचारत आहात तो असा की काही नियम मोडले तर हा शब्द अजूनही काही अर्थ राखतो का. खरे सांगायचे तर, इथेच गोष्ट किचकट बनते.
आधी थोडक्यात उत्तर, कारण उत्तर शेवटी दडवून ठेवणारे लेख मला आवडत नाहीत: हो, रोजच्या संभाषणात तुम्ही त्याला अजूनही RESTful म्हणू शकता, पण नाही, रॉय फिल्डिंगच्या मूळ व्याख्येनुसार ते REST API नाही — जोपर्यंत ते hypertext-driven नसेल. या दोन्ही गोष्टी एकाच वेळी खऱ्या आहेत, आणि त्यांच्यातील अंतर हीच संपूर्ण कथा आहे.
एक वर्षाहून जुन्या असलेल्या कोणत्याही प्रोजेक्टवर git log चालवा आणि तुम्हाला एखाद्या टीमबद्दलचे सत्य सापडेल. निम्मे मेसेज म्हणतात “fix”, “update”, “wip”, “asdf”, किंवा माझे वैयक्तिक आवडते — “stuff”. आणि मग एक दिवस प्रोडक्शन बिघडते, तुम्ही त्या त्रासदायक ओळीवर git blame चालवता, आणि ज्या कमिटने ती ओळ आणली त्यात फक्त “minor changes” असे लिहिलेले असते. छान. खूपच उपयुक्त. धन्यवाद, भूतकाळातील मी.
मी एका दशकाहून अधिक काळ कोड लिहीत आलो आहे आणि मी प्रामाणिक राहतो: पहिल्या काही वर्षांत माझे कमिट मेसेज कचरा होते. जोपर्यंत मला दुसऱ्याच्या सहा महिने जुन्या कोडचे डीबगिंग करावे लागले नाही (आणि मग लक्षात आले की तो दुसरा कोणी नसून मीच होतो), तोपर्यंत मला हे उमजले नाही. एखादा diff तुम्हाला सांगतो की काय बदलले. फक्त कमिट मेसेज तुम्हाला सांगू शकतो की का. हाच तर खरा खेळ आहे.
दोन प्रश्न सतत एकत्र मिसळले जातात: “TLS टर्मिनेशन म्हणजे काय” आणि “SSL ही ट्रान्सपोर्ट लेयरची गोष्ट आहे का?” लोक गृहीत धरतात की दुसऱ्या प्रश्नाचं उत्तर अर्थातच होय आहे — त्याला अक्षरशः Transport Layer Security म्हणतात ना? बरं. या नावाने अनेक हुशार लोकांना फसवलं आहे, आणि हा गोंधळ थेट लोक टर्मिनेशनबद्दल कसा विचार करतात त्यात उतरतो. तर मला दोन्ही उलगडून दाखवू द्या, कारण एकदा लेयरचा प्रश्न नीट समजला की टर्मिनेशन हे जादूसारखं वाटणं थांबतं.
मी ज्या बर्याच डेव्हलपर्सशी बोलतो त्यांना टेस्टिंगबद्दल एक अस्पष्ट समज आहे — त्यांना माहित आहे की त्यांनी ते करावे, परंतु त्यांना नेहमी हे स्पष्ट नसते की कोण त्या टेस्ट्स काय करतात आणि हे का महत्वाचे आहे. तर तुम्ही येथे एक युनिट टेस्ट लिहा, तेथे काही मॅन्युअल क्लिक्स चला करा, आणि संपूर्ण गोष्ट काम करेल अशी आशा करा. हा एक धोरण नाही. टेस्टिंगमध्ये विविध उद्देशांसाठी विविध प्रकार आहेत.
मला तुम्हाला प्रत्येक टेस्टिंग प्रकार खरेतर काय करतो हे समजवून द्या आणि अधिक महत्वाचे म्हणजे कोण त्या कंपन्या खरेतर लागू करतात विरुद्ध कोण सिद्धांतात सुंदर असतात हे आहेत.
सर्वजण SOLID तत्वांबद्दल बोलतात. तुमचे सिनियर डेव्हलपर कोड रिव्यूमध्ये त्यांचा उल्लेख करतात. तुमचे आर्किटेक्चर डॉक्युमेंटेशन त्यांचा संदर्भ देते. पण वास्तविक प्रकल्प SOLID समजून घेणार्या संघ असूनही का अव्यवस्थित बकवास बनतात? उत्तर: SOLID समजणे आणि त्याच्या साथ खरोखर बांधणे हे पूर्णपणे वेगळ्या गोष्टी आहेत [1].
बहुतेक विकासकर्ते SOLID लवकर शिकतात, डोके हलवतात, आणि नंतर ज्या क्षणी अंतिम मुदत येते तेव्हा या तत्वांचे उल्लंघन करतात. मला तुम्हाला दाखवू द्या जिथे रबर रस्त्यावर टेकला - आणि ते का कठीण असते.
बहुतेक विकासकर्ते सर्व निर्देशांकांना एकत्र करतात — “फक्त काहीतरी जे क्वेरीज जलद करते” — हे समजल्याशिवाय की Elasticsearch आणि Oracle DB पूर्णपणे वेगवेगळ्या समस्यांचे निराकरण करत आहेत. ते समान डेटा पूर्णपणे विरुद्ध मार्गांनी निर्देशांकित करतात, आणि हा फरक त्यांच्या कार्यक्षमतेबद्दल सर्वकाही आकार देतो.
मी तुम्हाला दाखवतो की Oracle वर संपूर्ण-मजकूर शोध का दातांपासून खेचायला वाटते, तर Elasticsearch ते तुच्छ वाटवते.
मूल समस्या: दोन वेगवेगळे वापरकेस Oracle डेटाबेस असे प्रश्न उत्तर देण्यासाठी तयार केले गेले आहेत: “मला तो पंक्ती दा जेथे user_id = 5” किंवा “जानेवारीच्या 1 ते 31 दरम्यान सर्व ऑर्डर शोधा.” अचूक जुळणी आणि श्रेणी क्वेरीज. डेटा संरचित आहे, स्तंभाने निर्देशांकित आहे, आणि क्वेरीज सामान्यत: अचूक असतात.
हे तीनही संकल्पना लोक एकमेकांत गोंधळून देतात. तुम्ही हे शब्द सतत एकत्रित वापरले जाताना पाहता, लोक या शब्दांचा वापर एकाच अर्थाने करतात, आणि बहुतांश लेख हे गोंधळून देतात किंवा फरक तांत्रिक भाषेत लपवून देतात. येथे ते खरेतर काय आहेत, ते का वेगळे आहेत, आणि कधी वापरायचे हे आहे. [1]
डिबाउन्सिंग: वादळ जाईपर्यंत प्रतीक्षा करा डिबाउन्सिंग निष्क्रियतेच्या अवधीनंतर अंमलबजावणी विलंबित करते.
कल्पना करा की कोई व्यक्ती शोध बॉक्समध्ये टाइप करत आहे. प्रत्येक की दाब एक घटना आहे. डिबाउन्सिंग न केल्यास, तुम्ही प्रत्येक की दाबावर API विनंती पाठवाल — वर्ण 1, वर्ण 2, वर्ण 3, इत्यादि. हे अकार्यक्षम आहे.
जर तुम्ही टेक क्षेत्रात “न्यूरल नेटवर्क” हा शब्द ऐकला असेल, तर तुम्ही कदाचित काहीतरी जैविक कल्पना केली असेल. न्यूरॉन हा शब्द नवीन प्रोग्रामरला एआई सोबत काम करण्यासाठी मेंदूचा जीवशास्त्र समजून घेणे आवश्यक आहे असे वाटू शकते. त्यांना नाही. पण न्यूरॉन खरोखर काय करतो आणि तो तुमच्या कोडमध्ये लिहिलेल्या फंक्शनपेक्षा कसे वेगळा आहे याबद्दल गोंधळ वास्तव आहे. आणि हा फरक महत्त्वाचा आहे [1][2].
न्यूरॉन खरोखर काय आहे? एआई मध्ये न्यूरॉन हा एक संगणकीय एकक आहे. सरलतेने सांगायचे तर, तो असा गोष्ट आहे जो इनपुट घेतो, गणित करतो आणि आउटपुट तयार करतो. हे फंक्शन सारखे वाटते, बरोबर? काहीसे तसेच आहे. पण समानता येथे संपते.
तुम्ही एक Full HD (1920×1080) मॉनिटर खरेदी करता आणि विशेषतांची तपासणी करता. तुमचा MacBook देखील समान रेजोलिऊशनमध्ये आउटपुट देतो. तरी देखील जेव्हा तुम्ही काम सुरू करता, तेव्हा मॉनिटरवरचा मजकूर लक्षणीयरित्या नरम दिसतो. खंडित किंवा वाचनीय नसून — फक्त तुमच्या MacBook च्या अंतर्निर्मित स्क्रीनवर दिसणारे जेव्हा तीक्ष्ण असतो तेव्हा तितका तीक्ष्ण नाही. काय चाललंय?
उत्तर रेजोलिऊशन संख्यांबद्दल नाही. हे पिक्सेल घनता बद्दल आहे.
पिक्सेल घनता समस्या बरोबर, दोन प्रदर्शकांमध्ये समान रेजोलिऊशन असूनही वेगवेगळ्या आकारांमध्ये पूर्णपणे वेगळी पिक्सेल घनता असू शकते [1]. 24-इंच Full HD मॉनिटरमध्ये अंदाजे 92 पिक्सल प्रति इंच (PPI) असतात [2]. तुमचा MacBook Air? 227 PPI वर जा [1]. तुमचा 16-इंच MacBook Pro? 254 PPI [1].
मला पहिल्यांदा CRA (जे आतून Webpack वापरते) वरून Vite वर प्रोजेक्ट स्विच केल्याचे आठवते. dev server एका सेकंदापेक्षा कमी वेळात सुरू झाला. मी खरोखरच काही क्षण टर्मिनलकडे टक लावून पाहत राहिलो, आणखी काही होण्याची वाट पाहत. काहीच झाले नाही. बस्स तेवढेच होते — ते तयार होते. Webpack वरील ही काही छोटी सुधारणा नाही. हा पूर्णपणे वेगळा अनुभव आहे.
Vite म्हणजे काय? Vite (फ्रेंचमध्ये “fast” म्हणजे जलद, उच्चार “वीट”) हे Evan You यांनी तयार केलेले frontend build tool आहे — तेच ज्यांनी Vue.js बनवले [1]. ते 2020 मध्ये लॉन्च झाले आणि वेगाने वाढत आहे. 2025 पर्यंत, Vite दर आठवड्याला 5 कोटी 30 लाख npm downloads नोंदवतो, Webpack च्या 3 कोटी 60 लाखांच्या तुलनेत [5]. त्याच्या GitHub stars देखील तीच कहाणी सांगतात: 78,000 विरुद्ध Webpack चे 66,000 [5].
फ्रंटएंड परिसंस्था दरवर्षी बदलते, पण 2025-2026 हे संरचनात्मकदृष्ट्या वेगळे वाटले. हे फक्त नवीन libraries नव्हते — मूलभूत mental models बदलले. आपण कसे hydrate करतो, bundle करतो, components कसे structure करतो, आणि reactivity कसे हाताळतो — हे सारे अशा प्रकारे बदलले ज्यामुळे apps च्या कार्यक्षमतेवर आणि build होण्यास लागणाऱ्या वेळावर खरोखरच परिणाम होतो. येथे काय लक्षात ठेवण्यासारखे आहे ते पाहू.
Framework Landscape विखुरत आहे (चांगल्या प्रकारे) React अजूनही सुमारे 45% adoption सह वर्चस्व गाजवत आहे [1], परंतु प्रत्येक project प्रकारासाठी हे default उत्तर आहे असे म्हणणे अधिकाधिक कठीण होत आहे. आता तीन स्पर्धक गंभीर आहेत.
दररोज QR कोड स्कॅन करायचा पण त्या तीन चौरसांबद्दल कधी विचारच करायचा नाही. मी अनेक वर्षे त्याच गटात होतो. पण खरं सांगायचं तर ते काही खरोखरच चतुर अभियांत्रिकी कार्य करत आहेत — आणि ते नक्की तीन का आहेत, चार का नाहीत, हे तुम्हाला वाटेल त्यापेक्षा जास्त रंजक आहे.
त्यांना एक नाव आहे: फाइंडर पॅटर्न तीन मोठे चौरस अधिकृतपणे पोझिशन डिटेक्शन पॅटर्न म्हणून ओळखले जातात, जरी जवळपास सर्वजण त्यांना फाइंडर पॅटर्न [4] म्हणतात. ते प्रत्येक QR कोडच्या वरच्या-डाव्या, वरच्या-उजव्या आणि खालच्या-डाव्या कोपऱ्यात असतात — खालच्या-उजव्या कोपऱ्यात कधीच नाही. ही असममितता हेतुपुरस्सर आहे, आणि तेच मुख्य कारण आहे.
तुम्ही /api/orders/1042 सारखा API endpoint उघड करता. तो integer कोणालाही ऐकणाऱ्याला — एखाद्या प्रतिस्पर्ध्याला, आक्रमणकर्त्याला, उत्सुक वापरकर्त्याला — तुमच्याकडे किती orders आहेत ते सांगतो. संख्या 1041 केली, तर तुम्हाला मागील order मिळतो. ती 1 केली, तर तुम्हाला पहिली order मिळते. कोणत्याही auth bypass ची गरज नाही. ID स्वतःच माहितीची गळती आहे.
हा एका परिच्छेदात sequential ID चा प्रश्न आहे. UUID त्याचे निराकरण करण्यासाठी अस्तित्वात आहे — आणि मोठ्या प्रमाणावर महत्त्वाच्या इतर काही गोष्टींसाठी.
OOP ला ५०+ वर्षे झाली आहेत. Classes, objects, inheritance — हे काम करते, सगळ्यांना माहीत आहे, जवळजवळ प्रत्येक लोकप्रिय भाषा याला support करते. मग लोक functional programming बद्दल अशा प्रकारे का बोलत आहेत जणू ते काही revelation आहे? कारण OOP गोष्टींचे modelling करण्यात उत्तम आहे. FP transformations चे modelling करण्यात उत्तम आहे. बहुतेक real software मध्ये दोन्ही आहेत, आणि दोन्ही एकत्र करण्याचा प्रयत्न करणे हेच confusion सुरू होण्याचे कारण आहे.
Kubernetes क्लस्टर सेट करणारा प्रत्येक जण शेवटी एकाच अडथळ्यावर येतो: या सिस्टममध्ये ट्राफिक नेमका कसा आणायचा? मग डॉक्युमेंटेशन ClusterIP, NodePort, LoadBalancer, Ingress, Gateway API, MetalLB — असे उल्लेख करतं आणि गोंधळ वाढत जातो. आणखी एक समस्या म्हणजे “LoadBalancer” नावाचा एक Service type आहे आणि प्रत्यक्ष लोड बॅलेन्सर आहेत — आणि ते एकच नाहीत. चला खऱ्या पर्यायांतून जाऊया, स्टॅकमध्ये प्रत्येक कुठे बसतो, आणि खरोखरच काय वापरणे योग्य आहे ते पाहूया.
दोन प्रकारचा ट्राफिक कोणताही लोड बॅलेन्सर मेकॅनिझम निवडण्याआधी, तुम्ही नेमकी कोणती समस्या सोडवत आहात हे जाणून घेणे उपयुक्त आहे.
मी “झिरो डे” हा शब्द डेटा उल्लंघनाच्या बातम्यांमध्ये, चित्रपटाच्या ट्रेलरमध्ये आणि विक्रेत्यांच्या मार्केटिंग ईमेलमध्ये वापरलेला पाहिला आहे. जवळजवळ नेहमीच याचा अर्थ “भयंकर हॅक” असतो. हे पूर्णपणे चुकीचे नाही — पण यामुळे नक्की ती गोष्ट चुकते जी झिरो-डेला इतर प्रत्येक अटॅकपेक्षा संरचनात्मकदृष्ट्या वेगळे बनवते. जेव्हा तुम्ही तुमचा धोका समजून घेण्याचा प्रयत्न करत असता तेव्हा ही अचूकता खरोखर महत्त्वाची असते.
तीन संज्ञा ज्या एकसारख्या नाहीत मी हे सतत एकमेकांच्या जागी वापरलेले पाहतो. ते तसे नाहीत.
चौऱ्याण्णव टक्के डेव्हलपर Git वापरतात [6]. उर्वरित सहा टक्के बहुतेक विशेष उद्योगांमध्ये आहेत — गेम स्टुडिओ, मोठ्या वित्त कंपन्या — आणि तेही हळूहळू स्थलांतर करत आहेत. प्रत्येक इतर व्हर्जन कंट्रोल सिस्टम एकतर मृत झाली आहे, मरणासन्न अवस्थेत आहे, किंवा केवळ एखाद्या कोपऱ्यात टिकून आहे. एका व्यक्तीने सुमारे दोन आठवड्यांत लिहिलेल्या सॉफ्टवेअरसाठी हा एक विचित्र परिणाम आहे.
या सर्वाची सुरुवात करणारी BitKeeper घटना Git कुणाला बसून “चला परिपूर्ण व्हर्जन कंट्रोल सिस्टम डिझाइन करूया” असा विचार आल्यामुळे उदयास आली नाही. ती उदयास आली कारण कुणीतरी एक मोफत परवाना काढून घेतला.
जेव्हाही Spark बद्दल चर्चा सुरू होते, तेव्हा “फक्त मायक्रोसर्व्हिसेस scale करा” हा प्रश्न पुन्हा पुन्हा येतो. ऐकायला हे तार्किक वाटते — तुमच्याकडे आधीच distributed services आहेत, समस्येवर आणखी टाकून द्या. पण ही तुलना एका अगदी मूलभूत प्रश्नापुढे कोसळते: तुम्ही प्रत्यक्षात कोणत्या प्रकारची समस्या सोडवत आहात?
हे डेटाबेस नाही. Queue सुद्धा नाही. लोक Spark कडे एखाद्या जलद डेटाबेसची किंवा हुशार Kafka ची अपेक्षा घेऊन येतात. दोन्ही चुकीचे आहेत.
CSS centering शी पहिली झुंज कोणीही विसरत नाही. तुम्ही Google करता, Stack Overflow वरून snippet paste करता, आणि पुढे जाता — हे योग्य मार्ग होते की फक्त एक मार्ग होता हे कधी विचारत नाही. 2026 मध्ये, div center करण्याचे किमान सात वेगळे मार्ग आहेत, आणि त्यातील काही वर्षांपूर्वीच बंद व्हायला हवे होते.
हे सर्व मार्ग, सर्वात वाईटापासून सर्वोत्तमापर्यंत क्रमवारीनुसार.
संपूर्ण तुलना पद्धत क्षैतिज उभी निर्णय display: table-cell होय होय कधीही नाही Negative margins होय होय कधीही नाही abs + translate(-50%, -50%) होय होय टाळा inset: 0 + margin: auto होय होय कधी कधी margin: auto होय नाही केवळ क्षैतिज Flexbox होय होय चांगला डिफॉल्ट CSS Grid होय होय सर्वोत्तम डिफॉल्ट CSS Anchor Positioning सापेक्ष सापेक्ष विशिष्ट वापर 1. display: table-cell — कृपया थांबा Flexbox येण्यापूर्वी लोक हे करायचे. तुम्ही तुमचा element एका बनावट table मध्ये गुंडाळता, browser ला तो <td> सारखा वागवायला भाग पाडता, आणि vertical-align: middle चा गैरवापर करता.
Kafka बाहेरून अगदी सरळ-साधा वाटतो — तुम्ही एखाद्या टॉपिकवर प्रकाशित करता, कुणीतरी वाचतो. आतून हे एक बऱ्यापैकी गुंतागुंतीचे वितरित प्रणाली आहे जिथे एकही बाइट वितरित होण्यापूर्वी अनेक भागांनी कोणाचे काय आहे यावर सहमती व्हायला हवी. मी यात बराच वेळ घालवला आणि बहुतेक लेख “विभाजनांमुळे समांतरता मिळते” इथेच थांबतात, वास्तविक हँडशेक समजावून सांगत नाहीत. मला अधिक खोलात जाऊ द्या.
Kafka क्लस्टर म्हणजे नक्की काय Kafka क्लस्टर म्हणजे ब्रोकर्सचा एक समूह — साधे JVM प्रक्रिया, प्रत्येक स्वतःच्या मशीनवर (किंवा कंटेनरमध्ये) चालत असतात. प्रत्येक ब्रोकर डेटाचा एक भाग साठवतो आणि क्लस्टरच्या उर्वरित भागाबद्दल जाणतो [1].
सगळे MCP ला “AI साठी फक्त एक API कॉलिंग लेयर” म्हणतात. हे चुकीचे आहे — आणि म्हणूनच “आमच्याकडे आधीच Swagger आहे” हा आक्षेप वारंवार येतो. दोन्ही गोष्टींचा उलगडा करणे आवश्यक आहे.
MCP प्रत्यक्षात काय आहे MCP म्हणजे Model Context Protocol. Anthropic ने नोव्हेंबर 2024 मध्ये याची घोषणा केली [1], आणि डिसेंबर 2025 पर्यंत ते Block आणि OpenAI सह सह-स्थापित Agentic AI Foundation अंतर्गत Linux Foundation ला दान करण्यात आले [2]. एकट्या स्वीकृतीचा वेग उल्लेखनीय आहे.
OOP ला पन्नास वर्षे झाली आहेत. Software क्षेत्रातील प्रत्येकाने यावर एक course केलेला आहे. बहुतेकांनी SOLID, inheritance, encapsulation, polymorphism याबद्दल वाचलेले आहे. तरीही — मला startup पासून enterprise projects पर्यंत, codebase नंतर codebase मध्ये त्याच design चुका दिसत राहतात.
सिद्धांत जाणणे म्हणजे चांगले OOP लिहिणे नव्हे. येथे ते खरोखर कुठे चुकते ते पाहूया.
The God Object एखादा project सुरू करा, एक UserService class तयार करा. कोणीतरी त्यात payment logic जोडते. मग notification handling. मग authentication checks. सहा महिन्यांनंतर: एक 2000-ओळींची फाईल जी सर्वकाही करते, सर्वांवर अवलंबून असते, आणि कोणी तिला स्पर्श केला की तुटते.
अमेझॉनने जगातील सर्वात मोठे क्लाउड प्लॅटफॉर्म बनवण्याचा कधीही इरादा केला नव्हता. आपल्या अभियंत्यांनी दर काही महिन्यांनी एकच पायाभूत सुविधा पुन्हा तयार करण्यापासून रोखण्यासाठी प्रयत्न करताना ते त्यात अडकले.
आतल्या गोंधळाने सुरुवात केली २०००च्या आसपास, अमेझॉन Merchant.com बनवत होते — एक उत्पादन जे Target आणि Marks & Spencer सारख्या तृतीय-पक्ष विक्रेत्यांना अमेझॉनच्या पायाभूत सुविधांवर ई-कॉमर्स स्टोअर्स उघडण्यास परवानगी देणार होते [2]. त्यानंतर जे झाले ते संघटनात्मक गोंधळ होता. प्रत्येक टीम स्वतःच्या आवृत्तीचे स्टोरेज, कॉम्प्युट आणि डेटाबेस प्रिमिटिव्ह बनवत होती. कोणते सामायिक API नाहीत, कशाही गोष्टीत प्रवेश करण्याचा कोणताही मानक मार्ग नाही.
गेल्या काही वर्षांत मी पाहिलेले बहुतेक ब्लॉग WordPress वर चालतात — एक डेटाबेस, PHP, प्लगइन्स, दर दोन आठवड्यांनी सुरक्षा पॅचेस. मूलतः मजकूर प्रकाशित करणाऱ्या साइटसाठी खूप जास्त हलणारे भाग. Hugo हे त्या सर्वांच्या अगदी विरुद्ध आहे. कोणताही डेटाबेस नाही. कोणतेही रनटाइम नाही. फक्त CDN वरून सर्व्ह केलेल्या साध्या HTML फाइल्स, एका सेकंदापेक्षा कमी वेळात तयार केल्या जातात.
Hugo नक्की काय आहे — आणि ते इतके वेगवान का आहे? Hugo हे Go मध्ये लिहिलेले ओपन-सोर्स स्टॅटिक साइट जनरेटर आहे [1]. तुम्ही Markdown मध्ये सामग्री लिहिता, एक थीम निवडता, एक कमांड चालवता, आणि ते साध्या HTML, CSS आणि JS चे एक फोल्डर तयार करते. ते फोल्डर तुमची संपूर्ण वेबसाइट आहे. सर्व्हरवर काहीही चालत नाही. कोणतेही PHP नाही, कोणतेही Python नाही, जिवंत ठेवण्यासाठी कोणतीही Node प्रक्रिया नाही.
तुम्ही ते ब्राउझर टॅबमध्ये पाहता. शोध निकालांमध्ये साइटच्या नावापुढे पाहता. तुम्ही त्याला एखाद्या वेबसाइटचा लोगो समजता. मग त्याला favicon का म्हणतात? हे नाव ऐकून टॅब्स किंवा लोगोशी काहीही संबंध असल्यासारखे वाटत नाही. आणि तुम्ही बरोबर आहात — नाही आहे. हे नाव त्या आयकॉनसाठी मूळात काय बनवले होते त्याचे अवशेष आहे, आज ते काय करते त्याचे नाही.
ते कधीच टॅब्ससाठी नव्हते “favicon” हे नाव दोन शब्दांचे संयोजन आहे: favorite + icon [1]. म्हणजे, तुमच्या ब्राउझरच्या आवडींच्या यादीत — ज्याला बहुतेक लोक बुकमार्क्स म्हणतात — वेबसाइटच्या बाजूला दिसणारा आयकॉन.
TypeScript ऑगस्ट 2025 मध्ये GitHub वरील सर्वाधिक वापरली जाणारी भाषा बनली — दशकाहून अधिक काळात पहिल्यांदाच Python आणि JavaScript दोन्हींना मागे टाकून [4]. 78% व्यावसायिक developers आता TypeScript लिहितात [5]. तरीही, जवळजवळ कोणताही legacy codebase, startup MVP, किंवा साधी utility script उघडा आणि तुम्हाला अजूनही plain .js फाईल्स दिसतील. हे आळशीपणा नाही. यामागे खरी, संरचनात्मक कारणे आहेत.
TypeScript म्हणजे नक्की काय? TypeScript म्हणजे JavaScript वर types जोडलेले. Microsoft ने ते एका खऱ्या समस्येसाठी तयार केले — मोठे JavaScript codebases वेगाने अव्यवस्थापित होतात. जेव्हा एखाद्या codebase मध्ये हजारो ओळी आणि डझनभर contributors असतात, तेव्हा फक्त call site वाचून function काय expect करते हे समजत नाही [1].
फ्रंटएंड डेव्हलपर आणि AI इंजिनिअर यांच्यातील सीमारेषा झपाट्याने पुसट होत आहे. 2026 मध्ये, सर्वाधिक मागणी असलेले वेब डेव्हलपर केवळ सुंदर UI तयार करत नाहीत — ते त्या UI ला थेट लार्ज लँग्वेज मॉडेल्स, व्हेक्टर डेटाबेस आणि स्वायत्त एजंट्सशी जोडत आहेत. जर तुम्हाला आधीच React, TypeScript किंवा Next.js माहीत असेल, तर तुम्ही त्या भविष्यापेक्षा खूप जवळ आहात — कदाचित तुम्हाला वाटते त्यापेक्षाही.
फ्रंटएंड डेव्हलपर्सना आधीच फायदा का आहे आधुनिक AI अनुप्रयोग स्टॅक TypeScript, React आणि HTTP API वर चालतो — तुम्ही दररोज वापरत असलेलीच साधने [1]. Next.js सारखे फ्रेमवर्क AI-चालित UI बिल्डर्सचे डिफॉल्ट आउटपुट बनले आहे, आणि Vercel AI SDK आधीच React इकोसिस्टममध्ये फर्स्ट-क्लास नागरिक आहे [2]. डेटा शास्त्रज्ञांप्रमाणे ज्यांना प्रथम डिप्लॉयमेंट आणि UI शिकणे आवश्यक आहे, त्यांच्याविपरीत, तुम्हाला आधीच उत्पादने कशी पाठवायची हे माहीत आहे. तुमचे आव्हान कसे बांधायचे हे शिकणे नाही — तर कोणत्या नवीन प्रिमिटिव्हसह बांधायचे हे शिकणे आहे.
JavaScript मध्ये पूर्वी कोड वेगवेगळ्या फाइल्समध्ये विभाजित करण्याचा कोणताही अंगभूत मार्ग नव्हता — या मर्यादेमुळे स्पर्धात्मक मॉड्युल फॉर्मॅट्सची एक संपूर्ण परिसंस्था निर्माण झाली. आज, डेव्हलपर्स require(), import, .mjs, .cjs, AMD, आणि UMD यांना बऱ्याचदा एकाच प्रकल्पात भेटतात. हे मार्गदर्शक प्रत्येक मॉड्युल सिस्टम समजावून सांगते, प्रत्येक केव्हा वापरायचे हे स्पष्ट करते, आणि पुढे जाण्याचा स्पष्ट मार्ग दाखवते.
JavaScript ला मॉड्युल सिस्टम्सची गरज का पडली वेबच्या सुरुवातीच्या दिवसांत, JavaScript हे साध्या पृष्ठ संवादांसाठी असलेली एक स्क्रिप्टिंग भाषा होती. जसजशे अॅप्लिकेशन्स वाढले, डेव्हलपर्सनी सर्वकाही ग्लोबल व्हेरिएबल्समध्ये कोंबले — ज्यामुळे नामकरण टकराव आणि अव्यवस्थापित “स्पघेट्टी” कोड निर्माण झाला [1]. समुदायाने भाषेच्या बाहेर मॉड्युल पॅटर्न्स शोधून उत्तर दिले: प्रथम खाजगी स्कोप तयार करण्यासाठी Immediately Invoked Function Expressions (IIFEs), नंतर AMD आणि CommonJS सारख्या औपचारिक मॉड्युल स्पेसिफिकेशन्स. 2015 मध्येच JavaScript ला ES6 स्पेसिफिकेशनद्वारे अखेरीस नेटिव्ह मॉड्युल सिस्टम मिळाली [6].
भारताचे सर्वात विश्वासू परीक्षा मंडळ CBSE मे 2026 मध्ये एका मोठ्या सायबर सुरक्षा घोटाळ्याने हादरले, जेव्हा एका 19 वर्षीय एथिकल हॅकरने त्याच्या ऑन-स्क्रीन मार्किंग (OSM) मूल्यमापन प्रणालीमध्ये थेट प्रवेशाचे प्रात्यक्षिक दाखवले — ज्यात प्रोडक्शन सर्व्हरवर शेल ऍक्सेस आणि असुरक्षित क्लाउड बकेटमधून विद्यार्थ्यांच्या उत्तरपत्रिका मोफत डाउनलोड करणे समाविष्ट होते [1][2]. या उल्लंघनामुळे अंदाजे 20 लाख इयत्ता 12 च्या विद्यार्थ्यांचा वैयक्तिक आणि शैक्षणिक डेटा धोक्यात आला [5]. हा लेख हॅकच्या प्रत्येक पैलूचे विश्लेषण करतो, विद्यार्थी आणि पालकांवर याचा काय परिणाम होतो हे स्पष्ट करतो, आणि पुनरावृत्ती टाळण्यासाठी सरकारने काय करायला हवे ते मांडतो.
क्लाउड कंप्युटिंग जगभरातील सॉफ्टवेअर चालवण्याच्या पद्धतीत बदल घडवत आहे — जागतिक बाजारपेठ 2026 मध्ये $1 ट्रिलियन जवळ पोहोचण्याच्या मार्गावर आहे [1], AI वर्कलोड, SaaS विस्तार आणि एंटरप्राइझ डिजिटल परिवर्तनामुळे. तरीही जर तुम्ही आधीच DigitalOcean Droplet किंवा तत्सम VPS वर अॅप्स डिप्लॉय करत असाल, तर तुम्हाला प्रश्न पडत असेल: मला खरंच काही बदलण्याची गरज आहे का? येथे एक प्रामाणिक, व्यावहारिक उत्तर आहे.
क्लाउड कंप्युटिंग म्हणजे काय? क्लाउड कंप्युटिंग म्हणजे संगणकीय संसाधने — सर्व्हर, स्टोरेज, डेटाबेस, नेटवर्किंग, सॉफ्टवेअर आणि विश्लेषण — इंटरनेटवर पे-ऍज-यू-गो आधारावर पुरवणे [1]. भौतिक हार्डवेअरचे मालक होण्याऐवजी, तुम्ही प्रदात्याकडून क्षमता भाड्याने घेता आणि कुठूनही त्यात प्रवेश करता. तीन प्रमुख खेळाडू म्हणजे AWS (~33% बाजार हिस्सा), Microsoft Azure (~23%), आणि Google Cloud (~12%), जे मिळून जागतिक क्लाउड पायाभूत सुविधा बाजाराच्या 60% पेक्षा जास्त नियंत्रित करतात [3].