nomad-programmer

x64dbg는 OllyDbg의 확장버전 개념의 디버거이다. 한글 지원과 다양한 플러그인들을 사용할 수 있다. https://x64dbg.com/# x64dbg Built on open-source libraries x64dbg uses Qt, TitanEngine, Zydis, Yara, Scylla, Jansson, lz4, XEDParse, asmjit and snowman. x64dbg.com https://x64dbg.com/blog/ x64dbg · Official x64dbg blog! 25 Feb 2018, by ViRb3 [This post was written by ViRb3, if you want to post on this blog you can! Go here for more inf..

OllyDbg란? OllyDbg는 윈도우용 어셈블러를 분석할 수 있는 디버거다. OllyDbg는 직관적인 사용자 화면을 제공하며 무료로 사용할 수 잇고 다양한 플러그인을 통해 기능을 확장할 수 있다. 현재 버전 2.01까지 제공 중이며 64비트 환경을 지원하기 위한 프로그램이 개발중이다. http://www.ollydbg.de/ OllyDbg v1.10 www.ollydbg.de OllyDbg는 프레임, 메뉴 바, 퀵 링크, 뷰 영역, 상태 바 이렇게 5개의 영역으로 구성된다. 프레임은 OllyDbg의 외부 골격을 형성하고 있으며 현재 어떤 프로그램의 무슨 모듈을 디버깅하고 있는지 표시하고 있다. 메뉴 바는 OllyDbg에서 제공하는 기능을 모두 담고 있다. 파일 다루기, 분석 화면에 대한 설명, 트레이..

OSX에서 주피터 랩을 자동 시작하려면 애플 스크립트를 만들어 서비스를 띄우는 방식으로 해야 한다. // 런치 에이젼트로 이동 cd ~/Library/LaunchAgents // 파일 생성 touch com.jupyter.server.plist 생성한 파일의 내용은 아래의 코드로 채운다. 그 후, 시스템에 로드 시키면 재부팅 할 때마다 자동으로 주피터랩 서버가 실행된다. // 로드 launchctl load ~/Library/LaunchAgents/com.jupyter.server.plist Jupyter 암호 설정 생성한 암호를 ~/.jupyter/jupyter_notebook_config.py 의 c.NotebookApp.password 에 넣는다. // 만약 ~/.jupyter/jupyter_not..

OSX에서 brew로 Qt5설치 brew install qt5 brew install Caskroom/cask/qt-creator // Qt Creator 실행 후 Qt Creator - Preferences - Kits - Qt Versions - Add - (Macintosh HD클릭 후 "Command + Shift + .[숨김파일 보여주는 단축키]") - /usr/local/Cellar/qt/5.13.2/bin/qmake

// home brew로 go 설치 brew install go // .bashrc나 .zshrc에 환경변수 설정 export GOPATH="${HOME}/.go" export GOROOT="$(brew --prefix golang)/libexec" export PATH="$PATH:${GOPATH}/bin:${GOROOT}/bin" // godoc 설치 go get golang.org/x/tools/cmd/godoc // golint 설치 go get github.com/golang/lint/golint 만약 VSCode를 쓴다면 아래의 Go Extension 설치 https://marketplace.visualstudio.com/items?itemName=ms-vscode.Go Go - Visual ..

conda environment 이름 변경 conda env 에는 rename이라는 것이 없다. 그래서 새로운 이름의 env를 생성하면서 기존에 존재하는 env를 복사해야 한다. // 아나콘다 env 리스트 conda env list // 바꾸려는 env name으로 생성하면서 기존에 존재하던 env 복사 conda create --name --clone // 기존에 존재하던 env 삭제 conda remove --name --all

