ქართული ვები მათთვის, ვინც უსმენს

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

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

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

ან გაგვიზიაროთ მოსაზრებები, მაშინ შემოგვიერთდით 14 მაისს, 14:30 საათზე.
ა/ო ინფორმაციული ტექნოლოგიების განვითარების ინსტიტუტთან (IDIT) ერთად, საქართველოს ინოვაციებისა და ტექნოლოგიების სააგენტოს მხარდაჭერით, ვატარებთ კონფერენციას – “შეუზღუდავი შესაძლებლობები ონლაინსივრცეში”.

გეგმა ასეთია:

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

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

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

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

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

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

მეტი ინფორმაციისთვის, კონფერენციის ორგანიზატორების და ჩატარების დეტალების შესახებ, ასევე რეგისტრაციისთვის, იხილეთ ღონისძიების გვერდი: https://www.facebook.com/events/1938015203106845

ერთი კოდი – სხვადასხვა პლატფორმა: NativeScript და React Native

9 კომენტარი

ამასწინათ გვინდოდა ერთი პროექტის გადაწერა ისეთი ფრეიმვორკით, რომ საერთო codebase გვქონოდა რამდენიმე პლატფორმაზე – ვებზე, Android-ზე და iOS-ზე. ახლა სამივესთვის ცალცალკე ერთისა და იმავეს წერა ცოტა ძვირიც ჯდება და დროც მეტი მიაქვს.

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

მაშ ასე: ჰიბრიდები თავიდანვე გამოვრიცხეთ. ჰიბრიდია მობილურის ისეთი აპლიკაცია, რომელიც html/css/javascript-ით იწერება და შემდეგ web view კომპონენტით იტვირთება აპლიკაციაში. ჩვეულებრივი საიტისგან განსხვავებით რაღაც დონეზე ხელმისაწვდომია მობილურის ოპერაციულის API, თუმცა ჩვეულებრივი საიტივით რენდერდება. Native აპლიკაცია მასთან შედარებით გაცილებით გლუვი და სწრაფია, user experience მაინც განსხვავდება, ამიტომ ჰიბრიდებს ძირითადად პატარა აპლიკაციების ან პროტოტიპებისთვის ირჩევენ ხოლმე.

ჰიბრიდის შესაქმნელი ფრეიმვორკები მრავლად არსებობს: Cordova (ყოფილი PhoneGap), Ionic, Sencha Touch, Mobile Angular UI, ა.შ.

გაცილებით ნაკლები ვიპოვე ისეთები, რომლებიც, საიტად რენდერის ნაცვლად, ამ ჯავასკრიპტის კოდს native ელემენტებს უსაბამებენ და ფაქტიურად native აპლიკაციებს ქმნიან. მაგალითად,

 

NativeScript

კომპანია Telerik-მა, რომელსაც შეიძლება ჰიბრიდის ბიბლიოთეკით იცნობთ, შექმნა NativeScript – ფრეიმვორკი, სადაც ანგულარის, typescript-ის ან ჯავასკრიპტის გამოყენებით შეგვიძლია შევქმნათ მობილურის native აპლიკაციები.

ტელეფონზე ეშვება ჯავასკრიპტის ვირტუალური მანქანა და reflection-ის, C++-ის და OS-ის აპის გამოყენებით ხიდს ქმნის native კომპონენტებთან. მეტი background დეტალებისთვის შეგიძლიათ ეს გვერდი ნახოთ: How NativeScript Works
თუმცა, ამ ხიდის მიუხედავად, ნამდვილი native-ის წარმადობასთან სხვაობას ვერ შეამჩნევთ.

ფრეიმვორკის ძირითადი ღირსებები ესენია:
– Native UI
– Extensible (Easily reuse existing plugins from npm, CocoaPods (iOS) and Gradle (Android) directly in NativeScript projects)
– Cross-Platform: Write and deploy native mobile apps for iOS, Android and (soon) Windows from a single code base
– Open source: Apache 2 license.

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

საიტისგან განსხვავებით NativeScript-შიც და React Native-შიც view-ებს html-ით არ ვწერთ, არამედ xml-ით, რომელიც ანდროიდის ვიუებს ჰგავს.

<StackLayout>
	<Button ios:text="foo" android:text="bar"></Button>
