2013年1月14日月曜日

GAE/J でセッションの clean up

#f1yosou では一応セッションを使ってログインできるようになっています。個人の成績等が少し見れるようになっているのですがこちらの機能はほぼ使われてなくて、次のレースのお題を投票する際に使ってるのがほとんどでした。しかし GAE/J ではそのセッションのデータは Datastore に保存されているようなのですが、それがずっと残り続けてそれなりにサイズを圧迫すると。 #f1yosou では 14,000 ものセッションが残っておりました・・・。

なのでそれをクリーンしましょう。そのためのサーブレットが既に組み込まれているのでそれを使います。web.xml に以下の定義を追加します。

 <!-- session cleanup servlet -->
 <servlet>
     <servlet-name>_ah_sessioncleanup</servlet-name>
     <servlet-class>com.google.apphosting.utils.servlet.SessionCleanupServlet</servlet-class>
 </servlet>
 <servlet-mapping>
     <servlet-name>_ah_sessioncleanup</servlet-name>
     <url-pattern>/_ah/sessioncleanup</url-pattern>
 </servlet-mapping>
 <security-constraint>
     <web-resource-collection>
         <web-resource-name>session-cleanup</web-resource-name>
         <url-pattern>/_ah/sessioncleanup</url-pattern>
     </web-resource-collection>
     <auth-constraint>
         <role-name>admin</role-name>
     </auth-constraint>
 </security-constraint>

これを cron.xml 等で定期的に叩くことによってセッションのデータを少なく保てるようです。既に多数残っている今回のケースではその URL を何度も直接叩いて減らしました。その際 Datastore Writer 等が増えるので Quota に余裕がある時にどうぞ。

2013年1月11日金曜日

Linux にリモートデスクトップで接続

表題のとおりです。なかなかいいよという噂を聞いたので試してみました。

まずは EPEL を enable しておきます。
# yum search xrdp
(snip)
Installed:
  xrdp.x86_64 0:0.5.0-0.13.el6                                                                                                 

Complete!
インストールは簡単ですね。
# service xrdp start
いきなり開始します。これだけ。そして・・・


このように Windows のリモートデスクトップ接続で接続できます。ただこのままだと日本語キーボードでは問題があるのでこのファイルを /etc/xrdp に置く必要があります。(以降のバージョンでは直っている可能性があります。その場合は xrdp-genkeymap を実行するとそのファイルが生成できるはずです。)

ちなみに接続する解像度がキーになっているのか、同一の解像度で接続すると同じセッションが取得できます。逆に言うと別の解像度で接続すると新たなセッションが割り当てられます。ログアウトすると当然そのセッションはなくなります。

なかなか感動もんですがどうなってるか気になりますよね。これを見ればある程度わかるかも?
$ ps -ef | grep vnc
user   18453 18451  0 23:17 pts/0    00:00:01 Xvnc :10 -geometry 1680x1050 -depth 16 -rfbauth /home/user/.vnc/sesman_user_passwd -bs -ac -nolisten tcp -localhost -dpi 96
つまり通信はリモートデスクトップのプロトコルに準じてるわけですが、その先は VNC サーバーを自動で立ち上げてくれているみたいです。なので上に書いたように解像度を変えると別のセッションになったりしますが、最悪 VNC のディスプレイ番号を見つければ、そのマシン上からは vncviewer で接続できます。

まあ家だとつないでるマシンとサーバー間に距離がない、というかGBitの中なので VNC とどっちがいいとかあまりないですが、vncclient を入れてない Windows 機からもつなげるのはありがたいですね。ちなみに、/etc/xrdp/xrdp.ini をいじると、固定の VNC ディスプレイに接続することもできます。vino とかを使ってる場合はそれで :0 につなげることも確認しました。

なかなか便利ですよね。しばらく使ってみることにします。

2013年1月10日木曜日

ケースファンを交換

サーバー機に使っている筐体の背面の12cmファンがシャカシャカ音をたてていたので、交換してみました。そのファンは3ピンのコネクタなんですが、この前買ったマザボ(ASRock Z77 Pro4)はファン1が4ピン、つまりPWM対応のコネクタでした。4ピンのところに3ピンも刺さるのでとりあえず動作は問題ないんですが、せっかくならPWM対応のファンを買ってもう少し静かにしたいなと。

そこで買ってきました。このように4ピンのコネクタがついています。交換したら静かになりました!

しかしすぐにまたシャカシャカ音が気になりだしました。なんだ!不良品か!と思ったら、今までうるさかった背面のファンが静かになったことで、今度はフロントのファンもシャカシャカ音を立てていたことに気付いたと言うわけですw

後日フロントも換えます。こっちは 9cm なので一回り小さい感じですね。

2013年1月8日火曜日

#f1yosou : ツイッターウィジェットの更新

現在 #f1yosou のサイトにはツイッターのウィジェットが出ています。こんなやつ→ですね。

