ただのにっき

■ Ruby 1.4.5

うっかりしていたらKondaraのsnapshotにRuby 1.4.5のパッケージが入っていたので、GETしてくる。とるものもとりあえず、突っ込みましょーっ♪

# rpm -Uvh ruby-1.4.5-2k.i586.rpm
error: failed dependencies:
        libreadline.so.4.1 is needed by ruby-1.4.5-2k

■ おおぅ。なんでreadlineが。まぁいいや、これも新しいのを取ってきましょう。

# rpm -Uvh ruby-1.4.5-2k.i586.rpm readline-4.1-k4.i586.rpm
error: failed dependencies:
        libhistory.so.3 is needed by postgresql-6.5.2-1k2
        libhistory.so.3 is needed by postgresql-devel-6.5.2-1k2
        libhistory.so.3 is needed by postgresql-server-6.5.2-1k2
        libhistory.so.3 is needed by postgresql-tcl-6.5.2-1k2
        libreadline.so.3 is needed by cdecl-2.5-9
        libreadline.so.3 is needed by ftp-0.15-1k4
        libreadline.so.3 is needed by git-4.3.17-5
        libreadline.so.3 is needed by guile-1.3.2a-1
        libreadline.so.3 is needed by postgresql-6.5.2-1k2
        libreadline.so.3 is needed by postgresql-devel-6.5.2-1k2
        libreadline.so.3 is needed by postgresql-server-6.5.2-1k2
        libreadline.so.3 is needed by postgresql-tcl-6.5.2-1k2
        libreadline.so.3 is needed by samba-client-2.0.6-5
        libreadline.so.3 is needed by samba-common-2.0.6-5
        libreadline.so.3 is needed by fvwm2-2.2.2-3k3
        libreadline.so.3 is needed by librep-0.11-1k2
        libreadline.so.3 is needed by samba-2.0.6-5
        libreadline.so.3 is needed by sawmill-0.25.1-1k2
        libreadline.so.3 is needed by bc-1.05a-4
        libreadline.so.3 is needed by python-1.5.2-7k

■ うぎゃー。まぁ、readlineにいろいろ依存してるのはわかるけど、なんでGUIのfvwmとかsawfishまで。sambaなんてdaemonやないか。どうもダメな気がしてきたけど、念のためこいつらも持ってきて一緒に入れてみると、最後にはgnome-coreまで依存してるとか言ってくる。なんでRubyを入れ替えるためにGNOMEまで入れ替えなあかんねんっ。

……とここまで毒づいてから、「ひょっとして、自分でパッケージを作り直したらいいんじゃないか」と思いつく。なんたって、Kondaraの基本はnosrc.rpmなんだから。もしそのSPECファイルにreadlineの特定のバージョンに依存する記述があったら、そこを直せばいいんじゃないの? そうだよ、それだ。Rubyのソースはすでに(用もないのに)入手済みだったので、ruby-1.4.5-2k.nosrc.rpmを持ってきて、rpm -ivhで展開。

■ ~/src/rpm/SPECS/ruby.specを見てみるが(KondaraのSPECファイルがこんなに複雑だとは知らなかった……)、別にreadlineのバージョンなんて書いてない。試しにビルドしてみるか。

$ rpm -bb ruby.spec
(略)
File not found: /var/tmp/ruby-1.4.5-root/usr/lib/ruby/1.4/i386-linux/curses.so
File not found: /var/tmp/ruby-1.4.5-root/usr/lib/ruby/1.4/i386-linux/dbm.so
File not found: /var/tmp/ruby-1.4.5-root/usr/lib/ruby/1.4/i386-linux/etc.so
(略)

■ ありゃ。これは最後のインストールテストのフェーズかな? 確かにこんなディレクトリ(というかシンボリックリンク)はない。そもそもなんでi386なのか。Kondaraはi586なんじゃないのか。いや、もしかするとどっかで明示してやらないとi586にならないのかも……と思ってrpmのmanを見てみると、--targetってオプションがあった。これかな。ひょっとすると~/.rpmmacrosに指定できるのかも知れないけどよくわからん。これでリトライしてみよう。

$ rpm --target i586 -bb ruby.spec

■ すると、何も指定しなかった時には-O2 -m486だったgccのオプションが、-O6 -mpentiumになってる。おお、これぞKondara神速の秘密か!?(笑)　Warningもやたらと出るけど、これはたぶん、RubyのソースがANSIじゃないからなのかな。で、無事にビルドが終わり、ruby-1.4.5-k2.i586.rpmが完成。ドキドキしながらアップデート。成功♪ readlineへの依存などなし。

