あんパン

こしあん派

Twitter APIの思い出

いいネタで面白かった。そういえばなんだかんだTwitter APIとの思い出があるなと思ったので自分も書く。

出会ったころの話

今のTwitterはOAuthでreadやwriteの権限をとってくるが、昔はもっと牧歌的でBASIC認証を利用してAPIにアクセスできた。当時書いたコードはもうどこにもないと思うけど、ちまちま情報を取得してうまく加工するツールみたいなのを作っていたと思う。

そんな折にBASIC認証が廃止されると聞いて、めんどくさいなあと思った覚えがある。

これが高校生くらいの頃で、OAuthなんて全然知らなかったので切り替わる時にドキュメントを全部印刷して読んでOAuthとはなんぞやを学んだ。当時はiPadが出たばかりでタブレット端末などは持っていなかったので、長い文章を読む時は家のレーザプリンタで印刷して読んでいたのだった。おそらくプラスの2穴ファイルに挟まれたTwitter OAuth 1.0aの書類がまだ実家に眠っているのではないか。

作ったものたち

もうどれも動かないと思う。上から順に新しい(一番下が古い)。ふしぎなもので、この順番で思い入れが強まっていく。 作った時期が大学生ごろに集中しているので、これは青春補正だろうなと思う。

tw2slack

ヤパチー(YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa)のスタッフをやっていて、Twitterを監視してなにかあったらアクティブサポートする担当として動いていた。

スマートフォンでツイートを監視したくて、TweetDeckでは間に合わなかったのでSlackで監視することにした。Slack Integrationだとリアルタイム性に欠けるのでStreaming APIでなんとかしたいと思って、専用のデーモンみたいなやつを作った。結構便利だったけど用途が結構限定されるのでこれ以降使ってない。

当時書いた紹介記事はこちら。

owlproxy

当時(今はどうか知らない)の夜フクロウはTwitter公式の画像アップローダに対応していなかった。任意のサードパーティ画像アップローダを指定する仕組みはあったため、ローカルにプロキシを立てて公式側にアップロードできるようにした。

Gyazoにも投稿できるようにして、GyaPC::Asia Tokyo 2015のLTで話した。

飯テロ.in

GyaPCの発表資料にもちょろっと書いた、Twitterアカウントでログインできるご飯画像アップローダ(閉鎖済、ドメインも手放し済)。通報機能が悪用されて画像が一つも無くなったりしたら嫌だなと思って、通報数で公開状態を制限するんじゃなくてTwitterでmentionをもらって自分の判断で公開停止する形にした。通報されたら手でMySQLのレコードに論理削除フラグを立てる仕組み。これまた牧歌的だったと思う。ぼくが恣意的にご飯画像かどうかを判断できるので微妙な仕組みではある。いまの時代に生まれていたら機械学習を学んでなんとかしていたと思う。

ちなみにGIGAZINEで紹介されたことがある。GIGAZINEはいろいろあるけどこういう記事でもずっと残していて偉い。

余談だけどこのブログのタイトルのせいで作者名をあんパンと勘違いされた状態で記事が出ていた。問い合わせて直してもらった。

violet

github.com

JavaScriptでTwitter APIを扱えるようにするクライアントライブラリも自作していた。Streaming API(昔はHTTPでコネクションを閉じずツイートをリアルタイムに受け取るAPIがあった)に対応していて、Firefox OSで動かすのに便利だった。

これを作った当時、世の中の動向に疎すぎたのでnpmの存在を知らなかった。package.jsonもなにもなくて、当然依存モジュールは存在しないのでOAuth周りも全部自分で書いていた(正確にはsha1まわりのライブラリだけ他repoからもってきている)。minifyにはGoogle Closure Compilerを使っていた。ECMAScript 5以前のコードなのでPromiseはPの字もなくcallbackでなんとかしていて涙ぐましい。自分の中では黒歴史的な存在だけど、書いてて楽しかったので思い入れはそこそこ強い。

別れ

明確にもうTwitter APIで遊ぶのをやめようと思ったタイミングがあって、Streaming APIが廃止されたときだった。あれ以降、遊び場としてのTwitterは完全に面白みを失って興味がなくなったと思う。プラットフォームとしての興味もこのころからだんだん薄れていった。負荷をかけまくるユーザが減ったということでビジネス的には正しかったのかもしれない。

