Linux 용 데스크탑 앱 훑어보기

요즘은 web 대신 app 으로 나오는게 유행인 것 같기도 하다. 모바일만 그런게 아니고 데스크탑도 약간 그런 것 같은데, 내가 쓰는 툴 중에 자주 쓰는 것 몇 가지도 이런 식.

이 중 두 가지가 내게 익숙한 .deb 1 형식이길래 두 가지를 뜯어봤다. 하나는 slack 이고, 나머지 하나는 WordPress.com 이다.

dpkg-deb -R 명령으로 아카이브된 것을 까보면, 대략 다음과 같은 파일들이 있다:

  • desktop 앱을 위한 파일들 (wpcom.desktop, slack.desktop)
  • node_modules (와 .asar 파일들)
  • elctron
  • libffmpeg.so

특이하게도 slack 쪽엔 cron.d 룰이 있었는데, 여기서 apt 저장소를 설정한다. 이건 좀 이상한듯. 왜 설치 후 스크립트 (postinst) 를 쓰거나, 다른 오픈소스 도구처럼 저장소 자체를 안내하는게 더 좋아보이는데 대체 왜 이럴까. 여담으로, package cloud 란 서비스를 쓰더라. 미리 알았다면 나라도 쓸 것 같이 생겼다 (apt, yum, pypi 저장소랑 몇 가지 더를 지원하는듯)

리눅스 데스트탑이니, GNOME desktop app 형식을 쓴다. 그리고 리눅스 전용으로 만들진 않을테니 electron 을 이용해서 만든다. 자연스럽게 (?) 묶는 것도 electron archive 형식 으로 처리한다.

Atom/Electron 기반의 앱들은 이제 정말 주류가 된 것 같다. MS의 Visual Studio Code나 Facebook 의 nuclide.io 도 그렇고. WordPress 는 PHP를 탈피해서 API 기반 + JavaScript 로 관리자 페이지 다시 만든다고 시작한 Calypso 프로젝트 결과물로 데스크탑 앱을 내놓기 시작했던 것 같다. Slack 쪽도 이번 데스크탑 앱 베타부터 프레임웍을 바꾼 모양…

플랫폼이 파편화되면서 오픈소스 도구나 프로그램들 — 특히 기업이 직접 개발하거나 지원하는 — 쪽이 크로스 플랫폼 라이브러리/프레임웍을 더 많이 쓰다보니 역으로 Mac/linux 데스크탑 환경 쓰는 나같은 사람에겐 더 편한 세상이 되어가는듯.

Update: libffmpeg.so 관련 – @lqez 님 제보로 업데이트 electron 이 chromium에 의존하고, chromium 이 proprietary codec 처리 때문에 libffmpeg 에 의존해서 그렇다 합니다.

 


  1. 데비안 패키지의 파일 형식; 회사에서 해당 형식으로 패키징 할 일이 잦아서 익숙하다. 

Python 기반의 static page 생성기로 블로그를 옮기려는 중

원래 내 의도는 최근에 읽은 책 (=”해커를 위한 디자인 레슨”) 과 게임 (=”어쌔신 크리드 2 및 그 확장팩, 3″)에 대한 리뷰를 쓰려는 거였다.
하지만 블로그 관리자 페이지 로딩이 너무 느려서 — WordPress 버전이 올라갈 수록 더 심한듯? — 좀 괴롭다.

(일반 유저가 볼) 페이지 로딩 자체는 큰 차이가 없어서 그냥 쓸 생각이 많았는데 오늘 좀 추가 많이 기운 듯 하다.

그래서 Pelican 이란 도구를 다음과 같은 이유로 시도해봤다: (이 순서대로 고려한 것은 아님)

  • OpenSource
  • History가 길다 (+5yr)
  • 현재도 개발이 진행되고 있다
  • Python 기반
  • Markdown 지원 (rst가 주 언어지만)
  • WordPress import 지원

