कॉफी के बारे में और वेब के बारे में, या PHP एक बाइक क्यों है

नहीं, नहीं। लेख PHP में बाइक लिखने के दृष्टिकोण के बारे में नहीं है, अर्थात् PHP अपने आप में एक बाइक है। और नहीं, लेखक उन आलसी लोगों में शामिल होने की कोशिश नहीं करता है जो PHP को किक करना चाहते हैं। बल्कि, यह कहा जाएगा कि न केवल PHP लेखक को किक करने वाला है। सावधानी: लेख अत्यंत क्रियात्मक है।

PHP हमारे समय की काफी अनोखी घटना है। PHP में प्रवेश की सीमा कम है, PHP अच्छी है क्योंकि tra-la-la, tra-la-la। आप खुद भी मुझसे बेहतर ये सब जानते हैं। यह PHP पर है कि बड़ी संख्या में साइटें और ब्लॉग कताई कर रहे हैं, जिनमें से रचनाकारों को कभी-कभी प्रोग्रामिंग के बारे में बिल्कुल पता नहीं है। जूमला और वर्डप्रेस इसका ज्वलंत प्रमाण हैं। और मैं विशेष रूप से ऐसी साइटों के रचनाकारों के बारे में बात कर रहा हूं, न कि इन इंजनों के लेखकों के बारे में। हालांकि, किसी भी व्यंग्य के बिना, मैं ध्यान देता हूं कि PHP वास्तव में कई मायनों में अच्छा है, और व्यक्तिगत रूप से मैं इसे बायटेकोड में एक पूर्ण बुराई नहीं मान सकता। बस कई, अच्छी तरह से, बहुत, बहुत से किसी कारण से भूल जाते हैं कि PHP सिर्फ एक टेम्पलेट इंजन है।



खैर, हाँ। यह सिर्फ एक बहुत, बहुत उन्नत टेम्पलेट इंजन है। इतना उन्नत कि इसमें OOP, नेमस्पेस, और सभी प्रकार की बहुत सारी उपयोगी और सुविधाजनक चीजें हैं। और उनके पास पहले से ही एक अंतर्निहित वेब सर्वर है, वे कहते हैं। मुझे पक्का पता नहीं है, मैंने व्यक्तिगत रूप से जाँच नहीं की है, क्योंकि मैं अब पीछे नहीं हूँ।

मुझे लगता है कि सभी के लिए माफी माँगना उचित होगा और यदि कोई भी निर्णय किसी के लिए अपमानजनक या अपमानजनक लगता है। कोई विचार नहीं था। बल्कि, इसके विपरीत: मैं ईमानदारी से निस्वार्थ रूप से अक्सर बहुत, बहुत अच्छे कोड लोगों को लिख रहा हूं, और ऐसे काम और ऐसे लोगों का बहुत सम्मान करता हूं। उदारता से क्षमा करें और कड़ाई से न्याय न करें। मैं आज आईटी और विशेष रूप से, वेब में, जो कुछ भी हो रहा है, सब कुछ देखता हूं और चुप रहना अधिक कठिन हो जाता है। इसलिए, लेख एक अर्ध-दार्शनिक प्रतिबिंब और विचार है, और इसमें बिल्कुल व्यावहारिक सिफारिशें नहीं हैं। लेकिन, फिर भी, मैं वास्तव में आशा करना चाहता हूं कि मुझे कुछ व्यावहारिक अर्थ बताने में सफल होंगे। यह ओपस Habré पर कई प्रकाशनों से प्रेरित है और न केवल - वेब के बारे में और इसके सूर्यास्त के बारे में, HTML5 / CSS / JS के बारे में और न केवल टेम्पलेट इंजन, फ्रेमवर्क और डिजाइन के बारे में; और साथ ही इस सब पर टिप्पणी भी।

खैर, हमेशा की तरह, लेखक के बारे में थोड़ा। लेखक टीम लीडर नहीं है, सीईओ नहीं है, जूनियर या सीनियर नहीं है। सामान्य तौर पर, एक प्रोग्रामर के रूप में लेखक का करियर अभी तक विभिन्न कारणों से किसी तरह विकसित नहीं हुआ है, हालांकि इसके लिए आवश्यक शर्तें थीं। विशेष रूप से, पूर्व-वयस्कता में, लेखक को Z80 mnemonics में शानदार खिलौनों और प्रोग्रामिंग के विघटन से उचित मात्रा में आनंद मिला। लेकिन भविष्य में, व्यक्तिगत परिवर्तन और उस स्थान पर संभावनाओं की कमी और उस समय एक शौक श्रेणी में यह सब धक्का दिया, एक अपरिचित मंच पर एक अपरिचित मंच पर मास्टर फेलर 2.6 को असफल करने का असफल प्रयास, और पूरी तरह से समझ में नहीं आने के बाद, कोडांतरक के बाद, एमएस से ओओपी ने इसमें बहुत योगदान दिया। लेकिन जो उन्होंने भविष्य में जोर से परिचित आईटी को कॉल करना शुरू कर दिया, उसे जाने नहीं दिया, परिणामस्वरूप, एक सिस्टम प्रशासक के रूप में एक छोटे से राज्य कार्यालय में कई साल बिताए गए थे। हालांकि, प्रोग्रामिंग के बारे में विचारों ने लेखक को वीबी / वीबीए / वीबीएस, डेल्फी, एमएस वीसी ++, भयानक और गलत समझा एमएफसी में विसर्जन के विभिन्न डिग्री के माध्यम से नेतृत्व किया, जिसके बाद लेखक ने बोरलैंड सी ++ और उनके वीसीएल के साथ कुछ समय के लिए शांति पाई। उसके बाद, प्रोग्रामिंग के तरीकों और प्रणालियों और इंटरफेस के डिजाइन पर साहित्य लॉन्च किया गया था। तब PHP, ActionScript (जो 3.0), पायथन और, निश्चित रूप से, HTML / CSS / JS की पवित्र त्रिमूर्ति थी। जावा को लंबे समय तक वैचारिक कारणों के लिए ध्यान में नहीं रखा गया था, लेकिन यह, जैसा कि यह निकला, अपरिवर्तित नहीं है। मैं दोहराता हूं (यह महत्वपूर्ण है), उपरोक्त सभी संक्षिप्त रूप और नामों का अध्ययन किया गया और केवल एक शौक के रूप में प्रयास किया गया; व्यावहारिक अनुप्रयोग (व्यावसायिक आधार पर) अक्सर नहीं हुआ, लेकिन फिर भी हुआ। तो चुच्ची, आखिरकार, एक लेखक की तुलना में अधिक पाठक है। फिलहाल, वेब-आधारित सहित (deja vu) प्रोग्रामिंग के क्षेत्र में आत्मनिर्भरता के लिए लेखक के संक्रमण के कारण राज्य कार्यालय अतीत में बना हुआ है। और हां, पहले डंप करना जरूरी था।
इसके अलावा, लेखक को अक्सर JFDI के सिद्धांतों की अनदेखी करने के लिए दोस्तों द्वारा डांटा जाता है (लेखक "शांत सवारी" और "सात बार मापें" की श्रेणी से लोक ज्ञान का सम्मान करता है ), साथ ही चरम क्रिया के लिए भी।
और आखिरी एक: लेखक स्वयं को विशेष रूप से आत्म-विडंबना के संदर्भ में एक तीसरे व्यक्ति की अपील का उपयोग करता है, क्योंकि वह उपरोक्त सभी को बहुत मजाकिया (लेकिन कुछ हद तक उदास भी) देखता है। लेकिन इसके बारे में पर्याप्त है।

तो, टेम्पलेट इंजन। एक पल के लिए सोचो, लेकिन एक टेम्पलेट इंजन के रूप में मानी जाने वाली चीज क्या करती है? ज्यादातर मामलों में, टेम्प्लेट इंजन, मोटे तौर पर बोलते हुए, एक टेम्प्लेट प्राप्त करता है (या, अधिक बार, एक टेम्प्लेट फ़ाइल का लिंक) और इनपुट पर चर का एक सेट, और चर के मूल्यों से भरे टेम्पलेट के रूप में तैयार पाठ बनाता है। इसके अलावा, डिफ़ॉल्ट टेम्पलेट अक्सर उपयोग किया जा सकता है। सिद्धांत रूप में, आप अक्सर चर नहीं पास कर सकते हैं, फिर आउटपुट एक साफ टेम्पलेट होगा। इसके अलावा, कुछ टेम्प्लेट इंजन डेटाबेस से कुछ डेटा का अनुरोध करने और इसे टेम्प्लेट में सम्मिलित करने में सक्षम हैं, हालांकि, यह स्वतंत्रता एमवीसी अवधारणाओं के साथ असंगति के कारण कई लोगों द्वारा अस्वीकार्य मानी जाती है। मुझे लगता है कि कई लोग पहले ही अनुमान लगा चुके हैं कि मुझे क्या मिल रहा है।
वास्तव में, मैंने कुछ भी नया नहीं कहा, क्योंकि PHP की कल्पना एक टेम्पलेट इंजन के रूप में की गई थी। यह एक टेम्पलेट इंजन की तरह काम करता है: एक अनुरोध प्राप्त हुआ - संसाधित - एक जवाब लौटा - नींद (या काम का अंत)। मैं इसके इस्तेमाल के बिल्कुल विरोध में नहीं हूं। लेकिन मैं पूरी तरह से अस्थायी इंजन बनाने के लिए एक टूलकिट के रूप में PHP का उपयोग करने के खिलाफ हूं। मैं PHP फ्रेमवर्क और सीएमएस लिखने के खिलाफ भी हूं, विशेष रूप से, ओओपी का उपयोग करके (और यहां तक ​​कि अगर वर्ग पदानुक्रम हजारों टुकड़ों तक बढ़ता है)।

हालाँकि, यह केवल एक परिचय है। कहानी सिर्फ शुरुआत है, क्योंकि यहां समस्या बहुत व्यापक और गहरी है। लेकिन चलो थोड़ा सा खोदो और बाइक को देखो। शाब्दिक अर्थों में। स्टीयरिंग व्हील, पैडल और पहियों की एक जोड़ी। आपको क्या लगता है कि साइकिल चलाने की गति का विश्व रिकॉर्ड क्या है? कुछ समय पहले तक मुझे कुछ पता नहीं था। हालाँकि, एक साधारण खोज 268 किमी / घंटा प्रदर्शित करती है। जरा सोचो: यह पता चला है कि आप एक साइकिल की सवारी कर सकते हैं कि हर कार सक्षम नहीं है! बेशक, और किसी भी सड़क पर नहीं, ऐसी गति विकसित की जा सकती है, और विभिन्न चाल की आवश्यकता होगी।

अब देखते हैं कि साइकिल का उपयोग कौन करता है:

