GitHub-თან კავშირი პროქსის გავლით

არ მგონია რომ ეს პოსტი ბევრისთვის სასარგებლო გამოდგეს, მაგრამ მთელი დღე დამაკარგინა და ვერ მოვითმენ რომ არ დავწერო..

GitHub.com არის პროექტების ჰოსტინგის სერვისი ვებ ინტერფეისით, რომელიც Git version control სისტემას იყენებს. მოკლედ რომ ვთქვათ, თქვენ შეგიძლიათ იქ განათავსოთ პროექტის კოდები და ფაილები. ის ცვლილებების ისტორიასაც შეინახავს. შეიძლება სხვადასხვა განშტოებების და ვერსიების გამოყოფა და გუნდური მუშაობის დროს მოსახერხებელია კოდების ასე ცენტრალიზებულად არსებობა.

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

GitHub-ი რამდენიმე შესაძლებლობას გვაძლევს შესვლისთვის: ssh, https და git read-only
https-ით ssl-ის სერტიფიკატების პრობლემის გამო რატომღაც ვერ დავუკავშირდი, ამიტომ ვუკავშირდები ssh-ით ოღონდ https-ის პორტით – 443.

ჩემთან ასეთი ნაბიჯები შევასრულე:
~/.ssh საქაღალდეში შევქმენი კონფიგურაციის ფაილი config შემდეგი შიგთავსით:

Host github.com
User <მომხმარებელი>
Hostname ssh.github.com
ProxyCommand /c/connect.exe -H <პროქსის მისამართი>:<პროქსის პორტი> %h %p
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa
Port 443

ProxyCommand არის option, რომელიც OpenSSH-ში SOCKS პროტოკოლის შესაცვლელად ჩაემატა და საშუალებას იძლევა რომ სხვა პროგრამები გამოიყენოს ssh-მა პროქსისთან ურთიერთობისთვის. ერთ-ერთი ასეთი პროგრამაა connect.c

მე ვინდოუსიდან ვცდილობდი ატვირთვას ამიტომ გადმოვწერე კომპილირებული ფაილი აქედან: http://dl.dropbox.com/u/2177278/connect.exe (თავის საიტზე არ მუშაობდა ლინკი).

ასეთმა კონფიგურაციამ არ იმუშავა, მაგრამ connect.exe-ს აქვს ერთი კარგი პარამეტრი -d დებაგისთვის (მაგ: ProxyCommand /c/connect.exe -d -H <პროქსის მისამართი>:<პროქსის პორტი> %h %p) და მაგის მითითების შემდეგ უფრო დეტალურად წერს სად რა პრობლემა შეხვდა. ძალიან დიდი ალბათობით მანდვე იპოვით მიზეზს.

ჩემ შემთხვევაში პრობლემა პროქსისთან აუტენტიფიკაცია იყო. პროქსის პაროლის მითითებისთვის რამდენიმე მეთოდი არსებობს, მაგრამ environment variable-ებში ღია სახით გაწერა არ მომეწონა და არც იმუშავა ჩემთან. არც git-ის global http.proxy პარამეტრმა იმუშავა (აქაც ღია სახით იყო გაწერილი).

ბოლო ბოლო გადმოვწერე Cntlm Authentication Proxy, რომელიც მანქანაზე გასაშვები სერვისია, პროქსის და აპლიკაციებს შორის დგება და ავტორიზაციას გადის მათ მაგივრად. მისი გამოყენების მარტივი მაგალითი არსად ედოთ და მაინც წამაკითხეს მთელი დოკუმენტაცია 😀 ამიტომ მოკლედ დავწერ როგორ მუშაობს:

Cntlm სერვისია და ინსტალაციის შემდეგ ავტომატურად არის გაშვებული. შეგიძლიათ Control panel-ის Administrative Tools-ში შეხვიდეთ და ამოაგდოთ.
პროგრამა უსმენს კონფიგურაციაში გაწერილ მისამართს და პორტს, მაგალითად: 127.0.0.1:3128
ამიტომ ყველა იმ პროგრამის კონფიგურაციაში, რომელიც გინდათ რომ მისი გავლით პროქსის დააკავშიროთ, პროქსის მისამართის მაგივრად უნდა მიუთითოთ ეს მისამართი და პორტი.