では最近はどうかというとあんまりTwitterを見てなくて https://social.masawada.me に引きこもってます。という話を来週くらいに書くであろう。

お名前.comで管理しているドメインをGandiに移管する

おもしろドメインを取得するのが趣味で、現在22のドメインを保持している。これでもいくつかは削ったのだけれど、思い入れのあるものはどうしても手元に残したいし使い続けたい。レジストラもいろいろあり

  • お名前.com
  • ゴンベエドメイン(インターリンク)
  • Google Domains
  • Amazon Route 53 Domains
  • Gandi

という状態。管理が煩雑なのと、個人的な信条によりお名前.comの利用を廃止したいという思いがあり、どこかにまとめたいと長年考えていた。そんな中、2月からお名前.comがサービス維持調整費という名目で値上げすることを発表し、取り柄であったやや値段が安いという部分も崩壊したため全てのドメインを移管することにした。

www.onamae.com

Gandiについて

移転先のレジストラを検討し、最終的にはGandiを利用することにした。Gandiはフランスの企業が運営するレジストラで、会社の歴史は以外と古く1999年から存在している。Amazon Route 53 DomainsのOEM元でもある。

最初はAmazon Route 53 Domainsに移管することを考えていたが、持っているTLD全てに対応しているわけではなく、結局はGandiと併用することになりそうだったため利用を諦めた。その点Gandiは対応しているTLDが多く、.moeや.みんななど一部のレジストラでは扱っていないようなものも大概は登録できる。

また、No Bullshitというモットーを掲げているところが良くて、とても共感できる。

www.gandi.net

TLDによって値が張るものがいくつかあり(なぜかAmazon Route 53 Domainsの方が安いTLDもある)、移管前後で年間約1万円ほど値上がりしてしまう計算だが、どうせ値上がりするならいずれにせよこちらに移管する方が得と判断した。

お名前.comからの移管

.jp以外のドメインの移管(トランスファー)は基本的にどこも同じ流れになる。具体的に行う作業は以下の通り。

  • (移管元) AuthCodeの発行
  • (移管先) ドメイン移管手続の開始(AuthCodeの入力)
  • (移管元) ドメイン移管の承認

ドキュメントにもだいたい同じことが書いてある。

help.onamae.com

お名前.comの場合、以下に気をつける必要がある

  • 移管ロックを設定している場合は事前に解除しておく
  • Whois情報公開代行設定をしている場合は事前に解除しておく
    • (他のレジストラではこんなことをさせられる記憶がないのだがどうだろうか)
  • ドメイン移転後もDNSの設定が残るので削除すること

上2つについてはそもそも移管手続ができないので問題ないかと思う。一番下のものだけ厄介で、AuthCode発行時に以下のような表示がなされるが、そのまま手続きできてしまう。

DNSの設定は移管後に手で削除する必要がある

お名前.comには、お名前.comが管理するネームサーバを利用してDNSのレコードを返す機能がある。この設定を行った状態で移管が完了すると、この設定は残り続けたまま課金の対象となる。移管後にネームサーバやDNSレコード設定の引っ越しを行い、お名前.com側の設定を削除する必要がある(消すまではお名前.com側が名前を解決してくれるので、必ず設定の引っ越しが終わってから消す必要がある)。Gandiでは移管時の手続でネームサーバ等を変更する操作がやや難しいので、移管が完了してからGandiが提供するDNSに切り替えることになる。

「DNS追加オプションの解約、DNSレコード設定削除のお手続きはこちら」から手続きできる

動線がやや分かりづらいが「DNS設定/転送設定-ドメイン一覧」内の「DNS追加オプションの解約、DNSレコード設定削除のお手続きはこちら」を押して「DNSレコード設定のゾーン削除」を選択すれば手続きできる。

移管直後に設定を削除した場合はどうやら課金の対象とはならないようにみえる。いまのところカードの明細に引き落としの情報は見えていない。

お名前.comについては以上の操作を行いひとつひとつドメインを移管していけば良い。これまでお世話になりました。

