ფიშინგის მსხვერპლი საიტები Caucasus Online-ის ჰოსტინგზე

დღეს კომპიუტერულ ინციდენტებზე სწრაფი რეაგირების ჯგუფმა თავის ფეისბუქ-გვერდზე გამოაქვეყნა რამდენიმე ქართული ვებსაიტის შესახებ ინფორმაცია, რომლებზეც მიმდინარეობს paypal-ის ფიშინგი. მათ შორის მოხვდა ჩვენი სტუდიის ერთ-ერთი ნამუშევარი - ახალი ნათების ვებსაიტი.

ჩვენ შევისწავლეთ სიტუაცია და თავს ვალდებულად ვთვლით განვაცხადოთ, რომ გატეხილია არა კონკრეტული საიტები, არამედ Caucasus Online-ის ჰოსტინგის სერვერი, რომლებზეც ეს საიტებია განთავსებული. შესაბამისად, ამ ჰოსტინგზე განთავსებულ ნებისმიერ დომენზე ამ მისამართის დამატებით, მოხვდებით ხსენებულ ფიშინგ-გვერდზე:

/~wscgroup/includes/65ebe9f5328f4a2dabe9f830d76df7f2/protect.html

მოვუწოდებთ CERT.GOV.GE-ს სასწრაფოდ გაავრცელოს ეს ინფორმაცია თავისი არხებით და შეატყობინოს არსებული სიტუაცია Caucasus Online-ს. ეს კი იმ დომენების არასრული ჩამონათვალი, რომელიც ხსენებულ სერვერზეა განთავსებული და, შესაბამისად, ყველა მათგანზე მიმდინარეობს paypal-ის ფიშინგი:

Read More

ჰეშტეგი Facebook-ზე

სხვადასხვა საინფორმაციო საშაუალებებით ვრცელდება ინფომაცია, რომ Facebook-ზე შეიძლება ჰეშტეგის ფუნქცია დაემატოს. 

ჰეშტეგი ეს არის დატაგული სიტყვა, რომელსაც წინ უძღვის სიმბოლო # - რის შემდეგადაც სიტყვა იქცევა აქტიურ ლინკად და შესაძლებელს ხდის მოძებნოს ამ ჰეშტეგის ქვეშ დატაგული სხვა პოსტები მთელი სოციალური ქსელის მასშტაბით. ჰეშტეგი მიკრო ბლოგინგის საიტის twitter-ის დამახასიათებელი ნაწილია. თუ თქვენ ეძებთ ინფორმაციას Twitter-ზე, ჰეშტეგი ამ პორცესს ძალიან ამარტივებს. თქვენთვის სასურველი სიტყვა შეიძლება გლობალურად მოიძებნოს და სასურველი ინფორმაცია, ლინკი თუ ფოტო რამდემე წამში გამოჩნდება თქვენს ეკრანებზე. 

ეს ინფორმაცია, თუ ის გამართლდა, იმაზე მიანიშნებს, რომ Facebook-ი საბოლოოდ აპირებს ჩაყლაპოს სხვა სოციალური ქსელები და მომხმარებელს ყველაფერი ერთ სივრცეში შესთავაზოს. 

სხვადასხვა მომხმარებლების აზრით, ჰეშტეგის დამატება Facebook-ზე ცუდი იქნება, რადგან ვირტუალური გარემოს დაბინძურებას გამოიწვევს. თუმცა, მეორეს მხრივ, უნდა აღინიშნოს, რომ ჰეშტეგის დამატება სოციალურ ქსელში მიმდინარე დისკუსიებს კიდე უფრო ფართო არეალს მისცემს და კიდევ უფრო გაასაჯაროვებს, სწორედ ისე, როგორც ტვიტერზეა. თუმცა, აქვე არსებობს სპამის და ქსელში მომრავლებული “პრიკოლების გვერდების” მიერ სხვადასხვა იდიოტური კონტენტის გავრცელების საშიშროებაც. 

Facebook-ის ახალი სახე

7 მარტს, Facebook-ის გუნდმა “ნიუს ფიდის” ახალი დიზაინი წარმოადგინა.

“ნიუს ფიდი” რამდენჯერმე შეიცვალა, რასაც FB-ს მომხმარებელთა დიდი უკმაყოფილება მოჰყვებოდა ხოლმე, მაგრამ აჟიოტაჟი ერთ კვირაზე მეტი არასოდეს გაგრძელებულა. გარკვეული დროის შემდეგ კი ძველი “ნიუს ფიდი” როგორი იყო აღარავის ახსოვს. რედიზაინის შემდეგ სავარაუდოდ კიდევ ატყდება ერთი ამბავი, მაგრამ ტრადიციულად ყველა ძალიან მალე შეეგუება. 

მარკ ცუკერბერგის (რომელის გვარიც ინგლისურად სინამდვილეში ზაკერბერგია) განცხადებით, “ეს იქნება მაქსიმალურად პერსონიზირებული გაზეთი (Newspaper)”

ახალ ნიუსფიდში უფრო მეტი ადგილი დაეთმობა ფოტოებს. Facebook-ის მთავარი დიზაინერის ჯული ჟუოს თქმით, “ნიუსფიდის” ვიზუალიზაცია და ფოტოების წინ წამოწევა მომხმარებლებისთვის უფრო სახალისო და საინტერესო გარემოს შექმნის. 

ახალი “ნიუს ფიდი” ასე გამოიყურება, როგორც ხედავთ მართვის პანელის დიზაინი და ლოკაციაც მთლიანად შეცვლილია. ასეთ დიზაინს Facebook-ი უკვე დიდი ხანია იყენებს მობილურ აპლიკაციებში. რედიზაინის მიზანი ის არის რომ მობილურზე, ტაბლეტზე და დესკტოპზე Facebook-ი ერთნაირად გამოიყურებოდეს. 

ახალი განლაგება ძალიან წააგავს გუგლის სოციალურ ქსელს “Google+”

იმ მომხმარებლებს, რომლებსაც უკვე ჩაერთოთ, ახალი “ნიუს ფიდი” ძალიან მოსწონთ. თუმცა, საუბრობენ ნაკლზე, რომელიც სხვადასხვა “პრიკოლის გვერდებისა” და sponsord story-ების იგივე ფორმატში გამოჩენას ეხება. “ნიუს ფიდის” დანაგვიანების დიდი საშიშროება აქვთ იმ ადამიანებს, რომლებსაც ბევრი “ფრენდები” ჰყავთ - სავარაუდოდ ახალი “ნიუს ფიდი” გამოიწვევს “ფრენდლისტების” მასობრივ წმენდას

