출력로그 설정하기

logback의 설정 파일인 logback.xml을 이용하여 출력 로그에 대한 설정을 바꿀 수 있다.

상세한 내용은 공식 홈페이지를 참조하면 된다.


색 바꾸기

  • %highlight를 이용하여 로그 레벨에 따른 색을 줄수 있다.

  • %black, %red, %green, %yellow, %blue, %magenta, %cyan, %white, %gray, %boldRed, %boldGreen, %boldYellow, %boldBlue, %boldMagenta, %boldCyan, %boldWhite를 이용 할 수도 있다.

  • 적용 범위는 ()로 %highlight([%-5level]) 이와 같이 사용 가능하다.

    <Pattern>%d{HH:mm:ss.SSS} [%-5level] [%thread] [%logger{36}] - %m%n</Pattern>
    

    log1

    위와 같은 출력을

    <Pattern>%d{HH:mm:ss.SSS} %highlight([%-5level]) [%thread] %cyan([%logger{36}]) - %m%n</Pattern>
    

    log2

    이렇게 바꿀 수 있다.

윈도우의 경우

  • org.fusesource.jansi:jansi:1.8 가 필요하며 (Linux ,Mac OS X는 기본적으로 지원) <withJansi>true</withJansi> 설정 한 후 사용해야 한다.

    <configuration debug="true">
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
      <!-- On Windows machines setting withJansi to true enables ANSI
           color code interpretation by the Jansi library. This requires
           org.fusesource.jansi:jansi:1.8 on the class path.  Note that
           Unix-based operating systems such as Linux and Mac OS X
           support ANSI color codes by default. -->
      <withJansi>true</withJansi>
      <encoder>
        <pattern>[%thread] %highlight(%-5level) %cyan(%logger{15}) - %msg %n</pattern>
      </encoder>
      </appender>
      <root level="DEBUG">
        <appender-ref ref="STDOUT" />
      </root>
    </configuration>
    

    현재 윈도우가 아닌 관계로 정확히 어떻게 적용 해야하는지 확인은 안됐다.


고정폭

  • %숫자는 출력 고정폭 값으로 -의 유무는 좌우를 결정 짓는다.

    log5

    log3

    log4

    순서대로 [%level] [%-8level] [%8level]


기본적인 설정에서 추가로 적용한 두 가지만 작성했는데 추후 적용하는 것들이 생기면 내용을 추가할 예정이다.

오늘 한일

- trello 프로젝트

  • 단순히 페이지 이동을 위한 Get 요청을 처리할 Controller 기능들 구현 완료

  • 유저 가입 Acceptance Test 통과

  • 거꾸로 UserService에 대한 테스트 코드는 실패…이로 인한 타임리프 발생 (원인 발견, 테스트 코드 자체에 문제가 있었다)

- 출력 로그 색 변경하는 글 작성

  • 굉장히 간단히 작성, 대신 나중에 추가로 사용하게 되는 옵션들이 생기면 내용을 추가할 계획이다. (여기)

- 어제 추가한 alias들 굉장히 편하다.

  • 솔직히 git add .도(gac) 설정했다. 대신 git status로(gss) 무엇이 추가되는지 확인 후 추가 한다. (git commit -m은 gcm)

