नोट्स
ब्लॉग
फ्रंटएंड इंजीनियरिंग, SEO, AI, एनालिटिक्स और असली प्रोडक्ट बनाने पर नोट्स।
42 पोस्ट
“Guaranteed Resources — No Sharing” के बावजूद मेरे AVA Hosting VPS पर औसत CPU Steal 32.73% था
सामान्य production traffic के दौरान मेरे AVA Hosting KVM VPS पर औसत CPU steal 32.73%, CPU idle 0% और CPU pressure लगभग 99% था। यह कोई नकारात्मक review नहीं, बल्कि Linux ने VM के अंदर वास्तव में क्या दिखाया, उसकी एक प्रत्यक्ष debugging कहानी है।
मेरा FDCServers VPS 3 TB से ज्यादा ट्रैफिक तक ठीक चला। फिर डिस्क पढ़ने में 18 सेकंड लगने लगे
मेरा FDCServers VPS शुरुआत में वास्तविक ट्रैफिक को सामान्य रूप से संभालता रहा और 3 TB से अधिक डेटा ट्रांसफर किया। बाद में सामान्य workload पर ही गंभीर virtual-disk stalls आने लगे: CPU iowait 100% तक पहुँचा, Linux I/O pressure लगभग 100% हुआ, read latency 18.7 सेकंड और flush latency 53 सेकंड से अधिक हो गई।
बिना ट्रैफिक के भी मेरे REGXA VPS पर 94% CPU Steal था
REGXA KVM VPS की गंभीर performance समस्या की जाँच में मुझे 92–94% CPU steal, कई सेकंड लेने वाले localhost requests, बढ़ती connection queues और दो मिनट से अधिक समय लेने वाले HTTP 504 मिले। पूरा production traffic हटाने के बाद CPU steal 94.17% हो गया, और बाद में REGXA ने इसे shared infrastructure पर resource contention का परिणाम बताया।
Nginx के पीछे Bunny Storage के साथ दो महीने: मैंने इमेज, वीडियो और ऑडियो को अलग मीडिया सर्वर पर क्यों भेजा
दो महीने तक मैंने Bunny CDN के बजाय Bunny Storage को अपने Nginx cache के पीछे private origin की तरह इस्तेमाल किया। Production logs में cold media requests पर long-tail connection timeout और MP4 के लिए Nginx Slice व inconsistent ETag की अलग समस्या सामने आई; अंततः मैंने एक सरल private media origin अपनाया।
WebP से AVIF ट्रांसकोडिंग में SSIMULACRA2: source के लिए 60 और lossy derivative के लिए 65 क्यों
पहले से lossy-compressed WebP से AVIF बनाते समय SSIMULACRA2 केवल दूसरी generation की degradation मापता है। इसलिए clean source के लिए मैं 60/58 और known lossy derivative के लिए 65/63 इस्तेमाल करता हूँ।
DeepSeek ने कीमतें बढ़ाईं — वही V4 Flash मुझे पुराने रेट से भी सस्ता मिल गया
17 अगस्त की सुबह मैंने देखा कि DeepSeek API पर मेरा खर्च सामान्य से लगभग पाँच गुना हो गया था। इसके बाद मैंने वही DeepSeek-V4-Flash-0731 checkpoint दूसरे provider पर पाया और टेस्ट किया, जिसकी मौजूदा कीमत DeepSeek के पुराने रेट से भी लगभग 45% कम है।
चलते WebP, GIF और APNG को फ़्रेम या समय बिगाड़े बिना H.264 MP4 में कैसे बदलता हूँ
मेरी उत्पादन प्रक्रिया उपयोगकर्ता को वास्तव में दिखाई देने वाले पूर्ण फ़्रेम पुनर्निर्मित करती है, स्रोत का समय सुरक्षित रखती है, हर अंतिम MP4 के लिए एक CFR चुनती है, बिना बड़ा किए सबसे छोटा साझा कैनवास बनाती है, संगत H.264 खंड एन्कोड करके उन्हें दूसरी हानिपूर्ण एन्कोडिंग के बिना जोड़ती है और फ़ाइल के साथ उसकी HTTP डिलीवरी भी जाँचती है। एक मापे गए रन में कुल 1.49 GB की 217 चलती WebP फ़ाइलें एक 78.49 MB H.264 MP4 बनीं।
मैं हर ब्राउज़र एरर पर अलर्ट भेज रहा था: शोर को उपयोगी प्रोडक्शन मॉनिटरिंग में कैसे बदला
मेरे शुरुआती फ्रंटएंड रिपोर्टर ने विज्ञापन ब्लॉक होने, GTM की विफलता, AbortError, अस्पष्ट Script error और असली Next.js चंक विफलताओं को एक जैसा माना। बाद में मैंने मॉनिटरिंग को स्वामित्व, उपयोगकर्ता पर असर, प्रमाण की गुणवत्ता, घटनाओं के सहसंबंध और रिकवरी के आधार पर दोबारा बनाया।
डिप्लॉयमेंट के बाद पुराने Next.js टैब क्यों टूटते हैं: पुराना HTML, गायब चंक और वर्ज़न असंगति
एक डिप्लॉयमेंट के बाद प्रोडक्शन मॉनिटरिंग में मेरी अपनी Next.js एप्लिकेशन का JavaScript चंक लोड नहीं हुआ। लॉग ने विफलता साबित की, कारण नहीं। उसी घटना के आधार पर यह लेख पुराने टैब, पुराने HTML, गायब /_next/static एसेट, वर्ज़न असंगति, पुराने संसाधन रखने की अवधि, deploymentId, सुरक्षित चरणबद्ध रिलीज़, मॉनिटरिंग और नियंत्रित पुनर्प्राप्ति को समझाता है।
एक टिक जिसने मेरा CFR तोड़ दिया: 5580 क्यों 5625 नहीं था और 3751 क्यों 3750 नहीं था
मेरे वैलिडेटर ने 16 fps MP4 को बार-बार इसलिए अस्वीकार किया क्योंकि एक पैकेट की अवधि 5625 के बजाय 5580 टिक थी। बाद में 24 fps पर 3750 की जगह 3751 टिक मिला। इन दोनों विफलताओं ने मुझे स्रोत समय-निर्धारण, CFR परिमाणीकरण, MP4 समय-आधार, PTS/DTS, मल्टीप्लेक्सिंग और पैकेट-स्तरीय सत्यापन को अलग-अलग समझने पर मजबूर किया।
H.264 के साथ मैंने वास्तविक संचालन के एक वीडियो को ~280 MB से ~50 MB तक कैसे घटाया
वास्तविक संचालन तंत्र का एक वीडियो H.264 विन्यास को CRF 28, x264 veryslow, 720p-श्रेणी की अधिकतम सीमा, उपयोगी फ्रेम दर और डिकोडर के लिए संतुलित सीमाओं के साथ दोबारा बनाने के बाद लगभग 280 MB से घटकर लगभग 50 MB रह गया। इससे पहले उसी उदाहरण को लगभग 350 MB से 238 MB तक घटाया जा चुका था, और पुरानी लाइब्रेरी की जाँच से पता चला कि कई मेगाबिट प्रति सेकंड वाले H.264 वीडियो सामान्य थे।
मैंने Gitae बनाया ताकि वेबसाइट आउटेज को सिर्फ “up या down” से आगे जाकर diagnose कर सकूँ
मैंने Gitae एक practical सवाल के लिए बनाया: website सच में unavailable है या समस्या सिर्फ local है? यह Moscow और Helsinki के external VDS checks को DNS, HTTPS/TLS, ports, routing, IP, hosting और CMS signals के साथ जोड़ता है और हर result को final proof नहीं, diagnostic evidence मानता है।
Production software में TypeScript और Codex की जोड़ी इतनी प्रभावी क्यों है
Production काम में TypeScript Codex को वह देता है जिसे अच्छा prompt भी replace नहीं कर सकता: machine-checkable contracts, तेज compiler feedback और बड़े refactor के लिए अधिक सुरक्षित रास्ता।
मैंने Jurfi.com बनाया: संरचित लीगल ड्राफ्ट के लिए ब्राउज़र-आधारित स्टूडियो
मैंने Jurfi.com को फॉर्म और टेम्पलेट से ब्राउज़र में संरचित लीगल वर्किंग ड्राफ्ट बनाने, ड्राफ्ट को लोकली रखने और रिव्यू को प्रक्रिया का साफ हिस्सा बनाए रखने के लिए बनाया है—बिना यह दावा किए कि सॉफ्टवेयर वकील की जगह ले सकता है।
SaaS से मेरी पहली कमाई: एक पेमेंट ने वास्तव में क्या साबित किया
मेरे अपने बनाए SaaS प्रोडक्ट से मिली पहली पेमेंट छोटी थी, लेकिन उसने मेरे पास मौजूद evidence की quality बदल दी। यह लेख बताता है कि एक transaction क्या validate कर सकती है, क्या साबित नहीं कर सकती, और milestone से ज्यादा repetition क्यों मायने रखती है।
मैं Codex से 15 प्रोजेक्ट कैसे रिव्यू करता हूँ और अंतिम नियंत्रण अपने पास रखता हूँ
15 software projects का review पहले repetitive checks में डूब जाने जैसा था। Codex bugs, tests, SEO, translations, localization और consistency को बहुत तेजी से जांचने में मदद करता है, लेकिन मैं हर AI finding को verdict नहीं बल्कि lead मानता हूँ और हर बदलाव को खुद verify करता हूँ।
मैं ChatGPT Plus में Codex limit के आखिरी 3–5% को बड़े engineering tasks पर क्यों खर्च करता हूँ — अपडेट: 2026 की गर्मियों में यह तरीका काम करना बंद कर गया
अपडेट: 2026 की गर्मियों तक यह workflow मेरे लिए भरोसेमंद नहीं रहा। मेरे account से 5-hour counter गायब हो गया, केवल weekly limit दिखी और लंबा task weekly allowance खत्म होने पर रुक सकता था।
मैंने AI से 10,000 SEO लेख प्रकाशित किए और आखिर में मेरी साइट Google में शून्य indexed pages तक गिर गई
Mass AI publishing शुरुआत में shortcut जैसा लगा: Google ने सभी 10,000 generated article URLs crawl किए, लेकिन केवल लगभग 1,000 pages वास्तव में index हुए, Search में दिखाई दिए और real traffic लाए। बाद में वे indexed pages भी गायब होते गए, जब तक पूरी site zero indexed pages तक नहीं पहुंच गई। इस experience ने AI, SEO, translation और editorial responsibility को लेकर मेरा approach बदल दिया।
8GB/256GB M1 MacBook के साथ पाँच साल: मैंने इसे अब तक क्यों नहीं बदला
मैंने 8GB मेमोरी और 256GB SSD वाला बेस M1 MacBook लगभग 1,000 डॉलर में खरीदा और उसे रोज़ करीब 15 घंटे सॉफ्टवेयर डेवलपमेंट, मीडिया वर्क, लेखन, सीखने और साइड प्रोजेक्ट्स के लिए इस्तेमाल किया। पाँच साल बाद इसकी सीमाएँ साफ दिखती हैं, लेकिन अपग्रेड पर विचार करने की वजह मेरा बढ़ा हुआ वर्कलोड है—यह नहीं कि मशीन अब उपयोगी नहीं रही।
मैंने ChatGPT से अपने ब्लॉग को 20 भाषाओं में अनुवाद किया — और दुनिया भर से सर्च ट्रैफिक आने लगा
AI ने मेरे लिए बहुभाषी पब्लिशिंग की लागत पूरी तरह बदल दी। एक भाषा वाले ब्लॉग से मैं हर लेख को अधिकतम 20 भाषाओं में प्रकाशित करने तक पहुँचा, जिससे ऑर्गेनिक सर्च के नए एंट्री पॉइंट बने।
मैंने QRViz को एक मुफ़्त static QR code generator के रूप में लॉन्च किया — और distribution को SEO पर छोड़ा
QRViz browser-based static QR code generator है, campaign platform नहीं। यह URL, Wi-Fi, vCard, PDF, menus, events, packaging और अन्य stable destinations को support करता है। Size, quiet zone, error correction, colors, gradients, eye styles और logo placement को adjust करके PNG, SVG या PDF export किया जा सकता है।. मैंने qrviz.com को एक फ्री QR कोड जनरेटर के रूप में लॉन्च किया, बिना विज्ञापन बजट, पेड एक्विज़िशन या मोनेटाइज़ेशन फ़नल के। लोगों तक पहुँचने के लिए मैं पूरी तरह SEO पर निर्भर हूँ, इसलिए डिस्ट्रिब्यूशन सबसे बड़ी अनिश्चितता है।
SaaS बनाने से ज्यादा कठिन मुझे ग्राहक लाना क्यों लगा
SaaS बनाने से मेरी सीधी सीख: इंजीनियरिंग में फीडबैक साफ और जांचने योग्य था, जबकि डिस्ट्रीब्यूशन, पोजिशनिंग, मैसेजिंग और रिटेंशन का लूप अलग और काफी कम अनुमानित था।
मैंने एक SaaS प्रोडक्ट अकेले बनाया। Payments ऑन होते ही काम का मतलब बदल गया
मैंने इस प्रोडक्ट को रातों, वीकेंड्स और छुट्टियों में अकेले बनाया। Payments live होते ही bugs, onboarding, moderation, retention और trust भविष्य के मुद्दे नहीं रहे; वे एक असली प्रोडक्ट चलाने का हिस्सा बन गए।
I Got 550 Views from One Image, Voiceover, and Subtitles: What Three Shorts Tests Actually Taught Me
A simple YouTube Short built from one static image, a voiceover, and subtitles reached 550 views. After three early tests, the useful lesson was not a proven formula, but a repeatable way to experiment without confusing a promising signal with proof.
मॉस्को की एक Frontend नौकरी पर मैंने लगभग 6,000 आवेदन देखे। यह रूस के IT बाजार के बारे में क्या बताता है — और क्या नहीं
2023 के आखिर में recruiters मुझे बताते थे कि एक opening पर 300–500 आवेदन भी बहुत हैं। 20 जनवरी 2026 को मैंने मॉस्को की एक mid-level Frontend भूमिका को कुछ ही घंटों में लगभग 6,000 आवेदनों तक जाते देखा। यहाँ मैं बताता हूँ कि यह संख्या किस बात का संकेत है, क्या साबित नहीं करती, और उम्मीदवार के रूप में मैं इसे अब कैसे पढ़ता हूँ।
DeepSeek ने मेरा Node.js workflow कैसे बदला: छह महीनों में 4,000+ commits
2025 में मेरा GitHub graph लगभग खाली रहने से साल के दूसरे हिस्से में 4,000 से ज़्यादा commits तक पहुँच गया। यह लेख बताता है कि AI coding ने मेरे Node.js side-project workflow को कैसे बदला, कहाँ समय बचाया, कहाँ गलत हुआ और verification generation speed से ज्यादा महत्वपूर्ण क्यों रहा।
28 की उम्र में मेरा पहला TikTok: एक vertical product demo ने मुझे traffic के बारे में क्या सिखाया
28 की उम्र में मैंने अपना पहला TikTok पोस्ट किया और उसी product demo को Reels और Shorts पर भी डाला। असली सीख views की संख्या नहीं थी; बल्कि यह कि 9:16 frame desktop interface को कितना बदल देता है और reach को acquisition समझे बिना short-form traffic कैसे मापा जाए।
मैंने 25 साल पुराना डोमेन खरीदा: dead URLs पर रोज़ 1,000+ requests आने लगीं
2000 में पहली बार रजिस्टर हुए डोमेन पर नया साइट लॉन्च करने के बाद मैंने पुराने URLs पर रोज़ 1,000 से ज़्यादा requests और Yandex Webmaster में एक ही रात में 900 से ज़्यादा errors देखे। यहाँ मैं बताता हूँ कि क्या वास्तव में साबित था, targeted 410 क्यों चुना और आज aged domain को कैसे audit करूँगा।
Yandex ने 12,500 पेज इंडेक्स कर लिए थे, फिर भी रूस से ट्रैफ़िक लगभग शून्य था: Cloudflare की समस्या जो मैं चूक गया
Yandex ने 12,500 पेज इंडेक्स किए हुए थे, लेकिन रूस से ट्रैफ़िक लगभग शून्य था। मैंने समस्या को नेटवर्क पाथ तक सीमित किया, Cloudflare प्रॉक्सी बंद की, कैशिंग, कंप्रेशन और बेसिक सुरक्षा को अपने VDS पर Nginx में स्थानांतरित किया और पहुंच बहाल हो गई।
मेरी static Next.js site पर रोज़ हजारों vulnerability scans आते हैं। Nginx पर मुश्किल से असर दिखता है
मेरे logs WordPress, PHP backdoors, .env और .git/config खोजने वाली probes से भरे रहते हैं। Static Next.js + Nginx setup में इनमें से ज़्यादातर low-cost misses और 404 बनकर खत्म हो जाते हैं, और observation के दौरान CPU load नहीं बदला। यह अनुभव static-site security के बारे में क्या साबित करता है—और क्या नहीं—यही महत्वपूर्ण हिस्सा है।
Yandex ने मेरी नई साइट पर ट्रैफ़िक भेजना शुरू किया, जबकि Google लगभग स्थिर रहा
उसी नए प्रोजेक्ट में Google ने लंबे समय में केवल करीब 300 क्लिक दिए, जबकि Yandex Webmaster में साफ़ बढ़त दिखी और एक समय क्लिक में +500% वृद्धि दिखाई गई। असली सवाल यह है कि ये आँकड़े क्या साबित करते हैं और क्या नहीं।
Yandex ने मेरी 4,278 Next.js पेज रातोंरात इंडेक्स कर दिए — इससे वास्तव में क्या साबित हुआ?
Yandex ने लगभग एक साथ मेरी 4,278 statically generated Next.js पेज इंडेक्स कर दिए। यह एक वास्तविक तकनीकी milestone था, लेकिन ranking या traffic की सफलता का प्रमाण नहीं। यहाँ मैं साफ़ करता हूँ कि इस नतीजे से SSG और programmatic SEO के बारे में क्या कहा जा सकता है और क्या नहीं।
SEO का मेरा पहला महीना: 632 ऑर्गेनिक विज़िटर और बॉट ट्रैफ़िक की एक रियलिटी चेक
काम पर एक बड़े SEO initiative की तैयारी के लिए मैंने अपने side project को प्रयोग की जगह बनाया। एक महीने में 632 ऑर्गेनिक विज़िटर मिले, लेकिन 83 विज़िटर वाले एक दिन ने दिखाया कि संदिग्ध traffic और analytics artifacts नतीजों की कहानी कितनी आसानी से बदल सकते हैं।
मैं Yandex Webmaster को लगभग नज़रअंदाज़ कर देता। दो हफ्ते बाद उससे Google से ज्यादा ट्रैफिक आ रहा था
SEO-केंद्रित काम के प्रोजेक्ट से पहले अभ्यास करने के लिए मैंने Next.js पर side project बनाया। पहले दो हफ्तों में Google से 58 और Yandex से 200 विज़िटर मिले, और मैंने सीखा कि traffic, indexing और diagnostics को अलग-अलग देखना चाहिए।
Yandex Metrica बनाम Google Analytics: एक हफ्ते बाद मैंने Metrica को क्यों पसंद किया
मैंने एक नए प्रोजेक्ट पर Google Analytics और Yandex Metrica को एक हफ्ते तक साथ चलाया। Metrica मेरी प्राथमिकता मुख्यतः Webvisor और session replay की वजह से बनी, लेकिन यह मेरे workflow का निष्कर्ष है—यह प्रमाण नहीं कि एक platform हर किसी के लिए बेहतर है।
Yandex ने मेरे ब्लॉग को /en के बिना crawl किया; 308 redirects ने 404 से बचाया
sitemap में लगभग 3,000 /en/blog/... पेज जोड़ने के बाद मैंने Yandex को उनके बराबर /blog/... paths crawl करने की कोशिश करते देखा। पहले से मौजूद 308 redirects ने इन requests को 404 पर खत्म होने से बचाया। असली सीख यह नहीं थी कि Yandex ने sitemap “तोड़ दिया”, बल्कि यह कि साफ redirect layer URL architecture को कितना resilient बना सकती है।
दो नई साइटों को Google में तेज़ स्पाइक मिला, फिर कुछ दिनों में ट्रैफ़िक लगभग 10× गिर गया
लगातार दो लॉन्च में Google impressions तुरंत बढ़े और कुछ दिनों बाद ट्रैफ़िक लगभग दसवें हिस्से तक गिर गया। पैटर्न वास्तविक था, लेकिन मैं यह साबित नहीं कर सकता कि यह तथाकथित Google “honeymoon” था।
Yandex Search से एक रात में 2,000 पेज गायब हो गए। इससे मैं वास्तव में क्या निष्कर्ष निकाल सकता था
Yandex Webmaster में मैंने देखा कि लगभग 8,000 पेजों में से 2,000 अब search में भाग नहीं ले रहे थे। 25% की गिरावट बड़ी थी, लेकिन असली सीख यह थी कि दिखे हुए search-status change को साबित कारण न मान लिया जाए।
MoscowJS 66 में मैंने 10 से ज़्यादा सवाल पूछे और दो इनाम जीते
MoscowJS 66 में Telegram bots, LangChain.js, site-builder architecture और TypeScript type testing पर talks के दौरान मैंने 10 से ज़्यादा सवाल पूछे। उनमें से दो को सबसे अच्छे सवाल चुना गया और मुझे दो इनाम मिले।
PiterJS #79 से मैंने क्या सीखा: Legacy Monoliths, FrontOps, Web Performance और बेहतर सवाल
सेंट पीटर्सबर्ग का PiterJS #79 मौजूदा सिस्टम को बनाए रखने पर केंद्रित था: legacy monolith, FrontOps और web performance metrics। मैं उपयोगी नोट्स, Q&A में मिले दो पुरस्कार और offline meetups में सक्रिय भागीदारी की अहमियत की नई याद के साथ लौटा।
मैंने 21 भाषाओं में Next.js ब्लॉग लॉन्च किया। 439 Google इम्प्रेशन ने मुझे वास्तव में क्या बताया
पहले सप्ताह में मेरे 21-भाषी Next.js ब्लॉग को Google से 439 इम्प्रेशन और 5 क्लिक मिले। बाद में 471 में से 436 पेज इंडेक्स थे। असली सीख थी—दिखाई देना, इंडेक्स होना और वास्तविक सर्च परफॉर्मेंस अलग-अलग चीजें हैं।
JavaScript के छह साल बाद MoscowJS 65: मैं अब भी स्थानीय मीटअप में क्यों जाता हूँ
5 जून 2025 को मैंने T Bank में MoscowJS 65 में हिस्सा लिया। चारों talks ने AI को अलग-अलग इंजीनियरिंग कोणों से देखा, लेकिन मेरी मुख्य सीख ज्यादा सरल थी: स्थानीय meetups आज भी कुछ ऐसा देते हैं जिसे documentation और recordings पूरी तरह replace नहीं कर सकते।