बोनसाई: परिवार विकि इंजन

गेय परिचय

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

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



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

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

एक और बाइक?

आज, बहुत सारे उपकरण हैं जो आपको परिवार के पेड़ों और कैटलॉग को रिश्तेदारों के बारे में जानकारी देने की अनुमति देते हैं। उन्हें सशर्त रूप से दो व्यापक श्रेणियों - ऑनलाइन सेवाओं और डेस्कटॉप अनुप्रयोगों में विभाजित किया गया है।

डेस्कटॉप एप्लिकेशन के मामले में, डेटाबेस को आमतौर पर डिस्क पर एक फाइल के रूप में संग्रहीत किया जाता है। आप एप्लिकेशन को खोलते हैं और इसे सिंगल-यूजर मोड में भरते हैं। यदि आवश्यक हो, तो डेटा को बैकअप के लिए या किसी अन्य सिस्टम (उदाहरण के लिए, GEDCOM प्रारूप में) में स्थानांतरित किया जा सकता है। उनमें से जो मैंने देखा था, उपयोग करने के लिए सबसे सुखद लग रहा था ग्रैम्प (मुक्त) और घरेलू जीवन वृक्ष (एक बार की खरीद की आवश्यकता है)।

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

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

इन दोनों दृष्टिकोणों की कमियों को देखते हुए, हम "आदर्श" इंजन के लिए आवश्यकताओं की एक सूची तैयार कर सकते हैं:

1. अपने स्वयं के सर्वर पर होस्ट किया गया वेब अनुप्रयोग
2. लोगों, पालतू जानवरों, स्थानों, घटनाओं आदि के बारे में लेख बनाना। विकी की तरह
3. मीडिया डाउनलोड करें
4. फोटो और वीडियो में लोगों के निशान
5. स्वचालित परिवार वृक्ष निर्माण
6. सभी महत्वपूर्ण तिथियों के साथ कैलेंडर।
7. सह-संपादन और भरने के लिए उपकरण

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

सुनहरा नियम कहता है: यदि आप अच्छा करना चाहते हैं - तो स्वयं करें!

उपयोग की गई तकनीकों को तीन मानदंडों के अनुसार चुना गया था: उनके साथ मेरा अनुभव, लोकप्रियता और खुलेपन से मुक्त। यहाँ परिणाम है:

• रनटाइम : .NET कोर 2.1
• बैकएंड : ASP.NET कोर MVC
• डेटाबेस : PostgreSQL
• फ़्रंटेंड लॉजिक : आंशिक रूप से Vue, आंशिक रूप से jQuery।
• सीमावर्ती शैलियाँ : बूटस्ट्रैप + सैस

सहायक भूमिकाओं में वीडियो से स्क्रीनशॉट लेने के लिए पूर्ण-पाठ खोज और ffmpeg के लिए एलीस्टेकर्च शामिल हैं।

डेटा स्कीमा

बोनसाई डेटाबेस में मुख्य ऑब्जेक्ट एक पृष्ठ और एक मीडिया फ़ाइल है । वे निशान के माध्यम से कई-से-कई संबंधों से जुड़े हुए हैं। एक टैग में लिंक के बिना एक शीर्षक हो सकता है - उदाहरण के लिए, यदि आपको किसी फ़ोटो में किसी को टैग करने की आवश्यकता है, लेकिन इसके बारे में पूर्ण पृष्ठ पर कोई जानकारी नहीं है।



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

चुनने के लिए पाँच प्रकार के पृष्ठ हैं: व्यक्ति, पालतू जानवर, घटना, स्थान और इसी तरह। उपलब्ध तथ्यों की सूची पृष्ठ के प्रकार पर निर्भर करती है: उदाहरण के लिए, "शिक्षा" केवल एक व्यक्ति के लिए प्रासंगिक है, "जन्म की तारीख" एक व्यक्ति और एक जानवर के लिए है, और "पता" केवल एक जगह के लिए है।

पेज रिश्तों द्वारा जुड़े हुए हैं : "माता-पिता", "पति या पत्नी", "दोस्त", "मालिक", "निवासी" और कई अन्य। कुछ रिश्ते समय में सीमित हो सकते हैं (पति / पत्नी, मालिक, निवासी), अन्य को स्थायी माना जाता है।

जब आप किसी पृष्ठ या संबंध को सहेजते हैं, तो परिणामी मॉडल को संगति के लिए जांचा जाता है। उदाहरण के लिए, जीवनसाथी के जीवन के वर्ष ओवरलैप होने चाहिए , एक व्यक्ति के पास प्रत्येक सेक्स के एक से अधिक जैविक माता-पिता नहीं हो सकते हैं, और आप अपने खुद के पिता भी नहीं बन सकते। हालांकि, समान-विवाह विवाह अनुमति योग्य हैं।

