ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 2013년 JCO 컨퍼런스
    도서요약/세미나_교육 2013.02.25 00:51

    1. Open Source Engineering

     - 각 업체들마다 오픈소스 전략이 다름

       Apple 은 본인이 못 가지면 다른 곳도 못 가지도록....

       Google은 Free Outsourcing 관점으로  ex) chrome

     - BSD 라이선스를 사용함으로써 향후 특허권 소송을 할 수 있는 여지를 남겨둠

       (Apache 라이선스는 특허까지 무료제공하는 방식이라 Apache라이선스로 소스 오픈하면

        특허를 포기하는 것임)

        원저작자 권리 (GPL/LGPL) , 사용자 권리 (MIT/BSD/Apache) 단, Apache는 특허Free

     - Code for America 를 통해서 미국에서 Open Source가 더욱 증가됨

     - 현재 국내에 GPL 위반 사례를 적발하기 위한 업체가 있음.. GPL은 기업에서 사용하지 말것

        skype가 GPL위반으로 보상한 사례도 있음

     - Architecture Visualization : stan4j.com 추천

       아키텍처를 분석하는데 유용함, 해당 오픈소스의 구조가 안정적인지...

        circular dependency 여부 파악 및 각 Layer별 추상화정도도 표시

        instablity = ce / ( ca + ce )  ;  ce ( 다른 곳을 참조하는 갯수), ca (다른 곳에서 참조되는 갯수)

        (다른 클래스(패키지)에서 사용하는 클래스(패키지)는 변경하기 어렵다....)

     - Asset을로써 Open Source

        Android는 23% open source  (버그만 잡을 수 있는 정도로 열림, 폐쇄적임)

        Android용 Log를 출력하기 위해서 LogDog 이라는 오픈소스를 만들었음

        XML 로딩을 위해서 Simple Framework 사용  (http://java.ihoney.pe.kr/197)

        모바일쪽 실제 오류의 50%는 광고부분 때문임...

        HighCharts사용 (구글차트는 2015년 이후 지원안 할 수 있다는 문구 때문)


    - facebook의 social graph 의 강력함

      이화여대는 facebook에 학교그룹을 가입해서 사용 중  

      구글나우는 사용자의 상황을 인식하여 서비스를 제공함 (출퇴근 이력을 가지고 도착지 날씨도 제공)


    - Framework 를 구축할 경우: 페이스북용 API를 제공하는 프레임워크 개발

      팀원이 적으면 일치성이 높아짐

      팀원이 많으면 복잡도가 올라가므로..요구사항의 조절이 중요함

      Framework의 핵심기능 찾기 (80%로 사용되는 20%의 기능을 찾기)

      Dummy Class를 만들어서 사용자들에게 code sample을 제공 (관련의견의 피드백 받기)

      framework 사용자 시나리오를 산출... 

      다른 곳에서 해당 framework를 효과적으로 사용하는지 테스트   

      

    - 라이선스 선택: 플랫폼 싸움으라 사용자권한이 높은 형식의 라이선스 방식을 취해야 함 (MIT/BSD/Apache)

      직관적 Naming, 개발가이드 제공, 소스관리 (Git)



    2. 파이라떼: Python코드를 JSP처럼, 거기에 몇가지 기본 프레임워크 구성 (DB관련처리)


    3. Hadoop 테스트

      Driver --> Mapper --> Reducer  의 각 부분별 Test 중요함

      Hadoop 프로젝트의 클래스는 열 몇개로 구성됨, Data를 잘 알아야 

      Hadoop 프로그램을 잘 할 수 있다. 

      Floating 연산을 주의

      단위테스트가 중요함 (white box 테스트) 

      MRUnit 는 문서도 없고 어렵다... 

      Pseduo Mode 방식은 한 컴퓨터에서 분산형식 테스트 (메모리 많이사용, 성능이 떨어져 테스트 어려움)

     Mini Cluster방식도 0.2 이전의 버전만 가능함... Hadoop의 버전계보 참조


    4. 서버사이드 개발 (조대협)

     스타트업 (쉬운것, 아는 것부터 시작, 소규모로 시작할 것)

     Devops 트렌드 : http://swprocess.egloos.com/2823875


     개발프로세스: 하향 평준화임, 실용주의 방법론 중요

     스크럼의 경우 관리자가 좋아하지 않음: 가시성이 나타나지 않음  

     Big Umbrella (RUP와 유사)

     어려운부분 부터 먼저 초기개발을 진행할 것 

     

     소규모 프로젝트 관리는 엑셀로 충분함 (툴에 얽매이지 말것)

     각 상황별로 방법론의 tailoring이 필수

     

     개발환경: 일일빌드 필수 (오류 시 email이 가도록 할것)

     단위테스트 라인 커버리지 80%, 좋으나 쉽지 않음 => 주요모듈 30%에 대해서라도 80% 준수


     rest api 테스트 방식을 추천함

     Dev -> QA -> Stage 서버 : 3단계로 나눠진 구조 추천

     Jenkins -> 배포시스템 (Python Fabric, Ruby Capistrano) 사용 추천


     서버아키테처: refrenece architecture 확보를 해서 참조

      (트랜잭션 처리, 연동, 리포트, 운영 )

     

     스크립트 언어는 한가지 할 것....


     스타트업 초기 법률체크 (NIPA 등의 도움)

     

     마이크로 벤치마크 테스트 (SOAP UI, NGINX 등) 50유저 정도의 테스트만 해도 대부분 오류나옴

     http://www.soapui.org/


     http://blog.naver.com/PostView.nhn?blogId=genycho&logNo=60124101558&categoryNo=75&viewDate=&currentPage=1&listtype=0


    5. 스타트업 프로젝트는 왜 대체로 산으로 가는가

     - 여성창업관련 수상이후 제휴 (카페베네)

     - 생각보다 기본은 부실했음, 생각(2만명) 보다 회원수 증가(10만명).. 문제 발생

        Renewal 작업 수행

     - 책: The startup owner's manual

         웹밴 사업 예시: 프로젝트는 성공했으나 사업은 실패 함 (당일 식료품배송 서비스)

                               확장을 너무 크게 해서 수요가 없는 상황에서 비용증대로 파산

    - 고객탐색이 더 중요... 실제로 사용할 부분

    - 회사의 비젼과 프로젝트는 같지 않음

      (너무 비전에 맞추기만하고 실제 사용할 수 있는 현실의 서비스를 하지 않으면 

       안됨)


    6. Google의 AngularJS 

      http://angularjs.org/





     



    댓글 0

Designed by Tistory.