이걸 가지고 내 블로그를 import 해보니 몇 가지 문제가 있다: (WordPress 가 정의한 xml을 rst로 변환하는 도구가 포함되어 있다)

  • 멀티바이트 인코딩된 블로그 제목이면 rst 의 #### 이 부분을 짧게 계산해서 망한다. (글자 수를 세서 그런가)
  • 일부 글에서 글자를 해석 못해서 망하고 있음
  • 글 제목(정확히는 WordPress의 slug 값)을 이용해서 .rst 를 만드는데 urlencode 당한 문자열을 쓴다 -_-

딱히 다른 대안이 없으면 importer를 고치고 어떻게 해봐야겠다;

블로그 로딩 시간 줄이기

주말 저녁에 블로그 패이지 뜨는 속도가 이상하리만치 느려서 최적화하기로 결정했다 — 심지어 구글은 페이지 랭크에 로딩 속도를 반영한다.

사용한 도구는 Chrome용 Pagespeed 확장기능. 여기서 네트워크 탭을 이용해서 오래걸리는 기능을 하나씩 제거했다.
최적화 하기 이전 측정치는  다음과 같다.


WordPress JetPack 관련
이 플러그인엔 적어도 두 가지 문제가 있다. 우선 통계 플러그인이 제 3자인 quantcast 쪽에 js파일을 큰 쿠키를 던져 요청하고, 이걸 실행한다. 위에서 quant.js, pixel;… 에 해당하는 내용. 이게 적어도 500ms는 걸리더라. 이게 이전부터 꽤 이슈였던듯. Respecting User Privacy in WordPress에 따르면 2011년 초 이전부터 있던 일이란다. 이슈화돼서 그런지 이에 대한 방책도 있다. WP DoNotTrack이란 플러그인이 이에 해당하는 DOM 삽입을 차단해준다. 이걸 쓰면 이 500ms를 줄일 수 있더라.그리고 쓰지도 않는 gravatar hovercard관련으로 로드하는 js 파일도 지연시간이 꽤 큰 편. 게다가 css까지 로드 하는 시간을 생각하면 아주 악몽이다. 저 위에선 6초 넘게 날려먹었음. (분산도 커서 더욱 거지 같기도하고). 첫 js 로드도  길고, 얘가 로드하는 파일도 다운로드가 오래 걸리고…
하지만 이게 어이 없었던건 — 난 켜지도 않은 기능이니 — 데이터베이스에 원래 있어야 할 옵션이 없어서 그렇다. 다음 항목을 wp_options 테이블에 추가하면 됨. (wp 부분은 설치 설정에 따라 다름)

mysql> insert into wp_options (option_id, option_name, option_value) values (NULL, ‘gravatar_disable_hovercards’, ‘disabled’);

이걸로 적어도 500ms ~ 3000ms 정도를 벌 수 있다.

 

블로그 테마 관련

위의 두 가지를 제외하면 다음 내용들이 적당히 튀어나온다.

1. 블로그 내용 시작 부분에 Google Transliteration관련 스크립트를 로드하더라. 이건 내 블로그엔 필요 없는 듯 하니 제거. jquery도 구글 서버에서 가져오게 수정.

2. 서버의 vhost 중 내 블로그만 mod_pagespeed 를 적용해 봤다.[1] wp supercache가 문제를 일으키길레 일단 이 플러그인은 삭제. 그리고 .htaccess에서 켰던 mod_deflate 강제하는 것도 껐다. 어차피 mod_pagespeed가 따로 로드하고 적용함. 이거 적용한 후엔 html 타입으로 가는 컨텐츠에 각 파일 별 만료 태그, css sprite, caching등이 자동 적용된다. 약간은 빨라지는듯.

3. 최근 댓글 보여주는 것도 잠시 생각하고 껐다. 이건 이글루스 블로그들을 따라 해본던데 좀 별로인듯.

4. 더불어 CC라이센스 플레이트에 붙어있는 아이콘 이미지 로딩이 느리길레 역시 제거함.

 

최종 결과:

이 결과 대략 800ms ~ 900ms 정도에 페이지 로딩이 되고, 최종 렌더링도 1.3초 수준에 해결.

 

  1. 사실 캡쳐한건 이 모듈 적용 후임 []