おまけ: 移管するドメインの管理

Todoistで移管する日付を管理している

このブログで度々登場しているとおりTodoistを利用して移管する日付を管理している。期限2週間前になると移管できなくなってしまうため、十分に余裕を持った状態で移管したい。しかし、移管時に費用の請求が走るため一気に移管するとそこそこの金額がかかってしまう。そのため、期限を管理しつつ1年かけて移管しようとしている。ひととおり終えたらまたどこかに感想などを書くことがあるかもしれない。

はてなブログで記事を書く際にやっていること11連発

はてなブログで記事を書く際にやっていること、主にツールの使い方について。

初手で下書き保存する

編集中のものを誤って公開すると悲しい気持ちになるので初手で下書き保存にしておく。以降、公開に切り替えなければ下書きで保存され続ける。

こまめに保存する

Ctrl+S(macOSならCommand+S)で保存できる。保存しなかったとしてもローカルに残してくれる神機能があるけど、あくまでバックアップのバックアップくらいで使うのが良さそう。

こまめにプレビュー確認する

何度か読んでおくと都度体裁を整えられたりtypoに気付くタイミングが増える。日本語として通っていないところも見付けやすくなる。

見出しはh3からh5を使う

これが推奨らしい(はてな記法ではh3からh5が使われるため?)。Markdownの場合は ### から ##### までを利用することになる。

staff.hatenablog.com

過去に似た話題で書いているなら過去記事を貼り付ける

似た記事があるなら書いておくと参考になりそう。なんとなく文中のキーワードで検索すると全く同じことを書いてないかなどにも気を払える。

サイドバーから貼り付けられます

スマートフォンで撮った写真を利用する際はアプリからアップロードしてしまう

パソコンに転送して写真を貼るのは大変なので、スマートフォンのアプリで新規に記事を作成して写真を貼る。この記事はアップロードが終わったら破棄する。Web側では下書き保存していればリロードすると同じ記事の下書きを開けるので、そのままリロードする。写真サイドバーの一覧にアップロードした写真が登場するのでそのまま貼る。

写真のサイズを調整する

フォトライフ記法の最後に w300h300 などを付けると幅や高さの値を設定できる。巨大な画像を目にするとウワッとなるので、特に縦長のスクリーンショットなどは高さを指定してあげると丁寧。

縦長のスクリーンショット

サイズを調整したスクリーンショット

help.hatenablog.com

Amazonの商品を貼り付けたい場合はAmazonで検索してからASINをAmazon商品紹介サイドバーに入力して貼り付ける

Amazon商品紹介サイドバーだと検索した書籍がKindle版と物理版のどちらか見分けが付かないのでこういう振舞いをするようになった。Amazon側で商品ページを開いてASINをコピーしてからサイドバーで検索する。当該の商品がピンポイントで出てくるのでそのまま貼り付ける。

公開する前にアイキャッチ画像を確認する

SNSにシェアした際に意図しない画像がバーンと出てしまうのを防げる。最近のTwitterはキャッシュを破棄する仕組みがなく、よく分からないタイミングで更新されるのでミスるとつらい気持ちになる。

最後に一通り読み直す

最終チェック。こまめに読んでいるはずなのでざっくりで。

記事を投稿したらTwitterに放流する

これはお好みで。放流しないこともある。このブログの記事は基本的に放流しているけど、masawadaの日記は基本的に放流しないことにしている。

Kensington SlimBlade Proの全てのボタンをbt2usbhid&Linuxデスクトップ環境下で利用する

bt2usbhidとはこれのこと。

github.com

端的に書くと、Bluetooth接続のキーボードやマウスをRaspberry Pi経由でPCに有線接続できるようにするソフトウェア。USB切替器を挟むことで複数PC間でBluetooth接続のキーボードやマウスを共有するのに役立つ。このブログではたびたび言及している(それだけ便利に使っている)。

そしてKensington SlimBlade Proはこちら。

かなり前から販売されていたSlimBladeのBluetooth版。長らく待っていたけれどようやく発売された。さきほど届いたので早速セットアップした。といっても接続自体は難しくなくて、bt2usbhidのREADMEにあるとおりにRaspberry Piに接続するだけ。

