ドイツでの電源事情

危うく忘れるところでした。スーツケースを閉じた後に閉めるベルトみたいなやつを大きなほうから今回持っていく小さなほうに移そうとしたときに中からゴロンと出てきた、プラグ変換器。こんなやつでした。これがないとパソコンはじめすべての電気機器に充電できなくなってしまいます！

こちらあたりを参考にするとドイツはＣかＳＥのようですね。だったら今持っているやつで対応できるようです。一安心。

次は持っていくものの電圧対応です。上の変換器はあくまでも形状を合わせるためのものなので、１００Ｖ専用のものはつなげません。ってつなげるかも知れませんがどうなるかわかりませんｗ ほとんどのものは壊れるでしょうね・・・。なのでアダプター等の裏面をチェックです。

まずパソコン。これはたぶん世界共通だろうから大丈夫でしょうが一応。Input : 100-240V とありますね。問題なし。

次はコンセントからＵＳＢの電源を取るやつ。おお、これも AC 100V-240V とあります。すばらしい。ま、これは最悪パソコンを起動しとけばって話もあるのでだめだったら持っていかないだけですが。

これで大丈夫かな・・・と思ったら忘れてました。電気シェーバー。これは無理かな・・・と思ったらこれも 100V-240V でした。おお、Panasonic さんありがとう！ｗ

とはいえ変換プラグは１つしかないので同時に１つしか使えないんですけどね。あ、分岐するやつも持っていけばいいのか、と思って調べたら家にあるやつはみんな 125V 程度までですね。まあ寝るときにＵＳＢの充電して、起きたときにシェーバーをつないで使えばいいかな。

というわけで変換プラグを持っていってきます。

出張へ行くことになりました

急な話ですが、近いうちに１週間ほどドイツのハノーバーというところまで行くことになりまして。飛行機は羽田から１２時間ほどでフランクフルトに着くのですが、そこから新幹線みたいな ICE (Intercity Express)という電車に乗って２時間半ほどかけていくことになります。果たしてうまく到着できるのか？ｗ しかも着いてすぐホテルに寄る間もなくオシゴトです・・・ orz

で、この ICE ですが、DB BAHN のサイトから予約できます。空いてるか混んでるかもわからないので予約を・・・と思ったんですが、考えてみたら飛行機が定刻につくかもわからないので着いてから買ったほうがいいですね。テレコムスクエアさんでWiFiルーターを借りていくことにしたので、外出先でもネットが使える予定です。なのでわからなくなったときは iPhone で解決を試みますｗ

時刻表を見るときとかに必要な駅名。
フランクフルト空港駅：Frankfurt(M) Flughafen Fernbf
フランクフルト中央駅：Frankfurt(Main)Hbf
ハノーバー中央駅：Hannover Hbf

ちなみに、ハノー「バ」ーと書いてますが、おそらく拙いドイツ語の知識を活用すると現地での発音はハノー「ファ」ーなはずですね。Vettel が「ベッテル」ではなく「フェッテル」のほうが近いというのと同じです。帰ってきたらドイツ語にかぶれて「フェッテル」と言い続けるかも知れませんｗ

xrdp でターミナルの補完時に待たされる件

ちょっと前に書きましたが、今自宅サーバーに接続するには xrdp 経由のリモートデスクトップで接続しています。いちいち Windows マシンに VNC クライアントを入れなくていいので重宝しているのですが、今のところ唯一かつ致命的な難点がありまして。それは

”ターミナルを開いて補完すると遅いことがある”

というものでした。とにかく接続したときに例えば

$ ls / <TAB><TAB>

などと打つと、普通はさっと / 直下のディレクトリやファイルが列挙されると思いますが、このときなぜか1秒程度待たされるのです。

$ ls /usr/loc<TAB>

のように候補が１つしかないものはさっと /usr/local とかになってくれるんですが、

$ ls /usr/li<TAB>

のように /usr/lib /usr/lib64 /usr/libexec 等複数の候補があったり、まったく候補がないような場合も同様に１秒程度待たされた後に /usr/lib まで補完されます。

