limitusus’s diary

主に技術のことを書きます

MacBook Air 11インチ用ケース

4年くらい前に800円くらいで買ったケースがだいぶボロボロになってしまったので、いっそのこと、ということで新しいのを買うことに。
近所の電器店で眺めて、収まりのよさそうなやつを選択。

いい感じ。

だが、結果的にはAmazonで買った方が安かったじゃないか。。。

MacのDockが暴走した

最近メインで使っているのはMacbook Air (Lion) なのだけど、数日前から妙に動きが重くなり、ファンもうるさくなったのでちょっと調べてみた。
まずhtopで長めてみると Dock がCPU 100%食っていた。原因はまずこれだ。
減少としては17秒くらいに1回DockがSIGABRTを受けて死んで、また起動してCPU 100%に貼り付く。を繰り返す状態だった。

検索したところ、VMware関係が原因だとかいうのが目立つが、どうやら違うらしく、最終的に以下の記事に行きついた。
https://discussions.apple.com/thread/3684623?start=0&tstart=0

まずは ~/Library/Preferences をまるっとbackupしておく。
で、とりあえず ~/Library/Preferences を消してみる。
そうすると次にDockの再起動時には直るので、ここが原因らしいと確認できた。
あとはbackupを戻して再起動して再現させ、設定ファイルを消しては再起動後に直るかどうかを順番に試していくだけ。

今回は最終的に

rm ~/Preferences/ByHost/com.apple.dock.AE697267-4B85-5FC7-BF96-EBE7847EF12B.plist

により落ち着くことが確認でき、復旧完了。

あー大変だった。

YAPC::Asia 2012にStaff参加してきた

日本で最も大きなPerlの会議、YAPC::Asia 2012に参加してきました。
去年は学生チケットで参加させていただいたのですが、今年はボランティアスタッフとして。

ということで、スタッフをやりながら印象に残った発表などを書いていきます。
前夜祭の日は参加できませんでしたが、2日目と3日目はフルで参加しました。

Kickoff Meeting

これはYAPC::Asia 2012の数ヶ月前に開催された、スタッフの顔合わせです。
ボランティアスタッフ募集に応募した人が一度集まり、名刺交換したり親睦を深めたり。
ここで多くの人がFacebook経由でゆるーく繋がり、連絡が取りやすくなりました。

LINE

「当日は LINE で連絡とりあいましょう」という通知がきました。
みんなスマホ持ってるし、IRC よりカジュアルに連絡が取れました。通知もくるし。
それまではスタッフ用 IRC で込み入ったやりとりをしていましたが、当日はこっちの方が楽だったのでよかったと思います。
結果論ではありますが、今年のネットワークではIRCのポートが遮断されていたので、むしろHTTPだけのLINEが好都合でしたね。LINE++

スタッフみんなが入るグループトークと別に部屋ごとにもグループトークをつくり、スタッフ同士の緊密なやりとりがそこでされていました。
発表中にでも離れたスタッフに空調の調整、マイク調整など、連携をとることができました。
スタッフみんなが#yapcasia をウォッチできていたわけではなかったのですが、見ていた人から「〜の部屋寒いって」などの情報が伝えられ、調整していました。

1日目

YAPC::Asia 2012 スタッフの朝は早い。
8時に現地に集合です。9時には受付を開始し、10時くらいには各部屋の机や椅子の配置、音響チェック、電源の確保、録画録音の準備、椅子ポンサー広告貼り、プロジェクタ投影テストなどを済ませておく必要があります。
特に録画録音はミスすると後日の映像公開に支障が出てしまうので、ミスのないようにどうするか、その場でプロトコルを決めました。結果的に非常にうまくいきました。

発表者の方には発表に関する連絡(持ち時間、ベル鳴らす時間)をします。1日目の中教室(Room 1)は日本語を話せない発表者の方が多かったので、全てはスタッフの英語力にかかっていました。話せてよかった。

Impressive Presentation

1日目で自分にとって最も印象的だった発表は Tim Bunce の Profiling memory usage of Perl applications です。
LLのメモリ消費は通常ランタイム実行系に任せてしまい、多くの場合プログラマは気にしなくていいのですが、いざメモリ消費が深刻な問題となったとき、それを突き止めるのが困難であるという面もあります。
この発表ではそれを分析するための基礎知識としてPerlにおけるメモリ消費がどのように行われているかという解説に始まり、あるPerlプロセスがどこでどれだけのメモリを消費しているかを可視化するツールの実演も行われました。資料によると9/30中に公開されるようです。
質疑ではLarryからの突っ込み回答などもあり、盛況なセッションでした。

