[Java]POJO 클래스

Plain Old Java Object

EJB에 반대급부로 등장한 개념. EJB는 엔터프라이즈 어플리케이션에서 필요로 하는 트랜젝션 관리, 보안 등을 처리해주었고 개발자는 비지니스 로직만 걱정할 수 있도록 도와주었다. 그러나 너무 복잡했다고 함(사용해본적이 없어서..)

그래서 등장 한것이 POJO클래스 . POJO 프레임워크.

POJO는 특정 프레임워크에 종속 되지 않는다.(POJO 클래스의 경우 프레임워크에서 제공된 interface/class의 상속이 없음) 이외에도 객체 지향적이다 등의 특징이 있지만 핵심은 프레임워크에 종속 되지 않는다는것.

POJO 의 장점은 간결한 코드와 쉬운 테스팅.

POJO 철학을 반영한 프레임워크의 예

Hiberate – JPA(Java persistence API)구현, 오브젝트-관계형 DB매핑

Spring – EJB의 세션빈이 하던(트렉젝션 , 보안)일을 POJO기반으로 구현.

 

#JPA #Hiberate #Spring 

 

*EJB(Enterprise JavaBeans ) : 세션빈(Session Bean)과 엔티티빈(Entity Bean)으로 구성

[Java]자바 용어

자바 용어에 대해 명확히 하고 넘어 가기 위해 정리한다.

#POJO 클래스 – 프레임워크에 의존(상속)하지 클래스. 프레임워크가 빠진 순수 자바 클래스.

#AOP – 객체지향 프로그래밍의 단점을 보완하기 위한 관심사(aspect) 중심의 프로그래밍

#JPA – 관계형 데이터베이스에 접근하기 위한 표준 ORM(Object-relational mapping)

#Java 8 – Java version 8

JTA – 데이터베이스를 이용할 경우 트랜잭션을 제어하기 위한 기술 ( J2EE 스팩 )

JMS – 메시징 시스템은 응용프로그램 간에 비동기적으로 메시지를 교환할 수 있는 기술 (J2EE 스팩)

[aws]aws 201세미나(2)

이글은 aws 201세미나(1)에서 이어지는 글입니다.

EC2의 몇가지 기본 요소에 대해 알아보자

  • AMI(아마존 머신 이미지)
    우리가 쉽게 사용하는 이미지. 하지만 aws에서 사용되는 이미지. AMI는 3가지 종류가 있는데,
    – AWS 관리 AMI : AWS에서 제공되는 기본 AMI
    – 커뮤니티 관리 AMI : 커뮤니티나 벤더들이 세팅해놓은 AMI이다. 제작자별로 특성에 맞게 세팅된 AMI를 찾을 수 있다.
    – 사용자 관리 AMI : EC2가 처음 시작 되면, 표준화된 AMI를 S3에서 불러 필요한 OS를 설치하는 등의 작업을 실시한다. 후에 사용자가 웹서버 등의 custom 작업을 한 AMI를 생성 할 수 있다.
  • 스토리지
    – 인스턴스 스토어 : 임시 블록 스토어 , 스냅샷 불가 , 분산파일에 유리, 비용 차지 없음
    – 아마존 EBS : 네트워크 기반 스토리지, 백업가능 , 비용발생
  • 키페어
    EC2는 ssh기반 공개키/개인키를 사용한다. aws자체는 개인키를 저장하지 않기 때문에 처음 제공된 개인키 분실시 복구 방법이 없다.(인스턴스 자체는 뭐 여차 가능한걸로 알고 있지만 개인키 자체는 불가능). 공개키는 EC2가 저장하고 있음
  • 부트스트래핑
    강사님이 이거 안쓰면 클라우드 native하지 않다고 강조를 강조를..
    인스턴스 생성시 소프트웨어를 자동으로 구성할 수 있도록 도와주는 요소이다.
    – 인스턴스 사용자 데이터 : 환경변수 , 스크립트를 설정해서 인스턴스 생성시 해당 설정을 진행한다. 리눅스의 경우 cloud-init을 사용
    – 메타데이터 : aws가 AMI에 기본적으로 설정해 놓은 인스턴스의 환경 데이터. ex) 호스트명, AMI ID 등등…
    부스트래핑(동적으로 변하는 부분)과 AMI(잘 변하지 않는 부분)을 조합해서 인스턴스 환경을 구축하는것을 추천.

