180716-180722

2018년 07월 16일 ~ 2018년 07월 22일 주간 회고


180716-180722 주간회고

Weekly Review

  • IntelliJ를 시작하시는 분들을 위한 IntelliJ 가이드 창천향로님의 강의를 신청하였다.
  • Geth를 이용해서 private network 구성 후 서로 다른 PC 간의 송금 테스트를 진행하였다.
    • 지난번에 하나의 PC에서 두 계정으로 진행하고 블로그 글을 썼었는데 여러 PC에서 테스트하는 방법을 같은 글에 업데이트하였다.
  • 회사 점심시간에 SQL이란: 데이터 쿼리와 관리 칸아카데미 SQL 강의를 듣고 코딩을 지탱하는 기술을 읽었다.
    • 길지 않은 시간이라 조금씩 밖에 진행을 못 하지만 이렇게라도 짬짬이 시간을 사용해야 한다. 하고 싶은 건 많고 시간은 부족하고..
  • 다음 주 토요일에 진행하는 하시코프 한국 사용자 밋업(HashiCorp Korea User Group MeetUp)을 신청하였다.
    • 테라폼, 앤서블, 베이그런트 등을 주변에서 자주 듣고 있는데 어떤 용도로 쓰이는지 잘 모르겠고 어떤 것인지 너무 궁금했다. 그래서 신청하였다. 현업에서 어떻게 사용되고 있는지 직접 듣고 느낄 수 있는 좋은 기회가 될 것 같다. 잘 모르니깐 다음 주에 계속해서 공부를 해보고 감을 잡은 뒤 토요일에 참석해야겠다.
  • 다음 주 수요일에 진행하는 Golang Korea MeetUp in Seoul 밋업을 신청하였다.
    • Java를 제외하고 학습하고 싶은 언어가 있다면 첫 번째가 Go lang인 만큼 여러 이유에서 관심이 가는 언어이다.
    • 근데 아직 주언어인 java에 집중을 해야 하다 보니 Go 언어를 공부할 시간이 많이 부족하다.(변명일 것이다…) 그래서 신청하게 되었다. 더 많이 봐서 Go lang 학습 욕구를 고취시키기 위하여!

