Die geboorte van hierdie projek kan beskou word as 'n klein idee wat iewers aan die einde van 2007 by my opgekom het, wat bestem was om eers 12 jaar later sy finale vorm te vind (op hierdie tydstip - natuurlik, hoewel die huidige implementering, volgens vir die skrywer, is baie bevredigend).
Dit het alles begin toe ek, in die proses om my destydse amptelike pligte in die biblioteek na te kom, die aandag daarop gevestig het dat die proses om data uit die geskandeerde teks van inhoudsopgawes van boek (en musiek) publikasies in die bestaande databasis in te voer, blykbaar aansienlik vereenvoudig en outomatiseer kan word, deur voordeel te trek uit die eienskap van ordelikheid en herhaalbaarheid van alle data wat benodig word vir insette, soos die naam van die skrywer van die artikel (as ons praat oor 'n versameling artikels), die titel van die artikel (of die subtitel wat in die inhoudsopgawe weerspieël word) en die bladsynommer van die huidige inhoudsopgawe-item. Aanvanklik was ek feitlik oortuig daarvan dat 'n stelsel wat geskik is om hierdie taak uit te voer, maklik op die internet gevind kan word. Toe een of ander verbasing veroorsaak is deur die feit dat ek nie so 'n projek kon kry nie, het ek besluit om dit op my eie te probeer implementeer.
Na 'n redelike kort tydjie het die eerste prototipe begin werk, wat ek dadelik in my daaglikse aktiwiteite begin gebruik het, en dit terselfdertyd ontfout op al die voorbeelde wat by my opgekom het. Gelukkig het ek by my gewone werkplek, waar ek geensins 'n programmeerder was nie, toe nog met sigbare "stilstand" in my werk weggekom, waartydens ek intensief besig was om my breinkind te ontfout - 'n byna ondenkbare ding in die huidige realiteite, wat impliseer daaglikse verslae oor werk gedoen gedurende die dag. Die proses om die program te poets het altesaam nie minder nie as sowat 'n jaar geneem, maar selfs daarna kon die resultaat kwalik heeltemal suksesvol genoem word - daar was te veel verskillende konsepte wat nie heeltemal verstaanbaar was vir implementering nie: opsionele elemente wat oorgeslaan kan word ; vorentoe kyk van elemente (met die doel om vorige elemente in soekresultate te vervang); selfs ons eie poging om iets soos gewone uitdrukkings (wat 'n unieke sintaksis het) te implementeer. Ek moet sê dat ek voorheen ietwat opgegee het (vir ongeveer 8 jaar, indien nie meer nie), so die nuwe geleentheid om my vaardighede toe te pas op 'n interessante en noodsaaklike taak het my aandag heeltemal gevang. Dit is nie verbasend dat die gevolglike bronkode - in die afwesigheid van enige duidelike benaderings tot die ontwerp van my kant - redelik vinnig 'n ondenkbare mengelmoes geword het van uiteenlopende stukke in die C-taal met sommige elemente van C++ en aspekte van visuele programmering (aanvanklik was dit is besluit om so 'n ontwerpstelsel soos Borland C++ Builder te gebruik - "amper Delphi, maar in C"). Dit alles het egter uiteindelik vrugte afgewerp in die outomatisering van die daaglikse aktiwiteite van ons biblioteek.
Terselfdertyd het ek besluit om, vir ingeval, kursusse te volg om professionele sagteware-ontwikkelaars op te lei. Ek weet nie of dit eintlik moontlik is om daar van voor af te leer "om 'n programmeerder te wees nie, maar met inagneming van die vaardighede wat ek toe reeds gehad het, kon ek ietwat tegnologieë bemeester wat teen daardie tyd meer relevant was, bv. as C#, Visual Studio vir ontwikkeling onder .NET, asook sommige tegnologieë wat verband hou met Java, HTML en SQL. Die hele opleiding het altesaam twee jaar geduur, en het gedien as die beginpunt vir nog 'n projek van my, wat uiteindelik oor etlike jare gestrek het - maar dit is 'n onderwerp vir 'n aparte publikasie. Hier sal dit net gepas wees om daarop te let dat ek 'n poging aangewend het om die ontwikkelings wat ek reeds op die beskryfde projek gehad het aan te pas om 'n volwaardige venstertoepassing in C# en WinForms te skep wat die nodige funksionaliteit implementeer, en dit as basis te gebruik vir die komende diplomaprojek.
Met verloop van tyd het hierdie idee vir my waardig begin lyk om by sulke jaarlikse konferensies uitgespreek te word met die deelname van verteenwoordigers van verskeie biblioteke soos "LIBKOM" en "CRIMEA". Die idee, ja, maar nie my implementering daarvan op daardie tydstip nie. Dan het ek ook gehoop dat iemand dit met meer bekwame benaderings sou oorskryf. Op een of ander manier het ek teen 2013 besluit om 'n verslag oor my voorlopige werk te skryf en dit aan die Konferensie-reëlingskomitee te stuur met 'n aansoek om 'n toekenning om aan die konferensie deel te neem. Tot my ietwat verbasing is my aansoek goedgekeur, en ek het 'n paar verbeterings aan die projek begin aanbring om dit voor te berei vir aanbieding by die konferensie.
Teen daardie tyd het die projek reeds 'n nuwe naam BIRMA gekry, verskeie bykomende (nie soseer volledig geïmplementeer nie, maar eerder veronderstelde) vermoëns verkry - .
Om eerlik te wees, was dit moeilik om BIRMA 2013 iets volledig te noem; Eerlik gesproke was dit 'n baie haastige handwerk wat inderhaas gemaak is. Wat kode betref, was daar feitlik geen spesiale innovasies nie, behalwe vir 'n taamlik hulpelose poging om 'n soort verenigde sintaksis vir die ontleder te skep, in voorkoms wat herinner aan die IRBIS 64-formateertaal (en in werklikheid ook die ISIS-stelsel - met hakies as sikliese strukture; hoekom Ek het destyds gedink dit lyk redelik cool). Die ontleder het hopeloos op hierdie sirkels van hakies van die gepaste tipe gestruikel (aangesien hakies ook 'n ander rol vertolk het, naamlik hulle het opsionele strukture tydens ontleding gemerk wat oorgeslaan kan word). Ek verwys weer almal wat met die destyds moeilik denkbare, ongeregverdigde sintaksis van BIRMA kennis wil maak, in meer besonderhede na my verslag van daardie tyd.
In die algemeen, behalwe om met my eie ontleder te sukkel, het ek niks meer om te sê oor die kode van hierdie weergawe nie - behalwe vir die omgekeerde omskakeling van die bestaande bronne na C++ terwyl 'n paar tipiese kenmerke van .NET-kode bewaar word (om eerlik te wees, dit is moeilik om te verstaan, wat presies my aangespoor het om alles terug te skuif - waarskynlik 'n dom vrees om my bronkodes geheim te hou, asof dit iets gelykstaande is aan die geheime resep van Coca-Cola).
Miskien lê hierdie dom besluit ook die rede vir die probleme om die resulterende DLL-biblioteek te koppel met die bestaande koppelvlak van 'n tuisgemaakte werkstasie om data in 'n elektroniese katalogus in te voer (ja, ek het nie 'n ander belangrike feit genoem nie: van nou af sal alle die kode van die BIRMA "enjin" was soos verwag, dit is geskei van die koppelvlak deel en verpak in die toepaslike DLL). Waarom dit nodig was om 'n aparte werkstasie vir hierdie doeleindes te skryf, wat in elk geval, in sy voorkoms en metode van interaksie met die gebruiker, dieselfde werkstasie "Catalogizer" van die IRBIS 64-stelsel skaamteloos gekopieer het - dit is 'n aparte vraag. Kortom: dit het die nodige stewigheid gegee aan my destydse ontwikkelings vir my afstudeerprojek (anders was die onverteerbare ontleder-enjin alleen op een of ander manier nie genoeg nie). Daarbenewens het ek toe 'n paar probleme ondervind met die implementering van die koppelvlak van die Cataloger-werkstasie met my eie modules, geïmplementeer in beide C++ en C#, en direk toegang tot my enjin.
Oor die algemeen, vreemd genoeg, was dit hierdie taamlik lomp prototipe van die toekomstige BIRMA.NET wat bestem was om my "werkesel" vir die volgende vier jaar te word. Daar kan nie gesê word dat ek gedurende hierdie tyd nie ten minste maniere probeer vind het vir 'n nuwe, meer volledige implementering van 'n jarelange idee nie. Onder ander innovasies moes daar reeds geneste sikliese reekse gewees het wat opsionele elemente kon insluit - dit is hoe ek die idee van universele sjablone vir bibliografiese beskrywings van publikasies en verskeie ander interessante dinge gaan lewe gee. In my praktiese aktiwiteite op daardie tydstip was dit egter min in aanvraag, en die implementering wat ek destyds gehad het, was redelik voldoende om inhoudsopgawes in te voer. Boonop het die ontwikkelingsrigting van ons biblioteek al hoe meer begin afwyk na die digitalisering van museumargiewe, verslaggewing en ander aktiwiteite wat vir my min belang stel, wat my op die ou end genoop het om dit finaal te verlaat en plek te maak vir diegene wat wees meer tevrede met dit alles.
Paradoksaal genoeg was dit na hierdie dramatiese gebeure dat die BIRMA-projek, wat op daardie stadium reeds al die kenmerkende kenmerke van 'n tipiese langtermyn-konstruksieprojek gehad het, skynbaar sy langverwagte nuwe lewe begin aanneem het! Ek het meer vrye tyd gehad vir ledige gedagtes, ek het weer die World Wide Web begin fynkam op soek na iets soortgelyks (gelukkig kon ek nou al raai om dit alles nie net oral nie, maar op GitHub te soek), en iewers in At the begin hierdie jaar het ek uiteindelik op 'n ooreenstemmende produk van die bekende Salesforce-maatskappy afgekom onder die onbeduidende naam . Op sigself kon dit byna alles doen wat ek nodig het van so 'n ontleder-enjin - naamlik individuele fragmente intelligent isoleer van arbitrêre, maar duidelik gestruktureerde teks, terwyl dit 'n redelik gebruikersvriendelike koppelvlak vir die eindgebruiker het, insluitend sulke verstaanbare essensies, soos 'n patroon, sjabloon en voorkoms, en terselfdertyd die bekende sintaksis van gereelde uitdrukkings te gebruik, wat onvergelykbaar meer leesbaar word as gevolg van die verdeling in aangewese semantiese groepe vir ontleding.
Oor die algemeen het ek besluit dat dit die een is Gorp (Ek wonder wat hierdie naam beteken? Miskien 'n soort van "algemeen georiënteerde gereelde ontleder"?) - presies waarna ek al lank gesoek het. Die onmiddellike implementering daarvan vir my eie behoeftes het wel so 'n probleem gehad dat hierdie enjin te streng nakoming van die strukturele volgorde van die bronteks vereis het. Vir sommige verslae soos loglêers (dit is naamlik deur die ontwikkelaars geplaas as duidelike voorbeelde van die gebruik van die projek), is dit baie geskik, maar vir dieselfde tekste van geskandeerde inhoudsopgawes is dit onwaarskynlik. Dieselfde bladsy met 'n inhoudsopgawe kan immers begin met die woorde "Inhoudsopgawe", "Inhoud" en enige ander voorlopige beskrywings wat ons nie in die resultate van die beoogde ontleding hoef te plaas nie (en dit met die hand af te sny elke keer is ook ongerieflik). Daarbenewens kan die bladsy tussen individuele herhalende elemente, soos die skrywer se naam, titel en bladsynommer, 'n sekere hoeveelheid vullis bevat (byvoorbeeld tekeninge en net willekeurige karakters), wat dit ook lekker sal wees om te kan sny af. Die laaste aspek was egter nog nie so betekenisvol nie, maar as gevolg van die eerste kon die bestaande implementering nie vanaf 'n sekere plek na die nodige strukture in die teks begin soek nie, maar dit eerder van die begin af verwerk, nie die patrone daar gespesifiseer en... my werk beëindig. Natuurlik was 'n paar aanpassings nodig om ten minste 'n bietjie spasie tussen die herhalende strukture toe te laat, en dit het my weer aan die werk gebring.
Nog 'n probleem was dat die projek self in Java geïmplementeer is, en as ek in die toekoms beplan het om 'n manier te implementeer om hierdie tegnologie te koppel met bekende toepassings om data in bestaande databasisse in te voer (soos Irbis se "Cataloguer"), dan ten minste ten minste doen dit in C# en .NET. Dit is nie dat Java self 'n slegte taal is nie - ek het dit selfs een keer gebruik om 'n interessante venstertoepassing te implementeer wat die funksionaliteit van 'n huishoudelike programmeerbare sakrekenaar geïmplementeer het (as deel van 'n kursusprojek). En in terme van sintaksis is dit baie soortgelyk aan dieselfde C-skerp. Wel, dit is net 'n pluspunt: hoe makliker sal dit vir my wees om 'n bestaande projek te finaliseer. Ek wou egter nie weer in hierdie taamlik ongewone wêreld van venster- (of liewer, lessenaar) Java-tegnologie induik nie - die taal self was immers nie "gepasmaak" vir sulke gebruik nie, en ek het glad nie gesmag na 'n herhaling van die vorige ervaring. Miskien is dit juis omdat C# in samewerking met WinForms baie nader aan Delphi is, waarmee baie van ons eens begin het. Gelukkig is die nodige oplossing redelik vinnig gevind – in die vorm van die projek , wat dit maklik maak om bestaande Java-programme in bestuurde .NET-kode te vertaal. Die projek self is weliswaar teen daardie tyd reeds deur die skrywers laat vaar, maar die jongste implementering daarvan het my in staat gestel om die nodige aksies vir die brontekste redelik suksesvol uit te voer Gorp.
Ek het dus al die nodige veranderinge aangebring en dit alles saamgestel in 'n DLL van die toepaslike tipe, wat maklik deur enige projekte vir die .NET Framework wat in Visual Studio geskep is, "opgetel" kon word. Intussen het ek 'n ander laag geskep vir gerieflike aanbieding van die resultate wat teruggestuur is Gorp, in die vorm van ooreenstemmende datastrukture wat gerieflik sal wees om in 'n tabelaansig te verwerk (met beide rye en kolomme; beide woordeboeksleutels en numeriese indekse as basis). Wel, die nodige hulpmiddels self vir die verwerking en vertoon van die resultate is redelik vinnig geskryf.
Die proses om sjablone vir die nuwe enjin aan te pas om dit te leer om bestaande voorbeelde van geskandeerde inhoudsopgawe-tekste te ontleed, het ook geen spesiale komplikasies veroorsaak nie. Om die waarheid te sê, ek hoef glad nie eers na my vorige sjablone te verwys nie: ek het eenvoudig al die nodige sjablone van nuuts af geskep. Verder, as die sjablone wat ontwerp is om met die vorige weergawe van die stelsel te werk 'n taamlik nou raamwerk vir tekste stel wat korrek met hul hulp ontleed kan word, het die nuwe enjin dit reeds moontlik gemaak om redelik universele sjablone te ontwikkel wat geskik is vir verskeie tipes opmaak by een keer. Ek het selfs probeer om 'n soort omvattende sjabloon vir enige arbitrêre inhoudsopgawe teks te skryf, alhoewel, natuurlik, selfs met al die nuwe moontlikhede wat vir my oopgemaak het, insluitend, in die besonder, die beperkte vermoë om dieselfde geneste herhalende rye te implementeer ( soos byvoorbeeld vanne en voorletters verskeie skrywers in 'n ry), dit blyk 'n utopie te wees.
Miskien sal dit in die toekoms moontlik wees om 'n sekere konsep van meta-sjablone te implementeer, wat in staat sal wees om die bronteks te kontroleer vir voldoening aan verskeie van die beskikbare sjablone op een slag, en dan, in ooreenstemming met die resultate wat verkry is, die mees geskikte een, met behulp van 'n soort intelligente algoritme. Maar nou was ek meer bekommerd oor 'n ander vraag. 'n Ontleder soos Gorp, ten spyte van al sy veelsydigheid en die wysigings wat ek gemaak het, was dit steeds inherent nie in staat om een skynbaar eenvoudige ding te doen wat my selfgeskrewe ontleder van die heel eerste weergawe af kon doen nie. Hy het naamlik die vermoë gehad om alle fragmente wat ooreenstem met die masker gespesifiseer binne die sjabloon wat op die regte plek gebruik is te vind en uit die bronteks te onttrek, terwyl hy glad nie geïnteresseerd was in wat die gegewe teks in die spasies tussen hierdie fragmente bevat nie. Tot dusver het ek die nuwe enjin net effens verbeter, wat dit moontlik gemaak het om te soek na alle moontlike nuwe herhalings van 'n gegewe volgorde van sulke maskers vanaf die huidige posisie, wat die moontlikheid laat vir die teenwoordigheid in die teks van stelle arbitrêre karakters wat heeltemal was onverklaarbaar in die ontleding, ingesluit tussen die bespeurde herhalende strukture. Dit het dit egter nie moontlik gemaak om die volgende masker op te stel nie, ongeag die resultate van die soektog na die vorige fragment met behulp van die ooreenstemmende masker: die strengheid van die beskryfde teksstruktuur het steeds nie ruimte gelaat vir arbitrêre insluitings van onreëlmatige karakters nie.
En as hierdie probleem vir die voorbeelde van inhoudsopgawes wat ek teëgekom het nog nie so ernstig gelyk het nie, dan wanneer ek probeer om 'n nuwe ontledingsmeganisme toe te pas op 'n soortgelyke taak om die inhoud van 'n webwerf te ontleed (d.w.s. dieselfde ontleding), is dit beperkings is hier het hulle verskyn met al hul vanselfsprekendheid. Dit is immers redelik maklik om die nodige maskers op te stel vir fragmente van webopmaak, waartussen die data waarna ons soek (wat onttrek moet word) geleë moet wees, maar hoe kan ons die ontleder dwing om onmiddellik na die volgende te beweeg soortgelyke fragment, ten spyte van al die moontlike etikette en HTML-kenmerke wat in die spasies tussen hulle geplaas kan word?
Nadat ek 'n bietjie gedink het, het ek besluit om 'n paar dienspatrone bekend te stel (%almal_voor) и (%almal_na), wat die ooglopende doel dien om te verseker dat alles wat in die bronteks vervat is, oorgeslaan word voor enige patroon (masker) wat daarop volg. Verder, as (%almal_voor) het dan eenvoudig al hierdie arbitrêre insluitings geïgnoreer (%almal_na), inteendeel, het toegelaat dat hulle by die verlangde fragment gevoeg word nadat hulle van die vorige fragment af beweeg het. Dit klink redelik eenvoudig, maar om hierdie konsep te implementeer moes ek weer deur die gorp-bronne fynkam om die nodige wysigings aan te bring om nie die reeds geïmplementeerde logika te breek nie. Op die ou end het ons dit reggekry (hoewel selfs die heel eerste, alhoewel baie foutiewe implementering van my ontleder geskryf is, en selfs vinniger - binne 'n paar weke). Voortaan het die stelsel 'n werklik universele vorm aangeneem - nie minder nie as 12 jaar na die eerste pogings om dit te laat funksioneer.
Dit is natuurlik nie die einde van ons drome nie. U kan ook die gorp-sjabloon-ontleder volledig herskryf in C#, deur enige van die beskikbare biblioteke te gebruik om 'n gratis grammatika te implementeer. Ek dink die kode moet aansienlik vereenvoudig word, en dit sal ons toelaat om ontslae te raak van die nalatenskap in die vorm van bestaande Java-bronne. Maar met die bestaande tipe enjin is dit ook heel moontlik om verskeie interessante dinge te doen, insluitend 'n poging om die meta-sjablone wat ek reeds genoem het te implementeer, om nie eens te praat van die ontleding van verskeie data vanaf verskeie webwerwe nie (ek sluit egter nie uit nie dat bestaande gespesialiseerde sagteware-instrumente meer geskik is hiervoor – ek het net nog nie die toepaslike ervaring gehad om dit te gebruik nie).
Terloops, hierdie somer het ek reeds 'n uitnodiging per e-pos ontvang van 'n maatskappy wat Salesforce-tegnologie gebruik (die ontwikkelaar van die oorspronklike Gorp), slaag 'n onderhoud vir daaropvolgende werk in Riga. Ongelukkig is ek op die oomblik nie gereed vir sulke herontplooiings nie.
As hierdie materiaal 'n mate van belangstelling wek, sal ek in die tweede deel probeer om die tegnologie vir die samestelling en daaropvolgende ontleding van sjablone in meer besonderhede te beskryf deur die voorbeeld van die implementering wat in Salesforce gebruik word. Gorp (my eie toevoegings, met die uitsondering van 'n paar funksiewoorde wat reeds beskryf is, maak feitlik geen veranderinge aan die sjabloonsintaksis self nie, dus byna alle dokumentasie vir die oorspronklike stelsel Gorp Geskik vir my weergawe ook).
Bron: will.com