@OneToMany ანოტაცია

ვაგრძელებთ ისევ Hibernate-ს ანოტაციების განხილვას და ამ პოსტში განვიხილოთ @OneToMany ანოტაცია. Hibernate-ში @OneToMany ანოტაცია განსაზღვრავს ერთი ბევრთან კავშირს. მაგალითად ერთ პიროვნებას აქვს ბევრი ტელეფონის ნომერი. თუმცა ამ ანოტაციასთან ერთად გამოიყენება @JoinColumn ანოტაცია, რომელიც განსაზღვრავს იმას, რომ ეს კონკრეტული entity (რომელშიც ეს ანოტაცია წერია) არის კავშირის მფლობელი (owner). ხოლო ატრიბუტი, mappedBy მიუთითებს იმაზე, რომ entity ამ მხარეში არის კავშირის უკუგება, ანუ სხვა სიტყვებით რომ ვთქვათ, ეს entity არ არის კავშირის „მფლობელი“ (owner). ამ კავშირის დროს გვაქვს კიდევ ერთი fetch ატრიბუტი, რომელიც განსაზღვრავს კავშირის დამყარებას როგორ ჩაიტვირთოს დაკავშირებული ობიექტი. მაგალითად, თუ Person კლასს აქვს PhoneNumber-ების სია თავის ველად, და fetch არის default, ანუ Lazy, მაშინ Person-ების გამოტანისას არ წამოყვება ტელეფონის ნომრები და ეს წამოღება მხოლოდ მაშინ მოხდება, როცა უკვე მივმართავთ ტელეფონის ნომრებს. ვნახოთ რა ხდება ამ დროს SQL-ში. 

Main-ში უბრალოდ ვეძებთ პიროვნებას, რომლის ID არის 1 და ვბეჭდავთ მის ტელეფონის ნომრებს (ამ შემთხვევაში მთავარი ისაა, რომ ამ ველს მივმართავთ)

ახლა ვნახოთ რა Query გაეშვა მონაცემთა ბაზაზე 

როგორც ხედავთ გაეშვა ორი Query: ერთ პიროვნების წამოღება და მეორე პიროვნების მიხედვით ტელეფონის ნომრების წამოღება. ახლა ვნახოთ რა მოხდება თუ fetch-ს გავხდით EAGER-ს.

როგორც სურათიდან ჩანს, ორი Query-ის მაგივრად გაეშვა ერთი და ტელეფონების ნომრები წამოიღო პიროვნების წამოღებასთან ერთად. ანუ ეს Query შეიცავს დაკავშირების ბრძანებასაც LEFT OUTER JOIN

მე, LUXOFT და კრაკოვი

