डेवलपर्स को किन जालों से सावधान रहना चाहिए

 (qouteall.fun)
66 पॉइंट द्वारा GN⁺ 2025-08-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डेवलपर्स के लिए आम लेकिन सहज रूप से स्पष्ट न होने वाले जालों को संकलित किया गया है, और ऐसे बग्स के कारण बताए गए हैं जो आसानी से पैदा हो सकते हैं
  • HTML, CSS, Unicode/टेक्स्ट एन्कोडिंग, floating-point, समय आदि विभिन्न तकनीकों में अक्सर आने वाली समस्याओं को शामिल किया गया है
  • यह ज़ोर दिया गया है कि अलग-अलग भाषाओं और frameworks में syntax और behavior के सूक्ष्म अंतर गलतफहमी या त्रुटियाँ पैदा कर सकते हैं
  • concurrency, networking, database जैसे backend के मुख्य क्षेत्रों में, वास्तविक production environment में आने वाले जालों को उदाहरणों के साथ समझाया गया है
  • विभिन्न उदाहरणों और संदर्भ लिंक के ज़रिए समस्या की स्थिति, समाधान, और अप्रत्याशित behavior को बेहतर करने के तरीकों का मार्गदर्शन दिया गया है

HTML और CSS

  • Flexbox/Grid में min-width का डिफ़ॉल्ट मान

    • min-width का डिफ़ॉल्ट मान auto होता है
    • min-width: auto कंटेंट के आकार से तय होता है, और flex-shrink, overflow: hidden, width: 0, max-width: 100% से पहले लागू होता है
    • सिफारिश: min-width: 0 को स्पष्ट रूप से सेट करें

  • CSS में क्षैतिज और ऊर्ध्वाधर का अंतर

    • width: auto parent की जगह भरने की कोशिश करता है, जबकि height: auto कंटेंट के अनुसार तय होता है
    • inline, inline-block, float elements में width: auto फैलता नहीं है
    • margin: 0 auto क्षैतिज center alignment देता है, margin: auto 0 ऊर्ध्वाधर center alignment नहीं देता (हालाँकि flex-direction: column में ऊर्ध्वाधर center संभव है)
    • margin collapsing केवल ऊर्ध्वाधर दिशा में होता है
    • writing-mode: vertical-rl जैसी layout direction बदलने पर behavior भी उलट सकता है

  • Block Formatting Context (BFC)

    • display: flow-root से BFC बनाया जा सकता है (overflow: hidden/auto/scroll, display: table आदि से भी संभव है, लेकिन side effects हो सकते हैं)
    • ऊर्ध्वाधर रूप से लगे sibling margins का आपस में मिलना, या child margin का parent के बाहर निकल जाना, BFC से रोका जा सकता है
    • अगर parent में केवल float children हों तो उसकी height 0 तक गिर सकती है → BFC से ठीक किया जा सकता है
    • border या padding होने पर margin collapsing नहीं होता

  • Stacking Context

    • नया stacking context बनने की शर्तें
      • transform, filter, perspective, mask, opacity जैसी rendering properties
      • position: fixed या sticky
      • z-index सेट किया गया हो + absolute/relative positioning
      • z-index सेट किया गया हो + flexbox/grid के भीतर का element
      • isolation: isolate
    • विशेषताएँ
      • z-index केवल stacking context के अंदर ही लागू होता है
      • position: absolute/fixed के coordinates सबसे नज़दीकी positioned ancestor के आधार पर तय होते हैं
      • sticky stacking context को पार करके काम नहीं करता
      • overflow: visible भी stacking context के कारण कट सकता है
      • background-attachment: fixed stacking context के आधार पर रखा जाता है

  • Viewport units

    • mobile browser में address bar/navigation bar स्क्रोल पर स्क्रीन से गायब होने पर 100vh का मान बदल सकता है
    • नया समाधान: 100dvh का उपयोग

  • Absolute Position का आधार

    • position: absolute parent नहीं, बल्कि सबसे नज़दीकी relative/absolute या stacking context ancestor को आधार मानता है

  • Blur behavior

    • backdrop-filter: blur आसपास के elements को ध्यान में नहीं रखता

  • Float का निष्क्रिय होना

    • अगर parent flex या grid है, तो child का float प्रभावी नहीं होता

  • प्रतिशत आधारित width/height

    • अगर parent का आकार पहले से तय नहीं है, तो यह काम नहीं करता (circular reference से बचने के लिए)

  • Inline element की विशेषताएँ

    • display: inline में width, height, margin-top, margin-bottom अनदेखा किए जाते हैं

  • Whitespace handling

    • डिफ़ॉल्ट रूप से HTML में line breaks को whitespace माना जाता है, और लगातार आने वाले spaces एक space में समेट दिए जाते हैं
    • `` space collapsing को रोकता है, लेकिन शुरुआत/अंत में इसका behavior अलग हो सकता है
    • अधिकतर कंटेंट के शुरुआत/अंत के spaces अनदेखे किए जाते हैं, लेकिन `` एक अपवाद है
    • inline-block के बीच के spaces/line breaks वास्तविक gap के रूप में दिखते हैं (flex/grid में ऐसा नहीं होता)

  • text-align

    • यह text और inline elements के alignment पर लागू होता है, लेकिन block elements के alignment पर नहीं

  • box-sizing

    • डिफ़ॉल्ट मान content-box है → इसमें padding/border शामिल नहीं होते
    • width: 100% + padding सेट करने पर parent area से बाहर निकलने की संभावना होती है
    • समाधान: box-sizing: border-box

  • Cumulative Layout Shift

    • `` में width और height attributes न देने पर image loading delay के कारण layout हिल सकता है
    • सिफारिश: CLS रोकने के लिए attributes सेट करें

  • Chrome में file download network requests

    • DevTools के network panel में नहीं दिखतीं (उन्हें दूसरे tab में संभाला जाता है)
    • विश्लेषण की ज़रूरत हो तो chrome://net-export/ का उपयोग करें

  • HTML में JavaScript parsing समस्या

    • console.log('') जैसे मामले में पहला `` closing tag माना जाता है
    • संदर्भ: Safe JSON in script tags

