아파치 로그 포맷

아파치 서버의 로그는 어떻게 읽어야 하지?

우선 mod_log_config에 가면 기가막히게 다 설명해주고 있다.

Access Log

"%h %l %u %t \"%r\" %>s %b"

기본적으로 이렇게 많이 쓴다. 하나씩 뜯어보면

  • %h : 원격 호스트
  • %l : 원격 로그인명(있다면)
  • %u : 원격 사용자
  • %t : 시간
  • %r : 요청의 첫번째 줄
  • %>s : 쪼금 이상한데 최종요청의 상태. Final Status
    • %s : 원래요청의 상태 Status of Original request
  • %b : HTTP 헤더를 포함한 응답 크기
  • %D : 요청을 처리하기 위한 시간 ms
  • %T : 요청을 처리하기 위한 시간 sec

자바에서 문자열을 다루는 클래스

String , StringBuilder, StringBuffer 차이

같은 점

모두 문자열을 다루고 append할 수 있다. StringBuffer, StringBuilder가 호출 할 수 있는 메소드는 모두 같다.

차이 점

성능 차이…. 극명하게 나뉨 String이 쓰레기

StringBuilderStringBuffer 랑의 차이점은 멀티 스레드일 때 안전성이다 버퍼는 스레드에 안전하게 설계되어 있고 빌더는 보장 못한다.

그래서 빌더를 쓰면 멀티 쓰레드에서 하나의 객체를 처리하면 문제가 발생할 수 있다.

그럼 왜?

String이 쓰래기이냐?

String a = "";
for( 많이많이 ) {
    a+="abc"
}

할때 a에 abc를 덧붙이는데 이때 새로운 Stirng 객체 만들어지고 이전에 a는 쓰레기가 돼서 GC 대상된다. 이걸 많이많이 반복하게돼…

계속계속 객체만들고 버리고 만들고 버리고 이러니까 메모리 다잡아 먹고 GC 계속 돌아서 속도 느려지고.

StringBuilder, StringBuffer 는?

예상한데로 얘네들은 새로운 객체를 생성하지 않아! 그래서 가지고 있던 객체를 재활용해서 그냥 더 크게 메모리잡고 문자열 저장하는 방식 매번 새롭게 생성하지 않으니까 메모리낭비 안하고 GC도 안돌고.

오..

java 5 이상에선 컴파일러 똑똑해져서 개발자가 String을 +로 문자열 만들면 알아서 버퍼나 빌더로 바꿔줌… 어.느.정.도

깨끗한 코드 - Clean Code

Clean code

프로그래머라면 깨끗한 코드를 짜야지! 좋은 코드를 만들기 위해 가이드하는 책!

코드를 나중엔 사람이 안짤까?

나~~중엔 코드짜주는 프로그램도 나올까? 프로그램을 만들기 위해 코드를 짜는데 나중엔 설계를 잘 해서 입력으로 주면 그거에 맞는 코드를 내 뱉는 시스템이 생길까? 왠지 요즘 잘 나오는 템플릿도 그렇고 간단한 프로그램은 마우스만으로 만들 수도 있으니까 가능성이 없진 않을까 생각한다. 중요한건 지금도 좋은 코드에 대한 고민 많이 하고 있는데 그 고민을 덜어줄 수 있을까?

그럼에도 좋은 코드를 짜야하는 이유

여러가지 이유가 있겠지. 좋은 코드가 좋다는건 모두 다 아는 사실이지만… 정신 개조가 필요한 개념인 것 같다.

나중은 절대 오지 않는다. 르블랑의 법칙

나중에 고쳐야지… 는 개나주자

그럼 중요한 건 알겠는데 어떻게 하냐

하는 방법은 엄~~~청 많다. 코드 그자체라 던지 구조던지 아래에 소개하는건 구조보단 코드 작성법에 가까운 팁들이다.

커밋할 땐 이전 코드보다 더 나은 코드만 커밋하자

어제보다 1%라도 나은 코드만 생산한다면 언젠간 100%에 도달할 수 있지 않을까?

클린 코드 작성법

