סיפורו של פרויקט אחד קטן בן שתים עשרה שנים (על BIRMA.NET בפעם הראשונה ולמען האמת ממקור ראשון)

הלידה של הפרויקט הזה יכולה להיחשב כרעיון קטן שעלה לי אי שם בסוף 2007, שנועד למצוא את צורתו הסופית רק 12 שנים מאוחר יותר (בנקודת זמן זו - כמובן, למרות שהיישום הנוכחי, לפי למחבר, משביע רצון מאוד).

הכל התחיל כאשר בתהליך מילוי תפקידי הרשמי דאז בספרייה, הפניתי את תשומת הלב לכך שתהליך הזנת הנתונים מהטקסט הסרוק של תוכן העניינים של פרסומי ספרים (ומוזיקה) למאגר הקיים, ככל הנראה, ניתן לפשט באופן משמעותי ולהפוך אותו לאוטומטי, תוך ניצול המאפיין של סדר וחזרה על כל הנתונים הנדרשים לקלט, כגון שם מחבר המאמר (אם אנחנו מדברים על אוסף מאמרים), הכותרת של המאמר (או כותרת המשנה המשתקפת בתוכן העניינים) ומספר העמוד של פריט תוכן העניינים הנוכחי. בהתחלה הייתי כמעט משוכנע שאפשר למצוא בקלות מערכת מתאימה לביצוע משימה זו באינטרנט. כשנגרמה איזו הפתעה מהעובדה שלא הצלחתי למצוא פרויקט כזה, החלטתי לנסות ליישם אותו בעצמי.

לאחר זמן קצר למדי, אב הטיפוס הראשון התחיל לעבוד, שמיד התחלתי להשתמש בו בפעילות היומיומית שלי, בו זמנית ניפוי באגים בכל הדוגמאות שהגיעו לידי. למרבה המזל, במקום העבודה הרגיל שלי, שבו בשום אופן לא הייתי מתכנת, אז עדיין יצאתי עם "זמן השבתה" גלוי בעבודתי, שבמהלכן בדקתי באינטנסיביות את יצירת המוחות שלי - דבר כמעט בלתי מתקבל על הדעת במציאות הנוכחית, מה שמרמז דוחות יומיים על עבודה שנעשתה במהלך היום. תהליך ליטוש התוכנית ארך בסך הכל לא פחות משנה, אך גם לאחר מכן בקושי ניתן היה לכנות את התוצאה מוצלחת לחלוטין - הונחו בתחילה יותר מדי תפיסות שונות שלא היו לגמרי ברורות ליישום: אלמנטים אופציונליים שיכולים לדלג עליו; צפייה קדימה באלמנטים (למטרת החלפת אלמנטים קודמים בתוצאות החיפוש); אפילו הניסיון שלנו ליישם משהו כמו ביטויים רגולריים (שיש לו תחביר ייחודי). אני חייב לומר שלפני זה ויתרתי במידת מה על התכנות (במשך כ-8 שנים, אם לא יותר), כך שההזדמנות החדשה ליישם את כישוריי למשימה מעניינת והכרחית תפסה את תשומת ליבי לחלוטין. זה לא מפתיע שקוד המקור שהתקבל - בהיעדר גישות ברורות לעיצוב שלו מצידי - הפך די מהר לתערובת בלתי נתפסת של חלקים שונים בשפת C עם כמה אלמנטים של C++ והיבטים של תכנות חזותי (בתחילה זה הוחלט להשתמש במערכת עיצוב כמו Borland C++ Builder - "כמעט דלפי, אבל ב-C"). עם זאת, כל זה בסופו של דבר נשא פרי באוטומציה של הפעילות היומיומית של הספרייה שלנו.