როგორც ყოველთვის სიახლეებს ტექნიკური პრობლემებიც ახლავს თან. თუ ახალ “ნიუს ფიდიან” მომხმარებლებს დავუჯერებთ, დამალვის ანუ Hide-ის ფუნქცია არ მუშაობს. როდესაც თქვენ არასასურველ კონტენტს დააჰაიდებთ, ის “რეფრეშის” შემდეგ კვლავ გამოჩნდება თქვენს კედელზე. ეს შეიძლება ტექნიკური გაუმართავობაა, რომელიც მალე გამოსწორდება ან ასეა ჩაფიქრებული, რაც დამეთანხმებით და საკმაოდ არაკომფორტული იქნება. 

მომხმარებლები ჩივიან ფოტოების მოჭრის სტილზეც.

და თუ გავითვალისწინებთ Facebook-ის მიზანს, გაამდიდრონ ჩვენი “ნიუს ფიდები” ვიზუალურად, მაშინ მომხმარებელთა ეს შენიშვნაც სამართლიანად უნდა ჩაითვალოს. 

ახალი “ნიუს ფიდი” მალე გაეშვება, რიგში ჩასადგომად კი აქ უნდა დარეგისტრირდეთ: https://www.facebook.com/about/newsfeed

ელფოსტის მახინჯი მისამართები

ბევრჯერ უკითხავთ ხოლმე ჩემთვის ნაცნობებს, ზოგს ასეთი უცნაური ელფოსტა რატომ აქვსო? ალბათ თქვენც შეგინიშნავთ, რომ ხშირად სხვადასხვა ფორუმებზე, ბლოგებში ან სხვა საიტებზე ხალხი საკუთარი ელფოსტის მისამართს „დამახინჯებულად“ წერს ხოლმე. მაგალითად, ასე: my[@]email.comან ასე: my_აქქეიცითრაც_email.com

თუ არ იცით გეტყვით, რომ ამის მიზეზი მარტივია — მათ არ სურთ საკუთარი ელფოსტის მისამართები სპამერებს ჩაუვარდეთ ხელში. სპამერებს, ანუ იმ ხალხს, ვინც არასასურველ, სარეკლამო წერილებს აგზავნიან ჩვენ ინბოქსებში. სპამერები კი, როგორც წესი, ელფოსტის მისამართებს ავტომატურად აგროვებენ.

არსებობს სპეციალური პროგრამები, ე.წ. „ბოტები“, რომლებიც დაბოდიალობენ სხვადასხვა საიტებზე, მიყვებიან ბმულიდან ბმულს და სადაც კი ელფოსტას წააწყდებიან, თავიანთ ბაზაში ინახავენ. სპამერი კი, გაუშვებს ხოლმე მსგავს ბოტს და რამდენიმე საათში ელფოსტის ასეულობით მისამართს იგდებს ხელში; რომელთა პატრონებსაც მოგვიანებით ან პენისის გადიდებას შესთავაზებენ, ან შვეიცარულ საათებს 20 დოლარად :)

ის მომხმარებლები კი, ვინც ასე ამახინჯებენ საკუთარ მისამართებს, სწორედ ამ სპამ-ბოტებისგან იცავენ თავს. პროგრამა ხომ ადამიანი არ არის, წინასწარ განსაზღვრული პრინციპით მოქმედებს. ეძებს ტექსტს, რომელიც მის კონკრეტულ შაბლონს ემთხვევა, მაგალითად ასეთს:
[a-z0-9]+[@]+[a-z0-9]+[.]+[a-z]
ანუ, ისინი ეძებენ ტექსტის ნაგლეჯს, სადაც მიყოლებით შეხვდებათ ლათინური ანბანის ასოები ან ციფრები (ანუ, სახელი), შემდეგ @ ნიშანი, შემდეგ — ისევ ლათინური ანბანის ასოები ან ციფრები (ანუ, დომენი) და ბოლოს წერტილი და დომენის ზონა (.ge, .com…) მაშინ კი, როდესაც ელფოსტის მისამართში სხვა სიმბოლოები ერევა, ეს ბოტები ვეღარ ცნობენ მას და გვერდს უვლიან. ადამიანი კი, ვისაც მიწერეს ეს მისამართი, (როგორც წესი) მოაზროვნე არსებაა და ხვდება ჩანაფიქრს :)

თუმცა, ყველა ვერ ხვდება ხოლმე. და ეს პირველ რიგში გამოუცდელ ინტერნეტ-მომხმარებლებს ეხებათ. სწორედ ამიტომ, მე პირადად პატივს არ ვცემ კომპანიას, რომელიც საკუთარ საიტზე მასთან დასაკავშირებელ მისამართს ასეთი დამახინჯებული ფორმით აქვეყნებს :) ან კიდევ, უფრო უარესი — სურათად აქვს ჩასმული ელფოსტის მისამართი.

პირველი მეთოდის (ანუ, დამახინჯებულად დაწერის) მინუსი იმაში მდგომარეობს, რომ ძალიან ბევრი მომხმარებელი უბრალოდ ვერ ხვდება რა ჩაიფიქრა ტექსტის ავტორმა და ცდილობს წერილი დამახინჯებულ მისამართზე გააგზავნოს ხოლმე. აბა დაფიქრდით, რამდენი დამწყები მიხვდება, რომcontact[@]company.ge-დან კვადრატული ფრჩხილები უნდა მოაცილოს?

მეორე, საკმაოდ გავრცელებული მეთოდის (ელფოსტის მისამართის სურათად ჩასმის) მთავარი უარყოფითი კი ის არის, რომ ასეთი ელფოსტის დაკოპირება უბრალოდ შეუძლებელია. და მომხმარებელს მისი ჯერ დამახსოვრება, შემდეგ კი ხელით აკრეფა მოუწევს წერილის გაგზავნისას. და ასეთ დროს ამ სურათზეmailto: ბმულის მიბმა გამოსავალი არ არის, რადგან ჯერ ერთი, ვებმეილის ეპოქაში ვცხოვრობთ და უმრავლესობა დესკტოპ-კლიენტებს აღარ ხმარობს ელფოსტისთვის; და მეორეც — თუ mailto:-ს შემდეგ ღიად დაწერთ მისამართს, მაშინ რაღა აზრი აქვს ამ ბმულის სურათზე მიმაგრებას? :)