너무나 잘 알려져 있는, 기본적인 것들은 좀 제외하고 신기한 것들이나 못들어 봤던 것들, 놓칠 수 있는 것들을 골라 적어본다..

Data, Info

  User userData;  // worse
  User userInfo; // worse
  User user;     // better

어차피 user엔 user 정보가 들어 갈거니까 Info, Data 라는 건 안써도 된다… 이건 쉽게 까먹을까 적어두자

일관성

여러 클래스에서 add라는 메소드를 쓴다고 새로운 클래스에서 하는 행동이 비슷하다는 이유로 add라고 써야하나 고민하지 말고 사전을 켜고 정확한 행동을 뜻하는 단어를 찾자. append, insert등 대체 가능

함수 인자

가장 베스트는 0개의 인자를 가지는 함수고 다음으로 1개 2개..

writeField(name);                 // better
writeField(outputStream, name);   // worse

위에꺼 보다 아래꺼는 outputStream을 보자마자 주춤하게 된다.

주석

닫는 괄호에 다는 주석을 사용한 적이 있다. 코드가 길어 질 경우 { } 이 괄호가 앞 뒤로 어느 부분에 걸리는지 들여쓰기로도 알아보기 힘들 때가 있어서 달았었다.

나쁜 주석에 속하는 편이라고 한다. 왜냐하면 이 주석이 필요하게 된 이유를 생각해 보면 코드가 길어졌다는 뜻이다. 코드, 함수는 간결하게 작성 돼야 한다는 규칙이 잘 지켜지면 쓸모 없는 주석일 뿐이다.

무릎을 쳤다.

또,

/* created by jungwon.seo */
/* added by someone */

같은 주석도 쓸모가 없다. 코드는 언제든 변하고 사라지니까 나중엔 부정확해지고 무쓸모. 이런건 그냥 git에 맡기는게 좋겠다.

기차 충돌

final String outputDir = ctxt.getOption().getScratchDir().getAbsolutePath(); // worse

기차 충돌이라고 불린다. 그냥 3개 함수를 나누는게 좋다.

예외

의미있는 예외 쓰기

DeviceResponseException;
ATM1212UnlockedException;

그리고 null 반환하지 말자

List<User> users = getUsers();
if (users != null) {
  for (User u : users) {
    // ...
  }
}

여기에 null을 확인할 필요가 있을까? 없을거 같은데 라고 생각하면 잘 한 것!

NHN Ent 4주차 회고

4주차 회고

NHN 신입 개발자 기술교육의 5주차 회고입니다. 이번 주에는 교육이 많았던 한 주 였다. 쉘 프로그래밍.. TDD, 정규 표현식 등등 또 미션도 많이 받고 프로젝트도 할게 굉장히 많았다.

쉘 프로그래밍

흥미로웠던 건 쉘프로그래밍 이었는데 이 전까지 리눅스에서 쉘을 안 써본건 아니다. 수업때도 쉘을 다뤘었고, 맥을 쓰면서도 가끔 만지긴 했는데 역시나 수박 겉 핥기였다. 생각한 것 보다 많은 일을 할 수 있었다. 무엇보다 감탄한 건 역시 단축키… 생산성을 위해선 마우스를 안 쓰는게 좋다고들 한다. 쉘은 마우스를 안쓰니까 단축키가 발달한거 같다. 팀장님께서 많은 단축키를 알려 주셨는데 역시나 손에 단기간에 손에 익긴 어려울 듯하다. 매번 쉘에서 작업하는 것도 아니고.. 아무튼 필요할 때, 정작 써먹어야할 때를 위해 리마인드하고 천천히 익혀나가야겠다.

TDD

TDD는 학교 때 강의랑 특강도 들었고 라이브 코딩도 보며 따라도 해봤다. 기술 교육 때는 Spring에서 사용하는 TDD라기 보다는 우리가 작성한 테스트 케이스를 리뷰해 주시는 형식으로 진행했다. 스프링에 사용할 테스트를 알려 주셨다. 유용했다… 그 중엔 적용하고 있었던 것도 있고 적용 했으나 무작정 쓴 것도 있고 새로운 것도 있었다.

