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

توفر الكثير من المواقع واجهات برمجية Application Programming Interface ،API بهدف إتاحة موارد الموقع لتطبيقات خارجية؛ قد تكون تطبيقات ٍللجوال، أجهزةً لوحية، أو أجهزةً مكتبية. قد نود مثلا إنشاء تطبيق للجوال نعرض فيه منتجات الموقع. نستخدم لغة البرمجة المناسبة للتطبيق (جافا مثلا لتطبيقات أندرويد) الذي يرسل طلبات لواجهتنا البرمجية يحصُل بموجبها على بيانات يتولى هو طريقة عرضها. نقول إن تطبيق الجوال في هذه الحالة يستهلك Consume الواجهة البرمجية. هذا الدرس جزء من سلسلة تعلم Laravel والتي تنتهج مبدأ "أفضل وسيلة للتعلم هي الممارسة"، حيث ستكون ممارستنا عبارة عن إنشاء تطبيق ويب للتسوق مع ميزة سلة المشتريات. يتكون فهرس السلسلة من التالي: مدخل إلى Laravel 5.تثبيت Laravel وإعداده على كلّ من Windows وUbuntu.أساسيات بناء تطبيق باستخدام Laravel.إنشاء روابط محسنة لمحركات البحث (SEO) في إطار عمل Laravel.نظام Blade للقوالب.تهجير قواعد البيانات في Laravel. استخدام Eloquent ORM لإدخال البيانات في قاعدة البيانات، تحديثها أو حذفها. إنشاء سلة مشتريات في Laravel.الاستيثاق في Laravel. إنشاء واجهة لبرمجة التطبيقات API في Laravel. (هذا الدرس)إنشاء مدوّنة باستخدام Laravel.استخدام AngularJS واجهةً أمامية Front end لتطبيق Laravel.الدوّال المساعدة المخصّصة في Laravel.استخدام مكتبة Faker في تطبيق Laravel لتوليد بيانات وهمية قصدَ الاختبار. نغطي في هذا الدرس المواضيع التالية: ماهي واجهات REST البرمجية؟الممارسات المنصوح بها في واجهات REST البرمجية.إنشاء واجهة برمجية لمشروع Larashop.ماهي واجهات REST البرمجية؟توصف الكثير من الواجهات البرمجية بأنها RESTful، فما المقصود بهذا الوصف؟ تختصر REST العبارة Representational State Transition (النقل التمثيلي للحالة) وهي طريقة لتصميم البرمجيات تعرِّف معاييرَ يجب على خدمات الويب اتباعها من أجل أداء أعلى وصيانة أسهل. تعتمد بنية التطبيقات REST على بروتوكول HTTP لإرسال الطلبات والحصول على إجابات؛ ومن أهم القيود التي يجب الالتزام بها في تطبيقات REST: العمل حسب مبدأ خادوم-عميل Server-Client، انعدام الحالة Stateless وتوحيد الواجهات (إضافة لقيود أخرى). مبدأ خادوم-عميل: يجب التفريق بين واجهة المستخدم والخادوم الذي يخزن البيانات ويطبق العمليات عليها.انعدام الحالة: يجب أن يحوي الطلب الموجّه من العميل إلى الخادوم كل المعلومات الضرورية ليستطيع الخادوم فهمه والإجابة عليه؛ دون الحاجة لسياق محفوظ على الخادوم (لفهم الطلب).توحيد الواجهات بمعنى أن كل مورد على الخادوم يمكن تعريفه فرديا واستغلاله عبر بيانات تمثله يحتفظ بها العميل. يجب أن تكون الطلبات واضحة يمكن فهمها والإجابة عنها دون الحاجة لمعلومات خارجة عنها. يدخل ضمن توحيد الواجهات أيضا افتراضُ العميل أن أي إجراء Action غيرُ متوفر على الخادوم، ما لم يصّرح هذا الأخير بتوفره.تساهم هذه القيود (والقيود الأخرى التي تعرفها بنية REST) في تسهيل عمل الواجهات، الرفع من أدائها، تيسير الصيانة وقابلية التمدد Scalability. سنرى في الفقرة التالية توصيات لبناء واجهات برمجية تساعد في احترام مبادئ REST. ملحوظة: يكثُر وصف الواجهات البرمجية بأنها RESTful (تلتزم بقيود REST) دون أن تلتزم بكامل القيود التي تعرِّفها بنية REST، وهو ما يجعلها أقرب لواجهات شبيهة لـREST منها لواجهات RESTful. الممارسات المنصوح بها في واجهات REST البرمجيةيُساعد الالتزام بالممارسات التالية في بناء واجهة تطبيقات برمجية ذات أداء عال وقابلية كبيرة للتمدد والصيانة. استخدام إجراءات HTTP لتحديد العمل الذي سيؤديه الخادوم: GET للحصول على مورد، POST لإنشاء مورد جديد، PUT لتحديث مورد وDELETE لحذفه.أَصْدَرَة Versioning الواجهة: يساعد استخدام إصدارات في عدم كسر التطبيقات التي تستهلك الواجهة البرمجية. يحدّد العميل إصدار واجهة التطبيق الذي يود العمل عليه مما يسمح بإحداث تغييرات على الخادوم تضمَّن في إصدار جديد دون أن يتوقف عملاء الواجهة البرمجية.من المتعارف عليه استخدام أسماء جموع لوصف الموارد، api.mysite/v1/products مثلا للمنتجات. ليس واجبا اتباع هذا العرف لكن الأهم هو تناسق تسمية الموارد: لا تخلط بين أسماء مفردة للموارد وجموع.استخدام الإجابات الجزئية: طلب العميل اسم المنتج؟ أرسل اسم المنتج فقط، وليس كامل بيانات المنتج، في الإجابة.استخدام رموز الحالة: تسهّل رموز الحالة في HTTP التخاطب مع العميل. عولج الطلب على النحو الأمثل؟ أرسِل الرمز 200 في الإجابة. طلب العميل إنشاء مورد وتم الأمر؟ أرسل الرمز 201 في الإجابة؛ وهكذا. راجع هذا الرابط للمزيد من رموز الحالة في HTTP.ضع حدًّا أقصى لعدد الطلبات القادمة من نفس عنوان IP في الواجهات المفتوحة للجميع. يساعد هذا الأمر في التصدي للعملاء الذي يفرطون في استخدام واجهة تطبيقاتك البرمجية. ينصح أيضا بحظر عناوين IP ذات السلوك المشبوه حتى لا يؤثر على بقية المستخدمين.قد يُختلف حول هذه التوصية، إلا أنه يُنصح باستخدام صيغة JSON لإرسال البيانات في الإجابة عن الطلب، ما لم يحدّد العميل عكس ذلك.خبِّئ Cache نتائج طلبات GET التي لا تتغير كثيرا. ربما تكون قائمة العلامات التجارية في مواقع التسوق مثالا جيدا للبيانات التي يجب تخبئتها (قد تمضي أشهر دون الحاجة لإضافة علامة تجارية جديدة).واجهة Larashop البرمجيةسننشئ في هذه الفقرة واجهة تطبيقات برمجية لمشروع Larashop. تشتمل الواجهة على المسارات أدناه. تستخدم جميع المسارات إجراء GET للحصول على المورد. التسلسل المورد الرابط الوصف رمز الحالة1Product/api/v1/productsسرد لائحة بالمنتجات وخاصياتها2002Product/api/v1/products/1سرد خاصيات المنتج رقم 12003Category/api/v1/categoriesسرد لائحة بتصنيفات المنتجات2004Category/api/v1/categories/1التصنيف ذو المعرّف 1200لاحظ أننا لم نتح إمكانية التعديل على الموارد عبر الواجهة. تشير v1 في المسارات إلى رقم الإصدار 1. نفتح ملف المسارات routes.php ونعدّله بإضافة المسارات التالية: // API routes... Route::get('/api/v1/products/{id?}', ['middleware' => 'auth.basic', function($id = null) { if ($id == null) { $products = App\Product::all(array('id', 'name', 'price')); } else { $products = App\Product::find($id, array('id', 'name', 'price')); } return Response::json(array( 'error' => false, 'products' => $products, 'status_code' => 200 )); }]); Route::get('/api/v1/categories/{id?}', ['middleware' => 'auth.basic', function($id = null) { if ($id == null) { $categories = App\Category::all(array('id', 'name')); } else { $categories = App\Category::find($id, array('id', 'name')); } return Response::json(array( 'error' => false, 'user' => $categories, 'status_code' => 200 )); }]);يعرف المسار Route::get('/api/v1/products/{id?}', ['middleware' => 'auth.basic', function($id = null)رابطًا يطلب المنتجات مع معرّف اختياري id. يُستخدم المعرف لطلب منتج واحد وفي حال عدم ذكره ترجِع واجهة التطبيقات جميع المنتجات. نحمي المورد بالتعليمة 'middleware' => 'auth.basic' التي تستوثق من العميل. حددنا نمط الاستيثاق بـauth.basic لاستخدام بريد المستخدِم (حقل email في جدول users) مع كلمة السر. يستدعي كل مسار النموذج المناسب للعثور على البيانات في القاعدة ثم نرسل الإجابة بصيغة JSON بالتعليمة Response::json. عند طلب الرابط http://larashop.dev/api/v1/products ستظهر نافذة تطلب إدخال بريد المستخدم وكلمة سره. استخدم الحساب الذي أنشأته في درس الاستيثاق وستظهر النتيجة التالية في المتصفح (بعد التنسيق) { "error":false, "products": [ { "id":"1", "name":"Mini skirt black edition", "price":"35" }, { "id":"2", "name":"T-shirt blue edition", "price":"64" }, { "id":"3", "name":"Sleeveless Colorblock Scuba", "price":"13" } ], "status_code":200 }حصلنا على إجابة بصيغة JSON للطلب الذي أرسلناه من أجل الحصول على منتجات الموقع. يشير الرمز 200 إلى أن معالجة الطلب تمّت دون مشاكل. يمكن للعميل الآن تنسيق الإجابة لعرضها بطريقة مناسبة. خاتمةوضعنا في هذا الدرس أساسا يمكن البناء عليه لإنشاء واجهات برمجية أكثر تطورا. يتلخص إنشاء واجهات برمجية في Laravel في تعريف المسارات، استخدام النماذج للحصول على البيانات المطلوبة ثم تهيئة الإجابة بصيغة JSON ثم إرسالها. ترجمة -وبتصرّف- للمقال Laravel 5 REST API لصاحبه Rodrick Kazembe.

