'개발자'에 해당되는 글 38건

허니몬의 IT 이야기/프로그래머, '코드 엔지니어'

가을은 수확의 계절! 계발자에게도 수확의 계절!

NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/80sec | F/4.5 | 0.00 EV | 18.0mm | ISO-200 | Off Compulsory | 2012:10:12 09:37:32


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/13sec | F/3.5 | 0.00 EV | 18.0mm | ISO-400 | Off Compulsory | 2012:10:12 09:38:02


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/30sec | F/3.5 | 0.00 EV | 18.0mm | ISO-360 | Off Compulsory | 2012:10:12 09:43:03


  가을은 '수확의 계절'이라고 한다. 개발자들에게도 '수확의 계절'이 있다면 단연코 10월이 있는 '가을'이 아닐까? 네이버, 다음, KTH 가 커다란 개발자 컨퍼런스를 열기 시작하면서 10월에는 그 컨퍼런스들을 찾아다니느라 분주하다. 

   * 네이버 : Deview - http://deview.kr/ 
   * 다음 : DevOn - http://devon.daum.net/ 
   * KTH : H3 - http://h3.kthcorp.com/ 

  이 커다란 컨퍼런스의 특징은 **'무료'**이면서 **들을 것**들이 많다는 것이다. 대부분 주최하는 기업들이 주가 되어 자신들이 현재 진행하고 있는 기술과 서비스들에 대한 발표를 하는 자리이기도 하고, 발표자(Speaker)들도 엄선된 분들이 나오시기에 발표의 질도 상당히 높은 편이다. 지난 JCO 때와는 여러면에서 질적인 차이가 많이 났다는 의견이 많았다. 
   네이버가 주최하는 'Deview'는 코엑스에서 열리고, 다음에서 주최하는 'DevOn'은 신도림 디큐브시트에서 열리고, KTH가 주최하는 'H3'는 신대방에서열리고... 나름 지역적인 위치를 가지고 진행이 되는 것으로 볼 수 있다. 작년에 열렸던 개발자 컨퍼런스에는 대부분 참관을 못한 탓에 '올해는 반드시 가고 말겠다!'는 일념으로 사전참관신청의 때를 기다리며 벼르고 있었다. 하지만 10월 31일에 열리는 H3는 참관신청을 못했다. ㅡ_-);; 너무 빨리 종료되어버렸... Orz.. SK Planet 에서도 주최하는 지식공유 컨퍼런스가 준비되고 있는 것으로 알고 있다.

  DevOn에서 주의깊게 들었던 트랙은 Hadoop과 NoSQL 관련한 주제로 발표한 트랙이다. 당장 회사에서 사용하고 있지는 않지만, 앞으로도 꾸준하게 기술이 유지되고 수요가 늘어날 분야로 빅데이터와 이를 분석할 수 있는 방향으로 생각하고 있다. 과거에 통계학을 배운 통계전문가가 데이터를 분석하던 시기를 벗어나 개발자 자신이, 그간 데이터베이스와 로그에 축적된 데이터를 바탕으로 자신에게 필요한 정보들을 추출하고 이를 바탕으로 보다 효과적인 준비를 할 수 있는 시기가 되어 가고 있는 것이다.

  수많은 사용자들을 보유하고 있는 포탈 업체이기 때문에 막대한 양의 검색쿼리와 검색결과 등이 축적될텐데 이것들을 분산처리 등을 이용하여 효과적으로 저장하고 분석해낼 수 있는 노하우를 공유받을 수 있을거라는 기대를 가지고 컨퍼런스에 참가했다.


컨퍼런스에 모여드는 개발자들이여 기회를 잡아라!

개발자들이 모여들이 지식을 공유하고, 그 모여든 개발자들 중에서 우수한 인재들을 자신의 회사로 끌어들이겠다는 은연 중의 욕심도 스며있다고 볼 수 있다. 이런 컨퍼런스를 가보면 한켠에 자신들의 회사에 취업하기 위한 면담을 하는 장소들이 있으니, 새로운 직장이나 새로운 도전을 시도하는 이들은 '꼭' 그 부스를 찾아가서 담당자들의 이야기에 귀를 귀울이도록 하자. 막연하게 친구들끼리 아름아름 들은 '이렇다 카더라 저렇다 카더라'하는 이야기보다는 '그 회사에서 일하고 있는 직원이나 인재채용 담당자'의 이야기를 듣고 준비하길 바란다.

나는 다음(Daum)을 좋아한다.

지극히 개인적인 취향이다(제주도에 있는 다음지사에 가고 싶기도 하다). 여기저기서 힘들다는 이야기도 들리기는 하지만, 그 속에서도 크고작은 시도를 하면서 새로운 서비스들을 내놓고 기술을 선보이는 것이 마음에 든다. 다음 개발자들은 외부활동이 제한되는지, 개발자 모임에서도 쉬이 만날 수가 없기에 더욱 '신비로움'에 쌓인 존재처럼 여겨지기도 한다.

좋았던 점

NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/5sec | F/3.5 | 0.00 EV | 18.0mm | ISO-800 | Off Compulsory | 2012:10:12 10:11:32

'DevOn(데브온? 디브온이라고 읽는 듯 한데..)'의 특징 중 하나라고 한다면, IT 혹은 SW관련 커뮤니티가 함께 참가한다는 것이다. 커뮤니티에서 활발히 활동하는 사람이 발표자를 하기도 하고, 부스에서 기념품을 주고 컨퍼런스의 이벤트 행사와도 연결되어 많은 개발자가 커뮤니티를 살펴보고 회원가입을 할 기회를 제공(회원가입을 사면 기념품을 준다!)한다. 이렇게 '커뮤니티'가 함꼐하는 컨퍼런스는 조금 더 '개발자들의 축제'같은 느낌이 든다. 

NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/25sec | F/3.5 | 0.00 EV | 18.0mm | ISO-400 | Off Compulsory | 2012:10:12 09:45:26


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/20sec | F/3.5 | 0.00 EV | 18.0mm | ISO-400 | Off Compulsory | 2012:10:12 09:45:29


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/30sec | F/3.5 | 0.00 EV | 18.0mm | ISO-320 | Off Compulsory | 2012:10:12 09:45:37


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/30sec | F/3.5 | 0.00 EV | 18.0mm | ISO-200 | Off Compulsory | 2012:10:12 09:45:49


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/30sec | F/3.5 | 0.00 EV | 18.0mm | ISO-200 | Off Compulsory | 2012:10:12 09:46:04


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/20sec | F/3.5 | 0.00 EV | 18.0mm | ISO-400 | Off Compulsory | 2012:10:12 09:47:26


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/50sec | F/3.5 | 0.00 EV | 18.0mm | ISO-200 | Off Compulsory | 2012:10:12 09:53:27OKJSP를 운영하고 계신 허광남(@kenu)님. SW개발과 관련된 분야에서 왕성하게 활동하고 계시는 활동가시다.


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/2sec | F/3.5 | 0.00 EV | 18.0mm | ISO-400 | Off Compulsory | 2012:10:12 09:56:47


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/30sec | F/3.5 | 0.00 EV | 18.0mm | ISO-800 | Off Compulsory | 2012:10:12 11:36:07


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/60sec | F/4.0 | 0.00 EV | 18.0mm | ISO-800 | Off Compulsory | 2012:10:12 11:36:102012년 KSUG 큰일꾼이 된 고종봉님


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/30sec | F/3.5 | 0.00 EV | 18.0mm | ISO-800 | Off Compulsory | 2012:10:12 11:36:15

