Khaled Shagrouni

كيف يتم تقدير تكلفة منظومة

(مقالة قديمة جدا قبل تطبيقات الويب والموبايل)

مقترح لمعيار تقدير تكلفة تطبيقات قواعد البيانات

المقترح يخصّ فقط السائد من منظومات قواعد البيانات
التي يجري الاتفاق عليها بين المطور والزبون قبل التنفيذ فعليا.
دون الأخذ في الاعتبار إمكانية إعادة بيع نفس المنظومة مرة أخرى.

على أي أساس تحسب تكلفة منظومتك.
كيف يقتنع الزبون بأن السعر المطروح مناسب لتطبيقك؟
على أية أسس يقوم الزبون بتقرير ما إذا كان السعر مناسبا أم لا؟
هل يمكن للمطور والزبون أن يتفقا على معيار يحدّدان به تكلفة منظومة؟

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

في منظومة قواعد بيانات؛ ما هي أكثر العناصر التي إذا تغيرت كميتها تغيرت كمية الجهد المبذول على معظم نواحي المنظومة؟

الإجابة الأولى التي تخطر هي: حقول قاعدة البيانات. فالملاحظ أن كل حقل يتم اضافته لجدول في قاعدة البيانات يترتب عنه كم من الجهد البرمجي يتوزّع على معظم نواحي المنظومة.
القائمة التالية تسرد بعضا من أنواع الجهد البرمجي الذي قد يرافق إنشاء كل حقل:

وضع الحقل بطريقة تضمن الاتّساق العام لتصميم و معمارية التطبيق، وربما إعادة هيكلتهما.
إضافة مداخل الحقل في الصنفيات ذات العلاقة: الصنفيات الأساسية والفرعية كصنفيات طبقات البيانات، والعرض.
خانة على واجهة الاستخدام لاستقبال بياناتها من المستخدم.
قائمة بمقترحات البيانات لهذه الخانة تقدّم للمستخدم للإختيار منها.
تعليمات برمجية للتحقّق من صلاحية بيانات الخانة.
تعليمات برمجية للتحقق من عدم تكرار المعلومة المدخلة.
تعليمات برمجية لمناولة ادخال بيانات الحقل داخل قاعدة البيانات.
خانة أو أكثر لإستظهار بيانات الحقل.
تعليمات برمجية لمناولة إدخال وتعديل وإستخراج بيانات الحقل في قاعدة البيانات.
تعليمات برمجية لتضمينها في شروط البحث أو الاستعلام
خانة أو أكثر ضمن تصميم صفحات التقارير.
تعليمات برمجية عند إعداد التقارير بحسب عددها.
تعليمات إضافية داخل قاعدة البيانات، كإجرائيات مخزّنة أو مبدّلات.
تعليمات لتضمينها ضمن صلاحيات المستخدم للإضافة والعرض والتعديل و الإلغاء.
شروحات في دليل الاستخدام أو ملف المساعدة.

القائمة السابقة كما أسلفنا هي سرد لبعض أنواع جهود التصميم والبرمجة التي تصاحب كل حقل، وتزيد وتتعمّق هذه الجهود البرمجية بحسب متطلبات المنظومة الوظيفية والفنية.

إن الافتراض بأن حجم الجهد البرمجي في منظومة يتناسب مع عدد الحقول بها، قد لا يكون حقيقيا تماما ولكن بالتأكيد يعكس جانبا كبيرا من الواقع، وهذا ما يشجّع على تحسّس إمكانية اعتباره أساسا أو معيارا لتقدير تكلفة بناء منظومة قواعد بيانات.
تطبيقا لهذه المقاربة بأبسط صورها، دعنا نقول أن تكلفة الحقل الواحد مثلا 30 دينار. سيكون تقدير تكلفة منظومة بها 40 حقلا هو 1200 دينار.

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

