자바 개발시 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

멀지 않은 미래의 개발자 사회구조 예측

미래의 개발자 사회는 이렇게 될 것이다.
0.1의 극소수로 가상머신 등을 개발할 코어를 담당할 씨언어 기반 개발자,
그다음 하위 소수에서 시스템 튜닝이 가능한 자바, C#, Rust 등 중급 시스템 레벨을 건드릴 시스템 개발자,
그리고 다수의 자바나 C#, 자바스크립트 등의 앱 개발자.
이렇게 나눠질 것이다. 이미 개발 언어 점유율만 봐도 나오고 있는 사실이다.

그리고 가상머신 개발자는 선택된 금수저처럼 운명 외에는 절대 아무나 접근 못할 시대가 올 것이고, 개발자의 빈부격차가 심각해질 것이며,
최종적으로 개발자 임금 구조까지 격차로 이어질 것이다.
근거?
지금 미국의 아이티 대기업들이 개발자들을 수천 수만명 잘랐고 심지어 IBM은 11만명씩이나 잘랐다.
이러한 이유는 대기업들이 개발자를 정예화하고 나머지는 스타트업 투자를 통해 기술과 점유율을 확보하겠다는 것이다.
사내직원의 모험보다는 스타트업의 모험에 투자하는 게 덜 손해보기 때문에.
스타트업은 투자해서 망하면 그걸로 끝이지만, 사내직원은 망해도 자른다 해도 또 퇴직금이나 인력유동으로 인한 비용 등으로 돈을 더 써야 한다.
이는 회사 운영해 봤다면 알 것이다.
이런 구조로 간다고 하면, 한국처럼 개발업체의 갑을병정 시대가 도래한다느 뜻이 된다.
물론 한국처럼 불공정하고 착취하진 않지만, 이제 정착의 시대가 온다.
당신이 개발자라면, 정체성을 반드시 확립해야 하는 시대가 올 것이다. 지금 당장.

만약 개발자의 계급화와 빈부격차가 도래된다면, 게임 개발자도 예외는 없을 것이다.
이제 게임의 모든 핵심 코어 기능과 최적화는 선택받은 게임 엔진 개발자들이 모두 알아서 해결하도록 환경을 조성할 것이고,
이제 게임 개발자들은 게임을 개발하는데에만 열을 올리면 될 것이다.
그것도 C/C++ 언어가 아닌 자바나 C# 같은 고급 언어, 심지어는 Lua나 자바스크립트 같은 스크립트 언어로.
내가 왜 이렇게 장담하냐고? 유니티를 보라. 유니티는 고급 언어로 개발할 수 있는 환경을 만들었고,
이제는 유니티 게임을 많이 쓰고 있다. 모바일 게임 시장 절반이 유니티가 먹을 정도이다. 이정도면 감이 올 만 할 것이다.

이는 곧 개발자의 종말 예고이기도 하다. 이제 극소수 외에는 코딩조차 안해도 앱개발이 가능한 시대가 올 것이기 때문이고,
많은 비IT 전문가들이 바라고 있으며, 많은 선진 개발자들이 예상을 하고 있기 때문에.
내 예측은 개발자가 종말하기 이전에 대한 과정이라고 봐도 무방하다. 개발자들의 경쟁, 분열… 이들이 소리없이 진행되고,
누군가는 개발자 없이 앱 개발하고, 누군가는 디자이너 없이 디자인 해주는 그런 솔루션이 개발을 할 것이다.
그러기 위해서는 물론 여러 환경적 영향이 있겠지만, 내가 아까 말한 환경도 이런 환경을 조성하는 데 밑걸음이 될 수도 있다.

이제 개발자로 먹고살기 힘들어 질 것이다.
설령 외국 간다 해도. 당신이 정말 핵심 브레인이 될 만한 역량이 없다면, 말할 것도 없다.
이를 약간 회피할 수 있는 유일한 개발자 분야는 역시 프론트엔드 개발자이다. 디자인과 사용자 경험까지 신경써야 하기 때문에.

긴장하라 개발자들이여. 미국 IT 대기업들이 개발자에게 던지는 메시지는 그리 좋지는 않을 것이다.

세줄요약
1. IBM 등의 미국 대기업은 사내 개발자 확보보다 스타트업 중심으로 기술과 점유율 확보에 중점을 둘 것이다.
2. 개발자의 계급이 피라미드처럼 구성되어, 저급 개발자는 VM에 초점을 맞추고 이를 다수의 고급언어 개발자들이 나눠쓸 것이다.
3. 2 항으로 인해 개발자 단가부터 빈부격차가 발생할 것이며, 이는 곧 개발자 간의 분쟁과 경쟁으로 개발자는 씨가 말릴 것이다.

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