코엑스에서 열린 Deview 와 달랐던 느낌이 여기서 생겨난 듯 하다. Deview 때는 출판사와 협력업체의 부스만 있을 뿐이었다. 물른 출판사들에서 개발서적을 '염가판매'하는 이벤트를 하면서 좋은 서적을 저렴한 가격에 구매할 기회가 제공되는 것이기는 Deview의 진행은 상당히 깔끔히 진행되었다. 그래서 뭔가 아쉬웠달까...? 각 기업이 주최하는 컨퍼런스가 각각의 색깔을 가지기 시작한다는 것은 박수치며 응원할만한 것이다. 앞으로도 꾸준하게 진행이 되면서 국내 개발자들에게 '지식 공유의 장'이 되었으면 한다. 나처럼 중소기업에서 일하는 개발자들은 상당수가 밥벌어먹기 바빠서 당장에 쓸 수 있는 기술에 얽매이게 되는데, 조금은 더 풍족한 자원 속에서 다양한 시도를 해보고 나온 '경험'과 '지식'을 공유해주는 이런 행사는 사막의 오아시스처럼 갈증을 해소시켜주니까.


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/20sec | F/3.5 | 0.00 EV | 18.0mm | ISO-800 | Off Compulsory | 2012:10:12 11:38:35


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/15sec | F/3.5 | 0.00 EV | 18.0mm | ISO-800 | Off Compulsory | 2012:10:12 11:38:36


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/15sec | F/3.5 | 0.00 EV | 18.0mm | ISO-800 | Off Compulsory | 2012:10:12 11:38:40


NIKON CORPORATION | NIKON D80 | Not defined | Pattern | 1/15sec | F/3.5 | 0.00 EV | 18.0mm | ISO-800 | Off Compulsory | 2012:10:12 11:38:42

좋았던 것 중 하나는, '밥먹을 걱정'이 없었다는 거다. 점심식사를 제공해준 덕분에 '어디가서 밥을 먹어야 하지?'라는 하루의 큰 걱정을 덜 수 있었다. 다른 곳에서는 주변에서 밥먹을 곳에 대한 안내라도 해주면 좋겠는데 그렇지를 않아서 밥먹을 곳을 찾아 다니는데 상당한 시간과 노력을 쏟아야 했었다. 내가 좀 단순해서 '밥'주면 좋아한다. ^^




세미나를 들으면서 정리했던 내용에 대해서는... 내 머리 속에서도 정리를 하고 올리도록 하겠다. ^^;

아쉬우시면... 메모로 갈증 해소하세요. ㅎㅎ

2012/10/16 - [허니몬의 IT 이야기/프로그래머, '코드 디자이너'] - DevOn 2012 - 오전 메모

2012/10/16 - [허니몬의 IT 이야기/프로그래머, '코드 디자이너'] - DevOn 2012 - 오후 메모

2012/10/18 추가사항 :

DevOn 발표자료 : http://devondaum.tistory.com/18



0 0
허니몬의 IT 이야기/프로그래머, '코드 엔지니어'

