ブレードランナーは良い

映画の中ではブレードランナーが一番好きだったりする。次に好きなのがソナチネで後はぱっと思い浮かんだのがマッドマックスか。

とにかくブレードランナーという映画はマジで素晴らしくて人類の宝なので見たこと無い人は見たほうが良いです。以下ネタバレするのでブレードランナーを見てなかったら読まないほうが良いです。

 

ブレードランナーを最初に見たのは確か大学3,4年の冬ぐらいだった気がする。当時の私は、大学の勉強は面白くないし、将来どうするかよくわからんしで、かなり参ってて映画ばかり見てた。大学の近くに、よく古い映画とか上映してる映画館があってしょっちゅうそこに行っていた。後は中央図書館が映画貸し出しててそこで見たりしてた。ある時その映画館でブレードランナーの上映企画があって、ブレードランナーブレードランナー2049を連続で上映するみたいな企画だった。私はブレードランナー2049を見たくて、ついでにブレードランナーも見るか、みたいな気分でブレードランナーを見たのだった。古い映画だし、ネットで難しくてあんまり面白くないみたいな意見も見たからね。初代ブレードランナーについては全然期待してないのだった。

 

初代ブレードランナーを見て本当に驚いた。人間とは何か、生きるとはどういうことか、という哲学的な視点、雨とネオンの光が降り注ぐ、サイバーパンクな街のあまりの美しさ、暗くてジメジメしていて退廃的な雰囲気。すべてが素晴らしくパーフェクトだった。

 

何よりも私が気に入ったのは、映画の終盤、ハリソン・フォードが人造人間のボスのルドガーバウアーに追い詰められて、ビルの屋上から落ちそうになったシーンだ。私はもちろん落ちないだろうと思っていた。でも、ここから助かるイメージが全く沸かなかった。ハリソン・フォードは人造人間の連中を皆殺しにしてきて、ルドガーバウアーとしては仇であるわけだ。ここからどうやって助かるのだろうか、と思っていると、ルドガーバウアーがハリソン・フォードを力強く引き上げるわけである。私としてはメチャクチャ困惑した。ハリソン・フォードが困惑したのと同じくらい困惑した。引き上げたルドガーバウアーはゆっくりとハリソン・フォードを見ながら、かの有名なモノローグを呟き、そしてゆっくりと目をつむって人造人間の寿命で死ぬ。

 

f:id:earthminami:20210909231630p:plain

I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain. Time to die.

 

このモノローグには本当に打ちのめされた。生まれて始めて英文を丸暗記したほどである。とくに最後の詩的表現が良すぎる。All those moments will be lost in time, like tears in rain. 雨の中で絞り出すようにゆっくりと呟かれるその言葉は言葉の力強さを初めて理解したような気分になった。

 

今思い返すとここでルドガーバウアーがハリソン・フォードを助けたのはいろいろなコンテキストが想定されるわけである。例えば、ルドガーバウアーは直前に人造人間の研究者に合っているから、「実はハリソン・フォードが人造人間で、本人は知らない」ということを知っており、だから仲間のハリソン・フォードを助けた、というコンテキストもあり得るわけである。ただ、私はそうではないと思いたい。ルドガーバウアーは今まで人造人間として生きてきて、強制労働や戦闘に巻き込まれて非人間的な地獄を見てきた。それでも、生きていたいと思うくらい素晴らしい光景を見てきて、自分の生を肯定している、そのことを仇であっても死ぬ直前に人間にわかってもらいたかった。そういうコンテキストのほうが美しいのではないかと考えている。

 

とにかく、この映画と最後のモノローグには打ちのめされてエンディングが終わったあともしばらく呆然とするほどであった。それくらい素晴らしかった。

あまりにも初代ブレードランナーが良すぎたせいで当初の目的だったブレードランナー2049はCGが現代的なこと以外はとにかくチープにしか感じられず、何の思想も感じられず、面白くない映画にしか感じられないほどだった。単体で見ていれば面白かったかもしれないけど。

もうこの映画が好きになりすぎてサイバーパンク2077とかいうゲームが発売されたときは有給とって遊んだくらいだ。残念ながらそのゲームには期待を裏切られたけど。

 

そんなわけで、ブレードランナーは私にとってどんな映画よりも好きな映画になったわけである。

 

 

 

アジャイル開発とスクラムについて

はじめに

アジャイル開発とスクラムについてまとめました。こういう働き方が出来たら楽しいだろうな、というのが一番の感想です。SCRUM BOOT CAMP THE BOOKのチームもスクラムについては色々経験不足だったりしてますが全体的に良い人が多そうで本当に楽しそう。

アジャイル開発について

 従来のソフトウェア開発ではウォーターフォール開発という手法がデファクトスタンダードだった。ウォーターフォール開発においては要件定義→基本設計→詳細設計→実装→単体テスト結合テストシステムテスト・受け入れテストというように進むのが基本だった。  しかし、このウォーターフォール開発というものは製造業、ハードウェア開発などでは向いているもののソフトウェア開発には不向きな開発スタイルであった。何故かと言うと、要件定義後に顧客・利用者が実際にソフトウェアに触れることが出来るのはシステムテスト・受け入れテストの段階になり、その時点においては要件定義段階で存在していたニーズがすでに変化していることが多かったからだ。また、ウォーターフォールにおいては不必要なドキュメントが生成され、そのドキュメントをまた基本設計担当、詳細設計担当、実装担当、テスト担当というように要件の又聞きで進められることになり、要件定義で決まったことが正確に下流工程に伝わらないことがあるなどのデメリットがあった。  ハードウェアと異なるソフトウェアの強みというのはいつでも変化を加えることができるということであるはずだ。ハードウェアの製造方法を参考にしたウォーターフォール開発はソフトウェア開発にはマッチしないと言わざるを得ない。そこで提案されたのがアジャイル開発である。  アジャイル開発というのは顧客や利用者からのフィードバックを反映しつつ、漸進的に進めるソフトウェア開発の手法である。はじめに最低限動作するミニマルなプロダクトを作成し、それに対する顧客とユーザからのフィードバックを受け、改善を加えてソフトウェアをあるべき姿へと変化させていく。  アジャイル開発を可能にしたのは幾つかの手法である。それは、続的インテグレーションと継続的デリバリー、自動化されたテスト、ソフトウェアの柔軟な変化を可能にする設計方針、変化に強いプロジェクトマネジメントなどの導入である。  これらの手法により、ソフトウェア開発者はソフトウェアに対して漸進的に変化を加えつつフィードバックを受けてより改善するための力を手に入れることができた。これらの手法の導入によりアジャイル開発は可能となり、アジャイル開発スタイルは現代のソフトウェア開発のデファクト・スタンダードとして採用されている。

スクラムについて

チーム構成

スクラムチームは以下の構成になる

  • スクラムマスター
  • プロダクトオーナー
  • 開発チーム

見積もりと計画

ベロシティ

プロジェクトを進めるにあたって、何の作業をいつまでに終わらせるか決める必要がある。 必要な機能を洗い出し、それぞれのポイントを開発チーム内で決める。 決める際にはプランニングポーカーなどで決める場合がある。 決めたあと、すべての合計ポイントを算出する。例えば、合計が200ポイントになるとする。 2週間を1スプリントとし、1スプリントに20ポイントを獲得するとすると、 プロジェクトは20週間で終わることになる。 この1スプリントで獲得する合計ポイントをベロシティと呼ぶ

ユーザーストーリー

どんなユーザー[who]がどんなときに[when]どんなところで[where]どんなふうに[how]どんなこと[what]をしたいのか、機能を作る際にユーザーストーリーとして決めておく。決めておいたユーザーストーリーはそのままスプリントレビュー、受け入れテスト時のデモ手順として利用できる。

進捗確認

スプリントが始まったあとは順調に進んでいるか確認する必要がある。

デイリースクラム

多くのスクラムチームでは朝会形式で15分程のミーティングを行うと良い。 これをデイリースクラムと呼ぶ。

スプリントレビュー

スプリント完了時にはそのスプリント内で完成したものを顧客に見てもらう。 デモ状態でも確実に動く状態で見せられるようにする必要がある。 動くソフトウェアを披露し、顧客からフィードバックを得て次回以降のスプリントに活かす。

計画の変更

ベロシティの変更について

ベロシティを上げる要求が発生するケースもある。例えばリリース日を早めたいなど。 安易に人員を増加するなどで対応した場合、ベロシティが安定せず、むしろベロシティが下がるなどの状況もありえる。人員を増やす場合は計画して取り組む必要がある。

ゴールの変更

