ドコモで新規契約したときはギガライトに変更予約してから、翌月にahamoに切り替えるのがよい

要約

ドコモで新規契約したのちにahamoに変更しようと考えている場合、以下の流れで行動すると支払いを少なくできる。

  • ギガライトへの変更予約をする
    • 翌月からの適用
  • 月が変わりギガライトに変わったら、ahamoへ変更する
    • ahamoの方が利用できるデータ量が多いので早めに変更するのがいい

ヨドバシカメラの店員さんが教えてくれた。聞いたときはよくわかってなかったけど、親切な店員さんありがとう。

説明

ドコモの新規契約時は料金は日割り。なので、月末近くに契約すると支払いが少なくなる。例えば、7000円のプランを月末2日前に契約すると470円の支払いで済む。

ahamoはドコモ内での契約プランの一種という位置付け。MNPではない。なので、新規契約してすぐにahamoに変えても、今のところはペナルティーはない、らしい。

ahamoに契約変更するとき、元がギガホ系の場合、元の契約プランの料金が請求される。この場合は日割りはされず満額が請求される。解約とかと同じイメージ。

ドコモのプランから初めて変更する場合、変更前のご契約プランによってかわります。
【5Gギガホ プレミア、5Gギガホ、ギガホ プレミア、ギガホ2、ギガホから変更した場合】
元のプランの料金が請求されます。
【5Gギガライト、ギガライト、ケータイプラン、はじめてスマホプラン、U15はじめてスマホプラン、データプラス、キッズケータイプランから変更した場合】
ahamoの料金が請求されます。

ドコモからahamoへ変更した場合、適用時期や変更月の料金はどうなりますか? | よくあるご質問 | ahamo

そうなると、上記の初月の日割りのメリットが失われてしまうので、あらかじめギガライト系に変更した上で、翌月にahamoに変更すると支払いが少なくできる。

Renovateのどこがいいのかを調べた(Dependabotと比較して)

Dependabotの代替としてRenovateが選ばれることが最近は多いらしい。理由が気になったので調べてみた。

Dependabotとどう使い分けるかの結論

DependabotはGitHub謹製という安心感が大きいのと、設定がシンプル。

どちらが優れているとかじゃないので好みでいい。だけど、以下の特徴に書いた、monorepo, ノイズを減らす、とかに価値を感じるなら、Renovateがいい。あとは、GitHub Actionsでsecretsにアクセスできるというのも選ぶポイントになるかもしれない。

Renovateの特徴

Mend Renovate: Automated Dependency Updates

依存性更新ツール。大きな特徴は以下の3つ。

  • Opinionated(設定が空でも動く)
  • monorepo構成をサポート
  • ノイズを減らすことにフォーカス

Dependabotを比較しての違い

  • デフォルトでの振る舞いが定義されているので、設定ファイルが空でも利用できる
    • Opinionatedなところが最近のツールっぽい。prettierみたい
  • monorepo構成をサポートしている
  • テストが通る更新なら自動でマージさせることができる
    • minor以下みたいな条件設定ができないから怖いんだけど
  • GitHub Actionsでsecretsにアクセスできる
    • pull_request_target イベントを使わなくてよかったり、(github.event_name == ‘pull_request_target’ && github.actor == ‘dependabot[bot]’) の分岐を入れなくてよかったりする
  • git-submodules, .circleci/config.ymlとかも対応している
  • 設定がめちゃめちゃ細かくできる
  • PRをグルーピングできる

加湿器について調べてダイニチの気化式 HD-154 を買った

結論

ダイニチのHD-154が安くなったのでジョーシン楽天のストアで買った。39,000円。

【楽天市場】HD-154-W ダイニチ ハイブリッド式加湿器(木造25畳まで/プレハブ洋室42畳まで ホワイト) DAINICHI [HD154W]:Joshin web 家電とPCの大型専門店

スーパーセール中でポイント率が25倍とか行くと7,000ポイントくらい返ってくるので非常にお買い得。

届いて使い始めた。機能がシンプルで良い。

HD-154がずっと欲しかったんだけど、10月頃は時期的にニーズが高い時期で44,000円くらい。5月頃だと35,000円とかなので、ちょっと高いので様子見。

様子見していたら、12月に入ってガクッと下がって39,000円になり、その影響でコジマネット、ヤマダウェブコムでも36,000円くらいで扱いだした。これくらいならどこで買ってもいいと思う。

