これは、 自然言語処理 Advent Calendar 2021 の20日目の記事です。 新卒2年目のエンジニア、吉成です。 普段はフォルシアのDXプラットフォーム部・技術研究所という2つの部署に所属し、web開発と自然言語処理の二足の草鞋を履いています。二兎を追う者は一兎をも得ずという言葉もありますが、今はひーひー言いながらも二兎を追えるエンジニアを目指しています。 ところで皆さん、依存構造解析してますか？ 依存構造解析は自然言語処理の実応用において重要な基礎解析の1つです。文中のどの単語（あるいは句）がどの単語（句）に依存しているか、またそれらの単語（句）間はどんな関係を持っているのか（依存構造）を解析します。一般的に依存構造解析は、文を単語や形態素に分割したり、単語や形態素に品詞のラベルを付与したりする形態素解析と呼ばれる処理の後に行われます。 （画像：「部屋から見える夜景が美しかった。」の依存構造解析の結果） 上の図は、「部屋から見える夜景が美しかった。」という、ホテルのレビューを想定した自然言語文に対して依存構造を解析した結果です。単語の下に書いてある NOUN , ADP などの文字列はそれぞれ名詞、助詞といった品詞を表しています。また、依存関係を持つ単語と単語が矢印で繋がれており、それぞれの矢印には関係の種類を表すラベルが付与されています。ここではすべてのラベルを説明することはしませんが、例えば以下のような意味があります。 夜景→見える acl：形容詞的修飾節 美しかっ→夜景 nsubj：名詞句主語 依存構造解析は様々な場面で役立てられます。例えば、「料理が高級ホテルのように豪華で美味しかった。」という修飾的な語句のある文を「料理が美味しかった。」などのように要約することで、人間が大量の文章を理解するのを補助する文書要約システムや、「〇〇ホテルはいつ開業しますか？」という質問に対して「〇〇ホテルは12月20日に開業予定です。」というような文を元に「12月20日」と回答するような質問応答システムなどへの応用が考えられます。今回は簡単な例文を使って、依存構造解析を使ったレビュー文からの情報抽出にチャレンジしてみましょう！ 準備 今回は依存構造解析を含む各種解析に GiNZA というPythonライブラリを使用します。GiNZAはMegagon Labsが開発したオープンソースの日本語NLPライブラリで、最先端の機械学習技術を組み込んだ自然言語処理のためのフレームワークである spaCy と、ワークスアプリケーションズ徳島人工知能NLP研究所で開発されたオープンソース形態素解析器のPython実装 SudachiPy を基盤技術としています。 今回の主役であり記事タイトルにもなっている DependencyMatcher はspaCyのAPIにあるものなので、本記事で DependencyMatcher の使い方を理解すればGiNZAによる日本語の自然言語処理だけでなく、spaCyで対応している他の言語の処理にも適用できます。 では早速、GiNZAをインストールしましょう。 pip install -U ginza ja-ginza-electra ja-ginza-electra というのは、GiNZA用の最新の言語モデルで、従来の言語モデルよりも高い解析精度を持ちます。 ただしメモリ容量16GB以上推奨とのことなので、メモリの小さいマシンで処理を行う場合や解析精度よりも実行速度を重視したい場合には、 ja-ginza-electra の代わりに ja-ginza をインストールしてください。 インストールが済んだら、ライブラリをimportして解析の準備を整えましょう。 import ginza import spacy nlp = spacy . load ( 'ja_ginza_electra' ) # 初回はモデルをダウンロードするために時間がかかります # nlp = spacy.load('ja_ginza') # ja-ginzaをインストールした場合のみ 続いて使用するテキストデータを準備します。 お手元にデータがあればそれを使用しても構いませんが、今回はサンプルとしてあるホテルのレビューを想定した3文を用意しました。 レビューデータは実務における自然言語処理でよく扱われるデータの1つです。 txts = [ "部屋から見える夜景が美しかった。" , "立地は悪いが食事が美味しい。" , "客室露天風呂は大人でも足がのばせてとても広かった。" ] Matcherによるマッチング まずは依存構造解析をせず、トークン（単語, 形態素）単位でのマッチングで情報を抽出してみましょう。 spaCyにはMatcherという、トークン単位でのマッチングに適したAPIがあります。 最初に、Matcherを使ってこのホテルのレビューにどのような形容詞が使われているのか見てみましょう。 from spacy.matcher import Matcher matcher = Matcher ( nlp . vocab ) # 日本語の語彙の集合を渡してMatcherオブジェクトを作る patterns = [ [{ "TAG" : { "REGEX" : "^形容詞" }}] # ルールの定義。品詞タグが「形容詞」で始まるもの ] matcher . add ( "adj" , patterns ) # Matcherオブジェクトにルール名adjとしてルールを登録 s = "" . join ( txts ) # 3つの文をつなげて1つの文字列にする doc = nlp ( s ) # 引数に与えられた文字列を文章として解析する matches = matcher ( doc ) # matchesの中にマッチング結果が入る ルールはマッチすべきトークンの属性を集めたdictのlistです。 例えば次のルールは、「品詞タグの名前が形容詞で始まるもの」を表すルールです。 [{ "TAG" : { "REGEX" : "^形容詞" }}] TAG は品詞タグを指定することを意味します。 TAG の代わりに LEMMA を使うことで見出し語に対する指定、 TEXT を使うことで文書中単語の文字列そのものに対する指定も可能です。 {"REGEX": "^形容詞"} は品詞タグが ^形容詞 という正規表現に当てはまるもの（＝すべての形容詞）という意味です。正規表現を使わない場合には文字列で "形容詞-一般" などと指定できます。 GiNZA内部で使われている形態素解析器SudachiPyの品詞タグの表現方法では、ハイフンつなぎでより詳細な品詞を表現しています。そのため「名詞」「形容詞」「動詞」といった大きな分類のみ使いたい場合は、正規表現で品詞タグを指定すると良いです。解析結果の doc をforループで回すとどの単語にどの品詞タグがついているか見ることができます。 ルールの書き方についてもっと詳しく学びたい方は 公式ドキュメント や公式の USAGE をご参照ください。 doc = nlp ( txts [ 0 ]) for token in doc : print ( token . text , token . tag_ ) # 部屋 名詞-普通名詞-一般 # から 助詞-格助詞 # 見える 動詞-一般 # 夜景 名詞-普通名詞-一般 # が 助詞-格助詞 # 美しかっ 形容詞-一般 # た 助動詞 # 。 補助記号-句点 ルールを定義できたら、次にそれをMatcherオブジェクトに登録します。 matcher.add() の第１引数にルールの名前、第2引数にルールのlistを指定することで登録できます。 ルールのlistなので、複数の条件を与えることが可能です。 例えば、形容詞に加えて形容動詞（「親切だ」「不愉快だ」など）にもマッチングさせたい場合には、次のように書くことができます。 patterns = [ [ { "TAG" : { "REGEX" : "^形容詞" }} ], [ # 今回使用したツールの品詞体系における形容動詞相当の表現 # 参考：https://ccd.ninjal.ac.jp/unidic/glossary { "TAG" : "名詞-普通名詞-形状詞可能" }, { "LEMMA" : "だ" } ] ] matcher . add ( "multiple patterns" , patterns ) マッチング結果を見てみましょう。 公式ドキュメント を見てみると、返り値には (match_id, start, end) のようなタプルのリストが返ってくるようです。ルールにマッチした部分の文字列はもともとの文章を解析した doc に対して doc[start:end] で取得できます。 for _ , start , end in matches : print ( doc [ start : end ]. lemma_ ) # .lemma_ は見出し語を取得することを意味する 上記のfor文を実行すると、次のような結果が出力されます。 美しい 悪い 美味しい 広い ホテルに泊まった人がどんなことを感じたのかはなんとなく伝わっていますが、なんとなく以上のことは分かりません。 特に、「悪い」については一体何が悪かったのか気になってしまいますね。 そこでルールを改良し、その形容詞に対する「何が」が分かるようにしてみましょう。 例えば、次のようなルール定義が考えられます。 patterns = [ [ { "TAG" : { "REGEX" : "^名詞" }}, { "TEXT" : { "IN" : [ "は" , "が" ]}}, #「は」か「が」のいずれかにマッチ { "TAG" : { "REGEX" : "^形容詞" }}] ] ] これを先程のようにMatcherオブジェクトに登録し、マッチング結果を見ます。 matcher = Matcher ( nlp . vocab ) matcher . add ( "noun-adj" , patterns ) doc = nlp ( s ) # s は txt に含まれる文をすべて join したもの matches = matcher ( doc ) for _ , start , end in matches : print ( doc [ start : end ]. lemma_ ) すると、次のように出力されます。 夜景が美しい 立地は悪い 食事が美味しい なるほど。「悪い」と言われているのは立地で、夜景と食事は褒められているようです。 ですがここで、形容詞を抽出したときの結果をもう一度見てみましょう。 美しい 悪い 美味しい 広い 上の3つは何に対して言われているのか分かりましたが、何が「広い」と言われているのかは抽出できていません。 「広い」という単語が含まれていたのは以下の文でした。 客室露天風呂は大人でも足がのばせてとても広かった。 他の文と比べるとやや複雑な文ですね。 人間はこの文を見たときに「広いと言われているのは客室露天風呂（あるいは露天風呂）だな」とすぐに判断できますが、コンピュータにとっては自明ではありません。 「広かった」の直前の3単語は「のばせ」「て」「とても」で、単純に「広い」の直前を見れば良いというわけではありません。 助詞「は」「が」で判断する手もあります。実際、助詞「は」「が」を含む直前の文節が形容詞の意味の対象となっている場合も多くあります。ただし今回の場合、直前の「は」「が」がつく単語は「足」で、「足が広い」と言っているとは考えづらいですね。 そんなときに使えるのが今回のメインテーマ、依存構造解析です。 DepdencyMatcherによるマッチング 実はspaCyにはDepdencyMatcherという、依存構造を使ったマッチングのためのAPIもあります。 使い方はMatcherと似ていますが、ルールの書き方とマッチング結果の取り出し方が異なります。 文に対する依存構造は木構造をなしています。つまり、ただ１つだけ根となるトークンがあり、根以外のトークンはただ1つの係り先トークンを持っているということです。 この記事の最初の図も、よく見ていただくと「美しかっ」というトークンを根とする木構造になっています。 文に対する依存構造が木構造なので、依存構造を使ったルールも木構造になります。 依存構造を使ったルールはトークン単位でのマッチングを行うルールより少し複雑なので、最初にルールの例をお見せします。 ソースコードと木構造の図を対応付けながら見てみましょう。 今回の例はノードが2つだけですが、これも立派な木構造です。 patterns = [ [ { "RIGHT_ID" : "adj" , "RIGHT_ATTRS" : { "TAG" : { "REGEX" : "^形容詞" }} } ,{ "LEFT_ID" : "adj" , "REL_OP" : ">" , "RIGHT_ID" : "noun" , "RIGHT_ATTRS" : { "TAG" : { "REGEX" : "^名詞" }, "DEP" : "nsubj" } } ] ] （画像：DependencyMatcher用のシンプルなルールの図解） 図のように、DependencyMatcher用のルールは左を根として右側にノードを生やしていく木構造になっています。 Matcherのときと同様に patterns がルールのlistになっていて、その中に1つ1つのルールがdictのlistとして表現されています。 dictはそれぞれ木構造の各辺に対応しています。ここでポイントになるのは、ノードではなく辺が1つのdictに対応していることです。 根ノードの左には何の条件指定もないダミーノードがくっついていて、ダミーノードと根ノードの間の辺も張らなければならない、と考えると分かりやすいです。 各項目の意味は次のようになっています。 LEFT_ID ：辺の左側のノードのIDとなる文字列。設定する場合、これまでの要素の RIGHT_ID で登場した文字列でなければなりません。 RIGHT_ID ：辺の右側のノードのIDとなる文字列。他のノードとかぶらない名前をつけます。 REL_OP ：左右のノードの関係。 > であれば右のノードが左のノードに直接依存していることを示し、 < であれば左右逆（左のノードが右のノードに依存）です。依存以外の関係も柔軟に定義でき、例えば . は文の中で右のノードが左のノードの直前に来ることを、 ; は右のノードが左のノードの直後に来ることを意味します。 RIGHT_ATTR ：辺の右のノードに対応するトークンの条件を記載します。Matcher用のルールと同様に品詞タグや見出し語などを直接指定できます。 DEP を使えば依存関係の種類も指定できます。 専門的な説明にはなりますが、GiNZA/spaCyで日本語テキストを解析する際の依存関係の種類については次の論文に詳しくまとまっています。 浅原 正幸, 金山 博, 宮尾 祐介, 田中 貴秋, 大村 舞, 村脇 有吾, 松本 裕治, Universal Dependencies 日本語コーパス, 自然言語処理, 2019, 26巻, 1号, p.3-36, https://www.jstage.jst.go.jp/article/jnlp/26/1/26_3/_article/-char/ja . 慣れないうちは依存関係の種類を指定することが難しく感じる方も多いかもしれません。 しかしながら、実際に様々な文を解析にかけながら参照してみると徐々に分かってくると思います。 解析結果は例えば次のように可視化できるので活用してください。 s = "部屋から見える夜景が美しかった" doc = nlp ( s ) displacy . render ( doc ) # jupyter上で可視化する場合はjupyter=Trueを指定する 次のような画像が出力されます。 また、各ノードには必須の項目があります。 根ノードを定義する dict： RIGHT_ID RIGHT_ATTR 辺を定義する dict： LEFT_ID REL_OP RIGHT_ID RIGHT_ATTR 右のノードがどんな単語でも良い、という場合もありますが、その場合は RIGHT_ATTR に空のdict {} を設定しておきます。 もっと複雑なルールを書きたい場合には 公式ドキュメント や公式の USAGE をご参照ください。 さて、ルールの書き方の説明が長くなってしまいましたが、上記のルールでマッチングをしてみましょう。 from spacy.matcher import DependencyMatcher matcher = DependencyMatcher ( nlp . vocab ) patterns = [ [ { "RIGHT_ID" : "adj" , "RIGHT_ATTRS" : { "TAG" : { "REGEX" : "^形容詞" }} } ,{ "LEFT_ID" : "adj" , "REL_OP" : ">" , "RIGHT_ID" : "noun" , "RIGHT_ATTRS" : { "TAG" : { "REGEX" : "^名詞" }, "DEP" : "nsubj" } } ] ] matcher . add ( "adj_noun_pair" , patterns ) # txts = [ # "部屋から見える夜景が美しかった。", # "立地は悪いが食事が美味しい。", # "客室露天風呂は大人でも足がのばせてとても広かった。" # ] # s = "".join(txts) doc = nlp ( s ) matches = matcher ( doc ) DependencyMatcherのマッチング結果は、マッチングIDと、ルールとの対応付け（alignments）のタプルとして返されます。 alignmentsはルールの各要素で定義された辺の右側のノードにあたるトークンのindexが格納されています。 そのため、次のようにして結果を取り出します。 for _ , alignments in matches : print ([ doc [ alignment ]. lemma_ for alignment in alignments ]) # ['美しい', '夜景'] # ['悪い', '立地'] # ['美味しい', '食事'] # ['広い', '露天風呂'] 各マッチング結果について、最初にID adj に対応するトークンのindexが、次にID noun に対応するトークンのindexが格納されていることがわかります。 また、 客室露天風呂は大人でも足がのばせてとても広かった。 について、広いのが露天風呂であるということも拾えています。 欲を言うと広いのは「露天風呂」というより「客室露天風呂」としてほしい場面もあると思いますが、複合名詞を抽出できるようにする対応もDependencyMatcherのルールを改良することで可能になります。ご興味のある方はぜひ考えてみてください。 まとめ 本記事では、GiNZAとspaCyのDependencyMatcherを用いて日本語のレビューから情報を抽出する方法について、簡単な例を用いて説明しました。 また、DependencyMatcherの便利さを示すため、Matcherによる情報抽出も行いました。 GiNZAもspaCyも、実務で自然言語処理を行う際には非常に便利なライブラリです。 今回紹介した機能に限らず、GiNZA/spaCyを使いこなして世の中のテキストデータを有効に活用していきましょう！