つまりこういうことか。バイナリパッケージを作った人の環境がすでにreadline-4.*を使っていたので、readlineを使っているRubyのパッケージはそれに依存してしまった(SPECファイルには無関係)。が、自分の環境でパッケージを作り直したことで、自分が使っているreadline-2.*に依存したバイナリになった、と。なるほど、「ソースパッケージを持ってきて【自分の環境に合わせて】ビルドしなおしましょう」というのは、まさにこういう意味だったのだな。バイナリパッケージが公開されてない場合に自前ビルドをしたことはあったけど、本来の意味がやっとわかったぜ。src.rpm万歳っ(笑)。

■ CSS

hr{diaplay: none;}ってのは試したはずだよなぁ……。と思ったら、試したのは「non」だったという(笑)。うーむ、バカ丸だしだ。ありがとうございました、中村さん。こんどはきれいに見えているはず。

■ vi

viのデフォルトがコマンドモードなのは、ファイルを開いて最初にする行動がカーソルを編集したい場所まで移動することだからじゃないかな。新規ファイルでない限り、最初からインサートモードになっていたら必ずESCキーを押すことになるので、これは理にかなっていると思う。

aとiは個人的にはけっこう使い分けているので、なんとも言えないっす。Aなんてかなり頻繁に使うし。

でもまぁ、おれは昨日も書いたようにタッチタイピングもできないし、ホームポジションから手を離すことをぜんぜんいとわない人なので(カーソル移動ももっぱらカーソルキーに手を伸ばしちゃうし)、まったく説得力ないよなぁ。実は昨日の日記を書いたあと、Emacs擁護派から矢のような反論があったらどうしようとか、ちょっとビビってたという(笑)。

■ Mobiler

1.1.1をリリース。Referer漏洩のセキュリティFIXと、JisCompactFilterとメール分割のバグ修正。cgi/mobiler-cgi.confに定数がひとつ加わってるのでご注意あそばせ。

■ vi(2)

いっ!?　そ、そうっすか(汗)。おれ的にはかなりいい方なんだけどなぁ。「J」って「↓」に似てない?(笑)　そいえば昔、Wordstarのダイヤモンドカーソルなんてのがありましたな。^S/^D/^E/^Xの。あれは直感的だった。小指がつるけど。

それにしてもRefererが爆発していて面白い。おれとしてはEmacsをネタに「同じプログラマとして同様のセンスのなさを自嘲する」というニュアンスをたっぷり入れたつもりなんだが、誤読は免れぬようだ。ま、それもWeb日記の醍醐味のひとつか。

で、単にリンクをたどってきただけの人は↑みたいな文章は読まずにずーっと誤解を続けるわけだ。うーむ。

■ HL:BS日誌

無事に発電機を動き始めると、今まで通ってきたルート上のいくつかのアイテムが動くようになっている。てことは、逆戻りしろってか。毒性のクーラントを二度も渡らされたり、かなりキツい思いをして、科学者君の待つワープ実験室へ。

そしたら今度はおまえが操作しろという。仕方なく2Fに上がって言われるままに操作してたら、できたワープゾーンに向かって飛び込みやがった。きたねー。なぜか敵が侵入してくるのを相手しつつ、こっちも後を追う。

そしたら科学者仲間が車に乗って脱出しようとしている現場に。しばらく立ち話をしたら……終わってしまった。え!?　もう終わり!?　まだ「黒ずくめ巨乳女」とかに会ってないし、ハエも撃ってないのに。なんだかあっけなさすぎるぞ。いいのか、こんなんで。ちょっと手応えなさすぎ。つーかOpForが手応えありすぎ。

仕方がない、レベルを上げて再挑戦だーっ。その前にKondara入れんかーい >おれ

■ ぶたじるvsとんじる

サブタイトルのプレフィックスに「W杯」って書きそうになったがやめた。

それにしても、「豚汁」→「ぶたじる」→「ブラジル」という昨日の駄洒落が一発で理解できなかった人が意外に多くて、夕べの我が家ではその点に関して議論が重ねられたわけだが(おおげさ)。北海道出身のかみさんは「ぶたじる」派だが、関東出身のおれは「とんじる」がメジャー、「ぶたじる」はかなりの少数派という認識。試しにGoogleしてみると、とんじる550件、ぶたじる460件で、とんじる優勢だが圧倒的というわけでもない。

