Tag Archives: web

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을 써야할지

며칠지나서 다시보니
bower는 Deprecated된 것 같다.
gulp, grunt도 대세에서 밀려난 것 같은데…
빌더가 아닌 Bundler라는 개념으로 webpack이 사용되고
의존성관리는 yarn과 npm으로 하고 있다.
yarn과 npm은 기능이 중복되는것같은데 왜 따로 있는건지

web.xml 버전별로 정리

를 하려고 했지만…. 최근것만

4.0

은 언제 나오나

 

3.1

 

3.0

 

JavaScript 주소 가져오기

Javascript에서 기본 오브젝트 정보를 가져올 때는 DOM구조를 타고 내려가는게 중요한데

 

location.href 라고 쓰는것은

window.document.location.href 와 동일하다.

 

요즘은 디버거가 잘 되어 있어서 location만 치면 객체구조를 확인가능하다.

 

Social 개발 – facebook 좋아요 버튼

<meta property=”og:title” content=”제목”/>
<meta property=”og:type” content=”article”/>
<meta property=”og:image” content=”http://image.server.com/image/path.jpg”>
<meta property=”og:site_name” content=”MemoBlog”/>
<meta property=”fb:app_id” content=”1304102″/>
<meta property=”og:url” content=”표시주소”/>
<meta property=”og:description” content=”description”/>
http://stackoverflow.com/questions/8217404/how-to-clear-facebook-like-button-cached-information
페이지가 변경되도 페이스북에 캐시가 남아서 제대로 동작하지 않는 경우에는 이 페이지에 접속해서 주소를 입력하고 새로고침을 해준다.
https://developers.facebook.com/tools/debug/og/object/
쉘명령으로 한꺼번에 처리할 때는

NextWebFramework 3. 뷰단의 구조

View단에서 사용가능한 REST Client.

Engine에서 DB2API가 자동으로 지원되게 하는 부분은 간단히 구현이 가능하다.
그렇다면…. thrift를 쓸까 어쩔까 하던… 웹/모바일/…등등등에서 이 API or RPC를 직접 호출하기 위한 방법…?

자바스크립트에서 간편하게 사용 가능한 REST Client가 존재한다면…?
이 부분을 Thrift에서 처리할 생각이었지만 더 간단한게 있다면… 적용할만하다는 생각이 들었다.

그리고 그 기반기술이 될만한것들…
https://github.com/garycourt/JSV
Json Validation라이브러리. 이거 조금 적용해서 도메인 구조를 json으로 정의하도록 만든다.
https://github.com/jashkenas/backbone/
js 모델 라이브러리
http://abaaso.com/
REST관련 라이브러리

프레임워크의 생산성 향상을 위해서는 전용 ide가 필수적인데… json기반으로 도메인을 정의한다면 웹쪽의 ide는 별도로 개발이 필요하지 않게 된다.

그래도 묶음배송기능, 로컬AJAX에서 외부 리소스호출을 위한(크로스도메인땜에) 인터페이스같은건 따로 개발이 필요하긴 하다.
좀 큰 부분은 해결된듯하다.
회사때리치는 일만 남았다.

NextWebFramework 1 : 무거운 프레임워크와 복잡한 테스트

요즘 웹 프로젝트는 사양이 상당히 좋은 컴퓨터로도 가동시키는데 30초? 조금 안좋은 컴퓨터로 하면 1~2분 무거운 프로젝트라면 5분까지 걸리기도 한다.

어마어마하다.

화면하나 고치고 테스트를 해보려면 5분을 기다려야 할 수도 있다. 동적으로 로딩이 되지만… 무거운 프로젝트라면 이조차도 버겁다. 로딩하다가 Pergem어쩌고 하면서 멈춰버린다. 그러면 재시작을 해줘야하니까….

그래서 사용하는게 Unit 테스트…. 그런데 View는 어쩔건가

별수없이 서버를 올려야된다.

아니면 가벼운구조로 새 프로젝트를 생성하고서 테스트를 하거나…  뭐 어쨌든 저쨌든 귀찮은 과정을 거쳐야만 한다.

자바는 너무 과도하게 무거워졌다. 루비도 몇번 돌려보긴 했는데 역시 마찬가지다. 서버 올리는데는 조금 시간이 걸린다. html테스트하는것처럼 바로바로 로딩이 되질 않는다.

