Alt MacBook Pro充電環境を揃える

cheero USB-C PD Charger 60W (White + Silver)

cheero USB-C PD Charger 60W (White + Silver)

CheeroのUSB-C PD充電アダプターが新しく出て、若干安くなってるのに気がついた。

たまーに会社のMacBook Proを持ち帰って仕事したりすることもあるけど、アダプタ類を持ち歩くのもめんどくさいなーと思ったりするので、この機会にサクッとUSB-CケーブルとUSB-Cハブも買っておくことにした。

届いたので動作チェックしてみたが、今のところ問題なし。持ち歩くこと考えると、こっちの方が楽かもしれない。

Domain modelling made functional Chapter 4, Chapter 5 を読む

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

ちょっと開いたけど、読んでいる。Chapter 4がF#での型システムの話、そしてChapter 5がそれを踏まえてOrderTakingSystemを型で表していくという流れ。

DDDでモデリングしていった結果、Value ObjectやEntity、Aggregateを発見していくけど、それらを型として定義してWorkflowをそれらの型の変換という形に落とし込んでいく。型として表す、それ自体はDDDにおいて大事な話だと思うが、Workflowを型として表していくのは実はしっくりくるのではないかと思った。実際にValue ObjectやEntityに属しないけど必要なビジネスロジックなどは存在するので、それらはServiceとして表したりするのだけど、データとしての型とそれらを変換する関数として定義するとそういう違いもなくなるなと。個人的にはChapter3あたりと違って、腑に落ちる内容が多かったかな。

読書会内ではOR typeをScalaで表現するとなると、case classが頻出してちょっと記述がめんどいなどの話や、AggregateであるOrderに含まれるEntityのIDのみを持つのかそのEntity自体を持つのか、その判断はどうやって決めるのかなどが上がっていた。Aggregateに他のEntityそのものを持たせるかは、基本的に疎結合強凝縮を意識してモデリングしていけばいいのかなと考えていて、今回の例だとそのドメイン上で扱うにはOrderからOrderLineのリストが辿れるようにしておく、CustomerはIDのみ持つは一つの解かな。詳細でRDBに保存するにしても、ドメイン上ではそれが置いておくのが吉となりそう。もちろん実装上OrderLineが膨大に持つことになってメモリを圧迫するとかなってしまうと、IDのリストを持つとか考えれば良さそうだが。

「【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践」を読んだ

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

最近他チームの手伝いでテスト作ったりしてるんだけど、今一度テストってどうやるんだけっけ?と思い購入。月一で書籍購入を会社でやってくれるのは本当にありがたい。

同値テスト、境界値、組み合わせテストなど、個々のテストについて作成の仕方を解説したり、もっと大枠の話としてテスト計画やテストの設計をどうしていくかなどが網羅的に書かれているなと感じた。内容的には知っていることも多く、忘れていたことをちゃんと呼び覚ましてくれたというところが大きいが、初めてテストに携わる人なんかはこれを読んで勉強するのも良いかと思う。特に組み合わせテストでのテスト項目の削減方法はきっちり知っておくといい。全ての組み合わせでテストするのは到底現実的でないので、いい落とし所を作るためにどうするか学べる。またこういうところはTDDやるときに、仕様からどういう値がありうるかなとか考えるときに役立つかな。

ただ記載のある内容は基本的に真面目にウォーターフォール開発でのテストを念頭に置いてるものなので、テスト計画のところはまあそういうこともあるよねぐらいの感覚で読んでおいたほうがいいかもしれない。現実的には無理くりやらないといけないこともあったりするのだ……うっ頭が……とはいえ、前々職で作っていたテストドキュメントなどはこういうのを元にして作ってるんだなという気づきがあった。以前読んだメルカリでのテスト管理ツールの選定に出てきたツールたちもこの辺りを念頭においたりしてるのだろうか。

tech.mercari.com

あと、アジャイル的にやっているところとかだと、本に書いてあるように設計書が細かく分かれているとかない場合もあるから、そういうときにどうなるかなーというのは気になる。もちろんソフトウェアが満たさなければならない要求があるのだから、それをチェックするためのテストがあればいいのだけど必ずしも本書通りの形にはならなそう。継続したテスト、テストの自動化、などなど最近話題のところもあるけど、本書では範囲に入っていない。以下のリンクのように探索的テストが必要な場合もあるだろう。

codezine.jp

ただテストする上での知識として何が必要かは、必要十分に詰まっていたと思う。割とさっくり読めるのでテストの手始めに読むのが良いと思った。

ネタバレになりそうな気もするゴジラ キングオブモンスターズ感想

godzilla-movie.jp

うまいこと時間が調整できたので、初日にさっさと見てきた。予告やちらほら流れてくるvsシリーズっぽいというお話に少し胸を踊らせて、19時からの回に。

結論からいうと、これは売れそうだなぁと思った。ハリウッドが作った大娯楽映画。派手なシーンも多く、あのキングギドララドンモスラがこれでもかと動きまくって見せ場も多い。音楽も伊福部昭のあのテーマを盛り込みつつ、面白い仕上がり。監督自身がおそらくほとんどのゴジラ映画は見てるんだろうなぁと思えるオマージュの数々、特撮好きがこぞってどれが元ネタか探そうとするだろう。話のネタとしては申し分ない。これを見るにあたって予習はいらないと思うが、もし数々のオマージュが何かを知っておきたいのであれば、この辺を最低限押さえておくといいんじゃないだろうか。

ゴジラ

ゴジラ

ゴジラVSデストロイア

ゴジラVSデストロイア

ゴジラVSメカゴジラ

ゴジラVSメカゴジラ

怪獣大戦争

怪獣大戦争

怪獣総進撃

怪獣総進撃

空の大怪獣 ラドン

空の大怪獣 ラドン

モスラ(1961)

モスラ(1961)

ストーリーもまあこういう荒唐無稽さというのは頭を空っぽにしてみる映画としては気にしなくてもいい、と振り切った感じになってるので気にしない人は気にしなさそう。マッドサイエンティストっぽい人たちはそれこそ初代の芹沢博士とか、メカゴジラの逆襲の真船博士とかもいたわけだし、復讐に燃える人と言えばvsスペースゴジラの結城さん*1とかもいたりあまり気にならず。

オルカの扱いなんかは怪獣総進撃の怪獣ランドとか怪獣大戦争のあれとかに近いのかなーとか。それこそ各地に怪獣が出現して暴れ出すというところなんかは、まんま怪獣総進撃でキラアク星人に操られた怪獣が世界各地に現れて破壊を尽くすというところに他ならず。そういや声に反応するネタだと84年のゴジラもそんなんだったなーとか。流石にモナーク環境テロリストそれぞれのザルさはなんなんだろうと思ったりしましたが、モナークがヘリで基地に着陸するところとか、完全にvsメカゴジラだしそういうメカ描写も面白いところはあった。もっとやるなら東宝特撮らしくメーサーとかああいうの出してくれてもいいのよ。

関西に住まうvsシリーズドンピシャ世代としてはエンディングのGodzillaのカバーに嬉しくもあったりした。


読売TV「ゴジラ復活作戦第2号」タイトル


読売TV「ゴジラ復活作戦」タイトル

vsシリーズっぽいというは確かにそうかと思える。2014年のギャレゴジやシン・ゴジラとは違う手触りでエンタメとしてのゴジラ映画であり、昭和のシリーズやvsシリーズに近い。いわゆる怪獣プロレスを求めている層だとドンピシャなんじゃないだろうか。


とかつらつら書いてきたけど、個人的には、最後まで映画にのれなかった。自分自身vsシリーズドンピシャで、昭和シリーズも全部見てきた。要素要素で見ると好きなものもたくさんあり、そういう細かいところをつつく楽しみ方もできてたし、南極でのギドラ登場〜ゴジラとのバトルシーンやラドンソニックブームなんかもすごかった。

そう映像はすごいものがあった。

すごかったけど、なんか自分にはグッと来なかった。

