ha-ah

로그, 게으른 로그

세상물정의 물리학

6월 말에 개발과 관련없는 책을 읽어보려고 집어왔던 책.
올해 8월 제천 영화제에 들고가서 조금 읽고 왔던 책.

그 당시 감상으로 ‘좌파 교수(좋은 의미로)가 쓴 책’ 정도로 이야기 했지만,
그건 정말 초반에 (의도는 좋지만 = 선하지만) 재미가 없어서 했던 말이었다.

이번에 날씨가 너무 좋아 점심시간에 책보러 카페로, 작은 공원(?)으로 다니며 읽었는데, 이번엔 또 너무 재미있는 거다.

책은 세 챕터로 나뉘는데,

  1. ‘지금 여기’를 말하는 사회물리학의 세계
  2. 복잡한 세상을 꿰뚫어 보는 통계물리학의 아름다움
  3. 물리학자는 세상물정을 모른다고?

두번째 챕터부터 신나게 읽었던 것 같다.

작은 호기심을 증명해내고야 마는 집념.
이전에 읽었던 책 ‘아이의 사생활’에 비해 근거로 충만하고 같이 실험했던 사람들의 이름도 꼬박꼬박 넣어주는 친절함.
은근 코드가 맞는 개그감.
최대한 이해하기 쉽게 설명하는 물리 개념.
그리고 과학자로서의 열정과 자부심을 드러내는 지점에선 일부 공감과 반성을 하곤 했었다.

글을 굉장히 잘 쓰신다.
요즘 나는 기술책만 너무 많이 보다 눈높이가 꽤 낮아진 관계로…
문학을 즐기는 분들이 보기엔 어떨지 모르겠다.
하지만 (과연 이게 칭찬이 될 지는 모르겠지만) 이공계 중에선 수준급이다!

Update: ‘모호한 앰퍼샌드‘ 원작자에게 허락을 구해 해당 글의 번역본을 추가함.


개발하면서 누구나 한번쯤은 궁금해하지만, 아무도 정확히 알려주지 않는 모호한 앰퍼샌드에 대해 얕게 한번 파보았습니다.

현상

공고 관리자 페이지에서 reg_mem_type이라는 변수를 검색할 수 있는 옵션을 추가했더니, 페이징 영역을 클릭하면 계속 오류가 발생했다.

®이라는 특수문자가 전송되는 것을 보고 페이징쪽 소스를 보니

소스보기로는 이상이 없어보이나 개발자도구로는 ®가 찍히는 것을 확인.

원인

일부 html entity는 세미콜론이 없어도 전환이 가능하다는 것을 알게 됐다.

예를 들어,

<a href="test?test=test&reg=aa&region=bb&reg_ion=cc">
test?test=test&reg=aa&region=bb&reg_ion=cc
</a>

와 같은 태그는 화면에는

test?test=test®=aa®ion=bb®_ion=cc

처럼 보이고, 개발자 도구에서 보면

test?test=test&reg=aa&region=bb®_ion=cc

처럼 보인다.

이는 화면에 보여줄 때는 &reg가 세미콜론이 없어도 마크로 변환해줄 수 있기 때문이며,

이게 attribute의 값으로 들어갈 때는 변환이 되지 않는다.

다만, &reg_ion 처럼 &reg 다음에 특수문자나 공백 등이 올 경우, 이는 ®마크로 변환이 된다.

세미콜론 없어도 변환해주는 경우

세미콜론이 없어도 마크로 변환해주는 경우가 어디에 정의되어 있는지를 잘 모르겠다.

이런 현상에 관한 질문을 좀 찾아봤다.

https://stackoverflow.com/questions/15532252/why-is-reg-being-rendered-as-without-the-bounding-semicolon

여기서는 named-character-references를 예로 들며, 세미콜론이 없어도 되는 문자 참조를 아래와 같이 정의한다.

AElig, AMP, Aacute, Acirc, Agrave, Aring, Atilde, Auml, COPY, Ccedil, ETH, Eacute, Ecirc, Egrave, Euml, GT, Iacute, Icirc, Igrave, Iuml, LT, Ntilde, Oacute, Ocirc, Ograve, Oslash, Otilde, Ouml, QUOT, REG, THORN, Uacute, Ucirc, Ugrave, Uuml, Yacute, aacute, acirc, acute, aelig, agrave, amp, aring, atilde, auml, brvbar, ccedil, cedil, cent, copy, curren, deg, divide, eacute, ecirc, egrave, eth, euml, frac12, frac14, frac34, gt, iacute, icirc, iexcl, igrave, iquest, iuml, laquo, lt, macr, micro, middot, nbsp, not, ntilde, oacute, ocirc, ograve, ordf, ordm, oslash, otilde, ouml, para, plusmn, pound, quot, raquo, reg, sect, shy, sup1, sup2, sup3, szlig, thorn, times, uacute, ucirc, ugrave, uml, uuml, yacute, yen, yuml

그런데 위에 언급한 named-character-references에서의 리스트와는 꽤 다르다.

예를 들어, 이 references에서 정의된 ycirc는 &ycirc_라고 해도 attribute에서 변환되지 않는다.

아직 브라우저가 구현을 안 한 것인지, HTML4 버전 때 정의된 것 만 세미콜론으로 안 끝나도 되는지는 잘 모르겠다.

아직 정확한 근거를 못 찾았는데, 누가 좀 알려줬으면 좋겠다.

정 궁금하면 더 찾아봤을텐데, 정확한 리스트를 안다고 달라질 게 없기 때문에 해결책으로 넘어간다.

해결 in PHP

페이징 링크에 들어가는 부분

$queryString = ‘&’ . http_build_query($params, ‘’, ‘&’) ;

와 같은 소스를

$queryString = ‘&’ . http_build_query($params, ‘’, ‘&amp;’) ;

이와 같이 &만을 escape 처리함.

모호한 앰퍼샌드

아래는 이 현상을 제대로 이해하기 위해 모호한 앰퍼샌드에 관한 글을 번역한 것이다.

원문 : https://mathiasbynens.be/notes/ambiguous-ampersands

각 용어는 아래와 같이 번역함(clearboth에서 번역한 문서 참고해서 맞춤)

  • Ambiguous : 모호한
    • 모호한이라는 뜻으로 주로 쓰이는 것 같고, 여러 뜻으로 해석할 수 있는..이라는 의미도 될 수 있음
  • named character : 명명된 문자

Character references in HTML

