프로그래밍을 일상 생활속으로

요즘에는 거의 모든 프로그램에서 자동 업데이트 기능을 제공하고 있습니다. 저의 경우 2008년도 SI 프로젝트에서 자동 업데이트 기능을 직접 구현하여 사용하였고, 또 그 시절 데브피아에서는 어떤 분이 자동 업데이트 기능을 판매하기도 했었습니다. 최근 회사 프로그램에서도 직접 자동 업데이트 기능을 구현하여 사용하였습니다. 이제는 맥에서 사용하던 자동 업데이트 프로그램인 Sparkle을 윈도우즈에서도 사용할 수 있습니다. 더 이상 자동 업데이트 기능을 구현할 필요가 없습니다. Sparkle이 윈도우즈로 포팅되면서 여러 변종이 생겨났습니다. C#/.NET에서 사용 가능한 NetSparkle 그리고 좀 더 간단하게 사용 가능한 WinSparkle( https://winsparkle.org/) 이 있습니다. WinSparkle에서는 아래 언어에 대한 바인딩을 지원합니다. C#/.NET, Python, Go, Pascal 현재 진행하고 있는 프로젝트의 고객사에서 자동 업데이트 기능을 요구해 왔습니다. 해당 프로젝트가 Python으로 구현되어 Python 바인딩을 지원하는 WinSparkle을 이용하여 해당 기능을 구현하기로 했습니다. 먼저 Python 바인딩인 pywinsparkle을 설치합니다. 에 가시면 예제 코드가 있습니다. 이 코드를 이용하면 아주 간단하게 프로그램에 자동 업데이트 기능을 추가할 수 있습니다. 이제 자동 업데이트 정보를 XML 파일에 저장하여 서버에 올려놓으면 프로그램 실행 시(구현에 따라 다름)에 최신 버전으로 자동 업데이트할 수 있습니다. 아래는 XML 파일 예제입니다. 여기서 중요한 부분은 릴리즈 노트(sparkle:releaseNotesLink), 설치 프로그램 위치(url), 버전(sparkle:version)입니다. 실행 프로그램 버전과 XML의 버전을 확인하여 최신 버전이 있으면 릴리즈 노트를 보여주고 사용자가 최신 프로그램을 설치할 수 있도록 합니다. <?xml version="1.0...

고객사에서 프로그램을 외부에서 사용해야 하는데 프로그램 유출이 우려되어 보안 기능을 적용해달라고 합니다. 고객사에서 제시한 기능은 다음과 같습니다. 프로세스 체크(특정 프로세스가 돌아가고 있는지 확인) 라이선스 키 체크 만료 기간 설정 첫 번째는 요새 기업에서는 보안 프로그램이 돌아가고 있기 때문에 그걸 체크해달라는 겁니다. 두, 세 번째는 JWT를 사용하여 기능을 구현하였습니다. 이제 Jenkins를 이용하여 보안 기능이 적용된 설치 파일을 만들어야 합니다. 참고로 보안 기능을 위해 git에 새로운 브랜치를 만들었습니다. 따라서 빌드할 때 브랜치를 선택해야 합니다. Jenkins의 Build with Parameter 플러그인을 이용하면 빌드할 때 브랜치를 선택할 수 있습니다. 다음과 같이 Job에 매개변수를 추가합니다. 브랜치 이름을 선택할 수 있도록 선택 파라미터로 2개의 브랜치 이름을 추가하였습니다. Windows batch command에서는 %Parameter Name% 형식으로 사용할 수 있습니다. [소스 코드 관리] 항목에 사용자가 선택한 브랜치 이름을 적용합니다. 이제 빌드 후 메일 통보에 선택한 브랜치에 따라 설치 파일 이름을 다르게 나타나도록 합니다. Email Extension에 설치 파일 이름을 넘기기 위해 Environment variables through a file 플러그인을 사용하였습니다. PowerShell을 이용하여 propfile에 환경 변수를 쓰면 됩니다. BUILD_NAME, OUTPUT_FILE_NAME 두 개를 저장하였습니다. 환경 변수를 서로 다른 줄에 저장하기 위해 `r`n 을 넣어 줄 바꿈을 하였습니다. Out-File -FilePath .\propfile -InputObject "BUILD_NAME=$version`r`nOUTPUT_FILE_NAME=$env:BRANCH" -Encoding ASCII Email Exte...

데이터베이스를 읽어 DataTable을 만들고 DataTable에서 다시 클래스를 만드는 작업을 합니다. 이렇게 하는 이유는 DataTable은 Control에 바인딩하기 위해서고 클래스는 프로그램에서 사용하기 위함입니다. 이렇게 하기보다는 클래스가 최종 데이타이니 이걸 그냥 바인딩 시키면 안되나?하는 의구심이 들었습니다. List<EQStructure> Structures = new List<EQStructure>(); EQStructure를 List에 담아서 GridControl에 바인딩시키려고 하니 되지 않았습니다. 포기하지 않고 구글링을 해보니 BindingList를 만들어 사용하면 된다고 합니다. BindingList<EQStructure> Structures = new BindingList<EQStructure>(); BindingList는 List와 사용법이 유사하여 기존 코드에서 List로 사용하던 부분을 BindingList로 쉽게 변환할 수 있었습니다. 이렇게 데이터 바인딩을 사용하는 이점은 데이터 조작만으로 화면이 갱신된다는 점입니다. 즉 Control에 데이터를 바인딩시킨 후 데이터를 추가 혹은 삭제하면 Control이 자동으로 변경됩니다. 데이터를 모델 그리고 Control을 뷰라고 생각하면 됩니다. 제공되는 Control에 뷰에 필요한 행위가 다 구현되어 있기 때문에 우리는 모델만 신경 쓰면 됩니다. 신경 쓸 것이 하나 줄어들어 한결 마음이 편안해집니다.

그림책 속 수많은 사람들 중에서 월리를 찾는 것처럼 문서의 수많은 단어들 중에서 원하는 단어를 찾는 일은 쉬운 일이 아닙니다. 아니 월리를 찾는 것이 더 쉬울지도 모르겠습니다. 요즘 회사들 사이에 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의 도쿠위키 데이타가 모두 복원되었습니다.

파이프 랙을 생성하기 위해서 먼저 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의 축과 칼럼 위치 정보를 구하는 부분은 명료하고 군더더기가 없어 만족합니다. 코...

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 같은 곳에 켜놓으면 프로젝트 상황을 볼수 있어 더욱 효과적일것 같습니다.

고객사에서 일부 사용자에게서 프로그램 오류가 발생한다며 아래와 같이 에러 캡처를 보내왔습니다. 프로그램에서 로그를 남기기 위해 로그 파일을 생성하는데 권한의 문제로 로그 파일을 생성하지 못해 프로그램 오류가 발생한 것 같습니다. 처음에는 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를 이용하여 설치 파일을 만드는 과정은 아래와 같습니다. 첫 번째 폴더의 파일들을 읽어 기본이 되는 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 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 를 추가합니다.