CNC მანქანების დაპროგრამება

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

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

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

lcamtuf_robot1

ყალიბის გაკეთება რობოტის ნაწილებისთვის. ფოტო აღებულია lcamtuf-ის საიტიდან.

othermill

Othermill კომპანია otherfab-ისგან

jobs.ge საიტის REST კლიენტი ანდროიდზე

ალბათ გსმენიათ თბილისის GTUG-ის შესახებ – ეს არის თბილისის Google Technology User Group ქომუნითი, სადაც ჯერ ჯერობით მაინც დეველოპერები ჭარბობენ. ისინი ქმნიან და ერთმანეთს აცნობენ თავის პროდუქტებს, უყვებიან საკუთარ გამოცდილებას. ამიტომ GTUG-ის შეკრებებზე სხვადასხვა ტიპის სემინარებიც ტარდება ხოლმე. მაგალითად იყო მოხსენებები ანდროიდზე, RESTful ვებ სერვისებზე, რჩევებზე თუ როგორ შეიძლება შევქმნათ უკეთესი პროგრამული უზრუნველყოფა, Responsive web დიზაინზე, გუგლის App Engine-ზე, Cross-platform Mobile Development-ზე, Machine learning-ზე (გუგლის Prediction API), GWT-ზე, გუგლის რუკებზე, NoSQL მონაცემთა ბაზებზე, ალგორითმებზე…

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

jobs.ge REST client application

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

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, რომელიც მანქანაზე გასაშვები სერვისია, პროქსის და აპლიკაციებს შორის დგება და ავტორიზაციას გადის მათ მაგივრად. მისი გამოყენების მარტივი მაგალითი არსად ედოთ და მაინც წამაკითხეს მთელი დოკუმენტაცია :D ამიტომ მოკლედ დავწერ როგორ მუშაობს:

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) ინახავს კეშირებულ ფაილებს მსგავსი სახით.

Who dares, wins :D

რას მივუძვნიდი ამ პოსტს, თუ არა ჯეოლიმპს :)

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

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

სამ დღეს თუ გადაცდა ეს პროცესი, სასტიკად მძულს ის ამოცანა და ამოხსნა კი არა, გახსენებაც აღარ მინდა : ))

ჯეოლიმპში ის მომწონს, რომ საჩემო ამოცანებიც არის :D ჩემს ჭიასაც უხარია, როცა ნოლზე არ ვრჩები.

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

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

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

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

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

(თვითონ ხომ კარგს არ დაწერენ თავის თავზე.. :D )

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

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

ჰოდა, რომ მეუბნებით ხოლმე ზოგიერთები ტრასაზე როდის დავდგეთო, :D მობრძანდით კვირას (19-ში) და ამ არენაზე შევეჯიბროთ. its more fun.  მე დიდი ამომხსნელი არ ვარ, მაგრამ მაინც სახალისოა.

”ჯეოლიმპი” თბილისის სახელმწიფო უნივერსიტეტში

”ჯეოლიმპი” თბილისის სახელმწიფო უნივერსიტეტში