დღეს, კრაკოვის დროით ჯერ კიდევ ოთხშაბათია, 2017 წლის 21 ივნისი. გუშინ ზუსტად 1 თვე გავიდა მას შემდეგ რაც კრაკოვში სრულიად მარტო ვცხოვრობ. არ დავიწყებ იმის მოყოლას თუ როგორ მოვხვდი აქ. 1 ივნისს დავიწყე ახალი სამსახური და აგერ უკვე 21-ე დღე დასრულდა რაც აქ ვარ. 20 მაისიდან 1 ივნისამდე პერიოდი ბინის ძებნას და ბიუროკრატიის მოგვარებასთან ერთად, ქალაქის დათვალიერებას და კარგად გაცნობას მოვანდობე. ძალიან კარგი პერიოდი იყო და ნაყოფიერი. ახალი სამსახურის დაწყებასთან ერთად, გაჩნდა ახალი „თავის ტკივილები“, რა თქმა უნდა, კარგი გაგებით. პირველი 2 კვირა დავალებები არ მქონია და დრო ნელა გადიოდა. ბოლო 2 დღეა პატარა დავალება მომცეს. დავალება, რომელიც განსაკუთრებულ ნიჭს და უნარს არ მოითხოვს. უფრო დიდ ყურადღებას მოითხოვდა და მეც რამდენიმეჯერ გადავამოწმე და ისე გავაკეთე. თუმცა ახალ, მომავალ საქმესთან გაცნობასთან ერთად გამოჩნდა, რომ სასწავლი და დასახვეწი ბევრი რამე მაქვს. რაც არ უნდა ბანალურად ჟღერდეს, ამისთვის დრო ცოტაა. დიახ, არ მეშლება. დრო ცოტაა, ძალიან ცოტა. დღეს დავფიქრდი გარკვეულ გლობალურ და გრძელვადიან გეგმებზე, რომლისთვისაც აუცილებელია დროის კარგად გადანაწილება. უკვე ძალიან დიდიხანია Daily Scheduling-ს ვიყენებ, და ასევე ყოველწლიურად 10 მნიშვნელოვან გეგმას ვისახავ ხოლმე. თუმცა მათ გადაფასება რამდენიმეჯერ მიწევს ხოლმე წლის განმავლობაში. რაც შეეხება ჩემს ახალ თანამშრომლებს და ახალ გუნდს, მათი ძალიან მადლობელი ვარ. ისინი პირველივე წუთებიდან გამოირჩეოდნენ მეგობრული დამოკიდებულებით და შეიძლება ითქვას, რომ მათ მომცეს შანსი, ჩემი დიდი ხნის ნატვრა, სამოყვარულო ფეხბურთში დაბრუნება, ამესრულებინა. ჩვენი კომპანიის გუნდი, პოლონეთს ბიზნეს ლიგას თამაშობს და რომ ვთხოვე მეც მინდა თამაში მეთქი, ყოველგვარი გასინჯვის გარეშე, დაუშვეს გამონაკლისი და მეორე დღესვე თამაში მათამაშეს. ახლა უკვე, ძირითადის მოთამაშედ მოვიაზრები. დიახ, რაც არ უნდა გასაკვირი იყოს, სწორედ ეს ხალხი მიდგას გვერდზე და არა მარტო მე, ყველა ახალს, რომ თავი მარტოდ არ ვიგრძნოთ. რაც არ უნდა გასაკვირი იყოს, ისინი ზოგიერთ, თუ უმრავლესობა ქართველ „მეგობრებზე“ ყურადღებიანები არიან. ახლა უკვე დროა, ავუწყო ფეხი სწრაფ განვითარებას და სპორტულ და ჯანსაღ ცხოვრების სტილთან ერთად, კარიერულ წინსვლაზე და პერსონალურ განვითარებაზე ვიფიქრო, რომლისთვისაც დრო ძალიან ცოტა გვაქვს ყველას, როგორც უკვე აღვნიშნე. დიახ, ეს ქვეყანა ძალიან მომწონდა, მაგრამ როცა პირადად გამოვცადე აქ ცხოვრება, უფრო მომწონს და მიყვარს თავისი ხალხით და თავისი ღირებულებებით. 

@Embedded ანოტაცია

ვაგრძელებთ წინა პოსტში განხილულ თემატიკას და ამ პოსტში გაგაცნობთ Hibernate-ს @Embeddable და @Embedded ანოტაციებს, რომლებიც საქმეს ერთად აკეთებენ. სანამ უშუალოდ მაგალითზე გადავიდოდე, მოვიყვან შემთხვევას როდის შეიძლება გამოვიყენოთ ეს ანოტაციები. მაგალითად, გვაქვს Person კლასი შესაბამისი ცხრილით მონაცემთა ბაზაში. დავუშვათ, რომ ამ ცხრილში ინახება ადამიანის მისამართი რამდენიმე ველის სახით. მაგალითად: საფოსტო კოდი, ქალაქი, ქვეყანა, ქუჩა. ცხადია, რომ ოთხი სხვადასხვა ველით წარმოდგენა არც ისე დიდი პრობლემაა, მაგრამ რას იტყოდით, ამ ველების ერთ Address ობიექტში "გახვევაზე" ? ანუ მონაცემთა ბაზაში ასე ცალ-ცალკე ველად იქნება, მაგრამ ჯავას კოდში ამ ოთხ ველზე ვიმოქმედებთ როგორც Address კლასზე. შემდეგი სურათები გვიჩვენებს სწორედ ამ მაგალითს.  ჩვენ აღვწერთ Address კლასს შესაბამისი ველებით და ამ კლასს თავზე დავაწერთ @Embeddable ანოტაციას. შემდეგ Address კლასის ტიპის ველი გვექნება Person კლასში და ამ ველს დავაწერთ @Embedded ანოტაციას.

@MappedSuperclass ანოტაცია

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