पृष्ठ, मीडिया फ़ाइल या संबंध का संपादन डेटाबेस में परिवर्तन को बचाता है। यह आपको संपादन के इतिहास को बचाने और यदि आवश्यक हो तो उन्हें वापस रोल करने की अनुमति देता है।

संबंधों

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

रिश्तेदारी के लिए बहुत सारे विकल्प हैं, लेकिन मूल तीन हैं: माता-पिता , बच्चे और पति या पत्नी । वे आपको उस परिवार से एक निर्देशित ग्राफ बनाने की अनुमति देते हैं जहां ये रिश्ते किनारों हैं और लोग नोड हैं। इस स्तंभ पर, आप प्रतिभागियों और उनके लिंग के बीच का रास्ता जानते हुए, किसी भी अन्य रिश्ते को व्यक्त कर सकते हैं: उदाहरण के लिए, किसी के दादा की पहचान करने के लिए, आपको पहले उसके माता-पिता (किसी भी लिंग) को ढूंढना होगा, और फिर इस माता-पिता (पुरुष) के माता-पिता, और इसी तरह।

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



रिश्ते की गणना करने के लिए, एक प्राथमिक ग्राफ ट्रैवर्सल का उपयोग किया जाता है, और रिश्ते के नाम एक विशेष डीएसएल के रूप में सेट होते हैं:

public static RelationDefinition[] ParentRelations = { new RelationDefinition("Parent:m", ""), new RelationDefinition("Parent:f", ""), new RelationDefinition("Parent Child:m", "", ""), new RelationDefinition("Parent Child:f", "", ""), new RelationDefinition("Parent Parent:m", "", ""), new RelationDefinition("Parent Parent:f", "", "") }; 

यहां तक ​​कि एक व्यक्ति के कई प्रत्यक्ष रिश्तेदार हो सकते हैं। बोनसाई निम्नलिखित समूहों में लिंक को विभाजित करता है:

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

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



जैसा कि हम देखते हैं, दो पत्नियों (वेरा और गैलिना) और एक बेटे (बोरिस) को सिकंदर के लिए संकेत दिया गया है, लेकिन हम नहीं जानते कि कौन सी पत्नियों की मां बच्चे की मां है - शायद यह किसी तरह की तीसरी महिला है, लेकिन उसे अभी तक जोड़ा नहीं गया है। ऐसे मामलों के लिए, कई रास्तों को इंगित किया जा सकता है जो मौजूद होना चाहिए या मौजूद नहीं होना चाहिए, और वे क्रमशः + और - संकेतों के साथ चिह्नित हैं:

 new RelationDefinition("Spouse Child+Child", "||", "") new RelationDefinition("Spouse Child-Child:m", "") new RelationDefinition("Spouse Child-Child:f", "") 

परिवार का पेड़

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

यहां कुछ उदाहरण दिए गए हैं कि परिवार के पेड़ किस तरह दिख सकते हैं:



टारगेरेनोव का पारिवारिक पेड़। बहुत कॉम्पैक्ट, क्योंकि यह हाथ से बनाया गया है। इस तरह के पेड़ को मनमाने डेटा से उत्पन्न करना अपने आप बेहद मुश्किल होगा।



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



एक अर्धवृत्ताकार आरेख के रूप में एक पेड़ की प्रस्तुति। आसानी से स्वचालित रूप से उत्पन्न होता है, लेकिन केवल पूर्वजों को ध्यान में रखता है।

मैंने कई विकल्पों के माध्यम से देखा। MyHeritage वेबसाइट पर सबसे अधिक सौंदर्यप्रद मनभावन था:



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

जल्दबाजी में एक स्व-निर्मित समाधान को फेंकने का प्रयास पूरी तरह से असफलता में समाप्त हो गया। ग्राफ तत्वों की एक सक्षम व्यवस्था एक ऐसा जटिल क्षेत्र है जिस पर शोध प्रबंध लिखे गए हैं, और तैयार किए गए घटक मास्को में एक अपार्टमेंट की तरह हैं। ठीक है, आप अपने आप को लिखने में सक्षम नहीं होंगे, लेकिन निश्चित रूप से सभ्य मुक्त समाधान हैं?

मेरी ज्यादातर उम्मीदें डी.जे. लाइब्रेरी में थीं। शायद यह पहली बात है जो आपको किसी वेब पेज पर एक ग्राफ या चार्ट बनाने की जरूरत है। काश, विकी पर तीन सौ से अधिक (!) उदाहरणों में, MyHeritage के पेड़ के समान एक या अधिक नहीं था।

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

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

अपने दम पर उपयुक्त समाधान नहीं मिलने के बाद, मैंने इसे फ्रीलान्स पर ऑर्डर करने का फैसला किया, और फिर बहुत ही ड्रामा शुरू हो गया।

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



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

