それはインデックスを乱してまでやることなのか？

常日頃から「家から出たくない」「外は危険だ」と言っているけれど，たまに実店舗に出かけて買い物をすることもある．

そういうときにいつも思う．
商品を探すのがえらく大変である．

こういうのは，欲しいものが決まっている時に，余計に強く思う．

「これが欲しい！」とか「あれが欲しい！」と思っているのに，なかなか見つからないと，どんどんイライラしてくる．

これの原因は決まっていて，「商品の並び順が必ずしも一定ではないから」だ．

売れ筋商品，宣伝したい商品を別のコーナーに

これは本屋レベルで落ち着きのある店でも頻繁に行われている．

売れているものや，おすすめのものを，店の入口近くに配置する方法だ．

これにより，「普段なら個々にある」「周りのジャンル的にここにある」「ジャンル別の案内板的にはここにある」という指標がすべて役に立たなくなる．

せめて，同じ商品をジャンル別のコーナーにもちゃんと置いておいて欲しい．

並び順変えたらインデックスの意味がないだろう

と，正直思うのだが，みんなインデックスというものの意義を理解しているんだろうか？

せめて並び順を変えたなら，インデックスも張り替えないといけない．
そうしなければ検索できないのだから．

買うものが定まっている人に対して冷たくない？

こういう施策って，つまりは買うものが明確に定まってない人や，ふらっと立ち寄った人に効果が絶大になる．

それによって店舗の売上が上がるのなら，好きにすればいいとは思うけれど……．

すでに買うものが決まっている客の方が，確度が高いはずなのに，そういう客に対して冷たい施策じゃない？

買うもの決まってる人はAmazonにいけばいいってことなですかね．
そういう諦めを感じるくらいには，商品が見つからない．

いつになったら俺の目にはgrep機能が付くんだろうか．

バケモノの子が予想に反して面白かった

細田守のアニメとは，「ぼくらのウォーゲーム」や「おジャ魔女どれみドッカーン」くらいからの付き合いになる．

前作「おおかみ子どもの雨と雪」が，思ったよりも全然面白くなくて，細田守のメジャー路線に付き合う気力を完全に失わせてくれた．
おかげで今回の「バケモノの子」に関しても，宣伝を見た時からメジャー路線感をすごく感じていたし，あまり期待していなかった．

そもそも，「時をかける少女」「サマーウォーズ」とSF路線をたどってきた細田アニメが，いきなりファンタジーに，それでもいい話に振ってきたので，非常にげんなりしていた．

そこは今回も変わらず，ファンタジーものであることは否定できなかった．

だけど，そんな予想を上回って全然おもしろかった．

オタクっぽい要素の内包

相変わらず誰でも見られる

以下のレビューの後半部分は非常に的を射ている気がしている．

movie.maeda-y.com

確かに細田守作品は，オタク要素を清々しく描くことに長けている．
ただ，そのオタク要素をオタク要素っぽく見せずに，話しを進めていき，気づかないうちに我らオタクを楽しませている．

もちろんそういったオタク要素としての楽しみ方ではない方面で楽しませている．

「サマーウォーズ」を見たときに思ったのは，「これは誰でも見られるように作られていて，それでいて楽しい」ということだった．
その基本を外してはいない．

たぶん，これの反対を行くのが押井守のアニメなんだろう．

アニメはこれでもいい

最近アニメに対しては，かなり「これでいい」という気分になることが多くなってきていて，正直，そんなにオタクっぽいアニメを追い求める必要もないと思っている．

もちろん，それで楽しめる領域もあるんだけど，そういうアニメはそういうアニメで，ちゃんと他の人がやってくれれば良い．

そして，細田守作品の目指す方向が，オタク方面ではないことが，そろそろはっきりとわかってきた．
誰でも見られるというのは，「これを知っていないと話がわからないだろう」「これを知ってると実はこんな楽しみ方が」みたいなものを押し付けないということだ．