これは、自然言語処理 Advent Calendar 2019の20日目の記事です。 新卒2年目のエンジニア、吉成です。 普段はフォルシアのDXプラットフォーム部・技術研究所という2つの部署に所属し、web開発と自然言語処理の二足の草鞋を履いています。 二兎を追う者は一兎をも得ずという言葉もありますが、今はひーひー言いながらも二兎を追えるエンジニアを目指しています。 ところで皆さん、依存構造解析してますか？ 依存構造解析は自然言語処理の実応用において重要な基礎解析の1つです。 文中のどの単語（あるいは句）がどの単語（句）に依存しているか、またそれらの単語（句）間はどんな関係を持っているの

これは、 FORCIA Advent Calendar 2021 の19日目の記事です。 はじめに 第1旅行プラットフォーム部長の武田です。これまで検索アプリケーションの開発をメインに担当していましたが、最近は検索で利用する商品データを作成するサービスの開発をしています。 慣れ親しんだ検索アプリケーションとは異なりますが、そのノウハウを活かしつつ、新しいことに取り組んでいます。今回はそのサービス開発で利用している技術についてご紹介いたします。 フロントエンド Next.js フォルシアではアプリケーション開発で社内製のWebアプリケーションフレームワークを利用しています。現在は3代目までのWebアプリケーションフレームワークが存在します。3代目のフレームワークは内部で Next.js を利用しています。そのためNext.jsを採用するのは自然な流れでした。 この社内製Webアプリケーションフレームワーク開発の話は こちら です。 なお、今回開発しているアプリケーションは検索アプリケーションではなく、主にデータを登録する管理画面系のアプリケーションとなっています。通常のSpookの開発とは大きく異なるアプリケーションのため社内製フレームワークは利用しませんでした。 個人的には今回のアプリケーションでは Svelte の採用もありかと考えましたが、以下の理由から見送っています。 Reactでの開発に慣れているエンジニアが多い アプリ開発の規模も大きく、Svelteでどこまでうまく対応できるか未知数 antd デザインシステムとして antd を採用しています。 MUI(旧Material-UI) と比較して管理画面向けのコンポーネントが多い Form関連のコンポーネントも強力で、不要な再レンダリングが発生しないようになっている（ React hook form も良い評判を良く聞きます） コンポーネントだけでなく、ガイドラインやデザインパターンについてのドキュメントも多く充実している といった点で採用しました。 現状、Next.jsでantdを利用していると特定のコンポーネントを使用した際に以下の Warning が出ます。 Warning: useLayoutEffect does nothing on the server, because its effect cannot be encoded into the server renderer's output format. This will lead to a mismatch between the initial, non-hydrated UI and the intended UI. Toavoid this, useLayoutEffect should only be used in components that renderexclusively on the client. See https://reactjs.org/link/uselayouteffect-ssr for common fixes. これはantdが内部的に利用している rc(react-component) がSSR対応されておらず、useLayoutEffectフックを利用しているためです。 対応 自体は進められており、近い将来解消すると思われます。 Storybook 今回の案件では、エンジニアがスタイリングを含めてコンポーネントを開発しており、 Storybook を利用しています。 GitLab CIを利用して、mainブランチをpushしたタイミングでStorybookをbuild、生成したhtmlをS3+CloudFrontにアップし、常に最新のコンポーネントを全メンバーが確認できる状態にしています。 Storybookを用意することでエンジニア以外のプロジェクトメンバーもどのようなコンポーネントがあり、開発中のデザインがどうなっているか確認できるというメリットがあります。 現時点ではコンポーネントの設計等も頻繁に変わるような開発初期段階のため、Storybookを利用したテストは書いていませんが然るべきタイミングでスナップショットテストを含むコンポーネントのテストを実装していこうと考えています。 Apollo client データフェッチのライブラリとして Apollo client を採用しています。 GraphQLを利用しており、バックエンドで生成したGraphQLのschemaと GraphQL Code GeneratorのTypeScript React Apolloプラグイン を利用して、hookを自動生成しています。 状態管理のライブラリとして recoil を使いたいと思っていますが、現時点ではGlobalな状態管理が必要になるケースがそこまでなく、 Context API や useState hook 等で十分な可能性があります。 このあたりは開発を進めていく中で検討できればと考えています。 バックエンド NestJS バックエンドのフレームワークとして NestJS を採用しました。 協力会社のエンジニアさんはJavaでの開発に慣れたエンジニアが多い 社内のエンジニアはJavaScript, TypeScriptでの開発に慣れたエンジニアが多い という状態でした。将来的には社内でメンテナンスしていくサービスになるため、開発言語をJavaにしてしまうと運用時に厳しくなる可能性が高いと考えました。 JavaのSpring Frameworkのような書き味のNestJSを採用することで双方が開発、運用しやすい形にできるのではと考え採用しました。 こちらは Yahoo! JAPAN さんのこちらのTech Blog も参考にさせていただきました。 デコレータやDIを利用した開発は私含め社内のエンジニアも慣れておらず、若干の取っ付きにくさを感じましたが、慣れてくるとまさに関心の分離により、メインのロジックに集中できるように感じました。 また、協力会社のエンジニアさんからも書きやすいという声をいただき、採用して良かったと思いました。 NestJSはGraphQL Serverとして実装していて、デコレータをたくさん書く必要がありますが cli-plugin を導入することにより、記述量を大きく削減できました。 GraphQLについて NestJSはGraphQL Serverとして実装しています。 今回のアプリケーションでは非常に多くの画面が存在し、それに伴いAPIの数も多くなることが見込まれました。 参照でGETのエンドポイント、データの追加でPOSTのエンドポイントを用意、データの更新ではPUT/PATCHといったエンドポイントを用意して...となると考えることも多く、特にRESTfulなAPIを設計する場合にエンドポイントの設計だけでも膨大な時間がかかってしまう可能性がありました。 GraphQLではデータ取得はquery、データを操作する際はmutation、あとはハンドラメソッド名を考えれば済むため、地味ではありますがエンドポイントについて考える時間はかなり短縮された感覚です。 GraphQLでは「フロントエンドでの取り回しは楽になるが、バックエンドの実装は複雑になる」といった話を何度か耳にしたことがあります。開発を進めてみてNestJSがよくできているのか、そこまで複雑になっている印象はありません。 現時点では、GraphQLのバックエンドの実装は通常のWeb APIとそこまで変わらないように感じました。 実際、REST APIで開発するか、GraphQLにするかは非常に悩んだポイントではありますが、チームメンバーの使ってみたさあります！という声や メルカリ Shops さんの記事 も採用の後押しになりました。 コードファースト？スキーマファースト？ NestJSでGraphQL Serverを実装する際にコードファーストで進めるか、スキーマファーストで進めるか、という点がひとつ悩ましいポイントかと思います。 今回のプロジェクトではコードファーストのアプローチを取ることにしました。 理由は以下のとおりです。 フロントエンドの開発をした人がそのままバックエンドのAPIも実装する形式になっている フォルシアではフロントエンドとバックエンドでエンジニアが分かれておらず、どちらも実装する そのためスキーマベースで認識を合わせる必要がない モノレポ構成となっており、フロントエンドとバックエンドのコードが同一リポジトリで管理されている こちらは毎週実施している技術ディスカッションという社内MTGの場で相談したところ、上記のようなコメントをいただき、コードファーストで進めることにしました。 実際、コードファーストで進めてみて快適に開発できている印象です。 Prisma ORMとして Prisma を利用しています。 通常はPrisma schemaによるモデリングでデータベースの設計をしていくかと思いますが、フォルシアには独自のschema定義を用意してデータベースを構築する仕組みがあります。 データベースの構築は独自の仕組みを利用し、Prismaとの連携では prisma db pull （旧 prisma introspect ）コマンドを利用してprisma.schemaファイルを生成しています。 データベースからのデータの取得が型安全になり、TypeScriptで補完が効く点も非常に良い開発体験が得られています。 一方、私含めフォルシアのエンジニアはパフォーマンス面も考慮したSQLを書くことを得意としていますが、PrismaのようなORMで効率的にデータを取得するノウハウは少ないため、少しずつ知見を貯めていければと考えています。 Prismaは周辺ツールも強力で、初期開発時のサンプルデータの作成では prisma studio を利用しています。 資金調達 もしており、引き続き活発な開発が進められていくことが見込まれる点も採用を後押ししました。 schemaspy 今回の案件では外部サービスからデータベースにアクセスするケースもあるため、テーブル定義書を用意する必要がありました。 schema定義と別でテーブル定義書を作成するのではなく、構築したデータベースから schemaspy を利用して定義書を生成するようにしました。 また、テーブルやカラムの論理名を表示したいという要件がありました。 PostgreSQLではテーブルやカラムに対してコメントを付与する機能があるため、こちらを利用しました。 コメントの1行目が論理名 2行目以降がテーブル、カラムのコメント本文 として、schemaspyをforkして機能を追加することで日本語の論理名も一緒に表示できるよう対応しました。 この機能を追加したもののソースコードは こちら に公開しています。 生成されるテーブル定義書は以下のようになります。 こちらもStorybookと同様にGitLab CIを利用してmainブランチにマージされたタイミングで最新のテーブル定義書がbuildされ、Web上で確認できるようにしています。 Dockerの利用について 開発環境では Docker を利用して、各プロセスはすべてコンテナで動作するようになっています。 環境構築用のinit scriptも用意しており、手元の環境にDocker、 Docker Compose をインストールしておけばすぐに開発に入れるようになっています。 また、バックエンドのNestJSで生成したGraphQLのschemaファイルは変更があったタイミングでフロントエンドのコンテナに同期されます。 これは chokidar-cli を動かすコンテナを別で用意して実現しています。 これによりフロントエンド側で参照していたフィールドを削除したケースなどは型エラーとして即時検知できます。 docker-compose up すれば自動生成ファイルの連携含めて、ホストマシン側では特に何のプロセスも動かさずに開発できるように、ということを意識しています。 バッチ処理まわり 外部サービスから連携データを取得し、取り込み 外部サービスへの連携データを生成 といったバッチ処理も存在します。こちらはSQLやshellコマンドなどを柔軟に実行する社内独自の仕組みを利用して実装しています。 実際に開発が進んできての印象 デザインを含めてエンジニアが実装していますが、デザインの調整にかなりの実装時間を割いてしまっている デザインの経験があるエンジニアが少なく、慣れていないという点が大きいです GraphQL、何もわからない状態からスタートしていましたが実際には単なるインタフェースであり、Web APIと大きく変わらないと感じてからは仲良くなれてきた気がします GraphQLを取り巻くエコシステムがかなり発達しており、このあたりも開発体験を向上させているように感じました データベースのテーブル定義が変わったときのコードの変更量が多い... このあたりはなるべく少なくなるように、というのを意識してはいましたが...開発初期段階ではどうしてもテーブル定義に変更が入ることが多く、ここの追従をいかに楽にするかは今後の課題です まとめ フォルシアでは検索Webアプリケーションの開発で培ったノウハウを活かしつつ、新しい技術も取り入れながら検索以外のWebアプリケーション開発にも取り組み始めています。技術選定の際に今回の記事が少しでも参考になりましたら幸いです。

