Daily Layer Daily Layer

개발자로서 일을 할 때는 항상 "기술" 만이 문제가 아니다. 소프트웨어 개발의 5단계가 어떻게 이루어져 있던가 요구사항 분석, 설계, 구현, 테스트, 유지보수 요구사항을 파악하고 일정을 잡고 이슈를 캐치하고 수정하는 모든 과정이 소통인데 이 책은 그 소통을 어떻게 해야 하는가의 전체적인 밑그림을 그릴 수 있는 능력을 키워준다. 그림을 그릴 수 있다는 것은 무언가 잘못되었을 때 스스로 문제를 확인하고 개선할 수 있다는 것이다. 일하면서 생기는 여러 문제들. 왜 내 설명을 높으신 분들이 이해하지 못하고 고객이 이해하지 못하는지 이 책을 읽고 나면 남 탓을 하기 어려울 것이다. 내가 과연 이해할 수 있는 언어로 한 건지, 내 의도를 충분히 전달한 건지, 상대방이 말하고자 하는 것은 내가 캐치했는지 사후 강평을..

꽤 작성하던 코드가 갑자기 빌드가 안된다. In file included from include/log.h:3:0, from src/main.cpp:13: /usr/include/c++/4.8.2/sstream:41:1: error: expected initializer before ‘namespace’ namespace std _GLIBCXX_VISIBILITY(default) 대체 무슨 문제인가 하고 찾다가 함수나 구조체 등 무언가 선언이 완료되지 않으면 주로 발생하다는 글을 보고 찾아보았다. 내 코드의 경우 main.cpp의 13번째 줄까지는 전부 include 선언이다. 13번 째 줄도 log.h를 include하는 내용이다. 그렇다는 것은, 13번째 이전 줄의 헤더 파일 어딘가에 선언이 완료되지..

테스트 구조는 알았고, 사내에 테스트를 적용을 마쳤다. 이해한 내용을 정리해서 테스트 프로젝트를 하나 작성하고, 이 아이를 "단위 테스트가 없던 프로젝트" 에서 "단위 테스트가 포함된 프로젝트" 로 바꾸는 과정을 살펴보자 CentOS 7 google-test 단위 테스트가 없는 상태의 프로젝트와 단위 테스트를 포함한 프로젝트를 각각 첨부한다. 코드는 직접 내려받아서 make 하고 make test 를 통해 테스트 바이너리까지 빌드할 수 있도록 만들어두었다 github에서 확인하기 https://github.com/BearMett/UnitTestTester GitHub - BearMett/UnitTestTester: 프로젝트의 테스트 코드 적용기 프로젝트의 테스트 코드 적용기. Contribute to B..

CPU 괴롭히기 자원 관리를 하다보면, CPU나 메모리에 부하를 주어 테스트 해야 하는 순간이 온다. 예전에는 while을 사용해서 ls 출력 결과를 /dev/null 로 리다이렉트 하는 방법을 사용했는데, 더 나은? 방법을 찾아보았다. 스택 익스체인지의 리눅스 서버의 CPU 사용량을 높히려면 어떻게 해야하나요? 글이 가장 큰 도움이 되었다. 1. stress 가장 기본적인 방법이다. 애초에 이 목적으로 나온 stress 라는 패키지를 설치하고, 이 기능을 이용하는것. stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s 심지어 이렇게 하면 메모리까지 간편하게 점유할 수 있다. 다만, 패키지를 설치해야 해야해서 폐쇄망에서 바로 쓰기는 좀 어려운것이 단점..

적다보니 잡담이 길어졌다. 아래 한줄까지 하면 세줄요약 echo -e "HTTP/1.1 200 OK\n\n $(date)" | nc -l -p 80 nc는 network concatenate, 즉 netcat 이다. centOS 7 환경에 패키지 이름은 nc yum install nc cat 명령은 파일을 순차적으로 읽어 출력으로 가져오는 동작을 한다. nc 명령은 이 행위를 소켓까지 확장한다. 간단한 배너그래빙 비슷한 동작을 해보면 sshd를 대상으로 파이프를 냅다 열어버리는 동작이다. 프로토콜 소개가 Full-Text로 오는것을 볼 수 있다. 물론 내가 보낸 응답은 그냥 개행문자. telnet에게 하는 동작과 굉장히 유사하나, Connection closed 에 대한 동작이 다르다. 중요한 내용은 아..

스크립트를 작성할 때 버릇처럼 적는 한줄이 있다. #!/bin/bash #!/bin/expect #!/bin/python3 이 구문은 shebang 이라는 구문인데, 간단하게는 실행할 때 어떤 스크립트인지 명시하는 부분이라고 생각해도 된다. (영문, 국문 위키백과) 이 글에서는 shebang 을 작성할 때 고려할만한 내용을 작성한다. 대부분의 경우 bash script나 expect script를 작성할땐 이 shebang을 어떻게 표기할지 고려할 필요가 없다. bash는 대부분의 환경이 /bin/bash에 있을것이며 expect는 설치가 보장되어있지 않다면 패키지를 같이 보내서 설치하라고 하면 그만이니 이 문제를 고민하게 된 원인은 python 덕분이었다. python3.7버전의 소스를 내려받아 특정 ..

현재 경로의 svn에 ignore 추가하기 svn propset -R svn:ignore *.pyc . svn propset -R svn:ignore __pycache__ . -R은 Recursive . 은 현재 경로를 뜻한다 이 글이 필요한 사람 중, 이미 svn에 commit 한 사람도 있을것이다. 해결법이 필요하다. pycache와 pyc 파일을 찾아 삭제하고 에서 rm 하기 find . -name "*.pyc" | xargs svn rm #--force find 로 찾은 .pyc 파일을 svn rm 의 인자로 넘겨주면 된다. 필요한 경우 #--force 의 주석을 풀고 강제 적용 가능 find . -name __pycache__ -type d | xargs svn rm #--force 디렉토리도 ..

Expert Beginner 라는 단어를 듣고난 후, 정말 많은 생각을 했다. 신입 티를 벗어나기 위해 해야 하는 성장 지표는 무엇이 있을까. 나는 무엇이 부족한건가, 무엇 때문에 발전이 없는 상태로 남아있는건가. 공부해야한다. 나는 C, C++를 위주로 작업을 한다. 현재 다루는 코드들은 작성된 지 굉장한 시간이 지난 프로시저(절차) 지향으로 개발된 프로그램이다. 그런데 기능 추가, 버그 수정을 할 때 큰 난관에 봉착한다. 예상하지 못한 영향으로 인해 생기는 생각지도 못한 버그. 분명 기능을 추가했으나 같은 코드가 여러곳에 있다보니 (아차!) 빠뜨려서 수정되지 않은 기능. 정말 많은 케이스가 있다. 코드가 지저분하다는 핑계를 멈추어야 한다. 내가 고쳐내려면 어떤 식으로 작성해야 하는지 알아내는것이 좋다..