오늘 느낀점

  • 뭔가 갈팡질팡하는 느낌으로 trello에 대한 진도가 안 나갔다. 그래도 오후가 돼서 감이 잡히는 느낌으로 진도가 잘 나갈뻔했으나 Service 쪽 테스트 코드에서 지속적으로 실패를 했다.

    당시 원인 파악이 안돼서 아직 급 초기 작업임에도 불구하고 많은 시간을 날린 거 같고 어려울 것 없는 부분에서 꼬투리도 못 잡고 막혀서 살짝 자신감이 떨어졌었는데 집 와서 생각해보니 무엇이 문제였는지 알 것 같다.

    @Resource(name = "userRepository")
    private UserRepository userRepository;
    
    @Autowired
    private UserService userService;
    

    이게 문제의 코드로서 계속 null 값이 들어간다. 일단 Mock 테스트를 아직 적용 안한 이유가 있는데 그 부분까지 해서 내일 포비한테 확인을 해야겠다. (지금 계속하면 너무 늦게 잘 것 같으니 내일 오전에 확인 및 정리해서 물어봐야겠다)

  • 사실 Service는 처음 만들어보는데 최근 해당 객체에 대해 알게 됐을 때는 유용성을 크게 못 느꼈는데 오늘 작업을 하려고 하니 상당히 효율적일 것 같아 적극적으로 사용하기로 마음먹었다. 근데 오늘 삽질의 원인 제공이 이 객체였다…. 그래도 처음인 만큼 진통이 있는 것일 테니 Service 객체를 이용할 때 무엇을 신경 써야 하는지 경험을 해보자.

    추가적으로 dto에 대해서는 알고는 있는데 내가 직접 작업을 한 적은 없고 얘는 몇 가지 이유로 유용하다고 생각했는데 정말 그럴까 의구심이 든다. 그래서 한번 사용해보기로 했다. 그래서 얘는 정말 유용할지 아닐지 경험을 해보자.

  • 위에 언급 한 것처럼 자신감이 떨어질 뻔했으나 일단 원인도 파악이 된 거 같고, 다행히도 테스트 코드를 작성하는 곳이 문제였다. 테스트 코드에 대한 학습 장벽이 크다고 하지 않는가?? 게다가 이미 익숙한 곳이었다면 좀 그랬겠지만 Service 쪽에 대해서는 아직 익숙지 않다고 생각하면서 멘탈 케어 중이다. 특히나 원인이 파악되니 마음이 편안하다.

    진척이 좀 느려서 걱정이 됐으나 오늘 작업하면서 대강 어떤 식으로 작업을 해야 할지 감이 온 거 같다. 내일부터 속도를 좀 더 내봐야겠다. 덤으로 집 와서도 삘(?) 받는 날은 그냥 더 늦게까지도 작업을 해야겠다. 대신 그렇지 않은 날은 후딱 자자.


내일 할일

  • trello 구현하기

    • Service 테스트 코드 작성에 대한 질문
    • Restful하게 구현하는 법 점검 및 질문
    • lombok이 뭔지 알아보기(경우에 따라 질문)
    • RestAssured????
    • 유저 가입 기능 마무리 하기
    • 유저 로그인 구현
    • 위 사항들이 끝나면 개발 서버 환경 구축

Alias

…라는 가명으로 알려진, 일명 …라 불리는

네이버 영어사전에 나오는 alias에 대한 설명이다. 뜻처럼 자신이 사용하는 명령어에 별명을 달아줘서 편하게 쓸 수 있게 한다.

설정 방법은 의외로 단순하다.

vi ~/.bashrc

일단은 ubuntu 16.04 LTS 기준이며 맥인 경우 ~/.bash_profile 혹은 ~/.profile에 등록 후
source ~/.bash_profile 또는 source ~/.profile을 하면 된다는 것 같다.

alias 별칭="명령어"

alias ll="ls -al"

위와 같이 자신이 사용할 별칭을 추가하기만 하면 된다.

alias

나중에 자신이 어디에 추가했는지 까먹을 수도 있으니 문서의 가장 아래서 작업하는게 좋으며 위와 같이 #을 이용해 주석으로 자신만의 alias라는 것을 남겨 놓는 것이 좋다. (가장 밑으로 갈 때 shift + g를 활용하면 편하다)

개인적으로 자주 쓰는 명령어와 복잡한 옵션 때문에 자꾸 까먹거나 치기 번거로운 내용들을 추가하면 아주 편히 쓸 수 있다.

특히나 자신이 설정한 내용이기 때문에 alias이기 때문에 해당 명령어를 까먹지 않을 확률도 높다.


주의해야 할 사항으로 기존에 이미 존재하는 명령어를 별칭으로 지정하면 둘 중 하나가 정상적인 실행이 안 될 수 있으니 등록하기 전에 이미 존재하는 명령어인지 확인을 하고 등록하는 것이 좋다.

