728x90
자바스크립트는 참 편리한 스크립트 언어이지만 다른 한편으로는 이해하기 힘든 녀석이기도 합니다. 이유인 즉선 너무 유연하게 사용할 수 있다보니 가끔 일반적인 언어, 컴퓨터 상식으로는 "왜 이렇게 동작하지?" 하는 경우들이 있기 때문입니다. 가장 대표적인 것이 조건 비교문을 이용하여 변수나 객체를 비교할때 입니다. 잘 동작할 것으로 생각했던 구문들이 정상적인 동작을 하지 않거나 예상치 못한 반응을 한다면 혹시 아래 표에 나온 경우중 하나가 아닌지 잘 살펴봐야 합니다. 아래 표는 http://dorey.github.io/JavaScript-Equality-Table/ 에서 업어왔습니다

 
Boolean 값인 True 와 1은 같은 값일까요? 그리고 True 와 "1"은 같은 값일까요? 조금 더 나아가 True 와 [1] 을 비교하면 어떻게 될까요? 두개의 이퀄 연산자(==)를 사용하여 자바스크립트에서 값을 비교하는 경우 위의 표에서 초록색으로 표시된 것처럼 결과가 리턴된다고 합니다. "" 와 0 이 같다는 생각을 해보셨나요? 혹은 "" 와 [[]] 가 같은 값으로 식별된다는 상상을 누가 해봤을까요? 

때문에 자바스크립트에서는 각 객체와 객체를 비교했을 때 값을 정확하게 예측하기 힘들다면 이퀄 연산자를 두개 이어쓰는 대신 세개(===)를 쓰는 것이 좋습니다. 세개의 이퀄 연산자를 사용하는 경우 엄격한 규칙에 의거하여 값을 비교하게 되고 이로 인한 조건 비교문의 오동작을 효과적으로 막을 수 있습니다. 세개의 연산자에 대한 부정형은 !== 이니 참고하시면 될 것 같습니다


훨씬 상식(?)에 가까운 결과를 보실 수 있습니다. 같은 형태의 자료형들간에 비교를 했을때 정확한 값이 나오는 것을 볼 수 있습니다. 자바스크립트를 쓰면서 뭔가 이해할 수 없는 동작이 발생하고 있다면 표를 참고하시고 연산자를 바꿔보는 것을 검토해 보세요. 우리의 시간은 소중하니까요. :-)

 

728x90
728x90
웹의 세상이 되면서 웹 개발자들이 각광받는 시대입니다. 서버사이드 개발을 하던 프론트엔드 개발을 하던 웹 개발은 이제 어느 회사에서도 없어서는 안되는 중요한 역할을 해내고 있습니다. 그런데 웹을 그냥 하는 것과 웹을 잘 하는 것은 분명 차이가 있을 것 같습니다. 고작 10년여의 경력인지라 모르는 것들이 정말 많고 계속 변하는 웹 관련 기술에 혀를 내두를 지경이지만 결국 기본이 탄탄하다면 두려울(?)것이 없다는 생각을 늘 하고 있습니다.

웹을 이해하기 위해서는 웹을 소화하는 주요 주체인 브라우저에 대해서 잘 이해할 필요가 있습니다. 내가 만든 자바스크립트가 브라우저에게 어떤 영향을 줄 것인지? 내가 만든 서버사이드 스크립트 메서드 한개가 사용자에게 어떤 경험을 주게 될지를 고민하는 것이 필요하다는 이야기입니다. 브라우저가 행하는 기본적인 동작을 이해하는 것에서 웹 튜닝이나 웹 가속에 대한 논의가 시작될 수 있을 것 같습니다.

사진 출처 : www.internetretailer.com


웹은 서버가 내려주는 HTML 을 읽고 사용자에게 표현하는 역할을 합니다. 브라우저는 HTML 의 여러가지 구성요소를 어떻게 해석하고 받아들이고 이해한 내용을 표현하는 것일까요? 렌더링 단계(화면에 컨텐츠를 보여주는 단계) 이전에 일어나는 일들과 하지 않아야 하는 것들을 간략하게 설명한 동영상이 있어서 소개해 봅니다. 브라우저의 동작을 이해하기 위해서 TCP 도 잘 알아야 하지만 일단은 그렇구나~ 하고 넘어가면 좋을 것 같습니다!


- NoPD -


 
728x90
728x90
팀 버너스리경이 인터넷에 엑세스 하는 방법의 하나로 월드 와이드 웹(World Wide Web)을 주창한 이래 웹은 이제 인터넷의 핵심이 되었습니다. 일상에서 일어나는 정말 많은 네트워크 연결은 인터넷을 통해서 일어나고 있습니다. 트위터에서 새로운 소식을 듣고 페이스북에 친구들과 사진을 공유하는 것 뿐만 아니라 부모님과 영상통화를 하고 동영상으로 인기있는 TV 프로그램을 보는 것도 모두 인터넷을 통해 이루어지고 있습니다.

그런데, 이런 인터넷의 폭발적인 사용을 뒷받침 해주고 있는 HTTP 프로토콜(Hyper Text Transfer Protocol)은 그다지 효과적인 프로토콜이 아닙니다. HTTP 의 첫 버전이었던 HTTP/1.0 은 단순히 서버와 사용자간에 하나의 연결만을 맺어주는 수준이었고 단일 서버에서 복수의 가상 웹 사이트를 운영할 수 있는 기능도 없었습니다. 이러한 단점을 개선한 HTTP/1.1 은 동시에 여러개의 연결을 맺을 수 있고 가상 호스트에 대한 지원이 가능해졌지만 너무 단순하게 만들어진 나머지 효율적인 웹 트랜잭션의 처리를 위해서는 추가적인 많은 작업들을 해주어야 했습니다

