AndroidのSDカードの扱いはちゃんとしよう

iSyncrでiTunesライブラリと同期したとき にやらかしてしまったんだけど、

PC 側で USB マスストレージとして Android を mount したままの状態で Android 上でうっかり USB 接続のモードをメモリーカードモードから充電のみに変えてしまうとまず確実に壊れる。

実際には SD カード自体は壊れてなくて中身は普通に見えるんだけど、Android からは read only mount しかできなくなり、 PC 上で初期化しないと使いものにならなくなるみたい。

ホーム画面にこの USB 接続時の挙動を切り替えるウィジェットを置いてしまったので操作の手順を間違えないように気をつけなければ。

これって SD カードを FAT32 じゃなくて ext3 とかにすれば案外大丈夫なんじゃないの？とか思わなくもないけど面倒なので試さない。

ところで Android のメモリーカードモードって面白い。SD カードを使わない部分は正常に動くけど使うアプリは動かなくなる。だから例えば iSyncr で同期中に「音楽」プレイヤーで SD カード内の楽曲を再生することはできない。Dropbox や Evernote などでも同様。なるほどなぁ。

Pyに触ってみた

昨日も書いたんだけどPython-FIT 0回目に参加してきた。その際、自分が Python の何を分かっていなかったか、何を期待しているかが少しはっきりしたので整理しておく。

Pythonも触れるようになっておこうと思った理由

Rubyを始めることにした何年か前の自分は、実は

PythonとRubyを比較してRubyを始めることに決めている

ので、Pythonを何も知らないわけではない。

いま改めて Python も使えたらいいかもな、と思った理由は勉強会で喋ってるうちに気づいたけど、

  1. Python 製のツールを一部直したり plugin 書いたりしたくなることはよくある
  2. GAE（要するにクラウド対応1）

という感じらしい。

積極的に乗り換えようとは思ってないけど、おいしいとこどりはしたいのだ。

インストール

  • 公式バイナリ
  • システム（OS）用のパッケージシステムから
  • ActivePython

とか使えばいんじゃね？ とりあえず CPython についてはそんなもんで、Pure Windows よりは Mac か Linux の方が簡単そうだねという話には落ち着く。

MacPortsの場合

$ port search python

すればたくさん出てくる。面白いのは

python_select

というパッケージで、これがあれば単に python と叩いたときに立ち上がる python を切り替えることができるので、安心して複数バージョン入れておくことができる。

はず。

充実してるっていうライブラリの恩恵はどうやって受けるの？

Perl なら CPAN, PHP なら Pear, 1.8 以降の Ruby なら Rubygems の話は必ず出てくるが、Python ではライブラリが充実しているという話だけはよく出てくるが、それを具体的にどう探してどうインストールするのかという話が少ないよね？

とりあえず当日その場にあった本にはライブラリの探し方やインストール方法については書かれていなかった。ライブラリの読み込み方は書いてあるんだけど、それだけだと標準ライブラリしか読み込めないから全然嬉しくない。いくら標準ライブラリが充実してても Web サービス用のライブラリは数多あり、かつ日々増えているはず。そういうものを見つけてインストールできなきゃ面白くないじゃん。

で、どうも聞いた話とその場でサクッと調べた範囲だと以下のような関係になっているっぽい。

言語RubyPythonPerlPHP
パッケージツールRubygemssetuptoolsCPANPear
パッケージリポジトリrubygems.orgPyPICPANpear2
コマンドgemeasy_installcpanpear

easy_install ってどうやって使うの？

でだ。この easy_install をどうやって使うのかがよく分からない。

実は OSX には最初から easy_install が入っている。しかしこれは MacPorts で後から入れた Python とは無関係である。

じゃあ MacPorts で入れた Python とマッチする easy_install を入手しないといけない。

しかしそもそも easy_install はコマンドであってパッケージ名じゃない。じゃあどのパッケージに入ってるのっていうのがよく分からず、例によって「インキー3な雰囲気」で、個人的にはイライラしていたのだけど、当の勉強会はそんなこと気にしない雰囲気だったので自分で勝手に調べた。あちこちのブログや本家ドキュメントを読んでいるうちに

easy_install というコマンドは setuptools というライブラリに含まれているらしい

ことが分かったので目的は setuptools をインストールすることに決まった。

egg 形式

egg 形式は jar みたいなもので、

  • 中にライブラリファイルのアーカイブを持っている sh スクリプト
  • Python を起動して必要な処理を走らせることができる

ので、

$ ./XXXXX.egg

