Deview 2013 Day 1.

개발자 컨퍼런스는 처음 참여해본다.
관심있는건 웹, 모바일, 빅테이터. 그래서 1,2일차 모두 참가할 예정이다.

막연히 알고 있던 것들을 디테일하게 알게되서 그런지,
아니면 몰랏던 것들을 새롭게 알게되서 그런지,
비슷한 세션들을 연이어 들어서 그런지… 오늘 들었던 세션들에서 공통적으로 느낀 점은….

  • 공부. 현실 안주하지 말고
  • 공유. 실패사례마저도 공유
  • 자존감과 자부심을 갖자. 나는 개발자다! 쯤?

이런 기회로 외부자극을 받는 기회가 비교적 많은 직군인 개발자가 부럽다.
개발공부를 하고는 있지만… 난 항상 그렇듯 입코딩 수준이 훨~~~~~~씬 높다ㅋㅋㅋ(개발은 ㄱ쓰다가 만..)
그래도 오늘 다녀오고 나니, 다시 차근차근 사이드프로젝트를 해야겠다는 생각이 든다.
(땅에 삽만 꽂아놓고 세워둔게 한 두개가 아니다…-_-)

PS. 그래서 기획자 컨퍼런스는 누가 안열어주나?? ㅠ^ ㅠ

_______________________________

Session1. nGrinder : 아이들도 할 수 있는 성능테스트

서버의 성능테스트가 어려운 이유

  • 성능테스트 툴의 가격이 비싸다. (억단위)
  • 툴을 효율적으로 사용하지 못함. (조직내에서의 자원 배분이슈)
  • 성능테스트의 메뉴얼의 충분한 숙지가 필요 (학습시간 부족)
  • 반복적인 테스트로 인한 트래픽이슈
  • 행위유발성 (Affordance)

성능 테스트 상식

  • 로드테스트 : 운영체제에 따른 성능비교
    • ApacheBench? LoadRunner? NHN같은 대규모 서버군에는 부적절. 한개의 서버에서 로드를 줘도 받는 서버가 죽지를 않음.
    • 분산테스트? 무제한 로드 부여 가능 / 대규모 테스트에 적합. 스크립트를 통해 여러 로드를 생성해 하나의 서버에 부하를 주는 방법
  • 스트레스테스트 : 시스템 크래시 상태의 문제를 찾는 테스트
  • TPS(Transaction per second / 초당처리량) : 성능테스트 도구는 실수까지 기록해야 한다
  • Jbench(?) 같은 오픈소스들 : 서버설정 등을 덮어쓰기 떄문에 나중에 봤을 때 알기 어렵다.

nGrinder

  • Dos 공격과 동일한 원리. ( 테스트할 때 조심 ㅋㅋ )
  • 에이전트별 가상사용자 = thread를 의미
  • 언제는 원하는 시점에 테스트 수행
  • 테스트 준비시간 0분, 학습시간 1~2시간
  • 네트워크 오버플로우 자동 정리
  • 퍼포먼스 테스트가 가능(==> 개발자들의 자부심이 늘어남 ㅋ)
  • 트래픽이 적은 밤에 테스트하는데, 굳이 그럴필요가 없어졌다.

nGrinder 구조설명

  • 설명 생략 ^__^ 1~2주후에 발표자료를 통해 그림이랑 같이 보심을 추천~

Summary ( nGrinder 장점 )

  • 성능 테스트 활동 활성화(10배)
  • 큰 사이즈의 가상 유저 시뮬레이션(에이전트만 확보하면, 100만유저 테스트도 가능)
  • 90% 테스트 성공률
  • 비용 최소화
  • 네트워크 오버플로우 최소화

Session2. 프로그래머로 산다는 것