მაშ ასე, მოდით დავიწყოთ @MappedSuperclass-ით. თითქმის ყველა აპლიკაციაში, რომელიც იყენებს მონაცემთა ბაზებს, ყველა ცხრილში გვაქვს ისეთი ველები, რომლებიც არის საერთო. მაგალითად, პირადი გამოცდილებიდან რომ გითხრათ, თითქმის ყველა პროექტში, ყველა ცხრილში მქონდა შემდეგი სამი ველი : CREATE_DATE, UPDATE_DATE, USER_ID. ამ შემთხვევაში თავი დავანებოთ იმას, რომ ყველა ცხრილს აქვს Primary Key და სიმარტივისთვის შეგვიძლია ყველა ცხრილში მას ID დავარქვათ და გამოვიყენოთ ასევე ზემოთ ხსენებული ანოტაცია. მოკლედ, თუ თქვენც გქონიათ ასეთი შემთხვევა, ალბათ ძალიან მოგბეზრებიათ თითოეული ცხრილის შესაბამის Entity-ში ამ სამი ველის აღწერა (ჩაკოპირება). ჯავა და კერძოდ Hibernate ამ მოსაბეზრებელი საქმის მოგვარებაში გვეხმარება @MappedSuperclass ანოტაციით. იდეა მდგომარეობს იმაში, რომ აღვწერთ კლასს, რომელშიც აღვწერთ საერთო ველებს და ამ კლასს დავაწერთ ზემოთ ხსენებულ ანოტაციას. შემდეგ ყველა Entity-ის გავხდით ზემოთ ხსენებული კლასის მემკვიდრეს. მოდით ვნახოთ მაგალითზე. საერთო ველების მქონე კლასს მე CommonFields-ს დავარქვი. ვთქვათ მაქვს ორი Entity: Person და Product.

აქვე დავაანონსებ, რომ შემდეგ პოსტსაც Hibernate-ის ანოტაციაზე შემოგთავაზებთ. 

ცხოვრება როგორც სახლის აშენება

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

Java StreamAPI Examples

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

• Sequence of Elements  - Stream გვაძლევს კონკრეტული ტიპის ელემენტების მიმდევრობას და მას შეუძლია ელემენტის ამოღება და გამოთვლა მოთხოვნების შესაბამისად. ის არასდროს ინახავს ელემენტს.
• Source - Stream იღებს კოლექციებს, მასივებს, I/O რესურსებს, როგორც მისი input.
• Aggregate Operations - Stream-ს შეუძლია განახორციელოს ისეთი აგრეგაციული ოპერაციები, როგორებიცაა: filter, map, limit, reduce, find, match და ა.შ. 
• Pipelining - უმრავლესობა Stream-ის ოპერაციებისა, აბრუნებს ისევ Stream-ს, ასე რომ ისინი შეიძლება გამოყენებული იყოს როგორც pipeline. ასეთ ოპერაციებს შუალედური ოპერაციები ეწოდება და მათი ფუნქციაა მიიღოს input, დაამუშავოს და დააბრუნოს output თავის ადრესატთან, target-თან. collect() მეთოდი არის ტერმინალური ოპერაცია რომელიც როგორც წესი pipelining-ის ბოლოში გამოიყენება და აღნიშნავს stream-ის დასრულებას. 
• Automatic iterations - Stream ოპერაციები იტერაციას აკეთებს ავტომატურად source ელემენტებზე, რაც კოლექციების შემთხვევაში შეუძლებელი იყო.

Stream-ის მიღება ჯავაში ორი მეთოდით შეიძლება, ესენია : Stream კლასის სტატიკური მეთოდებით, ან Collection Framework-ში განსაზღვრული მეთოდებით.

ახლა განვიხილოთ Stream-ებზე, რამდენიმე მაგალითი და აგრეგაციული ფუნქცია:

forEach

Stream გვთავაზობს forEach მეთოდს, რომელიც მისი თითოეული ელემენტის გადავლას ახორციელებს.  forEach მეთოდს არგუმენტად გადაეცემა ბრძანება, რომელიც გვეუბნება რა უნდა მოხდეს თითოეული ელემენტისთვის. 

map

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

filter

filter მეთოდი აკეთებს ელემენტების გამოხშირვას stream-დან გაკრვეული კრიტერიუმის მიხედვით.  ქვემოთ მოცემული ფრაგმენტი დათვლის ცარიელი სტრიქონების რაოდენობას. filter პარამეტრად იღებს პრედიკატს. 

