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

클라우드와 웬수 진 한국 개발환경

스타트업이야 클라우드 덕분에 쓸데없는 서버 구축과 유지, 인력 비용이 감축되는 효과 때문에 땔래야 땔 수 없는 관계다.
하지만 내가 쓸 글은 스타트업이 아니라 기존 국내 공기관과 대기업, 학교 등에서 왜 클라우드를 안쓰는지다.

사실 어느 대학에서는 클라우드를 도입하여 큰 효과를 도입한 사례가 있다.
그리고 클라우드의 위력을 겨우 이 사례 하나만으로 내 뼛속깊이 클라우드가 뭔지 와닿게 해 주었다.
그 대학 이름을 까먹어서 얘기를 못하겠지만 요약하자면 아래와 같다.

  1. 정시 모집. 언제나 그랬듯이 정시모집 기간에는 서버가 무조건 터져서 학사업무 보기 더럽게 어렵다.
    (일부러 DDoS 공격으로 접수 못하게 하다가 걸린 뉴스도 있을 정도.)
  2. 게다가 정시 모집때마다 외주 개발자들은 비상근무 체제에 돌입하기 때문에 집에갈 생각일랑 하지 않는게 좋았다.
  3. 그런 대학에서 새로운 시도를 했는데, 바로 정시모집 모듈을 클라우드에 옮기는 작업이었다.
  4. 같은 운영 환경으로 여차저차해서 어렵게 정시모집 부분을 클라우드에 옮겼다. 물론 국내 클라우드다.
  5. 드디어 악마같은 정시모집 프로세스가 오픈됐다.
  6. 하지만 학사업무에 하나도 지장이 없었다. 당연히 정시모집 부분만 클라우드로 옮겨서 완전히 격리됐기 때문이다.
  7. 게다가 많다 싶으면 스케일링을 업해서 자원을 늘려서 무사히 정시모집 마감.
  8. 이 사례로 인해 각기 업계 대표들이 클라우드를 다시보는 사례로 떠올랐다.

는 개뿔 지금도 국내 시니어 IT 전문가들은 아직도 클라우드랑 웬수졌다.
물론 전문가가 익숙치 않은 환경에서 도입을 어려워하는 건 있지만, 이것보다 더 큰 게 바로 어른들의 사장이다.
특히 매번 코레일이 명절때마다 서버 미어 터져서 Netfunnel 이라는 솔루션을 도입한 지 오래지만… 이번엔 Netfunnel 이 터지는 일이 부지기수라
재수 없으면 몇명 안되는 대기에서 통신이 안되어 무한 대기상태로 인해 새로고침 하고 다시 대기타야 하는 불상사는 흔한 일이다.
이렇게 클라우드를 기존 업체에서 활용하는 이유는 정말 다양하지만, 내가 대표적 사유를 꼽도록 하겠다.

1. 보안?

조금은 어이없지만, 보안상을 이유로 소스를 외부 업체 클라우드에 올리는 것을 꺼려한다. 보안 기준이 그렇기 때문이다.
대부분 공기관과 기업 보안 정책은 자산을 무조건 외부로 유출하면 안되도록 하고 있다. 소스 코드도 마찬가지인 거다.
물론 예외 상황이야 만들 수는 있지만, 책임 소재 때문에 결국 예외 상황을 만들지도 않고,
윗대가리 또한 이런 책임 소재를 지기 싫어한다. 지들 밥줄 끊기 싫고, 밥줄 끊어지는 순간 가정이무너지고 사회가무너지고… 하니까.
물론 코레일도 클라우드를 고려 안했을리는 없을 것이다. 하지만 이미 코레일은 5년전부터 NetFunnel을 선택했다.
그렇다. 무슨일이 있어도 자산을 외부에 맡기는 것은 절대 용납 안한다는 뜻이 된다. 어떻게서든 자체적으로 해결하려 한다.
괜찮다. 어자피 밤새도록 지켜줄 개발자가 있기 때문에. 병신같은 개발자들…

2. 비용?

