test

This is a test markdown post

include

Markdown test from Byword

First
Second

Quote

#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("Hello\n");
}

First from Byword

Code review

http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/


Code review로 찾을 수 있는 버그는 한계가 있다. 담당자가 조금만 신경쓰면 찾을 수 있는 버그를 찾을 수 있다. 

Code review의 진정한 의미는 "다른 사람이 내가 작성한 코드를 본다"라는 사실을 인지한다는 것이다. 남이 보는 코드인 만큼 좀 더 깔끔하게 작성할 것이다. 코드나, 주석이나 구조 측면에서. Coding standard도 보다 많이 준수하고.

다른 장점은 collective owernership이 자연스럽게 퍼진다는 것이다. 


Code review는 다른 사람이 작성한 코드가 내가 생각하는 코드와 얼마나 다른지를 확인하는 것이 아니라 문제를 얼마나 잘 해결했는지는 확인하는 것이다. 문제를 해결하는 데는 수 많은 방법이 있기 때문에 스타일이 다르

효율

메일 -> 위키/공지사항 -> 항상 이용하는 정보면 개발자들의 메일함을 찾아야 하는 것이 아니라 늘 볼 수 있는 yellow page같은 곳에 있어야 한다. 필요한 정보가 있으면 기억을 되돌리거나, 메일함을 뒤적이는 것이 아니라 항상 “어디에 가면 있다”라는 인식이 들도록 활성화가 되어야 한다. 쓸데없는 걸 기억하게 만들지 말고, 개발자들에게 보다 창의적인 업무에 시간을 들일 수 있는 환경을 만들어야 한다.
숫자로 진척도를 표시할 수 없다. 하려면 각 항목별로 중요도, 복잡도를 고려해서 숫자로 표현해야 한다. 덜 중요하고, 간단한 일을 많이 했다고 진척도가 높아지는 것은 아니다.
Task를 2주 단위로 계획 -> 장기 계획은 아쉽지만 믿기 어렵다.

우아한형제들의 Baby Steps

우아한 형제들의 Baby Steps

인상깊었던 글들 정리

지금까지 겪었던 어떤 조직보다도 빠르게 변화를 받아 들이고, 그것에 익 숙해지고 난 후 바로 옆 사람과 옆 조직에 빠르게 전파가 되었다는 점입니다. 일을 더 잘 하고 싶은 마음, 더 가치 있는 일을 하고 싶은 마음이 가득했고, 밀려 오는 파도를 두려워하지 않고 오히려 몸을 맡기는 서 퍼처럼, 이러한 변화의 물결을 피해서 도망가는 것이 아니라 그 물결 위에 올라타는 모습들을 보았습니 다.

그 결과로 지금은 Confluence를 이용한 문서화 수준을 넘어서, 각 프로젝트마다 특성에 맞게 Scrum 또 는 Kanban Board를 만들고, 업무들의 진행 상황을 같이 살펴 보고 논의하며 일을 하고 있습니다.
보통은 자신이 감당해야 할 부담이 늘어날 수 있기 때문에 익숙함을 선택하기 마련인데, 프로젝트를 진행하던 분들이 우리가 가야 할 변화의 방향이라면, 힘들더라도 그 당시에 피하기 보다는 정면으로 맞서서 어떻게 해서든 해보려고 했다는 점

변화를 대하는 태도 가 가장 중요하다. 아무리 좋은 환경을 제공해도 구성원들이 환경을 수용할 의지가 없다면 아무 소용없다.
지금보다 더 나은 방법으로 일할 수 있을 거라는 생각을 늘 가져야 한다. 이게 최선입니까?

이 조직은, 정말로 변화에 열려 있고 갈망한다.

그 변화를 같이 만들어 나갔으면 좋겠다.

시니어의 역량은 내가 얼마나 많은 것을 아느냐가 아니라, 나로 인해 같이 일하는 사람들이 얼마나 좋은 쪽으로 변화하고 그것을 통해 실질적인 성과를 만들어내는 데 있는 것 같다.

시니어가 이런 성과를 거두기 위해서는 같이 일하는 사람들도 그것에 동참해야 한다. 우아한형제들은 이것이 가능한 조직이다.

