ძველი ოცნებები

გამოხმაურება
Childhood dreams by Rebecca Cobb

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

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

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

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

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

ა ჰო, ჟურნალს “ცისარტყელა” ერქვა.

 

 

 
* * *
მართლაც აღმოჩნდა სხვენში ძველი არქივები. კროსვორდების ფართო არჩევანი გვქონია 😀 “თევზვორდი”…

მაღლიველი სტუდენტი და NASA-ს ჯავას სტანდარტი

4 კომენტარი


წინა პოსტისთვის მასალების გადამოწმებას რომ ვცდილობდი, ნასას საიტზე სხვა საინტერესო რამეებსაც გადავაწყდი და პატარა პოსტს მივუძღვნი ბარემ 🙂

ერთი იყო ჭკუის სასწავლებელი შეცდომები არქივი, რომელსაც ჰქვია Lessons learned. და პრობლემები, სადაც ცხვირი წაიტეხეს, თავისი გადაჭრის გზებით არის აღწერილი.

მეორე იყო JPL ლაბორატორიის სტანდარტი, რომლითაც მათი ჯავა პროგრამისტები ხელმძღვანელობენ. იქ ჩამოთვლილი საკითხების უმრავლესობის წყაროდ ორი წიგნი მოეყვანათ – ჯავას ერთ-ერთი შემქმნელის – ჯოშუა ბლოხის Effective Java და იგივე ავტორის Java Puzzlers: Traps, Pitfalls, and Corner Cases.

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

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

1. რას დაბეჭდავს მეორე ხაზი?

int i = 0; 
System.out.print(true ? 'x' : 0); // prints "x"
System.out.print(true ? 'x' : i); // prints ?

“120”
ეს იმიტომ რომ char დაყავს int-ზე. ამიტო ასეთ შემოკლებულ if ჩანაწერებში ჯობია ორივე მხარეს ერთი ტიპის ცვლადი იყოს.

2. როგორ შევადაროთ სწორად float ტიპის რიცხვები?

0.1 + 0.2 == 0.3

false
0.1 + 0.2 დაბეჭდავს 0.30000000000000004
მცოცავმძიმიან რიცხვებზე ოპერაციები ყოველთვის პრობლემაა და დიდი ისტორია აქვს, ახლა არ ჩავუღრმავდები (განსხვავებულად ინახება მეხსიერებაში). ენების უმრავლესობაში ჯობია, რომ სიზუსტე სადაც გვჭირდება long ტიპი ან შესაფერისი ბიბლიოთეკა გამოვიყენოთ. მაგალითად, ფული იყოს არა 1.43 ლარი არამედ 143 თეთრი.

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

final double EPSILON = 0.001;
System.out.println(Math.abs((0.1 + 0.2) - 0.3) < EPSILON); // დაბეჭდავს true;

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

class Spin {
    public boolean done = false;
    public void spin() {
        while(!done){ 
	    // რაიმე ლოგიკა
        }
    }
}

რა პრობლემა აქვს ამ კოდს?

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

4. ვთქვათ რიცხვის კენტობაზე შემოწმება გვსურს. რა პრობლემა აქვთ ამ პირობებს?

x % 2 == 1
x % 2 > 0

უარყოფითი რიცხვები.
ეს სწორად არ მუშაობს თუ x უარყოფითია. მაგალითად -5 % 2 არის -1.
ამიტომ ჯობია შევამოწმოთ ხოლმე ამ პირობით: x % 2 != 0 კენტობა, x % 2 == 0 ლუწობა.

ყველაზე ძვირიანი კოდი, NASA-ს სტანდარტები და რისკიანი პროგრამისტები

გამოხმაურება
როვერის ნაფეხურები მარსზე, რომელიც არსაიდან იწყება.

სულ მაინტერესებდა, როგორ წერენ უზარმაზარ წარმატებულ პროგრამებს შეცდომების გარეშე, მაგალითად მარს როვერი “Curiosity”, რომელიც მარსზე გაფრინდა, 8 თვეში გაიარა 350 მილიონი მილი, დაეშვა 6 მილის რადიუსში, უცხო გარემოში დადის და დედამიწაზე გზავნის მონაცემებს.

 