Twitter API V1.0 が動かなくなる3月にこのウィジェットも動かなくなるとか。まあ当たり前と言えば当たり前なんですが、V1.1 ではすべての API リクエストに認証(OAuth 等)が必要になったので、この任意の検索ができるウィジェットもできなくなって登録制になるという感じでしょうか。3月と言えばF1シーズン開始月になりますがそんなときにウィジェットが動いてなかったら泣けますw なので移行しましょう。

やり方はこちらに従うだけでよいはずです。それでは順に作業します。

まずは Twitter のアカウントのウィジェットの設定の画面に行きます。 そこで「新規作成」をクリックします。今回はハッシュタグによる検索なので、以下のようになりますね。いろいろ設定を変えると右のプレビューが変わります。
  これを保存すると、右下に javascript を含む HTML が生成されます。これをサイトに貼り付けます。気付かれた方もいるかと思いますが、上の設定にはドメインが必要です。1つ作っていろんなとこで使うってのはできないわけですね。それはいいんですが、開発するときにローカルで見れないと面倒だなぁと思っていたら、ちゃんと
By default we also support the "localhost" domain for testing on your local development environment.
とありました。なので安心して開発環境で試せます。実際張ってみると

完成!簡単ですね。(@ar147ti さん友情出演ありがとうございますw)

余談ですが、ドメイン指定は正確にホスト名を指定しなければいけないようで、サブドメインとかもだめです。なのでたとえば GAE で作業してる場合に別バージョンでデプロイして確認したいとかの時は <appname>.appspot.com だけでなく <version>.<appname>.appspot.com 等を一緒に指定する必要がありそうです。確認が終わったら消せばいいだけですしね。

サイトのほうにはもう少し整えてから反映します。

2013年1月6日日曜日

git との格闘w その5 IntelliJ IDEA との連携

なんとなく流れがつかめたところで IntelliJ IDEA との連携をしてみます。せっかくなので Linux にインストールしてやるんだ~。

インストール

