[딥빡] ASP.NET Core RC1 -> RC2 Tools

ASP.NET Core RC2가 나왔고, 비주얼 스튜디오 도구가 나왔다.
하지만 언제나 그랬듯이 Beta 에서 RC1 로 순탄하게 업그레이드 될 리 없었는데,
그때는 걍 베타 삭제하고 RC1 설치하면 바로 해결됐다.
하지만 RC1 지우려고 했는데 이번엔 뜬금없이 설치 파일을 요구한다.
설치 파일명은 AspNet5.ENU.RC1_Update1_KB3137909.exe 이다.
만약 취소하면 삭제가 취소된다.

마소 이 개생퀴들아!

RC2 나오자마자 파일 지워버렸잖아!

이 파일 어떻게 구해 썅것들아!!!!!

그래서 구글링 했는데 다행히도 쉽게 찾을 수 있었다.
필요한 사람 다운받아라. 그리고 설치하지 마라. 안될 거다.
AspNet5.ENU.RC1_Update1_KB3137909.exe
그리고 삭제 시 파일 요구할때 이 파일을 선택하면 속 시원히 지워질 것이다.

그리고 RC2 설치하면 된다. 속 시원히 설치될 것이다.

만약 파이프니 알 수 없는 오류니 안되는 경우가 있는데,
일단 안타깝게도 오프라인 설치가를 제공하지 않고 있다.
온라인 설치 파일을 다운받고,
다운 폴더를 콘솔 창에 열어
DotNetCore.1.0.0.RC2-VS2015Tools.Preview1.exe /layout
치면 원만하게 설치가 완료된다.
그리고 깔아주시면 된다.
그리고 어디 백업하던지 해서 남겨라. RTM 나오면 삭제할 때 필요하게 될 지도 모른다.

참고(영문)
ASP.NET 5 RC 1 Update 1 Offline Installer

추가 업데이트

나처럼 재수없게 새 프로젝트 생성하거나 웹 프로젝트가 안열릴때
RC1 삭제 시 웹개발 도구가 덩덜아 날아간 경우가 있다.
에휴… 프로그램 및 기능에서 비주얼 스튜디오 변경 클릭 후 웹 개발 도구 체크해주자.

composite / 2016년 5월 27일 / Piss Development / 0 Comments

From node-webkit to Electron 1.0

이 글은 Github 소속 Electron의 메인 개발자인 Cheng Zhao(@zcbenz)의 기고글을 번역한 글이다.
원문: From node-webkit to Electron 1.0
시간에 쫓기고 작성하다 보니 오역이 있을 수 있다. 오역 교정 환영한다.

아니 프리랜서가 시간관리도 못하고 왜 시간에 쫓겨다녀?

한국 프리랜서는 용병이 아니라 그냥 사업자를 빙자한 근로자거든요 ㅋ


이 글을 통해 내가 node-webkit를 재구성하다가 Electron 프로젝트를 시작하게 된 내역을 기고한다. 내역을 좋아하는 애들을 위해 커밋 내역과 관련 링크를 달아주었다.

DOM에서 node.js 모듈 불러오기

모든 것의 시작은 2011년 @rogerwang 이 만든 마법의 모듈 node-webkit이었다.
이 node.js 모듈은 웹킷으로 하나의 브라우저 창을 띄워주는 것도 모자라, node.js 모듈까지 사용하는 마술까지 부렸다.

Node.js 코드 단은 이랬고,

var nwebkit = require('nwebkit')
nwebkit.init({'url' : 'index.html'}, function () {
  nwebkit.context.runScript('')
})

그리고 index.html 내용은 이랬다.

<html><body>
<p id="output"></p>
<script>
require('fs').readdir('.', function (err, files) {
  var result = ''
  files.forEach(function (filename) { result += filename + '<br/>' } )
  document.getElementById('output').innerHTML = result
});
</script>
</body></html>

이 데모로는 아직 시판하기엔 부족한 점이 많았지만, 충분히 성공 가능성이 있었다.

크롬 임베디드 엔진을 사용하다.

그 당시 node-webkit 에서 가장 큰 문제였던 게 있는데, 웹킷 라이브러리 기능을 리눅스 외에 사용하기엔 너무나 버거웠다.
그래서 @rogerwang 은 이 모듈을 웹킷에서 크로미움을 애플리케이션에 넣는 인터페이스를 제공하는 크롬 임베디드 프레임워크로 바꿔 해결했다.

