기본 콘텐츠로 건너뛰기

월리를 찾아라: 문서에서 단어 분류

그림책 속 수많은 사람들 중에서 월리를 찾는 것처럼 문서의 수많은 단어들 중에서 원하는 단어를 찾는 일은 쉬운 일이 아닙니다. 아니 월리를 찾는 것이 더 쉬울지도 모르겠습니다. 요즘 회사들 사이에 Digital Transform(이하 DT)가 유행하고 있습니다. DT는 회사가 가지고 있는 문서들을 디지털 데이터로 변환하는 것을 말합니다. 4차 산업혁명의 핵심 기술인 AI를 활용하기 위해서 말이죠. 수많은 문서들 그리고 같은 의미를 가지는 다른 표현들. DT를 하기 앞서 이러한 단어들의 표준화가 진행되어야 합니다. 용어들의 표준화를 하기 위해 표준 용어 사전집이 필요합니다. 전국 사투리를 수집하고자 한다면 우선 서울 표준어를 정한 뒤 같은 의미를 가지는 사투리를 쭉 나열할 수 있습니다. 경상도/전라도/충청도/강원도/제주 사투리.... 서울 태생인 아내가 같은 의미를 가지는 단어를 하나여야만 한다고 이야기하던 일이 생각납니다. 경상도 출신인 저는 사투리도 중요하다고 반론을 했었습니다. 우리가 계산하고 나갈 때 식당 주인아주머니께서 저희를 보더니 빙긋 웃었습니다. 이렇듯 같은 의미를 가지는 용어들을 표준 용어집을 이용하여 표준 용어로 바꾸어 줍니다. 장치 문서 표준 용어집 위 표준 용어집을 이용하면 아래와 같이 바뀌게 될 것입니다. 이제 표준화된 용어를 분류하여 사전에 정의해둔 분류체계로 변환을 해야 합니다. 분류 체계 분류체계에 맞는 Value와 UOM(단위)를 찾아 채워줘야 합니다. Value와 UOM을 찾아 어떤 분류 체계에 속하는지 자동으로 채워주면 좋겠지만 이것은 대단히 어려운 작업이 될 거라 생각됩니다. 따라서 사용자가 Value와 UOM에 맞는 분류 체계를 선택하도록 합니다. 분류 체계 선택 후에 문서에서 값을 읽어 채워주면 아래와 같이 됩니다. 분류 체계에 맞게 값이 채워진 화면 위 데이터가 사용자가 원하는 최종 데이터입니다. 최종 데이터를 추출할 때 앞서 말한 표준 용어집은 의미가 ...

도쿠위키 이전