ბევრი რომ არ გავაგრძელო, ამ პრობლემის მრავალი დელიკატური გადაწყვეტა მოიფიქრეს მსოფლიოს დეველოპერებმა. ჩემი ფავორიტი კი დამახინჯებული ელფოსტის მისამართის დინამიურად გასწორების პრინციპია. აი მისი ერთ-ერთი ყველაზე მოხერხებული რეალიზაცია jQuery-ს ბაზაზე:

კოდი

პრინციპი მდგომარეობს შემდეგში:
საიტის რედაქტორი ნებისმიერ ადგილზე, სადაც სურს ელფოსტის მისამართის დაწერა, წერს მისამართს დამახინჯებულად, ასეთი ფორმით: contact*company.ge, ოღონდ შემდეგ ამ ტექსტს აფორმატირებს გადახაზულად, ანუ ათავსებს <del>ტეგში. კოდის ეს ნაგლეჯი კი, მომხმარებელთან გვერდის ჩატვირთვისას, ნახულობს ყველა <del> ტეგის შიგთავსს და თუ სადმე შეხვდება ასტერიკი (*), ანაცვლებს მას ეთ-ნიშნით (@).

<del> ტეგი არჩეული გვაქვს იმ მიზეზის გამო, რომ მისი გამოყენება საიტის ტიპიური რედაქტორისგან, ვისაც როგორც წესი, html-ის არაფერი გაეგება, მოითხოვს მინიმალურ ძალისხმევას — გადახაზული ტექსტის სტილი ხომ ნებისმიერ WYSIWYG რედაქტორს აქვს, სქელი, დახრილი და ხაზგასმული სტილების გვერდით. თანაც, ეს ყველაზე იშვიათად გამოყენებადი ტეგია.
სხვა შემთხვევებში, ბუნებრივია, უფრო მოქნილი გადაწყვეტაც შეიძლება გამოიყენოთ, მაგალითად, დამახინჯებული ელფოსტის შემცველი ტეგის კლასის მიხედვით მოძებნა ან სხვა ვარიაციები ამ თემაზე…

დავუბრუნდეთ ამ პატარა კოდს:
გარდა იმისა, რომ იგი ასწორებს დამახინჯებებს <del> ტეგში, იგი ასევე ეძებს ბმულის ტეგებსაც, <del>-ის შვილებში ან მის მშობლად და ასწორებს ამ ბმულების href ატრიბუტების მნიშვნელობებსაც. (ეს იმ შემთხვევისთვის, თუ რედაქტორმა მაინც გადაწყვიტა ელფოსტის მისამართისთვის mailto: ბმულის მიბმა).
შეცვლილ <del> ტეგს კი იქვე უყენდება სტლის text-decoration პარამეტრიnone-ზე, რათა თუ გარე CSS-ში არ არის გათვალისწინებული, ჩვენი ელფოსტა გადახაზული არ დარჩეს.
(გთხოვთ შეუქოთ jQuery-ს მოქნილობა :D)

ესეც ასე. სადაც კი საიტის რედაქტორს დაჭირდება ელფოსტის მითითება, იგი დაწერს მას ასტერიკით „ეთ“-ის მაგივრად და მოათავსებს <del> ტეგში (თუ უნდა, mailto:-საც კი მიუთითებს, აქაც ასტერიკით);
მომხმარებელი ბედნიერი იქნება — ელფოსტას სწორად წაიკითხავს, დააკოპირებს, ამობეჭდავს და კედელზე გაიკრავს;
სპამ-ბოტი კი უბედური — ისინი ხომ JavaScript-ს არ ამუშავებენ და, შესაბამისად, ასტერიკიანი ტექსტი შერჩებათ ხელში :)

P.S. შეიძლება იფიქროთ, რომ ზედმეტი თავის ტკივილია, მაგრამ ყოველთვის გახსოვდეთ, რომ ყველა მომხმარებელი დეველოპერი არ არის და მათთვის ცხოვრების გაადვილება სწორედ ჩვენი — დეველოპერების მოვალეობაა :)
კარგ საიტს კი სწორედ ასეთი დეტალების ერთობლიობა ქმნის, რომელიც ჩვენასე ძალიან გვიყვარს. :)

P.P.S. რათქმაუნდა, მთელი ეს ქიმია საჭირო არ არის, თუ კომპანიას ძლიერი სპამ-ფილტრი აქვს დაყენებული და სპამის უბრალოდ არ ეშინია. :)

გრავატარი — ჩემ გვერდით ჩემი ავატარია

სიახლე აღარავისთვისაა, რომ ინტერნეტი სულ უფრო და უფრო „სოციალური“ ხდება. ყველა საიტზეა კომენტარის ფორმა, დარეგისტრირების საშუალება, საკუთარი აზრის გამოთქმის ფუნქცია. მომხმარებლის მიერ გენერირებული კონტენტი ნებისმიერი ვებსაიტისთვის მიმზიდველია — იგი უფასოა, განსხვავებული, უნიკალური და საიტის მომხმარებლებს დადებითად განაწყობს ხოლმე. „ისინი მე აზრს მეკითხებიან, ჩემი აზრიც მნიშვნელოვანია“ — ფიქრობს მომხმარებელი და მზადაა თავისი პატარა წვლილი შეიტანოს დიდი საიტის კონტენტში. :)

ამავე დროს, მას უნდა, რომ სხვადასხვა ბლოგზე, საიტზე, ფორუმზე დაგროვილი კომენტარებით იგი ხალხმა გაიცნოს და დაიმახსოვროს. ამიტომ, როგორც წესი, ირჩევენ ხოლმე რაიმე ზედმეტსახელს და ყველგან ამ სახელით ტოვებენ თავიანთ კვალს. ხოლო სადაც საშუალება აქვთ — აუცილებლად ავატარსაც იყენებენ, რაიმე ვიზუალური სიმბოლო ან თუნდაც ფოტო ხომ უფრო ადვილად დასამახსოვრებელია, ვიდრე უბრალოდ სახელი.

და სწორედ აქ დგება პრობლემა — რა ვქნათ მაშინ, როდესაც გვსურს, რომ მომხმარებელს ავატარის ქონის სიამოვნებაც არ წავართვათ და არც რეგისტრაციით გავურთულოთ ცხოვრება? რათქმაუნდა, ეს მაშინ, როცა საუბარია ბლოგზე, უბრალო კომენტარებზე სტატიის ქვეშ, კომპანიის სტუმართა წიგნზე ან მსგავს საიტებზე, სადაც მომხმარებლის დარეგისტრირება ზედმეტი თავისტკივილი იქნება. სადაც მომხმარებელი შეიძლება შემთხვევით მოხვდა საძიებო სისტემიდან და უცბად სურს კომენტარის დაწერა, წინასწარი პროცედურების გავლის გარეშე. მარტივად და სწრაფად… სწორედ ამისთვის არსებობს გრავატარების სერვისი. :)

