لوحة المتصدرين

وقعتُ أخيرًا بالصدفة على اقتباس من مطور في مشروع Mozilla عن التوتر الكامن في إنشاء المعايير القياسية: ابقِ هذه المقولة في عقلك، ولنشرح كيف أصبحت HTML5 على ما هي عليه. أنواع MIME هذه السّلسلة تتحدث حول HTML5، وليس عن إحدى إصدارات HTML السابقة أو أي إصدارٍ من XHTML، لكن لفهم تاريخ HTML5 والدوافع خلف إنشائها تمامًا، فعليك أن تستوعب بعض التفاصيل التقنية أولًا، تحديدًا أنواع MIME. في كل مرة يطلب فيها متصفح الويب صفحةً، فسيُرسِل الخادوم "ترويسات" (headers) قبل أن يرسل شيفرة الصفحة نفسها، وهذه الترويسات غير ظاهرة عمومًا على الرغم من توفر أدوات تطويرية تمكنك من رؤيتها إن كنت مهتمًا بها. لكن الترويسات مهمة لأنها تُخبر المتصفح كيف يُفسِّر الشيفرات الموجودة في الصفحة، أحد أهم تلك الترويسات هو Content-Type وهو يبدو كما يلي: Content-Type: text/html "text/html" يدعى "Content Type" أو نوع المحتوى أو نوع MIME، هذه الترويسة هي الشيء الوحيد الذي يُحدِّد طبيعة المورد المُحدَّد وكيف يجب عرضه. فالصورة لها أنواع MIME خاصة بها (image/jpeg لصور JPEG، و image/png لصور PNG، وهلمَّ جرًا)؛ ولملفات JavaScript نوع MIME خاص بها، وكذلك الأمر لصفحات الأنماط CSS، فلكل شيء في الويب له نوع MIME خاص به. وبالطبع الواقع معقَّد أكثر من هذا، فالجيل الأول من خواديم الويب (وهنا أتكلم عن خواديم الويب في 1993) لم تكن تُرسِل ترويسة Content-Type لأنها لم تكن موجودةً في ذاك الوقت (إذ لم تُستعمَل إلا في 1994)، وكانت بعض المتصفحات الشهيرة تتجاهل ترويسة Content-Type في بعض الظروف لأسبابٍ لها علاقة بالتوافقية (وهذا يسمى "content sniffing")، لكن كقاعدة عامة، كل شيء يمكنك الحصول عليه على الويب (كصفحات HTML، والصور، والسكربتات، والفيديو، وملفات PDF، وكل شيء له رابط URL) يجب أن يُخدَّم بإضافة نوع MIME المناسب في ترويسة Content-Type. خزِّن المعلومات السابقة في عقلك، وسنعود إليها لاحقًا. شرح مسهب لكيفية إنشاء المعايير لماذا لدينا عنصر <img>؟ لن تسمع مثل هذا السؤال كل يوم. بكل تأكيد أنشأه أحدهم، إذ لم تظهر تلك الأشياء من العدم، فكل عنصر وكل خاصية (attribute) وكل ميزة من ميزات HTML التي استخدمتها من قبل قد أنشأها أحدهم وقرر كيف يجب أن تعمل وكتب كل ذلك، هؤلاء الأشخاص الذين كتبوا المعايير ليسوا خارقين وإنما مجرد بَشَر ولكنهم أذكياء. أحد الأشياء الرائعة عن المعايير هي أنها طُوِّرَت على الملأ، أي أنَّك تستطيع العودة في الزمن والإجابة عن ذاك النوع من الأسئلة؛ إذ أنَّ النقاشات كانت تُجرى في القوائم البريدية، التي أُرشِفَت وأصبحت متاحةً للعموم كي يبحثوا فيها؛ لذلك قررت أن "أنقِّب" في رسائل البريد الإلكتروني كي أحاول الإجابة عن السؤال السابق: "لماذا لدينا عنصر <img>؟"، كان علي البدء في حقبةِ قبل إنشاء منظمة باسم "رابطة الشبكة العالمية" (World Wide Web Consortium اختصارًا W3C)، ذهبت إلى الأيام الأولى للويب، حيث كنتَ تستطيع عدّ صفحات الويب على أصابع اليدين. في 25 شباط/فبراير من عام 1993، كتب Marc Andreessen: كانت صيغتا Xbm و Xpm صيغتَا رسوميات شهيرتان في أنظمة يونكس. "Mosaic" كان من أوائل متصفحات الويب ("X Mosaic" كان الإصدار الذي يعمل على أنظمة يونكس)، عندما كتب Marc Andreessen رسالته في بدايات 1993، لم يكن قد أسس الشركة التي جعلته مشهورًا (شركة Mosaic Communications Corporation)، ولم يكن بدأ العمل على المنتج الرائد في تلك الشركة: "Mosaic Netscape" (ربما تعرفها بأسمائها الحديثة "Netscape Corporation" و "Netscape Navigator"). عبارته "ربما أنواع MIME" كانت تُشير إلى ميزة Content negotiation في HTTP، حيث يُخبر العميل (أي متصفح الويب) الخادوم (أي خادوم الويب) ما هي أنواع الوسائط التي يدعمها (مثل image/jpeg) ومن ثم سيُرسِل الخادوم الوسائط إلى العميل بالصيغة التي يُفضلِّها. عُرِّفَت الصيغة الأصلية من HTTP في 1991 (وهي النسخة الوحيدة التي كانت موجودةً في شباط/فبراير 1993) ولم تكن توفِّر طريقةً للعملاء لأن يخبروا الخواديم ما هي صيغ الصور التي يدعموها، وهذه هي المعضلة التي واجهها Marc. بعد عدِّة ساعات، ردِّ Tony Johnson: Midas هو متصفح آخر من فترة بدايات الويب، وكان منافسًا لمتصفح X Mosaic، وكان متعدد المنصات، إذ كان يعمل على أنظمة يونكس و VMS. أما "SLAC" فهي تُشير إلى Stanford Linear Accelerator Center التي أصبح اسمها الآن "SLAC National Accelerator Laboratory" التي استضافت أول خادوم ويب في الولايات المتحدة (وفي الواقع، أول خادوم ويب خارج أوروبا). عندما كتب Tony هذه الرسالة، كانت SLAC من المحاربين القدامى في الشبكة العالمية، التي استضافت خمس صفحات على خادوم الويب الخاص بها لمدة 441 يومًا. أكمل Tony قائلًا: قصد ببروتوكول "HTTP2" بروتوكول HTTP الأساسي المُعرِّف في 1992، الذي لم يُطبَّق تطبيقًا كاملًا في بدايات 1993، وعُرِفَت المسودة باسم HTTP2 ثم أصبحت معيارًا قياسيًا باسم "HTTP 1.0" (بالرّغم من أن الأمر قد تم ذلك بعد ثلاثة أعوام)، تضمَّن بروتوكول HTTP 1.0 ترويسات طلبات لتحديد صيغة المحتوى (request headers for content negotiation)، أي أنواع MIME. أكمل Tony: لم يُطبَّق اقتراحه أبدًا، إلا أنَّ فكرة توفير نص إن لم تتوفر الصورة هي تقنية مهمة لتسهيل الوصول التي كانت ناقصة من اقتراح Marc الأولي لوسم <IMG>. استعملت هذه الميزة في خاصية <img alt>، التي أساء متصفح Netscape معاملتها باعتبارها تلميحًا (tooltip). بعد عدِّة ساعات من إرسال Tony لرسالته، ردَّ Tim Berners-Lee عليها: لم يُطبَّق هذا الاقتراح مطلقًا، لكن خاصية rel ما زالت موجودةً. أضاف Jim Davis: لم يُطبَّق هذا الاقتراح قط، لكن أضاف متصفح Netscape لاحقًا دعمًا لتضمين عناصر الوسائط المتعددة باستعمال عنصر <embed>. سأل Jay C. Weber: ردَّ Marc Andreessen: أجاب Jay C. Weber له قائلًا: أدركنا بعد فوات الأوان أنَّ مخاوف Jay كان لها أساسٌ من الصحة لكن ذلك استغرق فترةً طويلةً، فقد أضافت HTML5 أخيرًا عنصرَيّ <video> و <audio>. ردًا على رسالة Jay الأصلية، قال Dave Raggett: لاحقًا في 1993، اقترح Dave Raggett معيار HTML+‎ الذي كان تطويرًا لمعيار HTML. لكن لم يُطبَّق اقتراحه مطلقًا، ثم حلَّت HTML 2.0 محله التي أعطت طابعًا رسميًا للميزات شائعة الاستعمال: "هذا المعيار يضفي توضيحًا وطابعًا رسميًا لمجموعة من ميزات HTML التي كانت شائعة الاستعمال قبل حزيران/يونيو عام 1994". كتب Dave لاحقًا معيار HTML 3.0 المبني على مسودة HTML+‎ التي كتبها سابقًا، وذلك خارج إطار W3C للمعايير (المسمى Arena)؛ لكن لم تُطبَّق HTML 3.0 أبدًا، وحلَّت محلها HTML 3.2، التي رسَّمَت الميزات كالإصدار السابق HTML 2.0: "أضافت HTML 3.2 الميزات شائعة الاستخدام مثل الجداول، و applets والتفاف النص حول الصور، بالإضافة إلى توافقيتها مع معيار HTML 2.0". شارك Dave لاحقًا بوضع معيار HTML 4.0، وطوَّر HTML Tidy، وشارك في المساعدة بتطوير XHTML، و XForms، و MathML، وغيرها من معايير W3C الحديثة. بالعودة إلى 1993، رد Marc على Dave: Intermedia هو مشروعٌ من جامعة Brown، طوِّر من عام 1985 إلى 1991 وكان يعمل على نظام A/UX، الذي هو نظام شبيه بِيونكس (Unix-like) لحواسيب ماكنتوش في ذاك الوقت. راجت فكرة "لغة لتوصيفِ الرسومات ذاتُ غرضٍ عام"، وذلك بدعم المتصفحات الحديثة لصيغة SVG (لغة توصيفية يمكن دمج السكربتات معها)، و <canvas> (واجهة برمجية [API] إجرائية [procedural] مباشرة)، على الرغم من أن الأخيرة بدأت كإضافة مملوكة (proprietary extension) قبل أن يتم ترسيمُها من WHATGW. ردBill Janssen: "Andrew" هو إشارة إلى Andrew User Interface System (إلا أنه كان يسمى في ذاك الوقت Andrew Project). في ذاك الحين، وجد Thomas Fine فكرةً مختلفةً: "Display Postscript" هي تقنية لعرض Postscript على الشاشة طوِّرَتها كل من Adobe و NeXT. لم يُطبَّق هذا الاقتراح أبدًا، لكن الفكرة أنَّ أفضل طريقة لحل مشاكل HTML هي استبدال شيءٍ ما آخر بها ما زالت تظهر من وقتٍ لآخر. قال Tim Berners-Lee في الثاني من آذار/مارس عام 1993: HyTime كان نظام مستندات قديم مبني على SGML، وقد أثَّرَ كثيرًا في النقاشات الأولية للغة HTML، ولاحقًا لغة XML. لم يُطبَّق اقتراح Tim لوسم <INCLUDE> مطلقًا، لكنك تجده صداه واضحًا في عناصر <object> و <embed> و <iframe>. في النهاية، قال Marc Andreessen في الثاني عشر من آذار/مارس عام 1993: ترجمة -وبتصرّف- لفصل A Quite Biased History of HTML5 من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim. اقرأ أيضًا المقال التالي: نظرة على تاريخ HTML - الجزء الثاني المقال السابق: خمسة أشياء عليك معرفتها عن HTML5 النسخة الكملة لكتاب نحو فهم أعمق لتقنيات HTML5