במקביל החלטתי, ליתר בטחון, לעבור קורסים להכשרת מפתחי תוכנה מקצועיים. אני לא יודע אם באמת אפשר ללמוד שם "להיות מתכנת" מאפס, אבל בהתחשב במיומנויות שכבר היו לי אז, הצלחתי לשלוט קצת בטכנולוגיות שהיו יותר רלוונטיות עד אז, כגון כמו C#, Visual Studio לפיתוח תחת NET, וכן כמה טכנולוגיות הקשורות ל-Java, HTML ו-SQL. ההכשרה כולה ארכה בסך הכל שנתיים, ושימשה נקודת מוצא לפרויקט נוסף שלי, שנמשך בסופו של דבר על פני מספר שנים – אבל זה נושא לפרסום נפרד. כאן רק ראוי לציין שעשיתי ניסיון להתאים את ההתפתחויות שכבר היו לי בפרויקט המתואר ליצירת יישום חלונות מלא ב-C# ו-WinForms המטמיע את הפונקציונליות הנדרשת, ולהשתמש בה כבסיס ל- פרויקט הדיפלומה הקרוב.
עם הזמן, הרעיון הזה התחיל להיראות לי ראוי להשמיע בכנסים שנתיים כאלה בהשתתפות נציגי ספריות שונות כמו "LIBKOM" ו-"CRIMEA". הרעיון, כן, אבל לא היישום שלי באותו זמן. אחר כך גם קיוויתי שמישהו ישכתב את זה באמצעות גישות מוכשרות יותר. כך או אחרת, עד שנת 2013 החלטתי לכתוב דו"ח על עבודתי המקדימה ולשלוח אותו לוועדה המארגנת של הכנס עם בקשה למענק להשתתפות בכנס. להפתעתי משהו, הבקשה שלי אושרה, והתחלתי לבצע כמה שיפורים בפרויקט כדי להכין אותו להצגה בכנס.

באותו זמן, הפרויקט כבר קיבל שם חדש BIRMA, רכש יכולות נוספות (לא כל כך מיושמות במלואן, אלא בהנחה) שונות - ניתן למצוא את כל הפרטים בדוח שלי.

למען האמת, היה קשה לקרוא ל-BIRMA 2013 משהו שלם; למען האמת, זו הייתה מלאכה חריפה מאוד שנעשתה בחיפזון. מבחינת קוד, למעשה לא היו חידושים מיוחדים בכלל, למעט ניסיון די חסר אונים ליצור איזשהו תחביר מאוחד עבור המנתח, במראה שמזכיר את שפת הפורמט IRBIS 64 (ולמעשה, גם את מערכת ISIS - עם סוגריים כמבנים מחזוריים; למה בזמנו חשבתי שזה נראה די מגניב). המנתח מעד ללא תקנה במעגלי הסוגריים הללו מהסוג המתאים (מאחר שגם סוגריים מילאו תפקיד נוסף, כלומר, הם סימנו מבנים אופציונליים במהלך הניתוח שניתן לדלג עליהם). אני שוב מפנה את כל מי שרוצה להכיר את התחביר שהיה אז קשה לדמיין, הלא מוצדק, של BIRMA ביתר פירוט לדיווח שלי מאותה תקופה.

באופן כללי, מלבד ההתמודדות עם הנתח שלי, אין לי יותר מה לומר לגבי הקוד של גרסה זו - למעט ההמרה ההפוכה של המקורות הקיימים ל-C++ תוך שמירה על כמה תכונות אופייניות של קוד NET (למען האמת, זה קשה להבין, מה בדיוק הניע אותי להזיז הכל אחורה - כנראה איזה פחד מטופש לשמור את קודי המקור שלי בסוד, כאילו זה משהו שווה ערך למתכון הסודי של קוקה קולה).

אולי ההחלטה המטופשת הזו טמונה גם הסיבה לקשיים בשיוך ספריית ה-DLL שנוצרה עם הממשק הקיים של תחנת עבודה תוצרת בית להזנת נתונים לקטלוג אלקטרוני (כן, לא הזכרתי עוד עובדה חשובה: מעתה והלאה, כל הקוד של "מנוע" BIRMA היה כצפוי, הוא מופרד מחלק הממשק וארוז ב-DLL המתאים). מדוע היה צורך לכתוב תחנת עבודה נפרדת למטרות אלו, שבכל מקרה, במראה ובשיטת האינטראקציה שלה עם המשתמש, העתקה ללא בושה את אותה תחנת עבודה "קטלוגיזר" של מערכת IRBIS 64 - זו שאלה נפרדת. בקיצור: זה נתן את המוצקות הדרושה לפיתוחים שלי אז לפרויקט הגמר שלי (אחרת מנוע הניתוח הבלתי ניתן לעיכול לבדו איכשהו לא הספיק). בנוסף, נתקלתי אז בכמה קשיים ביישום הממשק של תחנת העבודה של Cataloger עם המודולים שלי, המיושמים גם ב-C++ וגם ב-C#, ובגישה ישירה למנוע שלי.