قد تواجهك بعض الصعاب في بداية عملك في التصميم ، وتحديدًا في العلاقات التي تطورها مع العملاء. يعود السبب في ذلك إلى التصوّرات المغلوطة من قبل العملاء حول ماهية عملنا، و أنه بإمكان “أي شخص أن يصمم موقعًا إلكترونيًا” . يعتقد العملاء أنه أمر سهل كسهولة فتح فوتوشوب ورسم شيء ما ثم كتابة ثلاثة أسطر من التعليمات البرمجية، وها قد أكملت تطوير موقع. جميعنا نعلم أن الواقع مغاير لذلك تمامًا. لكن لن يعي العملاء ذلك ولن نشرحه لهم. إن طريقة تحسين آراء العملاء تتمثل في محاولة إعطائم دروسًا مختلفة، إما بإخبارهم مباشرة أو بجعلهم يفهمون من خلال تعاونك معهم. على أية حال سيكون مفيدًا أن تفعل ذلك قبل أن توقّع العقد، لأن علاقة العمل ستتغير وستكون واضحة لهم منذ البداية. يمكنك بهذه الطريقة أن تضع بعض التوقعات، وسيعلمون بشكل جيد مع من يتعاملون. 1. أنت فنان، و لست عامل يفضّل أن تبدأ من هذه النقطة. اشرح لهم منذ البداية أنك تقوم بعمل إبداعي. أخبرهم أن المصممين بحاجة إلى الموهبة والمهارات و الخبرة كي يتمكنوا من تقديم منتجات عالية الجودة. أبدِ إعجابك بأي شخص أو فنان يعرف كيف يؤدي عمله. لا أحد يخبر الأطباء عن كيفية أدائهم لعملهم، وذلك لثقتهم بمعرفة الطبيب بصحتهم أكثر منهم، فعلى العملاء الثقة بالمصمم. إن مجرد معرفة العملاء بأن مزج الأزرق والأحمر يعطي اللون البنفسجي ومعرفتهم بالركيزة أو الحاوية، لا يجعلهم خبراء. أخبر عملاءك بأن عملية التصميم ليست سهلة كما يتصورونها، و إن بدت لهم كذلك فهذا يعود لمهارة المصمم في تقديم العمل. اشرح لهم أنك على استعداد لسماع آرائهم (سنتحدث عن ذلك لاحقًا)، وبأنك أنت الخبير وستفعل ما تعتقد بأنه أفضل للمنتج النهائي، بغض النظر إن اختلفوا معك. يحدث هذا الأمر غالبًا مع المصممين المستقلين، إن عملت ضمن استوديو، فعلى الأرجح سيتركونك تقوم بعملك بالطريقة التي تريدها. لكن الوضع يختلف مع المستقلين. يظن العملاء أنه بما أنك تعمل من دون مكتب أو لا تعمل من الساعة 9 إلى 5 في أيام الإثنين إلى الجمعة (الأمر الذي يفعله العديد منهم، بالمناسبة) فإنك غير محترف. أخبر عميلك أنك تملك ساعات عمل محددة كالبقية، ولا تسمح له أن يتصل بك في 10:30 مساءً ليطلب منك تعديلاً صغيرًا نهائيًا قبل طباعة المنشورات في الصباح التالي. إن وضع هذه الحدود سيجعل عملاءك أكثر حذرًا، وسيفكرون مرتين قبل الاتصال بك كثيرًا أو خارج ساعات العمل. 2. أنت الخبير وليس هم و هذه نقطة هامة أذكرها لك لأنه وفي الكثير من المرّات اتصل بي العميل ليخبرني كيف أقوم بعملي. خلاصة القول، أنت تعرف الويب أفضل منهم وعليهم ألا يشكّوا بذلك. لا يحق لهم إعطاؤك دروسًا حول وسائل التواصل الاجتماعي وقابلية الاستخدام والتصميم لمجرد أنهم يعرفون ذلك – وعلى الأرجح هم لا يعرفون أفضل منك-. يعتقد بعض الأشخاص أنهم أصبحوا مصممين لمجرد معرفتهم بكيفية فتح برنامج Illustrator أو لمجرد قيامهم بتصميم بطاقة دعوة زفاف جميلة باستخدام مايكروسوفت وورد. وضّح لهم منذ البداية من هو الخبير، لكن عليك أن تحرص على الطريقة التي تخبرهم فيها بذلك، فأنت لا تريد أن تبدو قاسيًا أو متعجرفًا. تعتمد طريقة تعاملك مع العملاء على عدة أشياء، لا أستطيع إخبارك الطريقة المناسبة كي تشرحها لهم، لكن إليك بعض الأفكار: حاول أن تشرح جميع الأسباب التي دفعتك لاتخاذ القرارات الأساسية. فعند سماعهم أنك قمت بشيء ما لهدف واضح، سيدركون أنك تعرف ما تفعله. استخدام الأبحاث والبيانات لدعم ما تقول أمر هام جدًا. ابحث عن ذلك باستخدام غوغل واستخدمه إن استطعت. سيُؤمن العملاء دومًا بالحل الذي اتبعته عندما سَيرون العديد من الناس يتبعونه أيضًا. يمكنك أيضا أن تستخدم الكتب وقواعد ومبادئ التصميم وحتى الأبحاث الأكاديمية أو الملفات لتوضيح أن ما تقوم به معترف به في مجال عملك (أو أنه مُحدث و مُبتكر). للأمثلة قوّة إقناع كبيرة إن أجدت استخدامها. وضّح لعميلك مواقع مهمة أخرى تستخدم نفس التقنية أو المبدأ. فبمجرد إخبار العميل بأن “اللاعبين الكبار” يستخدمونه، فسيطلبه بنفسه. توجد عدة أشياء أخرى يمكنك استخدامها أيضًا ، كالالتزام بالمواعيد والشكل اللائق والتنظيم وكتابة رسائل البريد الإلكتروني بمهنية و بالطبع الالتزام بالموعد النهائي. الأمر الأكثر أهمية هو أن يحترمك العميل، لكنك لن تتمكن من تحقيق ذلك إن لم تتبع هذه القواعد البسيطة. 3. آراء الآخرين تؤخذ بعين الاعتبار، فرض الآراء غير مقبول وهذه نقطة مهمة أيضًا، خصوصًا في زمن يعتقد الكل فيه بأنهم قادرون على التصميم. على المصمم أن يقبل آراء الآخرين ويأخذها بعين الاعتبار، فقد يملك الآخرون أفكارًا أفضل، وقد يملكون بعض الأفكار التي تحسّن من نتائجك النهائية. بجميع الأحوال، إن كانت الصفحة التي تصممها تنحو بمنحى لا يرغبه العميل، فهذا غير جيد لسمعتك، لذا اقبل آراء الآخرين دومًا. يوجد فرق واضح بين سماع آراء الآخرين وبين فرضها عليك. إن بدأ العميل بإملاء التوجيهات والأفكار عليك حول كيفية قيامك بعملك، عليك أن توقفه وتشرح له أنك تعرف ما تفعل. أخبره بأن يطمئن لحقيقة أن النتيجة النهائية ستكون أفضل مما يريد في الواقع، لأنك الخبير، كما ذكرت سلفًا. بجميع الأحوال، من الصعب حقًا أن تشرح للعميل، لذا احرص على ألا تكون قاسيًا. خصص وقتًا في البداية للاستماع لأسئلته وأجب عليها بدقة قدر الإمكان. ستنخفض رغبة أغلب العملاء في التدخل بالمشروع عندما تتحدث إليهم حوله. وضّح له منذ البداية أنك ترحب بآرائه حتى موعد التسليم، لكنك من سيتخذ القرار النهائي. 4. التواصل مهم جدًا إن الحفاظ على علاقة جيدة مع العميل خلال سير المشروع و بعد انتهائه مهمّ جدًا. لذا حاول أن تبقى على تواصل جيد مع العميل أثناء عملكما معًا. تكمن أهمية هذا الأمر أيضًا في أنه الطريقة الوحيدة لتعرف بم يفكر العميل وبم يرغب. لا تظهر بعد ثلاثة أسابيع وفي يدك المشروع النهائي جاهز للتسليم. حتى إن التزمت بموعد التسليم النهائي ولم تتخط الميزانية، فقد يستمرّ عدم رضا العميل لأنه بقي خارج العملية كليًا. يميل بعض العملاء إلى التدخل الزائد بعملية التصميم، لذا يحاول الكثير من المصممين البقاء بعيدًا ويظهرون فقط عند موعد تسليم المشروع وقبض المال والمغادرة. ستنتهي العلاقة هنا الأرجح بطريقة محايدة، ولن يعود العميل أبدًا للعمل معك. إن أشركت العميل ولو قليلاً بسير العمل، سيشعر بأنه جزء من المشروع، وبأنه من يتّخذ القرارات؛ بالرغم من أننا نعلم أن الأمر ليس كذلك. أن تشرح منذ البداية، والأفضل من ذلك أن تحدد في العقد، أنك ستطلب عدة اجتماعات مع العميل هو فكرة جيدة لتُشعر العميل بأنه جزء من عملية التطوير أكثر مما هو فعليًا متورط فيها. إشراك العملاء يعني عادة أنهم يقدّرون كثيرًا العمل الذي تقوم به وهم يشاهدونه يتطور من الفكرة الأساسية إلى المنتج النهائي. 5. الموقع الإلكتروني ليس مطبوعات هناك اعتقاد سائد ومغلوط أن الويب والمطبوعات متشابهان. حسنًا، ليسا متشابهين، ونحن نعلم ذلك، ولكن كيف نشرح ذلك لعملائنا المعتادين في الغالب على المطبوعات؟ قد يرغبون بموقع يشبه المنشور – في الوقت الذي لا ترغب فيه أنت بذلك-. من المهم أن تأخذ وقتك وتشرح لعملائك أن الويب يختلف كثيرًا عن المطبوعات (بالرغم من اعتقادي أننا جميعًا موافقون على أنه قبل أنت تعرف الفرق فمن السهل أن تفهم سبب اعتقاد الناس أنهما متشابهان تقريبًا) وهناك قواعد مختلفة. قررنا الآن من هو الخبير، فلم لا تقوم بعملك كخبير وتُثقفَ عملاءك؟ لست بحاجة لأن تقرأ لهم كتابًا كاملاً عن التصميم، اشرح لهم فقط بعض المفاهيم الأساسية وزوّدهم بالأمثلة – سيكون العملاء سعداء جداً في قبول حقيقة أنك الخبير عندما تتصرف بطريقة الخبراء. 6. لا وجود لـ “تغيير أخير و صغير” إن كانت لديك خبرة ولو ضئيلة جدًا في مجال التصميم فلا بد و أنك سمعت بهذه العبارة. و المزعج في الأمر أنه يحدث غالبًا في اللحظات الأخيرة قبيل موعد التسليم ويؤثر على العملية بأكملها ، بما في ذلك تسليمك العمل في موعده النهائي. يمكن لعملية بسيطة كتغيير اللون أن تكون معقدة، لأنه يتوجب عليك العودة وإعادة تصدير الملفات وتغيير النمط وحتى إجراء تعديلات عامة على التصميم كي يتماشى مع الألوان الجديدة. في اعتقادي الشخصي، إن أهم البنود التي يجب أن تشدّد عليها في العقد هو بند التنقيح. وضّح للعميل أن كل تغيير في المخطط سيكلفه المزيد من المال. اسمح لهم بإجراء تغيير أو تغيرين في المخطط (بالاعتماد على حجم المشروع) وابتداءً من هنا يمكنك تقاضي المال. سيفكرون مرتين قبل أن يتصلوا بك قبيل موعد التسليم بأربع ساعات ليطلبوا تغييرًا نهائيًا صغيرًا. 7. ضع مواعيد تسليم معقولة نعلم جميعًا أن جميع العملاء يرغبون باستلام المنتج بأسرع وقت ممكن، علمًا أن بعض العملاء لا يدركون الوقت الذي قد يتطلبه إنشاء موقع إلكتروني صغير ، ويطلبون مواعيد صعبة أو مستحيلة للتسليم. اشرح للعميل أن تصميم الموقع و تطويره و تفعيله لا يمكن أن يتم خلال يومين فقط، ولا توقّع العقد إن لم يكن موعد التسليم النهائي معقولاً؛ إذ يُفضَّل ألا تقوم بالعمل مع هؤلاء العملاء من أن تقوم به ولا تقبض مستحقاتك، أو أن يخصم منها لعدم التزامك بموعد التسليم الصعب. هذا أيضًا ليس أمرًا يسهل شرحه، يمكنك في الواقع أن تجهز مسودة للعمل وتوضح للعميل كيف ستقسم ساعاتك. هناك احتمالية كبيرة لأن يفهم العميل ذلك. نصيحة أخرى هي ألا تسلّم مسودة عمل تعتقد أنها تفي بالغرض لذاك النوع من المشاريع. فعبارة “تفي بالغرض” غير كافية على الإطلاق. ضاع الوقت الذي تظن أنك تحتاجه مرتين وثلاثة؛ فالعميل لا يعرف الوقت الذي تستغرقه عملية التصميم على أية حال. لا أقول لك أن تخدع العميل ليدفع لك أكثر مما تستحق، لكن عليك أن تضمن توفير الوقت للقيام بمثل هذه التغييرات الصغيرة وللحالات الطارئة التي قد تتعرض لها. من الأشياء الجيدة في تحديد موعد للتسليم هو أن العملاء سيسعدون دومًا عندما يستلمون المنتج بأسرع من المتوقع. أقول دومًا: “خفف الوعد وعجّل التسليم”. فقد يعتقد العملاء أنك عملت على مشروعهم أكثر مما ينبغي وسيكونون سعداء عندما يدفعون لك أتعابك في نهاية التعاون، حتى إنهم قد يوظفوك مرة ثانية في وقت قريب. 8. العقد ليس فقط للتسلية نحن لا نلعب لعبة المصمم والعميل. هذا عمل جدي، يتوجب عليك فيه أن تحترم العقد الذي وقعته مع العميل. من المهم أن يكون لديك عقد مُحكَم، وبغض النظر عن نوع الصفقة، عليك أن تعود إليه دومًا عند الحاجة. أخبر العميل منذ البداية أن العقد مهم وأنك ترغب باحترامه. سيأخذ العميل انطباعًا جيدًا عنك وسيدرك مدى جديتك ومهنيتك. حتى أقدم لك بعض الأفكار عما ينبغي أن يتضمنه العقد، فقد أعددت القائمة التالية: الاجتماعات مع العملاء. ساعات العمل. ساعات الاتصال. الأحداث الهامة. الرخصة (ملكية المنتج عند الانتهاء من العمل). الميزانية. قواعد الدفع. قاعدة التنقيح. هذا ليس كل شيء، لكن ما سبق هو بعض أكثر البنود أهمية والتي سترغب في وضعها ضمن العقد مع العميل. ضع في الحسبان أن هذه النصيحة ليست بخصوص وجود العقد (لن نتطرق إلى ذلك حتى)، لكنها تتعلق بإعادة النظر في العقد جنبًا إلى جنب مع العميل. لذا احرص على إبقائه قصيرًا، وأرغم العميل على إعادة النظر فيه وذلك بتواجده هناك أثناء التوقيع. الخلاصة أن تكون مصممًا أو مطورًا ليس بالأمر السهل، وأنا لا أقول ذلك نظرًا للمهارات المطلوبة، بل نظرًا للحاجة إلى العمل مع أشخاص مختلفين دومًا. لن تصادف عميلين أو مشروعين متشابهين أبدًا. تظهر التحديات والصعوبات دائمًا في التواصل مع العملاء، ويعود الأمر لك في حلّ هذه الصعوبات. ليس سهلاً أن تقف في وجه من يدفع لك، لكنه أمر مجد. لا تخف من مشاركة هذه الدروس مع عملائك، لكن انتبه لكيفية فعل ذلك. هل صادفتك مشاكل كهذه مع العملاء، كيف قمت بحلها، أم اكتفيت بقيامك بالعمل دون التطرق لها؟ ترجمة - بتصرف - للمقال How Web Designers Can Develop a Relationship with Clients. حقوق الصورة البارزة محفوظة لـ Freepik