ჩემი გაზაფხულის საკითხავი 2018

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

 

 

Advanced Microservices

მშვენიერი პრაქტიკული წიგნი აღმოჩნდა. აღწერილია, თუ როგორია კარგი API ჩვენი სერვისებისთვის; ვერსიები როგორ ვმართოთ; რა ვარიანტები გვაქვს ინფრასტრუქტურის აწყობისას; რომელი ბაზა რისთვის გამოვიყენოთ – Postgre, Redis, MongoDB, Elasticsearch… მონიტორინგი როგორ შეიძლება გავაკეთოთ – Logstash, Kibana, ანალიტიკა – Grafana, Graphite, StatsD, ავტომატური დოკუმენტაცია, Pipeline და CI სერვერები, Service discovery – Consul, Zookeeper.. მოკლედ, ნორმალურ მიმოხილვას აკეთებს თუ რა ტექნოლოგიები არსებობს, რისთვის დაგვჭირდება და რა გავითვალისწინოთ სერვისის შექმა/შენახვის ავტომატიზაციისთვის.

 

Painless Docker

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

 

Microservices AntiPatterns and Pitfalls

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

 

Building Microservices: Designing Fine-Grained Systems

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

 

Building Evolutionary Architectures: Support Constant Change

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

 

Pro REST API Development with Node.js

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

 

The Obesity Code

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

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

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

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

 

The Complete Guide to Fasting: Heal Your Body Through Intermittent, Alternate-Day, and Extended

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

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

Editorial illustrations for T3 by Nicolas Dehghani

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

მე მგონი მათ შორის საჩვენო კანონებიც გამოიძებნება. რამდენიმე მათგანი ამოვკრიბე.

 

ზოგადობის კანონი

წარუმატებლობის ერთ-ერთი უმოკლესი გზა ბრენდისთვის ზოგადი სახელის დარქმევაა (ბრენდინგი)

ზოგადი სახელის მქონე ბრენდის გამორჩევა ძალიან ძნელია.
შეიძლება იფქლის შპს “პურის” პური თაროზე მაინც ნახოს ადამიანმა, ჩვენს სფეროში კი თაროს მაგივრად გუგლი, stackoverflow და მისთანები გვაქვს. ამიტომ ძალიან დიდი პრობლემაა, მაგალითად, პლატფორმის დასახელება Parse, რომელთანაც json-ით მუშაობენ და ვერც ერთ საძიებო სისტემაში ვერ გადაფარავს ეს კომბინაცია json-ის დაპარსვის შესახებ შედეგებს. ანალოგიურად, ორაკლის NoSQL მონაცემთა ბაზისთვის სახელი – NoSQL Database. უკვე თვალწინ დგას როგორ დაიტანჯებით ამ ბაზასთან მუშაობით.

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

 

ლიდერობის კანონი

ჯობს იყო პირველი, ვიდრე უკეთესი (მარკეტინგი)

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

პირველი ობიექტზე ორიენტირებული პროგრამირების ენა SmallTalk იყო, მაგრამ პირველი უფასო – Java, ამიტომ დღესაც ბაზრის ძალიან დიდი ნაწილი უჭირავს.

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

ჩვენს სფეროში ეს კანონი მე მგონი მაინცდამაინც არ კანონობს, რადგან დრო ძალიან სწრაფად გადის და ყველაფერი ძალიან სწრაფად ძველდება. Angular შეიძლება პირველი იყო თავისი მოდელით, მაგრამ დროთა განმავლობაში React-მა გადაუსწრო ბაზრის წილით.

 

კატეგორიის კანონი

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

კომპიუტერებში IBM-ის დიდი წარმატების შემხედვარე ყველა იმ სფეროში გადაერთო – Burroughs, Control Data, General Electric, Honeywell, NCR, RCA, Sperry. ფიფქიას და შვიდ ჯუჯას ეძახდნენ…

აქედან რომელი ჯუჯა გაიზარდა 14 მილიარდიანი ბრუნვის მქონე მსოფლიო მასშტაბის კომპანიად? არც ერთი. 70-80-იან წლებში IBM-ის გვერდით ყველაზე წარმატებული კომპიუტერული კომპანია Digital Equipment Corporation ანუ DEC იყო, რადგან ის პირველი იყო მინიკომპიუტერებში (1998-ში DEC შეიერთა Compaq-მა, რომელიც მოგვიანებით HP-ის შეუერთდა).

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

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

სტატია: როგორ გადააქციეს ჯონ და პატრიკ კოლისონებმა სტრაიპი მობილური ხანის “პეიპალად”

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

 

აღქმის კანონი

მარკეტინგი არა პროდუქტების, არამედ აღქმების ბრძოლაა. (მარკეტინგი)

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

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

 

ფერის კანონი

ბრენდმა მისი მთავარი კონკურენტების ფერების საპირისპირო ფერი უნდა გამოიყენოს (ბრენდინგი)

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

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

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

 

 

მსხვერპლის კანონი და ფოკუსის კანონი

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

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

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

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

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

როგორც ჩანს, ეს პირდაპირ არ ვრცელდება პროგრამისტების შექმნილ პროდუქტებში. მაგალითად ოპერაციული და ვერსიის კონტროლის სისტემები სრულებით განსხვავდება ერთმანეთისგან, მაგრამ ორივე მაინც აპლიკაციაა. ამიტომ როცა ვიცით, რომ ლინუს ტორვალდსი კარგი პროგრამისტია, მის შექმნილ ოპერაციულ სისტემასაც და Git-საც დიდი წონა აქვს (Git-მდე არსებობდა სხვა DVCS სისტემები, შეიძლება ნაკლებად სტაბილური, თუმცა kernel-ისთვის git-ის არჩევამ კიდევ უფრო დიდი წარმატება მოუტანა ამ პროდუქტს).

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

წიგნები შეიძლება ცოტა მოძველდა, მაგრამ მე მგონი მაინც საინტერესო მაგალითებს იპოვით შიგნით. როგორც ჩანს ყველა თუ არა, ზოგიერთი კანონი ნამდვილად უცვლელია. კიდევ აქვთ ამ ავტორებს ერთი წიგნი, რომელიც ქართულად ითარგმნა – “მარკეტინგული ომები” (Marketing warfare).

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

Childhood dreams by Rebecca Cobb

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

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

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

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

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

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

 

 

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

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


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

ერთი იყო ჭკუის სასწავლებელი შეცდომები არქივი, რომელსაც ჰქვია 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 წუთში შლიან და აწყობენ მთელ მანქანას.

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