Приказната за еден мал проект долг дванаесет години (за BIRMA.NET за прв пат и искрено од прва рака)

Раѓањето на овој проект може да се смета за мала идеја што ми дојде некаде на крајот на 2007 година, која беше предодредена да ја најде својата конечна форма само 12 години подоцна (во овој момент во времето - се разбира, иако сегашната имплементација, според за авторот, е многу задоволително).

Сè започна кога, во процесот на исполнување на моите тогашни службени должности во библиотеката, свртев внимание на фактот дека процесот на внесување на податоци од скенираниот текст на табелите на книгите (и музичките) публикации во постоечката база на податоци, очигледно, може значително да се поедностави и автоматизира, искористувајќи ја карактеристиката на уредност и повторливост на сите податоци потребни за внесување, како што е името на авторот на статијата (ако зборуваме за збирка статии), насловот на написот (или поднасловот прикажан во содржината) и бројот на страницата на тековната ставка со содржина. Отпрвин, практично бев убеден дека на Интернет лесно може да се најде систем погоден за извршување на оваа задача. Кога некое изненадување предизвика тоа што не можев да најдам таков проект, решив да се обидам да го спроведам сам.

По прилично кратко време, почна да работи првиот прототип, кој веднаш почнав да го користам во секојдневните активности, истовремено дебагирајќи го на сите примери што ми дојдоа на рака. За среќа, на моето вообичаено работно место, каде што во никој случај не бев програмер, тогаш сепак се извлеков со видливото „застој“ во мојата работа, за време на кое интензивно го дебагирав мојот мозок - речиси незамислива работа во сегашната реалност, што подразбира дневни извештаи за сработеното во текот на денот. Процесот на полирање на програмата траеше вкупно не помалку од околу една година, но дури и после тоа резултатот тешко може да се нарече целосно успешен - имаше премногу различни концепти кои не беа сосема разбирливи за имплементација: изборни елементи што може да се прескокнат ; напредно гледање на елементи (со цел да се заменат претходните елементи во резултатите од пребарувањето); дури и нашиот сопствен обид да имплементираме нешто како регуларни изрази (што има единствена синтакса). Морам да кажам дека пред ова донекаде се откажав од програмирањето (околу 8 години, ако не и повеќе), па новата можност да ги применам моите вештини на интересна и неопходна задача целосно ми го привлече вниманието. Не е изненадувачки што добиениот изворен код - во отсуство на јасни пристапи кон неговиот дизајн од моја страна - многу брзо стана незамисливо мешање на различни парчиња во јазикот C со некои елементи на C++ и аспекти на визуелно програмирање (на почетокот тоа беше одлучено да се користи таков дизајн систем како Borland C++ Builder - „речиси Делфи, но во C“). Сепак, сето ова на крајот вроди со плод во автоматизирањето на секојдневните активности на нашата библиотека.

Во исто време, решив, за секој случај, да посетувам курсеви за обука на професионални развивачи на софтвер. Не знам дали навистина е можно таму да се научи „да се биде програмер“ од нула, но имајќи ги предвид вештините што веќе ги имав во тоа време, успеав донекаде да ги совладам технологиите што беа порелевантни до тоа време, како што се како C#, Visual Studio за развој под .NET, како и некои технологии поврзани со Java, HTML и SQL. Целата обука траеше вкупно две години, и послужи како почетна точка за уште еден мој проект, кој на крајот се протегаше во неколку години - но ова е тема за посебна публикација. Овде би било соодветно само да се забележи дека направив обид да ги прилагодам случувањата што веќе ги имав на опишаниот проект за да создадам полноправна апликација за прозорци во C# и WinForms што ја имплементира потребната функционалност и да ја користам како основа за претстојниот дипломски проект.
Со текот на времето, оваа идеја почна да ми изгледа достојна да се изрази на вакви годишни конференции со учество на претставници на различни библиотеки како „ЛИБКОМ“ и „КРИМЕА“. Идејата, да, но не и мојата имплементација на тоа време. Потоа, исто така, се надевав дека некој ќе го преработи користејќи покомпетентни пристапи. Вака или онака, до 2013 година решив да напишам извештај за мојата прелиминарна работа и да го испратам до Организациониот одбор на конференцијата со апликација за грант за учество на конференцијата. На мое некако изненадување, мојата апликација беше одобрена и почнав да правам некои подобрувања на проектот за да го подготвам за презентација на конференцијата.