このトラックボールにはボタンが4つついていて、全てのボタンを認識させるためにはXorgの設定でButtonMappingを変更する必要がある。bt2usbhidは単純に入力のイベントをそのまま再送しているだけなので、USBで接続した場合と同じマッピングを設定すれば良い。ただし、bt2usbhidはキーボードとマウスを接続していてもひとつのUSBデバイスとして振る舞っており、別個のデバイスとして認識されるわけではない。lsusbしてみると分かる。

$ lsusb
...
Bus 001 Device 009: ID 1d6b:0104 Linux Foundation Multifunction Composite Gadget
...

USBIDが1d6b:0104のデバイスがそれ。1d6bはLinux FoundationのVendor IDであり、0104はMultifunction Composite Gadgetであることをあらわす。これはbt2usbhid上で定義した値なので、どの環境でもこのUSBIDのデバイスが登場する*1。このデバイスが接続された場合にButtonMappingを書き換えてあげれば良い。具体的には以下のようなファイルを /etc/X11/xorg.conf.d に放りこんであげれば良い。

Section "InputClass"
  Identifier      "Bluetooth to USB HID Converter"
  MatchUSBID      "1d6b:0104"
  Driver          "libinput"
  MatchDevicePath "/dev/input/event*"
  Option          "ButtonMapping" "1 8 3 4 5 6 7 9 2"
EndSection

ちなみにどのボタンを押したときにどのボタンが反応するかは xev コマンドを見れば分かる。

ButtonPress event, serial 34, synthetic NO, window 0x3c00001,
    root 0x75d, subw 0x0, time 23937374, (231,956), root:(4075,1003),
    state 0x0, button 1, same_screen YES

ButtonRelease event, serial 34, synthetic NO, window 0x3c00001,
    root 0x75d, subw 0x0, time 23937444, (231,956), root:(4075,1003),
    state 0x100, button 1, same_screen YES

ButtonPress event, serial 34, synthetic NO, window 0x3c00001,
    root 0x75d, subw 0x0, time 23937584, (231,956), root:(4075,1003),
    state 0x0, button 3, same_screen YES

ButtonRelease event, serial 34, synthetic NO, window 0x3c00001,
    root 0x75d, subw 0x0, time 23937855, (231,956), root:(4075,1003),
    state 0x400, button 3, same_screen YES

うまく動かない場合はこれを頼りに調整することができる。とはいえ、これまで有線のSlimBladeとExpert Mouse Wireless Trackballを利用していたがいずれも同じButtonMappingを流用できたので、全ての製品が同じ配列なのかもしれない。

なおSlimBlade Proにはdpiを変更するスイッチが筐体の右側面にあり、これはハードウェア側で調整されるようで何も設定しなくても押せばカーソルの移動速度が切り替わる仕組みになっていた。ただ切り替えると素早すぎてコントロールを失うのでデフォルトのまま使おうと思っている。

SlimBladeは高さが低めに作られていて手首に負担がかかりづらいし、ボールの受け軸を掃除しやすくメンテナンス性も高いのでトラックボールを使うのに抵抗がない人にはぜひオススメしたい。

GitHub ActionsでstをビルドしてArch Linuxにインストールする

Linuxデスクトップを利用しはじめてからこれまでターミナルエミュレータとしてurxvtを利用してきた。のだが、どうもサロゲートペアに対応していない?ようで絵文字を表示できないのがやや気になるポイントであった。

普段から絵文字を入力することはないのでずっと放置していたのだけれど、最近「突撃! 隣のLinuxデスクトップ」という記事を書く中でstという軽量ターミナルエミュレータの存在を知り、絵文字もうまく表示されそうだったので利用してみることにした。

st.suckless.org

stは各種設定をconfig.hに書き込んでビルドするという硬派な設計になっている。つまり設定を変更するたびにビルドする必要がある。ArchWikiを眺めると

Consider maintaining your own config.h and PKGBUILD.

https://wiki.archlinux.org/title/st

と書いてあり硬派だ…… と思う。

