jQuery paging plugin update

jQuery paging plugin

내가 이걸 개발하고 방치한 지 3년이 지났다.
하지만 의외로 사람들이 페이징 플러그인을 찾다가 내 블로그에 들리기도 한다.
그리고 어느 블로그에서 내가 만든 페이징 플러그인을 소개하기도 했다.
그래도 돌아가긴 하나보다. 안정적으로.

그래서 오늘 오랜만에 재대로 손 좀 대봤다.
0.1.7 에서 0.2.0 으로 업데이트 했다.
기존 버전과 달라진 건 크게 없는데, append 속성이 쓸모 없어져서 제거하고, className 으로 컨테이너 관리 편의성을 높여준 업데이트이다.
나머진 기존 그대로 쓰면 되긴 하지만, 좀 더 편리하게
재호출할 때를 대비하여 일부 속성만 정의해도 기존 속성에서 정의 속성을 덮어씌워 페이징을 구성하겠끔 만들었다.
그렇다 보니 destroy 키워드가 생겼다.

아, 그리고 마지막으로 이건 문서에 안넣었는데, .paging(‘속성명’) 을 통해 속성값을 불러올 수 있다.
이는 아직 실험 단계지만, 조만간 편리하게 페이징이 처리되도록 할 생각이다.

프로젝트 페이지는 여기로 가면 되고,
bower 설치도 지원한다. bower install jquery.paging

언제까지나 유의사항은 “스타일링은 알아서 하라” 이다.

앞으로도 많은 성원 바란다.
감사하다.

독자: 이 미친새끼가 반말하고 지랄이야.

composite / 2016년 1월 26일 / Piss Development / 2 Comments

한국을 위한 CSS 그리드 디자인 프레임워크

그렇다. 사정은 잘 안다. 부트스트랩이나 파운데이션 같은 올인원 CSS 프레임워크는 안맞을 수밖에.

특히 디자이너가 있고, 기획이 재대로 되어 있다면, 한국 웹 사정에 부트스트랩은 어찌보면 경우에 따라 안어울릴 것이다.

디자인 떡칠해서 화려한 웹페이지 만들어야 직성이 풀리는 한국 웹사정에 안맞다 보니까.

하지만 이런 단어만 들으면 디자이너와 퍼블리셔는 가장 먼저 입에서 시발이라고 나올 것이다.

반응형 웹.

맞다. 반응형 웹의 주인공은 CSS의 미디어 쿼리다. 하지만 배우고 적용하기 까지는 시발 좆같다.

퍼블이나 디자가 왠지 개발자가 되어 가고 있는 기분 같을 것이다.

그럼 시발 개발자는 니들 하는 업무 다하고 있는 개발자도 있는데.

어쨌든, 그래도 자신이 맡은 업무에 충실하면서 클라를 만족하고 싶지 않은가?

그래서 시발 존나 위험한 개발자인 내가 소개한다. 퍼블과 디자인 니들을 위한 반응형 웹을 위한 CSS 프레임워크다.

나머지 디자인과 레이아웃 구성은 니들 꼴리는데로 하면 된다.