Unicode और टेक्स्ट एन्कोडिंग

  • Code point और grapheme cluster

    • grapheme cluster GUI में दिखाई देने वाली "character unit" है
    • दिखने वाला ASCII character आमतौर पर 1 code point = 1 grapheme cluster होता है
    • emoji कई code points से मिलकर बना एक grapheme cluster हो सकता है
    • UTF-8 में code point 1~4 bytes का होता है, और bytes की संख्या code points की संख्या के बराबर नहीं होती
    • UTF-16 में code point 2 bytes या 4 bytes (surrogate pair) का हो सकता है
    • standard cluster के भीतर code points की संख्या पर सीमा नहीं लगाता, लेकिन implementations performance कारणों से सीमाएँ रख सकती हैं

  • भाषा के अनुसार string behavior का अंतर

    • Rust: internal string UTF-8 का उपयोग करती है, len() bytes की संख्या देता है, direct indexing संभव नहीं, chars().count() code points की संख्या देता है, UTF-8 validity की सख्ती से जाँच होती है
    • Golang: string व्यवहारतः byte array है, length और indexing byte units पर आधारित हैं, सामान्यतः UTF-8 उपयोग होता है
    • Java, C#, JS: UTF-16 आधारित, length 2-byte units में मापी जाती है, indexing भी 2-byte units पर होती है, surrogate pairs मौजूद होते हैं
    • Python: len() code points की संख्या लौटाता है, indexing एक code point वाला string लौटाती है
    • C++: std::string पर encoding की कोई बाध्यता नहीं, यह byte vector की तरह व्यवहार करता है, length/indexing byte units पर आधारित हैं
    • बताए गए भाषाओं में से कोई भी भाषा grapheme cluster unit पर length/indexing नहीं करती

  • BOM (Byte Order Mark)

    • कुछ text files में BOM होता है, उदाहरण: EF BB BF → UTF-8 encoding का संकेत
    • इसका उपयोग मुख्य रूप से Windows में होता है, और non-Windows software BOM को सही से संभाल नहीं सकता

  • अन्य सावधानियां

    • binary data को string में बदलते समय, गलत हिस्सों को � (U+FFFD) से बदल दिया जाता है
    • Confusable characters मौजूद होते हैं (ऐसे अक्षर जो एक-दूसरे जैसे दिखते हैं)
    • Normalization: उदाहरण: é को U+00E9 (एक single code point) या U+0065+U+0301 (दो code points) के रूप में दर्शाया जा सकता है
    • Zero-width characters और Invisible characters मौजूद होते हैं
    • लाइन ब्रेक का अंतर: Windows में CRLF \r\n, Linux/MacOS में LF \n
    • Han unification: अलग-अलग भाषाओं में आकार में थोड़ा अलग दिखने वाले अक्षर एक ही code point का उपयोग करते हैं
      • फ़ॉन्ट भाषा-विशिष्ट variants शामिल करके सही render करते हैं
      • internationalization के समय सही font variant चुनना ज़रूरी है

