GeekNews Weekly

분해,자동화,고객중심 구성.
"팀은 서비스를 완전히 소유하는 작은 팀으로 나눠집니다. EC2도 2피자 팀으로 시작했습니다"

기술 부채는 대부분 안좋다고 얘기됨
돈빌려서 집을 사면 축하해주는데, 왜 기술은 안그럴까 ?
중요한 차이점은 "빚을 진 의도가 무엇인가?" 임

글에서 얘기한 세가지 좋은 기술 부채들
- Scaffolding
- Hardcoding Things
- Not Fixing All the Edge Cases

중요한건 "Good Tech Debt is Intentional"

빠르게 성장하고, 비용과 시간을 절약하기 위해 의도를 가지고 부채를 지는것은 괜찮다.
그 기술부채의 한계를 잘 알고 잘 정리해서 나중에 개선할수 있게 하자.

"실제로 프로젝트에서 사용되는 커밋 메시지는 간단하기 그지 없습니다. 문법도 중학 영어 수준이고, 어려운 단어 역시 사용되지 않습니다. 결국 커밋 로그 메시지의 작성은 작문이 아니라 패턴으로 접근해야 합니다. 자신의 커밋이 가진 특징을 패턴에 대입시켜 단어들을 뽑아내는 것이죠. 작문의 결과로 보면 너무 단순해서 부족해 보일지 몰라도, 여러 사람들에게 쉽게 읽히고 쉽게 이해되도록 하기에는 패턴화된 단순한 문장이 훨씬 낫습니다.

그럼에도 불구하고 커밋 메시지를 쉽게 쓰는 것은 어렵습니다. 첫째, 한 문장으로 설명이 가능하도록 작업을 쪼개어 커밋하는 것 자체가 쉽지 않습니다. 둘째, 작성한 당사자가 아닌 처음 보는 제3자가 이해할 수 있는 문장을 만들어야 합니다. commit -m을 입력한 후, 메시지 입력창이 나타나면 눈을 감고 크게 한숨을 내쉬면서 작업한 내용을 돌아보세요. 그리고 최선의 한 단어를 선택해보세요."

스타트업에 취업하고픈 사람들을 위한 지역사투리 정리.
아는 사람들에겐 유머, 모르는 사람들에겐 정보.

Micros 라는 PaaS를 통해 1000개가 넘는 서비스들이 호스팅중.
해커톤에서 만든 코드부터, 실제 플래그십 제품까지 모두 포함.

굉장히 중요한 서비스지만, 실제로는 간단히 구성됨.
- Docker 이미지 : 서비스 로직
- 서비스 설명을 담은 YAML
== DB,큐,캐쉬 등 필요로 하는 리소스 정의
== 오토스케일링 특성 같은 다양한 설정들

나머지 모든 일들은 Micros 에서 처리
= Log Aggregation , Monitoring , Alert
= 멀티 AZ, 백업/리스토어/리텐션 설정 등

개발한 부분이 많지는 않고 대부분 AWS 의 기능을 이용함.

** 이렇게 PaaS 를 구성하는 이유

- 사내 표준 도구 및 프로세스와의 통합하는게 개발을 쉽게함
- 서비스들에 폭넓게 적용되어야할 변경들이 단순화 되고 예측할수 있게 됨
- 소수 엔지니어의 전문기술들이 몇배로 증대됨(multiplied)
( 사내에 PostgreSQL 전문가는 얼마 없지만, Micros 에만 적용하면 회사 전체가 이득 )
- 플랫폼을 개선하는 작은 시도들도 회사 전체에 영향을 미치게 됨
- AWS의 새로운 피쳐들도 점진적으로 기존의 보안이나 규정을 지켜가며 추가됨.

물론 이 방식이 다 좋은것은 아니고, 새로운 AWS 기능을 실험하기 힘들기도 하고, 다른 3rd 파티 도구들이 Micros 와 연계가 안될경우도 있음. 그래서 내부적으로 PaaS 의 기능 추가하는 프로세스를 만들어놨음.

이 PaaS 는 내부 엔지니어와 AWS 사이를 가로막는 장벽이 아니라, AWS 의 인프라를 더 많이 보여주도록 하고 있음. 계속 발전 시켜 나갈것임

트래킹이 뭔지에 대한 정의부터 어떤 트래킹을 방지하는지, 기능제한이나 사전 사용자 동의가 이뤄졌을때의 내용, 이렇게 차단됨으로써 발생하는 일들을 웹킷이 어떻게 대응하는지 등을 정의.

기본적으로 숨겨진 모든 트래킹과 크로스 사이트 트래킹을 방지.

20개 이상의 장르, 장르당 46시간 이상의 음악들.
뽀모도로 기법을 적용해서 스트레치 & 휴식시간 알림 기능.
장르 선택해서 감상가능. 광고 및 기타 방해가 되는것 없음.

데이터에 대한 역사부터 요즘의 데이터 활용 사례까지를 얘기하는 수업자료.

계속하려면 돈이 중요하다.

결론
1-자신의 문제를 풀어라
2-빨리 남에게 보여줘라
3-빨리 배포해라
4-돈받는걸 두려워하거나,챙피해하지마라
5-니 작업의 가격을 매기는데 남의 의견을 듣지마라

Dropbox 는 2013년 시작할때 양플랫폼간에 공유하기 위해 C++을 사용.
그때는 팀이 작았고, 빠르게 성장하는 모바일 로드맵을 지원하기 위해서 였음.
현재는 Swift 와 Kotlin 을 이용하는것으로 바꿨고, 이것은 코드 공유를 위해 드는 아래와 같은 숨겨진 비용 때문임 ( 사실 별로 숨겨지지도 않음 )

- 커스텀 프레임워크와 라이브러리에 따른 오버헤드
- 커스텀 개발 환경의 오버헤드
- 플랫폼간의 차이점을 처리하는데 따른 오버헤드
- 개발자를 교육하고 채용하고 유지하는데 드는 오버헤드

결론적으로 한개의 코드로 쓰는건 좋아보이지만, 오버헤드가 크다는거
이 글의 마지막 패러그래프는 "Android / iOS 개발자 뽑아요!" 인게 중요

핵심은 쿠팡이 얼마나 사람들의 일상과 습관을 길들이고 있는가가 아닐까 싶다. 쿠팡은 그걸 해내고 있는 것으로 보인다. 그런 부분에서 10대와 50대 이상에서 폭발적으로 사용자가 증가한 쿠팡의 모습은 의미가 있는 것 같다.

우리는 왜 ‘넵’을 쓰는가. 아직 뚜렷한 치료법이 발견되지 않은 ‘넵’병에 대해 알아보자.

참고사항 2가 킬링포인트 인듯.

이미지/자바스크립트/CSS/써드파티 JS코드/웹폰트/네트웍 최적화 방법과 성능측정하기.

기존에 공개된 가이드에 써드파티 JS 관련 글이 3개 추가됨
- Third-party JavaScript performance
- Identify slow third-party JavaScript
- Efficiently load third-party JavaScript

필요없는 코드와 단계 제거하고, 루핑횟수와 계산을 줄이고, 빌트인 메소드를 잘 이용하고, 하고자 하는 작업에 알맞는 객체를 사용하고, Async 와 코드분할하기.

아마존은 100ms의 지연이 1%매출을 감소시킨다고 했고, 구글은 검색페이지 보여주는데 500ms 시간이 늘면 20% 트래픽이 감소한다고 했음.