이 과정을 통해서 시니어도 성장할 수 있다고 생각한다.
이미 잘 하는 조직이니까 여기에 오면 좋다는 것이 아니라, 변화를 만들어 가는 과정에 같이 참여하고 그 것을 통해 경험할 수 있는 것이 많다는 점에서 좋은 조직

어떤 조직의 문제는 모든 일을 책임 추궁하고 비난하는 것에 초점을 맞추다 보니 아무도 스스로 나서서 하려 하지 않는다. 주어진 문제를 어떻게 회피할 수 있을까 라는 생각이 먼저다. 아무도 챙겨주지 않으므로 스스로를 보호해야 하는 자연스런 본능이다.

조직원들이 창의성이 부족하고, 주인의식이 없는 무책임한 돈벌레라서 그런 게 아니다. 그렇게 행동하지 않으면 피해만 입는 문화를 만든 조직의 잘못이 크다.

조직 내에서는 점점 공유가 활발

내가 뭔가 대단한 것을 알아서 공유하는 것이 아니라, 내가 새롭게 알게 된 것을 공유함으로써 나 스스로 한 번 더 정리를 하고, 혹시 나와 비슷한 경험을 하게 될 사람들을 돕는다는 것

모르는 것은 부끄러운 것이 아니라는 것. 모르는 것을 모른다고 말하지 않는 것이 부끄러운 것이라는 생 각. 현재 실력이 뛰어난 것이 중요한 것이 아니라, 계속 발전하기 위한 노력을 하느냐 안 하느냐가 더 중 요한 것이라는 생각.

공유하는 작업이 특별 한 것일 필요는 없다.

자신이 새로 알게 된 것을 그냥 적으며 된다. 누군가에게는 이미 알고 있는 내용일 지 몰라도 자신에게는 정리하는 기호가 되고, 누군가에게는 새로운 정보가 된다. 누군가에게 보여주기 위한 것이라기 보다 스스로 알고 있는 것, 새로 알게 된 걸 정리하는 걸 목적으로 하면 된다. 에버노트처럼 second brain으로 활용하다보면 자연스럽게 정보가 모인다.

비단 개발자뿐 아니라, 사람이 가장 밀도있게 성장하는 때는, 잘하는 것을 계속하는 것이 아니라, 어제보 다 나은 오늘과 오늘보다 나은 내일이 끊임없이 반복될 때라고 생각합니다

Software developer의 생산성을 측정할 수 있을까?

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. They find ways to simplify code and eliminate duplication. And a lot of the code that they do write won’t count anyways, as they iterate through experiments and build prototypes and throw all of it away in order to get to an optimal solution.

Money

Velocity

But velocity (how much work, measured in story points or feature points or ideal days, that the team delivers in a period of time) is really a measure of predictability, not productivity. Velocity is intended to be used by a team to measure how much work they can take on, to calibrate their estimates and plan their work forward.

Once a team’s velocity has stabilized, you can measure changes in velocity within the team as a relative measure of productivity. If the team’s velocity is decelerating, it could be an indicator of problems in the team or the project or the system. Or you can use velocity to measure the impact of process improvements, to see if training or new tools or new practices actually make the team’s work measurably faster.

Organizations and managers who equate internal velocity with external productivity start to set targets for velocity, forgetting that what actually matters is working software in production. Treating velocity as productivity leads to unproductive team behaviors that optimize this metric at the expense of actual working software.

The down side of equating delivery speed with productivity? Optimizing for cycle time/speed of delivery by itself could lead to problems over the long term, because this incents people to think short term, and to cut corners and take on technical debt.

Better Software

It’s easy to measure that you are writing good – or bad – software. Defect density. Defect escape rates (especially defects – including security vulnerabilities – that escape to production). Static analysis metrics on the code base, using tools like SonarQube.

Devops