당신은 그 CEF를 사용하여 개발한 node-webkit 코드를 볼 수 있다. node.js 비동기 기능을 수행하도록 만들기 위해, 거기에는 크로미움 메시지를 node.js 입출력 라이브러리인 libuv로 대체하는 패치가 있었다. 그러나 이제 그 패치는 더이상 찾을 수 없었다. 왜냐하면 NW.js 의 Chromium fork 저장소가 이미 오래전에 rebase 해버렸기 때문에. 이제 그 당시 커밋 내역으로 돌아갈 수 없게 됐다.

인턴으로 취직

당신은 @rogerwang 오랫동안 오픈 소스를 지원했던 인텔에 일하고 있다는 사실을 알고 있는가? 놀랍게도 인텔이 오픈소스를 위한 인턴을 구했다. 이보다 더 좋은 인턴쉽이 있었던가?

Intel OTC

2012년 여름, 나는 한참 졸업을 앞둔 대학생이었을 때 여름 인턴쉽을 찾으러 다녔다. 그 때 바로 인텔의 구인란이 눈에 보였는데, 인텔은 node.js의 오픈소스 프로젝트 node-webkit 개발자가 필요하다고 했다. 나는 이때다 싶어서 지원했고 운좋게 붙었다.

그리하여 나는 그 node-webkit 를 개발하기 시작했다.

컨텐트 쉘

첫번째로 내가 했던 업무는 node-webkit의 CEF 브랜치 개선이었다. 그리고 개발하면서 정말 어렵게 해냈다.
node.js가 V8 API를 직접 호출하면서 CEF는 크로미움의 컨텐트 모듈을 입히는 자체 API를 연동한다.
당신이 크로미움과 node.js를 연동하고 싶다면 중간에 CEF를 엮이지 않게 달아야 할 것이다.

그래서 기존 코드를 향상시키는 대신 아예 컨텐트 쉘을 재구성하는 쪽을 택했다. 크로미움을 최소한으로 사용한 가벼운 브라우저를 구현하기 위해.

결과는 꽤 좋았고 node.js 통합이 가능한 작은 브라우저를 획득했다. 그리고 난 그 node-webkit 0.2.1 버전으로 릴리스를 배포했다.

node-webkit를 프레임워크로

node-webkit는 node.js 모듈이기 이전 독립적인 브라우저였었다. 왜 여태까지 이 프레임워크로 HTML과 자바스크립트로 데스크탑 앱을 만들지 않았지? 나는 그 때 몇 개월간 그 아이디어를 행동에 옮겼다.

먼저 나는 node-webkit의 패키징 시스템을 추가했다. 아이디어는 게임 프레임워크인 LÖVE framework 를 슬쩍했다. 그 아이디어는 앱을 ZIP 아카이브로 만들고 node-webkit 실행 파일을 합치면, node-webkit 실행 시 그 아카이브를 풀고 아카이브에 포함된 앱을 실행하는 식이었다.

Packaging node-webkit

몇가지 구현 항목이 있다면, package.json 에 윈도우 속성을 넣거나, DOM 요소 확장, 브라우저 보안 모델 삭제, DOM 요소에 네이티브 파일시스템 도입, 그리고 끝없는 버그 수정 등이다.

한가지 재밌는게 가장 어려운 도전이 있다면 아무래도 node.js 네이티브 모듈 도입이었다. 나는 V8에 OpenSSL을 도입하기 위해 따로 기호(Symbols)를 추가해 크로미움에 패치하고, NSS와 OpenSSL 사이에 충돌이 일어나는 node.js 기호도 수정해 패치했다. 이렇게 윈도우용 원시 코드 node.lib 커스텀 패치를 제공하여 node-webkit에 네이티브 모듈이 돌아가도록 했다.

이리하여 node-webkit v0.2.5 배포 후, 왠지 안정된 느낌을 받았다.

자체 API 추가

이번엔 API 제공하는 데 DOM을 여전히 격리되고 있고, DOM 제공이 너무 제한적인 부분인 현실에 내 생각을 말해본다.
예를 들면 네이티브 메뉴와 여타 텍스트가 들어간 메시지박스 등.

그때 나는 자체 API를 제공하는 제공할 수 있는 걸 생각해 냈다. 바로 require('nw.gui') 같은 빌트인 모듈. NW.js 써봤다면 알 것이다. 그때 나는 메뉴를 생성하거나, 트레이, 메시지 창 등을 API에 넣었다. 지금 NW.js의 원형인 셈이다.

내가 새 릴리스를 배포할 때마다 이런 아이디어를 유지했고, node-webkit v0.3.6 버전으로 피날레를 장식했다.

다른 GUI 프레임워크와는 달리 크로미움의 특별한 점 하나가 있는데, 바로 멀티 프로세스 아키텍쳐라는 점이다. 크로미움 브라우저는 웹 페이지를 실행하고 GUI를 띄우면서 응답해야 하기에 웹 페이지에 GUI 모듈 제공은 너무나 힘들었다.