이건 확실히 문제가 있다.

 

이 부분을 개선하기 위해서 필요한 것은 역시 모듈화.

그렇다면 어떤 구조로 나눌것인가가 문제가 된다.

 

1. SSO 를 중심으로 각 기능별로 웹사이트를 나눠버린다.

2. View / Controller / Service / Model / DB 의 방향으로 각 모듈별로 나눈다.

1번은 흔히 사용되는 방식으로 프로젝트의 크기를 적절히 분할한다면 효과적인 방법일 수 있다.

그런데 개인적으로 2번의 방법을 시도해보고싶었다. 이유는 간단하다. 2번이 더 간단하고 더 가볍고 효율적이다. 다만… 적절한 아키텍처가 제시되지 않고 있다. (찾아봤는데 없어서 없다고 단정지었다)

 

2번의 방법을 View-Engine-Model 구조로 정의한다.

VEM(가칭)

각 업무담당자별로 모듈을 나눌 수 있다는게 장점이다. 협업을 줄여서 각 모듈간의 충돌을 최소화한다.

설계단계는 별로바뀌는게 없을 것 같다. 기획이 나오고 개발자와 회의를 거쳐 구현이 가능한지를 결정한 다음 스토리보드를 뽑아낸다. 도메인모델과 디비도 이 단계에서 어느정도 설계가 될거고.

이 모델의 강점은 여기있다. 뷰단계에서 데이터가 들어있는 것처럼 화면을 동적으로 보여줄 수 있다는 점.

입력할 데이터를 미리 정의된 프로토콜형태로 text로 저장시켜놓은 후 화면단코드(자바스크립트,css등)을 수정하면서 바로바로 확인하며 코딩이 가능하다.

대략이런식으로 매핑이 되게 할 수 있다.

현재 나와있는 jquery , angular 등의 JS라이브러리로 구현이 가능할것으로 보인다. 이 부분은 조금 더 검토필요…. 화면단은 좀 덜해봐서

어쨌든 데이터를 기다리지 않고 화면단의 변경이 가능하다는 점이 가장 큰 장점이다. 일반 SI회사에서 가장 요구사항 변경이 잦고 고객사에서 귀찮게 하는 부분이 이 화면단인데 이 부분에 대해 초기대응이 가능하고 변경이 적어진다는 것이 장점이다.

보안이슈가 있는 경우에는 view쪽에서 사용자 인증 필터를 깔아야되는 경우도 있을 수 있다.(있을수도 있다가 아니라 대부분 경우-필요없는데서도- 이런 요청을 하지 않을까 싶다. 인증시스템은 기존에 만들던대로 만들면된다.)

 

View – Engine간의 연결

Ajax와 RPC.

언어에 따라 달라지겠지만 표준은 ajax와 rpc가 될 것이다. 화면과 로컬서버간에 ajax로 통신을 하고 ajax로 데이터를 가져오는 것은 cross domain제약이 있기 때문에 rpc를 이용해 통신을 하도록 한다. 쓰리프트의 경우 js도 지원을 하기 때문에 더 편리?하게 사용이 가능할지도 모르겠따. 생각해보니 쓰리프트 js거치는게 이것과 비슷하게 생성이 됏떤것같다.

앞의 화면코드에서 User배열을 json형태로 받았는데 이 부분은 다음과 같은 파라미터를 전송해서 호출한다.

묶음배송기능. ajax호출시 여러개의 데이터를 한꺼번에 호출하는 경우가 많은데 이 경우 RPC에 부하가 크기 때문에 묶음배송기능이 필요하다. 그래서 파라미터는 배열로 전송한다.

request : [{메서드명, 데이터(테이블 or 도메인)명}, {} …]

response : {{rpc상태메세지}, {data}, {data}}

response Set 첫번째 데이터는 상태메세지다. Set이지만 텍스트형태니까 앞쪽에 포함시키면 앞쪽이 된다.

각 domain이 가공되는 형태는 pre/post handler resolver 등을 붙여서 후처리 가공할 수 있도록 지원한다.

화면단에 보일 데이터의 형태인 도메인과 디비에 저장될 테이블은 같은 형태가 아닐 수 있다. 화면단에서는 완성된 vo를 호출하기 때문에 뷰에서 필요로 하는 데이터를 쿼리만 입력하면 완성된 데이터로 출력을 해 준다. 이 부분에 대해서는 api를 만들면서 만들어본적이 있으니 간단할듯 싶다.

 

