自分に通知を送る

人生には、自分に通知を送りたくなることがよくある。例えば、

$ tar xf 開くのにめっちゃ時間がかかるクソでかファイル.tar.gz 

ってしたときとか、あー終わったら呼び出してくれないかなぁって思うことがあると思う。
他にも、これは時間がかかりそうだなーという、なんかしらのコンパイルをするときとか、終わるまで待つのはだるいけど、でも終わったらすぐに結果が確認したい。そういうことがあるとおもう。
この手のまとまった時間が必要になるコマンドの実行が終わるまでは、液晶ディスプレイの前から離れて、まぁお茶でも飲んでおこうかな、って思うのが人情である。

これは、よくある問題である。
みんな、こういうとき、どうしているのだろうか。
自分は、url を叩いたら自分にメールを送るような仕組みを作って、コマンドが終わったら、その url を叩くようにしている。

やっていること

で、自分はこういうときのために、適当に url を叩くと、自分のスマホにメール(MMS)を送れるような簡単な web サービスを、6年くらい前にふと思い立って作った。
つまり、下のようなコマンドを打つと、結果的に自分のスマホに SAMPLEMESSAGE って本文に含まれたメールが届くようになっている。

$ curl "https://exampleserver.jp/yobidashi?msg=SAMPLEMESSAGE"

といっても、exampleserver.jp/yobidashi でやってることはアクセスが来たら、smtp サーバにアクセスし msg の内容を含むメールを送るだけである。

で、実際には、zshrc の中に更にこんな感じに書いている。

function sntfy() {
  curl --silent "https://https://exampleserver.jp/yobidashi?msg=$1" > /dev/null
}

なので実際には、こんな感じで使う

% tar xf 開くのにめっちゃ時間がかかるクソでかファイル.tar.gz ; sntfy tar_open_finished

これで、開くのにめっちゃ時間がかかるクソでかファイル.tar.gzを開いている間に優雅にお茶を飲みつつ、終わったら自分のスマホにメールが届き、tar.gz 内の内容を確認することができる。

懸念点

url を叩くと、今のところ、手元のスマホに push 配信され、届くのがはやいスマホのキャリアメールを使うようにしている。

でも、いつまでもキャリアメールがついているような高い携帯電話のプランを使わずに、格安スマホに変えたいなと思っている。
そうすると同様の仕組みは使えなくなる。

で、どうやら、最近は iPhone をはじめとするスマホでも web notify というブラウザ経由で web サーバーから手元のスマホに通知を送る仕組みがあるらしい。
色々調べてこっちを使う仕組みに切り替えたいなぁと思っている。

おわり

時間がかかる処理が終わったら自分に通知を送るために自分がやっていることについてざっと書いた。
よくある問題だと思うので、他の人がどうしているのか気になる。
みんなどうしてるのか教えてほしい。

自作レバーレスコントローラーの基板を GP2040 ベースに変えた

2年半前くらいに、自作のレバーレスコントローラーを作った。
そのときには、 pro micro を使って、この上で動くコードはライブラリを利用しつつも主要な部分は自分で書いていた。

2年半時間が経過して、レバーレスコントローラーの自作はかなり一般的になった。
また、Raspberry PI Pico が発売されて、これの上で動くコントローラー用のソフトウェア GP2040 が開発された。
GP2040 は開発体制が変わったのか、オープンソースで開発が続けるコミュニティ版がフォークして、今は、GP2040-CE という名前で開発が続いているように見えた。

自分としてもいつまでも pro micro で動くコードの面倒を見るのはたいへんなので、GP2040-CE に乗り換えることにした。

配線をどうするか

pro micro でレバーレスコントローラーを作っていた頃は、ユニバーサル基板を使って気合いでボタンを配線していた。
でもまぁ、なんかそれも面倒なので、今回は pro micro 用のターミナルブロックを使うことにした。

例えばこういうの。aliexpress で送料も含めて 1000 円以下で買える。

今回は面倒なので、amazon で似たようなものを買った。

GP2040で使うことを想定した PICO Fighting Boardってのもあるみたいで、これも高くはないのだけど、トータルの値段で言えば汎用のターミナルブロックを使うんでいいような気がする。

GP2040-CE への独自機能の移植

pro micro の頃に、ミスタードリラーやテトリスなどのパズルゲームを遊ぶときに、斜め入力が入るのを避けるため、方向キーについて、最後に押したものを優先して入力として扱うような機能を実装して、設定で切り替えられるようにしていた。

GP2040-CE に乗り換えるにあたり、この機能を移植したいと考えた。