올해 처음으로 Deview 2012(http://deview.kr/2012/xe/?mid=main)에 참가했습니다. 

  작년에 참가하려고 했다가 프로젝트에 치여지내느라 참가할 여유가 없었거든요. 올해는 SDEC 트랙도 포함해서 동시에 진행이 되었다고 합니다. 저는 당장은 DB와 관련된 관심사항이 없어서 SDEC 관련 트랙은 제외를 하고 들었습니다. 천여명의 국내 개발자들이 태풍을 뚫고 삼성동 코엑스 그랜드볼룸으로 모여들었습니다. 저는 회사에 교육신청을 하고 왔지만, 어느 개발자들은 연차를 사용해서 오는 경우도 심심찮게 볼 수 있었습니다. 개발자가 자신의 실력을 유지하기 위해 꾸준하게 이런 컨퍼런스 등에 참가하면서 소식들을 접해야한다는 것을 이해하는 임직원들이 많지 않다는 것이 참 슬프네요. 그것도 국내 대기업 IT회사들이 그런다는 것이 더욱 슬프군요.

  JCO때와 달리, 그랜드볼룸으로 가기 전에 접수대가 설치되어 있었습니다. 그래서 그랜드볼룸 쪽이 번잡하지도 않고 괜찮더군요.

LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/15sec | F/2.6 | 0.00 EV | 3.5mm | ISO-250 | Flash did not fire | 2012:09:17 10:09:07

SDEC 2012도 함께 진행되었습니다. 

빅데이터에 대한 이야기가 많이 다루어졌던 것 같습니다. 올해, 내년, 앞으로 당분간 DB와 관련된 트렌드에서 중요한 것은 클라우드 컴퓨팅과 빅데이터 처리가 아닐까요? 저는 당분간은 DB에 대한 직접적인 기술개발을 할 상황이 아니라 대충 어떤 흐름이겠구나 하는 정도지요. 몇몇 곳에서 하둡을 이용한 분산데이터처리를 시도하고 있는 것 같기는 한데, 아직은 컨퍼런스 등에서 '레퍼런스' 사례로 발표된 것은 못본 듯 합니다. 비싼 돈 주고 가는 세미나에서는 공유가 되었으려나요?

LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/12sec | F/2.6 | 0.00 EV | 3.5mm | ISO-400 | Flash did not fire | 2012:09:17 10:11:25

많은 사람들이 키노트를 듣기 위해 자리를 차지했습니다.

LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/10sec | F/2.6 | 0.00 EV | 3.5mm | ISO-640 | Flash did not fire | 2012:09:17 10:13:51


LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/30sec | F/2.6 | 0.00 EV | 3.5mm | ISO-320 | Flash did not fire | 2012:09:17 10:14:28


LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/13sec | F/2.6 | 0.00 EV | 3.5mm | ISO-320 | Flash did not fire | 2012:09:17 10:15:34

저는 키노트는 들을 생각이 없어서, 코엑스 맞은 편에 있는 카페에 가서 느긋하게 키노트가 끝나길 기다렸습니다. ^^;;

LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/15sec | F/2.6 | 0.00 EV | 3.5mm | ISO-250 | Flash did not fire | 2012:09:17 10:37:35



루비는 패셔니스타


LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/15sec | F/2.6 | 0.00 EV | 3.5mm | ISO-250 | Flash did not fire | 2012:09:17 13:00:01

  • Track A, Session 1
  • 발표자 : KTH 문추근
  • 루비는 만능, 최고?
  • 루비
    • 목표와 철학
      • 유키히로 마츠모토
        • Perl 보다 강력하고 Python보다 객체지향적인 언어를 만들고 싶었다.
        • 재미있는 프로그래밍, 프로그래머가 행복하게, 인간지향적인 프로그래밍(사람이 생각하는 바를 코드로 쉽게 옮길 수 있도록)
    • 특징
      • 객체지향 프로그래밍
        • 객체지향, 실제 세상과 닮아 있다. 코드로 옮기는데 적합하다.
        • 객체(데이터-자료, 행동-기능)
      • 루비에서는 모든 게 객체, 행동의 주체가 된다.
      • 유연한 문법
        • 몽키패치 : 실행 중 동적으로 코드 변경
      • 메타 프로그래밍
        • 자신만의 언어를 만드는데 유용한 문법코드
        • Attribute_accessor :name, :email -> 게터, 세터 제공
        • 코드의 양을 줄여주고, 코드를 개발자가 원하는대로 만들어주고
      • 반복 : for 문, while 문
        • 객체 대신 구문을 먼저 생각해야 하는 상황이 생겨 생각을 방해한다.
        • each, Enumerable
        • 객체를 먼저 생각하고, Enumerable 에서 제공하는 객체들을 먼저 생각하면 된다.
    • 영향
      • prototype
      • underscore.js
      • sugar
      • coffeScript
      • 루비의 유연한 문법을 차용
  • 레일스
    • 특징
      • 웹 프레임워크
      • 전통적인 MVC 구조, Router
        • Router를 통해서 가져온 URL을 바탕으로 컨트롤러에서 어떻게 처리할지 결정하고 Model과 통신하고 가져온 값을 View에서 처리
      • Scaffold
        • 15분 만에 블로그 만들기
        • 구조물
        • 자동으로 프로토타입으로 생성되는 파일의 구조를 파악하면 동작원리를 이해하는데 큰 도움이 될 것이다.
      • RESTful : CRUD
        • Create -> POST
        • Read -> GET
        • Upddate -> PUT
        • Delete -> DELETE
    • 영향
      • Backbone.js : 모델, 컨트롤러, 라우터 구조 가져옴
  • 루비와 레일스의 활용
    • 루비의 활용
      • Rake : Make의 루비버전
        • Backbone / Underscore / Zepto / Prototype
      • Homebrew
      • BDD
        • Cucumber
      • Terminal 기반 루비 프로그램
      • 개발자라면 ’터미널’에서 수족처럼 다룰 수 있는 스크립트 언어 하나는 있어야 한다.
      • 그 대안으로 ’루비’를 추천한다.
    • 레일스의 활용
      • 트위터, 그루폰, 깃헙, 슬라이드쉐어…
      • 한국에서는 왕따
        • 트위터에서 고래를 자주 봤지.
        • 트위터에서 루비를 걷어내고 있다더라
      • 등가교환의 법칙
        • 무언가를 얻기 위해서는 그와 동등한 대가가 필요하다.
        • 회사의 자원이 넘친다면 충분하다.
        • 스타트업, 사람, 돈, 시간이 없는 곳에서는 ’우선순위의 문제’를 겪게 된다.
      • 모바일 시대
        • 쏟아져 나오는 앱
          • 개발 속도가 더 중요한 서비스에 적합
        • MVC 구조는 죽었다.
          • 뷰가 중요하지 않은 시대
          • API 중심 서버
          • RESTful에 친숙한 서비스
    • 배워야 하는 이유
      • 매년 새로운 언어를 배워라.
        • 실용주의 프로그래머 Tip #8
        • 다른 언어는 동일한 문제를 다르게 푼다.
        • 그 언어에 맞는 해결방식을 이용하여 해결하도록 해라.
      • 언어의 한계가 곧 자기 세계의 한계다.
        • 나의 세계는 자바에 국한되어 있다.
  • 컴파일 언어 vs. 스크립트 언어
    • 터미널에서 스크립트를 작성하여 바로 테스트해볼 수 있다.
    • 자신이 하고자하는 작업에 집중하여 코딩이 가능하다.
  • 빠르게 언어를 배울 수 있는 방법
    • 배우려고 하는 사람의 성향에 따라서 달라진다.
    • 자신에게 맞는 방법을 찾는 것이 중요하다.


  • 정리
  • 새로운 언어를 배울 때에는 새로운 언어에 맞는 문제해결방식을 익혀두는 것이 좋다.
  • 루비(Ruby)라는 언어가 가지는 장단점에 대해서 가감없이 전달된 시간
  • 빠르게 개발하기 - 프로토타입 제품을 만들어내기에는 좋다.
    • ’빠르게 개발하기’와 ’빠른 성능’에는 차이가 있다.
    • 사람들은 이것을 제대로 이해하지 못하는 이들이 많다.
    • 루비로 빠르게 개발하여 제품을 출시한 후에는, 루비가 가지는 언어적인 한계를 정확하게 구분지을 필요가 있다.
    • 개발자는 그런 언어가 가지는 특징과 한계를 분명히 파악하고, 거기서 발생할 수 있는 문제를 파악하여 대비하는 능력도 필요하다.





 웹접근성, 어떻게 해야할까?



LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/10sec | F/2.6 | 0.00 EV | 3.5mm | ISO-800 | Flash did not fire | 2012:09:17 13:54:18


  • Track C, Session 2
  • 발표자 : 박대준(NTS 웹표준개발팀)
  • 웹접근성을 해야하는 분들을 위한 NHN 웹접근성 시행착오 프로젝트 경험담
  • 웹접근성이 뭔가요?
    • 접근성이란 장애인뿐만 아니라 모든 사람이 정보통신 기기나 서비스를 이용하는데 불편함이 없도록 해야하는 것
  • 해야 하나요?
    • 법 - 규제대응
      • 장애인차별금지법(장차법)
    • 자발적 참여 - 도의적
      • 무관심, 무관여, 무관찰
      • 주변에 직접적인 관찰의 기회를 가진 사람들이 없다.
      • Awareness : 결정권을 가진 분들을 대상으로 하여, 느낄 수 있도록 내재화 온오프라인교육
    • 웹의 태생 자체가 장애인들을 대상으로 해서 태어나지 않았다. 이 부분에 대해서는 생각해볼 여지가 많구나. 내가 장애인이 아니기 때문에 공감하지 못하는 부분들도 분명히 있다. 만약, 내가 장애를 겪게 되었다면 어떻게 대처하는 것이 좋을까?
    • 엔비전스(NVisions)
    • 보편성
    • 사용성에 대한 이슈 처리
    • 접근성이란 무엇인가 느끼게 하는 것이 중요하다.
  • 사용성이 떨어지진 않을까요?
    • 대부분 ‘오히려’ 좋아진다.
      • 적녹생맹 : 가이드라인
      • 페이지 네비게이션, 가이드
    • 고민되는 부분도 있다.
      • 일반 사용성과 장애 접근성
      • 장애인들은 각 요소들을 빠르게 뛰어넘는다.
        • 새로운 것이 업데이트 되었다는 것을 알아야할 필요가 있는가?
        • 새로운 것이 생긴 것보다는, 기존의 것이 유지되는 것이 더 중요하지 않은가?
  • 얼마나 적용해야 하나?
    • 어떤 서비스의 어떤 페이지에 어떤 수준으로 적용해야 하는가?
      • 모든 서비스의 모든 페이지를 전부다 적용해야 합니다.
      • 우선순위를 두고 점진적으로 적용
      • 접근성에 대한 효율적 접근 또는 전략
      • http://html.nhncorp.com/blog/42598
      • 시각장애에 포인트를 두고 접근성을 해결하자
    • 우선순위에 따른 점진적 적용
      • 우선순위
        • 소비성 컨텐츠 > 비소비성 컨텐츠
      • 적용범위
        • 모든기능 및 모든 페이지 > 동영상 > UGC
      • 적용수준
        • 시각장애 대응 수준 + 지체 장애
          • 스킵 네비게이션
          • 브라우저 타이틀
          • 대체 텍스트
          • 자동 재생 컨텐츠 제어
          • 키보드 사용 보장
  • 해야 하나요?
    • 선형화 - Linearization : Make sense when linearized
      • 시각장애인들은 마우스를 사용하지 않는다.
    • 대체 텍스트 - Alternative Text : The use of alternative-text is fundamental to accessiblility
      • 정보성 이미지는 대체 컨텐츠(텍스트를 제공)
      • 대체 텍스트가 영문일 경우, 정확한 의미전달을 위해 국문으로 입력
    • 적용범위 : 서비스 공급자가 제공하는 모든 정보성 이미지
    • NWCAG 1.0
      • 체크리스트
  • 모르겠어요
    • Ajax application
      • ex) 네이버 지도
        • 지도는 적용하기 어렵다.
        • 마우스 인터렉션 이외의 부분들에 대해서 지켜줘!!
      • Fallback, text
    • 동영상
      • 이상적 : Html5 로 대체
      • 현실적 : 키보드 조작이 가능한 컴포넌트를 제공하여 컨트롤
    • 그래프(차트)의 대체 텍스트
      • 복잡한 정보를 담고 있는 경우 모든 정보를 텍스트로 제공
      • 복잡한 정보를 담고 있는 경우 모든 정보를 전달할 수 없기 때문에 정보를 요약하여 선언한다.
  • 하긴 했는데 맞게 했나요?
    • 누가 맞나요?
    • UX 가이드
      • 스킵 네비게이션
        • 문서의 최상위에 위치, Tab키를 누르면 노출,
        • Skip to main menu : 메인 메뉴 바로 가기
        • Skip sub menu
        • Skip to content
        • 변하지 않고 고정된 3개의 Skip menu 를 제공(Tab을 이용) : 이것에 대한 적용은 장애인들의 웹사용방법에 대한 이해가 필요하겠다.
        • 노출 인터렉션
      • 자동재생 컨텐츠
        • 컨텐츠 자동생신 문제점
        • 페이지 리프레시, 리다이렉트
          • 일정시간이 자니면 리프레시가 발생한다.
        • 롤링컨텐츠
          • 해당 컨텐츠를 만났을 때 사용자가 제어할 수 있도록 한다.
      • 자동재생
      • 제어 기능의 위치
  • 웹 접근성에 대한 공감




  • 정리
    • 웹 접근성과 호환성(크로스 브라우징)은 다른 것이구나.
    • 마우스 없이 키보드만으로 웹을 사용할 수 있다면, 그건 개발자들에게도 좋은 일이겠…지? 그걸 적용하는 건 귀찮은 일이겠…지?