프로그래머의 환경

  • 일상적인 코딩 : 구글링 > ctrl+c,v > 돌아갈때까지 삽질
  • 시간이 지날수록 똑같은 일만 반복한다.
  • 원인 : 나쁜 고객과 상사, 탐욕스러운 회사, 비협조적인 동료
  • 원인은 알지만, 통제할 수 없는 요인들
    • 고객과, 상사, 회사, 동료가 모두 좋을 확률은 10%이하.
    • 프로그래머로 살기로 한 이상 언제나 겪을 수밖에 없다. 그래서 개발자만의 환경이 필요.
    • 외부 환경은 바꿀 수 없다면, 내부의 환경을 바꾸는 것이 좋겠다.

Keep carm for inner peace

  • 깔끔한 코드를 작성할 수 있어야 한다.
    • 나 뿐만 아니라 다른 동료들도 읽기 좋은
  • 적절한 논리력이 필요하다.
    • 균형감각( 원리 탐색 능력 + 제약조건을 고려한 해법 ) + 단순한 디자인
    • 개발 요구사항이 변경되지 않는 경우란 없다. 균형감각으로 조절.
    • 협업의 중요성
  • 내가 하는 일이 언제 끝났다는 것을 ‘아는 것’이 중요하다.
    • 고객의 ATDD (Acceptance test driven development)
      완료조건에 대한 정의를 내린다.
    • 개발자의 TDD (Test driven development)
      다른 시각에서 바라볼 수 있는 QA가 필요하다
      적당한 정도로만 만들고, 리팩토링. ( 오해의 소지가 없는지 등등.. )

실천법

  • 꾸준한 연습 + 매일 몸값 올리는 시간을 가져라. 새로운 기술을 공부하든, 리팩토링을 하든.. 매일 조금씩.
  • 멀리가고 싶다면 함께가라
  • 현재 필요한 만큼만 하라

좋은 @@ 개발자란?

  • @@에는 웹, 모바일, 클라이언트… 등등은 분야가 다양.

1) 공유할 수 있는 개발자

  • 공유의 목적 – 내 주변사람을 똑똑하게 만드는것.
  • 왜 해야하는 것일까?
    • 내 주위사람이 사고치게 하지 말아야 사고를 수습하는 일이 줄어듬. 내 시간을 벌 수 있다.
    • 좋은 평판을 얻을 수 있다. ( 조직내에 이름을 알리기 쉽다. )
    • 주변의 덕을 볼 확률이 올라간다.
  • 무엇을 하나?
    • 무엇이든. 실패사례. 삽질사례 공유! 상대방의 시간을 아껴줄 수 있다.
  • 공유방법은?
    • 메일링 리스트. DB등으로 기록해둬서 메일을 받지 못한 사람들이 나중에 볼 수 있도록한다.
    • 교육이나 세미나. 재미있게 해서. 시간을 책임져야 하는 사람들이니 재미있게 해주자
    • 코드리뷰. 기술적 제안을 해줘야 해야한다.

2) 협업할 수 있는 개발자

  • 소프트웨어 특징
    • 기획자 – 기획문서 : 이걸 왜 해야되는데요?
    • 개발자 – 개발코드 : 90%구현. 10% 때문에… 거지같은데?
    • QA – 테스트케이스, 버그레포트 : 그럴리가 없는데? 제자리에선 잘되요.
  • 자아존중감
    • 피드백을 나쁘지않게 받아들이기 위해, 자아존중감이 중요하다.
    • 있는그대로 자신을 인정할 것. 버그 만들 수 있지. 실수할수도 있지.. 사람이니까~
    • 타인의 부정적 견해에 크게 영향받지 말자. 내인생이니까 쿨하게 콜.
  • 중요한것? 사람의 본성은 바꾸지 않는다. 본성은 바꿀 수 있지만 외부로 보여지는 반응은 바꿀 수 있다.

Summary ( 좋은 개발자란? )

  1. 논리력! 적절한 논리력, 간단한걸 간단하게 풀수 있어야 한다.
  2. 좋은 코드 작성능력! 유지보수 좀… 신경써서.
  3. 공유하고 협업하는 능력!
  4. 도메인지식! 수시로 바뀌기 때문에 매일 노력을.
  5. 피드백을 자주받고, 잘 활용할 능력!
  6. 실천력! 지금까지 말한 것들은 반복연습 뿐. 습관으로 활용하라.