オタクっぽい，というのは，これをかなり要求してくる．
なぜかというと，そもそもオタク文化というのは「知れば知るほど面白い」というのが根底にあるからである．

だからオタクどもはアニメ本編だけでなく，関連する情報を目ざとく見つけてきては我が物顔で話したりする．

そして「これはオタク向けだ」と思わせるようなアニメというのは，そういったオタク文化，知ってて当たり前，というのを前提に作られ，それを知らないと面白くないようなものが多い．

細田守作品は，明らかにその路線ではなくなっているのがよくわかる．

ジブリを目指す

こういった，オタク要素をひっそりと入れ込んでいるにもかかわらず，話全体を別物として見せることができ，かつ面白いアニメを作り続けるというのは，スタジオジブリの宮﨑駿が非常に，芸術的なまでに上手い．
細田守は，「おおかみこども」あたりから，スタジオジブリを目指している感じがひしひしと伝わってきている．

というのも，今まで話したように，オタク要素を隠しながら，全体を楽しく見られるアニメを目指しているように見えるからだ．

そして，もう一つ凄いところは，「オタク要素を隠して」というところだ．
隠しているから，実は本気で読み解こうとすると，「知れば知るほど面白い」という文脈が存在する．

そういうものを残しているからこそ，表層が「だれでも見られる」形にしてあっても，我々のようのなオタクが楽しめる．

そういう意味では，今回の「バケモノの子」は良い要素をたくさん持っている気がしている．

若干の詰め込みすぎ感

ここからは具体的な内容についての話しをしよう．
話としての面白みをすごく感じていたのは，どちらかというと前半だった．

後半は，いつもの細田守のアニメっぽい．

• ひとりぼっち同士の仲の良さ
• ２つの世界を行き来する
• 闇を抱える

おそらく俺が面白いと感じていたのが，最初の要素で，ひとりぼっち達の喧嘩と仲がよくなっていく過程だ．
だから，旅をする辺りはもっと長々と描くのかと思っていた．

ストーリーの要となるのは，主人公の葛藤だと思うのだが，前半は「仲良くなれない」というところだ．
実は映画のキャッチコピーを見ても，今でもやっぱりここはもっと長く取ってもいいと思っている．

で，後半になると，主人公は人間界に帰れるようになる．
ここで「どっちの世界に残るのか」という葛藤が出てくる．

今回，あまりヒロインを長々と描いていないので，ちょっと蛇足感があったのだけれど，ここで出会うヒロインと，バケモノの世界との葛藤は，あまりメインのストーリーではない気がしている．
その証拠に，この葛藤は大きく問題視されることもなければ，根本的な解決を導き出そうとするわけでもない．

ただその後に発生した別の問題が覆いかぶさってきて，なし崩し的に終わってしまった．

このへんは，「じゃぁ出す必要合ったのか？」と思うところではある．

なんか，闇を抱えた同じ立場の友達を出すだけであれば，もっと別の描き方をしたほうが，このヒロインの蛇足感がなかった気がするんだけどなぁ．

題材として思い返すのは「カクレンボ」のような不気味さ

「現実世界の渋谷から，バケモノの世界へ通じている」という不気味さは，実に良い．
そしてそれが描かれるのが夜の街であるあたりは，描写的に非常に良い．

夜の街にある不思議さや不気味さみたいなものが出ているので，実はここはもうちょっと怖く描いても良い気がしている．

それは千と千尋のような神隠し的な要素でもあるし，ちょっと思い返したのは「カクレンボ」というアニメだった．

カクレンボ – cwfilms

カクレンボ OVA [DVD]

アニメーションとしての動きと止め

絵の話を少ししよう．
「おおかみこども」のときは戦闘シーンがまったくなかったので意識することがなかったのだけれど，「サマーウォーズ」以降，かなり良い格闘シーンが見られる．
今回の「バケモノの子」でも，戦闘シーンは結構でてくるので，なかなかに楽しめる．

特に素手同士での格闘が多いのだけれど，その描写はなかなかに緊張感があって引き込まれる．

