FrontEnd개발 – Angular2 개발시작

node 기술혐오

node진영은 비슷한 기술이 너무 많아 선택장애가 생긴다.

angular, react, backbone, ember polymer

왓 시바 다섯개다.

https://gist.github.com/makmanalp/9b7f50aa16d21c2f9d37

당신이 ~~를 선택해야 하는 이유같은 글 많이 읽어봤는데 뭐 다 비슷했다.
결국, 구글과 TypeScript 때문에 Angular를 선택

(처음 나올때는 angularJS였는데 이제 TypeScript를 쓰고 앱을 만들때도 쓰기 때문일까…
영역을 확장하기 위해 Angular라고 이름이 바뀐 것 같다.)

Angular2 설치과정


npm -g install @angular/cli

이렇게 하면 설치가 된다고 하는데… 그리고 분명 되어야 하는데… 먼가 오류가 난다.
뭔가 이상했는데

node -v
0.xx

윈도우에서도 다시 설치하면서 찾아보니 2013년이었나..?
node 가 주력이 아닌 사람들은 다들 비슷한 상황일거다.

이거보고 삭제진행(Mac)
http://stackoverflow.com/questions/11177954/how-do-i-completely-uninstall-node-js-and-reinstall-from-beginning-mac-os-x

아래 명령 둘중에서 하나 실행시키면 되는데.. 오타나면 컴퓨터가 맛이갈수도 있겠다.

$ sudo rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/{npm,node,man1/node*}

$ sudo rm -rf /usr/local/bin/npm /usr/local/share/man/man1/node* /usr/local/lib/dtrace/node.d ~/.npm ~/.node-gyp /opt/local/bin/node opt/local/include/node /opt/local/lib/node_modules

한다음에 공식사이트에서 재설치했다.
https://nodejs.org

튜토리얼 진행

https://angular.io/docs/ts/latest/cli-quickstart.html


npm install -g @angular/cli

ng new my-app

angur2 기본프로젝트를 생성하고 나니….

의존성 관리를 npm으로 하고 karma라는게 깔린다.
빌드는 ng-cli가 하는 것 같고…

그리고 모르는게 추가돼있다.

karma, e2e ???

karma는 자바스크립트 테스트 러너 라고 한다
https://blog.outsider.ne.kr/1020

e2e도 유닛테스트 관련 프레임워크인 것 같다.

Anguar개발에 익숙해지고 최적환경을 구성하려면 시간이 좀 더 걸릴 듯 하다.

서버단이 아닌 프론트엔드 라이브러리가 npm에서 싸잡아 관리되는게 못마땅하니
Bower를 적용해야겠고
빌드도 일관성을 위해 gulp를 적용하는게 나을지 npm을 써야할지

Thymleaf 적용중 만난 오류들

템플릿 소스 가지고 쓰는데…

