आजकल मुझे लगता है कि clean code से ज़्यादा बहस उन लोगों से हुई है जो किसी खास tech stack या architecture के इतने fan होते हैं कि जैसे अगर यह tech stack या architecture अपनाया नहीं गया तो बहुत बड़ी मुसीबत हो जाएगी। लगता है कि चीज़ों को स्थिति देखकर लागू करना सही है; हर चीज़ हर हाल में अच्छी नहीं होती।
ऐसा लगता है कि flink जैसे distributed systems में 2~3 rack बनाए रखकर HA बनाए रखना पड़ता है, लेकिन Kubernetes को जोड़कर HA सुनिश्चित किया गया है। लेकिन आखिरकार kube slave node के resources पर भी विचार करना होगा, तो सोचता हूँ कि क्या उन्होंने सिर्फ flink चलाने वाले nodes बनाए हैं (flink पर load बढ़ने पर slave node down होने की समस्या हो सकती है)।
उस नज़रिए से Kubernetes इस्तेमाल करने का फ़ायदा क्या होगा?
साथ ही, flink में window function इस्तेमाल करने पर उस दौरान data memory में बना रहता है और उसी से SQL join statement काम करता है। trade-off के नज़रिए से देखें तो क्या flink वाकई अच्छा विकल्प है, यह सोचने वाली बात है। समय के साथ बहुत बड़ा होता जाने वाला SQL + job अगर मर जाए तो उससे पैदा होने वाली भारी समस्या...
मैं भी सोच रहा हूँ कि जब सबसे ऊपर वाले data source पर join की ज़रूरत हो, तब flink का इस्तेमाल किए बिना किस तरह इसे application level पर नीचे लाकर process किया जा सकता है।
सब कुछ अच्छा है, लेकिन कोरिया में इसे खरीदने के लिए विदेश में रहने वाले किसी परिचित की ज़रूरत होना एक बहुत बड़ी कमी है...
सुना है कि फ़ॉरवर्डिंग एजेंसियों को भी काफ़ी सख़्ती से रोकते हैं
अच्छी पोस्ट के लिए धन्यवाद। मैं AWS में जनरेट होने वाली फ़ाइलों (जैसे रिपोर्ट) को HWP में बनाना चाहता हूँ, लेकिन संबंधित रेफ़रेंस कम होने के कारण दिक्कत आ रही है। फिलहाल हम Word का उपयोग कर रहे हैं। अगर आपके पास कोई ऐसी सामग्री हो जो संदर्भ के तौर पर मददगार हो, तो कृपया लिंक साझा करें।
पहले मैंने सुना था कि hwpx बस hwp के binary को साधारण रूप से xml में खोलकर लिखने के बाद zip में बाँध दिया गया है।
फिर भी कम-से-कम इसे पढ़ा तो जा सकता है...
कोडिंग self-help किताबें उन शुरुआती लोगों के लिए ठीक हो सकती हैं जिनके पास तकनीक या implementation methods को लेकर अभी कोई ठोस दृष्टिकोण नहीं है, लेकिन मेरा मानना है कि अनुभव बढ़ने के साथ उनकी उपयोगिता कम होती जाती है। इसकी वजह यह है कि हर project और environment पर लागू होने वाला कोई पूर्ण सत्य नहीं होता, और कई बार ऐसे हालात भी आते हैं जहाँ सामान्य सिद्धांत काम नहीं करते। दूसरे सामान्य क्षेत्रों की self-help किताबों की सलाह की तरह, उनसे थोड़ा फासला रखते हुए सिर्फ वही सलाह अपनाना बेहतर लगता है जो परिस्थिति के अनुकूल हो, और सलाह का अंधाधुंध पीछा नहीं करना चाहिए।
ब्लैक बॉक्स जैसी चीज़ सच में डरावनी होती है। "ये आखिर काम कैसे कर रहा है?"
"AI हमेशा के लिए स्वतंत्र रूप से काम नहीं कर सकता"
यह हिस्सा प्रभावशाली लगा।
आजकल मुझे लगता है कि clean code से ज़्यादा बहस उन लोगों से हुई है जो किसी खास tech stack या architecture के इतने fan होते हैं कि जैसे अगर यह tech stack या architecture अपनाया नहीं गया तो बहुत बड़ी मुसीबत हो जाएगी। लगता है कि चीज़ों को स्थिति देखकर लागू करना सही है; हर चीज़ हर हाल में अच्छी नहीं होती।
ऐसा लगता है कि flink जैसे distributed systems में 2~3 rack बनाए रखकर HA बनाए रखना पड़ता है, लेकिन Kubernetes को जोड़कर HA सुनिश्चित किया गया है। लेकिन आखिरकार kube slave node के resources पर भी विचार करना होगा, तो सोचता हूँ कि क्या उन्होंने सिर्फ flink चलाने वाले nodes बनाए हैं (flink पर load बढ़ने पर slave node down होने की समस्या हो सकती है)।
उस नज़रिए से Kubernetes इस्तेमाल करने का फ़ायदा क्या होगा?
साथ ही, flink में window function इस्तेमाल करने पर उस दौरान data memory में बना रहता है और उसी से SQL join statement काम करता है। trade-off के नज़रिए से देखें तो क्या flink वाकई अच्छा विकल्प है, यह सोचने वाली बात है। समय के साथ बहुत बड़ा होता जाने वाला SQL + job अगर मर जाए तो उससे पैदा होने वाली भारी समस्या...
मैं भी सोच रहा हूँ कि जब सबसे ऊपर वाले data source पर join की ज़रूरत हो, तब flink का इस्तेमाल किए बिना किस तरह इसे application level पर नीचे लाकर process किया जा सकता है।
यह एक शानदार चर्चा है।
वैसे सोचूँ तो, मैं जूनियर्स को John की philosophy of sw design की सिफारिश करता हूँ, लेकिन clean code की खास तौर पर सिफारिश नहीं की थी।
लगता है मूल पोस्ट हटा दी गई है। इसे Web Archive में देखें
https://web.archive.org/web/20250225151227/…
वाह, मैंने अभी PR review करने वाला GitHub app activate करके देखा है। यह कैसा होगा, इसे लेकर जिज्ञासा है।
सब कुछ अच्छा है, लेकिन कोरिया में इसे खरीदने के लिए विदेश में रहने वाले किसी परिचित की ज़रूरत होना एक बहुत बड़ी कमी है...
सुना है कि फ़ॉरवर्डिंग एजेंसियों को भी काफ़ी सख़्ती से रोकते हैं
कहा जाता है कि वह लगभग docx को ज्यों का त्यों फॉलो करता है.
MS ने भी पहले doc से docx बनाते समय ऐसा ही किया था.
मुझे लगता है कि किसी भी headline का आँख मूंदकर पालन करने के बजाय, उसके संदर्भ को अच्छी तरह समझकर लागू करना ज़्यादा महत्वपूर्ण है।
उम्... TS की तुलना में क्या यह ज़्यादा type-safe development होगा, यह जानने की उत्सुकता है।
2021-02 मॉड्यूलर लैपटॉप, Framework Laptop का अनावरण
2021-07 Framework Laptop की शिपिंग शुरू और रिव्यू प्रकाशित
2021-10 मॉड्यूलर लैपटॉप Framework Marketplace का अनावरण
2022-01 मॉड्यूलर लैपटॉप Framework ने firmware को open source किया
2022-05 नए अपग्रेड के साथ Framework Laptop की घोषणा
2022-09 मॉड्यूलर लैपटॉप Framework ने Google के साथ Chromebook edition की घोषणा की
2024-01 Framework Laptop 16 रिव्यू
हूँ, Chromebook तक को अपग्रेड करने लायक बनाया गया, लेकिन डेस्कटॉप की अपग्रेडेबिलिटी ही सीमित है।
मेरे हिसाब से भी यह Hancom Hangul 97 के आने तक एक बेहतरीन सॉफ़्टवेयर था।
अच्छी पोस्ट के लिए धन्यवाद। मैं AWS में जनरेट होने वाली फ़ाइलों (जैसे रिपोर्ट) को HWP में बनाना चाहता हूँ, लेकिन संबंधित रेफ़रेंस कम होने के कारण दिक्कत आ रही है। फिलहाल हम Word का उपयोग कर रहे हैं। अगर आपके पास कोई ऐसी सामग्री हो जो संदर्भ के तौर पर मददगार हो, तो कृपया लिंक साझा करें।
बस AI की ट्रेनिंग को PDF पर फोकस करना चाहिए, और Hancom Word प्रोसेसर के लिए अच्छा PDF converter बनाना बेहतर नहीं होगा? हाहा
MS Word या Libre Office की तुलना में, Hangeul से मनचाहे फ़ॉर्मैट का दस्तावेज़ बनाना कहीं ज़्यादा आसान लगा। साझा करना तो PDF में कर ही सकते हैं।
बेशक, मुझे Hangeul की आदत होने की वजह से भी ऐसा ज़्यादा महसूस हुआ होगा।
पहले मैंने सुना था कि hwpx बस hwp के binary को साधारण रूप से xml में खोलकर लिखने के बाद zip में बाँध दिया गया है।
फिर भी कम-से-कम इसे पढ़ा तो जा सकता है...
Han/Geul दस्तावेज़ फ़ाइल फ़ॉर्मैट: HWP फ़ॉर्मैट संरचना पर एक नज़र
कोडिंग self-help किताबें उन शुरुआती लोगों के लिए ठीक हो सकती हैं जिनके पास तकनीक या implementation methods को लेकर अभी कोई ठोस दृष्टिकोण नहीं है, लेकिन मेरा मानना है कि अनुभव बढ़ने के साथ उनकी उपयोगिता कम होती जाती है। इसकी वजह यह है कि हर project और environment पर लागू होने वाला कोई पूर्ण सत्य नहीं होता, और कई बार ऐसे हालात भी आते हैं जहाँ सामान्य सिद्धांत काम नहीं करते। दूसरे सामान्य क्षेत्रों की self-help किताबों की सलाह की तरह, उनसे थोड़ा फासला रखते हुए सिर्फ वही सलाह अपनाना बेहतर लगता है जो परिस्थिति के अनुकूल हो, और सलाह का अंधाधुंध पीछा नहीं करना चाहिए।