価格の推移

方式を決める

蒸気式、気化式、超音波式などがあるが、気化式、ないし、ハイブリッド気化式以外は常用できない。

気化式/ハイブリッド気化式

気化式とハイブリッド気化式の違いは温風がでるかどうか。後者が温風が出る。気化式はパナソニック、ハイブリッド気化式ならダイニチ。ハイブリッドの方が暖める分、消費電力が大きい。かなり大きい。消費電力が300Wとか600Wかかる。

でもダイニチの製品ならecoモードという、温風無しにできるモードがある。 太陽光発電がついているなら、日中は通常モード、夜間はecoモードという使い方もあり、だけど、モード変更が面倒か。

蒸気式

沸騰させて蒸気を出すので、加湿量はものすごく多いし、カビなども生えにくい。フィルター交換不要でメンテは月一のカルキとりくらいでラク

反面、沸騰させ続けるので、電気代がものすごくかかるし、蒸気は高温なので子供が居ると危ない。

蒸気式は象印が強い。

メーカーを決める

気化式を使いたいので、パナソニックかダイニチ。

パナソニック

暖めない気化式だしDCモーターなので消費電力が低いのが優れているが、タンク残量が見にくいし、メンテナンス性も悪い。

ダイニチ

暖めるタイプのハイブリッド気化式が基本だが、消費電力が高すぎるのでそれは使わないで、通常の気化式になるecoモードを基準にして考える。ecoモードだとしてもパナソニックより消費電力が高いが、パナソニックなら150円のところがダイニチで500円くらいには収まるので、消費電力の違いについては無視できる。また、ダイニチの機種はタンク残量が見やすく、水トレーが丸ごと交換できるのでメンテナンス性も高いのがメリット。

なので、基本的にダイニチの機種を選ぶので良いと判断する。

機種を決める

パナソニックなら

  • FE-KXU07, FE-KXU05などのスタンダードモデルはタンク容量が4.2Lしかないので対象から外す
  • FE-KXP23, FE-KXP20とかなら、タンクは6Lx2で、弱モードだと1000mL/hで消費電力も8W
  • FE-KXF15もいいんだけど、弱モード時の消費電力がFE-KXP23, FE-KXP20より高いのに、加湿性能が低いので、効率が悪い

FE-KXP23, FE-KXP20は電気代が25.51円なら147円。すごい安い。ただし、FE-KXP23, FE-KXP20はタンクの残量がすごく見にくい。メンテナンスもしにくい。

参考価格 FE-KXP20 10月頃は¥44,000だった https://kakaku.com/item/K0000985328/

ダイニチ

標準モードは加熱するので消費電力が300Wとか600Wとか高すぎるので基本は使わない。加熱しないecoモードを基本に考える。 ecoモードでも1200mL/hとか1500mL/h加湿できる、HDパワフルシリーズが良い。タンク容量も6L*2だし。でも、消費電力が28Wとかで、パナソニックと比べると高い。 24時間使う場合で計算してみる。

282430=20160 25.51円/kWhなら514円

冬の間しか使わないし、514円なら許容できる。

モデルの説明

  • LX
    • ハイエンドモデル
    • タンク容量や加湿量が多い
    • スマートリモコンに対応
  • RX
    • ミドルレンジモデル
    • LXとHDの中間くらい
  • HD
    • スタンダードモデル
    • タンク容量が小さい
  • HDパワフル
    • タンクが2個あって加湿量もLXより多い。余計な機能もないのでこれが一番いい。
    • HD-154, 184, 244
    • HD-1500F, 1800F, 2400F
    • 154系と1500F系の違いは、トレイカバーの有無が大きい
    • 154系にはある。トレイカバーがあると水垢の清掃の手間が減るのである方が嬉しい

ダイニチプラス HD-154 https://kakaku.com/item/K0001281810/

ダイニチプラス HD-1500F 参考価格 最安価格(税込):¥39,916 https://kakaku.com/item/K0001372959/

ダイニチプラス HD-RX920(W) [クリスタルホワイト] 参考価格 最安価格(税込):¥18,800 https://kakaku.com/item/K0001282365/

HD-RX920が安いけど、ecoモードでの加湿量が460mL/hしかないのでちょっと不安。HD-154ならecoモードでも1,200mL/hあるので安心感がある。

比較シートを作って検討した。

ダイニチの比較シート

参考情報