이렇게 해서 웹 페이지 내에 브라우저 처리를 하기 위한 내 첫번째 시도는 이랬다.
먼저 크로미움을 싱글 프로세스로 돌린다. 허나 이건 너무나도 불안정하게 돌아간다.
이번엔 그냥 네이티브 GUI API를 렌더러 프로세스에 호출하도록 해봤다.
하지만 몇몇 플랫폼에서 GUI 요소와 프로세스를 직접 핸들링할 수가 없었다.
그래서 찾은 마지막 방법은 IPC 메시지를 통해 GUI 모듈을 node-webkit에 입혔다.
이렇게 해서 렌더러 프로세스 중에도 상시 행동이 가능했고,
브라우저 프로세스 간이나 주어진 일을 완료하면 메시지를 보낼 수 있게 됐다.

node-webkit 홍보

node-webkit 같은 프레임워크는 사용자가 가장 중요하다. 많은 사용자를 가지고 만드는 데 있어서 가장 중요한 것들도.

그래서 내가 node-webkit를 개발하는 동안 최대한 홍보도 해왔다. node.js 메일링 리스트에 소개글도 올렸고, 답글도 달아줬다.
node-webkit 게시들을 달며 node-webkit 발표도 했고, node-webkit 샘플 앱도 제작했다.
이렇게 나는 전 세계에 내 힘으로 node-webkit를 알리는 계기를 만들었다.

그리고 node-webkit 개발을 중단하기 전에 Github 별을 천여개 씩이나 받았다. Github에 상위 C++ 프로젝트 10위 안에도 들었다.

첫 사용자

내게 node-webkit 첫 사용자는 정말 중요한 순간이었다. @ibdknoxLight Table editor 을 node-webkit 를 통한 웹 기술로 다시 탄생시켰다. 이후 많은 이들이 node-webkit 에 주목받고 많은 도움이 들어왔다. 이렇게 기쁜 순간을 만들어준 @ibdknox 에게 감사의 말을 전한다.

그 다음 해에 Light Table는 node-webkit 에서 Electron 으로 자리를 옮겼다. 왠지 오랜 친구가 돌아온 것 같았다.

GitHub으로 이동

어느날 Github 에서 비밀리에 Atom 에디터를 시작하면서, @nathansobo 가 node.js로 데스크탑 앱을 개발하는 사람을 구하고 있었다.
나는 Atom을 node-webkit에 마이그레이션하기 위해 필요할 때마다 node-webkit를 개선하는 조건으로 그와 계약했다.

이렇게 반년동안 node-webkit를 개발하다가 인텔 인턴쉽은 이렇게 끝났다. 바로 나는 Github 고객지원부로 일하기 시작했다. 그리고 동시에 node-webkit 개발을 중지하고 뒷일은 @rogerwang 이 모두 맡게 됐다.

Contribution Graph

왜 이렇게 뜨거운 감자인 node-webkit 개발을 중단했을까? 어자피 내가 Github으로 이동하는데 전혀 영향도 없었고, 누가 프로젝트를 운영하는데 나는 상관이 없으니까.

아시다시피, 난 인텔에서 다른 사람의 프로젝트를 진행하고, 프로젝트의 결정권을 가질 수도 없었다. 아무렴 어떤가.
그냥 난 누구의 방해도 없이 node-webkit을 재구성할 수 있고 기능을 추가하면서 장난감 조립하듯이 일하는 게 좋았으니까.
어느날 node-webkit 오픈 소스 규모 커지기 시작했고 말 나오기 무섭게 나의 node-webkit의 권한은 상실됐다.
새 버전을 배포하는 데 있어서 책임이 상급 엔지니어에게 이관되어
내가 일할 수 있는 범위가 사실상 줄어들었고, 내가 좋아하는 기능을 넣을 수 없었다.

비난할 이유가 없다. 인텔 말고도 다른 회사도 그러니. 하지만 단도직입적으로, 더이상 참을 수 없었다.

더 나은 데스크탑 프레임워크 제작

내가 Atom 개발에 참여했을 때, Atom은 CEF에 파일시스템을 운영하기 위한 자바스크립트 바인딩으로 이루어져 있었다. 이게 Atom이 node-webkit로 마이그레이션한 계기가 됐지만, node-webkit가 그때당시 결함이 많다 보니 앞길이 순탄치 않았다.

그래서 난 결국 자체 네이티브 쉘을 만들어 해결하기로 했다. 새로운 쉘은 node-webkit를 개선하는 대신 몇가지 근본적 구조를 바꾸는 방향으로 재구성했다.

