늘모자란

늘모자란


제목을 영어로 하는데 문법이 맞나 안맞나도 잘 모르겠다.
국내에서만 서비스하면 상관없겠지만, 해외에서도 서비스를 사용하고자 하는 사람도 있다.
대개는 문제가 없다. 왜냐면 서버에서 요구하는데로 보여지기 때문인데, 클라이언트에서 timer등을 이용해 유저에게 보여지는 식으로 구성했을때는 문제가 된다

요컨데 싴갤러스- 밀수업자 기능에서 사용하고 있는 방법은,
먼저 서버에서 데이터를 받아와 표를 만들고, 마지막 데이터를 로컬 시간에 저장해놨다가 그 시간까지 타이머를 돌리는 반영구적인 타이머를 구성해두었다. 하지만 서버에서 반환하는 값은 서버사이드의 시간이고, 로컬에서 처리하는 시간은 컴퓨터의 시간을 읽으니까, 타이머의 역할을 수행하지 못하는 버그(?) 가 있었다

이를 처리하기 위해서 처음에는 new date().getTime() 을 서버 사이드로 보내고, 서버 사이드에서 diff를 처리하는 식으로 수행했다

클라이언트
var d = new Date();

$.ajax...
data: { "date" : d.getTime(); }
...


서버(PHP)
$diff = (time() - round($_POST['date']/1000))*-1;
if ( $diff > 0 ) { $diff = "+".$diff; }

strtotime(TIME."$diff seconds");


이렇게 하면 로컬에서 보내는 시간과 서버의 초 차이를 계산해, 서버 사이드에서 데이터를 계산해 출력해주게 된다.
근데 이상하게 잘 안되었다. 분명히 클라이언트와 서버시간이 달라야하는데, 같은 값을 받을때가 더 많았다. 결론은, 실패였다
(테스트를 컴퓨터 시간을 바꿔가면서만 테스트 했기 때문일지도 모르지만 크게 다를것이라고 생각하진 않음)

그래서 두번째로 시도한것은,
서버에서 시간을 당겨와 현재 로컬타임을 계산해버리자는 것이었다.
jquery에서 ajax로 임의 페이지에 질의하면 header에는 반드시 date 헤더가 실려오게 된다. 이를 js 로 다시 파싱하면 서버기준으로 시간을 처리할 수 있게 된다. 원래 이런 목적은 type에 head를 사용해주면 되는데, forbidden 이 뜬다. 그래도 시간 얻는데는 문제가 없으니..