학습

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

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

  • Serverless와 기술도입, Backend Application의 미래 이 글을 첫 번째에 위치시킨 이유가 있다. 꼭 읽어보길 바란다.
    • 여러분의 기술 선택은 안녕하십니까?
      • 우선, 많은 팀들이 “기술 선택” / “기술 도입” 이라는걸 매우 추상적으로, 그리고 거대 트렌드 차원에서만 생각하고 실행한다는 생각이 든다.
      • 기술은 언제나 상황과 맥락에 따라 그 가치가 달라지고, 회사나 팀마다 상황이 분명히 다 다르다. “100% 나쁜 기술” “100% 좋은 기술” 이런건 단언코 없다.
    • 기술 선택은 팀과 비즈니스를 위해서
    • 개발자들이 일을 안해야 서비스가 죽지 않는다(?)
      • 정리해보면, 내가 새로운 기능을 만들고 배포할때의 2가지 문제
      • Application 자체가 너무 커서 기능간의 dependency가 많아 배포할때 다른 기능까지 터지는 경우가 잦고
      • 실제 business logic 작성 이외에 Monitoring / Scaling / Deployment 등이 너무 귀찮다
    • 람다를 사용 -> 개발을 시작하기도 전에 운영때문에 사고를 차단하는 일을 줄여 줬다.
    • Backend Application 개발의 미래
      • Backend Application을 만드는 방법은 몇가지 단계를 거치며 변화해 왔다.
      • IDC에 있는 거대한 서버 컴퓨터에 Application을 올린다.
      • Cloud에 있는 가상화 된 서버 컴퓨터에 Application을 올린다
      • Cloud에 있는 가상화 된 서버 컴퓨터에 Container를 올리고 (Docker+ ECS / Kubernetes 같은) Application을 Container Image로 만들어 올린다.
    • 여기서 읽어낼수 있는 트렌드는 물론, “개발자들이 좀더 편하게 Business Logic 작성에 집중할수 있도록” 일거다. 최대한 Scailing, Failover, monitoring 같은 infra 관리와 관련된 것들을 자동화 하는 것이 트렌드
    • 자연스럽게도, 저는 Serverless가 그런 트렌드의 미래라고 생각합니다. 그게 AWS같은 Cloud Vendor들이 막대한 투자를 하고 있는 이유
  • 서버리스에 대해 알아보자
    • 서비스 초기 모델에서는 기존의 방식인 Monolithic을 따르고, 그 이후 여유가 생긴다면 점진적으로 serveless 아키텍쳐로 이주하는게 좋을 것 같다.
    • 작성자의 아주 주관적인, 서버리스 Best Practice
      1. Monolithic 아키텍처에서 파일 업로드 기능을 따로 lamda로 빼서 구현한다.
      2. 미디어파일 업로드 시에 다양한 크기의 썸네일을 만들어야 할때
      3. 크롤링, 배치, 스케쥴러를 lambda로 구현한다. 별도의 인스턴스를 대여하는 것은 비교적 비쌈.
      4. Third Party 서비스(챗봇)에서 특별히 REST API를 필요로 할때
      5. 서비스에 OAuth 2.0을 직접 구현하려 할 때
      6. 버킷에 저장된 로그들을 Elastic Search로 전송할 때
      7. 인스턴스 Docker로 접근해서 모니터링 기능을 구현하고자 할 때
    • Serverless를 운영하면서 가장 중요한 것 세가지
  • RedisConf18 발표 후기 미국 샌프란시스코에서 열린 RedisConf18 컨퍼런스에 발표자로 참가한 최종열 님의 Review, 정말 멋있다. 나도 지금은 턱없이 부족하지만 시간이 지나 많이 성장하게 된다면 외국 컨퍼런스에서 발표… 꼭 해보고 싶은 버킷리스트 중에 하나!
  • 신입 개발자 & 학생을 위한 Spirng MVC Setting Eclipse를 이용하여 Spring 환경 setting을 자세하게 알려준다. 평소에 헷갈렸던 부분을 다시 한번 정리할 수 있는 기회다. 현재 계속 연재 중!
  • 좌충우돌 ORM 개발기 : 자바 ORM 표준 JPA 프로그래밍 책의 저자인 김영한 님의 발표 자료. JPA의 필요성, 스프링 데이터 JPA, Query DSL을 활용한 개발 방법 등을 설명한다. JPA를 공부하면서 복습 자료로 같이 보자!
  • IDC 1도 모르는 개발자가 DevOps를 만났을때 MY MUSIC TASTE 안주은 님의 발표자료. Multi-region deployment 부분은 현재 내가 다니고 있는 회사에서도 해결해야 하는 문제라서 기록!, 이외에 MSA, SPA 등의 내용을 볼 수 있다.
  • ECS를 시작하기전 알았으면 좋았을 것들 - 1.용어 설명 지난번에 AWS KRUG Container Hands-on에서 Docker를 실습하면서 ECS를 잠깐 써본 적이 있었다. 당시에는 ECS에 대한 이해 없이 실습만 따라 하느라 용어에 대한 이해가 전혀 없었는데 이 글을 읽고 ECS를 구성하는 5가지 요소에 대한 용어 정리가 된 것 같다.
  • IT 개발자를 위한 글쓰기 가이드
    • 기술 계통 사람에게 완벽한 문법이나 문장을 기대하는 이는 드물다. 그러나 사람들이 이해할 수 있는 방식으로 사실을 명확히 전달할 수 있을 것이라는 보편적 기대치는 존재한다. 이러한 기대에 부응할 수 있느냐 없느냐는 소프트웨어 개발 조직의 리더가 되느냐, 아니면 혹독한 유지보수 코드를 모두 떠맡는 일꾼이 되느냐를 가르는 차이가 되는 경우가 많다.
    • 목적
      • 글을 쓰는 첫 단계는, 기술적이든 또는 다른 경우이든, 목적(purpose)을 생각하는 것
    • 독자
      • 독자가 더 구체적일수록 이들에게 더 많은 말을 할 수 있으며, 더욱 효과적인 글이 가능해진다
    • 디테일
      • 목적과 독자에 따라 해당 글쓰기의 디테일이 크게 달라진다.
      • 개론적 수준의 글에서 구성(configuration)을 상세히 다룬다면 그것은 실수일 것이다. 반면 참고자료나 사용설명서를 쓴다면 구성을 명확히 해야 할 뿐 아니라 이들을 중심으로 문서를 구조화해야 한다.
    • 전술 및 과정(Tactics and process)
      • 양질의 작문을 보면 대개가 ‘글을 읽어야 하는 이유, 내용 소개, 가장 중요한 팩트와 이를 지지하는 상세 설명, 그리고 최종적으로 결론’이라는 기본적 구조를 갖는다.
      • 이를 달성하는 데에는 2가지 방법이 있다. 하나는 일단 쓰고 나중에 편집하는 것이고, 다른 하나는 개요를 꼼꼼히 잡은 후 디테일을 채우는 것이다.
    • 밈과 언어(Memes and prose)
      • 개발자들은 흔히 길게 늘어뜨리는 경향이 있다. 이를 피하라. 일반적으로 밈, 격언, 강력한 말은 짧은 문장들로 이뤄진다. 경험으로 볼 때, 음절이 가장 짧은 단어를 사용하고, 의미를 전달할 수 있는 최소의 단어 수를 사용하는 것이 좋다.
    • 연습
      • 글 쓰는 것을 좋아하는 사람이 그렇게 많지는 않을 것이다. 그러나 글을 효과적으로 쓰는 개발자는 단순히 코딩만 하는 개발자보다 더 빨리 발전한다. 주로 이는 자신의 설명에만 몰입하지 말고 목적과 독자를 염두에 두는 것을 배우고 연습하는 문제이다. 개요를 잡고, 글을 쓰고, 이후 편집하든, 또는 말을 하고 이를 필사하든, 자신에게 가장 잘 맞는 방법을 시도하라. 여러 문장 구조 및 문구들을 실험하고, 가장 ‘점착적인’ 것을 결정하라. 무엇보다도, 잘 될 때까지 이를 계속하라.
  • 당신이 아무리 책을 읽어도 제자리인 이유 : Youtube 영상 이 영상에서 설명하는 남는 독서하기 2가지 Point : 재독 + 계독
    • 다시 읽기(재독)
      • 좋은 책은 무조건 다시 읽기
      • 옮겨 적기
      • 원서로 다시 읽기
    • 깊게 읽기(해당 분야의 도서 여러권, 계독)
    • 어떻게 읽을 것인가 책 추천
    • 인생에서 할 수 있는 가장 리스크가 적은 투자 = 독서
  • 9년 만에 5억 모은 이야기, 사회초년생 직장인분들께 초기에 소소한 절약습관 정립하고 무작정 많이 모은다도단 경제관념(은행 상품, 경제 동향 등)에 밝아야 한다!
    • 도시 월세 -> 전세대출을 껴서 반드시 전세로 전환 (버팀목전세대출!)
    • 월급 다 저축하고 이자로 살자라는 경제관념 조기 확립
    • 대형마트의 할인 시간대, 전통시장의 저렴함 이용
    • 외식대신 요리, 주유할인, 생필품 등 최대한 아낌
    • 저축(사회생활 초반에 모으기 시작에 9년만에 5억 모이니 그 이후엔 큰 노력을 하지 않아도 자산효과 발생!), 주택청약저축(3년 동안 매달 2만원씩 72만원 무조건 저축! 나중에 765만원 아껴짐)
facebook share twitter share
0%