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

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

[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

[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

Symbol 프로그래밍?

https://en.wikipedia.org/wiki/Symbol_(programming)

심볼. 굳이 우리말을 쓰자면 기호. 기호 개발. (뭔가 어색하다?)

오늘 페북에서 ECMAScript 6 표준에 Symbol이 정의되어 누군가가 MDN에 번역해 주었다.
Symbol – Javascript | MDN
심볼. 아마 자바, 닷넷, 자스 개발자 등에게 어찌보면 생소한 개념일 수 있다.
하지만 루비 개발자나 Object-C 개발자는 이미 있기 때문에 알고 있을 것이다.
이 심볼 개발방법은 여러 스크립트 언어 등에서 채택한 개발론이다.

간단하게 설명하자면, “가장 유일한 식별자”다.
뭐?
루비(Ruby)의 심볼이란?

정의는 한 번. 더 이상 변경할 수 없는 값이다.
여기까진 상수와 비슷한 개념이다.
그렇다면 값 비교 시 “A” 와 “A”가 같다? 심볼은 그딴거 없다.
그렇다. 심볼의 값은 일종의 사람만이 식별하기 위해 존재하는 값일 뿐.
문자열 값은 리터럴을 정의할 때마다 메모리가 늘어난다. 설령 변수를 지정하던 상수를 쓰던.
간단하게 생각해보자.
“A” “BC” “DEF”… 이들은 언제 바뀌지 못하기 때문에 불명확한 메모리를 할당받으며 서 있다.
당연히 그런 만큼 메모리를 잡아먹는다.
하지만 심볼은 딱 정해진 메모리만큼만 먹는다. 바뀔 일도 없기 때문에. 확장할 일도 없고.
그러니 메모리 애끼는 효과가 있다.

그렇다면 어따가 쓰냐고?
가장 쓰임새가 많이 쓰이는 곳이 바로 “해시 값”을 다루는 데에 쓰인다.

JS에 새로 정의된 Symbol을 통해 예제 하나 뿌리겠다.
ES6 Symbol Test 예제

var obj = {};
var a = Symbol("a")

obj[a] = "a";
obj[Symbol.for("b")] = "b";
obj["c"] = "c";
obj.d = "d";

for (var i in obj) {
   console.log(i); // logs "c" and "d"
}

console.log(obj[a]); //logs "a"

심볼 “a” 란 해시 키에 “a” 값을 넣었다.
근데… 반복문에는 나타나지 않는다.
그렇다. 주소 값이니 나오지 않을 수밖에.
대신에 명시적으로 해시 키를 정의하면 가져올 수 있다.
이런 이득이 있다는 것이다.
그렇다면 이런 특징으로 얻을 수 있는 이득이 뭐가 있을까?

간단하다. hidden 키와 값을 넣을 수 있는 그런 개발이라면 모두 가능하다.
일종의 private identifier 인 셈이다.

자. 이제. 자바와 닷넷도 이런 개념이 존재하냐고 물어보는 사람이 있을 것이다.
당연히 없다. 근데 자바와 닷넷은 문자열에 한해 인터닝(Intern) 이라는 개념이 있다.

자바의 String.intern() String.intern()은 메모리를 아낄 수 있다?

  • String pool에 있는 각종 문자열에 equals해서 같은게 있다면 그 놈을 반환하고,
  • 같은게 없다면 String pool에 String object를 추가하고, 추가한 놈을 반환한다.

즉, String 객체를 리터럴로 관리하여 메모리 절약을 꽤하는 개념이다.
그렇다 보니 아래와 같은 단점이 존재한다.

  • 우선 String 객체를 하나 만들어야 한다.
  • String의 equals 메소드를 이용해서 String pool에 있는 놈을 찾아서 비교해야 한다. ( 시간이 걸림 )
  • String pool에 들어 갔으므로, 더 이상 GC(가비지컬렉션)의 대상이 될 수 없다. ( 메모리 관리 불가 )

그렇기 때문에 적재적소에 잘 관리해야 한다는 점이 있다. 그래도 같은 문자열을 객체로 정의하여 메모리 쳐묵보단 낫다.

참고로 닷넷도 아주 동일한 개념이다. String.Intern() 메소드 쓰는 건 매한가지이며 동일하기 때문에 별도의 설명은 생략하겠다.

자. 자바와 닷넷이 문자열을 관리하는 방법이 여기서 나온다. 리터럴은 자바나 닷넷이나 내부 풀을 따로 운영하여 저장한다. GC에 걸리는 걱정 없이.
(물론 new String 처럼 객체로 만들었다면 걸릴 각오는 해야 하지만.)

뭔가 삼천포로 빠진 것 같다.
하지만 메모리를 아껴서 빠르고 유연한 개발을 꾀하는 개발자는 있다.
이럴 때 필요한 것이 뭐고, 뭘 알아야 하는지는 개발자의 사명인 것이다.
그러기 위해 이 포스트를 올렸다.
그럼 이제…

끗.

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

CloudFlare에 연동중인 자기 도메인에 DNSSEC 적용하기

보안에 민감한 웹 사이트 관리자에게 희소식.
클라우드플레어가 드디어 DNSSEC를 지원한다.
사실 내가 좀 뒤늦게 소식을 접하긴 했다. 지인이 알려줬더라.

DNSSEC가 왜 필요하냐고?

  • 자신이 설정한 서브도메인과 바인딩된 IP 및 데이터 등을 인증되지 않은 사용자로부터 숨겨준다.
  • 위 기능으로 인해 피싱 및 파밍 공격으로부터 도메인을 보호할 수 있다.
  • 위 효과로 인해 고객들에게 도메인에 대한 신뢰도를 높일 수 있다.

자세한 내용은 KRNIC – DNSSEC이란? 에서 확인하라.

뭐… 한국인에게 어찌보면 DNSSEC은 생소할 지도 모르겠다.
심지어 국내 대규모 네이버와 다음조차도 자기 도메인에 DNSSEC을 적용 안한거 보면 답이 나오니까.
이놈의 한국 종특 안전불감증이란 ㅉㅉ.

글을 보고 있는 여러분이라도 이런 허술한 짓 하지 않기 위해 클라우드플레어를 통한 DNSSEC 세팅법을 알려주겠다.
아, 기존 DNS 세팅은 유지되니까 걱정하지 말고. 물론 만약에 사태에 대비해 백업한다면 당신은 역시 완벽해.

자, 이제 본론으로 들어가자. 방법은 어렵지 않다.

DNSSEC Enable
(제공 : Cloudflare)

CloudFlare에 로그인 후, Dashboard 에서 DNS 탭을 누른 뒤 맨 아래에 DNSSEC 영역에서 Enable DNSSEC 버튼을 누른다.
그러면 Pending이 뜰 텐데, 이때부터 당신은 도메인 등록업체에 등록하기 위해 몇가지 정보를 챙겨가야 한다.
새로고침하면 DNSSEC 영역 아래에 DS Record 버튼이 생긴다. 그걸 누르면 아래와 같은 화면이 뜰 것이다.

DNSSEC 2

참고로 도메인 등록업체에 따라 요구되는 양식이 다르니 유의하기 바란다.
CloudFlare는 미국 등 유명 도메인 등록업체에서 등록하는 방법을 친절하게 설명해준다.
이 때, 중요한 사실은 DNSSEC 기능을 지원하지 않는 업체가 있다는 것이다. 만약 없다면 여기서 포기하라.
국내 업체는 국내에서 해결해야 하니.. 일단 해결해보자.

내가 닷네임 쓰고 있는데 DNSSEC은 지원 안하는 모양이다. 기능이 안보인다.
후이즈는 지원되는 듯 하다. ㅅㅂ…

하아… 내 일부 도메인을 넘겼기 때문에 일단 적용은 보류.
DNSSEC 지원하는 도메인 등록업체 발생하면 내용 추가 하겠다.

공통적 사항은 위 내가 마지막에 그린 그림과 같이 요구하는 양식만 채워주면 된다. 이름과 값 매칭하면 된다.
국내 업체라도 영어로 써주기 때문에 어렵지 않게 양식을 작성할 수 있다.
대부분 업체들은 그닥 많은 양식을 요구하지 않기 때문에 어렵지 않을 것이다.

미안. 끝이다.

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

ASP.NET 5 베타 요약

최신 순으로 요약하겠다. 새로운 베타 내역이 생길 경우 이 글이 업데이트 된다.
http://blogs.msdn.com/b/webdev/default.aspx?CR_CC=200674120

ASP.NET Beta 8

(2015-10-15)

  • IIS 호스팅 기능개선

이제 더이상 기존 AppPool이 없어도 윈도우 서버에서 구동 가능.
자체 호스팅을 원할 경우 app.config 지원
IIS는 여전히 web.config가 필요함. 아래와 같이 구성하면 됨.

<configuration>
  <system.webServer>
    <handlers>
      <add
        name="httpPlatformHandler"
        path="*"
        verb="*"
        modules="httpPlatformHandler"
        resourceType="Unspecified"/>
    </handlers>
    <httpPlatform
      processPath="%DNX_PATH%"
      arguments="%DNX_ARGS%"
      stdoutLogEnabled="false"
      startupTimeLimit="3600"/>
  </system.webServer>
</configuration>
  • 다국어 기능

이제 다국어 기능은 자체 지원으로 변경.
Startup.cs 에 midleware 추가
app.UseRequestLocalization(options)
서비스 추가
services.AddLocalization(options => options.ResourcesPath = "resources");
MVC와 함께 사용

services
    .AddMvc()
    .AddViewLocalization(options => options.ResourcesPath = "Resources");

컨트롤러별 다국어를 정의할 클래스 예제

private IHtmlLocalizer<HomeController> SR;

public HomeController(IHtmlLocalizer<HomeController> localizer)
{
    _localizer = localizer;
}

public ActionResult Index()
{
    ViewData.Message = SR["Localize me!"];
    return View();
}

뷰에서 다국어 정의 사용

@inject IViewLocalizer SR

<h1> @SR["Localized header"]</h1>

유효성 검사 오류 메시지를 위한 middleware 사용

services
    .AddMvc()
    .AddViewLocalization(options => options.ResourcesPath = "Resources")
    .AddDataAnnotationsLocalization();

이후 유효성 오류 메시지에 대한 다국어 기능 지원

  • DNX 감시 명령

DNX Watch 명령어는 프로젝트 파일의 변경 사항을 모니터링하여 변경 사항 발생 시 상황에 따라 서버를 재시작 하여 별도의 사용자의 터치 없이 바로 반영된 결과물을 볼 수 있는 편리한 개발 기능
설치법
dnu commands install Microsoft.Dnx.Watcher

이후 project.json이 있는 경로로 들어가서 dns-watch 실행하면 됨.

C:\Users\danroth27\Documents\WatchTest\src\WatchTest>dnx-watch web
[DnxWatcher] info: Running dnx with the following arguments: --project "C:\Users\daroth\Documents\WatchTest\src\WatchTest\project.json" web
[DnxWatcher] info: dnx process id: 8348
Hosting environment: Production
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

기본 About 페이지
before

코드 변경만 한 후,

public IActionResult About()
{
    ViewData["Message"] = "Watch this!";

    return View();
}

브라우저 새로고침만 하면 반영 결과를 볼 수 있음.
After

  • 프레임워크 버전 지정

게시할 때 프레임워크 버전을 명시적으로 지정 가능
dnu publish –framework dnx451
이를 통해 해당 버전에 맞는 필요한 프레임워크와 같이 패키징 후 게시됨.

  • 패키지 복구 시 HTTP 캐시 초기화

실행핼 때마다 캐시가 쌓이는 게 일상이기 때문에 패키지 복구 시 아래 명령어로 캐시 초기화가 가능
dnu clear-http-cache

  • **닷넷 버전을 2.0이나 3.5로 변경 가능

미친 기능… project.json 에서 targetFrameworknet20net35 으로 지정하면 됨.

  • 빌드 상황에 따른 전처리/후처리 지원

DEBUGRELEASE 등에서 각 상황에 맞는 전처리/후처리를 project.json 에서 정의 가능.
전/후처리 스크립트에 %build.Configuration%%build.TargetFramework% 변수 가용.

  • 추가 포함 파일 정의

project.json 에서 사용자가 지정 가능한 추가 파일을 지정할 수 있음 주로 프로젝트 외 경로 참조에 쓸 수 있음.

"packInclude": {
    "destination1/": "source1/**",
    "destination2/": "source2/**",
    "destination2/some_additional_file.txt": "source2a/somefile.txt",
    "destination3/": ["source3/a.txt", "source3/b.txt", "source4/c/**/*.ps1"]
}
  • 패키지나 프로젝트 버전 지정 가능

project.json에 클래스 라이브러리 버전 지정 예제

"dependencies": {
    "ClassLibrary1": { "version": "1.0.0-*", "target": "project" },
    "ClassLibrary2": { "version": "1.0.0-*", "target": "package" }
}
  • DNVM Uninstall

이제 DNX 확장 삭제 가능. 경로는 ~/.dnx/runtimes (사용자 폴더/.dnx/…)

  • Visual Studio 2015 도구 개선사항
    • 프로젝트/솔루션 내 파일 제외 기능을 이제 사용 가능.
    • Nuget package 복구 시 info 바 생성
      info bar
    • 상속 패키지 오류를 이제 package.json이나 솔루션 탐색기에서 볼 수 있음
      1
      2
      3
    • 패키지 상속 구조 개선
      4
      아이콘부터 각 패키지 및 클래스 라이브러리에 필요한 패키지나 라이브러리 구조를 볼 수 있음.

ASP.NET Beta 7

()

  • a

ASP.NET Beta 6

()

  • a

ASP.NET Beta 5

(2015-06-30)

  • DNX
    • Nuget 3.x 패키지 목록 나열 지원
    • DNX에서 포터블 닷넷 실행환경을 제시하고 빌드하는 새로운 닷넷 Target Framework Moniker (TFM) 지원
    • project.json에 Nuget 패키지 정보를 포함할 수 있음
    • JSON.NET 버전 고정 제거
    • 새로운 IRuntimeEnvironment
      즉, 신규 OS에 대한 실행 환경을 정의하는 인터페이스.
  • ASP.NET 5
    • HttpContextConnection 속성을 추가하여 추가적인 접속 정보 수집 가능
    • 다국어 추상 정의 예제
    • ASP.NET 호스팅 시 아무 키를 누르거나 통상적인 Ctrl+C 키로 서버를 종료할 수 있음
  • MVC 6
    • Razor 템플릿 엔진에 C# 6.0 표준 사용 가능
    • MVC 전역 설정 구성 및 단순화 (특히 전역 HTML Helpers)
    • JSON Helper 추가. 사용법 : @Json.Serialize(Model)
    • 라우팅 토큰 기본값을 간편하게 지원
  [Route("Products/[action]", Name = "[actions]Products")]
  public class ProductsController
  {
      public void Add() { }
      public void Buy() { }
  }
  • 이미지 태그 헬퍼에서 캐싱 기능 추가
<img asp-file-version="true" src="~/images/my_cool_image.png" />
  • 태그 헬퍼에서 Dictionary 속성 바인딩 지원
<a asp-action="Edit" asp-route-id="@index">Edit</a>
  • 서버 개발 상황에 맞는 태그 헬퍼 바인딩 지원

여기까지.
베타 5부터 기재하는 이유는 ASP.NET 개발 블로그에서 개별로 집필하는 부분이 Beta 5부터이기 때문이며,
이때부터 크로스 플랫폼에 초점을 맞추기 시작했기 때문이다.

composite / 2015년 10월 16일 / Piss Development / 0 Comments

DB 엔진 순위

왜 쓰냐고? 즐찾을 가장한 순위 소개다!

  1. 오라클 – 입아프고 손아픈 독보적 1위 관계형 DB 솔루션.
  2. MySQL – 오픈소스였는데 오라클이 먹고나서 오픈소스가 맞는지 모르겠지만 어쨌든 오픈소스 1인자인 관계형 DB 솔루션
  3. MS SQL Server – 여러분, 왜 게임회사에서는 동시성 분산 트랜잭션에 오라클을 안쓰고 이 MSSQL 쓰는지 아시는분?
  4. MongoDB – 문서기반 NoSQL 1위. 모든 NoSQL 1위를 달리신다. 그만큼 문서기반의 비즈니스 앱이 많아 정체성을 찾았다는 증거이기도.
  5. PostgreSQL – 오픈소스 SQL 중에 이녀석은 써본 사람이 안다. 오라클 저리가라 할 정도의 분산능력과 트랜잭션 능력은 이놈의 코끼리 로고가 증명한다.
  6. DB2 – 깊은 역사를 자랑하는 비즈니스 시장의 독보적이었던 IBM의 관계형 DB.
  7. Microsoft Access – 시발 오피스 쓰는새끼들 왜케많아…
  8. Cassandra – Wide-column store. 대략적으로 테이블 같은 개념이다. 근데 관계형은 아님. 어쨌든 오픈소스 NoSQL의 2인자이다.
  9. SQLite – 이거 안쓴 응용 프로그램이 있을까? 심지어 모바일에서도. 가볍지. 빠르지…? 일단 임베디드 관계형 DB의 여전한 1인자
  10. Redis – 이걸로 캐시 구성해본 비즈니스 앱이라면 안다. 뒤질듯한 속도감과 씨잘대기 없는 데이터 관리에 효율적이라는 사실을. 키값 NoSQL 시장 1위.

http://db-engines.com/en/ranking

composite / 2015년 9월 22일 / Piss Development / 0 Comments