이리하여 이 쉘에게 atom-shell 이라고 이름 지었다.

node-webkit 에서 Electron 1.0 까지

그 이후 Electron과 NW.js 에 무슨 일이 일어났는지 내역을 정리했다. Atom과 Atom-shell 은 오픈 소스로 배포했고 그 atom-shell은 Electron으로 개명했고, node-webkit는 NW.js 로 이름을 바꿨다.

그리고 저번 주말에 드디어 Electron 1.0 을 배포했다.

Contribution Graph

Electron은 NW.js의 파생인가?

아마 내가 받은 질문 중 가장 많이 받은 질문이고, 내가 이 글을 쓴 이유이기도 하다. 기술적으로는 Electron은 node-webkit 0.3.6을 재구성했다. 내가 마지막으로 배포한 버전이고 이걸 끝으로 node-webkit 개발을 중단했으니. 그러고 보니 Electron은 원래 node-webkit와 아주 다른 노선을 밟았다.

그러니까 재대로 얘기 좀 하자면, NW.js는 내가 node-webkit 개발한 걸로 시작했고, Electron은 내가 다시한번 node-webkit에 파고든 작품이다.


복터진 개발자네. 군기잡힌 인턴 개발자에서 Electon 메인 개발자가 되기까지…

composite / 2016년 5월 25일 / Piss Development, Waldo Translation / 2 Comments

node.js의 웹 기반 데스크탑 앱 프레임워크 비교

nw.js

내가 많이 사용해봐서 잘 안다.

뭐래 병신이…

장점

  • 초보자에게도 쉬운 접근성
  • 크롬 확장 및 API 지원
  • nwjc를 통해 지적 재산권 보호 기능 지원 (소스 코드 보호해준다고.)
  • 키오스크, 항상 위, 트레이, 메뉴, 투명화 등 기본적으로 앱에 필요한 기능 지원
  • 웹 컨텍스트 기준으로 프론트엔드 개발에 능하다.

단점

  • 존나 무겁다. 크롬의 대부분 기능을 담았기 때문에.
  • 자체적으로 앱 패키징이 없기 때문에 타 모듈 등을 사용해야 한다. (근데 맥은 존나 편함 ㄳ)
  • 소스코드 보호기능은 당연하지만 성능이 30% 이상 하락하므로 필요한 곳만 사용.
  • node.js 확장 중 네이티브 확장 지원이 그지같다. node-gyp로 가져온다 해도 다시 nw-gyp 써야 함.
    업데이트: 0.13부터 이제 nw-gyp 안써도 됨. (윈도우는 개발자에 한해 한가지 뭐 해야함 아 귀찮.)
  • 피드백 속도가 좀 느리다 (Github Issue 피드백이 평균 7일이라고 함. 참고로 같은 Issue 트래킹에 Electron은 평균 1일.)

Electron

한국에서 가장 많이 알려지고 애용하는 프레임워크.

내가 nw.js 홍보했더니 구려 터졌다고 꺼지라더라.

장점

  • 가볍다. 크롬의 핵심 기능만 넣었기 때문에.
  • 앱의 Hang 및 Crash 처리를 자체적으로 지원.
  • HTML5 및 ECMAScript 6 등 가장 최신 기술을 가장 빠르게 지원
  • 자체적으로 쉽게 사용 가능한 앱 패키징 및 업데이트 모듈 지원
  • 항상 위, 트레이, 메뉴, 투명화 등 기본적으로 앱에 필요한 기능 지원
  • 절약 모드를 무력화하는 API 및 웹 표준 DRM 등 더 다양한 기능 지원

단점

  • 크롬 확장 미지원
  • 소스 보호 기능이 없어 타 모듈(enclose.js 등)을 사용해야 함.
    (Electron 메인 개발자인 Cheng Zhao(@zcbenz)는 퍼포먼스를 위해 이를 지원하지 않겠다고 못박음)
  • Electron은 컨텍스트 구분이 nw.js에 비해 뚜렷함.
    이런 이유로 nw.js에서 쉽게 jQuery 지원했던게 Electron에서 쉽게 안되는 이유이기도 함.
    자세한 내용은 해당 FAQ 참고.
  • node.js 확장 중 네이티브 확장 지원이 그지같다. node-gyp로 가져온다 해도 다시 electron-gyp 써야 함.

node-thrust

앤 또 뭐냐…

몰라 시발.

장점

  • node.js 뿐만 아니라 Go, Python, Ruby 등의 언어 지원
  • 자체 IPC 원격 통신 제공
  • 저장 경로 사용자화 및 다른 방식의 쿠키 저장소 지원
  • 자체 프록시 기능 지원