점심 잘 먹음.. 강의는 대략 1시간 반 정도 진행 되었고, 편안한 분위기에서 들을 수 있었음.

[aws]aws 201세미나(1)

aws 201 세미나를 다녀와서 배웠던 내용들을 정리.

해당 세미나에서는 주로 aws의 EC2에 대한 내용을 들을 수 있었다.

먼저 aws의 서비스를 이용하기 위해서는, region 을 선택하고 VPC(aws 내에서 나만의 데이터 센터를 만드는 개념)을 생성하면 이후 서브넷 생성, 라우터 추가 , 보안그룹 생성 등의 작업을 진행 할 수 있다.


이제 EC2에 대해 자세히 알아보자

EC2는 AWS의 가상머신 서비스의 이름이다. EC2는 CPU, 메모리, 스토리지 및 네트워킹 용량을 조합된 인스턴스를 선택해서 서비스 할 수 있는데, 그중 몇가지만 정리해보자

  • 범용(M)
    리소스를 가장 균형있게 사용하는 인스턴스
  • 마이크로(T)
    기본수준의 CPU , 가속기능 제공(버스팅) -> 개발환경, 트레픽이 적은 웹의 서버로 추천
  • 컴퓨팅 최적화(C)
    컴퓨팅 성능 최고 -> 고성능 프론트 엔드, 웹서버, 게임
  • 스토리지 최적화(D)
    SSD를 사용한 인스턴스와 고성능 HDD가 존재 -> No-Sql , DB , 하둡

이렇듯 서비스의 성격에 맞게 인스턴스를 선택하면 최저 비용으로 최대 성능을 기대할수 있다고 한다.

EC2의 특징 중 또 다른 점은 인스턴스에 할당된 자원(CPU, 메모리 등5)은 해당 인스턴스 전용으로 사용된다. 타임쉐어링 등을 구현할필요가 없다고 하는데 (OS 지식이 약해서 무슨말인지 잘..공부할게 산더미)

예를들어 EC2의 t2.micro 인스턴스를 사용한다면 ,일반적으로 해당 인스턴스는 vCPU의 10%만 사용이 가능하다. 그러나, 크레딧(시간마다 적립)을 사용한다면 100%의 성능(부스팅)을 잠시나마 사용할 수 있게된다. 이렇듯, 인스턴스의 특징과 서비스에 필요한 자원을 잘 계산한다면( 이 경우는 특정 시간에만 유저가 잠깐 몰리는 서비스) 적은비용(micro)로 최대효과를 볼 수 있다.

이 글은 aws 201 세미나 정리 2에서 계속..

 

[웹 최적화]웹사이트 최적화를 위한 몇가지 방법

