XNUMX년 동안 진행된 하나의 작은 프로젝트 이야기(BIRMA.NET에 대해 처음이자 솔직하게 직접 접함)

이 프로젝트의 탄생은 2007년 말 어딘가에 나에게 떠오른 작은 아이디어로 간주될 수 있으며, 이는 불과 12년 후에 최종 형태를 찾을 운명이었습니다(물론 현재 구현은 그렇지만, 작성자님은 매우 만족하십니다.)

모든 것은 도서관에서 당시의 공식 업무를 수행하는 과정에서 도서(및 음악) 간행물 목차의 스캔된 텍스트에서 데이터를 기존 데이터베이스에 입력하는 과정이, 분명히 기사 작성자의 이름(기사 모음에 대해 이야기하는 경우), 제목과 같이 입력에 필요한 모든 데이터의 질서와 반복성의 특성을 활용하여 상당히 단순화되고 자동화될 수 있습니다. 기사(또는 목차에 반영된 부제)와 현재 목차 항목의 페이지 번호입니다. 처음에는 이 작업을 수행하는 데 적합한 시스템을 인터넷에서 쉽게 찾을 수 있을 것이라고 실질적으로 확신했습니다. 그런 프로젝트를 찾을 수 없다는 사실에 놀랐을 때 나는 그것을 직접 구현해보기로 결정했습니다.