스칼라, 미지와의 조우




LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/13sec | F/2.6 | 0.00 EV | 3.5mm | ISO-320 | Flash did not fire | 2012:09:17 15:28:26


  • Track A, Session 4
  • 발표자 : SKP 이동욱 매니저, Platform SW 개발팀
  • Content
    • Scala 맛보기
    • 함수형 프로그래밍과 객체지향의 조우
    • 패턴 매칭과 조우
    • 정리의 시간
  • 미지와의 조우 : Close encounters of the third kind
  • 40분 동안 무엇을 할까?
    • 주입식으로 결정
    • 스칼라의 기본적인 뭄법을 주입식으로 익히고 자바에서 지원하지 않았던 몇가지 기능 확인
  • Scala 맛보기
    • Scala = Scalable Language, 마틴 모더스키?
    • Scala는 JVM 위에서 돌아간다.
      • Java의 성능과 유사하다.
      • 스칼라의 표현력을 이용하여 세련된 프로그래밍이 가능하다.
    • 인포그래픽으로 보는 Scala
      • 스칼라를 유명하게 만든 건 트위터?
      • 루비로 되어 있던 백단을 스칼라로 변경하면서 세간의 관심을 받기 시작
      • 아직은 마이너리한 위치에 있다
    • Scala는 하이브리드 언어
      • Java, ML, Smalltalk, Earlang, Haskell, Eiffel
    • Scala를 이용해 여러 언어들이 제공하는 특징을 접할 수 있습니다.
    • 스칼라의 전반적인 모습
      • Java Platform / .Net
      • 강화된 타입 시스템(동적 타입 시스템)
      • 객체지향
      • 함수형 프로그래밍의 패러다임을 안고 있음
    • REPL : Read -~~ command line
    • Scala는 모든 것이 객체
    • 엄청난 속도로 배우기!!
      • 변수, 그리고 타입 추론
        • val : read only, var = read-writable
      • 함수 선언하기
    • 중급편 들어가기
      • Object 이해하기
      • 튜플(Tuple) : 다른 타입의 자료를 담을 수 있는 그릇(Container Object)
        • 튜플 패턴을 이용한 대입
          • 각 자료형에 맞는 패턴이 있어 대입/반복문 등에 활용할 수 있다.
      • List : Scala의 기본적 컬렉션 클래스
      • Map : Key-Value 로 튜플을 만들어서 보관
      • Option
        • 존재할 수도/안 할 수도 있는 선택적인 값을 나타낼 때 사용.
          • Key가 없는 경우
          • Key는 있는데, 그 값이 Null인 경우?
    • 언어는 어떻게 발전하고 있는가?
    • 프로그래밍 언어가 추구하는 이상
      • 문제 영역의 크기나 복잡도가 증가하여도 가능하면 간단한 표현으로 문제 해결이 가능해야 함
    • 객체는 어떤 내용을 담는가?
      • 객체에게 적절한 역할을 분배하는 쪽에 집중되어 있음
      • 객체에게 역할을 부여
      • 어떻게 흐름제어를 할 것인가?
      • 어떻게 함수를 손쉽게 표현할 것인가?
    • 프로그래밍 스타일에 따른 시간/품질 분석
  • 함수형 프로그래밍과 객체지향의 조우
    • 스칼라의 위치 : 함수형과 명령형의 중간 어딘가
      • 명령구문을 많이 사용하면 명령형
        • 명령어 위주 : if, for, while
      • 함수호출을 많이 하면 함수형
        • 함수위주 : pass, store, return 가능
    • 함수 리터럴 선언
      • 함수 리터럴을 이용해 함수를 인자로 전달하거나, 변수에 저장, 반환할 수 있다.
      • Lamda 함수
    • Collection에게 던져주기
      • 루프를 이용한 List 조작하기
      • Higher-order method로 List 조작하기
    • underscore.js
      • higher-order method 많이 사용
    • Scala에서 자바를 보다.
  • 패턴 매칭과 조우
    • Programming in Scala
      • 1/2 - 880p
    • Scala의 패턴 매칭 - 기본 문법
      • Match ~ case는 자바의 switch ~ case와 닮았어.
      • 변수, 타입, 와일드 카드, 생성자 패턴, 시퀀스패턴(List), 튜플(Tuple), 패턴 혼합
      • 패턴 매칭 : 객체지향적으로 개선된 분기문
      • extractor를 통해 객체를 분해, 패턴으로 표현하기
  • 정리의 시간
    • 일단 학습 내용이 다양하다. 한번 봐선 잘 모른다.
      • 자바는 기본
      • 함수형 프로그래밍
      • 여러 언어의 특징들을 익히게 된다.
      • 꼬리 재귀, 패턴 매칭, 강한 타입 언어
      • 타입의 설계및 qusgud rhksfus sodyd
      • 동시성 관련 기법들
    • 혼자하긴 힘들어요!
    • 발표 이후 스칼라와 어떻게 만날 수 있을까?
      • Programming in Scala
      • 9월 18일부터 Martin Ordersky 의 직강 시작 @Coursera
      • scala-korea
      • Typesafe
      • github 번역







 Google Engineering Culture




LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/13sec | F/2.6 | 0.00 EV | 3.5mm | ISO-320 | Flash did not fire | 2012:09:17 16:30:27


  • Track E, Session 5
  • 발표자 : 권순선
  • 구글 : 개발자 relationship, 개발자 지원
  • 약력 : kldp, 삼성, nhn, google
  • 발표에는 위트가 섞여 있어야 한다잉.
  • 근무시간 :
    • 8시 출근~5시 퇴근, 야근 아침 10시 출근~7시 퇴근
    • 자율 출퇴근
    • 자신이 자율적으로 필요한 시간을 조절할 수 있다.
    • 자신에게 맞는 시간을 효율적으로 조절가능
  • 보고
    • 일한 것을 상관에게 보고
    • 보고를 위한 형식적이고 소모적인 보고서를 만들어내야 한다.
    • 내용에 집중하면 되고, 메일을 통해 보고
  • 투명성
    • 같은 팀, 옆팀이 뭘하는지 알 수가 없다.
    • 직원들이 각자하는 일의 진행상태와 목표를 확인할 수 있다.
  • 채용
    • 채용이 까다롭지. 실무자들이 참가
    • 실제로 같이 일을 할 사람들이 면접에 동참
      • 같이 일을 하고 싶은지 동의되어야 통과된다.
      • 실력이 있어도 통과하기 어려워질 수 있다.
  • 매니저
    • 관리자
      • 마이크로 매니지
      • 자율적으로 일하도록 냅둬
      • 평가에는 관여, 일을 하는데 지시를 해서 움직이지 않는다.
    • 우리나라 기업 임원
    • 상향평가
      • 직원들이 임원을 평가




  • 정리
    • 구글에 대한 개발자들의 관심이 높다.
    • 구글의 내부적인 문화에 대한 소개와 관련된 내용은 익숙했다.
    • 참관하는 사람들이 관심있었던 건, ’어떻게 들어갈 수 있는거지?’가 아니었을까?





 Netty Internal



LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/13sec | F/2.6 | 0.00 EV | 3.5mm | ISO-320 | Flash did not fire | 2012:09:17 17:23:24


  • Track E, Session 6
  • 발표자 : 이희승(Twitter 소프트웨어 엔지니어)
  • 소개
    • 네티란?
      • 사용자들이 참관을 많이 했네.
      • Java network application framework
        • http://netty.io/
        • @netty_project
      • 비동기 & 이벤트 기반
        • 요즘 추세는 비동기인가?
        • 적은 자원, 스레드, CPU 사이클
      • API 는 I/O 추상계층, 추상계층 API
        • works with NIO, OIO ,AIO(Asynchronized) & more without many changes
      • 잘 정의된 이벤트 모델 & 스레드 모델 : Well-defined event model & thread model
      • Flexible event handling with bi-directional chain of responsibility pattern
      • Promotes ‘separation of concerns’
        • I/O Layer(netty)
        • Protocol codec(Netty or user)
        • Business Loginc(User)
    • 구성요소
      • 이벤트 루프
        • 유사한 경우
          • 윈도우 이벤트 dispatcher
          • swing event loop
          • reactor
        • 사용자의 I/O 요청 처리
          • 이벤트 루프 스레드 내에서 요청했을 경우 즉시
          • 이벤트 루프 스레드 외에서 요청했을 경우 루프의 작업 큐에 넣어 스케쥴 처리
        • 외부의 자극에 반응하고 파이프라인에 알림
          • 데이터를 읽어들임
          • 소켓 버퍼가 꽉 찼음
        • 사용자가 원하는 임의 작업 실행
      • 파이프라인
        • BiDiCoR
          • Bi-directional Chain of Responsibility pattern
          • Similar to Servlet filters and decorator pattern
        • Inbound Event
          • 이벤트 루프가 발생시킨 이벤트(소켓 연결, 데이터 수신 등)
          • 사용자가 작성한 inbound Event 가 수신할 수 있도록 해줌
        • Outboud Event
          • 사용자가 요청한 동작(쓰기, 읽기 일시중단 등)
          • 사용자가 작성한 outbound event handler가 다른 핸들러에서 요청한 동작을 가로챌 수 있도록 해줌
          • 최종적으로 루프에 전달되어 실제 I/O가 수행되도록 함
        • Outbound Event
          • 선형적으로 구성되어 있지만, 로직에 따라 다르게 구현
      • Transports
      • Handlers : Component
        • 다양한 프로토콜을 제공해서 사용자가 사용할 수 있도록 하고 있음
        • 자기만의 핸들러를 작성해서 사용가능
      • I/O abstraction - Channels, Event loops and pipelines
  • 이벤트 모델
    • 기존 이벤트 모델
      • 이벤트 = 자바 객체
      • 이벤트가 발생할 때마다 자바객체가 생성되어 이것을 핸들링
      • 효율성에 대한 의심이 생겨남
      • 가정
        • Is GC cheap?
          • 작은 객체에 대한 GC 처리비용이 저렴하지 않았다.
        • Can buffer pool beat JVM’s memory allocator?
          • 자바기반의 메모리 할당을 빠르게 가져올 수 있을까?
        • Too many state events?
          • 사용자에게 제일 관심사항은 ’연결(Connected)’이다.
        • new buffer is created on every MessageEvent
          • GC pressure
          • User has no cotrol over the buffer
            • 사용자에게 제어권이 없지.
        • No Buffered flush
          • Every Write is an immediate flush.
            • 모든 쓰기는 즉시 flush가 된다?
            • Sometimes not desired?
    • 새 이벤트 모델
      • 이벤트 = 메소드 호출
      • 상태 전이 단순화
      • 핸들러가 수신 및 송신 버퍼를 만들어 네티에게 제공하면 지속적으로 재사용
      • Bufferd flush
        • Outboud 버퍼를 사용하지 않아.
      • 훨씬 적은 GC 빈도
      • 단점
        • 이벤트 유형별로 메소드를 전부 정의해야함(코드 중복)
        • 사용자 정의 이벤트 처리 어려움
          • 별도로 UserEventTriggered 메소드 추가
  • 스레드 모델
    • 왜 필요할까?
      • 잘 정의된 스레드 모델의 필요성
        • 프레임워크에서 사용자의 코드가 어느 스레드에서 언제 실행될지 충분히 정확히 정의해야 함
        • 프레임워크가 어느 정도의 Thread safety를 사용자 코드(e.g. 이벤트 핸들러)에게 제공할 것인가?
        • 정확한 스레드 모델이 제시되지 않으면 사용자 코드는 방어적으로(또는 부정확하게 작성됨)
        • 예 : 네티의 SSL 핸들러
    • netty 4 스레드 모델
      • 3.x 대비 이벤트 모델 개선과 함께 가장 중요하고 긍정적인 변화
      • 네티는 핸들러가 @Sharable 어노테이션이 붙어 있는 경우가 아니면 절대 같은 핸들러 메소드를 동시에 호출하지 안흔다.
      • 네티가 핸들러 메소드를 호출할 때 각 호출 사이에는 happens-before 관계가 성립한다
      • 이벤트 루프는 항상 싱글 스레드로 실행된다.
  • 테스팅
    • 네티 유저의 테스트
      • 네티는 EmbeddedChannel 이라 불리는 Channel 구현을 제공
      • 사용자는 자신이 작성한 핸들러를 EmbeddedChannel 의 파이프라인에 추가하고 이벤트를 임의적으로 발생시켜 테스트
    • 네티 자체의 테스트
      • 각 트랜스포트의 정확한 동작을 확인하기 위해 모든 트랜스포트 조합과 주요 프로토콜 조합에 대해 교차 테스트 수행
        • 모든 종류의 소켓 통신에 대한 테스트 처리를 함
      • 자체 제공 핸들러의 경우는 EmbeddedChannel 을 이용
      • 기타
  • 생각할 거리
    • Dynamic Event routing
    • Statistical Distributed performance Analysis on mesos cluster
      • 버전업 될떄마다 성능에 대한 이슈가 발생
    • Management and monitoring
    • Native Transport
      • 추상화된 계층을 제거
    • Scalable community
      • 커뮤니티의 건전성을 어떻게 벗어날 것인가
  • 이벤트에 대한 처리방식이 중요한 부분이구나.
  • netty 4 alpha, 문서화 작업 등의 작업을 마친 후 beta 출시 예정(올해 하는게 목표!?)




  • 정리
    • Netty를 사용하는 사람들이 많구나.
    • 비동기식, 이벤트 기반의 플랫폼들이 많은 인기를 받고 있구나.
    • 개발자가 차분하고 우리말로 경건하게 발표하는 모습은 종교적인 느낌이 들긴 했다. ^^;



 

