지난번에 zsh을 꾸미고 나니, pwsh이 너무 허접해 보였다. 이런 것을 역체감이라고 하나. 어쩔 수 없지. 파워쉘도 꾸며줄 수 밖에.
+
+
+
oh-my-posh 설치
설치 자체는 어렵지 않고, 관련 정보도 검색으로 쉽게 찾을 수 있다. mac은 brew를 통해서, windows에서는 winget, choco, scoop등을 통해서 설치한다. 파워쉘 설정의 위치가 window와 macos가 서로 다르기 때문에 설치 스크립트에 약간 신경써줄 필요가 있음. 파워쉘의 $PROFILE 변수가 위치가 들어있으니까 파워쉘로 설치 동작을 작성해야 양쪽 os에 대응하기가 수월하다.
동일한 테마를 사용해 mac에서 설정해 주었는데도, 프롬프트의 모양이 다르다. os별로 각각 디자인이 되어 있는 듯. 지금 사용하는 테마는 atomic이다.
+
+
+
이미지에서 처음 프롬프트는 agnoster 테마를 쓰는 oh-my-zsh, 아래가 atomic mac 버전의 oh-my-posh이다.
+
윈도우 로고 출력하기
스크린샷에 있는 os 로고와 하드웨어 스펙 정보 출력을 위해 neofetch를 설치해 실행한다. 윈도우에서는 버전이 몇가지가 되는 듯 하고 각자 윈도우 로고 출력 모양이 다르다. 그 중에 scoop에서 설치하는 버전이 로고가 가장 예뻐서 이것으로 선택했다. 하지만 부팅 시간이 너무 오래 걸려서 평상시엔 비활성 해두었다.
github actions 그거 뭐 별거냐고 대수롭지 않게 생각했었다. 근데 조금 들여다보니 자유도가 꽤나 높아서, 사람들이 정말 다양하게 활용하고 있다는 것을 알고는 흥미가 생겼다.
+
+
+
MS Developer Korea에서 정리해둔 actions 소개 영상을 추천
+
CI/CD 그거 알지. 나도 해봤어. 울 회사에도 있어.
+
+
actions를 제대로 알아보기 전의 내가 딱 이 정도 생각이었다. 그냥 깃헙이 원래 코드 저장소를 제공하니까, 코드 올려둔 김에 빌드도 같이 돌리라고 추가기능 제공하는구나 하는 느낌. 지금 일단 업무적으로는 버전 관리를 git으로 하고 있지 않기 때문에 딱히 관심이 크지 않기도 했다.
+
최근에 토이 프로젝트를 다시 시작하면서 actions도 조금 알아보고 있다. 한국 ms에서 만든 youtube 영상에 기본 개념 설명이 아주 잘 되어있다. actions를 처음 알아보려는 사람이라면 정주행을 권한다. 영상을 보고 나면 workflow, job, step, action 각 단계별 구성을 빠르게 잡을 수 있고, 시리즈 후반부에는 actions를 빌드나 배포가 아닌 다른 용도로 활용하는 예제 2가지를 소개하고 있다.
main branch는 직접 commit하지 못하게 막아둔 채로 여러 사람이 협업할 때 github을 활용하는 방법을 볼 수 있다.
+
pull-request를 제출한 후, 다른 사람이 리뷰를 마치고 승인했을 때, actions를 이용해서 PR에 라벨을 붙이는 예제를 볼 수 있다. (4-2)
+
이슈가 많이 쌓여서 관리가 필요할 때, actions를 이용해서 (라벨을 붙이면) 댓글을 달고 이슈를 닫는 예제를 볼 수 있다. (4-3)
+
+
첫 번째 bullet에 적은 것처럼 main branch에는 보호 정책을 걸어두고 PR - review - Merge하는 흐름으로 협업하는 과정을 볼 수 있는 것도 흥미로웠다. git은 주로 개인 작업할 때 혼자서만 작업하다 보니까, commit하고 push하는거 말고는 다른 기능을 사용할 기회가 거의 없다. rebase, cherry-pick도 사용할 필요가 없어. 이 영상을 보고 branch protection rule을 어떻게 쓰는 건지 감을 잡았다.
+
workflow를 처음 적용하면서 헤맸던 삽질들
workflow의 문법이나 개념을 소개하기에는 이미 잘 정리된 자료들이 많이 있어서 굳이 여기에 반복할 필요는 없어 보인다. 이번에 nuget 패키지를 만들어 배포하는 workflow를 만들면서 뻘짓했던 요소들 간단히 몇가지만 정리해본다.
+
repository가 개인 계정의 것이 아니라 organization의 소유인 경우
packages에 파일을 올리려면 접근 권한이 필요하다. 개인 계정의 repo라면 developers settings > personal access tokens > tokens(classic)에서 발급하는 토큰을 이용하면 되는데, organization의 구성원들이 같이 공유할 수 있는 토큰 같은 개념은 없는 것 같다. 그냥 해당 repo에 접근 권한이 있는 개인이 발급한 personal token을 secret으로 등록해두고 같이 사용하게 하면 workflow를 실행하는 데에는 문제가 없다.
+
release를 만들려면 token 외에도 권한 지정이 필요하다
마켓플레이스에서 검색해보면 create release해주는 actions가 많이 있다. 내가 사용한 것은 ncipollo/release-action이고 readme의 예시에도 설명된 내용이긴 한데, job 레벨에서 권한 지정을 해주어야 한다.
검색하다보면 permissions 설정이 없는 yml 예시도 많이 있는데, 왠지 권한 지정 문법은 나중에 추가된 것이 아닌가 싶다. 그 전에 만들어진 workflow들은 권한 지정 없이도 실행이 됐던 것 같고. 이거 빼먹고 issue 게시판에 글 올리는 사람이 나 말고도 많음..
+
추가로 공부할 것
지금은 기본적인 nuget 패키지 배포 정도 구성해봤는데, 좀 더 익숙해지려면 다른 활용을 몇가지 더 만들어봐야 할 듯 하다. actions를 미리 알았으면 지난달에 만들었던 모바일 게임 랭킹 순위 크롤러도 깃헙에서 바로 실행/저장하게 만들었을텐데, 그걸 몰랐네. 이거 수정하면서 좀 더 다루어봐야겠다.
이제 닷넷의 GC는 꽤나 쓸만하게 발전하여, 웬만한 경우는 프로그래머가 메모리 관리를 굳이 신경쓰지 않고 코딩할 수 있게 도와준다. 그리고 그것이 C++ 대신 C#을 선택하는 큰 이유이기도 하다. 하지만 C# 게임서버로도 성능에 욕심을 내고자 한다면, 짧은 순간 대량의 TPS를 낼 수 있는 네트워크 IO를 구현하려고 한다면 어느정도 메모리 운용에 대한 이해가 필요하다.
-
이번 포스팅에서는 네트워크 IO의 부하가 가중될 때 겪을 수 있는 메모리 단편화 현상에 대해서 정리해본다.
+
모바일에서 볼 때 왼쪽같이 보이던 페이지를 오른쪽처럼 변경했다. 지금은 블록 여백 등도 조금 더 정리해서 일단락 지었다. 실제 페이지는 https://leafbird.github.io 에서 확인 가능하다.
프로그래밍에서 각 스레드별로 고유한 상태를 설정할 수 있는 공간을 Thread Local Storage (이하 TLS. transport layer security 아님) 라고 한다. VC++에서는 __declspec(thread) 키워드를 이용해서 tls 변수를 선언할 수 있다.
-
C#에도 ThreadLocal<T> 라는 클래스를 이용해 tls를 사용할 수 있지만, 막상 실제로 사용해보면 C++에서는 존재하지 않았던 큰 차이점이 있다. C# 5.0부터 들어온 async / await 문법을 이용해 비동기 프로그래밍을 구현했다면, await 대기 시점 이전과 이후에 스레드가 달라지기 때문이다.
-
이를 해결하는 방법과 주의해야 할 사항을 정리해본다.
+
+
+
아, 사람들이 왜 터미널을 예쁘게 꾸미는지 이제야 알았다. 코딩 뽕이 막 차오르네. 뭐라도 막 만들고 싶어진다.
2018년에 네트워크 레이어 성능을 끌어올리기 위해 도입했던 System.IO.Pipeline을 간단히 소개하고, 도입 후기를 적어본다.
-
윈도우 OS에서 고성능을 내기 위한 소켓 프로그래밍을 할 때 IOCP 의 사용은 오래도록 변하지 않는 정답의 자리를 유지하고 있다. 여기에서 좀 더 성능에 욕심을 내고자 한다면 Windows Server 2012부터 등장한 Registerd IO 라는 새로운 선택지가 있다. 하지만 API가 C++ 로만 열려 있어서, C# 구현에서는 사용하기가 쉽지 않다.
이제 닷넷의 GC는 꽤나 쓸만하게 발전하여, 웬만한 경우는 프로그래머가 메모리 관리를 굳이 신경쓰지 않고 코딩할 수 있게 도와준다. 그리고 그것이 C++ 대신 C#을 선택하는 큰 이유이기도 하다. 하지만 C# 게임서버로도 성능에 욕심을 내고자 한다면, 짧은 순간 대량의 TPS를 낼 수 있는 네트워크 IO를 구현하려고 한다면 어느정도 메모리 운용에 대한 이해가 필요하다.
+
이번 포스팅에서는 네트워크 IO의 부하가 가중될 때 겪을 수 있는 메모리 단편화 현상에 대해서 정리해본다.
C++에서 가장 기본적으로 사용했던 __FILE__, __LINE__, __FUNCTION__ 등의 매크로와 유사한 효과를 내는 방법에 대해 적어본다. 이와 함께 나에게는 생소했던 string interning 개념에 대해서도 살짝 소개해본다. 자바 같은 managed 언어를 깊이 다뤄본 적이 없는 네이티브 개발자에게는 생소한 개념일 것이다. UI가 없는 서버에서 동작의 내용을 확인하는 가장 기본적인 방법은 file로 남기는 log다. 정상 동작이나 오류상황에 대한 상세한 로그가 남아야 문제가 생겼을 때 파악하기가 쉽기 때문에, 간단한 동작이지만 아주 빈번하게 호출되는 부분이다. 로그 출력에서 성능을 많이 빼앗기지 않도록 기반을 다져놓으면 비즈니스 로직 구현을 위해 더 많은 H/W 리소스를 배분할 수 있다.
-
성능을 굳이 신경쓰지 않는다면 아래 있는 내용을 끝까지 모두 적용할 필요는 없다.
+
프로그래밍에서 각 스레드별로 고유한 상태를 설정할 수 있는 공간을 Thread Local Storage (이하 TLS. transport layer security 아님) 라고 한다. VC++에서는 __declspec(thread) 키워드를 이용해서 tls 변수를 선언할 수 있다.
+
C#에도 ThreadLocal<T> 라는 클래스를 이용해 tls를 사용할 수 있지만, 막상 실제로 사용해보면 C++에서는 존재하지 않았던 큰 차이점이 있다. C# 5.0부터 들어온 async / await 문법을 이용해 비동기 프로그래밍을 구현했다면, await 대기 시점 이전과 이후에 스레드가 달라지기 때문이다.
예전에 트위터 하다가 읽었던 글인데, 개인적으로 마음에 들어서 부족하게나마 번역해 보았습니다. 원문은 슬랙 개발 블로그의 Technical Leadership: Getting Started라는 글입니다. 번역에 크게 자신이 없으니 부담이 없으신 분들은 원문을 보셔요.
-
+
+
+
2018년에 네트워크 레이어 성능을 끌어올리기 위해 도입했던 System.IO.Pipeline을 간단히 소개하고, 도입 후기를 적어본다.
+
윈도우 OS에서 고성능을 내기 위한 소켓 프로그래밍을 할 때 IOCP 의 사용은 오래도록 변하지 않는 정답의 자리를 유지하고 있다. 여기에서 좀 더 성능에 욕심을 내고자 한다면 Windows Server 2012부터 등장한 Registerd IO 라는 새로운 선택지가 있다. 하지만 API가 C++ 로만 열려 있어서, C# 구현에서는 사용하기가 쉽지 않다.
팀에서 만지는 코드에서는, 290Mb에 육박하는 pch파일을 본 적이 있다(…) 그 땐 코드를 정리하면서 pch 사이즈 변화를 자주 확인해봐야 했는데, 탐색기나 커맨드 창에서 매번 사이즈를 조회하기가 불편했던 기억이 있어서 pch 사이즈 확인하는 걸 만들어봤다.
+
C++에서 가장 기본적으로 사용했던 __FILE__, __LINE__, __FUNCTION__ 등의 매크로와 유사한 효과를 내는 방법에 대해 적어본다. 이와 함께 나에게는 생소했던 string interning 개념에 대해서도 살짝 소개해본다. 자바 같은 managed 언어를 깊이 다뤄본 적이 없는 네이티브 개발자에게는 생소한 개념일 것이다. UI가 없는 서버에서 동작의 내용을 확인하는 가장 기본적인 방법은 file로 남기는 log다. 정상 동작이나 오류상황에 대한 상세한 로그가 남아야 문제가 생겼을 때 파악하기가 쉽기 때문에, 간단한 동작이지만 아주 빈번하게 호출되는 부분이다. 로그 출력에서 성능을 많이 빼앗기지 않도록 기반을 다져놓으면 비즈니스 로직 구현을 위해 더 많은 H/W 리소스를 배분할 수 있다.
개별 파일 하나씩을 컴파일 할 수 있다면 이제 모든 인클루드를 하나씩 삭제하면서 컴파일 가능 여부를 확인해보면 된다. 이 부분은 간단한 file seeking과 string 처리 작업일 뿐이니 굳이 부연 설명은 필요 없다. 카페에서 여유롭게 음악을 들으며 즐겁게 툴을 만들자. 뚝딱뚝딱.
-
이정도 하고 나니 이제 vcxproj파일 경로를 주면 해당 프로젝트에 들어있는 소스코드에서 불필요한 인클루드를 색출해 위치정보를 출력해주는 물건이 만들어졌다.
작업 대상으로 1개의 프로젝트가 입력 되었습니다. ------------------------------------------------- Service : 프로젝트 정리. Service : PCH 생성. 컴파일 : stdafx.cpp ... 성공. 걸린 시간 : 1.04초 Client.cpp의 인클루드를 검사합니다. - process #1 Client.cpp (1/2) ... X - process #1 Client.cpp (2/2) ... X ClientAcceptor.cpp의 인클루드를 검사합니다. - process #1 ClientAcceptor.cpp (1/2) ... 컴파일 가능! - process #1 ClientAcceptor.cpp (2/2) ... X ClientConnection.cpp의 인클루드를 검사합니다. - process #1 ClientConnection.cpp (1/3) ... X - process #1 ClientConnection.cpp (2/3) ... X - process #1 ClientConnection.cpp (3/3) ... X Start.cpp의 인클루드를 검사합니다. - process #1 Start.cpp (1/4) ... X - process #1 Start.cpp (2/4) ... X - process #1 Start.cpp (3/4) ... X - process #1 Start.cpp (4/4) ... X ThreadEntry.cpp의 인클루드를 검사합니다. - process #1 ThreadEntry.cpp (1/1) ... X ------------------------------------------------- Project : Service 모두 1개의 인클루드가 불필요한 것으로 의심됩니다. D:\Dev\uni\World\Service\ClientAcceptor.cpp - 2 line : #include "World/Service/Client.h"
총 소요 시간 : 13.289 sec
+
예전에 트위터 하다가 읽었던 글인데, 개인적으로 마음에 들어서 부족하게나마 번역해 보았습니다. 원문은 슬랙 개발 블로그의 Technical Leadership: Getting Started라는 글입니다. 번역에 크게 자신이 없으니 부담이 없으신 분들은 원문을 보셔요.
매우 느리게 찔끔찔끔 진행하는 토이 프로젝트가 있는데, 오늘 처음으로 무언가 그럴싸한 아웃풋이 나오게 되어 스냅샷을 하는 느낌으로 간단히 포스팅.
-
cpp 프로젝트 규모가 점점 커지게 되면 빌드 시간 때문에 많은 고통을 겪는다. 이때문에 increadi build 같은 분산 빌드 솔루션도 쓰는거고 unity build 같은 꼼수도 사용하게 되는거다.
-
하지만 저런 솔루션들을 사용하기 이전에, 코드를 정리하는 것이 먼저 선행될 필요가 있다. cpp는 특성상 작업하다보면 소스파일에 불필요한 헤더파일의 #include가 남게되고, 이것들이 불필요한 dependency를 만들어내면서 늘어지는 빌드 시간을 무시할 수 없기 때문이다.
-
그런데 문제는 그렇게 생긴 불필요 인클루드 구문이 무엇인지를 골라내기가 힘들다는 점이다. 프로젝트 규모가 커질수록 더욱 힘들다. c#같은 경우 불필요 using 구문을 아예 visual studio IDE가 자체적으로 정리해주기까지 하지만, cpp는 색출조차 힘들다 보니 이런 기능을 제공하는 3rd party tool도 없어 보인다. Whole Tomato의 Spaghetti 처럼 인클루드간의 관계를 그래프로 보여주는 툴은 몇 번 본 적 있다. 조낸 멋지게 그래프까지 보여주었지만 정작 불필요한 놈이 무언지 콕 짚어주는 녀석은 없음. 참으로 척박한 현실이다.
-
그래서 한 번 직접 만들어보기로 했다.
+
pch 파일 사이즈
팀에서 만지는 코드에서는, 290Mb에 육박하는 pch파일을 본 적이 있다(…) 그 땐 코드를 정리하면서 pch 사이즈 변화를 자주 확인해봐야 했는데, 탐색기나 커맨드 창에서 매번 사이즈를 조회하기가 불편했던 기억이 있어서 pch 사이즈 확인하는 걸 만들어봤다.
개별 파일 하나씩을 컴파일 할 수 있다면 이제 모든 인클루드를 하나씩 삭제하면서 컴파일 가능 여부를 확인해보면 된다. 이 부분은 간단한 file seeking과 string 처리 작업일 뿐이니 굳이 부연 설명은 필요 없다. 카페에서 여유롭게 음악을 들으며 즐겁게 툴을 만들자. 뚝딱뚝딱.
+
이정도 하고 나니 이제 vcxproj파일 경로를 주면 해당 프로젝트에 들어있는 소스코드에서 불필요한 인클루드를 색출해 위치정보를 출력해주는 물건이 만들어졌다.
작업 대상으로 1개의 프로젝트가 입력 되었습니다. ------------------------------------------------- Service : 프로젝트 정리. Service : PCH 생성. 컴파일 : stdafx.cpp ... 성공. 걸린 시간 : 1.04초 Client.cpp의 인클루드를 검사합니다. - process #1 Client.cpp (1/2) ... X - process #1 Client.cpp (2/2) ... X ClientAcceptor.cpp의 인클루드를 검사합니다. - process #1 ClientAcceptor.cpp (1/2) ... 컴파일 가능! - process #1 ClientAcceptor.cpp (2/2) ... X ClientConnection.cpp의 인클루드를 검사합니다. - process #1 ClientConnection.cpp (1/3) ... X - process #1 ClientConnection.cpp (2/3) ... X - process #1 ClientConnection.cpp (3/3) ... X Start.cpp의 인클루드를 검사합니다. - process #1 Start.cpp (1/4) ... X - process #1 Start.cpp (2/4) ... X - process #1 Start.cpp (3/4) ... X - process #1 Start.cpp (4/4) ... X ThreadEntry.cpp의 인클루드를 검사합니다. - process #1 ThreadEntry.cpp (1/1) ... X ------------------------------------------------- Project : Service 모두 1개의 인클루드가 불필요한 것으로 의심됩니다. D:\Dev\uni\World\Service\ClientAcceptor.cpp - 2 line : #include "World/Service/Client.h"
매우 느리게 찔끔찔끔 진행하는 토이 프로젝트가 있는데, 오늘 처음으로 무언가 그럴싸한 아웃풋이 나오게 되어 스냅샷을 하는 느낌으로 간단히 포스팅.
+
cpp 프로젝트 규모가 점점 커지게 되면 빌드 시간 때문에 많은 고통을 겪는다. 이때문에 increadi build 같은 분산 빌드 솔루션도 쓰는거고 unity build 같은 꼼수도 사용하게 되는거다.
+
하지만 저런 솔루션들을 사용하기 이전에, 코드를 정리하는 것이 먼저 선행될 필요가 있다. cpp는 특성상 작업하다보면 소스파일에 불필요한 헤더파일의 #include가 남게되고, 이것들이 불필요한 dependency를 만들어내면서 늘어지는 빌드 시간을 무시할 수 없기 때문이다.
+
그런데 문제는 그렇게 생긴 불필요 인클루드 구문이 무엇인지를 골라내기가 힘들다는 점이다. 프로젝트 규모가 커질수록 더욱 힘들다. c#같은 경우 불필요 using 구문을 아예 visual studio IDE가 자체적으로 정리해주기까지 하지만, cpp는 색출조차 힘들다 보니 이런 기능을 제공하는 3rd party tool도 없어 보인다. Whole Tomato의 Spaghetti 처럼 인클루드간의 관계를 그래프로 보여주는 툴은 몇 번 본 적 있다. 조낸 멋지게 그래프까지 보여주었지만 정작 불필요한 놈이 무언지 콕 짚어주는 녀석은 없음. 참으로 척박한 현실이다.
diff --git a/rss2.xml b/rss2.xml
index 8c0b9858..313b2994 100644
--- a/rss2.xml
+++ b/rss2.xml
@@ -9,9 +9,61 @@
- Sun, 15 Oct 2023 01:14:03 GMT
+ Sun, 12 Nov 2023 01:00:58 GMThttp://hexo.io/
+
+ 처음으로 접한 깃헙 액션
+ http://leafbird.github.io/devnote/2023/11/09/%EC%B2%98%EC%9D%8C%EC%9C%BC%EB%A1%9C-%EC%A0%91%ED%95%9C-%EA%B9%83%ED%97%99-%EC%95%A1%EC%85%98/
+ http://leafbird.github.io/devnote/2023/11/09/%EC%B2%98%EC%9D%8C%EC%9C%BC%EB%A1%9C-%EC%A0%91%ED%95%9C-%EA%B9%83%ED%97%99-%EC%95%A1%EC%85%98/
+ Thu, 09 Nov 2023 04:38:49 GMT
+
+ <img src="/devnote/2023/11/09/%EC%B2%98%EC%9D%8C%EC%9C%BC%EB%A1%9C-%EC%A0%91%ED%95%9C-%EA%B9%83%ED%97%99-%EC%95%A1%EC%85%98/actions-graph.png" class="">
+
+<p>github actions 그거 뭐 별거냐고 대수롭지 않게 생각했었다.<br>근데 조금 들여다보니 자유도가 꽤나 높아서, 사람들이 정말 다양하게 활용하고 있다는 것을 알고는 흥미가 생겼다.</p>
+
+
+
+
github actions 그거 뭐 별거냐고 대수롭지 않게 생각했었다. 근데 조금 들여다보니 자유도가 꽤나 높아서, 사람들이 정말 다양하게 활용하고 있다는 것을 알고는 흥미가 생겼다.
MS Developer Korea에서 정리해둔 actions 소개 영상을 추천
CI/CD 그거 알지. 나도 해봤어. 울 회사에도 있어.
actions를 제대로 알아보기 전의 내가 딱 이 정도 생각이었다. 그냥 깃헙이 원래 코드 저장소를 제공하니까, 코드 올려둔 김에 빌드도 같이 돌리라고 추가기능 제공하는구나 하는 느낌. 지금 일단 업무적으로는 버전 관리를 git으로 하고 있지 않기 때문에 딱히 관심이 크지 않기도 했다.
최근에 토이 프로젝트를 다시 시작하면서 actions도 조금 알아보고 있다. 한국 ms에서 만든 youtube 영상에 기본 개념 설명이 아주 잘 되어있다. actions를 처음 알아보려는 사람이라면 정주행을 권한다. 영상을 보고 나면 workflow, job, step, action 각 단계별 구성을 빠르게 잡을 수 있고, 시리즈 후반부에는 actions를 빌드나 배포가 아닌 다른 용도로 활용하는 예제 2가지를 소개하고 있다.
main branch는 직접 commit하지 못하게 막아둔 채로 여러 사람이 협업할 때 github을 활용하는 방법을 볼 수 있다.
pull-request를 제출한 후, 다른 사람이 리뷰를 마치고 승인했을 때, actions를 이용해서 PR에 라벨을 붙이는 예제를 볼 수 있다. (4-2)
이슈가 많이 쌓여서 관리가 필요할 때, actions를 이용해서 (라벨을 붙이면) 댓글을 달고 이슈를 닫는 예제를 볼 수 있다. (4-3)
첫 번째 bullet에 적은 것처럼 main branch에는 보호 정책을 걸어두고 PR - review - Merge하는 흐름으로 협업하는 과정을 볼 수 있는 것도 흥미로웠다. git은 주로 개인 작업할 때 혼자서만 작업하다 보니까, commit하고 push하는거 말고는 다른 기능을 사용할 기회가 거의 없다. rebase, cherry-pick도 사용할 필요가 없어. 이 영상을 보고 branch protection rule을 어떻게 쓰는 건지 감을 잡았다.
workflow를 처음 적용하면서 헤맸던 삽질들
workflow의 문법이나 개념을 소개하기에는 이미 잘 정리된 자료들이 많이 있어서 굳이 여기에 반복할 필요는 없어 보인다. 이번에 nuget 패키지를 만들어 배포하는 workflow를 만들면서 뻘짓했던 요소들 간단히 몇가지만 정리해본다.
repository가 개인 계정의 것이 아니라 organization의 소유인 경우
packages에 파일을 올리려면 접근 권한이 필요하다. 개인 계정의 repo라면 developers settings > personal access tokens > tokens(classic)에서 발급하는 토큰을 이용하면 되는데, organization의 구성원들이 같이 공유할 수 있는 토큰 같은 개념은 없는 것 같다. 그냥 해당 repo에 접근 권한이 있는 개인이 발급한 personal token을 secret으로 등록해두고 같이 사용하게 하면 workflow를 실행하는 데에는 문제가 없다.
release를 만들려면 token 외에도 권한 지정이 필요하다
마켓플레이스에서 검색해보면 create release해주는 actions가 많이 있다. 내가 사용한 것은 ncipollo/release-action이고 readme의 예시에도 설명된 내용이긴 한데, job 레벨에서 권한 지정을 해주어야 한다.
검색하다보면 permissions 설정이 없는 yml 예시도 많이 있는데, 왠지 권한 지정 문법은 나중에 추가된 것이 아닌가 싶다. 그 전에 만들어진 workflow들은 권한 지정 없이도 실행이 됐던 것 같고. 이거 빼먹고 issue 게시판에 글 올리는 사람이 나 말고도 많음..
추가로 공부할 것
지금은 기본적인 nuget 패키지 배포 정도 구성해봤는데, 좀 더 익숙해지려면 다른 활용을 몇가지 더 만들어봐야 할 듯 하다. actions를 미리 알았으면 지난달에 만들었던 모바일 게임 랭킹 순위 크롤러도 깃헙에서 바로 실행/저장하게 만들었을텐데, 그걸 몰랐네. 이거 수정하면서 좀 더 다루어봐야겠다.
]]>
+
+
+
+ github
+
+ workflow
+
+ actions
+
+
+ http://leafbird.github.io/devnote/2023/11/09/%EC%B2%98%EC%9D%8C%EC%9C%BC%EB%A1%9C-%EC%A0%91%ED%95%9C-%EA%B9%83%ED%97%99-%EC%95%A1%EC%85%98/#disqus_thread
+
+
+
+
+ oh-my-posh로 파워쉘 꾸미기
+ http://leafbird.github.io/devnote/2023/10/19/oh-my-posh%EB%A1%9C-%ED%8C%8C%EC%9B%8C%EC%89%98-%EA%BE%B8%EB%AF%B8%EA%B8%B0/
+ http://leafbird.github.io/devnote/2023/10/19/oh-my-posh%EB%A1%9C-%ED%8C%8C%EC%9B%8C%EC%89%98-%EA%BE%B8%EB%AF%B8%EA%B8%B0/
+ Wed, 18 Oct 2023 23:54:03 GMT
+
+ <img src="/devnote/2023/10/19/oh-my-posh%EB%A1%9C-%ED%8C%8C%EC%9B%8C%EC%89%98-%EA%BE%B8%EB%AF%B8%EA%B8%B0/win_terminal.png" class="">
+
+<p>지난번에 zsh을 꾸미고 나니, pwsh이 너무 허접해 보였다. 이런 것을 역체감이라고 하나.<br>어쩔 수 없지. 파워쉘도 꾸며줄 수 밖에.</p>
+
+
+
+
지난번에 zsh을 꾸미고 나니, pwsh이 너무 허접해 보였다. 이런 것을 역체감이라고 하나. 어쩔 수 없지. 파워쉘도 꾸며줄 수 밖에.
oh-my-posh 설치
설치 자체는 어렵지 않고, 관련 정보도 검색으로 쉽게 찾을 수 있다. mac은 brew를 통해서, windows에서는 winget, choco, scoop등을 통해서 설치한다. 파워쉘 설정의 위치가 window와 macos가 서로 다르기 때문에 설치 스크립트에 약간 신경써줄 필요가 있음. 파워쉘의 $PROFILE 변수가 위치가 들어있으니까 파워쉘로 설치 동작을 작성해야 양쪽 os에 대응하기가 수월하다.
동일한 테마를 사용해 mac에서 설정해 주었는데도, 프롬프트의 모양이 다르다. os별로 각각 디자인이 되어 있는 듯. 지금 사용하는 테마는 atomic이다.
이미지에서 처음 프롬프트는 agnoster 테마를 쓰는 oh-my-zsh, 아래가 atomic mac 버전의 oh-my-posh이다.
윈도우 로고 출력하기
스크린샷에 있는 os 로고와 하드웨어 스펙 정보 출력을 위해 neofetch를 설치해 실행한다. 윈도우에서는 버전이 몇가지가 되는 듯 하고 각자 윈도우 로고 출력 모양이 다르다. 그 중에 scoop에서 설치하는 버전이 로고가 가장 예뻐서 이것으로 선택했다. 하지만 부팅 시간이 너무 오래 걸려서 평상시엔 비활성 해두었다.
+
+
+
+
+
+
+
+
+ 
+ 
+ 
+ 
+