'2012/05'에 해당되는 글 4건

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

20120519 KSUB 세미나 Part 1.

0. KSUG 큰일꾼 고종봉님의 KSUG 소개



1. 스프링 처음 시작하기

  • 발표자 : 고종봉
    • 스프링은 너무 방대하고 어렵다. 쉽게 이해하고 배울 수 있는 방법은 없나요?
  • 스프링이란 무엇인가?
    • 참고 URL : http://static.springsource.org/spring/docs/3.0.x/reference/html/

    • 엔터프라이즈급 애플리케이션을 만들기 위한 경량화된 솔루션
      • 엔터프라이즈에서 필요한 영역을 전체적으로 다루고 있다.
      • 성능상으로 무거운 것을 가볍게 바꿨…!!
      • 자바 애플리케이션을 개발하기 위해 필요한 인프라스트럭쳐를 종합적으로 제공해, 개발자로 하여금 애플리케이션 개발에 집중할 수 있게 도와준다.
      • 스프링은 POJO를 기반으로 애플리케이션을 개발할 수 있게 하여, 엔터프라이즈 서비스를 비간섭적(non-invasively)
    • 스프링의 3대 핵심기술
      • Plain Object
      • DI(Dependency Injection) : 두 객체의 결합을 줄이기 위해 인터페이스로 선언하고, 프레임워크에 의해 주입되는 형태
      • AOP :
      • Portable service Abstractions(추상화)
    • 스프링의 모듈구성

    • 변경 가능 영역
      • 폼 컨트롤러
      • Multipart 리졸버
      • 도메인 모델 동적 바인딩
      • JSP, Velocity, SLT, PDF, 엑셀 뷰 인티그레이션
    • Spring reference
    • OutSider님의 Spring Framework 번역 : http://blog.outsider.ne.kr/tag/spring_reference_documentation

2. 스프링 실무적용 사례


  • 발표자 : 최영목(넥스트리 소프트)
  • 스프링을 실무에 적용하면서 늦어졌다.
    • 스프링 모듈
      • 아키텍츠 구현을 위한 정보들(하드웨어 스펙, 사양, 자원) 수집 후 이에 적합한 솔루션을 선택
      • 컨설턴트를 하다보면, 그림을 가져다 쓰면 퀄리티가 떨어진다?
      • 왜 스프링을 쓸까?
        • 프로젝트에서 쓸 수밖에 없는 이유 : 리모팅(원격지 처리) - EJB, Spring Remote Call
        • 다양한 요구사항을 포함하는 것들을 살펴보다보니 공통적으로 도출되는 솔루션이 나타나기 시작
      • Component Biuild
        • 고객 요구사항
        • 의존성 관리, 비침투적임(기본적인)
        • 컨텍스트 생성
        • 모든 사람들이 스프링을 잘 쓰지는 않는다.
        • @annotation 다세요.
        • xml은 우리가 입력할게요. applicationContext.xml -> component-scan 설정
        • 테스트와 관련된 내용은 우리가 해줄게요.
      • DataAccess : JPA <-> iBatis, MyBatis
        • 도메인의 규모가 다르군…
        • Transaction 관리 -> 스프링!!
      • MVC
      • Spring Test
        • Spring에서 제공하는 Junit Runner를 사용가능하다. DBUnit 테스트 연결, JPA 테스트
        • 통합테스트를 위한
    • 모듈별 실무적용 사례
      • 프로젝트 내에 개발표준
      • 내가 잘하는 분야는… 뭐냐? ㅡ_-)? 삽질?
      • 아키텍트를 설계할 때 개발자는 프레임워크에 대해서 알 필요가 없을 정도로 만든다.
    • 프로젝트 투입 후 애타게 찾는 것.
    • 프로젝트를 투입하기 위해 고려해야하는 것은 무엇일까? 고객의 요구사항, 이를 수용할 수 있는