動きと止め，緩急の付け方が非常に良い．
パンチを繰り出すとき，パンチを出す瞬間を見せない．
そして動いている手のみを見せるので，スピード感のある動きになる．

こういうのをすべて連続的に描いても，実はあまり速く動いているように見えない．

そしてよく止まる．

パンチを受けた時，打ち終わった後，そういう登場人物からしてみれば一呼吸置く瞬間というのをよく表現していて，一瞬止まる．

それによって，戦闘シーン全体の緩急が気持よく，もちろん痛い絵にはなっていくのだけれど，キレがいいもんだから清々しさを感じられる．

これは，「サマーウォーズ」の戦闘シーンでもよく見られた．
が，今回の方が圧倒的に戦闘メインなので，見どころが多い．

そして，汗の飛び方なども加わっていて，重量感が増している．

非常に楽しく見られた

もう結構歳をとってしまったのか，アニメの見過ぎなのかわからないけれど，映画館に行って2時間集中して見られるアニメというのは，やっぱりそんなに多くない．

そういう現状でも，これは時間を忘れて見ていられた．
ファンタジーは，実はたまに現実に帰ってきてしまうのだけれど，そういうこともなく，2時間きっちり俺をアニメの世界に閉じ込めておいてくれた．

ネットには賛否両論あるんだけど，俺はおすすめしたい．

UITextView内のカーソル位置をCGRectで取得する

iOSでTextViewというと，UITextViewを使うのが一般的だ．
いろいろとイベントが用意されていて楽なのだが，カーソル位置を取得するのに結構迷ったので書き残しておく．

目的は，UITextViewのインスタンスが与えられたところから，カーソル位置をCGRectで取得することだ．

まずは，UITextView内のカーソル位置を，相対的にでもいいので取得する．

カーソル，キャレット，というより選択範囲が取得できる．

let textRange: UITextRange = textView.selectedTextRange

何も選択していなければカーソルの位置が帰ってくる．
ただし，型はUITextRangeだ．

次にこいつをCGRectに変換する．

let position: CGRect = textView.caretRectForPosition(textRange.start)

textRangeはその名の通り，範囲を示している．
それを，UITextPositionの値にしてやる．
今回は，範囲選択されてない前提だったので，startにした（範囲選択されてないのだからendでもいい）．

で，そしてcaretRectForPositionしてやると，見事CGRectになる．

UITextRangeやUITextPositionまでは調べると簡単にわかったのだけれど，CGRectにするのはなかなか見つからなかった．

参考

the moon at dawn: UITextFieldのキャレットを操作（UITextRangeとUITextPosition)

stackoverflow.com

stackoverflow.com

twitterにおけるフローの循環とストックという異物

Twitter、また協力サービスへの締め付けを強化か、OpenTween などの投稿制限

もはや絶望しかない．

サードパーティー製クライアント（Whalebird）の製作者として，正直呆れ果てて絶望としか言えない．

また，GFeedLine，Tween，夜フクロウ，HootSuiteを愛用している，利用者としても，呆れることしかできない．

俺はtwitterというサービスが大好きだ．

だけれど，最近のtwitter社は大嫌いだ．

twitterというサービスの基本理念は，非常に心地よいものだった．
それに対して，twitter社は，利益の拡大，広告の拡大という戦略を打ち出し，本来あった基本理念を次々と潰している．

サードパーティ製クライアントの話も，そもそもtwitterが初期にあれだけ流行っていたのは，クライアントの力を借りていた部分がかなり大きかった，という話は元記事でも触れられているのでここでは深く触れない．

今日はそれのついでに，最近twitterについて思っていたことの話をする．

最近嫌いなのは「不在中のできごと」というアレ

最近，Web版のtwitterに入ると，「不在中のできごと」というのがツイートの最上部に表示されている．

内部のアルゴリズムについては不明だが，これは俺がtwitterを見ていなかったときの誰かのツイートをサジェストしてくれている．