はじめに 第1旅行プラットフォーム部長の武田です。これまで検索アプリケーションの開発をメインに担当していましたが、最近は検索で利用する商品データを作成するサービスの開発をしています。 慣れ親しんだ検索アプリケーションとは異なりますが、そのノウハウを活かしつつ、新しいことに取り組んでいます。今回はそのサービス開発で利用している技術についてご紹介いたします。 フロントエンド Next.js フォルシアではアプリケーション開発で社内製のWebアプリケーションフレームワークを利用しています。現在は3代目までのWebアプリケーションフレームワークが存在します。3代目のフレームワークは内

これは、 FORCIA Advent Calendar 2021 の18日目の記事です。 こんにちは。DXプラットフォーム事業部のエンジニアの多田です。 技術教育チームにも所属し、技術系の新入社員研修の運営に関わっています。 本日は総合職および、エンジニア向け技術研修の内容についてご紹介します。 総合職向けの研修 概要 目的：アプリ開発を通じ、エンジニアの業務に対しイメージをつけ業務でのやり取りに活かしてもらうため。 業務に必要なWEBアプリケーションの基礎知識を学習するため。 期間：3週間 研修内容 Webアプリケーション開発に必要な基礎概念の学習 HTML/CSS/JavaScriptの概念、基本構文の学習 外部サービス Progate を用いています。 JavaScript課題 配列の値を順に書き出す等、基本文法やデバッグの仕方に慣れるための課題を出しています。 技術講義 基礎的な技術の知識（WEBアプリケーションの仕組みやDBについて）や フォルシアの検索プラットフォームであるSpookの特長などを学習します。 アプリ開発 　APIを用いて、検索可能なクライアントサイドのアプリ開発をします。 見積課題 　作業コストを見積もる課題を行います。 　 課題作成にあたりやったこと 研修後の業務に活きるよう、営業/エンジニア社員それぞれに業務で知っておきたかったこと、 知っておいてほしいことをヒアリングしました。 「営業として顧客とのやり取りで使う技術について知っておくとよさそう」、「エンジニアとして営業の方によく説明する単語があるので、研修時点で知っていおいてもらえると嬉しい」など 色々な意見をもらい取り入れました。 課題の変わり目のサポートを加えました。 これまでの経験より、ProgateからJavaScript課題、JavaScript課題からアプリ開発と課題の変わり目で躓きがちで あまり本質的でない点で時間が溶けてしまうこともありました。そこで、それぞれの課題の差分を考え、必要なサポートを追加しました。 具体的に言うとエディタや開発者ツールの使い方を先に知っておいた方がスムーズに進みそうだったので、学べる課題を追加しました。 エンジニア向けの研修 概要 目的：配属後スムーズに動き出せる技術や自走スキルを身につけるため。 フォルシアのエンジニアとして配属までに到達してほしい技術レベルを獲得してもらうと同時に、調査力や質問力を高めてもらいたいと思っています。 期間：2.5カ月 下記のように前半・後半に分かれています。 前半1.5カ月：個人課題 後半1カ月：チームに仮配属、実務体験 研修内容 今回は前半の期間に行う個人課題についてご紹介します。 ※新卒社員は未経験の方からアプリ開発経験者まで、技術レベルは様々です。 そのため、未経験からでも問題ないことを前提としています。 WEBアプリケーション開発に必要な技術の習得 基礎的な学習 総合職向け研修と同様、外部サービス Progate を用いています。 JavaScript課題 前述のProgateより発展的な課題として、JSON.stringifyをはじめとした関数の実装課題を出しています。 SQL課題 フォルシアの検索アプリケーション開発中ではSQLを触る場面が多くあります。 ホテルや最寄り空港のデータを用いて、データ取込やテーブル作成、WHERE,ORDER BY, GROUP BY, JOINなど基本構文を使った課題を出しています。 技術講義 WEBアプリケーションの構造、HTTPやSSHの仕組み、セキュリティといった一般技術の理解、 　GitやLinuxコマンド、サーバリソース調査、テストといった開発運用業務で必要な知識等々 　一般的な知識からフォルシア独自の知識まで幅広く扱います。 　講義の中で実際に手を動かしてみるような機会もあります。 アプリ開発 　研修のメインテーマです！約1カ月に渡り、検索アプリケーションを開発します。 　課題の大枠は用意していますが、明確なゴール設定はありません。　自ら設定し、解決のための道筋をたててもらいます。 　研修詳細については下記をご覧ください。 　 19卒エンジニアが奮闘　名簿アプリ開発研修 課題作成にあたりやったこと 必要な技術レベルに到達してもらいつつ、自由度を持たせるため必達の課題＋αの課題を作成しました。 技術講義は、講師側に教育チームより目標および「重点的に説明する点・ざっくり説明する点・とばしたほうが良さそうな点」を共有しました。 実際の講義では、目標に向け「わかりにくいから変更しよう」「これは手を動かす形にしてみよう」など講師が工夫して実施してくれました。 技術講義には教育チーム以外の技術社員にも協力してもらっており、新入社員との繋がりができる機会にもなっています。 おわりに 最後まで読んでいただきありがとうございました！ 今回は研修内容に焦点をあてご紹介しましたが、その他にも社員同士の関係性構築・ソフトスキル面向上のための取り組みも実施しています。 下記の記事でご紹介していますので、ぜひそちらもご覧ください。 FORCIA Meetup #3 未経験者も即戦力にするフォルシアの技術教育 新人研修はその後スムーズに入っていくための準備期間、そして内容や取り組みを通じ、 参加者にその場(会社)への安心感をもってもらい次へと進む土壌を作る期間でもあると思います。 期間はほんの一瞬ですが、それを経て各自の持ち味が少しでもより発揮しやすい状態になるといいなと感じます。 フォルシアに興味をもってくださった方は、是非弊社採用ページもご確認ください！

こんにちは。DXプラットフォーム事業部のエンジニアの多田です。 技術教育チームにも所属し、技術系の新入社員研修の運営に関わっています。 本日は総合職および、エンジニア向け技術研修の内容についてご紹介します。 総合職向けの研修 概要 目的：アプリ開発を通じ、エンジニアの業務に対しイメージをつけ業務でのやり取りに活かしてもらうため。 業務に必要なWEBアプリケーションの基礎知識を学習するため。 期間：3週間 研修内容 Webアプリケーション開発に必要な基礎概念の学習 HTML/CSS/JavaScriptの概念、基本構文の学習：外部サービスProgateを用いています。

