👋🏾 🧚 ❎ सामाजिक ग्राफ के कार्यान्वयन पर विचार 🐣 ⌨️ 👩🏽

आपका स्वागत है!

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

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

आइए एक सामाजिक ग्राफ के बारे में कल्पना करने की कोशिश करें और कुछ रेल कोड लिखें।

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

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

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

आगे देखते हुए, मैं कहूंगा कि मैंने कोड के अपने संस्करण में रिकॉर्ड का उत्पादन नहीं करने का फैसला किया है और डेटाबेस में 2 प्रश्न सबमिट करने के मार्ग के साथ चला गया।

सामाजिक नेटवर्क पर प्रदर्शित होने की तुलना में दुनिया अधिक जटिल है

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

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

इसके अलावा, एक नियम के रूप में, एक सामाजिक कनेक्शन का एक संदर्भ (जीवन, काम, सेना, स्कूल) है - अर्थात। जिस स्थान पर यह कनेक्शन स्थापित किया गया था।

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

इससे मुझे लगता है कि अगर सामाजिक रूप से महान होगा। नेटवर्क में अलग-अलग विकल्प प्रदान किए गए - एक दोस्त, एक खेल प्रशिक्षक, मेरी दादी, स्कूल का एक सहपाठी, एक ~~पीने वाला साथी~~ , काम का एक सहयोगी, एक बॉस, एक विभाग प्रमुख, आदि।

3 मिनट के लिए 45 मिनट का समय लेते हुए, मैंने उस चीज़ का एक प्रोटोटाइप फेंकने की कोशिश की, जिसने मेरे शिक्षक के दिमाग को अचानक उत्तेजित कर दिया।

आदर्श

मॉडल (मैं इसे ग्राफ़ कहूंगा) में 2 उपयोगकर्ता आईडी (आवेदन जमा करने वाला और आवेदन प्राप्त करने वाला व्यक्ति), आवेदन की स्थिति, प्रेषक की भूमिका और प्राप्तकर्ता की भूमिका, साथ ही साथ सामाजिक संचार का संदर्भ शामिल है।

rails g model graph context:string sender_id:integer sender_role:string recipient_id:integer recipient_role:string state:string

जो निम्नलिखित प्रवास देता है:

 class CreateGraphs < ActiveRecord::Migration def self.up create_table :graphs do |t| t.string :context t.integer :sender_id t.string :sender_role t.integer :recipient_id t.string :recipient_role t.string :state t.timestamps end end def self.down drop_table :graphs end end

कंसोल में चलाएँ:

 rake db:migrate

डेटाबेस में निर्दिष्ट फ़ील्ड के साथ आवश्यक तालिका बनाएंगे।

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

 class Graph < ActiveRecord::Base scope :pending, where(:state => :pending) scope :accepted, where(:state => :accepted) scope :rejected, where(:state => :rejected) scope :deleted, where(:state => :deleted) #state pending, accepted, rejected, deleted state_machine :state, :initial => :pending do event :accept do transition :pending => :accepted end event :reject do transition :pending => :rejected end event :delete do transition all => :deleted end event :initial do transition all => :pending end end end

उपयोगकर्ता मॉडल के लिए (यह किसी भी तरह से प्रत्येक एप्लिकेशन में है) मैं सबसे पहले एक विधि जोड़ूंगा : graph_to , जो मुझे इस उपयोगकर्ता के लिए एक ग्राफ़ तत्व लौटाएगा (यदि कोई ग्राफ़ तत्व मौजूद है) या बस एक नया तत्व बनाएं।

मैं वर्तमान उपयोगकर्ता से किसी अन्य उपयोगकर्ता के लिए, किसी संदर्भ में एक ग्राफ़ तत्व बनाता हूं, जहां मैं कोई हूं और प्राप्तकर्ता भी कोई है (पूर्वनिर्धारित भूमिकाओं के अनुसार)।