状況によってはやむを得ない要因により、ゴールの変更を行う必要性が出てくることもある。 その際に調整が可能なのは、予算、期日、スコープになる。 予算は上記ベロシティの変更にあるように必ずしも予算の増加がベロシティ改善やゴール達成へつながるとは限らない。期日については変更できれば追加可能なリソースも増えるが、その分予算が増えたり、期日自体が変更できないケースも多い。一番有効なのはスコープの変更になる。やるべきものを選択し、必要ないものは削除する取捨選択を行うことでよりゴールへ近づきやすくなる。

問題の報告

スプリントが遅れる要因となる問題が発生したときはチーム全体に共有するようにする。場合によってはスプリントを中断するなどして問題に対処するケースもある。いずれにしろ問題が発覚した時点で速やかに共有を行う。

参考資料

www.amazon.co.jp

www.amazon.co.jp

www.amazon.co.jp

ストップウォッチゲームを作ってみた

ストップウォッチゲームをTypeScriptの練習として作ってみました。

npx 334-stopwatch-gameで実行できます

実行するとカレントディレクトリにjsonファイルが生成されるので注意

www.npmjs.com

正直、大したこと無いゲームですが、思いの外考えることが多くて楽しかったです。 ゲームロジックが3, 4行なのに対してスコアの保存やスコアの表示、ゲームの起動などに何十倍も処理が書かれていて、 果たして自分は何を書いているんだ…。という気持ちになりましたが、そんなものでしょう。

本当はデータの永続化をaws lambdaとファイルの二種類にしてユーザが自由に選べるようにしたかったんですが、 aws lambdaがわからなすぎてモチベが無くなり、諦めました。今後の課題にします。

だいたい学んだこととしては、

  • 責務の分割
  • Interfaceを実装して動的にロジックを切り替える手法(Strategyパターン)
  • 浮動小数点同士の計算
  • staticファクトリメソッドによるオブジェクトの生成
  • JSONファイルにおける配列の保存方法
  • node.jsのエラー処理
  • TypeScriptの型の書き方
  • 軽量DDDもどきでの保存ロジック
  • node.jsのファイルシステム
  • inquirerの使い方
  • npm publishの行い方

ショボい何の目的もないアプリケーションでも作ってみたら結構勉強になりますね。

TypeScriptがかなり好きで、大分慣れてきたので、もう少しこんなふうに小さいアプリケーションを何個か作ってみたいです。

React ハンズオンラーニングを読んだので感想

感想

こちらの本を読みました。

結論としては結構いい本だと思いました。5点満点中4点くらい。

Reactの概要から始まり、JavaScriptの基本知識、Reactの仕組みの概要、具体的な使い方、 具体的なReactフックの使い方、フックによるステート管理、useMemo, useCallbackによるパフォーマンスの効率化、 REST APIとGraphQLでのリソース取得、リソース取得の効率化、エラーハンドリング、静的解析、テスト、おまけでルーティングやSSR 等々を具体的なアプリケーションを作りながら学ぶことが出来ます。

Reactについては公式チュートリアルが未だにクラスコンポーネントになっていたり、 色々と古い知識が点在していたりして、何が今のベストプラクティスなのか調べるのに骨が折れるのですが、この本では恐らく最新のベストプラクティスに準拠した形で知識が纏められており、わざわざ古い知識をフィルタリングする必要性が無いです。 ここまで丁寧に必要な部分だけを抽出して纏められている本は他に無いのではないでしょうか。 薄い本なので深く学ぶことは出来ないでしょうが、この本で得た知識を元に詳細な部分を調査するのは難しくないでしょう。

注意点としてはサンプルアプリケーションの設計がメチャクチャで、コンポーネントの名前付けも超適当。どこに何が書いてあるのか理解しづらい気がしました。 この本の構成として、最初にアンチパターンや古い方法を見せて苦しみを与えて、それを楽に解決してくれる新しい方法を提示してくれるので、このサンプルアプリケーションにおいても もしかしたらわざと酷い設計にして後でリファクタリング過程を見せるつもりなのかと途中で思いましたが、どういう訳かリファクタリングの過程が省かれており、読者が自分で行う必要があります。

あと、サンプルアプリケーションをそのまま実装してもeslintのエラーがたくさん出てきます。 そのまま実装しても動かない部分もあり、信じがたいことに筆者の作成したサンプルページを見に行っても正しく動いていません。

私はあまり詳しい人間ではないのですが、本書のサンプルアプリケーションのコードは良くない設計と実装として批判的に見たほうが良い気がします。 Reactのプロからの正しい評価をお待ちしてます。
oreilly-japan/learning-react-2e-ja 本書のコード

1章 Reactの世界へようこそ

