nodejs

Node.js 21の新機能要約 Node.js v21が安定版としてリリース fetchとWebStreams APIが安定化 組み込みWebSocketクライアントの追加 ESモジュールのサポート強化 パフォーマンスの向上と依存関係の更新 Stable Fetch API Status Fetch APIが安定版に昇格 Node.js v17.5.0で導入、v18.xからv20.xではフラグ不要だが実験的扱いが続く Web Streams API Is Stable WebStreams APIが安定化 Fetch APIの実装はAbortControllerインターフェースとWeb Streams APIに依存 Node.js v15.0.0とv16.5.0で追加され、v21で安定化 A Built-in WebSocket Client Node.jsに組み込みWebSocketクライアントが追加 WHATWGによって標準化されたWebSocket globalの導入 ES Modules Improvements 新しい--experimental-default-typeフラグでESモジュールとCommonJSのデフォルト挙動を変更可能 Test Runner Improvements Node.js v20で安定化したネイティブテストランナーのさらなる強化 グロブ表現による複数のテストファイルマッチングのサポート Module Customization Improvements モジュールカスタマイズの簡素化 globalPreloadフックをregister APIとinitializeフックに置き換え llhttp v9.1.2 Strict Mode Enforcement llhttp v9.1.2で厳格モードがデフォルト設定に コードの信頼性とセキュリティ向上のための変更 Performance Improvements to Key APIs 主要APIのパフォーマンス改善 Streams APIの最適化やレスポンスのuncorking改善など V8 Upgraded to v11....

Firebase Cloud Messagingで firebase-admin - npm 使って Multicastすると、複数のデバイスに対して一度にプッシュ通知を送信することができるけど、 どのTokenが失敗したのかわからないのでは？と思い調べた So to confirm, the response array from sendMulticast is in the same order as the tokens that were passed in, allowing you to match up the indexes of any errors. https://stackoverflow.com/questions/70008515/firebase-cloud-messaging-multicast-error-messaging-registration-token-not-regist ここにある通り、 multicast 時のトークン配列と、 応答される BatchResponse の配列順序は一致する らしいので、どのトークンが失敗したのかはわかるみたい

FCM Push用秘密鍵を SecretManager に登録する FCM 秘密鍵を取得 FireBaseへログイン プロジェクトを選択 プロジェクトの設定 サービスアカウント FireBase Admin SDK > 新しい秘密鍵の生成 FCM 秘密鍵を SecretManager に登録 取得した秘密鍵を ./fcm.json で配置する 以下コマンドで登録 aws secretsmanager put-secret-value --secret-id ${SECRET_ID} --secret-string "$(cat<./fcm.json)" 使う SecretManager を扱い易いようにクラス化する 'use strict'; const { SecretsManagerClient, GetSecretValueCommand } = require('@aws-sdk/client-secrets-manager'); const clazz = class Sm { constructor() { this.client = new SecretsManagerClient({ region: process.env.REGION }); // REGION で環境変数へRegionを設定している前提 } async get(key) { const command = new GetSecretValueCommand({ SecretId: key }); const res = await this....

customParseFormat 拡張した dayjs で TZ 環境変数 と指定するフォーマットで罠にハマる Z 指定したUTC日付はフォーマットで渡してパースしてもUTC扱いされると思ってた。 フォーマット指定では Z があろうが TZ 環境変数に依存する模様 いやいやいや。。。 フォーマット指定時に意図しない結果になる TZ=UTC dayjs('2022-12-17T11:43:29.277Z', 'YYYY-MM-DD[T]HH:mm:ss.SSS[Z]').toDate() // => 2022-12-17T11:43:29.277Z TZ=Asia/Tokyo TZ=Asia/Tokyoの場合は -9 時間されインスタンス化される!!!!!!(いやいやいや！！！) dayjs('2022-12-17T11:43:29.277Z', 'YYYY-MM-DD[T]HH:mm:ss.SSS[Z]').toDate() // => 2022-12-17T02:43:29.277Z フォーマットを指定しなければ問題ない TZ=UTC dayjs('2022-12-17T11:43:29.277Z').toDate() // => 2022-12-17T11:43:29.277Z TZ=Asia/Tokyo dayjs('2022-12-17T11:43:29.277Z').toDate() // => 2022-12-17T11:43:29.277Z

ブログシステムを Ghost へ乗り換えてみたが、 Publish 日付とブログの日付が合わない、といった事象が発生していた。（ブログ再構築の際に順番をいしきしていなかった為、 publish 日付でソートされると、あまり宜しくない結果になった。） 仕方ない、、、と放置していたが、この度簡単なスクリプトを書いて対応した。 node のインストールに若干手こずったが、まぁ、Javascript、簡単！ 概要 Ghost 管理メニューより Export した Jsonファイルを用意する。 今回は、ブログタイトルに、記事日付があったので、それを利用した。 title より取り出した 日付で、 publish_at 項目を更新。 本来の日付でソートできた！！ vim convertMyGhostExport.js var srcPath = "/home/ghost/Desktop/your-domain.ghost.2015-10-07.json"; var dstPath = "/home/ghost/Desktop/your-domain.ghost.2015-10-07_dst.json"; var json = require(srcPath); json.db[0].data.posts.every(function(post,index,ar){ var dateStr = post.title.substr(0, 8); if (!dateStr.match(/\d{8}/)) { // title の頭８文字が数値出ない場合は対象外 return true; } if (post.status != "published") { // 公開していない場合は対象外 return true; } var yyyy = dateStr.substr(0,4); var mm = dateStr.substr(4,2) - 1; var dd = dateStr....