몇몇 분들과 이야기를 나누어본 결과, 2012 JCO 컨퍼런스보다는 더욱 실속이 있었다.

Google Engineering Culture 를 보면서 문화쇼크를 기대했었는데...


약간 못미친 감이 없지 않아 있다. ^^;;

약간 피곤하기는 하지만, 전체적으로 유익한 컨퍼런스 였다.

역시 여기서도 숙제를 찾아냈다. 웁스.

0 0
허니몬의 IT 이야기/리눅스 이야기, 우분투

적용환경 : 우분투 10.04 64bit Server

주제 :

프로젝트 유틸리티

- 버전 관리 시스템 : SubVersion(VCS:Version Control System), Git(DVCS : Distribute Version Control System)

- 빌드 자동화 시스템 : Hudson

- 이슈 관리 시스템 : RedMine, Trac

- 통합 프로젝트 유틸리티



1. 버전 관리 시스템(VCS : Version Control System)

 프로젝트에서 사용된 소스는 물론 여러가지 문서, 파일 등을 관리할 수 있는 시스템이다.

     1.1. SubVersion 개요 및 특징

     1.2. SubVersion 설치 및 설정

          1.2.1. svn protocol 사용방법

          1.2.2. http protocol 사용방법

     1.3. SubVersion 사용방법

          1.3.1. CUI(Command) 환경에서 사용방법

          1.3.2. 이클립스 환경에서 사용방법

     1.4. SubVersion 관련 팁(Tip!)

     1.5. Git 개요 및 특징

     1.6. Git 설치 및 설정

     1.7. Git 사용방법

     1.8. GitHub 사용방법


2. 이슈 관리 시스템(Issue Manager System)

  흔하게 알려진 이슈 트래커(Issue Tracker), 버그질라(BugZilla) 등의 설치 및 실행방법

  2.1. 왜 쓰는걸까?

  2.2. 어떤 특징들을 가지고 있을까?

  2.3. RedMine 설치 및 설정방법

  2.4. RedMine 사용방법

    2.4.1. 브라우저로 사용하기

    2.4.2. 이클립스 플러그인으로 사용하기

  2.5. RedMine 관련 팁(Tip!)



3. 빌드 자동화 시스템(Build Automation System)

컴파일, 배포 파일 생성 및 배포 등의 반복적인 작업들을 한번에 처리할 수 있는 시스템이다.


     3.1. 빌드 자동화 시스템이란?

     3.2. Hudson 의 개요 및 특징

     3.3. Hudson 설치 및 설정

     3.4. Hudson 사용방법

     3.5. Hudson 활용팁




이제 쓸 수 있을 것 같...은가?

올해 안에 써야지.

0 0
허니몬의 IT 이야기/프로그래머, '코드 엔지니어'

20120627 TDD 실천법과 도구 - 2년 뒤

장소 : 회현 부근 LG CNS 2층 대회의실 발표자 : 채수원님


  채수원님의 책 [테스트 주도 개발 TDD 실천법과 도구] 책이 출간된지 2년의 시간이 흘렀다. 이 책이 나오기전 뭣도 모르는 상태에서 베타리딩을 신청했다. 베타리딩을 할 때도 그렇게 열심히 했다는 생각은 들지 않는다. 당시에 빠져있던 지독한 무력감을 벗어나기가 참 어려웠다. 그래도 꾸역꾸역 베타리딩을 하면서 TDD에 대해서 눈을 뜨게 되었다. 

'빨강(실패, fail!!)'에서 '파랑(성공, Success!!)'으로 바뀌는 재미를 느낀거다.


테스트 주도 개발 TDD 실천법과 도구

저자
채수원 지음
출판사
한빛미디어 | 2010-06-16 출간
카테고리
컴퓨터/IT
책소개
효율적인 설계와 간결한 코드를 만드는 필수 TDD 기법『TDD ...
가격비교