როგორ გაუშვეს როვერი მარსზე

ინტერნეტში არის ერთ-ერთი უიშვიათესი ტექნიკური ხასიათის გამოსვლა მარს როვერის შესახებ. ნასას JPL – Jet Propulsion Laboratory ლაბორატორიის ერთ-ერთი მთავარი მეცნიერი, Gerard Holzmann აღწერს, თუ როგორ ცდილობდნენ პროგრამირების პროცესის წარმართვას, რომ მაქსიმალურად აეცილებინათ პრობლემები.

მოკლედ ვიტყვი რამდენიმე ფაქტს ვიდეოდან:

  • დაახლოებით 4 მილიონი ხაზი კოდი, 100-ზე მეტი მოდული, 120 ნაკადი ერთ პროცესორზე (+1 ბეკაპი). ხუთი წელი და 40 პროგრამისტი. ყველაფერს კი ერთი მომხარებლისთვის და პირველივე გამოყენებაზე უნდა ემუშავა.

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

  • შემოიღეს რისკების შესამცირებელი სტანდარტი და მუდმივად ამოწმებდნენ ავტომატური ხელსაწყოებით. იმის გამო, რომ ადამიანები არ კითხულობდნენ და იცავდნენ დოკუმენტებს ასობით წესებით, ჩაატარეს გამოკითხვა და გამოარჩიეს ათი ყველაზე მნიშვნელოვანი წესი: Power of ten
    მაგალითად: ნუ გამოიყენებთ რეკურსიას, goto-ს და მსვლელობის სხვა რთულ კონსტრუქციებს; მონაცემების ხედვის არე (scope) იყოს მინიმალური; ყველა ციკლს ჰქონდეს ფიქსირებული საზღვრები; პოინტერის მხოლოდ ერთი განმისამართება გააკეთეთ, ფუნქციის პოინტერებს ნუ გამოიყენებთ; ა.შ.

  • ყოველ ღამე ხდებოდა კოდის დაბილდვა, სტატიკური ანალიზი და სხვადასხვა ავტომატური ტესტირება. ღამე იმიტომ, რომ 15 საათი სჭირდებოდა ანალიზს.

  • ვინც ბილდს გააფუჭებდა, დაჯარიმდებოდა და ბრიტნი სპირსის პლაკატს გამოაკრავდა თავის კუბში. ხოლო ვინც ბევრ warning-ებს დატოვებდა კოდში, “სირცხვილის კედელზე” მოხვდებოდა. როგორც ჩანს ნასაშიც კი სჭირდებათ ადამიანებს მოტივაცია წესების დასაცავად 😀

  • სპეციალური ტრენინგის და სერტიფიცირების გარეშე არ უშვებდნენ კოდთან ადამიანს.

  • ითხოვდნენ 100% code coverage-ს. ვისაც გაუკეთებია ეს, მიხვდება თუ რა შრომატევადი ამოცანაა 100%, რადგან არარსებული სცენარების გატესტვაც მოუწევთ – მაგალითად if-ების ისეთი განშტოებები, რომელიც შეუძლებელია ოდესმე შესრულდეს.

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

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

  • კრიტიკულ ნაწილებში იცავდნენ MISRA პროგრამირების სტანდარტს – რომელიც ძრავების და სასიცოცხლო მნიშვნელობის აპარატურაში გამოიყენება.

  • კრიტიკული ქვესისტემებისთვის ლოგიკურ ვერიფიკაციას აკეთებდნენ – მათემატიკურად ამტკიცებდნენ ალგორითმის სისწორეს.

ამ მისიაში დაინტერესებულებისთვის კიდევ ერთი გამოსვლა არსებობს (თუმცა მე პირველი უფრო მომეწონა): CppCon 2014: Mark Maimone “C++ on Mars: Incorporating C++ into Mars Rover Flight Software”

 

სტანდარტის დარღვევაზედ