OAuth

OAuth 는 익숙하지 않은 기술이다. 이런 것이 있고 사용되고 있다 정도만 알고 있었다. 네아로를 써보긴 했는데 API가 알려준데로 그냥 가져다 사용한 적이라 실상 이론은 1도 모르고 써봤다. 이번에 수석님께서 자세하게 Payco OAuth를 가지고 설명해 주셨다. 질문도 드렸고 유익한 내용이었다.

다음 주

기술 교육의 절반을 달려 왔다. 이전 까지 열심히 해왔다고 생각하지 않는다. 앞으로 더 열심히 해야 많은 것을 얻어 갈 수 있을 것이다. 하루 하루 미션을 내주시는 의도와 미션을 어떻게 수행해야 하는지를 생각해 깊이 생각해봐야겠다. 개발자의 길을 걸으면서 두 번다시 오지 않을 기술교육의 기회를 어떻게 사용해야 하는지 곱씹어야겠다. 나를 위해 얼마나 많은 분들, 그리고 많은 비용을 투자하고 있는지 감사하며 받아야겠다.

  • 교육은 들으면서 정리한다.
  • 하루에 쓴 노트는 하루를 마무리할 때 다시 한 번 읽는다.
  • 한 주를 마무리할 땐 꼭 회고를 쓰고 한 주 동안 작성한 문서를 다시 읽는다.
  • 궁금한 점은 참지 않는다. 궁금하지 않아도 질문한다.
NHN Ent 2주차 회고

2주차 회고

입사하고 2주가 지났다!

기술 교육

http 기초와 html, css 교육을 받았다. 학부때 웹프로그래밍 수업도 듣고 웹 페이지도 만들어본 경험이 있어서 나름 기본 지식이 있다고 생각했지만 큰 실수였다고 생각한다. 역시 사람은 겸손하고 자만하지 말아야겠다.

생각한 것 보다 더 심오한 기본 지식이 필요한 것이 웹 분야였다. headfirst로 javascript 스터디도 해보고 공모전에서도 웹 페이지를 만들어 봤지만 주먹 구구식으로 만드는데 급급했었던 것 같다. 정작 알아야할 지식들은 모두 묵살하고 진행했음에 후회와 부끄럼을 많이 느낀 한 주였다.

지금 하고 있는 개발도 스프링을 이용하니까 좀 더 알아야할 지식들도 많고 이를 위해선 http와 html, css가 얼마나 중요한지 알 수 있는 계기가 되었다.


그리고 또 후회스러운게 나름 Git을 사용해 봤다고 생각했었다… 부끄럽게도. 생활코딩으로 처음 접했고, 라이엇에서 유석문 기술이사님께도 강의도 오래 받으면서 협업하는 기회도 가져봤다. 이 역시 얼마나 깊이 없이 경험했는지 뼈저리게 느꼈다.

비록 신입사원들 간에 진행하는 이 개발은 큰 프로젝트는 아니지만 협업이 바탕이 되어야 하고 팀워크가 중요하다.

앞으로도 혼자 프로젝트를 진행하는 일은 결코 없을 것이다. 프로젝트를 진행하기 까지의 팀원들 간의 컨벤션 정리, 환경 세팅, 커뮤니케이션 방법 확립 등 먼저 수행되어야 할 것들이 너무나도 많고 이제까지 해온 내가 알던 방식을 뒤엎어야 할 정도였다. 그렇다고 너무.. 1도 도움이 안되는건 아니지만 ㅎ

하지만 좋은 팀원들과 함께여서 난 잘 진행되고 있다고 생각한다. 도움을 많이 받았고, 내가 할 수 있는, 도움을 줄 수 있는 부분을 매번 찾아 팀에 힘이 되고 싶다.


개발 능력도 중요하지만 이런 부분이 팀의 성장에 도움이 많이 될 것이라 생각한다. 앞으로도 많은 경험을 하면서 좀 더 나은 모습을 갖추려고 노력할 것이다.

+ 책을 더럽게 읽자