1. 960 Grid System (http://960.gs/)

전 세계에 인기를 한몸에 받고, 파생 CSS 프레임워크를 탄생시키게 한 장본인이자 웹에 생산성을 불어넣은 엄청난 놈이다.

이녀석은 웹 페이지의 한 행을 몇 열씩 나누게 하는 방식을 선보였는데, 전 세계적으로 인기를 한몸에 받았다.

이녀석의 특징은 960인데, 페이지의 기본 크기를 960으로 잡고 시작한다. 그리고 한 행당 12단씩 나눌 수 있다.

실질적인 컨텐츠가 들어갈 길이는 940이다. 여백 제외하고 말이다.

사용법이 무진장 간단하다.

<div class=”grid_나눌 숫자”>내용</div>

<div class=”clear”>행 나눔 (주로 공백을 넣는다. &nbsp; 같이.)</div>

예를 들어 12단 나눌 수 있을 경우, 3개씩 나누고자 한다면 이렇게 하면 된다.

<div class=”grid_4″>내용</div>

<div class=”grid_4″>내용</div>

<div class=”grid_4″>내용</div>

<div class=”clear”>&nbsp;</div>

이런 식으로 4+4+4=12 로, 총 12단으로 맞추는 것을 고려하여 4*3=12 니까 3개 div 에 grid_4 클래스를 넣으면 div 를 삽입하면 된다.

존나 쉽지 않은가?

단점은 니들이 원하는 반응형 그리드는 아니다. 타블렛이나 데스크탑에 적합한 레이아웃 구조에 탁월한 선택이다.

하지만 이거와 미디어쿼리를 합치면 반응형 그리드 디자인을 만들 수 있다.

그러면서 왜 이녀석을 소개하냐면 이녀석이 웹 그리드 디자인을 프레임워크로 탄생시킨 원조이기 때문이다.

2. Fluid Baseline Grid (http://fluidbaselinegrid.com/)

이녀석부터 이제 반응형 웹 디자인을 고려한 그리드 디자인 프레임워크 되겠다.

이녀석의 특징은 Baseline 인데, 글씨 크기 위주의 웹을 고려한 그리드 디자인을 생각했다고 보면 된다.

그래서 어찌보면 이미지 떡칠의 한국형 웹과 안맞을 지는 모르겠다. 그래도 소개한다.

이녀석의 특징은 % 단위의 넓이를 나눠서 처리한다는 것이다. 960.gs 또한 이를 지원한다.

그리고 이녀석은 최대 3단계 레이아웃이 있는데,

g1 은 작은 단위로 모바일에 표시 가능하도록 작은 크기의 영역을 잡는다.

g2 는 중간 단위로 타블렛에 표시 가능하도록 중간 크기의 영역을 잡는다.

g3 은 큰 단위의 테스크탑에 표시 가능하도록 큰 크기의 영역을 잡는다.

<div>

    <div class=”g2″>

         난 타블렛에서 하나를 다 잡아 먹는다.

     <div>

    <div class=”g3″>

         난 어느 장치에서 봐도 하나를 다 잡아 먹는다.

     <div>

    <div class=”g1″>

         난 휴대폰에서 하나의 영역을 잡아먹는다.

     <div>

</div>

솔직히 뭐 이 이상은 나눌 일이 없다고 봐도 무방하지 않은가? 그럼 됐다.

3. Negative Grid (http://chrisplaneta.com/free/negativegrid-generator/)

만약 직접 그리드 구조를 짜야 한다면 이녀석을 추천한다. 이녀석은 원하는 크기, 그리드 개수, 여백 등을 지정할 수 있다.

당연히 px 가 아닌 % 이기 때문에 % 단위로 짜야 한다. 만약 px 단위를 원한다면 960 그리드를 써라.

이녀석 또한 960 그리드와 마찬가지로 생성기 시스템인데, % 위주인 방식에서 틀리다.

게다가 가볍다. CSS 생성했는데 보기도 쉽고 내용도 별로 없다. 그리고 prefix 설정도 가능해서 반응형 웹 구성에 잘 맞는다.

사용방법은 대략 이렇다.

<div>

    <div class=”col4″>3단</div>

    <div class=”col4″>3단</div>

    <div class=”col4″>3단</div>

</div>

별거 없다. 나눌 크기를 정해서 col(또는 직접 정한 prefix) 옆에 숫자만 붙여주면 된다. 최대 숫자는 니가 정한대로다. 예를 들어 12개로 나뉘었다면 1부터 12까지를 쓰면 된다.

여백을 만드는 방법은 push(또는 직접 정한 prefix) 옆에 숫자만 붙여넣으면 된다.

난 굳이 미디어 쿼리 혼합하는 방법은 안가르쳐준다. 어자피 반응형 웹을 만들 거고 거기에 대응하기 위해 미디어 쿼리를 배웠을테니까.

그래서 이거와 잘 혼합한다면 깔쌈한 사이트가 만들어질 것이다.

IE를 위해서라면 respond.js 가 필요하다. 그냥 스크립트 쳐넣으면 끝이다 나머진 CSS에 맡겨라. 구글신 영접하면 바로 나온다.

귀찮아서 끝.

니들 그냥 좆돼봐라.

composite / 2014년 2월 27일 / 미분류 / 2 Comments

HTML5 API 정리 프로젝트 1

그렇다. 앞서 포스트에서 설명했듯이 나도 몰랐던 API가 우후죽순 생겼다.

하지만 앞으로도 계속 제안되고, 표준으로 등록되는 API가 많아질 것이다.
왜냐면 아직 표준 확정이 아니고 W3C에서도 Working Draft 상태거던!
이지랄을 하니 HTML5 과 HTML5.1 분리하자고 W3C에서 난리 브루스를 친다.

좋다. 그렇다면 현재 제안되어 Editor’s Draft 라도 나온 API를 알아보도록 한다.

물론 이미 알려져서 많은 이들이 알고 있는 API도 많지만, 나조차도 몰랐던 API가 속속 들이대기 시작할 것이다.

  • Fullscreen API 많이들 알거다. HTML5 게임이나 프리젠테이션을 위한 전체 화면.
  • Page Visibility API 말이 거창하지 그냥 다들 알고있는 모든 태그에 hidden 속성이다. style.display=’none’ 이냐 아니냐.
    하지만 더 특징은 hidden 속성 변경에 따른 이벤트를 제공한다는 점이다.
  • getUserMedia API 이것도 많이 알려져 있듯이 카메라에서 나오는 데이터를 HTML 미디어 표현 요소 <canvas>나 <video> 로 전달할 수 있는 API다.
  • Battery API 이건 순전히 모바일을 위한 API다. 뭐.. 제공해봐야 딸랑 배터리 얼마나 남음이겠지만. 아.. 노트북도 있지.
  • Link prefetching 별거 없고 그냥 미리 불러올 URL만 지정해서 해당 페이지로 이동할때 로딩 없이 바로 이동하는 목적이 있다.
  • WebMIDI 순수 웹으로 미디를 재생한다. 참고로 추억의 게임 포트리스2 블루가 음악이 MIDI 인데, 이걸 돌릴 수 있다. 근데 원본 가지고 있는 이가 얼마나 될런지 모르겠다. 근데 한국은 이런거 관심 없나보다. 추후 내가 포스팅 올리겠다.
  • Vibrate API 말그대로 진동 API로, 스마트폰의 진동 기능과 연동하는 API다. 현재 안드로이드 크롬 베타와 안드로이드 불여우가 지원하고 있다고 한다. 이제 순수웹으로 딜… 아니다.
  • History API 브라우저의 뒤로가기 앞으로가기 뿐만이 아니라 URL과 해시를 갖고 놀 수 있는 API로 뭐 많이들 알려져 있으니 패스.
  • Drag n Drop 요소 드래그앤 드롭. 물론 스크립트로 만든 드래그앤 드롭에 비하면 좀 엉성하지만 모든 환경에 지원하려면 이렇게 해야지. 많이 알려진 기능이다.
  • Geolocation 걍 GPS잖아. 알잖아. 내가 굳이 설명해줘야되?
  • Offline 인터넷 안되도 문서는 봐야겠지? 가지고 댕기면서 뭔가는 해야겠지? 그럼 이거야.
  • Messaging 다른 도메인인라고 스크립트 막는다? 응 그건 맞아. 하지만 이제 간단하게 서로를 전달이라도 할 수 있다는점.
  • Web Workers 자바나 닷넷의 쓰레드 역할. 백그라운드 실행을 담당할 API다. 구버전 IE야 지원을 안하지 그래도 웹오피스에서 이게 무거운 처리에 1등공신이다. 이제 무거운 스크립트를 직접 실행할 필요 없다. 이녀석에게 맡기면 브라우저가 얼지 않고 계속 즐길 수 있다.
  • Storage 단순한 저장 기능이다. 그 이상 그 이하도 아니다. 세팅값 저장에 이만한 거 없고 IE 8부터 지원한다. 당장 채용해도 된다. 근데 이벤트도 있는데 이건 안타깝게도 IE 지원은 안한다.
  • Indexed database 순수 웹상의 DB다. 당연히 도메인 단위로 쓸 수 있다. 하지만 NoSQL이다. 이거 이전에 SQL DB로 지정된 Web SQL Database 도 있긴 하지만 접근성이 떨어지고 기술적인 한계로 표준에서 배재된지 오래다. 이것도 많이 알려져 있으니 알아서 찾아봐.
  • Web sockets 존나게 많이 알려져있고 순수 웹으로 만드는 채팅 등 실시간 소켓통신의 선두주자 웹소켓이다. 구글링해라. 내손아프다. 기쁜소식 하나 알려줄까? 이녀석의 인기가 하늘을 치솟다보니 많은 참여와 수정으로 이제 거의 표준 확정이 되가고 있다.
  • Server-Sent Events7 푸시 알림의 HTML5 버전이라고 보면 된다. 한국에서는 웹소켓 때문에 얘기 묻혔지만 무시하지 마라. 구현이 쉽고 polyfill이 쉽게 제공되기 때문에 웹 사이트상의 푸시 알림이나, 실시간 정보 알리미에 이만한 API가 없다.
  • Microdata 시맨틱 정보 수집에 특화된 API다. 검색 잘되라고. 광고에 관심있다면 이것을 눈여겨보는것도 좋은 선택이다.
  • File API 어쩌다 보니 표준이 됐다. 좀 늦게나마 표준에 포함되서 다행이지. 파일을 말 그대로 다루는 API다. 물론 사용자 컴퓨터에 있는 파일을 맘대로 다룰 수 없고, 사용자가 파일을 요청해야만 다룰 수 있다. 그래봤자 예제는 업로드 뿐.
  • Web Notifications 알리미 API다. 현재 크롬에서 재대로 지원하고 있다. 당연히 사용자 승인이 요구되지만, 이 API가 있다면 CRM, 그룹웨어 같은 엔터프라이즈급 고객/자원관리 어플리케이션에 레드불이 날개를 달아준다.
수집하기 왜이렇게 힘드냐.. W3C 한국지사에 멜좀 보내야겠다. 정리하기 빡세네..

<

p>

composite / 2014년 2월 6일 / 미분류 / 0 Comments

비즈니스를 위한 node-webkit 데모를 지금 공개한다!

비즈니스에 node-webkit 를 관심가져야 하는 이유를 글 올렸었다.

하지만 아직도 망설이거나 개소리라고 하는 인간들 있을거다. 내가 다 안다.

그래서 준비했다. 나는 결과물을 통해 주장을 증명하고, 근거를 제시한다.

더이상 긴 말 안하겠다. 프로젝트 가서 설치법 및 실행법 보고 체험하라.

https://github.com/composite/NodePlatform

XPlatform 같은 비즈니스 CRUD를 순수 웹과 node-webkit 로 구현했다.

끝.

윈도우 사용자를 내가 열심히 배려했다. 단일실행파일 배포한다.

http://www.solidfiles.com/d/c5df88cb09/

다운받고 실행만 하면 된다. 소스? 프로젝트 사이트 가라니까 좀.

다른 운영체제? 미안하지만 회사컴에 맥이나 리눅스가 없어서.

composite / 2014년 1월 15일 / 미분류 / 2 Comments

데스크탑 앱의 홀릭, Brackets-shell 빌드하기 자료 소개.

뭐.. 내컴이 윈도우라 지랄같을 뿐이다.

일단 Brackets-shell 로 데스크탑 앱 개발하기 위해 고군분투를 할 것이다.

어도비에서 직접 지원을 하고 있고, 크로미움 기반이며, 소스가 MIT이기 때문이다.

Node-webkit 는 네이티브 플러그인 지원 측면에서 차별화된 양상을 보이지만,

bracket-shell 은 기존 node 네이티브 플러그인을 갖다 쓰거나 당신의 씨뿔뿔로 만든 라이브러리를 같이 쳐넣을 수 있기 때문에 더 주목을 받지 않은가 싶다.

이 링크를 참고하면 내가 왜 이리 씨뿔뿔부렸는지 알 것이다. 물론 영문이다.

http://clintberry.com/2013/native-desktop-javascript/

https://github.com/joelrbrandt/brackets-simple-node (이건 예제)

게다가 기본이 크롬리스 윈도우(테두리 없다고)이고, API가 안정적으로 제공되고 있는 측면이 힘을 발휘한 듯 하다.

어찌됐던 간에. Brackets-shell 을 빌드하여 커스텀 앱을 만드는 여러가지 팁이 있으니 소개해 보겠다.

나는 윈도우 기준으로 빌드를 할 거기 때문이고, 그리고 그렇게 할 것이기에, 윈도우 빌드방법 및 후기를 내가 직접 겪어봐서 올리도록 하겠다.

지금 나온 팁들은 죄다 맥 기준이다. 어도비는 맥에서 짱먹었으니.

http://clintberry.com/2013/html5-desktop-apps-with-brackets-shell/ (영문)

http://steamboatlabs.com/blog/brackets-native-desktop-apps-with-html-js-css/ (영문)

http://uiandwe.tistory.com/891 (한글 용자 등장, 물론 맥.)

어느 프레임워크를 선택할 지는 당신 마음이지만, 응용 프로그램의 다양성과 웹의 생산성 둘을 합친 비즈니스 앱의 강점은 내 블로그에 잘 설명되 있으니 보도록.

http://blog.hazard.kr/117

데스크탑 앱 만들기. 조또 없다.

근데 시발 Windows SDK가 안깔려…

composite / 2014년 1월 10일 / 미분류 / 0 Comments

요즘 웹디자인 대세는 점점 되돌아가는 방향으로 가는 것인가?

아마 앞으로 나간 디자인은 글로시 디자인(Glossy Design)인 것 같다. 확실히 미래지향적으로 느껴지는 디자인이었으니.

PNG의 보급과 CSS 의 입지가 커짐으로써 같이 주목받고 유행했던 디자인이었다. 2012년까지는.

그리고 2013년 플랫 디자인으로 유행을 했는데..

이제는 디자인 패턴이 되돌아보자는 차원인지.. 모르겠다.

물론 이게 나쁜것만은 아니다. 디자이너는 원래 유행을 좇는 종특을 가지고 있다고 하면 디자이너가 나 죽여 팰 것이고.

유행을 만들던 따르던 그건 당신 마음이지만 일단 유행은 그렇다고.

그리고 2013년 후반기부터 플랫 디자인에 힘입어 새로운 패턴이 등장했으니 바로 카드 디자인이다.

님들 페북이나 튓터 많이 하잖아. 글 하나하나마다 영역이 분리돼있지? 그게 카드 디자인이라고. 납득 ㅇㅇ?

어쨌든, 왜 카드 디자인이 2014년 디자인을 유행할 아이템인 것인가?

간단하다. 나 따라해봐.

  1. 니 명함을 본다.
  2. 니 명함을 스마트폰에다 갖다대본다
  3. 올ㅋ

그렇다. 카드 디자인은 모바일 장치에도 대응할 수 있고, 글 하나하나 영역이 뚜렷하기 때문에 어렵지 않게 볼 수 있다는 장점이 있다.

플랫 디자인은 영역이 “공백의 미” 라면, 카드 디자인은 “영역의 미” 인 것이다.

이 카드 디자인의 첫 상용화의 신호탄은 페이스북인가? 아니다. 의외로 새로운 서비스가 신호탄을 때렸다. 핀터레스트다. 사진 기반 소셜. 여자들이 모르면 간첩인 서비스다. (몰랐다구여? 죄송해여.)

페이스북도 사실 카드 디자인을 반영한 것 맞지만, 글로시도, 플랫도 아닌, 뭔가 리트로하고 심플하며 조금이나마 입체감 있는 디자인 패턴이 주류였다. 물론 지금은 IOS 7 신호탄 때릴때 플랫한 카드 디자인을 채용했다. 좀 됐지만.

구글도 이미 이를 따라갔고, 구글쁠라쓰 가면 카드 디자인이 담긴 메시지가 당신을 반길 것이다.

하지만 역시 디자이너의 글이 내 글보다 더 와닿을 것이다. 아래 글을 참고하라.

http://insideintercom.io/why-cards-are-the-future-of-the-web/ (원문)

http://radiofun.tumblr.com/post/60843934125/why-cards-are-the-future-of-the-web (한글번역)

비디자이너가 카드 디자인이 왜 유행인지 한번 내가 납득시켜주겠다.

쿠폰 봐봐. 존나 눈에 확들어오지? 그거야.

카드 디자인의 핵심을 다시한번 짚어보고 끝내겠다.

  • 정보 전달의 집중성.
  • 다양한 활용 능력.
  • 작지만 많은 것을 담을 수 있는 수용력.

ㅇㅋ?

이해 못하겠으면 내가 링크한데 가보랑께?

그럼 끝. 개발자가 존나 나불대봐야 디자이너와 개발자는 논란의 시발점이지. 물론 나처럼 안싸우는 사이도 있긴 하지만.

이렇게 기존에 실생활에 쓰던 디자인이 웹 디자인의 중심이 되고 있다.

그래서 나는 되돌아가는 방향으로 가고 있나 의심을 해봤다.

근데.. 되돌아간다기보다는 되짚어본다가 맞는 것 같다.

카드라고 해서 옛디자인으로 돌아가는 건 아니다. 디자인은 계속 진보되고 있는 사실은 확실하다. 베충이도 이해시켜줄까? 이게 팩트라고.

기존의 것에서 활용하는 것으로 시작된 웹 디자인. 플랫디자인부터 시작해서 카드 디자인,

이제 다음 디자인은 어디서 발견할 것인가? 이목을 집중시킬 만 하다.

진짜 끝.

composite / 2014년 1월 10일 / 미분류 / 0 Comments

composite / 2013년 12월 17일 / 미분류 / 0 Comments

비즈니스에서 node-webkit 에 관심가져야 하는 5가지 이유!

자바개발자던 닷넷개발자던 어자피 웹개발자라면 자바스크립트 쓸 줄은 아니 딴소리 마시고 읽어보고 판단하시길.

https://github.com/rogerwang/node-webkit

node-webkit 가 한국에서 점점 많이 알려진 점에 대해 기쁘게 생각한다.

프로젝트에도 쓰고 있고, 게다가 이미 공식 페이지에서 입증된 기술이다.

게다가 구글의 크롬 엔진이다. 크롬 엔진은 이미 웹에 앞서나간다는 업체라면 익히 알고 연구하거나 개발할 것이다.

그렇다면 무슨 말이 필요있겠는가? 이제 그런 강점에 촉진제를 넣어주도록 하겠다.

  1. 웹개발은 그대로 하면 된다.

기존 웹개발자가 갑자기 데스크탑 앱 만들라고 하면 시발 이게 무슨 소리여 할 것이다.

하지만 node-webkit 는 그딴거 신경쓸 필요 없다. 기존대로 웹개발만 하면 된다.

현재 개발자 중에 가장 많이 차지하는 게 웹개발자고, 그담 모바일앱 개발자다. 응용은 수가 적다. 물론 그만큼 희소가치가 있겠지만 웹이 더 싸게 먹히는게 웃지못할 정석이다.

node.js 개발이 별도로 필요하다고? 아니다. node.js 에서 그냥 님 웹페이지 띄울 수만 있으면 된다.

그 이상 신경 안써도 된다. 고급 기술을 채용하고 싶다면 그냥 node.js 개발자 뽑으면 된다. 아니면 님이 배우던가.

  1. 배포가 쉽다.

node-webkit 는 배포가 졸랭 쉽다. 소스 파일을 zip 압축해서 nw 로 바꿔 nw.exe 에 배치파일 걸어 실행해도 되고, love2d 처럼 nw.exe 내장시켜 단일 응용 프로그램으로도 배포 가능하다. 전혀 어려울 것 없다.

근데 그러면 어자피 소스가 다 까일텐데 걱정이 태산일 것이다. 웹 프로젝트 할건데 node-webkit 에다가 뭘 집어넣게?

굳이 해야 한다면 암호화/복호화 API 지원되니 그걸 쓰덩가. 데스크탑에 수행해야 하는 게 없지 않는 이상 크롬에 지원되는것들 다 지원되므로 걱정 붙들어 매기 바란다.

알리미 API? 그건 조금 아쉽긴 하지만 크롬처럼은 아직 지원이 어렵고 대신 구현은 가능하다. 링크 누르고 보고 따라하면 된다.

그정도면 비즈니스 앱 만드는데 불만은 없을 것이다. 이제 직원들에게 파일 하나만 딸랑 배포만 하면 되니까.

데스크탑에서 탭이라던가 그런것들 구현하고 싶다면 그냥 웹 그대로 하라. node-webkit 에서 해야할 일은 웹 페이지를 띄우는 것 뿐이다.

자동 업데이트? 님 응용 만드삼? 웹이잖아 웹. 웹 업뎃하면 그게 자동 업뎃이지 뭐야?

  1. 크로스 브라우징이 필요없다.

존나 고생하는거 안다. 시발 IE 조까튼 개새끼인거 안다. 이제 해방하라. 크롬 위주의 코딩을 해도 웹표준 그대로 따라간다.

W3C 에서 신기술 제의하는 대표적 기업이 구글, 모질라는 비영리단체고, 마소 등의 브라우저 만드는 기업이 포함되어 있으며, 표준안을 제시하며 그걸 그대로 따라간다. 따라서 카나리같은 개발자 전용 기능을 쓰지 않는 이상 HTML5/CSS3/Javascript 1.7 이상 표준 그대로 따라가도 된다. 쫄지마.

당신이 크롬 위주로 코딩한 95% 이상은 불여우와 IE 11 에서도 돌아가니 쫄지말고 코딩하라.

  1. 비즈니스 보안성이 향상된다.

비록 크롬 내장형 엔진이지만, 더이상 외부에 노출할 염려는 하지 말자. 물론 사내IP만 필터링 하면 되겠지만, 외부직원의 업무는 SSLVPN도 있고 하고. 하지만 문제는 아무래도 보안이다.

그런 면에서 액티브엑스 달린 웹은 보안성과 성능을 둘 다 씹고 똥컴 만드는 주범이다.

만약 보안성에 신경써야 한다면, 웹개발자는 웹에만 신경쓰게 냅두고, node.js 관련 보안 개발자를 통해 보안 모듈을 이식할 수 있다. 브라우저에 UUID 개념을 만들고 관리하여 인가된 사용자만 허용하게 할 수 있으며, 브라우저 헤더에 쳐넣을 수 있다. 아까도 말했듯이 암/복호화 API 제공하니 그거 써도 되고, 자체 보안 기술 가지고 있으면 C++ 확장 만들 수 있다.

사슬 edge.js 를 통해 .NET 코드도 돌릴 수 있긴 한데 문제는 .NET 4.5 이상이 요구되고 (윈도우 8 이상은 기본설치됨)

자바의 경우 node-java 가 있긴 한데 edge.js 에 비해 안정성 보장이 불확실한 점이 있다.

그러므로 응용 -> 웹 으로 이동하는건 문제가 아닌데 보안땜에 엑티브엑스 써야한다면 액티브엑스 개발자에게 node.js 모듈을 제안하던가 아니면 웹 보안에 맡기는 게 좋을 수 있다.

하지만 한가지 확실항 점은 바로 사용자 컴퓨터는 제어할 수는 없지만 node-webkit 프로그램을 쉽게 제어할 수는 있다는 것이다.

컴퓨터까지 통제해야 한다면 그건 그 업체 보안사항에 의한 별개의 문제고, 이 프로그램 연동과 상관 없으므로 알아서 생각하도록 하라.

그래도 쌩판 브라우저에서 실행되는 것보다는 보안성이 좋다. 브라우저를 제어하는건 불가능하지만 이 node-webkit 제어하는건 가능하기 때문이다.

  1. 많은 업체와 프로젝트를 통해 입증되었다.

node-webkit 의 개발자는 CPU 만드는 인텔 계열사인 오픈소스 업체의 사람이다. 인텔이 설마 신경 안썼겠는가?

게다가 많은 프로젝트와 업체가 생겼다. 개발자가 중국인이라(대만인가?) 중국업체가 대거 끼어들긴 했지만.

직접 눈으로 보려면 https://github.com/rogerwang/node-webkit/wiki/List-of-apps-and-companies-using-node-webkit

응용처럼 실행되지만 이것들이 모두 웹으로 만들었다. 믿겨지겠는가?

웹처럼 개발하고 응용처럼 실행되는 이상적인 환경에 이미 많은 프로젝트를 통해 입증했다.

아 피곤해. 당장 도입하겠다는 생각보다는 아무래도 고민이 앞설 것이다.

하지만 크롬은 크롬 앱을 통해 데스크탑 앱 시장에 손을 대고 있고, 웹으로 개발하고 응용처럼 사용하는 시대가 바짝 다가온만큼 비즈니스에서도 기존처럼 IE밖에 모르는 응용처럼 만들고 웹처럼 쓰는 고비용 저효율 자태 그만 뽐내고 이런 새로운 시대에 대응하는데에 고민을 하고 초첨을 맞추기 바란다.

composite / 2013년 12월 9일 / 미분류 / 0 Comments

Flat UI 로 만든 관리자 페이지를 보고싶다면?

플랫 디자인으로 만든 관리자 페이지? 있지!

뭐.. 물론 애플도 지금 아이클라우드 플랫UI로 베타 날려서 하고 있긴 하지만

이미 실전에서도 플랫 UI를 채택한 관리자 페이지가 있다는 말씀.

어디냐.. 윈도우 애져 관리자 페이지다.

Capture24.png

Capture25.png

메트로 UI로 플랫UI 상용화에 신호탄 때린 마소의 메트로UI 쏙 빼닮은 플랫 UI 관리자 페이지 되시겠다.

한글 글꼴이 굴림이라 촌스러워도 봐줘라. 영어로 하면 정말 플랫UI의 신세계를 맛볼 터이니.

19.png

영어로 하면 글꼴 덕분에 플랫UI가 지대로 살아난다.

안타깝게도 그냥은 못보고 애져 체험이라도 가입해야 한다. 90일 체험인데 신용카드 요구한다. 체험하기 싫거든 그냥 이 이미지로 만족하라. ㅈㅅ.

http://manage.windowsazure.com

composite / 2013년 8월 16일 / 미분류 / 0 Comments

composite / 2013년 7월 19일 / 미분류 / 0 Comments