JavaScriptのAsync/Awaitの仕様を数年前に見たときからなにか違和感を感じていたのだが、以下の記事で改めて全体を見通した時にその違和感の元に気づいた。
【初心者向け】JavaScriptの非同期処理を理解する callback、Promiseそしてasync/awaitへ - Qiita
Promiseの結果を取得するためにawaitが必要なことは直感的にわかる。 問題はasyncだ。これは単に返り値がPromiseであることを示すマーカーであり、返り値の型を明示する必要がないJavaScriptの思想とはそぐわない気がする。 これは例えばPythonのyieldとよく似ている。yieldは返り値の型をGeneratorにするが、その関数へasyncのような修飾子をつけることはない。
幸いにも疑問点に気づけば回答はネットに転がっていた。
どうやらawaitが予約後でなかったことと、parserの解析が簡単であることからasyncが用いられているようだ。 その理由に納得はしないものの、とりあえずの回答が得られたのはよかった。
以下の文章は私個人の意見であり、特定の企業や人物を揶揄する目的のものではありません。
僕はプログラミングが好きでずっとプログラミングをやっていたせいか、エンジニアで手を動かさない仕事の価値というものが長いことよくわからなかった。 8年ぐらいのエンジニア生活の中で、合理的で効果的な意思決定がなされたシーンを実感してこなかったこともその一因かもしれない1。
だからいわゆるアーキテクトや上流過程というものを結構長いこと軽視していたのだけど、以前こんなことがあった。 過去のある時点でAWS上にEC2で動くアプリケーションを作ったのだけど、実はそれに相当するサービスが開発開始当時からAWSに存在した。 そちらを使えば内製するより運用費が安く、4~6人月を投資する必要がなく、保守の手間も全くかからなかったことが発覚したのだ。
言い換えればこのアプリケーションを自分たちで作ると判断した人間は数千万をドブに捨てたわけだ(AWSについての知識がなかったがために)。 だから、(もちろん考え方にもよるが)このときAWSのサービスを知っておりそれを使うという判断が出来たら数千万円を使わずに済んだことになる。
これに気づいたとき、僕はこの意思決定には数千万円分の価値があったと言えるのだろうか？とふと思った。
こんなことがあってから、僕は意思決定についての価値をもう少し考えるようになった。 現在自分が行おうとしている意思決定がどれくらいのコストを生むか(一時的コスト・継続的コスト)、それが将来的にどれくらいの利益を生むか(短期的な利益・長期的な利益)。
そうして考えながら仕事中に意思決定をしていると、この意思決定というものが思っていた以上に危険なことがわかった。もちろん会社がどの分野・どの部署・どのプロダクトに投資するのかといったことは重要な意思決定なのは自明だが、僕のような平のエンジニアでさえ、何気ない判断で会社に長期に渡って数千万、数億の損失を生む意思決定ができてしまう。
ソフトウェアエンジニアの間違った意思決定の多くの場合現金ではなく、将来のエンジニアリングコスト(人・時間)であるため計測しづらい。結果的に多くの会社でそういった損失は計測を行わず振り返りも反省もなされない2。そのため大手IT企業などでも正しい判断基準を持たずランダムウォークするようなアーキテクト・マネージャが散見され、数億や数十億以上のコストを見えずに垂れ流したりあり得たはずのサービスの可能性を潰したりしている。
そう考えると、もし意思決定を適切・慎重に正しく行えるものがいてその人物が継続的に意思決定を行えば会社はたくさんの潜在的損失を回避できることになる。 僕は従来マネージャや管理職・アーキテクトといった立場の人間を軽視していたが、上のような人物がいればその利益は計り知れない。
それこそ業務時間の90%でコードを書いて残り10%で間違った意思決定をしてしまうプレイングマネージャーよりも、業務時間の98%寝ていても残りの2%の時間で正しい意思決定をしてくれる優秀なマネージャーははるかに会社へ貢献していることになる。
だから、僕は相変わらずコーディングが好きなことは変わらないけども、最近は自分の意思決定そのものや自分以外の意思決定する人物・役職のことを見直している。 果たしてその意思決定(者)が本当に正しく、長期的に見て正解だったと言えるかどうかを。
まずbrewの信頼性が高い。 イケてる開発ツールが多い。WIndows, Linuxでも提供しているツールも多いがSequel ProなどMacでしか提供されていない素晴らしいツールも多い。 なにより利用者が多い & LinuxやWindowsのようにディストリビューション/バージョン間の差異が少ないことから多くのノウハウがウェブ上にあり、周りに使っている人間が多いためヘルプも頼みやすい。 見た目もイケてるし、ミッションコントロールやワークスペース間の移動などUIも洗練されている1。
一つは自宅で使用しているubuntuとショートカットキーやUIが違うことによる操作への最適化限界がきになったからだ。 ubuntuとOSXではワークスペースの移動のキーなど多くのOS標準操作方法が違う。 そのためショートカットキーを覚えることが難しく、毎回設定を参照するようなことをしていた。 また、ubuntuではCtrlが使われるケースでMacはMetaキーを使うため、ブラウザ操作などショートカットを多用するシーンにおいて間違ったキーを押すことが多かった。 OSXのUIは明らかにubuntuより優れているため自宅のデスクトップをiMacないしMac Proにすることも考えたが、コストパフォーマンス面でPC/AT互換機と比べて格段に悪くまたMac Proが年単位で放置された過去を鑑みるとアップデートサイクルをこちらで制御しにくい点も欠点となり、自宅でOSXを使うことは断念した。
となると可能なら会社で使うPCをubuntuにしたいところだったのだが、ずっと諦めていた。 というのは以下の点で会社所属のエンジニアにMacBookを渡すことは合理的であるためだ。
が、先日MacBookによるコンパイルの重さ・HDDへのアクセスの遅さ・メモリの足りなさに辟易としているときに気がついた。
以上のような理由でむしろubuntu(linux)を使わない理由がないことに気がついた2。
現在ほぼubuntuへの移行が終わった状態だが、メモリやCPUなどが相対的に強化されたこともあり非常に快適に感じている。 特にDocker周りの動作が非常に軽く、レスポンスが早くなった。
当初は特にubuntu移行のデメリットはないかと思っていた(UIが劣るのは織り込み済み). が、最近徐々に手を出し始めていたxcodeによるiOSアプリ開発ができないことは少し頭が痛い。 手元のMBAは非力で開発にまったく使えないため、この点に関しては何らかの対策を打つ必要がある。
たぶんならない。僕がubuntuを使えるのは所属している会社がスタートアップで各々の裁量が大きいこと、特にソフトウェアエンジニア内でMacBookに揃えようという方針がないこと、ubuntuの経験がそこそこあり他人を頼らなくても自力で大抵の問題は解決できることなどが背景にある。
新卒や大企業のソフトウェアエンジニアの場合、いろんな要因でapple製品に統一したかったりするメリットがある。そもそもMacBookが強い会社は新卒もMacBookを使ってくれたほうが教えやすいし教えてもらいやすい。
ただ、今後長いことソフトウェア技術の核となるdockerがmac上では遅いというのは軽視できないデメリットで、Dockerを効率的に使う視点から長期的には開発PCでもlinuxの利用が増えていく可能性はあると思う3。
詳説implicitly（あるいはimplicitlyは黒魔術でないことの説明） [Scala] on @Qiita https://t.co/lgI9eojnvY
— Kota Mizushima (@kmizu) 2019年7月23日
この記事を読んでていくつか感じたことと思い出したことをツールドフランス第15日目観戦しながら書き出します。 特にまとまってない。
僕の勘違いでなければ、@kmizuさんは implicitly が静的に(コンパイル時に)一意に決定する、しかもそれがメタプログラミングやマクロ・リフレクションなどのコンパイル処理の外側ではなくコンパイル処理(= ファーストレベルの言語仕様1)として決まる点を指して黒魔術ではない、と行っていると思いました。
ただ、implicitlyを黒魔術的だと認識しているような人にはそこら辺の文脈・ニュアンスが伝わりづらい気がして非常に良い記事だけに少し惜しく感じました。
おそらく、 implicit parameterという概念（もしくは、その元ネタである型クラス）
implicit parameterって型クラスから派生した概念でしたっけ？と少し引っかかりました。
implicitは特に型クラスを意識せず実装されたけれど、後々型クラスにも使えることがわかったために型クラスの表現方法としてimplicit + context boundが利用されている、とどこかで読んだような (もしかしたら説明を単純にするためにあえてこう書いているのかも)。
@kmizuさんにその後詳しく教えていただいたのですが、広く一般には知られていないものの紛れもなくimplicit parameterは型クラスのための機能として作られたとのこと。
詳細はこちら。
感想ありがとうございます。この辺、ちょっとややこしいなと思うのは、implicit parameterは、もともと「紛れもなく」型クラスのための機能である（というのはOdersky先生のバックグラウンドとか、 https://t.co/z17QhhltBc を見ると明らかです）にも関わらず、Odersky先生ご本人は、研究文脈以外では
— Kota Mizushima (@kmizu) July 24, 2019
元の記事は簡潔にまとまったスクロール3画面分ほどの記事なんですが、僕はここで説明されていることを完全に理解できるようになったのは真剣にScalaを触り続けて3,4年経った後だったと思います。
この記事の中ではimplicitlyに到達するまでの道のりがだいたい以下のように提示されています2。
Haskellなどのバックグラウンドのない、Javaを触ったことのある程度の人間(だいたい10年前の僕)がもうちょっと補足するとこうなります。
| 題目 | 僕が理解した時期(Scala使い始めからの年数) | 理解にかかる労力 |
|---|---|---|
| implicitの使い方・作用 | 1~2年 | めっちゃ大変 |
| context boundの意味 | 3~4年 | 型クラスを理解していると一瞬。 理解していないと使い方・概念がさっぱりわからない |
| 型クラスの概念 | 4~6年 | 大変。数回の挫折をはさみつつ足掛け5年かけてすごいHaskellたのしく学ぼう！と独習 Scalaz — 独習 Scalazで理解した |
| implicitlyの使い方 | 1 ~ 2年 | それ自体は死ぬほど理解が単純。 型クラスとしての使い方に気づいたのは型クラスを理解した後だった |
上に書いていますが、僕が元の記事をだいたい理解できるようになったのは型クラスをぼんやり理解し始めた4年目以降でした。
こう書くとお前どんだけ頭悪いんだよと思われるかもしれませんが、実際のところ3つの職場で一緒にScalaを書いた同僚諸氏で確実に僕より早く・より深く上を理解していたのは10人中2,3人程度でした。 勉強への熱意や理解の早さはともかく、実際にScalaを使っている人でもかなりの人がimplicitやcontext boundなどをよくわからず使っている、またはそれらを知らなくても十分Scalaを使えていると思います。
改めて考えるとscalaのimplicitは本当にわかりにくいと思います。これはimplicitに多数の側面やシンプルでない仕様があるからだと思います。 以下implicitのわかりにくい点。
2) 探している implicit の型に少しでも関係のある様々なコンパニオンオブジェクトやパッケージオブジェクトから成る暗黙のスコープ (implicit scope) (具体的には、型のパッケージオブジェクト、型そのもののコンパニオンオブジェクト、もしあれば型の型コンストラクタのコンパニオン、もしあれば型の型パラメータのコンパニオン、型の親型や親トレイトのコンパニオンなど)。
何が言いたいか。
それらがすぐにわからないからと言って、自分が頭が悪いと思ったりScalaに絶望しなくていもいいと思います。これらの概念は広範に普及しているプログラミング言語の中でもかなり難しい概念ではないかと。
過去にimplicitもFutureもモナドも使わないScalaによるAPIサーバをScala初心者の人たちと一緒に書きましたが、Future・モナド・implicitを半端な理解で乱用したアプリケーションより10倍良いコードでした このように単なるbetter javaとしてscalaを使うことは全然ありだと思います4。
ここで話が最初の記事に戻ってきます。 元々の記事は非常によくまとまっていて内容は正しいのだけど、最低でもScala数年触っているような人じゃないとあれ読んですぐ理解するのは難しいんじゃないかと思いました。
implicitはScala 3でなくなるそうですが、型クラスの概念は多少変遷しうるもののおそらく今後20年, 30年以上プログラミング技術の中で使用される可能性が高いです。 すごいHaskellから逃げずに(!?)頑張って勉強しておきましょう。それにより得られるリターンは本当に大きいと思いますし、実際大きかったです(プログラミングの表現の幅が広がった)。
この前、久しぶりに非常にヘビーカロリーなコードを書いた。 僕は普段コーディングをしている日はScalaの場合テスト含めて100~300行程度のコードを書いているのだけど、機能まで書いていたコードは5~10日で100コード程度しか書いていなかった。 というのも内容がhttp clientの低レベルな実装とAWS V4 signatureの実装に関するコードで問題がかなり難しかったため。 この問題、そもそも自分で解決できるかどうかギリギリレベルの難易度だったのだが、なんとか解決することはできた。
ここでは後のためにその解決方法を言語化しておく。
今回の場合、根本的に何が問題なのか、何ができないのか、何をやればいいのかを調べだすのに丸2日分ぐらいの時間がかかった。 資料が少ないためでもあったが、まず問題の原因をはっきりさせることは基本であり絶対。 ここがあやふやなママ試行錯誤しても効率は上がらない。
取れうる手段を検討する。 今回の場合は既存のライブラリを頼ることが難しいことがある程度調べてわかった。 その結果、妥協して定期作業が必要な認証にするかそれともきちんと自分で実装するかの選択肢が出た。 最終的に後者を選んだ。
上長やチームへ説明するためにもトレードオフできる選択肢を出すことは大事。 それで自分がしようと思っていた以外の選択肢が選ばれたり新しい選択肢が出ることもままある。
まず絶対に動く例を作る。例えば今回のケースではpythonのサンプルコードが会った。 まずそれを動くようにして、徐々に動かないコードと近づけていって、どこで動かなくなるかを調べた。
取り急ぎまとめ。
以下取ったメモから順不同で書き出す
iot企業ハードウェアチームとの連携 絵をたくさん書く
先行しているプロダクト、リファクタリングが必要。 プロダクト要求を進められない。
手分けしやすい、スケールしやすい、 なんでわけるの？ PM以内の大丈夫？ 大規模チーム？ スケールスクラム 早めに手に入る。 要求分析 今は発注側がしんどい スクラムのメインフィールドはイノベーション イノベーションは外注できない
walking skeleton
scrum of scrum
遠隔地は最初からは難しい、一度一緒に飯を食べて、しばらく仕事をすると、リモートにしても成功しやすい。
outputではなくoutcome chaos report
機能数より成果 最初からチームで機能横断的である必要はない、レビューを繰り返すとフルスタックチームになる。
旧来のチーム、前職のようなチームではどうする？ スクラム部署を小さく作り始める。デンソーの例
スクラムマスターはいつかけしかける、自分の苦手なタスクをする。
挨拶、ボールゲームで推測の難しさ、 スクラムイベント、うまい弁当、アジャイル宣言
リスクに対するテクニック、ウォーキングスケルトン 細かく作る。 シンプルなケースを作る。 80%の人を救うケースを作る、それがウォーキングスケルトン。
そもそもの問題が見えてない、マネージャーがこない？部屋がコンフリクト？
プロダクトバックログ、あまり長過ぎると管理が大変。 せいぜい100個が上限 でもの重要性
リファインメントはスプリントの10% 2週間でクソみたいなものを出すのは大事。 工数感を共有できるから。
経験主義は科学分野から
POの最大の価値はプロダクトバックログ
リファクタリングをプロダクトバックログに入れろ、普段のタスクでリファクタリングしろ
機能は削除しろ。
デザイナーのためのCIを回して、積極的に参加してもらう。 チームに参加してもらう。 CIがキモ
セキュリティアーキテクチャ設計書に連絡先を書いてこちらです、にしておく
SIヤーではお客様はプロダクトオーナーではない。プロダクトオーナーは社内で建てる。 お客様はステークホルダーに過ぎない。
featureフラグでdoneにする。 デプロイは開発が任意。
プロダクトバックログには誰でも突っ込める。 優先順位を入れ替えられるのはPOだけ。
二日目
未完了は再見積もりしてバックログに戻す
デイリースクラムはマスターに報告しがちなので、マスターは隠れるなど メールが来る、登録する、日本語と英語がある、50問か30問かわからない、4択、制限時間は1時間、二回受けて2回とも落ちた人は居ない。72%で合格
ドラッカーもdone is better than doing
特に初心者のスクラムマスターは開発メンバーとも兼任するべきでない。 プロダクトバックログはvalidate 開発チームはバックログ通りに作っていることを保証するべき イテレーション、繰り返しではなく改善のサイクル、トヨタの片山さん曰く
優秀なスクラムマスターは待つ。気まずくても待つ。
スクラムマスターとしてチームに干渉し過ぎない。責任をチームに持たせるため、自ら解決させる。
でも、そうするとスクラムマスターはやることなくない？
プロダクトオーナーが休み、病気は代理を立てる。
ビーチに行っていい？
どこまでやるんだっけ、はプロダクトオーナーと相談
3,5,8,13をSMLXLに割り当てる
high priorityかつXLは潰す。
環境構築のような機能に直結しないタスクはどうなる？
スクラムはプロジェクトマネジメントの手法ではなくプロダクトマネジメントの手法
上手く立ち上がる3/2のチームがある程度パフォーマンスが出るまで3ヶ月ぐらい。 二、三ヶ月ごとに2,3名入れ替えるのは安定度が足りない。
product ownerはend targetを決める。
今、definition of doneは完了の定義ではなく完成の定義という訳語にして曖昧さをなくした。
完成の定義は、汎用的なもの。 acceptance criteria はPBIごとのもの。
サーバの用意やインスタンスの用意はスプリント外で事前に用意する。
Goalはstake holderからわかることが重要
リファインメントはミーティングを短くする
CXOの不安を解消するため、試してみる。
試作品でもwalking skeletonを作る。 ソフトウェアでハードウェアがきちんと動いていることをテストするようにすれば、すごく高速に設計できる。 あとシミュレータをガチガチに作る。 スプリントを回すため、
何がやりたいと聞く。 報酬制度は個々人でやるのは危険
5 whyはガビーもやるテクニック
これはと思ったら、病院へ
以下、数ヶ月もんもんと考えていてなかなかアウトプットすることができなかったので自分語り交えながらとりあえず出力することにした。 読みづらいのは勘弁願いたい。
数ヶ月ほど前、アドベントカレンダーに参加したときに以下の記事を書いた。
集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話 - kbigwheelのプログラミング・ソフトウェア技術系ブログ
そうしたところとても多くの人に反応を頂いて、自分としても一応の結論を出すことができた。
「集約の境界と整合性(略」に対して頂いたアイデアの分類と現状での僕の回答らしきもの - kbigwheelのプログラミング・ソフトウェア技術系ブログ
このとき多くの人の意見を読ませてもらい自分の結論に至って考えたのは、この結論は自分一人で考えていては絶対にたどり着けなかったということだ。
僕がどの解法を自分の結論としたかは上の記事を見てもらうとして、なぜ自分一人ではたどり着けなかったというとこの結論が正規化していないテーブル構造だからだ。
テーブル構造の正規化、およびそのパターンについては他の記事・サイトに説明を譲るとして*1、 使わないほうが良い説もそこそこ聞く外部キーと比べてDBの正規化がアンチパターンだと語る話はほとんど聞いたことがない。 テーブルの正規化はRuby系のDRYにも似た概念であり、無駄なデータの重複を作らないことは更新漏れを予防したりデータ保存効率を上げたりする点でも勧められるよい設計方針だ。 RDBMSでの正規化はOOP系のプログラミング言語とのインターフェイスでインピーダンスミスマッチを起こす要因として 挙げられることはあるものの、我々プログラマーはRubyのActiveRecordやORマッパーの機能、時には自分たちでDAO/DIOを書くことで そのミスマッチをプログラム側の努力で解消してきた。 それはそれだけDB領域の正規化を重要視してきたからである。
通常1対多のテーブル関係がある場合、多の方のカラムに1の方のIDを持たせるだけでよい。 データ保存効率がよく、また間違って多対多の関係になってしまうことも防げる。良いことづくめである。 たびたびで恐縮だが、上記リンクの回答編、最終的な結論ではDBを非正規化する解法を選択している。 なるほど、その選択肢は僕の頭には一切なかった。
端的に言えばトランザクション境界をスパッと切るためである。 上の例で言うと組織集約とユーザー集約は別の集約(=リポジトリ)でありトランザクション境界で別れている。 DB正規化の観点からすればどのユーザーがどの組織に属しているかはユーザー側のテーブルで管理するべきだが、 オブジェクト指向、というかDDDの集約(リポジトリ)の見地からすればそれは組織集約の方で管理するべきなのだ。 1対多の関係が多対多になるリスクを負うことになるが、それでもである。
私は今までごく少数の例外(forgeign keyや論理削除・物理削除)などの問題を除けばRDBMSの基本原則を信奉していたし、 インピーダンスミスマッチを認めつつもそれはプログラム側で努力して解消するもの、または工夫により解消できるものと信じてきた。
特に正規化については重複を避けるプログラミングの原則にもマッチしているし、RDBMSを使う根本理由であるとすら思っていた。
その考えが今揺らいでいる。
慣習的に従いたいのは正規化の方針だ。しかしDDDとIDDDを読み、多くの先達の意見を聞いた今理性は正規化を捨てるときだと言っている。 実際そういった思いでDDD・IDDDのリポジトリ・トランザクションの章を読むと正規化を捨てるという案は全編で肯定されている。 DDDに従うならば、必要に応じて正規化を捨てるという手段は当たり前のもののようである。
しかし、思うのだ。 我々は主にウェブプログラミングへマッチさせるために外部キーを捨て、論理削除の概念を生み出した。 この上正規化を捨てるとなるともはや使っているRDBMSの機能のほうが少なくなってくる。 集約でトランザクション境界を切るとなるとJOINすることも稀になるからだ。 もはやこの用途ではRDBMSよりスキーマ強制されるNoSQLを使うほうが用途にあっている気さえする (CQRSでJOINをフル活用する必要がある場合はRDBMSが生きると言えるが、あれは邪道な気がしてどうにもまともに捉える気になれない)。
DDD本にも何度か出てくるが過去オブジェクト指向DBというものが何度も考案されては実用化できずに消えていった。 しかし、このDDDに沿ったリポジトリ実装だとどうにもこのオブジェクト指向DBというものが最適な気がしてならない。
我々は、ドメイン領域と外界とのインピーダンスミスマッチを最小にするため、ソフトウェアエンジニアリング史何度目かのオブジェクト指向データベースへの挑戦をするべきなのではないだろうか。
今回の経験で、結果整合性を使うために集約間でトランザクション境界を切る場合は、それぞれのテーブルを別のスキーマ(MySQLなんかだと複数スキーマ間でJOINなどできてしまうが一旦それはなしと考えて)に置くとしてテーブルを設計すればいいことに気がついた。
*1:実際のところ他人に説明できるほど理解していないのである