文法的には「とん」と来れば「じゅう」になるのが筋なので、最初から重箱読みでない限り語源は「ぶたじる」であろう。どこかで「ぶた」→「とん」への変化があったはず。そう思って調べてみたら「ぶたじる とんじる」で184件。みんな悩んでいるようだ(笑)。

1995年にfj.rec.foodで行われた調査によれば、北海道と九州は明らかに「ぶたじる文化圏」、東北・中国が「とんじる」、都会は混在という感じ。とかち情報局による調査は北海道における「ぶたじる」の圧倒的な支持が明らかになっている(って回答数50かよ)。九州・北海道から上京してきた人が、「ぶたじる」が通じなくて愕然、という事例もたくさん。これは、「ぶたじる」で全国統一されていた時期もあったが、その後発生した「とんじる」族が勢力を伸ばしている、しかし北海道と九州にはまだ上陸していない、と見たがどうか。

「豚汁食べたきゃブラジルへ行け」なんて駄洒落に親しんだ人にとって、ブラジル戦で豚汁を食べるのはごく当たり前(?)の行為だろうなぁ。2年前のオリンピックで同じネタ(9/20分)やってる人もいるし。ちなみに手元のVJE-Deltaでは、「とんじる」は一単語として変換されるが「ぶたじる」だと「豚」「汁」と分割して変換される。VACSが町田の会社だからであろう(そうか?)。

なんにせよ、こんなネタでも即座にいろいろ調べ(?)が付く、Webってすごいなぁ、というのが結論だ。って結論になってへんがな。

■ Re: Reply-To

私感だけど、おれはReply-Toを付けないML運営者は怠慢だとすら思ってる。あくまで現時点の環境を鑑みて、ではあるが。Mail-Reply-ToやMail-Follow-To(だっけ?)みたいなヘッダが十分メジャーになれば別かも知れないけど、返信に関して「返信」と「全員に返信」くらいしか装備していないMUAがほとんどの現状では、MLにはReply-Toをつけるべきだ。つーか、Reply-ToのつかないMLでは発言する気が萎えるんだよな、おれ。

Reply-Toの弊害に関して引用されるのはたいてい``Reply-To'' Munging Considered Harmfulだ。他の文書を見たことがない。唯一無二のバイブルなのだろうか(あとはdjb文書や某前野文書もあるにはあるけどあえて無視:-)。この人、いろいろ理由はつけてるけど、「ようするにプライベートなメールをMLに流しちゃった自分のミスの言い訳してるだけとちゃうんかい」というのが正直な感想。

MLがグループコミュニケーションのためのツールである以上、デフォルトの返信先がMLになるのはごく当たり前だ。それをわかった上で送信者個人にメールするなら、十分気をつけて真っ先にToを書き換えるのが普通だろう。学校の放送室で、うっかりマイクのスイッチを切り忘れてヤバい発言しちゃうのと同程度の危険性である(ヘンな例え)。

そんなうっかりミスの防止のために、なんで普通にMLを利用するその他大勢の人たちがいちいち「全員に返信」を選択して、Toを消して、Ccの内容をToに移動して……なんて面倒なことをせなあかんねん。例えばテレビ会議で、発言するたびにいちいち複雑なスイッチを切り替えないと全員に話が伝わらないなんて面倒なシステムがあったら、誰も使わんよ。ちなみにBecky!には、MLのアドレスを登録しておくと、送信前に「本当に送っていいのか?」と聞いてくる機能がある。うっかりミス防止なら、こっちの方がよっぽど有効だと思うぞ(習慣化してしまうと意味がないという罠もあるけど)。

ループの防止だって、MLへの投稿を登録された人だけに許可するだけで防げるだろう。公開されたアドレスには漏れなくspamが届くようなご時世に、オープンなMLを運営するなら当然の措置だと思うし、そういう運用のMLで不正なエラーメールによるループが起きた例なんて、もう何年も見たことがない。少なくとも、そういう一部の腐ったMTAの対策のために、参加者全員に不便を強いるなんて間違ってる。

MLサーバがReply-Toを追加(書き換えまではしなくてもよろしい)するのは、コミュニケーションをスムーズにするための「サービス」だ。メールヘッダは書き換えない方がいいなんて主張は、サービスの否定だ。便利になりゃなんでもいいと言うわけではないが、たいした弊害もないのにそれを封じ込めるこたぁないだろう、と思うわけである。ついでに言っておくと「欧米では一般的です」なんて理由も論外である。

