내 맘대로 월간(月刊) 뉴스 - 2016년 09월

  • 맥에서의 파이썬 개발 환경 자동화(pyenv, virtualenv, autoenv)

    • 파이썬3 덕분에 python -m venv venv로 해결할 수 있어서 너무 편리함
    • 그렇지만 파이썬2를 사용한다면 읽어보자!
  • 파이썬 Docker 이미지 관리하기

    • Docker 이미지 크기가 부담스럽다면 꼭 읽어보자!
  • GDG Korea Android Magazine #16\

    • 안드로이드 스튜디오에서 한글 출력이 안될떄 많은 도움이 되었음
    • 매거진 소식에 '알찬' 내용이 많으니 북마크를하고 둘러보자!
  • #51. 폰트 적용 가이드 및 무료 영문 폰트 20선

    • 좋은 영문 폰트를 소개해줘서 알차게 사용하고 있음
    • 무엇보다 앞부분에 폰트에 관한 기초적인 내용과 몇가지 사소한(?!) 팁이 나오니 폰트에 대해서 궁금하다면 꼭 읽어보자!
  • 소카 타다가 불안과 절망에 빠져버린 이야기

    • 스타트업의 가치를 어떻게 보존하고 사용자에게 전달하는 과정에서 발생하는 문제를 슬기롭게 해결하는 방법이 뭔지 많은 고민을 하게 됨
    • 특히 CS에서 발생하는 문제를 의사결정 권자에게 어떻게 전달하고, 빠른 시간안에 해당 사안을 해결하는지에 대한 절차의 중요성을 다시금 생각해 봄
  • 스타트업 성장통: 의사결정의 병목현상

    • 의사결정의 병목현상이 생기는 이유는 다양하겠지만 결론적으로 병목현상을 해결하는 방법은 '빠른 소통'을 촉진하는 것
    • 급격한 성장통을 겪는 스타트업에 필요한 방법은 무엇일까? RAPID 프레임워크 같은 의사결정이 잘 흐를 수 있도록 하는 소프트웨어가 있을까? Slakc이 답일까?
  • 개발팀장이 필요 없는 이유

    • 글에서 제시하는 방법은 이상적이지만 현실에 적응하기 쉽지 않다. 이러한 일은 개발팀의 문제가 아니라 회사의 '문화' 혹은 'DNA'와 직결되어 있기 때문
    • 그렇다고 글에서 제시한 방법을 이해하지 못하면 성장의 속도를 둔화시킬 수 밖에 없음, 과연 우린 '독이든 독배'를 마시고 성장통을 이겨낼 수 있을까?

    개발팀장이 관리를 전혀 하지 않는다는 것은 크게 두 가지 의미가 있다.첫째, 개발자에게는 팀장이든, 누구든 관리를 시키지 않음으로써 개발에 전념하도록 하고 개발자로서 꾸준히 성장하여 60세가 되어도 개발자로서 경력을 유지할 수 있도록 한다. 둘째, 관리가 필요 없는 조직 문화에서는 개발이 더 효율적으로 진행된다.

  • 마이크로서비스 아키텍처의 장단점

    • MSA의 장단점을 소개하고 있지만, 실제로 도입하기 위해서 넘어야 할 벽은 'MSA'가 아니라는 점은 이 글을 읽어봐도 명확함
    • 내 주변에선 '피자 2판' 정도면 될꺼라고 생각하고 덤볐다가 팀원들의 반반 때문에 이러지도 저러지도 못하는 방법론 중에 하나로 이름 높은 방법론으로 평가받는데, 그 이유는 MSA가 가진 가장 큰 벽은 기존 팀원들의 '관점'을 옮겨야 하기 때문이 아닐까?
    • 비록 분산 환경을 사용하고 있다하더라도 프로그램은 단일 프로세스 컨텍스트 아래에서 동작합니다.
    • 어떤 기준으로 프로젝트를 독립적인 서비스로 나누어야 할까요? [...] 기능은 나누어질수 없으며 다른 기능에 의존성이 없어야 합니다.
    • 초기 단일체 구조 아키텍처로 시작된 작은 서비스가 서비스가 복잡해지고, 조직도 커지고, 팀원의 역량은 충분히 높아졌으면 마이크로서비스 아키텍처로의 진화를 고려하는 것이 좋을 것 같습니다.
  • 클린 코드를 위한 테스트 주도 개발 1

    • 친구들 사이에 '염소책'으로 통하는 TDD 관련 책의 코드를 수정해서 알려줌
    • Django 버전 때문에 염소책으로 고생받는 분들에게 많은 도움이 될꺼라 생각하지만, 생각보다 어려운건 어쩔 수 없는 일이니! 다 같이 힘내세요!
  • Vim의 비주얼 모드와 텍스트 블록 저장과 파일 임포트

    • yark의 모든 것이라 불러도 좋겠음
    • Vim에서 복사를 누가 못하나 싶지만, 그렇지만 복사(Copy)를 잘 하려면 엄청난 노력이 필요함
  • 스타일 가이드로 웹서비스 개발하기

    • 여기, 저기 어디를 둘러봐돠 재사용에 관한 논의가 활발
    • 바쁘다면 styleguide.io를 북마크에 넣어두자!
  • 티몬 모바일 기획자가 하는 일

    • 책에서만 보던 기획을 하는 스타트업이 있다니 그저 놀랍기만 함
    • 상세 기획안이 QA의 기준이 될 정도로 프로세스가 정리되어 있지 않으면 책에 있는걸 적용할 수 없다는 점에서 스스로를 돌아보게 만듬
    • 저희 모바일랩에서는 애자일(Agile) 프로세스의 스크럼(Scrum) 방법론을 채택하여 업무를 진행하고 있습니다.
    • 컨셉에 대한 충분한 공감을 마친 기획자는 내/외부에서 발의된 요구사항들에 대해 정리하기 시작합니다. 이 작업은 고객, 직원, 파트너가 각각 필요로 하는 기능이 무엇인지를 정리하는 과정이라 할 수 있습니다. 요구사항이 정리되면 기획자는 직접 손으로 스케치 해 보면서 요구사항이 녹아든 화면을 그려나갑니다. 그렇게 하나씩 화면을 그리면서 전체적인 플로우를 다듬고 나면 이제 상세 기획안을 작성합니다. 상세 기획안은 뒤이어 진행될 디자인, 개발, QA의 기준 문서가 되므로 꼼꼼히 작성하는 것이 좋습니다.
  • ANGULAR 2 IS OUT - GET STARTED HERE

    • Angular 1.5 버전도 제대로 못쓰고 있는데, ng2가 나온다고 해서 세상이 바뀔리 없음
    • 그럼에도 불구하고 React와 거의 비슷한 구조 덕분에 학습 비용은 충분히 줄일 수 있을 듯
  • '자고나면 연봉 오른다'··· 인기 절정의 IT 기술력 10선

    • 원래 물가는 꾸준히 상승하기 때문에 연봉을 자연스럽게 올라가게 되어있기 때문에 자고 일어나면 연봉은 어떻게든 올라가야 함
    • 그런데 기술력 10선이 뭔가 애매함(빅데이터를 단일 기술로 묶으면... 뭘 어쩌잔 말인가 싶음)
  • 개발자들의 행복지수가 엄청나게 상승했다

    • 'DNA'에 포함된 '밈(Meme)'의 중요성을 읽을 수 있음
    • 직장에서 자신이 하고 싶은 일을 할 수 있다는 것은 굉장한 경험이지만, 자신이 하고 싶은 일을 할 수 있는 잘 하는건 기적에 가까움
    • 따라서 그런 기적의 권능을 가진자들이 불행할리가 없음
  • Airbnb가 앱을 만드는 방식

    • 우리가 시스템을 만드는 이유는 시스템을 만들어야 되기 때문이 아니라 문제를 해결하는 시간을 '확보'하기 위해서임
    • 만드는 방법을 혁신하지 않고는 제품을 혁신할 수 없다.
    • 명료하거나 직접적(direct)이지 않은 것은 사람들 사이에 널리 퍼질 수 없다
  • CQRS란 무엇인가?

    • 적용할 자신이 없는 패턴이긴 하지만 그 필요성에 절대적인 공감을 하고 있기 때문에 따로 공부하기로 마음을 먹었음
    • 에릭 에반스의 DDD부터 다시 시작해야 될 것 같지만, 먼길을 가기전에 지도를 펼치듯 이 글을 시작으로 CQRS라는 긴 길을 걸어볼 예정

    CQRS는 시스템의 상태를 변경하는 작업과 시스템의 상태를 반환하는 작업의 책임을 분리하는 것입니다.

  • [번역] 최신 기술 – CQRS 처음 도입하기

    • CQRS를 공부하시는 분들에게 일독을 권함
  • Auto Scaling Pinterest

    • 오토 스케일링 관련된 자료중에서 가장 현실적인 듯 함
  • 도대체 CPU의 캐시는 왜 L1, L2, L3 같은 다층 구조로 구성되어 있는가?

    • 모으는 것보다 접근성이 중요함
    • 그렇다면 크기를 얼마만하게 잡아야 하는 걸까?

    접근성이 중요하며 지나치게 큰 책상, 즉 여러 캐시 레벨이 한 덩어리여선 안 되는 것

  • abrt를 이용한 Application Crash 디버깅

    • RHEL, Fedora, CentOS를 사용한다면 꼭 읽어 볼 것!
  • 코딩 인터뷰 꼭 해야 하나요?

    • 코딩 인터뷰는 모르겠지만, 한 시간 정도 시간을 내서 같이 간단한 토이 프로젝트 정도는 같이 코딩해 보길 권하고 싶음
    • 단순 게시판, 블로그 등은 한 시간 정도면 충분함
  • 더 빨라진 Android Nougat, 어떻게?

    • AOT에서 JIT으로 변경된 이유에 대해서 매우 자세히 설명하고 있기 때문에 안드로이드 개발자 분들에게 강추!
  • 페이스북에서 배운 크리틱의 4가지 규칙

    • 한국에서 이 4가지 규칙을 잘 사용하기 위해서 가장 중요한 일은 "질문"을 "비난"으로 착각하는 일부터 시작.
    • 요약하면 "역할, 이해, 피드백 그리고 집중"

    특정 질문에 대해 올바른 질문을 하는 것은 올바른 대답을 하는 것보다 더욱 효과적일 수 있다.

  • MS는 ReactiveX를 왜 만들었을까? (feat. RxJS)

    • Reactive의 역사를 알 수 있음
    • Rx계열이 왜 이렇게 인기가 있는지 쉽게 이해 할 수 있음
  • 오픈 소스 라이브러리 쉽게 배포하기 - JitPack

    • Github을 원격 저장소로 사용해서 배포하는 방법을 소개하고 있음
    • Maven 저장소를 왜 안 쓰는지는 별로 궁금하지 않지만 이제 Github을 사용하지 못하면 개발 할 때 뭔가 이상해지기 시작했음
  • 실제로 적용하고 있는 UX 방법론

    • "UX 방법론 개론", 이 글에서 소개한 방법론만 알아도 기획자/UX 설계자와 대화가 한결 쉬워짐
    • 개발자에게 강추!

    사용성 좋은 디자인은 항상 스토리 라인을 가지고 있다

  • 최고의 인터페이스는 인터페이스가 없는 것이다

    • 공자형이 생각나는 제목 때문에 읽었는데, 내용이 심오한 것 같음
    • 그렇지만, 글쓴이의 주장에 대해서 매우 격하게 동감하고 있고 이런 생각에 동의하는 개발자와 함께 뭔가 다양한 이야기를 나누고 싶지만...
  • 8년간의 NoSQL 운용에서 배운 것

    • 개인적인 견해론 개발자의 반발이 더 심한 것 같음

    그가 권하는 방법은 NoSQL을 사용한 현실적인 솔루션을 단기간에 저렴하게 구축하고 그것을 성공의 실례로 상층부에 알리는 것이다

  • 2016/09/01 JSCON 2016 참석 후기!

    • ng2, React에 관한 내용이 압축적으로 포함되어 있음

    내년엔 새로운 기술 트렌드를 소개하는 발표보다는 새로운 기술을 도입 못한 상황에서 최대한 트렌드에 맞게 개발한 사례에 대한 발표가 있으면 회사에 적용해볼수 있지 않을까 라는 생각이 들었다. 우린 IE 7/8을 못버릴꺼야....