here’s an aside…
here’s an aside…
Masaaki Shibata blog
here’s an aside…
てすてす
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
色は匂へど散りぬるを、わが世誰ぞ常ならむ。うひの奥山けふ越えて、浅き夢見し酔ひもせず。
ご報告が遅れましたが、窓の杜でひみつメモ帳を紹介していただきました。中村さんありがとう、あなたがお友達でなければ日の目を見ることはなかったでしょう。
そしていま見ると掲載されてるファイルがドット見出し形式なのが最高に恥ずい。なんだろ、emptypage.jp にあるとなんとも思わないのに外に出てると部屋の写真に洗濯物が写っちゃってるみたいなこっぱずかしさ。まあまだ直してないけど。
ありがとうございました。
そのひみつメモ帳の Mac 版を公開しました。ひみつテキストを Dropbox に置いて Windows 版と共有したりしてください。とりあえず Mountain Lion では動いています。もともとアプリ自体は一年以上前から作ってたんだけど、やっと最新の SDK でコンパイルし直しました。
以下余談。
Mountain Lion で(正確には Lion から)Gatekeeper が付いて、ダウンロードした署名なしのアプリケーションは簡単に起動できなくなった。署名はアップルのデベロッパー・プログラムに加入すると付けられるようになる。プログラムは有料で年額アルプス一万弱ぐらいかかる。iOS のは入ってるんだけど、Mac のには入ってないので署名はありません。付けてあげたいのは山々だけど。
Windows でも最近はダウンロード数の少ないファイルのダウンロードや、未署名バイナリの実行にものものしい警告が付くようになったので、これはもう時代の趨勢ということでしょうがない。仕組み自体に反対というわけでもないし。Windows ではバイナリ署名はウェブサイトにおける SSL 証明書同様の PKI のインフラであるのに対し、Mac ではアップルの AppStore 用の専用の証明書が用意される。前者のほうがオープンとも言えるけど個人の開発者がコード署名用の証明書を発行してもらうのは手間的にも経済的にもけっこう大変なのに対し、後者はプログラムに加入さえすれば個人でも簡単に署名を付けられるということで、一長一短です。あ、Windows アプリのコード署名用証明書取ってても Mac アプリの署名には使えないという無駄感はあるけど。Windows 8 のストアアプリの証明書は個人開発者でもできるようになってるのかな? だとすれば AppStore 方式かしら。そのへんは知らない。
Windows 版は上述の窓の杜効果によってダウンロード数が一気に増えたので、おかげさまで MSI インストーラは IE でダウンロードしても今は警告されなくなりました。今は。たぶん更新したらあたらしい MSI ではまた出るんだろうなあ。署名付きバイナリだと、更新しても同じ証明書で署名されていれば実績が引き継がれて警告は出ないんだそうで、そういう意味でもやっぱりコード署名の証明書がほしいなあ。
そうそう、ミスターPCという雑誌の6月号にもひみつメモ帳の記事とインストーラが掲載されているようですよ。窓の杜で知ったんだろうなあ、と思うとやはり影響力の大きさが覗えるというか、窓の杜の人が自力で探して見つけた成果を君たちは云々的なことも思わなくもなかったり。ちろっと立ち読みしたけどクレジット誤植ってたよ。
ひみつメモ帳 1.0.0 です。
四年前のコードで、今だったらこういう作りにはしないとか、こういうふうにしたいとかはあるけど、区切りをつけないと次に進めないのでひとまず。
なんか広げた風呂敷多すぎでとっちらかっとるよ。
ほかのモジュールで使うかもしれなくて、頭の体操めいたモジュールを作った。こういうものが世の中にあるのかどうか知らないけど、自分ではちょっと面白いと思ってるので書きます。
文字列の範囲を指定してマークアップするという作業を文字列から独立させたようなモジュールです。
markup.Marker オブジェクトを作り、markup.Marker.markup() メソッドで範囲 start と end を指定して stag と etag でマークアップします。markup.Marker オブジェクトはマークアップする対象の文字列(実際には文字列に限らず任意のシーケンスでよい)とは独立しています。markup.Marker.apply() メソッドを呼んで、マークアップ結果を文字列と混ぜ合わせて列挙します。”.join() で繋げればマークアップ文字列になります。
>>> import markup >>> marker = markup.Marker() >>> marker.markup(0, 5, '<b>', '</b>') >>> marker.markup(-1, None, '<i>', '</i>') >>> marker.markup(None, None, '<p>', '</p>') >>> list(marker.apply('Hello, world!')) ['<p>', '<b>', 'Hello', '</b>', ', world', '<i>', '!', '</i>', '</p>'] >>> ''.join(marker.apply('Hello, world!')) '<p><b>Hello</b>, world<i>!</i></p>'
markup.Marker.markup() の順に関わらず、マークアップの入れ子を適切に列挙するのが仕事です。start, end が正の整数値(fixed な範囲指定といいます)なら markup.Marker.markup() 実行時その場で、None や負の整数値であれば(こちらは unfixed な範囲指定)なら markup.Marker.apply() メソッド実行時に、入れ子の整合性チェックを行って、破綻するようであれば例外 ValueError を発生させます。
>>> marker = markup.Marker() >>> marker.markup(0, 5, '<b>', '</b>') >>> marker.markup(0, 6, '<c>', '</c>') >>> marker.markup(1, 7, '<d>', '</d>') Traceback (most recent call last): File "<stdin>", line 1, in <module> File ".\markup.py", line 148, in markup .format(span, conflicting)) ValueError: markup.Span(1, 7, '<d>', '</d>') conflicts with existing markup.Span (0, 5, '<b>', '</b>') >>> ''.join(marker.apply('ABCDEFGHIJ')) '<c><b>ABCDE</b>F</c>GHIJ' >>> ''.join(marker.apply('123')) '<c><b>123</b></c>'
同じ範囲であれば、あとから追加したほうが外側になります。
今回の用ではこれだけで足りてるのだけど、入れ子が破綻してたら分割点で分けて追加するとか、いろいろ機能の追加のしどころはあると思う。あんまり長くならないのが好きだけど。
やる気があるのかないのかわからなかった unicodeseg.py ですが、開発停止。理由は、ICU (International Components for Unicode) の Python バインディングである、PyICU がちゃんと動いたから。せこせこ作って試してた unicodeseg.py の LineBreaking 境界のン千項目のテストコードに試しに食わせてみたところ一瞬にして完全クリアしたのを見て踏ん切りついた(笑)。
いや、もともと PyICU の存在は知ってたんですよ。作る前に調べたから。けどどうもその時は開発がアクティブでなさそうで、なんか頼りなさそうだったのだ。しかしいまや新しい ICU のバージョンにもキャッチアップしてるのでこれでいけると。まあプロジェクトとして人は足りてなさそうだけど……。
なので次の関心としては、PyICU のバイナリ配布物を作りたい。ICU のビルドやそれと PyICU と組み合わせての動作確認はできてるので、使う人が ICU を自分で Visual Studio でビルドしなくても簡単にインストールできるようにしたい。それと OS X 版もバイナリ配布あったほうがいいよね。
OS X も Mountain Lion の今は開発ツールが別途ダウンロードだったと思うので、バイナリ配布物の需要はあると思う。というか、みんな忙しいんだからいちいち ICU みたいなでかいライブラリを手元でビルドさせることはないと思うんだよね。そういう意味で、バイナリ配布というのは現実的には(Windows にとっても Mac にとっても)重要な要素だと思うんだけど、現状のパッケージング開発界隈にはそうは見えてないらしい。まあおそらくウェブ開発の人中心なのだろうから、Win/Mac のデスクトップ・コンピューティングにはあまり関心がないのだと思う。かれらはどちらかというとダウンロードからインストールまでの工程の自動化という面にフォーカスしているように思える。
そういや pip って今はバイナリ配布できるのかな。Windows だと、setup.py bdist_wininst の出来がアレだし、MSI 形式も Python 3 では使えなくなっちゃったしで、現状バイナリ egg がいちばん現実的な形式になっている。そうなると easy_install からいつまでも卒業できないし、かといって wxPython のようにインストーラでしか配布してないモジュールもあるから、けっきょくパッケージ管理一元化なんて Windows では夢のまた夢、と悲しくなってしまう。
(wxPython のために一言添えておくと、かれらの独自インストーラはカスタマイズ用のオプションを持っているので標準のセットアップ配布物よりはまとも。けどたぶんセットアップ・オプションの存在なんて誰も知らないと思う(笑)。)
そういうわけで、バイナリ配布物の作り方のようなものを調べなくちゃいけないんだけど、手元で動いてるとそれでいいやあとなっちゃうのでなかなか進まない。というか PyICU いじる時間自体もあんまない。ああ、PyICU にもコミット取らなきゃいけないだろうしねえ。優先度としては低めかなあ……。