• एथलीट - उनके साथ सब कुछ स्पष्ट है; खेल एक खेल है। वह ऐसा है क्योंकि यह ऐतिहासिक रूप से हुआ है।
• बच्चे - ये अभी तक या तो कार चलाने के लिए, या कानूनी रूप से शारीरिक क्षमता के लिए परिपक्व नहीं हुए हैं। सामान्य तौर पर, अभी भी छोटा है। केवल बाइक ही रहती है।
• जिन लोगों के पास कार खरीदने की वित्तीय क्षमता नहीं है।
• लोग वैचारिक रूप से विभिन्न कारणों से इस प्रकार के परिवहन के लिए प्रतिबद्ध हैं (पारिस्थितिकी, स्वास्थ्य, फिर से, पैसा, लेकिन पहले से ही "सिद्धांत से बाहर")।

और किन स्थितियों में:

• साइकिल ट्रैक / ओलंपिक ट्रैक।
• बस "ड्राइव" / सवारी।
• "तेज गाड़ी चलाओ" कहीं पास में।
• विकल्पों की अनुपस्थिति में, आप और अधिक दूर जा सकते हैं, लेकिन यह आसान नहीं होगा।
• आप मैनुअल ले जाने के लिए कुछ भारी पर भी ला सकते हैं या रोल कर सकते हैं।

उपरोक्त को विभिन्न रूपों में भी जोड़ा जा सकता है। जैसा कि आप देख सकते हैं, व्यावहारिक रूप से साइकिल का उपयोग जनता के बीच शायद ही कभी किया जाता है (अधिकांश यूरोप और एशिया इस बात से सहमत नहीं होंगे, लेकिन इसके कारण हैं)। यह समझ में आता है - क्यों, अगर यह अधिक आरामदायक और तेज है? इसके अलावा, हर कोई एक साइकिल की सवारी करने का जोखिम नहीं उठा सकता है, कहते हैं, एक व्यापार बैठक के लिए। क्योंकि इसके लिए पर्याप्त साहस और आराम के लिए कुछ अवहेलना की आवश्यकता होती है (जब आप पैडल करते हैं) हां, और एक केस के साथ टाई के साथ एक सख्त सूट में एक आदमी, और, एक ही समय में, एक साइकिल पर, मेरे लिए कल्पना करना मुश्किल है। लेकिन फिर से - यह हर जगह ऐसा नहीं है, कहीं न कहीं यह सामान्य है।

इसलिए, हमारे पास अलग-अलग दुनिया से दो संस्थाओं की तुलना करने के लिए क्या है:

• और जाओ और जाओ - सरल और सस्ती
• लेकिन दूर और तेजी से नहीं जाना
• आप दूर तक जा सकते हैं, लेकिन यह पूरी तरह से त्वरित और थकाऊ होगा
• आप जल्दी से जा सकते हैं, लेकिन लंबे समय तक नहीं, और पहले से ही, सामान्य तौर पर, सस्ता नहीं है, और इससे भी अधिक थका हुआ है। और, सबसे अधिक संभावना है, दूर नहीं। और हर जगह यह ध्यान केंद्रित नहीं होगा।

अंतिम बिंदु सबसे स्पष्ट है। PHP के संबंध में, शायद, आप "अल्पकालिक" को बाहर कर सकते हैं, लेकिन अन्यथा - लगभग वैचारिक तुलना। हमें एक "कैप" / "एयर कॉरिडोर" की आवश्यकता है, जिसे इस अवसर के लिए विशेष रूप से आयोजित किया जाना चाहिए, और जो सबसे अधिक संभावना है, फिर कभी उपयोगी नहीं होगा। हमें एक चिकनी सड़क की जरूरत है, जो हर जगह नहीं है। हालांकि, किसी भी भूमि परिवहन के लिए एक चिकनी सड़क बेहतर है। और यह बहुत ही वांछनीय है कि यह "अपहिल नहीं" था। हालांकि, शायद "कम समय" के साथ मैं जल्दी में था। PHP में एक बड़ी या बहुत बड़ी परियोजना, इसकी स्थिरता सुनिश्चित करने के लिए विशेष उपाय किए बिना जल्दी या बाद में विफल हो जाएगी। हार्डवेयर या प्रोग्रामर क्षमताओं के लिए पर्याप्त नहीं है। फिर अपने लिए तय करें कि यह कैसा दिखता है, लेकिन मुझे यह सादृश्य पसंद है:

• एक DB सड़क की तरह है। चापलूसी बेहतर है।
• वेब सर्वर - हवा प्रतिरोध के रूप में। वह हिट से जितना कम हिट करे, उतना अच्छा है।
• विभिन्न प्रकार के कैश - यह "टोपी" और इसके साथ आने वाली तकनीक है - इसके बिना, बेशक, यह संभव है, लेकिन यह इसके साथ बेहतर है।

सिद्धांत रूप में, यहां लेखक को पूर्वाग्रह से उकसाया जा सकता है - आखिरकार, किसी भी भाषा में लिखी गई साइट के लिए एक वेब सर्वर की आवश्यकता होती है! एटा, ओनू, कनेश्नो, उह ... हां ... - लेखक हिचकिचाता है। लेकिन। आखिरकार, लेखक ने न केवल PHP को किक करने का वादा किया। आइए दूसरी तरफ से प्रक्रिया को देखें। अंतिम उपयोगकर्ता (उदाहरण के लिए, साइट आगंतुक) और उसके ब्राउज़र की ओर से। और HTTP के जीवन के कुछ बिंदुओं पर भी। आप ग्राहक साइट से अधिक देख सकते हैं, लेकिन हम इसके बारे में बात नहीं करेंगे। क्योंकि ग्राहक, अगर वह चुनता है, केवल वही है जो वह है। इस बीच, मान लें कि साइट का डेवलपर भी उसका मालिक है। ऐसा भी होता है।

एक सामान्य अर्थ में, अंतिम उपयोगकर्ता का मुख्य कार्य आवश्यक (और कभी-कभी आवश्यक) जानकारी प्राप्त करना है। विशेष रूप से, "लिंक पर क्लिक करें" (एक पंक्ति में पता / कॉपी / पेस्ट करें) और देखें कि आपको क्या चाहिए। और उसके लिए, अधिकांश मामलों में, मुझे परवाह नहीं है कि किस तरह का हार्डवेयर है, किस तरह का सॉफ्टवेयर है। वह सर्वर और उसके सभी प्रतिक्रियाओं और राज्यों के साथ-साथ HTTP के मार्ग की भी परवाह नहीं करता है। उसे कोई अंदाजा नहीं है कि वहां क्या है, क्यों और क्यों है। जिससे यह स्पष्ट रूप से अनुसरण करता है कि उसे मांसपेशियों, कश या नग्नेक्स की भी आवश्यकता नहीं है (मुझे पता है कि यह इस तरह से स्पष्ट नहीं है)। उसे infa की जरूरत है। और बात। और केवल एक चीज जिसे उपयोगकर्ता देखता है वह है चित्र / पाठ / वीडियो / ध्वनि। कोई अन्य व्यक्ति डिजाइन / सुविधा पर ध्यान देता है, लेकिन सभी नहीं। कोई और साइट की लोडिंग / प्रतिक्रिया की गति को देख रहा है, लेकिन, फिर से, सभी नहीं।

और साइट डेवलपर क्या देख रहा है? पूरे अर्थों में - हर चीज के लिए। लेकिन इसके लिए आपको सिस्टम प्रशासन के बारे में, और प्रोग्रामबिलिटी के बारे में, और वेब डिज़ाइन ("प्रयोज्य" के बारे में एक विचार रखने की आवश्यकता है) मैं सादगी के लिए डिज़ाइन में शामिल करने का प्रस्ताव रखता हूँ, हालाँकि अक्सर ऐसा नहीं होता है)। उनमें से बहुत सारे नहीं हैं, हमारे पास फैशन में श्रम का विभाजन है। नतीजतन, कभी-कभी सरकार की ये तीन शाखाएं एक-दूसरे से इतनी स्वतंत्र होती हैं कि आप बस चकित रह जाते हैं कि यह किसी तरह से कैसे काम करती है। आइए उस अनुरोध के पृष्ठ से वर्तमान में मौजूद रूप में भौगोलिक / लौकिक पथ को सूचीबद्ध करें। मुझे यकीन है कि जो लोग इस विषय में हैं, उनमें से ज्यादातर मुझसे बेहतर जानते हैं, और अगर वे झूठ बोलते हैं, तो वे इसे ठीक कर देंगे। लेकिन, मैं एक सामान्य अर्थ में, इसे अपनी आंखों के सामने अपनी महिमा के रूप में प्रकट करता हूं, इसलिए बोलने के लिए। तो:

• उपयोगकर्ता एक लिंक पर क्लिक करता है
• ब्राउज़र को सर्वर का पता चलता है (या इसे कैश से लेता है, यदि पहली बार नहीं। लेकिन पहली बार यह अभी भी करना होगा)।
• ब्राउज़र वेब सर्वर के लिए एक GET | POST (कम सामान्यतः अन्य HTTP) अनुरोध बनाता है और इसे लागू करता है।
• वेब सर्वर:
  • या तो अनुरोध का विश्लेषण करता है (उदाहरण के लिए, "स्टेटिक्स / डायनामिक्स" के विषय के लिए) और, अगर स्टेटिक्स, एक फ़ाइल का निर्माण करता है
  • या तो बस स्क्रिप्ट बुलाता है
• स्क्रिप्ट समझती है कि स्टैटिक्स या डायनेमिक्स। आप आम तौर पर मक्खी पर एक फ़ाइल उत्पन्न कर सकते हैं। और वह उत्तर का पाठ एकत्र करना शुरू कर देता है। PHP के संबंध में मानक मामलों में, यह प्रक्रिया कुछ इस तरह से आगे बढ़ती है:
  • स्क्रिप्ट डिस्क से पढ़ी जाती है (या फ़ाइल सिस्टम कैश से ली गई है), पार्स, निष्पादित
  • स्क्रिप्ट की सामग्री के आधार पर, कॉन्फ़िगर, टेम्प्लेट, आमतौर पर पढ़ना शुरू किया जाता है (कैश से लिया जाता है), यह सब पार्स, संकलित (अच्छी तरह से, या पीएचपी कैश से लिया गया) और निष्पादित होने लगता है; डेटा के लिए डेटाबेस के लिए प्रश्न किए जाते हैं, और कभी-कभी टेम्पलेट्स के लिए (यदि संभव हो तो, यह भी यहां कैश किया गया है)
  • पढ़ी और निष्पादित की गई सभी चीजों के आधार पर, एक तैयार प्रतिक्रिया पाठ बनता है
• स्क्रिप्ट वेब सर्वर की प्रतिक्रिया का सादा पाठ देती है
• वेब सर्वर (सामान्य रूप से) स्क्रिप्ट के हेडर और प्रतिक्रिया को ब्राउज़र में भेजता है
• ब्राउज़र सर्वर की प्रतिक्रिया को पार्स करता है और यह तय करता है कि इसके साथ क्या करना है:
  • अगर HTML कॉमरेड - पर्स और प्रदर्शित / निष्पादित करता है
  • अगर मीडिया shnyaga, फिर से, प्रदर्शित करता है / खो देता है, स्वयं या प्लगइन्स का उपयोग करके