これは、 FORCIA Advent Calendar 2021 の17日目の記事です。 zx とは zxはNodeの child_process のラッパーで、JavaScriptで記述したスクリプトをNodeで実行し、 shellコマンドを発行できます。 一言で表すと、お手軽にJavaScriptで記述し、実行できるshellです。 googleから公開され、2021年初頭に話題になりました。(google/zx: https://github.com/google/zx ) 筆者は普段からスクリプトはbashで実行している一方、業務で使い慣れているTypeScriptの型をzxで使えるとマニュアルで見かけ、使ってみました。 zx の導入 zxを利用するには、まず、Nodeのバージョンが14.13.1以上である必要があります。 Nodeの準備が整っていれば、以下でインストールします。 npm i -g zx zxで実行するスクリプトは、top-level-awaitを利用すべく、 .mjs 拡張子での作成が推奨されています。 .js で作成する場合、コマンドの発行部分で void async function(){...}() と記述する必要があり、少し長くなってしまいます。 zx の使用 以下でいくつかzxの使用方法を解説します。 コマンドの発行 zxで利用するスクリプトでは、先頭に #!/usr/bin/env zx を記載し、それ以下へ処理を記述していきます。 また、以下のcommandの部分へ、shellで発行したいコマンドを記述します。 $`command` 以下はhello worldするスクリプトです。 変数の記述はJavaScriptで見慣れた記法そのものです。 #!/usr/bin/env zx const word = "hello world"; await $`echo ${word}`; 作成したスクリプトは、以下のように実行します。 zx ./hello.mjs $ echo $'hello world' hello world zx ./hello.mjs で実行した結果、 $ echo $'hello world' とコマンドが出力された後、 hello world がechoされていることが分かります。コマンドおよび実行結果をコンソールへ出力させない場合、 zx ./hello.mjs --quiet と実行することで、表示させないことができます。 関数/パッケージの利用 追加でインストールせずとも利用できる関数/パッケージについて一部紹介します。 sleep JavaScriptでの setTimeout をラップした関数です。以下ではneruをechoし、1秒待った後 okita がechoされます #!/usr/bin/env zx $`echo neru`; await sleep(1000); $`echo okita`; zx ./wakeup.mjs $ echo neru neru $ echo okita okita fetch zxではnode-fetchをラップしたfetch関数を以下のように利用できます。 #!/usr/bin/env zx const resp = await fetch("https://www.forcia.com/"); console.log(resp.ok); zx ./fetchForcia.mjs $ fetch https://www.forcia.com/ true TypeScript で書いてみる 筆者は業務において、JavaScriptを生で記述する機会はほとんどなく、TypeScriptを使用しています。 zxのマニュアルにも記載がありますが、zxのスクリプトをTypeScriptで記述し、実行してみます。 まず、実行するには ts-node , typescript が必要なので、インストールします。 npm i -g ts-node npm i -g typescript hello worldするスクリプトは以下のように記述できます。 #!/usr/bin/env zx import "zx/globals"; const word: string = "hello world"; void (async function () { await $`echo ${word}`; })(); ここでは以下で実行します。 ts-node tsZx.ts $ echo $'hello world' hello world TypeScriptでの記述なので以下のような不正な記述に対し、警告を発報してくれます。 もちろんts-nodeで実行してみても同じ型エラーが発報され実行はされません。 また、TypeScriptをVScodeで記述する際によく活用される、 "F12を押して関数へジャンプ"がここでも可能です。 以下画像はzxでの $ 関数へジャンプしている画像です。 さらに、以下のように別途 index.d.ts を用意します。 interface Hello { word: string; language: string; } export type HelloWords = Hello[]; それをzxで実行するスクリプトへimportして型を利用できます。 #!/usr/bin/env zx import "zx/globals"; import { HelloWords } from "."; const words: HelloWords = [ { word: "こんにちは", language: "Japanese", }, { word: "Hello", language: "English", } ]; Promise.all( words.map(w => { $`echo word: ${w.word} language: ${w.language}`; }) ); ts-node tsZxType.ts $ echo word: $'こんにちは' language: Japanese $ echo word: Hello language: English word: こんにちは language: Japanese word: Hello language: English 筆者はShellよりもTypeScriptでの記述の方が親しみがあるためか、 zxでの記述が見通しがいいように感じられます。 使ってみた感想 慣れた方は普通にShellで書いた方が早そうではありますが、JavaScriptに親しみがある方は使用してみてもいいかもしれません。 TypsScriptの実行環境を整える手間はありますが、TypeScriptの便利さをShellでも再現できたのには感動しました。

zx とは zxはNodeのchild_processのラッパーで、JavaScriptで記述したスクリプトをNodeで実行し、 shellコマンドを発行できます。 一言で表すと、お手軽にJavaScriptで記述し、実行できるshellです。 googleから公開され、2021年初頭に話題になりました。(google/zx: https://github.com/google/zx) 筆者は普段からスクリプトはbashで実行している一方、業務で使い慣れているTypeScriptの型をzxで使えるとマニュアルで見かけ、使ってみました。 zx の導入 zxを利用するには、まず、No

これは、 FORCIA Advent Calendar 2021 の16日目の記事です。 はじめに 新卒1年目の井上と申します。本格的な業務を開始して以来、TypeScriptという言語を触ってきました。TypeScriptというのはその名の通り、JavaScriptに型を付けたような言語です。学生のころよく書いていた言語といえばC++やJavaなのですが 1 、どうやらそれらの言語よりも型でいろんなことができるようで、せっかくなのでTypeScriptの豊かな機能を学んでみたいとなんとなく思っていました。 そんなことを考えていたら、 type-challanges というサイトの存在を教えてもらいました。このサイトでは、与えられた型から新たな型を生み出すという問題を解きながら、TypeScriptの型について学ぶことができるようです。何かしらの問題を解くのが好きな筆者にとってはうってつけの場所です。本記事では、type-challangesに掲載されている、主に文字列に関する問題を解きながら 2 、TypeScriptの型でできることを紹介していきたいと思います。実務に何か生かすというよりは、こういう遊びもあるんだなという気持ちで読んでいただければ幸いです。 TypeScriptの型機能の紹介 問題を解くには知識が必要です。筆者が持つ(または参照できる)すべての知識 3 の解説をするのはここでは控えますが 4 、本記事で扱う問題を解く上でキーとなる機能について少し紹介しましょう。 リテラル型 TypeScriptの基本的な型(プリミティブ型)としては、 number 型、 string 型、 boolean 型などが挙げられますが、それらをさらに細分化した型がリテラル型です。 const age = 25; //ageは25型 const name = "inoue"; //nameは"inoue"型 const yes = true; //yesはtrue型 let age = 25; //ageはnumber型 ここで const で宣言した変数の型はそれぞれ number 、 string 、 boolean ではない ことに注意してください。例えば "inoue" 型というのは、 "inoue" という文字列しか代入できない型となります。 const で宣言された場合は再代入を許さないので、型としてもそれで十分だということですね。 let で宣言した場合は、別の値が入ることがあるのでプリミティブ型となります。 リテラル型が登場するシーンは他にもあります。 const printHello = (str : "World") => { console.log(`Hello ${str}!`); }; printHello("World"); printHello("Japan"); // compile error printHello という関数は、引数として " World " 型しか許さない関数として定義されます。これだと制約がきつすぎますが、 Union型 5 というものを考えることで、柔軟な型付けが可能となります。 type Country = "Japan" | "America"; const printHello = (country : Country) => { console.log(`Hello ${country}!`); }; printHello("Japan"); printHello("America"); printHello("Tokyo"); // compile error 型 A と B に対して型 C = A | B は、 A 型か B 型であるような型を表します。上記の場合、 printHello という関数は、引数として "Japan" 型か "America" 型しか許さない関数として定義されます。こうしてみると結構使いどころがありそうですね。 代入可能 文字列のリテラル型 "World" 型ですが、これを string 型として扱いたいというときもあるかもしれないし、実際そのようにみなすこともできます。このことを、ここでは " W orld " 型は string 型に 代入可能である ということにしましょう。このような関係は string 型だけではなく number 型、 boolean 型にも存在しますし、 "Japan" 型や "America" 型は "Japan" | "America" 型に代入可能です。型 A が型 B に代入可能なことを、 A extends B と書いたりします。 型から新しい型を作る TypeScriptでは、ジェネリクスを用いることで、型から新しい型を作る関数のようなものを作ることができます。 type getUnion<T, U> = T | U; type ex0 = getUnion<string, number>; //ex0はstring | number 型 type ex1 = getUnion<"a", "b">; //ex1は"a" | "b" 型 getUnion は、型 T と型 U を受け取り、型 T | U を返す関数です。このように、型から新しい型を作る関数のことをここでは型関数と呼ぶことにしましょう。 これは単純な例ですが、後に見るようにさまざまな型を生成できます。 ここからは少し高度な型の機能について見ていきます。 Conditional Types Conditional Typesの構文は以下のようになります。 T extends U? A : B この構文は、「 T が U に代入可能であれば、 A 型、そうでなければ B 型を返す」という意味です。三項演算子みたいなものですね。 type ex0 = "a" extends string? "x" : "y"; // "x"型 type ex1 = 0 extends string? "x" : "y"; // "y"型 type ex2 = "a" extends "a" | "b"? "x" : "y"; // "x"型 type ex3 = "c" extends "a" | "b"? "x" : "y"; // "y"型 例えば、Conditional Typesを使うとif文が実現できます。 問題1 真偽値のリテラル型 C 、任意の型 T 、 F が与えられる。 C が true であれば型 T 、そうでなければ型 F を返すような型関数 IF<C, T, F> を作成せよ。 type-challanges 問題リンク type ex0 = If<true, "a", "b">; // "a"型 type ex1 = If<false, "a", "b">; // "b"型 回答は次のようになります。 解答1 type If<C extends boolean, T, F> = C extends true? T : F; true 型に代入可能な型は true 型のみなので、 C が true 型なら T 型を返し、そうでなければ F 型を返すということになります。 さて、Conditional Typesには条件文がありますが、なんとこの条件文で、新たな型変数を導入できます。 問題2 Promise<Type> 型が与えられるので、型 Type を得る型関数 Awaited を作成せよ。 type-challanges 問題リンク 解答2 type Awaited<T> = T extends Promise<infer R> ? R : never; infer R という構文が、 R という新たな型変数をこの後使いますよ、という意味です。 Promise の中身の型はわからなくても、TypeScriptが型推論をし、その型を返すような型関数を作成できるわけです。 Template Literal Types Template Literal自体はJavaScriptのES6から導入された機能で、文字列を自分で定義した変数を用いて作成できる機能です。これはお世話になっている人も多いと思います。 const fruit = apple; const applePie = `${fruit}Pie` // applePie = "applePie"となる これが型でもできるいうのがTemplate Literal Typesです。 type Fruit = "apple" | "peach"; type FruitPie = `${Fruit}Pie`; // FruitPie型は "applePie" | "peachPie" 型 こんなこともできます。 type ID = `Number : ${number}`; const ex0:ID = "Number : 1 " ; const ex1:ID = "Number : 12345 " ; const ex2:ID = "Number : abc " ; //compile error ID 型の定義のTemplate Literal Typesの部分に number が使われています。このように書くと、 ${number} の部分を数値型に置き換えることが可能な文字列を受け入れる型を定義できます。 このTemplate Literal Typesと、先ほど紹介したConditional Typesを用いると、型における文字列の操作が可能になります。 問題3 文字列のリテラル型 S 、 From 、 To が与えられる。 S を左からみたときに一番最初に部分文字列として現れる From を、 To に置換した型を返すような型関数 Replace を作成せよ。ただし、 From が空文字列の場合は置換しなくてよい。 type-challanges 問題リンク type ex0 = Replace<"types are fun!", "fun", "awesome"> //"types are awesome!"型 type ex1 = Replace<"aaa", "a", "b"> //"baa"型 一見大変そうですが、なんとこれが次のように書けてしまうことがTemplate Literal Typesの面白いところです。 解答3 type Replace<S extends string, From extends string, To extends string> = From extends '' ? S: S extends `${infer L}${From}${infer R}`? `${L}${To}${R}`:S; 3行目に注目してください。この条件文では、「 S という型が ${L}${From}${infer R} という形で書けるか」ということを判定しています。しかもこの一致判定は前方一致 6 なので、最も左に現れる文字列 From が ${From} に対応します。この条件が満たされれば、 ${L}${To}${R} という形で表される文字列のリテラル型を返すので、 From を To に置換することが達成されます。 問題4 文字列のリテラル型 S 、 From 、 To が与えられる。 S を左から順に、部分文字列として現れる From を、 To に すべて 置換した型を返すような型関数 ReplaceAll を作成せよ。ただし、 From が空文字列の場合は置換しなくてよい。 type ex0 = ReplaceAll<"types are fun!", "fun", "awesome"> //"types are awesome!"型 type ex1 = ReplaceAll<"aaa", "a", "b"> //"bbb"型 type ex2 = ReplaceAll<"aaa", "aa", "b"> //"ba"型 type ex3 = ReplaceAll<"ababa", "cc", "acccc"> // " aba ba"型 先ほどは左から見て最初の From を置換するだけでしたが、今回はすべて置換する必要があります。ここで大事なことは、Conditional Typesによって 再帰 が実現できるということです。 解答4 type ReplaceAll<S extends string, From extends string, To extends string> = From extends '' ? S: S extends `${infer L}${From}${infer R}`? `${L}${To}${ReplaceAll<R, From, To>}`:S; 先ほどの Replace 関数と違い、 ReplaceAll 関数ではConditional Typesの分岐後に R 型の部分に対して ReplaceAll を適用しています。このように再帰関数として型関数を定義することで、さまざまなことが型で実現できるようになります。 さらに文字列操作に関する問題を解く これらの機能を用いて、いろいろな問題を解いてみましょう。 問題5 文字列のリテラル型 S に対して、その長さを表す数値のリテラル型を返す型関数 LengthOfString を作成せよ。 type-challanges問題リンク type ex0 = LengthOfString<"abcda">; // 5型 type ex1 = LengthOfString<"a">; // 1型 普通の文字列であればその長さを取得できるメソッドがありますが、型には残念ながらありません。自分で書きましょう。 まず、以下のようにすれば、「文字列を先頭から一文字ずつ切り出して何らかの操作をする」ということができます。つまり、 for文が書けます 。 S extends `${infer L}${infer R}`? Lに対する何らかの操作+Rに対する再帰 : 停止操作 ${infer L}${infer R} の L の部分が前方一致となっており、 S の最初の1文字を切り出すということができます。 S の残りの文字列が R になります。 それならば、 Cnt という数値型を用意して、一文字ずつ切り出すごとに Cnt に1加える、ということを繰り返せばよさそうに思えますが、なんと「数値型に対して1加える」という操作が容易にできません。そこで、型で数値演算を扱う唯一の方法である タプル型 が登場します。タプルといっても実際は配列なので、ここでは詳細な説明は省略し 7 、その機能に注目しながら先に進みます。 実はこのタプル型には、その長さを取得する方法が用意されています。 type T = ["a", "b", "c"]; // タプル型 type length = T["length"]; // 3型 なんとタプル型 T に対して、 T["length"] でその長さを表す数値型を取得できます。そんなわけで、このタプル型をカウンターとして用いることにしましょう 8 。 元の問題に戻ります。「文字列 S を左から一文字ずつ切り出し、タプル型の要素に追加する」ことを繰り返せばよいです。全て追加し終えたら、タプルの型の長さを取得すればよいです。 解答5 type LengthOfString<S extends string, Cnt extends any[] = []> = S extends `${infer L}${infer R}`? LengthOfString<R, [1, ...Cnt]> : Cnt["length"]; 型関数も普通の関数と同様、デフォルト引数を設定できます( Cnt extends any[] = [] の部分)。 Cnt のデフォルト引数を空のタプルとして、カウンターを初期化します。 `${infer L}${infer R}` で一文字切り出し、 LengthOfString<R, [1, ...Cnt]> としてカウンターに何かしらの要素を追加します(1である必要性はなく、 "" でも十分です)。 ...Cnt という記法は配列やオブジェクトと同じで、タプル型の要素を展開するものです。 問題6 文字列のリテラル型 S に対して、 S が回文であれば true 型、そうでなければ false 型を返す型関数 IsPalindrome を作成せよ。 type-challanges問題リンク リンク先ではnumber型も考慮する必要がありますが、ここでは文字列型に限定しておきましょう。 type ex0 = IsPalindrome<"abcba">; //true型 type ex1 = IsPalindrome<"abcdef">; //false型 この問題はTypeScriptの型ではなく普段慣れ親しんでいるプログラミング言語で判定を書いてくださいと言われても、苦戦する人がいるかもしれません。文字列 S が回文であるということは、 S を反転させた文字列を revS とすると、 S と revS が一致することと同値です。したがって、 S を反転した文字列が得られればなんとかなりそうです。このためには、空文字列 T を用意し、 S を1文字ずつ切り出しながら、 T の先頭に追加していけばよさそうです。 type Reverse<S extends string, T extends string = ""> = T extends `${infer L}${infer R}`? Reverse<R, `${L}${T}`> : T; Conditional Typesの条件分岐後の Reverse<R, `${L}${U}`> という部分で、 S の先頭の文字を T の先頭に追加する、という操作が実現されています。ここまでできれば、リテラル型に関する型の一致判定は extends で十分なので、次のようにすればよいでしょう。 解答6 type Reverse<S extends string, T extends string = ""> = S extends `${infer L}${infer R}`? Reverse<R, `${L}${T}`> : T; type IsPalindrome<S extends string> = S extends Reverse<S>? true : false いかがでしょうか。型レベルでも結構いろんなことができそうな気持ちになってきたのではないでしょうか。これらを体得したいという型は、ぜひtype-challangesの問題に挑戦してみてください。また、本記事ではオブジェクト型に関する問題は扱いませんでしたが、TypeScriptを使いこなすうえでは大事なテーマかと思いますので、こちらも問題を見てみるとよいと思います。 最後に、もう一問問題を出題して本記事の締めくくりとしたと思います。本記事で紹介した知識のみで解くことができるので、ぜひ考えてみてください。 最後まで読んでいただきありがとうございました。 演習問題 文字列 S が 平方 であるとは、ある文字列 T が存在して S=TT と書けることをいう。つまり、 S がある文字列を2つ並べて得られる文字列であるとき、 S は平方であるという。 文字列のリテラル型 S が与えられる。 S が平方であれば true 型、そうでなければ false 型を返す型関数 IsSquare を作成せよ。 9

はじめに これは、FORCIA Advent Calendar 2021の16日目の記事です。 新卒1年目の井上と申します。本格的な業務を開始して以来、TypeScriptという言語を触ってきました。TypeScriptというのはその名の通り、JavaScriptに型を付けたような言語です。学生のころよく書いていた言語といえばC++やJavaなのですが[1]、どうやらそれらの言語よりも型でいろんなことができるようで、せっかくなのでTypeScriptの豊かな機能を学んでみたいとなんとなく思っていました。 そんなことを考えていたら、type-challangesというサイトの存在を教え

これは、 Qiita Advent Calendar 2021 GitLab の15日目の記事です。 はじめに こんにちは、 フォルシア にて、旅行会社向けの web アプリケーションを開発しています、エンジニアの高橋です。普段のアプリ開発の業務のほかに技術広報も兼任しており、弊社で開催しているアドベントカレンダーの運営もお手伝いしています。 フォルシアではもともと、社内のイベントとしてアドベントカレンダーを始めましたが、2018 年からは弊社ブログ（ FORCIA CUBE ）にて外部の方向けに記事を公開しています。 社内のみで記事を公開していた頃は、誰かが多少締め切りをすぎても「かまへんかまへん」と言えますが、外部に公開するとなるとそうはいきません。25 日間落とすことなく記事を上げ続けるために、執筆者へのフォローや締め切り管理、ブログへのアップロードを組織的に行う必要がありました。 外部公開を始めた初年度は esa というドキュメントツールのみで記事や進捗を管理していましたが、どの記事がいつ公開なのか、レビューが終わっているのかどうかなどを一覧で見ることができず、管理がなかなか大変でした。 そこで 2020 年より、社内ですでに使用していたコードのホスティングサービスである GitLab を利用して記事を管理するようにしました。GitLab の issue 機能を使い 1 issue = 1 記事に対応させて管理するようにしたことで、かんばんボードを使って記事の進捗を管理することができるようになり、大変便利でした。以下の図のように、カラムやラベルを付けて記事を管理しています。記事自体も issue に直接記載する形式にしました。 issue の利用により進捗の管理が容易になった点はよかったのですが、その年のアドベントカレンダー運営の振り返りでは以下のような課題も上がりました。 レビューがやや難しい せっかくなので、GitLab の CI 機能をもっと活用したい そこで今年のアドベントカレンダーでは、 GitLab の MR 機能（マージリクエスト。GitHub の Pull Request に相当する機能）を利用してみることにしました。 MR であれば 行単位でレビューが書けるため、指摘箇所がわかりやすい 編集履歴を残すことができる CI を活用しやすい といった利点があります。 さらに、せっかく CI を使えるようになったので以前からやってみたいと思っていた誤字脱字の指摘、文章の構成の自動化にとりくんでみました！ その内容を本記事で紹介させてください。 できたもの 投稿された記事を校正し、MR にレビューコメントをしてくれる「赤ペン博士 bot」を作りました。 使用したライブラリの説明 textlint textlint は「linter」と言われるツールの一種で、記述されたプログラムや文章がルールに沿って書かれているかをチェックしてくれます。多くの linter がプログラミング言語を対象としてツールであるのに対して、textlint は自然言語を対象にしているため、文章の校正に利用できます。 textlint で適用するルールは様々なプラグインから自分で取捨選択でき、例えば以下のような項目をチェックできます。 文末が「。」で終わっているかどうか 日本語の誤用がされていないかどうか 必要な箇所にスペースが入れられているかどうか textlint の導入によりこれまで人力で指摘・修正していた文章の誤りを自動で検知することができるようになります。 Reviewdog Reviewdog は様々な linter と組み合わせて、GitHub や GitLab などのコードホスティングサービスに linter が指摘した内容をレビューコメントとして投稿してくれるツールです。これにより、GitLab に push された記事に対して、textlint を適用した結果を該当箇所にコメントできます。 余談ですが、ロゴが可愛いのも特徴です。 GitLab CI GitLab CI は GitLab が公式に提供している Continuous Integration（CI）ツールで、GitLab 上に push されたコードに対して、トリガーや実行内容を設定して処理を行うことができます。一般的なプロジェクトではテストやデプロイを自動化するために使われることが多いですが、今回は校正を自動化するために利用しました。 Reviewdog が MR にコメントするには GitLab でアクセストークンを発行する必要がありますが、Reviewdog 用の GitLab アカウントを新規で作成し、プライベートアクセストークンを発行することで実現しました。プロジェクト単位でアクセストークンを発行することもできますが、その場合アイコンを設定できないためレビューがややたんぱくになってしまうのが難点です。 上記のツールを組み合わせ、以下のような仕組みを作成しました。 MR が作成されたり更新されると自動で GitLab の CI が起動し、CI の中では文章に対して textlint で校正をかけ、その結果を Reviewdog が MR へのコメントとして通知してくれます。 各種設定について 次に、ツールを動かす設定をご紹介します。 package.json の設定 textlint は npm を使って導入できます。package.json を未作成のプロジェクトの場合、プロジェクトのルートディレクトリで npm init -y npm install --save-dev textlint とすることで、package.json の作成と textlint のインストールが行われます。textlint の拡張パッケージ（後述）についても同様に npm からインストールできます。 gitlab-ci.yml の設定 .gitlab-ci.yml ファイルをリポジトリに作成し、GitLab 側の設定をいくつかすることで CI 機能を使うことができます。もう少し詳しく知りたいという方は、よければ以下の記事をご覧ください。 GitLab CI/CD 導入の手引き（FORCIA CUBE） CI では使用するライブラリのインストールと、 textlint, Reviewdog の実行をしています。また、Reviewdog 実行用の API アクセストークンのキーは CI 設定の Variables に登録してあります。 image: alpine # CIで使用するdockerイメージの指定 reviewdog: allow_failure: true # CIに失敗してもMRをMerge可能なようにする設定 script: - apk add --update git - apk add --update npm - npm install # package.jsonに登録したtextlintのインストール # reviewdogのinstall # bin/ 以下に実行ファイルがインストールされます - wget -O - -q https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh | sh -s # textlintとreviewdogの実行 # *.md ファイルを対象にlinterを実行しています - npx textlint -f checkstyle *.md | bin/reviewdog -f=checkstyle -name="textlint" -reporter=gitlab-mr-discussion textlint のプラグイン textlint には様々なプラグインがあり、自分の好みのルールを追加することができます。今回利用したのは以下のプラグインになります。 textlint-rule-preset-ja-spacing 日本語におけるスペースの使い方のルール textlint-rule-preset-ja-technical-writing 日本語による技術文書向けのルール 技術書向けなのでブログにはふさわしくないルールも多く、適宜取捨選択して利用しています textlint-rule-preset-jtf-style 日本語用の標準的な textlint のルール郡 textlint-rule-prh 文章の表記ゆれを検出するためのルール 自分で辞書を作成して、検出対象を決めることができる これらのプラグインの細かなルールは .textlintrc.js にて設定することができます。 今回は以下のような設定で利用しています。 module.exports = { plugins: { "@textlint/markdown": { extensions: [".md"], // マークダウン用の拡張 }, }, rules: { // textlint-rule-prhの設定 prh: { rulePaths: ["./prh.yml"], }, // textlint-rule-preset-jtf-styleの設定 "preset-jtf-style": { "1.2.1.句点(。)と読点(、)": false, // 文中のピリオドとカンマを許容 "1.1.3.箇条書き": false, // 箇条書きの文末に句点(。)以外を許可 "2.1.8.算用数字": false, // 算用数字以外も許容する。1桁は全角でも入力できるように。 "2.2.1.ひらがなと漢字の使い分け": true, // ひらがなにしたほうが良い漢字をサジェスト "4.1.3.ピリオド(.)、カンマ(,)": false, // 文中のピリオドとカンマを許容 "4.3.1.丸かっこ（）": false, // 半角丸括弧を許容 "4.3.2.大かっこ［］": false, // 半角大括弧を許容 }, // textlint-rule-preset-ja-technical-writingの設定 "preset-ja-technical-writing": { "no-exclamation-question-mark": { allowFullWidthExclamation: true, allowFullWidthQuestion: true, }, "no-doubled-joshi": { strict: false, allow: ["か", "が", "に"], // これらの助詞は同一文中に多く登場しても許容 }, }, // textlint-rule-preset-ja-spacingの設定 "preset-ja-spacing": { "ja-space-around-code": { before: true, after: true, }, }, "ja-technical-writing/ja-no-mixed-period": { allowPeriodMarks: [":"], }, "ja-technical-writing/max-ten": { max: 5 }, // 文中の「、」の数は5個まで "ja-technical-writing/sentence-length": false, // 文の長さは指定なし "ja-technical-writing/ja-no-weak-phrase": false, // 弱い表現を許容 "ja-technical-writing/max-comma": false, // カンマの数は指定なし "ja-spacing/ja-space-around-code": false, // インラインコードの前後にスペースを入れなくてもよい }, }; phr.yml の設定 前述した textlint のプラグインの一種である textlint-rule-prh を用いることで、表現の揺れを統一することができます。 phr.yml に以下のようなルールを登録して、ライブラリ名の揺れなどを統一しました。 version: 1 rules: - expected: Docker pattern: docker specs: - from: docker to: Docker - expected: Ansible pattern: ansible - expected: Ansistrano pattern: ansistrano - expected: Kubernetes pattern: kubernetes - expected: React pattern: react - expected: Redux pattern: redux - expected: Next.js patterns: - next.js - Nextjs 以下のように揺れを指摘してくれます。 おわりに 今回の仕組みを導入したことにより、人力で指摘するのはハードルが高い内容も自動でレビューできるようになり、運営チームの負担を減らしつつ記事の質を高めることができるようになったと思います。 また個人的に嬉しかったこととしては、記事を書いてくださる方達も赤ペン博士によるレビューを面白がってくださったことです。煙たがられるかなとも思っていたので、楽しんでいただけたようで作った甲斐がありました。 それでは残りの記事もお楽しみに！

これは、[Qiita Advent Calendar 2021 GitLab](https://qiita.com/advent-calendar/2021/gitlab)の15日目の記事です。 はじめに こんにちは、フォルシアにて、旅行会社向けの web アプリケーションを開発しています、エンジニアの高橋です。普段のアプリ開発の業務のほかに技術広報も兼任しており、弊社で開催しているアドベントカレンダーの運営もお手伝いしています。 フォルシアではもともと、社内のイベントとしてアドベントカレンダーを始めましたが、2018 年からは弊社ブログ（FORCIA CUBE）にて外部の方向けに記

これは、 FORCIA Advent Calendar 2021 の14日目の記事です。 こんにちは。新卒2年目エンジニアの三浦です。 突然ですがみなさんは会社の同期のやっている仕事、知っていますか？ フォルシアでは、全く決まりや強制ではないのですがいつからか新卒エンジニアは代々同期同士の気軽な情報共有の場を設置して、コミュニケーションをとる習慣があります。 代によって頻度や形式など違いはありますが、私を含む新卒2年目(20期入社)の同期でも「20期エンジニアのつどい」と題して行っており(以下、これを単に「つどい」と呼びます)、個人的にはとてもよい取り組みだと感じています。 今回は、そんな「つどい」について私のおすすめポイントを含めてご紹介できればと思います。 「つどい」って具体的にどんなことやるの？ 形式としては 頻度は週1回45分 内容は技術寄りの情報共有 その回で話題を一つ提供するメインスピーカー もちろん、話したいネタがある人はいつでも好きなタイミングで話題提供してOK メインスピーカーはローテーションの持ち回り となってます。 情報共有というと少し硬い印象を受けるかもしれないですが、同期だけなのでとてもカジュアルな雰囲気でやっています。フォルシアではエンジニア全体の情報共有の場も別にありますが、そこで話すほどでない些細なレベルの話でも共有しています。 具体的な話題としては以下のような感じです。 仕事の内外で学んだTips共有 最近している仕事の内容共有 ある程度仕事に関係したお悩み相談 (たまに)雑談 最近ですと、「 CORS で詰まって、こう解決したよ」や「こんなふうにデータを取り出したくて、こんなSQLを書きました」といったことや、このアドベントカレンダーでも近日公開されるような「TypeScriptでこんな型パズルしてみました」という話などを共有しました。 また直接仕事と関連していない、興味で触ってみた技術の話なども共有しています。 やっていることはシンプルですが、社外で同じようなことをしているという話はあまり聞いたことがありません。おすすめできる点が3つあるので、順にご紹介します。 1. 幅広い学びがある 自分とは違うプロジェクト・チームにいる同期から、その中であった学びが提供されるのでかなり新鮮なことも多いです。自分の業務の中だけだと限られた範囲の技術ばかり触りがちになりますが、「つどい」があることで知る機会がなかった技術の話が聞けます。 技術だけではなく、業務の進め方やチームの運用方法などの面でも学びがあり、いい面を自分の業務に取り入れることもできます。 例えば、同期がTipsとして紹介していた「簡単なテキスト操作のためのワンライナーコマンド」であったり、「案件の見積もり作業に当たって注意したこと」などは今の自分の業務の中でも生きている学びでした。 2. メインスピーカーの持ち回りでメリハリが生まれる メインスピーカーを持ち回るのは結構重要なルールだと思っています。 ただのゆるゆる雑談ではなく、その週担当の、メインで話題を提供する人がいることで、提供者にとっては学びになることを探そうというモチベーションに繋がります。多少はプレッシャーにもなりますが、持ち回ることで二ヶ月に一回くらいの頻度となり、大した負担ではありません。 話題がある人はesaに簡単な資料を用意するので、共有する情報について提供者自身の中で整理でき、また共有することで人から質問がもらえるので、学びも深まります。 3. コミュニケーションが増える フォルシア内での新卒エンジニアの同期間の情報共有はコロナ以前から行われていましたが、特に今のリモートワーク前提のご時世では、コミュニケーションの機会として真価が発揮されているような気がします。対面でのちょっとした雑談や飲み会などの機会が激減している中、週に一回同期と話す習慣があるのはとても楽しいです。このおかげであまり会えなくても同期の仲が深められていると思っています。 また冒頭の質問のように、一緒に入った同期が今どんな仕事をしているか、なども自然に話せてお互いの頑張りが知れるのも良い点です。 時にはエンジニアだけでなく総合職の同期も参加し、総合職目線の話が共有されたりして新鮮でもあります。週一のとても気軽な同期会、ということでちょうど良いコミュニケーションだと思っています。 まとめ 直接は集まれない、あまり出社しないので雑談も生まれない、そんな中でも仕事の話と雑談の間のちょうど良い塩梅で学びがある、週に一回短時間の同期のコミュニケーションです。 昨年度の末には、1年目の仕事の振り返りをしてそれぞれ共有する会もありました。そんな感じで、気軽に内容をアレンジしても良さそうです。 社外の方が「つどい」ライクなものを実践される際の汎用的なポイントとしては 習慣化して定期的に行う会とする 内容は準備が負担になりすぎないレベルのものにする 気軽に質問してカジュアルな雰囲気を作っていく といったことを意識していただくのが良いかと思います。 みなさん、ぜひ取り入れてみてはいかがでしょうか。

こんにちは。新卒2年目エンジニアの三浦です。 突然ですがみなさんは会社の同期のやっている仕事、知っていますか？ フォルシアでは、全く決まりや強制ではないのですがいつからか新卒エンジニアは代々同期同士の気軽な情報共有の場を設置して、コミュニケーションをとる習慣があります。 代によって頻度や形式など違いはありますが、私を含む新卒2年目(20期入社)の同期でも「20期エンジニアのつどい」と題して行っており(以下、これを単に「つどい」と呼びます)、個人的にはとてもよい取り組みだと感じています。 今回は、そんな「つどい」について私のおすすめポイントを含めてご紹介できればと思います。 「つどい」

これは、 FORCIA Advent Calendar 2021 の13日目の記事です。 こんにちは。DXプラットフォーム部のエンジニアの伊藤（亜紀）です。 データクレンジングツールMasstery の開発を担当しています。 この記事のテーマは「ソースコードレビュー」です。突然ですが皆さん、ソースコードレビューはどのように実施されていますか？ 頭では重要とわかっているつもりだけれども、手を回せていない やってはいるけれど、時間をかけすぎている気がする やってはいるけれど、何をどこまでやれば十分か、悩ましい そんな方も多いのではないでしょうか。 私が担当しているMassteryの開発チームでは、ちょうど1年ほど前にソースコードレビューのやり方を変更しましたが、ソースコードレビューが開発速度の向上に寄与している実感を持てています。 今日はそのソースコードレビュー、題して「開発速度志向のソースコードレビュー」について、ご紹介させていただきます。 最適なソースコードレビューの進め方は、アプリ・チームの規模・求められるサービスレベル・リリース頻度等々によって異なりますが、何かしらヒントになる情報をご提供できたら幸いです。 Masstery開発チームでソースコードレビューを変更した経緯 Masstery開発チームでは、ちょうど1年ほど前、開発メンバーが2人から3～4人にふえたタイミングから、ソースコードレビューのやり方を変更しました。 それまでは2人目メンバー（アプリ習熟度が浅い）が開発したら、マージリクエスト（プルリクエスト）を作成して、1人目メンバー（アプリ習熟度が深い）に見てもらう、というやり方でしたが、新しいメンバーがふえたことで 必要なレビューの総量がふえた 大きめの機能追加が並行するようになり メンバー同士、最新のアプリ状態にキャッチアップが追いつかないことがふえた コンフリクト（ソースコード・仕様とも）がふえた という状況になったためです（※）。 とくに後者について、 キャッチアップ不足に基づきリリースに不具合が混入し、緊急対応が必要になる コンフリクトの解消に時間を取られる 他メンバーが実装した箇所に改修を加えたくなったときに、ソースコードの理解に時間がかかる といったことで、開発の進行に影響が出ていた点が懸念でした。 そこで、このタイミングで開発速度を向上させるためのソースコードレビューを考えました。 過去に所属していたチームのソースコードレビューのいいとこどりをしながら、Masstery開発チームにとって最適なやり方を検討しました。 ※参考：リリースは週1回で、開発メンバーごとに開発範囲を決めることはしていません。 基本的な考え方 具体的なやり方ついてお話する前に、まずは基本的な考え方についてピックアップしてご説明します。 開発メンバー全員参加のMTGでレビューする レビューは基本的に、開発メンバー全員参加のMTGで行います。Masstery開発チームでは毎週火曜と木曜の週2回、ソースコードレビューのMTGを設けています。週2回では足りない場合や多すぎる場合には、適宜調整しています。 正直なところ、定期開催・全員参加のMTGにするかどうかは悩んだポイントでした。個々人の開発時間を確保するために、できるだけMTGは減らしたいと考えていたためです。 ただ最終的に、全員がアプリの状況を把握するからこそのメリットの方が大きいと判断し、定期開催・全員参加にしました。 全員参加のメリットについては後ほどご説明します。 「全員がいち早く"概要理解"に達する」ことを目標に、実装者が口頭で説明をする 開発速度向上を目的としているので、レビューでまずめざすゴールは、いろいろ欲ばりたい気持ちを抑えて「全員が対応の概要を理解すること」としました。 ここで「対応の概要」というのは「なぜ・何を・どのように実装したか」です。 なぜ：対応の目的 何を：どの機能を追加or修正したか。ユーザや外部連携システムから見た変更点は何になるか どのように：ソースコードの変更要点。その設計思想 受け売りを含んでもよいので、とにかく全員が上記のポイントを抑えた状態をめざします。 そして、その状態にいち早く達することができるよう、レビューは 実装者が、ソースコードの差分をレビュアーに見せながら、対応概要を口頭で説明 レビュアーは、説明を聞いている途中で疑問があれば、その場で質問 という進め方をします。実装者自身が着目すべき差分をピックアップすること、そしてインタラクティブに進めることで、素早い理解につなげます。 「全員が対応の概要を理解」した後は、レビュアーから「このケースの動作確認はきちんとできている？」「こう書かないとメンテナンス性を損なうのでは？」といった、マージするために必要な質問・コメントを行います。 ただしあくまで「対応概要の説明を聞いたうえで気になった範囲」で行います。 このゴール設定は重要なポイントなのですが、その理由については後ほどご説明します。 極力その場でマージする。開発を止めない 「開発の効率をあげる」ことが一番の目的です。そのため、できる限りレビューの場でマージまでするように心がけます。 その場でマージすることが難しい場合も、「この点がクリアされれば、セルフマージしてOK」というように、マージ条件をレビュー中に明示するようにします。 もちろん、バグや、メンテナンス性を著しく損なうような変更をリリースしては問題なので、そのような場合は修正後のマージとします。 しかし開発速度が最優先であり、「たしかにそう書いた方がきれいだけど、今後の開発効率に大きく効いてこないのでは？」という場合はマージします。 特に不具合修正やユーザビリティ改善の場合、ユーザに早く快適に使ってもらえるようにすることが先決なので、その場はマージしたうえでリファクタリングは別のタスクに切り出すことも多いです。 具体的な運用 運用は以下のとおりです。 準備 実装者は、マージリクエスト（プルリクエスト）を作成する。 「機能の概要」「ソースコードの変更点」「動作確認内容」「特に見てもらいたい点」を簡単に記載します しっかり書くとそれだけで時間がかかってしまうので、「簡単に記載」がポイントです！ スムーズに説明するためのカンペ程度に書いています。 実装者はレビューMTG開始前までに、今日のMTGで見てほしいマージリクエスト（プルリクエスト）と、その説明所要時間を申告 特別な仕組みはなく、slackに書いています。 大きな対応でも、説明所要時間は最大10分程度におさまるようにします。 どうしても10分でおさまらない大作は、レビュー効率も悪くなりがちなので、マージリクエスト（プルリクエスト）を作成する段階で、レビュー単位が大きくなりすぎないよう気をつけます（大枠ができた段階で一度見てもらうなど）。 レビューMTG 30分のMTGで、チーム全員でレビューします。 申告されたマージリクエストのうち、対応期限などを考慮してその日見るものを相談・決定 実装者は、ソースコードの差分を見せながら、対応概要を説明 「なぜ・何を・どのように実装したか」「動作確認の内容」「特に見てもらいたい点」 レビュアーは、疑問があれば適宜質問 説明後、レビュアーから気になった点があればコメントする 問題なければその場でマージ 問題がある場合も、どうなったらマージ可能か、できるだけその場で明確にする メリット この進め方は開発速度を重視したものですが、開発速度以外にも以下のようなメリットがあります。 悩む時間がほとんどない 実装者が対応について口頭で説明し、インタラクティブに質問しながら進めるので、レビュアーが悩む時間が少なくて済みます。 マージリクエスト（プルリクエスト）に対応内容を丁寧に記載する方法は、記録がしっかり残る点はよいのですが、文章で説明している対応内容とソースコード変更点の対応づけに、地味に時間がかかるものです。 とくに、アプリ習熟度が浅いメンバーほど、ちょっとしたことで理解に躓きがちで、しかも1つ躓くとその先が理解できないことも多いです。 それを都度マージリクエスト（プルリクエスト）コメントで訊いていると、待ち時間を含めて理解までにかなり時間がかかってしまいましたが、インタラクティブに進めることでその問題は解消します。 さらに、MTGは時間の制約があるので、つい深入りして時間をたくさん使ってしまった、ということも防ぎやすいです。 アプリ固有知識の平準化が図れる 全員でレビューすることで、アプリの固有知識や設計思想を共有することができます。 そういった知識は、ドキュメントや概念図にまとめられているのが理想ではありますが、実際の開発現場では 変わらないと思っていた要件・前提・設計がどんどん変わり、ドキュメントの更新が追いつかない どうせすぐ書き換えることになるので、ドキュメントには大枠だけ書いておき、あとはソースコードを正とする 大きな変更が並行して進行する などといったことは日常茶飯事で、ドキュメントに落とし込みきれていない暗黙知というのはどうしても生じてしまうものです。 ですが、対応概要だけでもレビューしていれば「こういう設計になっているのでこう対応した」という理解を積み上げていくなかで、暗黙知をレビューの場で補完していくことができます。 さらに全員いると、アプリ固有知識への習熟度が高い人と低い人が必ず同席するので、「詳しくない人が調べる」のではなく「詳しい人が説明する」という方法で疑問を解決できるので、アプリ固有知識の平準化はさらに促進されます。 また、 全員が理解していれば、リリース後しばらくして不具合が発覚したときに、仮に実装者やその箇所に詳しい人が不在だったとしても、原因のアテがつけやすい 全員が最新の開発を把握していると、コンフリクト（ソース・仕様とも）に気が付きやすい というのもメリットです。 レビューが滞留しない 1～2人にレビューを割り当てる方式だと、レビュアーが忙しかったり割り当てられたことを見落としたりすると、そこでレビューが滞ってしまいます。 そこは「優先度をあげて、きちんとやりましょう」という話ではあるのですが、他ならぬ私も、レビュータスクが苦手な人間です（笑）。 たくさんタスクを持っているときに、差し込みのタスクが1つ飛んでくると、気づかぬうちにちょっとした心理的負担になってしまうのですよね。 多くのレビューは数分では完了しないので、完了するまでの間「やらねばやらねば」とレビュータスクがTODOリストと頭の中に存在し続けますし、緊急のものでなくとも相手を待たせると小さな罪悪感を感じてしまいます。 レビューを定期MTGにして、そこで全員の知見を結集して素早く疑問や懸念を解決し、マージしていくようにすれば、レビューが溜まりません。 もちろんMTGなので、毎度待ち時間のオフセットはつきますし固定の拘束時間にはなるのですが、それでもトータルで見ると快適になったと感じています。 レビュータスクが特定の人に集中しない レビューを全員でやると決めてしまうことで、特定の人（そのアプリに最も習熟している人）ばかりレビューすることを防げます。 時折「ここの実装は問題ないか、後でxxさんに詳しく見てもらった方がいいね」となることはありますが、本当にその人が入念に見るのが最適なものだけに限定することができます。 知識の平準化を図ることで、「対応内容の妥当性をチェックできる人」がふえていくので、そういった「入念な確認」も徐々に分散させていくことができます。 実はこれだけで品質担保にもかなり役立つ 開発速度向上を志向したソースコードレビューについてお話してきました。 レビューの第1のゴールはあくまで「全員が対応の概要を理解する」ことで、対応に問題がないかのチェックはあくまで「説明を聞いて気づいた範囲」で行うことを意外に感じられた方もいらっしゃるかもしれません。 このやり方ではバグを発見しきれず品質は担保が不十分になるのではとも感じられたかもしれません。 私は、これでも品質の担保にもかなり貢献していると感じています。それは、以下の理由からです。 （なお大前提として、バグはレビューだけで100%検知しようとするものではなく、テストやソースコードの質などで総力的に品質担保すべきものと考えています。） 口頭で説明すると問題点に気付きやすい これは個人的な経験則ですが、文字で説明するよりも口頭で話した方が問題点に気づきやすいと思います。 実装者は自身の対応内容を口頭でレビュアーに説明しますが、話している最中に実装者自身が問題点に気づくことがよくあります。 また口頭で説明すると、理解度・自信度合い・迷いなどが口調に如実に表れるので、問題点を検出するうえで重要な手がかりになります。 他メンバーの「視点」が入るだけでも問題発見効果がある これも経験則になってしまいますが、本当に致命的な不具合というのは 要件や仕様の理解不足 そんなことを考慮する必要があるとは思ってもみなかった そんなところに影響するとは思ってもみなかった というケースが多いです。ローカルなところで起こるというよりもグローバルなところで起きます。 こういったケースは、ソースコードやテストケースとにらめっこせずとも、「わかっている人」が見ればすぐに気付けます。 その点、異なる視点から「この観点には気をつけた？」というキャッチボールをたくさんできる進め方は効率的です。 もちろん、話した結果としてソースコードやテストケースを熟読する必要があると判断した場合は、熟読します。 さいごに いかがでしたでしょうか。 冒頭でもお伝えしたとおり、最適なソースコードレビューの進め方はアプリ・チームの規模・求められるサービスレベル・リリース頻度等々によって変わってきます。 とくに開発メンバーの人数がふえたらどうするかは悩ましい点ですが、今後も状況変化に合わせて試行錯誤と改良を加えていきたいと思います！

こんにちは。DXプラットフォーム部のエンジニアの伊藤（亜紀）です。 データクレンジングツールMassteryの開発を担当しています。 この記事のテーマは「ソースコードレビュー」です。突然ですが皆さん、ソースコードレビューはどのように実施されていますか？ 頭では重要とわかっているつもりだけれども、手を回せていない やってはいるけれど、時間をかけすぎている気がする やってはいるけれど、何をどこまでやれば十分か、悩ましい そんな方も多いのではないでしょうか。 私が担当しているMassteryの開発チームでは、ちょうど1年ほど前にソースコードレビューのやり方を変更しましたが、ソースコードレビ

これは、 FORCIA Advent Calendar 2021 の12日目の記事です。 はじめに 「CDN」という仕組みをご存知でしょうか。 インターネットを支える縁の下の力持ち的な存在ですが、実際に意識することは少ないかもしれません。 ここでは「CDN」がどのように動いているのか、digコマンドとcurlコマンドを使って理解してみようと思います。 CDNとは 「CDN」とは「content delivery network」の略称でCDN事業者のサーバを経由してコンテンツを配信する仕組みです。 ごく簡単に図で表すと以下のようなイメージになります。 CDNを使用しないで配信する場合： [ユーザ]----HTTP(S)---->[配信元サーバ] CDNを使用して配信する場合： [ユーザ]----HTTP(S)---->[CDN事業者のサーバ]----HTTP(S)---->[配信元サーバ] つまり、インターネットにアクセスした際に私たちがアクセスしているサーバは、Webサイトの運営者のサーバではなくCDN事業者のサーバであることもある、ということになります。少し意外かもしれません。 なぜ、このような構成がとられるのでしょうか。以下のようなメリットがあると言われています。 CDN事業者のサーバにコンテンツをキャッシュすることによって、高速な配信が期待できる 急激にトラフィックが増えた場合に、CDN事業者のサーバでトラフィックを吸収できるので、サービスがダウンしにくい ユーザの接続はCDN事業者のサーバに対して行われるため、配信元サーバが直接的な攻撃にさらされにくい ここで、以下のような疑問を持つ方もいるかもしれません。 「今どきのインターネット通信はほとんどがHTTPS通信で行われている。HTTPS通信はエンドツーエンドで暗号化されているため、CDN事業者のサーバでコンテンツをキャッシュすることなどできないのでは？」 「普通に」プロキシサーバーを立てるだけではその通りなのですが、一般的にCDNではHTTPS通信においてもキャッシュが利用可能です。 なぜなら、CDN事業者のサーバには配信元サーバと同じコモンネームのSSL/TLS証明書をインストールしてあるため、暗号化された通信の復号が可能だからです。 (逆に言えば、自身のサイトをCDN化する際にはCDN用に証明書を発行する必要があるということになります) [ユーザ]<=>[CDN事業者のサーバ]の通信はCDN事業者のサーバにインストールされた証明書によって暗号化され [CDN事業者のサーバ]<=>[配信元サーバ]の通信は配信元サーバにインストールされた証明書によって暗号化され それぞれ通信が行われている、ということになります。 アクセス先を確かめてみる では、Webサイトの運営者のサーバではなく、CDN事業者のサーバに接続されていることを確かめてみましょう。 アメリカのニュースサイト The New York Times は「Fastly」というCDN事業者によって配信されていますので、このサイトを例に見てみましょう。 弊社社屋からdigコマンドを実行すると以下のような結果が得られます。 $ dig www.nytimes.com <抜粋> www.nytimes.com. 381 IN CNAME www.prd.map.nytimes.com. www.prd.map.nytimes.com. 1 IN CNAME nytimes.map.fastly.net. nytimes.map.fastly.net. 30 IN A 151.101.229.164 「CNAME」というレコードが返却されていますが、これはCanonicalName(正規ホスト名)を指すものです。 つまりこの応答を読み解くと www.nytimes.com の正規ホスト名は www.prd.map.nytimes.com なので引き直してください www.prd.map.nytimes.com 正規ホスト名は nytimes.map.fastly.net なので引き直してください nytimes.map.fastly.net のIPアドレスは 151.101.229.164 です。 ということになります。 www.nytimes.com の最終的なCNAME先が nytimes.map.fastly.net つまりFastly社(CDN事業者)のドメイン名になっており、Fastly社が管理する権威DNSサーバによってIPアドレスが解決されていることが分かります。 また解決されたIPアドレス 151.101.229.164 をwhoisコマンドで引いてみると 以下のようにFastly社所有のものであることが分かります。 $ whois 151.101.229.164 <抜粋> NetRange: 151.101.0.0 - 151.101.255.255 Organization: Fastly (SKYCA-3) 以上のことから、ブラウザに https://www.nytimes.com/ と入力した際の通信相手は、「The New York Times」社のサーバではなく、「Fastly」社のサーバであることが分かります。 どのように配信サーバを割り当てているか CDN事業者はインターネット上に配信サーバを多数設置していると言われています。 Fastly社でも配信サーバを 世界各地 に配置しています。(日本国内にもあります) では、どのようにして多数あるサーバの中からアクセスさせるサーバを割り当てているのでしょうか？ 先ほど解決されたIPアドレス 151.101.229.164 にpingを打ってみると数msで返ってくることから、サーバは日本国内にあることが推測されます。 $ ping 151.101.229.164 PING 151.101.229.164 (151.101.229.164) 56(84) bytes of data. 64 bytes from 151.101.229.164: icmp_seq=1 ttl=55 time=3.38 ms 64 bytes from 151.101.229.164: icmp_seq=2 ttl=55 time=3.20 ms <以下略> ではDNSサーバを変えて名前解決をしてみます。 ここでは日本から遠そうなロシアの検索サービスである yandex社のDNSサーバ である 77.88.8.8 を使ってみます。 $ dig www.nytimes.com @77.88.8.8 <抜粋> www.nytimes.com. 500 IN CNAME www.prd.map.nytimes.com. www.prd.map.nytimes.com. 120 IN CNAME nytimes.map.fastly.net. nytimes.map.fastly.net. 30 IN A 151.101.245.164 151.101.245.164 に解決されました。(先ほどは 151.101.229.164 だったので、第3オクテットのみが異なっています) pingを打ってみると200ms以上かかっており、日本からはネットワーク的に遠く(おそらくロシア付近)にあることが推測されます。 $ ping 151.101.245.164 PING 151.101.245.164 (151.101.245.164) 56(84) bytes of data. 64 bytes from 151.101.245.164: icmp_seq=1 ttl=51 time=269 ms 64 bytes from 151.101.245.164: icmp_seq=2 ttl=51 time=269 ms <以下略> つまり、同じホスト名を問い合わせているのにもかかわらず、問い合わせ元のDNSサーバによって解決するIPアドレスを変えていることが分かります。 [日本国内のクライアント]--DNSクエリ-->[日本のDNSサーバ]--DNSクエリ-->[CDN事業者の権威DNS] =>日本からのアクセスとみなして日本国内のサーバのIPアドレスを返却 [日本国内のクライアント]--DNSクエリ-->[ロシアのDNSサーバ]--DNSクエリ-->[CDN事業者の権威DNS] =>ロシアからのアクセスとみなしてロシア付近のサーバのIPアドレスを返却 このようにして、クライアントに対してネットワーク的に近い位置のサーバを割り当てていることが推測できます。 ECS(EDNS Client Subnet)について ここまで読み進めてくださった賢明な読者の方なら、以下の疑問を持つかもしれません。 「あの有名なGoogle Public DNSである8.8.8.8に問い合わせたらどうなるの？」 問い合わせ元のDNSサーバのIPアドレスのみを元にして返却するIPアドレスを制御する、という仕組みには限界があり 実際に、過去にはこのようなPublicDNSを使用した場合、 不適切なサーバが割り当てられる問題 があったと言われています。 ただし現在は ECS(EDNS Client Subnet) という仕組みで解決されています。 これは、DNSキャッシュサーバがDNS権威サーバに問い合わせる際に、DNSキャッシュサーバに問い合わせをしたクライアントのIPアドレス情報も伝達してしまう、という仕組みになります。 簡単に図で表すと以下のようになります。 [クライアント]--DNSクエリ(1)-->[PublicDNSサーバ]--DNSクエリ(2)-->[CDN事業者の権威DNS] ※この「DNSクエリ(2)」内に「DNSクエリ(1)」の発信元クライアントのIPアドレス情報が含まれている CDN事業者の権威DNSはクライアントのIPアドレス情報を元に最適なサーバのIPアドレスを返却するため、ECSに対応しているDNSサーバであれば現在このような問題は発生しないと言えます。 (逆に言えば前述のyandex社のDNSサーバはECSに対応していないものと考えられます) curlでアクセスしてみる では実際にWebサイトにアクセスしてみましょう。 CDN事業者によってデバッグ用コマンドのようなものが用意してあり、キャッシュにヒットしたかどうかなどが分かるようになっています。 Fastlyの場合 を例にして、curlコマンドで Fastly-Debug:1 をリクエストヘッダに付与して「The New York Times」のトップページに何度かアクセスしてみます。 $ curl -s --head -H "Fastly-Debug:1" https://www.nytimes.com/ -w "time_total:%{time_total}\n" | grep -e 'x-cache:' -e 'time_total:' x-cache: MISS, MISS time_total:1.036584 $ curl -s --head -H "Fastly-Debug:1" https://www.nytimes.com/ -w "time_total:%{time_total}\n" | grep -e 'x-cache:' -e 'time_total:' x-cache: MISS, HIT time_total:0.032943 x-cache レスポンスヘッダでキャッシュにヒットしたかを確認できるので比較すると 最初のアクセスではキャッシュがない( MISS )ためレスポンスに1秒以上かかってるのに対し、 その後のアクセスではキャッシュにヒット( HIT )し0.03秒程度でレスポンスされていることが分かります。 「The New York Times」の配信元サーバはおそらくアメリカ国内にあるものと思われますが、キャッシュにヒットしない場合はアメリカ国内のサーバと通信するためレスポンスに時間がかかっているのに対し、キャッシュにヒットした場合は日本国内のサーバからレスポンスされるため非常に高速にコンテンツが取得できています。 まとめ 以上のことから分かったことをまとめてみます。 私たちが普段アクセスしているサーバは、Webサイト運営者のサーバではなくCDN事業者のサーバであることもある CDN事業者のサーバかどうか、どのCDN事業者を使用しているかはdigコマンドで分かる CDN事業者のサーバは世界各地にあり、最適なサーバが割り当てられるようになっている サーバの割り当てはCDN事業者の権威DNSにより問い合わせ元のIPアドレスを元に行われている CDN事業者のサーバのキャッシュからコンテンツが返却される場合は非常に高速である CDNは目に見えないものなので普段意識することもあまりないと思いますが、このような仕組みでインターネットが動いているというを知っておくと何かの役に立つかもしれません。(立たないかもしれません)

はじめに 「CDN」という仕組みをご存知でしょうか。 インターネットを支える縁の下の力持ち的な存在ですが、実際に意識することは少ないかもしれません。 ここでは「CDN」がどのように動いているのか、digコマンドとcurlコマンドを使って理解してみようと思います。 CDNとは 「CDN」とは「content delivery network」の略称でCDN事業者のサーバを経由してコンテンツを配信する仕組みです。 ごく簡単に図で表すと以下のようなイメージになります。 CDNを使用しないで配信する場合： [ユーザ]----HTTP(S)---->[配信元サーバ] CDNを使用し

これは、 FORCIA Advent Calendar 2021 の11日目の記事です。 こんにちは！ 旅行プラットフォーム部エンジニアの恒川です。 今年10月に入社し、毎日JavaScriptを書いています。 この記事では、JavaScriptのsymbolから始めて、「名前衝突」をキーワードに、それを利用したLispプログラムまで紹介したいと思います。 JavaScriptのsymbol symbol はES2015で追加されたプリミティブです。プリミティブとはメソッドを持たないデータのことで、 42 、 "Brendan Eich" などの仲間です。 symbol型のデータは関数 Symbol() の戻り値として生成できます。 console . log ( typeof Symbol ()) // symbol symbolに対してどんな計算ができるのでしょうか。 console . log ( Symbol ()) // Symbol() console . log ( Symbol (). toString ()) // 'Symbol()' ' Tell me your name, ' + Symbol () // Uncaught TypeError: Cannot convert a Symbol value to a string ほとんど何もできません。 symbolに対してstringと + の演算はできませんし、 .toString() を使っても 'Symbol()' が返ってきます。 恥ずかしがり屋さんなsymbolですが、 Symbol() で返されるデータはユニークであるという特徴をもっています。 console . log ( Symbol () === Symbol ()) // false つまり、 Symbol() は呼び出される度にこの世界でまだ一度も作られたことのないことを保証するsymbolを作るということです。 名前衝突を回避するJavaScriptプログラム(標準オブジェクトの拡張) symbolの名前が被らないという性質を使って、「名前衝突」を防ぐことができます。 例として、以下のようなStringオブジェクトに star() メソッドを追加してみます。 String . prototype . star = function () { return " * " . repeat ( 10 ) + this + " * " . repeat ( 10 )} console . log ( " Tsunekawa " . star ()) //**********Tsunekawa********** star() メソッドを使うと画面が華やかになって良いと思います。しかし、このように標準のオブジェクトにメソッドを追加するコードは非常に危険であると知られています。なぜなら、もし将来JavaScriptに star という名前の違う動作をするメソッドが追加された場合に既存のコードが動かなくなってしまうからです。また、 star を別の仕様で実装しているライブラリを使用した場合も同様です。 名前が競合することによってプログラムが意図しない動作をする状態を名前衝突と呼びます。非常にまずい問題ですが、以下のようにsymbolを使用することで名前衝突を避けることが可能です。 const star = Symbol (); String . prototype [ star ] = function () { return " * " . repeat ( 10 ) + this + " * " . repeat ( 10 )}; exports . star = star ; var s = require ( ' ./star.js ' ); console . log ( " Tsunekawa " [ s . star ]()); //**********Tsunekawa********** star.js ではsymbolを使ってStringオブジェクトに star() メソッドを追加し、そのsymbolをexportしています。 main.js ではexportされたsymbolを使って star() メソッドにアクセスしています。 star.js で作成されたsymbolは世界の誰とも被らない名前が付いているため、今後どんな拡張があったとしてもこのコードは動作します。この「名前衝突を回避することで互換性を維持したまま拡張をする」ことこそがsymbolの真骨頂と言えると思います。 Lispのsymbol JavaScriptのsymbolは名前衝突を回避するという、ある意味特別な目的のために導入されたデータ型でした。しかし、古い言語の中には基本的なデータの１つとしてsymbolを使っている言語がいくつか存在します。ここからはそんなsymbolと仲良しの言語、Lispを紹介していきます。 Lispは1950年代後半に登場した古いプログラミング言語です。1950年代がどれぐらい昔かというと、トランジスタが発明されたのがちょうどこの頃ですので、コンピューターも真空管からトランジスタへという時代でした。 そんな大先輩Lispの最も基本的なデータ型はsymbolでした。 coffee 、 *McCarthy* 、 + はLispのsymbolです。 Lispではしょっちゅう以下のようにsymbolを並べたリストを使って計算をします。 ( car ( cdr ( cons 'hoge ( cons 'fuga ( cons 'bar ( )))))) ; FUGA Lispの方言の１つであるCommon Lispには、ユニークな名前のsymbolを返す関数 gensym があります。 ( eq 'hoge 'hoge ) ; T ( eq ( gensym ) ( gensym )) ; NIL １つ目のプログラムでは、２つのhogeというsymbolを比較し、真であることを表す T というsymbolが返っていますが、２つ目のプログラムでは、 (gensym) の返す２つのsymbolを比較し、偽であることを表す NIL というsymbolが返っています。 (gensym) もJavaScriptの Symbol() と同様に名前衝突を回避する目的で使用されます。 Lispでは頻繁にマクロと呼ばれるプログラムを変更するプログラムを書きますが、マクロ定義の中で gensym を使うことによってマクロ展開後のプログラム中で名前が衝突することを回避できます。 以下では OnLisp から for マクロを紹介します。 ( for ( x 1 5 ) ( princ x )) ; 12345 for マクロは一般的な手続き型言語の for のようにループを記述できる便利なマクロです。 for マクロはCommon Lisp組み込みの do マクロをラップすることで以下のように定義できます。 ( defmacro for (( var start stop ) & body body ) ( let (( gstop ( gensym ))) ` ( do (( , var , start ( 1 + , var )) ( , gstop , stop )) (( > , var , gstop )) ,@ body ))) for マクロの引数は (var start stop) と body です。 var にはループ中で使用するループ変数、 start にはループ変数の初期値、 stop にはループ終了判定の際にループ変数と比較する値を渡します。 body にはループ中で繰り返し実行されるプログラムを渡します。 for マクロの展開後のプログラムは (do ...) の部分ですが、その前にローカル変数 gstop に (gensym) の返すユニークなsymbolを束縛しているところがポイントです。 この for マクロのみを展開した結果のプログラムを macroexpand-1 を使って見てみます。 ( macroexpand-1 ' ( for ( x 1 5 ) ( princ x ))) ; (DO ((X 1 (1+ X)) (G2951 5)) ((> X G2951)) (PRINC X)) for マクロに渡した引数が、 do マクロにきちんと渡っていることが確認できます。 G2951 という名前のsymbolは (gensym) が返したsymbolです。今回ユーザが for マクロに渡したループ変数としてのsymbolは x でしたが、どんな名前のsymbolが渡されたとしても名前衝突は発生しません。 名前衝突を利用したLispプログラム(アナフォリックマクロ) ここまで、JavaScriptの Symbol() とCommon Lispの (gensym) が名前衝突の回避に使用される例を紹介しました。 最後に名前衝突を利用したおもしろいCommon Lispプログラムを、こちらも OnLisp から紹介したいと思います。 次の例はある計算結果が nil でなければ、それを関数 foo に渡すというプログラムです。 ( let (( result ( big-long-calculation ))) ( if result ( foo result ))) このプログラムが次のように記述できれば楽ちんです。 ( aif ( big-long-calculation ) ( foo it )) 計算結果が勝手に it というsymbolに束縛され、then節で参照できています。 この便利な aif マクロは次のように定義できます。 ( defmacro aif ( test-form then-form & optional else-form ) ` ( let (( it , test-form )) ( if it , then-form , else-form ))) aif の第1引数のtest節の計算結果を it に束縛し、ifでテストしています。マクロ展開後のプログラムを見てみると意図した通りのプログラムに変換されていることが確認できます。 ( macroexpand-1 ' ( aif ( big-long-calculation ) ( foo it ))) ; (LET ((IT (BIG-LONG-CALCULATION))) (IF IT (FOO IT) NIL)) マクロに渡すthen節中で it という名前のsymbolを使用することによって、展開後のプログラムで名前を衝突させています。このように名前を衝突させて、symbolに代名詞的な働きをさせるマクロはアナフォリックマクロと呼ばれます。 おわりに 最後まで読んでいただき、ありがとうございました！ この記事ではJavaScriptの Symbol() や、Common Lispの (gensym) が返すユニークな名前を持つsymbolを使って、名前衝突を回避するプログラムを紹介しました。また、意図的に名前を衝突させるプログラムも紹介しました。古い言語の機能や工夫が、新しい言語に取り入れられる様子を見る度に、「昔コレ考えた人すごいなぁ」と思います。 私はこの記事を執筆するにあたって久しぶりにLispを書きました。楽しかったので今週末も少し書いてみようかなと思っているところです。

これは、FORCIA Advent Calendar 2021の11日目の記事です。 こんにちは！ 旅行プラットフォーム部エンジニアの恒川です。 今年10月に入社し、毎日JavaScriptを書いています。 この記事では、JavaScriptのsymbolから始めて、「名前衝突」をキーワードに、それを利用したLispプログラムまで紹介したいと思います。 JavaScriptのsymbol symbolはES2015で追加されたプリミティブです。プリミティブとはメソッドを持たないデータのことで、42、"Brendan Eich"などの仲間です。 symbol型のデータは関数Symbol