잘못된(?) 진단은 잘못된 처방을 낳는다. 모든 걸 개인의 잘못으로 돌리려는 의도는 의외로 단순. 잘못을 저지른 개인은 개선시키면 된다는 단순한 해법을 제시할 수 있으므로. 개인을 구박하거나 심지어는 그 조직에서 제외시키면 문제가 해결(?)되는 것처럼 보이니까. 하지만 그 뒤에 숨어있는 실은 개인의 잘못으로 돌려진 관리의 문제, 시스템의 문제는 아무도 건드리지 않는다. 문제의 원인이 너무 커서, 문제의 원인이 너무 근본적이라, 문제의 원인이 권력자에게 있는 터라. 그렇게 문제는 반복된다. 비난의 대상이 되는 ‘개인’만 바뀔 뿐. 병든 조직은 서서히 그렇게 스러진다…

관리자들이 개발자들을 위해 한 일이 뭐가 있나? 아무리 생각해도 잘 모르겠다. 그럼 개발자를 위한 사람이나 제도는 없다는 건데 그러면서 개발자가 잘 하기 기대하는 건 도둑놈 심보가 아닌가? 자꾸만 벗어나길 원하는 ‘개발’업무를 만든 게 누구인지? 왜 그렇게 된 건지? 이런 근본적인 질문에 대한 고민과 해결 없이 SW품질을 논한다는 건 어불성설이다.

규제를 풀기 어려운 이유는 그 규제를 풀어도 문제가 없는 지 자신이 없기 때문이다. 증명하기 어려운 경우가 대부분. 하지만 머리를 맞대고 함께 이야기해봐야 한다. 정말 필요한 절차인지 고민해야 한다. 가능하면 절차는 줄이고 또 줄여야 한다고 생각. 이런 고민조차 어려운 이유는 대부분 한 쪽이 들으려 하지 않기 때문. 기존에 하던 (불필요해보이는) 절차를 없애는 경우 발생할 수 있는 위험요소를 감수할 의지가 없으므로. 혹시 이렇게 생각하고 있는 건 아닌지 그런 번거로운 절차는 내가 하는 게 아니라 니들이 하는 거니까

TAILQ_HEAD(ip_pkt_list, ip_frag_pkt); /**< @internal fragments tailq */ 자료 구조체 Fragment 관리용 table struct rte_ip_frag_tbl *frag_tbl; locking 없이 IP reassembly를 수행할 단위(통상 core)로 한 개씩 만든다. 즉 하나의 core가 여러 rx queue를 처리하더라도 하나의 frag_tbl만 가지면 된다. 아래 rte_ip_frag_table_create()함수를 이용해서 생성한다. struct rte_ip_frag_death_row death_row core별로 갖는 death_row. IP reassembly를 호출한 후 해당 함수내에서 free할 mbuf를 이 리스트에 담아줌. main loop에서 reassembly작업 후 rte_ip_frag_free_death_row()함수를 호출해 reassembly에 실패한 mbuf를 free함 IP_MAX_FRAG_NUM defines the maximum fragments of one reassembly.

자네는 Agile이 뭔지, Scrum Master가 어떤 일을 해야 하는 지 모르겠지만, 앞으로 자네를 ‘Scrum Master’라고 부르겠네. 이제 우리는 Scrum Master를 가졌으니, Agile을 하는 걸쎄 글쎄요… 저도 Agile을 잘 모르지만, 동의할 수가 없네요. 국정교과서의 필요성에 대해 이야기하는 이상한 나라의 사람들 만큼이나 이해하기 어렵네요.

We can’t measure Programmer Productivity… or can we? LOC The more fundamental problem is that measuring productivity by lines (or Function Points or other derivatives) typed doesn’t make any sense. A lot of important work in software development, the most important work, involves thinking and learning – not typing. The best programmers spend a lot of time understanding and solving hard problems, or helping other people understand and solve hard problems, instead of typing.

예 ipsec on asf/se/… 불럭별 특징이 아니라 프로토콜별 호환성이나 주의사항에 대한 취합 필요 보통 postmortem하면 그 블럭의 특징이라고 보는 경향이 강한데 그것과 무관하게 프로토콜 특성에 대한 내용은 블럭 설계와 별개로 모아놔야 하지 않을까? StackOverflow 처럼 분야별로…

VirtualBox supports emulated e1000 NIC for VM while VMware fusion does not. VMware Fusion’s VM setting does not support configuring of NIC HW type. The NIC HW is PCnet32 which is not supported by DPDK. However, we can change NIC HW type by editing VM configuration file directly. Refer : How to emulate 10 Gbps NIC in a VMware Fusion VM Edit vmx file to VMX file is in where vmware image located

DPDK Userspace in Dublin 2015에서 발표 Stageful traffic generator 특징 Generate traffic based on templates of real, captured flows No TCP/IP stack Up to 200Gbps with standard server hardware Low cost 1RU (C220M UCS-1RU) Cisco internal DPDK, ZMQ, Python libs Virtualization(vmxnet3/e1000) ~20Gbps per core Generate flow templates Support 1K templates Yaml based traffic profile GUI GUI which monitors real-time properties of TRex - min/max/average latency, jitter Python 연동 Code https://github.com/cisco-system-traffic-generator/trex-core

From http://www.theeffectiveengineer.com/blog/what-makes-a-good-engineering-culture 1. Optimize for iteration speed Continous deployment to support rapid validation High test coverage to reduce build and site breakages Fast unit tests to encourage people to run them Fast and incremental compiles and reloads to reduce development time Bill Walsh, 49ers to 3 Super bowls, Commit, Explode, Recover A team crippled with indecisiveness will just cause individual efforts to flounders 2. Push relentlessly toward automation Consider operational burden per engineer