ინტერნეტში ცნობილი შემთხვევებიდან ყველაზე ძვირიანი კოდი Space Shuttle-ისთვის დაიწერა – 1000$/ხაზი. მაგრამ 2013 წელს ტოიოტამ სასამართლო წააგო და კომპენსაციის თანხით თუ დავთვლით დაახლოებით 1200$ დაუჯდა თითო ხაზი. ტოიოტას უნებური აჩქარების პრობლემა არაერთხელ მოხვდა სიახლეებში ავტო ავარიების და საჩივრების გამო. ხან ხალიჩები გაიწვიეს უკან, ხან გაზის პედლები, მაგრამ საკმარისი არ აღმოჩნდა. მერე NASA-ს გუნდმა შეამოწმა გაზის კონტროლის პროგრამა ტოიოტას მანქანაზე და, მართალია, თავიანთ სტანდარტთან შედარებით 243 დარღვევა ნახეს, მაგრამ საბოლოოდ ვერ დაადასტურეს, რომ პროგრამის შეცდომის ბრალი იყო. სასამართლოს გარე ექსპერტად ერთი ტიპი ჰყავდა, რომელმაც მიწასთან გაასწორა ტოიოტას კოდი, უწესო რეკურსიაო, სტეკ ოვერფლოუვო და კიდევ ათასი რაღაც.

თუმცა ბოლო ბოლო მგონი მაინც არ იყო ზუსტი განაჩენი გამოტანილი პროგრამისთვის. მთლიანი ქეისი აქ არის: A Case Study of Toyota Unintended Acceleration and Software Safety

 

ჩვენ, უბრალო მოკვდავი პროგრამისტები

კონსტრუქტორის არასწორად დაწერა ჯავასკრიპტში

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

არსებობს პროგრამები, რომელსაც შეცდომა თითქმის არ მოსდის, მაგრამ თუ მოუვა უზარმაზარს ზარალს მოიტანს. ანალოგიურად არსებობს ისეთებიც, რომელშიც ხშირად ხდება შეცდომა, მაგრამ მარტივი და იაფი ჯდება მისი გასწორება. დაახლოებით ისე, როგორც მანქანებში – იშვიათად გაფუჭებული BMW-ს შეკეთება ძვირია, ამერიკას კი ომის დროს ჰყავდა Willys MB ჯიპები, რომელსაც დაზიანებისას ძალიან სწრაფად აღადგენდნენ. საერთოდ შლიდნენ და ისე გადაჰქონდათ აქეთ-იქით. ვიდეოც არის ინტერნეტში, სადაც კანადელი ჯარისკაცები 4 წუთში შლიან და აწყობენ მთელ მანქანას.

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

როგორ გავხდეთ უკეთესი პროგრამისტი ეფექტურად

გამოხმაურება

ამ 10-11 წლის განმავლობაში, რაც პროგრამირება ჩემს პროფესიად იქცა, მრავალფეროვანი უკან დახევის და წინსვლის პერიოდები მქონდა, ხან რუტინები, ხან ნახტომები – როგორც ყველას მოკლედ 🙂

მომინდა სტატიაში მომეყარა თავი. თქვენც ხომ არ დამიმატებთ რჩევებს კომენტარებში?

 

დიდი სურათი

V8 ძრავი

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