هذا الدرس الرابع من سلسلة نصائح وحيل فوتوشوب، التي سنتعلم من خلالها العديد من الحيل والأدوات عند التصميم ببرنامج فوتوشوب بالإضافة إلى مجموعة من النصائح حول الإستخدام الأمثل للبرنامج. سنقوم في هذا الدرس بتصميم قلم وتحريكه لكتابة كلمة وسنراه يقوم بذلك بالحركة فعليًّا باستخدام برنامج فوتوشوب. وستكون النتيجة كالتالي: افتح ملفا جديدا في فوتوشوب ثم لوّن الخلفية كما تريد ثم استخدم أداة النص لكتابة أي كلمة أو عبارة تريدها مثلا: "حسوب". حوّل طبقة النص إلى طبقة صورة نقطية عبر النقر بالزر الأيمن على الطبقة واختيار Rasterize Type من القائمة. حدد هذه الطبقة واضغط Ctrl+J لصنع نسخة جديدة عنها ثم أخفِ الطبقة القديمة واستخدم أداة الممحاة لمسح جزء صغير من آخر النص. مجددًا حدّد الطبقة الجديدة ثم اضغط Ctrl+J ثم أخفِ الطبقة القديمة وامسح جزءًا إضافيًّا من النص ثم كرّر العملية حتى تمسح النص بالكامل. استخدم أدوات الأشكال واختر شكل القلم من بين الأشكال القياسية الموجودة في برنامج فوتوشوب أصلًا. ارسم شكل القلم ولوّنه كما تشاء (يمكنك استخدام صورة قلم حقيقي ببساطة). الآن اذهب إلى نافذة Window ثم فعّل نافذة Timeline ثم ابدأ بإضافة إطار Frame جديد وفي كل مرّة أظهِر طبقة جديدة من الطبقات النصيّة التي أخفيناها سابقًا مع تحريك القلم ووضع رأس القلم عند النقطة الأخيرة الظاهرة من النص وكرّر العملية حتى تصل إلى إظهار النص كاملًا. احفظ الملف من القائمة: File > Save for Web ثم اختر نوعية الملف GIF واحفظ الملف وستحصل على النتيجة التالية. طبعًا هذه نصيحة بسيطة ومختصرة ويمكنك تعديل العمل بخلفية مختلفة ونص آخر وقلم واقعي والتلاعب بعدد الإطارات ومدة إظهارها ...الخ