GitHub Actionsでの処理の再利用(Reusable Workflows, Custom Actions)について整理

処理を再利用したいときには、以下の方法があり、それぞれで呼び出しのレベルが異なっています。

  • Reusable Workflows
  • Custom Actions (Composite Action)
    • Stepの一つとして呼び出す
    • jobs.<job_id>.steps[*].uses シンタックスで呼び出す

なので、どういうレベルで呼び出したいかや処理の粒度で、workflowにするかactionにするかを選ぶと良いと思います。

ログの出力も少し違っていて、Reusable Workflowsの方が見やすいですが、どちらも見ることはできるのでそれほど困らないはずです。

checkoutの振る舞いの違い

GitHub Actionsのご紹介と弊社での利用について - Stanby Tech Blog に書いてくれていますが、以下のように違います。

  • Composite Action
    • Composite Actionを定義している側のリポジトリのリソースをcheckout
  • Reusable Workflow
    • Reusable Workflowを利用している側のリポジトリのリソースをcheckout

Composite Actionはステップの一つなのでそうなるのも理解しやすいですし、大元のワークフローの方でcheckoutするはずなので、この点はとくに問題にはならないと思います。Composite Actionでチェックアウトしたくなったら、Reusable Workflowへの変更を考えるのが良いでしょう。

Workflowなどをプライベートリポジトリーに配置したら再利用できない

現状ではできません。認証が通らないので、パブリックリポジトリーに置かないといけないです。それが憚られる場合は、暫定措置として、ファイルをコピーして別プロジェクトに展開するのが今のところの妥協案かなと思っています。

-   Both workflows are in the same repository.
-   The called workflow is stored in a public repository, and your organization allows you to use public reusable workflows.

Reusing workflows - GitHub Docs

Private Access Tokenを使ってチェックアウトすれば当然リポジトリーを参照できますが、権限が大きすぎるし個人に依存するし、詐称してなんでもできてしまうのでこれは使うべきではないでしょう。

- name: Checkout private tools
  uses: actions/checkout@v3
  with:
    repository: my-org/my-private-tools
    token: ${{ secrets.GH_PAT }} # `GH_PAT` is a secret that contains your PAT
    path: my-tools

GitHub - actions/checkout: Action for checking out a repo

一応、イシューにはなっており、 Actions: Reusable workflows work with private repositories · Issue #51 · github/roadmap · GitHub ロードマップ上では 2022Q4が目標になっているので、注視したいところです。どうやって権限を移譲するのかがイメージついていません。 GitHub public roadmap

Reusable Workflows

Reusing workflows - GitHub Docs

基本的にドキュメントの通りですが、いくつかポイントがあるので記します。

呼び出しの記述

以下のようにファイルパスまで指定します。

jobs:
  call-workflow-1-in-local-repo:
    uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89 # local repo
  call-workflow-2-in-local-repo:
    uses: ./.github/workflows/workflow-2.yml # local file path
  call-workflow-in-another-repo:
    uses: octo-org/another-repo/.github/workflows/workflow.yml@v1 # another public repo

ファイルパスまで指定するので .github/workflows ディレクトリーじゃなくてもいいかと思ったんですが、以下のエラーになって実行できません。

invalid value workflow reference: references to workflows must be rooted in '.github/workflows'

Custom Actions (Composite Action)

カスタムアクション自体は以下の3つの選択肢があります。

  • Docker container Action
    • コンテナー内で実行できるのでミドルウェアを利用するような処理を書ける
  • JavaScript Action
    • Node.jsで実行できるので複雑なロジックを書くことができる
  • Composite Action

それぞれ使い道があるので使い分ければいいですが、Composite Actionが実行が速くて手軽なので基本的にこれを使うのが良いはずです。

Creating a composite action - GitHub Docs

ディレクトリ構成

規定されていませんが、以下が推奨されています。

.github/actions/action_name

Composite Actionのシンタックス

通常のworkflowと少しだけ違うので以下を参照してください。

Metadata syntax for GitHub Actions - GitHub Docs

呼び出しの記述

以下のようにフォルダー名までを指定します。action.ymlは暗黙で補完されます。

    steps:
      - uses: actions/checkout@v3
      - uses: ./.github/actions/first_action # local folder path
      - uses: octo-org/this-repo/.github/actions/first_action@main # local repo        