HTML안에서의 문자 참조

Before explaining what ambiguous ampersands are, let’s talk about character references.

모호한 앰퍼샌드가 뭔지 설명하기 전에 문자 참조에 대해 이야기 해보자

There are different kinds of character references. The HTML 4.01 spec divides them in two groups, but really there are three:

문자 참조에는 여러가지 종류가 있다. HTML4.01 스펙에는 두 개의 그룹으로 나누었지만, 사실 세가지가 있다.

  • decimal numeric character references, e.g. &#169;
    • 정수 문자 참조
  • hexadecimal numeric character references, e.g. &#xA9;
    • 16진수 문자 참조
  • named character references, e.g. &copy;
    • 명명된 문자 참조

Character references should always start with a U+0026 AMPERSAND character (&) and end with a U+003B SEMICOLON character (;).

문자 참조는 &로 시작하고 ;로 끝나야 한다.

Fun fact: the list of named character references in the HTML spec includes &amp; and &AMP;, but also &amp and &AMP (without the trailing semicolon). The same goes for a few other entities. This is done for backwards-compatibility reasons. This way, the spec dictates that foo &amp bar should be rendered as “foo & bar”, even though it’s invalid markup (because of the missing trailing semicolon). More on this in a minute…

재밌는 사실은: HTML 스펙에서 명명된 문자 참조는 &amp;와 &AMP;를 포함하는데, 세미콜론(;)이 뒤에 붙지 않은 &amp와 &AMP도 있다는 것이다. 다른 일부 엔티티도 마찬가지이다. 이건 하위 호환성을 때문에 이렇게 됐다. 이 방식으로, (세미콜론이 빠져있으면) 유효하지 않은 마크업임에도 불구하고, 스펙에선 “foo &amp bar”를 “foo & bar”로 랜더할 수 있게 지시하고 있다. 조금 이따가 다시 다루겠다.

In this post, we’ll take a closer look at what happens if there’s an unencoded ampersand that’s not part of a character reference in your HTML code. Is it valid? Is it invalid? And what do “ambiguous ampersands” have to do with all this?

이 포스트에선, HTML안에 지정된 문자 참조의 일부가 아니면서 인코드도 안 된 앰퍼샌드가 있을 때 어떤 일이 벌어지는 지 좀 더 자세히 살펴볼 것이다. 그게 유효한 문법인가? 아니면 유효하지 않은가? 모호한 앰퍼샌드는 이 모든 것과 어떤 관계가 있는가?

Unencoded ampersands in HTML4

인코딩되지 않은 앰퍼샌드

The HTML 4.01 spec mentions this:

HTML 4.01 스펙에서 이를 언급하기를:

The URI that is constructed when a form is submitted may be used as an anchor-style link (e.g., the href attribute for the <a> element). Unfortunately, the use of the & character to separate form fields interacts with its use in SGML attribute values to delimit character entity references. For example, to use the URI http&colon;//host/?x=1&y=2 as a linking URI, it must be written as <a href=”http&colon;//host/?x=1&#38;y=2”> or <a href=”http&colon;//host/?x=1&amp;y=2”>.

Form 전송 시 만들어지는 URI는 anchor 스타일 링크(예를 들어 a 엘리먼트의 href attribute)를 사용하게 된다. 불행히도, 폼 필드를 구분지으려고 &를 사용하는 것은, 문자 엔티티 참조를 위한 SGML(역주: HTML, XML등의 부모뻘 되는 언어) attribute 안에서 사용하는 것과 상호작용을 하게된다. 예를 들어, 링크를 위한 http&colon;//host/?x=1&y=2 이라는 URI는, 반드시 <a href=”http&colon;//host/?x=1&#38;y=2”> 혹은 <a href=”http&colon;//host/?x=1&amp;y=2”> 으로 쓰여야 한다.

This means you can’t just copy-paste URLs into your HTML4 document if you want it to be valid — you’ll have to encode any ampersand characters first.

이 말은 당신이 HTML4 문서에 URL을 단순히 복사-붙여넣기를 해서만은 유효하진 않을 거라는 의미이다 - 앰퍼샌드를 인코딩 해야할 거다.

Ambiguous ampersands in HTML5

HTML5에서의 모호한 앰퍼샌드

In HTML5, the first definition for ambiguous ampersands was added:

HTML5에서 모호한 ampersand에 대한 정의가 처음으로 추가됐다.

An ambiguous ampersand is a U+0026 AMPERSAND (&) character that is not the last character in the file, that is not followed by a space character, that is not followed by a start tag that has not been omitted, and that is not followed by another U+0026 AMPERSAND (&) character.

모호한 앰퍼샌드는 파일의 마지막 문자가 아니며, 공백 문자가 뒤이어 나오지 않고, 생략되지 않은 시작 태그가 뒤에 오지 않고 다른 앰퍼샌드 문자가 뒤따르지 않는다.

Ambiguous ampersands are non-conforming (invalid); unambiguous ampersands are generally conforming (valid). (As mentioned before: ampersands that are part of a named character reference that doesn’t end with a semicolon are unambiguous, but still invalid.)