</StackLayout>

შეგვიძლია კონკრეტული პლატფორმისთვის სხვა ლოგიკა ჩავდოთ. ერთი მაგალითი ზევით მოცემული ღილაკის ტექსტია. ჯავასკრიპტში შეგვიძლია დავწეროთ if (page.ios) { … }

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

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

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

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

 

React Native

ამას გაცილებით შთამბეჭდავი გალერეა აქვს. ათასობით აპლიკაციაში ყოფილა გამოყენებული. React Native ფრეიმვორკი Facebook-ისგან მოდის და React-ს ჰგავს. ეს რომ ვცადე, ნამდვილად დავეთანხმე რამდენიმე სტატიას – NativeScript-თან შედარებით გაცილებით მეტი კონტროლი გაქვს UI-ზე, ამიტომ დიზაინში უფრო თავისუფალი ხარ, მაგრამ, სამაგიეროდ, მეტ კონტროლს მეტი კოდი მოჰყვება თან.

React Native ანალოგიურად ერთი კოდის პრინციპს იცავს, თუმცა პლატფორმების სპეციალურ სხვაობებს მაინც დიდ ყურადღებას აქცევს. როგორც ამბობენ, დიდ აპლიკაციებში 100% კოდს ვერ გააზიარებ iOS და Android-ს შორის. კი შეგიძლია სხვა იუზერების პლაგინები და კომპონენტები გამოიყენო და ერთნაირი გახადო, მაგრამ თუ პლატფორმების თავისებურებებს ‘პატივს სცემ’, ზოგ შემთხვევაში ცალცალკე კოდის წერა მოგიწევს.
მარტივი მაგალითი რომ მოვიყვანო, თარიღის ასარჩევი ველი სრულებით განსხვავდება ამ ორ პლატფორმაზე, როგორც გარეგნულად, ისე კონფიგურაციით.

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

 

დასკვნა

პროექტის გადაწერის მაგივრად, ნოლიდან რომ ვიწყებდე ახლა რაიმეს ცოტა კომპლექსური ინტერფეისით, ალბათ React Native-ს ავირჩევდი. თუმცა ესეც არ არის, რომ მეორე დღესვე მარტივად დაიწყებ წერას. იმ რამდენიმე გვერდისთვისაც კი ბევრი trial and error დამჭირდა – ცალკე გარემოს ვერსიების შეთავსებაში ინსტალაციისას და ცალკე უცხო ფრეიმვორკის ალღოს აღებაში. ამ ორივე ფრეიმვორკს ანდროიდის სქილები ეხმარება, რადგან ანდროიდშიც ანალოგიურად ხდება UI-ის აწყობა.

არსებობს კიდევ ერთი – Xamarin, სადაც C#-ზე წერ, უბრალოდ ეს ვინდოუსის სამყაროა და საჩვენო არ იყო. ისე Xamarin ცოტა განსხვავებულად იქცევა. მაგალითად, iOS-ის პროექტს პირდაპირ დივაისის ასემბლერში აკომპილირებს, ანდროიდისთვის კი Mono .Net ფრეიმვორკს იყენებს. დეტალები შეგიძლიათ საიტზე ნახოთ: Understanding the Xamarin mobile platform

სხვა ანალოგიური ფრეიმვორკი ვერ ვიპოვე. თქვენ ხომ არ იცით რამე მსგავსი?

Boxtrolls და რევოლუცია stop-motion ანიმაციაში

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

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

stop-motion არის ერთ-ერთი ტექნიკა კინემატოგრაფიაში, როდესაც ვიდეოს ნაცვლად ძალიან ბევრ კადრს იღებენ. მაგალითად 1 წამისთვის 12-24 კადრს და თითოეულ მათგანში ობიექტ(ებ)ის მდგომარეობა სულ ოოოდნავ არის შეცვლილი. შედეგად, კადრების გადაბმით ანიმაცია გამოდის.

Credit: Jason Ptaszek / LAIKA, Inc.
Credit: Jason Ptaszek / LAIKA, Inc.

ზუსტად ასეთი მეთოდის გამო, ბევრი რამე ძალიან რთული გასაკეთებელია, განსაკუთრებით სახის მოძრაობა, საუბარი, ემოციები. ანიმატორები ერთი კვირის განმავლობაში დაახლოებით 4-5 წამის ვიდეოს ქმნიდნენ.

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

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

 