• लाभ! (यदि 404 या कुछ अन्य गंदे चाल नहीं है, लेकिन इसके बारे में बात नहीं करते हैं, हमारे साथ सब कुछ ठीक है)

एक बहुत ही मानक प्रक्रिया, जैसा कि आप देख सकते हैं। कुछ भी असामान्य नहीं, कुछ भी घातक नहीं, सब कुछ मानक ढांचे के भीतर है। मैं स्वयं स्नान नहीं करूंगा, लेकिन मुझे लगातार यह एहसास होता है कि "यहाँ कुछ गलत है।" आइए इसे जानने की कोशिश करें। यहां तक ​​कि एक सरसरी निरीक्षण में एक सामान्य रूप से प्रयुक्त अभिव्यक्ति का पता चलता है: "कैश से लिया गया।" और अगर आप PHP में साइट के प्रदर्शन को बेहतर बनाने के लिए समर्पित मंचों के माध्यम से चलाने की कोशिश करते हैं - तो आप इस कैश में इतने फंस गए हैं कि आप हर जगह कैश के लिए कुछ और देख रहे होंगे। और आपके प्रश्न "कैश के लिए क्यों" आपको बहुत लोकप्रिय रूप से समझाया जाएगा कि यह कितना उपयोगी है। मैं अपना पसंदीदा फॉर्मूला दूंगा:
- और कैश के बिना कैसे?
- किसी भी साइट की अड़चन डेटाबेस है! कैश सब कुछ आप कर सकते हैं!
- ममाशड स्टीवर्स!
और केवल सबसे दयालु, एक गहरी आह के साथ, आप सौवें या हजारवीं बार के लिए एक संक्षिप्त व्याख्यान देंगे कि PHP एक दुभाषिया है, कि यह हर बार संकलित करता है, लेकिन यह कैश किया जा सकता है कि डेटाबेस के साथ काम करना कितना धीमा है और अंत में, स्थैतिक के लिए nginx डाल दें- प्रॉक्सी, और अपाचे स्क्रिप्ट को मोड़ने दें। इसके अलावा कुकीज़, सत्र और स्थानीय भंडारण का उपयोग करें, क्योंकि HTTP ...

मैं आपको पहली नज़र में असंगत छोटी सूची पर एक और दे दूँगा। आसानी से और बस एक वेबसाइट बनाने के लिए आवश्यक तकनीकों की एक छोटी सूची (यहाँ मैं अभी भी PHP के पीछे पड़ा हूँ, क्योंकि यहाँ खरगोश छेद पहले से ही शुरू है):
सर्वर साइड:

• वेब सर्वर, या यहां तक ​​कि कई
• स्क्रिप्टिंग (आमतौर पर, लेकिन आवश्यक नहीं) भाषा
• डेटाबेस सर्वर

ग्राहक पक्ष:

• एचटीएमएल
• सीएसएस
• जे एस
• अक्सर (फ्लैश) के रूप में और न केवल

यह सब किसी भी तरह ईथरनेट पर आईपी पर टीसीपी पर HTTP से बंधा हुआ है (हालांकि, एक सर्वर के अंदर इंटरप्रोसेस संचार सॉकेट का उपयोग किया जा सकता है)। एक साइट के लिए सात (!!!) तकनीकें! नहीं, ठीक है, यह वास्तव में सामान्य है? ऐसा भी नहीं है। एकल अनुरोध-प्रतिक्रिया चक्र के लिए, उन्हें अभी भी जरूरत है और अभी भी काम कर रहे हैं। यहां तक ​​कि अगर यह "मैं और मेरा कुत्ता" जैसे पृष्ठ का अनुरोध है, जो हर छह महीने में बदल जाएगा - सात अलग-अलग प्रौद्योगिकियां जो लगातार खुद को पार्स और कैश करती हैं, क्या यह सामान्य है? बेशक! - पेशेवरों जवाब देंगे। और वे राजनेताओं और साझा मेजबानी की बारीकियों आदि के साथ अपने जवाब को सही ठहराएंगे। आदि और वैसे, वे सही होंगे। आज तक लागू है। क्योंकि वर्तमान दिन के लिए, ऐसी योजना सबसे अधिक लचीली और कठिन साबित हुई है। इसके अलावा, टिप्पणियों में वे एक जोड़े को और अधिक या अधिक फेंक देंगे। किसी भी कारण से मैं कुछ भूल गया या बदतर हो गया, मुझे नहीं पता था।
लेकिन यह मुझे व्यक्तिगत रूप से सामान्य नहीं लगता। और अब मैं अपनी स्थिति समझाने की कोशिश करूंगा।

अंक संख्या एक। लगभग छह साल पहले, लेखक PHP / MySQL पर निर्मित साइटों को ट्रैक करने और जोड़ने के रूप में वेब प्रौद्योगिकियों से परिचित हुआ। सबसे पहले, निश्चित रूप से, यह बहुत ही बाहरी और नया था, लेकिन बहुत जल्दी यह अहसास हुआ कि HTML और JS के एक समूह में मिश्रित, या तो प्रतिध्वनि के माध्यम से प्रदर्शित होता है, फिर प्रिंट के माध्यम से, या बस के बाहर <? Php?> - यह नहीं है मजे करो। इसके समानांतर, यह अचानक पता चला कि ब्राउज़र-आधारित ऑनलाइन गेम लिखना न केवल शांत और लाभदायक है, बल्कि आसान भी है! क्या वह परिचित है? :) नतीजतन, एक ब्राउज़र-आधारित ऑनलाइन गेम लॉन्च किया गया था, माना जाता है कि एक ओपन-सोर्स इंजन पर लिखा गया है (बेशक, लेखक द्वारा नहीं, बल्कि किसी अज्ञात तीसरे पक्ष द्वारा), PHP के अंदर देखने के बाद, जिसमें बाल चल रहे थे, और लगभग 180 की मात्रा में डेटाबेस के साथ काम करने का अभ्यास। हर क्लिक के लिए ये अनुरोध बस भयानक थे। और अनुरोधों के थोक ने कार्यान्वित किया कि HTTP पर PHP क्या समान परियोजनाओं के संबंध में कमी है - खिलाड़ी की वर्तमान स्थिति और खेल प्रक्रिया। यहां यह अधिक उपयुक्त रूप से प्रौद्योगिकियों के बेकार विकल्प के लिए लेखक को किक करने के लिए उपयुक्त होगा, और ठीक ही ऐसा है। बेशक, कोड ने पत्राचार किया, खेल के यांत्रिकी में बहुत सारी चीजें बदल गईं, लेकिन फिर हम इंजन की मुख्य खामी को दूर नहीं कर सके - इसे खरोंच से पूरी तरह से फिर से लिखना आवश्यक था। जिसकी कल्पना और शुरुआत की गई थी। और उस समय हमारी सबसे बड़ी इच्छा किसी तरह के "दानव" को व्यवस्थित करने की थी जो इंजन के मैकेनिक्स को एकजुट करने और सरल बनाने के लिए डेटाबेस और इसकी सामग्री का प्रबंधन करेगा। लगभग उसी समय, संग्रहीत प्रक्रियाएं और एक अनुसूचक पेशी में दिखाई दिया, और यह हमें लग रहा था कि यह अंततः हमारी सभी समस्याओं को हल करेगा। पहले, हमारे पास तब सी या पायथन लेने की हिम्मत नहीं थी, फिर समय, और कुछ समय बाद यह स्पष्ट हो गया कि नियोजित सृजन अपनी विशिष्टता के कारण वांछित आय नहीं लाएगा, और सभी सर्वोत्तम विचारों को "बाद में" होने के लिए स्थगित कर दिया गया था। जो, अभी तक, अभी तक नहीं आया है। उपरोक्त का मुख्य बिंदु: यह वर्तमान स्थिति के साथ काम करने के लिए अंतर्निहित तंत्र की कमी है और अपने दम पर उनके बैसाखी कार्यान्वयन ने उस इंजन के अपरिहार्य पतन को तेज किया है।

पाचन संख्या दो। लेखक कुछ हद तक एक आदर्शवादी, पूर्णतावादी और स्वप्नदृष्टा है। लेखक सुबह में तुर्क में ताजा पीसा कॉफी पीना और थोड़ा सपना देखना पसंद करता है। जिसमें कि कॉफी किसी तरह खुद पी जाती है। लेकिन, चूंकि सपनों के इस विशेष उदाहरण में बिल्कुल कोई लागू चरित्र नहीं है, इसलिए लेखक इस विषय पर कुछ अगली बकवास पर कल्पना करना पसंद करते हैं, प्रलाप के क्रम में। शायद हमारे दिमाग को फैलाने के लिए या केवल कचरे से पीड़ित होने के लिए - मुझे यकीन नहीं है। तो, उस दिन सुबह मैं लेट गया और इस तरह तर्क किया:
ठीक है, मान लें कि आप शाम को तुर्क में पानी डाल सकते हैं और कॉफी डाल सकते हैं। पीज़ोइलेक्ट्रिक इग्निशन के साथ एक गैस स्टोव - वे रिले के साथ टाइमर पर क्लिक कर सकते हैं, यह मुश्किल नहीं है। गैस को खोलने और बंद करने के लिए बर्नर नल की घुंडी को मोड़ने के लिए यह एक सरल तरीका है। हम इस परिचित प्रक्रिया के इतने आदी हैं कि हम इस प्रक्रिया का विवरण देखना पूरी तरह से बंद कर चुके हैं, और उन चरणों के माध्यम से छलांग लगाने के बारे में सोचना शुरू कर दिया है जो बहुत पहले काम कर चुके थे। कॉफी बनाने के लिए क्या आवश्यक है? तुर्क, पानी, कॉफी, खुली गैस, गैस में आग लगा दो ... बंद करो! और सामान्य रूप से गैस के बारे में क्या? ताकि पानी गर्म हो सके। तो - क्या हमें जांचना या जाना है? क्या हमें खुली गैस की जरूरत है या हमें अभी भी गर्म पानी की जरूरत है?