პროქსის პაროლის შეყვანა ერთხელ არის საჭირო – თავიდან. შემდეგ დოკუმენტაციის (Configuration hints განყოფილების) მიხედვით უნდა დააგენერირებინოთ თავისი პაროლი, გადაიტანოთ კონფიგურაციის ფაილში და შემდეგ სულ იმით გაივლის ხოლმე ავტორიზაციას.

მე Git Bash-დან ვუშვებდი ბრძანებებს და კავშირს ამით ვამოწმებდი ხოლმე:
$ ssh -v git@github.com

ამ პრობლემის გადასაჭრელად ძირითადად ეს პოსტები დამეხმარა:

Using Github Through Draconian Proxies
Git SSH problem – bad file number 

ცუდი ის იყო, რომ github-დან კლონი უპრობლემოდ გაკეთდა და ფაილები წამოიღო სერვერიდან, მაგრამ push-ის დროს არაფრით ამთავრებდა ოპერაციას (არც timeout შეცდომით) და მაგის გამო კავშირის პრობლემაზე არ მიფიქრია თავიდანვე. მერე გამახსენდა, რომ კლონი IDE-დან გავაკეთე.. და push არ ჰქონდა იქ..

ფაილური სისტემის შეზღუდვები

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

(ვიკიპედიაზე არის ქართული სტატიის ნაწილი მათ შესახებ, აქ კი სისტემების შედარების ცხრილებია)

კოდის ფრაგმენტი, რაც ზევით ვახსენე, საიტზე სურათების ატვირთვას ეხებოდა. როგორც ჩანს ლინუქსის ფაილურ სისტემებს (ext2/ext3) შეზღუდვა აქვთ, რომ ერთ საქაღალდეში 32000-ზე მეტი ქვე საქაღალდის შენახვა არ შეიძლება. ანუ თუ მაგალითად, მომხმარებლის ფოტოების შესანახად ერთი საქაღალდე გაქვთ გამოყოფილი და იქ თითოეული იუზერისთვის ქვესაქაღალდეს ქმნით, 32000-ზე მეტი იუზერის შექმნის შემთხვევაში ამ საქაღალდეებს ვეღარ შექმნის.

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

მაგალითად, შეიძლება root ფოლდერში შეინახოთ საქალდეები სახელად 10000, 20000, 30000, ხოლო თითოეულში მაქსიმამუმ 10000 ცალი საქაღალდე რომელიც შესაბამისად არის გადანომრილი (1,2,3,.. ). როდესაც საჭირო იქნება იმის დადგენა თუ რომელ გარე საქაღალდეში უნდა მოიძებნოს თქვენი ფოლდერი, მისი სახელის 10000-ზე მთელი გაყოფით და შემდეგ ისევ 10000-ზე გამრავლებით გარე ფოლდერის სახელს მიიღებთ.

შეზღუდვები რომც არ იყოს, ზოგი ფაილური სისტემა არ არის ოპტიმიზირებული რომ ბევრ ფაილიან ფოლდერში სწრაფად ჩაამატოს, ამოშალოს ან წაიკითხოს ფაილები. მაგალითად ლინუქსის ext2 და ext3 დირექტორიების და ფაილების იერარქიას ბმული სიების სახით ინახავდნენ და შესაბამისად იქ ძებნას O(n) დრო სჭირდებოდა. ზოგ შემთხვევაში პრობლემა არაა, მაგრამ როცა, თუნდაც, კეშის მსგავსი სტრუქტურები იყო შესანახი, ძალიან ანელებდა ეს ყველაფერს. შემდეგ დაამატეს მარტივი ხის სტრუქტურა  – HTree, რომელიც ext3-ში შეიძლება ”ჩაირთოს”, ext4-ს კი default-ად აქვს უკვე. სხვა ფაილური სისტემებიდან ბევრი B-tree-ის მონაცემთა სტრუქტურას იყენებს სწრაფი მუშაობისთვის. ამაზე ალბათ მოგვიანებით დავწერ.

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