■ spc.gr.jp引っ越し中(2)

自宅からまだ新しいサーバが見えない。もう36時間以上たってるのに。なんでそんなに遅いのか >@nifty メンテができないじゃないか。

■ bsfilter 1.33

DBにsdbmを使うようになってからのバージョンアップは初めてだったので、性能面でも有利だからコンバートをしよう。まずはテキスト化:

% cd ~/.bsfilter
% bsfilter --db marshal --export-clean > clean
% bsfilter --db marshal --export-spam > spam

続いてこれを、sdbmにコンバート:

% bsfilter --import-clean < clean

……が、これがいつまでたっても終わらない。もしかして無限ループしてるんじゃないかと思ってコードに進行状況を出すような改造を入れてみたら、ちゃんと動いている。cleanファイルは5MBくらいなんだけど、かなりキツい処理をしてるせいで、ものすごく時間がかかるようだ。

メールサーバはVIA C3で荷が重いため、PenIII 866MHzのマシンにコピーして再実行。さっきcleanが終わった。spamはさらに大きく、9MBもある……いつ終わるんだろ。

■ pcspecs:SPC18 - Gentoo

こんなの、GHzオーダーのCPUがあればもっと早く終わるのに、肝心のCeleron 2GHzは放置状態である。悔しいので、Gentooのカーネル構築に再挑戦。

インストール手順書のとおり、xfs-sourcesを使って、さらに/proc/configを再利用する形でやりなおすことに。make oldconfの問い合わせも変な細工はせずにすべてデフォルトにした。これだけ素直にやれば動くだろ?

……甘かった。こんどはGRUBで選択後、勝手にリブートしてしまうようになった。無限ループ状態。なんでやねーん!!

■ 言及リンクのないTrackBackの何がいけないのか

昨日はなんだか、言及リンクのないTrackBackを受けまくったので、ちょっと時間もあることだし、ちゃんとまとめてみることにした。

言及リンクをしないサイト管理人は読者を大切にしていない

まず、下の図を参照して欲しい。左側のサイトAが、右のサイトBに対して言及リンクなしでTrackBackを送った状態を図にしたものである。

TrackBackは逆リンクを生成するので、「A→B」のTrackBackは、「B→A」のリンクを生成する。サイトAに言及リンクはないので、「A→B」のリンクはない。結果、サイトBの「読者」はサイトAの記事を読めるが、サイトAの読者は(関連しているはずの)サイトBの記事を読めない。

この場合、アクションを起こしたのはサイトAの管理人だけなので、管理人Aの行為がどういうことか考えてみよう。Aの行為は、サイトBの読者という「新規顧客」の呼び込みには成功しているが、「既存顧客」に対する新しいリンクの提供を怠っている。Aの読者は怒ってしかるべき、ひどい仕打ちである。

まぁ、そんな商売みたいなことを言わないまでも、このリンク関係で幸せになるのは、サイトBの読者β人だけである。もし言及リンクをしていれば、さらにサイトAの読者α人も幸せになれる。「β」だけより、「α+β」の方が良いのは言うまでもないであろう。言及リンクをしないサイトAの管理人は怠慢だし、サイトAの読者は不幸である。

これに対して、「サイトAの管理人は、サイトBを(自サイトの読者にとって)無価値と判断したからリンクはしなかったのだ」という主張がある。この点についての倫理的な問題は後述する。

ハブをハブ足りえる存在にするのは言及リンクの存在

さて、たとえ言及リンクがなくても、十分な数のTrackBackを集めたサイトは、情報のハブの役目を果たすから良いのである、という主張を見たことがある。次の図のような場合であろう。

サイトBはよほどよい記事を書いたのであろう、たくさんのサイトAnから(言及リンクのない)TrackBackを受けている。たしかに、構造的には、サイトBは「ハブ」になっている。読者がサイトBにたどり着ければ、そこからたくさんの関連記事を読むことができる。

「たどり着ければ」? そう、問題はここにある。出て行くリンクばかりで入ってくるリンクがないので、この「ハブ」のページランクは上がらない。つまり、検索サイトでひっかからないのである。検索されないサイトは存在しないも同じことだ。さらに、関連するはずのサイトAnに読者がたどり着いても、ハブへのリンクがないので、他のAnを読むこともかなわない。これでは意味がない。