단점

  • 데스크탑 앱의 모든 기능을 지원하지 않음. (다행히도 투명화는 지원)
  • file:// 프로토콜 미지원 (node-thrust에 자체 웹 서버가 있는 이유)
  • 프론트엔드와 백엔드 사이 연동 미지원 (예: 프론트엔드에서 node.js 모듈 바로 못씀)
  • 뜨고는 있지만 아직 부족한 문서

내가 뭐 부가설명 쓰려 했는데 까먹은 관계로 여기까지.

composite / 2016년 5월 18일 / Piss Development / 0 Comments

Microsoft Edge 브라우저가 빡치는 이유

윈도우 10에 내장된 Edge.
옛날 유럽에 IE 끼워팔기 논란에 휩싸였던 IE의 역사를 딛기는 개뿔 일단 OS 종속적 인터넷 브라우저다.
뭐 물론 이후 윈도우에서 선택적으로 프로그램 추가 제거에 포함되는 쾌거(?)도 낳았던 논란이다.
사실 그렇게 따지면 Mac OS의 Safari는 뭐냐 시발?

어쨌든 Edge. 크롬의 초창기를 보는 듯한 브라우저이다. 초기화 속도도 빠릿빠릿하고 페이지 불러오는 속도도 빠릿빠릿하다.
물론 크롬처럼 확장 기능 많아지고 이것저것 덕지덕지 붙이는 날이 온다면 어떻게 될지는 그때 가봐야 알 것 같고.
ACID 점수가 점진적으로 높게 간다는건 좋은 징조 아니던가.

하지만 역시 IE보다도 불편하게 만드는 Edge의 문제점을 짚어보고 사용 시 유념하고 넘길 건 넘어가야겠다.

뒤로가기와 앞으로가기 버튼의 히스토리 부재

이건 진짜 용서할 수 없는 부재다. IE보다도 불편하게 만드는 가장 큰 주범이다.
특히 리디렉트가 더럽게 많은 한국사이트와 소셜로그인으로 인한 다중 리디렉트 이후에는 정말 빡치게 만든다.
원하는 이전 페이지를, 예를 들어 구글 검색하다 레딧 들어가서 구글 로긴 하고 레딧 댓글 달다가 다시 구글 검색결과로 돌아가는 시나리오를 생각해보자.
히스토리 내역도 안보여주고, 오로지 감으로만 몇번 연속 클릭질을 해야 하니 얼마나 짜증 이빠이지 아니한가.
그렇다고 개발자도구 키고 history.go(-2) 이지랄 하리? 하아…

SSL 있어? 신뢰할 수 있는 사이트네. 근데?

HTTPS 를 통해 접속된 사이트라면 주소표시줄 옆에 자물쇠 아이콘이 있어 안전한 사이트임을 보여준다.
근데 그다음엔 어쩌란 말인가. 진짜 이 사이트가 정말 신뢰된 사이튼지 아닌지 검증하고 싶은데?
인증서를 볼 수 없다. IE도 크롬도 불여우도 다 인증서 정보 보여주는데 IE는 그딴거 없다.
다행히도 비주류(?) 브라우저라 망정이지 이건 정말 개선해야 한다.
주류였으면 피싱은? SSL 스니핑 등 다양한 공격을 구분할 수 있는 수단은? 개발자 도구 여는거? 지랄.

HTTP 오류 페이지 그만 좀 보고싶다.

엣지는 HTTP 오류 코드가 나오면 정말 친근한 페이지가 여러분을 반길 것이다. 400이던 404던 500이던…
하지만 개발자에게는 정말 지랄같지 아니할 수 없다. 오류 내용 보려면 개발자 도구 켜고 내용 볼 수 밖에 없다.
아 그래… 맞아.. 하긴… 이건 개발자가 볼 페이지긴 하지… 근데 이건 아니자나…
다행히도 Edge가 오류 페이지를 보여주는 조건이 있다고 한다.
Prevent Edge browser hiding HTTP error pages

In Internet Explorer, as long as the server returned more than 512 bytes of data in the response, it would display the response, but in Edge, that’s not enough.

원래 IE에서는 HTTP 오류 코드를 받을 때 응답 내용 크기가 512바이트를 넘기면 사이트에서 제공하는 오류 페이지를 보여준다고 한다. 하지만 Edge는 이걸로 부족하다고.

https://www.hackcraft.net/error/badrequest/

이 경우 400 HTTP 오류를 보여주는데 페이지 내용이 표시된다. 크기는 2.17KB라고 한다. 보여준다. 이런 식으로 조건을 만족하면 되나보다.