3. Spring Web-MVC 파헤쳐보자

  • 양완수
  • DispatcherServlet : Proto object?
    • Spring MVC를 사용하는 이유는?
      • 사용하지 않을 이유가 없다? 사용하지 않을 이유도 있을 수 있다.
      • 컨트롤러가 안나와요, view가 안나와요, class not found 가 떠요.
      • 오류와의 싸움! Debugging!!
    • 파헤쳐 보려면 : handler, View Resolver
        • 개발자스런 생각. 상속, 주입… 딸아이가 자신의 습관(엄지와 검지발가락 사이를 비비는… 습관을 따라한다.)
    • Dispatcher가 생성되는 부분
      • BeanMapper : 일반적으로 건드리지 않는 클래스다.
      • Init :
        • HttpServletBean
        • Bean의 Property처럼 init-param을 사용하여 필요한 속성들을 DI받을 수 있게 해준다.
        • PropertyEditor, BeanWrapper
        • WebApplicationContext : eGovment Framework 설명
        • onRefresh() template method : 참고 URL : https://jira.springsource.org/browse/SPR–3297
        • Multipart Resolver
        • ThemeResolver : FixedThemeResolver(default)
        • LocaleResolver
        • HandlerMapping
        • HandlerAdapter
        • doDispatch
        • doService 에서 시작

4. 스프링 3.1 요약정리!

  • 박용권
  • Spring One Session 정리
  • 스프링 3.1, 3.2 는 3.0을 강화하고 개념을 녹여내는 쪽으로 하게 될 것이다.
  • github : https://github.com/arawn/ksug–2012-spring–31-summary
  • 스프링 3.1
    • 빈 정의를 위한 환경 프로파일 Environment profile for bean definiation
    • Java-based application configuration : 자바기반 애플리케이션 설정
      • @Configuration
      • @ComponentScan
      • @Bean
      • @Enable
        • @EnableTransactionManagement
        • @EnableWebMvc
    • Cache abstraction & declarative caching
    • 3.2에서는 Java 7에 대한 지원을 강화시킨다.
    • Spring @MVC 3.1 : key
    • Java config
      • XML에서 자유로워졌다.
        • Java-Based : WebApplicationContext
    • Data Binding & Path Variable
  • 참고자료
  • Source
    • Configuration
    • ImportResource({})
    • PropertyResource({})
    • ApplicationContext.class 를 구현하여 과거의 applicationContext.xml을 대체할 수 있게 되었다….!!
    • RequestMapping에 대한 상세한 대응이 가능하다. -> 샘플… MobileMapping
  • Router -> Spring Router
    • HandlerMapping -> Abstract class. : 과거에 비해서 편리하게 사용가능하다.
    • DispatchServlet 은 크게 변하지 않았다.