Floating point

  • NaN की विशेषताएं

    • NaN, खुद अपने सहित, किसी भी value के बराबर नहीं होता (NaN == NaN हमेशा false है)
    • NaN != NaN हमेशा true है
    • NaN शामिल होने पर अधिकांश operations का result NaN के रूप में propagate होता है

  • विशेष values

    • +Inf और -Inf मौजूद हैं, और ये NaN से अलग हैं
    • -0.0 एक ऐसी value है जो +0.0 से अलग मानी जाती है
      • comparison operations में दोनों समान हैं, लेकिन कुछ calculations में अलग तरह से behave करती है
      • उदाहरण: 1.0 / +0.0 == +Inf, 1.0 / -0.0 == -Inf

  • JSON के साथ compatibility

    • JSON standard NaN और Inf की अनुमति नहीं देता
      • JS JSON.stringify, NaN और Inf को null में बदल देता है
      • Python json.dumps(...), NaN और Infinity को वैसे ही output करता है (standard violation)
        • allow_nan=False option देने पर NaN/Inf होने पर ValueError आता है
      • Golang json.Marshal, NaN/Inf मौजूद होने पर error return करता है

  • precision की समस्या

    • floating point की direct comparison fail हो सकती है → abs(a - b) < ε वाला रूप recommended है
    • JS सभी numbers को floating point के रूप में handle करता है
      • safe integer range -(2^53 - 1) ~ 2^53 - 1 है
      • इस range से बाहर integer representation सटीक नहीं रहती
      • बड़े integers के लिए BigInt का उपयोग recommended है
      • अगर JSON में safe range से बड़े integers हों, तो JSON.parse का result inaccurate हो सकता है
      • millisecond-स्तर के timestamps 287,396 वर्षों तक safe हैं, nanosecond-स्तर पर समस्या आती है

  • गणितीय नियम लागू न होना

    • operation order के अनुसार precision loss होने से associativity और distributivity सख्ती से लागू नहीं होते
    • parallel operations (matrix multiplication, sum आदि) nondeterministic results दे सकते हैं

  • performance

    • division, multiplication की तुलना में काफी धीमा है
    • एक ही संख्या से कई बार divide करना हो तो पहले उसका reciprocal निकालकर multiply करना optimization हो सकता है

  • hardware के अनुसार अंतर

    • FMA(Fused Multiply-Add) support: कुछ hardware intermediate calculation को ज्यादा precision से करते हैं
    • Subnormal range handling: modern hardware इसे support करता है, लेकिन कुछ पुराने systems इसे 0 की तरह treat करते हैं
    • rounding mode में अंतर
      • RNTE (निकटतम even की ओर round), RTZ (0 की ओर truncate) आदि मौजूद हैं
      • x86/ARM में इन्हें thread-local mutable state के रूप में set किया जा सकता है
      • GPU में rounding mode instruction स्तर पर अलग हो सकता है
    • trigonometric functions, log आदि mathematical functions के behavior में अंतर
    • x86 में legacy 80-bit FPU और per-core rounding mode होता है → इसका उपयोग recommended नहीं है
    • इनके अलावा भी कई कारणों से hardware के अनुसार floating point results अलग हो सकते हैं

  • precision बढ़ाने के तरीके

    • calculation graph को shallow रखें (लगातार multiplication वाली structure कम करें)
    • ऐसे cases से बचें जहाँ intermediate values बहुत बड़ी या बहुत छोटी हों
    • FMA जैसे hardware operations का उपयोग करें

समय (Time)

  • leap second

    • Unix timestamp leap second को ignore करता है
    • leap second होने पर आसपास के interval में समय बढ़ाया या घटाया जाता है (Leap smear)

  • time zone

    • UTC और Unix timestamp पूरी दुनिया में समान होते हैं
    • मनुष्यों के पढ़ने योग्य समय क्षेत्रीय time zone पर निर्भर करता है
    • DB में timestamp store करके UI में convert करने का तरीका recommended है

  • daylight saving time (DST)

    • कुछ क्षेत्रों में गर्मियों के दौरान घड़ी को 1 घंटा आगे-पीछे किया जाता है

  • NTP synchronization

    • synchronization के दौरान समय के "पीछे जाने" जैसी स्थिति हो सकती है

  • server time zone setting

    • server को UTC पर set करना recommended है
    • distributed systems में अलग-अलग nodes के time zone अलग हों तो समस्या हो सकती है
    • system time zone बदलने के बाद DB को फिर से configure या restart करना पड़ सकता है

  • hardware clock vs system clock

    • hardware clock में time zone की अवधारणा नहीं होती
    • Linux: hardware clock को UTC के रूप में treat करता है
    • Windows: hardware clock को local time के रूप में treat करता है