რა არის გრავატარი?

გრავატარი, ანუ Gravatar იშიფრება, როგორც Globally recognized avatar. სერვისის იდეა ძალიან მარტივია — შედიხარ საიტზე gravatar.com, ერთხელ რეგისტრირდები, ტვირთავ შენ ავატარს და შემდეგ, ყველა საიტზე, რომელსაც აქვს გრავატარის მხარდაჭერა, კომენტარის დაწერისას იგი ავტომატურად გამოჩნდება.

როგორ? ძალიან მარტივად. პრინციპი შემდეგშია: გრავატარზე რეგისტრაციისას უთითებ შენი ელფოსტის მისამართს. ავატარის ატვირთვისას კი, სისტემა ახდენს ამ ელფოსტის მისამართის ასოცირებას შენ ავატართან. ამის შემდეგ კი, ნებისმიერ საიტს, შენი კომენტარის გამოტანისას, შეუძლია გაუგზავნოს მოთხოვნა გრავატარების სერვისს და „გამოართვას“ შენი ავატარი, ელფოსტის მისამართის მიხედვით. და რადგანაც შენი ავატარი ერთ ადგილზე ინახება, ნებისმიერ დროს შეგიძლია ახალი დაიყენო და ისიც, ყველა საიტზე, სადაც ოდესმე გაგიკეთებია კომენტარი, ავტომატურად განახლდება.

იდეა მარტივი და გენიალურია :) ელფოსტის მისამართი ხომ ის ერთადერთი რამეა, რასაც ყველაზე იშვიათად იცვლი და რაც უნიკალურია. სხვადასხვა საიტზე კომენტარების დაწერსას შეიძლება სხვადასხვა დროს სხვადასხვანაირად დაწერო შენი ნიკი, ასო მოაკლო, დაუმატო, ან საერთოდ სხვა სახელი მოგინდეს… ელფოსტის მისამართს კი ყველგან ერთნაირს წერ, ნუ, ძირითად შემთხვევებში. თანაც, ერთნაირი ზედმეტსახელი შეიძლება მსოფლიოს მასშტაბით რამოდენიმე მომხმარებელს ქონდეს. ელფოსტის მისამართი კი — ყველასთვის უნიკალურია.

ასერომ, ელფოსტა ერთადერთი ელემენტია, რომელიც თითქმის ყოველთვის ერთნაირია და რომლით მომხმარებლის იდენტიფიცირებაც ყველაზე უტყუარია მსოფლიო აბლაბუდაში.

ცოტა ისტორია

ზევით აღწერილი პრინციპის საქმეში გამოყენების იდეა პირველად კალიფორნიელ ვებდეველოპერ ტომ ვერნერს დაებადა. სწორედ იგია გრავატარის სერვისის გამომგონებელი და მისი შემქმნელი.

სერვისის პირველ ვერსიაზე მუშაობა ტომმა 2005 წელს დაიწყო. იგი მალე აიტაცა რამოდენიმე საიტმა და ბევრმა მომხმარებელმა. პოპულარობის ზრდასთან ერთად, იზრდებოდა რესურსებიც, რომელიც სერვერს ამ სერვისის შენახვისთვის ჭირდებოდა. ამიტომ, გამომგონებელმა გრავატარის მეორე ვერსიაზე დაიწყო მუშაობა და 2007 წლის თებერვალში მისი ბეტა ვერსია გაუშვა.

ახალ ვერსიაში ბევრად იყო გაუმჯობესებული კოდი, ავატარების შენახვის სისტემა და რესურსების დაბალანსება. ცვლილებები მომხმარებლის მხარესაც მოხდა — ახლა უკვე ატვირთული ფოტოს მოჭრა ან ინტერნეტში არსებული ფაილის მიმაგრებაც იყო შესაძლებელი. მომხმარებელს უკვე შეეძლო საკუთარ ანგარიშზე ორი სხვადასხვა ავატარი მიემაგრებინა და მარტივად გადართულიყო სასურველზე. ასევე დაემატა ფასიანი „პრემიუმ“ სერვისი, სადაც განუსაზღვრელი რაოდენობის ელფოსტების და ავატარების მიბმა შეიძლებოდა ერთ ანგარიშზე.

სიახლეებმა კიდევ უფრო მეტი მომხმარებელი მიიზიდა და მეორე ვერსიის გაშვებიდან 3 თვეში სერვისს 32 ათასი ახალი მომხმარებელი შეემატა!

როგორც მოსალოდნელი იყო, გრავატარებით კომპანია Automatticდაინტერესდა და 2007 წლის ოქტომბერში მან ტომ ვერნერისგან ეს სერვისი შეიძინა. ვინც არ იცით, სწორედ ეს კომპანიაა WordPress-ის შემქმნელი და მფლობელი. შეძენის შემდეგ, აუტომატიკმა ბევრად გააუმჯობესა გრავატარების წარმადობა და ყველა ფასიანი სერვისი მომხმარებლებს უფასოდ შესთავაზა.

ამ გარიგებამ უზარმაზარი როლი ითამაშა გრავატარების პოპულარიზაციაში. აუტომატიკს, როგორც ვორდპრესის მფლობელს და მსოფლიო ბლოგინგის ტრენდ-მეიკერს, არ გაჭირვებია ამ სისტემის თითქმის სტანდარტად გადაქცევა. მან მალევე მიაბა გრავატარები Wordpress.com-ის ბლოგ-ჰოსტინგ სერვისს და 2.5 ვერსიიდან მოყოლებული გრავატარების პლაგინი უკვე ნაგულისხმევად მოყვება ვორდპრესის ძრავს.

გრავატარები საკუთარ საიტზე

გრავატარების სისტემის იმპლემენტაცია საკუთარ საიტზე უმარტივესი ამოცანაა. ისეთი პოპულარული ძრავებისთვის, როგორიცაა Drupal, Expression Engine, IP.Board, Joomla და სხვები, უკვე არსებობს პლაგინები. თუ თქვენ რომელიმე სხვა ძრავს იყენებთ, მაშინ აუცილებლად იარსებებს მისთვისაც რაიმე პლაგინი ან მოდიფიკაცია. დაძებნეთ მწარმოებლის საიტზე ან გუგლში.