parallel processing

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

Collectors

კოლექტორები გამოიყენება რეზულტატების კომბინირებისთვის/შეერთებისთვის. კოლექტორები გამოიყენება List-ის ან String-ის დასაბრუნებლად.

SOLID - პირველი 5 პრინციპი ობიექტზე ორიენტირებულ პროგრამირებაში

S.O.L.I.D არის აკრონიმი პირველი 5 პრინციპისა ობიექტზე ორიენტირებულ პროგრამირებაში. ამ პრინციპების კომბინირებით, პროგრამისტს შეუძლია ადვილად განავითაროს თავისი პროგრამული უზრუნველყოფა და მომავალში დაამატოს სხვა ფუნქციონალი.

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

S – Single-responsibility principle

O – Open-closed principle

L – Liskov substitution principle

I – Interface segregation principle

D – Dependency Inversion principle

ახლა სათითაოდ განვიხილოთ თითოეული მათგანი.

Single-responsibility Principle (S.R.P) - კლასს უნდა ჰქონდეს ერთი და მხოლოდ ერთი მიზეზი იმისთვის, რომ შეიცვალოს, ანუ ეს გულისხმობს, რომ კლასი უნდა ასრულებდეს მხოლოდ და მხოლოდ ერთ დავალებას.

Open-closed principle გულისხმობს, რომ ობიექტები (ან Entity-ები) უნდა იყოს ღია გაფართოებისთვის მიზნებისთვის, მაგრამ დახურული ცვლილებების მიმართ. ანუ სხვა სიტყვებით რომ ვთქვათ, კლასი  ადვილად უნდა ფართოვდებოდეს ამ კლასშივე ცვილებების გარეშე.

Liskov substitution principle - ყველა ქვეკლასი/შვილი კლასი უნდა იყოს შემცვლელი მისი base/მშობელი კლასის.

Interface Segregation principle (ISP) - გულისხმობს იმას, რომ არცერთ კლასს არ უნდა ჰქონდეს ვალდებულება დააიპლმენეტიროს მეთოდი, რომელიც არ სჭირდება მას, ანუ არცერთი კლასი არ უნდა იყოს დამოკიდებული მისთვის არასასურველ მეთოდზე. მაგალითად, გვაქვს ShapeCalculator კლასი, რომელიც სხვადასხვა სახის ფიგურების ფართობების ჯამს ითვლის და გვაქვს ShapeInter ინტერფეისი, რომელსაც აქვს area() მეთოდი. Square კლასი, რომელიც აიმპლემენტირებს ShapeInter ინტერფეისს თავისთვის განსაზღვრავს area() მეთოდს და მისი გამოთვლის წესს. ახლა ვთქვათ გვინდა მოცულობების ჯამის გამოთვლაც. ჩვენ თუ ShapeInter ინტერფეისში დავამატეთ volume() მეთოდი, მაშინ გამოვა, რომ Square-ს არ აქვს მოცულობა, რადგან ორგანზომილებიანი ფიგურაა და ტყუილად მოგვიწევს ამ კლასში არასასრუველი მეთოდის იმპლემენტირება. ამისთვის, ჩვენ უნდა შევქმნათ სხვა ინტერფეისი, მაგალითად ThreeDimShapeInter და იქ გვქონდეს volume() მეთოდი.

Dependency Inversion principle  გვეუბნება, რომ Entity-ები უნდა იყვნენ დამოკიდებულები აბსტრაქციებზე და არა კონკრეტიკებზე. High Level მოდული არ უნდა იყოს დამოკიდებული Low Level მოდულზე, მაგრამ ორივე შეიძლება დამოკიდებული იყოს აბსტრაქციებზე. მაგალითად, გვაქვს PasswordReminder კლასი და მას აქვს property სახელად connection, რომელიც მონაცემთა ბაზასთან კავშირისთვის გამოიყენება. რადგან Connection არის low level და  PasswordReminder არის high level, ასეთი სტრუქტურა დაარღვევს Dependency Inversion პრინციპს. თუ მოგვიწევს სხვა მონაცემთა ბაზასთან კავშირი, მოგვიწევს PasswordReminder კლასსის ცვლილებაც, როცა მას სულ არ უნდა აინტერესებდეს რომელ მონაცემთა ბაზას ვიყენებთ. ანუ უნდა გავაკეთოთ ინტერფეისი DBConnection და მისი იმპლემენტატორი კლასი, რომელშიც ეწერება ის ლოგიკა, რომელიც დაგვეხმარება მონაცემთა ბაზასთან კავშირში, ხოლო PasswordReminder კლასში connection property იქნება ინტერფეისის ტიპის.