მოდით ექსპერიმენტი ჩავატაროთ: გაიხსენეთ ენა, რაზეც ბოლო ერთი-ორი წელი წერთ. გარანტიას გაძლევთ, რომ თუ ამ ენაზე ერთ კარგ წიგნს (ან უბრალოდ მის დოკუმენტაციას) წაიკითხავთ თავიდან ბოლომდე, ნახევარი თუ არა დიდი ნაწილი მნიშვნელოვანი სიახლე იქნება. არ ვგულისხმობ, რომ წიგნის ყველა მაგალითზე გავჩერდეთ და კოდი გავუშვათ, ან ყველა დეტალი ბოლომდე გავიგოთ / დავიმახსოვროთ. უბრალოდ, როცა წინასწარ ვკითხულობთ მთლიანად და ერთიანად, დიდ სურათს ვხედავთ. ყოველთვის შეგვიძლია დეტალები დავგუგლოთ, თუ ვიცით რომ ეგეთი რამ საერთოდ არსებობს. თუ არ გვეცოდინება საფუძვლები ან თუნდაც, მაგალითად, როგორ იყენებს მეხსიერებას, გვექნება memory leaks პროგრამაში და ვერც მივხვდებით.
ამის შემდეგ შეგვიძლია წავიკითხოთ კიდევ ერთი წიგნი – შესაბამისი Best practices, ანუ ამ ენის გამოყენების საუკეთესო პრაქტიკა, რაც კიდევ უფრო მეტი ‘ტრამვისგან’ დაგვიხსნის. თუ სწავლის პროცესში უამისოდ პროექტს გადაწერთ ხუთჯერ, ამის წაკითხვის შემდეგ სავაურაუდოდ გადაწერთ ერთხელ.

წიგნს ორი-სამი დღე სჭირდება, იგივე შეცდომებზე სწავლას კი თვეები.

 

შეჯიბრებები და ალგორითმები

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

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

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

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

კარგი სია, სადაც ვარჯიში შეიძლება: The 10 Best Coding Challenge Websites for 2018

 

ასწავლე სხვას

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

 

სტრესი გვანადგურებს

Gravity Glue | Stone Balance by Michael Grab

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

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

  • გააკეთეთ ავტომატიზაციები. ჩვენი სფეროს ყველაზე სტრესული პროცესები ავტომატიზირებადია. ეს ძალიან ბევრ ნერვებს და დროს დაგიზოგავთ.
  • როცა ერთ პრობლემაზე გაიჭედებით, გადაერთეთ ან დაისვენეთ. არსებობს გამოთქმა – sleep on a problem. თუ ძილის წინ კარგად ჩამოაყალიბებთ გადასაჭრელ პრობლემას, ღამე ტვინი იფიქრებს და დილით პასუხსაც დაგახვედრებთ. ეს ნამდვილად მუშაობს.
  • ფიზიკური ჯანმრთელობა, ბუნებაში გასეირნება, მედიტაცია, ძილი. შეიძლება ჩათვალოთ, რომ ვარჯიშში დასაკარგი დრო არაა, მაგრამ გონებრივი სამუშაოც პირიქით უფრო მეტი ესწრება, როცა პარალელურად ფიზიკური დატვირთვაა. ხოლო უძინარმა და დაღლილმა მთელი ღამე რომც წეროთ კოდი, მეორე დღეს თვითონ გადააგდებთ იმ კოდს ან შეცდომებით იქნება სავსე. ენერგეტიკული სასმელები და უზარმაზარი რაოდენობით კოფეინი ალბათ მხოლოდ გამოუვალ მდგომარეობაში შეიძლება, თუ შეიძლება საერთოდ.
  • მხოლოდ თქვენ შეგიძლიათ საკუთარ თავზე ზრუნვა. სტრესი მშვენიერი მამოტივირებელია, მაგრამ მუდმივის შემთხვევაში ტვინსაც და ორგანიზმსაც ძალიან ცუდი რამეები მოსდის.

 

სხვისი კოდების კითხვა და open-source პროექტებში მონაწილეობა

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

Exponential backoff, Circuit breaker – ანუ ცადეთ მოგვიანებით

გამოხმაურება

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

პრობლემური შედეგი შეიძლება სხვადასხვა ხასიათის იყოს:
გარდამავალი – მაგალითად,
– 503 Service unavailable – როდესაც სერვისი გადატვირთულია ან დროებით გათიშულია;
– 504 Gateway Timeout – როდესაც ბექ სერვერიდან პასუხი დროულად არ მოდის პროქსისთან;
– ასევე ნებისმიერი timeout, როდესაც სერვერიდან საერთოდ არ მოდის პასუხი.
ეს გარდამავალი შეცდომებია და შეიძლება გამოსწორდეს რაღაც დროის შემდეგ

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

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

 

Exponential backoff

