しきゆらの投稿 - Crieit

【JS】テキストを一定の文字数で切り捨てる

2024-04-27T13:37:04+09:00

こんにちは、しきゆらです。
今回は、SNSなどで時々見るような「一定数を超えたテキストを切り捨てる」処理を作ったのでメモしておきます。

結論: 以下のコードでいい感じに端折れる

const truncate = (str, max) => {
  if (str.length < max) return str;

  return `${str.slice(0, max - 1)}…`;
};

const truncateStringExceptURL = (str, max) => {
  if (!str) return "";

  // URLの正規表現
  const urlRegexp = /https?:\/\/\S+/g;
  // マッチしたURLリスト
  const urls = [];
  //　文字列からURLにマークして除外する
  const markedString = str.replace(urlRegexp, (matchStr) => {
    urls.push(matchStr);

    return `>${urls.length - 1}<`;
  });

  // テキストを切り捨てる
  const truncatedString = truncate(markedString, max);

  // マークしたURL箇所の正規表現
  const replaceUrlRegexp = />\d+ {
    const urlIndex = parseInt(matchStr.replace(/>|



細かく見ていきます。

テキストを切り捨てる

単純に一定の文字数で切り捨てるだけであれば、以下だけで実現できます。

なお、ここでは文字数をString.lengthで簡易的に取得していますが、文字コード等によっては意図しない数になりそうです。

正確な文字数に関しては、以下が参考になると思います。

JavaScript: 文字数を正確にカウントするには？ #JavaScript - Qiita https://qiita.com/suin/items/3da4fb016728c024eaca

const truncate = (str, max) => {
  if (str.length < max) return str;

  return `${str.slice(0, max - 1)}…`;
};


String.prototype.slice() - JavaScript | MDN https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/String/slice

この中で、URLが入っている場合はURLの途中で切り捨てられてしまいます。

それが問題にならなければよいのですが、私の場合はURLはそのまま出した方が便利だったのでURL以外の部分で切り捨てるようにしてみた結果が、最初のコードでした。

処理の流れとしては、以下の通り。


文字列に含まれるURLを特定のマーカに置換
マーカに置換した文字列を指定された文字数に切り捨て
切り捨てられた文字列にあるURLマーカをURLに戻す


それぞれ見てみます。

文字列に含まれるURLを特定のマーカに置換

該当部分を抜き出します。

const truncateStringExceptURL = (str, max) => {
 ...
  // URLの正規表現
  const urlRegexp = /https?:\/\/\S+/g;
  // マッチしたURLリスト
  const urls = [];
  //　文字列からURLにマークして除外する
  const markedString = str.replace(urlRegexp, (matchStr) => {
    urls.push(matchStr);

    return `>${urls.length - 1}<`;
  });
  ...
}


URLを表現する正規表現を定義し、文字列内にあれば配列に格納しつつマーカに保管しています。

String.prototype.replace()は第1引数に検知するパターン、第2引数に置換するものを渡しますが、第2引数は文字列以外にも関数も渡すことができます。

String.prototype.replace() - JavaScript | MDN https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/String/replace

なお、この処理自体は過去記載した「YAMLに環境変数を埋め込む」や「YAMLにローカル変数を埋め込む」と同じ発想です。

【Ruby】YAMLに環境変数を埋め込む | しきゆらの備忘録 https://shikiyura.com/2021/03/embed_env_value_in_yaml/

【Ruby】YAMLにローカル変数を埋め込む | しきゆらの備忘録 https://shikiyura.com/2021/10/embed_local_variable_in_yaml/

マーカに置換した文字列を指定された文字数に切り捨て

該当部分を抜き出します。

const truncate = (str, max) => {
  if (str.length < max) return str;

  return `${str.slice(0, max - 1)}…`;
};

const truncateStringExceptURL = (str, max) => {
  ...
  // テキストを切り捨てる
  const truncatedString = truncate(markedString, max);
  ...
}


URLをマーカに置換した文字列に対して、指定数以上の文字列を切り捨てる処理をかませます。

単純にString.prototype.slice()で先頭から最大数-1までの文字列を作り、末尾に…を入れてます。

String.prototype.slice() - JavaScript | MDN https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/String/slice

切り捨てられた文字列にあるURLマーカをURLに戻す

該当箇所を抜き出します。

const truncateStringExceptURL = (str, max) => {
 ...
 // マークしたURL箇所の正規表現
  const replaceUrlRegexp = />\d+ {
    const urlIndex = parseInt(matchStr.replace(/>|


ここでは、マーカを正規表現で表現し、切り捨てた文字列からマーカ部分をURLに置換しています。

処理的にはマーカに置き換える処理の反対なので特に複雑なことはないかと。

マーカ部分をもう少し綺麗に書けないかな、と思っていますがいい方法思いついてません。

URLをマーカに置換する部分と、マーカからURLに置換するが分かれているので何とかしたい気持ち。

まとめ

今回は、SNSなどでよく見るような一定数を超えた文字列を端折る処理を書いたのでメモしました。

改めて全体を記載しておきます。

const truncate = (str, max) => {
  if (str.length < max) return str;

  return `${str.slice(0, max - 1)}…`;
};

const truncateStringExceptURL = (str, max) => {
  if (!str) return "";

  // URLの正規表現
  const urlRegexp = /https?:\/\/\S+/g;
  // マッチしたURLリスト
  const urls = [];
  //　文字列からURLにマークして除外する
  const markedString = str.replace(urlRegexp, (matchStr) => {
    urls.push(matchStr);

    return `>${urls.length - 1}<`;
  });

  // テキストを切り捨てる
  const truncatedString = truncate(markedString, max);

  // マークしたURL箇所の正規表現
  const replaceUrlRegexp = />\d+ {
    const urlIndex = parseInt(matchStr.replace(/>|


今回は、ここまで。

おわり



【JS】Google Apps Scriptのコードをviteでバンドルする
2024-04-16T23:38:37+09:00
こんにちは、しきゆらです。

今回は、Google Apps Script(GAS)をViteでビルドしてclaspでプッシュする環境を作っていきます。

・・・久々のプログラム関連の記事な気がする。

個人的に、GASのコードをローカルで書き、JSのバンドラー？ビルダー？を使ってビルドしてclaspでアップロードする、というのがGASを書く上でのお作法だと思っています。

claspに関しては、こちらをご覧ください。

GitHub - google/clasp: 🔗 Command Line Apps Script Projects https://github.com/google/clasp

ビルドツールも様々あります。

Webpackやparcel、esbuildなどいろいろあるうえに、時代によって流行り廃りが速いのであまり追い切れてません。

ビルドツールについてはいかがいろいろまとまっててよさそう。

JavaScriptビルドツールの整理 各ツールの機能と依存関係

Native ESM 時代のフロントエンドビルドツールの動向

また、過去のツールの流行り廃りは以下あたりが参考になるかと。

State of JavaScript

ということで、いろいろあるわけですが

今回は、tauriでちょっと使って動作が速かったviteを使ってGASをビルドする環境を作ってみようと思います。

Vite | 次世代フロントエンドツール

Tauriを触ったときの記事はこの辺をご覧ください。

【Rust】Tauriで簡易的なアプリを作ってみる

今回、調べてみるとviteを使ってGASを書く記事はHTMLを作ってWebアプリとしての環境構築ばかりでした。

欲しいのはJSやTSをビルドするだけの環境です。

色々調べているとviteの裏側にあるRollupのプラグインでGAS向けのものがあったのでこれを使ってみます。

環境構築

適当なフォルダで以下のツールをインストール。

ここではyarn(v4.1.1)を使ってインストールしていますが、他のツールを使っている場合も同じような感じかと思うので読み替えていただければと。

yarn add clasp vite rollup-plugin-google-apps-script

それぞれのリポジトリをいかにおいておきます。

GitHub - google/clasp: 🔗 Command Line Apps Script Projects

GitHub - vitejs/vite: Next generation frontend tooling. It's fast!

GitHub - mato533/rollup-plugin-gas: Rollup plugin for Google Apps Script. This plugin supports local development of applications that run on Google Apps Script.

vite/rollupの設定

viteは設定ファイルが必要です。

しかし、必要なものは以下に参考としてあるので、これをもとにちょっと手直しします。

GitHub - mato533/rollup-plugin-gas: Rollup plugin for Google Apps Script. This plugin supports local development of applications that run on Google Apps Script.

// vite.config.js
import { defineConfig } from "vite";
import rollupPluginGas from "rollup-plugin-google-apps-script";
import path from "path";

export default defineConfig({
  plugins: [rollupPluginGas()],
  build: {
    rollupOptions: {
      input: "src/main.js",
      output: {
        dir: "dist",
        entryFileNames: "main.js",
      },
    },
    minify: false, // trueにすると関数名が消えるのでfalse必須
  },
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "./src"),
    },
  },
});


ここではsrc/main.jsというファイルを作り、これをdist/main.jsへビルドする形を作っていきます。

GASのコードを書く

では、src/main.jsへ適当なコードを書きます。

単一ファイルだけでなく、せっかくなので分割してimportする形で書いてみます。

// src/main.js
import parts from "./parts";

const greet = () => {
  Logger.log("hello");
};

global.greet = greet;

global.parts = parts;


// src/parts.js
export default parts = () => {
  Logger.log("parts");
};


では、ビルドします。

ビルドは以下のコマンドでできます。

yarn run vite build

ビルドすると以下のようなコードが吐き出されるはず。

// dist/main.js
var global = this;
function greet() {
}
;
function parts() {
}
;
(function(factory) {
  typeof define === "function" && define.amd ? define(factory) : factory();
})(function() {
  "use strict";
  const parts$1 = parts = () => {
    Logger.log("parts");
  };
  const greet2 = () => {
    Logger.log("hello");
  };
  global.greet = greet2;
  global.parts = parts$1;
});


では、コードをGASへアップしましょう。

Google Apps Scriptへプッシュする

まずは、claspからログインしましょう。

以下のコマンドを実行すると、ブラウザが立ち上がるので、画面に従ってGoogleアカウントへログインしましょう。

clasp login

ログイン後、以下のコマンドでApps Scriptを作成します。 なお、すでに作成済みの場合は場合はcloneでもよいです。

> clasp create
? Create which script? standalon
reated new standalone script: 
Warning: files in subfolder are not accounted for unless you set a '/path/to/project/.claspignore' file.
Cloned 1 file.
└─ /path/to/project/appsscript.json


clasp createを実行するとどんなスクリプトか聞かれるので、今回はstandaloneを指定してます。

完了すると、URLが表示されます。

これを開くと、作成されたApps Scriptへアクセスできます。

また、clasp openでも開けます。

そして、appsscript.json、.clasp.jsonの2ファイルが生成されます。

.clasp.jsonファイルを開き、rootDirをvite.config.jsで設定したdistフォルダを指定します。

// .clasp.json
{
  "scriptId":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "rootDir":"/path/to/project/dist"
}

そして、appsscript.jsonファイルをdistフォルダへコピーします。

では、clasp pushでコードをApps Scriptへアップロードします。

clasp push

Apps Scriptを開くと、以下のようにコードが反映されているはずです。

では、関数名を指定して実行ボタンを押して動作確認しましょう。



greetを実行すると以下のように表示されるはずです。



はい、これにてviteでGASを書くための環境ができました。

まとめ

今回はローカルでGASを書くためviteでビルドする環境を作ってみました。

viteは裏側がrollupであり、プラグインもrollupのものが使えるようなので、プラグインを見てから判断してもよいかもしれません。

プラグイン | Vite https://ja.vitejs.dev/plugins/

今回は、ここまで。

おわり


【GAS】処理時間の制限を回避する
2023-12-17T10:50:09+09:00
こんにちは、しきゆらです。

急な出社が続いてあまり記事を書けていない今日この頃です。

今回は、以前投稿したGASでファイル一覧を取得するコードを載せましたが、実際の環境で処理回したら処理時間の制限に引っかかったので、回避するように直したのでその旨をメモしておきます。

前回の記事はこちら。

【GAS】Googleドライブにあるフォルダ・ファイルの一覧を取得する | しきゆらの備忘録 https://shikiyura.com/2023/11/how_to_get_file_list_in_google_drive/

改めて、GASの制限については以下を参照いただければと思います。

Google サービスの割り当て  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/guides/services/quotas?hl=ja#current_limitations

上記を見ると、スクリプトの制限としては１回の処理で6分までとなっています。 今回は、ここを回避していきます。

回避の方針

処理時間の制限としては、処理時間が一定時間を超えたらそこでいったん処理を止める、というだけ。

ただし、それだけだと処理しきれなかった部分が出てくるので、そこもケアしてあげましょう。

ざっくり手順としては以下の通り。


定期的に処理時間の確認し、一定時間を超えていたら処理を止める
処理途中のデータを保存する
処理を続きから実行するためのトリガーを定義する
一時停止した場合に前回の処理から再開する


それぞれ見ていきましょう。

なお、スクリプトのよって内容が変わると思いますが、ここでの例として前回のファイル・フォルダの一覧を取得する、というものに対してコードを書いていきます。

【GAS】Googleドライブにあるフォルダ・ファイルの一覧を取得する | しきゆらの備忘録 https://shikiyura.com/2023/11/how_to_get_file_list_in_google_drive/

ファイル・フォルダ一覧を取得するコードはこんな感じ。

function allFiles(){
  const folderId= "xxxxxxxxxx";
  const targetDir = DriveApp.getFolderById(folderId);
  const files = []; // ファイルオブジェクトを保持する配列
  const subFolders = [targetDir.getFolders()];

for(let i = 0; i < subFolders.length; i++) {
    const subFolder = subFolders[i];
    while(subFolder.hasNext()) {
      const folder = subFolder.next();
      subFolders.push(folder.getFolders());
      folders.push(...allFilesBy(folder));
    }
  }
  return files;
}

function allFilesBy(folder) {
  const files = []; // 対象となるフォルダにあるファイルオブジェクトを保持する配列
  const fileIterator = folder.getFiles();
  while(fileIterator.hasNext()) {
    files.push(fileIterator.next());
  }
  return files;
}


処理時間を回避するコード

処理時間の確認

処理時間を取得する機能はなさそうなので、単純に実行タイミングでDateオブジェクトを生成しておき、定期的に現在時刻との差分を求める形で簡易的に確認します。

// 処理の開始時点の日付・時刻を取得する

const startDate = new Date();
...


後は、定期的に処理の中でstartDateと現在時刻との差分を求めて処理時間を計算しましょう。

Dateオブジェクトの差分だったり、Date.getTime()を使っても同じように取得できます。 なお、値はミリ秒なので注意が必要です。

...
// ミリ秒で計測する場合
const processingMilliSec = (new Date() - startDate);
// 秒に直す場合
const processingSec = (new Date() - startDate) / 1000;
...


Date.prototype.getTime() - JavaScript | MDN https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Date/getTime

雑に関数にしておきます。 一定時間(ここでは300秒(= 5分)が経過したら処理を止めるようにしています。

function hoge() {
  // 処理の開始時点の日付・時刻を取得する
  const startDate = new Date();
  // いろいろな処理
  if (limitCheck(startDate)) return ;
}

function limitCheck(startDate: Date): boolean => {
  const processingSec = (new Date().getTime() - startDate.getTime()) / 1000;

  return processingSec >= 300; // 処理時間が300秒より大きい場合はtrueを返す
}


これにて、一定時間が経過した時点で処理を止める機能は完了です。

処理途中のデータを保存する

処理を止めるだけでは、次に実行したときに再開することはできません。 処理を止めたときに、次回実行時に処理途中から再開できるように

前述の通り、前回のファイル・フォルダ一覧を取得するコードを例として書いていきます。 前回の記事はこちら。

【GAS】Googleドライブにあるフォルダ・ファイルの一覧を取得する | しきゆらの備忘録 https://shikiyura.com/2023/11/how_to_get_file_list_in_google_drive/

データを保持する先は、以前に紹介したPropertiesServiceを使います。 PropertiesServiceに関しては、過去記事を書いているのでこちらもご覧ください。

【GAS】パスワードやトークンをコードに直書きしない方法 | しきゆらの備忘録 https://shikiyura.com/2021/07/how_to_use_properties_service_at_gas/

ファイル・フォルダの一覧を取得する場合、保持しなければいけないのは主に以下の3点ですね。


取得したファイル・フォルダのリスト
処理途中のファイル・フォルダイテレータ
参照予定のフォルダリスト


この3点の中で、最初の「取得したファイル・フォルダのリスト」については、おそらく取得した後で最終的にはスプレッドシートにまとめたりするはずなので、あえてPropertiesServiceに置いておかなくてもよいかもしれません。

一方で、「処理途中のファイル・フォルダイテレータ」や「参照予定のフォルダリスト」は処理途中で終了しなければいけない場合は保持しておかなければ続きから再開ができません。

ということで、この２点を保持する形を作っていきます。

イメージ図を置いておきます。

赤フォルダ配下にあるフォルダを取得するとき、getFolders()で青フォルダたちFolderIteratorとして取得できます。



青フォルダたちをFolderIteratorで取得している間に下図の線の位置で時間切れとなった場合、残り2つのフォルダは次回に回さないといけません。

合わせて、青フォルダ1の配下にある紫フォルダたちを取得するFolderIteratorも取得済みなので、こいつらも次回処理するときに見る必要がありますよね。



ということで上記3点のうち、青フォルダのFolderIteratorが「処理途中のファイル・フォルダイテレータ」、紫フォルダのFolderIteratorが「参照予定のフォルダリスト」となります。

では、それぞれの保持の仕方を見ていきます。

イテレータの保持

FolderIterator、FileIteratorのどちらもgetContinuationToken()メソッドが定義されており、イテレータ処理で時間がかかる場合に途中から再開することができるようになっています。

再開するには、DriveAppクラスに定義されているcontinueFolderIterator、continueFileIteratorにトークンを渡せばよい。

// トークンの取得
const iteratorToken = fileIterator.getContinuationToken();

// イテレータの再開
const resumeIterator = DriveApp.continueFileIterator(iteratorToken);


Class FolderIterator  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/reference/drive/folder-iterator?hl=ja#getContinuationToken()

Class FileIterator  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/reference/drive/file-iterator?hl=ja#getContinuationToken()

このトークンをPropertiesServiceなどで保持しておけば再開できますね。

参照予定のフォルダリストの保持

前述の通り、フォルダやファイル一覧についてはPropertiesServiceを使って保持します。 なお、参照予定のフォルダ一覧はFolderIteratorが複数ある形なので、これらも上記の通りトークンに変換して保持します。

const subFolders = []; // 参照予定のFolderIteratorリストを保持する配列
...

// スクリプトプロパティを取得
const scriptProperty = PropertiesService.getScriptProperties();
// 参照予定のFolderIteratorをトークンに変換する
const subFolderTokens = subFolders.map(subFolder => subFolder.getContinuationToken());
// 参照予定のリストをJSONに変換して保持
scriptProperty.setProperty("folders", JSON.stringify(subFolderTokens));


処理途中のイテレータも同じくgetContinuationTokenメソッドでトークンを取得できるので 取得しつつsubFoldersの先頭に置いておけば再開できそうですね。

ここまでで、一時停止のためのデータ保持が完了です。

処理の続きを実行するトリガーを定義する

GASにはトリガーという機能があり、特定の時間やタイミングなどになったら処理を始める、ということを指定できます。

トリガークラスについてはこの辺を参照ください。

トリガーの作成はScriptAppのnewTrigger()で作成できます。

Class ScriptApp  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/reference/script/script-app?hl=ja#getProjectTriggers()

トリガー作成時に、トリガー起動時に呼び出す関数名を文字列で指定します。 ここでは、トリガーとして1分後に起動するトリガーを作成します。

ScriptApp.newTrigger(functionName).timeBased().after(1000 * 60).create();


newTrigger()が返してくるのはTriggerBuilderクラスになっています。 詳しくはこちら。

Class TriggerBuilder  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/reference/script/trigger-builder?hl=ja

timeBased()はトリガーの種類として時間を基準として動くタイプとして指定しています。 after()でトリガーが起動する時間をミリ秒で指定しています。 create()で指定したトリガーを作っているだけ。見ればわかる感じですね。

一時停止した場合に前回の処理から再開する

前回の処理がある場合は、前回の処理から再開してあげる必要があります。

先ほどPropertiesServiceに保持したデータですが、ここから取得してできるかどうかで判別したり、関数の引数の有無で判別したり、方法はいくつかありそうですがここではPropertiesServiceにデータがあるかどうかで判別してみます。

// スクリプトプロパティを取得
const scriptProperty = PropertiesService.getScriptProperties();
// 前回の処理からの続きとなるデータを取得
const resumeData = scriptProperty.getProperty("folders");

if(resumeData === null) {
  // 前回のデータがないので、ターゲットとなるフォルダを取得
} else {
  // 前回のデータがあるので、再開する
}


再開する場合は、トークンを使ってイテレータの続きを取得します。 上記サンプルのelse部分は以下のような感じになります。

const tokenJson = JSON.parse(resumeData);
const subFolders = tokenJson.map(token => DriveApp.continueFolderIterator(token));


あとは、このトークンから復元したイテレータをひとつづつ取り出して処理を進めればよいですね。

まとめてコードを載せると以下のような感じ。

// 処理時間の制限を超えたかどうかのフラグ
let limitFlag = false;

function allFiles(){
  const functionName = "allFiles";
  const startDate = new Date();
  let subFolders = []; // 配下にあるサブフォルダを保持する配列
  let files = [];

// 中断データを取得する
  const resume = getResume(functionName);
  if (resume === null) {
    // 中断データがない場合は、初期フォルダから処理を開始する
    const folderId= "xxxxxxxxxx";
    const targetDir = DriveApp.getFolderById(folderId);
    subFolders.push(targetDir.getFolders());
    files.push(...Array.from(allFilesBy(targetDir, startDate)));
  } else {
    // 中断データがある場合は、トークンからFolderIteratorに変換する
    const tokensJson = JSON.parse(resume);
    subFolders = tokensJson.map(token => DriveApp.continueFolderIterator(token));
  }

for(let i = 0; i < subFolders.length; i++) {
    const subFolder = subFolders[i];
    while(subFolder.hasNext()) {
      const folder = subFolder.next();
      subFolders.push(folder.getFolders());
      files.push(...allFilesBy(folder));
      if(limitFlag || checkLimit(startDate)) break;
    }

    // 一定の処理時間を超えた場合、処理途中のFolderIteratorをトークンに変換して保存する
    if(limitFlag || checkLimit(startDate)){
      const tokens = [subFolder.getContinuationToken()];
      const subFolderTokens = subFolders.map(subFolder => subFolder.getContinuationToken());
      setResume(functionName, JSON.stringify(tokens.concat(subFolderTokens)));
            break;
    }
  }
    // 今回処理した結果を返す
  return files;
}

function allFilesBy(folder) {
  const files = []; // 対象となるフォルダにあるファイルオブジェクトを保持する配列
  const fileIterator = folder.getFiles();
  while(fileIterator.hasNext()) {
    files.push(fileIterator.next());
  }
  return files;
}

function checkLimit(startDate) {
  const processingSec = (new Date().getTime() - startDate.getTime()) / 1000;
  limitFlag = processingSec >= 300
  return limitFlag;
}

// 中断データを取得する
function getResume(functionName) {
  const scriptProperty = PropertiesService.getScriptProperties();
  const properties = scriptProperty.getProperty(functionName);
  scriptProperty.deleteProperty(functionName);

  return properties;
}

// 中断データを保持し、トリガーを設定する
function setResume(functionName, data) {
  const scriptProperty = PropertiesService.getScriptProperties();
  scriptProperty.setProperty(functionName, data);

  setTrigger(functionName);
}

// トリガーを設定する
function setTrigger(functionName) {
  let triggers = ScriptApp.getProjectTriggers();
  for(let trigger of triggers) {
    if(trigger.getHandlerFunction() === functionName){
      ScriptApp.deleteTrigger(trigger);
    }
  }
  ScriptApp.newTrigger(functionName).timeBased().after(1000 * 60).create();
}


これで、処理時間の制限に引っかかるような長時間の処理が必要な場合、これを回避して処理させることができるようになりました。

処理時間の制限があるのでGASを使うのはきびしいな、というような場合に参考にしていただければ幸いです。

まとめ

今回は、GASの処理時間の制限を回避するため、以下の項目を組み合わせて回避してみました。


処理時間の計測
処理途中のデータをPropertiesServiceへ保存
処理再開のためのトリガー設定
前回の処理途中からの再開


私の場合は、とあるフォルダ配下にあるファイルたちのオーナー一覧を取得してほしい、というお題が来たので上記のようなコードを書いていました。 RubyなどからAPI経由でデータ取得するよりも、GAS上で書く方がシンプルでしたが、ざっと書いたところ処理時間の制限に阻まれたのでリファレンス等を読みつつ変更した結果が今回の時期の内容になります。

GASでコードを書いた方がシンプルだが、処理にどの程度時間がかかるかわからない というような場合でもGASを使って処理させることができるようになるので、参考になればうれしいです。

今回は、ここまで。

おわり


【GAS】Googleドライブにあるフォルダ・ファイルの一覧を取得する
2023-11-04T21:30:36+09:00
こんにちは、しきゆらです。

今回は、GASでGoogleドライブにあるファイル・フォルダの一覧を取得する方法をメモしておきます。

ファイル・フォルダの一覧を取得するコード

すべてのフォルダを取得する

すべてのフォルダを取得する場合、以下だけです。

const folders = DriveApp.getFolders();


DriverApp.getFolders()でGoogleドライブにあるフォルダのイテレータを取得できます。

ドライブ内にあるすべてのファイルが欲しければ、このイテレータ内でファイル一覧を取得していけば可能ですね。

Class DriveApp  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/reference/drive/drive-app?hl=ja#getfolders

なお、Folderクラスにも直下にあるフォルダ一覧を取得できるgetFolders()メソッドが生えているので、同じように使えます。

Class Folder  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/reference/drive/folder?hl=ja#getfolders

フォルダ直下にあるファイル一覧を取得する

上記のようなFolderIteratorからFolderクラスのインスタンスを取得します。

Folderクラスには、直下にあるファイルのイテレータを取得するメソッドがあるのでこれを使います。

const folder = folders.next(); // FolderIteratorからFolderオブジェクトを取得
const fileIterator = folder.getFiles();

const files = []; // ファイルオブジェクトを格納する配列
while(fileIterator.hasNext()) {
  files.push(fileIterator.next());
}


Class Folder  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/reference/drive/folder?hl=ja#getfiles

これらを組み合わせれば、特定のフォルダ配下のすべてのファイル一覧を取得することができますね。 やってみましょう。

特定のフォルダ配下にあるすべてのファイルを取得する

ターゲットとなるフォルダを取得する

まずは、GASからターゲットとなるフォルダを取得します。

// https://drive.google.com/drive/u/0/folders/xxxxxxのxxxxxxx部分
const folderId= "xxxxxxxxxx"; 
const targetDir = DriveApp.getFolderById(folderId); 


targetDirはGASのFolderクラスのインスタンスが入っています。

Folderクラスについては以下を参照。

Class Folder  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/reference/drive/folder?hl=ja

フォルダ一覧を取得する

前述の通り、Folderクラスには配下にあるフォルダ一覧を取得するメソッドが定義されているのでそれを使います。

const folderIterator = targetDir.getFolders(); // Folderのイテレータオブジェクトが返ってくる
while (folderIterator.hasNext()) { // 参照していないFolderがあればループする
  folders.push(folderIterator.next()); // .next()でFolderを取得
}


FolderIteratorクラスは以下を参照。

よくあるイテレータで、hasNext()で次の要素があるかどうかを確認しつつ、次の要素があればnext()で取得する形です。

Class FolderIterator  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/reference/drive/folder-iterator?hl=ja

ただし、ここで取得できるのはtargetDir直下にあるフォルダのみです。

targetDir配下すべてを取得するにはちょっと工夫してあげる必要がります。

const subFolders = [targetDir.getFolders()];
for(let i = 0; i < subFolders.length; i++) {
  const subFolder = subFolders[i];
  while(subFolder.hasNext()) {
    const folder = subFolder.next();
    subFolder.push(folder.getFolders()); // フォルダ一覧を取得し、次に参照する
  }
}


配列に破壊的に追加しつつforでループ処理するので、だいぶお行儀がよくない印象ですがいい方法が思いつきませんでした。

forEachを使うと、追加された要素を参照してくれなかったのでforで回しています。

ファイルの一覧を取得するコードの全体像はこんな感じ。

最終的にはfilesの配列にファイルオブジェクトが集まるので、ここに対してあれこれすればよい。

3重ループになっているので、ファイル取得部分を関数に分けるなどすればもう少し見やすくなるかなと思います。

const folderId= "xxxxxxxxxx";
const targetDir = DriveApp.getFolderById(folderId);
const files = []; // ファイルオブジェクトを保持する配列
const subFolders = [targetDir.getFolders()];

for(let i = 0; i < subFolders.length; i++) {
  const subFolder = subFolders[i];
  while(subFolder.hasNext()) {
    const folder = subFolder.next();
    subFolders.push(folder.getFolders());

    const fileIterator = folder.getFiles();
    while(fileIterator.hasNext()) {
      files.push(fileIterator.next());
    }
  }
}


フォルダの一覧の場合は、fileIteratorのループが不要で、subFolder.next()を配列に詰めればOK。

もっとこう書けばええやん、というご指摘等あればコメントいただければ嬉しいです。

まとめ

今回は、GASでGoogleドライブにあるとあるフォルダ配下にあるすべてのファイルを取得する方法をメモしました。

GASは結構機能が用意されているので、Googleサービスに対してやろうと思ったことは気軽に実装できそうな印象です。

ただし、GASには実行時間の制限などもあるので、この辺に気をつけて使いましょう。

Google サービスの割り当て  |  Apps Script  |  Google for Developers https://developers.google.com/apps-script/guides/services/quotas?hl=ja

今回は、ここまで。

おわり


【WSL】ユーザアカウントにログインできなくなった場合の確認と対処方法
2023-10-29T22:01:49+09:00
こんにちは、しきゆらです。

今回は、WSL起動時に初期設定したユーザでログインできなくなったので、調べたり対応したことをメモしておきます。

WSLのインストール時にユーザアカウントを作成しますが、いつの間にかユーザアカウントへログインできずにrootとしてログインしてしまう状況になっていました。

何が起こっているのかわからなかったので、諸々も調べてユーザアカウントとしてログインできるよう修正したのでメモしておきます。

WSLはWindows Subsystem for Linuxという通り、動いているのはLinuxになります。

なのでLinuxコマンドや各ファイルをもとに確認していきます。

作業の流れ

ざっと流れを記載しておくと以下の通りです。


現在ログインしているユーザを確認する
ユーザアカウントの有無を確認する
デフォルトのログインユーザを指定する
指定したユーザでログインできるか確認する


では、それぞれを見ていきます。

現在ログインしているユーザを確認する

ほぼログイン時のパスなどでわかると思いますが、念のため書いておきます。

whoamiコマンドで確認すると以下のように表示されます。

> whoami
root


コマンド名の通り、現在のユーザを確認するコマンドになります。 rootとなっていれば大本の管理アカウントなので、普段使っているユーザアカウントとは異なっていることがわかります。

ユーザアカウントの有無を確認する

続いて、これまで使っていたユーザが残っているのかどうかを確認してみます。

これはコマンドではなく/etc/passwdファイルにまとまっているので、中身を確認してみます。

このファイルには、ユーザ以外にもデーモンなど裏側で作られているものも含まれているので、grepコマンドでほしい情報があるかを絞ったほうが見やすいです。

# 全体の確認
> cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
...

### これまでのアカウントがあるかどうかを確認する場合
> cat /etc/passwd | grep <ユーザ名>
# ファイルの中にユーザ名が含まれていればその行が表示され、含まれていなければ何も表示されません


grepしてユーザ名が書かれた行がなければ、/home/<ユーザ名>のディレクトリを確認し必要なファイルのバックアップを取ったうえで初期化したほうが良いかもしれません。

私の場合は、このファイルにユーザ名の行があったので以下の手順で復帰しました。

ログインするユーザを指定する

上記でユーザが残っていることはわかったので、ログインするユーザを明示してあげます。

記載するファイルは/etc/wsl.confで以下のように記載します。

# 以下を追記
[user]
default=<ユーザ名>

# ログイン時にWindowsのパス情報を追加したくない場合は以下も記載
[interop]
appendWindowsPath = false


上記を記載したら、念のためWSLの再起動をしてあげた後にログインしてみましょう。

PowerShellからWSLを止めます。

# PowerShellからWSLをシャットダウンする
> wsl --shutdown


指定したユーザでログインできるか確認する

WSLを一度シャットダウンしたので、該当するディストリビューションへログインましょう。

# wslを立ち上げてログインする
> wsl -d <ディストリビューション>


# whoamiコマンドで意図したユーザとしてログインできているかを確認する
> whoami
<ユーザ名>


無事に指定したユーザでログインできれば、修正完了です。

rootのままだった場合は、ユーザの指定を間違えていないかを確認してみてください。

解消しなければ「ユーザアカウントの有無を確認する」のところにも記載していますが、バックアップを取ったうえで初期化したほうが安全かと思います。

まとめ

今回は、WSLのログインがrootになってしまったので修正方法を調べつつまとめました。

私の場合は、たまたま今回はアカウントが残っていたので無事に修正できましたが、アカウントそのものが残っていない場合は復旧が難しいかもしれません。

その場合は、できるだけ必要なファイルをバックアップしたうえで初期化するしかないかと思います。

幸い、WSLの初期化は簡単なので使える状態にするには時間がかからないかと思います。

参考情報としてLinuxディストリビューションの登録解除の方法を置いておきます。

WSL の基本的なコマンド | Microsoft Learn https://learn.microsoft.com/ja-jp/windows/wsl/basic-commands#unregister-or-uninstall-a-linux-distribution

今回は、ここまで。

おわり


【Rust/Ruby】OBS Studioの録画時間をスクリプトから取得してみる
2023-09-27T12:17:24+09:00
こんにちは、しきゆらです。

連休は出かけていてブログ書けませんでした。

今回は、最近ちょっと触っているOBSをプログラムから操作したり情報を取得できるということを知ったので、サンプルを見ながら情報を取得してみようと思います。

OBSのドキュメントは以下になります。 詳しく知りたい方はこの辺を参考にするとよいかなと思います。

Welcome to OBS Studio’s documentation! — OBS Studio 29.1.3 documentation https://docs.obsproject.com/

上記を見るとC系での話が主なようですが、今回はよく使う言語であるRubyと、最近ちょっと触っているRustで書けることを目的として調べてみました。

どうやらOBSはWebSocket経由で操作することができるようです。

公式のリポジトリにもOBSのWebSocketプラグインがあるようで、v28以降のバージョンに対応しています。 手元の環境では、初期状態で入っていてちょっと設定してあげればすぐ使えるようになったので、初めはこの辺を触ってみるのが良いかなと思います。

GitHub - obsproject/obs-websocket: Remote-control of OBS Studio through WebSocket https://github.com/obsproject/obs-websocket

Rubyから録画時間を取得する

上記を受けてRubyから操作するgemがないかな、と思って調べてみると非公式ながらありました。

GitHub - onyx-and-iris/obsws-ruby: Ruby clients for OBS Studio WebSocket v5.0 https://github.com/onyx-and-iris/obsws-ruby

まずは、RubyからOBSを操作するためにサンプルを見たり内部のスクリプトを見ながら録画時間を取得するコードを書いてみました。

require "obsws"

client = OBSWS::Requests::Client.new(
    host: "IPアドレスなど",
    port: ポート番号,
    password: "PWの文字列"
)
loop do
    p client.get_record_status.output_timecode
    sleep 1
end


上記コードはシンプルに1秒ごとに録画時間を取得してターミナルへ表示するコードです。

IPアドレスやポート番号などは、OBSの「ツール」>「WebSocketサーバ設定」から確認・設定可能です。

実際にスクリプトを実行しつつOBSで録画すると、録画時間が表示されました。

Rustから録画時間を取得する

では、同様のことをRustでやってみます。

RustからOBSのWebSocketを操作するcrateは、obs-websocketにリンクがあったこちらを使ってみました。

GitHub - dnaka91/obws: The obws (obvious) remote control library for OBS https://github.com/dnaka91/obws

サンプルや内部コード、エラーを修正しつつできたのがこちら。

use std::{thread, time};
use anyhow::Result;
use obws::{Client, client, requests::EventSubscription};

#[tokio::main]
async fn main() -> Result<()> {
  let sleep_time = time::Duration::from_secs(1);
  let config = client::ConnectConfig {
    host: "IPアドレス",
    port: ポート番号,
    password: Some("PW文字列"),
    event_subscriptions: Some(EventSubscription::all()),
    broadcast_capacity: Some(100),
  };
  let client = Client::connect_with_config(config).await?;

  loop {
    let outputs = client.recording();
    let status = outputs.status().await?;
    println!("outputs: {}", status.timecode);

    thread::sleep(sleep_time)
  };

  Ok(())
}


サンプルコードから動かしてみたのですが、諸々エラーだったりcrateが足りなかったりと動かず悪戦苦闘しながらここまで持っていきました。

Rustのお作法をきちんと理解できていなので躓いただけかもですが、動く状態まで持っていけてよかったなと。

これにて、Rustでも同様にターミナルに録画時間を表示することができました。

まとめ

今回は、OBS Studioの操作をスクリプトからできることを知ったのでRuby/Rustで簡単なサンプルを作ってみました。

どちらもライブラリが用意されているので、そこまで難しくはありませんでした。

また、Rustの勉強にもなったのでちょっと自信が付いたかもしれません。

今回はここまで。

おわり


【Ruby/Selenium】v115からChromeDriverの配布元が変わったようなので対応した話
2023-07-29T23:01:28+09:00
こんにちは、しきゆらです。

数年ごとに時たま書いているSeleniumネタ、 今回は久々に大きく動かなくなったので調べつつ対応した記録を残しておきます。

webdriversが動かなくなった

これまではwebdriversというgemを使い、インストールされているChromeのバージョンにあったChromeDriver良しなに取得するようにしていました。

GitHub - titusfortner/webdrivers: Keep your Selenium WebDrivers updated automatically

さっくりwebdriversの中身を見てみましたが、インストールしているChromeのバージョンを確認し、必要なDriverがなければ以下のサイトから該当バージョンのものを取得・配置するようです。



「https://chromedriver.storage.googleapis.com/LATEST_RELEASE_114」のようにChromeのバージョン値を指定するとその最新版となるChromeDriverのバージョンを取得できるので、これをもとに取得する感じでした。

ところが、先日Seleniumを動かしたらChromeDriverがない、とエラーが出て動かなくなっていました。

何事かと思って調べてみました。

ChromeDriverの配布先が変わった

ChromeDriverのサイトを見てみると、配布先が変更されたようです。

ChromeDriver - WebDriver for Chrome - Downloads


  Latest ChromeDriver Binaries
  
  
  Starting with M115 the latest Chrome + ChromeDriver releases per release channel (Stable, Beta, Dev, Canary) are available at the Chrome for Testing availability dashboard. For automated version downloading one can use the convenient JSON endpoints.
  The older releases can be found at the Downloads page.
  


ということでwebdriversが参照していたサイトとは別のところで配布するようになったようです。

ついでに調べていると、Chrome for Testingなるものが出てきました。

Chrome for Testing: reliable downloads for browser automation - Chrome Developers

以前も何かのタイミングでちらっと見た気がするんですが、あまり詳しく見てはいなかったので今回読んでみました。

どうやら、Chromeは自動更新なので開発者はテストをするタイミングによって意図しないバージョンになっていたりしてつらい、そうだテスト用に自動更新がないChromeを作ろう、ということのようです。

ということでテスト用Chromeとそのバージョン向けのChromeDriverが以下のサイトで一緒に配布されるようになっていました。

Chrome for Testing availability

自前でChromeDriverを取得するスクリプトを組んでいる場合は、この辺の対応が必要になりそう。

対応方法

暫定対応

webdriversでも対応するPRが上がってますが、記載時点(2023/07/29)ではまだマージされてません。

Fixed Webdrivers::VersionError with chrome version greater than 115 by sadahiro-ono · Pull Request #249 · titusfortner/webdrivers

こちらのissueで対応方法が記載されていました。

Webdrivers trying to load a Chrome version that doesn't exist · Issue #247 · titusfortner/webdrivers

現在はv114向けのChromeDriverでも動くようなので、コード内でChromeDriverのバージョンを決め打ちすることでその場しのぎをすることができます。

ただ、これもこのバージョンで動作しなくなるのは時間の問題なのでいつまで使えるかは不明です。

Webdrivers::Chromedriver.required_version = "114.0.5735.90"


Selenium Manager

issueを見ていくと、Selenium Managerなるものが出てきました。

Selenium Manager (Beta)

まだBetaのようですが、Selenium自体に含まれる各WebDriverの取得などをしてくれるツールのようです。

これまでは、手動で配布サイトから取得したり上記webdriversのような別ツールでWebDriverを取得して使う必要がありましたが、Selenium Managerを使えば外部ツールを使わずにSeleniumだけで完結するようになりますね。

使い方も、以下の3点を満たしていれば勝手に動いてくれるようです。


ServiceクラスでWebDriverのパスを指定していない
webdriversのような外部のWebDriver管理ツールを使っていない
環境変数PATHの中にWebDriverがない


ということで、webdriversが動かないのでこっちを使ってみることにしました。

ここでは、タイトルの通りRuby環境である前提で記載しますが

selenium-webdriverのgemを最新にしたうえで、上記3点を満たすように環境を整えるだけで勝手に使えるようになります。

なお、selenium-webdriverのCHANGELOGを見てみると、4.6.0のころからSelenium Managerへ対応が入っているようです。



手元では、webdriversのみしか使っていないのでこれを削除するだけで利用できました。

webdriversがない状態でSeleniumを使ってブラウザを立ち上げようとするとターミナル上に以下のように記載されてChromeが立ち上がるようになりました。

2023-07-29 20:53:08 WARN Selenium applicable driver not found; attempting to install with Selenium Manager


Selenium Managerが良しなに動いてくれているようです。

これで、対応はおしまいです。

まとめ

今回はSeleniumを使っていたらChromeDriverを取得できずに死んでしまったので、原因を調べつつ対応してみました。

結果としては、外部ツールに頼ることなくSeleniumが擁してくれているSelenium Managerを使うことで無事動くようになりました。

今回は、ここまで。

おわり


【Ubuntu】apt updateで404エラーがでたので解消する
2023-05-11T23:28:12+09:00
こんにちは、しきゆらです。

今回は、Ubuntuでapt updateを実行したときに404エラーが発生していたので

解消するために色々調べつつ対応したのでメモしておきます。

今回利用していたUbuntuのバージョンは以下の通り。

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.10"
NAME="Ubuntu"
VERSION_ID="22.10"
VERSION="22.10 (Kinetic Kudu)"
...


はじめに

前回のPostgreSQLのインストールのように、あれこれリポジトリを追加したりOSを更新しているとapt updateを実行するとリポジトリの一部で404エラーが出るようになっていました。

出ていたエラーは以下の通り。

$ sudo apt update
...
Err:10  kinetic Release
  404  Not Found [IP: 185.125.190.52 443]


エラーが出ていたのは「ppa.launchpadcontent.net/deadsnakes/ppa/ubuntu」でした。

何を入れたときのものかすでに覚えていないですが、404であれば不要だろう、ということで解消していきます。

解消方法

ざっくりと手順を記載すると以下の通りです。


対象リポジトリを管理しているファイルを探す
リポジトリを無効化する
解消されたかを確認する


それぞれに分けてみていきます。

対象リポジトリを管理しているファイルを探す

調べてみると、apt updateで参照するリポジトリは/etc/apt配下にあるxxx.listというファイルで管理されているようです。

Repositories/CommandLine - Community Help Wiki

ということで、この中にあるファイルの中に該当するURLが書かれているファイルを探しましょう。 まずは、該当するリポジトリが書かれたファイルの一覧を取得してみます。

なお、出力結果は環境によって異なるので適宜ご自身の環境に合わせて読み替えてください。

$ find /etc/apt -name "*.list"
/etc/apt/sources.list
/etc/apt/sources.list.d/amdgpu.list
/etc/apt/sources.list.d/rocm.list
/etc/apt/sources.list.d/deadsnakes-ubuntu-ppa-kinetic.list
/etc/apt/sources.list.d/amdgpu-proprietary.list
/etc/apt/sources.list.d/docker.list
/etc/apt/sources.list.d/pgdg.list


取得できたそれぞれのファイルの中を確認していきます。

とはいえ、catとかエディタとかでひとつづつ見ていくのは手間。

この辺もコマンドでやってしまいましょう。

$ find /etc/apt -name "*.list" | xargs grep ppa
/etc/apt/sources.list.d/deadsnakes-ubuntu-ppa-kinetic.list:deb  kinetic main
/etc/apt/sources.list.d/deadsnakes-ubuntu-ppa-kinetic.list:# deb-src  kinetic main


なお、xargsは標準入力やファイルなどからリストを受け取って、それを別コマンドの引数とするコマンドのようです。

【 xargs 】コマンド――コマンドラインを作成して実行する：Linux基本コマンドTips（176） - ＠IT

これで、該当するファイルのパスと内容を確認できました。

リポジトリを無効化する

無効化するには、単純にコメントアウトすればよいだけなので以下のように先頭に#を追加。

cat /etc/apt/sources.list.d/deadsnakes-ubuntu-ppa-kinetic.list
# deb <https://ppa.launchpadcontent.net/deadsnakes/ppa/ubuntu/> kinetic main
# deb-src <https://ppa.launchpadcontent.net/deadsnakes/ppa/ubuntu/> kinetic main


これにて対応は完了。

解消されたかを確認する

apt updateを実行して404エラーが出ないことを確認できれば完了です。

私の環境では特に不要としてコメントアウトしてしまっていますが、リポジトリを追加したということは何らかのアプリ等をインストールするために追加しているはずなので

利用しているパッケージが度のリポジトリで管理されているかを確認してあげる必要があるかと思います。

未確認ですが、この辺で確認できそうです。

現在認識しているaptリポジトリーの一覧や、リポジトリーに含まれているパッケージを調べたい - CLOVER🍀

まとめ

今回はUbuntuでapt update時に404エラーが発生していたので、解消するために原因や解消方法を調べました。

何気なく使っているパッケージマネージャの裏側をなんとなくチラ見できた気がします。

調べてみると、よく使うものでもよくわからずに使っているんだなぁというのと、もう少し深く知りたくなります。

今回はここまで。

おわり


【Ubuntu】apt updateでKey is stored in legacy trusted.gpg keyringと注意されたので対応する
2023-05-07T08:47:15+09:00
こんにちは、しきゆらです。

今回は公式のドキュメントを見ながら対応したのに、apt updateで怒られるようになったので

 なぜなのか調べつつ、対応方法を見つけて対応したのでメモしておきます。

はじめに

今回起こったのはPostgreSQLのインストール時のこと。

PostgreSQLをインストールするためにリポジトリ追加を行った。 手順はこれ。

PostgreSQL: Linux downloads (Ubuntu) 

該当箇所は以下の通り。

# Create the file repository configuration:
$ sudo sh -c 'echo "deb  $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

# Import the repository signing key:
$ wget --quiet -O -  | sudo apt-key add -

# Update the package lists:
$ sudo apt-get update # <= ここでWarningが出た
...
Key is stored in legacy trusted.gpg keyring


ということで、記載されているが、そもそも何を怒っているのかを調べてみました。

何が起きているのか

apt-keyはなぜ廃止予定となったのか

Fully deprecate apt-key, schedule removal for Q2/2022 (ee284d59) · Commits · APT Developers / apt · GitLab

apt-keyコマンドがだいぶ前の2020年8月ころから廃止予定で、2022年Q2に廃止となっていたようです。

手元の環境はWSL2上のUbuntu 22.10でしたが、まだ残っているようでした。

今後はなくなるんでしょう。


  セキュリティ上の懸念点からくるもので、簡単にまとめると次の2点が理由です。
  
  
  apt-key addは単一ファイル（/etc/apt/trusted.gpg）に鍵を追加していくため、複数のリスクの異なるリポジトリの鍵を同じ権限で管理しなくてはならない。
  リポジトリ鍵として追加した鍵は、すべてのリポジトリに対して適用される。
  
  
  引用元: https://gihyo.jp/admin/serial/01/ubuntu-recipe/0675


ということで、リポジトリごとにリスクが異なるカギを全体で使うのよくいないよね、ということでこれをやめた、という感じなのかなと。

やめたはいいが、この記事時点では代替となるものが用意されていないようです。 今後は、各リポジトリで利用するカギを/usr/share/keyrings/配下に設置して個別に指定する運用が良いだろう、として締めています。

対応方法

大きく分けると以下の通り。


既存のカギを削除する
別途カギを取得し設定しなおす
リポジトリとカギを紐づける


1. 既存のカギを削除する

$ apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg.d/apt.postgresql.org.gpg # <= これを削除する
---------------------------------------------
pub   rsa4096 2011-10-13 [SC]
      B97B 0AFC AA1A 47F0 44F2  44A0 7FCC 7D46 ACCC 4CF8
uid           [ unknown] PostgreSQL Debian Repository
...

# 鍵の削除はfinger printの最後の8文字のようです
$ sudo apt-key del ACCC4CF8
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK

# 消えたことを確認
$ apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
...


2. 別途カギを取得し設定しなおす

カギについては、ここに記載されているので取得して入れなおします。

PostgreSQL: Linux downloads (Ubuntu) 

# カギの取得
$ wget 

# カギをgpgコマンドを使って変換
$ gpg --no-default-keyring -o postgresql-keyring.gpg --dearmor ACCC4CF8.asc

# カギを確認
$ file postgres-keyring.gpg
postgres-keyring.gpg: GPG keybox database version 1 ...

# 変換したカギを/usr/share/keyrings/へ設置する
# 手元ではフォルダがなかったので手動で作成
$ sudo mkdir -p /usr/share/keyrings
$ sudo cp postgres-keyring.gpg /usr/local/share/keyrings


3. リポジトリとカギを紐づける

リポジトリは/etc/apt/sources.list.d/pgdg.listに作成しているので、このファイルを以下のように変更。

# deb [signed-by=/path/to/gpg_key] URLの形式でカギの場所を記載
deb [signed-by=/usr/local/share/keyrings/postgresql-keyring.gpg]  kinetic-pgdg main


これにて対応完了です。

Warningが出ないことを確認しましょう。

# warningが出ないことを確認
$ sudo apt update
...
Hit:7  kinetic-pgdg InRelease


まとめ

今回は、apt-keyコマンドが廃止となっているために、ドキュメント通りに対応してもWarningが出てしまっていたので、諸々調べつつ対応してみました。 そもそもの廃止から知らなかったので勉強になりました。

なお、DockerやGithub CLIでは /etc/apt/keyrings 配下に設置しているようです。

Install Docker Engine on Ubuntu | Docker Documentation

Linux installation instructions recommend storing GPG keyring in the wrong location · Issue #5122 · cli/cli · GitHub

管理をユーザ側でやる、という形であれば1か所にまとめたほうが良いので どこか1か所を決めて、リポジトリ追加時にそこへ追加していく方法をとったほうが良いかもしれません。

DebianのWikiにも /etc/apt/keyrings 配下に設置しよう、となっているのでこっちに合わせたほうが良いかもしれません。

DebianRepository/UseThirdParty - Debian Wiki

今回はここまで。

おわり


【WSL2】systemdがサポートされたようなので試してみた
2022-11-19T08:32:00+09:00
ここ数年はWindowsの環境をクリーンインストールするたびにWSL2の環境を作り直し、その度にgenieを使ってsystemdをPID 1 にするための方法をメモしてきました。

【WSL2】systemctlが動かない問題をきちんと解決する

【WSL2】Ubuntu20.04でPID1をSystemdにする

【WSL2/Ubuntu】systemdをPID1で動かす 2021年3月版

しかし、気が付いたらWSL自体がsystemdをサポートしたようなので、WSLだけでsystemdをPID 1にしてみたのでメモしておきます。

詳しいことは公式ブログを参照ください。

Systemd support is now available in WSL!

設定手順

公式ブログによると、WSLのバージョンが0.67.6以上で使えるとのこと。

なお、手元のWSLのバージョンを確認するとすでに1.0になっていたのでだいぶ前から使えたんだなぁともっと早く気づきたかった気持ちでいっぱいです。

確認するためのコマンドは以下の通り。

powershell > wsl --version
WSL バージョン: 1.0.0.0
カーネル バージョン: 5.15.74.2
WSLg バージョン: 1.0.47
MSRDC バージョン: 1.2.3575
Direct3D バージョン: 1.606.4
DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windowsバージョン: 10.0.22621.819


なお、WSLの更新もwslコマンドでできるようになったようなので、バージョンが古い場合は以下のコマンドで更新すればよい。

powershell > wsl --update


次に、WSL環境にwsl.confというファイルを作成し、以下を書き込む。

wsl(Ubuntu) > sudo emacs /etc/wsl.conf
# 以下を追記
[boot]
systemd=true


書き込んだらWSL環境を再起動。

これにて準備完了です。

powershell > wsl --shutdown


この後、WSL環境に入りsystemctlを動かしてみます。

以下のようにエラーが起きずにつらつら表示されたらOK。

wsl(Ubuntu) > systemctl
UNIT                                                                                                                                                                      LOAD   ACTIVE SUB       DESCRIPTION                                            >
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-0fd20160\x2d7ac7\x2d4158\x2d9e38\x2d8685d280c3a6-net-eth0.device                                                 loaded active plugged   /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/VMBUS:>
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-ba31a026\x2d5b46\x2d4a8d\x2da6dc\x2df00324cf1e90-pci5b46:00-5b46:00:00.0-virtio0-virtio\x2dports-vport0p0.device loaded active plugged   /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/VMBUS:>
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-fd1d2cbd\x2dce7c\x2d535c\x2d966b\x2deb5f811c95f0-host0-target0:0:0-0:0:0:0-block-sda.device                      loaded active plugged   Virtual_Disk
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-fd1d2cbd\x2dce7c\x2d535c\x2d966b\x2deb5f811c95f0-host0-target0:0:0-0:0:0:1-block-sdb.device                      loaded active plugged   Virtual_Disk
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-fd1d2cbd\x2dce7c\x2d535c\x2d966b\x2deb5f811c95f0-host0-target0:0:0-0:0:0:2-block-sdc.device                      loaded active plugged   Virtual_Disk
sys-devices-platform-serial8250-tty-ttyS0.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS0
sys-devices-platform-serial8250-tty-ttyS1.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS1
sys-devices-platform-serial8250-tty-ttyS2.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS2
sys-devices-platform-serial8250-tty-ttyS3.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS3
  ...


まとめ

今回は、WSLがsystemdをサポートしたということで設定してみました。

今後はgenieを入れずともWSLだけでsystemdを使えるので、より手軽に環境を使えるようになりました。

今回は、ここまで。

おわり


【JS/Webpack】ビルドしたフォルダの不要ファイルを削除する
2022-08-24T23:45:46+09:00
こんにちは、しきゆらです。今回は、Webpackでビルドしたものが出力されるフォルダにできる不要ファイルを削除する方法を知ったのでメモしておきます。

WebpackでJSのコードをビルドしていると、結構な頻度で不要なファイルができたりします。例えば、デバッグ用に生成したソースマップファイルがそのまま残っていたり、過去に設定を変えてあるところから出力しなくなったファイルが残っていたり等、ビルド先のdistフォルダの中はごちゃごちゃしがちです。これを何とかしたいなぁ、と思って調べたら簡単に解決できました。

Webpackでこういうことできないかなぁと調べると大抵プラグインが出てきて追加しないといけないことが多く、今回もそのパターンでよくわからないものを追加しないといけないのかなぁ・・・と思っていたのですが、どうも標準機能として用意されているようでした。ということで結論。

結論: outputの中に[clean: true]を追加すればよい

ドキュメントを読むことは大事ですね。しっかり記載がありました。

https://webpack.js.org/guides/output-management/#cleaning-up-the-dist-folder

こちらによると、ビルドしたものを置くdistフォルダの中身をビルドのたびにきれいにしたい場合はoutput.cleanオプションを使え、とあります。ただし、この方法が使えるのはWebpack5以降のみなので注意してください。

// webpack.config.jsの一部分
~~~~~~
output: {
   filename: "output.js",
   path: path.resolve(__dirname, "dist"),
   clean: true // この1行を追加すればよい
}


はい、たったこれだけ。１行追加するだけで、ビルドのたびにdistフォルダの中身をきれいにしてくれるので、過去にビルドした残骸が残ることはなくなりました。

また、こちらのページには細かい設定方法もありました。

https://v4.webpack.js.org/guides/output-management/#cleaning-up-the-dist-folder

そして、前述の通りこの方法が使えるのはWebpack5以降のみとのことでした。Webpack4などを使っている方は、プラグインでの対応となるようです。

Webpack4を使っている方: clean-webpack-pluginを使う

https://v4.webpack.js.org/guides/output-management/#cleaning-up-the-dist-folder

Webpack4版のドキュメントを見ると、同様の項目ですが対応方法が異なっていました。「clean-webpack-plugin」というプラグインを使えば削除できるので、導入・設定しましょうとのことでした。以下にドキュメントにあったサンプルを載せておきます。

# プラグインのインストール
npm install --save-dev clean-webpack-plugin


webpack.config.jsはこんな感じ。

// webpack.config.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
// プラグインを読み込む
const { CleanWebpackPlugin } = require('clean-webpack-plugin');

module.exports = {
  entry: {
    app: './src/index.js',
    print: './src/print.js',
  },
  plugins: [
    new CleanWebpackPlugin(), // この行を追加する
    new HtmlWebpackPlugin({
      title: 'Output Management',
    }),
  ],
  output: {
    filename: '[name].bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
};


これにより、output.pathで指定したフォルダにある不要ファイルを削除したうえでビルドしてくれるとのことでした。さらに、Webpack5では細かい設定ができましたが、clean-webpack-pluginでも似たような設定はできそうです。

https://www.npmjs.com/package/clean-webpack-plugin

まとめ

今回は、Webpackで過去にビルドした残骸をきれいに削除する方法をまとめました。不必要なプラグインを導入せずに、たった１行の設定追加だけでやりたかったことが実現できてとてもハッピーです。

そして、Webpack5ではデフォルトでこの機能が入っていることを知りませんでした。過去に調べたときはプラグイン対応だったよなぁと思いつつ調べると、やはりプラグインを導入しろ、という記事が多く出てきました。とりあえずググるのは大事ですが、ドキュメントをさっくりと眺めておく、というのも必要ですね。




【JS】flatMapで不要なものを削除したい
2022-08-14T18:34:08+09:00
こんにちは、しきゆらです。今回は、flatMapの処理の中で不要な要素が出てきた場合にそれを排除する方法を知ったのでメモしておきます。

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/flatMapこちらのページの「map()のアイテムの追加と削除」の項目にある通り、処理の中で空配列([])を返すと、その要素の処理を削除することができるようです。

let array = [1,2,3,4,5,6,7,8];
array.flatMap( (item) => {
    if (item % 2 === 0) {
        return item * 2;
    } else {
        return [];
    }
})
// => [4, 8, 12, 16]


なお、同様の処理をmapで行うと、そのまま要素が空配列に置き換わってしまいました。(それはそう)

let array = [1,2,3,4,5,6,7,8];
array.map( (item) => {
    if (item % 2 === 0) {
        return item * 2;
    } else {
        return [];
    }
})
// =>[Array(0), 4, Array(0), 8, Array(0), 12, Array(0), 16]


ということで、flatMapの場合は処理の中で不要な要素を削除ができるようです。

なぜ、flatMapで空配列を返すと要素を削除することができるのかというのは


  flatMap()はmap()の後にflat()を行うのと同じ

  参照元: https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/flatMap


とある通り、処理の中でflat()をかけるので空配列は消えてしまいます。ということで、flatMapの中で空配列を返してあげれば要素を削除することができるよ、という話でした。

・・・で、これで終わるとしょうもないので、Rubyで同様のことができるのかやってみました。https://docs.ruby-lang.org/ja/latest/method/Enumerable/i/collect_concat.html

irb(main):001:0> a = [1,2,3]
=> [1, 2, 3]
irb(main):002:0> b = [-1, 0, 9]
=> [-1, 0, 9]
irb(main):003:0> list = [a, b]
=> [[1, 2, 3], [-1, 0, 9]]
irb(main):004:0> list.flat_map{|array| array.select{|i| i < 0}}
=> [-1]
irb(main):005:0> list.flat_map{|array| array.include?(-1)? []: array}
=> [1, 2, 3]


こちらも同様で、空配列を返すと削除される動きをしています。ただ、リファレンスにはそのような記載はないので、当たり前だよね、として書かれていないのかなと。

不要な要素をはじく場合、flatMapとmap+αはどっちが速いのか

この手の処理はmap()メソッドの前後で特定の値をはじいたりしていましたが、どちらが速いのでしょう。気になったので、ついでに調べてみました。ここでもJSとRubyで測ってみました。

例としては微妙ですが、-5から5の間の乱数の中で０以上の場合に3倍する処理をflatMapと他の処理で処理時間を計測してみます。

JSの場合

こんな感じの雑さで試してみます。

なお、処理の中で不要なコードが混じってますが一応2つの処理で同じ結果が返ってくるかを確認したかったのでequalArrayという雑チェック関数を作ってます。

import * as Benchmark from "benchmark";

const filterMapTest = (array) => {
    return array.filter((item) => {
        return item >= 0;
    }).map(item => item*3)
}

const flatMapTest = (array) => {
    return array.flatMap((item) => {
        if(item >= 0) {
            return item * 3;
        } else {
            return [];

        }
    })
}

const equalArray = (a, b) => {
    if(!Array.isArray(a)) return false;
    if(!Array.isArray(b)) return false;
    if(a.length !== b.length) return false;

    for(let i = 0; i < a.length; i += 1) {
        if(a[i] !== b[i]) return false;
    }

    return true;
}

// initialize
const minNum = -5;
const maxNum = 5;
const array = [...Array(99*99)].map(_ =>; Math.floor(Math.random() * 10) - 5);
let suite = new Benchmark.Suite

// benchmark
suite
    .add("filter + map", () => {
        filterMapTest(array)
    })
    .add("flatMap", () => {
        flatMapTest(array)
    })
    .on("cycle", (event) => {
        console.log(String(event.target))
    })
    .on("complete", function() {
        console.log("Fastest is " + this.filter("fastest").map("name"));
    })
    .run({async: true})

const filterTest = filterMapTest(array);
const flatTest = flatMapTest(array);


console.log(equalArray(filterTest, flatTest))


実行結果はこんな感じでした。

$ > node dist/bench.js
true
filter + map x 21,538 ops/sec ±18.58% (87 runs sampled)
flatMap x 1,673 ops/sec ±0.93% (96 runs sampled)
Fastest is filter + map


大きな差はなさそうですが、flatMapよりもfilter+mapのほうが速そうです。

Rubyの場合

こんな感じの雑さで試してみました。

require "benchmark"

def map_uniq(array)
  array.map { |item| item.negative? ? next : item * 3}.compact
end

def flatmap(array)
  array.flat_map{|item| item.negative? ? []: item * 3 }
end

array = Array.new(99*99){ rand(-5...5) }

Benchmark.bmbm do |r|
  r.report("flatMap") { flatmap(array) }
  r.report("map_uniq") { map_uniq(array) }
end


実行結果はこんな感じでした。

Rehearsal --------------------------------------------
flatMap    0.001012   0.000000   0.001012 (  0.001012)
map_uniq   0.000562   0.000000   0.000562 (  0.000562)
-----------------------------------total: 0.001574sec
user     system      total        real
flatMap    0.000815   0.000000   0.000815 (  0.000814)
map_uniq   0.000564   0.000000   0.000564 (  0.000563)


よく考えなくても、flatMapのほうは無駄に配列生成して処理スキップさせているので遅いよなぁ、という印象でした。

まとめ

今回は、JSのflatMapで不要な要素をはじいて処理することができる、ということを知ったのでメモしました。また、気になったので、同様な処理がRubyでもできるか確認したり、flatMapで不要要素を弾く場合とfilterなどをかけた場合の処理時間の差を見てみました。

今回はここまで。おわり


【node/yarn】asdfでnodeをインストールし、Yarnもつかえるようにする
2022-08-13T18:55:09+09:00
こんにちは、しきゆらです。

今回は、こちらで紹介したasdfを使ってNode.jsをインストールし、個人的によく使っているYarnも使えるように環境を作っていきます。

なお、Node.jsのインストールはすぐ終わったのですがYarnのインストールとか諸々に至るまでに紆余曲折ありました。まずは、インストールして環境構築までの流れをまとめます。

その後に、紆余曲折部分をメモしておきます。

必要なコマンドだけよこせ！という方は、以下の「環境構築の流れ」を参考にしてみてください。

環境構築の流れ

コマンド自体の使い方等はそれぞれのツールのサイト等で確認してください。

# node用のプラグインを追加
asdf plugin add nodejs

# nodeをインストール
asdf install nodejs latest

# システム全体で使うバージョンを指定
asdf global nodejs latest

# yarnを使う準備
corepack enable

# asdfの再構築
asdf reshim nodejs


これにて、環境構築は終了です。

yarnの手順が以前とだいぶ変わりましたが、npmで個別にインストールせずにパッケージマネージャを管理する仕組みが入ったようです。

そのおかげで手順がさっぱりしました。

では、前述の通り環境構築の紆余曲折や各ドキュメントを見ながらの細かい話は以下にまとめていきます。

環境構築の紆余曲折

Nodeのインストール

こちらは、asdfの仕組みにのっとって進めるだけなので、前回の記事と同じ手順を踏むだけです。

# node用のプラグインを追加
asdf plugin add nodejs

# nodeをインストール
asdf install nodejs latest

# システム全体で使うバージョンを指定
asdf global nodejs latest

# 確認
node -v


Yarnのインストール

手間取ったのはこちらのほう。

インストールするために、公式サイトを見てみると記述がガラッと変わっていました。

https://yarnpkg.com/getting-started/install

Node.js 16.10以上だと以下のコマンドだけでよいとのこと。

corepack enable


corepackとは何ぞや。

と思って調べると、Node.jsのパッケージマネージャを管理するための仕組みのようです。

https://nodejs.org/api/corepack.html

いい感じにまとめてくれている方がいました。先人に感謝です。

https://zenn.dev/teppeis/articles/2021-05-corepack

ということで、公式の手順に従ってコマンド実行してみました。

# corepackを有効化
corepack enable

# yarnは入った・・・？
yarn
zsh: command not found: yarn


ということで、実行してもyarnは使えませんでした。

corepackについてもう少し調べてみる

なんでじゃ、と思ってこれまた調べてみると、プロジェクトごとに使うパッケージマネージャを指定するような使い方を想定しているようです。

そして、事前に使うパッケージマネージャを指定することもできるようです。

ということで、以下のコマンドで明示的にyarnを使うようにしてみます。

# 明示的にyarnを使う
corepack prepare --activate [email protected]

# yarnは入った・・・？
yarn
zsh: command not found: yarn


同じくコマンドがない、と怒られたのでいろいろ考えてみました。

ここで思い出したのが、rbenvではrehashというコマンドを使っていたこと。

gemや新しいバージョンのRubyをインストールしたときはとりあえずrehashしておけ、

という程度の認識でしたが、このような仕組みがasdfにもあるのでは、と思い調べてみました。

asdf reshim

調べてみると、ドンピシャな質問と回答が出てきました。

https://stackoverflow.com/questions/70082424/command-not-found-corepack-when-installing-yarn-on-node-v17-0-1

asdf reshim というコマンドでrbenv rehashのようなことができるとのこと。

https://asdf-vm.com/manage/core.html#reshim

上記によると、インストール時に~/.asdf/shimsへコマンドとして使えるようにファイルが自動的に生成されるが、それ以外ではファイルが生成されないのこと。今回の場合は、nodeインストール後に手動でcorepack enableやcorepack prepare --activate [email protected]を実行しているのでasdf的には存在を知らない。そこで、asdfに追加があったことを教えてあげて、ファイルを作ってもらう必要があったようだ。

# asdfにファイル生成をしてもらう
asdf reshim nodejs

# 確認
yarn -v
# => 3.2.2


ようやく使えるようになりました。

ただ、未確認ではありますが、asdf reshimの動きを見るとcorepack prepareは不要な気がします。

ということで、「環境構築の流れ」では省いてます。

おまけ: rbenv rehashについて改めて確認してみる

ここで、改めてrbenv rehashを調べてみました。

https://github.com/rbenv/rbenv#rbenv-rehash

御幣を恐れずにざっくり書けば、新しいgemやRubyをインストールした場合は「~/.rbenv/versions/*/bin/」にインストールされるが、PATHが通っているのは「~/.rbenv/shims」なのでそのままでは使うことはできません。

そこで、バージョン切り替えやgemのコマンドなどを追加する場合は新たに「~/.rbenv/shims」へコピーしてあげる必要があるわけです。そのコマンドがrbenv rehashのようです。

・・・とはいえ、いつの間にかrbenv installなどのタイミングで良しなにrbenv rehashが実行されるようになり明示的に実行する必要はなくなったようです。

ということで、asdfも正式版がリリースされる頃にはもしかしたら今回のようなごたごたはなくなるかもしれないなぁ・・・ということを思いながら、諸々調べる機会を与えてくれて感謝しつつ紆余曲折のメモを終わります。

まとめ

今回は、asdfを使ってNode.jsをインストールし、パッケージマネージャのYarnを使えるように環境構築をしました。

いつの間にかYarnのインストール方法が変わっていたり、asdfの仕組みに躓いたりしましたが、いろいろなことを調べたり知ることができたので満足です。

というわけで、今回はここまで。

おしまい


【WSL2/clasp】WSL2上からclasp pushするとError: Looks like you are offline.と怒られる問題を回避する
2022-06-12T20:06:21+09:00
こんにちは、しきゆらです。

今回は、タイトルの通りWSL2からclaspを使おうとするとofflineと怒られる問題が起こったのでこれを回避する方法をメモしておきます。

気が付くとWSL2からclasp pushをしようとすると、以下のようなエラーが出てしまってプッシュできない状態になっていました。

よくわからないですが、たまにプッシュできたりするので何が悪いのかよくわかりません。

WSLをインストールしなおしたりしても解決しませんでした。

また、調べてもそれっぽい記事が出てこないので「おま環」ぽい気がしています。

さて、これではWSL内で書いたGASをプッシュできません。

これを回避する方法をメモしておきます。

回避方法は単純で、Docker上からclasp pushをするだけ。

調べてみると、結構DockerでGASを管理したい人がいるようで、情報がそこそこありました。

ということで、プロジェクト諸々をDocker上にマウントしてコマンド実行できるようにしていきます。

なお、ここではGASをTypeScriptで書いたのちWebpackでビルドしたものをclaspコマンドでプッシュする流れです。

参考: https://qiita.com/rei-ta/items/61b3fde6a069b77d335d

Dockerの準備

まずは、Dockerの準備をしましょう。

Dockerのインストールは、WSLのホストであるWindows側に行えば良いようです。

Dockerfileを以下のように作成します。

FROM node:slim
RUN npm install @google/clasp -g


claspを実行する環境が必要なので、イメージとしてnodeを使います。

サイズが小さいほうが何かと便利なのでnode:slimを使っていますが、nodeが動けばなんでもよいかと思います。

また、claspを使えるようにインストールしておきます。

続いて、docker-compose.ymlを作成します。

version: "3"
services:
  clasp:
    build: .
    tty: true
    stdin_open: true
    volumes:
      - "/home/:/usr/src"
    working_dir: /usr/src/${user}


clasp loginしたのち、認証情報がhome直下にできるため/home/${user}をマウントしています。

これで準備は完了。

offlineと怒られる問題を回避する

Dockerを立ち上げていきます。

docker-compose run --rm -u ${id -u $usr} clasp /bin/bash

シェルが立ち上がったら以下のコマンドでログインします。

clasp login --no-localhost

これにて準備は完了です。

あとは、コードを書いてWebapckでビルドしたものをclasp pushしましょう。

node@ded2ca180394:$ clasp push
└─ /usr/src/path/to/project/appsscript.json
└─ /usr/src/path/to/project/bundle.js
Pushed 2 files.


問題なくプッシュできていますね。

これにて回避完了です。

まとめ

手元の環境では、これにてofflineと怒られる問題を回避できました。

ちょっと手間ですが、ひとまずは回避できました。

同じような問題が起こっている場合は試して見てください。

今回は、ここまで。

おしまい