추가로 ~/.bashrc는 현재 로그인 되어 있는 유저에 한해서만 설정을 해주며 바로 적용되는 것이 아닌 로그인할 때 읽기 때문에 터미널을 새로 켜야 적용이 된다.

오늘 한일

- trello 프로젝트 재시작

  • 프로젝트를 진행하는 과정에서 branch들을 어떻게 관리할지 결정

  • 결정한 branch 정책(?) 기반으로 간단한 부분 구현 후 로컬에서 merge 하는 법 배움

- 자잘한 개발 환경 세팅

  • 이클립스 테마 변경

  • alias 설정들 추가 (alias 설정하는 법)

  • logback.xml을 이용한 로그 출력 커스터마이징

    로그화면

    (정말)간단하게 내일 정리해봐야겠다.


오늘 느낀점

  • 트렐로에 사용될 객체들을 뽑아 보는 걸 해봤는데 또 너무 복잡하게 생각한 것 같다. 아직은 경험이 부족한 만큼 어느 것을 어떻게 고려해야 할지에 대한 경험치도 부족한데 너무 욕심을 낸 거 같다. 포비의 말처럼 일단은 단순하게(핵심적인 부분들만) 생각하고 진행을 하면서 필요한 것들이 있으면 수정해 나가는 방식으로 진행해야겠다.
    급 떠올랐는데 한 번에 완벽한 코드를 작성하는 것이 아니라 리팩토링을 통해 클린 코드를 작성하는 것처럼 나한테 당면한 문제도 한 번에 완벽하게 하려고 하지 말고 리팩토링적(?)인 접근을 하는 습관을 들여봐야겠다.

  • git은 역시 자주 쓰는 명령어들에 익숙해진거지 아직은 많이 모르는 것 같다. 오늘처럼 차근차근 사용하는 명령어들을 늘려가면서 더 많이 알아가야 겠다.

  • 포비의 추천을 받아 “oh my zsh”를 설치 하는 도중 이게 무슨 도움을 주는지 설명을 보고 있다가 깔 필요가 없겠다는 생각이 들었다. 사실 이걸 내 스스로도 깔아 보고 싶었던 이유가 포비가 보여준 깃 축약 명령어 였는데 alias를 통해 설정 되어 있는 거라고 하니…그냥 내가 필요 한 것들을 내가 설정하는게 낫겠다 싶어져서 받은걸 그냥 지우고 내가 쓸 축약 명령어들을 등록 했다.

    딱 하나 더 탐나는 게 현재 내가 어느 branch인 지 보여주는 기능인데 이건 한 줄에 너무 많은 정보를 보여주는 바람에 명령어를 입력할 공간이 줄어들어서 탐나기도 하면서 별로라고도 느낀다. 거기다 oh my zsh가 아니라도 이 기능을 지원하는 플러그인도 충분히 있을 것 같다.
    (개인적으로 현재 경로가 나오는 걸 선호하고, 명령어 입력을 개행 후 가장 왼쪽에서 받는 것도 안 좋아한다)

  • 이번에 트렐로를 시작하면서 인텔리 제이를 사용해 볼까 싶었는데 포비와 대화를 하고 나니 이번에 시작해보는 것들이 많다. 일단 ATDD, CI, Docker 등등 이에 비해 인텔리 제이를 사용하는 건 개인적으로 중요도가 높진 않다. 그러다 보니 너무 많은 걸 한꺼번에 시도하다 과부하가 걸릴 수도 있고 인텔리 제이에 익숙지 않아 문제가 생길 수도 있으니 이번에 집중해야 할 것들에만 집중을 해야겠다. 게다가 현재 나한텐 인텔리 제이 라이선스가 없는 관계로 일단 지금 당장은 구매를 해서까지 사용할 생각은 없는지라 졸업한 학교 이메일이나 친구의 이메일을 통해서 라이선스를 획득해야 할 텐데 개인적으로 탐탁지 않다.


내일 할일

  • trello 구현하기
    • 본격적으로 기능 개발 시작

오늘 한일