डिफ़ॉल्ट रूप से, संदर्भ जीवन है, और उपयोगकर्ताओं की भूमिकाएं हैं - एक दोस्त।

 class User < ActiveRecord::Base def graph_to(another_user, opts={:context=>:live, :me_as=>:friend, :him_as=>:friend}) Graph.where(:context=>opts[:context], :sender_id=>self.id, :sender_role=>opts[:me_as], :recipient_id=>another_user, :recipient_role=>[:him_as]).first || graphs.new( :context=>opts[:context], :sender_role=>opts[:me_as], :recipient_id=>another_user.id, :recipient_role=>opts[:him_as]) end end

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

मैं उन लोगों के लिए समझाता हूं जो रूबल में नहीं पढ़ सकते हैं।

उपयोगकर्ता कोड में बनाए गए हैं।
संबंध संदर्भ स्थापित होते हैं।
प्रत्येक संदर्भ के लिए, उपयोगकर्ता भूमिकाएँ निर्धारित की जाती हैं।
अनुप्रयोग बेतरतीब ढंग से प्रस्तुत किए जाते हैं और उसी तरह, अनुप्रयोगों को बेतरतीब ढंग से एक स्थिति प्राप्त होती है

 namespace :db do namespace :graphs do # rake db:graphs:create desc 'create graphs for development' task :create => :environment do i = 1 puts 'Test users creating' 100.times do |i| u = User.new( :login => "user#{i}", :email => "test-user#{i}@ya.ru", :name=>"User Number #{i}", :password=>'qwerty', :password_confirmation=>'qwerty' ) u.save puts "test user #{i} created" i = i.next end#n.times puts 'Test users created' contexts = [:live, :web, :school, :job, :military, :family] roles={ :live=>[:friend,:friend], :web=>[:moderator, :user], :school=>[:teacher, :student], :job=>[:chief, :worker], :military=>[:officer, :soldier], :family=>[:child, :parent] } users = User.where("id > 10 and id < 80") #70 users test_count = 4000 test_count.times do |i| sender = users[rand(69)] recipient = users[rand(69)] context = contexts.rand # :job role = roles[context].shuffle # [:worker, :chif] # trace p "test graph #{i}/#{test_count} " + sender.class.to_s+" to "+recipient.class.to_s + " with context: " + context.to_s graph = sender.graph_to(recipient, :context=>context, :me_as=>role.first, :him_as=>role.last) graph.save # set graph state reaction = [:accept, :reject, :delete, :initial].rand graph.send(reaction) end# n.times end# db:graphs:create end#:graphs end#:db

उल्टे ग्राफ तत्व

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

मैं उपयोगकर्ता मॉडल की पंक्तियों को जोड़कर ऐसा करूंगा:

 has_many :graphs, :foreign_key=>:sender_id has_many :inverted_graphs, :class_name => 'Graph', :foreign_key=>:recipient_id

प्रत्येक उपयोगकर्ता के कई प्रत्यक्ष लिंक होते हैं (जहां वह लिंक का आरंभकर्ता होता है), और रिवर्स, जहां वह सामाजिक लिंक के लिए अनुरोध का प्राप्तकर्ता होता है। ये तत्व केवल विभिन्न विदेशी कुंजियों में भिन्न होते हैं।

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

 def accepted_chiefs_from_job chiefs = graphs.accepted.where(:context => :job, :recipient_role=>:chief) # my graphs _chiefs = inverted_graphs.accepted.where(:context => :job, :sender_role=>:chief) # foreign graphs chiefs | _chiefs end

संचालक | संयोजन सरणियों का एक ऑपरेटर है। मेरे लिए, यह बहुत सुंदर है।

मेटा प्रोग्रामिंग और रूबी जादू का एक सा

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

हम मेटा-प्रोग्रामिंग का उपयोग करते हैं ताकि रूबी खुद हमारे लिए आवश्यक तरीके बनाये और उचित चयन करे। मैजिक मेथड मेथड_मिसिंग (method_name, * args) इसमें मदद करेगा। इस विधि को तब कहा जाता है जब रूबी को कोई विधि नहीं मिलती है। यहां हम उसे समझाएंगे कि यदि उसे ग्राफ से डेटा चुनने की कोशिश पूरी करनी हो तो उसे क्या करना चाहिए।

