출처 : http://m.news.naver.com/read.nhn?mode=LSD&sid1=001&oid=008&aid=0003492855 4.어려운 문제에 무턱대고 덤비지 마라 어렵고 힘든 문제에 부딪히면 지레 겁을 먹기 쉽다. 아니면 무대포로 앞뒤 재지 않고 그냥 밀어붙인다. 그러나 구글과 페북에서 근무하며 얻은 지혜는 어렵고 덩치 큰 문제를 만나면 작게 쪼개서 각 부분별로 해결책을 찾는다는 것이다. 이렇게 부분별로 찾아진 해결책이 모아지면 원래의 덩치 큰 어려운 문제는 자연스럽게 풀리게 된다. 문제가 어려우면 어려울 수록 잘게 쪼개자. 잘게 쪼갠 문제를 해결하다 보면 전체 문제가 풀릴 수도 있다. 하지만 동시에 문제의 전체적인 모습을 보는 것도 게을리하면 안된다.

(예를 들어) 분명 물리적으로 10개월이 필요한 일이 있다. 일정이 급하다고 6개월내 해 내라고 한다. 열심히 하지만 결국 6개월 기한은 넘어가고 겨우겨우 (담당자들이 개고생해서) 8개월 혹은 9개월내 일을 마친다. 그리곤 말한다. (6개월을 요구했던 이들은) 처음에 6개월을 여구했으니까 8개월내 해낸거라고. 처음부터 10개월을 이야기했으면 못했을 거라고. 하지만 경험상 저런 경우 8개월내 끝나기 보다 12개월이 걸리는 경우가 많다. 무리한 일정은 부실한 설계와 엉성한 구현을 만들어내고 버그로 인한 재작업을 유도한다. 이때 책임은 누가 져야 할까?

스스로 잘한다고 공공연하게 말하는 친구의 말은 믿을 수가 없다. 자기가 잘하는 단 하나만 생각해서 잘한다고 말하지만, 그게 SW 개발자가 가져야 할 모든 건 아닌데. 그것도 깨닫지 못하는 걸 보면 잘한다고 자만하는 건 스스로의 착각. 남들의 인정을 받는 지 의문. 혹은 남들이 자신과 함께 일하고 싶어 하는 지 한번이라도 생각해 봤으면. 또 저런 친구들의 착각은 남들이 자기랑 함께 일하기 싫어하는 이유를 자신이 너무 잘나서 라고 생각한다는…

대부분의 개발자는 현업에서 선배 개발자들이 작성한 코드를 유지보수하면서 코드 작성 방법을 배우게 됩니다. 회사에 따라 다르긴 하겠지만, 이렇게 접한 대부분의 코드는 겨우 겨우 동작만 하지, 코드의 가독성이나 유지보수를 거의 생각하지 않고 작성된 코드일 확률이 높습니다. 이런 코드를 읽고, 어떻게든 돌아가게 수정하는 훈련만 하다 보면 애시당초 코드를 잘 짠다는 게 무엇인지 알기가 어렵게 됩니다. 출처 : http://wp.me/p66O1q-3j 평소 내가 가진 생각과 비슷하다. 코드는 작성하는 게 1이면 읽는 게 9라고 한다. 그 만큼 기계가 아닌 사람이 읽는 것의 대상이 되는 경우가 많으므로 읽는 작업에 도움이 되도록 coding style의 정리가 반드시 필요하다고 생각한다.

출처 : DPDK mailing list Coding Style Description This document specifies the preferred style for source files in the DPDK source tree. It is based on the Linux Kernel coding guidelines and the FreeBSD 7.2 Kernel Developer’s Manual (see man style(9)), but was heavily modified for the needs of the DPDK. General Guidelines The rules and guidelines given in this document cannot cover every situation, so the following general guidelines should be used as a fallback:

출처 : Docker 무작정 따라하기 참고 : 가장 빨리 배우는 Docker

p13 나는 사업을 하면서 수시로 수확체감의 법칙을 실감한다. 어떤 사업이든 일정 수준에 도달하면 노동이나 자본 등 생산 요소를 늘려도 결과물은 비례해서 증가하지 않는다. 일과 성공 역시 마찬가지다. 들인 시관과 성과는 정비례하지 않는다. 6시간 일한다고 목표를 달성하지 못하는 것도 아니고 12시간 일한다고 두 배의 성과를 얻는 것도 아니다. 그런데도 여전히 많은 사람들이 50시간이 아니라 70시간을 일할 때 더 많은 일을 해낸다고 믿는다. p15 우리가 12시간씩 일하며 인생은 원래 고달픈 거라고 스스로를 위로하는 동안 누군가는 획기적인 아이디어로 3시간 일하고 9시간 동안 여유를 즐긴다.

‘‘단의 공식’’ 버려라 : 중요한 것을 위해 덜 중요한 것을 버리는 것. ‘더 많이’를 버리고 핵심에 집중 세워라 : 왜 일해야 하는 지 사명을 세우고, 내가 누구인지 정체성을 세우고, 어디로 가야 할 지 길을 세워야 한다. 지켜라 : 단순함의 핵심은 지속 가능에 달려 잇다. p14 GE의 제프리 이멜트(Jeffrey Immelt) 회장은 2013년 10월 BBC와의 인터뷰에서 이렇게 설명했다. " 조직이 커지면서 중요하지 않은 일을 너무 많이 하고 있다. 단순화는 직원들이 중요하지 않은 일에 맞서 정말 중요한 일을 함께 하도록 돕는 도구다.

Heavy Reading 2014 December http://contextream.com/media/docs/HR-ConteXtream-Fit-VNF-WP-12-8.pdf The important Factors Driving NFV deployment is Service Agility & Flexibility In a virtual environment, where applications are extracted from hardware, VNF de- signers face different challenges and opportunities. If operators are to achieve a step change in service agility, it should be possible to provision VNFs on a quasi-on- demand basis. Fit VNFs can be dedicated to a single function and then connected together using traffic steering (or “chaining”) mechanisms to create services.

Small Cell Big Cell 256 user 이하를 small cell로 정의 mini-CRAN Paris Hill SOC을 이용하는 경우 RRH에서 LTE/3G DSP+DFE 까지 처리하고 Ethernet으로 IA core로 전달. Altiostar 구조와 유사한 듯 Wifi 와 3G/4G까지 지원하는 차세대 SOC 2/4/8 core까지 지원 Aricent와 협업하여 L1/L2/L3 Protocol stack 개발 ONP Red Rock Canyon Las Vegas에서 30분 가량 걸리는 거리 Switch와 NIC 통합 PCI-e를 지원해서 NIC없이 Xeon을 직접 연결할 수 있음. 150page 가량의 report ONP 1.1 버전.