GP2040-CE は、オープンソースである。
なので、ビルド環境さえ整えてしまえば独自の機能を追加できる。
しかも、ソースコードを眺めていたところ追加機能を作りやすいように、プラグイン用のインタフェースがコード内に用意されていることが確認できた。

なのでさっと作った。

この機能が欲しい人居るんだろうか。いればプルリクエスト送ってもてもいいのかもしれないけど、、

GP2040-CE は、2023年の頭くらいにいくつかの git submodule に分割された。
その影響で、変更が複数のレポジトリにまたがる形となって若干面倒ではあった。

あと、Build 手順のドキュメントが古く、2023年4月1日時点では、書いてある通りにビルドすることはできなかった。
けど、 issue に手順をアップデートする予定があることが記載されているので、そのうち改善されると思う。

レバーレスコントローラー(hitbox あるいはガフロコンって呼ばれるもの)を作った。格ゲーにおける優位性をちょっと測定した。

ふと、手元にあった、ピンの少ない Sparkfun Pro Micro 互換機で、ゲーム用のコントローラーを作ってみたらそれなりに作れたので、通常通りにピンが付いている Sparkfun Pro Micro を買ったり、ドリルを買ったりホールソーを買ったり、ボタンを買ったりしてレバーレスコントローラー自作してみました。


本 blog エントリではこの自作したレバーレスコントローラを自作レバーレスコントローラーと呼びます。また、製品として売られているレバーレスコントローラである HitBox を hitbox と呼びます。

普通、レバーレスコントローラーを作る場合には、あり物のコントローラーの基板を乗っ取ったり、あるいは Brook の UNIVERSAL FIGHTING BOARD を基板として使うのが定番のようです。Brook の UNIVERSAL FIGHTING BOARDは12000円くらいします。でも今回は、既存のコントローラーの基板やBrook の UNIVERSAL FIGHTING BOARD の代わりに Sparkfun Pro Micro とこれの上で動く自作のプログラムで代用したので、2000円くらいで済ますことができました。もしも Pro Micro 安い互換機を使えば更に安くすることができますね。

ちなみに、今回作った自作レバーレスコントローラーで使ったSparkfun Pro Micro は2000円くらいで、それ以外のボタンやケースやら配線のためのもろもろが6000円で、合計8000円くらいでした。ちなみに、 PC と Nintendo Switch で使えることは確認済みでです。一方 PS4 では使えないことを確認しています。でも、PS4でそんなにゲーム遊ばないから、今回はこれで良いということにしています。

レバーレスコントローラーと SOCD (Simultaneous Opposite Cardinal Direction/反対方向同時入力)

今回、わざわざ Pro Micro を使ったのは、安く仕上げるためであると同時に、コントローラーの挙動を細かく変更するためでもあります。

レバーレスコントローラーの作成にあたっては、SOCD(Simultaneous Opposite Cardinal Direction/反対方向同時入力)に対する考慮が必要となります。
SOCDとは、通常、レバーや十字キーでは入力できない、左右の同時押しあるいは上下の同時押しをどのように扱うかについてのアルゴリズムのことです。

格闘ゲームにおける SOCD

hitbox では、左右同時押しは横方向はニュートラルとして扱い、上下の同時押しは上入力として扱われます。格闘ゲーム向けのにおいては、この hitbox の SOCD の扱いが、デファクトスタンダードとなっているようです。
Brook の UNIVERSAL FIGHTING BOARDは、ジャンパピンを用いた設定により、hitbox と同等とすることが可能です。

レバーレスコントローラーの格闘ゲームプレイ上の利点の定量化

格闘ゲームにおいて、レバーレスコントローラーによる操作は、一部レバーを用いた従来のコントローラーよりも高速に可能であるとして、多くのプレイヤーが現在利用していることがインターネットを検索することによって確認できます。
しかしながら具体的にはどの程度有利であるかについては、レバーレスコントローラと従来のレバーによるコントローラそれぞれの操作の習熟度に伴い個々人で異なること、またその簡易な計測方法が存在しないことといった理由で、計測が行われてこなかったのではないかと考えました。

そこで今回、キーディスプレイおよび各入力の継続フレームの表示のみを行うプログラムを unity を用いて作成し、これを用いて測定を行える環境を作りました。

まだ十分な回数をこなせておらず、統計として不十分なので、いくつかの測定結果及び感想を書いておきます。
なお、自作レバーレスコントローラーの SOCD は、hitbox に準拠した設定としています。また、比較対象に使っている通常のレバーありコントローラーには、 RAP V4 隼を用いました。

