しゅみは人間の分析です

いらんことばかり考えます

プログラマとして健康への取り組み(1)

背景・問題点

大学生、大学院生と自転車には乗るもののまともに運動をしない生活をしてきた。また、麺や油の多い食品をよく食べる標準的なデブ食生活をしていたので、就職したとたんに贅肉が4, 5kgくらい増えてしまった。
プログラマとして1日に8時間も座る生活をしており、何らかの方法でカロリー支出を増やすしかなかったため去年の3月から対策を講じることにした。

目標

体重というのはわかりやすい指標だし、私も体重を目標にすべきだと思っていたところ、(異常に人間の骨格にくわしい)絵描きである妻*1が、体型のほうが重要だと言っていたので体型を重視するように認識を改めた。
確かに、身体の組成は人によって異なるので、体重という大雑把な指標で身体の肉づきを特徴づけられるとは言い難い。*2
また、客観的な評価が尊いのは確かなのだが、ご家庭にある数万円程度の体重計では精密で信頼のおける数値を出すのは難しいと思われる。*3*4
なので、主観評価でも良いので鏡の前に自然体で立ったときの見た目を指標にすることにした。そもそも、なんとなく鏡の前で自分を見てつらいなぁというのが出発点なので、そこを解決することに意義はあるだろう。

とりくみ(1)

ジム

月なみな手段としてまずジムを選択した。特に好きなスポーツも無いのが理由である。
ネットで近所のジムを見つけて契約を行い、5000円 / 月 + 約800円 / 回で通えるようになった。最初はインストラクターをつけてもらって、マシンの使い方の指導とトレーニング内容の設計を行ってもらった。
トレーニングの設計が終わってからは放牧状態になり、自主的にモチベーションをコントロールして通わなければならないようになった。今は月3, 4回通うようにしている。
ジムでの活動内容は、柔軟 -> 有酸素運動20分 -> マシントレーニング3周 -> 有酸素運動40分にしている。時間が無いときはマシントレーニングを優先して有酸素運動を省略することがある。

f:id:non_117:20170204210024p:plain

挿絵です。

ジム経過

背中と胸、上腹部の筋肉は増えてきたが、まだ目標達成と言える体型とはいえない。原因は有酸素運動(ルームランナーやオープンストライド)が不足していることで、脂肪があまり減っていない状態だと思われる。
グリコーゲンと脂肪の消費優先度みたいなものはあるが、結局身体はカロリーの入出力と筋肉いじめで体型が決まるので、脂肪を減らすには消費カロリーを増やすか、入力するカロリーを減らすかしか取れる選択肢がない。入力を減らすメジャーな方法が食事制限や糖質制限と呼ばれるもので、確かに短期間で結果を出すことはできるとは思うが、個人的な信条として受け入れられないのでこの方法は取れなかった。
かと言って有酸素運動はなかなかしんどいもので、とにかく時間がかかる問題がある。例えば時速5km/hで歩行しても1時間で400kcal消費できるのが良いところで、負荷の高いオープンストライドでも1時間あたり600kcalである。*51時間もルームランナーなどで過ごすのは本当に苦痛で、心理的には相当効率が悪い。まだ外を歩いている方がマシなので、最近は毎日数km余計に歩くようにしている。*6

マシントレーニングを経験してわかったのが、筋トレマシンは特定の筋肉に対して負荷をかけるようにできていることだった。確かに、腹筋などの自重トレーニングで大雑把に筋肉を痛めつけることは可能なのだけど、マシンを使うと関節の可動域が制限されるため、特定の筋肉を効率的に鍛えることができるようだ。*7

ジムまとめ

  • ジムは効率的に筋肉を増やすためには良い環境ではあるが、脂肪を減らすには苦痛な環境だった

時間がたくさんある、あるいはルームランナーについているテレビを苦痛なく見られる人はジムで有酸素運動をしまくれば良いと思う。しかし、暇なことに耐えられない人間は有酸素運動にコストをかけられないので、他の方法で消費カロリーを増やす必要がある。

 

長くなったのでいったん記事をわけ、次の記事では最も効果が出た歩行指導について書きます。

non117.hatenablog.com

*1:合気道経験者で姿勢が良い

*2:体脂肪率と組み合わせれば意味が出てくるが、後述のとおり家庭では正確に測るのが難しい

*3:ただし、ジムなどにある数百万円の体重計は数回の計測で筋肉量や骨量なども出してくれるので、そのような設備が気軽に利用できるならば数値を指標にしても良いと思う