웹사이트 최적화 방법을 구글링한 결과를 정리해본다.

  1. 도메인을 적절히 분리
    DNS 정보는 브라우져에 캐쉬 되기 때문에 같은 도메일을 가진 외부 파일을 사용하면 DNS lookup 시간을 단축 할 수 있다. 그러나, HTTP/1.1 스팩에 의하면 하나의 도메인당 최대 2개까지만 외부 파일을 병렬로 다운 받을 수 있다. 병렬 다운로드를 극대화해서 외부파일 다운로드 시간을 줄이기 위해서는 여러 도메인에서 파일을 다운 받는것이 좋은데 이글 의 저자는 2개~4개 사이의 도메인을 사용해서 DNS 캐쉬와 병렬 다운로드를 통한 성능 개선 간의 균형을 맞추라고 조언한다.
  2. ETags(Entity tags)의 사용(참고)
    ETags는 Entity(이미지,javascript,css 등)이 브라우져에 캐쉬된 파일과 같은지 판단하는 방법이다. Last-Modified 보다 더 융통성(flexible) 하다. 그런데, 로드벨런싱을 위해 여러대의 서버를 운영할 경우 같은 파일이지만 다른 ETag를 가지게 되어 캐쉬기능이 정상적으로 작동하는데 방해가 될 수 있다.
  3. Flush를 이용한 Buffer
    서버 작업이 오래 걸릴 경우 클라이언트 는 마냥 기다려야한다. 그때 먼저 준비된 HTML 부터 보내 줄 수 있는 기능이 Flush 이다. 이를 통해 클라이언트는 먼저 HTML을 불러(Fetch) 올수 있게 된다. Flush 위치는 Head태그가 끝나는 지점을 추천한다.
  4. Ajax의 method(Get/Post)를 올바르게 사용하자
    Post request의 경우 브라우져 내부적으로 request 해더를 먼저 보내고 body(data)를 보내게 된다. 이에 반해 Get은 하나의 TCP패킷 위로 해더와 데이터를 모두 전송 할 수 있다. 따라서 HTTP 스팩에 따라 Get을 사용해야 하는경우(데이터를 조회해오는 경우)에는 Get을 사용하자.
  5. Post-load Components를 구분하라
    Javascript 의 이벤트(가령 show/hide), hidden 속성의 Entity들 , 현재 보이지 않는 이미지 등은 최초 로드시에 불러올 필요가 없다.(최초 렌더링이 끝난 후에 작동 하는 컴포넌트들) Post-load 컴포넌트를 구별하여 lazy로드를 구현하는것도 좋은 방법이다. 야후에서 추천하는 tool들 

  6. Dom 갯수를 줄여라
    Dom 갯수가 많을 경우 Javascript 에서 Dom을 조작하는 경우 access 시간이 오래 걸린다.
  7. 쿠키의 size를 줄여라
    최초 response에 cookie가 존재한다면 브라우져는 사용자의 PC에 저장 후 이후 설정된 도메인(*.mukgee.com)의 request에 대해 해당 cookie를 다시 서버로 보낸다. cookie의 size가 클 경우 도메인을 방문할때마다 의도하든 의도하지 않든 큰 사이즈의 데이터를계속 보내고 받아야한다. 잘 사용하자.
  8. 자바스크립트/CSS minify
    이부분도 약간 논쟁이 있는것 같은데 minify를 통해 물론 파일 사이즈가 줄어들면 http request 타임이 줄어 들겠지만, 정말 그 효과가 크냐 라는 논쟁이 있는것도 사실이다. 그럼에도 JSmin 같은 프로그램을 이용하면 용량이 줄어든 파일들을 만날 수 있다.
  9. Javascript 는 가장 아래에 작성(참고)
    브라우져가 서버로부터 response를 받아 문서를 파싱하는 중 Javascript 태그를 만나면 HTML 파싱을 멈추고 외부 Javascript 파일을 로딩하게 되는데 그 동안 HTML 파싱이 딜레이 되면서 사용자입장에서는 느려보일 수 있기 때문이다.
  10. CSS는 가장 상단에 위치(참고)
    CSS를 head태그 안에 선언 할 경우 HTML 렌더를 순차적(progressively)으로 할 수 있다.  이런 점은 사용자에게 visual feedback를 줄 수 있다. 가장 중요한 사실은 HTML 스펙에 CSS는 Head 태그 안에 선언하라고 명시 되어 있다.
  11. Javascript 와 CSS는 외부 파일로 분리
    이부분은 논쟁이 될 수 있는게 사실, 웹 최적화의 1번 rule이 Http request를 줄이는 것이다. 때문에 css 파일의 작을 경우는 내부에 작성 하는게 Http 요청을 줄여 줄 수 있다. 그러나, trade-off를 봣을 때, request가 하나 늘어나는것보다 브라우져 캐쉬를 통한 성능 향상 크므로(그리고 사실 css파일이 작다의 기준도 알수 없음) 외부로 분리하자
  12. Javascript를 통한 Dom접근/제어는 최소한으로
    Dom이 복잡할 경우 javascript 를 통한 접근은 당연히 느릴것이고, 특히 레이어를 고치는 경우는 피해야한다고 한다. Jquery의 hide/show는 어쩌지 

  13. Event 설정도 최소한으로

    이 경우 button에 event를 추가하는 것이 아니라 button을 wrap 하고 있는 div에 event를 추가하라는 것이다. event는 bubbling 이 발생하기 때문에 div의 이벤트 트리거로도 어느 버튼이 클릭되었는지 확인 할 수 있다.

  14. 브라우져의 동작원리를 이해하고 적절히 사용해라
    Dom과 레이어 그리고 하드웨어 가속 등을 이해하고 적절히 사용해라. (이부분은 따로)
    http://d2.naver.com/helloworld/2061385
    https://www.html5rocks.com/ko/tutorials/speed/layers/
  15. 최대한 캐쉬를 이용해라
    Ajax든, 이미지든, Javascript, CSS 모두 캐쉬를 사용할 수 있다면 적극적으로 적용해라. 또한 정적인 컨텐츠에 대해서는 Expires header를 이용해 먼 미래로 expires 값을 설정해놓고 , 동적인 페이지에 대해서는 Cache-Control 해더로 캐쉬를 컨트롤해라. Ajax에 대해서도 Expires나 Cache-Control을 설정해서 캐쉬를 사용할 수 있도록 하자
    http://www.letmecompile.com/http-cache-%ED%8A%9C%ED%86%A0%EB%A6%AC%EC%96%BC/
  16. 기타
    Http 리퀘스트가 Gzip을 활용해서 데이터를 전송할 수 있도록 헤더를 추가해라. Http 리퀘스트를 줄여라

 