- trello의 UML, ERD 작성

  • 마음에도 안 들고 솔직히 제대로 작성도 안됐다. 고민한 기간만 길지 저번 주 생각한 것과 바뀐 것도 없다… 이럴 거면 그냥 미리 하고 조언 받을 걸 그랬다 싶다. 조금씩 느끼지만 시간적 여유가 넘치는 게 아니라면 너무 욕심내서 스스로 하려고 하는 것도 안 좋은 버릇인듯싶다.(솔직히 여유만 있으면 평소 더 욕심내고 싶다)

- trello 프로젝트 시작

  • 프로젝트 생성 과정에서 branch 이름 등 몇 부분에서 생각 보다 시간이 걸렸다.

  • 본격적으로 시작하기 전 기본적인 부분은 마무리했는데 내일 포비를 통해 다시 정리해서 시작해야겠다.

- 블로그 버그 수정

  • 모바일 화면인 경우 검색 버튼이 화면을 따라다니던 버그 수정
    • css에서 position: fixed; 이 부분이 문제로 모바일인 경우와 pc인 경우에 따라 position: absolute;로 변경이 되면 된다는 것까진 알아냈는데 어떻게 해야 할지 감이 안 잡혀서 지킬을 사용해 본 경험이 있는 프론트 분한테 도움을 청해 최종적으로 해결했다.
      (기존에 있는 네비게이션 부분을 활용하여 화면 크기에 따른 분기를 통해 해결.)

- 자바스크립트 복습(?)

  • 반복 주기에서 AJAX 구현 부분에서 답글(댓글) 작성 후 자바스크립트로 생성하는 삭제 버튼(실제 버튼 타입은 아니다)은 이벤트 등록이 안되어 있다.

  • 해결 방법은 두 가지로 부모한테 이벤트를 걸어 두는 방식과 댓글을 추가하면서 이벤트를 등록하는 방식으로 해결이 가능하다.


오늘 느낀점

  • fork를 떠와서만 과제를 진행하기만 하니까 프로젝트를 생성해서 작업 부분에서 Group, Artifact 등에 무엇을 써야 할지에 대한 고민됐다. 크게 중요하게 생각지 않는 프로젝트라면 편할 대로 쓰고 넘어갔을 텐데 제대로 관리하려는 프로젝트다 보니까 신경이 쓰였다. 이후 git init 후 branch를 어떻게 나눌지에 대한 부분들까지… 이 부분은 이전에 포비와 대화를 나누긴 했지만 실제 작업을 하려니 정확히 어떻게 나눌지 확신이 안 섰다.
    내일 포비를 통해 가이드라인을 잡고 다시 시작해 봐야겠다.

  • 오랜만에 반복 주기를 제외한 웹 애플리케이션 구현을 하는 것 같은데 빨리 본격적으로 시작하고 싶다. 그러나 위에 언급한 사항 및 추가적인 몇 가지를 내일 확인하고 본격적인 작업을 진행해야겠다.

  • 블로그 검색 버튼에 있던 버그를 수정하면서 당시 작성한 프런트 코드에 마음에 안 드는 부분들이 있어 수정을 했다. 확실히 프론트단만 해도 이전과 지금은 많은 차이가 있는 것 같다. 그런 의미에서 이전엔 손 대기 힘들었던 부분들에 대해서도 손대야 할 부분들이 있는데 솔직히 블로그 자체는 뒷전이다. 심심할 때나 삘 받을 때 한 번씩 할 듯싶다.

  • 이벤트가 등록되는 방식(혹은 시점?)에 대해 이전에 AJAX를 진행하면서 유념해 뒀는데 역시나 사람은 망각의 동물이다. 뒤늦게 떠오르긴 했지만 까먹었었다. 특히나 자바스크립트를 쓸 일이 적다 보니 더 그런 거 같다. 이번엔 잘 기억해 두 자.


내일 할일

  • trello!!!!
    • package 구조, git branch 등등 초기 세팅에 대해 조언 받자

    • 본격적인 코드 구현

    • 가능하면 일정 부분 이상에선 Acceptance Test 코드를 직접 짜보자
      (특히 BasicAuth를 이용하기 위한 설정들은 가능하면 꼭 직접 해보자)