$.ajax { ...
  success: function (dt, status, request) {
      servertime = request.getResponseHeader('date');
}


이런식으로 servertime을 얻어서 처리하면 되는데 ajax이기때문에 callback과 async에서 짜증을 겪을 수 있다. 적절히 처리하면 되긴하지만..

그런 다음,
data: { "date" : (d.getTime()/1000) - (new Date(servertime).getTime()/1000) },


이렇게 클라이언트에서다 처리해서 보내주기로 했다. 그러나, 처음했던 것 처럼 시간이 제멋대로 놀아나는 바람에 역시 제대로 계산되지가 않았다. 조금 더 고민해보다가.. 애초에 지역으로 나뉜 시간을 쓴다면 해당 지역의 offset을 보내줘버리고 내가 모두 처리해버리자 싶어서 검색하다가 다음을 찾았다

data: { "date" : d.getTimezoneOffset() },


이렇게 하면 현재 로컬 시간이 gmt와 얼마나 차이나는지 알려준다. 우리는 한국시간이니까 -540이 리턴된다. 나누기 60 하면 9니까..
그래서 서버에서 540을 기준으로 잡아놓고, 로컬 시간과 서버 사이드 시간이 얼마나 차이가 나는지 확인하면 된다

$diff = (540 + ((int)$_POST['date']))*-1;


아주 어려운 코딩은 아니었지만, 해외 유저들을 전혀 고려한적조차 없었고 (문제가 될줄도 몰랐기 때문에), 많이 당황했던 하루였다.
로컬에서 시간 관련 타이머를 사용한다면 반드시 고려해보자

2017/09/03 04:52 2017/09/03 04:52

시작하며


제목이 너무 거창한데, 유저들에게서 강제로 confirm에 대한 확인을 받아야할 일이 있었다. confirm을 내가 띄우는 주체가 아닌데 반드시 confirm 에 대한 확인을 받아야만 모든 데이터를 다 긁을 수 있기 때문이다. 별수 없이 방법을 찾아봤는데 confirm에 delegate를 거는 방법은 없었다. 이 method는 문자 그대로, 말그대로 유저의 confirm을 받아 처리하는 기능이기 때문이다.

바꿔치기


이건 정공은 아니고 그냥 trick 에 가깝다 혹은 cheat.. 강제로 confirm을 발현 시키고, 그 이후에 window의 confirm을 모두 true로 바꿔버리는것이다 코드를 보자

window._confirm = window.confirm;
window.confirm = function() {
 return true;
};

코드는 심플한데, 말그대로 브라우저 윈도우의 confirm을 모두 true 로 바꿔버리는것이다. 이 코드가 실행되면 해당 세션의 웹 브라우저의 confirm은 모두 true가 되서 뜨지도 않게 된다. 때문에, 현재 상태를 window._confirm 안에 저장해놓고, 이벤트가 끝나면 다시 다음과 같이 수행하면 된다

window.confirm = window._confirm;

Thanks to jake

2017/05/19 11:31 2017/05/19 11:31
블로그도 다 꾸며놓고, 첫 글도 썼는데, 2번째 글을 뭘로 써야하나 고민하게 되었다.
왠지 용두사미가 될 것 같은데 어떻게 유익한 글을 써보나..(믿지 못하겠지만 잡글 없는 클린 블로그를 지향... 첫 글이 좀 그렇지만 일단 목표는 그렇다), 고민하다가 Momentum(이하 모멘텀) 이라는 녀석을 알게 되었다.

모멘텀은 진짜 별 거 없는 'new tab' extension 이다.
새로운 탭을 열면 아래 화면이 뜬다......

구글 크롬 사용자는 여기서 다운로드 받을 수 있다.

크롬에 먼저 설치를 해보고, 사진이 바뀌는거에 꽤 만족했는데, 파이어폭스는 준비하고 있다고만 하고 아직 부가기능탭에 나오지 않았다. 사실 요즘 느끼는건데 파이어폭스 참 어려운 시기인것 같다. 부가기능도 크롬이 이제 더 뛰어난것 같고, 개발자들도 파이어폭스보단 사용자가 많은 크롬의 손을 들어주는 것 같다.

어쨌든, 구현자체는 어려워보이지 않았다. html 소스였으니까.. 그냥 파일 따다가 쓰면 될 것 같았다.
하지만 사람은 귀찮음의 생물, 처음엔 소스보기를 해서 일일히 손크롤을 할까 하다가, github를 뒤지기 시작했다..
덕중의 덕은 양덕 성님이라고 했던가, 역시 있었다. Mcdo - Momentum Flickr
아마 이 프로젝트는 소스를 그대로 사용하는데, 사진이 좀 많이 변하길 원하는 그런 느낌의 프로젝트였다.
어쩄든 이걸 써볼까 했는데, 플리커가 자체가 너무 느려서 ... 써먹진 못할것 같았다.

그래서 그냥 원본을 따기로했다.
역시 손크롤 할 수 있지만 왜 그러지 않느냐? 귀찮으니까..
파이어폭스는 xpi라는걸로 관리되는데, 크롬도 그런게 있을 것 같아서 보니 crx로 관리된다고 한다.
crx는 어떻게 얻는지 아직은 잘 모르겠고, 그냥 따주는데가 있다.

crx를 얻고 확장자를 zip으로 변경 후에 압축을 풀면 압축이 풀린다.
근데 놀라운 사실은, 알집으로는 안풀린다.. 7zip으론 풀리는데.. 알약의 기술력에 혀를 한번 내둘렀다.
이렇게 momentum의 소스를 얻었고 이제 xpi로 옮기면 될터.

그런데........xpi는 어떻게 만들지?
구글에 어떻게 만들지? 입력해보니 여러개가 검색되는데, github에서는 어떻게 개발하고 있을까 궁금했다.
사실 구글에 나와있는 한글 블로그들 보면 거의 2009년글들이고 깃헙에서 공유되고 있는 소스와 그냥 구조자체가 완전히 판이했다.
그래서, 뭔가 다른 방법이 있을거라 생각했고, 다른 방법은 있었다.

http://stackoverflow.com/questions/20409349/what-is-the-easiest-way-to-develop-firefox-extension
이 스택 오버 플로우 글을 보면, 자세히 소개되어 있다.
mozila-build 라는 툴을 제공하고 이를 이용해서 쉽게 만들 수 있다는 것 이다.
눈뒤집히는 소리가 아닐 수 없다. install.rdf 를 바꿔야된다느니, guid 를 따로 적어야된다느니 소개한 블로그들 글을 왜 보고 따라하고 있었나 이런 생각이 들었다.

답글에 너무 잘 설명이 되어있기때문에, 설치과정을 따로 설명하진 않겠다.
리눅스, 윈도우 둘다 mozila-build를 제공해주는데, 개인적인 느낌으로는 리눅스쪽에 훨씬 더 친숙하게 되어 있는것 같다.
세팅이랄것도 없는 세팅을 하고나고, cfx init을 하니 github에서 본 extension의 뼈대들이 생성되었다.



생성된 구조는 역시 대세를 따르듯이 js였다.
프로젝트를 생성했으니, 튜토리얼을 따르면 될 터, 튜토리얼을 켜고 만들어 보기 시작했다.
리눅스 운영체제에서 사용하는 사람은 cfx run이나 test는 좀 어려울것 같고, packing을 위해서 cfx xpi 를 하면 알아서 다 패킹된다는것에 너무너무 편안함을 느꼈다 -_-;

테스트를 순조로히 마치고 data에 모두 우겨넣고 xpi를 깔아봤는데 이게 왠일, 하나도 안보인다..
이상해서 이것저것 확인해보니 크롬에선 잘 돌아가는데, 파이어폭스에서는 안돌아가는 기이한 현상 발생..
opacity 이슈인가해서 css를 훑어보니 임의로 수정해주니 나오긴하는데, 중앙정렬도 제대로 안되고 엉망이었다.

쉽게 갈 수 있을 줄 알았던 것에서 터지니까, 괜히 파이어폭스 익스텐션이 없던게 아니구나 하는 생각이 들어서 아차 싶었다.
여기까지 했는데 물러날 순 없지 했으나..
너무 늦은 시간 시작했던터라 시간이 5시를 가까이 가리키는 것을 보고 블로그에 (1)을 붙이고, 2편에서 다시 써보기로 한다..
아마 어떤 점을 수정하고, 어떻게 변경하겠다는 js 변경이 주가 되지 않을까 하는데..

글이 너무 길어지는 감이 있으니, 적당히 분량조절하는 것 같아 괜찮은 기분이다.
2편에서 계속!!
2014/12/26 02:04 2014/12/26 02:04