Rails + rack-corsの設定をRSpecだけである程度お手軽にテストする - あーありがち(2019-06-01) の完成版とも言える。
できたこと
- rack middleware の設定をサーバサイドフレームワークから独立させることでテスト用の rack アプリで再利用
- Capybara の機能ではなく Thread と rack handler を使ってテスト目的のサーバを自由にいくつでも起動する
- Capybara にはアクセス先の URI だけ教える
- Selenium::WebDriver から browser の中を探っていくと log の interface がある driver もある
- 2019-09-01 時点で ChromeDriver でしか確認できていない。GeckoDriver では動かなかった
地味に 1 の設定を独立させる、つまり rack middleware に与える block を別な場所に分離するのが面倒だった。
3 は Capybara が古いとダメ。確認できたのは 3.x 系。(selenium/CHANGES at master · SeleniumHQ/selenium によると 2013年の 2.38 で beta API として登場しているが、公式になったのかどうかよく分からない。)
期待できること
- 単純に console の出力を取得できるのでレガシーな JavaScript のテストにも使える
- 本物のサーバサイドアプリからも本物のクライアントサイドアプリからも独立してインターフェイスをテストすることはまだまだできる
成果物
自分のためじゃないです。自分はもう Emacs / Meadow でいいです。
背景
これまで Windows の人には、ある国産のフリーのエディタを長いこと使ってもらっていました。国産のフリーの Windows エディタの多くがそうであるように、やはりそのエディタも UTF-8 には対応してはいるものの内部では SJIS で動いていました。そのためか、UTF-8 の判別や読み書きの部分で、ときどき困った動作をしていました。幸い、これまでは UTF-8 を直接読み書きしなければいけない機会はそれほど多くなかったのでどうにかやり過ごしてこれたのですが、さすがにもう 2009 年も後半になって UTF-8 の読み書きで問題を抱えているのはダメだろうと一念発起しまして、ちらちらと気にはなっていた notepad++ を試してみました。
いきなり謎
アーカイブを紐解くと ansi 版と unicode 版の二つのバイナリが出てきます。何が違うの? 同梱のドキュメントやサイトを軽く見ても書いてないっぽい…。とりあえず Unicode 版は Windows 2000 以降が必要ということなので、Windows 2000 以降を使っているならその Unicode 版の方が有利なのかなと思ってそっちにしました。
基本的すぎて申し訳ないけど、どっち使ったらいいか書いといてよ!
Notepad++ の特徴だと感じたところ
どうやら本家は EUC-JP に対応していないらしく、それはちょっと致命的なので EUC-JP 対応版だけを試しています。
ぱっと目についた特徴は
- MDI というかタブ式インターフェイス
- ものすごい数の言語に対応(YAML標準対応!)
- コードの折りたたみ(Eclipseとかでできるやつ)ができる
- こうした特徴の割に思ったより起動も動作も速い (netbook でもまったくストレスない)
ただまぁ頑張っているんだろうけど、
- Localization を日本語にしても半端な日本語メニュー
なのは我慢のしどころ。(個人的には問題ないけど、人に使わせる場合はそういうところも大事なのよね。)
設定はこんな感じ?
完全に自分の好みですが
設定
環境設定
全般設定
Localization
ツールバー
タブバー
ステータスバー
エディット画面
右端境界設定(80で折り返すように)
新規ドキュメント
デフォルト文字コード
その他
セッションの保存は好み分かれそう
スタイル設定 ( default で )
フォント MSゴシック サイズ 10
「フォントを他のスタイルにも適用」
「フォントサイズを他のスタイルにも適用」
表示
右端で折り返す
みたいな感じですかね。
とりあえず問題ないっぽい
本当に軽くしか試してませんが、euc-jp のファイル、utf-8 のファイル、shift_jis のファイルそれぞれ試してみましたが、特に問題はなさげです。まぁ、これから実際に使ってもらってみないと判断はできないでしょうが。(前述の国産エディタも自分だけの利用ではなかなか気づけない現象でしたし。)
ウィンドウ分割
MDI というかタブ式なので基本的には一つのウィンドウで複数の文書を閲覧します1。その場合、当然ウィンドウ分割の機能がないと複数の文書を同時に閲覧できません。ヘルプを見ると
[ View ] -> [ Move/Clone current document ] -> [ clone to another view ]
が正解っぽい。
こういう感じのメニューでウィンドウを分割するアプリが他にもあったような…。なんかちょっと直感的じゃない気がします。
疑問
右端での折り返しはあくまでウィンドウに対してであって、指定桁数で折る機能はないのでしょうか? そんなもんなのかなぁ。CotEditor もそういう設計ですが、だったら指定桁数のウィンドウを作成する機能がほしい気がするのは贅沢でしょうか。
euc-jp で保存し直すことってできない? euc-jp 対応版で保存ダイアログに手が回ってない感じ?
Open in new instance っていうメニューもあって実際には複数のウィンドウを開けますが。 ↩
つってもいつもパソコン持ち歩いて移動しまくってるわけではないので、普段と違う環境に行ったとき用なんだけど。
モノは D11LC ブラックで、もうすぐ 7.2Mbps 版が出るんだけど、すぐ欲しかったのでしょうがない。(端末代もべらぼうに安かったし。)
気になるスピードは、金沢市の街中(長町)では 1.2Mbps 出たんだけど、鞍月のビーンズでは 240kbps 止まり。時間帯はよく似たもんで、いわゆるプライムタイム? エリア的にはどちらも余裕なはずなので、スピードにバラツキが出たのはちょうどいい具合に基地局との距離にバラツキが出たからなのかな。ADSL じゃないんだから距離は関係ない? どういう条件でスピード変わるんだっけ。
1.2Mbps で使ってると「おぉ、結構はぇーなぁ」という感じなんだけど、さすがに 240kbps になってくると最近のWebサイトの読み込みにはつらいかもしんない。使えなくはないけど、次々クリックして読んでいくにはちょっとつらい。prefetch の機能があるならそれを有効にしておくとまだなんとかなるかな?って感じ。個人的にはそこまで試してないのであくまで予想だけど。
ところで最近 Twitter ばかりで落ち着いて日記を書けない。もっとも、irc とか Twitter はやってるので絶対的な時間不足ではないはずなんだけど、やっぱまとめて書く時間て結構貴重なのだなぁと思っているところ 1。だから最近は irc や Twitter のログをひっくり返してあとで整理し直すことがよくある。結構便利。
ほんとはネタを書くだけでなくライフログとしてもっと使っていきたいんだけど、いったんペースが落ちると「忘れたくない優先度」が日常生活よりも技術ネタの方に偏っちゃうんだよな。
あ。
もしかして日常は忘れたくなって来ちゃってるのかねぇ。そりゃいかんなぁ。
逆か。Twitter とかやってるから集中する時間を長く持続できないのか。 ↩
タイトルで全部なんですけど。
pear コマンドで管理可能なパッケージを作るためには
- package(2).xml ファイルを作成して
- pear package package(2).xml と入力
するとパッケージができるんだけど、この package(2).xml を作成するのが面倒らしく、いろいろフロントエンドがあるらしい。そんな中 PEAR_PackageProjector -lAiki に期待していたんだけど、試したら依存している CodeSniffer が PHP5 じゃないと動かないので使えないことが判明。(まぁその辺はイロイロあるでしょうがとりあえず無視。)
改めて調べると PEAR :: Package :: PEAR_PackageFileManager_Cli なんてのがあり、Pyrus - A few PEAR compatible packages を見ると順番に質問に答えるだけでよさそう。
2007-09-01 現在、0.3.0 alpha なのでインストール時は
pear install PEAR_PackageFileManager_Cli-alpha
としておく。
実際試した(OSX 10.3.9 PPC + PHP 4.4.4)ところ
- pfm コマンドが作成されたので、パッケージを作成したいファイル群のてっぺんのディレクトリで pfm を起動
- 順番に質問に答えていくだけ。ライセンスとかパッケージ名やバージョン以外は適当にデフォルトで進んじゃってオーケー
- CVS とか .svn は自動的に避けて package.xml を作成してくれるので working copy 上で無造作に作業可能
など結構親切な印象。ちなみに聞かれる内容は pfm 0.3.0 で以下の通り
1. Package name
2. Channel/URI
3. Summary
4. Description
5. Maintainers
6. Version
7. Stability
8. License
9. Notes
10. Dependencies
11. Tasks
12. Regenerate contents
13. Echo package file to stdout
14. Save & Quit
15. Quit without saving (ctrl-c)
package名がモジュールの prefix になっていないと警告が出るなど、pear package としての作法を教えてくれるので、その辺を直しながら package としての体裁を整えていけばいいのかな。
課題
- package2.xml を作る方法が分からない
- package.xml という名前だけど中身は version 2 なので気にしなくていいかも
- PHP_CompatInfo を使って利用できるバージョンを正確なものにしたかったが、CLI で動かしてみたらなんかエラーで動かなかった。なんだろ。
- channel サーバもあった方がいいかなぁ
- URL を直接指定させる方式なら channel サーバ要らないのかな
- でも channel サーバあれば update とかのチェックしやすいよね
[追記] PHP_CompatInfo の問題は単に依存しているライブラリが足りないだけだった。これしかしなんでこんな table 形式で出力するんだ? 他のテキストツールで加工しにくいじゃん。
cf.
リューク視点からなのが斬新、て別に本編はフツーに流れてて最初と最後に語りをくっつけただけでは…。ディレクターズカットってこの部分のこと? あとはテレビでやってたやつを編集し直しただけじゃないの? 通常のアニメのシリーズを見てないから知らないけど、終盤の L の描写の中に過去を連想される部分を変に入れてきたなという以外は普通に流れていったような気がする。
ただまぁさすがに3時間しかないとは言え端折りすぎだなぁ。説明として必要なシーンや血文字で殺すシーンがないし1。あと最後 L に黒ライトの表情を見せなかったのはなんでだろう。さすがに救われなさ感が強くなりすぎるから? でも墓の前で黒ライトぶっ壊れてたしなぁ。そっちで入れるから重ねるとクドいという判断か。
しかしこうして見直すとやはり映画のラストのノートの使い方や南空ナオミの使い方はいかにも映画的だったんだなぁという気がするな。
テレビシリーズを見ていないのでアニメに最初からなかったのかどうかは知らないけど、あそこは黒ライトが黒ライト自身を守るために必要な攻防なのだから。 ↩
エキサイト創業者に聞く、Wikiブームの実情 (CNET Japan)
メールの話が出ていたので、触発されて以前から思っていたことを。断片的にはすでに何度か書いているような気がするけど、復習ってことで。
個人的に、既存の多くの Wiki がメールと相性が悪いのは問題だなと感じている。それは編集の通知をメールで出せるとかそういう技術的な話ではなくて、Wiki のソースをメールで送ろうとしても読みにくいってこと。ときどき Wiki のソースは人間にも機械にも読みやすいと思っている人がいるけど、これは結構な割合で嘘だと思う。試しに Wiki 文化になじみのない人にソースをそのまま送りつけたら怪訝な顔をされるだろう。
そりゃそうだ Wiki は WikiWikiWeb であり、Web サイト上に文書があるのが前提なのだというのは正論なんだけど、自分の手元にない情報と自分の手元にある情報をうまく整理つけて取り回しできる人は、実はそれほど多くない。つまりそもそも Wiki の情報は手元にないものだから、Wiki 文化の外にいる人には扱いにくいという問題を抱えているし、例えばこれ読んでおいてくださいと言われてメールに URL が書いてある場合と、実際の文章が書いてある場合でどちらがちゃんと読まれるかを考えると、そりゃー文章が書いてある方だろうと思う。
で、何が言いたいかというと、
- Wiki 文化はまだ根付いていない
- Wiki に書くことが根付いていないと、多くの場合読むことも根付いていないだろう
- Wiki 文化の圏外に居る人に何か文書を読ませたい場合はメールで送りつけた方が効果的
- Wiki 文化内の人間としては Wiki ソースを貼付けてメールで送れると楽
- Wiki ソースがそのままメールに貼付けて違和感のない形になっていると両方の文化の人にとって嬉しい
ということが言えるんじゃないかなぁと。1
で、そのために個人的には reStructuredtext に期待しているというのは前にも何度か書いた気がするんだけど、setext を知らない人にはこの話は単なる飛躍なのよね。では書きましょう。setext は、プレインテキストであるメールの中で文章の構造を記述するために考案されたのです。確か。2だからその拡張版である reStructuredText に期待するのは当然なの。
ただし、現状で安心して日本語で書けて reStructuredText をサポートしている Wiki は選択肢があまりない3と。こういうことです。
以前早口の話に触れたことがあったが、やはり自分は頭はぶんぶん回す方が気持ちよいし、自分のためによさそうである。頭が疲れるくらいに高速で本題と本題じゃない話題を展開し、トレースし反芻してまぜ返すのはとても面白い。様々な刺激が頭の中を駆け抜け、気持ちが新たになったり、ふとした思いつきが出てきたりする。しかしこれは会話の相手が同じスピードでついてこれないとできない。
いつもいつも疲れるほど回すこたぁないけど、回した結果として気持ちよさが残る相手は貴重だ。
…ということは説明が徒労に終わったときに痛いほど感じる。めんどくさい思いをしてだるさだけが残るなんてあほくさい。
(setq perl-indent-level 2) だけでよかった。今は tab は使ってないので。
ふむ。つい忘れてしまいますな。@INC の存在を知っているというか昔カタギな Perl 使いは @INC に目が行ってしまいがちだけど、自分はこれから
use lib PATH;
の形を習慣付けようと思った次第。
従来は CVS は sourceforge を利用していたが、(実際に管理業務を行っている人間のポリシーで)リリースもその案内もすべて Wiki 上で完結させようとしていた。しかしこれでは md5sum の check も満足にできないわ、ページ数が増えすぎて決してレスポンスのよくない Wiki サイトを定期チェックしなきゃならないわ、RSS で更新をチェックしていてもノイズが多すぎてどうにもならないわで大変なものだったのだが、ようやく扱いやすくなってきた。
過去のリリースパッケージもこの7月末にアップされているし、sourceforge への登録から2年、ようやくプロジェクトが少し大人になってきたようだ。現在のメイン開発者は sourceforge 登録から数えて3代目。初期開発の sng 氏を加えると4代目である。短い期間に大幅なバージョンアップを続けた PukiWiki は、開発者の交代も早い。しかし今後はもう少しゆっくりしてもいいんじゃないか。
最後に、開発の議論は Wiki 上ではなく ML でやってほしい。話が収拾つかんから。
from wakatonoの戯れメモ
- PDU
- Professional Development Unit. PMP(Project Management Professional)資格は3年更新で、更新には 60PDU 必要。
- Lens
- Ruby で書かれたメール振り分けスクリプト。自分宛に来たメールを処理する。procmail 代替みたいな位置付けらしい。処理後、自分のメールボックスに保存する部分では Maildir しか考えていない。(mbox は lock 周りが面倒でやめたのか、imap 利用が前提だからか。)
参考
textfile.org からリンクたどって説教講座にきた件数が18(自分が踏んだのも含む)で、実際にサンプルを見た人は10以下(analog がカットしてるので正確な数は不明)。
まぁ sourceforge.net の方に行ったのかもしれないけど、日本語の資料はそっちにはないんだから、サンプル見てソースとドキュメントの対応を見た方がいいんじゃないのかなぁ。。。うっうっ。
しかし Perl である程度以上の規模の開発をするとドキュメントの問題って必ずついて回ると思うんだけど、みんな # なんて素朴すぎるコメントを不便だと思わないのかねぇ。
……と思ったけどよく見たら texifile.org からはメインのリンク先は sourceforge.net なんだ。説教講座は参考程度なのでそりゃ来る人少ないわな。