Connecting the dots ანუ მოვლენების კავშირი ერთმანეთთან

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

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

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

ნაჩუქარი 1/4 ფინალი თუ ვიდეო Referee-ის საჭიროება ?

  ფეხბურთის გულშემატკივარს ალბათ არასდროს დაავიწყდება 2016/17 წლის ჩემპიონთა ლიგის 1/8 ფინალური დაპირისპირება ბარსელონასა და პსჟ-ს შორის. ამ გუნდებს შორის პირველი დაპირისპირება პარიზულმა გუნდმა საფრანგეთის დედაქალაქში 4-0 მოიგო და ფაქტობრივად უშანსოდ იყო კატალონიაში ბარსელონა.

რა მოხდა კატალონიაში ? ბარსამ სწრაფი გოლი გაიტანა, მთელი თამაში დომინირებდა, პირველი ტაიმი 2-0 მოიგო და მეორე ტაიმში მოედანზე იმედიანად გამოვიდა. მეორე ტაიმის დასაწყისშივე კატალონიელებმა მე-3 გოლი გაიტანეს და უფრო დიდი შანსი მიეცათ. თუმცა ეს მესამე გოლი 11 მეტრიანი დარტყმით გავიდა და ნეიტრალური გულშემატკივრის თვალით რომ შევხედო ამას, შეიძლებოდა ამის არ დანიშვნა, რადგან მსაჯმა ნამდვილად დასადები პენლები არ დადო ორივე კარში და ასეთი პენლის დადება ცოტა საკამათო იყო. იმედიან ბარსელონას შანსები გაუქრო კავანის გოლმა, რომელმაც 3-1 გახადა ანგარიში და ახლა კატალონიელებს მინიმუმ 3 გოლი უნდოდათ. მატჩის ძირითადი დროის ბოლო 10 წუთში ნეიმარმა მე-4 გოლი გაიტანა და ბარსას იმედი გაუჩნდა, ამას მოყვა ის, რომ სრულიად სულელური 11 მეტრიანი დაინიშნა პსჟ-ს კარში (ამას არა მარტო ნეიტრალური გულშემატკივარი, არამედ ფეხბურთის მცოდნე ბარსელონას ფანიც კი აღიარებს) და ანგარიში 5-1 გახდა. ბარსელონას საწადელის მიღწევამდე ერთადერთი გოლი აკლდა და მატჩის 95-ე წუთზე ფსიქოლოგიურად გატეხილ პსჟ-თან ესეც მოახერხეს და საბოლოოდ ისტორიაში შევიდნენ, როგორც 4-0 ის მერე come back-ის გამკეთებლები.

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

12 Tips For IELTS Speaking Test

1) Be formal - like a job interview, take it serious, don't take it casually

2) Give a full answer - for example, if examiner ask you: Where are you from ? Don't answer : Tbilisi. Instead of it, answer : I am from Tbilisi, the capital of Georgia.

3) Be polite/cultured - if you don't understand examiners question, ask him/her in polite way.
WRONG : What ? Sorry ?
CORRECT : Excuse me, could you please repeat that ?

4) Maintain good posture - your posture affects the way you speak. Don't put your hand near your face.

5) Speak clearly - Don't worry too much about your accent. Enunciate words clearly. Speak as clear as possible.

6) Use descriptive words - use dynamic words.

7) Speak up - speak loudly

8) Keep a steady pace - don't speak too fast. Don't speak too slowly. If you aren't sure how fast you should speak, speak slower  than you think is necessary because that way much more likely you will be understood.

9) Explain foreign words

10) Stay on topic

11) Don't use slang - use children instead of kids. Use items instead of things.

12) Don't memorize model answers

შეზღუდული შესაძლებლობების მქონე ადამიანი, ანუ სითბოს უანგარო გამომცემი

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

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

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

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

რატომ ჩავაბარე Computer Science-ზე და არა იურიდიულზე

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

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

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

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