もし、すべてのサイトAnが言及リンクをしていれば、サイトBへ流入するリンクは増え、ページランクが上昇、検索上位に出てくるようになって、晴れてハブの役目を果たすことになる。言及リンクがなければ、ハブはハブ足りえないのである。

言及リンクをしないTrackBackはspamと同じ

こんな主張も見受けられる。自分のサイトに来て記事を読んでもらいたいと思ったからTrackBackしたのだ。サイトBの記事に価値があるかどうかには興味がない。サイトBはTrackBackを受け付けている以上、黙って受け入れればいいのである。いやならTrackBackを受け付けなくするか、不要なTrackBackは削除すればいいではないか(たとえばここに類似の意見)。

これとよく似たロジックを見たことがないだろうか。「うちのサイトに来て商品を買って欲しいと思ったからメールしたのだ」「メールを受け付けているのだから、黙って受け取ればいいではないか」「不要なら削除してくれてかまわない」……そう、スパマーの論理(屁理屈?)である。

スパマーが悪であることに、いまどき異論を唱える人は少ないだろう。ならば、同じロジックで無差別に打ちまくられたTrackBackもまた、悪ではないだろうか。少なくともサイトB管理人に対し、有用なTrackBackかどうかを判断し、削除するという手間を要求する時点で、サイトA管理人はスパマーと同類である。

もちろん、「じゃあリンクすればいいのかよ」とばかりに、単にサイトAにBへのリンクを追加しただけでは、この屁理屈に皮が一枚加わるだけである。記事中できちんと「言及」し、密接に関連するかどうか吟味した上でTrackBackする。この過程があるかどうかで、(サイトB管理人を含む)読者にとって価値のあるリンクが生まれるかどうかが決まる。言及リンクをすることで、TrackBack先を吟味するチャンスが生まれるのだ。TrackBackには、そういう熟考の成果が含まれて欲しいものである。

単なるアクセス数アップの手段として、独りよがりの屁理屈で送りつけられるTrackBackは、TrackBackの技術的な上っ面だけを見た、底の浅い利用例である。原子力という技術を使って原爆作ったっていいじゃん……というのと同レベルだ。技術の応用にはもっと頭を使って、結果をじっくり想像してもらわないと。

■ 新横浜駅で火事

帰ろうと思って外に出たら、駅前に消防車が集まっていた。ちょうど（クレーンの）ひかり号の下からもくもくと黒煙があがっている。また火事か!

駅は一部の通路が封鎖されたりしていたけど、電車には問題なく乗れた。

■ るびま特別号

出た出た、日本Rubyカンファレンス特別号。参加できなかった1日目の記事を貪欲に読むよ!

■ バナナスタンド入手

たつをさんに触発されて(?)、バナナスタンドを買ってきた。暑くなって痛みが早くなってきたので。 それにしてもバナナスタンドと私は、狙い通りGoogleでトップになってるなぁ。たいしたもんだ。

おれが買ったのは東急ハンズで1200円(税抜)。でも商品名は「バナナハンガー」だったよ。形はAmazonのヤツにそっくりだけど、材質も値段も違うから別物か。

ところでコレ、最後の1本になったらどうすればいいのか、誰か教えてくれ。

■ yomoyomo呑み

恒例の「yomoyomoさんの上京に合わせて集まる飲み会」に、久々に参加。場所は渋谷のchef's V、野菜を使った料理がメインの店。最近食生活が乱れがちだったので、ちょっとヘルシー方面でよかった。

飲み会の内容は、例によって無軌道でまとまりなく(笑)。

■ (ようやく) 日経電子版の有償版を読むようにした

最近やたらと飛ばし記事が増えている感のある日経新聞、まぁそのあたりに注意していれば悪くない新聞ということもあり、我が家では紙から電子版に完全に切り替えて購読し続けている。もちろん有償会員。

といってもkindlizer-backendを使ってクロールした結果をKindleで読んでいるのだが、いままではログイン処理を入れるのがめんどうでFree版(nikkei-free)しか読んでいなかった。せっかくの有償会員なのにもったいない! ……というわけで、新しくnikkei-paidを作ったのであった。

