Sheeprograming

https://github.com/Shunshun94/ytsheet_sw2.5/blob/57e6656c554678ea2accbcd27e69601c0520381e/_core/lib/sw2/client-ytsheet_one_mons.pl
書いた。このコードからだと perl client-ytsheet_one_mons.pl https://yutorize.2-d.jp/ms_sw2/s/data/1579365932.htmlとすれば動く。でも、これを本体に取り込んでもらうのはちょっとむずかしい気がしてはいる。ここからどう改修したものかねぇ。

うちの次男が時計を読めるようになった。保育園の同期の中では最速らしい。

最近は時計を見ては読み上げている。かわいい。

最近、障害発生時にあがってくる恒久対応策に対してフィードバックコメントを返す機会が多い。以下の場合はだいたい突っ返している。

ミスした人に「注意喚起」するのを恒久対応策とする

ミスをするということはミスをする構造になっている、ということである。多少注意を促したところで「多忙だったから」「焦っていたから」で同じ事故が発生するのは目に見えている。ミスするような部分を機械化するなどして対応を行うのが正解。次善の策としてプロセスでカバーするという策もあるが、工数が単純に増えるためあまり良くない。ただただそのメンバーの注意欠陥で障害が発生するのであれば、そのメンバーには別のタスクを割り当てるべきだ。ただし、有効な恒久対応策が実現するまでの時間稼ぎとしての実施であれば許容する。

意味のないダブルチェックやトリプルチェックである

ダブルチェックに意味がない、とは言い難いし、意味がある場面もある。しかし、単純作業としてのダブルチェックには意味がない。ダブルチェックが提案された場合にそのダブルチェックに意味がありそうか否かを確認すること。同じことを違う人が確認するだけならばそのダブルチェックには意味がない。別の人に「検算させる」ものであると上手く行くかもしれない。ただし、有効な恒久対応策が実現するまでの時間稼ぎとしての実施であれば許容する。

原因不明なので恒久対応策しない

ログが足りないとかそういったことで原因が追えないことは現実的に発生し得る。そうであればどんなログを足せばいいのか、どんな初期対応を次は行うべきなのかを記載して「これで次は恒久対応策を練られるようにする」等といった対応を行う。ただで転んではならない。

実行にデカいデメリットがある

実行した結果デグレが発生したり、特定の超人に依存した策だったりする場合は無論不可とする。ただし、多少のデメリットについては甘受するべき場面もあるので相談が必要である。恒久対応策の提案者ではなく、より上の立場の人がジャッジするべきことかもしれないので場合によっては偉い人にエスカレーションすること。

だが、運用に直に入っていない人間が恒久対応策の話を聞いても的外れなフィードバックを返してしまうこともある。運用に入って実情を知れていればいいのだが、そうでない場合は当人と会話してコンテキストの差を埋める方がよい。

所用で必要だったのでメモメモ。

const MYSQL = require('mysql'); // 事前に npm install しておく
const TUNNEL = require('tunnel-ssh'); // 事前に npm install しておく
const FS = require('fs');

// 経由するサーバに SSH するための情報。無論適宜変える事
const sshParam = {
  username: 'hiyoko',
  host: '192.168.22.17',
  port: 22,
  privateKey: FS.readFileSync('hiyoko-server.pem'),
  dstPort: 3306,
  localhost: 'localhost',
  localPort: 3306
};

// mysql サーバに接続するための情報。無論適宜変える事
const mysqlParam = {
  host: 'mysql.hiyoko.example.com',
  user: 'mysql-user',
  password: 'myStrongestPassword',
  database: 'hiyoko' // 特定の DB に入りたいわけでないのであれば書かない
};

const connectToDb = (connection) => {
  return new Promise((resolve, reject)=> {
    connection.connect((dbConnectErr)=>{
      if(dbConnectErr) {
        console.error('DB への接続に失敗したよ');
        reject(dbConnectErr);
      } else {
        console.log(`DB に接続できたよ スレッド ID は ${connection.threadId}`);
        resolve(connection);
      }
    });
  });
};

const disconnectFromDb = (connection) => {
  return new Promise((resolve, reject)=> {
    connection.end((dbDisconnectErr)=> {
      if(dbDisconnectErr) {
        console.error('DB との切断に失敗したよ');
        reject(dbDisconnectErr);
      } else {
        console.log('DB と切断したよ');
        resolve(connection);
      }
    });
  });
};

const requestQuery = (connection, sql) => {
  return new Promise((resolve, reject)=> {
    connection.query(sql, (requestErr, results, fields)=> {
      if(requestErr) {
        console.error(`DB へのリクエスト ${sql} が失敗したよ`);
        reject(requestErr);
      } else {
        resolve({
          results: results,
          fields: fields
        });
      }
    });
  });
};

const sshTunnel = TUNNEL(sshParam, async (sshErr, tunnel)=> {
  if(sshErr) {
    throw sshErr;
  }
  const connection = MYSQL.createConnection(mysqlParam);
  await connectToDb(connection);

  /* 以下で DB の処理とかをがちゃがちゃ */
  const queryResult = await requestQuery(connection, 'select * from aTable;');
  console.log(queryResult);

  /* 終わったら切断する */
  await disconnectFromDb(connection);
  sshTunnel.close();
});

Herokuでdiscord-bcdicebotを動かす - 恐竜の化石掲載の手順で Discord-BcdiceBot を Heroku 上で動かすことができる。サーバのメンテナンスコスト無しに 24365 で bot を動かすことができるのである。

今回、この手順の為に必要なファイルについて PR を頂いたので、動かすための手順を追記したものを 2.2.0 として公開する予定。楽しみだがプライベートが忙しくてなかなか進められていない。