Java

  • == object reference की तुलना करता है, object content की तुलना के लिए .equals का उपयोग करना चाहिए
  • अगर equals और hashcode को override नहीं किया गया, तो map/set में object identity को reference के आधार पर माना जाता है
  • अगर map की key object या set के element object की content बदल दी जाए, तो container का behavior टूट सकता है
  • List return करने वाले methods, स्थिति के अनुसार mutable ArrayList या immutable Collections.emptyList() return कर सकते हैं; दूसरे वाले को modify करने पर UnsupportedOperationException होता है
  • Optional return करने वाला method कभी-कभी null return कर सकता है (यह recommended नहीं है)
  • finally block में return करने पर, try या catch में हुई exception ignore हो जाती है और finally की return value लागू होती है
  • कुछ libraries interrupt को ignore करती हैं, और IO सहित class initialization process interrupt से टूट सकती है
  • thread pool में .submit() से दिए गए task की exception default रूप से log में नहीं छपती और सिर्फ future के जरिए देखी जा सकती है; future को ignore करने पर exception पता नहीं चलती
    • scheduleAtFixedRate jobs exception आने पर चुपचाप बंद हो जाती हैं
  • अगर numeric literal 0 से शुरू हो, तो उसे octal माना जाता है (0123 → 83)
  • debugger local variables की .toString() को call करता है; कुछ classes में toString() के side effects होते हैं, इसलिए debugging के दौरान code का behavior बदल सकता है (इसे IDE में disable किया जा सकता है)

Golang

  • append() में capacity बची हो तो memory reuse होती है; subslice पर append करने से parent memory भी overwrite हो सकती है
  • defer function return होने पर चलता है, block scope खत्म होने पर नहीं
  • defer mutable variables को capture करता है
  • nil से संबंधित
    • nil slice और empty slice अलग होते हैं
    • string nil नहीं हो सकती, केवल empty string होती है
    • nil map में read किया जा सकता है, लेकिन write नहीं
    • interface nil का विशेष behavior: अगर data pointer null हो लेकिन type info null न हो, तो वह nil के बराबर नहीं होता
  • Dead wait: Go में वास्तविक concurrency bug के मामले मौजूद हैं
  • Timeout के कई प्रकार हैं, net/http में इन्हें विस्तार से लिया गया है

C/C++

  • std::vector के elements के pointer को store करने के बाद अगर vector grow होता है, तो reallocation होती है और pointer invalid हो जाता है
  • string literal से बना std::string एक temporary object हो सकता है, इसलिए c_str() कॉल करना जोखिमभरा हो सकता है
  • iteration के दौरान container को modify करने पर iterator invalidation होता है
  • std::remove वास्तव में delete नहीं करता, बल्कि elements को rearrange करता है; delete के लिए erase चाहिए
  • अगर numeric literal 0 से शुरू हो, तो उसे octal माना जाता है (0123 → 83)
  • Undefined behavior (UB): optimization के दौरान UB को compiler मनचाहे तरीके से बदल सकता है, इसलिए इस पर निर्भर रहना खतरनाक है
    • uninitialized memory access UB है
    • char* को struct pointer में बदलने पर object lifetime शुरू होने से पहले access करना UB है; initialization के लिए memcpy recommended है
    • invalid memory access (जैसे null pointer) UB है
    • integer overflow/underflow UB है (unsigned में 0 से नीचे underflow हो सकता है)
    • Aliasing: अलग-अलग type के pointers अगर एक ही memory को reference करें, तो strict aliasing rule के कारण UB हो सकता है
      • exceptions: 1) inheritance relation वाले types 2) char*, unsigned char*, std::byte* में conversion (reverse conversion पर यह लागू नहीं होता)
      • forceful conversion के लिए memcpy या std::bit_cast recommended है
    • unaligned memory access UB है
  • Memory Alignment
    • 64-bit integer का address 8 से divisible होना चाहिए
    • ARM पर unaligned access crash करा सकता है
    • byte buffer को सीधे struct की तरह interpret करने पर alignment problem हो सकती है
    • alignment की वजह से struct padding बन सकती है, जिससे memory waste होती है
    • कुछ SIMD instructions (जैसे AVX) सिर्फ aligned data पर काम कर पाती हैं; आम तौर पर 32-byte alignment चाहिए

Python

  • function के default arguments हर call पर नए नहीं बनते, बल्कि शुरुआती value ही stored रहती है