Во тоа време, проектот веќе доби ново име BIRMA, се здоби со разни дополнителни (не толку целосно имплементирани, туку претпоставени) способности - сите детали може да се најдат во мојот извештај.

Да бидам искрен, беше тешко да се нарече BIRMA 2013 нешто комплетно; Искрено кажано, тоа беше многу хакерски занает направен набрзина. Во однос на кодот, практично немаше никакви посебни иновации, освен прилично беспомошен обид да се создаде некаква унифицирана синтакса за парсерот, по изглед кој потсетува на јазикот за форматирање IRBIS 64 (и всушност, исто така и системот ИСИС - со загради како циклични структури, зошто Во тоа време мислев дека изгледа прилично кул). Парсерот безнадежно се сопна на овие кругови на загради од соодветен тип (бидејќи заградите извршуваа и друга улога, имено, тие означуваа изборни структури за време на парсирањето што може да се прескокнат). Повторно ги упатувам сите кои сакаат подетално да се запознаат со тогаш тешко замисливата, неоправдана синтакса на БИРМА на мојот тогашен извештај.

Во принцип, освен што се борам со мојот сопствен парсер, немам што повеќе да кажам во врска со кодот на оваа верзија - освен обратна конверзија на постоечките извори во C++, притоа зачувувајќи некои типични карактеристики на .NET кодот (да бидам искрен, тоа е тешко разбирливо, што точно ме поттикна да поместам сè назад - веројатно некој глупав страв да ги чувам моите изворни кодови во тајност, како да е нешто еквивалентно на тајниот рецепт на Кока-Кола).

Можеби оваа глупава одлука лежи и причината за тешкотиите во спарувањето на добиената DLL библиотека со постојниот интерфејс на домашна работна станица за внесување податоци во електронски каталог (да, не спомнав друг важен факт: од сега па натаму, сите кодот на „моторот“ на BIRMA беше како што се очекуваше, тој е одделен од делот за интерфејс и спакуван во соодветниот DLL). Зошто беше неопходно да се напише посебна работна станица за овие цели, која сепак, по својот изглед и начинот на интеракција со корисникот, бесрамно ја копираше истата работна станица „Каталогизатор“ на системот IRBIS 64 - ова е посебно прашање. Накратко: ми ја даде потребната цврстина на моите тогашни случувања за мојот дипломски проект (инаку само несварливиот парсерски мотор некако не беше доволен). Дополнително, тогаш наидов на некои потешкотии во имплементирањето на интерфејсот на работната станица Cataloger со моите сопствени модули, имплементирани и во C++ и во C# и директно да пристапам до мојот мотор.

Во принцип, доволно чудно, токму овој прилично несмасен прототип на идниот BIRMA.NET беше предодреден да стане мојот „работник“ во следните четири години. Не може да се каже дека за ова време барем не се обидов да најдам начини за нова, поцелосна имплементација на една долгогодишна идеја. Меѓу другите иновации, веќе требаше да има вгнездени циклични секвенци кои можеа да вклучуваат опционални елементи - вака сакав да ја оживеам идејата за универзални шаблони за библиографски описи на публикации и разни други интересни работи. Меѓутоа, во моите практични активности во тоа време, сето тоа беше многу барано, а имплементацијата што ја имав во тоа време беше сосема доволна за внесување табели со содржини. Дополнително, насоката на развој на нашата библиотека почна сè повеќе да отстапува кон дигитализација на музејските архиви, известување и други активности од мал интерес за мене, што на крајот ме принуди конечно да ја напуштам, отстапувајќи им место на оние кои би биди позадоволен од сето ова.

Парадоксално, по овие драматични настани, проектот БИРМА, кој во тоа време веќе ги имаше сите карактеристични карактеристики на типичен долгорочен градежен проект, како да почна да го добива својот долгоочекуван нов живот! Имав повеќе слободно време за празни мисли, повторно почнав да ја чешлам World Wide Web во потрага по нешто слично (за среќа, сега веќе можев да претпоставам да го барам сето ова не каде било, туку на GitHub), а некаде во почетокот на оваа година, конечно наидов на соодветен производ од познатата компанија Salesforce под незначително име Горп. Сам по себе, можеше да направи речиси сè што ми требаше од таков парсерски мотор - имено, интелигентно да изолира поединечни фрагменти од произволен, но јасно структуриран текст, а притоа да има прилично лесен интерфејс за крајниот корисник, вклучувајќи такви разбирливи есенции, како што се шаблон, шаблон и појава, а во исто време користење на познатата синтакса на правилни изрази, која станува неспоредливо почитлива поради поделбата на назначени семантички групи за парсирање.