ローカルフォルダーパスで実行する場合は事前にチェックアウトが必須ですが、ローカルリポジトリー形式だとチェックアウトは不要です。 チェックアウトをしない関係なのか、ローカルリポジトリー形式の方が実行完了が速いです。

ワークフローとアクションは相互運用できない

Reusable Workflowをstes.usesシンタックスで呼ぼうとすると以下のエラーになります。

reusable workflows should be referenced at the top-level `jobs.*.uses' key, not within steps

Custom Actionをjobs.usesシンタックスで呼ぼうとすると以下のエラーになります。そもそもCustom Actionはworkflow_callトリガーを実装しないので無理がありますね。もし、実装したとしても多分実行できないはず。

invalid value workflow reference: references to workflows must be rooted in '.github/workflows'

アトミックな操作をしたいときのロック状態の作り方

Crontabで実行しているバッチで重複した実行をしてほしくないときにロック状態を作ったりしますが、どうやるのがいいのかの選択肢を整理。

令和の時代と思えない話だけど今も必要な話だった。

おおむね、サイボウズのsatさんの書いていることを確認した感じになります。 https://zenn.dev/satoru_takeuchi/articles/e0636407a0040c

選択肢は以下。

おすすめは一番最後のファイルロック。

汎用性のある話なので、Linuxのコマンドで例を書いています。高等言語でもたいていラッパーがあるし。

ロックファイルを作る

if test -e /var/lock/foobar
then
  exit
fi
touch /var/lock/foobar

# do something

rm /var/lock/foobar

最初でファイルの有無を確認し、なければ作成して続行。処理の最後で削除する。プリミティブ。

単純だけどあんまりおすすめはしない。

  • Pros
    • 単純
  • Cons
    • 確認と作成に時間差があるので、その隙間で重複実行されることがあるかもしれない。crontabからの実行とかなら問題となりにくいけど
    • プロセスが途中で死ぬとロックファイルが残ってしまう
    • ロックファイル名が衝突する可能性がある

シンボリックリンクを作る

ln -s $0 /var/lock/foobaz

# do something

unlink /var/lock/foobaz

ln -s は既に存在していたらexitcode 1を返す。なので、存在確認と作成を同時にできるので、時間差がない。

  • Pros
    • 時間差がないので、隙間で重複実行のリスクがない(はず)
  • Cons
    • プロセスが途中で死ぬとロックファイルが残ってしまう
    • ロックファイル名が衝突する可能性がある

pidofコマンドでプロセスがあるかを調べる

/usr/sbin/pidof -x cron_job.sh >/dev/null || /path/to/your/cron_job.sh

一番簡単かもcron起動プロセスの多重起動防止ワンライナー - Qiita

ワンライナーでやるならこれがいいかも。だけど、プロセスを探すときのクエリーを間違えそう。引数が多い時とか特に。

  • Pros
    • 解除処理が不要
    • プロセスが途中で死んでも問題ない
    • ファイルに頼らないので、ファイル名の衝突などのリスクがない
  • Cons
    • プロセスを探すときのクエリーを間違えそう

実行スクリプト自身をファイルロックする

flock -xn foobar.rb vi foobar.rb

Exclusive, non-blockingのオプションをつければ、実行プロセスは一つにして、他のプロセスは待たせないですぐ完了にできる。これが一番いいと思う。

  • Pros
    • 解除処理が不要
    • プロセスが途中で死んでも問題ない
    • ファイルに頼らないので、ファイル名の衝突などのリスクがない
    • スクリプト自身をロックすれば依存するものを減らせる
  • Cons
    • ないと思う

Rubyでの実装例

以下、Rubyでの実装例

def main
  puts "Start #{Time.now}"
  locked = lock_myself
  if locked
    puts "Grab lock, Stay running"
  else
    puts "Quit due to process duplicated"
    return
  end

  sleep_sec = 65 
  puts "sleep #{sleep_sec} sec"
  sleep sleep_sec
  puts "Completed"
end

def lock_myself
  f = File.open(__FILE__, "a")
  # ロックが取れない場合、falseを返す
  f.flock(File::LOCK_EX | File::LOCK_NB)
end

main

こんなスクリプトが以下のようにcrontabに登録されていると、

ubuntu@ip-172-31-10-98:~$ crontab -l
* * * * * ruby /home/ubuntu/flock_test.rb  >> /var/log/cron_log

以下のように出力される。

出力の順番がずれているのは、スクリプトの完了時に標準出力がフラッシュされるため。ロックが取れないケースの方が先に完了するので先に出る。

ubuntu@ip-172-31-10-98:~$ tail -f  /var/log/cron_log 
Start 2022-10-17 04:09:01 +0000
Quit due to process duplicated
Start 2022-10-17 04:08:01 +0000
Grab lock, Stay running
sleep 65 sec
Completed
Start 2022-10-17 04:11:01 +0000
Quit due to process duplicated
Start 2022-10-17 04:10:01 +0000
Grab lock, Stay running
sleep 65 sec
Completed
Start 2022-10-17 04:13:01 +0000
Quit due to process duplicated
Start 2022-10-17 04:12:01 +0000
Grab lock, Stay running
sleep 65 sec
Completed
Start 2022-10-17 04:15:01 +0000
Quit due to process duplicated
Start 2022-10-17 04:14:01 +0000
Grab lock, Stay running
sleep 65 sec
Completed

プランが変わったSlackの代替を探したけどDiscordもTeamsもフィットしなかった

やりたいこと

  • 用途ごとにチャンネルを分ける
  • RSSフィードの購読
  • Trelloの更新通知の受付
  • webhookの利用
  • チャットログのエクスポート
  • (optional) チャットログのインポート

Discord

インポートができないのはいいけど、エクスポートもできないのに驚いた。 RSSフィードの購読も機能としてない。IFTTTやMonitoRSSを使うことになるけど、

  • IFTTTは一つのアプレットで一つのフィードを登録する。フィードを登録しまくるというのができない
  • MonitoRSSは無料だとフィードは5つまで
    • Patreonで$1のサポートをすれば200まで登録できるのでサポートするのも全然アリ

という感じ。Zapierを使うのがいいんだろうか。 次を調べる。

Microsoft Teams

2021年5月の更新で個人向けが追加され、職場向けのものと別物になってしまった。

Microsoft、無料の個人向け「Teams」機能を正式リリース ~仕事用の「Teams」と併用可能 - 窓の杜 家庭向け Teams を友達や家族と一緒に | Microsoft Teams

画像 Microsoft、無料の個人向け「Teams」機能を正式リリース ~仕事用の「Teams」と併用可能(1/5) - 窓の杜

個人向けではできないことが多い。チャンネルを分けることもできないし、インテグレーションを追加することもできない。

暫定の結論

Slackを使い続けて、定期的にバックアップをとる、みたいな。

Slackの家庭内日記をはてなブログに同期していく - すぎゃーんメモ を真似したい。

Rails6, 7でのdb系rakeタスクの確認

この辺いつも忘れるのでメモ。 あと、paperclipを削除するときにmigrationファイルの add_attachment が残ってしまう問題があったので、どう影響するかの確認のためでもある。

db:migrate

migrateファイルを日付け順に実行する。なので、削除された外部依存(e.g. paperclipの add_attachment )があればそこでundefinedのエラーになる。

db:schema:load

schema.rbから実行する。migrateファイルは実行しない。速いのでいいのだけど、

execute (“ALTER TABLE apples AUTO_INCREMENT = 9999”)

みたいなのはschemaに載らないので実行されないのに注意。

db:prepare

6以降のbin/setupからはこれが呼ばれる。以下の挙動の通りなので、普段はこれ呼ぶだけでもいい。

DBがなければ以下を実行。

  • db:create
  • db:schema:load
  • db:seed

DBがあれば以下を実行。

  • db:migrate

db:setup

DBがなければ作り、あってもスキーマロードを実行する。なので、普段からこれを使うことはない。

  • db:create
  • db:schema:load
  • db:seed

db:truncate_all

テーブルを全部truncateしてくれる。 Rails6の時点でヘルプに出てこなかったけど存在している。 rails/databases.rake at d5fc7da4c39470a8f5b0055eddc2d1bca2d034e3 · rails/rails · GitHub

paperclipを削除して困らない?

困らないので削除していい。

削除して困るのは一から db:migrate を実行するケース。

本番環境では、最初からmigrateすることはない。

開発環境では、 db:prepareスキーマロードするのでいい。ALTER TABLE が走らないけど開発環境なら支障はない。

ステージング環境を増やすみたいなときは、既存の環境のデータを持ってきて、 db:truncate_all すればいい。そしたらデータがなくてAUTO_INCREMENTが進んだ状態を作れる。

ということで、マイグレーションを一から実行することはないので、squasher gemみたいなのは使う意味がないと思う。