*4:人体に抵抗はある以上、体脂肪率を測る方法も2極だと精度に難がありそうな気がするんですが、どうなんでしょうかその辺

*5:脂肪は9kcal/gで、1時間の運動がすべて脂肪から消費されるわけでもない

*6:歩行は最高で、歩きながら考え事をすると難しい設計もいい感じにまとまるので、どんどん散歩するようにしている

*7:まともなフォームでトレーニングを行えば

MacBook Proと4Kディスプレイその他の環境

MacBook Pro

Touch Barの13インチのやつを買いました。

キーボードが使いにくい、Touch Barなんて使わないなど諸説ありますが、スペックが上がっているだけで価値があると思っています。

レガシーUSBとの共存

 変換するためにこれを買いました。 

ヘッドホンやTime Machineバックアップ用のディスクなどを有線で繋ぐのにハブを使っています。お金がある人はストレージやヘッドホンやキーボードを無線化すると良いんじゃないでしょうか。

f:id:non_117:20161119150245j:plain

この変換アダプタの問題点がひとつあり、上の図のようにAUKEYの変換アダプタ同士が干渉するので、隣り合うコネクタには刺さないほうが良さそうです。

無理やり刺すといやな音がします。

4Kディスプレイ

気持ちが高まって買いました。

選択肢はそれなりにあって、先人の知恵として

r7kamura.hatenablog.com

ディスプレイ遍歴 - 9mのパソコン日記

この辺の記事が参考になりました。

40インチはでかすぎないか

PC用の4Kディスプレイには28インチ帯と40インチ帯にピークがあるのですが、個人的には40インチ帯のほうがおすすめです。確かに、届いたときはあまりの大きさに引くのですが、日常的に使っていたらディスプレイは慣れで縮みます。

また、幅100cmくらいのディスプレイを50cmの距離から見ると、だいたい視野すべてがディスプレイで埋まるので没入感が上がるような気がしています。

コネクタ

PS4 PROを4Kで繋ぐならHDMI 2.0対応のものを買いましょう。P4317QはHDMI2.0には対応していません。DisplayPortは2つあれば十分だと思います。

MacBook Proとの接続

在庫切れになっていますが、

https://www.amazon.co.jp/gp/product/B01EXKDRAC/

を買いました。

ケーブルが少し硬いですが接続性は全く問題がないです。

その他のポイント

MacBook Proに繋ぐケーブルの数

f:id:non_117:20161121231313j:plain

4Kディスプレイ環境で充電をしながら、レガシーUSBを繋ぐので合計3つです。

www.apple.com

この手のドック的なコネクタを買うと1あるいは2端子専有に抑えることも可能ではあります。

上記のように3本つなぐなら、Touch Barのモデルにするのは確定です。よかったですね。

Touch Bar使うのか問題

プログラマにはあまり恩恵無さそう……。

覚えられるくらいよく使うショートカットキーなら覚えているキーを押すほうが速いので、たまに使うかも?くらいの機能にTouch Barを割り当てると便利になるかもしれません。

ただし、ボタンとしてのTouch Barではなく音量や写真のフィルタのような連続値を制御するには良いインターフェイスだと思います。

 

 

以上です。どれも良い製品なので迷ったらこの構成にするとやっていきが捗ります。

ReactでもDOMの木構造はつらいよ問題

nippo.wikihub.io

Commented on 2016-09-01

何も考えずにReact, Redux使うような気はするのだけど、Reduxを使わない場合は各位どうやってState管理してるんでしょうか?

コンポーネントがstateとメンバ関数を持っており、子コンポーネントはpropsかcontext経由でその値を参照しながら描画とイベントバインディングを行っています。

日報で疑問を書いたら、id:r7kamuraさんが答えてくれた。

 facebookが想定してるのはこの用途かな。

原則として、木構造を小さくするべきだと思っている。木のデータ構造はノード間の依存関係があるからである。バケツリレーはノード間の結合を強くするので良くない。

なので、ページ全体のComponent木を部分木で構成するべきである。部分木の中でのstate置き場が部分木でのRootのContainer Componentで、子孫がPresentational Componentとなる。部分木とは、UI上で意味のある単位で分割されたComponent木である。

部分木同士が疎結合であるならば話は簡単なのだけど、部分木間でstateを共有したいとなると厄介なことになる。

仮に木全体のRoot Container Componentにグローバル変数を置いてもそれを子孫に渡すにはバケツリレーかcontextが必要になる。contextは暗黙的にバケツリレーしてるだけなので(ちょっと認識が合ってるか自信はない)部分木同士に依存関係が発生することに変わりはない。

部分木たくさん作ったときに、グローバルStateの注入で木同士の依存を発生させにくいのがRedux, [ここにあなたの好きなFluxの名前が入る] だと思っている。

私はReduxしか真面目に勉強しなかったのでReduxの話になるが、Reduxの場合は唯一のStoreにグローバル変数をぶち込んで好きなときに切り出して部分木に流し込むことができる。この時に部分木間でpropsが流れることはない。

 結論としてはこれになる。

原始的Propsバケツリレー

f:id:non_117:20160902230631p:plain

こうしたい

f:id:non_117:20160902230711p:plain

おまけポエム

とはいっても、人間は複雑なものを認知できないので、人間が直接触る木構造とかさっさと無くすべきだと思っている。スマートヒョンのGUI作る君だってGUIじゃないですか。

木構造は機械に優しいが人間には優しくない。特に変更をするときは。

UIとか作っては弄っての繰り返しを避けられないので木構造の変更・メンテナンスを人間がやるはめになって消耗必至である。

 

「君の名は。」感想, ネタバレ込み

君の名は。」を観たので言語化を行います。上映が終わって1時間も経っていないので大変新鮮なエモをお届けできることかと思います。ネタバレは多量に含むものとするので各位勝手にやっていってください。

 

 

客層

中高生メインで小学生も見受けられた。イオンで観たというのもあるかもしれないが。客層のせいか、せっかくのやまむらやCMが流れている間にも喋っている人が多くて大変よくない態度だった。でも、我々は大人なので慈悲の心で許さなければならない。

 

序盤

どのタイミングで入れ替わっているのかが多少わかりにくかったが慣れるとなんとかなった。OPが流れるまでのシーンですでに映像表現と5.1chサラウンドで脳がやられかけていた。桂川イオンの設備はULTIRAとかいうやつで、スクリーンがでかくて音が良い。眼前いっぱいのスクリーンにかわいい女の子と美麗な風景、光表現が登場するとオタクは速やかに脳をやられて死ぬ。

中盤

ちょっと退屈だったがぎりぎり没入できていた。たぶんここの筋に致命的な所は少なかったのだと思う。

終盤

おいおいまじか爆破させるのか。


これは許せない。
あと結局落ちちゃったのは、新海誠が蒸発→衝撃波を描きたかったのだと思っています。

ラスト

 

 

総括

記憶力を無にして素直に観ると大変良い作品だったと思う。後味が良くて象徴的な記号シーンでいい感じの歌が流れていたら脳直で人々は感動するんですよ。三葉がこけて手を開いたシーンとかで隣の席の女性泣いてたし……。

しかし、細かいところを突っ込みだすとキリがないくらいもぐらたたきができると思う。我々オタクはだいたいアニメの台詞を覚えて日常生活で喋っちゃうタイプなので、大筋に満足するのだけど細かいところが気になってモヤモヤするという現象が起きる。

 

なぜモヤモヤするのか

物語での整合性として、登場人物の気持ちで解決できるラインと、魔法で解決できるラインがあると思う。ヤシマ作戦とかの勝利が前者で、ウィッチに不可能は無いのが後者。ガルパンの特殊カーボンも後者。

フィクションである以上は気持ちが存在しない作品はおそらく存在しないので、これはある前提で良い。ここを疑ってはならないので、気持ちのパワーで秋の山頂で寝ても大丈夫だし、気持ちの力で山を高速に降りることができる。


問題なのは、魔法の存在とそのルールが視聴者に共有されるかどうかで、これが共有されてないと視聴者は混乱したり没入できなくなる。「君の名は。」でも魔法はいくつか登場しており、入れ替わりや酒と紐で物理はねじ曲がるのが主である。日記アプリのログが消えるのも個人的には絶対に許せないがそれは今いいです。
現代のフィクションでは物語の序盤で魔法のルールとその運用について視聴者に説明されることが多い。ラノベ原作アニメの第一話で見られるアレである。理想的には、最初のルールに原則従っていきつつ気持ちでルールをハックしたり、隠しルールを出す物語が視聴者にとってわかりやすいのだと思う。ただし、ルールが追加、更新されるさいには必ず視聴者への説明が必要になる。これが無いものはご都合主義のそしりを逃れることはできない。(既存の世界観やルールから自然に類推できるものが追加されるのであれば省略されることも多い気はする)


魔法の提示方法を踏まえたうえでの「君の名は。」での問題点は、現代っぽいどこかの世界を前提にしているのに、要所要所は未説明魔法で物語が進んでしまう点にある。簡単に言うとご都合主義にすぎない。というのも、我々は現実世界に生きているので魔法の説明がされなければ自然と現実世界ルールで物語を消費することになるからだ。
新海誠の世界が現実に即したものではなく、完全にファンタジーな世界であれば、多少変なことが起きてもそういう世界なんですねで済むのだが、現実世界ルールが適用されてるとなるとそれは守られなければならない。説明で例外が適用されない限りは。
だが、新海誠は鉄道とふすまのオタクなので現実世界を書かないわけにはいかないし、現実世界ルールが前提になっていると視聴者が覚えるルールが少なくて済むので一般人にとって楽というメリットもある。
このようにして、大衆的商業主義に舵を切ると現実世界ルールがベースになるのだけど、そこに追加ルールを敷いて全体の面白さと整合性のルールを守るのはけっこう難しい作業な気がする。

 

とは言ったものの、「君の名は。」のルール違反で私が思いつくのは送電網の単一障害点問題と、衝撃波での生き残りすぎ問題くらいで、大半は気持ち駆動で片付けられるような気はする。というか私は割と没入できてしまった弱いオタクです。。。
気持ち成分強めの作品は、気持ちの振幅が小さい人々には響きにくいので没入感が得られにくく、没入できないとなるとかなり冷静に物語を眺めるので物語のルール違反が散見されるのが各位が苦しんでいる現象ではないでしょうか。たしかに、気持ち多すぎは胸焼けするので良くないです。

 

(追記)

気持ちで物語を動かすのにも準備が必要で、登場人物みんなの気持ち遷移の整合性も重要そう。つまり、徐々に高まっていって状況を作り、最後にえいっと気持ちでキメるみたいな?

この状況作りができずに、我々視聴者の知らないところで勝手に主人公の気持ちが高まるとご都合主義だとか置いてけぼり感が出てしまうのだと思う。

(追記終わり)

どうすればモヤった視聴者は救われるのか

救われません。残念でしたね諦めましょう。

 

父との融和は???

ここまで書いて気がついたのだけど、三葉と父が最後の最後でかち合ってから避難するシーンが描かれていない。実は生きてたんよ〜演出をして視聴者をびっくりさせたいのもわからないでもないが、親子の確執をよくあるテーマとして記号的に出した割に解決しないのは中途半端で良くない。他に削れるシーンあるでしょ。

(追記2)

r7kamura.hatenablog.com

に記載されたやり取りでわかりもあったが、外伝小説読んだらすべて解決した。

www.amazon.co.jp

 

以上です。私はここまで言語化できたのでもう満足です。
それにしても三葉はかわいいですね。

なぜReactなのか

なぜReactなのか

React, Cyclejs, Reduxを学んだ上でこれらの技術が何を解決したのかまとめてみる。発想はオリジナルではなく、今まで私が読んだ記事から拝借した解釈などが含まれている。たぶんReact, Fluxを学んだ人にとっては当たり前の感覚を言語化しているだけの内容となる。

TL;DR

Q: なぜReactなのか
A: フロントエンドが自由度の高いGUIアプリケーションになった。既存の手法では自由度の高いGUI実装を人間にわかりやすく管理することが難しくなった。

自由度の高いGUIな世界

  • 自由度(複雑さ)の低い時代ではrender済みのDOMの上にDOMを操作する(jQueryによる)UIを載せる設計でも十分だった
  • 現代のwebフロントエンドではVisual StudioXcodeで作るネイティブGUIと同等の複雑さを求められる時代になっている
  • jQueryだけで複雑なGUIを実装するとDOMそのものが状態(State)であることが問題になる

    • DOMというグローバル変数に対してあちこちからCRUDする状況で、複雑さが増すにつれて人間にはメンテできないコードになる
      • クソコードと呼ばれる状況
  • React ComponentはDOMと状態を切り離した上でUI部品のコンポーネント化も行った点で優れていた

    • コンポーネント化は真新しい概念ではなく、おなじみの「関心の分離」
      • 人間にとって管理しやすくなることが重要
      • 再利用性が上る(こともある)、単体テストしやすくなるといった恩恵
      • コンポーネント化を担うのはReactである必要はない
    • 状態の管理は有史以来プログラマを苦しめ続けたやつ
      • たとえばサーバサイドだとDBとモデルに押し込めたり、マルチスレッドだとロックをきちんととったり
      • React Componentには this.state, this.props の変更を検知してDOMをrenderするライフサイクルがある
        • React Component単体ですでにDOMの状態を変更するフローは一方向になっている
        • DOMの状態を変化させるフローをUI設計全体に適用したのがFlux
      • FluxもReact Component同様に状態の変化に制約を与えるのが目的
        • 複雑な問題は制約を与えることで解きやすくなるし人間にとって認知しやすくなる
        • UI実装がスケールするならFlux層はなんでもいい
    • 状態の切り離し・管理とコンポーネント化を推し進めた設計が優れていたのであり、React, Reduxであるから無批判に良いというわけではない
      • React, Reduxにも問題はある
        • propsバケツリレーつらい問題
        • Reduxの非同期処理いけてない問題
        • React, ReduxそのものはStateとComponentをどう構造化すべきかフレームワークレベルの制約を与えてない(ドキュメントに指針はある Usage with React | Redux)
  • SPAであることが重要なのではなく、フロントエンドを複雑なGUI環境としてとらえる視点が重要ではないか

    • 自由度の高いUIを実装するには状態管理の制約とコンポーネント化があったほうが効率が良い
    • 要件で必要とされるUIの自由度によって適切な手段を選ぶべき
      • 自由度が低いなら今までどおりjQueryでもスケールする要件はある
      • 境界がどこにあるかは不明

今後

まとめ・言いたかったこと

「人工知能は人間を超えるか」という本を読んだ

www.amazon.co.jp

 

現役の研究者が、人工知能技術の現状と今後の展望について地に足の着いた視点で論じている本だった。
過去の人工知能ブームが何故収束し冬の時代を迎えたのか、そして今の人工知能ブームが何故もてはやされており、巨額の投資が行われているかを技術的な観点から語っている。

1~5章

ここを読めば、何故今の人工知能ブームとビッグデータ(付随してIoT?)が喧伝されているか理解できるはずだ。人工知能研究の黎明期から現代への流れと、要所要所の技術について、そしてそれを踏まえて何故ディープラーニングが優れているかを述べている。特に、ディープラーニングの要素技術である、特徴表現学習とロバスト性を獲得する手法についての解説がわかりやすかった。(オートエンコーダ, ドロップアウト

6章〜終わり

研究スライドでの今後の展望にあたるので、眉唾ぎみで読むと良いと思う。ディープラーニングを使って一発当てたい人は、参考にしつつ自分で頭を捻れば良いのではないだろうか。そもそもそれには大量のデータと計算資源が必要ということは終章で指摘されているが。
また、シンギュラリティによって人工知能が人類を支配するのか、という問は明確に否定されており、計算機の上で動作する人工知能が自己生産を行うのはコスト的・技術的に困難であることがよくわかる。
現在のブームの空回りしている点については明確に釘を刺しており、web上の適当なメディアの記事を鵜呑みにするよりはこの本を読むほうが良い。

ゆゆ式を無限に楽しみたかった話 〜 ゆゆ式 Advent Calendar 2014 20日目 〜

ある日のこと、後輩たちがこんなことを言いました。

ゆゆ式のコマをランダムに並びかえたら無限にゆゆ式が楽しめるのでは?」

真面目に計算してみると、10の15乗くらいの組み合わせができることがわかりました。
この記事ゆゆ式アドベントカレンダー20日目は、そんな無限にゆゆ式をたのしむためのシステムを真面目に作ってみた話をします。

コマの切り出し

漫画のコマを並び替えるためには、コマがバラバラな画像として存在していなければなりません。
なので、まずは自炊で電子化された書籍をコマの線にそって切り出していく処理を自動化することにしました。

f:id:non_117:20141220172013p:plain

上の図がふつうの4コマの1ページですね。これの枠線を識別して、1ページから8枚のコマを取り出してくる方法を考えます。

ハフ変換で直線検出

OpenCVという画像処理のライブラリに直線を検出するツールがあったので、まずこれを試してみました。

f:id:non_117:20141220172041p:plain

が、結果はこのとおり。

漫画には直線がたくさん含まれており、ノイズだらけでなかなか上手くいきませんでした。確かに枠の直線も検知されていますが、複数の線が検出されたりして微妙ですね。パラメータ調整をがんばったらそのうち上手くいきそうですが、あまりに面倒です。
よって、この方法はボツ。

ヒューリスティック導入

さて困ってしまい手も足も出ず放置することn日、天啓がひらめきました。

f:id:non_117:20141220173536p:plain

f:id:non_117:20141220173552g:plain

4コマの枠というのは、ページに対して水平に引かれています*1。なので、2次元の画像を縦(あるいは横)から眺めると、4コマの枠線は必ず同じ直線上に並びます。
そして、この直線上に並ぶ枠線は濃い黒色で、コマの内側は灰色、コマの外側は白色になります。つまり、行列の縦ベクトルのように画像を一方向から見て画素値を足しあわせていき、画素値の平均値が255付近から急激に変化する箇所がコマの枠線になります。

 

抽象的な話でわけがわからないかもしれないので、実際にグラフを見てみましょう。

まずは縦方向から画素を足しあわせて平均値を求めます。

f:id:non_117:20141220172257p:plain

このグラフは横軸が画像の横方向のピクセル(座標)で、縦軸が画素値です。ちゃんと枠線の数だけ4つのピークが見つかるのがわかりますね?

同様に横方向も見てみます。

f:id:non_117:20141220172313p:plain

枠線の数、8つのピークがちゃんとありますね。

このように、画素を足し合わせるだけの簡単な処理で枠線の位置を見つけられることがわかりました。実際には、ピーク値をもっと急峻にするために微分や画像のフィルタ処理をしています。
そして、このピークの値で切り出すべき線を引いてみたのが次の画像です。

f:id:non_117:20141220172409p:plain

以上のように、画像を縦横から見て画素値が急激に変化する座標を見つければコマの枠線を見つけ、全てのコマを切り出せるようになりました。
実際には、ゆゆ式の凶悪なフォントによってノイズが発生したこともありましたが、数が少なかったので閾値の調整でなんとかなりました。

ゆゆ式ガチャの完成

さて、これでゆゆ式全6巻すべてのコマをひとつの画像として切り出してくることに成功しました。あとはそれらを並び替えるだけです。この処理は単純にゆゆ式DBからランダムに4つのコマを取り出してくるだけでした。@tyage, @pastakくんが実装してくれたのが次のようなシステムになります。

 

f:id:non_117:20141220174522g:plain

ページを開くと、ランダムなゆゆ式画像が4つ表示されます。また、リロードするたびに4コマ?を生成するため、同じコマと出会うことはできません。一期一会です。

また、コマをクリックするとランダムでそこだけ入れ替わります。頑張ってガチャを回しまくればそれっぽいものもできます。

f:id:non_117:20141220172835p:plain f:id:non_117:20141220172843p:plain

 

これを作ってみた当初は皆頻繁にガチャを回していたのですが、なかなかおもしろい組み合わせは出てこなくてブームも下火になってしまいました。やっぱり原作が一番という結論でしょうかね。

 

以上がゆゆ式を無限に楽しもうとしたシステムの紹介です。

おまけ

話は脱線するのですが、このゆゆ式DBを作るさいに副産物的にゆゆ式の全台詞を書き起こしてIRC botにする計画が立ち上がりました。こちらの計画は、次のようなアノテーションツールを作るところからスタートしました。

f:id:non_117:20141220173024p:plain

1ページに切り抜かれた1コマが表示され、テキストボックスにその台詞や擬音語・擬態語を入力します。ショートカットキーを押すと次のコマに移動するものです。
また、キャラのタグ付けもすることになり、これもアノテーションツールになりました。

f:id:non_117:20141220173041p:plain

各キャラにショートカットキーが対応しており、キーを押すと選択されます。

このアノテーションを引き受けてくれたpossumさんですが、この作業に大いにハマってしまい、
ゆゆ式アノテーション無限に時間をつぶせる。レポート出すまで封印しないと……」

「短時間に過剰なゆゆ式を摂取すると体調を崩す恐れが」

「この前今日はここまでにしておこうって思ったけど結局その後も入力してたし吸引力強い」

などと言いながら3週間で全巻のコマの書き起こしとタグ付けをしてくれました。
このデータは今ゆゆ式のコマを文字列検索するシステムとして運用されています。

 

以上、ゆゆ式をきっかけに作ってみたシステムの紹介でした。当然の事ながらここで紹介したデータ・システムはインターネットで共有することはできません。もし作りたいという方がいらっしゃるなら協力しますので、そのさいはご連絡下さい。

 

*1:理想的には. 実際には傾いてしまうため、eTilTranを使って修正しました