ხოლო თუ საკუთარი ძრავი გვაქვს ან ისეთი ძრავი, რომლისთვისაც ჯერ არ შეუქმნიათ გრავატარების პლაგინი, კოდში ჩარევა მოგვიწევს. მაგრამ, მინიმალურად. :)

გრავატარების საიტზე ჩასასმელად გვჭირდება მხოლოდ კონკრეტული მომხმარებლის გრავატარის მისამართის გაგება. გრავატარის საწყისი მისამართი კი აი ასეთია:

http://www.gravatar.com/avatar/940bbfd7e1ab7c6907222ebc30d6c205

ამ მისამართზე შესვლით დაინახავთ ჩემ ავატარს, რომელიც მიბმულია მისამართზე rocko@omedia.ge :) როგორ შედგა ეს მისამართი? აი ასე:

echo "http://www.gravatar.com/avatar/" . md5( strtolower( "rocko@omedia.ge" ) );

როგორც ვხედავთ, მისამართის პირველ ნაწილს, http://www.gravatar.com/avatar/უნდა დავუმატოთ სასურველი მომხმარებლის ელფოსტის MD5 ჰეში. ამ შემთხვევაში, ელფოსტის ჰეშირებამდე მისი ყველა სიმბოლო ქვედა რეგისტრში ჩამომყავს, რადგან rocko@omedia.ge და roCKo@Omedia.Ge სხვადასხვა ჰეშს დამიბრუნებს. გრავატარებში კი ქვედა რეგისტრის ელფოსტის ჰეში ინახება.

ეს არის ის მინიმალური, რაც საჭიროა მომხმარებლის გრავატარის მისამართის გასაგებად მისი ელფოსტის მიხედვით. თუმცა, ამ მისამართში დამატებითი პარამეტრების გადაცემაც შეიძლება. მაგალითად, ზომის. ნაგულისხმევად, ამ მისამართით მიღებული გრავატარი იქნება 80x80 პიქსელზე ზომის (ყველა გრავატარი კვადრატულია). მაგრამ თუ გვინდა სხვა ზომაზე გამოტანა, შეგვიძლია მისამართს დავუმატოთ კიდევ ერთი პარამეტრი s= და გადავცეთ სასურველი ზომა პიქსელებში (მაქსიმუმ 512px):

http://www.gravatar.com/avatar/940bbfd7e1ab7c6907222ebc30d6c205?s=120

ეს მისამართი გამოიტანს გრავატარს ჩემი ელფოსტისთვის 120x120 პიქსელზე ზომით. ასევე, შეგვიძლია გადავცეთ იმ სურათის მისამართი, d= რომელიც ნაგულისხმევად უნდა გამოვიდეს იმ შემთხვევაში, თუ მომხმარებელი გრავატარების სერვისში დარეგისტრირებული არ არის და, შესაბამისად, არც ავატარი აქვს:

http://www.gravatar.com/avatar/50cfe8f4e170708ad6516b3fa1f3fc05?d=http%3A%2F%2Fomedia.ge%2Fimages%2Fdefault_avatar.png

ეს მისამართიც ავტომატურად გადამისამართდება d ცვლადში გადაცემულ სურათზე. სულ ეს იყო. დამატებითი ინფორმაციისთვის, პარამეტრებისთვის და მაგალითებისთვის იხილეთ ოფიციალური დოკუმენტაცია.

ასერომ, თქვენ საიტს უკვე აქვს გრავატარების მხარდაჭერა. :) ახლა ისღა დაგრჩენიათ, გაავრცელოთ გრავატარები თქვენ მომხმარებლებშიც, გააცნოთ ეს სერვისი, აუხსნათ მისი მუშაობის პრინციპი და მისცეთ მათ ერთმანეთის იდენტიფიცირების მარტივი საშუალება. ;)

განუსაზღვრელი სიგანის CSS მენიუს ცენტრირება

მენიუს შექმნა CSS-ის გამოყენებით, ზოგადად სირთულეს არ წარმოადგენს. ვისაც პირველი რამოდენიმე თავი მაინც წაუკითხავს ნებისმიერი საშუალო სირთულის წიგნში მარკაპზე, მათთვის, მენიუს გაკეთება ჩვეულებრივი, ტრივიალური ამოცანაა. ამიტომ, ჩემი აზრით ამ თემისადმი პოსტის მიძღვნას დიდი აზრი არ ექნებოდა.

ალბათ პოსტს არც დავწერდი, რომ არა შედარებით არასტრანდარტული ამოცანა, რომლის გადაწყვეტაც ბოლოს მომიხდა.

ჩვენმა ძვირფასმა :D დიზაინერმა დახატა ლეიაუთი, რომელშიც გათვალისწინებული იყო ჩვეულებრივი ჰორიზონტული მენიუ (როგორიც ხშირად გვიკეთებია), ოღონდ (!) ცენტრირებული. მე თვითონაც გამიკვირდა, რომ აქამდე მსგავსი შემთხვევა არასოდეს მქონია. გარკვეულ გარემოებათა გამო, მომიწია ცოტათი მეტი ფიქრი და გუგლში სეირნობა, რომ ჩვენი დიზაინერის „პრეტენზიები“ დაკმაყოფილებულიყო :D.

ახლა, რაც შეეხება საკითხს და პრობლემას :).

ზოგადად, არც ბლოკური ობიექტის ცენტრირება წარმოადგენს რაიმე სირთულეს. ცნობილია, რომ თუკი ბლოკურ ობიექტს CSS-ით განვუსაზღვრავთ margin: 0 auto; მაშინ ეს ობიექტი პოზიცირდება ჰორიზონტულად ცენტრში მისი მშობლის მიმართ. ეს ფაქტი ეფუძნება CSS2-ის წესს, რომ ობიექტისთვის, რომელსაც განსაზღვრული აქვს მარცხნივ და მარჯვნივ საზღვარი auto მნიშნელობით (margin-left: auto; margin-right: auto;) — ავტომატურად დაითვლება ტოლი სიდიდის მნიშვნელობები. აი ეს არის „ფილოსოფია“ ბლოკური ობიექტის ცენტრირებისა :) მოთხოვნა ამ შემთხვევაში არის ერთადერთი, მაგრამ პრინციპული(!); ობიექტის სიგანე უნდა იყოს წინასწარ განსაზღვრული!

