written by yechoi

와일드카드 하나(*)는 한 단계의 맥락만 포함하고 두개(**)는 뒤의 모든 단계의 맥락을 포함할 수 있어요. 예를 들면 아래처럼 이렇게 네 개 파일이 있다고 할때, ContextLevel1 ContextLevel1.ContextLevel2 ContextLevel1.ContextLevel2.ContextLevel3 ContextLevel1.ContextLevel2.ContextLevel3.ContextLevel4 ContextLevel1.*을 검색하면 ContextLevel1.ContextLevel2 이것만 나오고요 ContextLevel1.**을 검색하면 ContextLevel1 ContextLevel1.ContextLevel2 ContextLevel1.ContextLevel2.ContextLevel3 ..

humansof42.com 이라는 웹사이트를 운영하고 있다. 나의 첫 웹프로젝트였으며, 42서울 사람들의 이야기를 담는 인터뷰 채널이다. 기획 단계에서부터 지금까지 약 반년이라는 시간이 흘렀다. 개발한 시간 2개월, 운영한 시간 4개월 정도. 매주 한건의 인터뷰를 발행하고 있고, 이 콘텐츠를 위해 참여하고 있는 팀원은 9명으로 늘어났다. 그간의 과정을 기록해보려 한다. 💪 시작 시작은 42에서 채워주지 못한 것을 해봐야겠다는 생각에서였다. 42에서는 주로 C/C++로 로우한 레벨의 프로젝트를 한다. 공식적인 교육과정 상에서 웹프로젝트를 경험할 수 있는 건 공통과정의 마지막에서다. (지금은 웹피신이 생겨서 일찍 경험해볼 기회가 만들어지긴 했지만 그 당시에는 그랬다.) 그러니까 교육을 시작하고 1년 6개월쯤..

프로그래밍을 시작한지 어연 1년 6개월. 지금까지 한 것 중 가장 큰 프로젝트가 막을 내렸다. 3명이서 팀을 이뤄 c++로 nginx와 비슷하려고 노력한 웹서버를 하나 만들었다. 스터디를 시작한 것이 2월 1일이고 프로젝트를 제출한 것이 4월 24일이니까, 거의 꽉채운 세달이 걸렸다. 오랜 걸린 만큼이나 느끼고 배운 것들이 많다. 이번 프로젝트를 통해 성장한 점을 기록해보고자 한다. git으로 구조화된 협업하기 이전에도 git은 사용했지만, 거의 코드 저장소로 사용했을 뿐이다. 이번 프로젝트를 하면서 git을 좀더 '협업툴스럽게' 사용할 수 있게 됐다. 우리는 git으로 협업을 관리했고, 그 과정에서 처음부터 끝까지 지키려고 한 규칙들이 있다. 이러한 규칙들이 있어 비효율적인 소통을 줄일 수 있었다. 1..

gunicorn을 사용하는 데는 두가지 방식이 있다. 하나는 포트를 이용해 서버를 띄우는 것이다. gunicorn --bind 0:8000 config.wsgi:application 와 같은 커맨드가 그러한 역할을 한다. 두번째는 소켓을 사용하는 것이다. unix 계열 시스템에선 포트로 서비스 하는 것보다 유니스 소켓을 사용하는 게 빠르고 효율적이라고 한다. gunicorn --bind unix:/tmp/gunicorn.sock config.wsgi:application와 같은 커맨드로 소켓을 사용할 수 있다. 나는 소켓을 사용하는 방식을 택했다. 자동적으로 gunicorn을 실행하기 위해선 앞선 명령어를 매번 쓰는 것보단, gunicorn을 서비스로 등록하는 게 좋다. gunicorn 서비스로 등록하기..

request 메세지 수신을 멈추는 조건은 다음과 같습니다. 1. 클라이언트가 Transfer-Encoding: Chunked 로 메세지를 보냈다면, chunk의 길이가 0일 때 메세지 수신을 완료 2. 클라이언트가 Content-Length 헤더를 보냈다면 해당 길이만큼 바디를 읽었을 때 완료 3. 메세지 바디가 없는 경우(\r\n이 연달아 두번 이어질 때) 🔗스택오버플로우