180723-180729

2018년 07월 23일 ~ 2018년 07월 29일 주간 회고


180723-180729 주간회고

Weekly Review

  • 이번 주 토요일에는 하시코프 한국 사용자 밋업(HashiCorp Korea User Group MeetUp)을 다녀왔다.
    • 테라폼, 앤서블, 베이그런트 등을 실무에서 어떻게 활용되고 있는지 알 수 있는 좋은 기회였다.
    • 데브시스터즈 분들의 ‘20명 규모의 팀에서 Vault 사용하기’ 발표는 정말 재밌었다. 나도 다음에 어디서든 발표를 하게 된다면 이런 유머와 함께 발표를 하면 관중들이 재미있어하고 더 집중해서 들을 수 있지 않을까 하는 생각이 들었다.
    • 사실 해시코프 제품들을 한 번도 사용해보지 않고 사용해보기 전에 들어놓으면 좋지 않을까 해서 참석했는데 발표 내용들이 쉽게 와닿지 않았다. 그래도 앞으로 어떻게 공부를 하고 사용하면 좋을지에 대한 감을 얻은 좋은 경험이였다.
  • 저번 주부터 시작하기로 했던 알고리즘 스터디가 미뤄져서 다음 주 수요일부터 본격적으로 진행하기로 했다.
    • 알고리즘 문제 해결 전략을 통해 진행한다.
    • 걱정 반 기대 반이지만 후회 없이 많은 걸 공유하고 배울 수 있도록 노력할 것이다.
  • 회사 일도 바쁘고 여러모로 스트레스를 많이 받는 한주였던 것같다.
    • 퇴근 후 개인 시간도 많이 없었고 게으른 한 주(Lazy Week)를 보낸 거 같아 많이 아쉽지만, 다시 마음을 굳게 먹고 열심히 공부할 것이다.

학습

  • 스프링 입문을 위한 자바 객체 지향의 원리와 이해
    • 이번 주는 객체 지향 설계 5원칙 - SOLID, 디자인패턴을 집중적으로 학습하였다.
    • 최대한 빨리 끝내고 스프링을 Deep 하게 공부해볼 것이다!
  • 사내에서 아주 급하게 관리자(admin) 사이트를 개발해야되서 스프링 setting부터 DB 설계까지 혼자서 만들어 보는 좋은 경험을 하였다.
    • 혼자서 처음부터 진행하면서 그동안 알지 못했던 또 다른 많은 것들을 배울 수 있는 좋은 기회였다.
    • 또한 현재 내가 무엇이 부족한지 알 수 있었다.
    • 기간이 너무 타이트해서 스트레스받긴 했지만..얻는 것이 있어서 좋았다.

다음 주 목표 (꾸준히 읽고 정리하고 강의듣기)