مثال على هذه العوامل:
هل قاعدة البيانات مكتبية أم بتقنية خادم/عميل؟ إذا كانت الأخيرة يتم إضافة قيمة أخرى إلى القيمة الأصلية للخانة ولتكن 10 دينار مثلا.
عدد التقارير المطلوب إنجازها، ويتم إضافة قيمة لكل تقرير ولنقل نصف دينار.
هل يوجد دليل تشغيل للمنظومة، يضاف 10 دينار.
مدى خبرة المبرمج ومدى جودة برامجه. ويضاف نقاط لها.
واستكمالا لمثالنا السابق، اذا افترضنا أن المنظومة ستكون بتقنية خادم/عميل، بعشرة تقارير مع وجود دليل استخدام، فإن سعر الخانة سيكون: 30 + 10 + (10 × 0.5) + 10 = 55 دينار.
وبالتالي تكون اجمالي تكلفة المنظومة ذات 40 خانة 2200 دينار.

ملاحظات عامة:

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

ماذا عن تقدير الوقت اللازم للتنفيذ؟

المعيار المقترح هو لتقدير تكلفة المنظومة، لكن هل هذا المعيار سيكون صالحا لتقديرالوقت اللازم لتنفيذ المنظومة؟ لو حدّدنا أن الزمن المقدّر لتنفيذ خانة هو نصف يوم، فهل يصلح أن نقول أن منظومة تحوي 40 خانة سيستغرق تنفيذها 20 يوم؟
هذا أمر يحتاج لمزيد من البحث و الدراسة.

السؤال الآن : هل يمكن اعتماد عدد الحقول كأساس للتسعير في منظومات كهذه؟

لا أعلم مدى نجاعة هذا الاقتراح أو مدى تطبيقه عمليا، ولكن الأمر قد يستحق التأمل.

لمن يريد أن يعرف معنى Hard-coded في البرمجة.

لغات بيئة .net سريعة جدا لكن فيسع ما تدهش.

عند البرمجة؛ أكثر الاشياء ازعاجا وارهاقا : دعم اللغة العربية ومناولة التواريخ.

زمان كانت انواع قواعد البيانات هي العلائقية relational و الهرمية hierarchical والشبكية network وبعدها جت قواعد البيانات الكائنية object oriented ، الان باستثناء العلائقية لا أحد يتحدث عنهم

في لغات البرمجة الدالية واللغات التي تدعم المفاهيم الدالية functional concepts عموما، تكون الدالّة أو ال Function مواطن درجة أولى (first class citizen)، ويقال عنها أيضا دالة مستوى أعلى higher-order function (HOF)
ما معنى أن تكون الدالة و غيرها مواطن درجة أولى وذات مستوى أعلى في لغات البرمجة؟
سنبدأ بالشرح العملي ؛ سوف نستخدم لغة F # لشرح المفاهيم الخاصة بالدالة، وقد اخترت هذه اللغة لبساطتها و وضوحها في تبيان المفاهيم التي سنتعرّف علها، مع هذا؛ قمت باعداد نسخ لهذه الأمثلة بلغات أخرى للمقارنة ولمزيد من الاستيعاب، تم إعدادها بلغة Python ولغة Go ولغة Rust. (تجدون الرابط لها أدناه).
لنبدأ،
الصيغة الأبسط لتعريف دالة function هي:
‏let add x y = x + y
إسم الدالة هو add، وبها محددان parameters وهما x و y، وبعد علامة = يكون جسم الدالة وهو x + y ولأن x + y هو التعبير expression الوحيد والأخير في جسم الدالة، فسيكون ناتج هذا التعبير هي القيمة التي ترجعها الدالة.
في F # (والعديد من اللغات الأخرى) يمكن الاستغناء عن تحديد نوع البيانات صراحة explicitly وجعل اللغة تستنتج أو تستدل inference على نوع البيانات ضمنيا implicitly ، لذلك إذا أردنا تحديد نوع البيانات صراحة في الدالة فستكون الدالة كالتالي:
‏let add (x: int)(y: int): int = x + y
لاحظ أننا لا نحتاج لوضع أمر return أو result حيث أن آخر تعبير في الدالة سيتم اعتباره قيمة الدالة المرتجعة ، وسنلاحظ نفس الأمر في لغة Rust.
مناداة هذه الدالة واستدعائها تتم بالتعبير التالي:
‏let a = add 1 1
على نفس المنوال، يمكننا أيضا صنع دالة أخرى ترجع حصيلة ضرب رقمين (سنحتاجها لاحقا):
‏let multiply x y = x * y
1- تخصيص دالة لمعرّف (متغيّر)
في اللغات الدالية يمكن تخصيص معرّف identifier (أو متغيّر variable) للدالة، فنقول مثلا:
‏let my_add = add
هنا تم تخصيص الدالة للمعرّف my_add ، وبإمكان المعرّف أن يقوم مقام الدالة، ونتحصّل على نفس النتيجة.
‏let aa = my_add 1 1
الصيغة الأصلية للدالة:
صيغة الدالة التي رأيناها سابقا:
‏let add x y = x + y