計測対象 自作レバーレスコントローラー レバーありコントローラー
←ため→ のニュートラル経過フレーム数 0フレームあるいは1フレーム 1から3フレーム。8割くらい2フレーム。
標準的な昇龍拳入力開始から完成まで(623入力) 7フレームくらい 7フレームくらい
昇龍拳のhitbox 向け入力開始から完成まで(639入力) 大体6フレームくらいだけど4フレームで完成したときもあった やってない

回数をこなした統計は、また追々測って行こうと思います。

あと、すでにレバーレスコントローラーの操作になれた人のフレーム情報も見てみたいので、汎用的な作りにして配ったりしたい。
今は、とりあえず図り始められる環境を作ることを優先して、PC環境依存でベタ書きになっていて人に配れたものではないので。

格闘ゲーム以外における SOCD

現在、製品として入手可能な hitbox を始めとするレバーレスコントローラーは格闘ゲーム用に使うことを想定している事が多いですが、もちろん他のゲームに使うことも出来ます。
ただし、他の種類のゲームに用いるときには、 SOCD の扱いは格闘ゲームとは別の考え方をするべきなのではないかと考えています。
通常 SOCD は、左右の同時押しあるいは上下の同時押しを考慮しますが、斜めの入力を行う必要がなく上下左右の4方向の入力のみを想定するテトリスなどのパズルゲームでは、格闘ゲームでの利用を想定した SOCD とは異なるアルゴリズムがより適しているのではないかと考えていました。例えば、上下左右の4方向をすべて排他し、最後に押されたものを優先するのが良いのではないかと考えました。
このような SOCD についての挙動の変更は、既存のコントローラの基板や Brook の UNIVERSAL FIGHTING BOARD では実現不可能であるため、これを自由にコントロールするために、Pro Microで自作する必要がありました。

格闘ゲーム以外においてはどうするのが良いのかについても追々考えていきたいですね。

twitterで最近tweetしてないアカウントに対するfollowをやめるためにいろいろした

もうずいぶん前にGeForce1080を買って、今更ながらdeep learningでもやってみるかーって思っていたんですが、
そもそもそんなにpythonを書いたことがないということに気づいた。

そうだpython書こう

なにかpythonを書く口実がほしい、と思ったので、
pythonでtwitterのapiを叩いて、フォローしているかカウントの中から、
ここ最近tweetがないアカウントを洗い出して、そのアカウントをチェック、
気分でフォローをやめる、という作業をした。

特定の条件で自動的にフォローをやめるのは事故りそうだから、
フォローをやめる候補のリストアップだけpythonのコードでやって、
最終的な判断は自分でした。

pythonには、候補のアカウントに対するリンクを並べたhtmlを適当の吐かせた。
そのhtmlのリンクを自分が叩いて、各アカウントを自分で確認した。

適当に有り物のライブラリを叩いただけで、技術的に面白いことはなにもないので技術的なところは省略。

最近tweetがない の条件

最近tweetがないと判断する条件については、2018年に入ってからのtweet回数が30回以下である、とした。
2018年5月22日のお昼すぎの時点で、自分は2283人をフォローしており、
そのうち2018年に入ってからのtweet回数が30回以下のアカウントは、490個あった。

先述の通り、これらのアカウントに対するリンクを並べたhtmlを作成して、見て回った。

こんな無味乾燥なhtmlを吐いた。490人分ある。

最近tweetがない人のパターン

最近tweetがない人については、ふわっとした感覚だけど、いくつかパターンが有るように思った。
パターンの集合に重複があったりするけど、適当なので許してほしい。

  1. よくわからない外国人(何かのwebページにアクセスするための条件みたいになっていて、その際にフォローした?)
  2. 閉店してしまったお店のアカウント
  3. サービス停止してしまったwebサービスのアカウント
  4. 開発が終わってしまったスマホアプリの公式アカウント
  5. 終わってしまったイベントのアカウント
  6. 使わなくなってしまった個人アカウント
  7. 利用者が亡くなってしまった個人アカウント
  8. ただ単純にtweetの頻度が低いもの

ただ単純にtweetの頻度が低いものが結構な数あって、「2018年に入ってからのtweet回数が30回以下」という条件は、
若干厳しすぎたかなーって思った。

上にあげたパターンのうち、1.~5.については全部フォローを辞めた。
6.については、アカウントを見て、顔が思い出せる場合を除きフォローを辞めた。
7.と8.についてはそのまま残した。

作業の結果

結果的には179のアカウントに対するフォローを解除した。

感想