実は他の発表、眠気に勝てずちゃんと見られていません。あとで録画を見ます…

懇親会

懇親会は大盛況でしたね。去年と比べても人が多かったように思いました。
同僚やスタッフ、その他知り合いとゆっくり話すことができました。
食事は豪華でしたね。来年もできるのかな…?

2日目

Impressive Presentations

午後の id:TAKESAKO による発表『Perlで始める!初めての機械学習の学習』が非常に面白かったです。
機械学習のバイブルともいえるビショップ本を読んでいた話、それを読むための基礎数学をまとめた話、そしてKinectを使ったデモなど、明瞭なプレゼンが人気を博していました。

特別教室で行われた @nontan___ の『Perlでひとつサービスをつくってわかったこと』も印象に残りました。
本当にプログラミングの経験が一切ない人が、3ヶ月間で1つWebサービスを作ってみたとき、何に躓くのか、紹介してくれました。
個人的には12年くらい前、自力でプログラミングを覚えたときの自分を見ているようで、懐しい気分になりました。似た気分になった人もいるのではないでしょうか。
発表後、つい話しかけてしまいました。

Closing

Closing session は我らYAPC::Asia スタッフを取り纏めてくださっていた id:lestrrat です。
過去にない規模のイベントになり、そこでスタッフとして参加できてよかったです。
この最後にスタッフ紹介という感じで壇上に上がったのですが、ほぼ満席になったメインホールは壮観でした。

片付け

イベントが終わり、参加者がだいたい帰ったところでスタッフは片付けです。
忘れ物の集計、発送しておく必要のある荷物をまとめるなどして、借りていた会場のセッティングを元に戻して完了です。
今年は人数も多く、非常に速く作業ができたようです。
50個くらいある椅子を「片付けるの手伝ってくださーい」といった数分後には完全に片付いていました。
数の力ってすごい。

打ち上げ

全てが片付いてスタッフが撤収したあとは、スタッフみんなで打ち上げです。
おいしい肉を食べながらお酒を飲んで、盛り上がりました。
そこでもいろいろ面白いことは起きていましたが、それはスタッフだけの秘密です。


そんな感じで、このエントリをもって僕の YAPC::Asia 2012 は無事に終了しました。
来年も大丈夫そうであればまたスタッフとして参加できればなと思っています。

運営のみなさまお疲れ様でした。
そしてご来場くださった皆様、ありがとうございました。

Githubの証明書問題をまっとうに解決する

github SSL certificate problem - A Life Less Ordinary と同じ問題に遭遇してしまったので、まっとうな解決策を探ってみたところ、無事に解決できたのだが、どうやら同じようなことをしているページが見つからなかったので書いておく。

error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing https://github.com/......
  • 問題はGithubHTTPSで使われているSSL証明書を発行しているところ(CA)が変わったが、たまたまそのgitコマンドは Root CA のセットが古く、新しいCAの証明書が入っていなかったこと。
  • したがって、根本的な解決策としては新しい Root CA のセットを用意して、gitがそれを参照するようにしてあげればいい。

まず、そういう Root CA のセットをとってくる。

curl http://curl.haxx.se/ca/cacert.pem -o ca-bundle.crt
  • /etc/pki/tls/certs/ に置いたりするみたい。今回は全然関係ない適当なところに置いた。

あとはgitが参照する Root CA セットのファイル名をどこに置くかということになる。
git-config(1) によると、どうやら http.sslCAInfo でいいらしい。

ということで、たとえば

git config --global http.sslCAInfo /home/limit/ssl/ca-bundle.crt

みたいなことをするか、適当に書くなどして、~/.gitconfig は以下のようになる。

[http]
    sslCAInfo = /home/limit/ssl/ca-bundle.crt

と、ここまで書いておいて、実際やってるページをみつけた。 Github のプライベートリポジトリからcloneするときにSSLエラーがでた場合の対応策 - Goodpic

Twitterの過去履歴を消去するtwdelを書いた

今まで数多くのTwitterクライアントアプリが書かれてきて、誰もが様々な方法で手軽にPOSTできるようになっている。
一方、過去の自分の歴史を抹消したいと考える需要もあるにもかかわらず、その需要に応えるアプリケーションは見当たらない。