なぜかログインフォームがJavaScriptで生成されていたり、ログイン成功時に無駄なリダイレクトページが挟まっていたりと、よくわからないこだわり(?)のせいでちょっと苦労したけど、いまのところ朝夕ちゃんと生成されているようだ(ただし現状、エラー処理はほぼない)。もっとも、今まで省略されていた記事が読めるようになったものの、省略されている部分がわりとどうでもいい1、2行だったりして、なんだかなぁという感じでもあるが。

そういえば朝日新聞用のプラグインも書こうと思っていたんだけど、あそこも最近は有償会員しか続きを読めない記事が増えていてちょっと面倒になってしまったなぁ。電子新聞の有償モデルはうまくいっているのだろうか。

■ 庭に濡れ縁を設置した

先日土台の仮置きまで済ましておいたが、その後風邪を引いたり雨が降ったりでだいぶ間があいてしまった。今日は予報が外れて晴れたので完成させた。今回もWOODPROのセミオーダータイプ。

木製の六本足を直接地面に置くわけにはいかないのでコンクリートブロックの土台(束石)を挟むわけだけど、穴を掘って砂利を敷いてその上に載せる*1。で、ちゃんと足が均等に付くように水平を出さないといけないのだが、水準器なんて持ってないしどうしたもんかなーと悩んだのはほんの一瞬、そう、なぜなら現代の我々は傾きセンサーを内蔵したデバイスを持ってるのである。

というわけでスマホに水準器 Ultimateというアプリをダウンロード、足の間に平らな木材を渡して傾かないように高さを合わせたのだった。はー、便利な時代だねぇ。

あとは木ねじを何本か締め込むだけで組み立てられる本体を、そうやって位置を合わせた束石の上に載せて完成。今回は「羽つき」という金属製の支えがついた束石を使ったので、それと本体を共締めしてしっかり固定した。けっこう高さがあるけどこれで微動だにしなくなった。腰が痛い。

おまけ: 今回もなぜか自慢気なグスタフ。

■ R1200GS、10年目の車検

2005年に購入してから、10年目の車検からGSが戻ってきた。屋内保管なのでぜんぜんヨレた感じはしないし、そもそも(予定に反して)4万kmしか乗ってないので、もう10年くらい楽勝で走れそうではある。というか乗るけど。

そういえばこないだ走っていたら警告が出てさ、こんなの:

いったいどういう意味なのか、どう考えても発熱する巾着袋にしか見えないんだけど、停車してぐるっと見てまわったら前照灯が切れてるという意味だとわかった。って、わかんねーよ(笑)。日本だと電球のソケットは下向きに描くけど、ドイツでは上につけるのだなぁ。まぁ一度見れば覚えるからいいけどさ、10年乗って初めて切れたよ。

電装系といえば、今回2008年につけた純正ナビが用をなさなくなってきたので外してもらい、スマホ一本で行くことにしたのだけど、実はその純正ナビをつけたときから起きていた不具合を調査してもらったのだ。スターターを押すタイミングによってこれらの外部装置に電源が供給されなくなる(しかもときどき復活する)という挙動があって、再現性があるけど原因がよくわからなかったので。

結果は車検から追加で一週間もかけたにもかかわらず「原因不明」。バッテリが弱いのではとか(新品ではないけど電流は十分だった)、供給先の電流が少なすぎて車載コンピュータが勝手に切っているのでは(純正ナビでそんなことが起きるとは考えがたい)など、仮説はあったがどれも否定的で、BMW本体に報告をあげてもらったけど、現状ではノーマルなやり方で直しようがないとのことだった。BMWでもそんなことがあるんだなぁ。

しばらく騙しだまし乗ってみるけど、スマホのナビは消費電力が大きいから、充電できなくなると死活問題になるので(方向音痴ならではの悩みである)、どうにもならないようならコンピュータを回避して直接バッテリから取り出すような改造をするしかない。やれやれ。

そうそう、店内にいるあいだ雨が降ってて乗れなかったんだけど、新型のRSが試乗可能になってた。まぁ、フロントがテレスコピックという時点で眼中にないんだけど*1、エンジンだけかけさせてもらった。キーがいらなくなっていたのでエンジンのかけかたがわからなかったけど(笑)、水冷になったのでエンジン音はずいぶんマイルドになったね。デザインはなかなかカッコイイけど、RSのくせにシートが低すぎて、試乗した客がみんな「ハイシートにしたい」と言うらしい。同意する。

で、そんなこんなで雨もやんだので出てきたら、家につく直前でまた盛大に降りはじめて、ひさびさにパンツまでぐっしょり……。