출처 : 아웃사이더님 인스타그램 : http://instagram.com/p/MX7-gIsvxw/


아.. 난 몰라.. 

나도 모르겠다!!

  채수원님이 어떤 이야기를 해주실지 두근두근하는 마음으로 자리에 앉았다.


  • 푸뤼하게 진행하는 것!! Free style!!
  • think smart - Change the world.

2년 동안

국내외의 내노라하는 개발자들이 모였다.
  • How do you do?

    I'm fine, and you?

  • 2010년
    • 난 뭐했지?
      • 나 말 정말 못한다. ㅡ0-)!! 이래 가지고 어디가서 발표할 수 있겠어?
  • 2011년
    • 모바일 교보문고
      • XP - 스프린트
      • 스프링
      • 스프링 시큐리티
      • ibatis
      • 아무 생각없이 한 것 같다. 그래... 좀 더 집중해서 했어야했어.
    • 회사 솔루션
      • DDD
      • TDD
      • 난 삽질 중이야. ㅡ0-)!!
    • 애자일
      • TDD
      • 짝코딩
      • 기획, 디자인 파트
      • 기획, 디자인과 개발 파트가 한데 어우러진 팀
    • 코딩 해본 게 언제인가?
      • 시뮬레이션
    • 봄싹 스터디에서 만나게 되었다.
      • 취업 사기단
      • 애자일을 적용할 수 있는 가능성
      • 안드로이드 번역
    • TDD
      • 주요 기능에 대한 테스트 이외에는 테스트케이스를 줄어들 게 되고 있다.
      • 업무적으로 테스트 커버리지 맞추라는 강요에 흥미를 잃어가고 있다.
    • 사람들의 무관심
      • 애자일
      • XP 스프린트에 대한 이야기가 점점 잦아들고 있다.
    • 애자일, 스크럼과 XP
    • 2년 전과 지금
      • 지쳐서 도망갈 사람은 도망갔다.
      • 체력 싸움
    • HTML5 & JavaScript -> App publish(Sencha였던가?)
    • Embeded
      • 2년 사이
    • 애자일 코칭
      • TDD가 잘하는 것만으로는 불충분 하다.
      • TDD가 아닌 것들
      • 몰라서 못하는 것보다 알면서 못하는 것이 더 힘들다.
      • TDD를 어려워하는 사람들
      • 정상적으로 돌아가는 것들에 드는 비용을 줄여라.
    • 안영회
      • TDD로 개발하는 지, 개발 후 jUnit만 끼워넣는 건지…
      • 프로젝트에서 테스트 커버리지를 정해놓고, 그걸 맞추기 위해 노력하게 된다.
      • 작게 쓰고 모호한 것들은 TDD를 통해서 진행하는 것이 좋다.
    • 루비를 쓰는 개발자
      • 보릿고개를 살아가고 있는 개발자
      • 루비 하지 마세요. ㅎㅎ
      • Startup
    • NHN 황상철
      • Spec by example -> 요구사항에 맞춰서 테스트를 작성해내는 것?
      • 어려워요. ㅡ0-)~
    • 서버, 통신쪽 위주로 한점
      • 스쿱미디어 CTO
  • TDD로 개발을 한 적 있나요?
    • 팀 전체가 TDD로 개발을 한적 있나요?
    • 몇 명쯤 변화 시켰나요?
      • 누군가를 변화시킨 적이 있는가?
    • 뭘 배웠을까?
    • 한 달 만에 20년 산 포도주와 비슷한 맛의 포도주를 만드는 방법!
      • 한달에 4시간 일하기!!?
      • 독하게 하는 사람들 : 소믈리에
      • 들어봐~~
  • 왜 안될까??
    • TDD를 써야 하나?
    • TDD가 안되는 이유?
    • 개발이 잘 안되는 이유?
    • 프로젝트가 실패하는 이유?
    • 오바하지마! vs. 원래는 안되는 거야!
      • 불편해하거나
      • 지속적으로 하지 않거나
  • CBD 실패의 이유…
    • 쓸 일이 없다.
    • 함수 -> 객체 -> 컴포넌트 의 단계를 제대로 겪어오지 못했다.
    • 방법론 등이 실패하는 이유
      • 사람은 쉽게 바뀌지 않는다.
    • 기술이 받쳐주지 못하기 때문에
      • 과거에도 있었지만, 현재에 그 개념을 구현할 수 있는 기술이 지원하기 때문에 유행되기 시작한 것들이 있다. 실패하게된 이유 중 하나는 그 당시에 개념들을 지원한 기술이 없었기 때문이다.
      • 공격과 방어!! +_+)~
    • CBD의 개념이 다르다.
      • 장사꾼(밴더, Vendor)
    • 무엇을 하려고 했는지 초심을 잊고, ‘어떤 결과를 얻으려는 욕심’ 키워갔다.
      • ‘무조건 된다’ 라는 욕심
    • ’문제가 있다.’는 큰 문제는 아니다.
      • ‘한 사람이 그 문제를 고민하면 된다.’
    • 다르게 생각한다.
      • 실패를 했다는 이야기… 성공을 한 것은 뭘까?
      • 성공과 실패를 말하기는 쉽지 않다. 언뜻 보면 모두 실패 같다.
      • 다른 렌즈로 보고 있다.
      • “어차피 안된다.”
        • 혈당이 낮으면 의지력이 떨어진다.
    • 목표와 역량의 차이!!


출처 : 정용식님 페이스북 :http://www.facebook.com/photo.php?fbid=386681444723742&set=a.163284913730064.36566.100001456685573&type=1&theater


