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

[JS] String.prototype.replace() 문자열 함수 대체를 허하노라!

제목은 좀 거창하겠지만 그냥 String.prototype.replace 메소드의 함수 사용법 정리다.

먼저 콜백 함수 구조는 아래와 같다.

function(match, p1, [p2... p9, offset, string){
    // insert your code here.
}

인자는 이렇게 알면 된다.

  • match: RegExp.prototype.match() 메소드 실행 후 나오는 배열의 첫자리[0]에서 정규식에 매치된 문자열 전체를 불러온다. 그걸 가져다 쓴다. ($0)
  • p1, p2... p9: 정규식의 그룹 매치 ($1 ~ $9) 인자이다. 그룹 매치는 최대 9개 불러올 수 있으며, 늘어날수록 두번째 기준 인자에서 늘어난다.
  • offset: 정규식이 매치된 원래 문자열 대비 위치이다. 예를 들어 abcd 에서 bcd 매치가 될 경우 offset 값은 1이 된다. 당연히 0부터 시작이다.
  • string: 정규식을 검색하기 위해 사용된 문자열 전체를 불러온다.

여기서 주의해야 할 점은 p1, p2... 인자인데, 이들 때문에 offset이 몇번째 인자인지를 가늠할 수 없다. 당신이 그룹 매치를 몇번 하냐에 따라 인자 위치가 달라지기 때문이다.

이제 거청하지도 않은 설명 끝났으니 예제를 통해 사용해보도록 하겠다.
간단한 템플릿 치환 예제이다.

var tmpl = '내 이름은 [[name]] 이며 나이는 [[age]] 이다.',
    binding = {name: '홍길동', age: 20},
    regex = /\[\[(\w+)\]\]/g,
    callback = function(match, name, offset, string){
        return binding[name] || '그딴거없다';
    };

console.log(tmpl.replace(regex, callback));
//결과: "내 이름은 홍길동 이며 나이는 20 이다."

간단하지 아니한가?

여담:

String.prototype.replace 메소드는 원체 느리다. 가장 빠른 방법이 일반 문자열 replace이다. 어자피 한번만 갈아 끼우기 때문에 빠를 수밖에 없다.
이는 문자열 대체냐 함수 대체나 상관없이 비슷한 성능을 내준다.
그러니 업무상 템플릿 엔진에 성능 신경쓸 시간에 걍 체념하고 이거 쓰거나 어떤 이가 만들어준 템플릿 엔진을 쓰자.

ECMAScript 6 의 새로운 문법인 템플릿 문자열이 있다. 사용법은 아래와 같다.

var binding = {name: '홍길동', age: 20},
    tmpl = `내 이름은 ${binding.name} 이며 나이는 ${binding.age} 이다.`;

console.log(tmpl);

PHP 쓰거나 .NET 4.6 쓴 사람에겐 익숙한 문법이긴 하지만 역따옴표(`)를 쓴다는 게 특이점이라 하겠다.
ES6 트랜스파일러인 Babel.js 는 위 문법을 쓰면 아래와 같이 변환한다.

'use strict';

var binding = { name: '홍길동', age: 20 },
    tmpl = '내 이름은 ' + binding.name + ' 이며 나이는 ' + binding.age + ' 이다.';

console.log(tmpl);

그렇다. 문자열 합치기(string concatenation)를 사용하여 간단하고 성능 좋게 해석했다.
아직은 이 기능이 네이티브로 들어간 모습은 못봤다. 그래서
트랜스파일링 시간과 표현 시간이 합쳐져서 아직까지 성능은 느리게 나온다.
직접 테스트하고 싶으면 http://jsperf.com/es6-string-literals-vs-string-concatenation 가면 된다.

그럼 이만.

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

CloudFlare가 이제 HTTP/2 를 지원하기 시작했다!

원문 보러가기

cloudflare

HTTP/2. 중구난방이었던 여러 HTTP 프로토콜을 하나로 통일하였습니다.
인터넷에 중요한 파트로 자리잡은 HTTP/2 를 CloudFlare 무료 및 유료 사용자 모두에게 제공됩니다.
CloudFlare CEO 메튜 프린스는 “Alexa 상위 수백만여개 사이트 중 75% 이상이 새로운 HTTP/2 기술을 접목하게 될 것이다.” 라 원문 필자에게 전했습니다.
“이제 1998년 구식 인터넷에 작별을 고할 시간이 됐습니다. 우린 정말 인터넷의 미래를 제공할 새로운 프로젝트를 지원하는 것에 대해 상당한 감격을 받았습니다.”
사실 HTTP/2 는 구글이 만든 HTTP 표준인 SPDY의 상당 기술을 접목하였습니다.
CloudFlare 는 이미 SPDY 프로토콜을 제공하고 있었죠.
어찌보면 프린스가 말하길, SPDY에서 HTTP/2 로 완벽히 제공하게 되면 인터넷이 다소 느려질 수 있다고 말합니다. 그런데도,
“몇몇 서비스 제공자들은 SPDY를 HTTP/2 로 대체할 준비가 됐다.”면서, “이제 문제는 얼마나 많은 인터넷 브라우저들이 SPDY 대신 HTTP/2를 제공할 것인가 이다.” 라고 하는군요.
그렇다면 기존 HTTP 1.1 에 비해 HTTP/2는 얼마나 빠를까요?
CloudFlare는 처음에는 다소 느릴 지 몰라도, 매번 똑같은 페이지 및 리소스를 불러올 때 빛을 발한다고 말합니다.
꼭 SPDY에 비해 HTTP/2 가 드라마틱한 결과를 초래한다고 말하기는 어렵긴 하죠.
아직은 Business 및 Enterprise 고객은 바로 적용하지 않는다고 합니다. 물론 안정성을 위해서겠죠? 단, 옵션으로 킬 수는 있죠.
하지만 내년이 되면 대부분의 고객이 새로운 HTTP 규격이 자리잡기를 기대하고 있습니다.

composite / 2015년 12월 4일 / Waldo Translation / 0 Comments

Cloudflare 로 호스팅하는 웹 사이트의 진짜 IP 뽀려내기 외전

이전 글 에서 첨언하고자 글을 쓴다.
이글 쓴지.. 1년 넘었구나. 내가 왜 이걸 비공개로 닫았지? 그래서 오픈했다. 어자피 알 놈은 아니까.

요즘 들어 몇몇 한국의 불법 서비스 뽀사불라고 하는데 하필 Cloudflare 로 보호하고 있어
아 시발 저새끼 존나 조져주고 싶은데 거대한 방화벽에 막혀 좆같은 표정이나 짓고 있을 모습이 구글링을 통해 눈에 선하다.

그런 사이트야 나는 알지만 일일이 소개하기엔 귀찮다.

어쨌든, 내가 전에 소개했던 Crimeflare는 아예 도메인을 하나 만들고 운영하고 있다는 건 알고 있을 것이다.
http://www.crimeflare.com/

예전 도메인은 망했으니 넘어가고, 의외로 많은 수의 금액이 기부되어 있다.
내 지인 도메인도 마침 CloudFlare 길래 검색해봤고 내 도메인도 검색해 봤는데…
일단 내 도메인 기준으로 보여주겠다.

CloudFlare search results

그렇다. 마침 Crimeflare가 진짜 IP를 뽀려낸 듯 한데…
어떡하냐.. 그 IP 는 Github IP인데 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

뭐.. 이렇다.

다음은 Cloudflare Resolver라는 사이트다.
https://exonapps.nl/cfresolver/index.php

이녀석은 도메인 넣고 검색하면 CloudFlare 에서 사용할 법한 NS 이름에 대한 레코드에 연결된 IP를 검색한 뒤 사용자에게 보여준다.
만약 CloudFlare 서비스를 대충 쓰고 있다면, 이 서비스를 통해 진짜 IP가 드러날 수 있다.
그러므로 이 서비스에 나온 서브도메인은 보안을 위한다면 “절대” 쓰지 않는 것이 현명하다고 할 수 있다.

그리고 마지막으로, 요즘 클라우드가 대세다 보니, AWS 등 여러 클라우드 호스팅 서비스를 이용할 것이다.
국내 클라우드 서비스는 개 쓰레기인 건 초보 개발자도 아는데 뭐.

이 서비스를 통해 호스팅을 한다면 Crimeflare나 Cloudflare resolver 는 진짜 IP를 뽀려냈다고 착각할 수는 있다.
하지만 해당 클라우드 업체의 약관을 위반하지 않는 이상, 개소리는 이제 마음 속에 담아두도록 하자.

그러면 왜 이렇게 IP 숨겨서 호스팅 하는게 유행이 된 건가?
당연하다. 보안이다. 해커가 자기 IP 알아내서 해킹 시도하면 기분이 좋겠는가?
물론 ISIS 같은 개좆같은 테러들에게 제공하는 건 정말 나쁜 짓은 분명하다.
근데… 수많은 고객들 중에 ISIS 걸러낼 자신 있으면 해봐.
게다가 Onion 이라는 그리드형 프로토콜도 있고… 여러 보안 네트워크를 이제 당연하게 쓰는 시대다.

일반인이 뽀려낼 수 있는 건 한계가 있다. 포기하라.
게다가 안좋은 사이트라면 방통위 차단 걸면 땡인거고 (URL 필터링 기반이라 문제라면 문제겠지만)
자신에게 위해를 가하는 사이트라면 경찰에 경위서 쓰고 넘기면 나머진 알아서 해결해준다.

결론이 뭐냐고? 뽀려내는 건 포기하자. 멍청이가 운영하지 않는 이상 너 원하는대로 못조진다. 끗.

composite / 2015년 12월 1일 / Dog's bullshit / 2 Comments

composite / 2015년 11월 30일 / 미분류 / 0 Comments

잠긴 글: IntelliJ IDEA 2017.1

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

composite / 2015년 11월 30일 / 미분류 / 0 Comments

드디어 모습을 드러낸 새로운 7-Zip 안정화 버전

예전에 가지고 있던 노트북이 뇌사상태에 빠져 어쩔 수 없이 새 노트북 사고 윈도우 깔고
반디집 쓸까 7zip 쓸까 고민하다가 7zip에서 드디어 새 버전이 나와 내 눈을 자극했다.
2015년 11월 19일 릴리즈. 9.20 이래로 5년만이다.
오랜만이다. 깔아줘야지.

7-zip 공식 사이트에서는 그저 stable 이라고만 changelog 남긴 걸로는 정리가 안되어
이 사이트에서 새로워진 점을 가져왔다.

  • 이제 7z 압축 시 멀티 코어를 재대로 지원한다.
  • 7zip 프로그램에서 ext2,3,4 이미지 및 VMDK 이미지, LZMS 압축 방식의 WIM 이미지, UEFI 바이오스 파일, winzip(zipx) 압축파일, RAR5 파일 압축 해제 가능
  • 실행 인자 추가. -bt 추가 시 압축에 걸린 시간 통계 표시, -rn 추가 시 압축파일명 변경 가능, -h 추가 시 해시 계산.
  • 윈도우 7 이상의 작업표시줄 진행상황을 볼 수 있다.
  • 파일 관리자에서 move to archives 옵션 추가
  • 큰 파일이나 폴더를 열 때에 대한 성능 향상
  • 파일 경로 글자 개수가 260 이상인 파일 및 폴더 지원

이제 7zip 압축 시 불편했던 큰 짐은 덜어진 셈이다.
반디집의 경우 필자가 직접 공식 게시판에 질문을 했더니, 현재 버전인 5.x는 안정화 단계이니 어렵고, 차기 버전인 6.x부터 지원한다고 한다.
외국인도 의외로 반디집을 꽤 쓴다.

그리고 이제 내 새 노트북의 기본 압축 프로그램은 7zip 이다.

composite / 2015년 11월 26일 / Dog's bullshit / 0 Comments

[C#] Assembly Attribute

자바 어노테이션에 없는 아주 강력한 기능이 있는데, 닷넷에 있는 어셈블리 단위 특성 기능이다.
닷넷 개발자가 어셈블리 특성을 자주 만지는 경우가 바로 프로그램 정보에 쓰이는 아래 코드다.

[assembly: AssemblyTitle("HelloWorldProgram")]
[assembly: AssemblyDescription("The Hello World Program")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("My company")]
//...

사실 이들 특성은 프로젝트/Properties/AssemplyInfo.cs 에 있는데, 프로젝트 속성으로 손쉽게 수정할 수 있다.
나도 사실 아무렇지도 않게 봤지만, 이제서야 이녀석의 진면모를 알게 되었다.
어셈블리 단위의 특성이 왜 위력적인지 예제를 통해 알아본다.

어셈블리 단위 특성은 아래와 같은 용도로 사용할 수 있다.

  • 프로그램의 플러그인
  • 프레임워크 확장

그렇다. 주로 확장 편의성에 유용한 기능이다.

그렇다면 나만의 커스텀 어셈블리 특성을 만들고 적용할 수 있을까?
당연하다.

2개의 프로젝트를 만들어보자. 하나는 콘솔 응용 프로그램, 하나는 클래스 라이브러리.

먼저 응용 프로그램에 특성을 정의해 보자.

[AttributeUsage(AttributeTargets.Assembly)]
public class MyCustomAttribute : Attribute {
    public MyCustomAttribute() : this(string.Empty) {}
    public MyCustomAttribute(string txt) { Mytext = txt; }
    public string Mytext { get; private set; }
}

그다음 클래스 라이브러리에 아무 CS 파일에 넣어 클래스 및 네임스페이스 바깥 아무 곳에나 아래 특성을 추가한다.
물론 그 클래스 라이브러리는 응용 프로그램 프로젝트를 참조해야 겠지.

[assembly: MyCustom("Hello World!")]

어셈블리 단위 특성이기 때문에 아무 곳에나 특성을 추가할 수 있으나, 반드시 앞에 assembly: 넣어야 에셈블리 특성이 적용된다.

다시 응용 프로그램으로 돌아가서, 타 라이브러리에 접근하여 특성에 접근해 보자.

public static void Main(string[] args)
{
    Assembly asembly = Assembly.LoadFrom("어셈블리경로");
    var attributes = assembly
    .GetCustomAttributes(typeof(MyCustomAttribute), false)
    .Cast<MyCustomAttribute>().select(my => {
        Console.WriteLine("타 어셈블리 특성 : {0}", my.Mytext);
        return my;
    });
}

끗. 별거없다. 테스트는 안해봤다. 조만간 테스트 후 업데이트 하겠다.
예제만 별거 아닌것처럼 보이지만, 플러그인 베이스 개발에는 이만한 메타데이터 저장소가 없다.
많이 쓸 일은 없다. 그건 현실이다. 하지만 아는만큼 힘이 될 것이다. 특히 확장성에.

진짜 끗.

composite / 2015년 11월 24일 / Piss Development / 0 Comments