Research & Develop

문제풀이 학습전략

2022-02-10T00:00:00+00:00

학습 전략

각 전략은 병행으로 진행한다.

Programmers 문제 뿌수기

2월 10일 기준 Programmers 난이도 별 문제 개수

시간을 정하고 푸는데 시간을 넘길 경우 처음 보는 알고리즘이어서인지 코딩 미숙인지 판단 후 개선

Level1: 65 => 한 문제에 10~20분
Level2: 80
Level3: 63 => 한 문제에 한 시간
Level4: 29
Level5: 13

백준 문제 뿌수기

계획중

고수들 따라하기

많은 고수들 ([1], …)이 이미 같은 길을 걸어왔다.

좋은 코딩 스타일과 어떤 문제들을 풀어야 할 지, 어떤 것을 더 해야할지 그들에게 묻자.

자주 쓰는 STL 함수 정리

2022-02-10T00:00:00+00:00

학습 전략

문제풀이 프레임워크

2022-02-03T00:00:00+00:00

Introduction

코딩 테스트 문제는 다음 세 가지로 구성된다.

“입력, 로직, 출력”

입력, 로직, 출력을 class로 추상화함으로써 기존의 지겨운 입출력 구현을 없애고 로직 구현에 집중할 수 있도록 한다.

앞으로의 글에서는 코드만 올릴 예정이지만 필자 개인적으로 프레임워크를 발전시켜나가면서 로직에 집중하고자 한다.

아직 개선의 여지가 많은 프레임워크[1]이기 때문에 기여하고 싶으시다면 언제든지 댓글 바랍니다.

입력

ProblemFile.h 헤더파일에는 입력을 담당하는 함수들이 존재한다.

최상위 클래스인 ProblemFile을 상속받아 ReadFile 함수를 수정함으로써 다양한 문제 풀이 사이트의 입력에 대응할 수 있다.

아래 코드는 프로그래머스 입력 파일에 대응하는 ReadFile 함수의 예시다.

// ProblemFile.h
inline void ProgrammersFile::ReadFile(std::string file_name, std::vector<FileFormat::Types> type)
{
	std::fstream ifs;
	std::string buffer;

	ifs.open(file_name);

	if (ifs.is_open())
	{
		while (ifs.peek() != EOF)
		{
			std::getline(ifs, buffer);

			// 입력이 개행 문자로 나뉜다는 가정
			this->num_of_problems++;

			std::vector<std::string> split_string = StringOperation::split(buffer, '\t');
			for (int i = 0; i < split_string.size(); i++)
			{
 				std::string s = split_string[i];
				std::vector<std::string> array;

				if (type[i] == FileFormat::Types::List)
				{
					s = StringOperation::remove_all(StringOperation::remove_all(StringOperation::trim(split_string[i]), ' '), '\"');
				}
				
				array = StringOperation::split(s, ',');
				arrays.push_back(array);
			}
		}
	}
	else
	{
		throw ifs;
	}

	ifs.close();
}

로직

Problem class의 Run 함수엔 크게 Prepare (입력), Solve (로직), Score (출력) 함수가 쓰인다.

여기서 Problem class를 상속한 자식 클래스에서 Solve 함수를 구현하는 형태이며 디자인 패턴을 안다면 template method 라고 보면 된다.

// Problem.cpp
void Problem::Run()
{
	vector<vector<string>> inputs;
	vector<string> output;
	vector<string> right_answer;
	int num_problems = 0;

	Prepare(); // 입력!
	inputs = file->GetArrays();
	num_problems = file->GetNumOfProblems();

	for (int test_case = 0; test_case < inputs.size(); test_case += inputs.size() / num_problems)
	{
		vector<vector<string>> input;
		for (int i = test_case; i < test_case + inputs.size() / num_problems; i++)
		{
			input.push_back(inputs[i]);
		}
		right_answer = inputs[test_case + inputs.size() / num_problems - 1];
		output = Solve(input); // 로직!
		Score(output, right_answer); // 출력!
	}

}

활용법

실제 문제를 풀 때는 각 문제 사이트에 맞는 Problem class를 상속하고 Solve 함수만 구현하면 된다.

밑 소스코드는 2020 카카오 인턴십 문제인 보석 쇼핑을 풀 때 사용한 것이다.

// JewelShopping.h

class JewelShopping : public ProgrammersProblem
{
public:
	JewelShopping(FileFormat file_format);
	std::vector<std::string> Solve(std::vector<std::vector<std::string>>& input) override;
	int GetCatNum(const std::vector<std::string>& gems);
};

Figure 1. 실행 결과

Figure 1과 같이 main.cpp에서 Solve 함수를 호출하면 결과를 확인할 수 있다.

결론

