Regular Motion

개발자가 상팔자

Page 2 of 59

Getting Literal with Template Strings.

최근 개발하고 있는 기능 중, JavaScript에서 XML String을 생성하는 부분이 있다.  해당 코드는 Template화된 XML String에서, 필요한 값들을 replace하는 방식으로 구현되어 있었다.
문제는 Template에 replace 해야 할 값들이 많을 수록 코드의 미적인 부분과 성능적인 부분이 함께 추락하는 방식이었다.
아래의 코드는 위의 예시와 72% 정도 유사하다.

생성해야 할 XML Template을 String으로 선언한 뒤, 변수로 치환되어야 할 값들을 String.prototype.replace()를 통해 치환하는 구조다.  쉽고, 나름 직관적이다.  사실 크게 문제가 있는 코드라고 보기는 어렵다. 하지만 위에서 언급했듯 치환되어야 할 값들이 늘어나면 replace chaining이 늘어나며 뭔가 문제가 생길 것 같은 불안감을 내포하는 코드다.

그래서 위 코드를 깔끔하게 개선하고 싶어 약간의 조사를 해보니 ES6의 Template Strings을 활용하면 매우/훨씬 깔끔한 코드로 수정 가능 할 것 같았다.  (정말 약간의 조사로 알게되어 애초에 왜 저렇게 구현했나 자괴감이 들었다)

실제로 위 코드를 ES6의 Template Strings을 활용하여 수정한 코드는 아래와 같다.