Во принцип, решив дека ова е она Горп (Се прашувам што значи ова име? Можеби некој вид „општо ориентиран редовен парсер“?) – токму она што го барав долго време. Навистина, неговата непосредна имплементација за мои потреби имаше таков проблем што овој мотор бараше премногу строго придржување кон структурната низа на изворниот текст. За некои извештаи како што се датотеките за евиденција (имено, тие беа поставени од програмерите како јасни примери за користење на проектот), ова е сосема погодно, но за истите текстови на скенирани табели со содржини, тоа е малку веројатно. На крајот на краиштата, истата страница со табела со содржини може да започне со зборовите „Содржина“, „Содржина“ и сите други прелиминарни описи што не треба да ги ставаме во резултатите од предвидената анализа (и рачно да ги отсечеме секој пат е исто така незгодно). Покрај тоа, помеѓу поединечни елементи што се повторуваат, како што се името на авторот, насловот и бројот на страницата, страницата може да содржи одредена количина ѓубре (на пример, цртежи и само случајни знаци), што исто така би било убаво да може да се отсечен. Сепак, последниот аспект сè уште не беше толку значаен, но поради првиот, постоечката имплементација не можеше да започне да ги бара потребните структури во текстот од одредено место, туку едноставно го обработи од самиот почеток, не ја најде таму специфицирав шаблони и... ја завршив мојата работа. Очигледно, беше потребно малку дотерување за барем малку да се остави простор помеѓу повторливите структури и тоа ме врати на работа.

Друг проблем беше што самиот проект беше имплементиран во Јава, и ако планирав во иднина да имплементирам некои средства за поврзување на оваа технологија со познати апликации за внесување податоци во постоечките бази на податоци (како што е „Каталогот“ на Ирбис), тогаш барем направете го ова во C# и .NET. Не е дека Јава сама по себе е лош јазик - еднаш дури го користев за да имплементирам интересна апликација за прозорци што ја имплементираше функционалноста на домашен програмабилен калкулатор (како дел од проект за курсеви). И во однос на синтаксата е многу сличен на истиот C-sharp. Па, ова е само плус: толку полесно ќе ми биде да финализирам постоечки проект. Сепак, не сакав повторно да се втурнам во овој прилично необичен свет на прозорски (или подобро, десктоп) Java технологии - на крајот на краиштата, самиот јазик не беше „прилагоден“ за таква употреба и воопшто не копнеев за повторување на претходното искуство. Можеби тоа е токму затоа што C# во врска со WinForms е многу поблиску до Delphi, со кој многумина од нас некогаш започнаа. За среќа, неопходното решение беше пронајдено доста брзо - во форма на проектот IKVM.NET, што го олеснува преведувањето на постоечките Java програми во управуван .NET код. Точно, самиот проект дотогаш веќе беше напуштен од авторите, но неговата најнова имплементација ми овозможи доста успешно да ги спроведам потребните активности за изворните текстови Горп.

Така, ги направив сите потребни промени и сето тоа го составив во DLL од соодветен тип, кој лесно може да се „подигне“ од кој било проект за .NET Framework создаден во Visual Studio. Во меѓувреме, создадов уште еден слој за практично прикажување на вратените резултати Горп, во форма на соодветни структури на податоци што би било погодно за обработка во приказ на табела (земајќи ги како основа и редовите и колоните; и клучевите за речник и нумеричките индекси). Па, самите потребни комунални услуги за обработка и прикажување на резултатите беа напишани доста брзо.

Исто така, процесот на прилагодување на шаблоните за новиот мотор со цел да се научи да ги анализира постоечките примероци од скенирани текстови на табели со содржина не предизвика никакви посебни компликации. Всушност, воопшто не морав да се повикувам на моите претходни шаблони: едноставно ги создадов сите потребни шаблони од нула. Дополнително, ако шаблоните дизајнирани да работат со претходната верзија на системот поставија прилично тесна рамка за текстови што може правилно да се анализираат со нивна помош, новиот мотор веќе овозможи да се развијат прилично универзални шаблони погодни за неколку типови означување на еднаш. Дури се обидов да напишам некој вид сеопфатен образец за кој било произволен текст на табелата со содржини, иако, се разбира, дури и со сите нови можности што ми се отвораат, вклучително, особено, ограничената можност за спроведување на истите вгнездени повторувачки секвенци ( како, на пример, презимиња и иницијали неколку автори по ред), ова се покажа како утопија.