프레임워크를 [1] 에서 git pull을 통해 다운로드 받은 후에 visual studio로 바로 결과를 확인할 수 있으니 기존 문제 풀이 사이트만 이용하는 것보다 편리할 수 있을 것이다.

다만 일반적인 프레임워크를 만든다는 것이 쉽지는 않은 일이며 무엇보다 많은 사람이 사용할 지 의문이 있다.

이러한 프레임워크 설계에 관심이 있다면 연락 주길 바란다. 같이 한번 발전시켜볼 수 있을 것 같다.

협업을 위한 github issue 작성방법

2022-02-03T00:00:00+00:00

Introduction

[1]을 참고하여 협업을 위한 github issue 작성 방법을 정리하고자 한다.

순서

issue 생성
처리하고자 하는 이슈의 번호 확인
git branch feature/8 // (처리기능/이슈번호)
git checkout feature/8
git add .
git commit -m "Fix: ~~~로 변경 close #8"
git push -u origin feature/8
git checkout master
git merge feature/8

예시

[2]와 같이 깃허브에서 issue를 생성할 수 있다.

Issue에는 누가 해결할 것인지 (Assignees) 또는 issue의 특성은 무엇인지 (Labels) 등을 설정하여 추가적인 정보를 줄 수도 있다.

또한 [3] 처럼 commit message에 #이슈번호를 붙이면 자동적으로 이 issue와 관련된 commit로 [2]에 나타나게 된다.

결론

필자는 가끔 수정해야할 버그를 까먹고 나중에서야 발견하는 경향이 있다.

일이 바쁘다보면 나중에 수정해야겠다고 생각했다가 잊어먹고 안하는 경우에 그렇다.

그러나 본 글에서처럼 issue를 통해 기록해두면 까먹을 일도 없고 어떤 식으로 진행되어왔는지 한 눈에 볼 수 있어 좋은 것 같다.

Github 명령어 정리

2022-01-26T00:00:00+00:00

Introduction

실제와 같이 순차적으로 Repository 생성 => 환경 설정 => 파일 처리 명령어 순으로 정리함.

이외의 것들은 Etc에 정리.

Github repository 생성

순서

github.com에서 new repository를 통해 remote repository를 생성한다.
remote repository를 복사하거나 기존 폴더에서 local repository를 생성한다.
- git clone [원격 저장소 주소]
- 기존 폴더에서 git init

Git remote

local repository와 remote repository 연결

git remote add origin [remote repository 주소] or git remote add origin [branch 이름]
git remote -v // remote repository와 연결 확인

Git config

git config --global user.name "[사용자명]"
git config --global user.email "[사용자이메일명]"
git status // git 상태 확인

파일 처리 명령어

Commit

git add [파일명.확장자명] // [파일명.확장자명]을 스테이지에 올림
git commit -m "[메시지명]" // -m 없이 하는 것을 추천
git commit -a -m "[메시지명]" // 스테이징과 커밋을 동시에 진행 (add + commit)
git log // 커밋 내역 확인
git log --pretty=oneline // 커밋 내역 한 줄로 표기
git show [커밋 id] // 특정 커밋 내역 확인
git diff // 최근 버전과 작업 파일간 차이를 출력
git diff [이전 커밋 id] [이후 커밋 id]
git checkout [커밋 해시] // 지정한 커밋 해시로 이동
git reset HEAD^ // 현재 HEAD의 이전 커밋으로 되돌리기
git reset HEAD~n // 현재로부터 n번째 이전 커밋으로 되돌리기
git reset --soft [커밋ID] // head만 바뀜
git reset --mixed [커밋ID] // staging도 그 때로 바뀜
git reset --hard [커밋ID] // working 디렉토리 / staging 모두 그 때로 바뀜
git revert [커밋 해시] // 지정한 커밋 해시의 변경 이력을 취소

Push

// 보통 [저장소명] 을 origin으로 한다. => git remote를 통해 정확한 저장소명을 알아낼 수 있음
git push [저장소명] [브랜치명] // 특정 저장소에 특정 브랜치의 코드 변경 이력을 올린다.
git push -u [저장소명] [브랜치명] // -u를 붙이면 다음부터는 git push만으로 올릴 수 있다.

Push 하기 전에 .gitignore 파일을 잘 추가했는지 확인하자. [3]

그리고 push 과정에서 access deny가 발생한다면 [2]을 확인하자.

Branch