一応AURにはPKGBUILDがあるので、config.hを置いたディレクトリで BUILDDIR=$(pwd) yay -Sy st みたいな感じで設定入りのstをビルドすることはできる。しかしまっさらな環境でこれを自動化するのは面倒なので、ArchWikiに書かれている通りPKGBUILDを飼うことにした。

ArchWikiのPKGBUILDページを眺めてだいたい雰囲気を掴んで、 cp /usr/share/pacman/PKGBUILD.proto ./PKGBUILD してきて編集すればあまり詰まることはないかと思う。実際に書いたPKGBUILDは以下。

# Maintainer: Masayoshi Wada <developer@andantesoftware.com>

pkgname=st
pkgver=0.9
pkgrel=1
pkgdesc="A simple terminal implementation for X."
arch=("x86_64")
url="https://st.suckless.org"
license=("MIT")
depends=("libxft")
source=("${pkgname}-${pkgver}::https://dl.suckless.org/$pkgname/$pkgname-$pkgver.tar.gz"
        "config.h")
sha256sums=("f36359799734eae785becb374063f0be833cf22f88b4f169cd251b99324e08e7"
            "8c6e61cabdd083315863c77e72ef5f669496b24863c3f1420ce83af3927da53d")

prepare() {
  cp "config.h" "$pkgname-$pkgver/config.h"
}

build() {
  cd "$pkgname-$pkgver"
  make
}

package() {
  cd "$pkgname-$pkgver"
  make PREFIX=/usr DESTDIR="$pkgdir/" install
}

config.hを変更する度にsha256sumも変える必要があるのはややだるいが、ある程度カスタマイズしたら更新頻度は落ちるだろうからよしとする。

これでPKGBUILDファイルとconfig.hディレクトリを一緒に置いて makepkg -si するだけでインストールできる状態になった。しかしこれをGitHubに置いていちいちcloneしてきてビルドするのも自動化するにはやや手間に見える。せっかくならビルド済のデータをGitHub Releasesから配信すれば良いのではないかと考えて、GitHub ActionsのWorkflowを書くことにした。書いたYAMLはこちら。

on:
  workflow_dispatch:

permissions:
  contents: write

jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    container: 
      image: archlinux:latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Initialize
        run: |
          pacman -Syu --needed --noconfirm base-devel
          useradd builder -m
          echo "builder ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
          chmod -R a+rw .
      - name: makepkg
        run: |
          sudo -H -u builder makepkg -sC --noconfirm
      - name: Parse .SRCINFO
        id: srcinfo
        run: |
          sudo -H -u builder makepkg --printsrcinfo > .SRCINFO
          echo "version=$(grep pkgver .SRCINFO | awk '{print $3}')-$(grep pkgrel .SRCINFO | awk '{print $3}')" >> $GITHUB_OUTPUT
      - name: Create new release
        uses: softprops/action-gh-release@v1
        with:
          name: Release ${{ steps.srcinfo.outputs.version }}
          tag_name: ${{ steps.srcinfo.outputs.version }}
          files:
            st-${{ steps.srcinfo.outputs.version }}-x86_64.pkg.tar.zst

makepkgはrootで実行すると ERROR: Running makepkg as root is not allowed as it can cause permanent, catastrophic damage to your system. というエラーを吐いて落ちるのでビルド専用のユーザを用意して利用している。バージョンの文字列を作るところはやや強引だけどPKGBUILDと二重管理したくなかったので .SRCINFO を生成して読み取ってawkで抜き出す形にした。あたりが工夫ポイント。

最後にReleaseを新規に作成して成果物をアップロードしている。actions/upload-release-assetを使えばよいという記事を多く目にしたが、既にArchiveされていてsoftprops/action-gh-releaseを使えと書かれていたのでこれを利用した。tagを作ってpushするのでpermissionとして contents: write を足す必要がある。

ということで、stをビルドしてGitHub Releasesの成果物として置いておくことができるようになった。あとはこれをダウンロードして sudo pacman -U st-0.9-1-x86_64.pkg.tar.zst のような形でインストールすれば良い。

stでは絵文字を表示できる

絵文字も表示できるようになって大満足。まだ何もカスタマイズしていない状態なのでざっくり好みの状態に整えていきたい。

リポジトリは以下にあるのでforkするなりなんなりしてご自由にお使いください。

github.com