5. 개발자 토론(Free talking)

  • Software
  • Enginee 이라는 단어가 붙은 소프트웨어의 역할? 정의 ?
    • Framework는 뭔가?
    • 변경되는 것과 변경되지 않는 것
    • 일반적인 것과 일반적이지 않은 것
    • 어떻게 시스템화 할 것인가? SOA - 단일서비스화
    • 정의 하기가 애매하다… ->
  • 야근하는 개발자
    • 난 일찍 퇴근한다.
      • 자신이 할 수 있는 분량을 정확하게 상사에게 전달한다.
      • 갑이 불안하기 때문에 그렇다. -> 안도감을 심어준다면 된다.
    • 난 칼퇴근하지 않는다.
      • zeide 님 : 칼퇴가 뭐에요? 이게 뭐야?
      • 허니몬 님 : zXXXX 님이 칼퇴하는 모습을 보지 못했…던가?
  • m2e와 WTP 궁합 : 필요한 플러그인 설치하면 되요~
  • 기술 선택의 근거와 설득은 어떻게 하나요?
    • 요구사항을 만족하는가? -> 고객이 원하는 요구사항을 모두 충족시킬 수 있는가?
      • 대형 프로젝트 레퍼런스
    • 절차가 원칙적으로 진행할 수 있는가?
      • 선택을 고객에게 하도록 한다.
      • 고객 설득
      • 스터디 비용을 최소한으로 할 수 있도록 제공해야한다.
      • 나와 상대방의 차이.
      • 팀원들을 하나둘씩 꼬드겨서 함께해라.


  개발자들이 강남에 출현했다. +_+) 검정색 인케이스 백팩으로 무장한 개발자들의 무리가 몰려간다.

  발표하신 분들 수고하셨습니다. ^^


  개발자들은 주말에도 끊임없이 자기계발을 위한 노력을 하고 있다. IT 관련한 기술이 빠르게 변모하고, 이런 변화의 흐름을 즐기기 위해서는 그것을 배우기 위해 꾸준한 노력을 즐길 수 있어야 한다. 그런 의미에서 본다면, 나는 그런 변화의 흐름을 즐기는 노력을 제대로 못하고 있다. 자전거 타는 재미에 빠져서는 매일 출퇴근시에 자전거를 타려고만 하고 있으니... 이런 습관적인 자기비하!!

  '오픈소스OpenSource의 시대'라고 한다. 프로젝트 속에서 고객의 요구사항과 기술적인 기능 제공을 위해 솔루션의 선택하는 것이 중요하다. 그리고 스프링 프레임워크는 이런 고객의 요구사항에 대한 해결책을 제시해줄 가능성을 내포하고 있다. 그래서 컨설턴트와 개발자들의 많은 관심과 사랑을 받고 있다. 하지만 아직도 어렵고 어렵게만 느껴지는 녀석이다. ^^; 익숙해지려면 많이 써보고... 시간 날 때마다 어떻게 돌아가는 지 삽질하듯 깊게깊게 파고 들어가는 노력이 필요하다.

  이번 발표에서는 Prezi(http://prezi.com/)를 사용한 발표가 두 개 있었다. 동적으로 움직이는 화면이 잠깐의 호기심은 일으킬 수도 있겠지만.. 시간이 지나면 산만함을 야기하는 느낌이다. @_@);;; 발표용으로는 그리 효과적이지는 않은 것 같다는 개인적인 생각을 가지고 있다. 아직은 고전적인 프리젠테이션이 좋다.


허니몬의 IT 이야기/아키텍트, 'SW건축가'를 꿈꾸다
업무(도메인)를 제일 잘 아는 사람은 당연히 그 업무를 수행하는 실무자가 아닐 수 있다(응??).

도메인이 잘 만들어지려면 그 도메인을 사용하는 사람이 업무에 대해 잘 알고 있어야 한다. 그 다음으로 도메인 분석가가 얼마나 그 도메인의 핵심요소들을 절묘히 뽑아내느냐가 아닐까?

요구/분석부터 어긋나면 설계, 구현은 완전히 틀어진다.

사진 출처 : http://www.ddaily.co.kr/news/news_view.php?uid=48974


허니몬의 IT 이야기/아키텍트, 'SW건축가'를 꿈꾸다
서비스를 사용하다보면,
'이거(기능) 왜 넣은거야?'
라는 생각이 드는 것들이 종종 있다.

그런 경우 대부분,
빈 공간을 활용하기 위해,
모양이 변하면서 불필요해진 기능이지만 버리기 아까워서 어떻게든 가져가려고 했던 경우가 그렇다.

혹은 그 기획에 이것저것 넣어서 서비스를 개선하려고 하다가 원래 서비스가 제공하려던 취지(초심이랄까?)을 잃고 혼란에 빠진 경우랄까? 이 경우는 서비스 사용자가 갑자기 늘어나고 그 사용자들을 수용하기 위해 기획자와 개발자가 대거 투입되어 운영되면 나타나기 시작한다.

기획도 기능도 중요하다. 그런데 둘 다 '뭔가를 추가하면 좋겠다. A서비스에서 제공하는 저 기능과 화면, B서비스에서 제공하는 요 기능과 화면을 넣어보면 어떨까?'라는 궁리를 하면서 이것저것 넣고 싶어진다(악마의 유혹은 달콤하고 치명적이라 하지 않는가?).
그러다가 그것들을 추가하고 마는 실수를 벌이게 된다(이 때부터는 단순한 따라하기에 지나지 않는다. 평생 앞으로 나아갈 수 없다. 남의 뒤만 따르게 된다. 애플에서 하는 것들을 따라하기 바쁜 삼성처럼 되는거다. '뭐, 그게 어디야?'라며 감지덕지한다면 어쩔 수 없는 거지만...). 그리고는 그 서비스는 점점 개성을 잃고 무거워지고 복잡해진다.

더하는 것은 쉽다.
빼는 것은 어렵다.
허니몬에 관한 보고서/허니몬의 취미생활

&amp;quot;cfile1.uf@17319D334FA1C24127439A.jpg&amp;quot;



헬멧은 필수.
전조등, 후미등도 필수.

가방에는 갈아입을 옷을 넣고 다니는 출근길. 왕복 40킬로미터의 거리.

&amp;quot;cfile3.uf@111321404FA1C2B7293A76.jpg&amp;quot;


1
블로그 이미지

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

허니몬