JetPack: WordPress.com의 기능을 설치 형 블로그에서도

WordPress는 GPL v3 에 따라 배포되는 Free/Open Source SW다. 이걸 개발하고 있는 Automattic은 설치 형 블로그로 WordPress를 제공하고, 이와 별개로 WordPress.com 을 통해 무료 및 유료 서비스도 한다. 얘네 핵심 사업 모델이 이 WordPress.com 인데, 설치 형 WordPress에서도 이 사이트에서만 제공되는 기능 중 일부를 쓸 수 있다. 예를 들어 WordPress.com 의 통계 기능[1] 을 설치 형 블로그에서도 그냥 쓸 수 있게 해준다 – 다만 무료라도 WordPress.com 계정이 있긴 해야 함. 스팸 댓글 혹은 트랙백을 막는 Akismet 의 서비스도 일정 규모 이하의 사이트에서는 공짜다. 더불어, wp.me 로 짧은 URL을 만들어주는 기능도 제공한다.

최근에 WordPress.com 에서만 제공되던 기능들 중 일부가 JetPack이란 이름의 플러그 인[2] 으로 새로이 제공되는 걸로 바뀌었다. 몇 가지는 기존에 서로 다른 플러그 인으로 존재하거나, WP.com 밖에서도 쓸 수 있게 해주던 것이고, 몇 가지는 내가 생각하기에는 구현 방식의 한계로 다른 프로그램 없이는 잘 안될 거 같은 기능이다. 예를 들어[3] 서버에 LaTeX이 있어야 적당히 돌 거 같은 \LaTeX 지원이라거나…

관리자 메뉴에서 실제 페이지는 이런 식이고, 통계나 공유 기능처럼 약간의 설정이 필요한 녀석들은 추가 메뉴가 들어있음.

jetpack-page

현재 지원되는 기능은 전부 무료고, “Coming soon…” 으로 표시된 자리가 있으니 앞으로 몇 가지 기능이 더 추가될 것으로 보인다. WordPress.com에서 현재 제공 중인 서비스 방식을 생각할 때, 추후에 추가되는 플러그 인, 혹은 JetPack 자체가 기간 당 사용료를 받는 모델로 전환될 가능성도 있는 것 같다. Akismet 처럼 소규모 사용자에겐 계속 무료일 수도 있고 말이다. 뭐 이건 어디까지나 내 추측; 이 기능들 중 상당 수는 WordPress 설치 자체에서 제공할 수 있는 기능도 아니고, 설치 형 사용자들도 원할만한 기능들이 꽤 많이 있으니, 앞으로 이것도 얘네 사업 모델의 일부가 될 것 같다. WordPress.com 을 몇 가지 이유로 안 쓰는 사람들도 꽤 있고, 그 중 일부는 그래도 WordPress.com의 일부 기능(통계, LaTeX, …)을 쓰고 싶어하니까 말이다.

그리고 이런 기능이 WordPress.com이 다른 WordPress hosting 서비스에 대한 edge가 될 듯…

  1. 흔히 볼 수 있는 페이지 별 방문 수, 일별 통계, 참조 페이지 목록, 검색어 등등 []
  2. Mozilla에서 제공하는 PlugIn SDK의 이름이랑 겹친다; 이미 Mozilla 소프트웨어 재단이랑 얘기가 되어서, 이름을 쓰는데 큰 문제(?)는 없다고 한다… []
  3. 원격 서버를 통해 가능은 하지만 []

모바일 디바이스용 테마 설정

…한지 거의 3주는 된거 같지만(쿨럭). 볼 방법이 없는지라 – 아이폰을 선물로 뿌린다는 소문만 회사에 돌고있지만… – UserAgent 를 수정해서 쏴보내고 모바일 버젼[1] 의 블로그를 읽었다.

WP Touch 란 WordPress 모바일 페이지 플러그인을 설치한 결과가 다음 화면. 설정도 WP 답게 쉬운 편. 그냥 플러그인 디렉토리에 업로드하고 활성화(activation)하면 끝.

reinsworld_on_iphone