באופן כללי, באופן מוזר, זה היה אב הטיפוס המגושם למדי של BIRMA.NET העתידי שהיה מיועד להפוך ל"סוס העבודה" שלי בארבע השנים הבאות. אי אפשר לומר שבמשך הזמן הזה לפחות לא ניסיתי למצוא דרכים ליישום חדש, שלם יותר, של רעיון ותיק. בין שאר החידושים, כבר היו צריכים להיות רצפים מחזוריים מקוננים שיכלו לכלול אלמנטים אופציונליים - כך עמדתי להחיות את הרעיון של תבניות אוניברסליות לתיאורים ביבליוגרפיים של פרסומים ודברים מעניינים אחרים. אולם בפעילותי המעשית באותה תקופה, כל זה היה מבוקש מעט, והיישום שהיה לי באותה תקופה הספיק למדי לכניסה לתוכן עניינים. בנוסף, וקטור הפיתוח של הספרייה שלנו החל לסטות יותר ויותר לקראת דיגיטציה של ארכיוני מוזיאונים, דיווחים ופעילויות אחרות שמעט עניינו אותי, מה שבסופו של דבר אילץ אותי לעזוב אותה סוף סוף, ופינה את מקומו למי שירצה. להיות מרוצה יותר מכל זה.

באופן פרדוקסלי, היה זה לאחר האירועים הדרמטיים הללו שפרויקט BIRMA, שבאותה תקופה כבר היו לו את כל המאפיינים האופייניים לפרויקט בנייה טיפוסי ארוך טווח, נראה כאילו התחיל לקבל את חייו החדשים המיוחל! היה לי יותר זמן פנוי למחשבות סרק, שוב התחלתי לסרוק את ה-World Wide Web בחיפוש אחר משהו דומה (למרבה המזל, עכשיו כבר יכולתי לנחש לחפש את כל זה לא סתם, אלא ב-GitHub), ואיפשהו ב-At. בתחילת השנה הזו, סוף סוף נתקלתי במוצר מקביל של חברת Salesforce הידועה בשם הלא משמעותי Gorp. כשלעצמו, הוא יכול לעשות כמעט כל מה שהייתי צריך ממנוע מנתח כזה - כלומר, לבודד באופן מושכל קטעים בודדים מטקסט שרירותי אך מובנה בבירור, תוך ממשק ידידותי למדי למשתמש הקצה, כולל מהויות מובנות כגון דפוס, תבנית והתרחשות, ובמקביל שימוש בתחביר המוכר של ביטויים רגולריים, שהופך קריא לאין ערוך עקב החלוקה לקבוצות סמנטיות ייעודיות לניתוח.

באופן כללי, החלטתי שזה האחד Gorp (אני תוהה מה פירוש השם הזה? אולי סוג של "מנתח רגיל מכוון כללי"?) - בדיוק מה שחיפשתי כבר הרבה זמן. נכון, ליישום המיידי שלו לצרכים שלי הייתה בעיה כזו שהמנוע הזה דרש הקפדה יתרה על הרצף המבני של טקסט המקור. עבור כמה דוחות כגון קובצי יומן (כלומר, הם הוצבו על ידי המפתחים כדוגמאות ברורות לשימוש בפרויקט), זה די מתאים, אבל עבור אותם טקסטים של תוכן עניינים סרוק, זה לא סביר. אחרי הכל, אותו עמוד עם תוכן עניינים יכול להתחיל במילים "תוכן עניינים", "תוכן" ועוד כמה תיאורים ראשוניים שאין לנו צורך למקם בתוצאות הניתוח המיועד (ולחתוך אותם ידנית כל פעם זה גם לא נוח). בנוסף, בין אלמנטים חוזרים בודדים, כגון שם המחבר, הכותרת ומספר העמוד, הדף עשוי להכיל כמות מסוימת של זבל (לדוגמה, ציורים וסתם תווים אקראיים), שגם זה יהיה נחמד להיות מסוגל לחתוך. עם זאת, ההיבט האחרון עדיין לא היה כל כך משמעותי, אבל בגלל הראשון, היישום הקיים לא יכול היה להתחיל לחפש את המבנים הדרושים בטקסט ממקום מסוים, אלא פשוט עיבד אותו מההתחלה, לא מצא את ציינו שם דפוסים ו... סיים את עבודתי. ברור שהיה צורך בשינוי מסוים כדי לפחות לאפשר קצת רווח בין המבנים החוזרים, וזה החזיר אותי לעבודה.