아 손아파. 일단 여기까지.

composite / 2016년 5월 17일 / Piss Development / 0 Comments

자바 개발시 Hot Swapping 종류

Java Server Hotspot

  • JDK 설치하면 기본적으로 제공
  • 메소드 내용을 수정한 뒤 재시작 없이 반영
  • 그게 다임. 내용 수정 외의 수정은 모두 재시작해야 함.

jRebel

  • 상용으로 유료 솔루션
  • 자바 코드 어떻게 수정해도 재시작 없이 반영
  • Spring 플러그인에 한해 XML 설정도 재시작 없이 반영
  • 왠만한 WAS 및 환경에서 사용가능 (국내한정 JEUS는 되긴 하지만 공식 미지원)
  • 적은 코드 변경에는 아주 빠른 Reload
  • 변경 코드가 많을수록 Overhead 심각 (이건 어느 솔루션도 못피함. 이건 무조건 재시작삘.)

Spring loaded

  • 무료이며 오픈소스
  • 스프링만 적용 가능 (전자정부는 되겠지 뭐)
  • 스프링 자바 및 XML, properties 변경 시 적용
  • 스프링 외 플러그인 설정파일 변경 지원 안함.
  • 현재 톰캣만 지원. 나머지 WAS 보증불가
  • 몇몇 사용자에서 재시작이 안되는 문제가 보고되고 있음

Spring boot devtools

  • 무료이며 오픈소스
  • Spring boot만 적용 가능 (상속 때문에 일반 spring 적용 불가)
  • spring boot 및 상속 가능한 모든 자바 및 설정 파일 변경 시 적용
  • spring boot 돌아가는 어떤 WAS 상관 없이 지원 (JEUS는 모름)

닷넷커: ㅋㅋ ASP.NET (MVC 포함)은 기본 전체 홧스왑 수준인데 고생한다.
자바커: MS 종속적이고 비싸기만 하며 오픈소스 없는 놈이 말이 많어.
닷넷커: 이제 크로스플랫폼 지원하고 소스는 이미 오픈된지 오래임.
자바커: 그러던가. 어자피 한국에서는 영원히 잊혀질 기술임 ㅗ.

composite / 2016년 5월 12일 / Piss Development / 0 Comments

SQL별 숫자 극한값 구하기.

주로 ORDER BY 에서 최우선순위를 주거나 아예 밀 때 요긴할 SQL 구문이니
잘 쓰도록.

MySQL(MariaDB)

출처: StackOverflow – In SQL how do I get the maximum value for an integer?
MIN은 현재 방법 없다고 한다. 그냥 타입에 알맞는 상수 써라.

SELECT ~0 as max_bigint_unsigned
,      ~0 >> 32 as max_int_unsigned
,      ~0 >> 40 as max_mediumint_unsigned
,      ~0 >> 48 as max_smallint_unsigned
,      ~0 >> 56 as max_tinyint_unsigned
,      ~0 >> 1  as max_bigint_signed
,      ~0 >> 33 as max_int_signed
,      ~0 >> 41 as max_mediumint_signed
,      ~0 >> 49 as max_smallint_signed
,      ~0 >> 57 as max_tinyint_signed
\G

*************************** 1. row ***************************
   max_bigint_unsigned: 18446744073709551615
      max_int_unsigned: 4294967295
max_mediumint_unsigned: 16777215
 max_smallint_unsigned: 65535
  max_tinyint_unsigned: 255
     max_bigint_signed: 9223372036854775807
        max_int_signed: 2147483647
  max_mediumint_signed: 8388607
   max_smallint_signed: 32767
    max_tinyint_signed: 127
1 row in set (0.00 sec)

MSSQL

방법 없다. 아래 링크가서 타입에 알맞은 상수 갖다 써라. 아니면 아래 상수를 스칼라 함수 꾸며 써도 된다. 아니면 “닷넷 어셈블리” 간단히 만들어서 써도 된다.
MSDN – int, bigint, smallint, and tinyint (Transact-SQL)

MSSQL 2012 이상

Maximum Limit Value For Integer Data Type in SQL Server 2012

Select Power(cast(2 as varchar),(64) -1) as 'Bigint max range'  from sys.types Where name = 'BIGInt' 
Select Power(cast(2 as varchar),(32) -1) as 'int max range'  from sys.types Where name = 'Int' 
Select Power(cast(2 as varchar),(16) -1) as 'Smallint max range'  from sys.types Where name = 'SMALLInt' 

ORACLE