git branch // 로컬 branch 정보를 보여준다.
git branch -v // 로컬 branch의 정보와 마지막 커밋 내역을 함께 보여준다.
git branch -r // remote 저장소의 branch 정보를 보여준다.
git branch -a // local/remote 저장소의 모든 branch 정보를 보여준다.
git branch [브랜치명] // 로컬에 새로운 branch를 생성한다.
git checkout -b [브랜치명] // branch 생성과 동시에 해당 branch로 이동한다.
git checkout -t [remote 브랜치명] // remote에 있는 branch를 가져온다.
git branch --merged // merge된 branch 표시 (merge 및 *가 표시되지 않은 branch는 삭제 가능)
git branch --no-merged // 아직 merge 안된 branch 표시
git branch -d [브랜치명] // branch를 삭제한다. 아직 merge하지 않은 커밋을 담고 있는 경우 강제 종료 옵션 -D를 써야함
git branch -m [변경할 브랜치명] [변경될 브랜치명] // 브랜치 이름을 바꾼다. 

Etc

Github message convention [1]

커밋 메세지 7가지 규칙

제목과 본문을 빈 행으로 구분합니다.
제목을 50글자 이내로 제한합니다.
제목의 첫 글자는 대문자로 작성합니다.
제목의 끝에는 마침표를 넣지 않습니다.
제목은 명령문으로! 과거형을 사용하지 않습니다.
본문의 각 행은 72글자 내로 제한합니다.
어떻게 보다는 무엇과 왜를 설명합니다.

커밋 메세지 구조

<type>(<scope>): <subject> 
<BLANK LINE> 
<body>
<BLANK LINE>
<footer>

<type>:
feat : 새로운 기능에 대한 커밋 
fix : build 빌드 관련 파일 수정에 대한 커밋 
build : 빌드 관련 파일 수정에 대한 커밋 
chore : 그 외 자잘한 수정에 대한 커밋(기타 변경) 
ci : CI 관련 설정 수정에 대한 커밋 
docs : 문서 수정에 대한 커밋 
style : 코드 스타일 혹은 포맷 등에 관한 커밋 
refactor : 코드 리팩토링에 대한 커밋 
test : 테스트 코드 수정에 대한 커밋

