مزايا و عيوب Windows 8.x (2- العيوب)

هذا هو المقال الثاني من مقالين متصلين أتحدث فيهما عن أنظمة تشغيلWindows 8.x (أي نظام Windows 8 و تحديثاته التالية و علي رأسها Windows 8.1)، و قد خصصتُ المقال الأول لأتحدث فيه عن الميزات التي أراها في النظام، و خصصتُ هذا المقال الثاني لأتحدث عن العيوب التي أراها فيه. و كما أوضحتُ في المرة السابقة فإن المميزات التي أوردتُها و العيوب التي سأوردها تخضع لوجهة نظري و آرائي الشخصية، و تتأثر بتجربتي للنظام علي مدي تسعة عشر شهراً كل التأثر. لذا فلا مشكلة أن تكون لديك انطباعات مختلفة نظراً لاختلاف ظروف تجربتنا للنظام.

مزايا و عيوب Windows 8.x (1- المزايا)

 

مقدمة

من بين كل إصدارات نظام التشغيل Windows أظن أن نظام Windows 8 من أكثر الإصدارات إثارة للجدل (يشترك في المركز الأول مع Windows Vista من وجهة نظري)؛ فما بين رغبة Microsoft في بناء نظام تشغيل موحد يعمل علي مختلف أنواع الأجهزة، و ما بين رغبة المستخدمين القدامي في الحفاظ علي نفس الشكل بدون تغيير، و رغبة المستخدمين الجدد في شكل مختلف يتناسب مع الاحتياجات المعاصرة و تجربة الاستخدام المختلفة عن كل ما هو قديم، صارت الأمور عكس ما ترغب فيه Microsoft.

 

الغريب في الأمر أنني قديماً لم أكن أميل إلي أنظمة الـWindows و كنتُ أفضِّل (و لا زلتُ) توزيعة Kubuntu عليهن جميعاً، و أري أنها تعطيني كل ما أرغب فيه من حيث القوة و الجمال و التطبيقات الناضجة المدمجة، مع قوة الأساسيات التي ورثتها من كونها مبنية علي توزيعة Ubuntu بينما كان معظم الآخرين يميلون للـWindows  و ينفرون من الـGNU/linux إلا أقل القليل، ثم حينما خرج Windows 8 للنور سارت الأمور بشكل عكسي؛ حيث نفرت منه الأغلبية، بينما ملتُ أنا إليه و أحببتُه، ثم ازداد حبي له أكثر بكثير حينما استخدمتُ Windows 8.1 !.

ابدأ التنقيح debugging باختبار الاحتمالات الأسهل في التحقق

عندما تتأكد من أن لديك مشكلة منطقية في البرنامج الذي تقوم بالعمل عليه، و حينما تقرر أن عليك البدء فعلياً بمعرفة سبب المشكلة و أصلها تمهيداً لحلها، فإن من أهم الأمور التي من الأفضل أن تفعلها في البداية هو أن تتحقق من صحة أو خطأ الأسباب التي يسهل التحقق من صحتها أو خطئها، حتي و إن كانت تلك الأسباب ضعيفة، و إمكانية أن تكون هي السبب الفعلي للمشكلة لا تُقارَن بإمكانية بقية الاحتمالات.

و السبب في ذلك أنك قد تنفق من الوقت و الجهد الكثير و الكثير؛ لتختبر الأسباب الأكثر احتمالاً أن تكون هي السبب الفعلي للمشكلة، ثم تُفاجأ في نهاية الأمر بأن السبب الفعلي كان صغيراً و تافهاً و لم يخطر لك أنه يستحق التنقيب و راءه إلا متأخراً، فتنصب حينها مخيم لوم الذات و البكاء علي اللبن المسكوب.

لذلك فمن الأفضل من البداية أن تنفق القليل من الوقت لتتأكد أن تلك الاحتمالات الصغيرة ليست هي السبب، فإن لم يكن أحدها هو السبب فأنت لم تخسر وقتاً أو جهداً كبيرين علي أية حال، أما إن كان أحدها هو السبب فقد حميتَ نفسك من اللف و الدوران و إضاعة الكثير من الوقت و الجهد بدون فائدة، و هكذا أنت الرابح في كلا الحالتين.