윗분들이 클라우드에 옮길 경우 비용산정을 할 때, 절대로 생각 안하는 부분이 있는데, 그게 바로 운영 손실분이다.
그렇다. 비용 산정할때 참 널널하게 짠다. 물론 가끔 타이트하게 짜기도 하지만, 왠만하면 널널하게 짠다.
그 이유는 간단하다. 눈 먼 돈이거든. 지들 호주머니 들어갈 돈을 산정하지. 미래에 무슨일이 일어날 지에 대해서는 어자피 땜빵할 인력이 있기 때문에.
고도화가 맨날 망하는 이유가 그거다. 널널하게 예산 잡으면 뭐하나, 결국 실제 쓰는 예산은 타이트하고, 기획하느라 시간 다 빼먹고 시간 얼마 안남았으니 외주 조져서 개발 어떻게든 완성은 시키는데…
언제 와르르 무너져내릴 지도 모르는 시스템이 지들 성과라 자랑하면서 무너지면 지들 책임 회피하고자 외주 더 조지고 손해배상 소송까지 하고…
어쨌든, 이들에게 클라우드를 상기시키는 건 참 어려운 일이다.
“돌아가면 됐지 우리가 왜 문제가 발생할 때 비용을 지출해야 하냐? 문제 발생하면 고치는 게 당연한 도리지 않냐?”
이딴 생각 하고 있는 윗님이 자리잡고 있는데 클라우드 생각 하겠는가? 나같아도 안한다.
그러니 문제 해결에 필요한 다른 대책방안을 생각하기 어렵고, 결국 땜빵에 의지할 수밖에 없는 실정이다.

3. 고정관념

윗분들 문제 뿐만이 아니다. 더이상 새로운 기술을 접하기 싫은 개발자도 문제다.
클라우드는 서버를 대여하는 개념이고, 언제든 사양을 높이고 줄일 수 있다.
하지만 대부분의 개발자는 고정된 운영 환경에 맞춰 프로그램을 만들고 운영하는 데에 익숙해져 있다.
즉, 처음부터 규모를 잡고, 이 규모에 맞춰 개발한다.
그렇다 보니, 썰렁하면 썰렁할수록 돈먹는 하마가 되고, 많으면 많을수록 이거대로 확장이 어렵게 하여 한계가 오고 결국 서버가 다운되기 일쑤다.
사실 개발 지침부터 병신같은 게, 무조건 보안을 위해 HTTP POST를 통해 링크를 구성하고 웹 페이지를 연결해야 하는 가이드가 있다.
참으로 병신같지 않을 수가 없다. 그건 그렇다 치자. 이렇게 한계를 가지고 개발하다 보니 클라우드 접목은 생각도 못할 일이 된다.
게다가 클라우드를 도입하면 서버관리자는 필요가 없어진다고 생각하는데, 없으면 당연히 예상비용 대비 손실 발생 시 답이 안나오기 때문에 안둘 수가 없다.
근데 서버 관리자들은 클라우드를 자기 밥그릇 뺏든 웬수라고 생각하기도 한다. 대체 어떤 대가리를 가지면 그런 발상이 나오는지 참 신기할 따름,
오죽하면 어느 서버 호스팅 업체에서 클라우드를 대차게 까고 정답은 서버호스팅이니 우리 서버호스팅 이용해달라는 병신마케팅하는 업체가 있을 지경이다.
하아… 시발 똥꾸멍에서 손이 나와 그 손으로 타자 치고 쓴 글같은 느낌이 물씬 풍긴다.

반드시 클라우드만이 정답은 아니다.

물론 클라우드가 모든 걸 해결해 주는 게 결론은 절대 아니다.
기존에 운영하던 걸 모두 클라우드로 옮기겠다고? 아까 서버호스팅 영업하는 병신보다 더 병신 납셨네.
내가 아까 대학교의 클라우드 도입 사례를 나열해줬다. 그렇다. 필요할 때 쓰라는 것이다.
안정적으로 운영하여 모든 업무의 성공율을 높이는 것은 이렇게 유연한 운영 대책이 절실하다는 것이다.
근데 한국에는 스타트업 빼면 그딴거 없다. 모 아니면 도다.
이러니 대민 서비스가 개판인 것이다.

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