문장을 감싸는 부호를 single quotes(‘)에서 back-ticks(´)으로 대체했고, 값들을 치환하는 replace() chaining 구문이 사라졌다. (JavaScript 엔진에 의해 자동으로 치환된다는 의미다.)
코드가 간결해졌다는 것은 시력이 0.2 이상인 사람은 모두 육안으로 확인 가능하고, 성능이 빨라졌다는 것은 간단한 Benchmark를 통해 증명 가능하다.  (https://jsfiddle.net/6xnutcsd/)
* 위의 예제는 크롬에서 7~10배 정도의 성능 향상이 있으며, 치환되어야 할 값들이 많을수록 성능 개선 효과도 크게 나타났다.

 

예제로 글을 시작했으니, 이제 문법과 활용 범위에 대해 알아보자.
(글 끝부분의 Reference 링크를 참고하시는게 더 낫다)

Syntax
Template String은 일반적으로 String을 감쌀 때 사용하던 single quote(‘)나 double quote(“) 대신 back-ticks(`)을 사용하면된다.  쉽다;


String Substitution
문자열에 JavaScript Expression을 삽입 할 수 있는 String Substitution은 Template String의 가장 큰 장점이라고 할 수 있다. 심지어, 거의 모든 JavaScript Expression이 허용되며,  치환/처리가 필요한 Expression을 중괄호{}로 감싼 뒤, 앞에 달러($)를 붙여주기만 하면 된다. (아, 이놈의 자본주의, 그놈의 돈돈돈)

Expression에는 단순히 변수의 이름이나, 간단한 수식은 물론이고, Instance의 property나 method등 일반적인 JavaScript Expression 대부분 허용된다. (개발자한테 참 좋은데, 설명할 방법이 없다.)

Tagged Templates
Tagged Templates은 함수를 이용하여 Template String의 출력을 변형하기 위한 목적으로 사용 할 수 있다. 사용법은 함수의 이름 뒤에 Template String을 선언하면 된다. 그러면 함수의 첫번째 인자로 Template String의 문자열이 Array 형태로 전달되고, Expression이 순서대로 함수의 인자로 전달된다.

상상력이 미천한건지 아직까지 Tagged Templates의 활용할 코드는 발견하지 못했다.

 

References

 

Should URL be case sensitive?

회사에서 회의 중 URL이 Case Sensitive하게 처리되어야 하는지에 대한 사실 확인이 필요하여 이를 찾아본 과정의 기록입니다.

결론부터 말하면 URL은 Case Sensitive 합니다.
(결론부터 알려드렸지만 끝까지 읽어주세요. 광고도 없는 걸요;)

아주 조금만 더 들어가서 우리가 URL이라고 말하는 건 크게 6가지 요소로 나눌 수 있습니다.

RFC 7230에 따르면, 위 구성요소 중 Scheme와 Host를 제외한 요소들은 Case Sensitive하게 처리되어야 합니다.
(Port는 숫자로만 구성되니 논외로 합시다)

 

시작부터 비교적 명확하게 결론이 났습니다.  Scheme와 Host를 제외한 요소들은 Case Sensitive하게 처리되어야 한다.

즉,  https://www.google.com/HTTPS://WWW.GOOGLE.COM/은 완전히 동일한 결과를 보장하지만,  https://www.google.co.kr/search?query=new와 https://www.google.co.kr/search?query=NEW는 다른 URL로 볼 수 있고, 실제로 검색결과도 미세하게 다릅니다.

 

어허,  근데 실제로 대부분의 사람들이 URL을 입력 할 때 대/소문자를 의미있게 구분해서 사용하고 있을까? 라고 자문해보면  ‘아니오‘라고 말 할 수 있습니다. 대부분의 사람들은 소문자만으로 URL을 입력하고 있고, URL에 대문자가 섞여 있다면 아마 Caps lock을 의심해봐야 합니다.

RFC 규약의 scheme와 host를 제외한 요소는 Case Sensitive하게 처리돼야 한다는 사실과는 별개로 실제 URL에 대소문자를 의미있게 섞어서 사용하는 사람이 거의 없다고 할 때,  HTTP://WWW.EXAMPLE.COM/LIST로 접속한 사용자에게 http://www.example.com/list의 결과화면을 보여주지 않을 이유가 없습니다.

실제로 많은 서비스들에서는 Scheme와 Host를 제외한 요소에 대해서도 Case Insensitive하게 URL을 처리하고 있습니다.  믿지 못하는 분은 아래 2개의 링크를 클릭해보시길 바랍니다. 동일한 페이지를 나타내는 걸 알 수 있습니다.

http://stackoverflow.com/questions/7996919/should-url-be-case-sensitive

HTTP://STACKOVERFLOW.COM/QUESTIONS/7996919/SHOULD-URL-BE-CASE-SENSITIVE

 

다시 처음으로 돌아가서 그래서 URL은 Case Sensitive한가? 또는 Case Sensitive하게 처리되어야 하는가?

RFC에 따르면 Scheme와 Host를 제외한 요소들은 Case Sensitive하게 처리되어야 한다. 허나; 서비스에서 Path와 Query, Fragment의 대소문자 구분이 크게 의미가 없을땐 알아서 잘 하자잉.

 

References

 

2017 목표

역시 사람이 목표가 있어야 되는 것 같아서 새해를 맞아 몇가지 목표를 세움.

  • 업무 목표
    • Spindle Android Viewer재설계 + 리펙토링: 4년간 여러가지 기능을 추가하는 과정에서 Viewer가 많이 낙후되고야 말았다. 외관은 크게 낙후되지 않았으나 내부 구조는 조금 낙후된 것 같다. 개인적으로는 신경을 쓰면서 기능을 추가했지만 시간에 장사가 없는 것 같다. 바닷가 바람에 녹슨 배처럼 정비가 필요한 시점이다.
      재사용 가능한 모듈은 살리되, 설계부터 다시하는 방향으로 Refactoring이 필요한 시점이 된 것 같다.
      시간이 2~3달 정도 소요될 것 같은데 어떻게 시간을 만드나;;  그래도 진행하면 2~3달은 꽤나 재미있게 작업 할 수 있을 것 같고, 개선되는 부분도 아마 매우 선명할 것 같다.
    • Tablet에 최적화된 eBook 포맷 기획 및 개발: 현재의 포맷이 갖는 한계는 비교적 명확한 것 같다.
      1) 일반적으로 책의 물리적인 크기가 태블릿 화면보다 크다.  2) 책의 물리적인 크기는 대부분의 사람이 편하게 볼 수 있는 크기로 만들어졌을 확률이 높다.  1)과 2)가 참일 때 책의 비율을 유지하면서, 태블릿에서 컨텐츠를 보여주려면 책이 원하는 크기보다 좀 작게 보여질 확률이 높다.  물론 Zoom in/out은 가능하지만 Default 값은 중요하지 않은가. 회사가 보유한 좋은 책들의 가치를 100% 프린트북 대비 150%를 끌어낼 수 있는 새로운 포맷을 개발해야 될 시점이 점점 다가오는 것 같다. 기기 사양은 이미 충분히 올라왔다.

 

  • 개발자로서의 목표
    • AWS 공인 솔루션 아키텍트 자격증 취득: 현재 회사의 이점을 살려, AWS 솔루션 아키텍트 공부를 하여 자격증을 취득해보자. 3~4달 정도 공부를 해야 될 것 같은데 앞으로 도움이 될 것 같은 몇 안되는 자격증으로 보이니 꼭 공부해서 상반기내 취득을 목표로. 취득하는 과정에서도 도움이 많이 될 것 같고, 자격증을 보유한 것으로도 도움이 될 것 같다.
    • Radio inn: 올해에는 다운로드 수 보다는 기능 추가에 목표를 두고 개발
      1) 로그인 / 로그아웃 / 북마크 팟캐스트 계정 동기화
      2) 친구 또는 다른 사용자가 북마크한 팟캐스트 열람
      3) 취향 기반 팟캐스트 추천 서비스
      4) 팟캐스트 별점 / 에피소드 별점
    • 블로깅 12개: AWS 자격증 준비 및 Radio inn 개선 과정에서 배운 것들을 꾸준히 포스팅. 양보다는 질. 허나 최소 12개 정도는 블로깅 할 수 있도록.
    • Git을 자유롭게: 아직도 Git이 어색할때가 있다. git을 자유롭게 사용할 수 있도록.

 

  • 개인 목표
    • 82kg까지 다이어트: 문득, 예전 사진을 보다 거울 속 나와 너무 차이가 나는 것 같아 급하게 목표에 추가하게 되었다. 7kg을 빼보자. 82kg까지 다이어트.
    • 어진이와 분기별 1회 둘이서 여행: 초등학교 들어가면 아빠보다 친구들을 더 좋아한다고 하던데, 아마 올해가 어진이와 가장 잼있게 보낼 수 있는 시기 일 것 같다. 올해는 꼭 같이 여행을 많이 다녀야겠다. 캠핑이면 가장 좋겠지만, 캠핑이 아니더라도 1) 물놀이 할 수 있는 곳 2) 박물관 / 미술관 위주로 딸과 많이 여행을 다녀야겠다.

 

2016 회고

어느덧 개발자라는 직업으로 일하고 있는지 만으로 7년,

남편으로 사는 것도 만으로 6년,

그리고 아빠라는 이름으로 살고 있는 것도 만으로 5년.

시간은 점점 더 빠르게 흘러가고,
흘러간 시간 대비 크게 나아지는게 없는 것 같아 회고를 하며 기록이라도 남겨야 될 것 같다.

  • 아빠 그리고 가장으로서의 2016
    너무나 다행히 크게 아픈 사람없이 한해를 보낼 수 있었으니 행복했던 한해다.
    특별히 기억에 남는 순간은 역시나 여권 보여주고 다녀온 2번의 여행, 괌과 세부. 두 곳 모두 휴양지라 어진이가 실 컷 물놀이를 할 수 있어서 좋았고, 아무래도 나이가 한살, 두살 먹어가니 가족끼리의 여행이 좋아지는 것 같다.
    2016년 가장 그리고 남편으로써 부족했던 부분은 기념일을 잘 챙겨주지 못했던 점.
    특히, 결혼 기념일과 아내의 생일. 내년에는 최소한 작은 선물과 이벤트는 준비하도록!
  • 개발자로서의 2016
    개발자로서 2016년에 소박한 목표 2가지가 있었던 것 같은데 그마저도 지키지 못한 것 같다.
    1) 블로깅 12회: 딱 절반인 6개의 글을 썼다;
    2) Radio inn 10만 사용자 만들기: 6만은 넘겼으나, 후반 뒷심 부족으로 10만은 실패. 1분기 기세를 이어갔으면 20만도 가능했을텐데 많이 아쉽다.
  • 회사에서의 2016
    회사에서의 생활은 딜레마의 연속인 것 같다.
    개발자와 팀장, 두개의 롤. 하고 싶은 것과 해야 하는 것.
    호불호가 뚜렷한 성격 탓에 최대한 하고 싶은 것만 하면서 살고 싶은데, 점점 해야 하는 것들이 늘어나서 고민이 되는 한해였다.
    그 와중에 저작툴을 다시 만든건 2016년에 제일 잘한 일이 아닌가 싶고, 팀장으로서의 역할은 여러모로 아쉬움이 많이 남는다.
    우선은 ‘하고 싶은 것’에 좀 더 집중!

 

[Android] 악화가 양화를 구축한다.

‘악화가 양화를 구축한다’는 말은 그레샴이 멀리 500년 후를 내다보고 지금의 Android를 빚대어 한 말인 것 같다.

대다수의 안드로이드 개발자들은 표준을 준수하는 코드를 작성하고 싶어 하지만 삼성의 높은 시장 점유율과 반복되는 버그 리포트는 표준만 준수해서는 답이 없다는 뼈아픈 가르침과 인실좆을 반복적으로 알려준다.

삼성을, 정확히는 갤럭시를 지원하기 위한 코드들은 마치 표준인양 인터넷을 떠돌아다니고 표준은 설 곳을 잃는다.

Android Support Library의 눈부신 활약으로 요즘은 상황이 많이 좋아졌지만 카메라나 미디어 코덱과 같이 하드웨어와의 연동이 필요한 부분은 현재 진행형이다.

범용적이거나 호환성이 높은 제품을 만들 때 필요한 자질은 보이지 않는 단점들을 하나 하나 덮어 줄 수 있는 인내심과 따뜻한 마음 그리고 구글링 인 것 같다.

« Older posts Newer posts »

© 2017 Regular Motion

Theme by Anders NorenUp ↑