![\"임시명세서의](\"/img/bidrum/janggu_patent_figure_old.png\")
당근마켓에서 복합기를 샀다.
\nCUPS 서버를 구축해 프린터를 공유하고 테스트 페이지를 인쇄했는데 인쇄가 모노크롬(회색조)으로만 인쇄됐다. 왜일까...
\n열심히 검색하면서 찾아본 결과 CUPS에서 프린터를 추가할 때 회색조 인쇄를 기본값으로 하는 버그가 있어서 그렇다.
\n아래 명령어에서 PRINTER 부분만 프린터 이름으로 바꿔서 실행하면 된다.
\nsudo lpadmin -p PRINTER -o print-color-mode-default=color끝~
\nRPG Maker MV로 제작된 게임을 리눅스에서 wine으로 실행했는 데 자꾸 로딩에서 걸렸다.
\n그냥 Windows를 가상 머신으로 깔까 고민하던 와중 nwjs.dll을 발견했다. 게임 www 폴더 내 package.json의 구조도 nwjs 어플리케이션의 package.json과 유사했다.
그러면 그냥 리눅스용 nwjs 바이너리를 받아서 직접 실행하면 되지 않을까? 실제로 해본 결과 매우 잘 됐다. 그냥 nwjs 바이너리를 받아서 직접 실행하면 된다.
\nwww 폴더를 찾는다.www 폴더를 1번에서 받은 nwjs 바이너리로 실행시키면 된다. (e.g. ~/nwjs-binary/nwjs ~/game/www)이러면 실행이 매우 잘 된다. 게임에 따라서 안 될 수도 있긴 한데... 나는 잘 됐다.
\n끝
\n", "url": "https://blog.litehell.info/post/how_to_run_rpg_maker_mv_on_linux", "title": "Linux에서 RPG Maker MV로 제작된 게임 실행하기", "summary": "wine으로 실행이 잘 안 될 때", "image": "https://gravatar.com/avatar/837266b567b50fd59e72428220bf69b1", "date_modified": "2025-02-18T11:02:55.344Z" }, { "id": "retrospective_of_representative_2023", "content_html": "본래 2023년 말에서 2024년 초 사이에 게시할 주제였으나 필자가 게으른 관계로 퇴고가 계속 늦어졌다. 그렇게 계속 미루다가 2025년 초가 되어서야 간략하게나마 초안을 마치게 됐다. 그러나 초안을 한 번 읽어보니 이 글이 공개되면 중앙대학교 학생사회를 뒤집고, 또한 얽히고설킨 사람들의 신의를 잃을 것 같다는 생각이 들었다. 민감한 내용이 너무 많은데 이 내용을 모두 검열하면 남는 내용이 없다. 따라서 결국 글을 공개하지 않기로 결정했다. 추후 시간이 좀 많이 흐르면 공개할 수도 있겠지만 적어도 지금은 아니다.
\n혹여 이 글을 기대하신 분들이 계시다면 심심한 양해를 구한다.
\n", "url": "https://blog.litehell.info/post/retrospective_of_representative_2023", "title": "학생자치 후기", "summary": "동아리연합회 분과장 임기를 마치며", "image": "https://gravatar.com/avatar/837266b567b50fd59e72428220bf69b1", "date_modified": "2025-01-31T10:58:09.183Z" }, { "id": "my_first_patent", "content_html": "많은 사람들은 특허 출원과 특허 등록의 차이를 모른다. 회사 입학 원서를 예시로 들자면, 삼성전자 공채에 원서를 내는 걸 특허 "출원"이라고 하고, 삼성전자 공채에 최종합격하는 것을 특허 "등록"이라고 한다.
\n2024-1학기 캡스톤디자인 프로젝트를 하면서 프로포절 발표할 때 특허 출원을 넣으면 입 털기 좋을 것 같다는 생각이 들었다. 그래서 장구 컨트롤러 프로토타입을 기반으로 특허를 출원했다.
\n특허를 출원하려면 특허고객번호가 필요하다. 특허고객등록을 하면 된다. 쉽게 할 수 있다.
\n특허 출원은 의외로 어렵지 않다. 특허는 가출원할 수 있다. 대충 휘갈겨 쓴 임시명세서로 가출원하면 특허출원번호가 바로 나온다. 청년이면 출원료 85% 감면도 해준다.
\n일단 캡스톤디자인 프로포절과 프로포절 발표에서 입을 터는 게 목표였기에 출원번호를 얻는 게 중요했다. 그래서 마크다운으로 대충 쓰고 PDF로 바꿔서 제출했다. 내용은 다른 명세서의 목차를 참고해 나름 특허명세서의 구조를 갖추려 노력했다.
\n
위는 임시명세서에 넣었던 도식이다. draw.io로 그리다가 짜증나서 그림판(Krita나 GIMP 둘 중 하나인데 정확히는 기억나지 않는다.)으로 휙휙 그렸다.
\n대충 쓴 임시명세서를 특허청에서 제공한 전자출원프로그램으로 출원했다. 전자출원은 무조건 윈도우에서만 가능하며(리눅스 wine 시도시 오류남), 공인인증서가 반드시 필요하다. 본인이 윈도우를 끔찍이 싫어하는 자유 소프트웨어 원리주의자라면 우편으로 출원하면 되긴 한데, 나는 그렇게까지 하고 싶진 않아서 그냥 VM에 윈도우 설치하고 전자출원했다.
\n덧붙여서, 공개되는 특허서류에 주소가 공개되는 데 이게 싫은 사람은 특허청 홈페이지에서 주소가 구 단위까지 공개되도록 바꿀 수 있다. 참고하도록 하자.
\n특허는 명세서가 가장 중요하다. 명세서를 제대로 쓰려면 변리사를 고용해야 하는데 변리사를 고용하는 건 비싸다. 대학생이 이용할 수 있는 변리사 무료지원 사업은 크게 다음 세가지가 있다.
\n공익변리사센터는 학과장 확인서를 받아야해서 귀찮고, 공익상담은 방문하려니 가기가 귀찮고 전화로 하려니 설명하다가 열불이 터질 것 같다는 생각이 들었다. 그래서 공익변리사센터의 서류작성지원 사업을 이용했다. 공익변리사센터에서 제시하는 양식을 다 채우고 필자가 작성했던 임시명세서를 추가로 제출했다.
\n![\"공익변리사센터로부터](\"/img/bidrum/pcc_accepted_sms.jpg\")
지원사업에 선정되면 위와 같이 문자가 온다. 변리사님께서 제출한 서류를 읽다가 이해가 안되면 전화를 해서 물어볼 수 있다. 친절히 답해주면 된다. 명세서는 선정 후 2~3개월 정도 기다리면 이메일로 받을 수 있다.
\n![\"정식명세서의](\"/img/bidrum/janggu_patent_figure_new.png\")
변리사님이 써준 정식명세서는 위와 같이 변리사 사무소에서 그림을 깔끔하게 다시 그려준다. 분량도 31페이지 정도로 굉장히 상세하게 써주신다. (참고로 본인이 쓴 임시명세서는 6페이지였다.)
\n임시출원된 특허를 정식출원된 특허로 바꾸는 방법은 다음 두가지 방법이 있다.
\n두번째 방법의 존재를 몰라서 첫번째 방법으로 할 생각이었는데 공익변리사센터에서 배정받은 변리사님과 통화하던 중 여쭤보니 두번째 방법으로 하는 게 좋을 것 같다는 답변을 들었다. (모든 경우에 그런 건 아니고 특허 케이스마다 다를 것이다. 내 경우에는 그랬다.) 그래서 기존특허를 근거로 우선권주장하여 정식명세서로 출원했다.
\n이제 기다리기만 하면 된다. 순번 기다리는데 최소 1년 반 정도 걸린다. 운 좋으면 한번에 통과되고 운 안 좋으면 의견제출통지서가 날라온다. 지금도 기다리고 있는데 한번에 통과될 지 안 될지는 잘 모르겠다.
\n특허를 "출원하는 것" 자체는 쉽다. 근데 등록되는 건 어렵다. 출원은 그리 어렵지 않으니 여러분도 특허를 한번 출원해보면 좋을 것 같다.
\n프로포절 발표에서 입 털려고 출원한 거였는데 청자들에게 큰 영향이 있었는 지는 잘 모르겠다.
\n아래 문단은 내가 특허명세서 쓸 때 작성한 리듬게임의 정의의 초안이다.
\n\n\n"리듬게임"은 조작 지시가 음악의 흐름에 따라 제시되고, 이용자는 지시에 따라 입력장치(예: 키보드, 마우스, 악기를 모방한 입력장치, 발로 누르는 버튼, 버튼, 터치스크린 등)를 조작하며, 최대한 많은 조작 지시를 정해진 타이밍에 최대한 근접한 시간에 수행하는 것을 목표로 하는 게임을 의미한다. 그리고 "아케이드 리듬게임"은 리듬게임 중 일정한 장소에서 일정한 시설을 갖추고 제공되는 게임을 의미한다.
\n
위 정의를 변리사님이 살짝 수정하고 교정한 최종 버전은 다음과 같다.
\n\n\n리듬 게임이란, 조작 지시가 음악의 흐름에 따라 제시되고, 사용자는 지시에 따라 입력 장치(예: 키보드, 마우스, 악기를 모방한 입력 장치, 발로 누르는 버튼, 버튼, 터치스크린 등)를 조작하며, 최대한 많은 조작 지시를 정해진 타이밍에 성공시키는 것을 목표로 하는 게임을 의미한다. 그리고 아케이드 리듬 게임이란 리듬 게임 중에서도 일정한 장소(예: 오락실)에서 일정한 시설을 갖추고 제공되는 게임을 의미한다.
\n
혹여나 다른 사람에게 도움이 될까싶은 마음에 적어둔다. 누군가에게 도움이 됐으면 좋겠다.
\n", "url": "https://blog.litehell.info/post/my_first_patent", "title": "내 첫 특허 출원기", "summary": "출원과 등록은 엄연히 다르다구요!", "image": "https://blog.litehell.info/img/bidrum/janggu_patent_figure_old.png", "date_modified": "2025-01-29T08:01:46.305Z" }, { "id": "caucalendar_in_serverless", "content_html": "학사일정/RSS/시간표 미리보기 서비스의 공통점은 크롤링 서비스이다. 학사일정 서비스의 특정을 요약하면 다음과 같다.
\nfrom 매개변수와 to 매개변수를 지원해야 하므로 백엔드가 불가피하다. (예시: /cau.ics?from=2019)다른 서비스의 특징은 다음과 같다.
\n이 글의 시점은 2024년 초이다.
\n그렇다면 크롤링 부분만 AWS Lambda 함수로 분리하면 매우 단순한 구조의 서비스이지 않은가?\n따라서 다음과 같이 중앙대학교 학사일정 서비스를 재구성했다.
\n![\"calendar.puang.network의](\"/img/caucalendar/caucalendar_serverless.png\")
다른 서비스는 백엔드 자체가 필요없으므로 더 단순하다. 강의시간표 미리보기 서비스와 중앙대학교 RSS 서비스의 서버리스 구조도는 다음과 같다.
\n![\"pre-timetable.puang.network와](\"/img/caucalendar/others_serverless.png\")
원래 스크린샷 하나하나 찍어가며 상사하게 쓸 생각이었는데 귀찮아진 관계로 대충 글로 정리한다.
\n참 쉽죠?
\n위와 같이 서버리스 서비스를 구축하여 월1000~1500원 정도의 비용으로 서비스를 운영하고 있다.
\n원래 글을 작년에 쓸 계획이었는데 미루고 미루다보니 1년이 지났다... 이제 글도 썼으니 동아리나 다른 후배에게 서비스를 인수인계할 계획이다.
\n", "url": "https://blog.litehell.info/post/caucalendar_in_serverless", "title": "학사일정 ICS 서비스 개발기 (下)", "summary": "Go와 함께 서버리스로", "image": "https://blog.litehell.info/img/caucalendar/caucalendar_serverless.png", "date_modified": "2025-01-29T07:54:49.043Z" }, { "id": "retrospective_of_2024", "content_html": "올해는 뭔가 많은 일이 있었다.... 되게 바빴지만 동시에 많은 것들을 이루어낸 해이기도 했다. 회고를 쓰면서 지난날들을 되돌아보려 한다.
\n하반기에는 인턴십을 하고 학업을 마무리했다.
\n중앙대학교 현장실습지원센터를 통해 여러 인턴십에 지원했다. LG CNS 채용 연계형 인턴십과 카카오 채용 연계형 겨울 인턴십, 그리고 주식회사 슈르의 산학연계 인턴십에 지원했다.
\nLG CNS 채용 전형은 서류, 코딩테스트, 2:2 비대면 면접 순으로 진행됐고, 카카오 채용 전형은 서류, 코딩테스트, 3:1 대면 면접으로 진행됐다. 둘 다 면접까지는 갔으나 아쉽게도 불합격했다. LG CNS는 같이 면접 본 다른 지원자분께서 스펙이 너무나 뛰어났고, 카카오 인턴십은 면접이 서툴러서 잘못 본 것이 원인인 것 같다. 카카오는 대면면접을 볼 때 대기실이 따로 있고, 면접비로 50,000원 상당의 카카오페이포인트와 춘식이 핫팩을 주는 점이 좋았다.
\n주식회사 슈르는 중앙대학교 현장실습 통합관리 시스템을 통해 지원했다. 전형은 서류, 1:1 비대면 면접 순으로 진행됐다. 면접은 웹과 관련된 기술면접으로만 이루어졌다. 회사가 가산디지털단지역에 있어서 학교 기숙사에서 출퇴근하기 매우 편했고, 사람들이 되게 좋았다. 출퇴근은 자유로운 편이었으며, 휴가 사용은 완전히 자유로웠다. 포괄임금제이지만, 초과근무시 그에 상응하는 보상휴가를 지급해준다.
\n회사에서는 고인물테스트의 프론트엔드를 개발했다. 그때 회사에 나를 포함하여 인턴이 3명 있었는데, 내가 백엔드를 하면 다른 분께서 프론트 개발하는 데 우여곡절이 많을 것 같아서 그냥 내가 프론트엔드를 맡았다.
\n처음 회사 직원분께서 사이트가 매우 간단할 것으로 예측하고 그냥 HTML + CSS + Javascript 조합으로 빠르게 만들자고 제안하셨다. 초반 기획서도 그렇게 거창하지 않았기에 알겠다고 하고 HTML + CSS + Javascript 조합으로 만들었다. 그러나 기획서가 가면 갈수록 수정되면서 복잡해졌고, 이에 나는 개발 편의성을 위해 Javascript 코드를 Typescript 코드로 재작성하고 Webpack을 이용한 빌드 시스템을 구축했다.
\n가장 인상 깊었던 것은 좌우 무한 스크롤링을 구현하라는 요구사항이었다. 처음에는 웹브라우저에서 제공하는 스크롤바를 최대한 활용하려 했는데 사파리에서 자꾸만 버그가 나서 결국 그냥 바퀴를 재발명했다. 마우스랑 터치 이벤트를 받아 이동량을 계산하고 계산한 값에 따라 requestAnimationFrame으로 자식 요소의 위치를 이동시킴으로써 스크롤링을 직접 구현했다. 가장 하기 싫은 방법이었지만 결국 어쩔 수 없었다. 사소한 버그는 있었지만, 나름 그럴싸하게 동작했다. (이에 대해서는 추후 별도의 글로 쓸 예정)
학교 프로젝트에서 디자이너나 기획자랑 협업할 일이 없었는데 회사에서 처음으로 기획자, 디자이너, 실무자와 같이 협업했다. 그 과정에서 슬랙이랑 노션도 적극적으로 써보고 스타트업이 어떻게 돌아가는지에 대해 많은 걸 배울 수 있어 좋은 경험이었다.
\n2024-1학기에는 정보보호이론, 네트워크응용설계, 신호및시스템, 데이타베이스시스템, 캡스톤디자인(2)를 수강했다. 임베디드 관련 과목을 듣고 싶었는데 담당 교수님이 안식년인지라 어쩔 수 없이 신호및시스템을 대신 수강하게 됐다.
\n정보보호이론은 DES, AES, RSA, ElGamel와 같은 암호에 관한 내용을 배웠다, 한 번 제대로 배워보고 싶었던 내용이라서 재밌었다. 네트워크응용설계는 네트워크 레이어 3~7을 Top-down으로 배운다. 데이타베이스시스템은 DB 시스템의 내부구조에 대해 가르친다. 신호및시스템은 푸리에 변환에 대해 맛보기로 가르쳐준다. 모두 다 좋은 내용이어서 만족스러웠다.
\n중앙대학교는 캡스톤디자인을 2번 해야 한다. 2023-2학기에는 알고모여를 했었고 (관련 글) 이제 2024-1학기에도 프로젝트를 해야 했다.
\n팀 인원은 다행스럽게도 2023-2학기의 구성 그대로 가기로 결정돼서 주제만 빠르게 결정되면 됐다. 이때 리듬 게임을 만들 것을 다시 한번 더 제안했다. 말로만 제안하면 또 반대를 받을 게 예상돼서 이번에는 프로토타입을 미리 만들어 팀원들을 설득했다. 프로토타입에 관한 이야기는 이 글을 참고하라.
\n주제부터 결과물까지 모든 것이 어그로였다. (중앙대에서 졸업작품으로 아케이드 리듬 게임을 하는 용자는 매우 드물다) 그래서 이왕 어그로 끄는 김에 최종 발표도 어그로로 하기로 했다. 한솜미술센터에서 사물놀이복을 빌려서 최종 발표를 했다. 결과는 매우 성공적이었고 웃음을 참지 못하던 조교의 표정을 아직도 잊을 수가 없다.
\n상반기에는 본격적인 사회인이 됐다.
\n하계방학에 인턴십을 진행한 주식회사 슈르에 정규직으로 입사하게 됐다. 내가 학업에 열중하는 동안 회사는 여러 우여곡절을 겪으며 체계가 더 단단해졌다. 회사에서 개발하는 이커머스 서비스의 백오피스 프론트엔드 개발을 주로 맡았었다. 스타트업 기업에서 근무하면서 스타트업이 어떻게 돌아가는 지를 인턴으로 근무할 때보다 더 자세히 알 수 있었다. 다른 현직 개발자와 협업도 처음으로 해봤지만, 개인적으로 시간에 쫓겨 개발하느라 기술적인 성장을 많이 이루지 못한 것 같다. 그와는 별개로 Firebase를 본격적으로 처음 써봤는데 꽤 편리해서 좋았었다.
\n되게 열심히 일했다. 학교로 졸업사진 찍으러 가다 회사에 큰 일 터져서 바로 헐레벌떡 회사로 달려가 고쳐도 보고... 여러 추억을 쌓았다.
\n슈르를 다니다가 더 좋은 직장에서 더 높은 연봉의 오퍼를 받아 이직하게 됐다. 아직 모든 것이 낯설고 앞으로 내가 잘할 수 있는지 두렵지만 어찌 됐든 잘 적응해서 어서 빨리 성취를 이루고 싶다.
\n직장을 옮기니 집과 직장 사이의 거리가 더 멀어져 결국 자취를 하게 됐다. 수도권 집값 너무 비싸서 볼 때마다 아깝다는 생각이 들지만, 그래도 어쩔 수 없다. 집값도 비싸면서 이상한 집은 얼마나 많은지... 그래도 자취를 하니 직장까지 가기가 너무 편해서 만족스럽다. 특히 자취를 한 번도 안 했다가 이제서야 진정한 프라이버시를 얻게 된 점이 너무 좋다.
\n지인으로부터 안 쓰는 데스크톱 본체를 얻게 됐다. 이 본체에 Proxmox를 설치해 개인 서버를 구축했다. 이제 NAS를 설치하려고 이것저것 알아보고 있는데 TrueNAS는 제대로 쓰려면 하드웨어 패스쓰루를 해야 한다고 해서 내키지 않고, openmediavault는 웹 파일 브라우저 UI가 뭔가 마음이 들지 않아서... 그냥 내가 직접 만들까도 생각하고 있다.
\n개인적으로 고대역폭 Tor 릴레이를 구축해보고 싶다. 그래서 KINX에 관련 문의를 해봤는데 추후 견적이 어떻게 나오는가에 따라서 안 할 수도 있다.
\n나무위키의 초반기 역사에 대한 책을 쓰고 싶어서 올해 중반쯤에 프로젝트를 결성했는데, 바쁘게 살다 보니 그 새 까먹어서 이제서야 본격적인 시동을 걸게 됐다. 사람들이 슬슬 기억이 안 나기 시작해서 원할하게 될지는 모르겠지만, 어쨌든 잘 이루어졌으면 좋겠다.
\n아직 못 쓴 글들은 다음과 같다. 학생자치후기는 특성상 검열이 많이 될 수 있어서 재미가 없을 수도 있다.
\n아랫글들은 잠깐 쓰다 말았는데 완성 안 하고 그냥 삭제할 수도 있다.
\n아랫글은 쓰다 말았는데 타이밍을 놓쳐서 그냥 삭제할 계획이다.
\n이제 연말이 얼마 남지 않았다. 다음 해에는 다들 즐거운 일만이 있기를!
\n", "url": "https://blog.litehell.info/post/retrospective_of_2024", "title": "2024년의 회고", "summary": "졸업과 취업", "image": "https://gravatar.com/avatar/837266b567b50fd59e72428220bf69b1", "date_modified": "2024-12-27T10:41:06.311Z" }, { "id": "caucalendar_1", "content_html": "나는 캘린더 앱을 적극적으로 활용한다. 시간이나 약속을 머릿속으로만 관리하면 잘 잊어버리기 때문에 캘린더 앱을 적극적으로 활용하고 있다.
\n그렇게 캘린더 앱을 적극적으로 쓰다가 대학교에 입학했다. 시험기간이나 수강정정기간 같은 것도 캘린더 앱에 뜨면 좋겠는데 이걸 직접 추가하는 건 귀찮았다. 그래서 중앙대학교 학사일정 페이지를 크롤링하는 어플리케이션을 작성했다. 그리고 캘린더 앱과 내 어플리케이션을 연동하는 데에는 iCalendar 파일 포맷을 이용했다.
\nGoogle Calendar나 MS Outlook, 혹은 필자가 이용하는 FastMail에서는 캘린더 기능을 제공한다. 이 캘린더 서비스들은 기본적으로 특정한 iCalendar 주소를 구독하는 기능을 지원한다. 즉, 다시 말해 필자가 구글 캘린더나 아웃룩에 iCalendar 파일 주소를 추가하면, 구글 캘린더나 아웃룩 서버가 주기적으로 iCalendar 주소에 접속해 동기화한다.
\niCalendar 파일은 다음과 같은 형식으로 되어있다.
\nBEGIN:VCALENDAR\nVERSION:2.0\nTIMEZONE-ID:Asia/Seoul\nX-WR-TIMEZONE:Asia/Seoul\nX-WR-CALNAME:중앙대학교 학사일정\nX-WR-CALDESC:calendar.puang.network에서 제공하는 중앙대학교 학사일정\nCALSCALE:GREGORIAN\nPRODID:adamgibbons/ics\nMETHOD:PUBLISH\nX-PUBLISHED-TTL:PT1H\nBEGIN:VTIMEZONE\nTZID:Asia/Seoul\nTZURL:http://tzurl.org/zoneinfo-outlook/Asia/Seoul\nX-LIC-LOCATION:Asia/Seoul\nBEGIN:STANDARD\nTZOFFSETFROM:+0900\nTZOFFSETTO:+0900\nTZNAME:KST\nDTSTART:19700101T000000\nEND:STANDARD\nEND:VTIMEZONE\nBEGIN:VEVENT\nUID:552361268d864ef42fff1bee5d295e073f7ab2b2@calendar.puang.network\nSUMMARY:신정(공휴일)\nDTSTAMP:20240825T081930Z\nDTSTART;TZID=Asia/Seoul;VALUE=DATE:20220101\nEND:VEVENT\nBEGIN:VEVENT\nUID:eb57cfcaf7345c4ad83d1e7537dd81016db2d8a7@calendar.puang.network\nSUMMARY:2022년 1학기 재입학 원서접수\nDTSTAMP:20240825T081930Z\nDTSTART;TZID=Asia/Seoul;VALUE=DATE:20220103\nDTEND;TZID=Asia/Seoul;VALUE=DATE:20220107\nEND:VEVENT\nEND:VCALENDAR위와 같은 식으로 iCalendar 아이템(VCALENDAR) 속에 여러 일정(VEVENT)들이 나열되어 있다. iCalendar 형식은 할일(VTODO)이나 일기(VJOURNAL)도 지원하지만 이 글에서는 다루지 않는다.
첫 버전은 Koa 프레임워크를 이용하여 간단하게 작성했다. 원래 이전에는 express를 썼었는데, express는 async 함수 핸들러가 바로 지원되지 않아서 약간 귀찮다는 단점이 있었기에 Koa 프레임워크를 이용했다.
이 프로그램에서 중요한 것은 iCalendar 파일을 제공하는 것이다. 따라서 그 외의 요소는 모두 부수적인 것이다. 그렇기에 프론트엔드는 다음과 같이 디자인이 극단적으로 되어있어도 상관없었다. (사진은 첫 커밋 버전의 메인 페이지이다.)
\n![\"첫](\"/img/puang_network/caucalendar_first_commit_html.png\")
다만 그래도 위처럼 만드는 건 좀 심하니 bulma CSS 프레임워크를 이용해 아래와 같이 간단히 꾸몄다.
\n![\"bulma](\"/img/puang_network/caucalendar_bulma_frontend.png\")
이때가 2019년 5~6월쯤이였다. 이때의 구조도는 다음과 같다.
\n![\"서비스](\"/img/puang_network/caucalendar_vps_nodejs.png\")
당시 가상서버에서는 여러 웹서비스가 구동되고 있었기에, Host를 확인하여 알맞은 웹서비스로 트래픽을 전달해야 했다. 따라서 Nginx로 리버스 프록시가 동작하고 있었다.
\n위 사진에서 PM2는 프로세스가 꺼지면 다시 켜주는 역할을 한다. 리브레위키의 리버티엔진에서 쓰길래 써봤다.
\n초기에는 크롤링을 분리하기 귀찮아서, 그냥 요청이 들어올 때마다 학교 홈페이지에 접속해 학사일정 iCalendar 파일(이하 "ics 파일")을 제공했다. 그랬더니 어느순간 학교에서 서버 ip를 차단했다. 이게 2019년 11월 쯤의 일이였다.
\n그래서 크롤링하는 코드를 별도의 파일로 분리하고, crontab을 이용해 크롤링 스크립트가 주기적으로 실행되게 했다. 크롤링된 데이터는 Sequelize ORM을 이용해 저장했다.
\n학사일정 서비스에 버그가 생겼다고 캘린더 앱에서 잘 보이던 일정이 갑자기 사라지진 않는다. 그래서 동작에 이상이 생겨도 기존에 쓰던 사람들은 티가 잘 안난다.
\n그래서 동작이 정상적으로 이루어지는 지 주기적으로 확인하기 위해 다음과 같이 GitHub Action을 추가했다.\n푸시나 커밋시가 아닌 특정 주기에 따라 반복되는 GitHub CI로 테스트가 주기적으로 이루어지도록 했다.
\n따라서 이를 통해 학교 홈페이지의 갑작스런 디자인/API 변경에도 대응할 수 있었다.
\nname: Build and test\n\non:\n schedule:\n - cron: '0 19 * * *'\n push:\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v3\n\n - name: Build\n run: docker build --target test .푸시나 커밋시가 아닌 cron으로 GitHub CI를 추가하여 학교 홈페이지의 갑작스런 디자인/API 변경에도 대응할 수 있도록 했다.
\n개인서버에서 돌아가던 서비스들을 다 도커 컨테이너에 감싸는 작업을 했었다. 그때 학사일정 ics 서비스도 도커 컨테이너로 감쌌다. crontab을 이용해 따로 돌아가던 크롤링 스크립트는 어플리케이션에 다시 집어넣어서, 어플리케이션 실행시 크롤링이 자동으로 주기적으로 실행되도록 수정했다. Docker에서 crontab을 쓰려면 약간 귀찮기 때문이다.
\n처음에는 node:14 도커 이미지를 기반으로 썼는데 값싼 가상서버에서 쓰기에는 디스크를 너무 많이 차지했다. 그래서 나중에 Alpine Linux 기반 도커를 기반으로 바꿨다. Alpine Linux 기반 이미지를 쓰니 디스크 소비량을 줄일 수 있었다. 이때가 2021년 2~3월인가 그랬을 것이다.
그렇게 Javascript로 작성해서 잘 쓰다가 문득 이런 생각이 들었다. 'Go를 쓰면 더 빠르지 않을까?' Javascript는 인터프리터 언어이고, Go는 컴파일 언어이니, 알고리즘의 효율성이 유사하다는 가정하에 Go가 더 빠를 수도 있지 않을까란 생각이 들었다. 물론 Go 언어를 한 번 써보고 싶은 생각도 없진 않았다.
\n그래서 Go 언어로 학사일정 서비스를 재작성했다. 크롤러는 다음과 같이 고루틴을 이용하여 비동기적으로 동시에 구동되도록 했다.
\npackage main\n\nimport "time"\n\nfunc crawlWorker() {\n for {\n time.Sleep(time.Hour * 1)\n fetchAllYears()\n }\n}\n\nfunc setupCrawller() {\n go crawlWorker()\n}DigiCert CA 인증서와 관련된 문제가 있어 해당 CA 인증서를 추가하여 문제를 해결했었다. 물론 HTTP 요청시 인증서 오류를 모두 무시하도록 하는 방법도 있지만, 그 방법은 보안이 취약해지기에 채택하지 않았다.
\n다만 이렇게 CA 인증서를 추가하는 식으로 해결할 시에는 go test -v 명령어만으로 테스트를 할 수 없다는 문제점이 있었다. 그래서 Docker를 테스트에도 활용할 수 있도록 다음과 같이 Dockerfile을 수정했다.
FROM golang:alpine AS base\n\nWORKDIR /app\n\n# To avoid tls error from swedu.cau.ac.kr\nCOPY digicert-ca.pem /usr/local/share/ca-certificates/digicert-ca.crt\nRUN cat /usr/local/share/ca-certificates/digicert-ca.crt >> /etc/ssl/certs/ca-certificates.crt\n\nCOPY go.mod go.sum ./\nRUN go mod download && go mod verify\n\nCOPY static ./static\nCOPY *.go ./\n\nFROM base AS deployment\nRUN go build -v -o /app/app\nCMD ["/app/app"]\n\nFROM base As test\n\nRUN go test -v ./...위와 같이 만들어서 굴리다가 추후 AWS Lambda 함수를 이용한 서버리스로 재작성했다. 이에 대해선 다음 글에서 이어서 작성하도록 하겠다.
\n", "url": "https://blog.litehell.info/post/caucalendar_1", "title": "학사일정 ICS 서비스 개발기 (上)", "summary": "Javascript랑 함께 Docker로", "image": "https://blog.litehell.info/img/puang_network/caucalendar_first_commit_html.png", "date_modified": "2024-09-15T13:06:50.914Z" }, { "id": "bidrum_on_rust", "content_html": "※ 참고: 이 시리즈의 글은 시간순 작성을 최대한 목표하고 있으나, 글의 짜임새나 가독성을 위해 미리시점이나 과거시점의 이야기가 섞이거나 순서가 일부 달라질 수 있습니다.
\n내가 만들고 싶은 게임은 아케이드 리듬게임이였다. 마침 내 방에 라즈베리 파이(4B Rev 1.2)가 있어서, 라즈베리 파이로 게임을 구동하고 싶었다. Unity나 Unreal Engine으로 만든 게임이 라즈베리 파이 위에서 돌아갈까? 아마도 돌아가지 않을 것이다. 실제로 돌려본 적은 없지만 라즈베리 파이가 성능이 좋은 편은 아니니까.
\n그래서 필자는 마침 Rust 프로그래밍 언어를 한 번 써보고 싶은 생각도 있었기에, Rust로 직접 게임을 만들어보기로 결심했다. 게임 엔진을 쓰면 나중에 게임이 유명해졌을 때 라이선스비를 내야 한다는 것도 하나의 이유였다. (좀 과한 김칫국이긴 하지만...) 그래서 유니티니 언리얼이니 하는 게임 엔진을 쓰지 않고 Rust로 기초부터 쌓아올리기 시작했다.
\nRust에는 rust-sdl2라는 라이브러리 바인딩이 있다. SDL2는 오디오, 키보드, 마우스, 그래픽, 조이스틱을 다를 수 있게 하는 크로스플랫폼 라이브러리이다. 즉, 그래픽이나 마우스 등에 대한 Direct3D/OpenGL 등의 운영체제/플랫폼 종속적인 API를 추상화하고 단일한 인터페이스로 통일하여 크로스 플랫폼으로 개발할 수 있게 하는 라이브러리이다.
\n따라서 SDL2를 이용하면 Mac OS X/Windows/Linux에서 크로스플랫폼으로 실행할 수 있고, 라이브러리도 별로 무겁지 않다. 그래서 SDL2를 이용하게 됐다.
\nSDL2는 rust-sdl 레포 내의 예제 코드를 보면서 따라하면 사용하기 쉽다. SDL2는 먼저 Window(창)을 만든 뒤, Window의 Canvas에 원하는 것을 그리고 렌더링하고 클리어하는 것을 반복한다. 이를 순서대로 나타내면 다음과 같다.
\n\n\n(A) Window 생성 → (B) Window의 Canvas를 Clear한다 → (C) Canvas에 뭔가를 그린다. → (D) Window의 Canvas를 Present한다. → (E) 화면이 표시한다. → (F) B로 되돌아간다.
\n
학부 수준의 컴퓨터그래픽스 수업을 들었거나 OpenGL 프로그래밍을 조금이라도 맛보았다면 매우 이해하기 쉬울 것이다.
\nSDL2는 키보드나 조이스틱 인식을 위한 EventPump 기능을 제공한다. 키보드 인풋이 들어오면 EventPump에 Event가 생성된다. 게임은 이 EventPump에 Event가 있는지 확인하여 만약 Event가 있다면 해당 Event의 데이터를 활용해 키보드 인풋을 처리할 수 있다. 게임 특성상 이 EventPump은 디버깅 용으로만 주로 이용됐다.
\n위에서 언급한 바에 같이 그래픽을 렌더링하기 위해서는 Canvas 객체에 대한 접근이 필요하다. 그래서 초기 게임 초기화시 Canvas와 Window, SDL Context 등을 담은 GameCommonContext 객체를 만들고 이를 함수간에 서로 주고받는 형태로 빠르게 게임을 구현했다.
\nuse kira::manager::AudioManager;\nuse sdl2::{render::Canvas, EventPump, video::Window};\n\npub(crate) struct GameCommonContext {\n pub(crate) coins: u32,\n pub(crate) price: u32,\n pub(crate) sdl_context: sdl2::Sdl,\n pub(crate) audio_manager: AudioManager,\n pub(crate) canvas: Canvas<Window>,\n pub(crate) event_pump: EventPump,\n}(속성은 나중에 게임이 개발되면 될 수록 더 늘어난다.)
\n그리고 이는 추후 대규모 리팩토링으로 Rust의 특징을 온몸으로 깨닫는 계기가 됐다.... 나중에 소유권이랑 lifetime 문제가 미친 듯이 터져나와서 그거 씨름하느라 엄청 고생하게 됐다.
\n게임을 장구 하드웨어와 연동하기 위해서는 시리얼 통신이 필요하다.
\nArduino Leonardo 등 HID 에뮬레이션을 지원하는 보드가 있으면 장구 하드웨어에서 키보드 인풋을 주도록 할 수도 있다. 그런데 당장 내 방에 있는 게 Arduino UNO 호환보드(흔히 "짭두이노"라고 불리는 보드)밖에 없었다. 그래서 시리얼 통신으로 구현했다. 나중의 미래에 레오나르도 보드를 사서 키보드 인풋으로도 구현해보긴 했는데.... 딱따구리마냥 장구 채를 갖다대기만 해도 장구 채를 미친듯이 연타한 것마냥 동작하는 버그가 있어서 그냥 시리얼 통신을 계속 쓰게 됐다.
\nRust에서는 시리얼 통신을 어떻게 할까? 고맙게도 serialport라는 라이브러리가 있다. 이를 이용해 장구 하드웨어와의 시리얼 통신 코드를 작성했다. 그리고 장구 하드웨어로부터 인풋을 읽는 코드를 멀티쓰레딩으로 분리하고 AtomicU8을 이용하여 게임 쓰레드와 인풋 쓰레드 간에 장구 인풋 상태를 서로 공유했다.
왜 뜬끔없이 AtomicU8이냐? 장구 컨트롤러의 상태를 나타내는 데에는 4개의 비트만 있으면 충분하다. 그래서 컨트롤러는 1바이트의 데이터를 무한히 연속적으로 보낸다. 이 1바이트를 해석하는 코드는 다음과 같다.
pub(crate) fn parse_janggu_bits(bits: u8) -> JangguState {\n JangguState {\n 궁채: if bits & 1 != 0 {\n Some(DrumPane::채편)\n } else if bits & 2 != 0 {\n Some(DrumPane::북편)\n } else {\n None\n },\n 북채: if bits & 4 != 0 {\n Some(DrumPane::채편)\n } else if bits & 8 != 0 {\n Some(DrumPane::북편)\n } else {\n None\n },\n }\n}장구 컨트롤러와 연동하는 쓰레드는 컨트롤러로부터 시리얼 통신으로 받은 데이터를 바로 GameCommonContext 개체의 janggu_bits_ptr 필드에 저장한다.
// ... (생략) ....\n\npub(crate) struct GameCommonContext {\n // ... (생략) ...\n pub(crate) janggu_bits_ptr: Arc<AtomicU8>,\n}\n\nimpl GameCommonContext {\n pub(crate) fn read_janggu_state(&self) -> JangguState {\n return parse_janggu_bits(\n self.janggu_bits_ptr\n .load(std::sync::atomic::Ordering::Relaxed),\n );\n }\n}\n게임 쓰레드에서 장구의 상태를 확인할 때는 read_janggu_state 메소드를 이용한다.
추후 미래에 AtomicU8을 없애고 Product-Consumer Lock으로 JangguState 객체를 직접 공유해보기도 했는데, 렉이 너무 심해서 그냥 AtomicU8을 계속 쓰게 됐다.
Rust를 이용한 게임 개발은 초창기에는 할만했는데 뒤로 갈수록 어려웠다. 소유권, 대여, lifetime 문제를 해결하느라 골머리를 참 많이 썩었다. 그래서 결론적으로 짧은 기간 안에 게임을 개발해야 한다면 Rust는 별로 좋은 선택이 아니지 않을까라는 생각이 들었다.
\n", "url": "https://blog.litehell.info/post/bidrum_on_rust", "title": "Rust와 SDL2", "summary": "게임 개발에 Rust를 써보셨나요?", "image": "https://gravatar.com/avatar/837266b567b50fd59e72428220bf69b1", "date_modified": "2024-08-11T14:35:24.968Z" }, { "id": "bidrum_and_janggu_controller_prototyping", "content_html": "문득 장구를 이용한 리듬 게임을 만들고 싶었다. 태고의 달인도 있는데 장구의 달인이 안 될 이유가 있을까? 그래서 군대 있을 때 계속 장구 게임을 상상만 하다가 복학하고 3학년 2학기에 캡스톤디자인 과목을 듣게 됐다.
\n3학년 2학기 캡스톤디자인 과목에서 게임 아이디어를 제시했지만, 다른 팀원들은 리스크가 너무 크다고 반대했다. 지금 막 개강했는데 하드웨어 개발부터 시작하면 십중팔구 프로젝트가 망할 것이라는 지적이였다. 반박하기에는 너무나도 맞는 말이였다. 그래서 그냥 받아들이고 "알고모여"라는 웹 어플리케이션 프로젝트를 하게 됐다. 의외로 교수님의 평가가 계속 호평이여서 손쉽게 A+를 받았다.
\n중앙대학교는 캡스톤디자인을 2번 해야 졸업이 가능하다. 그래서 4학년 1학기에도 캡스톤디자인을 해야 했는데, 이때 게임 아이디어를 다시 꺼내고 싶었다. 그러나 하드웨어도 없이 빈손으로 아이디어를 꺼낸다면 또다시 팀원들로부터 리스크 우려를 받을 것 같았다. 그래서 일단 프로토타이핑을 해서 설득해야 되겠단 판단이 들었다. 판단이 이루어졌으면 바로 실천해야 하지 않겠는가? 바로 당근마켓으로 45,000원짜리 어린이 장구를 샀고, 곧이어 아두이노랑 쿠킹호일, 그리고 몇가지 부품을 구매했다.
\n내가 만드는 게임은 단순히 타격 여부만을 인식하지 않는다. "어떤 채로 어떤 면이 타격됐는가"를 인식한다. 즉, 다시 말해 열편으로 궁편을 친다면 "궁편이 타격됐다"라는 정보가 아닌 "열편으로 궁편이 타격됐다"라는 정보가 인식된다.
\n이를 구현하려면 채에도 센서가 있어야 된다. 그리고 이 센서는 게임 본체랑 연결되어야 한다. 어떻게 연결한 것인가? 무선과 유선 두가지 방법이 있다.
\n무선과 유선 각 두 가지 방법의 장단점은 다음과 같다.
\n| \n | 무선 | \n유선 | \n
|---|---|---|
| 장점 | \n선이 걸리지 않음 | \n정확도가 매우 높고 딜레이가 낮음 | \n
| 단점 | \n너무 낮은 정확도 및 높은 딜레이 | \n선이 걸리적거림 | \n
무선 통신은 정확도가 너무 낮다는 단점이 있다. 무선으로 채의 위치를 측정한다고 가정해보자. Inpixion의 자료에서의 무선 위치 측정 시스템의 정확도와 레어턴시는 다음과 같다.
\n| \n | UWB | \nChirp (CSS) | \nBLE | \nWi-Fi | \n
|---|---|---|---|---|
| 정확도 | \n10~50 cm | \n1~2m | \n< 5 m | \n10 m | \n
| 레이턴시 | \n< 1 ms | \n< 1 ms | \n3~5s | \n3~5s | \n
정확도가 너무 낮아서 무선 위치 측정 시스템은 쓸 수가 없다. 블루투스와 와이파이는 레이턴시때문에 리듬게임 컨트롤러로 쓸 수조차 없다.
\n'그렇다면 무선이되 다른 방법을 쓰면 되는 것 아닌가?'라는 생각이 들 수도 있는데, 내 머리로는 그렇게 할 수 있는 방법이 딱히 떠오르지 않았다. 그래서 그냥 유선으로 연결하기로 하고, 걸리적거리는 문제는 나중에 해결하기로 했다.
\n자, 이제 유선으로 채의 종류를 인식하기로 했다. 장구는 두 개의 채와 두 개의 접촉면이 있다. 이 경우 가능한 경우의 수는 총 몇 가지인가? 답은 아래 표에서 볼 수 있듯 9가지이다. 두 개의 채로 하나의 접촉면을 동시에 치는 경우(아래 표에서 5번, 9번)도 고려해야 하므로 9가지이다.
\n| \n | 궁채 | \n북채 | \n
|---|---|---|
| 1 | \nX | \nX | \n
| 2 | \n궁면 | \nX | \n
| 3 | \n북면 | \nX | \n
| 4 | \nX | \n궁면 | \n
| 5 | \n궁면 | \n궁면 | \n
| 6 | \n북면 | \n궁면 | \n
| 7 | \nX | \n북면 | \n
| 8 | \n궁면 | \n북면 | \n
| 9 | \n북면 | \n북면 | \n
전기는 색깔이 없다. 접촉면에서 흐르는 전기가 궁채에서 흐르는 전기인지 북채에서 흐르는 전기인지 알 수 없다. 그렇다면 접촉면에 닿은 채가 어떤 채인지 어떻게 구분해야 할까? 필자는 FDM(주파수 분할)과 TDM(시분할)을 생각했다. 처음엔 FDM을 생각했었는데, 아두이노로 구현하기에는 난이도가 높을 것 같아 비교적 구현이 손쉬운 TDM으로 결정했다.
\n시분할 알고리즘은 매우 단순하다.
\n이를 도식도로 나타내면 다음과 같다.
\n![\"알고리즘의](\"/img/bidrum/controller-algorithm.png\")
위를 실제 회로로 구현하기 위해서는 특정 회로를 신호로 열거나 닫을 수 있어야 한다.
\n특정 회로를 신호로 열거나 닫는 대표적인 부품은 릴레이이다. 릴레이는 일종의 스위치 역할을 하는 부품으로, 전자석을 이용하여 회로를 열거나 닫는다.
\n![\"아두이노](\"/img/bidrum/relay.jpg\")
매우 직관적이고 만들기 쉬워서 처음에 릴레이를 시도했었다. 그러나 문제가 있었다. 릴레이는 딜레이가 너무 크고(5ms) 결정적으로 딱따구리 같은 소음이 난다. 위 알고리즘을 빠르게 무한반복해야 하는 특성상 릴레이 열고닫기를 반복하니 전자석 딱딱거리는 소리가 무한히 들리는 것이었다.
\n그래서 주변 분들의 조언을 받아 트랜지스터를 이용했다. 주변 분께 딜레이가 1ms이하인 릴레이가 있나고 여쭤보니, 그 분께서 그런 릴레이는 없으니 트랜지스터를 쓰라고 답변해주신 것이 큰 도움이 됐다. 트랜지스터는 라디오 만들 때나(증폭) 쓰는 건 줄 알았는데 검색해보니 트랜지스터도 스위치처럼 쓸 수 있음을 알게 됐다.
\nNPN 트랜지스터와 저항으로 약간의 시행착오를 겪으니 잘 인식됐다. 트랜지스터를 이용한 회로는 아래와 같다.
\n![\"트랜지스터를](\"/img/bidrum/janggu_prototype_circuit_1.png\")
위 회로에서 궁채, 열채, 북편, 채편 기호는 각각의 부위에 붙은 전도체를 의미한다.
\n전기가 흘려야 하니 채와 접촉면에는 전도체 물질을 부착해야 한다. 뭘 붙일까 고민하다가 펌프 발판을 수작업으로 제작할 때 은박지를 이용했다는 글이 생각났다. 그래서 다이소에서 쿠킹호일을 사다가 붙였다. 내구성은 썩 좋은 것 같진 않았지만 꽤 잘 인식됐다.
\n![\"장구](\"/img/bidrum/janggu_prototype_1.jpg\")
사진은 위와 같다. 사진에는 보이지 않지만, 장구의 면에도 은박지가 부착되어 있다.
\n쿠킹호일과 NPN 트랜지스터, 저항, 그리고 아두이노를 이용해 장구 컨트롤러를 만들었다. 내구성은 썩 좋지 않았지만 인식은 잘 됐다. 2023년 겨울방학의 일이었다.
\n", "url": "https://blog.litehell.info/post/bidrum_and_janggu_controller_prototyping", "title": "쿠킹호일과 트랜지스터로 리듬게임 컨트롤러 만들기", "summary": "학교 캡스톤디자인 작품으로 장구 리듬게임 만든 이야기", "image": "https://blog.litehell.info/img/bidrum/controller-algorithm.png", "date_modified": "2024-07-19T12:53:12.021Z" }, { "id": "show_all_slides_of_pptx_and_convert_to_pdf_batch_operation", "content_html": "이번 학기에 데이터베이스시스템 과목을 수강하게 됐다. 이 과목의 강의자료는 교재 홈페이지에서 제공하는 pptx 파일을 이용하는데, 숨김 처리된 슬라이드도 모두 활용한다. 따라서 숨겨진 슬라이드를 모두 숨김 해제해야 했다.
\n파일이 한두개면 그냥 직접 숨겨진 슬라이드를 숨김 해제하면 된다. 하지만 강의가 시작되는 Chapter 12이후의 파일은 약 20개 정도였다. 물론 그 pptx들을 다 강의하진 않겠지만, 한두개의 파일이 아닐 것임은 확실했다.
\n이걸 어떻게 하면 일괄처리할 수 있을까?
\npptx 파일은 zip 파일이다. pptx파일을 압축 프로그램을 열면 다음과 같은 구조를 볼 수 있다.
\n![\"pptx파일을](\"/img/show_all_slides_of_pptx_and_convert_to_pdf_batch_operation/pptx_zip_structure.png\")
ppt/slides 디렉토리 내의 xml 파일들이 슬라이드를 나타내는 xml 파일이다. 숨김 처리된 슬라이드의 xml 파일을 보면 다음과 같이 루트 요소의 show 속성이 0으로 설정되어 있음을 확인할 수 있다.
![\"숨겨진](\"/img/show_all_slides_of_pptx_and_convert_to_pdf_batch_operation/hidden_slide_xml.png\")
그렇다면 ppt/slides 디렉토리 내의 xml 파일의 루트 요소에서 show 속성만 제거하면 되지 않을까?
python을 이용하면 기본으로 제공되는 라이브러리만으로 간단히 해결할 수 있다.
\n#!/bin/python3\nimport re\nfrom os import listdir\nfrom os.path import isfile, join\nfrom zipfile import ZipFile\nimport xml.etree.ElementTree as ET\n\npptx_dir = "."\n# pptx_dir 디렉토리 내에서 파일명이 .pptx로 끝나는 파일의 목록을 가져온다.\npptx_files = [f for f in listdir(pptx_dir) if isfile(join(pptx_dir, f)) and f.endswith(".pptx")]\n# ppt/slides/*.xml 패턴을 검사하기 위한 정규표현식\nslide_xml_filename_pattern = re.compile("ppt/slides/[^/]+\\\\.xml")\n\nfor pptx_file in pptx_files:\n print("Processing pptx %s " % pptx_file)\n # pptx파일을 zip 파일로 연다.\n with ZipFile(pptx_file, 'a') as zipfile:\n # ppt/slides/*.xml 형태의 파일 목록을 가져온다.\n slide_xml_filenames = [i for i in zipfile.namelist() if not slide_xml_filename_pattern.fullmatch(i) is None]\n for slide_xml_filename in slide_xml_filenames:\n print("Processing xml %s" % slide_xml_filename)\n xml = None\n # xml을 파싱한다.\n with zipfile.open(slide_xml_filename, mode = 'r') as file:\n xml = ET.parse(file)\n # 루트 요소에 show 속성이 있다면 제거한다.\n if "show" in xml.getroot().attrib:\n xml.getroot().attrib.pop("show")\n # 수정된 xml을 pptx 파일 내에 쓴다.\n with zipfile.open(slide_xml_filename, mode = 'w') as file:\n xml.write(file)위 스크립트는 디렉토리내의 pptx 파일을 열고, pptx 파일 내에서 파일명이 ppt/slides/*.xml 형태인 파일을 xml로 파상한 뒤, 루트 요소에서 show 속성을 삭제하고 다시 쓰는 것을 일괄 반복하는 스크립트이다.
사용 시에는 pptx_dir 변수값만 필요에 따라 수정하여 쓰면 된다. 위 스크립트를 실행하면 pptx_dir 변수에 설정된 디렉토리 내에 있는 pptx 파일들에서 숨김 처리된 슬라이드를 모두 숨김 해제한다.
필자는 OneNote를 쓰는데 OneNote는 인쇄물 삽입을 pdf나 docx로만 해야한다. 따라서 모든 pptx를 pdf로 변환할 필요가 있다.
\n이건 쉽다. 그냥 LibreOffice 명령어 한 줄이면 끝난다.
\nlibreoffice --headless --convert-to pdf *.pptx이상으로 여러개의 pptx 파일에서 숨김 처리된 슬라이드를 모두 일괄 숨김 해제하고 pdf로 일괄 변환하는 방법에 대해 알아보았다.
\n다른 사람들에게 도움이 됐으면 좋겠다.
\n", "url": "https://blog.litehell.info/post/show_all_slides_of_pptx_and_convert_to_pdf_batch_operation", "title": "PPTX 파일 모든 슬라이드 숨김 해제하고 PDF 변환 일괄 작업하기", "summary": "Python과 LibreOffice를 이용한 pptx 일괄 처리", "image": "https://blog.litehell.info/img/show_all_slides_of_pptx_and_convert_to_pdf_batch_operation/pptx_zip_structure.png", "date_modified": "2024-03-06T08:33:00.099Z" } ] }