نصيحة ذهبية: قلل اعتماديات برامجك التي لا لزوم لها قدر الإمكان

إحدي النصائح الذهبية التي يمكنني أن أوجهها للمبرمجين الآخرين (و ربما واحدة من أفضل تلك النصائح)، هي أن يقللوا قدر الاستطاعة من الاعتماديات dependencies التي تحتاج إليها برامجهم لكي تعمل (إن كانوا لا يحتاجون لتلك الاعتماديات بشدة)، و سيكون من الممتاز ألا تعتمد تلك البرامج سوي علي المكتبة القياسية للغة البرمجة المستخدمة مع الاعتماديات التي يحتاج إليها البرنامج بحق و لا تُعتبر زيادة لا ضرورة لها.

في البداية فإن من ضمن الاعتماديات التي أتحدث عنها (و النقطة التي سنركز عليها في هذا المقال) أن يكون برنامجك يستعين بمكتبات إضافية في عمله ليست من برمجة المطورين القائمين عليه، سواء أكانت تلك المكتبات مفتوحة المصدر أو مغلقة المصدر. كأن تريد إضافة ميزة الـOCR (اختصار لـOptical character recognition) إلي أحد برامجك، و لأن هذه ميزة معقدة للغاية، فبالتالي سيكون من الأفضل بكثير أن تستعين بمكتبة خارجية لتقوم بتلك العملية، مثل مكتبة tesseract-ocr، و هكذا يمكنك أن تركز جهدك كله علي الأمور التي يتميز بها برنامجك بدون الحاجة لبناء ما بناه الآخرون بالفعل، كما أنك بهذه الطريقة ستستفيد في المستقبل من التحسينات و الإصلاحات التي يطبقونها علي مكتبتهم بدون أي جهد من ناحيتك.
 

 

هل كانت الـBasic هلي اللغة المدللة لـMicrosoft طوال تاريخها ؟

لغة الـBasic هي لغة برمجة غاية في القِدم تم تصميمها في عام 1964 علي يد "John Kemeny" و "Thomas Kurtz"، و اسمها اختصار لجملة "Beginner's All-purpose Symbolic Instruction Code" و التي تعني "الأكواد الرمزية عامة الأغراض للمبتدئين". و انتشرت بين المستخدمين لأجهزة الحواسيب الشخصية الأولي لأنها وفرت لهم آلية سهلة و يسيرة لبرمجة تلك الحواسيب، و كذلك تطوير مهارات التفكير البرمجي لديهم، رغم أن تلك اللغة لم تكن من حيث القواعد و الإمكانيات المتاحة لها فائقة القوة. ثم بدأت الشركات المختلفة بإضافة مميزاتها الخاصة إلي اللغة و إخراج إصدارات خاصة بها لأجهزة الحواسيب التي تنتجها. و كانت Microsoft من ضمن تلك الشركات التي تبنت لغة الـBasic و استغلتها لتجذب نحوها هواة البرمجة.

 

عن فترة انقطاعي الأخيرة

السلام عليكم و رحمة الله

لا زلتُ حياً أُرزَق و الحمد لله تعالي، و لم أُتوفَّ أو أفقد ذاكرتي أو يختطفني غزاة من الفضاء الخارجي، و لم يزرني البعض بعد الفجر لأن "الباشا عاوزك خمس دقايق يدردش معاك في موضوع صغنن" :)

 

ما حدث أنني مررتُ بفترة من الاضطراب الشديد في حياتي الشخصية و العملية، مما جعلني أقلل من نشاطي الرقمي قدر الإمكان إلي أن أتجاوز تلك الفترة علي خير. خصوصاً مع وفاة والدي رحمة الله عليه منذ ما يقرب من الشهرين (أسأل الله أن يرحمه رحمة واسعة و أن يجعله جليس النبي في الجنة)، مما أدي إلي انقطاعي عن نشاطي الرقمي سواء علي الفيسبوك أو مدوناتي المختلفات. و ربما يستمر الارتباك لفترة بسيطة أخري لسبب سأحدثكم عنه فيما بعد بإذن الله تعالي (هو أمر جيد بفضل الله تعالي بعد سلسلة من الأحداث المحزنة).

 

ميزات و عيوب الاعتماد علي آلة وهمية virtual machine في العمل