As I pointed out in an [earlier post](https://dzone.com/articles/measuring-your-devops-success this makes operational metrics more important than developer metrics. According to recent studies, success in achieving these goals lead to improvements in business success: not just productivity, but market share and profitability.

그래서 결론은?

Stop trying to measure individual developer productivity.

It’s a waste of time.

Everyone knows who the top performers are. Point them in the right direction, and keep them happy.

Everyone knows the people who are struggling. Get them the help that they need to succeed.

Everyone knows who doesn’t fit in. Move them out.

Measuring and improving productivity at the team or (better) organization level will give you much more meaningful returns.

When it comes to productivity:

Measure things that matter – things that will make a difference to the team or to the organization. Measures that are clear, important, and that aren’t easy to game.
Use metrics for good, not for evil – to drive learning and improvement, not to compare output between teams or to rank people.

vim tip

잘 모르던 vim의 기능들.

Color scheme 선택

:colo 까지 입력하고 Ctrl+D를 누르면 선택 가능한 항목이 표시됨

도움말 항목을 선택

:help wor까지 입력하고 Ctrl+D를 누르면 wor로 시작하는 항목이 표시됨.

Case-sensitive searching

\c 옵션을 사용하면 현재 설정된 ignorecase와 반대로 검색

LF 변경

%s/\r//g

숫사 증감

Ctrl+A 현재 커서가 위치한 곳에 있는 숫자를 증가시킴(10진수, 16진수 지원)  
Ctrl+X 숫자 감소. 음수도 지원

모든 라인에 `abc` 추가

:%s/$/abc/g

e-mail 찾기

/[a-zA-Z0-9.-]\+@  
/[a-zA-Z0-9.-]\+@[a-zA-Z0-9.-]\+  
/\([a-zA-Z0-9.-]\+@[a-zA-Z0-9.-]\+\)

파일 읽기

:find filename    filename을 편집함  

:n **/*.c         현재 디렉토리 이하의 *.c 파일을 하나씩(한번에 하나씩) 읽어들임. **는 recursive. */*c는 1단계 아래만 검색.   
gf                현재 커서 위치에 있는 파일이름을 읽어들임   
Ctrl+W f          현재 커서 위치에 있는 파일이름을 새로운 창에 열어줌  
Ctrl+W gf         현재 커서 위치에 있는 파일으름을 새로운 탭에 열어줌  
Ctrl+^            이전 파일로 돌아감

Windows 창 크기

Ctrl+W           현재 창의 너비를 1칸 늘림
Ctrl+W 10        현재 창의 너비를 10칸 늘임

tabpage 사용하기

:tabnew           탭 추가
:#gt              # 번째 tabpage로 이동. tabpage은 1부터 시작  

vim -p a.c b.c    2개 파일을 tabpage로 열기

현재 열어놓은 파일 목록 보기

: filles
: buffers

Abbreviation

ia – Insert mode에서만 동작
ca – command mode에서만 동작

ab mymail cychong@gmail.com  
ab prjsrc /home/foobar/project/abc    
ia date0 =strftime("%Y.%m.%d-%H%M%S")  
ia time0 =strftime("%c")

key mapping

nmap – normal mode only
imap – insert mode only
map – both mode
cmap – command mode only

자동으로 파일 타입에 따라 실행

autocmd BufRead, BufNewFile *.txt colo evening  
autocmd BufRead, BufNewFile *.c cool morning | set ts=2 sw=2

indentation

={motion}

{motion} 에는 gg, G, )), ]] 등 이동 관련 키를 사용할 수 있다.

=gg     현재 줄 부터 첫번째 줄 까지 indent   
=G      현재 줄 부터 파일 마지막까지 indent  
=]]     현재 줄 부터 함수 마지막까지 indent 하고, 현재 줄에 커서가 유지됨 
=))     현재 줄 부터 함수 마지막까지 indent하고, 함수 끝으로 커서 이동

Auto completion

Ctrl+N                 현재 코드에서 대상이 되는 단어들을 보여줌          
Ctrl+P 
Ctrl+X Ctrl+F          현재 디렉토리에 있는 파일목록을 보여줌  
Ctrl+X Ctrl+K Ctrl+N   사전 검색 모드 동작

DPDK 2.0

http://dpdk.org/browse/dpdk/tag/?id=v2.0.0

Release note from http://dpdk.org/ml/archives/dev/2015-April/016174.html