composite / 2016년 1월 20일 / 미분류 / 0 Comments

민원24 출력꼼수 정리

경고

이 방법은 편법적이고 우회적인 방법으로 비보안 상태로 처리하기 때문에,
민원24는 이 방법으로 파일 출력한 내용에 대한 보증이 불가능할 수 있으며,
원본 파일 유출로 인한 위조 및 불법 행위에 대한 책임을 본인이 질 수 있다.
필자는 소개한 내용을 모방하여 발생한 모든 책임을 지지 않으며, 본인에게 있다.

출력꼼수 시작.

프린터가 없을 경우

  • HP LaserJet 5200 PostScript 드라이버를 다운로드 후 설치. (관리자 권한 필요)
    • PCL5 및 PCL6 이 아닌 반드시 PostScript 드라이버를 설치
    • 일반모드를 선택한 뒤 다음 버튼 클릭
    • 로컬 프린터 추가(L) 클릭
    • 기존 포트 사용(U)에서 LPT1: (프린터 포트)를 선택한 뒤 다음 버튼 클릭
    • HP Universal Printing PS를 선택한 뒤 다음 버튼 클릭
    • 프린터 이름은 기본 값 그대로 사용. 다음 버튼 클릭
    • 프린터 공유는 공유 안 함을 선택한 뒤 다음 버튼 클릭
    • 설치 후 종료
  • whria 다운로드 및 관리자 권한 실행
    • 원래 프로그램은 RawPrintServer 인데 어느 한국 개발자가 변형한 듯 함.
    • 사용 가능한 포트번호는는 9100 및 910x 이며 오픈한 포트를 메모에 적은 후 서비스 등록 SUCCESS 확인.
  • PDF 드라이버 암거나 설치 (윈도우 10의 경우 기본 제공, 한컴PDF던 DoPDF던 PromoPDF던 상관없음. 프린터가 없을 경우 PDF 프린터를 기본 프린터로 설정.
  • 새 하드웨어 장치 추가 -> Microsoft Loopback Driver 설치 (이유: 민원24 인쇄 관리자가 127.0.0.1 막음)
    • IP는 192.168.x.x 이 아닌 (민원24에서 차단했다는 보고가 있음) 10.x.x.y 로 설정, 서브넷 마스크는 255.255.255.0, 게이트웨이는 10.x.x.1 로 10 과 1 을 제외한 x 부분을 동일하게 지정.
    • 명령 프롬프트에 ping 10.x.x.y 입력 후 엔터쳐서 ping <1 가는지 확인.
  • HP LaserJet 5200 PostScript 드라이버 속성 변경
    • 포트는 TCP/IP, IP는 방금 설정한 10.x.x.y 로 설정. 포트번호는 whria 에서 설정한 포트 설정.

프린터가 있으나 지원하지 않을 경우

공유 프린터를 통한 사용법은 여기 블로그 참조.
구글에 민원24 지원하지 않는 프린터 검색하면 어쩌면 해당되는 모델에 대한 방법을 찾을 수 있다.
또는 SPL을 이용한 방법 참고

SPL을 이용한 방법은 탐색기로 파일 찾는 귀차니즘만 제외하면 프린터가 있을 때 가장 추천하는 방법.
PDF 인쇄 여부는 확인 못해봤으나, 지원한다면 이 방법은 나쁘지 않음.

VMWARE 같은 가상에 사용할 경우

나처럼 액티브엑스로 컴퓨터를 더럽히고 싶지 않은 사용자나 맥 등의 타OS 사용자의 경우,
VMWARE 기준으로 아래 항목을 .vmx 파일에 편집기를 넣고 추가한다.
(원래 가상에서 프린터를 막고 있었으나 현재 정부 기반 가상 데스크탑 때문에 풀렸을 수도 있음. 아래 설정 전 확인 바람.)

isolation.tools.getPtrLocation.disable = "TRUE"
isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
monitor_control.disable_directexec = "TRUE"
monitor_control.disable_chksimd = "TRUE"
monitor_control.disable_ntreloc = "TRUE"
monitor_control.disable_selfmod = "TRUE"
monitor_control.disable_reloc = "TRUE"
monitor_control.disable_btinout = "TRUE"
monitor_control.disable_btmemspace = "TRUE"
monitor_control.disable_btpriv = "TRUE"
monitor_control.disable_btseg = "TRUE"

주의 : VMWARE에 대한 시그니처가 없어진 격리 모드로 실행하는 설정 파일이기 때문에 호스트 간 상호작용(3D 기능 및 프린터, 클립보드 공유 등)이 불가능하다.

Bootcamp는 실컴으로 취급하기 때문에 문제 없으나, 맥 OS에서 사용하는 대표 가상인 Parallels 의 경우 보고된 바가 없음. 해당 OS에 프린터 설치하면 문제없이 되는 듯 함.

composite / 2016년 1월 18일 / Dog's bullshit / 4 Comments

JetBrains 가 이젠 닷넷 IDE도 만든다!

어젯밤에 잠시 사색에 빠졌다.

ASP.NET 5가 이제 크로스 플랫폼일 테고…
핵심 코어인 .NET Core가 크로스 플랫폼이라면…
분명 JetBrains 에서는 이를 놓치지 않을 것이다…

그리고 다음날 내 예언(?)을 페북에 올리려 했는데…

http://i.imgur.com/6LABroy

http://i.imgur.com/3w4S7zG

그렇다. 진짜 JetBrain이 단단히 미쳤다.
그렇다면 블로그 원문 링크로 가도록 하겠다.

프로젝트 명은 Rider 이고 아직 정확한 제품명은 없다.

일단 특이한 점은 C#만 지원한다. VB나 F는 언급이 없었다. 근데 만들런지도 불투명 하니 신경 끄자.

Rider Search Everywhere popup

Rider editing

Rider new project templates

뭐… IDEA 제품 패턴이 어디 가겠는가? C# 에 Resharper 기능이 가미된 C# IDE라고 보면 된다고 한다.
게다가 크로스 플랫폼 지원한다니 말 다했지. 맥과 리눅스에도 돌아가는 IDE라면 매료될 것이다.

EAP(Early Access Program) 에 제한적 신청을 내주 오픈한다고 한다. 만약 실시간으로 받고 싶으면 @JetBrainsRider 트위터를 팔로우하면 된다.
라이선스야 뭐 IntelliJ 공통일 테고 Jetbrains Toolbox 에 포함된다고 한다. 이제 가격만 공개되면 된다.

그럼… 나는 이만.

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

무료 최상위 도메인

http://www.freenom.com/en/pricechart.html

TK $ 0.00 $ 0.00 $ 0.00
ML $ 0.00 $ 0.00 $ 0.00
GA $ 0.00 $ 0.00 $ 0.00
CF $ 0.00 $ 0.00 $ 0.00
GQ $ 0.00 $ 0.00 $ 0.00

참고: .tk 도메인은 무차별 광고/악성코드 사용으로 대부분 DNS 및 서비스 등에서 차단하므로 유의.
특징: 1~12 개월 단위 계약 시 무료, 1~10년 이상 계약시 유료.
주의: 무료 라이선스는 도메인 소유권을 주장할 권리가 없으며, 이로 인해 이전 등 소유권 관련 업무 처리 불가.

http://domainnamesales.com/domain/dotfree.com

.free 도메인이 곧 오픈되며 무료로 운영할 예정이라고는 함.

composite / 2016년 1월 11일 / 미분류 / 0 Comments

Javascript 파이프라인

어찌보면 나도 간과한 일일 수도 있다.
Javascript 로 열심히 삽질하다 보면 역시 콜백 늪에 안빠져본 자스 개발자는 없을 것이다.
이런 콜백 지옥을 빠져나가기 위해 여러 패턴이 도입되었고, 그 중 대표적인 게 Promise 패턴, Generator, 그리고 async/await 이다.

마침 Play.node() 라는 컨퍼런스가 이미 진행했었고, 공개된 발표자료 중 바로 한눈에 들어온 세션이 있었는데,
그게 바로 Session 3. Pipe: 콜백지옥의 또 다른 거짓 선지자 였다.

그리고 콜백 지옥을 빠져나갈 수 있다는 여러 선지자들, 그리고 세션 발표자가 이를 개선하기 위해 만든 또다른 선지자를 소개하는 시간이었다.
필자는 여기에 참여하지 못해 이 세션의 처음과 끝이 어땠는지는 잘 모르겠지만, 자스 개발자들은 뭔가 너무 차별화된 형식으로 접근하려는 시각이 눈에 띄었다.

그렇다. 너무 차별화되어 다르게 보일 수 있지만 결국 똑같은 패턴.

그게 바로 작업 흐름 관리이다. 영어로 Task flow management.
이를 관리하기 위해 보통 제공되어 사용하는 패턴이 바로 Pipeline pattern 이다.
작업 단위 간 통신을 위해 꼬리를 물고 무는 패턴.

자바스크립트는 싱글 쓰레드다. 그렇기 때문에 얻을 수 있는 이점이 있지만 이를 위해 잃은 많은 것들이 있다.
얻을 수 있는 이점이 바로 비동기 이다. 자스는 비동기에 능하다. 어떤 작업 흐름을 미꾸라지처럼 빠져 나가는 재주를 지녔다.

다른 언어에서도 이런 미꾸라지같이 작업 흐름을 마칠 수 있는 이점을 수용하려 하고 있었고, 이렇게 생겨난 것이
자바의 Future<T> 와 닷넷의 Task<T> 이다. 그리고 닷넷 4.5 에는 asyncawait 문법으로 비동기 작업 흐름 관리에 종지부를 찍을 것 같았다.
자스에서도 이런 종지부를 받아들여 ES7에 들어올 예정이긴 하지만… 언제 들어올지는 아직 모른다. 그렇기에 기대에 부응하지 못하고 오늘도 자스는 작업 흐름을 관리하고 있다.

동시성과 비동시성을 합쳐서 여러 케이스로 작업 흐름을 관리하는 업무는 의외로 많다.
하지만 많은 개발자들은 이를 동기적으로 처리하려고 한다. 왜냐, 그게 편하고 순서있고 보기도 편하기 때문에.

하지만 위 소개된 세션을 통해 이런 자스의 고충을 이해할 수밖에 없는 이유가 있다. 아니. 이해해야 할 수밖에 없다.
바로 자스는 아까 말했듯 싱글 스레드이다. 아까 말했듯이 자스는 어찌보면 너무 많은 것을 잃은 것만 같다.
쓰레드를 여러 개 사용할 수 있는 자바나 닷넷 등이 아니다 보니 쓰레드 단위로 Pipeline 을 갖는다는 것은 매우 어려운 일이다.
그래서 위 세션처럼 비동기 방식의 장점을 살려 바로 이벤트를 통해 작업 흐름을 관리하는 파이프라인을 구현한 것이다.
여기서 가장 핵심 공통점은 바로 작업 간 데이터를 주고받아야 한다. 그리고 이 때문에 구현한 것이다.
자스는 작업 흐름 관리를 위해 콜백 간에 데이터를 주고받아야 하는 일이 많다. 그렇다 보니 전통적인 방법으로는 콜백 지옥이 발생하는 것이다.

그렇다. 자스도 결국 파이프라인 패턴 써야 한다. 작업끼리 물고 물고 늘어진다. 이건 어느 언어나 업무 흐름에 피할 수 없는 숙명인 것이다.
자스는 작업을 관리하는 방식이 다를 뿐, 결국 작업은 파이프라인인 것이다. 어쩌면 동시에 해야 할 수 있고, 그리고 동시에 모두 끝나야 대기탔던 작업 해야 하고.

WE ARE THE HELLO WORLD.

참고자료

Play.node() 발표자료 http://d2.naver.com/news/2602887
자바 : 파이프 스트림과 쓰레드간 데이터 교환 http://javacan.tistory.com/entry/72
닷넷 : C# 쓰레드 이야기: 11. 이벤트(Event) http://www.hanbit.co.kr/network/view.html?bi_id=360

콜백지옥의 또 다른 거짓 선지자 관련 또다른 참고자료

Node.js Flow (part 1) – Callback Hell vs. Async vs. Highland http://blog.vullum.io/javascript-flow-callback-hell-vs-async-vs-highland/
Node.js Flow (part 2) – Fibers and Generators http://blog.vullum.io/nodejs-javascript-flow-fibers-generators/
yortus/asyncawait – Callback heaven for Node.js with async/await https://github.com/yortus/asyncawait

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

Markdown WYSIWYG Editor – woofmark

Markdown은 개발자가 문서작성 시 대단히 유용하다.
하지만 이는 개발자에게나 한정이지, 비개발자가 접근하기엔 여전히 장벽이 있긴 하다.
특히 워드 등으로 문서작성을 해온 사람에게 마크다운을 처음부터 접하라고 하기엔 무리가 있고,
꾸역꾸역 편집자나 기자 등이 마크다운을 배우고 있다고는 하지만 심층적으로 들어갈 수록 빡센 게 현실이다.

그래서 필자는 “그나마” 비개발자도 마크다운을 작성하면서 가장 가까이 접근할 수 있는 에디터를 찾았다.
그리고 찾았다. 이름은 woofmark. 직역하면 멍찍. 멍찍?

woofmark

UI/UX는 좀 디자이너가 보기엔 오그라들 것 같지만, 기능은 꽤 끝내준다.
굵게 등의 기본적인 글맵시 속성을 제공하며, 파일첨부같은 부가기능도 지원할 수 있도록 확장성을 제공한다.
그리고 마크다운이 할 수 있는 최대한의 역할일 해낸 듯 한 느낌을 줄 수 있다. (아직 표는 지원하기엔 껄끄럽긴 하다…)

개발자와 비개발자가 손쉽게 꾸밀 수 있는 점에서, 그리고 위지윅으로 마크다운에 가장 가깝게 꾸몄다는 점에서는 획기적이고 극찬을 주고 싶은 에디터이다.
하지만 아직 불편함이 숨어있고, 버그가 많이 산재해 있으며 (첨부파일 열기도), 개인이 운영하다 보니 버그 개선에 한계가 있는 모양이다.

아무래도 여기에 참여해서 뭔가 좀 해줘야 할 것 같다. 이렇게 꿀단지 같은 프레임웤을 그냥 둘 수는 없지.

어쩌면 이녀석보다 더 낫고 안정적인 에디터가 있다면… 말할 것도 없지.

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

[윈도우] 자주 쓰는 에디터 컨텍스트 메뉴 추가하기

맥은 내가 맥이 따로 없어서 추후 주위 사람을 통해 포스트 하도록 하겠다.

Sublime Text나 Atom… 많이들 쓸 거다. 무거워 터진 UltraEdit보다 더 저렴하고 효율적이기 때문에 필자도 애용하기도 한다.
안타깝게도 이들 에디터는 설치 시 편리하게 편집을 위한 컨텍스트 메뉴를 같이 설치하지 않는다. 아쉽다.
하지만 커뮤니티의 노력으로 매우 쉬운 컨텍스트 메뉴 추가를 위한 배치 스크립트를 만들었다.
당신은 설치 폴더에 배치 스크립트를 다운받은 뒤 실행만 하면 된다.

Sublime Text

https://gist.github.com/jcppkkk/8330314

Atom 내가 위에 거 Fork 해서 수정했다.

https://gist.github.com/composite/32c4ec768268762e431e

참고: Powershell 1.0 이상이 있어야 하기 때문에 윈도우 XP의 경우 Powershell을 따로 설치해야 하지만 윈도우 7부턴 기본내장이라 실행만 하면 된다.
사용법은 간단하다. OpenWith(에디터명)AsAdmin.bat 파일 다운받고, 에디터가 설치된 폴더에 넣은 다음, 관리자 권한으로 실행만 하면 된다.
실행하면, _elevate.cmd_elevate.vbs 파일, 그리고 컨텍스트 메뉴 제거를 위한 uninstall_OpenWith(에디터명)AsAdmin.bat 파일을 다운받게 된다.
위 2개는 당연히 편집 시 관리자 권한 상승을 위한 필수 파일들이기 때문에 두는 것이 좋다. 그렇다. 이놈의 특장점이 바로 관리자 권한으로 편집 기능이 있기 때문이다.

만약 당신이 자주 쓰는 다른 에디터(예:AcroEdit 등)가 있다면, 간단하게 에디터가 설치된 폴더에 OpenWith(에디터명)AsAdmin.bat 파일을 복사 후 내용을 편집해
에디터의 파일명과 에디터 이름을 수정하여 실행만 하면 된다. 아, 대신 귀찮겠지만 uninstall_OpenWith(에디터명)AsAdmin.bat 파일도 수정해야 한다.

이제 더이상 설명은 필요없다. 잘 써라. 끗.

composite / 2015년 12월 30일 / Piss Development / 0 Comments

Cloud IDE를 통해 우리가 얻을 수 있는 프로젝트 이점들

Eclipse. 국내 자바 개발자들의 국민 IDE 도구이다.
현재 릴리즈는 MARS 이며, 나온 지 얼마 안됐다. Luna 를 쓴지 얼마 안됐는데…
하지만 아직도 꽤 프로젝트들이 Indigo 및 심지어 Galileo 버전을 쓰기도 한다. ㄷㄷㄷ
그리고 어떤 이들은 디스크 오버헤드가 큰 개발환경에 질려 유료 IDE인 IntelliJ IDEA 를 통해 모던 웹 개발을 꾀하기도 했다.
게다가 구글은 자사 안드로이드 개발에 Eclipse 를 떠나보내고 IntelliJ 를 수용하여 많은 국내 안드개발자들의 공분(?)을 얻었다.

그런 말도 탈도 많은 Eclipse에서 며칠 전 Che 버전이 오픈됐다.
몇년 전부터 웹 기반 Eclipse 개발을 발표했고, 그리고 꾸준히 개발해왔다.
그리고 이제 “쓸 수 있는” 웹 기반 Eclipse IDE가 생겼고, 이 버전 코드명칭을 Che 로 칭했다.
근데 Che가 뭔지 아직 모르겠다. 좀 더 자료를 수집해야겠다.

어쨌든, 이녀석은 웹 기반의 IDE이다.
Atom같은 쉘을 통하여 자체 브라우저를 통해 응용 프로그램 행세하는 에디터는 아니고 그저 브라우저에 돌아가는 녀석이다.
이녀석은 서버로 운영되며, 서버 내 개발자들에게 같은 개발 환경을 제공한다.

그리고 또하나 흥미로운 기능이 있다면 바로 Workspace 서버이다.
이클립스는 Workspace를 잡고 여기에 설정을 관리하고 개발 환경을 만든다.
이런 Workspace가 이제는 서버에서 관리되어 개발자들의 용량 부담을 최소화 했다.

Eclipse Che

요렇게 생겼다. 뭔가 인텔리제이같이 생겼다고? 디자인만 그럴 뿐 순전히 Eclipse 환경이다.
그리고 이 같은 개발환경을 여러 개발자에게 워크스페이스와 같이 제공한다.

그렇다면, 이런 개발 환경에서 얻을 수 있는 개발 이점은 무엇이 있을까?
가장 많이 쓰이는 자바 개발 환경 기준으로 설명하겠다.

1. 개발환경을 매우 쉽게 세팅할 수 있다.

한국의 SI 스러운 개발환경. 솔직히 말해 A부터 Z까지 표준을 맞춘다는 건 마음에 안들고 너무 꽉막힌 생각이다.
한국의 개발환경은 그리고 A-Z 모두 맞춰줘야 한다. 심지어 경로까지… 워워…
아무렴 어떤가. 클라우드 개발환경은 개발자들의 쓸데없는 개발환경 세팅 시간을 줄여준다.
관리자가 그저 개발자 계정과 워크스페이스 권한만 주면 개발자는 브라우저를 통해 접속만 하면 개발환경 세팅 끝이다.
물론 DB의 경우는 얘기가 틀리겠지만 Tadpole DB Hub를 통해 개별 관리하거나 하면 시간은 더 줄어들겠지만 그럴 일은 없어보이고…

2. 익숙한 개발환경을 그저 클라우드로 즐길 뿐이다.

Eclipse Che 는 Eclipse 기반이다. 당연히 자바로 만들었고, 자바로 돌아간다. 자바 개발환경이 모범을 보여줘야지.
자바 개발자들에겐 당연히 Eclipse 는 친숙함 그 자체이다. 이 친숙함 그대로 클라우드로 즐기면 된다. 뭐가 문제인가?
개인 프로젝트 개발해야 하는데? 그러면 별도 IDE를 쓰면 되잖나. 개발환경 분리되는게 일상인 프리랜서가 뭔 걱정인가?

3. 보안과 통합이 매우 쉽다.

워크스페이스를 서버가 관리한다는 게 무슨 뜻이겠는가? 개발 소스를 자기들이 관리하겠다는 거 아닌가?
그렇게 되면 개발자들이 개별로 소스와 구조를 가질 필요가 없어지고, 그리고 이로 인한 소스 코드 유출 피해를 줄일 수 있지 않겠는가?
아직 소스 구조를 다운로드 받기 기능과 이에 대한 권한에 대해서는 확인이 필요하지만, 만약 있다면 개발 보안도 한층 업그레이드 될 것이다.
그리고 개발자가 이제 철수한다면 철수할 개발자에게 권한을 빼면 끝이다. 뭐 삭제
또한, 통합을 하고자 한다면 그저 관리자가 Eclipse Che 서버만 관리하면 된다. 모든 개발자가 다 적용된다.
물론 각 개발자별 플러그인이 필요할 것이고, 이를 관리자가 맞춰줄 수 있다. 그렇지 않다면 분명 불편할 개발자도 있을 테니.
SVN? Git? 다 된다. 버전 관리는 공통으로 한번 세팅하거나, 사용자별 세팅하면 땡이다. 그다음 지속적 배포 환경 고민을 하면 된다.

4. 개별적 개발상 이슈를 최소화할 수 잇다.

개발하다보면 예상치 못한 문제에 직면한다. 갑자기 개발자 컴퓨터가 맛이 가버리거나, 팅기거나 등등…
여태까지 작업한 것들이 날아가는 모습을 본 개발자에게는 허망함과 부담감이 가득할 것이다.
또한, 개발 환경이 반드시 100% 맞춤형이 아니다 보니, 어떤 컴퓨터에서 잘 안돌아가기도 한다.
그래서 어떤 프로젝트는 심지어 OS와 브라우저 등 아주 원초적인 환경까지 통일해야 하는 표준을 규정하여 개발시키기도 한다.
피곤하다.
웹 환경은 그딴거 없다. 웹만 되면 된다. 구버전 브라우저만 아니라면 개발할 수 있는 모든 게 다 된다.
Eclipse Che는 그렇게 만들어졌고, 그게 목표이기 때문이다.
웹 브라우저 외에 어느 환경도 구애받지 않는 개발 환경이라면 피곤할 필요도 없지 않겠는가?
게다가 관리자가 허락만 한다면 재택 근무도 가능하고. 물론 그럴 가능성을 염두해 둘 리는 없겠지만.

이제 개발환경도 새바람이 불고 있다.
여태까지 나온 임대 기반 개발환경이 싫다면 언제든 개발환경을 구축하여 제공할 수 있다.
서버 기반의 개발환경으로도 데스크탑 못지 않은 개발환경을 구축할 수 있는 시대도 도래했다.
이를 친숙한 Eclipse 에서 Che 버전을 통해 제공할 것이다.

이제 자바 개발자들에게 고민해야 할 것은 무엇인가?
바로 인식의 전환이다.
다른거 다 필요없다.

composite / 2015년 12월 28일 / Dog's bullshit / 6 Comments