내 취향대로의 미니멀리즘이 되어버린듯? 블로그 자체를 아예 이 테마로 운영해버릴까하는 생각도 든다.

  1. 확인해본 실제 지원 목록은 google android, aspen, 블랙베리 9500/9530, iPhone/iPod Touch, opera mini 등등을 지원한다고 한다 – wptouch  설정 페이지조. opera mini 까지 포함되니 왠만한 모바일 플랫폼에선 대부분 적용될듯? []

statpress 에 Naver 검색 추가하기

WordPress 용 플러그인 중에 statpress 란 녀석이 있다.

이 플러그인이 블로그에 방문한 사용자가 검색 엔진을 통해서 들어왔는지, 그렇다면 어떤 검색어로 들어왔는지 추적해준다. 그리고 apache log를 직접 해석해서나 가능한 일인, 방문자(정확히는 IP지만) 별, 진입 경로, 계속해서 본 페이지 등도 추적하게 해준다. 여튼 이 작업 때문에 아래와 같은 일을 했다.

이제부터 모든 경로는 플러그인 설치 디렉토리 기준이다.[1]

우선 검색 엔진 정의 파일이 statpress/searchengines.dat 에 있는데 여기에 다음 두 줄을 추가 해준다.

Naver|cafeblog.search.naver.|query|
Naver|search.naver.|query|

그리고 statpress/statpress.php를 다음처럼 수정해준다.

# statpress.php의 1046번째 줄에 추가
function iriIsNaverEncodingUTF8( $vars )
{
    $= count($vars);
    while$i )
    {
        $tab = explode( ‘=’$vars[$i] );
        if$tab[0== ‘ie’ )
            if$tab[1== ‘utf8’ )
                return true;
            else
                return false;
    }
    return false;
}

# statpress.php의 1058번째 줄 수정
if($tab[0== $key){
    if$nome == ‘Naver’ )
     { // naver?
         if( iriIsNaverEncodingUTF8( $variables ) )
             return ($nome.‘|’.urldecode($tab[1]));
         else
             return ($nome.‘|’.iconv( ‘EUC-KR’‘UTF-8’,  urldecode($tab[1]) ) );
     }
    else
        return ($nome.“|”.urldecode($tab[1]));
}

하는 일을 따지자면,

  • referrer url 을 받았을 때, 이를 검색 엔진이름에 해당하는지 분석하는데, (def/searchengines.dat 기준)
  • 여기 추가한 Naver 관련 항목을 이용하고,
  • Naver 일 땐 검색어 인코딩이 UTF-8 인지 혹은 UHC(or EUC-KR 여튼 legacy 한지 확인)인지 검사하고,
  • UTF-8 이면 그냥 원래 statpress 코드를, 그렇지 않으면 EUC-KR을 UTF-8으로 변경한다

정도?

이 수정 작업을 마치고 나면 네이버에서 검색해들어온 결과가 깨지지 않게 된다.

ps. 이 작업을 처음 했을 때 – 밤 중에 애가 배고프다고 울 때, 아내가 젖주는 동안 노트북으로 코딩했다 – 수정이 다 끝났는데도 결과가 그대로라서 삽질했다. 원인은, 위 코드를 잘 보면 알겠지만 $nome 이라는 변수가 있는데, 난 이걸 $name 으로 보고 코딩한 것. 확인해보니 플러그인 제작한 이가 이탈리아 인이었고, 이탈리아 어의 name에 해당하는 단어가 nome 인 것. Orz.

밤 중의 흐릿하게 보이는 화면에서 nome과 name을 어찌 구분하나요 ㅠㅠ.

  1. wordpress_설치_디렉토리/wp-contents/plugins/ 가 됨 []

WordPress 2.8.4 릴리즈

http://core.trac.wordpress.org/changeset/11805

지난 번 패치에 이어 이번에도 보안 패치.

원격 공격자가 패스워드를 리셋(…)만 할 수 있던 버그가 수정되었다고 한다.
이메일 계정을 가로챌 수 없다면 진짜 의미없는 버그겠지만 일단 업데이트는 해야할 듯 하다.