ზუსტად აქ “წამოვკარი ფეხი” :D.
ე.ი. მე მჭირდება მენიუ, რომელიც იქნება ცენტრირებული და არ ექნება ზუსტად განსაზღვრული სიგანე, რათა შესაძლებელი იყოს მისი დინამიური მართვა CMS-იდან. პრობლემაც აქ არის — ცენტრირების სტანდარტული მეთოდით აქ ფონს ვერ გავალთ, იმიტომ რომ სიგანე არ ვიცით და შესაბამისად არაფერიც არ დაიცენტრება.

ფაქტია, რომ ამ შემთხვევაში გვჭირდება სხვა მიდგომა, რომელიც ობიექტის ცენტრირებისთვის არ გულისხმობს მისი სიგანის ზუსტად განსაზვრას.

ზემოთხსენებულ გუგლში სეირნობის შემდეგ, ვიპოვე ამ ყველაფრის მარტივიCSS გადაწყვეტა. ასევე ცნობილი, როგორც „Shrink Wrap“ მეთოდი. Shrink Wrapping-ის იდეა მარტივია და მდგომარეობს შემდეგში: ბლოკურ ობიექტს უნდა მივუდგეთ როგორც ცხრილს.
შესაბამისად, კონტეინერს, რომელშიც გვაქვს მენიუს ელემენტები, საჭიროა განვუსაზღვროთ display: table; ხოლო ელემენტებს — display: table-cell;

კოდი

ვაშა! :D
ამის შემდეგ ჩვენი განუსაზღვრელი სიგანის მენიუ ცენტრში ექცევა :)

ახლა, რა თქმა უნდა პრობლემა გვაქვს ბრაუზერად წოდებულ IE-სთან. აბა სხვანაირად როგორ იქნება :D ცნობილია, რომ IE-ს არ აქვს display: table;მნიშვნელობის მხარდაჭერა მე-7 ვერსიის ჩათვლითაც კი :) ამ პრობლემის მოსაგვარებლად საჭიროა, რომ კონტეინერს განვუსაზღვროთ text-align: center; ხოლო მენიუს აითემს მივუდგეთ, როგორც inline ელემენტს.

კოდი

ამ უკანასკნელს გავაფორმებთ IE conditional comment-ში <!--[if IE]>....<![endif]--> და საბოლოოდ, რომ შევაჯამოთ მივიღებთ დაახლოებით ასეთ რამეს:

კოდი

კოდი

ყველაფერი ნათელია - გვაქვს ტრადიციული <ul> </ul> კონტეინერი და <li> </li> მენიუს ელემენტები. მათზე კი მოქმედებს შესაბამისი სტილები რაზეც ზემოთ იყო საუბარი. დანარჩენი კი უკვე თქვენი გემოვნების, ხასიათის და კონკრეტული ამოცანის ამბავია :).

ტეგების ღრუბლის გენერაცია

„ტეგების ღრუბელი“ ვებსაიტებზე სტატისტიკური მონაცემების ვიზუალიზაციის ერთ-ერთი ყველაზე გავრცელებული საშუალებაა. იგი ცნობილ ანარეკლებთან და წყვეტილ ხაზგასმებთან ერთად, ყბადაღებული Web 2.0-ის ცნობადი ტრენდია. იდეა მარტივია და შემდეგში მდგომარეობს: საწყისად ვიღებთ სიტყვების, ფრაზების ერთობლიობას და მათი გამოყენებების რაოდენობებს მთელ ვებსაიტზე. ამ რაოდენობების შედარებით, ყოველი ტეგისთვის ისაზღვრება ე.წ. „წონა“, ანუ, მისი გამოყენების სიხშირე და, შესაბამისად, აქტუალურობა. მათი ვიზუალური წარმოდგენისას კი, „წონა“ გამოიხატება თითოეული ტეგის ფონტის ზომაში და, ზოგ შემთხვევაში, ფერის ტონალობებშიც. ტეგი წარმოადგენს ბმულიან ტექსტს, ხოლო ტეგების ღრუბელი კი ამ სხვადასხვა ზომის ბმულების ერთობლიობაა.

ერთი შეხედვით არაფერი განსაკუთრებული ან რთული არ უნდა იყოს :)მაგრამ დამიჯერეთ, რომ დეტალებში საკმაოდ საინტერესო და სპეციფიური ამოცანაა. მოკლედ, საკითხი დაისმის ასე:

პირველ ეტაპზე, უნდა ავიღოთ ორი ტიპის მონაცემების მიმდევრობა: პირველი — ტეგები და მეორე — თითოეულის გამოყენების რაოდენობა ბლოგის პოსტებში ან სიახლეებში. 
ამის შემდეგ ხდება მთავარი — რაოდენობების მაჩვენებლის გარდაქმნა მეორე ტიპის მახასიათებელში, რომელიც საბოლოო ჯამში შრიფტის ზომის განმსაზღვრელი იქნება, ყოველი ტეგისთვის.

როგორ კეთდება ეს ყველაფერი?

პირველი, რაც უნდა გავაკეთოთ, არის მონაცემების ამოღება. როგორ და საიდან მოვახდენთ ამას, გადამწყვეტი მნიშვნელობა არ აქვს — მთავარია, რომ გვქონდეს სტრინგები და მათი გამოყენებების რაოდენობები :)

ზოგადად უნდა შესრულდეს რაიმე ასეთი ტიპის მოთხოვნა:

კოდი

ასეთი ტიპის SQL მოთხოვნის შემდეგ, მონაცემთა ბაზიდან ავიღებთ 50 ცალ შემთხვევით ტეგს და weight-ს — მათი გამოყენებების რაოდენობებს. მშვენიერია :) ანუ სტატისტიკური მონაცემები გვაქვს. ახლა საჭიროა ამ მონაცემების ვიზუალურად წარმოდგენა.

ცხადია, რომ უნდა ავირჩიოთ პრინციპი, მეთოდი, რომლის მიხედვითაც განვსაზღვრავთ ტეგის გამოყენების რაოდენობის მიხედვით მის შესაბამის ფონტის ზომას. ლოგიკა გასაგებია, რაც უფრო ბევრჯერ არის ტეგი გამოყენებული, მით უფრო დიდი ზომის უნდა იყოს ის და პირიქით — ნაკლებად გამოყენებული ტეგი უფრო მცირე ზომის იქნება. ერთი შეხედვით, დამოკიდებულება ცალსახად წრფივი უნდა იყოს, ხომ? სწორედ ეს არის ამ პოსტის მთავარი თემა :)

წრფივი თუ ლოგარითმული ფუნქცია?