Changelog (main changes since 1.8.0)
– enhancements:
* ABI versioning
* x32 ABI
* non-eal thread supports
* multi-pthread per core
* enable big contigmem blocks in BSD
* port hotplug
* jobstats library
* reorder library
* memcpy optimization
* acl for AVX2
* crc hash arch-independent
* uio_pci_generic support
* kni optimizations
* vhost-user support
* virtio (link, vlan, mac, port IO, perf)
* ixgbevf RSS
* i40e hash filtering
* i40e nvgre offloading
* i40e TSO
* fm10k driver
* mlx4 driver
* bonding mode 4 tests
* bonding mode 6
* Rx/Tx callbacks
* unified flow types
* remove old filtering API (flow director, flex, ethertype, syn, ntuple)
* remove static tailqs from EAL
* remove device arguments limit
* add indirect attached mbuf flag
* use default port configuration in testpmd
* tunnel offloading in testpmd
* PDF doc output
* NICs guide
– fixes for:
* build
* memory leaks
* big endian
* devargs
* kvargs
* cmdline
* timer
* lpm
* pipeline
* bonding
* vhost
* virtio
* pcap
* igb
* ixgbe
* i40e
* enic
* testpmd

Charting the path to RAN virtualization

C-RAN means

Centralized : Centralized processing resource pool supports 10-10,000 cells
Collaborative : Multicell joint scheduling and interference management
Cloud
Clean

RAN

H/W accelerator for L1 function FFT/IFFT channel encoding/decoding
“Recent Progress on C-RAN Centralisation and Cloudification” Chih-Lin I
CPRI compression
RAN and core within the shared NFV platform -> closer to each other and remove the sharp demarcation line that has separated the two.

Fronthaul

One fiber connection provides 6Gbps
9.8Gbps per carrier(FA). Doubled for bi-direction.
3 carrier = 9.8G23 = 58.8Gbps
CPRI compression ration 50%
WDM(Wavelength-Division Multiplexing) : fewer finer connection compared to dark fiber which is native frontal solution that has the best performance
Three way for C-RAN/v-RAN adoption
- Reduce frontal requirements by using functional split – enable some functions to be virtualised while the others remain distributed
- Improve the efficiency of the fronthaul – pack more traffic
- Use wireless alternative where fiber is not unavailable or too expensive

Dark-Fiber alternative

OTN(Optical Transport Network)
PON(Passive Optical Network)
CPRI over Ethernet(CoE)
*outdoor small cell frontal in dense urban areas
- higher latency than Dark-fiber
Wireless
- outdoor small cell frontal
- Suitable for short distance and relatively low capacity requirement

CPRI alternative

CPRI : 0.4ms latency, very low jitter
- But not standard-based
- ETRI’s ORI – Standardized CPRI for interoperability
Ethernet : should be carefully managed end-to-end to meet the CPRI’s performance

Split funtionalities

Functional split to reduce fronthaul requirement
RF is RRH
PHY is L1 function which requires FFT/IFFT

RF-PHY

Need 20-50x bandwidth than PHY-MAC
eICIC and CoMP can be implemented effectively, so the C-RAN can manage interference effectively.

PHY-MAC

Coordinated transmission can not implemented in the pooled BBU as there are L1 functions instantiated at the cell sited(PHY)
Macro-only network, this can be acceptable trade-off

Central scheduler based scheduling can be another option. MAC-level coordination among cells has lower latency and bandwidth requirements and ethernet can be used for this.

Functions in each layer

L3
- Control RRC
L2
- PDCP
- RLC
- Transport MAC
L1
- CoMP
- eICIC
- Channel decoding/coding
- Quantization/De-
- Resource Block mapping
- Sampling/De-
- Modulatio/De-
- FFT/iFFT

Cost reduction with vRAN

30% in capex – mainly from equipment and installation cost
54% in opex – lower site rental
Resource utilization
Mobility management
Robust interference management

Leveraging uneven traffic distribution

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

LOC

Money

Velocity

Better Software

Devops

그래서 결론은?

Share this:

Color scheme 선택

도움말 항목을 선택

Case-sensitive searching

LF 변경

숫사 증감

모든 라인에 abc 추가

e-mail 찾기

파일 읽기

Windows 창 크기

tabpage 사용하기

현재 열어놓은 파일 목록 보기

Abbreviation

key mapping

자동으로 파일 타입에 따라 실행

indentation

Auto completion

Share this:

Share this:

C-RAN means

RAN

Fronthaul

Dark-Fiber alternative

CPRI alternative

Split funtionalities

RF-PHY

PHY-MAC

Functions in each layer

Cost reduction with vRAN

Leveraging uneven traffic distribution

Share this:

모든 라인에 `abc` 추가