`

Thymleaf 되게 엄격하군.

쓸데없을 정도로..

안써야겠다 역시.

CQRS와 EventSourcing 기술을 보고

CQRS와 EventSourcing제대로 이해를 했나 모르겠는데

비슷한 생각을 하고 그런 설계를 잡으려고 했었는데,
당시에는 Hibernate ORM Envers라는게 있는줄 몰라서…
그 때의 설계는
ORM을 이용한 도메인 설계를 그대로 화면에 보여줄 수 있도록 하고 히스토리는 별도로 저장하는 구조였다.

)를 들어 회원정보 엔티티에서
level 변동, password 변경 등에 대한 히스토리 저장이 필요하다.

RDBMS에서는 다음 엔티티의 현재상태만 저장

UserEntity {
username : string
password : string
passwordChangeDate : date
email : ref EmailEntity
level : type { bronze, silver, gold, platinum, diamond, challenger }
lastLoginDate : date
}

로그는 별도 디비 또는 파일로 관리.
user-password-change-history (password, passwordChangeDate)
user-level-change-history
user-lastLoginDate-history

이런방식으로 현재상태와 변경상태를 저장한다.
변경히스토리를 저장하는 부분을 하나하나코딩하면 안되고,
하이버네이트 인터셉터라던가 해서 데이터변경을 확인하고 로그를 남기도록 하는 추가기능이 필요하다.

이렇게 하는 경우 RDBMS의 데이터가 메인이기 때문에 변경기록이 남지 않게 되는 상황이 생길수도 있다. 중요한 데이터는 트랜잭션을 걸면 느려
계좌 밸런스를 저장하는걸 예로들걸 그랬나

지금 CQRS컨셉으로 제시하는 것을 보면 현재상태는 메모리디비같은데 저장하는 것 같은데 소규모시스템에서 생각 해 보면
RDBMS에 현재상태를 몽땅저장하는게 괜찮아보인다.

이정도로 중규모까지는 사용가능 해 보인다.

RDBMS의 업데이트를 과도하게 사용하는 부분이 문제가 되긴 할텐데…

어쨌든.. envers쓰면 쉽게 된다.
http://hibernate.org/orm/envers/
….
잘도 만들어 놨다. 이걸 왜 못찾았을까 좀만 더 찾아볼걸

MSA의 시대, 다시 주목받을 RPC

RPC : Remote Process Call 진영은

몇년째 딱 대표적인 기술이 떠오르지 않고 고만고만하게 유지되고 있다.

개인적으로 RPC가 더 편하다고 생각하는데, RestAPI가 너무 대세가 되서 인기를 잃어버려 아쉽다.

아니 먼 RestAPI 데이터를 브라우저로 봐서 뭐한다고?!?~!

지금당장 기억나는것은 이정도….

Thrift
Avro
gRPC
ProtocolBuffer
BSon

완전 RPC라고 하기는 좀 그런 시리얼라이징 기술도 넓게 보면 RPC아닐까…
아니 그냥 RPC인가? 그냥 다 포함시켰다.

아직까지는 연동 API 제공 한다고 하면 당연하다는 듯이 RestAPI를 제공한다.

API는 다양한 문제점을 가지고 있고 기술적으로 열등하기 때문에 점점 사용률이 낮아질거라고 본다.

표준기술로 사랑받아왔던 RestAPI의 문제점들

  • 무거운 http api만드는데 http를 돌리는데 코스트낭비가
  • 너무 자유로운 설계 json을 ?params=%XX%XX 형태로 받는 경우도 있고
  • http1 프로토콜에서 낭비되는 네트워크 리소스 http2로 사용하면 좀 더 낫긴하겠지만..

웹기반 기술에서는 계속 사용되겠지만 MicroService가 등장하며 내부 네트워크 부하가 더 심해지는판에.. 이걸 계속써야할까?

아니

여태까지는 아키텍처/UX까지 Request후 Response를 기다리는 형태로 설계가 되었으니 RestAPI를 써도 불편한줄을 몰랐다

async환경으로 변화는… 패러다임의 변화다. 설계까지 변경된다.

변화의 조짐은 보인다.

요즘 유행하는 기술 트렌드를 보면

MSA, Async, Functional Programming

이정도… 그리고 이런 트렌드가 지속/확대 된다고 봐도 될 것 같다.

왜냐? 작은조직의 효율적 개발, 클라우드환경, 늘어나는 네트워크 트래픽 등등의 상화을 봤을때 방향성이 그쪽을 향하고 있으니까…

새로운 트렌드는

MicroService사이의 통신을 위한 가벼운 프로토콜 + MQ(MessageQueue) 클러스터를 이용한 내부 통신채널 일원화 + Functional Programming을 통한 Async방식 개발

이 될 것이고

MQ를 이용한 Async프로그래밍을 도와주는 프레임워크이 등장하면서 RPC 사용이 활발해질 것이다.

이직후에 프레임워크 만들면서 쓸만해보이면 공개나 해볼까…

MS의 Cloud Design Pattern 24선. (CQRS, EventSourcing … etc)

원문 링크 : https://docs.microsoft.com/en-us/azure/architecture/patterns/

MS에서 발표한 Cloud 에서 적용하면 좋은 디자인 패턴

(for Azure, 다른 Cloud도 가능)

그중에서 요즘 관심을 끄는것은 CQRS와 EventSourcing
정확히 이해는 못했는데

DDD구현의 문제를 해결
CRUD가 분산환경에서 갖는 문제점(고가용성 서버한계)
때문에 나왔다.

아주 간단히 하면 이정도인듯 하다.
StreamData처리하는것과 비슷한건가 좀 더 봐야할 것 같고.

구글에서 CQRS로 검색하면 한글로 번역된 문서도 좀 있다.

[번역] 최신 기술 – CQRS 처음 도입하기

시간이 되면 원문을…

Command Query Responsibility Segregation
https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs

https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

프레임워크도 나와있다

Axon : www.axonframework.org

Reveno : reveno.org

Eventuate : eventuate.io

Lagom : www.lagomframework.com

다들 쉽고 빠르고 분산가능하다고 써있는데 안써봤다.

기타 참고할만한 문서

Introduction to Domain Driven Design, CQRS and Event Sourcing

DevOps 관련 정리

개요?

완전히 새로운 개념은 아니다.
기존에 개발자들이 하려고 하던 많은 노력들을 모아서 하나의 이름을 붙인 것 뿐.
DevOps에 따라붙는 몇가지 개념들

애자일, 마이크로서비스, 배포자동화

이런것들을 하기 위해서 필요한 기술들은.. 흔히 생각하던 것들
귀찮아서 안하지만
에러메세지, 테스트 …

팀 규모

피자2판 규칙 – 아마존
한팀의 인원을 2명으로 제한한다.

Docker 개념, 그리고 처음 프로젝트 적용 소감

도커 이미지로 동일한 환경을 구성하면

이 환경을 개발/테스트/운영 모두 동일한 환경에서 의존성 문제없이 사용할 수 있다.

동일환경 배포라는 문제를 해결하기 위해 등장한 도구들

  • 가상화 도구 : VMware, KVM, VirtualBox, HyperV
  • 클라우드 플랫폼 : OpenStack, CloudStack
  • 서버설정 자동화 : Puppet, Chef
  • 배포도구 : Capistrano, Fabric
  • 작업부하 관리 : Mesos, Fleet
  • 개발환경 설정 : Vagrant

도커와 함께 쓰이기도 하고 따로 쓰이기도 한다.

도커를 일주일정도 쓰면서 프로젝트에 적용하고나니 이제서야 감을 좀 잡겠다.
도커관련 책이 많이 나와있는데… 이걸 다 외울게 아니라면 한번훑어보고 넘어가는게 좋겠다.
명령어는 인덱스만 잡아놓고 그때그때 찾아서 쓰다보면 외워지는게 제일 나은것같다.

도커 개념을 잡으려면 먼저 써보는게 좋다.

일단 명령어 하나도 몰라도 윈도우/맥에서 쉽게 설치해서 쓸 수 있게 나와있다.
Docker(https://www.docker.com/)
GUI도구 (https://kitematic.com/)

도커의 아키텍처

리눅스의 컨테이너가 발달한 형태로
iptables, virtual bridge, cgroups, namespace.. 등의 커널매커니즘이 얽혀서 돌아간다.
(자세한 것은 리눅스커널을 먼저 이해해야 알 수 있을 것 같다.)

도커는 클라이언트, 서버데몬, 레지스트리로 나뉜다.

서버데몬이 우리가 생각하는 도커 컨테이너를 구동하는 녀석이고
docker 명령어를 친다고 생각하는게 클라이언트
레지스트리는 도커허브의 역할이다.
(자세한 것은 책에 잘 나온다)

도커 도구

도커 도구가 많이 나왔던 것같은데…
초기에 나온것들은 많이 정리가 됐는지 책에 나와있는것들도 바뀐게 좀 있는 것 같다.
최신 방법론은 도커 최신 공식문서를 찾아봐야 하지 않을까

활용법

도커 컨테이너는 쓰고버리는 1회용품으로 생각하면 쉽다.
영구적으로 저장하는 데이터를 여기 저장하면 안되겠지
API서버를 돌린다면 사용자 정보와 디비는 별도로 돌아가도록…
테스트에 한해서 DB를 돌리기도 한다. 저장경로를 컨테이너 외부로 잡으면 디비를 직접 돌려도 상관없지 않을까 싶기도 하지만… 디비를 업그레이드 하면서 파일이 깨질가능성도 생각해보면.. 좋은 생각은 아니다.

사용법

http://tutorial.polypia.net/w/Docker

설치방법

다운받아서 깔아도 되고 apt yum 등.. 자동설치 지원이 잘 된다.

사용후기

적용을 하려면 이해가 좀 필요할 것 같다.
그리고 도커에 맞춰서 아키텍처의 변형도 좀 필요해 보인다.
지금까지 gradle bulid 를 war로 만드는게 목표였다면
docker내에서 사용하는 방법은 좀 다를 수 있다.
docker이미지 내에 maven/gradle빌드환경을 구축 해 놓을수도 있고
docker하에서는 spring boot에서 기본옵션으로 사용하는 embedded was컨셉이 기존 별도 was실행하는 방식보다 더 적합해 보인다.
embedded하는게 spring boot가 꼭 필요하진 않지만…
어쨌든 오래된 자바 컨셉에 적합한 구조는 아니다. 도커에 맞춰서 설계를 새로 잡아야 할 것 같다. 설정파일 관리부터 많은 부분이 바뀌어야한다.

Java Template 엔진 – 텍스트

JSP – jstl

www가 html을 쓴다면,  jsp도 계속 쓴다
협업시 jsp를 쓴다면 깔끔한 코딩은 신경쓰지 말자
쑤셔넣어서 개발하기좋고 보통 그렇게 사용된다

Thymleaf

이메일 템플릿 용도로 써봤는데
잘 만들어놓으면 퍼블리셔가 자꾸 망쳐놓는다.
문법이 어려우니까…
디자이너 퍼블리셔 개발자 협업해서 쓰라고 만든 것 아닌가?
이정도면 용도폐기 수준.

다시는 쓸 생각이 없다.

Velocity

jstl에서 꺽쇠 쓰는걸 샵으로 대체하는 정도
그만 만들고 다른 생산적인 일을 했으면 좋겠다.

Freemarker

Velocity와 또 다른 끔찍한 혼종
뷰 코드에 베이직형태의 코드를 짜집어 넣고싶어 환장한 사람이 있다면 추천
아니라면 이걸 쓸 필요는 없지 않을까

Mustache

jquery tmpl 하고 비슷한 방식을 사용한다.
익히기 쉽고 사용도 쉽다.
눈에띄는 단점은 없는데 실제 프로젝트에 적용 해 보지 않아서 아직 뭐라 말을 못하겠다.
간단한 페이지에 적용 해 볼 의향이 있는 정도

Jade

노드랑 ㄷ장고 프로젝트 만질 때 좀 썼었는데
좋지도 나쁘지도 않았다.
익숙하지 않아서 그런지 모르겠지만 탭강간이 심각했다
탭이 대여섯개 넘어가면 파일을 나눈다거나 하는 별도의 노력이 필요하지 싶다.
자바용으로도 나와있다고 하는데 자바에서는 안 쓸 것 같고
노드 프로젝트 할 때나 써봐야겠다.

결론

은 HTML

결국 HTML을 뽑아낼 방법을 찾는 것들인데

뭐가 더 편할지는 취향차이가 있을 것이라고 생각한다.

물론 완전히 잘못된 선택도 존재한다.

Java Template 엔진 – Layout

JSP include

엔진이라고 할건없지만…

구성 잘 잡아놓고 쓰면 tiles나 sitemesh 못지않다.

 

Sitemesh

레이아웃을 잡고 콘텐츠만 바꿔먹을 때 써먹기 좋다.

그런데… 프로젝트 할 때 마다 이것저것 써보자 써보자 하는것도 아니고…

우선순위에서 밀리다 보니 안쓰게 된다.

 

Tiles

주로 사용하긴하는데…

좋은지는 잘 모르겠다.

다른 쓸게 없어서 쓴다는 정도 느낌

ignore=true 옵션을 켜놔도 스텍트레이스가 계속 올라오는건 짜증이 난다.

이 부분을 소스코드 안쪽에 박아놔가지고 고작 이거하나고치자고 jar새로 만들기도 귀찮고 해서 그냥 쓰긴하는데

이것 말고도 캐싱할 파일이랑 아닌부분이랑 구분도 좀 되면 좋겠고 한데

별로 더 발전시킬 생각은 없는 듯 하다.

너무 복잡해지면 쓰기도 힘들어질테니