배운점

  • 기술이 없어서 못하는 경우는 없다.
    • 핑계다!
    • 하는 사람은 다 해! -> 기술이 없어서 못한다고 생각한다.
    • 밀린다.
  • 왜 실패할까?
    • 무지 : 문제가 뭔지 몰라
    • 무시 : 변화를 시도하지 않는다.
    • 무지속 : 시도를 지속하지 않는다.
    • 무개선 : 개선하지 않는다. -> 내 이야기 같어!!
  • 대상이 없으니 감동이 적다
    • TDD로 뭘 해결할 수 있나? 무엇을 할 수 있는가? 목표의식?
    • 신기함은 잠깐
    • 감동도 잠깐
      • 현실이 녹녹치 않아요.
  • 재미가 없다
    • 커버리지의 압박!!(테스트 커버리지 압박, 수치로 체크!!)
  • 고민
    • 개인 ‘어떻게 하면 개발을 잘할 수 있을까?’
    • 회사 ‘좋은 개발자를 만들기 위해서는 어떻게 할까?’
  • 걍 하지 말까…
  • TDD 잘하는 사람 : 관찰하기
    • 우선 채수원님
      • 좋아하는 데 열심히 하는데 못하면 심란하다.
    • 협력업체 직원
      • 해야하니까.
    • 잘 하는 것처럼 보이는 캐릭
      • 우리팀 1등 개발자!!
    • 다음과 같은 조건을 가진 사람
      • 경험의 소유자 : 장점의 기억(좋은 경험을 가지고 있는 사람)
      • Divide & Conquer : 분할과 정복!?
      • 협력
    • 묻지 말게하고 시키자!!
      • 설계 먼저 하기
      • Given/When/Then : 기억을 남긴다. 자신이 테스트하려고 했던 것의 느낌…
      • Pen/Paper로 미리미리 그려보기
    • TDD 해보려면
      • 계획을 세우고, 연습을 하고, 피드백을 준다.
        • 기능 요구사항이 명확한지 확인
        • 머리속으로 단게를 그리고
        • 종이에 적어보기
        • 단계별로 확인해야할 경우 보기
    • 가장 중요하면서도 괴로운 질문
      • 시나리오를 써내려가서 문맥을 유지해라.
      • 지금 작성하려고 하는 코드에서 테스트를 작성할 수 있는 가장 간단한 것은?
        • 끊임없이 묻고 답하라.
      • LUHN 공식
        • 한국말인데 모르겠어.
        • Given : 16자리의 숫자가 나타난다.
        • When : - 우측숫자부터 2번째 숫자마다 2를 곱하고? - 1번째 숫자는 합쳐?
        • Then : 보안숫자와 일치해야한다 : 내 카드 번호 945가 나와야 한다.
    • 누가 좀 도와줬으면 좋겠어~ Some body help!!
      • 코드 리뷰 하자!! 라고 하면…
    • Mock Object
      • 개발자들은 Mock에 매우 흥미를 느낀다.
      • 하지만 불필요하게 만들어지는 코드가 많다.
      • 안쓰는 경우가 더 좋다.
    • 짝코딩!!
      • 짝으로 시키니 훨씬 낫다!!
      • 성공조건!!
        • 둘이 함께 같은 업무를 개발하는 것이다? -> 나는 O!!
        • 재미있으면 되지!! 둘이 같이 일하는 것을 편안하게 즐겁게 생각하면 되지 않을까나?
        • 가치관의 차이를 좁혀가는 것?
        • 가치관이 달라도 괜찮아. - 서로 다름을 이해하는거야. 소셜스킬(살이 닿고 호흡이 섞이고 코드가 섞이고… 응?) - 갈등해소 능력!!
        • 페어 프로그래밍을 할 때 중요한 상황은 화면보다 사람 사이에서 발생한다.
        • VIsion Planning : 함께 달성하고자하는 목표를 함께 얻는 것을 목표로 한다.
        • 요령과 발생할 수 있는 문제점, 그리고 대처 방식을 사전에 알려주어야 함
        • 드라이버와 네비게이터의 역할을 분명하게 할 것
      • 효율 높았던 경우
        • 프로젝트 초반
        • 서로 낯설었던 경우?
      • Do
        • 상대방에 대한 존중
        • 개발 업무의 목표를 잊지 않을 것
      • Don’t
        • 짜증
        • 100분 토론
        • Don’t에는 Do를 붙여라!
      • 짝코딩 실패 케이스
        • 자존심 대결
        • 마이크로 컨트롤 : 세세한 컨트롤, 지시를 내리고 기다리는 것에 미숙함
        • 너무 쉽거나 너무 어렵거나
        • 모르쇠로 일관하게 되는 경우?
      • 이건 뭐지!
        • 하면 좋긴 한데 힘들다.
        • TDD 안해도 된다.
        • 단위 테스트를 잘 만들면 좋다.
      • 외쿡!
        • 외국 소스들은 안그렇던데?
        • 없으면 defect report도 의심함
        • 기능추가 해도 테스트 코드 없으면 pull 안 받아줌.

정리

  • 기법/테크닉 별로 도움 안됨
  • 습관만이 살길
  • 느끼지 못하면 지속되지 않는다.
    • 재미를 느끼고 본인이 지속적으로 하지 않으면 변하지 않는다.
  • 사례와 상황들
    • 신입은 참 잘한다.
    • 정말 잘한다.
    • 기존 사원은 습관이 무섭다고 잘 안된다.
    • 머리 좋은 사람들도 경계해야 함
    • 함께 연습하면서 하는 것이 짱!
    • 버전업 때 변경사항을 수정하기 편리하다.
    • 문제는 대부분 테스트코드를 작성하지 않은 부분에서 생긴다.
    • 남코드 고치기에도 좋음
  • 업계 선배들의 책임
    • 본인 살기도 힘든 건 알지만 후배들도 챙기자
    • 후배가 없으면 동기 좀 챙기자
    • 선배랑도 잘 지내며 선배도 챙기자

회고


개인 의견

  • 김창준님 처음 뵙니다! ㅡ0-)~?
  • 채수원님의 책을 읽고 어디가서든 "TDD 합니다."라고 이야기 하지만, 실제로 TDD로 개발하는 경험은 그리 많지 않았다. TDD로 개발하기 보다는, 먼저 기능을 구현하기 거기에 짜맞추든 단위테스트를 진행하는 '착한 테스트'를 더 많이 하는 그런 개발자였다.
  • 개발자들 사이에서 애자일, 스크럼, XP 등의 이야기가 잦아들기 시작하는 이유는 뭘까?
  • 새로운 방법론과 개발론을 적용할 때 '왜 해야하는지'에 집중하기 보다 그것을 통해 '무엇을 얻을지'에 관심을 기울이고 있기 때문에 널리 퍼지지 않는 것은 아닐까?
  • 좋은 것이 있다는 것은 알지만, 쉽게 전파하기 어렵다.
  • 수원님이 TDD를 하시면서 전달하고 싶으신 내용이 많으셨던 것 같다. ^^;
  • 다른 사람들도 TDD 등에 대한 이야기를 서로 나누고 싶어하는 눈치였다. 조만간 이런 자리가 다시한번 마련되지 않을까하는 기대가 된다.
  • 말을 물가로 끌고 가기는 쉽다. 그러나 말에게 물을 먹이기는 어렵다. // 강제로 TDD를 시킬 수는 있다. 그러나 스스로 TDD를 즐기면서 개발하기란 쉽지 않은 법이다.



1 0
분류없음

내일은 개발자 공감 세미나가 있는 날이군요.

이번에 발표내용들은 마음에 드네요.

클라우드 컴퓨팅과 관련된 이야기는 여전히 내게는 멀고도 먼 이야기.

당분간이 될 수도 있고, 앞으로 계속 쭈욱 그럴수도 있고...


바쁘지도 않은데... 무엇이 문제란 말이더냐.

포스팅이 적은 이유....

게임에 미쳐서!! 공부와 개발에 미쳐야하는데...

게으름에는 장사가 없... 핑계가 좋다.


0 0
1 2 3 4 5 6 ··· 8
블로그 이미지

Email : ihoneymon@gmail.com 안녕하세요, 꿀괴물 입니다. ^^ 멋진 비행을 준비 하는 블로그 입니다. 만능형 인간이 되어 많은 이들에게 인정받고, 즐겁고 행복하게 살기를 간절히 원합니다!! 달콤살벌한 꿀괴물의 좌충우돌 파란만장한 여정을 지켜봐주세요!! ^^

허니몬