'허니몬의 IT 이야기/프로그래머, '코드 엔지니어''에 해당되는 글 99건

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

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




  가을은 '수확의 계절'이라고 한다. 개발자들에게도 '수확의 계절'이 있다면 단연코 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)을 좋아한다.

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

좋았던 점

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







OKJSP를 운영하고 계신 허광남(@kenu)님. SW개발과 관련된 분야에서 왕성하게 활동하고 계시는 활동가시다.




2012년 KSUG 큰일꾼이 된 고종봉님


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





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




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

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

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

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

2012/10/18 추가사항 :

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



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

이번에는 진짜 자바개발자를 위한 세미나가 된, [제9회 개발자를 위한 ‘共感(공감)’ 세미나]가 열립니다.

오는 10월 20일 교보타워 23층 회의실에서 열립니다.

선착순으로 제공하는 경품을 위해 1시 이전에 도착하려고 무던히 노력하고 있는데 그게 쉽지가 않은 세미나!!

이번에 발표하시는 분들 모두가 자바쪽에서는 한가닥 하시는 유명하신 분들입니다. 벌써 어떤 내용으로 발표를 하실지 기대감이 부풀어 오르고 있습니다. 매번 참가할 떄마다 만족스러운 세미나 중 하나입니다. ^^ 서둘러 신청하시고 같이 들어요! 


참가신청 사이트 : http://onoffmix.com/event/9706


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

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

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

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

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

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

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



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



루비는 패셔니스타


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





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




  • 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을 이용) : 이것에 대한 적용은 장애인들의 웹사용방법에 대한 이해가 필요하겠다.
        • 노출 인터렉션
      • 자동재생 컨텐츠
        • 컨텐츠 자동생신 문제점
        • 페이지 리프레시, 리다이렉트
          • 일정시간이 자니면 리프레시가 발생한다.
        • 롤링컨텐츠
          • 해당 컨텐츠를 만났을 때 사용자가 제어할 수 있도록 한다.
      • 자동재생
      • 제어 기능의 위치
  • 웹 접근성에 대한 공감




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





스칼라, 미지와의 조우





  • 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





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




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





 Netty Internal




  • 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 를 보면서 문화쇼크를 기대했었는데...


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

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

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

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

검정문어가 참 귀엽네.


https://status.github.com/ 에서 깃헙의 서비스 상태를 확인가능하다. 오우~


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

난 아직까지 단순한 코더라고 생각한다.


리눅스 약간 알고,

컴퓨터 약간 알고,

자바 약간 알고,

스프링 약간 알고,

자바스크립트 약간 알고...


이 바닥에 뛰어든지 벌써 4년째가 되어가지만 아는 것보다 모르는 것이 더 많다.

그런데 회사에서 내부 인력변경에 따라 해야하는 일이 바뀌었다.

기존에 해오던 것들과는 조금 다르다.

조금 더 앞에 서서 조율하는 역할이 추가되었다.

그런데 그것만으로도 많은 것이 바뀌었다.


적당히 할 수 없게 되어가고 있다.

누군가의 돈을 받으며 일을하는 자로서 '적당히' 하면서 지내려고 했던 태도자체가 잘못되었던 것이지만...


이제부터라도 열심히 할 수 밖에.

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

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

허니몬