こんな機能はいらない．
というか，これはtwitterというサービスにとって邪魔でしかない．

フロー情報とストック情報

twitterは，当初短文投稿サービスという位置づけで売り出していた．

twitterが画期的だったのは，過去のツイートが参照できなくなるという仕様だった．
twitterは過去3000件を超えるツイートが取得できなかった．

これが技術的な限界だったのか，それとも仕様によるものだったのかは，俺は知らない．
ただし，使う人にとっては，これがtwitterの使い方として定着した．

即ち，流れてくる情報にのみ気を使い，過去の情報については触れない．

そういう意味で，twitterはことごとくフロー情報にのみ注目している．

地震などがいい例で，地震が発生するとまっさきにtwitterで検知できる．
みんなが地震のことをつぶやいていて，すぐに震源地情報まで発覚する．

だけれど，じゃぁ一ヶ月前に起こった地震の情報をtwitterで検索しようと思うと，それは至難の業だ．
というか，やろうとする人もいないと思う．

フロー情報を循環させる仕組み

それだけでは，情報はただ流れていくだけで，情報の間に優位付がなされない．

そこでRTというものが登場する．

RTは，面白いと思った発言を，自分のタイムラインに載せることができる．

これにより，フロー情報として一度流れ去ってしまったものを，再びフロー情報として流し直すことができる．

これがうまく機能していれば，ストック情報は必要なくなる．

twitterというサービスにとって，重要な情報は，RTされてひたすらフローの循環を繰り返す．
情報がストックとなることがない．

twitterにおいて，Fav以外の機能はほとんどフロー情報を扱うものでしかない．

これが俺にはtwitterの基本理念として，心地いいものに感じる．

そういうフローの中にいるからこそ，この世界のコミュ障ヒキコモリどもがここまで活性化するんじゃないか．

明らかにフロー情報でないものをフロー情報と一緒に出すな

RTという文化，Userstreamの開放，そういったtwitterの流れはひたすらフロー情報を循環させることを目的としてきたように思う．

「バルスに耐える」というような逸話も，あんなつぶやきに意味などない．ストックする必要があるものなど何一つない．
単に，瞬間的なフローの増大に耐えるプライドの戦いに見えた．

それに対して，「不在中のできごと」とは何事か．
Facebook気取りなのか．

フロー情報の一番上に，ストック情報を流すとはどういう神経をしているのか．
ストック情報的な機能というだけの話ではない，それらを混ぜあわせて表示しているところに，プライドはないのかと問いたい．

はっきり言って，ゴミが付随しているようにしか感じられなかった．

ストックの必要性と外部化

従来より，twitterはその基本理念と思えるフローの循環化には熱心に取り組んでいたと思う．

反面，Fav以外のストック方法を持たなかった．

twitterを流れるフロー情報のストック化は，ひたすら外部のサービスに任されていた．
twilogなどが代表的だ．

もちろん，それがtwitter社が巻き取れる利益と捉えているのかもしれない．

でも，だとするなら別のものとしてやれば良い．

サービスの基本理念を曲げてまでやるものなどない．
あくまでtwitterというサービスはフロー情報にこそ価値を置いて欲しかった．

そもそもストックする必要がある情報はtwitterには少ない．
もちろん有益な情報も流れてくるのだが，たいていは別のソースによってWeb上に存在するものが多い．

だからこそ，ストックは外部化する程度で事足りていた．

これはおそらく車の両輪で，フローしか扱わないからこそ，それに見合ったしょうもないつぶやきが多く，それによってユーザーが多く面白いフローができている．
これを無理やりストック化しようとしても，しょうもないつぶやきがストックされるだけで，ストックを必要とする人にとっては無意味だ．
そしてフローを必要とする人にとっては，ストック化されることによりフローがつまらなくなっていく．

作らないという選択

前々からいろいろなところで見聞きしていて，すごく重要だと思うことがある．
俺がWebサービスを作るのを趣味でやっていたり，仕事でやっているからWebサービスに話を限定させてもらうが……

