isyumi_netブログ

isyumi_netがプログラミングのこととかを書くブログ

モデリング関数

僕がモデリング関数と呼んでいる概念の話をしたい。

 

DBから落としてきたデータをもとにビジネスロジックを書くと、関数の引数が増えすぎてうざくなる経験はないだろうか。

例えばTwitterを作っているとして、AさんがBさんをフォローしているか判定する関数はこうだ。

(followsはFollowテーブルのレコードの配列だ)

if(isFollow(toUserID, fromUserID, follows)){
// 処理
}

投稿数が5以上のユーザーをフィルターするのはこうだ。

users = filterPostCount(users, posts, 5);

どうも汚い。

オブジェクト指向言語で書く以上こういう風に書きたい。


if(user.isFollow(toUserID)){
// 処理
}

users = users.filterPostCount(5);

これを実現するためにはそもそも生データ用のクラスとビジネスロジックで使う用のクラスを分けるといい。僕は前者をEntity、後者をModelと呼び、EntityをModelに変換する関数をmodeling関数と呼んでいる。

EntityはDBのスキーマと1:1で対応し、ORMがインスタンスを作ってくれるものだ。


// エンティティ
class UserEntity {
String userID , name;
}

class FollowEntity {
String to , from;
}

// モデル
class UserModel {
String userID , name;
List<FollowEntity> follows;

bool isFollowTo(String to) {
return follows.where((f ) => f.to == to).isNotEmpty;
}
}

// モデリング関数
List<UserModel> modeling(List<UserEntity> userEntity , List<FollowEntity> follows ){
// ここにいろんなフィルターとかマップとか
}

これで目的が達成できた。

欲を言えばEntityとModelを一つのオブジェクトツリーにぶら下げることで、全てのmodeling関数を共通化することができる。そうすれば、どんな時もとりあえずEntityを取得して一種類のmodeling関数にかければいいということになりわかりやすい。


class Entities {
List<UserEntity> users;
List<FollowEntity> follows;
// その他いろんなエンティティ
}

class Model {
List<UserModel> users;
// その他いろんなモデル
}

// モデリング関数
List<Model> modeling(Entities entities ){
// ここにいろんなフィルターとかマップとか
}

この方法のメリットは「そのオブジェクトに関することは、そいつに聞けばなんでもわかる」状態になりコードが綺麗になることだ。

デメリットは、そのビジネスロジックに必要のないところまでモデリングするためリソースが無駄になることだ。

注意点は、Modelに生やすメソッドはそのModelの状態を書き換えてはいけないということだ。単に聞かれたことに答えるだけの関数を書こう。

このような反論が想定される。クラス自体を分けずにEntityにメソッドを生やすだけではダメなのか。それをしようとするといつどのタイミングで関連するEntityをそのEntityに配ればいいのかわからないからダメだ。

今回はサーバーサイドを例に説明したが、本質的にデスクトップアプリでもWebアプリでも使えるテクニックだ。僕はReduxでmapStateToPropsとReducerの先頭でStateをModelに変換している。

考え方の背景を説明しよう。データを保持するということとそのデータをもとに何かを判断するということでは、求められるデータ構造が異なる。

前者は重複がなく、極力1操作で状態を更新でき、矛盾しづらいデータ構造だ。

後者はそのオブジェクトに関することはなんでも知っている方がよく、データの重複は問題ではない。Twitterのフォロワー・フォロイーの話なら、AさんオブジェクトがBさんをフォローしているという情報を持っておりBさんオブジェクトもAさんにフォローされているという情報を持っていてもかまわない。

f(保持用のデータ) = 判断用のデータ

の関係になっており、判断用のデータは毎回保持用のデータから作成されそして使い捨てになっているといい。

 

Active Recordとかの話は長くなりそうなので省略した

10年のプログラミングの変化

お断り:僕は数年前まで東海地方のクソ田舎に住んでたので「時系列がおかしい!」と思った方は、それは都会↔田舎のタイムラグです。東名高速道路オーバーヘッドです。死罪死罪。

Java

一番俺史が長いJavaについて。

まずJavaアップレットがなくなりました。ブラウザでJavaが動くって相当夢広がリングだったと思いますが、支持を得なかったようです。

その後ちょうどJavaFXが満を持して登場して「JavaGUIの覇権来るか!」って時にAjaxからのHTML5の潮流に飲み込まれてしまいました。

その代わりサーバーサイドのJavaは元気みたいですね。

あと、文字列処理系のミドルウェアJavaが強いみたいです。

それに、Javaが「速い」扱いされるようになったのは大きな変化じゃないでしょうか?

レンタルサーバー

昔はCGIを置くのは簡単でしたがプロセス常駐型のプログラムを置く場所を確保するのは大変でした。だからPHPPerlが使われてたんですね。きっと。今ではNode.jsやGoで書いた常駐プロセスを簡単に公開できるので便利ですね。

静的型付き言語に揺り戻し

業界的に「動的型付け言語はちょっと……」という空気が増した気がします。僕は昔のことはよく知らないので「人類はなぜ動的型付け言語なんかを普及させていたのだ」と思ってます。僕が就職する前にいい感じにして置いてくれた皆様ありがとうございます。

>人類が静的型チェックなしの動的スクリプト言語に費やしたこの20年くらいは、将来黒歴史として語り継がれるかもしれません。

六本木ではたらくソフトウェアエンジニアへのよくある質問とその答え (FAQ) (2015 - 2017) — hayato.io

ところでスクリプト言語(ざっくり言ってコンパイルしない言語)で静的型付きってDart以外に何があるんですかね。TypeScriptを直接実行するVMとか出てくるんですかね。

 状態を持たない

我らが伊藤直也さんのこのスピーチ、傑作だと思うんですよね。僕が言いたいことを全部言ってくれてます。

www.publickey1.jp

 この状態を持たないようにするという流れがこの10年の最大の進化だと思います。

 

感想

ちょうど本格的にプログラミングを始めだしたのが10年前くらいだな~。

思えば遠くへ来たものだ。

ホリエモンさんを見て「俺もプログラミングを勉強すれば億万長者になれる」と思ったのです。

想像していたよりはるかにプログラミングができるようになったのに、5,000兆円は手に入りませんでした。

【緩募】配列Aと配列Bを引数にA→B変換経路を返す関数の一般名が知りたい

僕には「こういう関数って一般的になんて言うの?」と思ってる概念があります。ご存知の方がいらっしゃいましたら是非教えていただきたいです。

知りたい概念をざっくりいうと「配列Aと配列Bを引数にA→B変換経路を返す関数」です。一般名詞とかあるのでしょうか?

経路をJSON化したいので高階関数で渡されるのはちょっと困ります。たぶん下記の代数的データ型の配列で受け取れるものと思います。

enum Step{

  add(value), remove(index), set(index, value)

}

 多くの言語の配列には.whereや.mapや.reduceが生えています。そんな感じで生えてたらいいと思います。

 

例1

空の配列と [ 1 ] を引数に取った場合「1を追加する」を返す。

 hoge( [ ] , [ 1 ] ) ; // [{ type: "add" , value: 1}]

 

例2

[ 1, 2, 3] と [ 1, 2 ] を引数に取ると 「2個目の要素を消す」を返す。

 hoge([ 1 , 2 , 3] , [ 1, 2]); // [{ type:"remove" , index: 2}] 

 

例3

[ 1, 2, 3 ] と [ 1 , 2, 4 ] を引数に取ると「2個目の要素を4で上書きする」を返す。

 hoge([1 , 2 , 3] , [ 1, 2 ,4]); // [{type: "set" , index: 2, value: 4}]

 

例4

違いがたくさんあってもいい感じに配列で返してくれる。

hoge([ 1 , 2 , 3 , 4 ] , [ 1 , 3 , 4 , 5 ]);

// [

//   { type: "remove", index: 1},

//   { type: "add" , value: 5} ,

// ]

 使途

  • MVCでMの変化にVを追従させたいときに使う
  • サーバー・クライアント間の通信の容量削減
  • 二次元配列の圧縮(MPEGの理屈)
  • データベースを洗い替えしなくてよくする
  • 配列を変更したときのログを見やすくする
  • Thread間通信で、重い処理をするワーカースレッド側に負荷を押し付けてUIスレッドを軽量化する
  • (↑と同じ話で)WASMでRustとJSの通信に使う

これまでの調査

レーベンシュタイン距離っていう似たような概念を見つけました。ただ、僕がほしいのは距離ではなく道筋です。

MATLABに近似導関数っていう似たようなのがありました。

PHPのarray_diff関数も似ていますが、この出力と元の配列だけで次の配列を100%復元できないのでダメです。

欲を言えば

上記の例ではJS風オブジェクトで書きましたが、バイナリのほうがパフォーマンス的によろしそうです。エンコーダーデコーダー、見やすいロガーがセットだといいです。

どんなプリミティブな操作が許されているかを段階的に指定できるといいと思います。ADD、REMOVE、SET以外のみ、REVERSE、SLICEしてもいい、FILTER、MAPしてもいい等。

たぶん

React.jsの中にそういう部品はあると思うのでコード読んでみようかなー。

 

 

 

 

 

 

2017年読んだ本の1行感想

2017/11

失敗の科学

 失敗を「絶対に起きてならない事」とすると余計に重大な失敗につながるが「減らそうと」すると減る。

未来型国家エストニアの挑戦

 日本もこうなったらいいのになーと思う。ただ、国民IDを「最初の二桁が生まれた年で~その次の一桁が性別で~」的な設計にしてるのはダサいと思った。

世界を破綻させた経済学者たち

 経済学で定説とされているようなことが、実はただの論に過ぎず特に証拠もないという話。

月をマーケティングする

 今年一番面白かった本の一つ。実はアメリカ人はアポロ計画にそんなに積極的ではなかった。そんな中どうやって何年にもわたり莫大な予算を確保し続けたのか。アポロ計画の技術的な挑戦と別にマーケティング的挑戦に挑んだ人たちの話。

トップランナーの才能を引き出した情報空間

 清水亮さんのブログで紹介されてたから読んだ。

東大卒プロゲーマー 論理は結局、情熱にかなわない

 ときどさんの自伝。最初は誰よりもひたすら必勝パターンを練習することで頂点に立ったときどさんのプレイスタイルが変わっていく話。

少女

 湊かなえ好き。あらゆる善意と悪意が何もかもが悪いほうに転ぶスタイル。

絶望の裁判所

 一般的な裁判官のイメージは「頭でっかちで少々世間ずれしているが、実直でまじめで高潔な人たち」だと思う。僕もそう思ってた。しかし、現在の裁判官の評価制度のせいでおかしくなっていく実態が暴かれる。

重力とは何か

 難しかった。

福島第一原発 1号機冷却「失敗の本質」

 なぜメルトダウンが起こったかについて、丁寧な調査に基づく問題点の分析が面白かった。誰が悪いとかではなく、「こういうことをしてるといざというときにやらかすよね」という話。組織人は一度読むといいと思う。

騎士団長殺し

 村上春樹の最新作。やっぱり面白い。

世界一の生産性バカが1年間、命がけで試してわかった25のこと

 正直この本は面白くなかった。


2017/10

ビジネスモデル症候群

 起業したい人はすぐにビジネスモデルを考え始めるが、ビジネスモデルなんてそこまで大事じゃないから。という主張。


2017/09

バッタを倒しにアフリカへ

 前野ウルド浩太郎さんの本。すごい人だなと思った。


2017/8

バッドエンドの誘惑~なぜ人は厭な映画を観たいと思うのか

 世の中のバッド映画本を語った本。正直ほとんど知らない映画ばっかりだったのでそこまで評価高くない。

システムを外注する時に読む本

 ううん。僕はあんまりこういう光景に出くわしたことはない。

初めてのWatson APIの用例と実践プログラミング

 読んだはいいが、いまいち利用シーンが思い浮かばなかった。

ブロックチェーン 仕組みと理論

 ブロックチェーンを自分でも書いてみようと思って読んだが、詳しい仕様が載ってたわけではなった。

現代農業入門

 農業的なゲーム作ろうと思って読んだ。でも今どきの農業って想像していたような牧歌的な感じじゃなくて現代工学感満載らしい。

どんなストーリーでも書けてしまう本

 ストーリーって結構型があるんだよ。

オブジェクト指向実践ガイド

 実践的だと思う。

アルケミスト

 すごく面白かった小説。みんなも読むといい。

現代知識チートマニュアル

 これをちゃんと覚えたら割と簡単に雑学王になれそう。でも、読みながら思ったんだけど中学高校レベルの国社数理英をちゃんと勉強するのが先決だと思う。

恐竜は滅んでいない

 僕も小学生くらいまで恐竜博士だったんだけど、その時と学説が大幅に変わってるようだ。継続的に勉強しなければいけない。

未来の年表 人口減少日本でこれから起きること

 日本ヤバい。

縮小ニッポンの衝撃

 もうホント日本ヤバい。

生き心地の良い町 この自殺率の低さには理由(わけ)がある

 同町圧力が強い場所は自殺率が高いらしい。

 

極論で語る睡眠医学

 専門用語が多くてあんまりわからなかった。

蜜蜂と遠雷

 われらが恩田陸直木賞受賞作。

メタセコイアマスターブック

 3Dモデリング楽しかった。でも難しかった。趣味でゲームとか作るときもクラウドワークスしていこうと思った。


2017/7

three.jsによるHTML5 3Dグラフィックス

 https://games.isyumi.net/pinball/

 ゲーム作ったからやって。

HIGH OUTPUT MANAGEMENT

 インテルの伝説的社長アンドリュー・グローブのマネジメント論。別にマネージャーじゃなくても仕事で役に立つと思う。

 
2017/6

僕だけがいない街

 マンガ全巻読んだ。こういうストーリ思いつける人すごいな。

罪の声

 グリコ・森永事件ってのが昔あったんだって。

悪童日記 アゴタ クリストフ

 rebuild.fm でnさんがおすすめしてたから読んだ。面白かった。

効きすぎて中毒になる 最強の心理学

 意中の女性に使ってみたが、まったく効かなかった。「最強の心理学※ただしイケメンに限る」みたいな話だろこれ。

無気力なのにはワケがある

 心理学の実験でわかったこととして、うまくいかないことが続くと「自分はだめなんだー」って思いこんじゃうんだって。気をつけなはれや。

上半身位筋肉をつけると肩がこらない

 今年は筋トレを頑張った。肩こりは治らなかった。

エンダーのゲーム

 これもrebuild.fmでおすすめされてたから読んだ。面白かった。長門有希の百冊に入ってたんだってね。


2017/5

ランニングの作法

 今年もランニング頑張った。2年間で1000キロ達成した。継続が力なり。

アーサー王と円卓の騎士

 なんとなくストーリーは知ってるけど誰も読んだことはない小説の代表格。読んでみたところ円卓の騎士たちの話かと思えばサー・ラーンスロットが最強なだけの話じゃないか。


2017/4

箱男

 キモオタキモイ。

きみがモテれば、社会は変わる

 悪かったですね。

工場日記

 インテリの女の子が下級層と一緒に働いてみた日記。


2017/3

プログラミングElixir

 一時期Elixirに取り組んでた。ただ、自分はやっぱり型システムで防御していくほうが好みだと思った。

スエズ運河を消せ

 イギリス軍が戦争にマジシャンを投入してドイツに勝つ話。砂漠の中で大量の戦車を消したりする。「マジシャンが人をだましてるんじゃなくて、人間は自分から騙されに行っている」

女騎士 経理になる

 くっ殺せ! どんな職業であれ、基本的な簿記の知識は持ってたほうがいいと思う。

下半身に筋肉をつけると「太らない」「疲れない」

 筋トレしましょう。

集団主義という錯覚

 TLでkmizuさんがおすすめしていて買った。日本人は自分たちのことを集団主義的だと思っているが、実際そうでもないらしい。

荒神

 宮部みゆきはすごい。


2017/2

禁断の魔術

 ガリレオシリーズ。面白かった。

リスクにあなたは騙される

 2001年のテロ直後、アメリカ人は飛行機を避けるようになった。しかし、飛行機は世界で一番安全な乗り物の一つ。飛行機をやめて車で移動すると余計事故にあう確率が上がる。怖いか怖くないかじゃなくて正しくリスクを見極めましょうという話。

矢倉囲いを極める77の極意

 矢倉囲い、相手の右桂馬が飛んで来たら終わるよね。

ネット炎上の研究

 ずいぶん懐かしい炎上話が紹介されてた。大沢あかねブログ炎上事件とか。あとカノッサの屈辱も取り上げられてたけど、それSNSの炎上事件って言わないでしょw

虐殺器官

 SF小説

日比谷公園

 まだ公園っていう概念がなかった時代に初めて公園を作った人の話。


2017/1

あなたの人生の物語

 SF小説

山椒魚

 僕ももうこの年齢だと外に出れなそう。いや、中に入れなそうかな。

何者

 就職活動に関してはプログラマーって恵まれてるよね。

量子物理学の発見 ヒッグス粒子の先までの物語

 自分は何もできないけど科学者を応援しようと思う。もし、プログラマーの需要あったらTwitterでDMください。

TensorFlow始めました

 微分積分よくわからん。あきらめ。

ずっと受けたかった要求分析の基礎研修

 本を読んでもよくわからん。

天才

 自分はこういうどぶ板タイプの政治家好きじゃなくて、会計とか海外の政策とかに精通した実務家タイプの人が政治家になったほうがいい気がするんだけど、やっぱりそれじゃあうまくいかないんだよね。きっと。

チームが機能するとはどういうことか

 外科医の話。手術において外科医は一番偉いらしい。周りに指示をするのが仕事だった。しかし、これだけいろいろなIT技術に支えられるようになると、看護師さんなどに正しく指示をしてもらうのが仕事になった。

はじめよう! 要件定義 ~ビギナーからベテランまで

 やっぱり本を読んでもよくわからん。思うにこの手の本は「急にITの現場に放り込まれた素人に仕事内容を紹介する本」として出版されているのではないだろうか。僕が求めてるのは「一通りプログラミングもできるしこれまでたくさんシステム作って運用してきたけど、要件定義とかは我流になりがちだからちゃんとしたやり方を知りたい」という人のための本である。

Scratchでつくる!たのしむ!

今年小学生にプログラミングを教えるということを初めて見た。

2017年、Twitterで知った新常識

今年Twitterで「お前そんなことも知らないのかよwww」「知らなくても気づけよwww」と煽られている人を発見したが、正直知らなかったことをメモした。

お前らの常識のハードル高すぎだろという揶揄を込めて。

コンロはガスボンベが爆発しないように使わなければいけない

 

乳児にはちみつを与えてはいけない

そんなことよりもその後に見かけた「たとえ本人の無知が原因とは言え、我が子をなくした母親をいたわる気持ちはないのか?」的なTweetのほうが刺さった。

 月は自転している

これは知ってた。

筒井康隆は炎上する

慰安婦についての発言で筒井康隆さんが炎上したことについて、「逆に今まで筒井さんをなんだと思ってたの?」という反応が目立った。僕も筒井康隆さんのことは知ってたが、炎上常連客だとは知らなかった。界隈的には典型的な「才能はすごいけど人間性はダメ」な人とされているらしい。

togetter.com

美術館の学芸員さんと監視員さんは違う

山本幸三・地方創生相「学芸員はがん。一掃しないと」 発言に批判相次ぐ

もともと政治家の失言に端を発した話。一般の方なので晒さないが、その発言を見たあるTwi民が「学芸員なんて美術館で座ってるだけじゃん」と書き込んだところもらい炎上してしまった。僕も学芸員さんのことはよく知りませんでした。

 

昔の地図にセントレアはない

正直、言われて初めて気が付いた。俺が地図の絵を描く担当者だったら確実にやっちまってた。

 マーキュリー計画

マーキュリー計画について、日本の映画配給会社が「マーキュリー計画とか知名度内からアポロにしとけ」ということで勝手に名前を変えたところ炎上。早速Twitterに「マーキュリーは常識か否か」各位の所感が投稿された。僕は知ってたけど常識とは程遠いと思う。

 言語コミュニティを揶揄するような冗談はやめよう

なんとなくメモのリストに入ってたけどジャンル違うかも。これは本当に知っておくべきことだと思う。とある言語コミュニティについて「怖い人が多いw」みたいな冗談に対して、コミュニティの中の人からの「冗談でもやめてほしい」という趣旨のTweet。僕も言ってた側なので気を付けようと思った。

 お気に入りバーは気を付けよう

 科学者たちを大切にして 科学研究事業に専念できるように 保障してあげなければならない

生理は毎月来る

これは知ってた。普通に保健体育で習うよ。そんなことより、真偽不明だが地震が起きた時に被災地の配給担当の職員の方が生理についての知識がなくて避難所の女性たちにドエライ迷惑をかけてしまったといういたたまれない話を聞いた。俺もいつか似たようなことをしでかすんじゃないだろうか。

togetter.com

togetter.com

パスワードを定期的に変更してはいけない

変更しても意味がないということは知っていたが、より危険だというのは初めて知ったかもしれない。一般ピープルはワンパスワードでおk。というか、Web系のサービスは全部GoogleとかTwitterのOAuthでいいだら。

www.newsweekjapan.jp

おぼれた時に助けてと叫んではいけない

人間、体の2%しか浮かないんですって。だから手を挙げるとその分顔が沈む。それよりも顔が常に水面に出る姿勢を維持するべきだという。僕は初耳だったが結構常識らしい。

dual.nikkei.co.jp

nVidiaは大企業

日経の人は知ってたと思うけど、さすがに知らない人も多いのでは。

ちなみにこの直後にファーウェイも謎の企業扱いされてた。

 カタカナのポルトガル語が書かれた看板の意味

見た瞬間「作ったやつバカだらwwww」って思ったけど、それは僕の不見識だった。

twitter.com

圧縮効果

望遠レンズで遠くにあるものを撮ると、非常に離れた物も近づいて見える現象のことらしい。知りませんでした。新聞社の人が知らないのは問題かもしれないけど、決して常識ではないよね。

togetter.com

近くに適当な建物がない場合は、物陰に身を隠すか地面に伏せ頭部を守る

ミサイルが飛んできたときに取るべき行動を政府が発表したところ、当初は内容を馬鹿にするTweetが目立ったが、徐々にいろいろな証言Tweetが集まり、実はちゃんと過去事例に基づく合理的な内容の広報だったと反省した。

togetter.com

犬にブドウやマスカットを食べさせてはいけない

気を付けよう。家には猫がいたから以下を食べさせないようにというのは言われたことがある。

togetter.com

北朝鮮のミサイルはPAC3で撃ち落とせない

どうも日本に落ちてこない限り高さ的に無理らしい。知らなかった。

 トリアージ

そんな言葉知らなかった。

 Shame on you.

英語の授業でShameは習った気がするが、Shame on youという言い回しは知らなかった。

 

その他些細すぎることや出展が見当たらなかったもの

高校生か大学生くらいの政治活動に熱心な方が「閣議決定」の意味を知らずに批判したところ、「内閣は議員から質問主意書が来たら答弁を閣議決定するっていうルールになってるの知らないの?」と返されていたが、俺も知らなかった。

シーチキンは登録商標だと知らずにTweetした女性がいたが、俺も知らなかった。

藤井聡太さんの発言「僥倖」。

CPUのことをMPUって言うらしい。

 

以上。

 

 

スターウォーズの感想。

ネタばれあります。

 

スターウォーズ EP8見終わったので感想を書く。

 

テーマについて

ストーリーはいろんな大人の事情の上に成り立っているものだと思うが、あえてそこには触れない。続編を作らないといけないとか誰々が活躍するとスポンサーが喜ぶとかそういうのはいったん置いておく。

今回のテーマは主に二つあると思う。

一つは「ヒーローにならなくていい」である。

ポー・ダロメンは最初の戦闘で降格させられた。

フィンとローズはトラッカーの停止に失敗した。

あのアル中野郎はヒーローになるよりお金を選んだ。

さらにフィンはキャノンの破壊に失敗した。

唯一英雄的な活躍をしたのは代理提督さんだけだった。

終始徹底して「戦う、倒す」よりも「逃げる、守る」が高く位置付けられた話であった。

もう一つのテーマは「血筋じゃない」だ。

スターウォーズ4~6は「血筋がすげえ奴が無双する」という話になりがちだった。

しかし、今回はそういうのがなかった。

レイがジェダイの島の鏡に親を見せてもらうシーンはとても緊張した。

あらゆる選択肢があったと思う。

オビワンの孫、アナキンに弟か妹がいた、パルパティーンの孫、クワイガンの孫、ウィンドゥの孫等々。

しかし、結局つまらない話だった。

もちろん自作以降で本当の親が明かされる可能性がある。

しかし、僕はこのままでいいと思う。

ローズもフィンも含めてただの名もなき労働階級生まれの子が自分の責任を果たすという話でいいと思う。

 

カメラワークについて

カメラワークが素晴らしかった。

僕は映画はほとんど見ないのでその手の芸術的要素についてはわからないが仕事でUI・UXを考えることが多いので「どう見せたら説明しづらいことが伝わるか」について悩むことが多い。

冒頭のレイア姫とカイロ・レンの目が合ってることがわかる構図やその後レイとカイロ・レンの目が合ってることがわかる構図、あるいはカイロ・レンとレイが一緒にスノークの護衛と戦ってるシーンでカイロ・レンには背後が見えてることがわかる構図などいろいろあった。

特に好きなのは、鏡の中で自分の分身と一緒に指を鳴らすシーンだ。

その中の、野球観戦中のウェーブのように後方の自分に合わせて指を鳴らすという行為。

ジェダイはめちゃくちゃ殺陣が強いが、その理由が「相手の動きが見えてるから」だそうだ。

これはなかなかジェダイにしかわからない感覚だと思う。

しかし、この動画ですごく納得がいった。

要するに戦ってる最中のジェダイには自分がどう動けばいいかがあんな感じで見えてるんだと思う。

後ろからくる自分に合わせてタイミングよく太鼓の達人感覚でライトセーバーを振るといい感じに敵が倒せるってことだろう。

この説明力はすごいと思った。

 

課題

僕がまだよく理解できてないこと。

まず、ストーリー上の不思議として

ジェダイって結局なんだ

・あの島はどこだ

・あの本には何が書いてあるんだ

・レイは何者か

などがあげらえる。

それとは別に、いまいちメッセージがつかみきれないことがある。

一つはヨーダはEP8において、あるいはスターウォーズ全体において何の役割を果たしんだ、ということ。

これは2ちゃんのコピペなどにもあるが、ヨーダは実際結構ポンコツである。

「突き詰めればジェダイが崩壊したのは全部ヨーダが悪くね?」と言ってしまえるほど役立たずである。

しかし、重要なキャラクターとしていまだに登場人物に道を示唆する役割を担っている、ように見える。でも話の中身がなさ過ぎていてもいなくても変わらない気がする。

きっと僕が見落としているだけで、本当は何か大事な仕事をしてたんだろう。

二つ目はルークの死に方だ。

僕を含めて全員がカイロがルークを切る瞬間、ローブを残して消えることを期待したと思う。

しかし、実際はもっと地味な死に方だった。

なぜルークはそれを選んだのか。

もちろん、ライトセーバーをレイが持って行っちゃったとかフェリーの定期便が3日に1回だとかいろいろ理由はあったと思うが、よくわからない。

結局フィンがルークを、カイロがベイダーを、ポーがソロを越えられないのと同じように、ルークもオビ=ワンを超えれないということなのか。

最後にカイロ弱すぎないだろうか。

もちろん十分強いんだが、スノークの護衛に囲まれたシーンでも、「あ~アナキンならこのくらいの人数10秒で蹴散らしてたな~」って思う。

前作からもカイロ弱い説はさんざん指摘されていたと思うが、今作で確信した。彼が弱いという事は何かの伏線である。

意図である。

自作では強いカイロを見たい。

 

あと、ルークの島に湾にルークの戦闘機が沈んでるのを見たとき、ルークがレイに戦闘機をフォースで持ち上げろと命じるシーンを期待したが、なかったね。

 

常に最新のcreate table文を用意しておこう

create table文は現在のTableの状況を説明する最も大切なドキュメントだ。テーブルのスキーマがわかるだけではない。foreign key文からリレーション関係が読み取れる。index文からパフォーマンスの要所がわかる。

実際のシステムのDBはalter table文でどんどん更新されていくものだが、その都度create table文をバージョンアップしてほしい。