تحدثنا في الدرس السابق عن المبادئ الأوليّة لتطبيق مفاهيم البرمجة كائنيّة التوجّه في سي شارب، حيث تعلّمنا كيفيّة إنشاء الأصناف وأعضائها، وإنشاء الكائنات من الأصناف والتعامل معها. سنتابع في هذا الدرس الحديث عن تطبيق مبادئ البرمجة كائنيّة التوجّه في سي شارب حيث سنتناول مُحدّد الوصول private (تناولنا محدّد الوصول public في الدرس السابق). وسنتحدّث أيضًا عن الخصائص Properties كنوع جديد من أعضاء الصنف، والفرق بينها وبين حقول البيانات Data Fields. وسنختم هذا الدرس بالحديث عن الأعضاء الساكنة Static Members في الصنف. الخصائص Properties للخصائص ولحقول البيانات المعنى المنطقيّ نفسه في البرمجة كائنيّة التوجّه، إلّا أنّ سي شارب تميّز بينهما من الناحية العمليّة. للخصائص في سي شارب مرونة أكبر، حيث من الممكن تنفيذ عبارات برمجيّة عند إسناد قيمة إلى خاصيّة أو حتى عند القراءة منها. كما من الممكن أن نجعل إحدى الخواص قابلة للقراءة فقط أو حتى قابلة للكتابة فقط (ولو أنّه أمر نادر الحدوث). لفهم هذه المزايا بشكل جيّد سأستعير البرنامج Lesson06_02 من الدرس السابق، وأجري عليه بعض التعديلات لإدخال مفهوم الخصائص. 1 using System; 2 3 namespace Lesson07_01 4 { 5 6 class Employee 7 { 8 private string firstName; 9 private string lastName; 10 private double salary; 11 12 public string FirstName 13 { 14 get 15 { 16 return this.firstName; 17 } 18 set 19 { 20 this.firstName = value; 21 } 22 } 23 24 public string LastName 25 { 26 get 17 { 28 return this.lastName; 29 } 30 set 31 { 32 this.lastName = value; 33 } 34 } 35 36 37 public double Salary 38 { 39 get 40 { 41 return this.salary; 42 } 43 set 44 { 45 this.salary = value; 46 } 47 } 48 49 public string DisplayInfo() 50 { 51 string result = string.Format("{0} {1} - Salary: {2:N0}", 52 this.FirstName, this.LastName, this.Salary); 53 54 return result; 55 } 56 57 public Employee(string firstName, string lastName, double salary) 58 { 59 this.FirstName = firstName; 60 this.LastName = lastName; 61 this.Salary = salary; 62 } 63 64 public Employee() 65 { 66 67 } 68 } 69 70 71 class Program 72 { 73 static void Main(string[] args) 74 { 75 Employee employee1, employee2; 76 77 employee1 = new Employee("Mohammad", "Mansoor", 1000); 78 employee2 = new Employee("Saleh", "Mahmoud", 2500); 79 80 Console.WriteLine("First Employee: {0}", employee1.DisplayInfo()); 81 Console.WriteLine("Second Employee: {0}", employee2.DisplayInfo()); 82 } 83 } 84 } عند تنفيذ البرنامج Lesson07_01 سنحصل على نفس الخرج الذي حصلنا عليه في البرنامج Lesson06_02. لقد أجرينا في الحقيقة بعض التعديلات التي تبدو للوهلة الأولى أنّها ليست ذات مغزى. لقد استبدلنا محدّد الوصول للحقول في الأسطر من 8 حتى 10 ليصبح private بدلًا من public (كما كان الوضع في البرنامج Lesson06_02). يفيد مُحدّد الوصول هذا في جعل الحقل خاصًّا بالصنف ولا يمكن الوصول إليه من خارج الكائن المُنشَأ من هذا الصنف، وبالتالي لا يمكن لأحد أن يُعدّل عليه إلّا التوابع الموجودة ضمن نفس الصنف حصرًا. الأمر الآخر أنّنا قد جعلنا أسماء الحقول تبدأ بحرف طباعي صغير وذلك لتمييزها عن الخصائص التي ستأتي بعدها والتي تحمل نفس الاسم ولكن بحرف طباعي كبير. يبدأ التصريح عن الخاصيّة FirstName في السطر 12 ويمتدّ حتى السطر 22. للخصائص في سي شارب فوائد عظيمة سنختبرها بالتدريج في هذا الدرس وفي الدروس اللّاحقة. لاحظ وجود النوع string قبل اسم الخاصيّة في السطر 12، يُشير ذلك إلى أنّ هذه الخاصيّة تقبل وتعطي قيمًا نصيّة فحسب. في الحقيقة يمكن استبدال string بأيّ نوع نحتاجه. من الواضح أنّ التصريح عن الخاصيّة FirstName يتألّف من قسمين: قسم القراءة get (بين السطرين 14 و 17) وقسم الإسناد set (بين السطرين 18 و 21). في الواقع لا تتعدّى الخاصيّة كونها وسيلة للوصول إلى الحقول الخاصّة private fields الموجودة ضمن الكائن سواءً بالقراءة أو الإسناد، ولكن مع إمكانيّة معالجة القيم سواءً قبل إسنادها إلى هذه الحقول أو بعد القراءة منها. عندما نحاول إسناد قيمة إلى الخاصيّة FirstName ستُنفّذ العبارات البرمجيّة الموجودة في قسم set، وهي عبارة برمجيّة واحدة فقط في مثالنا هذا: this.firstName = value; الكلمة value هي كلمة محجوزة تحتوي على القيمة المُسندة إلى الخاصيّة FirstName. العبارة السابقة واضحة للغاية فهي تعمل على إسناد القيمة المخزّنة ضمن value إلى الحقل firstName. لاحظ كيف يمكننا الوصول إلى هذا الحقل من الكلمة this، كما ويمكننا إغفالها. نستطيع الوصول إلى الحقل firstName رغم أنّه ذو محدّد وصول private لأنّنا نصل إليه من تابع يقع في نفس الصنف. أمّا عندما نحاول قراءة الخاصيّة FirstName فسيتمّ تنفيذ العبارات البرمجيّة الموجودة ضمن القسم get. في هذا المثال يحتوي القسم get على عبارة برمجيّة واحدة وهي: return this.firstName; حيث تعمل على إرجاع القيمة المخزّنة ضمن الحقل firstName إلى الشيفرة التي طلبت قراءة الخاصيّة FirstName. يطبّق نفس الأمر تمامًا على الخاصيّتين LastName و Salary. الخصائص المطبقة تلقائيا يبدو البرنامج السابق طويلًا بلا مبرّر، فنحن لم نقم بأيّ عمل ضمن الخصائص سوى الإسناد أو القراءة. إذا كان الأمر كذلك في برامجك الحقيقيّة فيمكنك الاستغناء عن هذا الشكل من الخصائص واللجوء إلى شكل أكثر حداثةً وعصريّة، والذي يتمثّل بالخصائص المطبّقة تلقائيًّا auto implemented properties. انظر الشكل العام لها فيما يتعلّق بالخاصيّة FirstName: public string FirstName { get; set; } لم تعد العبارات البرمجيّة في قسميّ get و set موجودة. ينحصر دور هذه الخاصيّة في شكلها الحالي في تخزين القيم ضمن الخاصيّة FirstName والقراءة منها فقط. ولكن يأتي السؤال هنا، أين ستخزّن الخاصيّة FirstName قيمها، فأنا لا أرى حقلًا للتخزين! يعمل المترجم في هذه الحالة على إنشاء حقل خاص غير مُشاهد في شيفرة MSIL وظيفته الاحتفاظ بقيمة الخاصيّة FirstName. وهنا قد يجول بخاطرك سؤال آخر: لماذا كلّ هذا التعقيد، لماذا لا نستخدم الحقول كما كنّا نفعل في الدرس السابق وحسب؟ الإجابة بسيطة على هذا التساؤل المشروع. فنحن نستخدم الخصائص بهذا الشكل لغايات تصميميّة فحسب. فكلّما كنت بحاجة لأن تُضيف خاصيّة لأحد الأصناف يمكن الوصول إليها من خارجه فافعل ذلك عن طريق الخصائص (وليس الحقول) ولن تندم، وإن بدا ذلك يتطلّب المزيد من العمل. سنطبّق هذه الخصائص الفريدة على برنامجنا المعدّل Lesson07_02 بحيث تستغني تمامًا عن الحقول firstName و lastName و salary. 1 using System; 2 3 namespace Lesson07_02 4 { 5 6 class Employee 7 { 8 public string FirstName { get; set; } 9 public string LastName { get; set; } 10 public double Salary { get; set; } 11 12 public string DisplayInfo() 13 { 14 string result = string.Format("{0} {1} - Salary: {2:N0}", 15 this.FirstName, this.LastName, this.Salary); 16 17 return result; 18 } 19 20 public Employee(string firstName, string lastName, double salary) 21 { 22 this.FirstName = firstName; 23 this.LastName = lastName; 24 this.Salary = salary; 25 } 26 27 public Employee() 28 { 29 30 } 31 } 32 33 34 class Program 35 { 36 static void Main(string[] args) 37 { 38 Employee employee1, employee2; 39 40 employee1 = new Employee("Mohammad", "Mansoor", 1000); 41 employee2 = new Employee("Saleh", "Mahmoud", 2500); 42 43 Console.WriteLine("First Employee: {0}", employee1.DisplayInfo()); 44 Console.WriteLine("Second Employee: {0}", employee2.DisplayInfo()); 45 } 46 } 47 } أصبح هذا البرنامج الآن يُشبه البرنامج Lesson06_02 من الدرس السابق إلى حدّ كبير، باستثناء أنّنا نستخدم هنا الخصائص بدلًا من الحقول. لاحظ فقط أنّه يمكننا كتابة التصريح عن أيّ خاصيّة على نفس السطر مثل الأسطر 8 و 9 و 10. الخصائص ذات إمكانية القراءة فقط هل تذكُر التمرين الداعم الأوّل من الدرس السابق؟ كان يطلب ذلك التمرين إضافة تابع جديد اسمه GetSalaryAfterTax للحصول على قيمة الراتب بعد خصم الضريبة. واتفقنا وقتها أن تكون هذه الضريبة 2%. سنضيف خاصيّةً لتقوم بهذه المهمّة بدلًا من هذا التابع، ولكنّنا سنجعلها للقراءة فقط read only. أي لا يمكن إسناد أي قيم لها. ستكون الخاصيّة SalaryAfterTax الجديدة على الشكل التالي: public double SalaryAfterTax { get { return 0.98 * this.Salary; } } من الواضح أنّه قد أزلنا القسم set المسؤول عن الإسناد من تصريح الخاصيّة SalaryAfterTax وبذلك تتحوّل للقراءة فقط. يحتوي القسم get على عمليّة حسابيّة بسيطة تطبّق عملية حسم الضريبة على الراتب Salary. سنجري تعديلًا طفيفًا على التابع DisplayInfo لكي يُرفق قيمة الراتب بعد حسم الضريبة ضمن النصّ المنسّق الذي يرجعه. سنحصل في النتيجة على البرنامج Lesson07_03 المعدّل: 1 using System; 2 3 namespace Lesson07_03 4 { 5 6 class Employee 7 { 8 public string FirstName { get; set; } 9 public string LastName { get; set; } 10 public double Salary { get; set; } 11 public double SalaryAfterTax 12 { 13 get 14 { 15 return 0.98 * this.Salary; 16 } 17 } 18 19 public string DisplayInfo() 20 { 21 string result = string.Format("{0} {1} \n Salary: {2:N0} \n Salary after tax: {3:N0}", 22 this.FirstName, this.LastName, this.Salary, this.SalaryAfterTax); 23 24 return result; 25 } 26 27 public Employee(string firstName, string lastName, double salary) 28 { 29 this.FirstName = firstName; 30 this.LastName = lastName; 31 this.Salary = salary; 32 } 33 34 public Employee() 35 { 36 37 } 38 } 39 40 41 class Program 42 { 43 static void Main(string[] args) 44 { 45 Employee employee1, employee2; 46 47 employee1 = new Employee("Mohammad", "Mansoor", 1000); 48 employee2 = new Employee("Saleh", "Mahmoud", 2500); 49 50 Console.WriteLine("First Employee: {0}", employee1.DisplayInfo()); 51 Console.WriteLine("Second Employee: {0}", employee2.DisplayInfo()); 52 } 53 } 54 } أضفت الخاصيّة SalaryAfterTax (الأسطر من 11 حتى 17). وأجريت تعديلًا طفيفًا ضمن التابع DisplayInfo في السطر 21 حيث أضفت المحرف n\ والذي يُستخدم ضمن النص للإشارة إلى وجوب الانتقال إلى سطر جديد لأغراض تنسيقية فقط، كما أضفت مكانًا في النصّ التنسيقيّ {3:N0} لإدراج قيمة الراتب بعد خصم الضريبة this.SalaryAfterTax، وهذا كلّ ما في الأمر. إذا حاولت في هذا البرنامج أن تُسند أيّ قيمة إلى الخاصيّة SalaryAfterTax ستحصل على خطأ يفيد أنّها للقراءة فقط read only. الأعضاء الساكنة Static Members هي أعضاء يمكن استدعاؤها مباشرةً من الصنف الذي صُرّحت ضمنه، وليس من كائن مُنشَأ من هذا الصنف. يمكن أن نجعل أيّ عضو ساكن وذلك بوسمه بالكلمة المحجوزة static. يوضّح البرنامج Lesson07_04 استخدام التوابع الساكنة. لاحظ وجود الكلمة المحجوزة static بعد محّدد الوصول public: 1 using System; 2 3 namespace Lesson07_04 4 { 5 class Calculator 6 { 7 public static double Addition(double x, double y) 8 { 9 return x + y; 10 } 11 12 public static double Minus(double x, double y) 13 { 14 return x - y; 15 } 16 17 public static double Division(double x, double y) 18 { 19 if (y == 0) 20 { 21 return double.NaN; 22 } 23 else 24 { 25 return x / y; 26 } 27 } 28 29 public static double Multiplication(double x, double y) 30 { 31 return x * y; 32 } 33 } 34 35 class Program 36 { 37 static void Main(string[] args) 38 { 39 double x = 5; 40 double y = 9; 41 42 double addition = Calculator.Addition(x, y); 43 double minus = Calculator.Minus(x, y); 44 double multiplication = Calculator.Multiplication(x, y); 45 double division = Calculator.Division(x, y); 46 47 Console.WriteLine("{0} + {1} = {2}", x, y, addition); 48 Console.WriteLine("{0} - {1} = {2}", x, y, minus); 49 Console.WriteLine("{0} * {1} = {2}", x, y, multiplication); 50 Console.WriteLine("{0} / {1} = {2}", x, y, division); 51 } 52 } 53 } نفّذ البرنامج السابق لتحصل على الخرج التالي: 5 + 9 = 14 5 - 9 = -4 5 * 9 = 45 5 / 9 = 0.555555555555556 أنشأنا الصنف Calculator الذي يحتوي على التوابع الساكنة Addition و Minus و Multiplication و Division. إذا انتقلنا إلى التابع Main (الذي هو بالمناسبة تابع ساكن بسبب وجود الكلمة static) انظر إلى السطر 42 كيف استدعينا التابع Addition من الصنف Calculator مباشرةً بدون إنشاء أي كائن من هذا الصنف. سنكرّر نفس العمليّة من أجل التوابع Minus و Multiplication و Division. أمرٌ أخير. انظر إلى محتوى التابع الساكن Division، ستجد أنّنا نختبر قيمة y فيما إذا كانت تساوي الصفر أم لا. فإذا كانت قيمة y تساوي الصفر فإنّه لا يجوز القسمة على صفر. لذلك فنرجع double.NaN وهو عبارة عن ثابت يُعبّر عن عدم وجود قيمة عدديّة. وهذا أمر طبيعي لأنّ القسمة على صفر لن تعطينا عدد. إذا استبدلت قيمة y في السطر 40 من البرنامج السابق بالقيمة 0 سنحصل على الخرج التالي: 5 + 0 = 5 5 - 0 = 5 5 * 0 = 0 5 / 0 = NaN لاحظ السطر الأخير من البرنامج كيف يبدو منطقيًّا تمامًا. يمكننا تعميم نفس المفهوم السابق بالنسبة للخصائص والحقول ضمن الصنف بجعلها ساكنة وذلك بإضافة الكلمة المحجوزة static بعد محدّد الوصول مباشرةً. بقي أن نشير إلى أنّه من غير الممكن استخدام الكلمة المحجوزة this ضمن أي عضو ساكن والسبب كما أعتقد واضح. يُشير this إلى الكائن الذي يحدث من ضمنه الاستدعاء. ولكن في الأعضاء الساكنة فإنّنا نجري الاستدعاءات للتوابع أو الخصائص من الصنف المصرّحة ضمنه مباشرةً، لذلك فاستخدام this لن يكون له أيّ معنى. تمارين داعمة تمرين 1 أجرِ تعديلًا على البرنامج Lesson07_03 بحيث يُضيف الخاصيّة Tel (قابلة للقراءة وللكتابة) التي تمثّل رقم الهاتف للموظّف Employee، ثمّ أجرِ التعديل المناسب على التابع DisplayInfo لكي يعرض قيمة هذه الخاصيّة على سطر منفصل كما يفعل مع بقيّة الخصائص. تمرين 2 أنشئ صنفًا سمّه StaticDemo بحيث يحتوي على خاصيّة ساكنة اسمها Counter من النوع int. عند كل إنشاء لكائن من هذا الصنف يجب زيادة قيمة هذه الخاصيّة بمقدار 1 وبشكل تلقائيّ. (تلميح: يمكنك كتابة العبارة البرمجيّة المسؤولة عن زيادة قيمة الخاصيّة Counter ضمن بانيّة الصنف StaticDemo التي ليس لها وسائط.) الخلاصة تعرّفنا في هذا الدرس على كيفيّة التعامل مع الخصائص، والتي تمثّل أسلوبًا أكثر تطوّرًا من الحقول لتشكّل مزايا الصنف. كما اتفقنا أنّه ينبغي على الحقول أن تكون داخليّة بالنسبة للصنف باستخدام محدّد الوصول private، وتعرّفنا أيضًا على الأعضاء الساكنة static members وكيفيّة التعامل معها.