बच्चे को फेंक दिया - पर कर्म में ऋण!

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

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

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



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

पूर्ण पाठ खोज

सुविधाजनक पूर्ण-पाठ खोज के बिना पाठ्य सूचना को संग्रहीत करने की प्रणाली बेकार होगी। बोन्साई PostgreSQL डेटाबेस का उपयोग करता है, इसलिए पहली चीज़ जो मैंने तय की थी वह यह जांचना था कि यह बॉक्स से बाहर की पेशकश क्या कर सकता है। एक और निराशा: tsvector सामान्य शब्दों के साथ tsvector करता है, लेकिन सबसे महत्वपूर्ण चीज की खोज करने से इंकार करता है - नाम और उपनाम:

 SELECT to_tsvector('') @@ to_tsquery(''), -- true to_tsvector('') @@ to_tsquery(''), -- false to_tsvector('') @@ to_tsquery(''), -- false to_tsvector('') @@ to_tsquery(''), -- false to_tsvector('  ') @@ to_tsquery('') -- false 

ट्रिगर्स ने भी कुछ अच्छा नहीं दिया। अंत में, मैं एक अपेक्षित विकल्प पर बस गया: इलास्टिकसर्च + रूसी आकृति विज्ञान । यह .NET से इसके साथ काम करने के लिए बहुत असुविधाजनक निकला, हालांकि, वह अपने पूरे नाम के साथ एक ठोस पांच की खोज का सामना करता है।

होश में लाना

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

उदाहरण के लिए, जब हम कोई पृष्ठ खोलते हैं तो क्या होता है?

1. पेज टेक्स्ट को मार्कडाउन से HTML में संकलित किया गया है। यदि पाठ में अन्य पृष्ठों और मीडिया फ़ाइलों के लिंक हैं, तो आपको अधिक जानकारी के लिए डेटाबेस में जाना होगा।
2. तथ्यों को JSON से हटा दिया जाता है जिसमें वे डेटाबेस में संग्रहीत होते हैं, दृश्य मॉडल में।
3. रिश्ते तय होते हैं। ऐसा करने के लिए, लंबे समय से पीड़ित डेटाबेस से, संपूर्ण कनेक्शन ग्राफ प्राप्त करना और उसमें पहले से ज्ञात रास्तों के अनुसार नोड ढूंढना आवश्यक है।

पहली नज़र में यह बहुत मुश्किल ऑपरेशन जैसा लगता है, लेकिन वास्तव में यह अपेक्षाकृत कम मात्रा में डेटा के कारण नहीं है। आप कितने रिश्तेदारों को याद कर सकते हैं और लिखना चाहते हैं? ब्याज की खातिर उन्हें फिर से मिलाने की कोशिश करें और पाएँ कि कम से कम सौ डायल करना बहुत मुश्किल होगा। और कितने लोग पहुँच देना चाहते हैं? यहां तक ​​कि एक परिवार के लिए एक खगोलीय बड़ी संख्या में एक हजार लोग हैं! - आधुनिक डेटाबेस के मानकों के अनुसार, यह हास्यास्पद है।

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

परियोजना स्थानीयकरण और उपस्थिति के परिवर्तन का समर्थन नहीं करती है, प्राधिकरण OAuth पर Facebook \ Google पर काम करता है, और व्यवस्थापक पैनल सामान्य रूपों पर बनाया जाता है, न कि नवीनतम फैशन के आधार पर कुछ एसपीए फ्रेमवर्क। यह सब महसूस किया जा सकता है या सुधार किया जा सकता है , लेकिन इससे कोई समस्या हल नहीं होती और इसलिए समय बर्बाद होता।

भविष्य की ओर देख रहे हैं

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

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

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

कैसे करें कोशिश?

दुर्भाग्य से, मैं समाप्त डेमो के लिए एक लिंक प्रदान नहीं कर सकता: कोई सर्वर नहीं है जो हबल प्रभाव का सामना कर सकता है। लेकिन कुछ दृश्य स्क्रीनशॉट हैं (चित्र क्लिक करने योग्य हैं)।



यदि बोनसाई आपको उपयोगी लगता है और आप इसे स्वयं चलाना चाहते हैं, तो स्रोत कोड जीथब से डाउनलोड किया जा सकता है:

https://github.com/impworks/bonsai

रीडमी में विस्तृत स्थापना निर्देश प्रदान किए गए हैं। आपको इसकी आवश्यकता होगी:

1. .NET कोर 2.1+
2. PostgreSQL 10+
3. ElasticSearch 5.x और रूसी आकृति विज्ञान प्लगइन
4. OAuth प्राधिकरण के लिए फेसबुक या Google ऐप

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

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