Model : Engine부분과 굳이 분리할 필요는 없다. 합쳐지는게 더 효율적이지 않을까

ORM을 사용할 경우 Engine에 상당부분 포함될 수 있다.
ActiveRecord 생각하다보니 Rails구조가 떠올랐는데….
이 구조가 왠지 레일즈와 닮은것같다.

ORM을 써도 그냥 쿼리를 넣을 경우에는 그냥 쿼리로 뽑아볼수도 있어야한다.

 

이걸 분리시키면 너무 복잡하니 그냥 View-Engine Structure로 하는게 나을것같다.

구체적인 아키텍처는 다음번에 이어서.

JavaScript – 이벤트 발생후 화면 다시 로딩

그냥 이렇게 써놓으면 된다.

확인 후 재시작… ajax같은거 사용후에 적용해놓으면 좋다.

상황에 따라 재로딩을 하는 방식이 달라져야한다.

ajax로 추가되는 리스트인 경우는…. 다른방법인데 지금은 생각이 안난다.

BootStrap 빠르고 간편하고 간지나는 홈페이지 제작

개발자의 고충

디자이너는 너무 비싸다.

의사소통도 힘들다.

직접 디자인을 하면… 촌스럽다.

 

그래서 이런 불편을 해소해주는 프레임워크? 부트스트랩

http://twitter.github.com/bootstrap/

트위터의 개발자가 만든것으로 디자인을 간편하게 할 수 있도록 도와준다. 네비게이션메뉴, 버튼디자인 등을 간편하게 해 준다. jquery로 노가다 떡칠을 해야 겨우 만들 수 있던 것을 무려 apache 라이센스로 풀어주셨다. 글로벌 회사라면 이정도는 되야하는건가? 요즘 컴퓨터쪽 오픈소스 최신기술 나오는거 보면 요즘 잘나가는 회사들이다. 애플만 없는건가

 

부트스트랩도 그냥 막 편하기만 한 것은 아니다. 메뉴명이나 클래스명을 좀 알고 있어야 하기 때문에 시행착오도 있고 익히는데 시간이 좀 걸린다. 그래도 오픈소스 개바자들이 관련 툴들을 많이 배포해주니 편하게 감사하게 사용하자. 시간이 되면 자신이 만든것도 공유하고~

 

1번. 폼 배치하기 – 회원가입 폼 같은거… 굉장한 노가단데… 여기가서 마우스로 클릭클릭하면 쓸 수 있다.

http://bootstrap-forms.heroku.com/#

2번. 부트스트랩용 버튼들

http://charliepark.org/bootstrap_buttons/

http://www.plugolabs.com/twitter-bootstrap-button-generator/

 

 

ACL,Access Control List 접근 제어 목록

사용자별로 권한을 부여하고 그 권한을 바탕으로 접속 허용 여부를 결정하는 것을 말한다.

값은 보통 String을 사용한다.

 

guest, member, admin 세개의 권한이 있다.

사용자들은 위 권한중의 몇 가지(중복가능)의 권한을 가지고 있다.

권한은 사용자가 가진 최상위 권한을 우선 적용한다. 구현하기 나름이지만… member {student, teacher} 이런식으로 포함관계를 갖게 만들수도 있고 {minsu, dongsu}와 같이 수평 개념으로 만들수도 있다.

예1)

연습장에다가 다음의 사용자 이름을 적어본다

이건희, 이재용, {내이름}, 박정희

다음의 사용자가 있다고 가정하고 {guest, admin, member} 세개의 권한을 적당히 줘 본다.

예2)

그럼 다음 기능에 권한을 줘 보자

{사용자목록보기, 공지사항읽기, 공지사항댓글쓰기, 자유게시판 읽기}

(역시 구현하기 나름이지만 기능에 권한을 줄 수도 잇고 페이지에 줄 수도 있다. 도쿠위키의 경우는 페이지에 준다.)

 

이거 대충 보고 dokuwiki를 설치하고 ACL설정을 해 보면 곧 이해가 갈 것이다.

굳이 dokuwiki를 찝어서 말한것은…. 이게 설치하기 쉬우니까