أثناء عملي بوظيفة بدوام كامل؛ كان يصادفني بعض العملاء ممن يطلبون أعمالًا كتابية لهم -بشكل حر-، ورغم ميلي لهذا النوع من العمل إلا أنني لم أكن واثقة من إمكانية التحوّل إليه بالكامل، وفي حين يعاني المستقلون عادة من مخاوف كثيرة في بداية انتقالهم للعمل الحر؛ كان لديّ تخوّف واحد فحسب: المال. فالمال هو ما يحرك العالم بالنسبة لي، وهو ما يتيح لي شراء منتجات تجميلية من علامات تجارية مشهورة، أو حضور فيلم سينمائي في ليلة عرضه الأولى، بالإضافة إلى ما هو أهم: الادخار للتخطيط للحياة التي أطمح لها، في منزلي الخاص مع أطفالي. ما منعني من الانتقال إلى العمل الحر أثناء عملي الوظيفي هو شكوكي بإمكانية تأمين متطلبات معيشتي الأساسية من خلاله، ورغم معرفتي بمستقلين يجنون الكثير من المال، إلا أنني لم أكن واثقة من أنني سأكون كذلك؛ وبدت الأمور ضبابية بالنسبة لي، فالحديث عن الراتب وكم تنفق على منزلك، وكم تتقاضى على ساعة العمل، أمور كهذه لم يكن مألوفًا الحديث عنها في محيطي. وحقيقة فإن السبب الذي دفعني للبدء بالعمل الحر هو أن المستقلين تعاملوا معي بوضوح تام بخصوص الجانب المادي، أخبروني بكم يسعرون خدماتهم وكم يجنون من العمل الحر، وأكّدوا لي وجوب اتخاذي لهذه الخطوة. أعمل كمستقلة منذ شهرين فحسب؛ رغم ذلك أشعر بأنني أبلي بلاء حسنًا دونما كثير جهد، وبرأيي فإنه يجدر بالمستقلين إجراء مناقشات مستمرة مع بعضهم البعض بشكل فعلي، كم يجب أن نسعر خدماتنا؟ كيف يمكن أن نؤمن مستقبلنا؟ نقاشات كهذه واجبة وضرورية بين المستقلين، وإليكم الأسباب: 1- حتى تعلم المقابل المادي الأنسب لعملك في بداياتهم؛ يواجه العديد من الكتاب المستقلين فرص عمل منخفضة الأجور من عملاء يرغبون بمقال مقابل 15-20$، وبالتأكيد فإن المصممين المبتدئين يتلقون عروضًا مماثلة. قد تغريك هذه العروض في خطواتك الأولى؛ والسبب -كما تظن- أنك لا تملك خبرة كبيرة في العمل الحر وأجوره؛ وأن العملاء يعرفونه بشكل أفضل. لكن هل تعلم من لديه معرفة أوسع من العملاء بهذا الشأن؟ المستقلون الآخرون. ابحث عن مستقلين في محيطك، وليكن من بينهم ذوي الخبرة الممتازة وآخرين مبتدئين مثلك، واسألهم عن الأجور التي يتقاضونها لقاء عمل مشابه، بهذا تستطيع تقدير موقعك الحالي؛ والأجر الأنسب لمستوى خبرتك. 2- لتحسين عالم العمل الحر يتعامل العديد من العملاء مع إنشاء المحتوى كسلعة، لذا يبحثون عن العروض الأرخص والأسرع، لكن هل هذه الصورة هي ما نريد ترسيخه كمستقلين عن العمل الحر؟ نحن بحاجة لجعل أجورنا كفيلة بتأمين معيشتنا بغية دعم أنفسنا بشكل أكبر، وإذا أردنا من أصحاب المشاريع أن يدركوا قيمة العمل الإبداعي، فعلينا أن نسعّر أعمالنا وفقًا لهذا المنظور، والطريقة الوحيدة التي نتأكد بها أن مجتمع المستقلين يسعّر بشكل مناسب ويقدّم أعمال متقنة ومبدعة هي عن طريق مشاركتهم ذلك، فمشاركة السعر الواجب علينا طلبه يشجع أولئك الذين يعملون مقابل الفُتات على طلب المزيد. 3- لكسر عزلة العمل الحر كنت ألتقي بالكثير من الناس يوميًا في وظيفتي المكتبية، يستمعون لطرائفي، ويشاركونني المقالب والضحكات، ويساعدوني في شتى النشاطات، كان لدي مدير يساعدني في ترتيب أولويات مهامي، وفي تطوير نفسي باحتراف. أما اليوم كمستقلة، أشعر بعزلة كبيرة مقارنة مع ذلك، وكان من الممكن أن أكون وحيدة كليًا لولا وجود مجتمع من المستقلين حولي ممن يعلمون ما معنى أن تعمل بمفردك. نتبادل الأحاديث عبر مواقع التواصل الاجتماعي خلال النهار ويتفقد أحدنا الآخر، ولكم مدّني هؤلاء المستقلون بالدعم كلما شعرت بالإحباط، عندما أصادف مراجعات مربكة من العملاء، أو عندما لا أكون واثقة كم يجب أن أسعر خدمتي، أتجه فورًا لمجتمع المستقلين لأستلهم منهم الآراء والنصح. 4- لتشارك المشاكل المادية وتبادل حلول لها تناولت الغداء مع صديقة عقب عملي الحر بفترة قصيرة، وكان لديها العديد من الأسئلة، أدركتُ أن الجانب المادي للعمل المستقل مربك وغير مفهوم بالنسبة لها، ازداد ذلك وضوحًا عندما أخبرتها بعد الغداء أن لديّ لقاء مع المحاسب، وكان استغرابها شديدًا. لندع المزاح جانبًا، فقد تجاوز العمل الحر القواعد التقليدية للأعمال الوظيفية التي تعرفها عائلاتنا ومحيطنا، ما يجعله معقدًا وغير مفهومًا بالنسبة لهم، إذ يجدر بنا أن نقدّر الضرائب بدقة، ونقتطع أجور البرمجيات التي نحتاجها؛ ونتعامل مع علاماتنا التجارية الشخصية، وننتبه لتأمين التقاعد والمستقبل. وفي الحقيقة ثمة العديد من المصادر المتوافرة على الشبكة لمساعدتنا في ذلك، لكن أيًا منها لا يعوّض المناقشات المطولة لكل حالة، وعندما نتشارك همومنا "الفريدة" ومشكلاتنا المالية النادرة مع بعضنا البعض، سندرك فجأة أنها ليست نادرة كليًا، الأمر الذي سيشعرنا بارتياح كبير. 5- ماذا عن التنافس؟ قد يميل البعض من المستقلين إلى الحفاظ على موضوع التسعير كسرّ خاص بهم، خوفًا من أن تقضي المنافسة عليهم، لكنني لا ألقي بالًا لهذا الأمر، لا أشعر بالندرة بل أعتقد أن هناك عمل يكفينا جميعًا؛ وبشكل خاص: لأولئك المميزين في مجالهم. في الحقيقة؛ فإن العاملين في مجال العمل الحر غالبًا ما يحصلون على المشاريع من خلال بعضهم البعض؛ ووفقًا لدراسة أجراها اتحاد المستقلين، فإن 81% منهم يمررون الأعمال لمستقلين آخرين. شخصيًا فقد حصلت على الكثير من المشاريع بهذه الطريقة، لذا أود أن أبني علاقات إيجابية مع بقية أفراد مجتمعي؛ وأعتبرهم أصدقاء لا منافسين. تشاركوا الوفرة لم يكن لي لأعمل كمستقلة لو لم يخبرني من يعملون في هذا المجال كم يجنون من المال، لا أعني بحديثي هذا أن تكتب الرقم الذي تتقاضاه لقاء عملك كمنشور على موقعك الشخصي، لكنني أقترح أن نكون صادقين مع المستقلين الذين يعملون معنا في ذات الدرب. ترجمة -وبتصرّف- للمقال Why Freelancers Should Discuss Rates With Each Other لكاتبته Emma Siemasko. حقوق الصورة البارزة: Designed by Freepik.