هي صيغة مُحلاة syntactic sugar أي أنها صيغة محوّرة عن الصيغة الأصلية من أجل سهولة الاستخدام، أما الصيغة الأصلية فهي:
‏let add = fun x y = x + y
‏add هنا سيكون معرّف (متغيّر) تم تخصيص قيمة له، القيمة هنا دالة ليس لها اسم في حد ذاتها، ويشار للدالة في لغة F # ب fun. بعض اللغات تشير إليها بكلمة lambda وأخرى تشير إليها بكلمة anonymous (بعض محررات الكود تكتب العلامة λ بدلا من lambda).
إذا دالة لامبدا أو الدالة عديمة الإسم anonymous هي هيكل لدالة بدون إسم.
ولأنها دالة مكتملة يمكننا مناداتها ككتلة واحدة مباشرة مثل:
‏let c = (fun x y = x + y) 3 3
والتي تعطينا ناتج جمع x و y أي 6.
2- تمرير دالة كمعطى argument
الدالة أيضا يمكن لها أن تستقبل دالة كمعطى argument فمثلا؛ الدالة التالية تستقبل ثلاث معطيات، الأول هو دالة، والثاني والثالث قيمتان سنفترض أنهما من نوع int (حسب مناداتها لاحقا)
‏let ApplyFunc f x y = f x y
حيث تقوم الدالة بتطبيق الدالة f التي استقبلتها على x و y أي : f(x,y)
ويمكن مناداتها كالتالي:
‏let d = ApplyFunc add 5 5
حيث مرّرنا لها الدالة add التي سبق تعريفها، فتقوم بتطبيق الدالة add على الرقمين 5 و 5 لتعطي الناتج 10. يمكن أيضا أن نمرر لها دالة أخرى، مثل multiply مع الرقمين 6 و 6 فتعطي لنا الناتج 36 :
‏let e = ApplyFunc multiply 6 6
يمكن أيضا تمرير هيكل دالة بالكامل بدلا من إسمها فقط مثل:
‏let f = ApplyFunc (fun x y = x * y + 1) 7 7
فتقوم بتطبيق الدالة التي استقبلتها على الرقمين 7 و 7، أي 7 × 7 ثم إضافة 1 ، لتعطي الناتج 50.
3- إرجاع دالة كقيمة
الدالة يمكن لها أن ترجع دالة جديدة كقيمة . فمثلا الدالة التالية تقوم باختبار المعطى x فإن كان يساوي a ؛ تردّ دالة تستقبل رقمين وترجع حاصل اضافتهما، غير ذلك تردّ دالّة غيرها تستقبل رقمين وترجع حاصل ضربهما:
‏let returnFunc x = if x == ‘a’ then
‏ fun x y = x + y
‏ else
‏ fun x y = x * y
ويمكن استدعاؤها كالتالي:
‏let myFun = returnFunc a
‏let g = myFun 8 6
الناتج سيكون 14
الخلاصة
تكون الدالة مواطن درجة أولى في اللغة البرمجية عندما يكون متاحا في اللغة:
* تخصيص الدالة لمعرّف أو متغيّر
* أن تستقبل الدالة دالة أخرى كمُعطى argument.
* أن تقوم الدالّة بارجاع دالة كناتج لها.
وتكون الدالة عالية المستوى higher-order function في حالة إمكانية القيام بالنقطتين الأخيرتين.
كل الأمثلة الوارد أعلاه موجودة في برنامج F # قابل للتشغيل. كما توجد نسخ أخرى للبرنامج قابلة للتنفيذ والتشغيل بلغات Go و Rust و Python
روابط ملفات البرنامج في GitHub