SQL Databases

  • Null handling

    • x = null काम नहीं करता; x is null इस्तेमाल करना चाहिए
    • Null अपने आप के बराबर भी नहीं होता (NaN जैसा)
    • Unique index Null के duplicate values को allow करता है (लेकिन Microsoft SQL Server इसमें exception है)
    • select distinct में Null handling का तरीका DB के हिसाब से अलग हो सकता है
    • count(x) और count(distinct x) Null value वाली rows को ignore करते हैं

  • General behavior

    • date का implicit conversion timezone-dependent हो सकता है
    • complex join + distinct, nested query से धीमा हो सकता है
    • MySQL(InnoDB) में अगर string field utf8mb4 नहीं है, तो 4-byte UTF-8 character insert करने पर error आ सकता है
    • MySQL(InnoDB) by default case-sensitive नहीं होता
    • MySQL(InnoDB) implicit conversion allow करता है: select '123abc' + 1; → 124
    • MySQL(InnoDB) gap lock deadlock करा सकता है
    • MySQL(InnoDB) में group by और select columns match न करें, तो non-deterministic result मिल सकता है
    • SQLite में strict न हो, तो field type का बहुत मतलब नहीं होता
    • Foreign key implicit lock पैदा कर सकती है, जिससे deadlock हो सकता है
    • Locking, DB के हिसाब से repeatable read isolation को तोड़ सकती है
    • distributed SQL DBs locking support न करें या उनका behavior अलग हो सकता है (DB पर निर्भर)

  • Performance/Operations

    • N+1 query problem slow query log में नहीं दिखती, क्योंकि हर query अपने-आप में तेज होती है
    • long-running transactions lock जैसी problems पैदा कर सकती हैं → transaction को जल्दी खत्म करना recommended है
    • full table lock के cases
      • MySQL 8.0+ में unique index/foreign key add करते समय ज्यादातर concurrent processing संभव है
      • पुराने MySQL versions में full table lock हो सकता है
      • mysqldump में --single-transaction option न हो, तो full table read lock लगता है
      • PostgreSQL में create unique index या alter table ... add foreign key full table read lock करा सकता है
        • बचाव: create unique index concurrently इस्तेमाल करें
        • foreign key के लिए ... not valid के बाद validate constraint वाला तरीका इस्तेमाल करें

  • Range queries

    • non-overlapping ranges:
      • simple condition p >= start and p file 2>&1 → stdout+stderr दोनों file में, cmd 2>&1 > file → सिर्फ stdout file में, stderr वैसा ही रहता है

  • file name case-sensitive होते हैं (Windows से अलग)

  • executable files के लिए capability system होता है (getcap से जांचें)

  • unset variable का खतरा: अगर DIR unset है, तो rm -rf $DIR/ → rm -rf / चलने का जोखिम → set -u से बचाव संभव

  • environment apply करना: script को current shell में लागू करने के लिए source script.sh इस्तेमाल करें → permanent apply के लिए ~/.bashrc में जोड़ें

  • Bash में command caching होती है: $PATH के अंदर file move होने पर ENOENT आ सकता है → hash -r से cache refresh करें

  • variable को बिना quote के इस्तेमाल करने पर newline को space की तरह treat किया जाता है

  • set -e: script error पर तुरंत exit करता है, लेकिन conditional blocks (||, &&, if) के अंदर काम नहीं करता

  • K8s livenessProbe और debugger conflict: breakpoint debugger पूरे app को रोक देता है, जिससे health check fail हो सकता है → Pod terminate हो सकता है

React

  • rendering code में state को सीधे modify करना
  • Hook को if/loop के अंदर इस्तेमाल करना → rule violation
  • useEffect dependency array में ज़रूरी values छोड़ देना
  • useEffect में clean up code छोड़ देना
  • Closure trap: पुराने state capture होने से bug पैदा होता है
  • गलत जगह data बदलना → impure component
  • useCallback का उपयोग न करना → अनावश्यक re-rendering
  • memoized component को non-memoized value pass करना → memo optimization बेअसर हो जाती है

Git

  • Rebase history को rewrite करता है

    • rebase के बाद सामान्य push में conflict होगा → force push ज़रूरी है
    • remote branch history बदलने पर pull भी --rebase के साथ करें
    • --force-with-lease कुछ मामलों में दूसरे developers के commits overwrite होने से बचा सकता है, लेकिन सिर्फ fetch करके pull न करने पर यह सुरक्षा नहीं देता

  • Merge revert समस्या

    • merge revert का असर अधूरा होता है → उसी branch को दोबारा merge करने पर कोई बदलाव नहीं दिखता
    • समाधान: revert का revert करें या साफ तरीका अपनाएँ (backup → reset → cherry-pick → force push)

  • GitHub से जुड़ी सावधानियाँ

    • API key जैसे secret को commit करने के बाद force push से overwrite कर दें, तब भी GitHub पर उसका रिकॉर्ड रह जाता है
    • private repo A को fork करके बना B private हो, तब भी अगर A public हो जाए तो B की सामग्री भी public हो जाती है (delete के बाद भी access संभव)

  • git stash pop: conflict होने पर stash drop नहीं होता

  • .DS_Store macOS अपने-आप बनाता है → .gitignore में **/.DS_Store जोड़ना बेहतर है