ზოგადად, ტეგების ღრუბლის გენერირებისას, გამოყოფენ ორ მეთოდს — წრფივსა და ლოგარითმულს. ანუ, ტეგის ფონტის ზომა მისი გამოყენების რაოდენობაზე წრფივად უნდა იყოს დამოკიდებული, თუ ლოგარითმულად. განსხვავება ამ ორ მეთოდს შორის ვიზუალურ შედეგში გამოიხატება.
წრფივი მეთოდის გამოყენებისას, თუ ტეგების გამოყენების რაოდენობებს შორის დიდი ნახტომებია, მიღებული შრიფტის ზომებით ღრუბელი ნაკლებად მიმზიდველი ხდება. ტეგიდან ტეგზე გადასვლა ზომაში ზედმეტად მკვეთრდება, ზოგიერთი ტეგი ზედმეტად დიდდება, ზოგი კი — საერთოდ იკარგება გიგანტების ჩრდილქვეშ.
ლოგარითმული დამოკიდებულებისას კი, ფონტის ზომებს შორის ცვლილება უფრო ნაკლებად საგრძნობია და ტეგების ნებისმიერი რაოდენობის, ასევე მათი გამოყენების რაოდენობებს შორის დიდი სხვაობის შემთხვევაშიც კი, ვღებულობთ ვიზუალურად უფრო ლამაზ და, ამასთანავე, რეალობის არანაკლებად წარმატებით ამსახველ სურათს.

ვისაც აინტერესებს, თუ რატომ ხდება ასე, ცოტათი მათემატიკასაც შევეხოთ :)მოკლედ, მათემატიკურად სიტუაცია არის ასეთი — თუ, ტეგის გამოყენების რაოდენობასა და ფონტის ზომას შორის დამოკიდებულება არის წრფივი, ეს ნიშნავს იმას, რომ ფონტის ზომას განვსაზღვრავთ წრფივი ფუნქციით, რომლის არგუმენტიც სწორედ ეს რაოდენობაა. ამ ფუნქციის გრაფიკის დახრილობა (ზოგადად, წრფივი ფუქნციის მახასიათებელი „საკუთხო კოეფიციენტი“) დამოკიდებულია სწორედ იმაზე, თუ რამდენად დიდია სხვაობა ტეგების გამოყენებებს შორის. შესაბამისად, თუ ეს შუალედი იქნება დიდი, მაშინ ჩვენი წრფივი ფუნქციით დათვლილ ფონტის ზომებს შორის განსხვავებაც მკვეთრი იქნება. უფრო „ჭკვიანური“ ტერმინებით რომ ვთქვათ, ფუნქციის ცვლილების სისწრაფე დიდი იქნება, რაც ამ არასასურველ შედეგს უზრუნველყოფს.

ლოგარითმული ფუნქციის შემთხვევაში კი სიტუაცია ბევრად უფრო მისაღებია :) წარმოიდგინეთ ლოგარითმის გრაფიკი და ყველაფერი გასაგები იქნება. ეს არის ზრდადი, მაგრამ „გლუვი“ ფუნქცია, რაც ტეგებს შორის ზომების ცვლილებას უფრო ნაკლებად მკვეთრად შესამჩნევს გახდის, ნებისმიერი ზომის ნახტომების შემთხვევაშიც კი.

შეგიძლიათ ჩაატაროთ ექსპერიმენტები და შეამოწმოთ :) მანამდე კი იხილეთ ეს ლინკი: http://www.tocloud.com/linearvslogarithmic.html

ღრუბლის შესაქმნელად საჭირო მეთოდის არჩევის შემდეგ, ვწერთ ალგორითმს. უნდა შესრულდეს დაახლოებით ასეთი მოქმედებები:

კოდი

სადაც, $minUses და $maxUses ცვლადები განსაზღვრავენ კონკრეტულ მიმდევრობაში ტეგების გამოყენებების მაჩვენებლის მინიმუმსა და მაქსიმუმს, შესაბამისად.

$minFontSize და $maxFontSize კი, ის შუალედია, რომელშიც გვინდა, რომ დაგენერირდეს ფონტის ზომები, მინიმალური და მაქსიმალური მაჩვენებელი. გაითვალისწინეთ, რომ მიღებული შედეგები ნატურალური რიცხვები არ იქნება, ასერომ თქვენს მარკაპში შრიფტის ზომა em ერთეულით უნდა განისაზღვროს.

ზოგადი მოსამზადებელი და საბოლოო სამუშაოები კი (მონაცემების ამოღება და მიღებული შედეგებით საჭირო html-ის დაგენერირება) სტანდარტულია და თავს აღარ შეგაწყენთ :D კარგი იქნება, თუ მსგავს მეთოდს ისინი გამოცდით, ვისაც უკვე გაქვთ ტეგების ღრუბელი და წრფივ მეთოდს იყენებთ, საინტერესოა განსხვავებების ნათლად დანახვა.

შემთხვევითი რიცხვები

ყოველთვის მაინტერესებდა (და ალბათ ყველასთვის საინტერესო გახდება, ვინც დაფიქრდება ამ საკითხზე) თუ, როგორ ხდება შემთხვევითი რიცხვების გენერირება კომპიუტერში. ჩემი საქმიანობიდან გამომდინარე ხშირად მომითხოვია კომპიუტერისთვის შემთხვევითი რიცხვი და მიმიღია კიდეც! უამრავი ფუნქცია აქვს სხვადასხვა პროგრამირების ენებს. არადა, ხომ საინტერესოა როგორ ხდება და რა ხდება? ცხადია, რომ რეალურად შემთხვევით რიცხვებთან ვერ (!) გვექნება საქმე, რადგანაც კომპიუტერისთვის ყველაფერი წინასწარ განსაზღვრული ალგორითმია, მისთვის ხომ შემთხვევითობა არ არსებობს.

მოკლედ, დამაინტერესა ამ საკითხმა და ცოტაოდენი ქექვის შემდეგ ამ თემაზე საინტერესო მასალები ვიპოვე :)
არსებობს საიტი www.random.org — True Random Number Service, სადაც გვეუბნებიან, რომ ისინი ჭეშმარიტად შემთხვევით რიცხვებს აგენერირებენ. აი ციტატა საიტიდან:

RANDOM.ORG offers true random numbers to anyone on the Internet. The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs

აღმოჩნდა რომ არსებობს ე.წ. „ფსევდო შემთხვევითი რიცხვები“ და „ჭეშმარიტად შემთხვევითი რიცხვები“; შესაბამისად, მათი გენერირების ორი მეთოდი. პირველი — „ფსევდო-შემთხვევითი რიცხვების გენერატორი“ და მეორე — „ჭეშმარიტად შემთხვევითი რიცხვების გენერატორი“; Pseudo-Random Number Generators (PRNG-ები) და True Random Number Generators (TRNG-ები).