GitHub 문서 작성의 표준이라고 할 수 있는 마크다운 작성 규칙. 문단 구분을 위한 강제 개행 일반적인 문단 작성은 그냥 텍스트를 입력하면 된다. 문단을 구별하러면 한 개 이상의 빈 줄을 문단 사이에 삽입하거나 줄의 마지막에 [Space Bar]를 두 번 이상 눌러 띄어쓰기하면 된다. 헤더 '# 헤더 이름' 식으로 작성하면 된다. #을 1개부터 6개까지 총 6단계로 쓸 수 있다. 인용 상자 > 내용 형식으로 인용 상자를 작성할 수 있다. 빈 줄이 나오기 전까지의 내용이 인용 상자 안에 포함된다. 목록 기본적인 리스트 작성 방법은 다음과 같다. 무순서 목록을 만드는 것이다. 세 가지 중 어떤 방법을 사용하든 상관없다. * 목록이름 - 목록이름 + 목록이름 순서가 있는 목록을 만들려면 다음과 같은 방식으..

모든 프로젝트 소스를 공개할 수는 없는 법이다. 그러므로 팀 프로젝트를 언제나 GitHub에서만 진행할 수는 없다. 물론 돈을 내고 비공개 저장소를 만드는 방법도 있지만 Git자체는 오픈 소스 프로젝트이므로 비공개 저장소를 제공하는 서비스를 사용하는 것이 더 나은 선택일 수 있다. 그런 서비스 중 대표적인 것이 GitLab (https://gitlab.com/) 이다. GitHub와 비슷하지만 비공개 저장소를 생성하는 데 전혀 돈이 들지 않는다. 또한 사용 방법은 GitHub와 비슷하다. 가입하고, 저장소를 만들고, 공개/비공개를 설정하고, 로컬 저장소에 클론하는 등의 작업을 할 수 있다. GitHub와 GitLab은 메뉴의 구성이 다를 뿐이지 기능적인 측면에서는 거의 동일하다고 생각하면 된다. 하지만 ..

git은 다양한 명령어를 지원한다. 구글에서 'git cheat sheet' 등의 검색어로 검색하면 많이 찾을 수 있다. https://git-scm.com/docs Git - Reference Reference git-scm.com git은 파일을 세 가지 작업 영역으로 관리한다. 이러한 가상의 공간 구분을 염두에 두고 살펴보면 몇몇 명령어들의 의미가 더욱 명확해진다. Working Directory : 저장소가 추적 중인 파일들이 위치하는 영역이다. Staging Area : 커밋할 준비가 된 (staged) 파일들이 위치하는 영역이다. Repository : 커밋되어 버전을 관리하는 파일들이 위치하는 영역이다. 이 영역의 파일이 수정되면 Working Directory 영역으로 이동된다. 위의 작업..

git-flow와 github-flow는 git을 이용한 작업 흐름 방식의 양 극단에 있는 작업 흐름이다. git-flow는 복잡하거나 견고하고 브랜치 사이의 엄격한 상호 작용 규칙에 따라야 하는 작업 흐름이다. 그만큼 전체적인 개발-주기가 긴 프로젝트에 어울린다. 반면, github-flow는 개발과 배포에 필요한 최소한의 브랜치 그룹만 유지해 언제나 배포할 수 있고, 여러 가지 요구나 상황 변화에 민첩하게 대응할 수 있는 작업 흐름이다. 이 두 가지의 중간에 gitlab-flow 가 있다. 'GitLab Flow' 라는 웹 문서에서 github-flow를 기본으로 여러 가지 변형 형태를 gitlab-flow라는 이름으로 소개한다. github-flow를 따르지만 배포 과정을 GitLab에서 개선한 작..

git-flow의 단점을 해결하고자 github에서 사용하는 github-flow가 있다. 이름에서 알 수 있듯이 이 작업 흐름은 github에서 사용 중인 작업 흐름이다. https://guides.github.com/introduction/flow/index.html Understanding the GitHub flow · GitHub Guides Create a branch When you're working on a project, you're going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. B..

git-flow 작업 흐름 데스트탑 애플리케이션은 한번 배포된 후에는 유지보수가 쉽지 않다. 사용 환경이 오프라인일 경우, 도중에 실행을 중단할 수 없는 경우, 사용자가 유지보수에 관심을 가지지 않을 경우 등 다양한 이유로 유지보수가 쉽지 않기 때문이다. 이런 애플리케이션은 매우 견고하게 만들어져야 하며, 견고함을 유지하기 위해 프로젝트 작업 흐름 또한 여러 가지 결함을 최소화하고 결함이 있다고 해도 빠른 시간 안에 감지해 수정할 수 있는 모델이어야 한다. 이런 조건을 만족하는 것으로 빈센트 드라이센(Vincent Driessen)이 제안한 작업 흐름 모델인 'A successful Git brancing model' 이 있다. https://nvie.com/posts/a-successful-git-br..

git을 이용한 협업은, 다르게 말하면 브랜칭 생성 규칙을 공유하는 것으로 말할 수 있다. git의 장점인 '자유롭고 무제한 브랜칭' 에 규칙을 정하는 것으로 협업의 틀이 완성되는 것이다. 브랜칭 생성 규칙의 예 요소/플랫폼 데스크탑 애플리케이션 웹 모바일 앱 특징 배포 후에 유지보수가 힘듦. 배포와 개발의 구분이 없음. 배포 이후 지속적인 업데이트 가능. 프로젝트 마감 최초 배포 시 해당 없음 버전마다 배포 단위 최초 한 번. 업데이트는 패치 등으로 제공됨 해당 없음. 무결절성(seamless) 버전마다 배포 시기 조절 가능 여부 ㉮ 가능 해당 없음 불가능 ㉯ 추천 Flow git-flow github-flow gitlab-flow ㉮: 배포 시기를 개발하는 쪽에서 완전하게 가져갈 수 있는지를 뜻한다...

git 을 이용해 프로젝트를 관리하는 방법에는 특별히 정해진 규칙이 없다. 언제든지 브랜치를 만들어서 새로운 기능을 시험해 볼 수 있고, 원 저장소와는 상관없는 자신만의 로컬 저장소를 만들어서 작업할 수 있는 것이 git 이다. 하지만 협업한다면 무엇보다도 중요한 것이 있다. 바로 브랜칭 규칙이다. 모두가 다 master 브랜치를 브랜칭해서 자신의 이름을 딴 브랜치에서 작업할 수도 있다. 하지만 그것보다 프로젝트 전체를 관리하는 훨씬 더 쉬운 방법이 있다. 프로젝트를 관리하기 전에 세워야 할 규칙 커밋 단위 커밋에 포함될 수 있는 내용이 여러 개로 나누어질 수 있을 만큼 크다면 이를 쪼개서 커밋해야 한다. 커밋의 내용을 최소 단위(Atomic)로 유지하는 것이다. 이를 위해 다음과 같은 규칙을 지키는 것..

github는 단순히 원격 저장소만을 제공하는 서비스가 아니다. 프로젝트를 진행하는 데 필요한 서비스들도 같이 제공하고 있다. 따라서 github가 제공하는 여러 가지 기능을 적극적으로 이용하여 협업하는 것이 좋다. github 의 협업 도구 github 는 엽업을 위한 다양한 도구를 제공하고 있다. github 에서 제공하는 도구 중 필수적이라고 할 수 있는 이슈 트래커, 위키, 풀 리퀘스트, 코드 리뷰 기능등이 있다. 이슈 트래커 이슈 트래커는 쉽게 말하자면 게시판이다. 버그 보고, 기능 개선 건의, 그 외 프로젝트에 관련된 주제(이슈)를 등록할 수 있는 공간이다. 물론 일반적인 게시판과는 다른 점이 있다. 담당자: 이슈 담당자 지정 기능 알림: @ 형식으로 특정 그룹이나 특정 사용자에게 알림 라벨:..

git merge 명령을 실행할때마다 --no-ff 옵션을 주었다. 이유는 커밋 내역을 남기기 위함이다. 그런데 git의 전역 속성으로 추가하면 굳이 옵션을 따로 안주어도 된다. git config --global --add merge.ff false

git 을 이용한 버전 관리 시스템의 작업 흐름은 평소에는 여러 개의 브랜치와 커밋 내역을 만들고, 마지막에 작업 내역을 확인하고 올바른 작업물만 병합하는 것이다. git 의 특징 중 하나는 커밋 내역을 수정할 수 있다는 것이다. 하지만 수정할 수 있다고 해서 이미 원격 저장소에 푸시가 끝난 커밋 내역을 수정하는 것은 정말 특별한 상황이 아닌 이상 절대로 권장할만한 일이 아니다. 푸시하기 전에 git merge 명령을 이용해서 병합하면 충돌 해결 커밋이나, --no-ff 로 만든 병합 커밋을 남기게 된다. 이는 작업 흐름을 일관되게 파악하는 데는 깔끔하지 않다. 따라서 할 수 있다면 로컬 저장소에 있던 커밋을 깔끔하게 정리해서 푸시하는 것이 좋다. 그런 정리를 가능하게 하는 것이 git rebase 명령..

파일 하나를 대상으로 변경 내역을 통째로 원래대로 (변경 직전의 최종 커밋 시점으로) 되돌릴 때 사용한다. git checkout HEAD -- 파일이름 위 명령을 실행하면 파일이름 파일의 내용이 최종 커밋 시점 (HEAD 대신 다른 커밋 SHA-1 체크섬 값을 입력하면 해당 커밋 시점으로 되돌림) 으로 되돌아가게 된다. '--' 는 포함하는 것이 좋다. git checkout 명령에 뒤따라 오는 것이 파일이라는 것을 확실하게 해주는 것이다. 만약 '--' 가 없다면, 파일이름이 브랜치 이름과 같을 경우 해당 브랜치로 체크아웃하거나, 특정 커밋 시점으로 저장소 전체가 되돌아갈 수 있다. // example git checkout HEAD -- README.md cat README.md 명령을 실행하면 파..

git reset 명령은 어떤 특정 커밋을 사용하지 않게 되어 다시 되돌릴 때 사용한다. git revert 명령이 이전 커밋을 남겨두는 명령이었다면 git reset 명령은 이전 커밋을 남기지 않고 새로운 커밋을 남긴다는 차이가 있다. 또한 git reset 명령은 현재 커밋인 HEAD의 위치, 인덱스, 작업하는 저장소 디렉토리 등도 함께 되돌릴지를 선택하기 위한 모드를 지정할 수 있다. git rest 명령의 모드 모드 의미 HEAD 위치 인덱스 저장소 디렉토리 hard 완전히 되돌림 변경 변경 변경 mixed (기본값) 인덱스의 상태를 되돌림. 모드를 지정하지 않았을 때의 기본값 변경 변경 변경 안 함 soft 커밋만 되돌림 변경 변경 안 함 변경 안 함 * 인덱스(Index) 는 실제 커밋 전 변..

이미 공개된 커밋 내역을 수정하는 것은 매우 위험하다. 할 수는 있지만 "절대로" 하면 안된다. 하지만 안전하게 변경 내역을 되돌리는 방법이 있다. 커밋으로 발생한 변경 내역의 반대 커밋을 하면 된다. 즉 추가한 코드는 빼고, 지운 코드는 다시 추가하는 커밋을 하는 것이다. git revert 이 명령을 특정 지점의 커밋 SHA-1 체크섬 값을 입력하면 해당 지점까지 변경 내역을 취소하게 된다. ex) git log -5 git log 명령을 통해 특정 지점의 커밋 SHA-1 체크섬 값을 찾는다. 그 후 git revert 523a 명령을 실행한다. vim 편집기 창이 등장하면서 커밋 메시지를 수정하게 된다. 잘 살펴보면 원래의 커밋 메시지가 큰 따옴표로 묶여 있고 앞에 'Revert'라는 문자가 입력되..