どうにもストレスするので、使うの止めようかとも思ったんですが、VNCよりクリックしたときのクリック感（？）とかがコンソールからログインしてるときに近いとか、セッションがないときにも勝手にあげてくれるとかいいところもあるので原因を探っていました。そして今日ようやく見つけました！ググってもあまり出てこないところを見るとあまりみなさん気にしてないのか、こんな環境あまりないのか、はたまた私の何かの設定のせいで会社のサーバーも自宅のサーバーも同じような状態に陥ってるのかわかりませんが、とにかく解決方法です。

解決方法は

gnome-terminal の Preferences で "Terminal bell" をオフにする

でした。なるほど、音まわりでしたか。リモートデスクトップってリモートのマシンの音もローカルに持ってこれましたよね。そのあたりに何かありそうです。

なぜこれにたどり着けたかというと、この補完が遅いという事象、今のところは gnome-terminal を使ったときにしか観測されてないんですね。なので別のターミナルを入れてみようかということで、terminator というものを入れてみました。これはこれでなかなかよさげなツールなんですが、これを使った場合、補完は遅くなかったのです。おお、解決したか！と思ったんですが、補完した瞬間（というか上の例で補完が遅い瞬間）、terminator に何かアイコンのようなものが表示されます。

 なんでしょうね、これ。と思って急いでクリックしたりなんかしてたんですがわからない。そこでデバッグオプションをつけて実行してみたところ、こんなログがでました。

ConfigBase::get_item: ConfigBase::get_item: urgent_bell found in profile default: False
ConfigBase::get_item: ConfigBase::get_item: icon_bell found in profile default: True

ベル・・・。もしや！？と思って先ほどの設定をしたところ見事に解決した、というわけです。めでたしめでたし。

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 に余裕がある時にどうぞ。

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 につなげることも確認しました。

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

ケースファンを交換

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

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

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

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

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

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

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

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

まずは Twitter のアカウントのウィジェットの設定の画面に行きます。 そこで「新規作成」をクリックします。今回はハッシュタグによる検索なので、以下のようになりますね。いろいろ設定を変えると右のプレビューが変わります。

  これを保存すると、右下に javascript を含む HTML が生成されます。これをサイトに貼り付けます。気付かれた方もいるかと思いますが、上の設定にはドメインが必要です。１つ作っていろんなとこで使うってのはできないわけですね。それはいいんですが、開発するときにローカルで見れないと面倒だなぁと思っていたら、ちゃんと

By default we also support the "localhost" domain for testing on your local development environment.

とありました。なので安心して開発環境で試せます。実際張ってみると

完成！簡単ですね。（@ar147ti さん友情出演ありがとうございますｗ）

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

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

git との格闘w その５ 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 を入れますか。そうだ、ここは思い切って７だな、７！ここから 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 がやってることと等価ではないかと。

ようし、準備完了～！

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

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

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

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

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

・・・とりあえずデモの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" をクリック～！おおおおお！

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

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

そういえば呪文のように打っていたコマンド

$ 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

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

git との格闘w その２ いろいろ変更

さて、サーバーにも接続できるようになったところでチュートリアルに戻ります。さっき clone したところに移動して、

$ vi README        <-- 適当に編集
$ git commit -a
[master 2698c25] Add one line
 1 files changed, 1 insertions(+), 0 deletions(-)

git commit をするとエディタが上がるので適当に commit のコメントを追加。これも git push origin master で push してみるとうまくいく。なるほど。

次はstaging。

$ vi README 
$ vi tmp/README 
$ git status
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   README
# modified:   tmp/README
#
no changes added to commit (use "git add" and/or "git commit -a")

何か変更を作ってみた。一つ staging。

$ git add README 
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
# modified:   README
#
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   tmp/README
#

コミットしてみる。

$ git commit
[master ae419f9] Add another line
 1 files changed, 1 insertions(+), 0 deletions(-)
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   tmp/README
#
no changes added to commit (use "git add" and/or "git commit -a")

ほほう。１つはちゃんと commit されて、もう一つの変更はそのままと。さっき何も考えずに commit -a としていたが、その -a は全部ファイルを commit しちゃうためのものだったとか。（それを知らずに -a して全部コミットされたアカウントはこちらですw その場合は git reset --hard HEAD~ とやると全部投げ捨てられる模様。）なるほどなるほど。この状態でまた push すると当然 commit されたものだけ飛んでいきます。

