本文 Cloud Runでは sm://<project_id>/<secret_name> の形式で環境変数をセットして起動すれば自動的にSecretManagerから秘密情報を取得して展開してくれます。(言語不問) 同様の機能がCloud Functionsにもあったらいいなと思ったんですが、Go言語版のみしかサポートされていなかったので、Node.js版を作成しました。 const { SecretManagerServiceClient } = require('@google-cloud/secret-manager'); async function resolveSecret(element) { const client = new SecretManagerServiceClient(); const [, , projectId, secretName] = element.split('/'); const name = `projects/${projectId}/secrets/${secretName}/versions/latest`; const [version] = await client.accessSecretVersion({ name: name, }); return version.payload.data.toString(); } async function substituteSecrets() { const resolved = await Promise.all( Object.entries(process.env) .filter(([_, element]) => element.startsWith('sm://')) .map(async ([key, element]) => [key, await resolveSecret(element)]) ); for (const [key, element] of resolved) { process.env[key] = element; } } 参考 https://github.com/GoogleCloudPlatform/berglas https://www.npmjs.com/package/@google-cloud/secret-manager
nodist で node のバージョン切り替えをしているとはまりました。 Windows環境です。 そのときのメモです。 解決策は、ありませんというか、nodist 使うのやめます。 nodist で node を切り替えていました。 > nodist -v 0.9.1 > nodist (x64) 11.13.0 (global: 11.13.0) > 15.13.0 この状態で、次のコマンドがエラーになりました。 > npx create-react-app my-app npm ERR! cb.apply is not a function npm ERR! A complete log of this run can be found in: npm ERR! C:\Users\<UserName>\AppData\Roaming\npm-cache\_logs\2021-07-25T01_47_20_805Z-debug.log Install for [ 'create-react-app@latest' ] failed with code 1 ネットでいろいろさぐって、Roaming内のキャッシュを消せやなんだかんだとあったのですがいろいろ試しても解決せず。 なんで変なことしてないのに npx create-react-app が動かないんだと探っていたら、nodist を使っていたことを思い出しました。 nodist で node 11.13.0 に切り替えると正常動作しました。 node の切り替えは純粋なインストーラーとかでやったほうがいいと思いました。 以上です。
Hapiはserver.injectというメソッドでサーバーをシミュレートすることができます。その中で「あるAPIをテストしたいが、authの結果をモックして返したい」という場面があると思います。その場合は const res = await server.inject({ method: "POST", url: `${baseUrl}/users`, auth: { // authを指定 strategy: "my-strategy", credentials: {}, artifacts: { name: "Admin User", admin: true, }, }, }); こんな感じでauthを指定するとそのテストで欲しいデータをrequest.authから取ることができました。
本記事 本記事は初学者を対象とした記事です。 npmとかyarnをざっくり説明しています。 npmとyarnとは どちらもNode.jsで動作するパッケージマネージャのこと。 それぞれ、Node Package ManagerとYet-Resource-Negotiatorの略称。 Node.jsとは サーバーサイドで動かすことができるJavaScript。 ※奇数が開発版で、偶数が安定板。 JavaScriptにおけるパッケージマネージャ-とは Nodeの開発に伴いフレームワークが開発されるなど、飛躍的な進歩を遂げることとなるが、同時に必要なものをインストールするのに工夫が必要となった。 （フレームワークを構成するのにプログラムのインストールが１０００個とかあると大変！もちろんバージョン管理もしないといけない！） 筆者は何も考えずにインストールしていたのですが、npm listを開発していたアプリで実行して軽く引きました（恥ずかしい話ですが、、、）。 npm Node.jsと同時にインストールされている。 2009年にNode.jsが開発されたのち、2010年1月にリリースされている。 yarnって？ 2016年にリリースされたnpmと互換性のある新しいパッケージマネージャー。 新しいぶん、使いやすい。以下のような特徴がある。 1.npmと互換性がある。 2.インストールが速い。 3.セキュリティが高い。 4.強固なバージョン管理が可能。 yarnでパッケージのインストールをした後、yarn.lockというファイルが生成される。中にはインストールしたパッケージが使用している別のパッケージのバージョンが明確に書き込まれる。 yarn initコマンドを実行すると、package.jasonファイル（プロジェクトの設定ファイル）が生成される(npm initも同じ)。 参考文献 最後に 書いてて気づいたのですが、既に多くの方が書かれている内容でした。 自身の知識定着も兼ねて書いたのですが、わかりにくい場合は参考文献にURLを貼っておりますので、そちらの記事を読まれることをお勧めします。 お付き合いいただきありがとうございました。
概要 Line bot上でじゃんけんをできるようにしました。早い話が下記動画です。 アジェンダ 実装 リッチメニューの作成 デプロイ・実行 備考 1. 実装 ディレクトリ構成 ~/develop/study/linebot $ tree ./jankenbot -I node_modules ./jankenbot ├── janken.js ├── package.json ├── serverless.yml └── yarn.lock serverless.yml service: jankenbot frameworkVersion: '2' provider: name: aws runtime: nodejs12.x lambdaHashingVersion: 20201221 stage: dev region: ap-northeast-1 plugins: - serverless-offline functions: lineWebhook: handler: janken.webhook events: - http: path: janken/webhook method: post janken.js 'use strict'; // パッケージのインストール const line = require('@line/bot-sdk'); // LINEアクセストークンの設定 const config = { channelAccessToken: 'アクセストークン', channelSecret: 'シークレットキー', }; // インスタンス化 const client = new line.Client(config); exports.webhook = async (event, context) => { /* リクエストボディ*/ const body = JSON.parse(event.body) /* Lineのevent情報*/ const response = body.events[0] /* ユーザの出した手を取得*/ const userHand = response.message.text /* コンピュータの出した手を取得 */ const cpHand = getCpHand() let message = hantei(userHand, cpHand) /* メッセージ送信のために必要な情報 */ const replyToken = response.replyToken console.log('replyToken:' + replyToken) const post = { type: 'text', text: message, } try { await client.replyMessage(replyToken, post) } catch (err) { console.log(err) } }; /** * コンピュータの手を決定します。 * @return {string} cpHand - コンピュータの手 */ function getCpHand(){ /**ランダム数値を取得(範囲：0~2) */ let num = Math.floor(Math.random() * 3) let cpHand = '' if(num ==0){ cpHand = 'グー' }else if(num ==1){ cpHand = 'チョキ' }else{ cpHand = 'パー' } return cpHand } /** * じゃんけんの勝ち負けを判定します。 * @param {string} userHand - ユーザの出した手 * @param {string} cpHand - コンピュータの出した手 * @return {string} - message 判定結果 */ //TODO ロジックが美しくない。数学的に処理する方法を後日の記事にする。 function hantei(userHand, cpHand){ let message = '' if(userHand == 'グー'){ if(cpHand == 'グー'){ message = 'あいこです。(あなた：'+userHand + '、CP：'+ cpHand +')' }else if(cpHand == 'チョキ'){ message = 'あなたの勝ちです。(あなた：'+userHand + '、CP：'+ cpHand +')' }else{ message = 'あなたの負けです。(あなた：'+userHand + '、CP：'+ cpHand +')' } }else if(userHand == 'チョキ'){ if(cpHand == 'チョキ'){ message = 'あいこです。(あなた：'+userHand + '、CP：'+ cpHand +')' }else if(cpHand == 'パー'){ message = 'あなたの勝ちです。(あなた：'+userHand + '、CP：'+ cpHand +')' }else{ message = 'あなたの負けです。(あなた：'+userHand + '、CP：'+ cpHand +')' } }else{ if(cpHand == 'パー'){ message = 'あいこです。(あなた：'+userHand + '、CP：'+ cpHand +')' }else if(cpHand == 'グー'){ message = 'あなたの勝ちです。(あなた：'+userHand + '、CP：'+ cpHand +')' }else{ message = 'あなたの負けです。(あなた：'+userHand + '、CP：'+ cpHand +')' } } return message } 2. リッチメニューの作成 Linebotでリッチメニューを作成します。えっ、リッチメニューって何って思った人はリンクを参考にしてね。 まぁ、簡単に言うと、下記画像を作成します。 作り方は省略しますが、下記内容が作れていればOKです。 3 デプロイ・実行 デプロイ ~/develop/study/linebot/jankenbot $ serverless deploy Serverless: Packaging service... Serverless: Excluding development dependencies... Serverless: Uploading CloudFormation file to S3... Serverless: Uploading artifacts... Serverless: Uploading service jankenbot.zip file to S3 (4.53 MB)... Serverless: Validating template... Serverless: Updating Stack... Serverless: Checking Stack update progress... ......................... Serverless: Stack update finished... Service Information service: jankenbot stage: dev region: ap-northeast-1 stack: jankenbot-dev resources: 12 api keys: None endpoints: POST - https://URL/dev/janken/webhook functions: lineWebhook: jankenbot-dev-lineWebhook layers: None Serverless: Removing old service artifacts from S3... webhook用のURLをLine botに追記すれば稼動します！！ 4. 備考 じゃんけんの判定ロジックが美しくないですよね。次回の記事では数学的に処理したロジックを紹介します。
TypeScriptの勉強のために小さなnpmパッケージを作成・公開しました。本記事は、パッケージを作成・公開するときに学んだこと・つまづいたことをまとめた内容になります。 本記事で言いたいことは、TypeScriptの勉強法としてnpmパッケージ作成は適しており、公開するだけであればその敷居は思ったより低くないということです。 作ったもの commitlintという、コミットメッセージがコミット規約に従っているのかどうかをチェックするnpmツールがあります。 ESlintのように、プラグイン・ルールを組み合わせて拡張することで、プロジェクトに合ったコミット規約をカスタマイズできます。 今回は、コミットメッセージがIssue駆動開発のコミット命名規則に則っているか？をチェックするという、とても小さなプラグインを作りました。コミットメッセージ本文に#issue番号があるかどうかをチェックするだけのルールで、ほぼ自分用に作ったものではありますが、もしよければ使ってくださると幸いです。 作った動機 自分は普段Goでバックエンド開発をしているのですが、直近でTypeScriptの知識が必要になりました。 そこで、プログラミングTypeScript等の技術書を読んで基本的な読み書きができるようになったのですが、勉強を進めていくうちに何か一つ作ってみるかとなり、React×TypeScriptでのアプリ開発を考えました。しかし、筆者はReactに精通しているわけでもないため、ハマった時に何が原因なのかが混乱してしまい、学習効果が薄くなるだろうと思いました。 というわけで、自分は TypeScript単体の勉強としてコードを書きたかった node_moduleの勉強もしたかった ので、簡単なnpmパッケージを作ることにしました。 どのようにして作っていったか 以下の順番で進めていきました。 npmパッケージの作成・公開フローを知る commitlintのプラグインの開発ルールを知る npmパッケージ公開用のTypeScriptのビルド設定を知る 他のcommitlintプラグインのコードを真似ながら、開発していく また、開発を進める際は以下の資料を参考にしました。 npmパッケージの作り方 TypeScriptのビルド設定周り の[TypeScriptのビルドと実行]の章 あとは、@commitlintの型を使うため@commitlint/typesのソースコードを読んだり、npmで他のcommitlintのプラグインのソースコードを探して読んだりしました。 学べたこと 実際にTypeScriptで書いたコードは、ちょっとしたスクリプト程度の量だったので、TypeScript完全に理解した！というより、JavaScript・TypeScriptのエコシステムについて学んだことが多かったです。 TypeScriptのビルド周りの設定 TypeScriptはバイナリではなく、JavaScriptのソースコードをビルドします。そのため、どのプラットフォームで動くJavaScriptを生成するか？他の開発者のためにソースマップや型定義を生成するか？等を決める必要があり、それらの設定はtsconfig.jsonで細かく指定ができます。 業務では、他の開発者の方が設定してくれているので、今回位置から設定することでTypeScriptのビルド設定を知る良い機会になりました。 また、「export ？ module.exports？どっちがどっちで、何がちがうのか？」といったCommonJsとNode.jsの記述の違いについて理解しておかないといけないため、開発前のタイミングで他の方が書かれたJavaScriptの変遷について説明した記事などで知識を整理できたのも良かったです。 TypeScriptの型定義 今回作成したcommitlintプラグインのソースコードでは、@commitlintの型を使用しています。その際に@commitlintのソースコードを読んだのですが、ジェネリクスの使い方などは非常に参考になりました。 保守性・拡張性の高いOSSのコードを読むことは、TypeScript初心者にとってとても良い勉強方法だったのではないかと思います。 npmパッケージの公開の仕方 npmパッケージはインストールして使ったことは何回もありますが、公開したことはありませんでした。開発前は設定が色々必要なのかな？と思っていたのですが、npmパッケージ開発の方法について解説している記事が多く、そもそもnpmパッケージの公開が簡単だったこともあるため敷居は低かったです。 つまづいたポイント 開発に必要なツールの設定 eslintやprettier、jestの設定につまづきました。TypeScriptの開発をするために、どのパッケージをインストールしたり、設定を追加すればよいのかを把握するのに時間をかけてしまいました。よくわからないまま他のプロジェクトを真似て突っ込むのではなく、ドキュメントを確認しながら一つづつ入れていけば良かったです。 個人の感想なのですが、Goと比較すると、あちらは言語に標準でフォーマッタやテストツールが付属しており、Go用のVSCode拡張を入れれば動くため、こちらは諸々の設定が面倒だなと感じました（単に自分に知識が足りないことや慣れの問題もありますが）。 また、設定ファイルは.jsでもymlでもjsonでもなんでもござれという点には面食らいました。 動作確認方法 yarnやnpmには、linkというローカルの開発中のnpmパッケージに対してシンボリックリンクを貼り、手元で動作確認ができる仕組みがあります。 誠に恥ずかしながら、開発中の自分はこの仕組みを知りませんでした。「テストに通っているからこれでええやろ!」と一通り単体テストを行いつつ、パッケージとして組み込んだ際の動作はスクリプトをそのままcommitlintに組み込んだりして確認していました。 そのため、実際の動作確認はnpmに公開してから行っていました。今振り返るととんでもないことです。普通に考えると何かしら動作確認ができる仕組みはあるはずなのですが、自分は気づきませんでした。npmほどのプラットフォームであれば、必ず開発ツールは充実しているはずなので、焦らずうまく検索ワードを変えて根気よく調べられれば良かったです。 おわりに npmパッケージをTypeScriptで書くことによって、コードの書き方だけでなく巨大なJavaScriptのエコシステムについてもある程度学べる機会となりました。 ある程度入門的な内容（リテラルの書き方など）を勉強した後に、何かサラッと書いてみる分には、npmパッケージ開発はうってつけだと思います。