や

$ sh XXXXX.egg

でライブラリのインストールができる。egg 内で Python のバージョンを決め打っているものがあるので、自分の使いたいバージョンに合わせた egg を落としてきて実行すればよい。今回は setuptools を入れたいので

Python Package Index : setuptools 0.6c11

から目的のアーカイブを落としてきて実行する。

ez_setup.py

setuptools に関しては ez_setup.py というスクリプトも用意されていて、これを実行するとよいという話も見かけた。で、これは PyPI じゃなくて以下にある。

http://peak.telecommunity.com/dist/ez_setup.py

Rubygems や rubyforge と関係なく

setup.rb

が存在するのと似たようなものか。

これを実行すると自動的にいいバージョンの setuptools を落としてきてインストールまでしてくれるらしい。結局動かさなかったのでよく分からないけど、中身を見ると shebang が

#!python

なので、複数の Python を入れている場合には注意が必要だと思う。個人的にはこういう場合はバージョンを明記してある egg を落としてきて実行する方が安心。

MacPorts用のsetuptoolsはMacPortsで入れればいいじゃん

最後になって気づいたけど、これがいちばん簡単だね。当たり前だけど。最初からパッケージシステムに依存してるんだから、そのまま走るのが正解。そうでない方法を混ぜると面倒が増える。ただし、tcl を入れたり、えらく遠回りするのでさっさと使いたい人には不向き。

まだ結局 easy_install 使えてない easy_install-2.6 を使うことにした

MacPorts で setuptools を入れるところまでは終わったんだけど、これをやってもインストールされるだけで後から入れた easy_install に PATH が通っていないので、

結局立ち上がるのはシステム標準の easy_install

という状態は変わらなかった。うーん、面倒くさい。この話はまた今度。上に挙げた python_select で切り替えてくれればいいのにね。

と、思ったら

/opt/local/bin/easy_install-2.6

っていう link を見つけた。MacPorts で入れるとこの link が作られるのかな？ ちょっとアレだけど Debian で Ruby を使うようなもんか。分かった、これにするわ。

  1. Ruby にも Heroku があるけど、Google という看板の大きさはね。やっぱね。 ↩

  2. および各所の pear channel ↩

  3. 陰気じゃなくて鍵のとじ込みね ↩

Preview での回転と Exif

Exif に縦位置、横位置の情報なんてあったのか。知らなかった。

まぁ以前使っていた GraphicConverter による回転では画素数が何かの倍数（8だったか？）でないと劣化する可能性あるよって警告出てたし、実際に回転させるより速いからこっちの方がいいのかも。

SourceForge.net: Spyc 0.3 beta is out

待てしばし。

遅さが気になってた人は今度は性能向上を感じると思うよっつー話なんだけど、フルスクラッチで書き直しているらしいのでテストが欠かせませんな。

つか時代は yaml.com の方なんだよな。Spyc 0.3 は PyYaml 互換になった…わけじゃないんだろな。中身は見てないけど。

説得スキル

多国語で書けるブログはどこ？ブログ124サービス【文字コード】全チェック

たださんは（内心は知らないけど）煽り1に対して真正面から論理的に反論していて、さすがだなぁと思うわけだけど、この記事については

煽りで問題が解決するとでも思っていたのだろうか？

というのがものすごく疑問。あり得ないと思うんだけど。問題点と傾向を明確にするという意味では今回の調査はそんなに悪くないと思うんだけど、なぜ全体の体裁は煽りなのかな。中には感情的に反応しちゃう人が当然出てきて、余計に話を進めにくくなると思うんだけどなぁ。

まぁ多言語対応で煽りを入れることができるくらいには、「多言語対応していないが完成度の高いアプリ」が多くなったという風に解釈することもできるんだけど、逆に多言語対応してても機能的に有用でなければ使われることはないんだしね。そういう意味では「ずいぶんと乱暴な話をするな」という印象はやっぱり拭えない。開発者は閉鎖的な us-ascii オンリーなアプリをあれこれ苦心しながら使っていたりするんだから。

では今回はどういう話に持っていくのがいいんだろう？ それはずばり、

私が自分を含め多言語対応のテスターを募って協力します

ではなかろうか。細かい理由はいろいろあると思うけど、多言語対応は明らかに開発のコストを上げるのだし、いくらかでも協力してくれる人の意見はかなりツールに反映されやすいと思う。

  1. まぁこの煽りもどこまで本気なのか分からないけど。 ↩

About

例によって個人のなんちゃらです