예시
Feat: 관심지역 알림 ON/OFF 기능 추가(#123) 
시군구의 알림을 각각 ON/OFF 할 수 있도록 기능을 추가함 
- opnion0055: 구분 코드 
해결: close #123

눈으로 보는 깃허브 페이지 (github page) 코드 분석: From code to HTML

2022-01-25T00:00:00+00:00

Introduction

깃허브 페이지를 처음 사용해보는 유저의 입장에서 코드를 분석하고자 한다.
~~(실제로 작성자가 초보다.)~~

여타 유투브 영상등을 통해 Minimal mistake와 같은 template을 fork해서 사이트를 만들었지만 코드 내용은 모르는 사람들을 타겟으로 한다.

Figure 1. Code structure

Figure 2. Output HTML

우선 template을 fork하고 나면 Figure 1과 같은 code structure을 가진다.

그렇다면 Figure 1의 code가 Figure 2의 HTML로 어떻게 변환되는 것인가?

이에 대한 궁금증을 풀어나가도록 하겠다. 그리고 이것을 이해하면 다른 공식 문서들을 이해하는 것도 한결 쉬워질 것이다.

Structure

본 글의 코드는 깃허브 페이지와 코드 ([1, 2])을 참고하여 진행한다.

/index.html

Github page를 만들고 가장 처음 접근하는 주소는 “https://user-name.github.io/”이다.

“https://user-name.github.io/”을 주소창에 치면 Figure 1의 code structure에서 /index.html 이 호출된다.

Figure 3. index.html

Figure 3의 /index.html을 보니 원하던 html 코드는 없고 생뚱맞은 내용과 이를 감싸는 --- 들로 구성되어 있다.

--- 들로 감싼 부분을 머리말(front-matter)이라고 한다. 공식 문서[3]을 참고하면 layout, sidebar_main, author_profile 들이 값을 저장하는 변수라는 것을 알 수 있다.

나중에 언급하겠지만 Liquid 라는 언어의 if, for 문 등을 이용해 최종 HTML 파일을 만든다. 변수들도 이러한 로직을 짤 때 사용된다.

여기서는 layout 변수에 저장된 home에 집중하자.

공식 문서[3]에서도 layout이라는 사전 정의된 전역 변수에 대해 간략히 소개하고 있다. layout에 저장하는 이름을 layout_name이라고 했을 때 /_layouts/layout_name.html 파일을 이용하여 최종 html 파일을 만들겠다는 것이다.

여기서는 /_layouts/home.html 을 이용하겠다는 것이 된다. 실제로 code structure에서 찾아보면 home.html이 이미 있을 것이다.

/_layouts/home.html

Figure 4. home.html

일단 Figure 4의 home.html을 보니까 뭔가 <h3 class> 나 <div> 등의 HTML code가 있다. 이게 실제로 어떻게 반영되는지 눈으로 확인해보자.

Figure 5. home.html to HTML

참고로 Figure 5처럼 특정 부분의 HTML 소스코드를 보려면 특정 부분에 마우스를 대고 오른쪽 클릭 후 “검사”를 누르면 된다.

Figure 5의 HTML 소스코드중 회색으로 변한 부분을 보도록 하자.

회색 부분에 해당하는 HTML 소스코드인 <h3 class="archive__subtitle">Recent posts</h3>는 Figure 4의 home.html 8번 째 줄에 나온 부분과 같다.
(정확히 똑같진 않은데 중괄호로 감싼 부분은 Liquid 문법이니 그저 뭔가의 로직이 실행됐다고만 알고 지나가자.)

그리고 바로 다음 이어지는 HTML 소스코드들이 바로 Figure 4의 다음 문장을 실행시킨 것이다.

<div class="entries-{{ entries_layout }}">
  {% for post in posts %}
    {% include archive-single.html type=entries_layout %}
  {% endfor %}
</div>

for문이 반복문의 개념이고, archive-sigle.html이 특정 post를 list로 나열해주는 함수처럼 생각하면 해석은 간단하다.

모든 post들을 담은 전역변수, posts에서 post를 하나씩 꺼내 페이지 list에 나열해주는 코드와 같다. (즉, Figure 5의 Recent posts 밑 부분처럼 post를 나열한다. 지금은 post가 한 개라서 하나만 나타남)

그런데 home.html에 의해 생성된 HTML 코드들은 일부분의 코드일뿐 아직 전체 HTML 코드가 완성되지 않았다. 나머지 코드는 어디서 완성하는걸까?

Figure 4. home.html의 머리말 (front-matter)을 다시 보면 layout: archive가 또 정의되어 있다.

index.html에서 home.html로 넘어왔듯, 다시 한번 archive.html로 HTML 코드 생성의 역할이 넘어가게 된다.

공식 문서[4]에서는 이를 layout 상속이라고 표현하는데 개인적인 생각으론 wrapper 개념에 가까운 듯 하다. 그 이유는 다음 sub-section에서 설명하겠다.

/_layouts/archive.html

Figure 6. archive.html

결론적으로 말하자면 home.html의 모든 코드가 archive.html의 {{ content }}부분에 들어가게 된다.

이를 확인하기 위해 Figure 6의 코드들중 파란색으로 감싼 부분들에 초점을 맞춰보자.

가장 첫 줄인 <div class="archive">는 Figure 5의 HTML 코드에서도 나온다. 회색으로 줄 친 부분 윗윗 줄이다. 그리고 {{ content }} 부분은 home.html의 코드로 대체되어 Figure 5의 회색 줄 부분이 시작되게 된다.

마치 archive.html이 home.html을 감싸는 듯한 느낌이기에 상속보다는 wrapper가 더 좋은 묘사가 아닌가 싶다.

하지만 archive.html도 머리말(front-matter)을 보면 default.html이라는 최상위 html에 의해 감싸지는 것을 확인할 수 있다.

/_layouts/default.html

Figure 7. default.html

드디어 Figure 2의 최종 HTML 파일을 완전히 구성하는 태초의 HTML을 발견했다.

HTML 소스코드의 시작과 끝은 <html> ~ </html>이고 Figure 7에서 확인할 수 있다.

물론, 여전히 이해가 안되는 중괄호 내의 Liquid 문법등이 남긴 했지만 이는 다음 글로 넘기도록 하겠다.

Summary

본 글에서 알아가야할 것은 다음과 같다.

“https://user-name.github.io/”을 주소창에 쳤을 때 처음으로 찾는 index.html 부터 최종적인 HTML 파일을 만들기까지의 코드 흐름

하지만 아직은 전체적인 그림만 본 것이기 때문에 바로 응용에 들어가기란 쉽지 않다.

다른 사람들이 잘 만들어둔 깃허브 페이지와 코드[1, 2]들을 잘 참고하면서 원하는 기능들을 하나씩 구현하다 보면 응용의 단계까지 금방 도달할 수 있으리라 생각한다.

추가로 공식 문서[3, 4, 5]들도 잘 참고하도록 하자.

Research & Develop

문제풀이 학습전략

학습 전략

자주 쓰는 STL 함수 정리

학습 전략

문제풀이 프레임워크

Introduction

입력

로직

활용법

결론

협업을 위한 github issue 작성방법

Introduction

순서

예시

결론

Github 명령어 정리

Introduction

Github repository 생성

Git remote

local repository와 remote repository 연결

Git config

파일 처리 명령어

Commit

Push

Branch

Etc

Github message convention [1]

눈으로 보는 깃허브 페이지 (github page) 코드 분석: From code to HTML

Introduction

Structure

/index.html

/_layouts/home.html

/_layouts/archive.html

/_layouts/default.html

Summary

References