ალბათ შეგიმჩნევიათ, როცა GMail არის გახსნილი და ინტერნეტი ითიშება, თავზე ეწერება შეტყობინება Connecting in 1s… ჯერ ერთ წამში ცდის, მერე 2 წამში, მერე 4 წამში, მერე 8-ში და ასე ექსპონენციალურად ზრდის დროს მცდელობებს შორის. საათებზეც კი ადის.
საუბარი არ არის მხოლოდ ბრაუზერს და სერვერს შორის ურთიერთობაზე. შეიძლება ასეთი პრობლემური კავშირები მთელიანად სერვერის მხარეს არსებულ სხვადასხვა კომპონენტს შორის იყოს. ზოგჯერ უკეთესი შედეგის მისაღებად ‘შემთხვევითობაც’ შემოაქვთ, მაგალითად Amazon AWS არქიტექტურაში ორივე ერთად გამოიყენება: Exponential Backoff and Jitter.
ანუ მეორე მცდელობა 4 წამის შემდეგ კი არა იყოს, არამედ 1-4 ფარგლებში შემთხვევითად შერჩეულ X წამის შემდეგ.

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

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

Exponential backoff ალგორითმი Ethernet პროტოკოლშიც გამოიყენება. როცა ქსელში ორი მანქანა ერთდროულად ცდილობს პაკეტის გაგზავნას, კოლიზია ხდება. ზუსტად იგივე დაყოვნების შემდეგ რომ გაგზავნოს ორივემ, ისევ ისე დაემთხვევა და ასე უსასრულოდ. ამიტომ დაყოვნების ფორმულა ასეთია
0 ≤ r < 2^k სადაც k = min (n, 10)
n არის კოლიზიების რაოდენობა და r შემთხვევითად ირჩევა. ანუ რაც უფრო მეტი კოლიზია ხდება, ექსპონენციალურად იზრდება საზღვარი, და მერე ამ საზღვრიდან ხდება დაყოვნების დროის ამორჩევა შემთხვევითად.

 

Circuit breaker

ეს ალგორითმი ჰგავს ელექტრო ქსელის ავტომატურ ამომრთველს, რომელიც ყველას გვიყენია სახლში.
სერვისს და კლიენტს შორის დამატებით დგება ერთი შუალედური ობიექტი, რომელიც სერვისის მცველის როლს ასრულებს. როცა ხედავს რომ დროის გარკვეულ მონაკვეთში სერვერისგან ცუდი პასუხები მოდის ან საერთოდ არ მოდის, გადადის “Open” რეჟიმში, აღარ უშვებს მასთან კლიენტის მოთხოვნებს და თვითონვე პასუხობს ჩავარდნით.

როცა ელექტრო ამომრთველს მოსდის ასე, ხელით ვრთავთ უკან, მაგრამ აქ ხელით ვერ ჩავრთავთ, ამიტომ რაღაც ინტერვალის შემდეგ ეს მცველი ობიექტი გადაგვყავს “Half-Open” რეჟიმში და ის ერთ მოთხოვნას სერვისამდე გაატარებს საცდელად. პასუხის მიხედვით ან ისევ “Open” რეჟიმში დაბრუნდება, ან “Closed” გახდება და ყველა მომდევნო მოთხოვნას სერვერთან გაუშვებს ჩვეულებრივ.

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

სურათი აღებულია მარტინ ფოულერის ბლოგიდან

ზოგიერთ ფრეიმვორკში (განსაკუთრებით ბაზასთან ურთიერთობისას) უკვე იმპლემენტირებულია მსგავსი ალგორითმები.

თუ თქვენ public API გაქვთ და გსურთ რომ უცხო კლიენტებმა retry-ის სწორი მექანიზმი გამოიყენონ – სულ მთლად არ მოკლან თქვენი სერვისი გაჭირვების ჟამს, მაშინ შეგიძლიათ თქვენ თვითონ დაწეროთ რამდენიმე კლიენტი-ბიბლიოთეკა სხვადასხვა ენისთვის და მომხმარებლებიც მათ გამოიყენებენ.