Pseudo Random Number Generators

როგორც სახელიდან ნათლად ჩანს, PRNG არ გვაძლევს ჭეშმარიტად შემთხვევით რიცხვებს. თვითონ PRNG წარმოადგენს გარკვეულ ალგორითმს, რომელიც იყენებს მათემატიკურ ფორმულას ან საერთოდ წინასწარ გამზადებულ რიცხვების მიმდევრობას, რომლებიც საბოლოო ჯამში წარმოადგენენ „შემთხვევით“ რიცხვებს. ყველაზე გავრცელებული მაგალითი ამ PRNG-ებისა, არის ე.წ. „წრფივი შესაბამისობის მეთოდი“, რომელიც გულისხმობს შემდეგს:

ჩვეულებრივი მიმდევრობაა ;) ხოლო m, a და с არიან კონსტანტები, რომლებიც მთლიანად განსაზღვრავენ გენერატორს. ისინი აკმაყოფილებენ ამ პირობებს:

გენერატორის პერიოდის მაქსიმუმი შეიძლება იყოს m-ის ტოლი. თუმცა, როგორც წესი, უფრო ნაკლებია ხოლმე. ეს მეთოდი ძალიან მგრძნობიარეა с, a და m მუდმივების მიმართ. ყველაზე ეფექტურ გენერატორებში m 2-ის ხარისხის ტოლია, ყველაზე ხშირად ეს 232-ს ან 264-ს შეადგენს.

ადამიანური ენით რომ ვთქვათ, PRNG-ები უბრალოდ რაღაც წესით ახდენენ გარკვეული რიცხვების მიმდევრობის დაგენერირებას, რომლებიც შემდეგში წარმოადგენენ ვითომ-შემთხვევით რიცხვებს. :) სწორედ ეს მეთოდები მუშაობენ რეალურად კომპიუტერულ პროგრამებში. ცხადია, რომ ეს მეთოდი (ანუ PRNG) არის პერიოდული. რაც ნიშნავს, რომ მიმდევრობა როდესმე გაიმეორებს თავის თავს. თუმცა, ეს მეთოდი უპრობლემოდ მუშაობს, როდესაც გვჭირდება ბევრი შემთხვევითი რიცხვი და იმ ფაქტს, რომ მიმდევრობა გამეორდება მნიშვნელობა არ აქვს. გარდა ამისა, თანამედროვე ალგორითმების ეს პერიოდი იმდენად დიდია, რომ გამეორებადობის შანსი მიზერულამდე მცირდება. მაგრამ არსებობს შემთხვევები როდესაც ფსევდო-შემთხვევითი რიცხვები არ გამოდგება. მაგალითად, აზარტული თამაშების დროს, დასტაში ბანქოს მიმდევრობის ან ლოტოს ბილეთის ნომრების გენერირებისას, დამთხვევა-გამეორება-გათვლის ყველანაირი რისკი თავიდანვე უნდა გამოირიცხოს. სწორედ ასეთი შემთხვევებისთვის არსებობს

True Random Number Generators

PRNG-სგან განსხვავებით, ეს მეთოდი რიცხვების დასაგენერირებლად იყენებს რეალურ ფიზიკურ მოვლენებს და შემდეგ გადასცემს ამას კომპიუტერს. მაგალითად: ასეთი მოვლენა შეიძლება იყოს მაუსის მოძრაობა (მცირედი ვარიაციებით), ან კლავიატურის ღილაკებზე დაჭერებს შორის დროის ინტერვალი, ან კიდევ უამრავი სხვა რამ :) მაგალითად, ზევით ხსენებული საიტი random.org შემთხვევითი რიცხვების დასაგენერირებლად იყენებს „ატმოსფერული ხმაურის“ ამპლიტუდას და სპეციალურ პროგრამულ უზრუნველყოფას, რომელსაც ჩამწერით მიღებული მონაცემები ციფრებში გადაყავს.

მსოფლიოში არსებობს ხალხი, ვინც სპეციალურ მოწყობილობებს ამზადებს, რომლებიც ფიზიკურ მოვლენებზე დაყრდნობით აგენერირებს შემთხვევით რიცხვებს და სერიოზულ ფულსაც აკეთებს ამ საქმიანობით. მათ მომხმარებლებს შორის კი, ხშირია კამათი და დაუსრულებელი ჰოლი-ვარები თემაზე, თუ რა ტიპის, რომელ მოვლენაზე ორიენტირებული TRNG-ებია უმჯობესი, რომელი შემთხვევისთვის და ა.შ. და ა.შ.

კამათი ხანდახან ისე ღრმად ჩადის, რომ იწყება საუბარი, როგორი TRNG ჯობია — კვანტურ მოვლენებზე დამოკიდებული თუ ის, რომელიც რიცხვებს რაღაც ქაოსური სისტემის ერთიანი ქცევიდან აგენერირებს. :D ამ ყველაფრის დაკავშირება კი პირდაპირ ხდება სამყაროს მოწყობის შესახებ ჩვენ წარმოდგენებთან. ანუ თემასთან, სამყარო არის დეტერმინიზირებული თუ არა — ყველა მოვლენა წინასწარგანსაზღვულია თუ არა? კვანტური ფიზიკის მიხედვით, ატომურ დონეზე ყველაფერი შემთხვევითია; საერთოდ კი, კონკრეტულ მოვლენას ჩვენ მხოლოდ იმიტომ მივიჩნევთ შემთხვევითად, რომ უბრალოდ მისი არსებობის ახსნა არ გაგვაჩნია; კლასიკური ფიზიკის მიხედვით კი ნაწილაკების ერთობლიობის, ანუ სისტემის პროგნოზირება, ცხადია შესაძლებელია…

მოკლედ, ძალიან ღრმად გავიჭერი :D გასაგებია, რომ შემთხვევითი რიცხვების გენერაციისას არანაირი (!) მნიშვნელობა არ აქვს სამყაროს მოწყობას :) სამყარო პროგნოზირებადიც რომ იყოს, თუ ჩვენ შევძელით ნებისმიერი მოვლენის პროგნოზირება ნაწილაკების მოძრაობის დონეზე, მაშინ შემთხვევითი რიცხვებს შემთხვევითობა ყველაზე ნაკლებად იქნება საინტერესო :)