次はいよいよブランチ。

$ git branch
* master

作成。

$ git branch experiment
$ git branch
  experiment
* master

作成されました。

$ git checkout experiment
M tmp/README
Switched to branch 'experiment'
$ git branch
* experiment
  master
$ git status
# On branch experiment
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   tmp/README
#
no changes added to commit (use "git add" and/or "git commit -a")

なるほど・・・。さっき commit してなかった変更とかはそのままなんですね。当たり前か。

$ vi TODO
$ git add TODO 
$ git commit -am "Commit on branch"
[experiment 700f0dc] Commit on branch
 2 files changed, 3 insertions(+), 1 deletions(-)
 create mode 100644 TODO
$ git status
# On branch experiment
nothing to commit (working directory clean)

あれ、commit どこいった？

$ git diff master
diff --git a/TODO b/TODO
new file mode 100644
index 0000000..295f16a
--- /dev/null
+++ b/TODO
@@ -0,0 +1,2 @@
+Todo file
+
diff --git a/tmp/README b/tmp/README
index edb0724..3105724 100644
--- a/tmp/README
+++ b/tmp/README
@@ -1,2 +1,2 @@
 This is sample file 2.
-
+This is another line in another file.

とりあえず master との比較ではずれがあることはわかる。（コマンドがこれでいいのかは不明。）

$ ls
README  tmp  TODO
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
$ ls 
README  tmp

さあ conflict させてみますよ。

$ vi tmp/README 
$ git commit -am 'Conflict!'
[master 9fb2424] Conflict!
 1 files changed, 1 insertions(+), 1 deletions(-)

これで master と experiment がそれぞれ先へ進みました。マージしてみます。

$ git merge experiment
Auto-merging tmp/README
CONFLICT (content): Merge conflict in tmp/README
Automatic merge failed; fix conflicts and then commit the result.

おうふ・・・。ちょっと変更が近すぎましたかね。TODO のほうは成功したんですが tmp/README がだめでした。ファイルの中身はどうなってるかな？

$ cat tmp/README 
<<<<<<< HEAD
This is sample file 2 and more!.

=======
This is sample file 2.
This is another line in another file.
>>>>>>> experiment

解決するには編集して普通に add して commit だそうで。

$ vi tmp/README 
$ git add tmp/README 
$ git commit -am 'Resolve conflict'
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 4 commits.
#
nothing to commit (working directory clean)

それぞれの変更が入った状態の完成です。最後にワークに使った branch を消す。

$ git branch -d experiment
Deleted branch experiment (was 700f0dc).

git との格闘w その１ git サーバー on CentOS 6

気楽に Twitter4J の JavaDoc のリンク切れをドヤ顔で指摘したら、pull request してくださいとの返答をいただき、これまた気軽にりょうかいしたところ、やったことない人には壮絶に敷居が高そうなことがわかりましたｗ 自宅で１人で書いてるコードの変更管理なら CVS やら SVN やらで十分だし、仕事では某社のツールべったりだったし、目にはしたけど使ったことないんですよね、git。なのでもちろん github も見るだけでして。ここで諦めてもいいんですが、せっかくなので挑戦してみますか。まずは git から。

インストール

ふむふむ。git はコマンドラインでいろいろやるっぽいですね。もちろん IDE からもできるはずですがコマンドの理解から入るほうが理解しやすいですし。最終的にはせっかく買ったこの子から使いますよ。で、コマンドライン環境は・・・そんな時のために Linux サーバーがあるんですよ！ ええ！早速インストールです。

# yum install git
(snip)
Setting up Install Process
Package git-1.7.1-2.el6_0.1.x86_64 already installed and latest version
Nothing to do

既に入ってましたｗ

使ってみる

まあ何はともあれ使ってみよう。まずはこのへんを読んでみる。ポイントは分散開発環境では当然問題になる部分ですが”cheap branching and easy merging”という部分にありそうですね。

まずは全体の環境設定から。

$ git config --global user.name "Sdk0815"
$ git config --global user.email "***@***.***"