यहां, वास्तव में, इस योजना के अनुसार, हम सभी आमतौर पर इसका कारण बनते हैं। हम जीवन की समस्याओं को सफलतापूर्वक हल करने के लिए एक मॉडल के रूप में अच्छी तरह से स्थापित, अच्छी तरह से स्थापित, अच्छी या सिर्फ सुविधाजनक प्रथाओं और एल्गोरिदम को बनाए रखते हैं, और ऐसे ही मामलों में हम इन सिद्ध प्रौद्योगिकियों को ठीक से लागू करने की कोशिश कर रहे हैं। यह हमारी सोच की नींव का एक मुख्य आधार है, और यह अच्छा है, और अक्सर यह दृष्टिकोण कार्य का उचित समाधान होगा। लेकिन हमेशा नहीं। यहाँ एक सार उदाहरण है, जो अधिक विशिष्ट रूपांतरों में मेरे अपने कार्यों सहित, सामान्य जीवन में सैकड़ों बार निरीक्षण करने का सौभाग्य था। मान लीजिए हमें एक दोस्त को पानी पीने की ज़रूरत है। हम अपने दिमाग में जल्दी से स्थितियों का पता लगाते हैं: मात्रा, सीमा, ले जाने में आसानी, और हम खुद को काफी सामान्य समाधान पाते हैं। हम एक मग लेते हैं, पानी डालते हैं, इसे एक दोस्त को ले जाते हैं। दोस्त खुश है - तो हम हैं। समस्या हल हो गई है, हर कोई खुश है। नमूना समाधान बनाया। कुछ घंटों के बाद, एक दोस्त दोहराने के लिए कहता है - हम एक ही मग को लेने और प्रक्रिया को दोहराने में संकोच नहीं करते हैं। सब ठीक है। नमूना समेकन के पहले चरण से गुजरा - सत्य की पुष्टि। एक हफ्ते बाद, एक मित्र फिर से प्रकाश को देखता है, और - उसी परिदृश्य के अनुसार। नमूना औद्योगिक उपयोग के लिए तैयार है। और जब एक महीने के बाद कुछ दोस्त पानी मांगेंगे - हम साहसपूर्वक दो मग लेंगे और बस कोई समस्या नहीं है! कार्रवाई में औद्योगिक आवेदन, स्केलिंग लागू, परीक्षण और परीक्षण। अब से, हमारे दिमाग में "पीने ​​का पानी" को "सर्कल से" के साथ जुड़ा हुआ कंक्रीट प्रबलित किया जाएगा। जाल तैयार है। क्योंकि एक बार, लगभग पंद्रह की एक शोर कंपनी जुलाई में सड़क पर और +30 सेल्सियस पर हमारे चूल्हा में गिर गई। संक्षेप में, हेब्राफ़ेक्ट। मंडलियों के साथ सात से दस उड़ानें, साथ ही उनमें से कई को तोड़ने की क्षमता। कुछ खाली मग लेने के बजाय, बस उन्हें अपने हैंडल से एक हाथ की उंगलियों पर रखें (अब आपको उन्हें विशेष रूप से क्षैतिज रूप से ले जाने की आवश्यकता नहीं है, वे खाली हैं) और दूसरे हाथ में एक बोतल / कैफ़े / जग का पानी। कुछ इस तरह, वास्तव में, विचारों को जन्म देता है जो वास्तव में मूल हैं - बस कुछ विचारों को वापस ले जाएं और स्थिति को पक्ष से देखें। अन्यथा, हम एक बार में 15 मग पानी को आराम करने के अपने कार्य को किसी भी तरह से सरल करना शुरू करते हैं। उदाहरण के लिए, आप उन सभी को एक ट्रे पर रख सकते हैं। और आप इसे चिपकने वाली टेप के साथ रिवाइंड कर सकते हैं ... और फिर भगवान ने इस समस्या को सफलतापूर्वक हल करने के लिए मना किया। क्योंकि कुछ समय के बाद कुँए से दस लीटर लाने का काम होगा, और निकटवर्ती पड़ोसी बहुत देर तक हँसता रहेगा, हमारा अवलोकन करेगा, कुएँ से पानी इकट्ठा करेगा, मग से पानी निकालेगा, और ध्यान से रचना और इन टुकड़ों को बनाएगा जो इन मगों को तैयार करता है। गोल बैग विशेष रूप से क्षैतिज_समूह मंडलियों के लिए तेज किए गए। और, कुएं के बगल में खड़े बाल्टी के किनारे पर उसके दुर्भावनापूर्ण नोड के जवाब में, हम उसे किसी भारी चीज के साथ बहुत मुश्किल से मारना चाहेंगे, उदाहरण के लिए, यह बहुत ही बाल्टी। क्योंकि यह महसूस करना बहुत अप्रिय और दर्दनाक है कि वह हमें बेवकूफ कहने में सही है ...

एक समय मैं AS3 के शानदार जुलूस को लेकर बहुत उत्साहित था, लेकिन मिस्टर आय ने सब कुछ बर्बाद कर दिया । बेशक, चलो इसके निषेध और बोझिलता के लिए तीन साल पहले की प्राचीन तकनीक को शाप देते हैं, हम लोहे और सॉफ्टवेयर के एक दर्जन अंतिम निर्माताओं में से कुछ के साथ तकनीकी मुद्दों पर सहमत और समझौता करके इसे अनुकूलित करने का प्रयास नहीं करेंगे, और इसके बजाय हम अप्रभावी रंग के समर्थन के साथ फ्लैट पाठ पर आधारित नए दस साल के विकास को ले लेंगे। एक सुपर-फास्ट व्याख्या की गई भाषा जो पहले से ही लगभग समस्याओं के बिना हमारे पहले से ही शानदार पन्नों में अन्तरक्रियाशीलता का स्पर्श जोड़ती है, यदि, निश्चित रूप से, आप उपयोग करते हैं इस उत्कृष्ट ढांचे के साथ और जिस तरह से आप अपने सभी डायनामिक रूप से बदलती प्राइमेटिव्स को बायपास करेंगे, और बहुत जल्द हम इस सब से बाहर कैंडी बना देंगे, बस कुछ साल बाकी हैं! .. मैं वास्तव में बहुत सारी चीजों के लिए अंकल स्टीव का बहुत सम्मान करता हूं, लेकिन इस मामले में विशेष रूप से उनके साथ हूं मैं सहमत नहीं हूं। हालाँकि, मैं इस बात को बाहर नहीं करता कि वह वास्तव में सर्वश्रेष्ठ चाहता था। लेकिन adobes या तो गलत समझा, या बस बहकाया, और, परिणामस्वरूप, वास्तव में वेब profiled ...

पाचन संख्या तीन। एक अंतर्निहित ब्राउज़र और कीबोर्ड / माउस समर्थन के साथ एक अपेक्षाकृत नया स्मार्ट टीवी मेरी दीवार पर लटका हुआ है। लेकिन 90% मामलों में वीडियो होस्टिंग सेवा तक पहुंचने का प्रयास विफल रहता है। शुरुआत के लिए, यह पता लगाना मुश्किल है कि क्या यह सील है, क्योंकि कीबोर्ड पर तीर माउस कर्सर (!!!) को नियंत्रित करता है। लेकिन, भले ही आप साइट पर सफलतापूर्वक प्रवेश कर सकें - यह एक तथ्य नहीं है कि आपको फिल्म देखने को मिले। पागल स्क्रॉलिंग के कारण या तो कर्सर मूवी में आने में विफल हो जाता है, या ब्राउज़र जेएस स्क्रिप्ट के वजन के नीचे मर जाता है, जिसे साइट के मालिक द्वारा सावधानीपूर्वक सोचा जाता है, और आपको फिर से शुरू करना होगा। Vaunted स्मार्ट एप्लिकेशन विकसित करने वाले लोग, ऐसा लगता है, उन्होंने कभी कीबोर्ड नहीं देखा है, क्योंकि ऑन-स्क्रीन कीबोर्ड का प्रतीकात्मक लेआउट किसी कारण से, ज्यादातर मामलों में, वर्णानुक्रम में है। वहाँ भी कभी-कभी इनपुट भाषा को स्विच करने के लिए एक बटन होता है, लेकिन आमतौर पर इसके लिए उपयोग में लाया जाने वाला कीबोर्ड शॉर्टकट कुंजी नहीं है। क्या भाषा है - इन एप्लिकेशन में कीबोर्ड हमेशा काम नहीं करता है। और, वास्तव में, यह तथ्य कि एक ही फ्लैश का उपयोग किया जाता है, इसका कोई मतलब नहीं है। सिर्फ इसलिए कि कहीं यह काम करता है जैसा कि यह होना चाहिए, लेकिन कहीं यह नहीं है। और प्रगति क्या है?

जब मैंने वही AS3 - I को फिर से चालू किया, तो वे उस पर लिखे गए शब्दों से भयभीत थे। शैक्षिक पुस्तकों से उदाहरणों के आधार पर सबसे प्रसिद्ध आकस्मिक खिलौने बनाए जाते हैं, और ग्राफिक्स "शानदार" साल पहले (!!!) की तुलना में बहुत खराब हैं, मैं एनीमेशन के बारे में चुप हूं। लेकिन यह, सौभाग्य से, एक भाषा समस्या नहीं है, लेकिन कुटिल हाथ। क्योंकि विभिन्न इंजनों के अपेक्षाकृत व्यापक वितरण के समय तक, कुछ स्थानों में गुणवत्ता में सुधार हुआ है। उस समय, हमारे हमवतन सहित काफी संख्या में प्रतिभाशाली लोगों ने AS3 पर स्मार्ट चीजें कीं, जिसमें लगभग पूर्ण 3 डी और भौतिकी को लागू किया गया था, क्योंकि फ्लैश प्लेयर के दसवें संस्करण से पहले कोई तीसरा आयाम नहीं था। 10 वें संस्करण में, उन्होंने जेड समन्वय को खराब कर दिया, हालांकि सब कुछ बादल रहित नहीं था, लेकिन यह महत्वपूर्ण नहीं है। महत्वपूर्ण बात यह है कि एडोब ने महसूस किया कि एक बहुत स्पष्ट और पहले से ही लगभग घातक दोष था, और इसे खत्म करने के लिए उपाय किए। वैसे, यहां आकार में 4825 बाइट्स का एक सरल दो-वर्षीय संस्करण है। स्रोत कोड में कोड की लगभग 250 लाइनें हैं; केवल अंतर्निहित कक्षाओं का उपयोग किया जाता है, कोई तृतीय-पक्ष इंजन नहीं। कक्षाएँ अण्डाकार होती हैं, ग्रहों की स्थिति की गणना औसत विसंगति (त्वरित गति, केप्लर के अनुसार) के अनुसार की जाती है। निष्पादन की गति या आकार के संदर्भ में कोई अनुकूलन नहीं किए गए थे। तो मुझे क्लाइंट कोड और निष्पादन की गति में समान नंगे JS पर समान आकार दें, यहां तक ​​कि कैनवास के साथ भी, कम से कम। या सीएसएस, जी-जी। शायद तब मैं HTML5 और सहयोगियों की विजय को स्वीकार करता हूं ...

अब आइए HTML के अलावा प्लेटफार्मों के लिए PHP के अलावा अन्य भाषाओं में प्रोग्रामर और प्रोग्रामिंग के विकास पर एक त्वरित नज़र डालें (हम बाद में इन पर चर्चा करेंगे)। आमतौर पर, एक प्रोग्रामर का विकास पथ कई प्रमुख चरणों से गुजरता है:

चरण 00. हम "हैलो वर्ल्ड" लिखते हैं। हुर्रे! मैं एक प्रोग्रामर हूँ!
चरण 10. हम कूल विंडो एप्लिकेशन लिखते हैं।
चरण 20. कुछ बहुत कुछ चर की तरह, फ़ंक्शन और चर का एक गुच्छा कॉपी-पेस्ट द्वारा झुका हुआ है। दस स्थानों में सुधार पहले से ही थका हुआ है, आपको इसके बारे में कुछ करने की आवश्यकता है।
चरण 30. हाँ! आपको कक्षाओं का उपयोग करना होगा!
चरण 40. कुछ कक्षाएं मेरे लिए अधिक से अधिक कॉपी की जाती हैं, और मुझे एक अंजीर को दस स्थानों पर संपादित करना होगा।
चरण 50. हाँ! डिजाइन पैटर्न मेरी सभी समस्याओं को हल करेगा!
चरण 99. अरे, मैं एक बेवकूफ था ... खैर, यह अभी भी सरल है ...
चरण 100. ज़ेन।

चरणों की संख्या और विधियों के नाम लगभग मनमाने ढंग से चुने गए हैं। वे अपने आप में महत्वपूर्ण नहीं हैं, लेकिन यह तथ्य कि प्रोग्रामर सोच के प्रतिमानों को बदलता है। कम से कम मेरे साथ ऐसा ही था, और जिन लोगों के साथ मैं परिचित हूं और जिनके कोड को मैंने देखा। सच है, मेरे आलोचनात्मक दृष्टिकोण में, उनमें से कोई भी 99 वें चरण तक नहीं पहुंचा है, साथ ही साथ खुद भी। हां, और न जाने कितने प्रोग्रामर मुझे पता हैं। लेकिन जब आप कुछ चौखटे / पुस्तकालयों / कार्यक्रमों के लेखकों के कोड को देखते हैं, तो आपको इससे नरक मिलता है और आपको लगता है कि लोग लंबे समय से कुछ पाँच सौ कदम चले गए हैं ...

मेरे पास एक अवलोकन है जो मुझे परेशान करता है। विभिन्न पाठ्यपुस्तकों में, कंप्यूटर प्रौद्योगिकी की हार्डवेयर क्षमताओं पर कार्यक्रमों को डिजाइन करने की प्रक्रिया में पीछे मुड़कर नहीं देखने की सिफारिश की जाती है, साथ ही यह सोचने के लिए भी कॉल नहीं किया जाता है कि यह इस तरह से क्यों काम करता है, लेकिन बस इसका उपयोग करें। यह एक गुणवत्ता प्रोग्रामर को प्रशिक्षित करने के लिए मुझे मौलिक रूप से गलत लगता है। और मैं इसके लिए कई पुष्टियों से मिला हूं - वास्तव में अच्छे प्रोग्रामर का एक अच्छा विचार है कि "सामान्य रूप से यह सब कैसे होता है", कभी-कभी कोडांतरक और टीसीपी स्तर तक काम करता है। लेकिन क्या उल्लेखनीय है: मंकीपैचर को बढ़ाने के लिए इस तरह की सिफारिश वास्तव में मूल्यवान है। यह समझ में आता है। पशु प्रशिक्षण आमतौर पर एक समान तरीके से किया जाता है: इससे कोई फर्क नहीं पड़ता कि क्यों और क्यों, यह सिर्फ इतना करना महत्वपूर्ण है और यह स्वादिष्ट होगा। और इस अप्रिय नोट पर, हम PHP / HTML के प्रतिष्ठित जोड़े की ओर बढ़ते हैं।

मैं व्यक्तिगत रूप से PHP को दो व्यापक श्रेणियों में विभाजित करने की प्रवृत्ति रखता हूं: वे जो अन्य प्रोग्रामिंग भाषाओं को जानते हैं (उनके लिए, एक नियम के रूप में, PHP पहली भाषा नहीं थी, हालांकि यह दूसरे तरीके से भी होता है), और जो लोग PHP के अलावा कुछ भी नहीं जानते हैं। पहली श्रेणी अक्सर पिछले परिदृश्य के अनुसार विकसित होती है, और मेरे पास उनके लिए कोई सवाल नहीं है - वे आमतौर पर PHP में अच्छा कोड लिखते हैं और इसे सही और यथोचित रूप से उपयोग करते हैं। लेकिन यहां दूसरी श्रेणी है - वहां सब कुछ अलग है। बस इतना ही। क्योंकि, पहले परिदृश्य के अनुसार विकसित होते समय, लोग अक्सर शुरू में सीधे केवल एक या दो तकनीकों का उपयोग करते हैं जो किसी विशिष्ट भाषा से नहीं बंधे होते हैं (उदाहरण के लिए, कंसोल या WinAPI / X11), और कारण-प्रभाव संबंध नहीं तोड़े जाते हैं: यहाँ वे हैं, कमांड लाइन तर्क और यहाँ वे कोड में हैं, हम इसका उपयोग करते हैं। दूसरी श्रेणी के बारे में क्या नहीं कहा जा सकता है।

क्योंकि PHP से पहले प्रोग्राम करने वाले लोग खुद को तैयार, बड़े, पहले से ही काम करने वाले और बहुत समझ से बाहर सिस्टम के साथ आमने-सामने पाते हैं। एक ओर, यहाँ 'हैलो वर्ल्ड' की गूंज है - ब्राउज़र - F5 - यहाँ यह है, लेकिन दूसरी तरफ यह स्पष्ट नहीं है कि यह वहाँ कैसे मिला और इसने स्वयं को अपडेट क्यों नहीं किया। नहीं, "वेब सर्वर की जड़ में एक फ़ाइल डाल" जैसी बुनियादी अवधारणाएं, निश्चित रूप से, महारत हासिल हैं, लेकिन प्रश्न "वेब सर्वर कहां से आता है?" और "यह कैसा दिखता है?" अक्सर भविष्य में इस अंतर को भरने की आशा के साथ अनुत्तरित हो जाते हैं? । समय के साथ, इस तरह के अस्पष्ट स्थानों की संख्या केवल बढ़ती है, सभी प्रकार के सीईईएस / जेईएस / हैटयूट / ओओपीई / टेम्प्लेट / फोंट / जिप्गी वहां जोड़े जाते हैं, जिनमें से अंदरूनी बहुत स्पष्ट नहीं हैं, लेकिन (और यह बहुत महत्वपूर्ण है) - यह पता चलता है कि आप निश्चित रूप से इसका उपयोग कर सकते हैं। क्या, क्यों और कैसे के बारे में सोच रहा था। समय के साथ, "मत सोचो" प्रतिमान कभी-कभी प्रचलित साबित होता है, और फिर यह पूरी तरह से दुख की बात है। कहीं एक बार, कुछ मनोवैज्ञानिकों ने पाया कि एक व्यक्ति द्वारा एक नए पाठ की धारणा उस स्थान पर बंद हो जाती है जहां वह एक समझ से बाहर शब्द से मिला था। इस मामले में, इस शब्द पर वापस जाना सबसे सही होगा, इसके अर्थ को स्पष्ट करेगा, और जारी रखेगा। वेब प्रौद्योगिकियों के मामले में (और सबसे अधिक बार वे PHP के साथ शुरू होने वाले वेब पर) - बहुत सारे अस्पष्ट शब्द हैं। अविश्वसनीय रूप से बहुत, कुछ के लिए - लगभग सब कुछ। लेकिन: यदि आप टीसीपी-प्रकार द्वारा वेब सर्वर के माध्यम से ब्राउज़र से अनुरोध करने से पूरी श्रृंखला की व्याख्या करना शुरू करते हैं, तो हम बहुत जल्द वास्तविक प्रोग्रामिंग तक नहीं पहुंचेंगे। और इसलिए यहां से झूठ शुरू होता है। या तो शिक्षक (व्यापक अर्थों में, यह वरिष्ठ कॉमरेड, मित्र और फ़ोरम उपयोगकर्ता और वीडियो पाठ से व्याख्याता हो सकते हैं) प्रशिक्षुओं से झूठ बोलते हैं कि सब कुछ बाद में स्पष्ट हो जाएगा, या छात्र स्वयं और शिक्षकों से झूठ बोलना शुरू कर देते हैं (क्योंकि यह गलतफहमी को स्वीकार करने के लिए शर्म की बात है। ): "हाँ लान, तब मैं सब कुछ समझ गया।" "हाँ, आप नहीं समझे," शिक्षक अपना हाथ हिलाते हैं और प्रशिक्षण के अगले भाग को देते हैं। समय के साथ, प्रशिक्षु "एक छोटी सी गलतफहमी की स्थिति के आदी हो जाते हैं, लेकिन इतने पर आते हैं," कि अवधारणाओं, विधियों, स्वरूपों और उन सभी का एक पूरा डंप मन में जमा होता है।

आउटपुट में, हम एक "विशेषज्ञ" प्राप्त कर सकते हैं जो कई वर्षों से PHP में प्रोग्रामिंग कर रहा है, लेकिन अभी भी स्पष्ट रूप से यह नहीं बता सकता है कि किसी सर्वर पर अपलोड की गई फ़ाइल ब्राउज़र में कैसे दिखाई देती है जब इसे किसी अन्य सर्वर से अनुरोध किया जाता है। नहीं, पूरी तरह से, वह निश्चित रूप से घबरा रहा है, लेकिन यदि आप स्पष्टीकरण मांगते हैं, तो आउटपुट "ऐसा कुछ" और "हां, क्या अंतर है" के बीच कुछ होगा।

PHP के लिए एक अतिरिक्त सिरदर्द किसी भी अर्थ में OOP है और सभी प्रकार के अन्य रन बन्स हैं। और PHP प्रोग्रामर का विकास अंततः एक सौ से ऊपर ज़ेन से थोड़ा अलग होगा। क्योंकि, एक तरफ, सभी पीसी जानते हैं कि स्क्रिप्ट काम करेगी, ढह जाएगी और सब कुछ भूल जाएगी, और दूसरी तरफ, वे कोड लिखते हैं जैसे कि यह सॉफ्टवेयर है जो वर्षों और सदियों से लगातार चल रहा है। वर्गों, स्थिर तरीकों, इंटरफेस को लागू करने और यहां तक ​​कि (!!!) संकेतों की संरचना के माध्यम से पूरी तरह से सोच, वे कोड के किलोमीटर का उत्पादन करते हैं।एपोथोसिस "आलसी लोडिंग" के कार्यान्वयन से शुरू होता है - आखिरकार, वे अभी भी समझते हैं कि यह कोड अप्रकाशित हो सकता है, इसलिए इसका उपयोग कुछ भी नहीं करने के लिए क्यों करें? अभी तक पकड़ में नहीं आया? इस कोड को कभी निष्पादित नहीं किया जा सकता है, लेकिन यह लिखा जाता है! और इसे लिखने में समय, प्रयास, अक्सर पैसा लगता है ...