Ajax어플리케이션의 성능 향상에 대해 글을 남기신 Julien Lecomte에 따르면 Less is more 이다. 고민해보고 줄일 수 있는건 최대한 줄여라. 추가적으로 캐싱할 수 있는건 최대한 캐싱.

참고 : https://developer.yahoo.com/performance/rules.html , https://firejune.com/1302/

[ReactJS] setState에 대하여

튜토리얼을 보면,

이 부분이 잘 이해가 안가더라. Game 객체 내의 moves라는 React element에 onclick 이벤트로 등록된 것이 jumpTo 함수인데, jumpTo 함수가 실행되고 나면, 화면이 다시 그려지는데 그 re-rendering 시점을 못찾았었다. onRender 같은 이벤트가 존재하는것도 아니고 어떤 기준에서 다시 그려지는 건지 하고 검색 해봤더니

ReactJS는 상태가 변경(setState 함수 호출)시에 render 메소드를 다시 호출해서 re-rendering 을 진행한다.

결국 setState 는 사용자 이벤트에 따라 UI가 변경(show/hide 같은)되거나 Ajax 호출을 통해 데이터를 불러와서 다시 display 해줘야하는 등의 조건에서 사용해주면 좋을것 같다.

 

[ES6]변수 선언

ES6(부르는 용어가.. ECMAScript 6라고 부르기도하고, ECMAScript 2015 , ES6 , 뭐 여튼) 에 대해 천천히 공부해보자

일단 내가 알던 Javascript 와 다른 첫번째는 변수 선언에 관한 키워드 이다

기존의 Javascript 는 var로 모든 것이 해결 되었다. var의 경우 중복선언 / 함수 scope 등의 특징을 가진다.

반면, let과 const 는 중복 선언이 불가능하고 Block-scope를 가진다(bracket 범위). 이런 특징 때문에 다른 언어들과 비교해서 Javascript 가 가졋던 문제점(문제점인지 장점인지 알수 없으나.. Hoisting에 따른 중구 난방 변수 선언이나 중복 선언 등)을 해결 할 수 있게 된거 같다.

특히 변수의 범위가  블럭 scope이기 때문에 기존의 Javascript 에 익숙한 개발자들은 조심해야할거 같다.