الدالة function كمواطن درجة أولى العمليات التي تتم على الدالة في اللغات البرمجية التي تدعم المفايم الدالية

في اليابان كتب البرمجة شكل ثاني.

الدالة function كمواطن درجة أولى

ما معنى أن تكون الدالة مواطن درجة أولى وذات مستوى أعلى في لغات البرمجة؟

مقالتي على منصة GitHub حول مكانة الدالة واستخداماتها

الدالة function كمواطن درجة أولى العمليات التي تتم على الدالة في اللغات البرمجية التي تدعم المفايم الدالية

حقيقة: زمان .. بعد كل جلسة برمجة بلغة lisp أتعوّذ من الشّيطان وأتأكد إني لا زلت على التوحيد لما في lisp من سحر وخيالات كفرية.

صدّقوني.. هذه المهارة تحتاج لخبرة طويلة قبل الحصول عليها:

"إحدى أفضل مهارات البرمجة التي يمكنك اكتسابها هي معرفة متى تبتعد لبعض الوقت"

كنت أعلم أن لغة Rust تدعم بقوة مفاهيم البرمجة الدالية وأن الدالة فيها مواطن درجة أولى، بل أن صنّاع اللغة - - في بداياتها استخدموا لغة OCaml لبرمجة وتنفيذ اللغة قبل أن تصبح لغة Rust قادرة على تنفيذ نفسها بنفسها. لكن الذي فاجئني وأنا أقرأ عن آخر مستجداتها الشبه الكبير في صيغها مع لغات ML ، المثال التالي يوضح دالة function بها مطابقة أنماط Pattern matching، ولاحظوا الشبه الكبير في صيغتها
بين لغة Rust ولغة

تدوينة قديمة منذ ما يقرب من 24 سنة عن لغة التي ظهرت حديثا وقتها.

زمان وقبل ظهور الويندوز ودعمها للأحرف العربية أي قبل 1993 كانت أنظمة التشغيل لا تدعم إلا الأحرف اللاتينية.

كنا نستخدم برامج خاصة بالتعريب تعلق بذاكرة الحاسب عند تشغيلها وتتيح إدخال وعرض الأحرف العربية في بعض البرامج المستخدمة مثل تعريب Aptec و ADos ثم برنامج التعريب "نافذة" الذي كان أكثرهم فائدة وانتشارا. إلى جانب ظهور برامج تعريب أخرى بصورة محدودة مثل صخر وأمير.
كما ظهرت برامج متخصصة تدعم العربية أشهرها محرر النصوص Arab Word وأخوه Arab Calc محرر الجداول الالكترونية، والبرامج المكتبية من شركة صخر.

تعريب "نافذة" كان الأكثر انتشارا كما ذكرت وأتاح لنا استخدام مجموعة خيارات أكبر من البرامج العالمية بالأحرف العربية لأول مرة، فصرنا مثلا نستخدم برامج مثل Word Star لتحرير النصوص و 123 للجداول الالكترونية و MS Word ، كما أن تعريب "نافذة" كان أكثر ملائمة للمبرمجين عند تطوير برامجهم الداعمة للعربية.