모호한 앰퍼샌드는 …(역주: 번역하기 어려워 생략)…(이전에 언급한 것처럼: 세미콜론으로 끝나지 않는 명명된 문자 참조의 일부로써 앰퍼샌드는 모호하진 않지만, 아직 유효하진 않다.

In other words, if an unencoded ampersand is followed by EOF, a space character, <, or &, it’s perfectly valid.

다시 말해, 인코드 안 된 앰퍼샌드 뒤로 EOF, 공백문자, <, &가 있다면 이건 완전히 유효하다.

According to this definition, the ampersands in this example are all ambiguous, and thus invalid:

이 정의에 의하면, 아래 예시에서 모든 앰퍼샌드는 모호하고, 그러므로 유효하지 않다.

<a href="https://example.com/?x=1&y=2";>foo</a>
&123
&abc
foo &0 bar
foo &lolwat bar

However, this is valid HTML:

그러나, 이건 또 유효한 HTML이다

foo & bar
foo&<i>bar</i>
foo&&& bar

Later the spec was changed, and the HTML spec now defines ambiguous ampersands as follows:

나중에 스펙은 수정되고 현재 HTML 스펙은 아래와 같이 정의되어 있다.

An ambiguous ampersand is a U+0026 AMPERSAND character (&) that is followed by one or more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER Z, and U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z, followed by a U+003B SEMICOLON character (;), where these characters do not match any of the names given in the named character references section.

모호한 앰퍼샌드는 하나 이상의 0~9 숫자, 대/소문자 라틴 문자와 세미콜론으로 이어지는 엠퍼샌드를 의미하고, 이 문자들은 명명된 문자 참조 영역에 있는 이름에 매칭되지 않는다.

This definition is probably easier to grok as a regular expression: a string contains an ambiguous ampersand if it matches /&([0-9a-zA-Z]+;)/ and if the first back-reference ($1) is not a known character reference.

이 정의는 아마 정규식으로 더 이해하기 쉬울 것 같다. 앰퍼샌드가 포함된 문자열이 /&([0-9a-zA-Z]+;)/ 에 매치되고, back-reference 된 값(역주: 정규식에서 괄호안에 매칭되는 값)이 알려진 문자 참조가 아니어야 한다.

The ampersands in this example are all ambiguous, and thus invalid:

아래 앰퍼샌드는 모두 모호하다. 따라서 유효한 문법이 아니다.

&123;
&abc;
foo &0; bar
foo &lolwat; bar

However, all these are unambiguous:

그러나 아래는 모두 명확하다.

foo & bar
foo&<i>bar</i>
foo&&& bar

…even the ones that were invalid as per the old definition, are now valid:

…예전의 정의로는 유효하진 않지만, 현재 유효한 것은:

<a href="http://example.com/?x=1&y=2";>foo</a>
&123
&abc
foo &0 bar
foo &lolwat bar

With the new definition, this is perfectly valid HTML — even though no HTML validator I know of recognizes this yet.

새로운 정의에 의해서는, 완벽하게 유효한 HTML이다 - HTML 유효성 검사기가 아직 이걸 모른다 하더라도 말이다.

So we’ve established that not all ampersand characters require escaping in HTML. Semi-related fun fact: In most cases, there’s no need to escape the > character either. It has no special meaning (and is thus unambiguous) unless it’s part of a tag or an unquoted attribute value. For example, <p>foo > bar</p> is perfectly valid and reliable HTML.

이제 우리는 HTML안에서 모든 앰퍼샌드가 escape 될 필요는 없다는 게 확실해졌다. 크게 관련은 없지만 재밌는 사실은: > 문자도 escape할 필요가 없다는 사실이다. 따옴표 없는 attribute값이나 태그의 일부가 아닌 이상 특수한 의미가 있지는 않다(모호하지 않음). 예를 들어, <p>foo > bar</p>는 완전히 유효하며 믿을만 한 HTML이다.

The pedantic nitty-gritty

학술적인 핵심

As mentioned before, some named character references work without a trailing semicolon (e.g. &amp) even though it’s invalid markup. What complicates things even more is that these entities are handled differently in attribute values.

말했지만, 일부 명명된 문자 참조는 세미콜론이 뒤에 붙지 않아도(그게 유효하지 않은 마크업 문법이라도) 동작한다. 이걸 더 복잡하게 만드는 건, 이 엔티티들이 attribute 값에서는 다르게 작동한다는 사실이다.

If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON character (;), and the next character is either a U+003D EQUALS SIGN character (=) or an alphanumeric ASCII character, then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND character (&) must be unconsumed, and nothing is returned. However, if this next character is in fact a U+003D EQUALS SIGN character (=), then this is a parse error, because some legacy user agents will misinterpret the markup in those cases.

만약 문자 참조가 attribute안에서 사용되고 세미콜론으로 끝나지 않으며 다음 글자가 =나 알파벳, 숫자일 경우, 관행적으로, & 이후 매칭되는 모든 문자들은 처리되지 않고 아무것도 리턴되지 않는다. 그러나 이 ‘다음 문자’가 =이라면, parse error가 발생하는데, 오래된 user agent가 오역할 수 있기 때문이다.

Take this (obviously invalid) HTML, for example:

예를 들어, 명백히 유효하지 않은 다음 HTML을 보라

<p title="foo&ampbar">
foo&ampbar
</p>

Try it out in your browser. You’ll see that the paragraph’s text content displays as “foo&bar”, while the titleattribute value is displayed as “foo&ampbar”.

네 브라우저에서 시도해봐라. 내용은 “foo&bar”라고 나오지만, title attribute 값은 foo&ampbar로 나올 것이다.

Mothereffing ambiguous ampersands

형편없는 모호한 앰퍼샌드

To summarize: there’s a difference between unencoded ampersands (sometimes valid), ambiguous ampersands (always invalid) and encoded ampersands (always valid). An unencoded ampersand is not always an ambiguous ampersand. An unambiguous ampersand can still be invalid.

요약하자면: 인코딩 안 된 앰퍼샌드(가끔 유효한), 모호한 앰퍼샌드(언제나 유효하지 않은), 그리고 인코딩된 앰퍼샌드(언제나 유효한) 사이에는 차이점이 있다. 인코딩이 안 된 앰퍼샌드가 항상 모호한 앰퍼샌드인 건 아니다. 모호하지 않은 앰퍼샌드도 여전히 유효하지 않을 수 있다.

In my opinion, this is all a bit confusing. But it doesn’t have to be! When in doubt, just encode your effin’ ampersands.

내 생각에, 이것들은 좀 헷갈린다. 하지만 그럴 필요는 없다! 의심스러우면, 망할 앰퍼샌드를 인코딩해라.

That said, if you want to find out if an HTML snippet contains any ambiguous ampersands or character references that don’t end with a semicolon (both of which are invalid), feel free to use mothereff.in/ampersands.

즉, HTML 스니펫에 모호한 앰퍼샌드나 세미콜론 (세미콜론으로 끝나지 않는 문자 참조)이 모두 포함되어 있는지 알아 보려면 (둘 다 유효하지 않음) mothereff.in/ampersands를 자유롭게 사용하기 바란다.

Ambiguous ampersand checker for HTML

Note that this is not a complete HTML validator; it will only look for ambiguous ampersands and semicolon-free character references. (Hopefully, bug #841 will be fixed soon, so we can just rely on validator.nu instead.)
Understanding what ambiguous ampersands are and how they work is especially important for library authors wishing to deal with HTML entities. Not accounting for these edge cases might result in XSS or other security vulnerabilities in your code.

아이의 자존감

책 자체가 잘 쓰였다고는 생각하지는 않다만,
부모로서 스스로 돌아보기에 괜찮은 기회일 수도 있다.

육아에 대해 큰 고민없이 살거나 고민은 많은데 부모 스스로 감정 조절이 안되거나 지금 내가 하는 게 맞나 싶은 사람이라면 도움이 될 수도 있겠다.

3장의 목차가 저 모양이라 마음엔 안 들지만
(오래 전 책이라 줄을 잘못 섰기도 섰거니와)

저 부분만 잘 넘어가면 이래저래 생각할 거리는 많다.
(3장은 낯 간지러워서 도저히 못 읽겠다!)

한문장 한문장 읽으면서 내 행동을 돌아보는 용도로 가볍게 읽고 넘어가면 좋을 것 같다.

읽다보면 이 자존감을 세우는 일은 아이에만 필요한 게 아니다. 내 주위 사람들, 지나간 동료들도 많이 생각이 났다.

저기 자존감이 높은 대표적인 인물로 꼽힌 안철수가 그…(?) 과정을 거치며 얼마나 자존감이 낮아졌는가, 그 아이가 얼마나 삐뚤어졌나 생각해보자.

아쉬운 건,
이런 저런 연구 결과나 박사 이름을 언급하지만,
행동 지침을 도출하게 된 직접적인 근거는 또 아니어서,
이렇게 해라 저렇게 해라 하는 게 진짜 근거가 있는지 아닌지 알게 뭐냐는…
시간 없는데 할 말이 많은 사람처럼 문장도 좀 산만한 것 같고.
잔소리 많은 아는 형님이 조금 취했다고 생각하자.

하지만 그 형님이 말하는 아이의 사생활도 한번 들어볼 생각.

나의 EIDF(EBS국제다큐영화제) 2017년 후기

개발 관련 RSS 피드를 받는 중에도 이렇게 후기를 올리신 분도 계신다.
제14회 EBS국제다큐영화제 The 14th EBS International Documentary Film Festival (EIDF 2017) 감상 트윗

이 분이 추천하신 게 《섀도 월드》, 《리처드 링클레이터: 꿈의 연대기》, 《라스트맨 인 알레포》, 《데이빗 보위: 지기 스타더스트 마지막 날들》 4가지였는데,

(뭐 이 분이 평론가는 아니지만) 운 좋게도 《섀도 월드》만 제외하고 다 볼 수 있었다.


다른 영화제보다 상영작이 적어서 그런지 리뷰도 달려있고 영화를 고르기 수월했다.

게다가 시놉시스와 영화 내용이 일치한다.
(영화제 예매를 위해 그 몇 줄짜리 영화 소개를 보신 분은 이해 하실 듯)

무료로 다시보기도 가능하니 참고하시길

이제 나만의 감상평.

우리 사랑 이야기 (The Grown Ups)

우리 사랑 이야기

40년째 다운증후군 환자를 위한 학교에 다니는 친구들은 학교가 지루하기만 하다. 어느새 50대에 가까워진 그들은 이제 독립한 성인으로 존중받을 자유를 원한다. 집을 사려 돈을 모으고, 사랑하는 연인과 미래를 약속하며, 직업을 찾기도 하지만, 가족들은 여전히 그들을 성인으로 인정해주지 않는다.

40대 다운증후군 환자들의 아기자기한 귀여운 일상을 보여주다가 독립을 하려고 노력하는 모습을 보여주고 주위 사람들의 반대를 접하는 지점까지는 예상 가능했지만,

영화 끝에서 보여주는 현실의 잔임함에는 혀를 내두르게 됐다. 내가 예민하게 바라본 것일 수도 있지만.

학교 내에서는 계속 독립할 수 있다고 희망을 주는데, 학교 밖에서 실제로 어떤 환경에 부딛히게 될 지 알려주지 않는다.

가족이 비싼 등록금을 대주지 않으면 냉정하게 떠나야 하는 학원같은 곳이었다.

학교에선 결혼을 할 수 있다고 용기를 주면서 반지는 반드시 다이아로 받으라고 타협하지 말라고 조언해주지만,

이들이 학교에서 벌어들이는 돈으로는 은반지 조차 살 수 없다.

영화 미 투의 경우는 좀 특별한 케이스라고는 하지만,

이 다큐의 아이같은 사람들이나 미 투의 그 똑똑한 사람이나 보편적인 삶을 누리기는 녹록치 않다.

임신을 하게 되면 기형아/다운증후군 검사를 하게 되는데, 그 때의 불쾌함이 떠올랐다.

(이에 대한 친절한 설명이 없었으므로) 그 땐 ‘아니 그럼 기형아라고 판명나면 죽이기라도 할꺼야?’라는 반발심이 있었는데, 이런 검사는 더 나은 결과를 만들기 위해 필요하다는 의견도 있다.

무력한 다운증후군 환자에 대한 다큐를 보며 먹먹했던 마음은 결국 어쨌든 딸램이 아무 불편함 없이 세상에 나와서 다행일 뿐이라는 간사한 감사함으로 수렴되고 말았다.

그들도 가족도 쉽지 않다.

라스트맨 인 알레포 (Last Men in Aleppo)

라스트맨 인 알레포

5년간 지속된 내전. 약 삼십오만 명만 남은 알레포 주민들은 언제 닥칠지 모르는 폭격에 대한 불안감 속에 살고 있다. 자원활동가로 이루어진 민간 구조대 ‘화이트 헬멧’은 붕괴 직전의 알레포 현장에서 싸우고 있다. 작은 생명들조차 폭격으로 사라져 가는 일상 속에서, 그들은 인류에 대한 회의와 더불어 자신의 선택에 대한 의문과도 싸우고 있다.

시리아 내전에 관한 이야기. 정말 이렇게 사람이 죽어나가는 게 말도 안된다는 생각이 끊이지 않는다.

영화 초반부 무너진 건물 잔해 사이에서 아이들을 구해내는 장면이 시각적으로 꽤나 인상적인데,

(죽은 아이 산 아이 반반이지만) 모두 출산 장면을 떠올리게 한다.

러시아 저 놈들은 또 왜 와서 민간인을 학살하는가 싶어서 도저히 상식적으로 이해가 안되서 영화를 보는 중간중간 시리아 내전에 대해 검색도 해봤다.

그러나 워낙 복잡한 양상이라 곧 이해하기를 포기.

그렇게 미친 듯이 활약하는 민간 구조대 주인공들은 결국 모두 사망한다.

아마 영화에 등장한 대부분이 사망했을 것 같다.

이 동네도 당장 답이 없다.

데이빗 보위: 지기 스타더스트 마지막 날들 (David Bowie: The Last Five Years)

데이빗 보위: 지기 스타더스트 마지막 날들

예측 불가능한 아티스트 데이빗 보위. 그의 작업은 늘 흥미로웠고 도전적이었으며 대중의 예상을 뛰어넘었다. 현대 대중음악 역사상 가장 위대한 아티스트 중 한 사람이었던 데이빗 보위의 마지막 5년을 다룬 이 다큐멘터리는, 관객들이 그를 만들어낸 ‘크리에이티브’ 전략을 엿볼 수 있게 한다.

처음부터 본 건 아니지만.

보는 내내 입 벌리고 대단하다고 밖에 생각할 수 밖에.

모 세미나에서 전길남 박사가 나와서 이야기 할 때의 그런 느낌과 비슷했는데,

그 나이에도 불구하고 전혀 사고가 막혀있지 않았구나 생각도 들고.

그렇다고 데이빗 보위의 음악을 즐기게 된 건 아니지만.

리처드 링클레이터: 꿈의 연대기 (Richard Linklater - Dream is Destiny)

리처드 링클레이터: 꿈의 연대기

할리우드 거대 자본의 영향권 밖인 텍사스 오스틴에서 등장하여, 독립영화 제작 방식을 치열하게 실천하려 분투한 어느 감독을 바라보는 독특한 시선. 희귀한 영상 자료와 언론, 링클레이터 본인과의 인터뷰, 영화 제작 메이킹 필름 등을 볼 수 있고, 매튜 맥커너히, 패트리샤 아퀘트, 에단 호크, 잭 블랙, 줄리 델피, 케빈 스미스 등 함께 작업한 배우들도 만날 수 있다.

이게 다 이 양반 영화였어?라는 놀라움의 연속이었다.

데이빗 보위처럼 타협 (거의) 없이 새롭게 도전하는 모습에서 둘이 좀 비슷한 느낌도 있었다.

영화를 익히는 초반에 기초를 충실히 닦는 모습도 인상적이었고,

역시 체력이 되는 애들은 집중력이 좋구나 싶기도(운동을 더 이상 못하게 되자 도서관에 짱 박힘).

스쿨 오브 락에서는 나름 상업 영화의 틀 안에 있었지만, 그 캐릭터에 자기 모습을 많이 녹여낸 것도 재미있었다.

씨앗: 우리가 몰랐던 이야기 (SEED: The Untold Story)

씨앗: 우리가 몰랐던 이야기

인류가 탄생한 직후부터 씨앗은 소중하게 다뤄야 할 가장 중요한 것이었다. 지난 세기 동안 우리가 가지고 있던 종자 품종의 94%가 사라졌다고 한다. 생명공학 기업이 종자와 농부, 과학자, 변호사들 그리고 토종 씨앗의 수호자들까지도 지배하게 되면서, 우리 식량의 미래를 지키기 위한 다윗과 골리앗의 싸움은 시작되었다.

대충 대충 구경했지만, 그 다양한 씨앗의 아름다움이 꽤나 인상깊었다.

씨앗을 통해서 우리가 얼마나 경제의 논리로 다양성을 멸종 시키는가를 다루는 처음 부분은 재미있었다.

종자를 지키기 위해 의외로 오랜 시간 많은 사람들이 노력하고 있었구나 생각도.

GMO를 다루는 후반은 조금 고개를 갸우뚱하게 만들었다.

GMO 곡물 자체의 유해성을 다뤘으면 좋았을 것 같은데,

이를 재배하는 글로벌 대기업의 횡포나 환경 파괴를 섞어서 논점이 좀 흐려진 것 같다.

그 사람들이 원하는 결과는 동일하겠지만 말이다.

오늘 라라벨 꾸준 코딩 모임에서 나왔던 이야기인데, 라라벨의 유효성 검사 규칙 중 alpha에 관해 써본다.

원문에서는 아래와 같이 정의하고 있다.

The field under validation must be entirely alphabetic characters.

이를 정수님이 옮기시면서 역주를 추가하셨는데,

필드의 값이 완벽하게 (숫자나 기호가 아닌) 알파벳[자음과 모음] 문자로 이루어져야 합니다.
(역자주: 영문 알파벳만을 의미하지 않고, 숫자나 기호가 아닌경우에 해당하여, 한글도 허용합니다.)

여기서 자음과 모음이 언급되었길래 그럼 자음과 모음이 없는 중국어는 어떻게 되냐고 여쭤보았고,
(중국어에 진짜 자음과 모음이 없는가에 대한 문제는 일단 넘어가자..)

유니코드의 구간을 정해놓고 validation 처리한 예전 소스를 보여주신 분도 계셨다. 한글을 구분하는 코드였던가?
(좀 더 복잡한 소스였지만) 예를 들어 이런 식.

아래는 persian alphabet을 골라내는 정규식이(란)다.
(출처 : anetwork)

public function Alpha($attribute, $value, $parameters, $validator)
{
ValidationMessages::setCustomMessages( $validator );
$this->status = (bool) preg_match("/^[\x{600}-\x{6FF}\x{200c}\x{064b}\x{064d}\x{064c}\x{064e}\x{064f}\x{0650}\x{0651}\s]+$/u", $value);
return $this->status ;
}

결국 다같이 라라벨 소스를 보게 되었다.
막상 코드를 열어보니 단순해서 놀랐는데, 코드는 아래와 같다.

/**
* Validate that an attribute contains only alphabetic characters.
*
* @param string $attribute
* @param mixed $value
* @return bool
*/
protected function validateAlpha($attribute, $value)
{
return is_string($value) && preg_match('/^[\pL\pM]+$/u', $value);
}

“아니, 저건 무슨 정규식이죠?!”라며 놀랐지만, 내가 뚫어져라 본다고 알 턱이 없었다.

그래서 좀 찾아보기로…

Alphabet

내가 처음에 혼란스러웠던 것은, 유효성 규칙에 대한 설명에서 ‘알파벳[자음과 모음]’이라는 문자에서 과연 자음과 모음이라는 게 중요한가..라는 의문 때문이었다.

한국어 위키디피아의 음소문자 설명부터 보자.

음소문자(音素文字, alphabet)는 하나하나의 문자가 원칙적으로 하나의 자음 또는 모음의 음소(音素)를 나타내는 문자 체계이다. 자음과 모음에 대응하는 각각의 문자가 따로 존재하는게 다른 종류의 문자와의 다른 점이다. 로마 문자, 한글, 키릴 문자, 그리스 문자 같은 것들이 음소 문자 중 하나다.

위키디피아 설명에는 sets of letters used in written languages라는 설명으로 시작해서,

"alphabet" is a script that represents both vowels and consonants as letters equally라는 표현도 나온다.

자음과 모음을 동일하게 하나의 글자로써 표현하는 것인가 본데…

라라벨 매뉴얼에서 alphabet을 ‘알파벳[자음과 모음]’이라고 표현하신 건 이제 이해가 됐다.

Unicode property

유니코드 표준에서는 각 code point마다 여러가지 속성을 부여하는데,

이를 Unicode character property라고 하고, 이를 통해 Letter인지, Mark인지, Number인지 알 수 있다.

라라벨의 alpha가 정의하는 유효성 확인 정규식을 다시 보자.

/^[\pL\pM]+$/u

\p를 통해 property를 부여할 수 있고, 대문자로 쓰면 반대의 개념이다.

\pL은 문자(Letter)를 가져오고, \PL은 문자가 아닌 것만 가져온다.

\pM은 Mark를 의미하는데, 어디까지가 이 Mark에 부합하는가..가 좀 복잡하다.

이 중에는 악센트와 같이 옆에 있는 문자를 꾸며주는 역할을 하는 것도 있다. 그러니까 문자(이쯤되니 문자라는 표현이 맞는지도 모르겠다)를 꾸며주는 역할을 하는 걸 의미하는 듯 하다

더 자세하고 친절한 설명은 역시 stackoverflow에 있다.

그럼 ™ <- 요렇게 생긴 트레이드 ‘마크’는?

http://www.fileformat.info/info/unicode/char/2122/index.htm

UnicodeBlock이 LETTERLIKE_SYMBOLS로 정의되어 있다. 그렇다. 이런 걸 심볼이라 부른다.


마지막으로 저 정규식에는 u라는 변경자가 붙어있는데,

u (PCRE_UTF8)

이 변경자는 펄과 호환되지 않는 PCRE의 추가 기능을 사용하게 합니다. 패턴 문자열을 UTF-8으로 취급합니다. 유닉스에서는 PHP 4.1.0부터, win32에서는 PHP 4.2.3부터 사용할 수 있습니다. PHP 4.3.5부터 패턴의 UTF-8 유효성이 검사됩니다.

라고 PHP 매뉴얼에 나와있다.

이번에 매뉴얼 좀 찾아보다 발견했는데, 아사마루(?)님의 블로그에 이 정규식 부분이 한글화 + 보충 설명되어 있다.

PHP 정규식(PCRE)의 모든 것

validation#rule-alpha

비슷한 문제로 2014년에 라라벨 Github에 이슈가 등록됐다.

validator rules shouldn’t allow unicode

Taylor Otwell은 We can document it. 한마디하고 닫아버린다.
(어쩌자는 말인 지 모르겠다.)

ASCII에 존재하는 라틴 알파벳 만을 매칭하려는 게 아니라면 정규식 자체에는 문제가 없어보이지만,

여전히 alpha라는 단어를 쓰는 게 맞는 지는 잘 모르겠다.

Letter에 매칭되는 문자가 모두 알파벳에 속하지 않을테니까.

Run

$arr = [
"x", "A", "3", "\n", ".", "\t", "\r", "\f",
"주", "$", "я", "张", "@", "ⓐ", "à",
"\u{0300}", /* COMBINING GRAVE ACCENT */
];
preg_match_all('/\pL/u', implode('', $arr), $matchesL);
preg_match_all('/\pM/u', implode('', $arr), $matchesM);

print_r($matchesL);
print_r($matchesM);

결과가 예상 되시나요?


Array
(
[0] => Array
(
[0] => x
[1] => A
[2] => 주
[3] => я
[4] => 张
[5] => à
)

)
Array
(
[0] => Array
(
[0] => ̀
)

)

한글만 골라내기

이렇게 유니코드에는 수많은 카테고리가 존재하고, 이 중에는 역시 한글을 표현하는 카테고리도 존재한다.

preg_match_all('/\p{Hangul}/u', implode('', $arr), $matchesHangul);

print_r($matchesHangul);

결과가 예상 되시나요?

추가

페이스북에서 받은 질문을 좀 더 상세히 찾아보려는데,

역시 유니코드 이 동네는 까면 깔수록 깔 게 많다.

우선 질문은 “항상 /[가-힣]+/u 을 사용했는데 틀린 건가요?”였는데,

그 전에 문맥/비즈니스 요구 사항에 관해 반문해야할 게 좀 많다.

그 기능에서

  • 자모를 모두 사용한 완성된 글자만 필요한가?
  • 자모를 개별적으로 입력할 수 있어야 하는가?
  • 한국어에서 쓰이지 않는 글자 조합을 표시해야 하는가?
  • 입력한 자음이나 모음이 한글인지 검색해야 하는가?

유니코드에서 한글이 존재하는 구간은 다음과 같다.

Hangul Jamo (U+1100 to U+11FF)
Hangul Compatibility Jamo (U+3130 to U+318F)
Hangul Jamo Extended-A (U+A960 to U+A97F)
Hangul Syllables (U+AC00 to U+D7AF)
Hangul Jamo Extended-B (U+D7B0 to U+D7FF)

이중 /가-힣/으로 걸러낼 수 있는 건 한글 소리 마디 (Hangul Syllables)인데,
한글 자모 각각을 구별하기 위해선 Hangul Jamo (U+1100 to U+11FF)까지 살펴봐야 한다.

/ㄱ-힣/이라고 쓰는 사람도 많은데, ㄱㄴㄷ..ㅜㅠㅡㅣ까지의 구간과 가나다…힡힢힣까지의 구간 사이에 한자 등 다른 문자가 많이 포함되어 있으므로 금지해야 한다.
/ㄱ-ㅣ가-힣/으로 써야 한다.

페북에서는 옛한글(언급은 안했지만 아래아 같은 걸 염두에 뒀었다)이 현대 한글의 코드 구간 뒤쪽이라고 얘길 했었는데,
아래아의 경우는 한글 자모에 속해있다. 이외에 쓰이지 않는 많은 진짜(?) 옛한글은 호환용 한글 자모나 자모 확장 등에서 발견된다.

결론

올바른 정규식을 얻기 위해선 뭉뚱그려 ‘한글 문자를 검사하는 기능’ 정도로 설명하지 말고, 정확한 요구사항을 명시하는 게 좋다.

자모를 사용한 완성된 글자만 필요한가?

  • /가-힣/

자모를 개별적으로 입력할 수 있어야 하는가?

  • /ㄱ-ㅣ가-힣/

한국어에서 쓰이지 않는 옛한글이나 글자 조합도 표시해야 하는가?

  • /\p{Hangul}/u

입력한 자음이나 모음이 한글인지 검색해야 하는가?

  • 자음이나 모음을 하나만 입력하고 이게 속해있는 지 검색하는 기능이라면, ‘한글 호환 자모’에 관해서도 알아놔야 한다.

한글을 입력할 때 완성된 글자가 아니라 자음이나 모음 하나만 단독으로 입력하는 경우, 그 음소는 유니코드의 ‘한글 호환 자모(Hangul Compatibility Jamo)’ 영역에 있는 것을 사용하게 됩니다.

각자의 비즈니스 요구 사항에 따라 선택하면 될 일이지만,

향후의 요구 사항을 고려하는 좀 더 세심한 네이밍이 필요할 것 같다.

라라벨 유효성를 다시 한번 돌아보자.

메소드 명을 validateAlpha()라고 해놓고 /^[\pL\pM]+$/u로 검사하는 것은 올바른 선택인가?

thank to

http://blog.gaerae.com/2015/10/postgresql-hangul-regular-expression.html
http://www.programminginkorean.com/programming/hangul-in-unicode/

  • 뭐 이런 사이트가 다 있나 싶은데…이런 사이트도 있다

http://advent.perl.kr/2015/2015-12-04.html
http://d2.naver.com/helloworld/76650

REST에 관해 연구했던 내용을 공개하고 가장 많이 받은 피드백은,

‘간단히 말해보라’는 것이었다.

간단한 문제가 아니라서 여전히 간단히는 말할 수는 없지만,

널리 퍼지기 좋게 몇 가지 문장으로 (자극적으로!) 정리할 필요를 느꼈다.

이 글 조차도 다 읽지 않고 비판하는 사람이 많을 것을 알고 있지만,

  • “뭘 그렇게 복잡하게 생각해? 피곤한 친구구만”

나는 계속 REST라는 용어를 함부로(!) 쓴다고 해서 비난하지 않는다.

REST라는 용어를 쓰지 말라고도 하지 않고, 잘못 썼다고 그 사람을 폄하하지도 않는다.

어느 누구도 설득하고 싶지 않다.

다만 REST가 우리에게 주는, 변화와 확장에 대응하라는 교훈을 좀 더 알리고 알리고 싶다.

연구했던 내용을 짧게 줄여 한장에 정리해보겠다.(이미 글이 길어진 기분이지만..)

중간 중간 아래 연재 목록에 어떤 내용이 담겨 있는지 설명한다.

  1. REST - 긴 여정의 시작
  2. REST - HTML Form에서 GET/POST만 지원하는 이유
  3. REST - 논문(요약) 훑어보기
  4. REST - REST 좋아하시네
  5. REST - Roy가 입을 열다
  6. REST - 당신이 만든 건 REST가 아니지만 괜찮아
  7. REST - 논문 읽기(To Do)

REST

Roy T. Fielding

Senior Principal Scientist at Adobe, co-founded Apache, authored the REST architectural style and Web standards for URI, HTTP/1.x, and URI Templates.

온라인에서 보게되는 RESTful API라고 부르는 것 대부분은 로이 필딩의 의도에 반한다.

RESTfather - 그가 만들었으니 그가 옳다!

몇 가지 잘못 사용되는 수준이 아니라 반대 방향을 바라보고 있다.

2008년 로이 필딩은 블로그에서 이에 관해 비판했지만, 육아를 시작한 후로 더 이상 이야기가 없다. (트위터에선 여전하시다)

2008년에 로이가 한 이야기를 해석해 본 것이 - 5. REST - Roy가 입을 열다

REST는 어렵다

사람들은 REST가 구현하기 어렵다고 하는데,

  • HTTP를 HTML form에서 다루기 힘들거나
  • RPC에 어떤 메소드를 써야할 지 모르거나
  • 어떤 응답코드를 써야할 지, 응답코드가 무슨 의미인지 모르거나
  • 복잡한 기능을 명사로 표현하기 어렵기 때문인 것 같다

이런 건 REST의 문제가 아니다. 단지,

  • HTTP를 이해 못했거나
  • 리소스를 잘못 설계했거나
  • 당신의 API가 RESTful할 이유가 없거나

사람들의 오해를 단적으로 보여주는 글을 읽고, 여기 달린 100여개의 댓글을 번역하고 정리한 것이 - 4. REST - REST 좋아하시네

그렇다고 REST가 쉽다는 건 아니다. 로이 필딩은 논문이 전문가를 위한 것이라고 언급했다.

논쟁에서 가장 흔히 등장하는 이야기가 Form에서 GET, POST만 지원해서 REST를 적용하기 어렵다인데, 이를 위해 특별히 2. REST - HTML Form에서 GET/POST만 지원하는 이유도 조사했다.

REST가 의미하는 것

REST가 최종적으로 추구하는 건 효율적이고 확장가능한 시스템이다.

이를 위해 6가지 제약조건(하나는 optional)을 제시했다.

조금 비약해서 소개하자면

  • client-server로 나누어 UI와 data 저장에 대한 관심사를 분리하면 각기 독립적으로 진화할 수 있어서 좋고
  • 시스템이 커져서 client가 많이 붙으면 서버가 일일이 관리하기 힘드니, payload에 필요한 모든 정보를 넣으면 한번의 요청/응답으로 관계를 정리할 수 있고
  • 그럼 네트웍에 부하가 갈테니 캐시를 사용해야하고
  • 복잡한 시스템으로 확장되면 구성요소간 커뮤니케이션에 문제가 생길 수 있으니 동일한 인터페이스를 써야하는데 4가지를 언급한다
    • 리소스 식별 방법
    • representation을 통한 제어
    • 요청/응답에 필요한 모든 정보를 넣을 것
    • 어플리케이션의 상태 변경이 hypertext로부터 발생하는 것
  • 시스템이 커지면 중간에 방화벽이나 리버스 프록시같은 미들웨어가 필요하게 되는데 통신하는 client와 server는 이를 모르고 통신할 수 있어야 함

로이는 네트웍 기반의 효율적이고 확장가능한 시스템을 만들기 위해선 이 제약조건이 필요할 것으로 생각했고, 이 조건을 만족하면 REST한 시스템이라고 할 수 있다.

이 제약조건에 대해 더 자세히 설명한 것은 - 3. REST - 논문(요약) 훑어보기

그 많은 API가 RESTful하지 않은 이유

클라이언트와 서버가 지나치게 결합되어 있기 때문이다.

API 문서를 옆에 끼고 개발을 해야만 한다면,

API를 수정하려는데 클라이언트에 문제가 생기지 않을까 걱정을 하고 있다면,

UI와 백엔드가 독립적으로 진화할 수 없게 단단히 결합되었다고 볼 수 있다.

hypermedia as the engine of application state.

로이 필딩은 hypertext의 역할이 가장 중요하다고 강조한다.

response에 링크를 쉽게 추가해주는 ‘HATEOAS 지원 라이브러리’같은 것도 꽤 보이는데,

단순히 다른 페이지에 대한 링크를 추가하는 것 만으로는 부족하다.

사실 웹 문서가 아닌 바에야, 시스템 전체를 관통하는 인터페이스로써 hypertext를 설계하기가 쉽지 않다고 생각한다.

내가 이 부분을 명확하게 설명하기 위해선 사례 연구가 더 필요하다.

표준

로이는 요청/응답 트랜잭션 이외의 영역에서 의존해야할 정보가 있다면, 그건 표준이어야 한다는 생각인 것 같다.

세상엔 별별 표준이 다 만들어진다.

API를 내부 시스템으로 한정하면 독자적인 표준도 가능할 것이다.

ROA(Resource-Oriented Architecture)

그 똑똑한 개발자들 간 10여년이 넘는 시간 동안 용어를 잘못 쓰고 있는 이유는 나도 의아한데, ROA에서 그나마 원형을 발견할 수 있었다.

Leonard Richardson의 RESTful Web Services한국어 번역서은 절판 상태.

행복한 아빠님의 블로그에 정리된 게 있어서 참고했다.

마틴 파울러가 Richardson의 Maturity Model을 소개한 블로그를 썼는데, 지앤선 블로그에 번역이 되어있다.

REST에서 ROA로, 여기서 개발자들에게 전달되면서 소위 말하는 REST 규칙이 생겨난 것 같다.
가족오락관 게임처럼..

소위 REST라고 할 때 어떤 것을 떠올리는가?

  • HTTP의 네가지 메소드를 CRUD에 대응하는 것
  • HTTP의 응답코드를 200, 404, 500이 아닌 것으로 리턴하는 것
  • URL을 계층적으로 구성하는 것
  • 또 있던가?

하지만 지금 이 순간부터 REST라는 용어가 나타나면 유심히 살펴보자.

그 많은 REST라는 용어로부터 확신할 수 있는 형식이 무엇이 있는가?

‘CRUD를 위한 네가지 HTTP 메소드를 쓴다’정도?

루비 온 레일즈와 같은 프레임웍에서 이를 더 부추겼다는 의견도 있다.

당신이 만든 건 REST가 아니지만 괜찮아

하지만 난 당신의 API가 REST가 아니라 해도 괜찮다고 말해주고 싶다.

REST가 아니라도 실패한 디자인이 아니라고 말해주고 싶다.

난 RESTful API를 만들 생각은 ‘아직’ 없다.

  • 면접을 본다면 RESTful API를 만들어봤다고 하겠지만 말이다

이런 이야기를 적은 것이 - 6. REST - 당신이 만든 건 REST가 아니지만 괜찮아

여기선 Your API isn’t RESTful — And That’s Good이라는 블로그의 내용을 번역했는데,

이런 혼란을 종식 시키고 RESTful 대신 RESOURCEful이라는 용어를 정의해서 모범 사례를 구축하자는 주장이다.

우리가 원하는 바로 그 API의 모습이 담겨있다.

최초 누가 주장했는지는 잘 모르겠지만 이 블로그는 2016년 초에 발행됐으며, RESOURCEful이라는 용어의 사용은 점점 증가하는 추세다.

Laravel의 문서에서도 5.3버전(2016년 9월)부터 RESTful이라는 용어가 제거됐다.

Moder PHP User Group 8월 발표자료

이 내용으로 8월달 MPUG 정기 모임에서 발표한 자료도 걸어둔다.

당신이 만든 건 REST가 아니지만 괜찮아

예전 발표자료 정리하기 2탄

Explaining MySQL’s EXPLAIN

한번 훑어주면 튜닝하는 데 꽤 도움된다.(그 동안 개판으로 튜닝했다는 말)

Real MySQL이란 책에서 explain 부분만 대략 보고 정리했는데, 일단은 회사에서 innodb만 쓰니까 관련 부분만 훑어봤다.

오늘 누가 MyISAM이랑 차이가 뭐냐고 물어봤을 때, 입력이 느리다고 말을 했던가?

뭐 틀린 말은 아닌 것 같은데;; table-level lock 때문에.

암튼 트랜잭션 지원 안 함. (아 이걸 이야기 할 것을…)

MyISAM은 외래키 지원도 안 되는구만. 본 것도 같고.

새로 이사온 집에 뚫어놓은 하수구에 물 내려가듯 지식이 빠져나가 큰일이다.

브랜든 아이크나 제임스 고슬링 이런 사람들은 나이가 먹어도 뇌가 잘 돌아가겠지? 기억력도 유지되는지 참 궁금하다.

그 사람들은 술을 안 먹기라도 하는 걸까?

라는 질문을 맥주를 마시면서 하고 있는데, 예거 쯔비켈이라는 맥주가 편의점에서 8월에만 6캔 9,900원에 팔고 있다.

1,650원에 마시기에는 꽤꽤꽤 괜찮은 맥주임!

애드센스 승인을 받으려면 글을 꾸준히 쓰거나 404로 떨어지는 링크가 없어야 한다는 말이 있어서 최근 발표자료나 올려봐야겠다.

자료 : Resource Hints and Preload

prefetch를 비롯한 resource hints와 preload에 대해 연구한 결과.

사실 원래 코드에는 회사 소스 구조도 있었지만, 논란이 될 수 있으니 제거하고 공유한다.

발표일 : 2017년 6월

  • 사내에서 발표하고 일부 preload 적용
  • 모던 PHP 유저그룹 정기 모임에서 발표함
0%