حينما تستخدم حاسوبك في إنجاز أحد الأمور التي تعمل عليها، فإنك في المعتاد ستستخدم نظام التشغيل المُنصَّب عليه و البرمجيات التي تم تثبيتها علي ذلك النظام، و هو الأمر العادي و الطبعي. و لكن هناك خيار مختلف يقضي بأن تقوم بتنصيب نظام تشغيل آخر علي آلة وهمية Virtual Machine، و أن تقوم بتنصيب البرامج التي تحتاجها علي ذلك النظام؛ بحيث تستخدم تلك الآلة للعمل كأنها هي حاسوبك الرئيس و ليست مجرد آلة وهمية !، و هي الفكرة التي قد تبدو غريبة و غير ذات جدوي في النظرة الأولي (خصوصاً إذا لم يكن لك باع طويل في بناء البرمجيات متعددة المنصات cross-platform)، إلا أن لها الكثير من الفوائد في أحيان معينة.

 

لذلك ففي هذا المقال سأتحدث عن فوائد و عيوب هذه الطريقة للعمل من وجهة نظري، و الجدير بالذكر أنني جربتُ هذه الطريقة لبعض الوقت (القليل جداً من الوقت في واقع الأمر)، مما يعني أن أغلب ما سأذكره هنا (إن لم يكن كله) ليس كلاماً نظرياً، بل هو نتيجة خبرة عملية حتي و إن كانت لفترة صغيرة للغاية.

مرحباً Swift، ما الذي أخَّرك حتي الآن ؟!

 

في مؤتمر WWDC 2014 الصاخب الذي عقدته Apple في الأيام الماضية كان هناك العديد من المفاجآت، منهن أن نظام mac os x صار قريب الشكل من نظام iOS (و هو الأمر الذي لا أخفي كرهي الشديد له، و ربما أخصص مقالاً قادماً لانتقاد هذا الأمر و أوضح فيه مدي استيائي منه). و لكن كان هناك الكثير من الأمور التي أسعدتني، و علي رأسها كان خبر إطلاق Apple للغة برمجة جديدة تسمي swift ستعمل كبديل للغة Objective-C علي المدي البعيد. و في هذا المقال أنوي أن أكتب بعض الفقرات التي أوضح فيها وجهة نظري لتلك اللغة الجديدة.

لكن يجب أن أنبه في البداية إلي أن الملاحظات التي سأضعها هنا عن swift أتت نتيجة لاطلاع مبدئي علي قواعد اللغة، و علي ما كتبه كتاب تقنيون مشهورون، لذلك ففي الإمكان اعتبار آرائي هنا انطباعاً مبدئياً و ليس حكماً نهائياً إلي حد ما؛ فعلي الرغم من أن لغة swift تعجبني من الناحية التصميمية إلي حد كبير، و أنني قرأتُ الكثير عنها بما يجعلني أفهم إلي حد كبير المبادئ التصميمية التي كانت وراء تصميمها بذلك الشكل، إلا أنه لا يمكن إعطاء حكم نهائي علي لغة برمجة تعلق عليها شركة مثل Apple آمالها في الفترة القادمة إلا باطلاع مكثف للغاية، و ربما لو استطعتُ تجربة اللغة بشكل أو بآخر فسيكون هذا ممتازاً.

هل يمكن لبرمجيات الـNet. أن تصير محمولة كبرمجيات الـjava ؟

كما أفضتُ في الشرح في أحد المقالات السابقة، فإن من أكثر الأمور التي تجعلني أحب لغة الـjava أن البرامج المكتوبة بها لها القدرة علي العمل علي أنظمة التشغيل الشهيرة كلها بدون أي تعديل في الأكواد الرئيسة. بالطبع سيكون لزاماً عليك في أكوادك أن تراعي أن تلك الأنظمة تختلف فيما بينها في بعض الأمور، مثل مسارات الملفات و المجلدات، و بالتالي قد يكون مسار مجلد برنامجك (بعد أن يتم تنصيبه) في أنظمة الـWindows كالتالي:

C:\Windows\programfolder

بينما يكون علي أنظمة التشغيل شبيهة اليونكس unix-like (مثل توزيعات الـGNU\linux، و الـmac os x) كالتالي:

/usr/bin/programfolder