현재 GCP(Google cloud platform)에 SCM(gitea), 도쿠위키, 워드프레스가 돌아가고 있습니다. 크레딧으로 거의 일 년 동안 무료로 사용하다가 지난달에 요금이 33,470원이 나왔습니다. 개인이 사용하기에는 부담이 되어서 SCM은 Github로, 도쿠위키는 개인 서버로 이전하기로 마음먹고 어린이날 연휴 동안 작업하였습니다. Github은 가입만 하면 공개, 개인 저장소를 무제한으로 제공하고 가격도 무료입니다. 4달러로 계정을 업그레이드를 하면 다양한 혜택을 누릴 수 있습니다. 향후에 계정을 업그레이드를 해야겠습니다. 도쿠위키는 Bitnami 도쿠위키로 손쉽게 개인 서버에 설치하였습니다. 도쿠위키는 모든 데이터를 파일로 저장하기 때문에 파일을 옮기기만 하면 이전할 수 있습니다. 파일 위치는 환경 설정에서 확인할 수 있습니다. PSCP 명령어로 GCP에서 파일을 다운로드하기가 어려워 data 폴더를 하나의 파일로 압축하여 개인 서버에 운영 중이던 Artifactory에 업로드하였습니다. 리눅스의 curl 명령를 이용하면 Artifactory에 데이타를 업로드할 수 있습니다. zip -r data.zip ./data/* curl -u<id>:<password> -X PUT "<url>" -T "<file path="">" 업로드한 파일을 다운로드해 도쿠위키가 설치된 폴더에 풀어주니 GCP의 도쿠위키 데이타가 모두 복원되었습니다.

[S3D] Grid Line 생성하기

파이프 랙을 생성하기 위해서 먼저 Grid Line을 생성한 후에 Grid Line의 교차점에 칼럼을 생성하고 칼럼 간에는 빔을 생성합니다. 하지만 이번에는 이미 모델링한 파이프 랙의 Grid Line을 생성해달라는 요구를 받았습니다. 다음과 같은 파이프 랙의 경우에는 3개의 Grid Line System이 필요합니다. 그럼 주어진 파이프 랙에서 생성할 Grid Line System을 구분해야 합니다. 이 부분은 칼럼과 빔의 물리적 연결로 구분할 수 있습니다. 직관적입니다. Grid Line을 생성하기 위해서는 Grid Line System을 구성하는 축과 해당 축에 놓인 칼럼의 위치 정보가 필요합니다. 축을 구하기 위해서는 아래/좌측 칼럼(Y값이 가장 작은 칼럼들 중에서 가장 왼쪽에 있는 칼럼)을 구합니다. 아래/좌측 칼럼에서 가장 가까운 칼럼을 선택하여 축 하나를 생성합니다. 그리고 나머지 칼럼들 중에서 생성한 축과 직교하는 축을 이루는 칼럼을 선택하여 나머지 축을 생성합니다. 이렇게 Grid Line System을 구성하는 축들을 생성하였습니다. Global E 축과 구한 축과의 사이 각을 구하여 생성할 Grid Line System의 속성에 넣어주면 됩니다. 이제는 칼럼들을 축으로 매핑하여 축에 대한 위치를 구하면 됩니다. 해당 축과 아래/좌측 칼럼과 임의의 칼럼 간의 벡터의 내적을 이용하면 축에 대한 위치를 구할 수 있습니다. 이렇게 모든 칼럼들에 대해서 축 상의 위치를 구하면 부동 소수점 연산으로 인해 위치가 조금씩 맞지 않는 경우가 발생할 수 있습니다. 이때 Round 함수등을 이용하여 위치 변이를 보정할 수 있습니다. Grid Line System을 구분하는 부분은 직관적이고 파이프 랙 모델링 품질에 따라 결과가 바뀌게 됩니다. 만족하지 못하지만 그런대로 괜찮은것 같습니다. Grid Line System의 축과 칼럼 위치 정보를 구하는 부분은 명료하고 군더더기가 없어 만족합니다. 코...

SonarQube와 Jenkins 연동

Jenkins와 연동하기 위해서 SonarQube Scanner for Jenkins 플러그인을 설치합니다. SonarQube에서 프로젝트를 생성합니다. Project key로 프로젝트 이름을 입력합니다. 그리고 Set Up 버튼을 클릭합니다. 토큰을 생성하기 위해 프로젝트 이름을 입력하고 [생성하기] 버튼을 클릭합니다. 생성한 토큰을 저장합니다. 이 페이지를 벗어나면 생성한 토큰을 찾을 방법이 없습니다. [Continue] 버튼을 클릭합니다. 프로젝트에서 사용하는 주요 언어를 선택합니다. 기타를 선택했을 경우 운영체제까지 선택해줍니다. SonarQube Scanner를 다운로드합니다. 다운로드한 파일을 Jenkins가 구축되어 있는 시스템에 설치합니다. Sonar Scanner 실행 예제를 Jenkins Job에 복사, 붙여넣기 합니다. 그러면 Jenkins에서 프로젝트를 빌드할때 마다 SonarQube에서 소스를 검사하게 됩니다. Python 프로젝트를 SonarQube 를 통해 소스 검사를 했는데 에러가 발생했습니다. 분명 Python 프로젝트인데 왜 node 를 찾는지 모르겠네요. 이런 현상을 구글링해보니 프로젝트 속성에 node 경로를 넣어주면 된다고 합니다. sonar-project.properties 파일을 만들어 프로젝트 최상위 폴더에 추가하였습니다. 에러없이 잘 돌아갑니다. 검사 결과는 SonarQube 대시보드에서 확인할 수 있습니다. 회사 사람들 모두가 볼수 있도록 입구 TV 같은 곳에 켜놓으면 프로젝트 상황을 볼수 있어 더욱 효과적일것 같습니다.

[Pyinstaller] 실행 파일 관리자 권한 획득하기

고객사에서 일부 사용자에게서 프로그램 오류가 발생한다며 아래와 같이 에러 캡처를 보내왔습니다. 프로그램에서 로그를 남기기 위해 로그 파일을 생성하는데 권한의 문제로 로그 파일을 생성하지 못해 프로그램 오류가 발생한 것 같습니다. 처음에는 Python 코드에서 관리자 권한을 요청하는 코드를 넣으려고 했는데, 실제로 Stackoverflow를 찾아보면 이런 내용이 나옵니다. 프로그램이 관리자 권한으로 실행되지 않았다면 관리자 권한으로 다시 프로그램을 실행시키는 코드입니다. import os import sys import win32com.shell.shell as shell ASADMIN = 'asadmin' if sys.argv[-1] != ASADMIN: script = os.path.abspath(sys.argv[0]) params = ' '.join([script] + sys.argv[1:] + [ASADMIN]) shell.ShellExecuteEx(lpVerb='runas', lpFile=sys.executable, lpParameters=params) sys.exit(0) 하지만 개인적으로 이런 방식은 마음에 들지 않았고 조금 더 찾아보니 Pyinstaller로 exe 파일을 만들 때 옵션을 설정하여 관리자 권한을 요청하도록 할 수 있다고 합니다. --uac-admin을 옵션에 추가하면 프로그램 실행 시 관리자 권한을 요청할 수 있습니다. pyinstaller.exe --uac-admin sample.py 하지만 안타깝게도 이 방식은 원하는 대로 동작하지 않았습니다. 마지막으로 manifest 파일을 이용하여 시도해보았습니다. spec 파일을 이용하여 pyinstaller로 빌드하면 <실행 파일 이름>.manifest 라는 파일이 생성됩니다. 파일에서 아랫부분을 찾아볼 수 있습니다. <security> <re...

[WIX] 설치 파일 만들기

WIX를 이용하여 설치 파일을 만드는 과정은 아래와 같습니다. 첫 번째 폴더의 파일들을 읽어 기본이 되는 WXS 파일을 생성합니다. %HEAT% dir .\Setup -dr INSTALLFOLDER -cg <ComponentGroup> -g1 -gg -sf -srd -scom -sreg -out ".\<프로젝트 이름>.wxs" 1. dir : 설치할 파일들이 있는 폴더 이름을 지정합니다. 2. -dr : WXS에서의 Directory 이름을 지정합니다. 3. -cg: WXS에서의 ComponentGroup 이름을 지정합니다. 4. -out: 생성할 WXS 파일 이름을 지정합니다. 이렇게 해서 WXS 파일을 생성하면 아쉽게도 32비트 용을 설치됩니다. 이것을 64비트로 바꾸려면 Component Attribute에 Win64='yes' 속성을 추가해 줘야 합니다. 예전에 수백 개의 Component에 일일이 속성을 추가해 주던 기억이 나네요^^; 이렇게 무식한 방법 대신 xslt 파일을 이용하면 속성을 수정할 수 있습니다. %HEAT% dir .\Setup -dr INSTALLFOLDER -cg <ComponentGroup> -g1 -gg -sf -srd -scom -sreg -t HeatTransform.xslt -out ".\ .wxs" 이렇게 xslt 파일을 이용하면 Component Attribute에 Win64='yes' 속성을 추가할 수 있습니다. - HeatTransform.xslt - <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:w...

[Jenkins & Artifactory] Jenkins Freestyle Job 생성 및 Artifactory 구축

먼저 Jenkins Freestyle Job에 대해 알아보도록 하겠습니다. ​ 1. Jenkins 설정 1.1 사용자 정보(Credential)은 Manage Credential 화면에서 추가할 수 있습니다. 1.2 Plugin 설치 - MSBuild Plugin: MSBuild를 사용하기 위해서는 MSBuild Plugin을 설치해야 합니다. - change-assembly-version-plugin : .NET 프로젝트의 어셈블리 정보를 수정할때 필요합니다. - Environment File Plugin : 파일의 정보로 환경 변수를 바꿀때 사용합니다. - Email Extension Plugin : html 형식의 메일을 발송할때 사용합니다. 1.3 Jenkins 환경 설정 - Global properties를 설정합니다. 프로젝트 빌드에 필요한 파일들의 경로를 설정하였습니다. - 빌드 결과를 통보하기 위해 Email 설정을 합니다. - .NET 프로젝트를 MSBuild로 컴파일하기 때문에 필요한 Global Tool Configuration에서 MSBuild 를 추가합니다.

[Jenkins] Pipeline Job 구축

Pipeline 프로젝트를 생성하기 위해서는 Groovy 스크립트를 알아야 합니다. 하지만 Freestyle 프로젝트보다는 스크립트를 사용하기 때문에 한 군데서 빌드 흐름을 제어가 가능합니다. Freestyle의 경우는 설정하는 부분이 여기저기 흩어져 있어 설정하기에 산만한 것 같습니다. Jenkins Pipeline에 대해서는 여기 를 참조하면 좋을것 같습니다. 아래 2가지 종류의 프로젝트에 대해서 Jenkins 파이프 라인을 구축하였습니다. 둘다 흐름은 동일합니다. .NET 프로젝트 파이프라인 파이썬 프로젝트 파이프라인 우선 Jenkins의 " 시스템 설정 에서 프로젝트 빌드에 필요한 환경 변수들을 설정합니다. - 버전별 Python 실행 파일 경로 : Python 프로젝트 컴파일에 필요합니다. - MsBuild.exe 파일 경로 : .NET 솔류션 컴파일에 필요합니다. - WixToolSet 파일 경로들 : 설치 파일 생성에 필요합니다. - CURL, DOXYGEN .... : 필요한 파일들을 추가합니다. 1. git에서 소스 얻어오기 git에 접속하여 소스를 얻어올 사용자의 Credential을 추가합니다. ID/PASSWORD를 입력하면 됩니다. stage('Checkout') { steps { git branch: 'master', credentialsId: 'Your credentials id', url: '{Repository Path}' } 2. Python 가상 환경 구축     이전 글을 참조하시면 됩니다. 3. 버전 수정 Jenkins로 빌드할 때마다 Jenkins BUILD_NUMBER로 실행 파일 및 설치 파일의 빌드 넘버를 설정하도록 합니다. MSDN을 찾아보면 빌드 넘버는 Major.Minor.Build.Revision으로 구성되어 있습니다. Python 프...

길 찾기 개선

  이전 글 참조 Dijkstra 알고리즘을 이용하여 출발점에서 종료점까지 가는 최소 비용의 경로를 찾을 수 있습니다. 하지만 시간 복잡도는 $$O(n^2)$$로 좋지 않습니다. Dijkstra 알고리즘은 종료점까지 도착한 경로들을 구한 뒤 가장 적은 비용의 경로를 선택합니다. 만일 각 노드마다 비용을 확인하여 도중에 탐색을 멈추게할 수 있다면 알고리즘을 개선할 수 있습니다.

[리팩토링] 신박한 정리

 유명한 그리고 한때 유명했던 사람들이 출연하여 자신들의 집을 정리하는 프로그램이 있습니다. 집 정리가 끝난 후 입을 쩍 벌리며 놀라워하는 사람들의 모습이 인상적인 프로그램입니다. 코로나 시국이라 이런 포맷의 프로그램도 등장하는 것 같습니다. 정신없이 프로젝트를 수행하다 보면 우리의 코드도 정리가 필요할 때가 옵니다. 우리도 입이 쩍 벌어질 정도의 깔끔한 코드를 짤 수 있습니다. 아래는 제가 코딩을 하면서 지키는 나름의 가이드입니다. 1. 메모리 관리에 신경쓰야 합니다. .NET Framework에서 가비지 컬렉션으로 메모리 관리를 하지만 프로그램에서 메모리를 과도하게 낭비하다보면 결국에 OutOfMemoryException을 경험하게 될겁니다. 위 코드에서 Map은 생성하자마자 쓰레기통에 쳐박히게 됩니다. 2. 멤버 변수의 노출을 최소화합니다. 멤버 변수를 가지고 외부에서 어떤 일을 할지 몰라 항상 위험이 존재하게 됩니다. 그리고 멤버 변수를 참조하게 되면 해당 멤버 변수를 수정했을때 참조하는 코드도 수정해야 합니다. 즉 결합도가 증가됩니다. 결합도는 줄이고 응집도는 높여야 좋은 코드가 됩니다. 따라서 메서드를 만들어 클래스에게 일을 시키는 방향으로 코드를 작성하는 것이 좋습니다. 데이터를 받아 일을 하는게 아니라 일을 위임하여 서비스를 받는다고 생각하면 될것 같습니다. 3. 오류가 노출되게 합니다. 가끔씩 오류가 발생할 가능성이 있는 부분 혹은 디버깅시 오류가 발생한 곳에 try/catch로 감싸놓은 코드를 볼 수가 있습니다. 이런 부분의 프로그램의 잠재적 위험이 됩니다. 프로그램이 죽지 않을뿐 우리가 원하지 않은 다른 결과를 얻게 됩니다. 그리고 점점더 위험한 프로그램을 만들게 됩니다. 오히려 우리의 예상과 다른 결과를 얻었을때 오류를 발생시키는 것이 좋습니다. /// <summary> /// start에서 end로 가는 최소 비용의 경로를 구한다 /// </summary> /// <param name="start...