何かリポジトリを作ってみます。

$ mkdir -p git/sample
$ cd git/sample
$ git init
Initialized empty Git repository in ~/git/sample/.git/

適当にファイルを置いて

$ git add .
$ git log
fatal: bad default revision 'HEAD'
$ git commit -m "initial commit"
[master (root-commit) 253133b] initial commit
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 README
 create mode 100644 tmp/README
$ git log
commit 253133b619739070a06835181c4ed6c40aa7e08c
Author: Sdk0815 <***@***.***>
Date:   Fri Jan 4 13:55:45 2013 +0900

    initial commit

ふむ。何かコミットできたようです。

・・・というか、ここから先はサーバーとやりとりするようになってる。せっかくだから自宅サーバーも git のサーバーとして使えるようにしてみるか？

サーバー構築

今度は

# yum install git-daemon
(snip)
Running Transaction
  Installing : 2:xinetd-2.3.14-35.el6_3.x86_64         1/2 
  Installing : git-daemon-1.7.1-2.el6_0.1.x86_64       2/2 
  Verifying  : git-daemon-1.7.1-2.el6_0.1.x86_64       1/2 
  Verifying  : 2:xinetd-2.3.14-35.el6_3.x86_64         2/2 

Installed:
  git-daemon.x86_64 0:1.7.1-2.el6_0.1
Dependency Installed:
  xinetd.x86_64 2:2.3.14-35.el6_3

Complete!

入ってませんでしたのでめでたくインストールw /etc/xinetd.d/git を開き、disable = yes を no に変更し、xinitd を restart。

ん、これだけ？よくわからんのでとりあえずリポジトリを作って進んでみよう。ユーザーも特に作られてないし・・・。

# cd /var/lib/git/
# mkdir sample
# cd sample
# git init --bare --shared

さっきのプロンプトに戻って

$ git remote add origin git://localhost/sample
$ git push origin master
fatal: The remote end hung up unexpectedly

ですよね・・・。そううまくいくわけはなく。/var/log/messages を見ると

git-daemon[25672]: 'receive-pack': service not enabled for '/var/lib/git/sample'

なるほど。さっきの /etc/xinetd.d/git の server_args に --enable=receive-pack を追加して xinetd を再起動してみる。

$ git push origin master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 333 bytes, done.
Total 5 (delta 0), reused 0 (delta 0)
error: unpack failed: unpack-objects abnormal exit
To git://localhost/sample
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'git://localhost/sample'

めげるな！またログを見ろ！

git-daemon[25747]: error: insufficient permission for adding an object to repository database ./objects

ふむ。さっきの /var/lib/git/sample には objects ってディレクトリがあってそこは root の持ち物になってる。xinetd は root だが・・・ってそうか！また /etc/xinitd.d/git に戻り、ユーザーをチェックすると、nobody になってる。なるほど、では git ユーザーを作って再挑戦。ついでに repository のディレクトリも ~git/repo に変更。xinitd を再起動していざ。

$ git push origin master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 333 bytes, done.
Total 5 (delta 0), reused 0 (delta 0)
To git://localhost/sample
 * [new branch]      master -> master

おおお？うまくいったかな？確認。

$ cd ..
$ ls
sample
$ rm -rf sample
$ ls
$ git clone git://localhost/sample
Initialized empty Git repository in ~/git/sample/.git/
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 5 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (5/5), done.
$ ls
sample
$ cat sample/README 
This is test file.

おおお、できましたね！

Linux で日本語

実際のところそんなには利用頻度は高くないですが、Linux 環境でも日本語を入力したくなることはあります。たとえばここに書くときとかw これまでは Linux で作業したやつをコピペして Windows 上で書いてたのですが、いい加減面倒くさくなってきました。 なので大した手間ではなかったので手順を書いておきます。

インプットメソッド

インストールしたときに日本語を選んでおけばよかったのですがそんなつもりもなかったので英語でインストールしてました。でもその状態でも IM とかはちゃんと入ってるようですね。

1. gnome 上から System -> Preferences -> Imput Method を選ぶ
2. iBus を選び、Imput Method Preferences をクリック
3. Imput Method タブで Japanese -> Anchy を選び、Add
4. ログアウトしてログインしなおす

