180827_180902

2018년 08월 27일 ~ 2018년 09월 02일 주간 회고


180827_180902 주간회고

Weekly Review

  • 자바 카페 커뮤니티에서 진행하는 스프링 5 레시피 스터디에 참가하게 되었다.
    • 다음주 토요일에 OT를 시작으로 매주 토요일 오전에 진행하게 된다.
    • 스프링을 조금 더 깊게 공부하고 싶었는데 이번 기회에 확 끌어 올려봐야겠다!
  • 트레바리 모임의 이번 달 책 : 헤르만 헤세 - 데미안을 완독하였고 오늘내일해서 독후감을 작성할 것이다.
  • 8/31 금요일 저녁에 Popit 멘토링 데이에 참석하였다.
    • 멘토 두 분(남윤님, 대희님)과 정말 많은 얘기를 나누었고 끝까지 하나라도 더 알려주려고 하는 모습이 너무 감사했다.
    • 운 좋게 카프카 책도 얻었고 뜻깊은 하루였다. :)
    • popit

학습

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

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

  • 스타트업의 업무용 컴퓨터 선택하기 무엇이 되었던 자신에게 맞는(사용 용도, 디자인 등) PC를 사용하면 최고의 퍼포먼스를 낼 수 있다고 생각한다. 하지만 아이맥은 좀 부럽다. ^~^
  • 세계에서 가장 성공한 리버스 ICO로 부터 배워야 할 것 블록체인기반 사업은 경쟁회사가 하고 있는 사업이 아닌, 경쟁회사가 아예 시작조차 할 수 없었던 사업이어야 한다. 블록체인 기반 사업은 “중앙화된 서비스보다 더 잘하자”가 아니라 “중앙화된 서비스가 못하는 것을 하자”는 철학에서 시작해야 한다.
  • 2018년 상반기 회고 : 창천향로님 엄청난 자극이 된 창천향로 님의 상반기 회고 글. 매번 그렇지만 또 한 번 배우게 된다. 
    • 나는 신기술 쓰는걸 정말 싫어한다. 그 기술을 썼다가 문제가 발생하면 해결을 해야한다. 나만의 만족으로 썼다가 문제 나서 해결 못하는 것만큼 꼴불견은 없다고 생각한다. 새로운 기술, 새로운 모델을 쓰는건 현재 환경에선 더이상 문제를 해결할 수 없다고 느낄때만 엄청 엄청 부담감을 느끼면서 적용한다.
    • 대신 백엔드의 전반적인 기본기를 잘 쌓고 싶다.  네트워크, 리눅스, RDBMS, 메세징 서비스, 시스템 디자인, DDD, 테스트 코드, 클린 코드, 리팩토링 등을 더 잘하고 싶다. 이 중에서 특출나게 잘하는게 없을수도 있지만, 그래도 두루두루 기본은 했으면 좋겠다. 풀스택 개발자, DevOps 엔지니어와 같은 그런 거창한 단어를 붙이고 싶은게 아니다. 그냥 백엔드 개발자로서 어떤 문제가 발생하면 Java 코드만 쳐다보는 개발자가 되고 싶지 않다. 문제를 해결할 수 있는 개발자가 되고 싶은거다.
    • 나는 어떤 기술을 익힐때 항상 예습과 복습만 한다. 회사에서 쓰고 있는 기술을 좀 더 확실히 제대로 사용하기 위한 복습과 회사에서 앞으로 쓰게 될 기술을 미리 연습해놓는 예습 2가지만 한다. 무조건 회사가 기준이다. 회사에서 쓰지 않을 기술에 대해서는 일절 관심 없다. 결국 트래픽 맞아봐고 비지니스에 녹여봐야 내 것이 되는데, localhost:8080에서만 쓸 기술에 대해서 관심 없다.
  • “마이크로 서비스는 답이 아니었다” 세그먼트가 모놀리틱으로 돌아온 이유
    • 마이크로 서비스를 사용하지 않으면 정상적인 서비스를 제공할 수 없을 때(그만큼 규모가 있을 때) 그때 사용하는 것이라고는 익히 들었다. 이 기사에서 말하는 상황은 아마 굳이 사용하지 않아도 되는 규모였음에도 무리해서 사용한 것이 아닌가 싶다. 그리고 이 기사에 대해서 손권남님이 페스이북에 남긴 글이 있다. 기사를 한 번 읽고 스스로 생각해본 뒤 보면 도움 될 것 같아 남긴다.
  • GitHub 하나로 1인 개발 워크플로우 완성하기 : 실전편과 GitHub 하나로 1인 개발 워크플로우 완성하기 : 이론편 이슈 기반 버전 관리 워크플로우에 대해서 확실히 감을 잡게 해준 좋은 글이다. 항상 혼자 개발할 때도 이슈 생성해서 브랜치 따고 개발해야지라고 생각했지만 실천하지 않았던 나로서는 많이 반성하게 되고 지금이라도 해당 글에서 설명하는 것처럼 이슈 기반으로 버전 관리를 진행해봐야겠다는 생각이 들었다. 아래는 이슈 기반 버전 관리 워크플로우.
    • ① 새로운 이슈를 열고 번호를 확인한다.
    • ② 로컬 저장소에 새로운 브랜치를 생성한다. 형식은 “이슈 번호-설명”.
    • ③ 이슈에 적어둔 목표를 해결한다. (오직 이슈에 적힌 내용만 작업한다)
    • ④ 작업을 테스트하여 제대로 완료됐는지 확인한다.
    • ⑤ 수정 사항을 커밋하고 푸시한다. (github이 커밋을 추적할 수 있도록 커밋 메시지 안에 이슈 번호를 적어야 한다)
    • ⑥ 작업이 잘 완료됐다면 작업 브랜치를 메인 브랜치에 병합(merge)한다.
    • ⑦ 이슈에 모든 내용이 잘 기록됐는지 확인하고 이슈를 닫는다.
  • 가장 현대적인 웹을 만들자 3편(GraphQL) GraphQL이 무엇인지, 기존 REST API 방식과 어떤 차이가 있는지에 대한 궁금점을 어느 정도 해소할 수 있었던 글이다. 앞으로 GraphQL이 어떻게 발전해 나갈지 매우 궁금해진다.
  • 모던 아키텍트에 대해 개념 잡아보기 
    • 산업 분야와 상관없이 우리 산업이 처한 공통적인 문제를 가려 뽑고자 할 때 가장 많이 제기된 키워드는 ‘개념설계conceptual design’ 역량의 부재였다. 개념설계 역량은 제품개발이 되었건, 비즈니스 모델이 되었건 산업계가 풀어야 할 과제가 있을 때, 이 문제의 속성 자체를 새롭게 정의하고, 창의적으로 해법의 방향을 제시하는 역량으로서 … - 이정동 교수
    • 개발표준이라고 프레임워크나 기반 솔루션을 정하던 시대는 끝났다는 주장이다. 작명 원칙이라고 의미를 모호하게 만드는 약어같은 규칙을 강제하거나 XML 등의 형식으로 획일화를 강조하던 시행착오를 당장 그만두자 -한 명의 전지전능한 아키텍트가 개발자를 통제하던 시대는 갔다. 이제 개발자에게 자유를 허하라.
    • 우리는 현재의 시장/산업에 적응해서 앞으로도 10년 이상 직업생활을 누리려면 이제라도 빨리 눈치채야 한다. 이미 개발자들은 과거 제조업의 생산자 역할을 하고 있다. 흥미로운 사실은 정해진대로 일하는 생산직 노동자가 아니라 주체로 판단하여 전통적인 제품과 서비스를 바꾸는 역할을 해야 한다.
  • Tabnabbing 공격과 rel=noopener 속성 아무 생각 없이 _blank를 썼었는데 피싱이 가능하다니.. 주의해서 사용해야겠다.
  • 칸반 칸반이 무엇인지 이해하는데 많은 도움이 될 수 있는 글
  • 웹 프로젝트는 PWA이어야 한다 전적으로 PWA 도입 시 장점에 대해 설명하고 있는 글이다. PWA 과연 앞으로 대세가 될 것인가? 조금 더 공부해볼 필요가 있는 것 같다.
    • 프로그레시브 웹 앱이 너무 기술적으로 보이거나 현실 프로젝트의 요구보다 너무 과잉된 것으로 보일 수도 있다. 그러나 실제로는 그렇지 않다. PWA는 높은 품질의 웹 경험을 만들기 위한 지름길일 뿐이다. 사용자의 삶에 절대적인 차별성을 주는 경험 말이다. 
  • Hashed Report: 비탈릭 부테린과 댄 라리머의 이더리움 vs. EOS 논쟁 해설 단순한 논쟁이 아닌 이더리움과 EOS의 장, 단점이 잘 드러나는 글이다. 점점 흥미진진해지는데 과연 미래에는 어떤 플랫폼이 블록체인 시장의 주도권을 잡게 될까? 
facebook share twitter share
0%