और अगर एक प्रोग्रामर के लिए एक भाषा में एक लंबे निष्पादन समय के साथ, एक बार के शुरुआती वेरिएबल को प्रोग्राम के काम के एक साल बाद भी अच्छे आधे मामलों में इस्तेमाल किया जा सकता है, तो PHP में यह सभी आरंभीकृत, त्वरित और संयोजित है। उपयोगकर्ता के ब्राउज़र से प्रत्येक छींक के जवाब में, अक्सर एक अजाक्स अनुरोध के जवाब में, जिसके बाद सब कुछ तुरंत क्रैश हो जाता है और भूल जाता है। लेखक को कभी-कभी थोड़ा ब्रेक होता है, और उसके लिए इस तथ्य का एहसास एक बार मानस के लिए एक मजबूत झटका बन गया।

बेशक, मैंने फिर से अमेरिका की खोज नहीं की है, लेकिन मैं इस बारे में बात क्यों कर रहा हूं और मैं इसे महत्वपूर्ण क्यों मानता हूं। क्योंकि कई प्रोग्रामर्स के सिर में आम गड़बड़ उन्हें पूरी प्रक्रिया से अमूर्त होने से रोकती है और होने के सार को दर्शाती हैइस सब के लिए यह ढेर है। और इसे ध्यान में रखने के उनके प्रयासों के जवाब में, वे इस तथ्य के आदी हैं कि "यह अभी भी इसे बदलना संभव नहीं है," वे कुछ भी समझने से इनकार करते हैं। कभी-कभी, क्योंकि कोई अन्य तरीका नहीं है, लेकिन एक ब्राउज़र - एक वेब सर्वर - पीएचपी - एक डेटाबेस - पीएचपी - एक वेब सर्वर - एक ब्राउज़र बस प्रतिनिधित्व नहीं करता है। खैर, चूंकि किसी भी मामले में आउटपुट अभी भी HTML बन्स के साथ है, तो यह अपरिवर्तनीय और अपरिवर्तनीय सत्य की श्रेणी में जाता है, एक्सिओम्स के अधीन नहीं। और, चूंकि आज PHP बहुमत में है, और यह इसके लिए ठीक है कि एक अलग_वेब सर्वर की आवश्यकता है, अन्य भाषाओं में प्रोग्रामर व्यक्तिगत_वीबी सर्वरों से बंधने लगते हैं, क्योंकि वे अभी भी स्थापित और कॉन्फ़िगर किए गए हैं, और पहिया को क्यों सुदृढ़ करते हैं? और वास्तव में, क्यों? फिर भी, ऐसा लगता है, और इसलिए ठीक काम करता है?

फिर भी पहले से ही इस प्रश्न का उत्तर देने के लिए, हम किसी अन्य विषय पर स्पर्श करेंगे। अर्थात्: एक अलग वेब सर्वर। वह आमतौर पर क्या करता है और यह सब कैसे शुरू हुआ? दूसरे शब्दों में, ऐसा क्यों किया जाता है? तथ्य यह है कि पहला वेब सर्वरबहुत पहले बनाया गया था। रैम तब छोटी थी और यह महंगी थी। फ़ाइलें तब भी छोटी थीं, और डिज़ाइन के लिए ग्राफिक तत्व व्यावहारिक रूप से उपयोग नहीं किए गए थे। कोई PHP, कोई JS, कोई CSS नहीं थी। केवल नंगे HTML था। उस समय ब्राउज़र जानकारी के लिए भूख को संतुष्ट करने का साधन नहीं था, लेकिन एक नया कार्यक्रम, जिसे चलाकर आप कुछ जानकारी प्राप्त कर सकते थे (यदि आपके पास इंटरनेट कनेक्शन था, जो तब बहुत छोटा और धीमा था)। और वेबसाइटें दिखाने का एक तरीका नहीं था (कम से कम ... :)), लेकिन कुछ जानकारी साझा करने का एक तरीका। डिस्क सरणियां भी बड़ी क्षमता में भिन्न नहीं थीं, लेकिन फिर भी, वे रैम की तुलना में सस्ते थे। यह केवल (और वास्तव में माना जाता था) रैम में फ़ाइलों को स्टोर करना असंभव था, भले ही वे अक्सर उपयोग किए गए हों।इसके अलावा, कनेक्शन की गति को इकाइयों और दसियों किलोबाइट्स में मापा गया था। इसलिए, पहले वेब सर्वर, एक उपयोगकर्ता के अनुरोध के जवाब में, सर्वर की हार्ड डिस्क से प्रति सेकंड कई दर्जन बाइट्स से एक फ़ाइल को पढ़ना शुरू किया और इसे नेटवर्क के माध्यम से बिट्स और टुकड़ों में क्लाइंट को स्थानांतरित कर दिया। और एक फ़ाइल को स्थानांतरित करना हमेशा एक सेकंड से कम नहीं लगता था। हां।तब से थोड़ा बीस साल बीत चुके हैं। सब कुछ बदल गया है। उस समय का कोई भी औसत सर्वर संभवतः किसी भी पैरामीटर द्वारा आधुनिक औसत स्मार्टफोन से ईर्ष्या करेगा, यह रैम की क्षमता, सीपीयू आवृत्ति, और रोम क्षमता, शायद, भी हो सकता है। और स्क्रीन रिज़ॉल्यूशन भी।

लेकिन हम अभी भी डिस्क पर फ़ाइलों को संग्रहीत करते हैं, उन्हें वेब सर्वर द्वारा पढ़ते हैं और ब्राउज़रों को बंडल खिलाते हैं। हमने अभी-अभी सभी तरह की सुख-सुविधाओं और सुविधाओं का एक समूह बनाया है, जिसमें एक समृद्ध इंटरनेट एप्लीकेशन है, जिसमें स्क्रिप्टिंग भाषा है। और यह सब बीस साल पहले तकनीक के शीर्ष पर था। उन्होंने स्थैतिक फाइलों के साथ खराब कश को हटाने और वेब सर्वर द्वारा अलग से वितरित करने का फैसला किया। स्मार्ट लोग, सीएसएस खामियों से थक गए, यहां तक ​​कि लेस और एसएएस के साथ भी आए, या शायद कुछ और है। और अब दुविधा यह है कि इसे कब और कहां संकलित किया जाए? या तो सर्वर पर, या क्लाइंट पर। या तो कैश, या प्रत्येक परिवर्तन के बाद recompile और स्टेटिक्स में जोड़ें? लेकिन किसी कारण से कोई यह नहीं देखना चाहता है कि कैश क्या सार है, और वेब सर्वर स्टैटिक्स कैसे वितरित करता है।हालाँकि हर कोई भाषा का उपयोग करता है जैसे "फाइल अभी भी सिस्टम द्वारा कैश की जाएगी और हर बार डिस्क से रीयर नहीं होगी।" खैर, यह अंतिम कदम पहले से ही ले लो! सब के बाद, हर कोई पहले से ही देख सकता है कि फ़ाइलों को कैश किया जा रहा है, वास्तव में, डिस्क पर संग्रहीत नहीं है, लेकिन रैम में! एक अन्य प्रकार के कैश का आविष्कार क्यों करें - बस इन फाइलों को मेमोरी में लोड करें और उन्हें सीधे दें। यदि इसके लिए संकलन की आवश्यकता है, तो अंतिम रूप से संकलन करें और रैम से, फिर से दें। और पहले से ही वास्तव में परिवर्तनशील है - डेटाबेस से लोड करें या जहां आप इसे स्टोर करते हैं ...यदि इसे संकलन की आवश्यकता है, तो अंतिम रूप से संकलन करें और रैम से, फिर से दें। और पहले से ही वास्तव में परिवर्तनशील है - डेटाबेस से लोड करें या जहां आप इसे स्टोर करते हैं ...यदि इसके लिए संकलन की आवश्यकता है, तो अंतिम रूप से संकलन करें और रैम से, फिर से दें। और पहले से ही वास्तव में परिवर्तनशील है - डेटाबेस से लोड करें या जहां आप इसे स्टोर करते हैं ...

इस स्थान पर, किसी को लेखक को ओकाम के रेजर के साथ पक्ष में पेश करना चाहिए, और वस्तु, वे कहते हैं, अगर सब कुछ इस तरह से काम करता है, तो हमें अतिरिक्त संस्थाओं की आवश्यकता क्यों है? और आपको एक कार की आवश्यकता क्यों है, अगर सौ साल से थोड़ा अधिक समय पहले, बहुमत में घोड़े और उनके खुद के दो की कमी थी? किसी व्यक्ति को व्यक्तिगत कंप्यूटर और ब्राउज़रों और tyrnets के साथ एक ग्राफिकल इंटरफ़ेस की आवश्यकता क्यों है? आखिरकार, यह बहुत पहले नहीं था कि इसे बहुत आधिकारिक रूप से अनुमोदित किया गया था ... इसलिए, सज्जनों, अवसरवादियों। डिजाइन के हर स्तर पर पेनेट्रेटिंग, सर्वव्यापी कैश, वास्तव में, यह बहुत ही शानदार इकाई है! सब के बाद, सब कुछ उसके बिना काम करेगा, है ना? और यदि ऐसा है, तो हमें इसकी आवश्यकता क्यों है? हमारे निर्णयों में सुसंगत होना चाहिए। लेकिन नहीं, कोई भी कैश से इंकार करने की जल्दी में नहीं है, एक अतिरिक्त कैश कभी नहीं होता है। और क्यों?क्योंकि कैश, हमें बताया गया है, अनुप्रयोगों को गति दें। लेकिन सज्जनों, मुझे अनुमति दें, क्योंकि यह बकवास है! आप किसी चीज को बिना गति दिए कैसे तेज कर सकते हैं? सीपीयू अभी भी एक ही आवृत्ति पर काम करता है, रैम की आवृत्ति समान है, डिस्क सरणियों के साथ विनिमय दर में वृद्धि नहीं होती है। लेकिन, हालांकि, यह वास्तव में कैश के साथ तेजी से काम करता है। महान पवित्र सत्य यह है कि कैश कभी भी कुछ भी गति नहीं देता है - यह सिर्फ ब्रेक को हटा देता है। यही है, यह आपको उनके माध्यम से दोहराया मार्ग के दौरान धीरे-धीरे काम करने वाले क्षेत्रों को बायपास करने की अनुमति देता है, बस संक्षेप में उनकी स्थिति को याद रखना चाहिए। ठीक है, अगर उन्हें अभी भी खतना करना है, तो वे हैं। लेकिन वे कहां से आए? तो हम खुद उन्हें वहाँ, वास्तव में ढेर ...