ცეცხლი, წყლის ათინათები, ტანსაცმლის დიზაინი, უამრავი წვრილმანი დეტალი…

 

ერთ-ერთი რევოლუციური ნაწილი მათ ნაშრომში 3D ბეჭდვის გამოყენებაა. თქვენი აზრით როგორ აკეთებენ სახის ანიმაციას? ყოველი კადრისთვის შესაბამის სახეს (ან თავს) ბეჭდავენ და მერე ობიექტს წამში 24-ჯერ უცვლიან სახეს :))

faces

მოკლედ, შემოქმედების ზეიმია ეს ფილმი 🙂

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

 

 

ისე, ძველი ქართული მულტფილმებიდანაც ბევრი stop-motion ტექნიკით იყო მგონი გადაღებული, გარეგნულად თითქოს ეგრეა. მაგალითად ბომბორა, კომბლე, საზამთრო… არა?

 

რატომ PHP?

14 კომენტარი

threads

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

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

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

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

Java EE-ში რიქვესთების საპასუხოდ პროგრამისტები ვწერთ სერვლეტ კლასებს, იქ კი instance ცვლადების გაკეთება არ არის კარგი. იცით რატომ? იმიტომ რომ თითო სერვლეტის ერთი ობიექტი გამოიყენება ყველა რიქვესთის საპასუხოდ (მთლად მაგაზე დაყრდნობაც არ შეიძლება, რადგან კონტეინერი აკონტროლებს როდის მოკლას ან ჩაანაცვლოს ის ინსტანსი). სტატიკური რაღაცები, სინგლტონ კლასები – ყველაფერი ჩვეულებრივ არსებობს აპლიკაციაში და shared არის მომხმარებლებს შორის. სპეციალურადაც კი არის ობიექტი – ‘აპლიკაციის კონტექსტი’ რომელიც სერვლეტებს შორის shared მონაცემებს დაატარებს და არაერთ best practice-ში გამოიყენება, თუნდაც რაღაც ობიექტების კეშირებისთვის. ამ ყველაფერს კი სჭირდება სინქრონიზაცია. უნდა იცოდეს პროგრამისტმა რა ბიბლიოთეკები და კლასებია thread-safe, იცოდეს კოდის რა ნაწილი მოხვდება ცალკე ნაკადში და რა ნაწილი იქნება გაზიარებული. მერე შესაბამისად lock-ებით და სინქრონიზაციის სხვადასხვა მექანიზმებით უნდა აკონტროლოს ეს ყველაფერი.

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

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

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

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

მეორე გახდა node.js, რომელზეც ქვევით ვიტყვი უფრო დეტალურად.

როცა PHP-ის ვებ სერვერზე ვიყენებთ, უმეტეს შემთხვევაში ისე ვაკონფიგურირებთ რომ ის არ ინახავს არანაირ state-ს. თუ CGI-ის, FastCGI-ის ან Apache-ს Prefork რეჟიმს გამოვიყენებთ, სერვერთან მოსული თითოეული რიქვესთისთვის ახალი პროცესი გაეშვება და მარტო ერთ ნაკადში შესრულდება php-ის კოდი. მაშინაც კი თუ php-ის კომპილირებული ფაილების კეშირებას ვაკეთებთ, სკრიპტის თითოეული ინსტანსი მაინც ცალკე შეიქმნება და ფიზიკური მეხსიერებაც ცალკე გამოეყოფა.
თურმე სახელიც ჰქონია ასეთ მიდგომას – Shared nothing architecture.

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

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

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

ისიც მესმის, რომ ნელ-ნელა გარდაუვალი გახდება წარმადობაზე ფიქრი და წინსვლისთვის მაინც მოგვიწევს ისეთი პროგრამების შექმნა, რომლებიც ბევრი პროცესორისთვის და ბევრი ნაკადისთვის იმუშავებს, მაგრამ რაღაცნაირად იმედი მაქვს რომ იქნება რაღაც იდეები (მაგალითად როგორც node.js ან როგორც nosql ბაზები) და ნაწილობრივ მაინც მოგვაცილებენ shared state-ის თავისტკივილს.

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