■ Herokuで動かすアプリにwebpack用のbuildpackを追加した

先日、Webアプリのフロント開発環境をnpm + webpackに移行してから、ぼちぼちと他のツールも加えていっている。

jQuery依存はほぼ断ち切れて、非同期通信なども含め babel-polyfill や whatwg-fetch で置き換えた。

フレームワークは redux にしようと思っていたんだけど、使ってみたという知人たちの評判がすこぶる悪いので、mizchi/flumptを試している。いやぁ、持続性のあるプロジェクトじゃないかも知れないけど、サーバサイドにRailsじゃなくてSinatra使ってるような人(おれ)だと、これくらい軽量なのが見通しよくていい気がするんだよなぁ。

次はUIフレームワーク、Reactとの相性が良いmaterial-uiを使おうと決め、たぶんいまや誰も使っていない(自分でも使ってない)BOOKSCAN Premium Optimizerを実験台にして実装していたら、依存するjsがどんどん増えて、ついにHerokuでboot timeoutが発生する事態に(笑)。いや、そもそもboot時にするもんじゃないのだよな、これ。手元の開発環境でも、productionのビルドするのに40秒くらいかかるし、しょうがない。

というわけで、泥縄的にwebpack用のbuildpackを導入することにした。自作するしかないかと思っていたけど、jerrysu/heroku-buildpack-webpackというのがあったので、コードを読んでから自分のリポジトリにforkして*1app.jsonに追加した。これでruby / nodejs / webpackと、buildpackの3連装だよ。大げさだなぁ。

でもおかげでboot時間は大幅に短縮できたのだった。……と思ったらminifyされてねーじゃんこれ。ちょっといじらないとダメだなぁ。

そういえば、こうするとビルド時にだけ必要なパッケージはdependenciesからdevDependenciesに移せるのかな? あとで試してみよう。

■ デレステイベント「咲いてJewel」

今回から2枚取りは6万位まで、1枚取りは12万位までに拡張されて、プレイヤー数の増加がうかがえる。人数増えたら上位に入りにくくなると思ってたけど、枠を拡大してくるとは、なんか最近のソシャゲは良心的だなぁ(←やや騙されてる感)。いつものように2枚取り狙いだったが、ボーダーの伸びが読めなかったから走りすぎてしまったよ。

https://www.amazon.co.jp/dp/B01FMZH2NK

その後、ジュエルが溜まったので10連回したら、3枚目のSSRが来た。Coが欲しかったのにPaが2枚になってしまった。バランスがとれない。

■ ミリシタ、アプリの提供が始まるも、サービスインはまだ

午後になってからGoogle Playで、次いでiOSにもミリシタのアプリの配信が始まり「いよいよか!?」と色めき立つアイマス界隈だが、それっぽい時間(15時とか17時とか)になってもサービスインしてくれず、とうとう公式が「おまえら落ち着け」という声明を出す始末*1。まったくだよ(←おまえのことだ)。

それはそれで「来月早々とかかねー?」とおしゃべりに興じているわけで、新しいゲームにはわくわくするのはしょうがない。はやく始まらないかなー。

■ ミリシタイベント プラチナスターツアー「咲くは浮世の君花火」(閃光☆HANABI団)

5thライブでいきなり初披露されて「このユニットと曲、めっちゃ好きなタイプ！」と気に入ってから、イベントになるまでずっと待ってたヤツ(いうほど待ってないけど)。「脳筋プリンセス」というあだ名に恥じないバカバカしいコミュも良かった。繰り返し出てくる「海のライブ」とやらがいったいどういう伏線(?)なのかさっぱりわからないのが消化不良だけど。THE@TER BOOST!のビーチバレーでからんだりするのかしらん。あれは海美がセンターっぽいし。

MMixの譜面は極端に難しくはなかったので、イベント期間中にフルコンできるかなと思ったけどムリだった。もうひと息だったんだが。ミリシタの曲はなかなか腕前が上がった実感がない*1。

3万ptで上位報酬がもらえるようになってから、この近辺のボーダーはガクッと下がって、ライブ30回クリアのミッションを普通にこなすとだいたいこれくらいの順位で落ち着く感じ。ガチ勢じゃないけど上位報酬は1枚くらい欲しい……という向きにはだいぶ楽になって良いね。それでもシャニマスする時間はまったく取れないのだけど。

https://www.amazon.co.jp/dp/B07CZD76RR