დიდი ხანი არ არის, რაც ჩემი ძველი მობილური ტელეფონი ისე გაფუჭდა, რომ მის გაკეთებას აზრი აღარ ჰქონდა და ამიტომ ახლის ყიდვა მომიწია. მიუხედავად არსებული iPhone-მანიისა, არჩევანი მაინც Windows Mobile-ზე შევაჩერე. ბევრი ქექვის, შედარებისა და ფიქრის შემდეგ, ჩემი რჩეული Samsung Omnia 8GB გახდა.
Samsung-ის სასარგებლოდ უნდა ითქვას, რომ ტელეფონი მართლაც რომ მშვენიერია და პრაქტიკულად ყველა ასპექტში მომწონს. ერთადერთი რაც არ მომწონს მისი მუსიკალური შესაძლებლობებია, რაც Sony Ericsson-ის W სერიის ტელეფონის რამდენიმე წლიანი გამოყენების შემდეგ გასაკვირი არც არის.
ვრცლად…
და კიდევ ერთხელ სტანდარტები! 
ვიცი რომ არავის არ გვიყვარს, ისიც ვიცი რომ თითოეულმა ჩვენთაგანმა აღმოაჩინა კოდის წერის ყველაზე ოპტიმალური და სწორი ვარიანტი, ფორმატირების ყველაზე მოსახერხებელი სტრუქტურა. ისიც ვიცი რომ თითოეული ჩვენთაგანის მიერ დაწერილი კოდი არ საჭიროებს კომენტირებას, რადგანაც ის თავისთავადაა ერთი დიდი კომენტარი, რადგანაც საოცრად გასაგები და ბუნებრივია. ეს ყველაფერი ვიცი, განა მეც ერთ-ერთი თქვენთაგანი არ ვარ? მაშინ რატომ ვდარდობ? ვდარდობ იმიტომ, რომ როცა საკუთარი კოდის გარდა სხვის კოდთან მუშაობა გიწევს და როცა ეს “სხვა” არა ერთი, არმედ რამოდენიმე ადამიანია, ხვდები რომ ამდენი გენიოსის მიერ დაწერილი კოდის გასარჩევად უბრალოდ რესურსი აღარ გყოფნის
ვრცლად…
რაც უფრო გადის დრო, ვრწმუნდები რომ Google ნელ-ნელა უახლოვდება იმ კომპანიას, რომელიც არა მხოლოდ ფულს აკეთებს ხალხზე, არამედ ხალხსაც ეხმარება იმის გაკეთებაში, რაც ამ უკანასკნელს სურს და რაოდენ საოცრადაც არ უნდა ჟღერდეს, ეს გამოსდის, თან არაჩვეულებრივად
ალბათ დაახლოებით 1,5-2 წლის წინ რომ დამეწერა ის, რის დაწერასაც ახლა ვაპირებ, ბევრისათვის ახალი იქნებოდა, მაგრამ დღეს დარწმუნებული ვარ უამრავი ადამიანი იცნობს Google Applications სერვისს. საქმე იმაშია, რომ მე რატომღაც მთელი ეს პერიოდი ვერ ვახერხებდი თავი მომება და ჩავჯდომოდი ამ საკითხს, შესაბამისად, ჩემი ცოდნაც 0-ზე იყო და მხოლოდ “იცი რა მაგარია?” ტიპის შეფასებების მოსმენით შემოიფარგლებოდა. ბოლო ხანებში კი რაღაც შემიჩნდა და უფრო კარგად გავეცანი ყველაფერს. შედეგად ახლა ამას ვწერ
ვრცლად…
თუ ერთხელ მაინც არ შეგქმნიათ ბროუზერებს შორის თავსებადობის პრობლემა, ორი ვარიანტია: ან თქვენ ვებთან შეხება არ გაქვთ, ან თქვენ ლელა კაკულია გმფარველობთ
მოკლედ ყველასთვის ნაცნობია თავის ტკივილი, სახელად “ბროუზერებს შორის თავსებადობა” და ამ პრობლემასთან ბრძოლაში გატარებული უამრავ საათიც კარგად გახსოვთ… მაგრამ სხვადასხვა ბროუზერებს შორის თავსებადობაზე რა უნდა ილაპარაკო, როცა IE-ს ვერსიებს შორისაც კი განსხვავებულ რენდერინგს ვხვდებით და რეალურად ერთი და იგივე CSS-ით გაფორმებული HTML სხვადასხვაგვარად გამოიყურება.
ვრცლად…
აი დადგა ნანატრი მომენტი, როცა ჩვენ ბოლოს და ბოლოს უნდა გავარკვიოთ რა არის და ვინ იმალება ამ მაგიური სეიტყვა “სერვერი”-ს მიღმა! ალბათ ძალიან არ შევცდები, თუ ვიტყვი, რომ სერვერი, ეწოდება კომპიუტერს, რომელიც ჩართულია ქსელში (არა აუცილებლად ინტერნეტში) და მუდმივი მოსმენის რეჟიმშია. მოსმენის რეჟიმში ყოფნა იმას ნიშნავს, რომ სერვერი “ელოდება” მოთხოვნებს დანარჩენი სამყაროდან, ანუ კლიენტებისაგან და მოსულ მოთხოვნებზე შესაბამის პასუხს სცემს. რეალურად სერვერიც უბრალო კომპიუტერია (ნუ თუ შეიძლება ნახევარმილიონიან სერვერს ჩვეულებრივი ეწოდოს :D) რომელიც კონკრეტული ამოცანის შესრულებაზეა ორიენტირებული. სერვერები რომ რაღაც მითიური კომპიუტერები არ გეგონოთ, გეტყვით რომ სერვერის შეძენა შეიძლება დაწყებული 2000$-დან, დამთავრებული რამდენი ათასი$-იც გაგიხარდებათ, იმდენით ცხადია ფასები ცოტა არაკორექტულია და შეიძლება 1000$-დ იყიდოთ, მაგრამ ამ შემთხვევაში ეს გადამწყვეტი არ არის სერვერები, გამომდინარე თავისი დატვირთვიდან, სხვადასხვა კომპლექტაციის არსებობს. ზოგს ოპერატიული მეხსიერება ჭირდება ბევრი, რეალურ დროში მონაცემებთან სამუშაოდ, ზოგს მძლავრი პროცესორ(ებ)ი, დიდი გათვლების გასაკეთებლად, ზოგსაც დიდი მოცულობის მყარი დისკი, ინფორმაციის შესანახად.
ვრცლად…
ამ წინა საახალწლო პერიოდში, პრობლემებმა კვლავ იჩინა თავი და კვლავ მომიწია მცირედი კვლევების ჩატარება ამ საკითხთან დაკავშირებით. შესაბამისად გადავწყვიტე ბლოგის სტუმრებსაც გაგიზიაროთ არსებული პრობლემის არსი და მისგან გამოსავალი.
როგორც ადრ ვყვებოდი, თემაში SQL Server 2005 და მისტიური Error 701 32 ბიტიან ოპერაციულ სისტემაში, სერიოზული პრობლემები შეიძლება შეგექმნათ მეხსიერებასთან დაკავშირებით. იქვე ნახავდით გამოსავალსაც, რომელიც იმ დროს ვიპოვნე. საქმე იმაშია, რომ გამოსავალმა თითქოს ყველაფერს უშველა, მაგრამ ბოლო პერიოდში მსგავსი შეცდომები იშვიათად, მაგრამ მაინც ხდებოდა და შემდეგ ლოგში დიდი ოდენობით რეგისტრირდებოდა AppDomain xxx is marked for unload due to memory pressure. ტიპის შეცდომები. საბოლოო ჯამში ერთადერთი გამოსავალი სერვერის გადატვირთვა იყო.
ვრცლად…
როგორც ჩემს წინა პოსტში ვწერდი, SQL 2005–ზე, თუ ის 32 ბიტიან სისტემაზე დგას და გააქტიურებული აქვს AWE, კონკრეტულ მომენტებში საკმაოდ უსიამოვნო შეცდომა იჩენს თავს და ამ დროისათვის პირდაპირი FIX არ არსებობს. იქვე ავღნიშნე, რომ Pinal Dave–ს ბლოგზე გამოსავალის სახით Max Server Memory–ს ხელით მითითება იყო შემოთავაზებული.
ვრცლად…
ვაგრძელებთ თემებს ციკლიდან “ოჰ ეს Microsoft” 
არ ვიცი თქვენ რამდენად შეხებიხართ/გაწუხებთ ეს პრობლემა, მაგრამ ბოლო პერიოდია, ერთ–ერთ სერვერზე, ბაზის სრული სარეზერვო ასლის შექმნა კრახით სრულდება და ლოგებში ერთადერთი ეს ჩანაწერი მხვდება:
There is insufficient system memory to run this query.
საქმე იმაშია, რომ სარეზერვო ასლის შექმნამდე, ეშვება Database Integrity Check–ი და შეცდომაც სწორედ მანდ ხდება, პროცესი ჩერდება და ასლი არ იქმნება. სარეზერვო ასლი სარეზერვო ასლად ცალკე საკითხია, მაგრამ ისიც გაითვალისწინეთ, რომ როგორც კი ეს შეცდომა ხდება, MS SQL სერვერი არამდგრად მუშაობას იწყებს და ძალიან არაადექვატურად იქცევა, იზრდება ტრანზაკციების რიცხვი, პრობლემები იქმნება CLR პროცედურებთან და ა.შ. მოკლედ სანამ სერვერის რესტარტი არ მოხდება, აღარ შველის არაფერი…
ვრცლად…
2009 წელი კარს მოგვდგომია და ის დროა MS SQL 2008–ს ახალი შესაძლებლობებით აღფრთოვანებულები ტაშის კვრაში ვიყოთ, მაგრამ პირადად მე MS SQL 2005–ის შესაძლებლობებში გაპარული ლაფსუსებით უფრო ვარ იმედგაცრუებული.
შეცდომა ვის არ მოსვლიაო ნათქვამია და არც Microsoft–ია გამონაკლისი, კაცმა რომ თქვას არც შეცდომაა ისეთი კრიტიკული, რომ ორგანიზაციის ფუნქციონირებას რეალური საფრთხე შეუქმნას, მაგრამ მაინც გულდასაწყვეტია, რომ პროგრამულ კოდში გაპარული პაწია შეცდომის გამო დეველოპერები იძულებული ხდებიან არ გამოიყენონ მთელი სიძლიერით MS SQL 2005-ის ისეთი მშვენიერი საშუალება, როგორიც გახლავთ Automatic Failover–ი გააქტიურებული Mirroring–ისას.
ვრცლად…
ვიდრე შემდეგ ეტაპზე გადავიდოდეთ და სერვერების განხილვას დავიწყებდეთ, მანამდე ზედაპირულად მაინც უნდა განვიხილოთ კავშირისა და დამისამართების ელემენტარული საწყისები, რაც საფუძველში უდევს ნებისმიერ პროტოკოლსა თუ სერვერის მუშაობას.
მაშ ასე, წარმოვიდგინოთ რომ გვაქვს ორი დაშორებული კომპიუტერი, ერთი თბილისში, მეორე იამაიკაზე (მაინც წავალ მაქ :P). ორივე ჩართულია ინტერნეტში. ჩვენი ამოცანაა, თბილისში არსებული კომპიუტერიდან რაღაცნაირად მოვახერხოთ იამაკაზე არსებულ კომპიუტერში ინფორმაციის გადაცემა. აი მანდ იწყება ყველაზე საინტერესო. მარტო ის ფაქტი, რომ ეს ორი კომპიუტერი ინტერნეტშია ჩართული (თუნდაც პირდაპირ იყოს მიერთებული ერთმანეთთან ერთი გრძელი კაბელით) არაფერს არ ნიშნავს, გვჭირდება მექანიზმები, რომლებიც საშუალებას მოგვცემს გადავცეთ ინფორმაცია ერთი კომპიუტერიდან მეორეს და არა მხოლოდ გადავცეთ, არამედ დავრწმუნდეთ რომ მეორეზე ეს ინფორმაცია კორექტულად მივიდა.
ვრცლად…