يمكن اعتبار ولادة هذا المشروع فكرة صغيرة زارتني في مكان ما في نهاية عام 2007 ، والتي كان من المفترض أن تجد شكلها النهائي بعد 12 عامًا فقط (في هذه المرحلة من الزمن - بالطبع ، على الرغم من أن التنفيذ الحالي ، في رأي المؤلف ، مرضٍ للغاية) .
بدأ كل شيء بحقيقة أنه أثناء عملية أداء واجباتي الرسمية في المكتبة ، لفتت الانتباه إلى أن عملية إدخال البيانات من النص الممسوح ضوئيًا لجدول محتويات منشورات الكتاب والموسيقى في قاعدة البيانات الحالية ، على ما يبدو ، يمكن تبسيطها إلى حد كبير وأتمتة ، باستخدام خاصية الانتظام وتكرار جميع البيانات المطلوبة للإدخال ، مثل اسم مؤلف المقال (إذا كنا نتحدث عن مجموعة من المقالات) ، واسم المقال (أو العنوان الفرعي الموضح في جدول المحتويات) و صفحة جدول المحتويات الحالي. في البداية ، كنت مقتنعًا تقريبًا أنه من السهل العثور على نظام مناسب لهذه المهمة على الإنترنت. عندما حدثت بعض المفاجآت بسبب عدم تمكني من العثور على مثل هذا المشروع ، قررت أن أحاول تنفيذه بمفردي.
بعد وقت قصير إلى حد ما ، بدأ أول نموذج أولي في العمل ، وبدأت على الفور استخدامه في أنشطتي اليومية ، وقم بتصحيحه في وقت واحد بكل الأمثلة التي جاءت في يدي. لحسن الحظ ، في مكان عملي المعتاد ، حيث لم أكن أبداً مبرمجًا ، كنت لا أزال قادرًا على الابتعاد عن "فترات التوقف" المرئية في العمل ، والتي عملت خلالها جاهدة لتصحيح طفلي العقلي - وهو أمر لا يمكن تصوره تقريبًا في حقائق اليوم ، مما يعني ضمناً تقارير يومية حول العمل المنجز خلال اليوم. استغرقت عملية تلميع البرنامج ما لا يقل عن عام ، لكن حتى بعد ذلك بالكاد يمكن وصف النتيجة بأنها ناجحة تمامًا - كان هناك الكثير من المفاهيم المختلفة التي لم تكن مفهومة تمامًا للتنفيذ من البداية: عناصر اختيارية يمكن تخطيها ؛ عرض أولي للعناصر (لغرض الاستبدال بنتائج بحث العناصر السابقة) ؛ حتى محاولتك الخاصة لتطبيق شيء مثل التعبيرات العادية (وجود بناء جملة مميز). يجب أن أقول أنه قبل ذلك تمكنت من رمي البرمجة قليلاً (لمدة 8 سنوات تقريبًا ، إن لم يكن أكثر من ذلك) ، لذلك لفتت انتباهي فرصة جديدة لتطبيق مهاراتي على مهمة شيقة وضرورية. ليس من المستغرب أن شفرة المصدر الناتجة - في غياب أي مقاربات واضحة لتصميمها بالنسبة لي - سرعان ما أصبحت مزجًا لا يمكن تصوره من قطع متباينة في لغة C مع بعض عناصر C ++ وجوانب البرمجة المرئية (تقرر في الأصل استخدام نظام تصميم مثل Borland C ++ Builder - "Delphi تقريبًا ، ولكن في C"). ومع ذلك ، فقد أثمر كل هذا في النهاية في أتمتة الأنشطة اليومية لمكتبتنا.
في الوقت نفسه ، قررت ، في حالة الضرورة ، أخذ دورات تدريبية لمطوري البرامج المحترفين. لا أعرف ما إذا كان من الممكن حقًا تعلم "من مبرمج" من البداية ، ولكن مع الأخذ في الاعتبار المهارات التي كانت لدي بالفعل في ذلك الوقت ، تمكنت من إتقان تقنيات أكثر تطوراً قليلاً مثل C # و Visual Studio للتطوير. NET ، وكذلك بعض التقنيات المتعلقة Java و HTML و SQL. استغرق كل التدريب ما مجموعه عامين ، وكان بمثابة نقطة انطلاق لآخر من بلدي المشاريع ، والتي امتدت في نهاية المطاف على مدى عدة سنوات - ولكن هذا هو بالفعل موضوع لمنشور منفصل. هنا سيكون من المناسب فقط ملاحظة أنني بذلت محاولة لتكييف التجربة التي كانت لدي بالفعل في المشروع الموصوف لإنشاء تطبيق نافذة متكامل في C # و WinForms يقوم بتنفيذ الوظيفة الضرورية ، ووضعها على أساس مشروع التخرج القادم.
مع مرور الوقت ، بدأت هذه الفكرة تبدو جديرة بالتعبير عنها في مثل هذه المؤتمرات السنوية بمشاركة ممثلين عن مختلف المكتبات ، مثل LIBCOM و CRIMEA. الفكرة هي نعم ، ولكن بأي حال من الأحوال إدراكي لذلك الوقت. ثم كنت آمل أيضًا ، من بين أشياء أخرى ، أن يعيد شخص ما كتابتها باستخدام طرق أكثر كفاءة. بطريقة أو بأخرى ، بحلول عام 2013 ، قررت إعداد تقرير عن عملي الأولي وإرساله إلى اللجنة المنظمة للمؤتمر مع طلب للحصول على منحة للمشاركة في المؤتمر. لدهشتي ، كان طلبي راضيًا ، وبدأت في إجراء بعض التحسينات على المشروع لإعداده للعرض في المؤتمر.
بحلول ذلك الوقت ، كان المشروع قد تلقى بالفعل اسمًا جديدًا BIRMA ، واكتسب العديد من الفرص الإضافية (التي لم تتحقق تمامًا كما كان متوقعًا) -
يمكن العثور على جميع التفاصيل في تقريري .
بصراحة ، كان 2013 BIRMA الصعب استدعاء شيء كامل. بصراحة ، لقد كان سوطًا مصنوعًا جدًا من الإختراق. بالنسبة لجزء الشفرة ، لم تكن هناك أي ابتكارات خاصة على الإطلاق ، بصرف النظر عن المحاولة التي لا حول لها ولا قوة لإنشاء نوع من بناء الجملة الموحد للمحلل ، والذي يشبه في الظاهر لغة التنسيق IRBIS 64 (وفي الواقع ، حتى ISIS ، مع أقواس في دور الهياكل الدورية ؛ لماذا ثم بدا لي أنه يبدو رائعا جدا). تعثر المحلل اللغوي بشكل يائس على هذه الدوامات من الأقواس من النوع المقابل (نظرًا لأن الأقواس لعبت نفس الدور هناك ، أي أنها حددت هياكل اختيارية يمكن تخطيها أثناء التحليل). كل من يريد التعرف بمزيد من التفاصيل على بناء جملة BIRMA الذي كان يصعب تخيله ، غير مبرر ، أشير مرة أخرى إلى تقريري في ذلك الوقت.
بشكل عام ، فيما عدا الصراع مع المحلل اللغوي الخاص بنا ، وفيما يتعلق برمز هذا الإصدار ، ليس لدي ما أقوله - باستثناء التحويل العكسي للمصادر المتاحة في C ++ مع الحفاظ على بعض الميزات النموذجية لرمز .NET (بصراحة) ، من الصعب فهمها ما الذي دفعني بالضبط إلى إعادة كل شيء إلى الوراء - على الأرجح نوع من الخوف الغامض للحفاظ على سرية أكواد المصدر الخاصة بي ، كما لو كان شيئًا يعادل وصفة كوكاكولا السرية).
ربما يحتوي هذا القرار الغبي أيضًا على سبب الصعوبات في مزامنة DLL الناتج مع واجهة محطة العمل القائمة بذاتها لإدخال البيانات في الكتالوج الإلكتروني (نعم ، لم أذكر بعد حقيقة مهمة أخرى: من الآن فصاعدًا ، كان رمز محرك BIRMA هو كما هو متوقع ، مفصولة عن الواجهة وتعبئتها في DLL المناسب). لماذا احتجت إلى كتابة محطة عمل منفصلة لهذه الأغراض ، والتي على أي حال ، في مظهرها وفي طريقة التفاعل مع المستخدم ، قامت بنسخ محطة عمل "Catalogizer" نفسها لنظام IRBIS 64 - بدون خجل - هذه مشكلة منفصلة. باختصار: لقد أعطى الاحترام الواجب لإنجازاتي في ذلك الوقت في مشروع التخرج (وإلا فإن محرك المحلل اللغوي الذي لا يمكن هضمه وحده لم يكن كافيًا). بالإضافة إلى ذلك ، واجهت بعد ذلك بعض الصعوبات عند تطبيق محطة عمل "Catalogizer" على الاقتران بوحداتي الخاصة المطبقة في C ++ و C # ، والتوجه مباشرة إلى محركي.
بشكل عام ، من الغريب أن يكون هذا النموذج الأولي المحرج لمستقبل BIRMA.NET الذي كان من المفترض أن يصبح لي "رب العمل" للأربعة أعوام القادمة. لا يمكن القول أنه خلال هذا الوقت لم أحاول حتى إيجاد طرق لتطبيق جديد أكثر اكتمالا لفكرة طويلة الأمد. من بين الابتكارات الأخرى ، كان ينبغي أن يكون هناك بالفعل تسلسل دوري متداخل ، والذي يمكن أن يشمل عناصر اختيارية أيضًا - هكذا كنت أدرك فكرة قوالب عالمية لوصف ببليوغرافي للمنشورات والعديد من الأشياء الأخرى المثيرة للاهتمام. ومع ذلك ، في ممارستي في ذلك الوقت ، كان كل هذا مطلوبًا بشكل سيئ ، وكان التنفيذ الذي أجريته في ذلك الوقت كافًا لتقديم جدول المحتويات. بالإضافة إلى ذلك ، بدأ اتجاه التطوير في مكتبتنا في الانحراف أكثر فأكثر نحو رقمنة أرشيفات المتاحف ، وإنشاء تقارير وأنشطة أخرى لم تكن تهمني كثيرًا ، مما جعلني في النهاية أتركها تمامًا ، وأفسح المجال لمن كانوا أكثر سعادة بكل هذا .
من المفارقات ، ولكن على وجه التحديد بعد هذه الأحداث الدراماتيكية ، بدا أن مشروع BIRMA ، الذي كان يمتلك في ذلك الوقت كل الميزات المميزة للبناء طويل الأجل النموذجي ، بدأ يكتسب حياته الجديدة التي طال انتظارها! كان لدي المزيد من وقت الفراغ للأفكار الخاملة ، وبدأت مرة أخرى تجوب شبكة الويب العالمية بحثًا عن شيء مشابه (جيد ، والآن يمكنني أن أخمن بالفعل أن أبحث عن كل هذا في أي مكان ، أي على جيثب) ، وفي مكان ما في في بداية هذا العام ، صادفت أخيرًا الحرفة المقابلة لمكتب Salesforce المعروف تحت الاسم غير المهم
Gorp . في حد ذاته ، يمكنها أن تفعل كل ما أحتاجه تقريبًا من محرك تحليل مثل - بمعنى ، عزل الأجزاء الفردية بذكاء عن التعسفي ، ولكن مع بنية واضحة للنص ، مع وجود واجهة سهلة الهضم إلى حد ما للمستخدم النهائي ، بما في ذلك هذا الوضوح الكيانات كنموذج ونمط وحدوث ، وفي الوقت نفسه تتضمن بناء الجملة المعتاد من التعبيرات العادية ، والتي تصبح أكثر قابلية للقراءة بشكل لا يضاهى بحكم الانقسام إلى مجموعات دلالية ذات معنى للتحليل.
بشكل عام ، قررت أن هذا
Gorp نفسه (أتساءل ماذا يعني هذا الاسم؟ ربما بعض "المحلل اللغوي العادي الموجه"؟) هو بالضبط ما كنت أبحث عنه لفترة طويلة. صحيح أن تنفيذه الفوري لاحتياجاتي الخاصة واجه مشكلة تتطلب هذا المحرك الالتزام الصارم للغاية بالتسلسل الهيكلي للنص المصدر. بالنسبة إلى بعض التقارير ، مثل ملفات السجل (أي ، تم وضعها من قبل المطورين كأمثلة مرئية لاستخدام المشروع) ، سيكون ذلك جيدًا ، لكن بالنسبة للنصوص نفسها ، فإن جدول المحتويات الممسوح ضوئيًا غير مرجح. بعد كل شيء ، يمكن أن تبدأ الصفحة نفسها التي تحتوي على جدول المحتويات بالكلمات "جدول المحتويات" و "المحتويات" وبعض الأوصاف الأولية الأخرى التي لا نحتاج إليها على الإطلاق لوضع نتائج التحليل المقترح (كما أنه من غير المناسب فصلها يدويًا في كل مرة). بالإضافة إلى ذلك ، بين العناصر المكررة الفردية ، مثل اسم المؤلف وعنوانه ورقم صفحته ، قد تحتوي الصفحة على قدر معين من القمامة (على سبيل المثال ، الصور والأحرف العشوائية فقط) ، والتي سيكون من الجيد أيضًا أن تكون قادرًا على قطعها. ومع ذلك ، فإن الجانب الأخير لا يزال غير مهم ، ولكن بحكم الأول ، لم يستطع التنفيذ الحالي البدء في البحث عن الهياكل اللازمة في النص من مكان معين ، ولكن بدلاً من ذلك ، قام بمعالجته من البداية ، ولم يعثر على الأنماط المحددة هناك و ... انتهى عملك من الواضح ، كانت هناك حاجة إلى مراجعة مناسبة ، والتي من شأنها أن تسمح على الأقل بترك بعض الفجوات بين الهياكل المتكررة ، وهذا جعلني أجلس مرة أخرى في العمل.
مشكلة أخرى هي أن المشروع نفسه تم تنفيذه في Java ، وإذا كنت تخطط لمواصلة تنفيذ بعض وسائل ربط هذه التكنولوجيا مع التطبيقات المعتادة لإدخال البيانات في قواعد البيانات الموجودة (مثل مفهرس Irbis) ، عندئذٍ على الأقل الأقل تفعل ذلك في C # و. NET. ليس أن Java نفسها كانت لغة سيئة - بمجرد أن قمت بتنفيذها على تطبيق نافذة غير مهتم بتنفيذ وظيفة الآلة الحاسبة القابلة للبرمجة المحلية (كجزء من مشروع الدورة التدريبية). نعم ، وفي بناء الجملة يشبه إلى حد كبير نفس C- شارب. حسنًا ، هذه مجرد ميزة إضافية: كلما كان من الأسهل بالنسبة لي وضع اللمسات الأخيرة على مشروع قائم. ومع ذلك ، لم أكن أرغب في الانغماس في هذا العالم غير المعتاد إلى حد ما من تقنيات جافا (أو بالأحرى سطح المكتب) - في النهاية ، لم يتم "شحذ" اللغة نفسها لمثل هذا الاستخدام ، ولم أكن على الإطلاق لفترة طويلة لتكرار التجربة السابقة. ربما يكون السبب هو أن C # بالتزامن مع WinForms أقرب بكثير إلى دلفي ، والتي بدأ الكثيرون منا ذات مرة. لحسن الحظ ، تم العثور على الحل المناسب بسرعة كبيرة - في شخص مشروع
IKVM.NET ، مما يجعل من السهل ترجمة برامج Java الحالية إلى رمز .NET مُدار. صحيح أن المشروع نفسه قد تم التخلي عنه بالفعل من قبل المؤلفين في ذلك الوقت ، لكن تنفيذه الأخير سمح لي بالقيام بالإجراءات اللازمة لنصوص مصدر
Gorp بنجاح.
لذلك قمت بإجراء جميع التغييرات اللازمة ووضعها كلها في DLL من النوع المناسب ، والتي يمكن لأي مشاريع لـ .NET Framework التي تم إنشاؤها في Visual Studio أن "تلتقط" بسهولة. في
غضون ذلك ، قمت بإنشاء طبقة أخرى للعرض التقديمي المريح للنتائج التي تم إرجاعها بواسطة
Gorp ، في شكل هياكل البيانات المقابلة التي ستكون ملائمة للمعالجة في تمثيل الجدول (مع الأخذ كأساس لكل من الصفوف والأعمدة ؛ مفاتيح القاموس والمؤشرات الرقمية) . حسنًا ، تمت كتابة الأدوات المساعدة اللازمة نفسها لمعالجة النتائج وعرضها بسرعة كبيرة.
أيضًا ، لم تتسبب عملية تكييف القوالب للمحرك الجديد في حدوث أي مضاعفات خاصة لتعليمه كيفية تفكيك العينات الموجودة من نصوص جدول محتويات الممسوحة ضوئيًا. في الحقيقة ، لم أضطر حتى إلى اللجوء إلى الفراغات السابقة: لقد قمت للتو بإنشاء جميع القوالب الضرورية من البداية. علاوة على ذلك ، إذا وضعت القوالب المصممة للعمل مع الإصدار السابق من النظام إطارًا ضيقًا إلى حد ما للنصوص التي يمكن تحليلها بشكل صحيح بمساعدتهم ، فقد سمح المحرك الجديد بالفعل بتطوير قوالب عالمية إلى حد ما مناسبة لعدة أنواع من الترميز في آن واحد. لقد حاولت حتى كتابة بعض القوالب الشاملة لأي نص لجدول المحتويات التعسفي ، على الرغم من أنه بالطبع ، مع كل الاحتمالات الجديدة التي تفتح أمامي ، بما في ذلك ، على وجه الخصوص ، القدرة المحدودة على تنفيذ نفس تسلسلات التكرار المتداخلة (على سبيل المثال ، الأسماء الأخيرة والأحرف الأولى العديد من المؤلفين في صف واحد) ، اتضح أن هذا هو يوتوبيا.
من الممكن أنه في المستقبل سيكون من الممكن تطبيق مفهوم معين لقوالب التعريف التي يمكنها التحقق من النص المصدر للتأكد من توافقه مع العديد من القوالب المتوفرة في آن واحد ، ثم ، وفقًا للنتائج التي تم الحصول عليها ، اختر الأنسب باستخدام خوارزمية ذكية. ولكن الآن كنت أكثر قلقا بشأن سؤال آخر. إن المحلل اللغوي مثل
Gorp ، على الرغم من تنوعه وتعديلاته التي أجريتها ، لا يزال بطبيعته غير قادر على أداء شيء بسيط يبدو أن المحلل اللغوي المكتوب بخط اليد الخاص بي كان قادرًا على القيام به من الإصدار الأول. وهي: كان لديه القدرة على العثور على النص المصدر واستخراجه من جميع الأجزاء التي تتطابق مع القناع المحدد في إطار القالب المستخدم في المكان الصحيح ، بينما لا يهتم على الإطلاق بما يحتويه النص في الفراغات بين هذه الأجزاء. حتى الآن ، قمت فقط بتحسين المحرك الجديد قليلاً ، مما سمح له بالبحث عن جميع التكرارات الجديدة الممكنة لسلسلة معينة من هذه الأقنعة من الموضع الحالي ، تاركًا إمكانية تجاهل النص تمامًا عند تحليل مجموعات الأحرف التعسفية المحصورة بين هياكل التكرار المكتشفة. ومع ذلك ، فإن هذا لم يجعل من الممكن تعيين القناع التالي بغض النظر عن نتائج البحث للجزء السابق بواسطة القناع المقابل له: لا تزال دقة البنية الموصوفة للنص لا تترك مجالًا للتضمين التعسفي للأحرف غير النظامية.
وإذا لم تكن هذه المشكلة خطيرة للغاية بالنسبة لأمثلة جدول المحتويات التي صادفتني ، فعند محاولة تطبيق آلية التحليل الجديدة على مهمة مماثلة في جوهرها لتحليل محتوى موقع الويب (أي نفس التحليل) ، توجد قيوده هنا ظهرت مع كل الأدلة الخاصة بهم. بعد كل شيء ، من السهل جدًا تعيين الأقنعة اللازمة لشظايا ترميز الويب ، والتي يجب أن تكون بينها البيانات التي نبحث عنها (والتي تحتاج إلى استخراجها) ، ولكن كيفية جعل المحلل اللغوي ينتقل فورًا إلى الجزء التالي المشابه ، على الرغم من جميع علامات HTML وسماتها المحتملة التي يمكن أن تتوافق مع الفجوات بينهما؟
بعد قليل من التفكير ، قررت تقديم اثنين من أنماط الأداة
(٪ all_before) و
(٪ all_after) ، والتي تخدم الغرض الواضح المتمثل في ضمان حذف كل شيء يمكن
تضمينه في النص المصدر قبل أي نمط تالٍ (قناع). علاوة على ذلك ، إذا تجاهل
(٪ all_before) كل هذه
الإدخالات التعسفية ، فإن
(٪ all_after) ، على العكس من ذلك ، سمح بإضافتها إلى الجزء المطلوب بعد التبديل من الجزء السابق. يبدو الأمر بسيطًا جدًا ، ولكن لتطبيق هذا المفهوم ، كان عليّ "تمشيط" مصادر gorp مرة أخرى لإجراء التعديلات اللازمة حتى لا يتم كسر المنطق المطبق بالفعل. ( - , – ). - – 12 .
, . gorp' C#, - . , , Java. , , - (, , – ).
, , Salesforce (
Gorp ), – . , .
, Salesforce
Gorp ( , , ,
Gorp ). –
Gorp.NET .