이제 하드웨어의 역습이 시작된다.

아니, 이미 시작됐다.

내가 뭔가 잘못 생각했다…

한국에서는 삼성의 하드웨어 중심 전략에 대해 우려를 표시시 이들이 많았지만,
삼성은 한국에 최악의 근무조건과 환경에도 불구하고 오히려 해외에서 승승장구 하고 있다.

그리고 PC사업의 위기로 인해 잠시 주춤했던 Dell 도 갑자기 승승장구하며 대규모의 소프트웨어를 잡수시고 있다.
심지어 소프트웨어 가상화로 엄청난 부를 축적한 VMWARE조차 델 앞에서 깨갱한 것이다.

그렇다… 하드웨어 플랫폼이 구축된 대기업이…
소프프웨어 파워를 이긴 것이다…

소프트웨어 파워를 강조한 전문가들 다수 의견들과 달리
결결적으로는 소프트웨어 파워는 하드웨어 파워를 이길 수가 없는 것인가…

이제… 하드웨어의 역습이 시작될 것이다.
소프트웨어가 아무리 좋아도…
하드웨어 구축 없이 소프트웨어는 돌아가지 않는다고.

삼성은 더 뜬다. 이재용은 이미 알아차렸다.
어자피 중국 처럼 국가 지원 받으면서 쪽쪽 빨아먹으며 커졌다.
한국에서 털어서 해외에 투자하는 전략은 이미 성공한 것이다.

그렇다. 하드웨어가 정답인 것이다.
마소와 애플도 하드웨어가 있어서 잘 살고 있는 것이다.

이제 하드웨어의 권리행사가 시작될 것이다.
소프트웨어 개개자들이어, 이제 하드웨어도 익혀야 할 때다.
아두이노, 라즈베리… 이놈들 물론 무시는 안하겠지만,
이들을 공략해야 한다. 안그러면 살아남지 못하는 시대가 올 것이다.

참고기사
VMware swears it will continue to support Fusion and Workstation after firing both programming teams

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

또다른 오픈소스 IDE: Consulo IDE

흐음… 한국에 자바 IDE 쌍벽은 아무래도 Eclipse 와 IntelliJ 일 것이다.
Netbeans 도 있긴 하지만 쓰는 사람이 드물어서…

어쨌든 간에, JetBrains 에서 .NET IDE 만든다고 한 지 2주.
근데 댓글에서 심상치 않은 IDE를 발견했다.

이름하여 Consulo IDE 이다.

Consulo는 IntelliJ IDEA Community Edition의 쉘 전신인 IDEA IDE 베이스로 만들어진 오픈소스 IDE이다.
현재 안드 공식 개발 툴인 IntelliJ IDEA 기반의 쉘 UI 프레임워크가 오픈했다라…
엉? IntelliJ에 썼던 UI가 오픈소스라고?

정말 있다. 오픈소스로. IntelliJ Community Edition

그렇다. 커뮤니티 에디션에 한해서 오픈소스로 공개하긴 했다.
게다가 Apache 2.0 라이선스다. 상업적으로 써도 문제는 물론 없다.
아니었으면 상업적으로 안드로이드 개발은 물건너 갔을테니.

어쨌든, 다시 Consulo로 돌아가자.

Consulo는 현재 C#, Javascript, Java 등을 지원하며, 모든 언어를 지원하는 하나의 IDE로 통일하겠다는 목표를 가지고 있다.
안타깝게도 안정된 버전이 아니라서 실무에 쓰기는 조금 어렵지만,
유니티 개발자들이 이 IDE를 주목하고 있다.
왜냐?
모노IDE가 좆같거든.

인텔리 기반이라 인텔리 플러그인을 지원 하기는 한다. 조금 손을 봐줘야 한다고 한다.
마이그레이션 과정을 거치는데, 아무래도 라이선스 이슈 때문이다.
불편하더라도 인텔리제이와는 분리해야 써야 하는 이유이기도 하다.

Add a plugin

JetBrains 에서 Project Rider 로 C# IDE를 꾀하고 있고.
아마 유니티 개발에서 하나의 변수로 떠오를 가능성이 큰 상황이다.
어자피 모노와 닷넷은 API가 틀리지 언어 구조와 스펙까지 틀린 건 아니니
지켜봐야 할 내용이고,

거기에 오픈소스로 강공을 펼칠 Consulo IDE에도 주목할 필요가 있다.

IDE 전쟁이 시작되는 것이다. 우오.

composite / 2016년 1월 28일 / Piss Development / 0 Comments

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