Networking

  • कुछ routers और firewalls idle TCP connections को चुपचाप काट देते हैं → HTTP client और DB client के connection pool invalidate हो सकते हैं → समाधान: TCP keepalive configure करें
  • traceroute का result पूरी तरह भरोसेमंद नहीं होता → कुछ मामलों में tcptraceroute ज़्यादा उपयोगी होता है
  • TCP slow start latency बढ़ा सकता है → tcp_slow_start_after_idle disable करके हल संभव
  • TCP sticky packet समस्या: Nagle algorithm packet transmission delay करता है → TCP_NODELAY enable करके हल संभव
  • Nginx के पीछे backend रखने पर connection reuse setting ज़रूरी है → इसे न करने पर high-load environment में internal port exhaustion से connection fail हो सकते हैं
  • Nginx default रूप से packet buffering करता है → SSE(EventSource) में delay हो सकता है
  • HTTP standard GET और DELETE request body को मना नहीं करता → कुछ लोग body इस्तेमाल करते हैं, लेकिन कई libraries और servers इसे support नहीं करते
  • एक ही IP पर कई websites host की जा सकती हैं → फर्क HTTP Host header और TLS के SNI से किया जाता है → कुछ sites सिर्फ IP से direct access पर नहीं खुलतीं
  • CORS: दूसरे origin से request पर browser response access को block कर देता है → server पर Access-Control-Allow-Origin header set करना ज़रूरी है
    • cookie भेजनी हो तो अतिरिक्त configuration चाहिए
    • अगर frontend और backend same domain और port पर हों, तो CORS समस्या नहीं होती

Other

  • YAML सावधानियाँ

    • YAML whitespace-sensitive है → key:value गलत है, key: value सही है
    • country code NO को बिना quotes लिखने पर वह false के रूप में parse हो सकता है
    • Git commit hash को बिना quotes लिखने पर वह number में convert हो सकता है

  • Excel CSV समस्याएँ

    • Excel CSV खोलते समय automatic conversion करता है
      • date conversion: 1/2, 1-2 → 2-Jan
      • बड़े numbers का गलत conversion: 12345678901234567890 → 12345678901234500000
    • वजह यह है कि Excel internally numbers को floating point के रूप में handle करता है
    • इसी समस्या के कारण gene name SEPT1 के गलत बदल जाने का मामला भी सामने आ चुका है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-18