ps. 그래봐야 개발 버젼 계속 쓰고 있으면(…)

WordPress에서 사이트 내부 검색하기

거의 3년 반 전에 TatterTools를 버리고[1] WordPress를 사용하기 시작한 이래로 거의 항상 맘에 드는 툴로 잘 쓰고 있다.

그렇지만 한 가지 불만족스러운 점이 있다면 — 이번 WP 2.9에선 미디어 기능 강화에 초점을 맞춰서 나랑은 좀 연관이 적을 듯 하다 — 사이트 내부 검색 기능이다. 저장된 DB를 샅샅이 뒤지는 일 — 그러니까 전문 검색 — 을 하긴 하지만 일상에서 흔히 접하게되는 Google이나 naver  수준의 무언가에는 한참 못 미친다.

이를 WordPress 커미터인 Matt 도 인지하고 있는데, WP의 경쟁툴이기도한 drupal 쪽에서 SaaS류로 acquia search란걸 시작해서 자극받는듯 하다. 여기서는 apache solr + lucene으로 사이트 내 검색을 지원한다.

그래서 WordPress에는 뭐 없나 고민 좀 했는데, 얼마 전에 kaistizen.net 에서 검색을 하다 뜬 화면이 떠올랐다. Google 맞춤검색으로 사이트 검색을 하는 거였는데, 여튼 이걸 적용해본 경험담.

  • 검색 버튼 자체에 Google이 생성해 준 JavaScript 변수 +  JavaScript를 써서 검색을 하고
  • 이를 역시 Google이 생성한 JavaScript  코드가 붙은 페이지에서 출력한다. 이건 iframe이나 dom에 노드 만들고 쓰는 작업으로 한다(이건 선택 가능)
  • 다만 비영리 기관을 증명할 수 없으면 광고가 출력된다 -_-;; 이건 좀 맘에 안들지만 공짜로 쓰려면 어쩔 수 없지;

WordPress 쪽에는 플러그인이 하나 있긴했는데 2.8에서 문제가 있다. 원래 검색에 http://WP-uri/?s=검색어 형식으로 이루어져는데, 이게 http://WP-uri/search/검색어 형태로 예쁘게(…) 바뀌면서 플러그인과 충돌하는 것 -_-; 그래서 그냥 구글에서 지시하는데로 페이지 만들고 검색 폼을 조금 수정해서 동작하게 만들었다.

실제 검색 화면은 다음 이미지처럼 생겼다. 그냥 평소에 많이 보던 Google 검색 화면에 약간의 차이가 있는 정도? 문맥이 맞으면 맞춤검색이라고 구글로고가 뜬 밑에 광고도 뜬다;

GoogleCustomSearch

외부 툴/사이트에서 검색되는걸 달가워하지 않는 사람들이 많으니, 그리고 광고 다는걸 꽤나 피하는 사람도 많아서 일단 임시(?) 해결책일 수도 있긴하지만 당장 적용할 수 있는 수단이긴 하다. 일단 WP내부 툴 자체 검색은 좀 문제가 많으니까 -_-;

ps. 근데 개인적인 생각이지만, drupal/acquia에서 사용하는 방법은 약간 문제가 있어 보인다. 페이지를 변경하면,

  1. drupal 에서 SSL/HMAC을 써서 변경한 정보를 acquia 서버에 알리고
  2. acquia가 이를 수집하고
  3. drupal은 이를 이용해서 검색을 수행하는 코드를 넣고
  4. acquia는 실제 검색을 실행하는

방식이다. 구글의 좀 더 묵시적인 방법 (1은 sitemap.xml이 업데이트 된 걸 알려서 수행할 수도 있고, ping 서비스도 있고 .. + 전혀 알려주지 않아도 되고) 이랑 자주 나타나는 구글 크롤러의 위력을 생각하면 (경쟁사(?)인 구글에 비해) 너무 번잡한게 아닌가 싶기도 하다.

  1. 사실 버젼업에서 DB호환 문제 때문에 내가 버림받은 거에 가깝다. 덕분에 나는 이전툴을 만들고 WordPress에 정착 []