이번 주에 읽었던 좋은 글(출퇴근지하철)

  • 아마존 웹 서비스 계정 생성 후 해야하는 IAM 보안 조치 무심코(아니겠지?) 사용했던 AWS IAM(Identity and Access Management) 서비스를 어떻게 사용하는 것이 좋은지 알려주는 정말 좋은 글. 일독을 권한다!
  • 이직일기 - raccony 님 raccony님이 여러 회사의 면접을 경험하면서 겪은 일들을 생생하게 전달해주는 글. 4년 차쯤이면 어떻게 면접을 진행할지 궁금했는데 많은 도움이 되었다. 이제 나도 슬슬 이력서를 주기적으로 업데이트하고 가상 면접, 손 코딩 면접, 알고리즘 스터디 등을 조금씩 준비해 나가야겠다.
  • 라이브러리와 프레임워크와 Spring 프레임워크를 헌법에 빗대어 설명을 하는 것이 인상 깊었고 Spring 프레임워크가 어떤 기준으로 애플리케이션을 운영하는지 알 수 있는 글이다.
    • 라이브러리란 일련의 기능 뭉치
    • 프레임워크란 일종의 규격에 가깝다. 우리는 여러 규격 중 마음에 드는 것을 하나 선택해서, 규격에 맞춰 코드를 짜넣는다.
    • Spring이 하는 일!
      • Spring은 Spring Bean의 의존성을 관리한다.
      • Spring은 Spring Bean의 동작을 관리한다.
    • 개발자는 Spring이 생성하고, 사용하고, 변형할 수 있는 Spring Bean을 이루는 코드를 짜 바친다!
    • 헌법 조문을 명심하고 Spring을 사용하면, Spring이 꽤나 일관적인 기준으로 애플리케이션을 운영함을 다시 한 번 깨달을 수 있다. 
    • 그래서 프레임워크 공부할 때에는 책을 처음부터 잘 읽어보자
      • 새로운 언어도 마찬가지이지만, 새로운 프레임워크를 공부하고자 책을 읽을 때에는 책의 서문부터 주의깊게 읽으면 도움이 될 지도 모른다. 서문의 XX한 프레임워크인 AA는~ 이라거나, 내가 BB를 선택한 것은 YY 때문이다, CC는 특히 ZZ 패턴을 중시하는데 같은 문장은 희미한 예감이 될 것이다.
  • 우아한 형제들 CISO 박성철이 추천하는 자바 서버 개발자를 위한 도서 10권 
    • 자바 8 인 액션
    • 토비의 스프링
    • 이펙티브 자바
    • 클린 코더
    • 클린 아키텍처
    • 빌딩 마이크로서비스
    • 클라우드 네이티브 자바
    • 자바 ORM 표준 JPA 프로그래밍
    • 도메인 주도 설계 핵심
    • 객체지향의 사실과 오해
  • TDD 실천법과 도구 책 전체를 PDF로 공개합니다 채수원님이 테스트 주도 개발 TDD 실천법과 도구 책을 일부분 수정해서 PDF로 공개한다. 책을 중고로 라도 사서 읽어 볼려고 했었는데 너무 좋은 기회가 생겼다! 정말 정말 감사합니다 :)
  • 스프링 부트와 카오스 몽키  스프링 부트용 카오스 몽키 도구를 소개하고, 간략한 사용법을 설명하는 글.
    • 카오스 엔지니어링은 일반적으로 서비스를 테스트의 목적으로 일부러 망가트려 보고, 이에 대한 시스템의 반응을 바탕으로 더 견고한 서비스를 만들기 위한 엔지니어링을 의미한다. 
    • 언뜻 보기에 스프링 부트를 그냥 죽이거나 요청에 대한 응답을 모사하기 위한 간단한 도구로 보일 수 있지만, 테스트 자동화 도구등을 통해 서비스에 함께 구현된 서킷 브레이커나 리트라이(Retry)등의 패턴을 통해 의존 관계에 있는 다른 서비스에 문제가 생겼을때 어떻게 되는지에 대한 실험과 검증의 자동화 방법으로 사용할 수 있는 도구라는 점이 중요하다.
    • 실제 서비스에 문제가 되더라도 장애를 극복할 수 있는 애플리케이션 테스트에 사용할 수 있다는 점에서 카오스 엔지니어링 부분에 상당히 중요한 도구라고 할 수 있다.
  • AWSKRUG #enterprise 소모임 2018.06.11 참석후기 “개발자의 길 : 김재완님”의 세션 후기, 너무 좋은 말이 많아서 정리 해볼려고 했는데 그냥 그대로 복사 한것 같다…
    • 개발자, 그대는 누구인가? - 퍼펙션을 추구하는 여정
    • 개발자의 역할
    • Builder
      • 무언갈 만드는 사람
      • 많은 사람들은 개발자를 Builder로 끝난다고 봄
    • Detective
      • 장애가 발생했을때 뭐때문에 났는지, 뭔가 문제인지 발견
      • 한 길만 고집하면 이런 디텍팅 능력을 갖추기가 힘듬
      • 버그는 의도하지 않는 기능 (피쳐)
      • 어디에나 항상 존재
      • 미스테리란 없다
    • Designer
      • 시간이 지나면 개발자도 Designer가 될 수 있다고 봄
      • 코딩 하는 사람이 디자인을 해야한다고 생각
      • 코드 디자이너, 시스템 디자이너, 인터렉션 디자이너
      • 요구사항을 본인이 이해하고, 머릿 속에 그림을 그린 뒤에 코딩을 해야함
      • 단순한 디자인이 최고
        • SOLID 원칙
        • 원서: Don’t make me think (번역: 생각하게 하지마)
    • Mechanicla Sympathy
      • 우수한 드라이버는 드라이빙만 잘하면 됨
      • 최고의 드라이버가 되려면 어떻게 돌아가는지를 알아야함
      • 현대의 많은 기술들이 추상화를 강조
      • 최적화의 키는 기대값을 받는 것 (1ms가 나오겠다고 했으면 1ms가 나오는게 최적화)
      • 계속 100이 나오는건 괜찮지만, 어떨때는 1이 나왔다가 어떨때 1000이 나온다면 최적화가 필요함
      • 최적화는 빠름을 얘기하는게 아니다. 내가 기대한 값이 나와야 하는 것을 의미
    • Communicator
      • 요구사항을 제대로 이해하려면 커뮤니케이션이 잘 되야함
      • 소통에도 기술이 있음
    • Developers are Engineers
      • 창의적인 솔루션을 만드는 사람
      • 모든 걸 다 만들진 않고, 있는걸 가지고 창의적인걸 만드는 사람
      • 과학자와는 다름. 과학자는 없는걸 증명해야함
      • Feynman Algorithm
        • 문제를 작성한다
        • 굉장히 깊게 생각한다
        • 답을 적는다
        • 여기서 사람들은 2번째인 깊게 생각하는게 어렵다고 생각하지만, 중요한건 1번이다
        • 문제를 어떻게 정의하냐에 따라 해결이 된다.
  • (번역) 만든 건 직접 관리하라 넷플릭스의 사례  
    • 개발팀과 운영팀이 분리되어 있을때는 문제를 해결하는데 더 많은 시간이 필요했다. 각 팀간의 커뮤니케이션 과정, 관련 지식 전달 과정 등으로 시간 낭비
    • 소프트웨어 개발의 생명 주기를 구분하는 이유는 ‘아이디어가 실제로 고객이 사용할 수 있게 배포되는 데까지 걸리는 시간’을 개선하기 위해서다.
      • Design > Develop > Test > Deploy > Operate > Support
    • “개발한 것을 직접 운영하라”라는 문장은 개발팀이 자신이 개발한 코드와 관련한 운영과 지원 업무에 함께 참여함으로써, DevOps 원칙을 직접 실천하도록 했다.
    • 결론은 해당 방식을 사용함으로써 수많은 이점을 가져다주었다.
  • 구글, EU에 반격…”안드로이드 공짜시대 끝” 구글의 안드로이드 비즈니스가 반독점 행위에 해당된다면서 43억4천만 유로(5조6천억원)에 이르는 거액의 벌금을 부과한 유럽연합집행위원회(EC) 조치에 강하게 반발하는 내용이다. 제목은 자극적이지만 실제로 끝이 아니라, 경고 메세지를 날린 셈이다. 
facebook share twitter share
0%