إلا أن كثرة أنظمة التعريب خلقت مشكلة بسبب اختلاف كل نظام في طريقة ترميزه للأحرف؛ فكل نظام تعريب يقوم بتخزين نفس النص برموز أو ترقيم يختلف عن المستخدم في نظام التعريب الآخر. ولكي تقرأ نصا مخزنا

يجب أن تعرف مسبقا نظام التعريب المستخدم في كتابته وتخزينه.
في محاولة من الجامعة العربية لحل المشكلة قامت بطرح مواصفة موحدة لترميز المحارف العربية، لكن كالعادة لم يلتفت إليها أحد حتى أتت شركة مايكروسفت ودعمت الأحرف العربية في نظام ويندوز، ومع انتقال الكل لهذا النظام استطاع مستخدمي العربية لأول مرة أن يكونوا على قلب حرف واحد. تلى ذلك قيام منظمة أيزو للمواصفات باعتماد مواصفة الترميز الموحد Unicode والتي شملت أحرف كتابات كل لغات العالم وتتوحد تحتها كل أنظمة المعلوماتية.

انتقل الناس ومعهم المؤسسات إلى ويندوز وخلّفوا وراءهم كما كبيرا من ملفات البيانات المرمّزة بنظم تعريب مختلفة، والتي يصعب قراءتها مباشرة في ويندوز. كان هذا يوحي بوجود مشكلة في كيفية تحويل هذه البيانات إلى صيغة التعريب الجديدة، لكن لحسن الحظ معظم المؤسسات والناس لم تكن مهتمة بهذا الأمر لأنه على ما يبدو ليست لبياناتها ووثائقها أية أهمية.

في هذا السياق قمت قديما باعداد بعض البرامج التي تساعد على تحويل التصوص في الملفات وفي قواعد البيانات من أنظمة تعريب مختلفة إلى تظام تعريب ويندوز، كما قدمت هذه الخدمة للعديد من المؤسسات، كما قمت باعداد برنامج خاص يقوم بتحويل ملفات بصيغ مختلفة مثل Arab Word لتحرير النصوص وصيغة DBF لقواعد البيانات إلى نظام تعريب ويندوز أسميته وقتها "نظام تحويل" وجعلته متاحا.

بعدها قمت بإعداد برنامج أخف لاستعراض ورؤية محتويات الملفات ذات النصوص المرمزة بأنظمة تعريب مختلفة، كما يقوم بتحويلها إلى ترميز ويندوز المعمول به حاليا.

يمكن تنزيل برنامج Arabic Code Page Converter من الرابط التالي:
http://www.eazypo.ca/tools.html

البرمجة كشغف

كجزء من عملي في الترجمة؛ خاصة ترجمة نصوص البرمجيات والمواقع ، كنت أستخدم أدوات برمجية مختلفة متخصصة بتحرير وإدارة ملفات الترجمة خاصة تلك الموجّهة لملفات ترجمة بمعيار Gettext/Po، وه, معيار منتشر بي صنّاع البرمجيات والمواقع. حقيقة توجد محررات وأدوات كثيرة جيدة ؛ لكن كل واحد منها تفتقر إلى ميزة تحتوي عليها الأخرى ، فوجدت نفسي أنتقل من أداة إلى أخرى لتحرير أو إدارة نفس الملف، ومع هذا ؛ أجد بعض المهام يصعب مناولتها لقصور هذه المحررات.