Можеби во иднина ќе биде можно да се имплементира одреден концепт на мета-шаблони, кои ќе можат да го проверат изворниот текст за усогласеност со неколку од достапните шаблони одеднаш, а потоа, во согласност со добиените резултати, да го изберете најсоодветен, користејќи некој вид интелигентен алгоритам. Но, сега повеќе ме загрижуваше друго прашање. Парсер како Горп, и покрај сета негова разноврсност и модификациите што ги направив, сè уште беше инхерентно неспособен да направи една навидум едноставна работа што мојот самонапишан парсер можеше да го направи уште од првата верзија. Имено: тој имал можност да ги пронајде и извлече од изворниот текст сите фрагменти кои одговараат на маската наведена во шаблонот користен на вистинското место, притоа воопшто не го интересирал што содржи дадениот текст во празнините меѓу овие фрагменти. Досега, само малку го подобрив новиот мотор, дозволувајќи му да ги бара сите можни нови повторувања на дадена низа такви маски од моменталната позиција, оставајќи можност за присуство во текстот на множества произволни знаци кои беа целосно неоткриени во парсирањето, затворени помеѓу откриените повторливи структури. Сепак, ова не овозможи да се постави следната маска без оглед на резултатите од пребарувањето на претходниот фрагмент користејќи ја соодветната маска: строгоста на опишаната текстуална структура сè уште не остави простор за произволни вклучувања на неправилни знаци.

И ако за примерите на табели со содржини на кои наидов овој проблем сè уште не изгледаше толку сериозен, тогаш кога се обидувате да примените нов механизам за парсирање на слична задача за парсирање на содржината на веб-локација (т.е. истото парсирање), Ограничувањата се тука тие се појавија со сета нивна очигледност. На крајот на краиштата, прилично е лесно да се постават потребните маски за фрагменти од веб-означување, меѓу кои треба да се лоцираат податоците што ги бараме (кои треба да се извлечат), но како да го принудиме парсерот веднаш да премине на следното сличен фрагмент, и покрај сите можни ознаки и HTML атрибути кои можат да се постават во празнините меѓу нив?

Откако малку размислив, решив да воведам неколку модели на услуги (% all_before) и (%all_after), служејќи ја очигледната цел да се осигура дека сè што може да биде содржано во изворниот текст е прескокнато пред која било шема (маска) што ги следи. Покрај тоа, ако (% all_before) тогаш едноставно ги игнорираше сите овие произволни инклузии (%all_after), напротив, им овозможи да се додадат на саканиот фрагмент по преместувањето од претходниот фрагмент. Звучи прилично едноставно, но за да се имплементира овој концепт морав повторно да ги прочешлам изворите на Gorp за да ги направам потребните модификации за да не ја скршам веќе имплементираната логика. На крајот, успеавме да го направиме ова (иако дури и првата, иако многу загрозена, имплементацијата на мојот парсер беше напишана, па дури и побрзо - за неколку недели). Отсега натаму, системот доби навистина универзална форма - не помалку од 12 години по првите обиди да функционира.

Се разбира, ова не е крајот на нашите соништа. Можете исто така целосно да го преработите парсерот на шаблоните Gorp во C#, користејќи која било од достапните библиотеки за имплементација на бесплатна граматика. Мислам дека кодот треба да биде значително поедноставен, а тоа ќе ни овозможи да се ослободиме од наследството во форма на постоечки извори на Јава. Но, со постоечкиот тип на мотор, исто така е сосема можно да се направат разни интересни работи, вклучително и обид за имплементација на мета-шаблоните што веќе ги споменав, а да не зборуваме за парсирање на различни податоци од различни веб-страници (сепак, не исклучувам дека постоечките специјализирани софтверски алатки се посоодветни за ова - едноставно сè уште не сум имал соодветно искуство за нивно користење).

Инаку, летово веќе добив покана по е-пошта од компанија која користи технологии Salesforce (развивачот на оригиналот Горп), поминете интервју за последователна работа во Рига. За жал, во моментов не сум подготвен за вакви прераспоредувања.

Ако овој материјал предизвика одреден интерес, тогаш во вториот дел ќе се обидам подетално да ја опишам технологијата за составување и последователно парсирање на шаблони користејќи го примерот на имплементацијата што се користи во Salesforce Горп (моите сопствени додатоци, со исклучок на неколку веќе опишани функционални зборови, практично не прават никакви промени во самата синтакса на шаблоните, така што речиси целата документација за оригиналниот систем Горп Погоден и за мојата верзија).

Извор: www.habr.com