ჯავასკრიპტის ხრიკები

გამოხმაურება
ფოტო jstips-დან

jstips-header-blog

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

1. როგორ ჩაწერდით false-ს ორი სიმბოლოთი? true-ს?

!1 false, !0 true

2. როგორ შეამცირებდით ამ კოდს?

if (a) b();

ამათ?

if (!a) b();

if (a) {
b = 1;
c = 2;
}

&& და || ჯავასკრიპტშიც short-circuit ოპერატორებია, ანუ გამოსახულების შესრულებისას როგორც კი ცხადი გახდება შედეგი, შემდეგ აღარ გრძელდება დანარჩენი ნაწილების ევალუაცია, ფუნქციების გამოძახება, ა.შ. ამიტო if-ის მაგივრად შეგვიძლია დავწეროთ a&&b().
მეორე შემთხვევაში იქნება a||b().
მესამე შემთხვევაში დიდი არაფერი ხდება, უბრალოდ მინიმიზატორები ხშრად ერთ ბრძანებად აერთიანებენ ყველაფერს და მძიმით გამოყოფენ. მერე ბლოკების გაკეთება აღარ უწევთ.
if (a) b=1, c=2

3. ყველაზე მოკლედ როგორ შეამოწმებთ ასეთ რამეს ცვლადისთვის: თუ ცვლადი არის undefined, 0, false, “”, null ან NaN – ყველა ამ შემთხვევაში დააბრუნოს false, წინააღმდეგ შემთხვევაში true.
(ეს მინიმიზატორში არ იყო, უბრალოდ კოდში ხშირად კარგად გამომდგომია).

bool ტიპად გადაქცევით: result = !!a

4. როგორ შეამცირებდით ამ ნაწილს? ვთქვათ რაღაც arg-ის ვალიდაციას აკეთებთ და თუ არაა განსაზღვრული, default მნიშვნელობას ანიჭებთ. ესეც არ არის მინიმიზატორში.

var options = (arg) ? arg : [];

ჯავასკრიპტში && და || ცოტა არასტანდარტულად იქცევიან – boolean-ს კი არ აბრუნებენ შედეგად, არამედ იმ ოპერანდს, რომელიც გამოსახულების ბედს გადაწყვეტს.
მაგალითად 1 && 0 && false დააბრუნებს 0-ს.

შესაბამისად ის გამოსახულება უფრო ლამაზად შეგვიძლია ასე ჩავწეროთ

var options = arg || [];

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

მოდი ჯერ პირდაპირ დავწერ. ქვემოთ დამრგვალებისთვის არსებობს ფუნქცია Math.floor(), თუმცა ეს სტანდარტულად ამრგვალებს negative infinity-ისკენ. ანუ 12.6 გადავა 12-ში, მაგრამ -12.6 გადავა -13-ში. ამ კითხვის პასუხში ეგ შემთხვევა არ გაითვალისწინება (და ისედაც მე პირადად უფრო ხშრად ნოლისკენ დამრგვალება უფრო მჭირდება, რომ -12.6 გახდეს -12, რადგან ნიშანი სხვა დატვირთვით მაქვს ხოლმე).
ჰოდა გამოვიდა შემდეგი:

foo > 0 ? Math.floor(foo) : Math.ceil(foo)

თუ არ ვართ დარწუნებული რომ foo რიცხვი იქნება და NaN-ის მიღება არ გვინდა, მაშინ შემოწმებების დამატება მოგვიწევს:

typeof foo === 'number' && !isNaN(foo) && foo !== Infinity
? foo > 0 ? Math.floor(foo) : Math.ceil(foo) : 0;

ჰოდა ახლა ეს ყველაფერი ჩავწეროთ ორი სიმბოლოთი 🙂 foo-ს გარდა ცხადია

ბინარული ოპერაციები დაგვიჭრდება აქ, ორი ვარიანტი გვაქვს – ორმაგი ბინარული უარყოფა ან ბინარული ‘ან’ ნულთან.
~~foo
foo|0

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

5. 1000000, 0.0000023 და სხვა ბევრ ნულიანი რიცხვების დაპატარავება

1e6, 23e-7 – ნულების თვლა ცუდია 😀