كنت بحاجة إلى محرّر يضم جميع المزايا التي أريدها في واجهة واحدة ، محرّر يمكنني الاعتماد عليه ويجعل عملي أكثر كفاءة وسهولة. لذلك قررت تطوير محرّر الترجمة الخاص بي، ووضعت فيه كل الوظائف والخصائص التي تمنيّتها، فكان برنامج Eazy Po.
ولأني أقوم كثيرا بأعمال ترجمة النصوص من مقالات وغيرها؛ رأيت أن أضيف قسما لهذا الأمر ، يقوم باستقراء النصّ المطلوب ترجمته من ملفات "وورد" أو ملفات نصية، ثم تقسيمه إلى فقرات ، ومحاداة كل فقرة مع ترجمتها، مع دعم للذاكرة الترجمية المبنية في البرنامج والتي تقوم باقتراح الترجمات حسب ما هو مخزّن لديها.

برنامج EazyPo يخدم ثلاث فئات لهم علاقة بالترجمة:
• المطوّرون والمبرمجون أصحاب المواقع والبرمجيات، ليقوموا بعمليات استخلاص النصوص والفقرات من أكواد برامجهم ومواقعهم وصفّها في ملفات بصيغة معيارية خاصة، تمهيدا لترجمتها من قبل المترجمين.
• المترجمون، الذين يقومون بترجمة هذه الملفات الترجمية.
• مسؤولو مشاريع الترجمة لإدارة الترجمات المختلفة وتتبع موقف التنفيذ لكل ترجمة ونسب الانجاز فيها.

البرنامج الآن يأتي بأربع لغات: قمت باعداد العربية والإنكليزية ثم قام مستخدم له من اسبانبا بترجمته للاسبانية ومستخدم آخر من تركيا أسهم بترجمته للتركية فالشكر لهما.

لقد استمتعت كثيرا بتطوير هذا البرنامج، واستمتعت باستخدامه أيضا، ولعلّها من أحلى المتع أن يلتقيا الاثنان في نفس الوقت : متعة البناء ومتعة الاستخدام، اللهفة للحصول على خاصية معينة، ثم الحماس لتطوير وتحقيق هذه الخاصية، ثم الاثارة عند استخدام ما حلمت به وحققته، وتتوالى متعة الحلم والتمني مع متعة البناء والانجاز ثم الاستمتاع بما حلمت به وانجزته.

الصورة لي في تورونتو – كندا أمام مدرسة أولادي، وهي في نفس العام الذي أطلقت فيه البرنامج.
#برمجة

برنامجي Eazy Po تم الاشارة اليه في أحد الكتب التقنية.
رابط البرنامج في أول تعليق.

https://books.google.com.ly/books?id=mnc5DwAAQBAJ&pg=PA449&lpg=PA449&dq=eazypo&source=bl&ots=k-YfG6lNuO&sig=I6B99_Z26dNHdSaljse9faXnrJA&hl=en&sa=X&ved=0ahUKEwi4187J3IvZAhVIhqQKHfJHA844ChDoAQg6MAY

برنامج TMX Viewer
لعرض ملفات الذاكرة الترجمية بصيغة TMX

ولكن قبل ذلك ماهي ملفات TMX ؟
يستعين المترجمون في عملهم بأدوات برمجية تسهّل عليهم إدارة مشاريعهم للترجمة وتزيد من انتاجيتهم، وتظبط اتساق وانسجام ما يتم ترجمته . هذه الأدوات تقع تحت فئة البرامج التي تسمى الترجمة بمساعدة الكومبيوتر أو بالانكليزية Computer Aided Translation وتختصر بكلمة CAT .