これで日本語入力ができるようになるはずですし、直接コンソールから入ってる場合は Ctrl+Space や半角全角キーで日本語モードになるはず。

しかし私の環境では Linux マシンにはディスプレイ等はつながっておらず、常に VNC で作業してる状態なのですが、VNC 経由では Ctrl+Space は効くものの半角全角は効かない。しかも Ctrl+Space って IDE/エディタでは重要なキーバインドなのでやはり半角全角で変換したいです。なので先ほどの Input Method Preference に戻ります。

5. Keyboard Shortcuts の Enable or disable : のところの ... をクリック
6. Keycode の ... のところをクリック
7. ダイアログが出てるところで半角全角キーを押す
8. 出てきた「Hankaku」と「Zenkaku」を "Release" のチェックを外して Add

VNC の設定等で回避できるのかもしれないのですがキーコードが Hankaku か Zenkaku になるようですね。

これで日本語の入力ができるようになりました。

フォント

入力はできるようになりました。しかし表示は相変わらず昔のコンピュータみたいです。もう少しマシなフォントを入れますか・・・。おお、今時はIPAフォントが base からとれるんですね。

# yum install ipa-*-fonts
(snip)
Installed:
  ipa-gothic-fonts.noarch 0:003.02-4.2.el6           ipa-mincho-fonts.noarch 0:003.02-3.1.el6          ipa-pgothic-fonts.noarch 0:003.02-4.1.el6         
  ipa-pmincho-fonts.noarch 0:003.02-3.1.el6         

Complete!
$ fc-list  | grep IPA
IPAGothic,IPAゴシック:style=Regular
IPAPGothic,IPA Pゴシック:style=Regular
IPAMincho,IPA明朝:style=Regular
IPAPMincho,IPA P明朝:style=Regular

楽々ですね。ってもそんなに綺麗にはなってない気がしますが・・・。文字が少しぼけた感じなのはフォントを変える前からですが。

#f1yosou : HRD への移行

というわけで、HRD への移行を行ってみます。基本はガイドに従えばいいはず・・・。

Task	Status	Remarks
Duplicating Your Application	Done
Deploying Your New HRD Application	Done
Using the Migration Tool	Done	結構待ちます。

あれ、結構簡単でした？ｗ

しかし実際は index の定義をちゃんと書いてるわけではない（Eclipse 上で実行していると自然と生成される定義を使っていた）ので、最初に新しいアプリケーションのほうに deploy したら索引が全くない状態になってしまいました。なので開発環境で適当に実行して生成された定義を使ってもう一度 deploy。今度はうまくいきました。

果たして migration した元のアプリケーションは消してよいのか。消さないと１０個までというアプリケーション数の制限を圧迫するんだけど・・・。

同様にチェックしたＤＭログ（仮）は実はバグがあってだいぶ前から動いてなかったっぽい。けど何も言われてないってことはそろそろ消してもいいかな？政治家的にいえば「一定の役割は果たした」のでｗ

#f1yosou : 現状の説明

みなさんご存知の通り #f1yosou の中の人をやっているわけですが、今年もやるためには以前ツイートしたように、

もし来年続けるとした場合の備忘録。HRD対応。Twitter API V1.1対応。公式アカウントによる参加者のフォロー＆ＴＬ読み込み、ＤＭによるお題投票。ログインシステム廃止。解析のオフロード。トップページの静的ファイルへの変更。

— クルさん (@Sdk0815) 11月 28, 2012

といった作業が必要になります。作業を分類すると

必須の作業

• HRD 移行
• Twitter API V1.1 対応

ほぼ必須の作業

•  公式アカウントによる参加者のフォロー＆ＴＬ読み込み（Twitter API V1.1でリスト関連の API が変更になったため、どのみち何らかの作業が必要なため）

できればやりたい作業

• ＤＭによるお題投票
• ログインシステム廃止

といった感じです。

このうち Twitter API V1.1 対応については Twitter4J V3.0.3 への更新が完了したので基本問題ないはずです。なので残る作業は HRD 移行とフォロー＆ＴＬ読み込みです。