Const 같은 경우에 좀 특별한데.. 일단 keyword가 생긴걸로만 봐서는 상수(immutable)이다. 실제로 ES6스팩 document(http://es6-features.org/#Constants)에도 immutable라고 표현되어 있는데, 이게 원시형 데이터를 할당하면 변경 불가능인데 참조형 데이터는 또 변경이 가능하다.(이러면 안되는거 아닌가) 또 이게 크롬의 경우 Strict Mode 일 경우 값을 변경하면 에러 난다고 한다. (일괄성에 대한 문제를 해결하려고 하는거 아니였나?)

var와 또 다른 let의 차이점은 loop index에서 찾을 수 있다.

var는 index의 경우 할당된 변수 하나에 값을 변경 시켜 나가지만 let 을 loop index로 사용할 경우 각기다른 변수가 생긴다. (loop가 메우 큰경우 메모리 문제가 발생할 수 있는 부분 아닌가?)

결국 var보다는 let과 const의 특징을 이해하고 바르게 사용하는 것이 중요할텐데 실제 코드에서는 let보다는 const가 많이 사용된다고 한다.

참고 : http://blog.javarouka.me/2016/03/es2015-var-const-let.html ,

http://blog.nekoromancer.kr/2016/01/26/es6-var-let-%EA%B7%B8%EB%A6%AC%EA%B3%A0-const/

 

[근황_20170123]와닿는 말

“The reason why people give up so fast is because they tend to look at how far they still have to go, instead of how far they have gotten.”

 

[ReactJS] ReactJS 튜토리얼 따라하기

이 글은 https://facebook.github.io/react/tutorial/tutorial.html 의 튜토리얼을 따라해본 것이다.

환경 설정을 마쳤다면(환경 설정이 안되어 있다면 이글을 확인), https://codepen.io/ericnakagawa/pen/vXpjwZ?editors=0010 에서 starter code를 받아보자.

  1. components 밑에 app.jsx 파일을 만들어 Square , Board , Game class를 생성하여 export 한뒤 entry.jsx 에서 해당 모듈들을 구현한다.
  2. src/css 폴더 밑에 style.css를 만들어 starter code에 있는 css를 그냥 복붙하자.
  3. index.html 에 html  코드들도 복붙해서 튜토리얼을 따라할 기본적인 코드를 구성한다.
  4. webpack 으로 빌드해서 브라우져에서 확인해보자

환경 설정과 starter code가 브라우져에서 실행 되었다면 튜토리얼을 따라가는데 큰 문제가 없을 것이다.

튜토리얼에 나오는 몇가지 중요한 점만 확인해보자

  • Immutability
    그 중간에 객체의 값을 변경하는데 slice() 를 사용하여 복제한다음 값을 변경하고 다시 state에 할당하는 작업이 있다. 이 부분에 대해 튜토리얼에서 꽤나 중요하게 언급(bold 처리된 텍스트)하는데,왜 복사해서 값을 변경하고 다시 할당 하는 작업(Immutability 라고 부른다)가 중요하냐면, ReactJS는 변경된 데이터에 대해 re-rendering 작업을 하는데 값을 변경하는 작업을 immutability하게 진행 되었다면 변경여부를 판단하는게 간단하고 쉽지만(주소값만 체크) mutated 객체의 경우 변경 여부 확인을 위해 내부 모든 값을 확인해야하고 값 변경 작업이 복잡했을 경우 re-rendering 을 위한 값 변경 여부 체크 프로세스가 기하급수적으로 복잡해지기 때문이다. 따라서 ReactJS에서는 특히 Immutability가 중요하다.
  • Functional Components
    이 함수는 stateless functional components 라고 불리는데  render() 함수만 가지는 컴포넌트이다 Functional Components 의 경우작성하기가 쉽고 향후에 ReactJS가 해당 컴포넌트에 대해 최적화를 진행하기 때문에 목적에 따라 해당 컴포넌트를 정의하는것이 중요할 것 같다.
  • Key
    ReactJS에서 리스트 컴포넌트를 렌더링 할 때 중요한 포인트가 Key 이다. 리스트 아이템이 업데이트(추가,삭제,수정)가 될 때 React는 그 중 어떤 객체가 변경 되어서 re-rendering 해야하는지 파악해야한다. 그때 사용되는것이 Key 이다. 리스트 객체에 Key를 할당하는것은 strongly recommended 하다. (Global unique 일 필요는 없고 그 리스트 내에서만 unique 해도 문제 없다.)

AngularJS의 문제점으로 느린 속도가 많이 지적되었던 것으로 아는데 이런 몇가지 요소들을 지켜 준다면 속도 이슈 없이 View를 구성 할 수 있을것으로 생각된다.

튜토리얼 자체는 어렵지 않지만 ReactJS를 처음 시작하기 위해서는 ReactJS와 함께 작동하는 에코시스템들(파이프라인)에 대해 이해하고 사용할 줄 알아야 한다는 점이 꽤나 피곤한것 같다.(러닝커브가 ReactJS에서만 발생하는 것이 아니라 webpack이나 Babel , 사실상 webpack에서 발생).

튜토리얼 자체는 step by step 으로 꽤나 친절하게 그리고 추가 문제까지 제공해주는데 따라가기 쉽다. Square에서만 이벤트가 시작되는 초기 단계에서 Square에서 발생된 이벤트가 Game 객체의 state를 변경시키는 것까지로 마무리 된다. 소스코드를 다시 보고 추가 문제를 풀어봐야겠다.

ReactJS에서 또다른 특징이 Server-side Rendering 으로 알고 있는데, 튜토리얼 후에 그 부분과 Ajax처리.. Fetch 인지 Request인지 그 부분도 공부해야할 필요가 있을것 같다.

튜토리얼을 따라가며 만들었던 소스는 github에 올려두자

https://github.com/sok891111/reactJStutorial

[ReactJS] ReactJS 튜토리얼 따라하기 – 개발 환경 구성

이번 글은 https://facebook.github.io/react/tutorial/tutorial.html 의 튜토리얼을 따라해본 것이다.

Javascript 로 Jquery를 주로 사용했던 개인 경험에 비춰보면 이건 신세계다.

마치 backend에서 빌드 파이프라인을 구축하듯이 front-end 또한 파이프라인을 구축한다. (튜토리얼에 따르면 파이프라인 없이도 ReactJS를 사용 가능하다.)

“A modern build pipeline” 은 3가지로 구성되어 있다.

  1. package manager : npm , yam 같은 페키지 매니저 들인데, 이들은 에코시스템의 third-party 패키지들을 쉽게 설치/업데이트 가능하도록 도와준다.
  2. bundler : webpack, browserify 등이 있는데 Javascript의 모듈화를 도와주는 도구들이다. 모듈들을 작성하여 webpack으로 컴파일 하면 bundle.js 를 생성할 수 있는데 이를 통해 브라우져에서 실행 할수 있게 되는 구조이다. 자세한 내용은 http://d2.naver.com/helloworld/0239818
  3. compiler:  Babel 등이 있는데 ES6 같은 모던 javascript 문법들로 작성된 javascript 파일을 브라우져가 인식 할 수 있는 파일로 만들어 주는 도구들이다.

http://www.looah.com/article/view/2054 (사랑해요 javascript)

위의 3가지를 갖춘 후 ReactJS를 설치하고 사용해보자

npm 설치 후 webpack은 여기서 , Babel은 여기서. npm만 설치 된다면 다른 도구들 설치는 어렵지 않음(npm은 세계에서 가장 많은 모듈을 가진 저장소)

webpack을 베이스로 babel 모듈을 설치해서 개발 환경을 구성하였다.

webpack 에서 babel을 이용해서 빌드 할 경우 아래 두가지는 npm으로 설치

npm install –save-dev babel-preset-es2015
npm install –save-dev babel-preset-react

프로젝트 파일 구조는 일단 이렇게 가보자 ( 참고 : https://velopert.com/814 )

 

.

├── package.json        
├── dist            # 서버 운영 파일
│   └── index.html    # 메인 페이지
├── src               # React.js 프로젝트 루트
│   ├── components    # 컴포넌트 폴더
│   │   └── App.js    # App 컴포넌트
│   └── entry.js      # Webpack Entry point
└── webpack.config.js # Webpack 설정파일
이렇게 환경이 구성되면이제 드디어 ReactJS 튜토리얼을 따라해볼 수 있다.
개발 환경 구성이 길어지면서 튜토리얼 내용은 다음 글에서 정리하겠다.
p.s ReactJS는의 클래스는 첫글자가 대문자인 캐멀 네이밍 룰을 따른다는것을 기억하자
실제 튜토리얼은 여기서