रूबी इस तरह बनाएंगे तरीके:

 user.accepted_friends_from_live user.rejected_friends_from_live user.deleted_friends_from_live user.deleted_chiefs_from_job user.accepted_chiefs_from_job user.rejected_chiefs_from_job user.accepted_teachers_from_school user.deleted_teachers_from_school

उपयोगकर्ता मॉडल में निम्नलिखित जोड़ें:

 def method_missing(method_name, *args) if /^(.*)_(.*)_from_(.*)$/.match(method_name.to_s) match = $~ state = match[1].to_sym role = match[2].singularize.to_sym context = match[3].to_sym graphs.send(state).where(:context => context, :recipient_role=>role) | inverted_graphs.send(state).where(:context => context, :sender_role=>role) else super end end

यदि method_missing (method_name, * args) को कोई विधि नहीं मिलती है, तो वह इसे नियमित रूप से पार्स करने का प्रयास करेगा। यदि नियमितता हमारे ग्राफ के तरीकों के नाम पर फिट बैठती है, तो कटौती स्वयं लाइन से प्राप्त आंकड़ों के आधार पर एक अनुरोध संकलित करेगी और परिणाम लौटाएगी। यदि बुलाया विधि नियमित अनुसूची में फिट नहीं होती है, तो method_missing (method_name, * args) बस अपने मानक व्यवहार - सुपर पर चला जाएगा, और संभवतः एक कोड निष्पादन त्रुटि देगा।

उपयोगकर्ता सारांश कोड:

 class User < ActiveRecord::Base has_many :pages has_many :graphs, :foreign_key=>:sender_id has_many :inverted_graphs, :class_name => 'Graph', :foreign_key=>:recipient_id def method_missing(method_name, *args) if /^(.*)_(.*)_from_(.*)$/.match(method_name.to_s) match = $~ state = match[1].to_sym role = match[2].singularize.to_sym context = match[3].to_sym graphs.send(state).where(:context => context, :recipient_role=>role) | inverted_graphs.send(state).where(:context => context, :sender_role=>role) else super end end def graph_to(another_user, opts={:context=>:live, :me_as=>:friend, :him_as=>:friend}) Graph.where(:context=>opts[:context], :sender_id=>self.id, :sender_role=>opts[:me_as], :recipient_id=>another_user, :recipient_role=>[:him_as]).first || graphs.new( :context=>opts[:context], :sender_role=>opts[:me_as], :recipient_id=>another_user.id, :recipient_role=>opts[:him_as]) end end

खैर यह सब है

अब रेक करें:

 rake db:graphs:create

रेल कंसोल चलाएं

 rails c

हम प्रदर्शन करने की कोशिश करते हैं:

 u = User.find(10) u.graph_to(User.first, :context=>:job, :me_as=>:boss, :him_as=>:staff_member) u.graph_to(User.last, :context=>:school, :me_as=>:student, :him_as=>:teacher) u.graph_to(User.find(20), :context=>:school, :me_as=>:student, :him_as=>:school) u.accepted_friends_from_live u.rejected_friends_from_live u.deleted_friends_from_live u.deleted_chiefs_from_job u.accepted_chiefs_from_job u.rejected_chiefs_from_job

पुनश्च:

एप्लाइड प्रोग्रामर सम्मान और स्कूल शिक्षक से शुभकामनाएँ!

सामाजिक ग्राफ के कार्यान्वयन पर विचार

सामाजिक नेटवर्क पर प्रदर्शित होने की तुलना में दुनिया अधिक जटिल है

आदर्श

उल्टे ग्राफ तत्व

मेटा प्रोग्रामिंग और रूबी जादू का एक सा

खैर यह सब है

More articles: