銀の弾丸

プログラミングに関して、いろいろ書き残していければと思っております。

全部約束 Promise.all - 非同期処理を効率よく並列実行するために

f:id:takamints:20200830201734j:plain photo credit: EpicTop10.com Promise via photopin (license)

互いに独立した複数の非同期処理は、 Promise.all で待ちましょうね!ってことを書いています。

例えば、複数のREST APIの結果を得たい場合、以下のように書きがちです。 一見問題なく見えますが、処理速度的にちょっと無駄なんですね。

実際ワタシも細かいことを気にせずにザクザクとコードを書いている時はこのように書いていて、あとから見直すことが多々あります。

async function sample() {
    const response1 = await fetch("http://path.to/rest/api1");
    const response2 = await fetch("http://path.to/rest/api2");
}

上のコードでは、 最初のAPIの結果を得てから次のリクエストを行います。つまり順次実行されるのですが、これってちょっと無駄なんです。

APIの数が多くなればなるほど処理速度はどんどん伸びます。しかし、そのほとんどが結果を待っているだけの時間なので無駄なんです。 (他の非同期処理が行われるため一概に無駄とは言い切れませんが)

無駄なく実行するコード

複数の独立した非同期処理を素早く実行するには、以下のように書きます。

async function sample() {
    const [response1, response2] = await Promise.all([
        fetch("http://path.to/rest/api1"),
        fetch("http://path.to/rest/api2"),
    ]);
}

仮にAPIの数が10個になると、最初の例では約10倍の時間がかかります。でも Promise.all を使った場合は、それほど時間は伸びません。 理論的には、ひとつのAPIの結果を得るまでの時間と同程度のはず(実際にはRESTサーバー側の処理能力に依存しますが)。

Promise.all について

Promise.all は、複数のPromiseオブジェクトがすべて完了するのを待ちます。 引数はPromiseオブジェクトの配列で、ひとつのPromiseオブジェクトを返します。 Promise.all が返すPromiseオブジェクトは、引数で与えられたすべてのPromiseが解決した場合に解決し、 その結果は、引数で与えたPromise配列と同じ数の配列であり、各要素が解決した値となります。 (ここではすべてのPromiseの解決が成功する前提で書いています)

上のコードの例では、個々のAPI呼び出しが返すPromiseオブジェクトを、個別に awaitせず、配列に格納して Promise.all に与えています。 これによって、すべてのAPIリクエストを一気に行って、結果が出るまで待つことになります。

複数非同期処理の並列実行で気をつけること

ここまでに書いたコードは、以下のように Array.map を使って置き換え可能です。 これが直感的であるかどうかは Promiseやasync/awaitに慣れているかどうかに依存すると思いますが、ここでワタシがよくやる間違いをひとつ書いておきます。