역시 방법 없다. 오라클은 여타 SQL과는 달리 INTEGER가 NUMERIC(11)의 ALIAS다.
일단 알려진 방법은 아래 함수가 있다. INTEGER MAX 구하는 함수이다.
Is there a way to get the PL/SQL maximum pls_integer?

CREATE FUNCTION MAX_PLS_INTEGER_SIZE RETURN PLS_INTEGER AS 
  p PLS_INTEGER;
  b NUMBER;
BEGIN
  b := 0;
  WHILE TRUE LOOP
    BEGIN
      p := POWER(2, b)-1;

      b := b + 1;
      EXCEPTION WHEN OTHERS THEN
        EXIT;
    END; 
  END LOOP;

  RETURN p;
end;
\
SELECT MAX_PLS_INTEGER_SIZE FROM DUAL;

PostgreSQL

얘도 오라클과 마찬가지로 NUMERIC이 모든 숫자 타입을 담당한다.
상수 값은 공식 문서 참조.
다행히도 간단한 방법이 있는데, pg_column_size라는 함수가 있다.
여기에 원하는 타입과 타입에 맞는 바이트 길이를(예: int는 4) 대입하여 처리하면 된다.
Postgres maximum value for BIGINT

select  (2^(8*pg_column_size(1::bigint)-2))::bigint << 1 as min_bigint_value;
select  -(((2^(8*pg_column_size(1::bigint)-2))::bigint << 1)+1) as max_bigint_value;

일단 많이 쓰는 SQL 기반으로 작성하였다. 추가할 거 있다면 서로 공유하면 웃음꽃이 피어날 것이다.

composite / 2016년 5월 11일 / Piss Development / 0 Comments

블로그 계속 운영합니다.

언제나 그랬듯이 공지는 존대말로 운영합니다.

호스팅 제공자에게 어찌저찌해서 사이트는 살렸습니다.
따라서 폐쇄될 일은 없어졌습니다.

알고보니 워드프레스 플러그인 중 Wordfence 라는 놈이 문제였습니다.
이 플러그인이 운영하는 테이블 중 일부가 손상되어 백업 작업에 문제가 발생해
이게 어쩌다가 시스템 장애까지 났는지 모르겠지만 wordfence 삭제 후 디비 백업은 정상으로 돌아와
간신히 호스팅 제공자와의 갈등은 해결했습니다.

더 웃긴 건, Wordfence 도 이를 인지했는지 업데이트를 했지만, 최신 버전을 쓰는대도 문제가 발생했고,
wordfence 제작진은 그저 “업데이트 하면 해결된다” 식으로 일축해 더이상 그 플러그인 쓸 맛이 안나는군요.
대체 플러그인 찾아야 쓰겄습니다.

어쨌든 만약 제 블로그를 항상 눈팅하시는 독자님께 감사의 말씀을 드리며,
다시 블로깅을 진행하도록 하겠습니다. 닷넷 만세! (자바 개발자중에 스파이가 있다.)

composite / 2016년 4월 4일 / Notice / 0 Comments

블로그 잠정 폐쇄합니다.

갑자기 존대말 써서 놀라셨죠? 공지는 언제나 존대말 씁니다.
호스팅 제공자 요청으로 블로그를 잠정 폐쇄하게 되었습니다.
사유는 과도한 디비 사용입니다.
워드프레스 남들과 다를 거 없이 써왔다고 생각했는데 아니었나 봅니다.
해명 메일 보냈지만, 이미 확정이기 때문에 이번주까지는 블로그 보이실 겁니다.

아, 물론 갑작스런 공지라 저도 어디로 옮길지는 고민하고 있습니다.
흐음…

지금까지 블로그를 봐주셨던 독자 및 안티 여러분께 감사의 말씀을 드립니다.
이런 저런 일도 많지도 않았던 블로그가 소리소문없이 폐쇄하면 뭐할까봐
이번엔 미리 공지를 드리겠습니다.

그럼 어떤 모습으로 찾아뵐 지 고민해야 봐야 할 시간이군요.
가장 빨리 접할 수 있는 페이지는 아무래도 제 메인 페이지입니다.
http://hazard.kr
여기서 블로그가 탄생하면 링크 날려봐야죠.
페북 친구분들도 있으실 테고, 블로그 나오면 공개로 올라가겠죠.

어찌보면 이제 더이상 반말 찍찍 갈기며 욕하는 컨셉도 이게 한계인가 봅니다.
나름 도움이 됐다고 하던 분도 있고, 불편하다고 하던 분도 있더군요.

이참에 새출발 해야겠습니다. 그리고 고민 후 오픈하면 공지 날리죠.
제 페북 아시죠? 아실 겁니다. 알아서 찾으세요.
아니면 걍 제 홈페이지 가시면 됩니다. 트위터 하냐고요? 맨날 털려서 안합니다.