Linux のインストールは簡単。tar.gz を展開するだけです。こういうの大好き。そして bin/idea.sh を起動すると・・・。
$ /opt/idea-IU-123.94/bin/idea.sh 
OpenJDK Runtime Environment (IcedTea6 1.11.5) (rhel-1.50.1.11.5.el6_3-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
OpenJDK Runtime Environment (IcedTea6 1.11.5) (rhel-1.50.1.11.5.el6_3-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
WARNING: You are launching the IDE using OpenJDK Java runtime.

         ITS KNOWN TO HAVE PERFORMANCE AND GRAPHICS ISSUES!
         SWITCH TO THE ORACLE(SUN) JDK BEFORE REPORTING PROBLEMS!

NOTE:    If you have both Oracle (Sun) JDK and OpenJDK installed
         please validate either IDEA_JDK, JDK_HOME, or JAVA_HOME environment variable points to valid Oracle (Sun) JDK installation.
         See http://ow.ly/6TuKQ for more info on switching default JDK.

Press Enter to continue.

おおなんと・・・。以前はまったく話にならなかったけど最近 OpenJDK まあまあじゃね?と思ってたんだけど。ならば Sun の、じゃなくて Oracle の(棒)JDK を入れますか。そうだ、ここは思い切って7だな、7!ここから rpm をゲットします。
# yum localinstall jdk-7u10-linux-x64.rpm
なんかエラー出るんだけど・・・。でも入ったっぽい。
$ /usr/java/latest/bin/java -version
java version "1.7.0_10"
Java(TM) SE Runtime Environment (build 1.7.0_10-b18)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)
よしよし。ではさっそく起動!
 
うむうむ。ちょっと昔風になっちゃうのが残念だけど・・・。


使ってみる

えー、まだ使ったことないのですがw とにかく突き進みましょう。きっと世の中の開発者のみなさんが絶賛してるんだから細かいところにも手が届いてるはず。gitからチェックアウトしてきてなんてお手のものだろう!

その通りでしたw

上のメニューから Check out from Version Control を選ぶと、当然のように git が。リポジトリの URL 等を入れると

そもそもタイトルが Clone Repository なので先ほどやっていた git clone そのものですね。そして先へ進むと、
おおお、プロジェクトになりました~。右下でブランチの作業も出きるし、上の VCS のメニューからもいろいろできます。たしかに eclipse だときっといろんなプラグインを入れないとですが IntelliJ IDEA は何もしなくても入ってるんですね。なるほど。

githubも

というかそもそも先ほどの Check out from Version Control に github すらあったんでした。起動後には VCS のメニューからアクセスできますね。
さて Login をクリックすると・・・。さっきと同じダイアログが出てきます。

あとは git のときと同じ操作感でいけますね。(当たり前か)

コマンドではエディタベースでやっていた rebase なんかも
こんな感じで GUI ベースで操作できます。

最後に VCS -> Git -> Push でサーバーに push すれば出来上がり!予想通り既に入力しているのでパスワードを聞かれることはありません。私は origin のところに同じ名前のブランチを作って push しました。それが git push origin new_branch がやってることと等価ではないかと。

ようし、準備完了~!

2013年1月5日土曜日

git との格闘w その4 githubとの格闘w

いよいよ本題に近づいて参りました。ようやく github の前半3文字を少し理解できるようになったので次は github です。いけいけゴーゴー! (古っ?w)

ここあたりを参考に進めます。さらにこちらも参考にさせていただきました。

github にアカウントを作ってログインします。検索やら何やらで参加するプロジェクト(と呼ぶのかな?)を探します。そして Fork を・・・。

いいのかな~。本当にいいのかな~。いいや、失敗してもいいって @yusuke さんが言ってくれたし。(正確には「何度でもやり直しできるので」であって失敗していいってわけではないんですがw)えいっ!

・・・とりあえずデモのrepoで試してみますw
$ ls
sample
$ git clone https://github.com/Sdk0815/Spoon-Knife.git
Initialized empty Git repository in ~/git/Spoon-Knife/.git/
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 24 (delta 7), reused 18 (delta 2)
Unpacking objects: 100% (24/24), done.
$ ls
sample  Spoon-Knife
$ cd Spoon-Knife/
$ ls
forkit.gif  index.html  README
最終的には親に pull request を送るので、fork 元のrepoを足します。
$ git remote -v
origin https://github.com/Sdk0815/Spoon-Knife.git (fetch)
origin https://github.com/Sdk0815/Spoon-Knife.git (push)
$ git remote add upstream https://github.com/octocat/Spoon-Knife.git
$ git remote -v
origin https://github.com/Sdk0815/Spoon-Knife.git (fetch)
origin https://github.com/Sdk0815/Spoon-Knife.git (push)
upstream https://github.com/octocat/Spoon-Knife.git (fetch)
upstream https://github.com/octocat/Spoon-Knife.git (push)
ふむふむ。いい感じ。適当に変更を作る branch を用意します。
$ git checkout -b work
この branch 上で変更を作ります。変更ができたら pull request 用の branch を作ります。
$ git checkout -b fix_css
$ git rebase -i master
Successfully rebased and updated refs/heads/fix_css.
rebase するときに複数の commit を一つにまとめるそうです。そうでないとローカルでいろいろやった変更がサーバー上にも見えちゃうとか。

さていよいよサーバーに push してみますかね。
$ git push origin fix_css
error: The requested URL returned error: 403 while accessing https://github.com/Sdk0815/Spoon-Knife.git/info/refs

fatal: HTTP request failed
おうふ・・・。そういえばそもそもログインとかしてないような・・・。.git/config の origin のところ、https://... を https://Sdk0815@... に変えます。
$ vi .git/config 
$ git push origin fix_css
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 285 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To https://Sdk0815@github.com/Sdk0815/Spoon-Knife.git
 * [new branch]      fix_css -> fix_css
おおお!できましたね! git push のときにパスワードを聞かれます。

さて今度はブラウザで見てみましょう~。
 キター!

最後に pull request です。やり方はこちら。デモなんでがんがん行きますよ~。まず
 のように作業したブランチを選択。そして右上の"Pull Request"ボタンをクリック。
いざ "Send pull request" をクリック~!おおおおお!

これはなかなか楽しいですなw


gitとの格闘w その3 リモート

そういえば呪文のように打っていたコマンド
$ git push origin master
がありましたがチュートリアルの次のページでようやくわかりました。
$ git remote
origin
最初にクローンしたので remote としてそのクローン元が origin として定義してくれてたんですね。で、master というブランチ(?)を origin に push するコマンドが呪文の正体だったと。なるほど。

別のディレクトリで同じリポジトリに大して clone してたほうからいくと
$ git status
# On branch master
nothing to commit (working directory clean)
$ git fetch
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git://localhost/sample
   aa7f9ba..2c64353  master     -> origin/master
$ git status
# On branch master
# Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
#
nothing to commit (working directory clean)
$ git pull
Updating aa7f9ba..2c64353
Fast-forward
 README |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
$ git status
# On branch master
nothing to commit (working directory clean)
fetch の時点では変更内容をとるだけでファイルの変更等はしないと。これもまあ当たり前ですかね。ブランチの情報とかもこの時点で持ってくるみたいです。その後変更を取り入れるなら pull で取り込むと。ふむふむ。
$ git log --pretty=oneline --graph
* 2c64353f62ac483887e773f58fe59315eeb3f2e1 Delete one more line
* aa7f9ba17d78193174415b97dae2b32264fc2061 Delete a line
*   0961ac4a66fbfcace7c0fc766544fa8da4b678dd Resolve conflict
|\  
| * 700f0dcca4861dd99ceb5dee12220d687c793433 Commit on branch
* | 9fb2424b4d9314e8d50f1bdb619d050b57675e07 Conflict!
|/  
* fda2f7be817a8534594a094b0b6e5b20e22d622d Commit
* ae419f95f40424091667aa750bf495b0665d133b Add another line
* 2698c25066c123921d74115385a52a627c067f30 Add one line
* 253133b619739070a06835181c4ed6c40aa7e08c initial commit
いい感じw

あとは実際に使うときに必要に応じてヘルプを見ながらすすめればいけそうですね。