و هو ما يعني أنه يجب عليك لكي يكون برنامجك محمولاً portable أن تنتبه إلي مثل هذه الأمور جيداً، و أن تحتاط لها في أكواد البرنامج. و لكن بشكل عام فإن نفس الأكواد التي كتبتَها بالـjava ستعمل علي كل أنظمة التشغيل، و نفس ملفات الـjar (التي تمثل الملفات التنفيذية لبرامجك) ستعمل علي كل أنظمة التشغيل بلا مشاكل.

الـWindows فيه سم قاتل!… حقاً ؟!

 

 

 

قليل جداً من البرامج التي أستخدمها (أو أكون قد استخدمتُها) أثار إعجابي حتي تعلقتُ به عاطفياً، و لا أتذكر من تلك الفئة سوي الـVisual Studio و الـNetBeans و Kubuntu، ثم مؤخراً Windows 8 و تحديثاته. و أتذكر أنني كنتُ مع أحد أصدقائي في يوم من الأيام (حينما كنتُ في السنة قبل النهائية في الكلية) في أحد الحدائق، فأشار إلي مكعبات من القرميد مصفوفة علي شكل علامة المالانهاية في الرياضيات، فما كان مني إلا أن أشرق وجهي و قلتُ في سعادة “علامة الـVisual Studio” !، و لكم أن تتخيلوا إحساس ذلك الصديق ساعتها.

 

و نفس الأمر ينطبق علي توزيعة Kubuntu لسطح المكتب؛ حيث استخدمتُها لفترة طويلة و أثارت إعجابي إلي حد أن مجرد رؤية كلمة Kubuntu مكتوبةً في أي مكان يجعل قلبي يهفو ناحيتها. و لا زلتُ حتي اليوم أعتبرها أنضج التوزيعات المخصصة للمستخدمين العاديين؛ و السبب الرئيس وراء ذلك هو أنها تحوي كل البنية الأساسية التي ترثها من Ubuntu لكنها تضع واجهة الـKDE فوق كل ذلك، كبديل ممتاز لواجهة الـunity التي لا أحبها و أري أنها أضعف و أقل جمالاً (بالنسبة لي علي الأقل)، إذا ما قُورنت بالـKDE الغاية في النضج و الجمال و القابلية للتخصيص.

الدروس المستفادة من أزمة نزف القلب (3)

هذا هو المقال الرابع و الأخير في حديثنا عن أزمة نزف القلب heartbleed و الدروس المستفادة منها، و قد كتبتُ هذه الرباعية من المقالات بسبب أن تلك الأزمة نبهتني إلي بعض الأمور البدهية التي يحتاج الكثيرون للانتباه إليها، و كان من الممكن أن أطيل أكثر من ذلك لكنني آثرتُ السلامة و أن أكتفي بهذا القدر؛ حتي لا يعزف الناس عن قراءة هذه المقالات مللاً، فتفقد وظيفتها الأساسية و تصير كأنها لم تكن، و الكابوس الأكبر لأي كاتب (مبتديء كان أو محترف) هو أن يجده الناس مملاً و يعزفون عن قراءة ما يكتب.

الدروس المستفادة من أزمة نزف القلب (2)

هذا هو المقال الثالث الذي أتحدث فيه عن أمور تتعلق بأزمة “نزف القلب heartbleed” البرمجية، و الثاني الذي أتحدث فيه عن الدروس المستفادة من تلك الأزمة. أنا أعلم عن نفسي أنني ثرثار للغاية حينما يتعلق الأمر بأشياء تهمني و لي فيها وجهات نظر أريد شرحها للآخرين، و لكني لم أكن أعلم حينما بدأتُ في كتابة أول المقالات عن هذا الأمر أنني سأجد الأمر ثرياً لدرجة تجعلني أكتب بلا توقف !، و أنا حينما أفقد السيطرة علي نفسي في الكتابة يكون من الصعب للغاية أن أوقف فيضان الأفكار الذي يأتيني بخصوص الموضوع الذي أكتب عنه، و هذه كما ترون ميزة لأنها تضمن لك ككاتب تقني ألا يخرب بيتك لتوقف أفكارك و مقالاتك، و عيب لأنها قد تجعل قراء مقالاتك يكرهونك كالجحيم؛ بسبب الملل الذي سيواجهونه عند تحدثك في موضوع واحد طويلاً. لذلك أعدكم ألا يكون هناك بعد هذا المقال سوي مقال واحد فقط عن ذلك الموضوع.