簡単にReactの概要と環境構築を教えてくれます。ここで先に付録も見たほうが良いです。create react appで本書の実装を進めるのがおすすめです。

2章 Reactに必要なJavaScriptの知識

Reactを学ぶための最低限必要なJavaScriptの知識を教えてくれます。当然ですが詳しくはないのでわからない部分はjsprimerなどを参照したほうが良いです。

3章 JavaScriptにおける関数型プログラミング

map, filter, reducerなどの関数の使い方と、関数を合成してロジックを組み立てる考え方を教えてくれます。 この章の最後では小さい関数をいくつも合成して簡単な時計アプリケーションとして動く、関数型JavaScriptソースコードを見せられます。ここで、私は「え…こんなの無理…。書けない…。」と思ってしまったのですが、別に書けるようになる必要は無いと思います。関数型JavaScriptが書けなくても小さい関数を合成してロジックを組み立てる考え方さえ理解できればReactは使えるようになります。

4章 Reactの基本

Reactの仕組みについて簡単に紹介してくれます。ここは、読み飛ばしていい気がしました。

5章 ReactとJSX

このあたりからReactの具体的な使い方を教えてくれます。

6章ステート管理

useState, useContextを使ったステート管理を教えてくれます。reduxは出てきません

7章フック

useEffectやカスタムフックの実装方法、useMemo, useCallbackなど、レンダリング時のパフォーマンス最適化について教えてくれます。

8章データ

REST APIやGraphQLでのリソース取得について教えてくれます。仮想リストやデータ取得時のパフォーマンス最適化なども教えてくれます。 ここらへんで手を動かして実装を始めたのですが、サンプルコードが良くないです。サンプルレポジトリからそのままコピペしても動かなかったりします。 具体的に言うと、ページ199のRepositoryReadme.jsの実装について、react-markdownのv6以降では、sourceが廃止されており、childrenというpropsにmarkdownを渡す必要があるので、そのままでは動かず、注意が必要です。 他にもいくつか問題点があるように思えます。

10章サスペンス

この章ではReactに現在実験的に存在している幾つかの機能について紹介してくれます。 ここまで読んでいるうちにクライアント側の例外処理やエラー監視をどうやってやるのか気になりましたが、エラーバウンダリという機能でサポートしているようです。 サスペンスはpending状態のpromiseをキャッチして保留用の処理を行うことが出来ます。 サスペンスとエラーバウンダリを使用することで、非同期処理の成功、失敗、保留に応じた処理を行う事ができます。 fiberについてはReactの内部機構変更の話なのでとりあえず知っておくというだけで良いと思いました。

11章 テスト

jestを使った振る舞いとレンダリングのテストを教えてくれます。

12章 ルーティング

react routerを使ったルーティングを教えてくれます。react routerは面倒くさそうですけど、next.jsならルーティングが楽みたいですね。

13章 SSR

サーバーサイドレンダリングについて教えてくれます。

終わりに

全体としては非常によくまとまっていて、この本を読めばReactにとてもスムーズに入門できると思いました。 誰かからReactの勉強を始めたいと言われたら間違いなくこの本をオススメすると思います。

vue3 composition APIでautofocusを実装する

はじめに

vue3 composition APIでautofocusを実装するのが結構大変だったので忘備録として書いておく。

autofocusの定義

unruffled-roentgen-467661.netlify.app

例えば、componentが更新されたときに、input要素に自動的にフォーカスを当てたいときなどがある。

f:id:earthminami:20210808160847p:plain

この新規作成ボタンをクリックして編集モードになったとき、

f:id:earthminami:20210808160942p:plain

このinput要素に自動でフォーカスされているとユーザーフレンドリーだと思う。

これを実現したい。

実装方法

結論としては、カスタムディレクティブを使用し、コンポーネントのmount, updateのタイミングでfocusさせればそれで実現できた。

カスタムディレクティブ | Vue.js

autofocusを実現したいコンポーネントに対して、ディレクティブオプションを追加する

  directives: {
    focus: {
        mounted(el) {
          el.focus()
        }
    }
  },

autofocusを追加したいdom要素に対して、v-focusを付与する

<input v-focus type="text">

これで実現できた。

技術書を積んでおこう。

自分の本棚に買った技術書がどんどん増えている。全部読めているわけではない。だいたい読むペースの3倍くらいのスピードで増えているので、増える一方だ。 積んだだけで読んでない本、かつ、心のどこかに引っかかっていていつか読もうと思っている本がたくさんある。