בעיה נוספת הייתה שהפרויקט עצמו הוטמע בג'אווה, ואם תכננתי בעתיד ליישם אמצעי כלשהו להתממשקות הטכנולוגיה הזו עם יישומים מוכרים להזנת נתונים לבסיסי נתונים קיימים (כגון "הקטלוג" של אירביס), אז לפחות עשה זאת ב-C# ו-.NET. זה לא ש-Java עצמה היא שפה גרועה - פעם אפילו השתמשתי בה כדי ליישם יישום חלון מעניין שהטמיע את הפונקציונליות של מחשבון ביתי שניתן לתכנות (כחלק מפרויקט קורס). ומבחינת תחביר זה מאוד דומה לאותו C-sharp. ובכן, זה רק יתרון: כך יהיה לי קל יותר לסיים פרויקט קיים. עם זאת, לא רציתי לצלול שוב לעולם יוצא דופן זה של טכנולוגיות Java (או ליתר דיוק, שולחן העבודה) של Java - אחרי הכל, השפה עצמה לא "נתפרה" לשימוש כזה, ובכלל לא השתוקקתי לחזור על הניסיון הקודם. אולי זה בדיוק בגלל ש-C# בשילוב עם WinForms הרבה יותר קרוב לדלפי, שאיתה רבים מאיתנו התחילו פעם. למרבה המזל, הפתרון הדרוש נמצא די מהר – בדמות הפרויקט IKVM.NET, מה שמקל על תרגום תוכניות Java קיימות לקוד NET מנוהל. נכון, הפרויקט עצמו כבר ננטש על ידי המחברים עד אז, אבל היישום האחרון שלו אפשר לי לבצע בהצלחה את הפעולות הדרושות עבור טקסטי המקור Gorp.

אז ביצעתי את כל השינויים הדרושים והרכבתי את הכל ל-DLL מהסוג המתאים, שניתן היה "לאסוף" בקלות על ידי כל פרויקט עבור .NET Framework שנוצר ב-Visual Studio. בינתיים יצרתי שכבה נוספת להצגה נוחה של התוצאות שהוחזרו Gorp, בצורה של מבני נתונים מתאימים שיהיה נוח לעיבוד בתצוגת טבלה (לוקח כבסיס הן שורות והן עמודות; הן מפתחות מילון והן אינדקסים מספריים). ובכן, כלי העזר הדרושים עצמם לעיבוד והצגת התוצאות נכתבו די מהר.

כמו כן, תהליך התאמת התבניות למנוע החדש על מנת ללמדו לנתח דוגמאות קיימות של טקסטים סרוקים של תוכן העניינים לא גרם לסיבוכים מיוחדים. למעשה, אפילו לא הייתי צריך להתייחס לתבניות הקודמות שלי בכלל: פשוט יצרתי את כל התבניות הדרושות מאפס. יתרה מכך, אם התבניות שתוכננו לעבוד עם הגרסה הקודמת של המערכת קבעו מסגרת צרה למדי לטקסטים שניתן לנתח נכון בעזרתם, המנוע החדש כבר איפשר לפתח תבניות אוניברסליות למדי המתאימות למספר סוגי סימון ב- פַּעַם. אפילו ניסיתי לכתוב איזושהי תבנית מקיפה לכל טקסט שרירותי של תוכן עניינים, אם כי, כמובן, אפילו עם כל האפשרויות החדשות שנפתחות לי, כולל, במיוחד, היכולת המוגבלת ליישם את אותם רצפים חוזרים מקוננים ( כמו, למשל, שמות משפחה וראשי תיבות של כמה מחברים ברצף), זו התבררה כאוטופיה.

אולי בעתיד ניתן יהיה ליישם קונספט מסוים של מטא-תבניות, שיוכלו לבדוק את טקסט המקור לעמידה בכמה מהתבניות הזמינות בו-זמנית, ולאחר מכן, בהתאם לתוצאות המתקבלות, לבחור את המתאים ביותר, תוך שימוש בסוג של אלגוריתם אינטליגנטי. אבל עכשיו דאגתי יותר לשאלה אחרת. מנתח כמו Gorp, למרות כל הרבגוניות שלו והשינויים שעשיתי, הוא עדיין לא היה מסוגל מטבעו לעשות דבר אחד שנראה פשוט, שהמנתח שלי שנכתב בעצמי היה מסוגל לעשות כבר מהגרסה הראשונה. כלומר: הייתה לו היכולת למצוא ולחלץ מטקסט המקור את כל הפרגמנטים התואמים את המסכה שצוינה בתוך התבנית המשמשת במקום הנכון, תוך שהוא לא מתעניין כלל במה מכיל הטקסט הנתון ברווחים שבין הפרגמנטים הללו. עד כה, שיפרתי רק מעט את המנוע החדש, ומאפשר לו לחפש את כל החזרות החדשות האפשריות של רצף נתון של מסכות כאלה מהמיקום הנוכחי, מה שמותיר את האפשרות להימצאות בטקסט של קבוצות של תווים שרירותיים שהיו לחלוטין לא נלקח בחשבון בניתוח, מוקף בין המבנים החוזרים שזוהו. עם זאת, זה לא איפשר להגדיר את המסכה הבאה ללא קשר לתוצאות החיפוש אחר הפרגמנט הקודם באמצעות המסכה המקבילה: ההקפדה על מבנה הטקסט המתואר עדיין לא הותירה מקום להכללות שרירותיות של תווים לא סדירים.