ちなみにHRDなんじゃそれと言う方も多いと思うので一応説明しておくと、#f1yosou のサイトは Google App Engine for Java といういわゆる PaaS サービス（の無料部分を！）利用しています。しかし #f1yosou サイトを立ち上げた当時にはデータストアとして Master/Slave というものが使われていたのですが、それが deprecated となり、HRD (High Replication Datastore)に１年以内に移行する必要が出てきました。一応別のアプリケーションとして新たに同じコードを deploy したらちゃんと HRD 上でも動いたので移行作業さえ終われば問題はないはずですが・・・。面倒そうな雰囲気だけがありますｗ

さて今年の開催も含めてどうするか。悩みどころです。

RAID と LVM と 4K セクタ

フォロワーさん（いつもありがとうございます！）から教えていただいた情報。

LVM on RAID するときの注意点

そういえば（爆）使ってるディスクたちは Western Digital のいわゆる Advanced Format、つまり4096バイトセクタを採用しているディスクたちでした。もともと512バイトが一般的だったので、それを前提としたフォーマットを特に考えないで使ってしまうとパフォーマンスが劣化すると言うやつですね。まあぶっちゃけるとサイズにばかり目が行ってて忘れてました。 orz

で、ようやく全ステップが完了したのでのんびり（おい）対応していこうかなぁと。また無駄なデータの移動とかしちゃうけどね～。楽しいからいいもんね～。などと自分をごまかしつつ。

ディスク全体をRAID1にしてる場合

まずは上記のリンクにあるように、ディスク全体を RAID 1 にしてる人。そんなことしてるわけが・・・ありました。うーむ。まずは RAID の superblock のバージョンですが、

# mdadm --detail /dev/md4
/dev/md4:
        Version : 1.2

おうふ・・・。お勧めの1.0なんかにはもちろんしていない。上のリンクでは、1.0だとmetadata の位置が領域の最後方となるため、データ領域がディスクの先頭＝4096バイトセクタの先頭ということですよね。えー、でも1.0より新しい気がするのに問題あるとか納得いかない感じなのですが・・・。1.2とはどういうものかというとこれによれば、superblock の場所が

4K from the beginning of the device

とあります。1.0だとたしかに at the end of device とあるのでデータ領域は先頭のようです。しかしどう読んでも superblock の長さもわからないのでデータ領域がいくつから始まってるのか不明。いろいろ調べたら mdadm で調べられると。コマンド発行対象のデバイスはディスク自体であることに注意です。

# mdadm -E /dev/sdc
/dev/sdc:
        Version : 1.2
(snip)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors

たしかに superblock は 8 sectors = 512x8 bytes = 4096 ですね。でも Data Offset はちゃんと 2048 sectors = 512x2048 bytes で 4K セクタに合っているではないですか！ＧＪ！（であってますかね？ｗ）

なので RAID のほうはこのままで OK と。次はPV（物理ボリューム)のほうです。 これもデータ領域がどこから始まってるかが問題。

# pvdisplay --verbose /dev/md4
    Using physical volume(s) on command line
  --- Physical volume ---
  PV Name               /dev/md4
  VG Name               vg_data
  PV Size               2.27 TiB / not usable 1.64 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
(snip)

うーむ。これもまたデータ領域がどこから始まってるのかわからない。man pvcreate 等を見ていたら、pvs でどこから始まってるのかがわかるそうな。

# pvs -o +pe_start
  PV         VG      Fmt  Attr PSize   PFree   1st PE 
  /dev/md4   vg_data lvm2 a--    2.27t      0    1.00m

おお！？これって最初のPEが1Mから始まってるってことですよね？ということはこれも4KにアラインしてるということでＯＫ！（でいいんですかね？ｗ）そして PE の単位は上で調べたとおり4Mなので当然4Kにアラインします。というわけで、結論。

 ディスク全体を RAID 1 にしたものについてはこのまま運用！ｗ

 あってるかどうか実験しようもないのであくまでも推察ですが・・・。結局のところ勝手によきにはからってくれるようないい時代になったってことですかね。

パーティションを切ってRAID1してる人たち（>2TB)