출처 : The Telegraph (http://goo.gl/gVQw3)



시간이 흘러 바야흐로 21세기로 접어들면서 인터넷은 이제 단순히 컴퓨터를 위한 기술이 아니라 수많은 스마트 기기들과 사물들까지 연결하는 하이퍼커넥티드(Hyper Connected) 세상을 만들어 가고 있습니다. 사물인터넷(IoT, Internet of Things)이라는 용어는 그런 네트웍의 복잡성과 연결된 기기의 수를 이야기 해주고 있고 빅 데이터(Big Data)는 이런 네트웍을 통해서 발생되고 있는 데이터의 규모를 발해주는 대표적인 단어들입니다

우리가 웹을 통해 요청을 하나 만들때 마다(HTTP Request) 전력이 소모되고 있다는 사실을 인지해 본 적이 있나요? 불필요한 트랜잭션 처리를 위해서 서버와 클라이언트의 브라우저 혹은 스마트 기기에서 동작하는 앱이 전기 혹은 베터리를 소모하고 있다는 생각을 해본적 있나요? 더 많은 기기들(스마트폰, 패드, 컴퓨터, 센서 등)이 더 많은 방법으로(브라우저, 스크립트, 앱 등) 인터넷에 연결되고 있는 작금의 트래픽 폭발을 효율적으로 조정하고 더 빠른 사용자 속도를 제공하는 것에 대한 고민에서 HTTP/2.0 은 출발했습니다.

구글이 추진하고 있는 SPDY 와 이를 근간으로 마이크로소프트가 SPDY 혹은 Web Socket 기반으로 준비중인 Microsoft S+M 은 HTTP/2.0 의 기본 골격이 되어 결국 최종적으로 만들어질 표준에 전체 혹은 일부가 녹아들어갈 것입니다. 이들의 노력으로 만들어지고 있는 HTTP/2.0 은 앞으로 우리의 인터넷, 웹웹을 어떻게 바꿔 나갈까요? IETF 에서 공개한 프로토콜 Draft (http://tools.ietf.org/html/draft-ietf-httpbis-http2-04) 를 바탕으로 어떤것들이 바뀌고 어떤 변화가 생길 것인지를 하나씩 알아보도록 하겠습니다.

- NoPD -
728x90
728x90
웹 사이트 혹은 웹 서비스를 글로벌 사용자들을 대상으로 제공하고자 할 때 가장 걸리는 것이 바로 속도문제입니다. 내 서버가 어디에 위치하고 있느냐에 따라 엔드유저가 접근하는 시간이 달라질 수 밖에 없기 때문입니다. 아마존과 같은 클라우드 인프라 서비스는 세계 여러곳에 지역(Region) 센터를 두고 있어 이런 문제점을 어느정도 해결할 수 있게 해주고 돈을 조금 들인다면 아카마이와 같은 CDN 서비스를 통해 손쉽게 웹 트레픽의 속도를 보장할 수 있습니다.

그렇지만 개인 개발자라던가 아직 서비스에 대한 클라우드 인프라 투자, CDN 전송망의 사용이 힘든 상황이라면 얘기가 조금 다릅니다. 이런 경우라면 최대한 웹 사이트를 최적화하여 HTTP 세션이 맺어지는 불가피한 오버헤드를 제외한 나머지 웹 컨텐츠, 오브젝트에 대해서는 최대한 최적화를 하는 것이 필요합니다. 그런데 최적화를 하려면 현재 상태를 알아야 합니다. 도대체 미국, 프랑스, 영국, 호주 등 외국에서 내 웹사이트에 접근했을 때 속도는 어떻게 측정해야 할까요?

 
해외로도 발이 아주 넓어 각지에 친구가 있는 경우라면 웹 사이트 접속해보면서 시간을 재달라고 하면 되겠지만 현실적으로 그러기는 너무 힘이들죠. 이런 노고를 위해 착한 사람들이 만든 착한 웹 사이트, 웹페이지 테스트(http://www.webpagetest.org)를 이용하면 어렵지 않게 세계 각지에서의 속도 측정을 할 수 있습니다.

여러가지 심도있는 테스트는 Advanced Settings 를 통해서 할 수 있습니다만 간단하게 URL 을 입력하고 테스트 지역을 선택하는 것 만으로도 기본적인 데이터를 모두 뽑아볼 수 있습니다. 브라우저 User-Agent 값을 변경시켜 가면서 웹 사이트를 테스트 할 수 있는 기능도 제공되기 때문에 여러가지로 유용한 서비스라 하겠습니다. 어차피 HTTP Request / Response 로 분석을 해주는 서비스이기 때문에 우리가 흔히 아는 웹 사이트를 가지고 속도 테스트를 해봐도 상관 없습니다.  트위터를 가지고 한번 해보니 아래와 같은 결과가 나오네요. 지역은 브라질 상파울로를 선택하고 브라우저는 크롬을 가지고 테스트 요청을 했습니다.


상세 화면으로 들어가면 파이어버그나 크롬 웹 개발자 도구를 이용하는 것과 같은 뷰를 볼 수 있습니다. 상세한 내용은 직접 보시면서 확인하면 될 것 같구요, 처음 테스트 결과가 나오는 화면에서 두번의 테스트를 하는 이유를... 혹시 아시나요? 아신다면 그대는 웹 사이트 튜닝 세계로 들어올 준비가 된 것입니다 ^^ 정답은 댓글로 물어보시면 답변해 드리는 것으로...

웹 페이지 성능 측정 서비스, WebpageTest 방문하기 [바로가기


- NoPD - 
728x90

+ Recent posts