これ以外にもたくさんの本が本棚に眠っている。

リストに上がっているのは結構難しくて読むのに時間がかかる本ばかりだ。 でも、積んでおいて意識のうちに置いておくと凄く良いと思っている。

何故かというと、買ってみて読んでみて理解できなかったとしても、本棚に眠らせておくといつの間にか理解できるようになっていることが多いからだ。 もちろん、ただ眠らせておくだけでウィスキーが熟成するみたいに勝手に読みやすくなるわけじゃない。熟成されるのは本じゃなくて自分自身だ。 あの本をいつか読めるようになろうと意識して関連分野を勉強しているうちに、そのうち知識が身についてきて、 「あ、そういえばあの読みたかった本、本棚にあるじゃないか」と思って本棚に手を伸ばした時、驚くほどスラスラ読めるようになっていることがあるのだ。

これは実体験としてある。

恥ずかしながらエンジニアになって半年くらいのころに結木浩先生の「デザインパターン入門」を買ってみて、読んでみて、全く理解できなかった。 コードは何を書いているかわからないし、説明も全くわからなかった。 この本が理解できるようになる気もしなかった。 でも、それから1年半くらいたって、オブジェクト指向設計実践ガイドを読んでみたり、クリーンアーキテクチャを読んでみたり、 RubyJavaのコードをたくさん書いてみたあと、ふと本棚に目をやった時、「デザインパターン入門」が目についた。 読んでみて驚いた。前は全然わからなかったのにスラスラ分かる。しかも内容が本当に面白くて、役に立つのがよく分かる。 どこかで見たパターンがいくつも書いてあって、あのコードはこのパターンを使っていたのか!というのがよく分かる。 いつの間にか、理解ができるレベルに達していたようだ。

こういう経験ができるととても楽しくて、自分の成長が実感できる。

だから、難しい本を積もう。今は読んでも理解できないOSSのレポジトリをブックマークしておこう。

いつか読めるようになるから。

オブジェクト指向設計実践ガイドを読んだので感想1

オブジェクト指向設計実践ガイドを読みました。 結構難しい本だった気がします。最初は翻訳が分かりづらいとか散々文句言ってましたが、単に知識がないだけだった気がします。反省。

ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 | 成瀬 允宣 | コンピュータ・IT | Kindleストア | Amazon

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) | Robert C.Martin, 角 征典, 高木 正弘 | 工学 | Kindleストア | Amazon

最初はよく分かっていなかったんですが、 このあたりの本を読んでオブジェクト指向設計がデータと振る舞いの持たせ方を定義し、それぞれのオブジェクトがどのようにメッセージをやり取りし合うことで依存関係を構築するかを設計する行為だと分かった上で読んだらスラスラ分かるようになりました。とは言っても上の二冊も簡単な本ではなく、知識の結びつきで簡単に読めるようになっただけだとは思います。

f:id:earthminami:20210729024447p:plain

オブジェクト指向設計では、このようにお互いがお互いを知っており、どのように呼び出すかを知っている状況を好ましくない状況とし、

f:id:earthminami:20210729024611p:plain

このように単方向に自分が呼び出すべき相手を知っていることを好ましい状況として定義して、 これをどうやって実現するかを考えていく必要があるわけです。

変更が起こりうる部分を特定し、図でいうとrootのオブジェクトはあまり変更が発生しないオブジェクトを配置し、 leafの部分の方に変更の発生しうるオブジェクトを配置することで、変更時の対応がしやすくなります。

小さいソフトウェアであれば依存関係がゴチャゴチャであっても気合でなんとかしたり、自分が知ってさえすればそれで何とかなるのですが、 ある程度規模のあるソフトウェアになると、オブジェクトを入れ替えたり修正したいときなどに、お互いがお互いに依存して密結合になり、変更不可能になる部分が出てきてしまうため、 修正が困難になってしまいます。また、後々関わったプログラマは設計当時の状況を知らないので、オブジェクトを好き勝手に使ってメチャクチャにしてしまう可能性があるため、設計により、使用方法に制限を加えなければいけません。

そのための方法論が書いてあります。(今度まとめる

  • is-a
  • has-a
  • behave like

に着目してそれぞれ継承、委譲、モジュールインクルードを使い分けることが重要です。

可能な限り委譲を使用し、継承はあまり使わないことが必要です。

今後調べる必要がある部分としては、 Rubyの場合は静的型ではなく、InterfaceやAbstract Classも存在していないので、JavaC#との違いを深堀りしたい。