그냥 누구나 생각하는 바람직한 방법과 목표 그리고 절차를 따라야 한다는 게 고작 결론인가? 그런 누구나 할 수 있는 이야기잖아. 저런 이야기를 돈을 내고 들어야 한다는 건가? 이해가 안된다.
현재 불편한, 잘못된, 쓸데없는 일을 하게 만드는 절차를 감당해야 하는 사람들에게 솔직한 의견을 구하는 것이 더 나은 방법 아닐까?
아무리 다른 곳의 일하는 체계나 조직을 분석해도 소용없다. 그 비교자료에는 없는 내용이 핵심이니까. 조직을 운영하는 사람들의 능력과 그 조직을 구성하는 사람들의 능력. 그리고 생각들.
출처 : 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
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 버전.
며칠 밖에 보지 않았지만, 그래도 내용을 분석해 보려고 했던 OVDK인데, 오늘 기사를 보니 Intel에서 공식적으로 OVDK의 개발 중단을 발표했단다.
Intel Dead-Ends Its Fork of Open vSwitch
Data path(Fast path)를 커널 모듈에서 처리하는 OVS를 fork해서 DPDK를 이용해서 user space에 Fast Path를 만들려고 했는데 그러다 보니 역시 계속해서 발전하는 OVS의 기능을 수용하기 부담스러웠나 보다. 더군다나 OVS에서도 experimental feature이긴 하지만 DPDK를 이용하는 코드도 있다고 하니.
내년 초에 나올 다음 버전 OVS에 공식 기능으로 들어가길 기대한다고.