次はパーティションを切ってる場合の調査です。これはさんざいわれてましたね。fdiskを使うときに。

# fdisk /dev/sde

WARNING: GPT (GUID Partition Table) detected on '/dev/sde'! The util fdisk doesn't support GPT. Use GNU Parted.


WARNING: The size of this disk is 3.0 TB (3000592982016 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID 
partition table format (GPT).


The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): q

・・・って新しく買ったディスク、３ＴＢなので fdisk を使おうとすると警告が出ます。というか警告多すぎｗ そのまま使うと正しく認識されなかったりさんざんな目にあうとか。実際 2.5TB のディスクを Windows につけたら謎のパーティション構成になってました。そちらは dos 形式の MBR を gpt に変更したら直りましたけど。

で、今回はいよいよ上の警告でお勧めされている parted を使いました。なんか使ったことないので怖いぞｗ parted で mkpart を実行すると、もう画面はどっかいっちゃったので見せられませんが、「このままだとパフォーマンス悪いよー」的な警告が。その対策としては「ユニットをMiBにすればいいよ」と。なので u MiB をしてからパーティションを作成すると何も言われずに作成されます。果たしてこのパーティションは 4K バイトに沿っているのでしょうか？

(parted) u s                                                              
(parted) print                                                            
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sde: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start        End          Size         File system  Name  Flags
 1      2048s        3907028991s  3907026944s                     raid
 2      3907028992s  5860532223s  1953503232s

ユニットをs（セクタ）にして print してみたところ、ちゃんと開始が 2048s になってました。ということでこれもＯＫだし、RAID の superblock も

# mdadm -E /dev/sde1
/dev/sde1:
(snip)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors

なのでこれも問題なし！（ですよね？ｗｗ）というわけで、結論。

 3TB で RAID 1 にしたものについてもこのまま運用！ｗｗ

 パーティションを切ってRAID1にしてる人たち（ブート）

さて最後に残った一番怪しそうなところです。今回 CentOS を新たにインストールしたとき、インストーラの時点で RAID のパーティションを作成してインストールしました。ここが一番うまくいってなさそうな気配です。ここを上と同様にチェックしてみます。

(parted) u s                                                              
(parted) print                                                            
Model: ATA WDC WD20EARS-00M (scsi)
Disk /dev/sda: 3907029168s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start       End          Size         Type     File system  Flags
 1      2048s       1050623s     1048576s     primary  ext4         boot, raid
 2      1050624s    17827839s    16777216s    primary               raid
 3      17827840s   554698751s   536870912s   primary               raid
 4      554698752s  3907024064s  3352325313s  primary               raid

まずいきなり見えた１から2048セクタなのでいい感じ？ほかもすべて 2048 (64) の倍数から開始しているのでこれもよさそうな感じではないですか！（本当にいいんですよね？ｗｗｗ） RAID の superblock も同じように 2048 sector から開始しているようです。なんだすばらしいじゃないですか。ちなみに partition 3 は / 用に切ったパーティションなんですが、この人はなぜか metadata 1.1 になってます。インストーラから作る /boot でないやつは 1.1 になるんですかね。

というわけで、結論。

 インストール時に作ったものについてもこのまま運用！ｗｗｗ

 というわけで、今現在ささっているすべてのディスクについてこのまま運用するという結論が出ました。めでたしめでたし。

（間違ってるところあったらぜひ指摘していただけるとうれしいです。）

Step 9-11 : 完了

さていよいよ最終ステップです。

9. もともと VG に入っている 1.5TB の HDD を抜き、新たに 3.0TB と交換
10. 開発機から 1.0TB のディスクを抜いて刺し、3.0TB の RAID 1 を VG に追加
11. 開発機に 2.5TB、1.5TB を刺し、1.5TB RAID1 + 1.0TB にする

これも技術的には特に問題なし。mdadm, pvcreate, vgextend 等を使って追加します。開発機のほうも移動したディスクに cygwin の rsync で全コピーしてドライブレターを付け替えるだけで問題なく移行できました。

これにてストレージに関しては

Server      : RAID1 6.5TB
Dev Machine : RAID1 1.5TB + non-RAID 1.0TB

となりました。めでたしめでたし（？）