꽤 짧은 시간이 지난 후, 첫 번째 프로토타입이 작동하기 시작했고 저는 즉시 일상 활동에 사용하기 시작했으며 동시에 제 손에 들어온 모든 예제에서 디버깅했습니다. 다행스럽게도 제가 프로그래머가 아니었던 일반적인 직장에서는 눈에 띄는 "다운타임"을 겪으면서도 여전히 제 작업을 집중적으로 디버깅하고 있었습니다. 이는 현재 현실에서는 거의 상상할 수 없는 일입니다. 하루 동안 수행된 작업에 대한 일일 보고서입니다. 프로그램을 다듬는 과정에는 총 약 8년이 걸렸지만 그 후에도 결과가 완전히 성공적이라고는 할 수 없었습니다. 처음에는 구현하기에 완전히 명확하지 않은 너무 많은 다양한 개념이 제시되었습니다. 건너뛰다; 요소의 향후 보기(이전 요소를 검색 결과로 대체하기 위한 목적) (고유한 구문이 있는) 정규식과 같은 것을 구현하려는 우리의 시도도 마찬가지입니다. 그 전에는 프로그래밍을 어느 정도(그 이상은 아니더라도 약 XNUMX년 동안) 포기했기 때문에 흥미롭고 필요한 작업에 내 기술을 적용할 수 있는 새로운 기회가 내 관심을 완전히 사로잡았습니다. 내 입장에서는 디자인에 대한 명확한 접근 방식이 없는 상황에서 결과 소스 코드가 C++의 일부 요소와 시각적 프로그래밍 측면(처음에는 Borland C++ Builder와 같은 디자인 시스템을 사용하기로 결정했습니다. "거의 Delphi이지만 C입니다." 그러나 이 모든 것이 궁극적으로 우리 도서관의 일상 활동을 자동화하는 데 결실을 맺었습니다.

동시에 혹시라도 전문 소프트웨어 개발자를 양성하는 과정을 수강하기로 결정했습니다. 거기에서 "프로그래머가 되는 것"을 처음부터 배우는 것이 실제로 가능한지는 모르겠지만, 그 당시 이미 가지고 있던 기술을 고려하면 그 당시에 더 관련성이 높은 기술, 즉 .NET 개발을 위한 C#, Visual Studio 및 Java, HTML, SQL과 관련된 일부 기술이 있습니다. 전체 교육에는 총 XNUMX년이 걸렸고, 내 또 다른 프로젝트의 출발점이 되었으며, 결국 몇 년에 걸쳐 진행되었습니다. 하지만 이는 별도의 출판물에 대한 주제입니다. 여기에서는 필요한 기능을 구현하는 C# 및 WinForms에서 본격적인 창 응용 프로그램을 만들기 위해 설명된 프로젝트에서 이미 수행한 개발을 적용하고 이를 기반으로 사용하려고 시도했다는 점을 언급하는 것이 적절할 것입니다. 다가오는 졸업장 프로젝트.
시간이 지남에 따라이 아이디어는 "LIBKOM"및 "CRIMEA"와 같은 다양한 도서관 대표가 참여하는 연례 회의에서 표명 될 가치가 있다고 생각되기 시작했습니다. 아이디어는 그렇습니다. 하지만 당시에는 구현하지 않았습니다. 그런 다음 누군가가 더 유능한 접근 방식을 사용하여 그것을 다시 작성하기를 바랐습니다. 어떤 식으로든 2013년까지 나는 예비 작업에 대한 보고서를 작성하여 컨퍼런스 참여를 위한 보조금 신청서와 함께 컨퍼런스 조직위원회에 보내기로 결정했습니다. 다소 놀랍게도 내 신청서는 승인되었고 컨퍼런스에서 발표할 준비를 하기 위해 프로젝트를 일부 개선하기 시작했습니다.

그 무렵 프로젝트는 이미 BIRMA라는 새 이름을 받았으며 다양한 추가 기능(완전히 구현되지는 않았지만 예상됨)을 획득했습니다. 모든 세부정보는 내 보고서에서 확인할 수 있습니다..

솔직히 말해서 BIRMA 2013을 완전하다고 말하기는 어려웠습니다. 솔직히 말하면, 그것은 급하게 만든 매우 해킹된 공예품이었습니다. 코드 측면에서는 IRBIS 64 형식 언어(실제로 ISIS 시스템도 포함)를 연상시키는 일종의 파서용 통합 구문을 생성하려는 다소 무기력한 시도를 제외하고는 사실상 특별한 혁신이 전혀 없었습니다. 순환 구조로 괄호를 사용하는 경우(당시에는 꽤 멋져 보인다고 생각한 이유) 파서는 절망적으로 적절한 유형의 괄호 원을 발견했습니다(괄호는 또 다른 역할도 수행했기 때문에, 즉 파싱 중에 건너뛸 수 있는 선택적 구조를 표시했기 때문입니다). 당시에는 상상하기 어려웠고 정당화되지 않은 BIRMA 구문에 대해 더 자세히 알고 싶은 모든 사람에게 당시 보고서를 다시 언급합니다.

일반적으로 내 파서와 씨름하는 것 외에는 이 버전의 코드에 대해 더 이상 말할 것이 없습니다. .NET 코드의 몇 가지 일반적인 기능을 유지하면서 기존 소스를 C++로 역변환하는 것 외에는(솔직히 말하자면, 이해하기 어렵습니다. 모든 것을 다시 되돌리게 된 정확한 이유는 아마도 코카콜라의 비밀 레시피와 동등한 것처럼 내 소스 코드를 비밀로 유지하는 것에 대한 어리석은 두려움 때문일 것입니다.

아마도 이 어리석은 결정은 전자 카탈로그에 데이터를 입력하기 위해 결과 DLL 라이브러리를 집에서 만든 워크스테이션의 기존 인터페이스와 결합하는 데 어려움을 겪는 이유이기도 합니다(예, 또 다른 중요한 사실은 언급하지 않았습니다. 지금부터 모든 BIRMA "엔진"의 코드는 예상한 대로 인터페이스 부분에서 분리되어 적절한 DLL에 패키지되어 있습니다. 이러한 목적을 위해 별도의 워크스테이션을 작성해야 하는 이유는 무엇입니까? 외관과 사용자와의 상호 작용 방법이 IRBIS 64 시스템의 동일한 워크스테이션 "Catalogizer"를 뻔뻔하게 복사한 이유는 별도의 질문입니다. 간단히 말해서, 그것은 내 졸업 프로젝트를 위한 당시의 개발에 필요한 견고성을 제공했습니다(그렇지 않으면 소화되지 않는 파서 엔진만으로는 충분하지 않았습니다). 또한 C++ 및 C#으로 구현된 자체 모듈을 사용하여 Cataloger 워크스테이션의 인터페이스를 구현하고 엔진에 직접 액세스하는 데 몇 가지 어려움에 직면했습니다.

일반적으로 이상하게도 향후 XNUMX년 동안 나의 "일꾼"이 될 운명은 미래 BIRMA.NET의 다소 서투른 프로토타입이었습니다. 이 기간 동안 나는 적어도 오랜 아이디어를 새롭고 더 완벽하게 구현하는 방법을 찾으려고 노력하지 않았다고 말할 수 없습니다. 다른 혁신 중에는 선택적 요소를 포함할 수 있는 중첩된 순환 시퀀스가 ​​이미 있어야 했습니다. 이것이 제가 출판물의 서지 설명 및 기타 다양한 흥미로운 항목을 위한 범용 템플릿 아이디어를 생생하게 구현하려고 했던 방법입니다. 그러나 당시의 실제 활동에서는 이 모든 것이 거의 요구되지 않았고 당시 구현한 것만으로도 목차를 입력하기에 충분했습니다. 또한, 우리 도서관의 개발 벡터는 박물관 기록 보관소의 디지털화, 보고 및 나에게 거의 관심이 없는 기타 활동으로 점점 더 벗어나기 시작했고 결국에는 마침내 도서관을 떠나고 싶은 사람들에게 양보하게 되었습니다. 이 모든 것에 더 만족하십시오.

역설적이게도 당시 전형적인 장기 건설 프로젝트의 모든 특징을 이미 갖추고 있던 BIRMA 프로젝트가 오랫동안 기다려온 새로운 삶을 시작하기 시작한 것은 이러한 극적인 사건 이후였습니다! 나는 한가한 생각을 할 더 많은 자유 시간을 가졌고 비슷한 것을 찾기 위해 다시 World Wide Web을 샅샅이 뒤지기 시작했습니다. (다행히도 이제는 이 모든 것을 어디에서나 찾을 수 있을 것으로 추측할 수 있었지만 GitHub에서 찾을 수 있었습니다.) 올해 초, 드디어 유명 세일즈포스 회사의 미미한 이름으로 해당 제품을 발견했습니다. 고프. 그 자체로 파서 엔진에서 필요한 거의 모든 작업을 수행할 수 있습니다. 즉, 다음과 같이 이해할 수 있는 본질을 포함하여 최종 사용자에게 상당히 사용자 친화적인 인터페이스를 제공하는 동시에 임의의 텍스트에서 개별 조각을 지능적으로 격리하지만 명확하게 구조화되는 것입니다. 패턴, 템플릿 및 발생을 동시에 사용하는 동시에 친숙한 정규식 구문을 사용합니다. 이는 구문 분석을 위해 지정된 의미 그룹으로 분할되어 비교할 수 없을 정도로 더 읽기 쉬워집니다.

일반적으로 나는 이것이 하나라고 결정했습니다 고프 (이 이름이 무엇을 의미하는지 궁금합니다. 아마도 일종의 "일반 지향 일반 파서"일까요?) – 바로 제가 오랫동안 찾고 있던 것입니다. 사실, 내 필요에 따라 즉시 구현하려면 이 엔진이 소스 텍스트의 구조적 순서를 너무 엄격하게 준수해야 한다는 문제가 있었습니다. 로그 파일과 같은 일부 보고서(즉, 프로젝트 사용에 대한 명확한 예로 개발자가 배치한 보고서)의 경우 이는 매우 적합하지만 스캔한 목차의 동일한 텍스트에는 적합하지 않습니다. 결국 목차가 있는 동일한 페이지는 "목차", "목차"라는 단어와 의도한 분석 결과에 배치할 필요가 없는 기타 예비 설명으로 시작할 수 있습니다(수동으로 잘라내기). 매번 불편합니다). 또한, 저자 이름, 제목, 페이지 번호 등 개별적으로 반복되는 요소 사이에 해당 페이지에는 일정량의 쓰레기(예: 그림, 임의의 문자)가 포함될 수 있습니다. 끊다. 그러나 마지막 측면은 아직 그다지 중요하지 않았으나, 첫 번째로 인해 기존 구현에서는 텍스트에서 필요한 구조를 특정 위치부터 찾을 수 없었고 대신 처음부터 단순히 처리만 했기 때문에 해당 구조를 찾지 못했습니다. 거기에 특정 패턴을 지정하고... 내 작업을 종료했습니다. 분명히 반복되는 구조 사이에 최소한 약간의 공간을 허용하기 위해 약간의 조정이 필요했고 그로 인해 다시 작업할 수 있었습니다.

또 다른 문제는 프로젝트 자체가 Java로 구현되었다는 점이었고, 향후 이 기술을 기존 데이터베이스에 데이터를 입력하기 위한 친숙한 애플리케이션(예: Irbis의 "Cataloguer")과 인터페이스하는 수단을 구현할 계획이라면 최소한 C# 및 .NET에서 이 작업을 수행하세요. Java 자체가 나쁜 언어는 아닙니다. 저는 한때 Java를 사용하여 국내 프로그래밍 가능한 계산기의 기능을 구현하는 흥미로운 창 응용 프로그램을 구현한 적이 있습니다(강의 프로젝트의 일부로). 그리고 구문 측면에서 보면 동일한 C-sharp와 매우 유사합니다. 글쎄요, 이것은 단지 장점일 뿐입니다. 기존 프로젝트를 마무리하는 것이 더 쉬울 것입니다. 그러나 나는 윈도우(또는 데스크탑) Java 기술의 다소 특이한 세계로 다시 뛰어들고 싶지 않았습니다. 결국 언어 자체는 그러한 용도에 "맞춤화"되지 않았으며 이전 경험. 아마도 WinForms와 결합된 C#이 우리 중 많은 사람들이 한때 시작했던 Delphi에 훨씬 더 가깝기 때문일 것입니다. 다행스럽게도 프로젝트 형태로 필요한 솔루션이 매우 빠르게 발견되었습니다. IKVM.NET를 사용하면 기존 Java 프로그램을 관리되는 .NET 코드로 쉽게 변환할 수 있습니다. 사실, 그 당시에는 프로젝트 자체가 이미 작성자에 의해 포기되었지만 최근 구현을 통해 소스 텍스트에 필요한 작업을 매우 성공적으로 수행할 수 있었습니다. 고프.

그래서 필요한 모든 변경 작업을 수행하고 Visual Studio에서 생성된 .NET Framework용 프로젝트에서 쉽게 "선택"할 수 있는 적절한 유형의 DLL로 모두 어셈블했습니다. 그동안 반환된 결과를 편리하게 표시하기 위해 또 다른 레이어를 만들었습니다. 고프, 테이블 뷰에서 처리하기 편리한 해당 데이터 구조 형태(행과 열, 사전 키와 숫자 인덱스 모두를 기본으로 함). 결과를 처리하고 표시하는 데 필요한 유틸리티 자체는 매우 빠르게 작성되었습니다.

또한 스캔한 목차 텍스트의 기존 샘플을 구문 분석하도록 가르치기 위해 새 엔진에 템플릿을 적용하는 프로세스는 특별한 문제를 일으키지 않았습니다. 사실 이전 템플릿을 전혀 참조할 필요도 없었습니다. 필요한 템플릿을 처음부터 모두 만들었습니다. 더욱이, 이전 버전의 시스템과 함께 작동하도록 설계된 템플릿이 도움을 받아 올바르게 구문 분석할 수 있는 텍스트에 대해 상당히 좁은 프레임워크를 설정했다면, 새 엔진은 이미 다음과 같은 여러 유형의 마크업에 적합한 상당히 보편적인 템플릿을 개발하는 것을 가능하게 했습니다. 한 번. 나는 심지어 임의의 목차 텍스트에 대한 일종의 포괄적인 템플릿을 작성하려고 시도했습니다. 물론, 특히 동일한 중첩 반복 시퀀스를 구현하는 제한된 능력을 포함하여 모든 새로운 가능성이 나에게 열려 있음에도 불구하고( 예를 들어 여러 저자의 성과 이니셜을 연속으로 사용하는 경우) 이는 유토피아로 판명되었습니다.

아마도 미래에는 소스 텍스트가 사용 가능한 여러 템플릿과 호환되는지 한 번에 확인할 수 있는 특정 개념의 메타 템플릿을 구현하는 것이 가능할 것입니다. 그런 다음 얻은 결과에 따라 일종의 지능형 알고리즘을 사용하여 가장 적합한 것입니다. 하지만 이제 나는 또 다른 질문에 더 관심을 갖게 되었습니다. 다음과 같은 파서 고프, 그 모든 다재다능함과 내가 수정한 내용에도 불구하고, 내가 직접 작성한 파서가 첫 번째 버전에서 할 수 있었던 겉보기에 단순해 보이는 작업을 본질적으로 수행할 수 없었습니다. 즉, 그는 올바른 위치에 사용된 템플릿 내에 지정된 마스크와 일치하는 모든 조각을 소스 텍스트에서 찾고 추출할 수 있는 능력이 있었지만 주어진 텍스트가 이러한 조각 사이의 공간에 포함된 내용에는 전혀 관심이 없었습니다. 지금까지 나는 새 엔진을 약간만 개선하여 현재 위치에서 해당 마스크의 주어진 시퀀스에 대해 가능한 모든 새로운 반복을 검색할 수 있도록 허용하고 완전히 임의의 문자 집합이 텍스트에 존재할 가능성을 남겨 두었습니다. 감지된 반복 구조 사이에 포함되어 구문 분석에서 설명되지 않습니다. 그러나 이로 인해 해당 마스크를 사용하여 이전 조각을 검색한 결과에 관계없이 다음 마스크를 설정할 수 없었습니다. 설명된 텍스트 구조의 엄격함은 여전히 ​​불규칙한 문자를 임의로 포함할 여지를 남기지 않았습니다.

그리고 내가 접한 목차의 예에서 이 문제가 아직 그렇게 심각해 보이지 않는다면 웹 사이트의 콘텐츠를 구문 분석하는 유사한 작업(즉, 동일한 구문 분석)에 새로운 구문 분석 메커니즘을 적용하려고 할 때 한계는 여기에 모든 명백함과 함께 나타났습니다. 결국 웹 마크업 조각에 필요한 마스크를 설정하는 것은 매우 쉽습니다. 그 사이에 우리가 찾고 있는(추출해야 하는) 데이터가 위치해야 하지만 파서가 즉시 다음으로 이동하도록 강제할 수 있는 방법은 무엇입니까? 가능한 모든 태그와 HTML 속성 사이에 배치할 수 있음에도 불구하고 유사한 조각이 있습니까?

조금 생각한 끝에 몇 가지 서비스 패턴을 소개하기로 결정했습니다. (%all_이전) и (%all_after), 소스 텍스트에 포함될 수 있는 모든 항목을 뒤에 오는 패턴(마스크) 전에 건너뛰도록 보장하는 분명한 목적을 제공합니다. 게다가 만약에 (%all_이전) 이러한 임의의 포함을 모두 무시한 다음 (%all_after), 반대로 이전 조각에서 이동한 후 원하는 조각에 추가할 수 있도록 허용했습니다. 매우 간단하게 들리지만 이 개념을 구현하려면 이미 구현된 논리를 깨지 않도록 gorp 소스를 다시 샅샅이 뒤져 필요한 수정 작업을 수행해야 했습니다. 결국 우리는 이 작업을 수행할 수 있었습니다(비록 매우 버그가 있기는 하지만 내 파서의 구현이 가장 먼저 작성되었으며 심지어 몇 주 만에 훨씬 더 빨라졌습니다). 이제부터 시스템은 기능을 구현하려는 첫 번째 시도가 있은 지 12년이 채 지나지 않아 진정한 보편적인 형태를 갖추게 되었습니다.

물론 이것이 우리의 꿈의 끝은 아닙니다. 자유 문법 구현에 사용 가능한 라이브러리를 사용하여 C#에서 gorp 템플릿 파서를 완전히 다시 작성할 수도 있습니다. 나는 코드가 상당히 단순화되어야 한다고 생각하며, 이를 통해 기존 Java 소스 형태의 레거시를 제거할 수 있을 것입니다. 그러나 기존 유형의 엔진을 사용하면 다양한 웹 사이트의 다양한 데이터를 구문 분석하는 것은 물론이고 이미 언급한 메타 템플릿을 구현하려는 시도를 포함하여 다양하고 흥미로운 작업을 수행하는 것도 꽤 가능합니다(단, 배제하지는 않습니다). 기존의 전문 소프트웨어 도구가 이에 더 적합하다고 생각합니다. 아직까지는 적절한 사용 경험이 없었을 뿐입니다.

그런데 올 여름 이미 Salesforce 기술을 사용하는 회사(원본 개발자)로부터 이메일로 초대를 받았습니다. 고프), 리가에서의 후속 작업을 위한 인터뷰를 통과하세요. 불행하게도 현재로서는 그러한 재배치를 할 준비가 되어 있지 않습니다.

이 자료가 관심을 불러일으킨다면 두 번째 부분에서는 Salesforce에서 사용된 구현 예를 사용하여 템플릿을 컴파일하고 이후에 구문 분석하는 기술을 더 자세히 설명하려고 노력할 것입니다. 고프 (이미 설명한 몇 가지 기능 단어를 제외하고 내가 직접 추가한 내용은 템플릿 구문 자체를 사실상 변경하지 않으므로 원래 시스템에 대한 거의 모든 문서가 고프 내 버전에도 적합합니다.)

출처 : habr.com