ولأغراض الترجمة توجد صيغ معيارية كثيرة يتداولها المنتجون للنصوص الخاضعة للترجمة والمترجمون والبرامج الخاصة بالترجمة. منها صيغ لحفظ النصوص وترجماتها ، أو صيغ لحفظ قوائم المصطلحات وترجماتها، من هذه الصيغ صيغة TMX وتشير إلى تبادل الذاكرة الترجمية Translation Memory Exchange و هي صيغة قياسية لحفظ قوائم فقرات نصية بلغة الأصل وما يقابلها بلغات أخرى. وتستخدم لتبادل الذاكرة الترجمية بين البرامج المختلفة. هذه الفقرات يكون قد تم استخلاصها من مشاريع ترجمة مختلفة وتجميعها وفق تخصصاتها.
ا
لكثير من الجهات التي تتعامل أو تنتج عددا ضخما من النصوص وترجماتها مثل المنظمات الدولية ووكالات الأنباء، تقوم بإتاحة هذه النصوص وترجماتها للعموم حتى تعمّ الاستفادة منها. كما الجهات التي تنتج وثائق متعددة وبلغات مختلفة فشركات الأدوية مثلا؛ تحرص على أن تكون لديها قوائم للذاكرة الترجمية مستخلصة من ترجمات سابقة لمواصفات ونشرات الأدوية وتقوم بتحديثها وتوزيعها على القائمين بالترجمة للغات مختلفة للتقيّد بها، حتى تضمن اتساق الترجمة ضمن اللغة الواحدة، وأن تكون هذه الترجمات مراعية لثقافة أهل اللغة أو البلد المترجم لها.

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

برنامج TMX Viewer الذي قمت باعداده يساعد المهتمين وأهل الاختصاص على استعراض هذه الملفات وعرضها فقرات النصوص الأصلية وترجماتها بطريقة ميسّرة.
البرنامج صغير الحجم خفيف على الذاكرة، سريع التنفيذ، وقد قمت بجهود مضاعفة من أجل التأكيد على الخصائص التالية:
- سرعة تشغيل البرنامج و سرعة فتح للملفات.
- القدرة على عرض الترجمات بلغات مختلفة في صف واحد
- القدرة على فتح واستعراض الملفات ذات الحجم الضخم (أكثر من 100 ميغا)
- التأكيد على سلامة عرض أحرف كل لغة والتخلص من أي تشويش.
- سهولة تكييف طرق عرض قوائم الترجمة
- امكانية اختيار ونسخ بعض أو كل فقرات الترجمة بالملف.

يمكن تحميل البرنامج من الرابط التالي:
http://www.eazypo.ca/tools.html

https://www.linkedin.com/pulse/a-romanizer-arabic-script-romanization-khaled-shagrouni

A-Romanizer, for Arabic script Romanization Transliteration is the process of converting text from one script to another while preserving the original meaning and pronunciation. Arabic Romanization is the process of transliterating Arabic scripts to its equivalent in Latin letters.

A-Romanizer, for Arabic script Romanization

Transliteration is the process of converting text from one script to another while preserving the original meaning and pronunciation. Arabic Romanization is the process of transliterating Arabic scripts to its equivalent in Latin letters.

A-Romanizer is a web based application that provides the service of Romanizing Arabic scripts and convert it to equivalent in Latin letters. A-Romanizer supports three different common used Romanization standards:
• ALA-LC standard from (American Library Association and the Library of Congress)
•ISO 233-2:1993 standard from (International Organization for Standardization)
•United Nations Group of Experts on Geographical Names

One of the main challenges in automation of Arabic script Romanization is the absence of diacritics in most of texts. Diacritics are used in Arabic script to indicate vowels and other phonetic features, and their absence can make it difficult to determine the correct pronunciation of a word. Therefore, making the application to determine the correct phonetics of a word in the absence of diacritics is essential for Arabic script Romanization.

A-Romanizer, unlike other methods, does not rely on machine learning or pre-prepared databases to find the correct phonetics when diacritics are absent. Instead, it utilizes patterns associated with Arabic linguistics to identify the accurate pronunciation of a word. This approach ensures that the application provides almost instant responses, making it highly suitable for real-time Romanization needs in various applications and websites through API service provided by A-Romanizer.

A-Romanizer has been created using F #, a functional programming language derived from the ML family of languages renowned for its exceptional capabilities in natural language processing and text manipulation.

http://www.edari.ly/romanization/index.html


#رومنة

شجرة عائلة مادي - الشقارنة
تم اعداد المشجرة بواسطة برنامج نظام أنساب.

www.ansab.ca

Khaled Shagrouni