[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

ASP.NET 5 RC1 요약

Visual Studio 2015 (Update 1) 개선점

설치 방법 (공통, 윈도우 기준)

새 프로젝트로 ASP.NET 프로젝트를 선택하고 만들면, 아래 그림과 같이 Get ASP.NET 5 RC가 생긴다.

Before

클릭하면 설치된다고 한다.

(역자 주 : 댓글 보고에 따르면, 0x80091007 - The hash value is incorrect 이런 식의 메시지로 만약 설치가 안되는 사용자가 있다고 한다. 이 경우, 베타 버전의 DNVM 및 Visual Studio Tools 를 모두 제거한 다음 최신 ASP.NET 5 설치 방법 페이지에 가서 Download 라고 써있는 필요한 것들을 다시 받거나 Command line 방법으로 다시 설치하면 된다.)

설치 후, ASP.NET 5 Template에 3가지 템플릿이 뜨면 성공이다.

After

맥과 리눅스는 Command line tool로 설치하면 되며, 설치가 안될 경우 또한 지우고 다시 설치하면 된다.

Bootstrap Snippet

Visual Studio도 이제 IntelliJ IDEA 처럼 확장 추천 기능이 생긴 모양이다. 페이지를 만들어 bootstrap을 쓰게 된다면
아래 화면처럼 추천 확장하는 노란 탭이 뜨면서 클릭하면, Bootstrap snippets 확장을 설치할 수 있다.

Extenstion

그럼 도구 상자에 Bootstrap 도구가 생길 것이다.

Tools

New Bower Package Manager UI

여태까지는 제이쿼리 같은 자바스크립트 프레임웤 등을 Nuget으로 설치할 수 있었다. 근데 관리가 너무 비효율적이라 원성도 잦았다. 흐음.. 아무래도 자바진영의 WebJar도 좀 그럴텐데…
어쨌든, ASP.NET 5 프로젝트에서 아예 프론트엔드 패키지 관리를 Bower로 사용하기 시작했다.

Bower

오른쪽 마우스 클릭으로 백엔드는 기존처럼 Nuget, 프론트엔드를 Bower로 패키지 관리를 할 수 있게 된다.
크로스 플랫폼 및 다환경간 접근 차원에서는 괜찮은 정책이다.

UI

그것도 모자라 Visual Studio 에서는 프론트엔드 패키지에 대해서 이제는 Nuget으로 설치했다면 Bower로 설치하라고 안내까지 뜬다.

nuget

MVC 스캐폴딩

이제 ASP.NET 5 에서도 ASP.NET MVC 5 처럼 스캐폴딩 항목 추가 기능이 생겼다.

Scaffold

근데 필자는 ASP.NET MVC보다는 NancyFX를 더 많이 써온 터라 이 부분에 대해서는 지식이 부족한 점 양해 바란다.
이 기능으로 컨트롤러와 뷰 또는 API 컨트롤러를 한번에 생성 가능하다는 이점이 있다고 한다.

솔루션 탐색기 정리작업

Explorer

이제 project.json 같은 고급 설정 파일을 가렸다. 솔루션 탐색기에서 안보일 뿐 실제로는 당연히 존재한다. 프로젝트 관리를 용이하게 하기 위해서인 듯 하다.
그리고 hosting.ini 파일 대신 hosting.json 으로 교체했다. 내용은 hosting.ini와 비슷하며, 없어도 돌아가는데 지장 없다. 이 경우 자체 웹 서버 가동 시 포트는 5000번이 할당될 것이다.

프레임워크 및 런타임 개선사항

Static Void Main

콘솔 프로그램 실행하는 메인 메소드를 아래와 같이 바꿨다.

public static void Main(string[] args) => WebApplication.Run(args);

C# 6.0 문법으로. 대부분 할 게 없으니까. 물론 내용이 좀 들어가야 한다면 그땐 종전 방식대로 사용하면 되지만.

Cross-platform SQL Client

이제 MSSQL 클라이언트 라이브러리를 크로스 플랫폼으로 밟고 있다.
아직 여러 건의 레코드셋 기능을 지원하지 않는다는 단점이 있지만, 이는 곧 해결될 것이라고 한다.
이제 윈도우를 비롯해 맥과 리눅스까지 LocalDB가 지원된다는 것이다.

SQLClient

아직 베타이지만, 아래 연결 문자열을 등록하면 된다.

"ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=aspnet5-MyCoolWebsite;Trusted_Connection=True;MultipleActiveResultSets=false"

몇몇 플랫폼에서 System.Net.Security 패키지가 정상적으로 설치되지 않는 문제점이 있을 수 있다고 한다. 이 경우 명시적으로 System.Net.Security 패키지를 추가하면 해결은 가능하다.

Default webroot folder

베타 버전까지는 project.json 에서 명시적으로 webroot 폴더를 지정했고, 없으면 더이상 돌아갈 이유가 없었다.
하지만, 이제부터 굳이 지정을 안해도 기본값으로 프로젝트 내 webroot 폴더를 가리키도록 하였으며, 이 폴더 조차 없을 경우 프로젝트 폴더를 가리키되, 정적 파일로 제공하는 방식으로 바뀌었다.

Strong Named Framework Libraries

윈도우는 파일명에 대소문자 구분을 안하지만, 유닉스 기반은 대부분 파일명 등에 대소문자를 구분한다. 그래서 닷넷 환경에서 크로스 플랫폼을 위해서 대소문자를 구분할 수 있는 강력한 이름 정책이 당연히 필요했고, 이를 적용했다. 패키지 명도 당연히. 윈도우 GAC 내 어셈블리도 모조리 대소문자 구분하도록 강력한 이름으로 지정하도록 하며, 만약 커스텀 GAC이 있다면 강력한 이름으로 적용해야 한다.

새로운 .NET 플랫폼 표준 소개

새로운 크로스 플랫폼 닷넷 환경이 ASP.NET 5만 맞춰져 섭섭해 보였던 개발자들도 있을 것이다. 하지만 이미 뒤에서 닷넷 개발환경 표준을 만들고 적용하고 있다.
여태까지 닷넷 개발환경은 Visual Studio 기준에서 만들여졌다고 봐도 무방할 정도로 닷넷 개발 환경이 툴에 너무 의존적이었다.
오해입니다. 오해! 닷넷 개발환경 표준을 참고하라.
각 플랫폼 및 닷넷 버전별로 버전을 표시하고 이를 관리하는 표준을 지원하여, Visual Studio 뿐만 아니라 다른 텍스트 에디터나 IDE 등의 개발 환경에서도 닷넷 개발이 편리해지도록 꾀하고 있다.

이 표준은 ASP.NET 5 RTM이 나오면 그 때 확정이 된다고 한다.

현재 ASP.NET 5 프로젝트를 만들면 dotnet5.4 라는 프로파일이 정의되는데, 이는 .NET 4.6, .NET Core 5,Mono 에 호환되는 프로파일이라 보면 된다.

기타 변경사항

Github Issues를 통해 여태까지 바뀌거나 수정, 개선한 사항들을 확인할 수 있다.

(필자는 NancyFX를 써와 Glimplise를 안써와서 이 부분은 따로 다루고 여기서는 다루지 않는다.)

요약정리

이제 RC를 통해 닷넷에 대해 크로스 플랫폼 개발환경을 적용하며, MS에서 지원하는 정식 개발환경으로 거듭고 있다.

  • live.asp.net 에서 커뮤니티 질문과 업데이트 소식 등을 실시간 또는 이전에 방송했던 소식을 받아볼 수 있다. 라즈베리에 닷넷도 돌렸다.
  • get.asp.net 항상 최신을 유지하라. 안되는 환경 붙들어 매는것보단 낫다.
  • docs.asp.net 에서 ASP.NET 문서 작성에 누구나 참여할 수 있다. 당연히 번역도 가능하다. 페북에 어느분이 번역해주신다는데 당연 환영!

이제 거의 완료되었다. 내년 봄까지 긴 시간이 남았다고 하지만 금방 지나갈 것이다. 이제 당신이 더 다양해진 ASP.NET 환경으로 개발할 앱은 무엇이 있을까?

composite / 2015년 11월 19일 / 미분류 / 1 Comment

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