तो सवाल यह है - क्यों, किस नाम से हम इस धीरे-धीरे काम करने वाले कोड को तैयार कर रहे हैं? हम इसे जल्दी क्यों नहीं बनाते? एक नियम के रूप में, या तो अज्ञानता या अक्षमता से बाहर। कभी-कभी गलतफहमी से। लेकिन देखते हैं: औसत आधुनिक, बहुत जटिल साइट में सैकड़ों किलोबाइट से लेकर ग्राफिक और अन्य स्टाइलिंग की मेगाबाइट की इकाइयां नहीं हैं। आधुनिक कीमतों पर, रैम कुछ भी नहीं है। दूसरी तरफ - अगर यह कैश में है, तो कोई फर्क नहीं पड़ता कि यह किस स्तर पर है - वैसे भी यह रैम लेगा। इसके अलावा, यह सिस्टम के विभिन्न हिस्सों के विभिन्न स्तरों के कैश में दिखाई दे सकता है और इस रैम को कई बार खा सकता है। और हमेशा एक इष्टतम तरीके से नहीं। तो हमें अतिरिक्त परतों की आवश्यकता क्यों है, हम श्रेक नहीं हैं और धनुष नहीं हैं? बस जब आप सिस्टम शुरू करते हैं, तो उन्हें मेमोरी और उपयोग में लोड करें। और कैश प्राप्त किया जाता है, इसकी बिल्कुल आवश्यकता नहीं है।लेकिन यह इस जगह पर है कि PHP की कमजोरी स्वयं प्रकट होती है ... यह ऐसा नहीं कर सकता। आप कुछ भी प्राप्त नहीं कर पाएंगे, भले ही आप इसे क्रमबद्ध और सहेज लें - फिर भी, अगली बार जब आपको ऑब्जेक्ट पदानुक्रम को इनिशियलाइज़ करना होगा और फिर उसे डीरलाइज़ करना होगा। अत्यधिक, बेकार काम जो कुछ भी तेजी नहीं करता है।

पाचन संख्या चार। क्या आप जानते हैं कि बिना मॉडिफिकेशन के VAZ2101 200 किमी / घंटा की गति तक पहुंचने में सक्षम होने की संभावना क्यों नहीं है? इंजन की वजह से भी नहीं। लेकिन क्योंकि पहले से ही 130 किमी / घंटा पर गरीब "पैसा" एक तरफ से दूसरी तरफ फेंकना शुरू कर देता है ताकि वह ड्राइव करने के लिए डरावना हो जाए। क्योंकि 20 किमी / घंटा पर 15 डिग्री स्टीयरिंग बैकलैश लगभग ध्यान देने योग्य नहीं है, और 200 किमी / घंटा पर आप आसानी से सड़क से सचमुच नीले रंग से उड़ सकते हैं। यह बस ऐसी गति के लिए डिज़ाइन नहीं किया गया है। वैसे, बाइक की सवारी करना भी खतरनाक है। कोई मूल्यह्रास नहीं, प्रत्यक्ष स्टीयरिंग ... एक गलत आंदोलन में काफी शारीरिक नुकसान हो सकता है। यह उच्च गति के लिए भी डिज़ाइन नहीं किया गया है। लेकिन उच्च गति पर, आधुनिक ऑटोमोबाइल उद्योग के परिणामों की सफलता की गणना की जाती है। और क्या आप जानते हैं कि पंद्रह साल पहले एक आधुनिक कार एक औसत साइकिल से कैसे भिन्न होती है? हाँ, सही है। सभी को।लेकिन इसमें जो सबसे महत्वपूर्ण है वह यह है कि इसमें सभी नोड्स पेशेवर डिजाइनरों द्वारा एक-दूसरे के लिए अधिकतम रूप से अनुकूलित हैं ताकि आपको इसके बारे में सोचने की भी जरूरत न हो। आप बस कार में बैठें और ड्राइव करें। और जब आपके संगठन के लिए एक कार अचानक आवश्यक हो जाती है, तो आप विशेष रूप से प्रशिक्षित कार मैकेनिकों को क्यों नहीं नियुक्त करते हैं, जो एक दूसरे के साथ बहस करने के लिए सिलेंडर की संख्या के बारे में बहस करेंगे, जैसे ब्रेक, चेसिस डिजाइन, आपको कार बनाने के लिए आपकी ज़रूरत है , और कोई भी यह फिर से होगा? हां, कोई अपने लिए कारें इकट्ठा करता है, लेकिन यह या तो एक शौक है या एक औद्योगिक ऑर्डर है, और यह हमेशा सस्ता नहीं होता है। लेकिन इस मामले में भी, व्यावहारिक रूप से कोई भी आपके लिए इंजन के मापदंडों की गणना करने और इसे डिजाइन करने के लिए शुरू नहीं करेगा, लेकिन बस उपयुक्त मापदंडों को लें। जब तक, निश्चित रूप से,आप तैयार कार में रुचि रखते हैं, और इंजन मापदंडों की गणना करने की प्रक्रिया नहीं। इस रूपक में, महत्वपूर्ण बिंदु यह है कि ज्यादातर मामलों में विशेषज्ञों द्वारा जो गणना की जाती है वह घुटने की विधानसभा की तुलना में बेहतर और अधिक विश्वसनीय होती है, और कभी-कभी सस्ती होती है। अपवाद के बिना नहीं, बिल्कुल।

वे मुझे बताएंगे: एक ही लेखक सीएमएस या रूपरेखा के बारे में बोलता है! हाँ और ना की तरह। हां, क्योंकि दोनों को प्रोग्रामर को अनावश्यक दिनचर्या के काम से बचाने के लिए डिज़ाइन किया गया है, और नहीं, क्योंकि उनका काम अभी भी आवेदन स्तर पर किया जाता है। दूसरे शब्दों में, यदि आप वाहनों के लिए रिवर्स ऐल्गोराइज़ेशन करते हैं - एक फ्रेमवर्क या सीएमएस, वे शब्दार्थ रूप से अमूर्त विस्तार के अलग-अलग डिग्री के एक निर्माता से इकट्ठी हुई कार के समान हैं। इसके अलावा, बेशक, जीवन का अधिकार है, लेकिन किसी भी तरह ... बड़े पैमाने पर उपयोग में नहीं, शायद। लेकिन प्रोग्रामिंग में, किसी कारण के लिए, यह अभी भी मामला है।

एक ही अजगर पर कई रूपरेखाओं में, उदाहरण के लिए, और, हाल ही में, PHP में, विकास के लिए एक अंतर्निहित वेब सर्वर है, लेकिन उत्पादन पर उनका उपयोग करने की अनुशंसा नहीं की जाती है क्योंकि विशेष समाधान तेज और अधिक विश्वसनीय हैं। वेब सर्वर के साथ काम करने के लिए एक्सटेंशन और प्रोटोकॉल दोनों विकसित किए गए हैं। इसके अलावा।डेटा भंडारण। अधिकांश भाषाओं में फ़ाइल सिस्टम और डेटा संग्रहीत करने के विभिन्न तरीकों के साथ काम करने की अंतर्निहित क्षमताएं हैं। लेकिन एक औद्योगिक पैमाने पर, फिर से, विशेष डीबीएमएस का उपयोग करने की सिफारिश की जाती है - क्योंकि, फिर से, यह अधिक विश्वसनीय है। हालांकि यह हमेशा आसान नहीं होता है। हालांकि कई परियोजनाओं के लिए, मैं मानता हूं, रैम में स्थित SQLite- डेटाबेस, काफी तेज और विश्वसनीय समाधान है। दूसरे शब्दों में, विशेष समाधान फिर से जीतता है। अब आइए आज की साइटों के थोक में देखें और सभी के लिए कुछ अर्थ संबंधी विशेषताओं को उजागर करने का प्रयास करें। उदाहरण के लिए:

• सबसे पहले, डिजाइन सिद्धांत। बन्स के साथ HTML / CSS / JS c। सभी समान। संक्षेप में, केवल टाइपफेस / आकार / फ़ॉन्ट रंग और आकार / शैली / ब्लॉक डिजाइन तत्वों का लेआउट भिन्न होता है।
• -, . , , , (, , ). , . — — - , - .
• -, . - , . , , - . , , , — , , - HTML+CSS+JS. , , , .

और वेब के बारे में क्या? यहाँ HTML5 है - फ्लैश किलर। यहां जेएस - एएस 3 हत्यारा है। सीधे लोगों के सामने किसी तरह का। केवल जो किसी के साथ लड़ रहा है? क्रो-मैग्नन के साथ निएंडरथल का युद्ध, और किसी अज्ञात कारण से, पराजित, क्रो-मैग्नन है। और यह अजीब है, और बुरे विचारों की ओर जाता है कि यह किसी के लिए फायदेमंद हो सकता है। एक तकनीक के रूप में फ्लैश क्या नहीं था? बदसूरत परेशान बैनर? तो सवाल निर्माताओं और वितरकों के लिए हैं, न कि प्रौद्योगिकीविदों के लिए, वास्तव में। क्या है, 2000 के दशक की शुरुआत की HTML साइटों के wyviglaznyh winking डिजाइन- क्या यह बेहतर था? माप से परे चमकने वाली हर चीज जल्द या बाद में चली जाएगी, और वह चली जाएगी। हमें फ्लैश की आवश्यकता क्यों है, क्या अब हमारे पास कैनवास है? नंगा नंगा। Adobe के स्थान पर, मैं नए तरीके से शुरू किए गए तत्वों के साथ ActionScript और व्यवसाय के अगले संस्करण में काम करने के लिए सभी तरीकों को पेंच करूँगा। मैं लंबे समय से उनका पालन नहीं कर रहा था, मुझे नहीं पता, शायद वे पहले से ही ऐसा कर चुके थे। हाल ही में, एक फ़्लैश प्लेयर एक पेस्ट्री की तरह सूज जाता है। तो, HTML के बजाय फ्लैश के पीछे लेखक? नहीं। लेखक एक उचित दृष्टिकोण के लिए है।

