ميزات و عيوب الاعتماد علي آلة وهمية 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” البرمجية، و الثاني الذي أتحدث فيه عن الدروس المستفادة من تلك الأزمة. أنا أعلم عن نفسي أنني ثرثار للغاية حينما يتعلق الأمر بأشياء تهمني و لي فيها وجهات نظر أريد شرحها للآخرين، و لكني لم أكن أعلم حينما بدأتُ في كتابة أول المقالات عن هذا الأمر أنني سأجد الأمر ثرياً لدرجة تجعلني أكتب بلا توقف !، و أنا حينما أفقد السيطرة علي نفسي في الكتابة يكون من الصعب للغاية أن أوقف فيضان الأفكار الذي يأتيني بخصوص الموضوع الذي أكتب عنه، و هذه كما ترون ميزة لأنها تضمن لك ككاتب تقني ألا يخرب بيتك لتوقف أفكارك و مقالاتك، و عيب لأنها قد تجعل قراء مقالاتك يكرهونك كالجحيم؛ بسبب الملل الذي سيواجهونه عند تحدثك في موضوع واحد طويلاً. لذلك أعدكم ألا يكون هناك بعد هذا المقال سوي مقال واحد فقط عن ذلك الموضوع.