ASP.NET MVC पाठ एफ। यह है के रूप में काम करते हैं

सबक उद्देश्य: एक आवेदन बनाने पर अंतिम पाठ। तकनीकी विनिर्देश लेखन। एक डेटाबेस बनाना। WebTemplate का नाम बदलें। मचान का उपयोग। व्यवस्थापक। मुख्य साइट। टेस्ट।

मुख्य के बारे में

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

(defun quicksort (lis) (if (null lis) nil (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< ax)))) (append (quicksort (remove-if-not fn r)) (list x) (quicksort (remove-if fn r)))))) 

लेकिन अब मैं प्रोग्रामिंग को एक सेवा के रूप में देखता हूं। जैसे कुछ मुझे मिलता है। मैं तीन साल से फ्रीलांस कर रहा हूं। एक फ्रीलांसर के रूप में मेरे काम की शुरुआत में, मैंने न केवल वेब और न केवल asp.net mvc पर प्रोग्राम किया। ZendFramework पर php था, और Quirk पर RTS पर ट्रेडिंग के लिए रणनीतियों की गणना के लिए मॉड्यूल लिख रहा था।



लेकिन फिर उसने asp.net mvc की दिशा को एकतरफा कर दिया और उसमें विकास करना शुरू कर दिया। वैश्विक, रणनीतिक उद्देश्य इस प्रकार था: "विकास की गति बढ़ाना।" विकास की गति सबसे महत्वपूर्ण पैरामीटर है। सबसे पहले, हम अपना समय बचाते हैं, और बेहतर समय सीमा का भी पालन करते हैं। उसी समय, मैं पाइपलाइन विकास में स्लाइड नहीं करना चाहता था, जहां प्रोग्रामर, बार-बार, एक ही तरह की केले की चीजें करता है। मैंने अपने लिए उन उपकरणों को संचित करने और बनाने की एक विधि की पहचान की है जिनकी लगभग हमेशा आवश्यकता होती है।

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

सिद्धांतों के बारे में

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

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

संदर्भ की शर्तें

तकनीकी कार्य आपका सब कुछ है, यह सफलता का 70% है। संदर्भ की शर्तों को निम्नलिखित प्रश्नों का उत्तर देना चाहिए और निम्नलिखित भागों से मिलकर होना चाहिए:

• उद्देश्य। यहां हम परियोजना के उद्देश्य का संक्षेप में वर्णन करते हैं। हम क्या कर रहे हैं? यह परियोजना किस लिए है?
• परियोजना के कुछ हिस्सों। उन्हें तार्किक रूप से परियोजना के लक्ष्य से आना चाहिए और डेटाबेस में टेबल बनाने का प्रोटोटाइप होगा। वहाँ होना चाहिए:
  
  • साइट भाषा (यदि बहुभाषी, कौन सी भाषाएं)
  • परियोजना का सार। यह हो सकता है:
    
    • उपयोगकर्ता
    • पद
    • समाचार
    • वीडियो
    • फोटो एल्बम
    • फोटो कार्ड
    • मशीन
    • मित्र
    • संगीत
    • खेल, आदि
    
    
  • साइट सुविधाएँ। इसमें शामिल हैं:
    
    • पंजीकरण
    • व्यक्तिगत खाता
    • मेरी तस्वीरें
    • स्थिति
    
    
  • साइट व्यवस्थापक।
    
    • उपयोगकर्ताओं
      
      • सक्रिय करने की क्षमता के साथ
      • प्रतिबंध लगाने के लिए
      
      
    • वीडियो
      
      • जोड़ना
      • संशोधन करना
      • हटाएं
      
      
    • समाचार
      
      • जोड़ना
      • संशोधन करना
      • हटाएं
      
      
    • एसएमएस के साथ काम करें
    • सामाजिक नेटवर्क के माध्यम से पंजीकरण
    • वेबमनी या अन्य ऑनलाइन भुगतान प्रणालियों के साथ काम करें
    
    
  
  
• समय और बजट। परियोजना के सभी हिस्सों का वर्णन करने के बाद, हम एक टैबलेट बनाते हैं
  
  • कार्य करें। उदाहरण के लिए, "प्रोजेक्ट डेटाबेस बनाना" या "पंजीकरण"
  • तिथियां (घंटों में)। कोशिश करें कि प्रत्येक सेल में 20 घंटे से अधिक न हों। और निश्चित रूप से 40+ घंटे नहीं। अन्यथा, कार्य को छोटे भागों में तोड़ने का प्रयास करें।
  • पैसा। बस अपने वर्तमान दांव से गुणा करें।
  • परिणाम। इसके बाद, बिना देखे या गोलाई में रिजल्ट को देखें। $ 1695, उदाहरण के लिए? हां, और लिखो। समय और बजट एक महत्वपूर्ण हिस्सा है, यह हमें एक परिभाषा देता है कि विकास में कितना समय लगेगा (दिन में 6 घंटे, 8 या इससे भी बदतर 10 नहीं) और कितना खर्च होगा।
  
  