पाचन संख्या पाँच, अंतिम। इतना समय पहले नहीं, लेखक ने एक मुफ्त जीवन शुरू किया, अन्य बातों के अलावा, यह एक गैर-मुख्य व्यवसाय प्रोफ़ाइल के रूप में "एक पैसा के लिए tsmsk पर त्वरित त्वरित शुरुआत, लेकिन ठीक है" के सिद्धांत पर साइटों के विकास पर लौटने का निर्णय लिया गया। लेकिन यहाँ PHP में CMS चुनने के सवाल ने मुझे मार दिया, कोई कह सकता है। बहुत समय बीत चुका है, लेकिन मेरे सपनों की चांदी की गोली कभी नहीं मिली। ज़ेन हासिल करने के निरर्थक प्रयासों में, यहां तक ​​कि वाईआईआई पर भी विचार किया गया। जैसा कि वे कहते हैं, बहुत बढ़िया कोड, भयानक विशेषताएं, व्यापक, यद्यपि अंग्रेजी-भाषा, प्रलेखन, एक अच्छा समुदाय। लेकिन निसिल। खैर, मैं किसी फ़ंक्शन के तर्क के रूप में सरणियों के सरणी को पास नहीं कर सकता, जो कि वहीं सेट है। शांत रूपरेखा, शांत लिखित कोड, लेकिन क्यों ??? और मंचों पर निरंतर "कैसे करना है? "गोदी में जाओ!" लेकिन लानत हैयदि एक ही सवाल अलग-अलग समय पर अलग-अलग लोगों से उठता है, तो इस जगह पर कुछ गलत है! सभी प्रोग्रामिंग भाषाओं के सभी मंचों में लगातार एक जैसे प्रश्न होते हैं। एक उपयोगकर्ता कैसे बनाएं, उन्हें कैसे स्टोर करें, उन्हें कैसे हैश करें, एक अनुरोध कैसे लिखें, और यह क्या कर सकता है, और ऐसा क्यों? .. और अब एक सौ हज़ारवां प्रोग्रामर खर्च करता है, शायद, पहले से ही एक सौ अरब वैश्विक मानव-घंटे में एक ही उपयोगकर्ता भंडारण का एहसास करने के लिए, फिर सबसे एन्क्रिप्शन पासवर्ड, डेटाबेस के लिए समान क्वेरीज़, समान कैश को समान स्थानों से जोड़ता है, ताकि बिल्कुल समान ब्रेक हो ... लेकिन प्रशंसा कोड के पुन: उपयोग के बारे में क्या? उस समय के आसपास, ऊपर वर्णित कॉफी स्थिति उत्पन्न हुई, जिसके बाद मैंने अंततः और अपरिवर्तनीय रूप से निर्णय लियाइस जगह पर कुछ गड़बड़ है! सभी प्रोग्रामिंग भाषाओं के सभी फ़ोरम में लगातार समान प्रश्न होते हैं। एक उपयोगकर्ता कैसे बनाएं, उन्हें कैसे स्टोर करें, उन्हें कैसे हैश करें, एक अनुरोध कैसे लिखें, और यह क्यों संभव है? और ऐसा क्यों? .. और अब सौ हज़ारवां प्रोग्रामर खर्च करता है, शायद, दुनिया भर में एक ही उपयोगकर्ता भंडारण का एहसास करने के लिए सौ अरबवां मानव-घंटा, फिर सबसे एन्क्रिप्शन पासवर्ड, डेटाबेस के लिए समान क्वेरीज़, समान कैश को समान स्थानों से जोड़ता है, ताकि बिल्कुल समान ब्रेक हो ... लेकिन प्रशंसा कोड के पुन: उपयोग के बारे में क्या? उस समय के आसपास, ऊपर वर्णित कॉफी स्थिति उत्पन्न हुई, जिसके बाद मैंने अंततः और अपरिवर्तनीय रूप से निर्णय लियाइस जगह पर कुछ गड़बड़ है! सभी प्रोग्रामिंग भाषाओं के सभी मंचों में लगातार एक जैसे प्रश्न होते हैं। एक उपयोगकर्ता कैसे बनाएं, उन्हें कैसे स्टोर करें, उन्हें कैसे हैश करें, एक अनुरोध कैसे लिखें, और यह क्या कर सकता है, और ऐसा क्यों? .. और अब एक सौ हज़ारवां प्रोग्रामर खर्च करता है, शायद, पहले से ही एक सौ अरब वैश्विक मानव-घंटे में एक ही उपयोगकर्ता भंडारण का एहसास करने के लिए, फिर सबसे एन्क्रिप्शन पासवर्ड, डेटाबेस के लिए समान क्वेरीज़, समान कैश को समान स्थानों से जोड़ता है, ताकि बिल्कुल समान ब्रेक हो ... लेकिन प्रशंसा कोड के पुन: उपयोग के बारे में क्या? उस समय के आसपास, ऊपर वर्णित कॉफी स्थिति उत्पन्न हुई, जिसके बाद मैंने अंततः और अपरिवर्तनीय रूप से निर्णय लियाऔर ऐसा क्यों? .. और अब सौ-हज़ारवां प्रोग्रामर खर्च करता है, शायद, पहले से ही सौ-बिलियन विश्वव्यापी मानव-घंटे उपयोगकर्ताओं के एक ही भंडारण का एहसास करने के लिए, एक ही पासवर्ड एन्क्रिप्शन, एक ही डेटाबेस अनुरोध, एक ही कैश उसी तरह जोड़ता है ... कोड? उस समय के आसपास, ऊपर वर्णित कॉफी स्थिति उत्पन्न हुई, जिसके बाद मैंने अंततः और अपरिवर्तनीय रूप से निर्णय लियाऔर ऐसा क्यों? .. और अब सौ-हज़ारवां प्रोग्रामर खर्च करता है, शायद, पहले से ही सौ-बिलियन विश्वव्यापी मानव-घंटे उपयोगकर्ताओं के एक ही भंडारण का एहसास करने के लिए, एक ही पासवर्ड एन्क्रिप्शन, एक ही डेटाबेस अनुरोध, एक ही कैश उसी तरह जोड़ता है ... कोड? उस समय के आसपास, ऊपर वर्णित कॉफी स्थिति उत्पन्न हुई, जिसके बाद मैंने अंततः और अपरिवर्तनीय रूप से निर्णय लियाto बिल्कुल___हे_ने_ असामान्य ... लेकिन बहु-प्रशंसित कोड के पुन: उपयोग के बारे में क्या? उस समय के आसपास, ऊपर वर्णित कॉफी स्थिति उत्पन्न हुई, जिसके बाद मैंने अंततः और अपरिवर्तनीय रूप से निर्णय लियाto बिल्कुल___हे_ने_ असामान्य ... लेकिन बहु-प्रशंसित कोड के पुन: उपयोग के बारे में क्या? उस समय के आसपास, ऊपर वर्णित कॉफी स्थिति उत्पन्न हुई, जिसके बाद मैंने अंततः और अपरिवर्तनीय रूप से निर्णय लियाभेजने अजगर में पीएचपी पक्ष है, जो काफी समय में गिरा से दूर है, और इस लेख लिखने के लिए।

तो लेखक क्या चाहता है, और यह सब क्यों होता है?

श्रेणी से पूछे गए प्रश्न के लिए मेरा सबसे अप्रकाशित उत्तर: "ऐसा क्यों किया जा रहा है / बिल्कुल इसी तरह होता है?" "और आप कैसे चाहते हैं?"। किसी कारण से, यह मुझे स्पष्ट लगता है कि मेरा मतलब है कि जो कुछ हो रहा है, उससे अलग है, क्योंकि वास्तव में, मैं पूछता हूं। तो, कृपया कुछ प्रश्नों के उत्तर दें:

• हम अक्सर विकास उपकरण का उपयोग क्यों करते हैं जिसमें कोड निष्पादन के प्रत्येक चरण में अलग-अलग डिग्री के पार्सिंग और पार्सिंग शामिल होते हैं, पहले सर्वर की तरफ, और फिर क्लाइंट की तरफ?
• , - , ?
• -, --- FAQ' , , ?
• CRUD, ( IT-, ) ?
• User/Password Post/Comments - — , , ?
• , , ( __JS_, ) — , 20 , , ? , . , MVC , , , , ?
• , , , ?
• , , , , MVC, -, ? , ?
• - ? - RichWebDataServer, web-, , , , , , ? , . - HTTP_2.0 . MVC, , . , ActionScript, - , plain_text GET|POST. , - X.Org RDP, , , .

यह उनकी सेवा के लिए ब्राउज़रों को धन्यवाद देने का समय है, लंबे और वफादार हैं, और उन्हें स्टेंसिल और टाइपराइटर के बगल में इतिहास संग्रहालयों को सौंपते हैं, अपनी जेब से कुछ नए-पुराने उपकरण निकालते हैं, और आधुनिक तकनीक की विजय पर निर्मित प्रामाणिक इंटरैक्टिव का आनंद लेते हैं, न कि टुकड़ों पर। तकनीक तीस साल पहले। बस मजाक कर रहे हैं।:) लेकिन गंभीरता से, फिर गंभीर रूप से मौजूदा वेब की संपूर्ण प्रौद्योगिकी स्टैक की समीक्षा करें, मेरे व्यक्तिपरक राय में, यह वास्तव में समय है। PHP के लिए के रूप में, यह कहीं भी नहीं जाएगा। मैं बाहर नहीं करता कि वह नए वेब में जगह पाएगा। खासकर अगर उत्साही लोग " तेज घोड़ा " बनाने की कोशिश करना बंद कर देते हैं । और अच्छी पुरानी सीधी साइटें इस पर बहुत लंबे समय तक काम करेंगी।

और एक बात और। सामने आए सवालों में, मैं जानबूझकर छड़ी को स्थानों पर झुकाता हूं और काफी सचेत रूप से वैध आलोचना की उम्मीद करता हूं। जैसा कि अभ्यास से पता चलता है, अच्छी तरह से की जाने वाली आलोचना कमजोरियों को अच्छी तरह से प्रकट करती है, और अगर अच्छा है, तो वास्तव में उपयोगी कुछ पैदा हो सकता है। केवल एक चीज जिससे मैं बचना चाहूंगा, वह यह है कि "उपकरणों की मौजूदा सफलता और प्रशिक्षित विशेषज्ञों की सेना को कहां रखा जाए" की भावना से टिप्पणी की जाती है। मैं इतना भोला नहीं हूं कि तत्काल क्रांति के साथ विस्फोटक प्रभाव की उम्मीद करूं। सच में, मुझे बिल्कुल भी यकीन नहीं है कि दुनिया में कुछ भी बदल जाएगा, लेकिन कुछ कारण की जीत की उम्मीद हैकम से कम अभी भी वहाँ किसी को हिलाओ। मैं आत्म-पुष्टि के खिलाफ भी चेतावनी देना चाहूंगा जैसे कि "यह तुरंत स्पष्ट है कि लेखक एक प्रोग्रामर नहीं है" - यह मौजूदा प्रौद्योगिकियों के ढांचे के भीतर कोड के बारे में नहीं है, बल्कि खुद प्रौद्योगिकियों के विस्तार और सुविधा के बारे में है। एक अनुभवी टकटकी के अंधेपन के बारे में, मामलों की इस स्थिति को ठीक करने का आदी। और इस बारे में कि क्या दुनिया को बेहतर और स्वच्छ बनाया जा सकता है, और इसके लिए क्या आवश्यक है।

मैं इस ओपस को पढ़ते समय सभी का ध्यान और धैर्य के लिए धन्यवाद देता हूं। और मैं इतनी लंबी प्रस्तुति के लिए माफी मांगता हूं। और नहीं, लेखक स्किज़ोफ्रेनिक नहीं है। हम दोनों इस पर बिल्कुल यकीन करते हैं - मैं और लेखक दोनों। :)