自分は、人の連絡先を管理するのが苦手で、
だから、その分できるだけtwitterを始めとする開かれたインターネットに、どうでもいいことを書いておいて、
自分に連絡を取りたいなと思った人が、既に顔を知っている人であれ、そうでない人であれ、
気軽に連絡を取りやすい状態を維持しようとしてきた。

数年前であれば、みんな、そこそこtwitterみてるよなーって思っていたけど、
ここ数年で使わなくなった人もいるし、twitterだけでは不十分だな、ということを今回の作業で実感した。

なので、twitter以外にも色んな人のいそうなところに出向いていったり、
あるいは、ちゃんとこのblogをメンテするなりして、
連絡とりたいに人にちゃんととってもらえる状態を維持したいなと思った。

複数マシン間で、atomで取ったメモを同期するための環境を整えた

自分は、いろんな作業をするときに、人に報告したり、twitterに書いたりするほどでもないことを、atomを使ってmarkdown形式でメモをとりながら進めています。
1台のマシンでメモを取るだけなら、シンプルでいいんですが、VMを含め、複数台のマシンを行ったり来たりしながら作業するとなると、これらの間でどうやってメモを同期するか、という点が悩ましくなってきます。
今回のエントリは、どうやってatomを用いて、複数のマシンでどうやってメモを同期させるか考えたっていう、そんなお話。

TL;DR

  • atomのsync-on-saveはとても良い
  • WindowsとLinuxだとパッチ当てないと動かない(2017年10月12日時点)

gitでメモの同期をとりたい。でもコマンド打つの、面倒だな。

ファイル単位で同期を取る仕組みというのは、atomには色々あって、たとえばRemote-FTPというパッケージで実現することができます。
最初はこれを使っていたんですが、同期の粒度がファイルだと、複数のマシンで同じファイルを変更したときに、どちらかがどちらかをうっかり上書きして、せっかく書いたメモを失う、なんてことになりそうだなと思いました。
実際に上書きをしてしまったことはなかったものの、そういうことが起こりうるということを意識しなければならないのがなんとなくストレスでした。

だから、ファイルよりも小さい単位で同期を取りたい。
そうだ!僕達には、gitがある!gitを使おう!と考えました。

でも、gitも、コミットメッセージを書いたり、共有のためにpushしたりと、やらなければいけないことが多くてちょっと面倒です。

sync-on-save というパッケージに面倒事を引き受けてもらう

どうせ、自分が適当に見るメモなんだから、コミットメッセージなんて適当に自動でつけてくれればいいし、pushも勝手にやってくれればいいのに。
そんなパッケージないかなー?と探してみたところ sync-on-saveというパッケージがありました。

このパッケージを使って救われました。本当に欲しいものそのものでした。
コマンドパレットからEnable Syncすると、ファイルを保存したタイミングでgit commitとgit pushを自動でしてくれます。
あとなんか他の場所で同じファイル編集してたらmergeもしてくれる。

本当に便利だ。素敵だなぁ。

LinuxとWindows向けにバグがあって動かなかった→なおした

バグを見つけたので直しました!バージョン0.1.5からは何も考えずにATOMのパッケージをインストールすれば使えるようになりました!
みんな使ってみてね。

2017年10月12日時点でダウンロード可能な、バージョン0.1.4にはちょっとしたバグあり、WindowsとLinuxでは動きません。
直したのでプルリク投げてみるつもりです。

差分は1行なので、これ読んで今すぐ使ってみたい!って思った人は、sync-on-saveをインストールした上で、コードを直接いじるのが楽そうです。
コミットの情報はここにおいときますので参考にしていじってみてね。

https://github.com/sirrow/sync-on-save/commit/7df50d7094156b9fd030ab698a6ff69a680177af
おしまい。

本文に書ききれなかったけど書きたかった事

sync-on-saveを作った人について

sync-on-saveを作った人すごいなぁ、ありがたいなぁ。プルリクも投げなきゃいけないし、どんな人なんだろう?って思ったので調べてみたら、 Hajime Morita さんでした。
そういえば、rebuild.fm 聞いたことないし、今度聞いてみよう。

昔はssh + screen + emacsでメモを取ってた

自分は一昔前は、VPS上でscreenを動かして、その上で動かしたemacs -nwに、色んなマシンからsshでログインした上でattachしてメモを取ってました。
これはこれで悪い方法じゃなかった気がします。手軽だしね。ただ、ネットワークから切断されるとつらいんだこれ。
gitなら手元にコピーあるからネットワークなくても編集できるしね。そんなところが素敵。