ואם לדוגמאות של תוכן העניינים שנתקלתי בהם הבעיה הזו עדיין לא נראתה כל כך רצינית, אז כשמנסים להחיל מנגנון ניתוח חדש על משימה דומה של ניתוח תוכן של אתר אינטרנט (כלומר אותו ניתוח), שלה המגבלות הן כאן הן הופיעו עם כל המובן מאליו. אחרי הכל, זה די קל להגדיר את המסכות הדרושות עבור קטעי סימון אינטרנט, שביניהם צריך למצוא את הנתונים שאנו מחפשים (שצריך לחלץ), אבל איך נוכל לאלץ את המנתח לעבור מיד לנתח הבא קטע דומה, למרות כל התגים ותכונות ה-HTML האפשריות שניתן למקם ברווחים ביניהם?

לאחר חשיבה קטנה, החלטתי להציג כמה דפוסי שירות (%all_before) и (%כל_אחרי), משרת את המטרה הברורה של להבטיח שכל מה שעשוי להיכלל בטקסט המקור ידלג לפני כל דפוס (מסכה) שאחריהם. יתר על כן, אם (%all_before) פשוט התעלם מכל ההכללות השרירותיות האלה (%כל_אחרי), להיפך, אפשרו להוסיף אותם לשבר הרצוי לאחר המעבר מהמקטע הקודם. זה נשמע די פשוט, אבל כדי ליישם את הקונספט הזה הייתי צריך לסרוק שוב את מקורות ה-gorp כדי לבצע את השינויים הדרושים כדי לא לשבור את ההיגיון שכבר מיושם. בסופו של דבר, הצלחנו לעשות זאת (למרות שאפילו היישום הראשון מאוד, אם כי בעייתי, של הנתח שלי נכתב, ואפילו מהר יותר - תוך שבועיים). מעתה, המערכת לבשה צורה אוניברסלית באמת - לא פחות מ-12 שנים לאחר הניסיונות הראשונים לגרום לה לתפקד.

כמובן, זה לא סוף החלומות שלנו. אתה יכול גם לשכתב לחלוטין את מנתח תבניות gorp ב-C#, באמצעות כל אחת מהספריות הזמינות להטמעת דקדוק חופשי. אני חושב שצריך לפשט משמעותית את הקוד, וזה יאפשר לנו להיפטר מהמורשת בצורה של מקורות Java קיימים. אבל עם סוג המנוע הקיים, אפשר גם בהחלט לעשות דברים מעניינים שונים, כולל ניסיון ליישם את המטא-טמפלטים שכבר הזכרתי, שלא לדבר על ניתוח נתונים שונים מאתרים שונים (עם זאת, אני לא פוסל שכלי תוכנה מיוחדים קיימים מתאימים יותר לכך - פשוט עדיין לא היה לי את הניסיון המתאים בשימוש בהם).

אגב, הקיץ כבר קיבלתי הזמנה במייל מחברה שמשתמשת בטכנולוגיות Salesforce (המפתחת של המקור Gorp), לעבור ראיון לעבודה הבאה בריגה. לצערי, כרגע אני לא מוכן לפריסות מחדש כאלה.

אם החומר הזה מעורר עניין מסוים, אז בחלק השני אנסה לתאר ביתר פירוט את הטכנולוגיה להידור וניתוח תבניות לאחר מכן באמצעות דוגמה של המימוש המשמש ב-Salesforce Gorp (התוספות שלי, למעט כמה מילות פונקציה שכבר תוארו, אינן עושות שינויים בתחביר התבנית עצמו, כך שכמעט כל התיעוד עבור המערכת המקורית Gorp מתאים גם לגרסה שלי).

מקור: www.habr.com