فرص أمام Google لتطوير منصة Blogger

أنا أعلم أنه كان من المفترض أن يكون هذا المقال تكملة للمقالين السابقين عن أزمة “نزف القلب heartbleed” التي تم اكتشافها مؤخراً في مكتبة OpenSSL مفتوحة المصدر، و لكن بما أن الأمر استغرق بالفعل مقالين سابقين، و بما أنه سيطول بعض الشيء و سأكتب عنه ما لا يقل عن مقالين آخرين، فقد رأيتُ أن أجعل بين تلك المقالات ذات الموضوع الواحد مقالاً يتحدث عن أمر مختلف؛ ليكسر حدة الملل و يجعلنا قادرين علي الاستفاضة في الحديث عن الدروس المستفادة من أزمة نزف القلب بدون كثير من التثاؤب و مغالبة النعاس.

الدروس المستفادة من أزمة نزف القلب (1)

في المقال السابق تحدثتُ عن ثغرة “نزف القلب heartbleed” التي تم اكتشافها في الفترة الماضية في مكتبة OpenSSL مفتوحة المصدر و ذات الشهرة الفائقة في عالم التشفير، و تحدثتُ عن ردود الفعل المختلفة لاكتشاف الثغرة و التي صدرت من أفراد و هيئات مختلفين، ثم عبَّرتُ في نهاية الأمر عن رأيي القائم علي أن الثغرات البرمجية يكاد لا يخلو منها برنامج سواء أكان مفتوح المصدر أو مغلقه، و سواء أكان ضخماً أو صغير الحجم، و سواء أكان يتم الإنفاق عليه بالملايين أو لا يُنفق عليه أي شيء؛ فالأمر الذي يعلمه كل المبرمجين أنه مهما بلغ الواحد منهم من البراعة و الذكاء فإنه يظل مجرد بشري له أخطاؤه و خطاياه، و حتي أفضل تصميماته و أكواده يظل فيها و لو هامش صغير من الثغرات، التي يمكن لمن هو أكثر علماً و/أو ذكاءً (أو حتي أقل علماً و ذكاءً!) أن يكتشفها قبله و يستغلها.

عن نزف قلب المصادر المفتوحة

منذ فترة بسيطة اكتشف الباحث في الأمن المعلوماتي ”Neel Mehta” (و الذي يعمل في شركة google) ثغرة أمنية في غاية الخطورة في المكتبة البرمجية مفتوحة المصدر OpenSSL، و قد تم إطلاق اسم “نَزْف القلب heartbleed” علي تلك الثغرة. مما جعل الدنيا كلها تنشغل بالحديث عن الأمر ليل نهار، و مما لا شك فيه أنكم مثلي تشبعتم تماماً من كثرة المقالات التي قرأتموها و تتحدث عن هذا الأمر، مما قد يدفع الكثير منكم للتساؤل عن السبب الذي يدفعني إلي الكتابة عن ذات الموضوع الذي قتله الجميع بحثاً !.

 

في الواقع فإنني أحب أن أتحدث عن الأخبار و الأمور التقنية بعد فترة غير قصيرة من ظهورها و انشغال الناس بها، لستُ أتذكر إن كنتُ قد تحدثتُ من قبل عن أمر من الأمور التقنية في عُجالة أم لا، و لكن ما أدريه عن نفسي أنني أفضِّل أن أقرأ معظم (إن لم يكن كل) وجهات النظر عن المسائل التي تشغلني، ثم أدون بعض الأفكار عما قرأته، و بين فترة و أخري أعود لما كتبتُه لأعدِّل فيه بما يتفق مع الجديد الذي قرأتُه عن ذات الموضوع. خصوصاً في تلك الأحيان التي يكون فيها الموضوع خارج نطاق تخصصي، و/أو يكون شائكاً و يمثل حقل ألغام لكل من يريد الخوض فيه، و في الواقع فإن مسألة الثغرة التي تم اكتشافها في OpenSSL من أهم الأمثلة علي النوعين الأخيرين.

مقدمة سريعة عن الحوسبة و البرمجة

توطئة:

 