何がしっくりきてないんだろう? 見終わってから考えてみたのだが、映画として没入しずらい構成に感じた。序盤の方はそうでもなかったのだが、南極のバトルあたりから全体的な流れを感じずとりあえず見せたいシーンを繋げまくったという印象が残っている。また人が足元にいる中、怪獣たちのバトルが繰り広げられる箇所がやたらと多かった。おそらく物事がシームレスに繋がってるということなんだろうけど、怪獣の取っ組み合いをちゃんと見たいのに度々視点が人の方にいってしまうので、途中で意識が途切れてしまった。あとやたらカメラが近いので、もうちょっと空間を持たせて作ってほしかった。

役者さんたちもいいキャラしてるなーというのが多くていいんだけど、結構な脱落者が出てしまって色々もったいないなーと思ってしまう。そこらへん文化の違いなのかもしれないけど、芹沢博士の重みが薄らいでしまってなんだかなーという気持ちです。

結局のところ、映画としての緩急を感じられなかったのが、自分がのれなかったところなのかなと思う。良くも悪くもずっと高カロリーの油物が立て続けにくる映画。そこに自分はさっぱりとしたサラダ類などがほしかった。そんな気持ちです。


ただ来年にはコングとのマッチが控えていて、果たしてどうなるのかという期待は今から持っている。実際に今回のゴジラはかなり評判いいみたいだし、今後も作られていくことになるかもしれない。そうやって火を絶やさないようにはしてほしいと思う。多分見にいっている。

二週間ぶりにまた風邪ひきそう

昨日人混み行ったのがあかんかったか……悲しみ。念を飛ばしておく。

【第3類医薬品】南天のど飴U 54錠

【第3類医薬品】南天のど飴U 54錠

THE IDOLM@STER MILLION THE@TER GENERATION 04 (特典なし)

THE IDOLM@STER MILLION THE@TER GENERATION 04 (特典なし)

エンジニアのためのデザイン思考入門 を読んだ

エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門

会社の行き帰りにちまちま読んでいて、またまただいぶ時間がかかった。

デザイン思考ってなんぞやというところから、適当に買ってみたのだが結構面白い話が読めてよかった。東工大でのデザイン思考を実地で学ぶための授業、東工大生のみならず別大学の学生や企業もごちゃ混ぜのワークショップ。そこでの環境づくりや運営方法、ワークショップを進めていくための方法、実際に授業を受けた人のコラムなど、WhyからHow to、感想まで書かれてる。

ユーザーインタビューを通じて共感し、ユーザー自身が気がついてないニーズを見つけていく。繰り返しのプロトタイプ作りでフィードバックをもらい、煮詰めていくというところは割とソフトウェア開発でも聞く話であるので、そうよねとすんなり納得できた。環境づくりにしても、すぐに試せるような場所にしたり雑談できたりと大事にされていることである。

何より多様性やデザイン思考が根底となる文化が大事、共通言語を持つこと、チームメンバーへの信頼感があるようにしていかなければならない点などは、アジャイルやDevOpsなどでも共通する話であるなと思いながら読んでいた。*1実際に文中にアジャイルやソフトウェア開発でのプロセスに言及されているので、そういったものも参照されてるのだろう。

raydive.hatenablog.jp

raydive.hatenablog.jp

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DDDなんかでもユビキタス言語をドメインエキスパートとの共通言語としたり、Event Stormingで多数の視点からイベント・コマンドを洗い出すなどの話もあったりする。

raydive.hatenablog.jp

raydive.hatenablog.jp

こういうのはやはり問題解決のためになにをすべきかを考えていくと、自然と似通っていくのかな。

閑話休題

一方でデザイン思考のみだと、気づいてないニーズとはいえ、根っこの部分は他者に依存しているので全く新しい発想にまでたどり着くのが難しいのかなと感じた。*2コラムにてデザイン思考と合わせてクリティカルデザインという思考についても触れられており、新しい発想に繋がるように思える。

まあそんな感じで、話題の共通点を色々見つけることができて面白かったです。

エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門

*1:Effective Devopsまだ全部読みきれてない

*2:誰も思いつかない発想を自分が発想するという前提自体が間違ってるのかもしれないが