91\0a\90401e7bdc0452eea5630.jpg

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

მაგალითად,  Squid (web proxy cache) ინახავს კეშირებულ ფაილებს მსგავსი სახით.

კოდის წერის სიჩქარის მნიშვნელოვნად გაუმჯობესება

არა მარტო კოდის 🙂

ალბათ უმეტესი თქვენგანი უკვე იყენებს მას ან მის ალტერნატივას. ზოგიერთ IDE-ს ჩადგმული აქვს მისი შესაძლებლობები.

მე კი მხოლოდ დღეს ვნახე Nettuts+ საიტზე და უკვე შემიყვარდა. ლაპარაკია Texter პროგრამაზე.

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

არა მარტო ტექსტს ვაბამთ. შესაძლებელია მაკროსების წერაც. მაგალითად, თუ წინადადების ბოლოს გაგვახსენდა, რომ წინადადება <p></p> პარაგრაფის ტეგებში უნდა ჩაგვესვა, Texter-ს შეუძლია ისევ რაღაც წინასწარ განსაზღვრული shortcut-ით ეს ტეგები ჩაუსვას, თუ ამ shortcuts განვსაზღვრავთ მაკროსით: {HOME}<p> {END}</p>

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

Hotstring-ის დამატება Texter-ში
Hotstring-ის დამატება Texter-ში

როგორც ჩანს LifeHacker-ის Texter-ის გარდა კიდევ არსებობს მისი მსგავსი პროგრამები, მაგრამ მე უკეთესი ვერ შევარჩიე. ამას კი ჯერჯერობით რაც ვუპოვე ერთადერთი ნაკლი უნიკოდია. არა მარტო ის, რომ უნიკოდი თვითონ პროგრამას არ ესმის, არამედ ხელსაც მიშლის, როცა სხვაგან ვწერ ქართულად და პროგრამის გათიშვა მიწევს.. მიუხედავად ამისა მაინც საშინლად მოსახერხებელია 😀

The NetBeans Collaboration Project

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

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

NetBeans-ის Developer Collaboration პლაგინი კი ზუსტად ‘remote’ pair programming-ის საშუალებას იძლევა. 🙂 თუ ასე შეიძლება დაერქვას.

რის შესაძლებლობას იძლევა?

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

პლაგინს მესენჯერიც აქვს ჩადგმული, რომელსაც სხვადასხვანაირად ფორმატირებული შეტყობინებების გაგზავნა/მიღება შეუძლია (ფორმატირებაში კოდის ფორმატირებას ვგულისხმობ. ანუ, იგივენაირად შეიძლება წერა, როგორც ჩვეულებრივ NetBeans IDE-ში – თავისი shortcut-ებით)

NetBeans Collaboration

გარემოს ასაწყობად საჭიროა:

1. Collaboration სერვერის დაყენება და დაკონფიგურირება (ასეთი სერვერი რამდენიმე არსებობს, თუმცა NetBeans-ის Developer Collaboration მოდულები კარგად არის შემოწმებული OpenFire XMPP სერვერთან ერთად სამუშაოდ, ამიტომ მის საიტზე ამ სერვერის დაყენებას გვირჩევენ და ინსტრუქციაც დევს).

2. NetBeans IDE-ში საჭიროა Developer Collaboration პლაგინის დაინსტალირება.

3. მომხმარებლების დამატება OpenFire-ის ადმინისტრატორის პანელიდან და შემდეგ ამ მომხმარებლების შესვლა (log in) NetBeans IDE-დან.

თამაში გამოცანებით

🙂 არა, მე არა.

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

ამ ბლოგზეც (”თითქმის EXCLUSIVE!”)  მსგავსი თამაშია 🙂 საინტერესო კითხვები. თითოეულის პასუხი შემდეგი ტურის პაროლია.

მოკლედ, ისიამოვნეთ 🙂 და ბლოგის ავტორს კი დიდი მადლობა, კარგად ვიმხიარულეთ :)))