そこで、今回 twdel というアプリケーションを実装した。
limitusus/twdel - Github

細かい必要モジュールなどはREADME.mdを読んでもらうとして、使い方は至って簡単である。

./authenticate

によってOAuth認証を行い、アクセストークンとアクセスシークレットを記録する(パスワードはもちろん保持しない)。
認証をやり直すときはいつでもこのコマンドを実行できる。基本的には最初の1回だけ。

./twdel

によって実際の消去を実行する。デフォルトではAPIの許す限り、2ページ目から100ページ目まで(0-originで)を消去しに行く。
オプションにより

./twdel -s 5 -e 10

などとすれば、5ページ目から10ページ目までの消去もできる。

ライセンスはMITです。
過去の自分を隠したい方はどうぞ。

libsqlite3.so を差し替える

ちょっと聞かれたので調べてみた。

目的

オリジナル libsqlite3.so.0 を実装したので、これを /module/libsqlite3.so.0 とし、 Python から使えるようにしたい。
Python

import sqlite3

とすると最終的に /usr/lib/python2.7/lib-dynload/_sqlite3.so が読まれるので、

ldd _sqlite3.so

としたときに libsqlite3.so.0 が /module/libsqlite3.so.0 を指すようにすればよい。

普通なら

動的ライブラリなんだから LD_LIBRARY_PATH を設定するのがまずは常識。

LD_LIBRARY_PATH=/module

しかし変わらない。

RPATH

実は _sqlite3.so には RPATH という情報が書かれていて、これが動的ライブラリの場所を示している。
manpage dlopen(3) を読んでもらうとわかるが、動的ライブラリはまずこの RPATH を検索し、ここにあればこれを使う。
LD_LIBRARY_PATH が読まれるのはその次の優先順位なのである。
したがって、この場合 LD_LIBRARY_PATH は機能しない。

RPATH を消す

以下の情報は多分に Frank's Geo-Geeking: RPATH, RUNPATH and LD_LIBRARY_PATH を参考にしている。
RPATH 情報は chrpath(8) により見ることができる。

chrpath /usr/lib/python2.7/lib-dynload/_sqlite3.so 
/usr/lib/python2.7/lib-dynload/_sqlite3.so: RPATH=/usr/lib/i386-linux-gnu

ここで気付いた。
_sqlite3.so の RPATH がないバージョンを作り、これを Python から読むようにすれば?」

cp /usr/lib/python2.7/lib-dynload/_sqlite3.so /module/_sqlite3.so
chrpath --delete /module/_sqlite3.so
export LD_LIBRARY_PATH=/module
ldd /module/_sqlite3.so

これで /module/_sqlite3.so が /module/libsqlite3.so.0 を読むようになってくれた。
もちろん Python から使うときには

export PYTHONPATH=/module

も忘れずに。

ちなみに

libpthread.so.0 ではこんな問題は起きない。というのも、libpthread.so.0 は RPATH で指定されたディレクトリではないところにあるからである。
この問題は SQLite3 モジュールが Python 組込みであることによっているのではないだろうか。

iccをインストールした記録

Intel C コンパイラって買わないと使えないのかと思ってたけど、非商用ならば無料でインストールできることがわかったので実際にやってみた。

ダウンロードまで

これは 2011 年 11 月 18 日の操作記録だが、サイト更新に伴いページ構成が変更されたりリンクが切れる可能性がある。

C Compiler & C++ Compiler Suite from Intel - Intel® Software Network

この辺に IntelC/C++ 系開発用ソフトウェアがまとめられていた。
画面上部の Tools & Downloads から Free Non-Commercial というのを選ぶ。

Non-Commercial Software Development - Intel® Software Network

ここで非商用利用の規約に同意する。

その後いくつかのソフトウェアを選択できる。ここでは Intel® C++ Composer XE 2011 for Linux を選択した。
あとは必要事項を入力すればダウンロードできるようになる。

ライセンス番号もさりげなく画面に表示されるので忘れずに控えておく。

インストー

tarball を落としてきたので、適当に展開し、その中の ./install.sh を実行する。
あとは画面の指示に従ってライセンス番号やインストール先を指定していけばいい。
root 権限があればシステム領域にインストールできるし、今回はユーザ領域($HOME/intel 以下)にインストールした。
RPM 系のディストリビューションではなかった & tarball の中には rpm ファイルもあったが、特に問題なくインストールできた。