「これはやらない」

ということを決めることは非常に重要なことなんだ．

サービスの基本理念に背くような追加機能は，たとえそれで一時的にユーザーが喜びそうな予感がしても，作ってはいけない．

せっかくtwitterというサービスが，フローという新しい情報の流し方を提示していたのに，その理念に真っ向から反対するような機能は，（便利と思うユーザーがいたとしても）作るべきではなかった．

それによってtwitterというものが壊れることに気づいていないのか．

だったらFacebook見ればいいじゃん．

だったらTumblr見ればいいじゃん．

しばしば，エンジニアとしてはこういうものを考えないといけない．

twitterの「不在中のできごと」にしたって，中身のアルゴリズムを実装しようと思ったら相当エキサイティングだ．

いろいろな方法が考えられるし，試行錯誤のやりがいがあるのは，非常に同感する．
エンジニアリングとしてかなり面白い課題なのは理解する．

だけど，それはサービスに載せるべきものなのかは，たとえエンジニアであっても考える必要がある．と思う．
ましてやユーザーにもエンジニアが多く，会社もエンジニアが主体になることが多いWeb系の会社なら，なおさらだ．
エンジニアが考えなければ，誰が考えるというのか.

Capistranoでバックグラウンド処理を発火する

Capistranoでバックグラウンドジョブを実行させたいときがある．
監視スクリプトなんかがいい例だ．

そんな時，2タイプの記事を見つけた．

• sleepすればいいよ

d.hatena.ne.jp

• $ /dev/nullリダイレクト

qiita.com

どちらも正しいのだけれど，おそらく両方が成功するわけではない．

というのも，これは別の設定に依存している．

ptyという設定

Capistranoのはptyというオプションがある．

set :pty, true

このオプション，デフォルトではfalseになっているが，結構trueにする記事も見かける．

quanon.hateblo.jp

qiita.com

そう，ptyとは仮想端末の割り当てフラグなのだ．

sudoなどはわかりやすい例で，やってみればわかるとは思うが，sshでコマンド引数からsudoを実行する際などに必要になる．

仮想端末があるかないかによって変わる

例えば，& /dev/nullという設定はコマンドラインでよく見かけるバックグラウンドジョブの起動方法だ．
これがきっちりバックグラウンドに移るのかどうかについては，以下の記事が非常に詳しい．

技術/UNIX/なぜnohupをバックグランドジョブとして起動するのが定番なのか？(擬似端末, Pseudo Terminal, SIGHUP他) - Glamenv-Septzen.net

おそらくこの場合，ptyで割り当てられた仮想端末が終了するときに，同時にプロセスを殺してしまっている．これは，プロセスが「STOP状態 + J_NOHUP有」になるからだ．そのために仮想端末がSIGCONTを送信してしまっている．

では，sleepは仮想端末が死んだ時，どうなるのか．
これは，sleepが付くことにより，プロセスがrunning状態になる．
これにより，上記記事の「RUNNING状態 + J_NOHUP無 」に該当し，SIGCONTとSIGTERMが送信されなくなる．そのため，プロセスは生き残る．

しかし，仮想端末がない状態でsleepしても，単にCapistranoの実行が待たされるだけで，別にバックグラウンドに移るわけではないので，次の瞬間にはプロセスが殺されてしまう．

どうすればいいの？

ptyがtrueのときはsleepで

仮想端末がある場合は，上記の通り，sleepで対応する．

set :pty, true

namespace :deploy do
  task :hoge do
    run "(cd $DIR && (nohup sh ./background_script.sh &)) && sleep 1"
  end
end

ptyがfalseのときは& /dev/nullで

仮想端末がない場合は，通常のコマンドライン上でのバックグラウンド処理と同様になる．

set :pty, false

namespace :deploy do
  task :hoge do
    run "sh -c 'cd $DIR && nohup sh ./background_script.sh &' >& /dev/null"
  end
end