Hacker News राय

  • कुछ routers और firewalls application को कोई signal दिए बिना idle TCP connections को चुपचाप काट देते हैं। HTTP client libraries या database clients जैसे TCP connection pool बनाए रखने वाले code में इससे connection बिना किसी warning के invalid हो सकता है। इसे हल करने के लिए system TCP keepalive सेट किया जा सकता है, या HTTP में Connection: keep-alive, Keep-Alive: timeout=30, max=1000 headers इस्तेमाल किए जा सकते हैं। TCP connection एक बार establish हो जाने पर बीच के routers में state नहीं रहती। असली समस्या firewall या NAT session timeout की होती है। इस स्थिति में RST packet भी नहीं आता। K8s environment में conntrack module setting बहुत कम होने की समस्या भी देखी गई। HTTP Keep-Alive आज़माने पर भी वह सिर्फ connection reuse में मदद करता है, network पर connection को ज़िंदा नहीं रखता(व्याख्या लिंक)। HTTP Keep-Alive वास्तव में packet generate नहीं करता, सिर्फ close होने में देरी करता है। इसके विपरीत TCP Keep-Alive समय-समय पर packet भेजकर timer reset करता है।

    • TCP Keep-Alive mobile devices पर हमेशा ठीक से काम नहीं कर सकता। Mobile OS अक्सर सिर्फ application level पर बनने वाले keep-alive packets को अलग-अलग track या manage कर पाते हैं। लेकिन TCP Keep-Alive application level के नीचे काम करता है, इसलिए कुछ स्थितियों में इसे disable किया जा सकता है, और इस दौरान भी app अभी accessible रह सकता है।

  • Optional<T> return करने वाला method null भी return कर सकता है। यह व्यवहार बहुत confusing है। अगर भावनात्मक रूप से थोड़ा शांत होता तो शायद @java.lang.NonNullReference जैसी annotation लाने वाला JEP लिखा होता। इच्छा यह है कि इस annotation से type declare करने पर compiler null assignment को error माने। उदाहरण के लिए Alpha में null assignment संभव हो, लेकिन Beta में error आए। शायद javac में dead code elimination वास्तव में कैसे होता है, यह समझने के लिए spec भी देखनी पड़ेगी। उदाहरण के लिए if (true) में b = null वाला हिस्सा व्यवहार में elided हो सकता है, और कानूनी तौर पर वैध code भी माना जा सकता है।

    • Kotlin में ऐसे case पहले से ही compile error होते हैं। अलग annotation की भी ज़रूरत नहीं पड़ती।

    • जिस language में null है, उसमें Optional<T> का अलग से क्या फ़ायदा है, इस पर संदेह है। Python में function return type को Optional object की जगह सीधे T | None की तरह लिखा जाता है। अगर अंत में check तो वैसे भी करना है, तो framework का फर्क बहुत स्पष्ट नहीं लगता। कोई खास monad style न इस्तेमाल करें तो check अंततः वही रहता है।

  • कहा गया कि Java, C#, JS in-memory strings को UTF-16 जैसी encoding में रखते हैं, लेकिन Java के बारे में यह गलत है। C# और JS के लिए भी शायद यही बात लागू हो सकती है। किसी भी language में अगर string type पर्याप्त opaque हो, तो in-memory representation implementation detail होती है। Java में version 9 के बाद से यह और स्पष्ट है(संबंधित JEP लिंक)। FFI होने पर implementation details बदलना कठिन होने का यह भी एक कारण है। साथ ही JS numbers के बारे में कहा जाता है कि max accurate integer 2^53−1 है, लेकिन वास्तव में 2^100 जैसे बड़े integers भी exact represent किए जा सकते हैं। 2^53−1 का मतलब यह है कि n-1, n, n+1 तीनों IEEE double में ठीक-ठीक represent होते हैं। इसलिए n == n-1 और n == n+1 दोनों false आते हैं।

    • C# में in-memory representation काफ़ी fixed है। ReadOnlySpan<char> या raw char* के ज़रिए buffer को सीधे access करने के case आम हैं, इसलिए char एक UTF-16 codepoint type है। JS में शायद किसी तरह इससे बचा जा सके।

    • max accurate integer कहने से बेहतर max safe integer कहना ज़्यादा सही लगेगा।

    • (Base64 encoding के संदर्भ में) Java, C#, JS की in-memory strings UTF-16 जैसी नहीं हैं, यह तकनीकी रूप से सही हो सकता है, लेकिन अगर किसी UTF-8 आधारित language में string को Base64 encode करके Java में decode किया जाए, तो Java की UTF-16 representation की वजह से समस्या आने के मामले मौजूद हैं।

  • Manual format में लिखी tips या जानकारी उन्हीं चीज़ों को जल्दी समझने में मदद करती लगती है जो पहले से पता हों या लगभग पता हों। ज़्यादातर manuals सीखने से ज़्यादा organize करने और revision के लिए असरदार होते हैं, लेकिन किसी को बिल्कुल शुरुआत से सिखाने के लिए अक्सर अप्रभावी रहते हैं।

    • Manual का मूल उद्देश्य सिर्फ memory पर निर्भर रहने के बजाय record छोड़ना है। ज़्यादातर Unix manuals इसी रूप में होते हैं। जब पहले से पता हो कि कोई software क्या करता है, लेकिन उसका exact usage याद न आ रहा हो, तब manual देखा जाता है। दूसरी ओर, बिल्कुल beginner को concepts सीखने के लिए tutorial या guide चाहिए होती है। Manual बेहतर सवाल पूछने की तैयारी जैसा काम करता है।

  • “Traceroute Isn’t Real” नाम का लेख बहुत दिलचस्प लगा। लंबे समय से महसूस होता रहा कि traceroute data अक्सर बहुत inaccurate या अर्थहीन लगता है, और यह जानना उपयोगी था कि ऐसा क्यों होता है(मूल लिंक)। अगर किसी के पास इस पर नया update हो तो जानना अच्छा होगा।

  • यह लेख सचमुच traps की सूची कम और लेखक द्वारा अनुभव से सीखी गई छोटी tips का संग्रह ज़्यादा लगता है। कई बातें बहुत सीमित context में ही लागू होती हैं, लेकिन context स्पष्ट नहीं है। कुछ बातें गलत जानकारी जैसी भी लगती हैं। इसलिए पूरे लेख को बहुत शाब्दिक रूप से लेने के बजाय सोच की धारा या notes की तरह देखना बेहतर होगा।

  • Python में default argument value हर call पर नया बनने वाला value नहीं होती, बल्कि stored value होती है। datetime variables के साथ काम करते समय यह ज़रूर जानना चाहिए।

    • मैं Python का हमेशा का developer नहीं था, लेकिन इस हफ़्ते default argument values stored रहने की वजह से काफ़ी परेशानी हुई। सोचा था कि argument न देने पर empty set assign होगा, लेकिन वही set reuse हो गया और bug बन गया। कारण समझने में काफ़ी समय लगा।

  • पेज के पहले “trap” में कहा गया कि min-width: auto में minimum width content के हिसाब से तय होती है, लेकिन flex/grid न होने पर यह सही नहीं है। MDN के अनुसार block, inline, table आदि में auto को 0 के रूप में resolve किया जाता है(आधिकारिक दस्तावेज़ लिंक)।

    • असली पहला trap यह है कि “किसी भी CSS property को अलग-थलग पढ़ा नहीं जा सकता।” नाम की तरह ही cascading में default values और कई rules के परिणाम कहीं न कहीं मिलते हैं, इसलिए पूरे document का context महत्वपूर्ण है।

    • CSS text properties की cascade कुछ हद तक समझ में आती है। लेकिन CSS layout page designer, implementer, user—किसी भी नज़रिए से बहुत कठिन लगता है। समझ नहीं आता कि यह design आखिर किसके लिए है।

  • कुल मिलाकर यह एक ठीक-ठाक list article है। कुछ टिप्पणियाँ हैं।

    • Unicode Han unification के बारे में, अलग-अलग भाषाओं में एक ही अर्थ वाले अक्षर का एक ही codepoint इस्तेमाल होना और font के अनुसार अलग दिखना कोई trap नहीं है। दिए गए उदाहरण वाले Han characters चीन और जापान दोनों में लगभग वैसे ही इस्तेमाल होते हैं, और दोनों भाषाओं के उपयोगकर्ता दूसरे variants को भी उसी concept के character के रूप में पहचानते हैं। लेखक इसे ऐसे पेश कर रहा है जैसे letter A को English और French में अलग-अलग define करना पड़े। वास्तव में ऐसा नहीं है। Han unification देखें।
    • -0.0 और +0.0 (negative 0, positive 0) floating point comparison में बराबर माने जाते हैं, लेकिन उन्हें अलग पहचानने के तरीके हैं। जैसे उनके bit patterns से, या 1.0/-0.0 = -अनंत और 1.0/0.0 = +अनंत के परिणाम से।
    • server timezone को UTC पर रखने की सलाह से पूरी तरह सहमति है। Server, logs, photo storage जैसी हर जगह जहाँ preservation value हो या exact timestamp चाहिए, वहाँ UTC इस्तेमाल होना चाहिए। Local time सिर्फ बातचीत के लिए इस्तेमाल हो।
    • integers में (low + high) / 2 overflow दे सकता है, इसलिए low + (high - low) / 2 लिखने की सलाह दी गई, लेकिन अगर low या high negative हो सकते हैं, तो यह सिर्फ overflow range को शिफ्ट करना हो सकता है। सामान्य binary search में यह महत्वपूर्ण मुद्दा है।
    • C/C++ में integer types और operations को सही तरीके से इस्तेमाल करना भी बहुत बड़ा trap है। संबंधित guide लिंक
    • कहा गया कि rebase history बदल सकता है, लेकिन rebase तो अपने-आप में history rewrite करने वाला command है।

    • दोनों भाषाओं के उपयोगकर्ता conceptually एक ही character पहचानते हों, फिर भी इसे सिर्फ “font variation” कहकर टाला नहीं जा सकता। Unicode codepoint समान होने का मतलब यह नहीं कि character replacement सुरक्षित है। जापानी उपयोगकर्ताओं के लिए ऐसा replacement product इस्तेमाल न करने की वजह भी बन सकता है।

    • सच है कि English A और French A अलग नहीं किए जाते, लेकिन А (Cyrillic) और A (Latin) जैसे cases भी हैं जहाँ दिखने में समान होने पर भी codepoint अलग होता है। Han unification में भी कई बार काफ़ी अलग दिखने वाले glyphs को एक साथ बाँधा जाता है, इसलिए Japanese या Chinese सीखने वालों को वास्तविक भ्रम हो सकता है। उदाहरण के लिए '喝' (drink) character लिंक की तरह rendering के अनुसार काफ़ी अलग दिख सकता है। Copy करने पर भी उसका रूप तुरंत बदलता दिखाई दे सकता है, इसलिए इसका handling काफ़ी जटिल है। Han unification व्यवहार में सचमुच पेचीदा विषय है।

  • कहा गया कि numpy और pytorch के बीच सूक्ष्म अंतर हैं, लेकिन बिना ठोस examples के यह बहुत उपयोगी नहीं लगता और जानकारी भी अधूरी है, इसलिए इसे practical trap कहना कठिन है।