इस प्रकार, टीके तीन चीजों की घोषणा करता है, सबसे महत्वपूर्ण:

• क्या करें?
• कितना समय लगता है
• कितना खर्च होगा

इस लिंक को छोड़कर, आप शुरू में प्रोजेक्ट को बर्बाद कर देते हैं। आप काम के मामले में, लागत में, तीनों बिंदुओं के लिए गलत हैं। इससे बचने की कोशिश करें।

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

मैं फिर से स्पष्ट करूंगा: टीके बातचीत के सबसे महत्वपूर्ण सिद्धांतों में से एक - घोषणा के सिद्धांत का उपयोग करता है। यह लिखा है "हम 10:00 से 20:00 बजे तक काम करते हैं", ग्राहक 20:10 पर पहुंचे, और यह बताने लायक नहीं है कि आप उन्हें क्यों नहीं भेज सकते। लेकिन ग्राहक की नाक के सामने दरवाजा बंद करने के लिए 19:50 पर अपने स्वयं के नियमों का उल्लंघन है, उनकी अपनी घोषणा।

टीके ने मंजूरी दे दी। आपको काम मिल सकता है।

बेस संरचना, वेबटेम्पलेट और मचान

तकनीकी कार्य के माध्यम से चल रहा है, मैं सभी संस्थाओं को एक फाइल में अलग से लिखता हूं, कनेक्शन का मूल्यांकन करता हूं। और फिर मैं उन्हें डेटाबेस में वर्णित करता हूं। इसमें बहुत समय लगता है, 8 घंटे तक। टीके के बाद - यह परियोजना का सबसे महत्वपूर्ण हिस्सा है।

उसके बाद, मैं webTemplate प्रोजेक्ट की प्रतिलिपि बनाता हूं और webTemplate का नाम बदल देता हूं -> [नया प्रोजेक्ट नाम]। इसमें लगभग 30 मिनट लगते हैं।

उसके बाद, एक नई परियोजना में, मैं आवश्यक प्रदाताप्रतिपाद और मॉडल तालिकाओं के लिए मचान चला रहा हूं। आप तुरंत सभी आदेशों की रचना कर सकते हैं और प्रक्रिया शुरू करने और चाय पीने के लिए पैकेज प्रबंधक कंसोल पर कॉपी कर सकते हैं।

अगला, ViewModels में, मैं आवश्यक SelectReference जोड़ता हूं, अनावश्यक फ़ील्ड हटाता हूं और ManagedAttribute से आवश्यक विशेषताओं को जोड़ता हूं और मचान नियंत्रक को प्रारंभ करता हूं।

उसके बाद, मैं प्रोजेक्ट को सही करता हूं ताकि यह संकलित हो, और मैं व्यवस्थापक पैनल के साथ काम करता हूं।

इसके अलावा, मुख्य पृष्ठ से शुरू करते हुए, मैं दिन के बाद अन्य सभी मॉड्यूल करता हूं।

खुद की लय

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

• रविवार नियोजन (कार्य) का दिन है। इस दिन, यह आवश्यक है कि अगले दो दिनों में योजना बनाई जाए और काम शुरू किया जाए।
• सोमवार एक सामान्य कारोबारी दिन है। इस दिन, मैं वही करना शुरू करता हूं जो मैंने रविवार को किया था।
• मंगलवार एक व्यस्त कार्य दिवस है। इस दिन, मैं आमतौर पर स्काइप को बंद कर देता हूं और काम का एक बहुत बड़ा हिस्सा करता हूं। कार्य दिवस लगभग 10-12 घंटे तक रहता है। आमतौर पर यह एक टुकड़ा बनाने के लिए पर्याप्त होता है जिसमें दो या तीन सामान्य दिन लगते हैं। रविवार का लक्ष्य इस बड़ी मात्रा में काम की योजना बनाना है।
• बुधवार आधा दिन है। बुधवार को, मैं पुरानी परियोजनाओं के संपादन से विचलित हो जाता हूं, और शहर में चीजों को तय करता हूं। शायद पूरे दिन की छुट्टी भी।
• गुरुवार या तो वर्तमान परियोजना के लिए मंगलवार के बाद वापसी है, या यदि वे अभी भी बने हुए हैं तो संपादन जारी है।
• शुक्रवार एक सामान्य कार्य दिवस है, आमतौर पर वर्तमान परियोजना पर कुछ नियमित पूरा हो रहा है।
• शनिवार - कोई प्रोग्रामिंग नहीं। आराम करें।

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

अपनी लय के लिए देखें, अपने विचारों को महसूस करें।

सभी स्रोत https://bitbucket.org/chernikov/lessons पर स्थित हैं