هذه مقدمة بسيطة مختصرة تصلح لشرح الفكرة العامة لبعض الأمور و المفاهيم الأساسية المتعلقة بالحوسبة computing و البرمجة programming، و الهدف الرئيس من ورائها أن تكون هي نفسها مجرد توطئة للدخول فيما بعد إلي عالم التفاصيل التقنية المتخصصة رويداً رويدا. و لذلك حرصتُ أن تكون خاليةً قدر الإمكان من أية تفاصيل تقنية تتطلب أي نوع من أنواع المعرفة السابقة، مع الحرص علي تشبيه معاني المفاهيم و المصطلحات الحاسوبية المذكورة هنا بأشياء محسوسة من الواقع؛ لتكون الأمور أيسر في الاستيعاب حتي بالنسبة لمن ليست له أية خلفية تقنية قديمة *.

 

 

كيف تزيد من قوتك و إنتاجيتك ؟ (المجال البرمجي كتطبيقٍ عملي)

من بين الأسئلة التي تتردد علي ألسنة المبرمجين هناك سؤالان هما الأكثر ترددا (علي الأقل من وجهة نظري الشخصية)، و هما: "كيف أصير مبرمجاً محترفاً (أو: كيف أتعلم البرمجة حتي الاحتراف) ؟"، و هو السؤال الذي تسأله الأغلبية الساحقة من المبتدئين في عالم البرمجة (و ربما يسأله من وصل لمرحلةٍ متوسطة و لا يرضي بأن يقف عند تلك النقطة)، و السؤال الثاني هو: "كيف أزيد من إنتاجيتي كمبرمج (أو: كيف أستطيع أن أحسن من قدراتي و مهاراتي) ؟"، و هو السؤال الذي يشغل بال الكثيرين ممن وصلوا لمرحلةٍ جيدة أو متوسطة.

كيف يمكن إدارة المشاريع البرمجية الجماعية ؟

علي موقع Arabia I/O كان هناك تساؤلٌ تحت عنوان: "كيف يمكن إدارة المشاريع البرمجية الجماعية ؟"، يقول فيه صاحبه:

السلام عليكم :)

آمل أن الجميع بخير .. لدي سؤال، و هو "كيف يقوم فريق من المطورين بالعمل على مشروع معين بشكل مرتب و منظم؟، هل هناك أي طرق مفضلة يجب إتباعها؟، على سبيل المثال المشروع عبارة عن منتدى سيتم تطويره بـ استخدام PHP وربطه مع قاعدة بيانات MySql."

آمل أن يحدثنا أحد الخبراء ليستفيد الجميع، حتى نبدأ بعمل مشروع مع فريقنا الخاص بشكل منظم ومرتب. لو هناك نصائح لا تبخل علينا بها :)

تحياتي،،

فكانت إجابتي عليه كما يلي:

ما هي أفضل لغة برمجة ؟

علي موقع Arabia I/O كان هناك تساؤلٌ يقول فيه صاحبه: "ما هي أفضل لغة لبرمجة تطبيقات سطح المكتب ؟"، فكتبتُ إجابةً مُختصَرةً علي سؤاله تصلح للإجابة عن كل الأسئلة التي من عينة: "ما هي أفضل لغة برمجة لفعل كذا و كذا ؟"، أو حتي للإجابة علي السؤال الأعم و الأشمل: "ما هي أفضل لغة برمجة ؟".

و كان ردي كما يلي (مع تصرُّف بسيط للغاية):

المأساة الـNexusيـة !

البارحة علي موقع ardroid الخاص بالأخبار التقنية التي تخص نظام تشغيل android كان هناك حوارٌ مفتوحٌ حول "السياسة الجديدة لـgoogle تجاه android، التي أصبحت فيها تعمل على تطويره بشكلٍ تدريجي و كل جزءٍ منه منفردا، دون أن تُقدم لمستخدميه إصدارةً جديدةً تختلف بشكلٍ كليٍ عن الإصدارة السابقة لها، و كان التساؤل المطروح للإجابة عليه: هل تعتقد أن هذه السياسة الجديدة تُقدم فائدة أكبر لنظام تشغيل android، أم أن الكشف عن إصدار android بتغييراتٍ كثيرةٍ و كبيرةٍ يُعتبر أفضل ؟.