async function sample() {
    const apis = [
        "http://path.to/rest/api1",
        "http://path.to/rest/api2",
    ];
    const responses = await Promise.all(apis.map(api => fetch(api));
}

例えば、当初は非同期処理でなかったので Array.forEach で書いていたのだが、途中で非同期処理に変更されたような時に、Array.forEachArray.map に置き換えることを忘れていたり、 Promise.allawait するのを忘れていたり。これが実行時にエラーにならないんですよねえ。

できれば Array.forEach に AsyncFunction を与えた場合や、 Array.map の戻り値に対してなにも行っていない場合は警告を出してほしい。

AsciiDocのテーブルを入れ子にするにはビックリマーク

f:id:takamints:20200714090741j:plain
photo credit: Trey Ratcliff Boston Library via photopin (license)


AsciiDocのテーブル(表)のセル内に、これまたAsciiDocのテーブルを記述する方法です。

ごくたま~に、これをやりたくなるのですが、いつも書き方を忘れておりまして、 検索しても、なぜか上位のサイトで書き方が説明されていません。

「どこかの英文サイトの深~いところで確か見つけた記憶があるんだけどなあ~」と時間をかけて、やっと見つけて「あぁこれこれよ」という毎度の始末。

ということで、AsciiDocでネストしたテーブルを書く方法を、未来の自分のために書いておきます。時間がもったいないですからね。書いて覚えるスタイルで。


B07JHZMH9C
技術者のためのテクニカルライティング入門講座
髙橋 慈子(著)

新品 ¥2,178 5つ星のうち4.2 27個の評価
Amazon.co.jpで詳細を見る


目次

以降、このページ内の AsciiDocの変換は、npm miceroux を使っています。 使い方などは以下のページで説明しています。 takamints.hatenablog.jp


素のテーブル内にAsciiDocは書けません

そもそも AsciiDocの素のテーブル内に、AsciiDocを書いても、AsciiDocとして解釈されません。
以下のように、書いた内容がそのまま表示されてしまいます。

[cols="2,2,5"]
|===
|Firefox
|ブラウザ
|FirefoxはオープンソースのWEBブラウザです。

下記のような特徴があります。:

* 標準仕様準拠
* 高パフォーマンス
* 高い可搬性

http://getfirefox.com[Firefoxをダウンロードする]!
|===

ちょっとわかりにくいですが、箇条書きが箇条書きになっていませんね。
リンクが正しく解釈されているのはよくわかりません。

テーブル内にAsciiDocを記述する

セルの中のAsciiDocが正しく表示されるようにするには、セルの属性に a を設定する必要があります。おそらく asciidoc の意味ですよね。よく知りませんが。

AsciiDocのテーブルは(当たり前ですが)AsciiDocの文書ですから、この設定をしておかないとテーブルは書けません。

このことは Asciidoctor 文法クイックリファレンス(日本語訳) にしっかり書かれておりまして、文書も丸パクリしています。ちなみにワタシのメインブラウザはChromeです。

以下の例では、AsciiDocを記述する列全体に a 属性を設定しています。

[cols="2,2,5a"]
|===
|Firefox
|ブラウザ
|FirefoxはオープンソースのWEBブラウザです。

下記のような特徴があります。:

* 標準仕様準拠
* 高パフォーマンス
* 高い可搬性

http://getfirefox.com[Firefoxをダウンロードする]!
|===

以下のように、列単位ではなくセル単体に a 属性を設定することも可能です。

a|FirefoxはオープンソースのWEBブラウザです。

セルの中では「| (パイプ or 縦棒)」は使えない

AsciiDocのテーブルは | (パイプ or 縦棒) を使用して記述します。 テーブル自体が |=== の行で始まって |=== の行で終わります。 また、その中のセルの区切りにも | を使用します。

しかしセルの中にネストしたテーブルを書くために、これらの記号は使えません。 |=== が出てきたところで、外側のテーブルが終了してしまって意図通りの表示にはなりません。

ネストされたテーブルでは「!」を使う

じゃあ、どうするか?

ネストしたテーブルでは、| の代わりに ! (エクスクラメーション or ビックリマーク)を使います」ってことでした。

[cols="2,2,5a"]
|===
|Firefox
|ブラウザ
|FirefoxはオープンソースのWEBブラウザです。

下記のような特徴があります。:

* 標準仕様準拠
* 高パフォーマンス
* 高い可搬性

http://getfirefox.com[Firefoxをダウンロードする]!

[cols="2,2,5a"]
!===
!Firefox
!ブラウザ
!FirefoxはオープンソースのWEBブラウザです。
下記のような特徴があります。:

* 標準仕様準拠
* 高パフォーマンス
* 高い可搬性

http://getfirefox.com[Firefoxをダウンロードする]
!===

|===

それなら3段重ねはどうするの?

「じゃあ、3段階のネストはどうする?」って言うと、、、ワタシそれは知りません(あいすみません)。 できるのかどうかもわからないです。

ま、「そんなテーブルは見にくいだろうし、書かないでしょ?」ってことかもしれませんね。

AsciiDocで文書内の任意の場所にリンクする

f:id:takamints:20200627135648j:plain
photo credit: verchmarco Open book with a cone symbolising the snug time of the year staying inside and reading via photopin (license)

正式な文書はAsciidocで書いてPDFを出力することが多くなっています。 しかし、いつでもAsciidocを書いているわけでもありません。コードも書かなきゃならんし、メモ書き程度ならマークダウンで充分だし。

「さあ今日はガッツリ設計書を書きますよ~」って時に、あれ?リンクを貼るのってどうするんだっけ?といったことがよくあります。というか毎回そうなっている。ぼんやりとは覚えているけれど、正しくレンダリングされないとか。

こんな時は、すぐに検索するのですが、Asciidocの書き方を説明してくれてるページって、「見出しはこうする。テーブルはこう書けば良い・・・」みたいな感じが多くて、いろんな記法の説明がたくさん詰まっているもんで、いま知りたいことが、すぐわからない。

しかし文句ばっかり言ってちゃダメです。無いなら自分で書いときましょう。一旦書いたら割と覚えておけたりするもんで・・・。

てなことで、ここでは「文書内の任意の場所に飛べるリンクの書き方」を書いています。 外部の文書や、見出しへの自動リンクについてはまた別の機会に。

目次

概要

AsciiDocで、文書内の任意の場所にリンクを貼るには、 リンク先に「アンカーID」を設定し、 リンク元では「アンカーID」と「リンクテキスト」を指定します。

リンク先に アンカーID を設定する

リンク先に アンカーID を設定するには、その直前の行の行頭から、 [[アンカーID]] と記述します。

[[anchor-id]]
この段落がリンク先です。この直前に anchor-id が設定されています。

文書内へのリンクを記述

AsciiDocで、文書内の任意の場所にリンクを貼るには、 「<<アンカーID,リンクテキスト>>」 と記述します 。

リンクを貼るには、<<anchor-id,このように>> 記述します。

アンカーID は、 リンク先に設定しておく識別子です(「アンカー(anchor)」はイカリの意味)。 日本語でも構わないようですが、 私はなるべく英数字+ハイフンなどを使っています。 検索する時に便利なので。

文書内リンクの例

リンクを貼るには、<<anchor-id,このように>> 記述します。


[[anchor-id]]
リンク先の文章です。

アンカーID は、文書内で複数同じものが設定されていてはいけません。 複数あると、どこにリンクすればよいかわかりませんから。

JavaScriptのArray.fillで気をつける事

f:id:takamints:20200512125305j:plain
photo credit: diana_robinson The Milky Way over a radio telescope at the Karl G. Jansky Very Large Array National Radio Astronomy Observatory in New Mexico via photopin (license)

JavaScriptで、あらかじめ一定の長さの配列に初期値を放り込んでおくために Array.fill を使いますが、勝手な思い込みからハマってしまいました。恥ずかしながら、その詳細をご報告。

目次

Array.fill はどんな関数?

Array.fill は、配列の全要素に同じ値を設定する関数です。 以下の例では、3個の数値配列を生成して値 0 で初期化しています。

const arr = Array(3).fill(0);

余談ですが、fillで初期化しておかないと、要素はすべて undefined になっており、そのままでは forEach などの列挙メソッドが回りません。

Objectで初期化したらおかしな挙動

以下のように初期値にObjectを与えていたのですが、思った通りの動きをしてくれませんでした。

const arr = Array(3).fill( { x: 0, y: 0 } );

3個の二次元座標値を持つ配列。。。のつもりですが、以下のようなことになりました。

const arr = Array(3).fill( { x: 0, y: 0 } );
arr[0].x = 10;
arr[0].y = 8;
console.log(JSON.stringify(arr));
//出力:[{"x":10,"y":8},{"x":10,"y":8},{"x":10,"y":8}]

0番目の情報を書き換えただけで、他のすべてのデータが書き換わってしまいました。 配列要素は確かに3つあるのですが、全ての要素が、ひとつの座標値を参照しているのです。

なぜこうなるか

JavaScriptのObjectはメソッドの引数や代入時には、必ず参照が渡されますから、このようなことが起こります。 ソースコードをよく見れば、fill に与えられている座標値は、1度しか生成されていません。 だから直感的でないにせよ、これは当たり前の挙動です。 つまり、ワタシが勝手に「別の複数のオブジェクトが生成される」と思い込んでいただけなのでした。

解決方法

唯一の正しい答えなんてありませんから、3つほどの解決方法を示してみます。 プリミティブな型なら最初の方法が良いと思いますが、プロパティを持つオブジェクトならば2番めの方法が好みです。 関数プログラミング的には最初の方法が正解だと思われますが。

(1) まるごと代入すれば良い

上の例の2行目と3行目を以下のように変えれば、別のオブジェクトを生成して代入していることになるので、なんら問題ありません。

const arr = Array(3).fill( { x: 0, y: 0 } );
arr[0] = { x: 10, y: 8 };
console.log(JSON.stringify(arr));
//出力:[{"x":10,"y":8},{"x":0,"y":0},{"x":0,"y":0}]

ただ、これがベストだとは思いません。 なんて言いましょうか、初期化のコードとまるごと代入部分で、統一感がないというか、思想に差があるというか、そんな妙なミスマッチ感がありますね。 最初は全要素がx,yともに0の単一オブジェクトを参照していますが、その後、値としては同じ(x,yとも0である)データを代入したなら、別のインスタンスを参照することになる。

あと、誰かがうっかり別のところで要素の「プロパティを書き換えちゃった」というような不測の(しかし予測可能な)事態に対して脆弱です。構文的な防御策がありませんからね。

加えて、多くのプロパティを持つオブジェクトである場合、インスタンスの生成コストも気になります。本来、気にするべきではないのですが。

(2) 別オブジェクトで初期化する

初期化時点で別のオブジェクトを設定しておくには、以下のように書けばよろしいかと思います。

const arr = Array(3).fill().map(e=>({ x: 0, y: 0 }));

fill()fill(null) と同じです。全要素をnullで初期化しています(初期値は nullでなくても undefined 以外ならOKです)。 これをしておかないと全ての要素が undefined になっていて、うしろの map が回ってくれないのです。 こうしておけば、以下のように間違いは発生しません。

const arr = Array(3).fill().map(e=>({ x: 0, y: 0 }));
arr[0].x = 10;
arr[0].y = 8;
console.log(JSON.stringify(arr));
//出力:[{"x":10,"y":8},{"x":0,"y":0},{"x":0,"y":0}]

(3) ループを回して初期化する

また、以下のようにループを回して初期化する方法もありますが、前時代的ではありますね。

const arr = Array(3);
for(let i = 0; i < arr.length; i++) {
  arr[i] = { x: 0, y: 0 };
}

Git初心者が最初に知るべきチームでGitの使い方

f:id:takamints:20200415072108p:plain



皆さんはGitを問題なく使えているでしょうか?

時おり社内で「リポジトリが何だかおかしくなってるんです~」と相談を受けることがあります。 コミットログが思ってたのと違う状態になっていて、さらに元に戻そうとアレコレやって状況悪化。 最終的に、どうにもならなくなっちゃったって感じです。

たいていは単純にGitの操作ミスによるものです。でもGitについて正確に理解していれば、ちょっとした間違いはすぐに元に戻せるはず。 裏返せば、Gitの仕組みや概念を正確に理解できておらず、「なんとなく」Gitを使っている人が多いのでしょう。 Gitのコミットやブランチについて明確なイメージを頭の中に描けていないように思います。

ところがこの春、新型コロナの影響で、弊社も「基本的にはテレワーク」と指示が出まして不安が的中。既にちらほら問題が発生してます。

ということで「Gitが不安、難しい」と思っている人たちのために、最初にキチンと理解しておいて欲しいことや、基本的な使い方を書いておきます。 ちなみに、Gitを難なく使っている人にとっては当たり前のことしか書いていません。


目次


masterブランチで作業しないで

いちいち「この作業はブランチを切って行えばよいですか?」って聞いてくる人がいますが、これ当たり前なんですよね。 なにか作業するにはワーキングブランチを作成して、そのブランチで行ってください。

ワーキングブランチのベースをどこにするかは、採用しているフローに依存します。 弊社では GitHub Flow でやりましょうとなっているのでベースは必ず master です。 この点についてはチーム内で取り決めがあるはずですし、なければ取り決めておくべきですね。

GitHub Flowでは、作業内容を具体的に表す名前をワーキングブランチに付けるべきだとなっています。 そして早い段階で(コードを変更していなくても)リモートにpushしておきます。 これによって、チーム内に「自分が何をしようとしているかを知らせる」ためです。

いろんな変更を詰め込まないで

たくさんのコードを変更して、一発巨大なコミットをぶちかますのはやめてください。 また、ひとつのワーキングブランチで、色んな種類のコミットを積み重ねるのもやめてほしい。ワーキングブランチの変更内容は首尾一貫している必要があります。

その時の作業に無関係な部分で「あら、ここのインデントおかしいやん」とたまたま発見しても、そのまま流れで修正しないでほしいのです。 これをやると、後のmergeやrebaseでCONFLICTが発生しやすくなって、割ととんでもない手間がかかります。 本筋から外れた問題を見つけたときは、忘れないようにIssueを書いて、本来の作業に戻りましょう。

これらを正しく行うには、キチンと作業の計画を立て、短期のゴールを見定めて、それに集中する必要がありますよ。

masterブランチをpushしないで

複数人のチームで開発しているとき、masterブランチを前に進めるのはプルリクだけに限定したい。 緊急のBugFixなどでは、この限りではありませんが、少しでも時間的に余裕があるならプルリク投げてマージしたい。

主な理由はレビューできないからですが、チーム内に「masterが前に進む」ということを周知できるのも理由のひとつ。

同じ場所で作業している場合に、声を掛け合ってワーキングブランチをローカルでmasterにマージして、pushするケースは確かにあります。プロジェクトの初期段階では特に。 でも、リモートワークでメンバーがバラバラな状況で、さらにGitの操作に慣れていない人がいる場合などでは、正統にプルリクを投げてレビューしてからマージするのが筋というものです。

複数のコミットが連なったブランチを直接(プルリクを投げないで)レビューする時、レビュアーはレビュー対象のブランチを手元にチェックアウトしてHEADとベースブランチの差分を確認する必要があります。 GitHubなどのサービスでは複数コミットの差分をまとめて確認しにくいので。

他人のワーキングブランチにコミットしない

他の人のワーキングブランチをチェックアウトするのは構いません。コードを確認したりするだけですから。 でも、そのブランチに変更を加えてコミットした上で、push しないで欲しいのですよ。

これって論外だと思うのですが、おそらくワーキングブランチとは何であるかを理解できていないのでしょうね。

ワーキングブランチは、それを作った人の責任においてコーディング作業が進んでいるものであって、途中から無言で他の人が別の変更を加えちゃうと、その時点で枝分かれしてしまいますよね。 ブランチのオーナーは最終的に複数のコミットをまとめようとしているかもしれませんし。 とにかくワーキングブランチは途中段階の中途半端な状態なので、本人から移譲されたのでない限り、勝手に変更を加えるようなものではありません。

他の人のワーキングブランチが自分にとって必要であるならば、きりの良いところでプルリクを投げてもらってmasterへマージしてもらうように依頼するべきです。 そして、そのプルリクがマージされたあとに、自分のワーキングブランチへマージするべきです。いずれにせよ無言でしれっとやるのはご法度です。

ワーキングブランチを早い段階でリモートにpushしておくのは「私はこういう作業をしていますよ」ということをチーム内に表明するためです。

今まで未遂も含めて何度か経験しています。 一度はそのブランチがmasterにマージされていて驚きました。 怖いよ初心者w。まあその後問題が出なかったので良かったけれど。

rebaseしないでmergeして

ワーキングブランチで作業中に、リモートのmasterが前に進んでいることがあります。 このとき自分の作業が終わってプルリク投げる時などに、新しいmasterにrebaseする(ワーキングブランチのベースブランチを新しいmasterに切り替える)のはやめて欲しいのです。

じゃあどうするか。その時点でコンフリクトが発生する可能性があったり、新しいmasterに加えられた変更が自分の作業に必要であったりするなら、新しいmasterをワーキングブランチへmergeすれば良いのです。 逆に、明らかにコンフリクトが発生しない場合や、自分の作業に無関係な変更であるなら、何もしなくても構いません。

コンフリクトが発生するかどうかの判断は、少し難しいかもしれません。 なので同じファイルを変更しているかどうかで判断すれば良いと思います。 同じファイルを変更しているなら良いタイミングで新しいmasterをワーキングブランチにmergeする。 そうでないなら何もしなくてOKです。

rebaseをやめて欲しい理由のひとつは「際限がない」からです。 複数人で開発している場合、作業中にどんどんリモートのmasterは進んでいくと思います。 その時に、いちいちrebaseするのは手間ですし、コンフリクトが発生しそうなときだけrebaseするという対応も、状況によってベースブランチが変わるなんて、おかしな話です。

ちなみにmasterとの間でコンフリクトが発生したら、その解消時に尊重されるべきなのはmasterブランチのコードです。 masterブランチに取り込まれた時点で、それは「みんなが認めた正統なコード」ですからね。

プルリクのマージを急かさないで

プルリク投げてマージを急かす人がいますけど、あれも困ります。

あとの作業にそのブランチがマージされる必要があると懇願されたことがあるのですが、それってプルリク投げるタイミングでないかもしれません。 切りの良いところで、一旦プルリクを投げておきたいのであれば、その後も同じブランチで作業すればよいのです。 そのブランチでの作業はまだ終わっていないということですから。

勝手に安易にリファクタリングしないで

全体の構成を変更したり、命名規則を修正したりするリファクタリングに類することは広範囲に影響を及ぼしますから安易にこっそりやるべきではありません。 チーム内に注意を促してタイミングを見計らう必要があります。

また個々のコミットの変更内容を、極力あとでリファクタリングする必要がないように気をつけるのも必要です。