그럼 여러분, 그동안 감사했습니다. 즐거운 하루 보내시길.

composite / 2016년 3월 24일 / Dog's bullshit / 0 Comments

잠긴 글: 증명서 PDF 출력

이 콘텐츠는 비밀번호로 보호되어 있습니다. 보려면 아래에 비밀번호를 입력해주세요:

composite / 2016년 2월 19일 / 미분류 / 0 Comments

넷퍼넬은 트래픽을 제어하지 분산시키지 않는다.

먼저, 내가 넷퍼넬 영업하는줄 아는 아해들에게 본문요약부터 간다.

  1. 넷퍼넬은 트래픽 분산을 하지 않고 제어를 한다. 분산이라고 착각하지 마라.
  2. 트래픽 분산하려면 또다른 영역이 필요한데 대표적 사례가 클라우드다.
  3. 넷퍼넬 고객들은 대부분 2와 같은 시나리오보다 기존 시스템 활용을 원하기 때문에 사용한다.

요즘 왠만한 국가기관 및 대학에서 뭐 신청할 때 꼭 대기번호와 대기인원수가 표시되어 기다려야 하는 이상한 기능이 있다.
그렇다. 알 사람이라면 알 넷퍼넬이라는 일종의 솔루션이다.
근데 넷퍼넬을 트래픽 분산 솔루션이라고 잘못알고 계시는 분들 꽤 많은데,
넷퍼넬은 “트래픽 분산 솔루션”이 아니다.
“트래픽 제어 솔루션”이다.
이는 넷퍼넬 공식 사이트에서도 언급하고 있다.

그럼 왜 대부분의 접수 사이트에 넷퍼넬이 있는가?
사실 어른들의 사정이 꽤 작용하긴 하지만 주요 요인은 이렇다.

  1. 기존 시스템 활용
    넷퍼넬 고객들은 대부분 기존 시스템을 건드리지 않고 그저 embed 하는 형식으로 트래픽을 제어하길 원한다. 국가기관일 수록 더. 그럴 때 넷퍼넬은 정말 좋은 사업 아이템인 것이다. 국가기관 입장에서는 인력비보다 덜 든다고 착각하는 효과를 가져온다.
    그렇다. 착각이다. 더 얘기하면 설명이 길어지니 여기까지.

  2. 임시 창구를 늘리는 것보다 번호표를 활용
    간단하게 은행 창구를 예를 들자.
    기존환경: 고객들은 번호표 없이 줄서서 순서대로 은행업무 수행.
    트래픽 분산: 창구를 돈을 들여 더 만들어 줄을 분산시켜 고객에게 빠른 은행업무 제공
    트래픽 제어: 그냥 번호표 출력제품을 사들여 번호 순으로 고객에게 은행 업무 제공.

그러고 보니 내가 전에 클라우드를 일시적으로 도입하여 트트픽 분산에 큰 효과를 본 사례를 소개했다.
장점은 한번 구축하면 필요 시마다 클라우드에 배포만 하면 되며, 트래픽으로 인해 필요한 자원을 늘렸다 줄였다 하여 유연하게 트래픽을 제어하여 분산시킬 수 있는 이점을 가지고 있다. 이로 인해 고객들에게 빠르고 장애가 적은 서비스를 제공하면서 분산된 환경으로 기존 업무를 문제없이 수행할 수 있다는 점이다.
하지만 단점으로는 단 하나의 모듈이라도 구축 비용이 소모되며, 따로 관리해야 하고, 관리하는 인력비용이 든다는 것이다.
이는 외국에서 주로 사용하는 수법이긴 하다.
외국에서도 넷퍼넬 같은 트래픽 제어 솔루션을 사용해야 할 때가 있는데, 이는 대부분 대규모 기업/기관이 아닌 중소기업/단체 들이 사용한다. 당연히 분산 비용이 더 부담되기 때문에.
하지만 넷퍼넬은 고객들이 대기업 아니면 국가기관이다. 그렇다. 넷퍼넬 구축 비용은 분산 비용하고 차이는 시스템 구조를 잘 몰라 파악은 어렵지만, 분산 비용과 맞먹는 비용이 나온다는 점도 되겠다. 중소기업에겐 넷퍼넬 같은 제어 솔루션을 쓰기엔 돈이 없다는 것이다.

어찌 됐던, 트래픽 분산과 제어에 대해 햇갈리지 않았으면 하기에 글을 올렸다.

composite / 2016년 2월 2일 / Dog's bullshit / 0 Comments

1 2 3 20