Session3. High Performance Android App Development

음.. 내용상 패스;; 너무 어려웠… Git 세션 들을 껄.
기억에 남는 부분이 있다면,

  • CPU 프로세서 향상 우선은 끝나가고, GPU 프로세서 개발에 힘이 실릴것이라 예상.
  • Web-base vs Native-base vs VM-base : 최적화된 Native로 개발하는 것이 멀티플랫폼 앱 개발에 효율적일것.

Session4. 나는 왜 개발자인데 자신이 없을까?

내가 배웠던 것들을 체화하는 과정이 필요하다.

  • 개발은 문화적 활동과 같다. 책으로 문화를 공부하고 있지만, 몸으로 배울순 없다. 개발도 경험으로 직접 만들어 보면서 배워야 한다. 그게 아니면, 개발자가 아니라 그냥 공부한 사람일 뿐.
  • 진도나가고 문제풀이만 했을 때가 문제를 낸 사람을 능가할 수 없다.
  • 내가 만든 문제를 해결하면서 배우지 않으면 평천하는 개뿔, 수신도 어렵다.
  • 작은 성과를 얻으면서 가자. 만들면서.
  • 내가 가진 아주 사소한 문제부터 해결하면서, 책/연습문제/소스 등을 만져보자. pair program, code review, agile.

( 현장성 확보를 위한 ) 세가지 필살기

현장성이란, 배움이 가장 잘 일어나는 개발현장(==회사). 학교는 공부할 수 있지만, 배울수는 없다.

  • 리뷰
    • 내가 믿는 것이 정말 그런지 검증하는 행위 : 요구사항 리뷰, 테스트 작전 리뷰, 소스 리뷰
    • 필받아 만든 것을 냉정하게 다시 보다.
    • 공부한 것을 내것으로 만든다
  • 테스트
    • 내가 믿는 것을 남들도 믿는 것으로 바꾸는 행위 : 테스트를 위한 설계(가 있었어야), 단계별 테스트(에 대한 고민), 적절한 도구
    • 내가 해냈다고 믿는 것을 부정해본다.
    • 나와 다른 생각도 수용할 수 있는지 확인해본다.
  • 릴리즈
    • 공부한 것을 경험적 배움으로 승화시키는 행위 : 사용자 가치, UX/UI, 품질, 성능
    • 내가 만든 걸 남으로부터 피드백을 받는다
    • 내가 해낸 것, 내가 할 수 있는것을 확인받는다.

롤모델을 찾자

  • 가까이에서 만날 수 있는 사람이 롤모델이다. 굳이 선배가 아니더라도 롤모델이 될 수 있다.
  • 선배 롤모델을 대하는 자세
    • 한풀이할 시간을 주고
    • 좋은 이야기를 듣고 느끼고
    • 내 문제를 묻고 배우자

Summary

  • 다른 사람 소스를 본적이 없다 -> 오픈소스가 생김
  • 내 소스를 보여준적 없다 -> 깃헙, 구글코드 등이 생김
  • 피드백 받을 방법이 없다 -> 해커톤 대회, 앱스토어 등등
  • 모르면 물어볼 곳이 없다 -> 스택오버플로우, 개발자 컨퍼런스…
  • BUT, 기본도 중요하다. 수학같은.
  • AND, 치킨집은 실패한다. 배운걸(==개발)로 먹고살자.

Seesion7. Popular Convention 개발기

노트는 전부 했지만, 내용 올리는건 패스 ~ 나만 알아볼 수 있을 것 같다. ㅋㅋ

변정훈(@Outsideris) 님께서 발표자료를 올려주셔서 블로그를 링크!

[slideshare id=27165068&doc=day1-track3-7-131014053808-phpapp02]