GitHub Actions で SATySFi の文書やパッケージの CI

これは SATySFi Advent Calendar 2019 6日目の記事です。 5日目はzr_tex8rさんによるSATySFiコード中で整数を16進数で書きたいでした。

3日目の記事では satysfi-docker の紹介をしましたが、今回は satysfi-docker と GitHub Actions を使って SATySFi パッケージや文書の CI をする例を紹介したいと思います。

GitHub Actions は最近正式版になった GitHub の機能で、GitHub の様々なイベント (リポジトリへのプッシュ、Pull Request、リリースの作成、などなど) に反応してワークフローと呼ばれる一連のタスクを実行できるというものです。

GitHub のサービスなだけあって GitHub との親和性は抜群で、CI サービスとしては後発なのでいろいろやりやすかったり (個人の感想です)、Microsoft パワーなのか CI サービスとしては利用制限が緩かったりします。

サンプルリポジトリ

github.com

こちらがサンプルコードが入ったリポジトリです。 簡単なものから少しだけ複雑なものまで5つの例を用意したので、順に説明していきます。

  • 01-simple-example
  • 02-library-example
  • 03-submodule-example
  • 04-satyrographos-example
  • 05-custom-action-example

01-simple-example

一番簡単な例です。 doc.saty というファイルがあり、リポジトリへの push 毎にビルドできるか確認したいという状況です。 依存パッケージもなく、文書をあるバージョンの SATySFi でだけビルドできればいいならこの方法で十分だと思います。

name: build   # ワークフローの名前は build (バッヂをつける際はこの名前で参照することになります)
on: push      # push 毎にワークフローを実行

jobs: # job 定義
  build-simple-example:      # job 定義の名前
    runs-on: ubuntu-latest   # ubuntu 環境で実行
    steps:
      - uses: actions/checkout@v1   # ソースコードをチェックアウトしてくる
      # satysfi-docker を使ってビルド (この例くらいなら slim タグを使ったほうがいいですが簡単のため latest)
      - run: docker run --rm -v $(pwd):/satysfi amutake/satysfi satysfi doc.saty  
        # 今回は 01-simple-example というディレクトリの下にあるのでその中でコマンドを実行
        working-directory: ./01-simple-example   
      - uses: actions/upload-artifact@master
        with:
          name: 01-simple-example          # 01-simple-example という名前で、
          path: 01-simple-example/doc.pdf  # doc.pdf をアップロード

GitHub Actions ではジョブの中で普通に docker run できるので、satysfi-docker の使い方の通りに satysfi を実行するだけです。

生成した PDF はアーティファクトとしてアップロード・ダウンロードできます。 勝手に zip 形式に圧縮されます。PDF はブラウザから確認できたら嬉しいのですがダウンロードして展開してとやらなければいけないのでちょっと面倒。

実行されたワークフローは Actions タブ から確認することができます。

↓ここからダウンロードできるようになります。

f:id:amutake:20191202194831p:plain

02-library-example

次は SATySFi のライブラリの CI をしたい例です。以下のような状況だと思ってください。

  • commands.satyh をライブラリとして配布したい
  • commands.satyh の使い方の説明ドキュメント doc.saty (この中で commands.saty を使っている) をテストとしてビルド・目視確認したい
  • ライブラリなので SATySFi の複数のバージョンで使えるか確認したい

この場合は下のようにするといいと思います。

  build-library-example:
    runs-on: ubuntu-latest
    strategy:
      matrix:
         # 確かめたい SATySFi のバージョンを列挙
        version: [0.0.3-slim, 0.0.3-dev2019.11.16-slim, nightly] 
    steps:
      - uses: actions/checkout@v1
      # matrix.version によってタグを指定
      - run: docker run --rm -v $(pwd):/satysfi amutake/satysfi:${{ matrix.version }} satysfi doc.saty  
        working-directory: ./02-library-example
      - uses: actions/upload-artifact@master
        with:
          name: 02-library-example_${{ matrix.version }}
          path: 02-library-example/doc.pdf

01-simple-example との差分は matrix を使っている部分です。 GitHub Actions の matrix 機能を使って簡単に複数バージョンでのビルドができます。今回はバージョン0.0.3, 2019-11-16時点のスナップショット、nightly で確認しています。 そしてバージョンごとに成果物がアーティファクトとしてアップロードされます。

ライブラリのドキュメントや使用例のPDFはリポジトリに含めておきたい (つまり生成した PDF をリポジトリに push したい) ことが多いと思いますが、 その場合も、 github actions push to repo とかで検索すればいろいろ出てくるので簡単に実現できると思います (試してはないですが…)。

03-submodule-example

以降の3つは依存パッケージがある場合の例です。 依存パッケージがある場合にビルドする方法はいくつかありますがこの例では submodule を使う方法を説明します。

  build-submodule-example:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        version: [0.0.3-dev2019.11.16-slim, 0.0.3-dev2019.07.14-slim]
    steps:
      - uses: actions/checkout@v1
        with:
          submodules: recursive  # submodules: recursive を指定することで submodule init --recursive をしてくれるようになる
      - run: docker run --rm -v $(pwd):/satysfi amutake/satysfi:${{ matrix.version }} satysfi doc.saty
        working-directory: ./03-submodule-example
      - uses: actions/upload-artifact@master
        with:
          name: 03-submodule-example_${{ matrix.version }}
          path: 03-submodule-example/doc.pdf

02-library-example との差分は checkout に submodules: recursive を指定していることです。 あとは doc.saty から @import: ... で読み込むと submodule にしたライブラリが使えるようになります。

この方法の利点としては、slim が使えるので CI も速い (ダウンロード時間が小さい) のと、ジョブ定義もシンプルに保てて手軽なことです。 ただ、文書を作成したい場合はこれでいいかもしれませんが、@import を使っているため、ライブラリとして配布したい場合にこの方法を使うのは配布方法によっては微妙かもしれません (ライブラリの利用者にも submodule で recursive update してもらうことになるかも)。

04-satyrographos-example

こちらは依存パッケージを Satyrographos と opam を使ってインストールする例です。

  build-satyrographos-example:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        version: [0.0.3-dev2019.11.16]
    container:
      image: amutake/satysfi:${{ matrix.version }}   # run で使うイメージを指定
    steps:
      - uses: actions/checkout@v1
      - run: |
          export HOME=/root # workaround
          eval $(opam env)
          opam update
          opam install satysfi-grcnum # opam で SATySFi のライブラリをインストール
          satyrographos install -library grcnum # Satyrographos で SATySFi のライブラリをインストール
          satysfi doc.saty
        working-directory: ./04-satyrographos-example
      - uses: actions/upload-artifact@master
        with:
          name: 04-satyrographos-example_${{ matrix.version }}
          path: 04-satyrographos-example/doc.pdf

差分は run のところで、 opam と Satyrographos を使って SATySFi のライブラリ (ここでは satysfi-grcnum) をインストールしています。

また、 container でジョブの中でコマンドを実行するコンテナイメージを指定しています。 こうしないと、

run: docker run --rm -v $(pwd):/satysfi amutake/satysfi:${{ matrix.version }} bash -c "opam update && opam install satysfi-grcnum && satyrographos install -library grcnum && satysfi doc.saty"`

と長々と書かなければならずちょっとだるいです。ただ GitHub Actions は環境変数 HOME を上書きして走らせるため、 opam がインストールされてあるディレクトリに指定し直しています。

こういう感じで opam リポジトリに登録されている SATySFi のパッケージを使うことができます。

(なお、インストールするパッケージはワークフローの定義に直接書くのではなくパッケージ一覧を書いたファイルかなにかをリポジトリに入れておくのがいいと思います)

05-custom-action-example

SATySFi 用の Action を作って使う例です。 04-satyrographos-example は run にコマンドがベタ書きされていて見づらかったので、 Action としてモジュール化しています。

以下がジョブの定義になります。

  build-custom-action-example:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: ./.github/actions/satysfi
        with:
          main: ./05-custom-action-example/doc.saty # メインファイルを指定
          packages: 'satysfi-fonts-theano satysfi-grcnum' # パッケージ一覧を指定
      - uses: actions/upload-artifact@master
        with:
          name: 05-custom-action-example
          path: 05-custom-action-example/doc.pdf

.github/actions/satysfi に Action の定義を入れておいて、ジョブの中からはそれを参照しています。

以下が Action の定義 (.github/actions/satysfi/action.yml) です。いわゆる container action になっています。mainpackages を受け取って、docker run の引数として与えています。

name: 'SATySFi'
description: 'Build SATySFi file'
inputs:
  main:
    description: 'Target file which will be built via SATySFi.'
    required: true
  packages:
    description: 'Space separated SATySFi packages which will be installed via opam & Satyrographos'
    required: false
    default: ''
outputs:
runs:
  using: docker
  image: Dockerfile
  args:
    - ${{ inputs.main }}
    - ${{ inputs.packages }}

以下が docker のエントリポイントとなるファイル (.github/actions/satysfi/entrypoint.sh) です。 ここに、04-satyrographos-example に長々と書いていたコマンドの列を書いています。

#!/bin/sh -l

main=$1
shift
packages=$@

# workaround. GitHub Actions overwrites $HOME.
export HOME=/root
eval $(opam env)

opam update
opam install $packages

satyrographos install

satysfi $main

あとはsatysfi-docker をベースイメージにした Dockerfile を書いてやればそれで完了です。CI が走るたびにイメージがビルドされて Action が実行されます。

おわりに

この記事では、GitHub Actions を使って SATySFi のパッケージや文書の CI をする説明をしました。 GitHub Actions を使うと、依存ライブラリをインストールしつつ文書をコンパイルできたり、 matrix を使ってライブラリがサポートしたいバージョンで簡単に CI を走らせることができたりします。 ライブラリの信頼性を高めたり、複数人で文書を書く際には有効だと思うので、ぜひ使ってみてください。

satysfi-docker を使って SATySFi をお手軽に試す

この記事は SATySFi Advent Calendar 2019 3日目の記事です。 2日目はSATySFiの作者であるgfngfnさんによるSATySFiの2段組機能でした。

前置き

SATySFi をインストールするためには opam と OCaml コンパイラのインストールが必要ですが、OCaml を使わない人にとっては SATySFi のためだけに opam 環境を入れるのは面倒です。 opam をすでに使っている人にとっても、SATySFi のインストールには専用の opam repository を使うので環境を分けるために SATySFi 用の switch を作って OCaml コンパイラをビルドして〜といったことをすることになると思います。この作業もそれなりに時間がかかるので面倒です。 ようやく opam 環境を用意して SATySFi をインストールする環境が整った後も、SATySFi のインストールでまた少し時間がかかります。 いずれもやればよくはあるのですが、少しだけ試したいときでも時間がかかりますし、罠にはまる可能性もありますし、もっとお手軽に SATySFi を試せたらいいですよね。

ホストの環境を壊さずにソフトウェアを試すために、最近は Docker を使うことが多くなっていると思います。 SATySFi も有志の方が作ってくださった Docker イメージがあったのですが、バージョンが古いあるいは不明だったり、メンテされているか怪しかったので、自分で作ってみました。

github.com

satysfi-docker の使い方

まず docker をインストールしていない方はしてください (結局インストールするのかという感じですが、opam よりは Docker のほうがすでにインストールしている人が多そうなのと、いろいろ便利なので入れておいて損はないのではと思います。Docker のインストールに関する資料も少なくとも SATySFi のそれよりは多いはずです)。なお、以降 Docker に関する説明は省略します。

Docker Developer Tools | Docker

Docker をインストールできたら、あとは .saty ファイル (今回は demo.saty とします。 ) があるディレクトリに行き、

docker run --rm -v $(pwd):/satysfi amutake/satysfi satysfi demo.saty 

で文書 (ここでは demo.pdf) がビルドできます (イメージは勝手にダウンロードされてきます)。イメージのダウンロードと展開に多少時間がかかります(後述する slim タグを使うともっと速くなります)が、何も考えなくていいのでお手軽なのではないかと思います。

各タグの紹介

amutake/satysfi にはいくつかタグがあります。 無印、slim、nightly と、バージョン付きかそうでないかの組み合わせがあります。 すべてのイメージで SATySFi と Satyrographos (SATySFi のパッケージマネージャ。これについては7日目、12日目で作者の na4zagin3 さんによる解説があることと思います) が含まれていますが、それぞれ特徴があるので、適切に使い分けていただけたらと思います。

タグ 説明
latest SATySFi の新しいバージョンが出たら更新されます (2019-11-19 時点では 0.0.3-dev2019.11.16 と同じイメージ)。opam 環境と、ビルドに便利ないくつかのパッケージ付き。
slim SATySFi の新しいバージョンが出たら更新されます (2019-11-19 時点では 0.0.3-dev2019.11.16 と同じイメージ)。opam など諸々が入っていないのでサイズが小さいです。
nightly 毎日朝9時 (JST) に更新されます。SATySFi と Satyrographos の master ブランチが入っています。slim と同様に opam 環境は入っていません。
0.0.3-dev2019.11.16 2019年11月16日時点の SATySFi の master ブランチのスナップショットが含まれます。更新しません。
0.0.3-dev2019.11.16-slim 0.0.3-dev2019.11.16 の slim バージョン。
0.0.3 SATySFi の 0.0.3 が入っています。基本更新しません (といいつつ2019年11月15日くらいにインタフェースの破壊的変更を入れました…)
0.0.3-slim 0.0.3 の slim バージョン。

無印

latest, 0.0.3-dev2019.11.16 のようなタグをここでは無印と呼ぶことにします。無印は opam 環境がフルで入っている環境です。また、 make や fontconfig など、文書のビルドに便利そうないくつかのパッケージも含まれています。

opam と Satyrographos を使って SATySFi のいろいろなパッケージをインストールするのであればこちらを利用してください。

欠点はイメージのサイズが大きいことです。opam 環境がフルで入っているので、圧縮した状態で715MBほど、解凍すると2.2GBくらいあります。

slim

無印は2GB以上のイメージになっているのに対し、こちらは圧縮した状態で50MBほど、展開して150MB程です (これでも大きいと言えば大きいですが)。 SATySFi 単体で使う場合はこちらで SATySFi を試すのがいいんじゃないかと思います。

ただしこちらは opam 環境を削除して SATySFi と Satyrographos のバイナリだけを置いているので、 opam を使って SATySFi のパッケージをインストールすることはできなくなります。 システムフォントを Satyrographos でインストールして使うくらいであればこちらで十分です。

nightly

「SATySFi の master ブランチに面白い機能が入ったけど自分でビルドするの面倒」という方はこちらを利用してください。 毎日 09:00 (JST) 時点の SATySFi と Satyrographos が入っています。

中身は slim 版と同様に opam 環境が削除されたものになっています。おそらく nightly は SATySFi の新機能を軽く試すものになると思っていて、その場合は外部パッケージも使わなさそう、かつサイズは小さい方がよさそうなため、こうしています。

イメージの中には /satysfi-revision/satyrographos-revision/build-date という3つのファイルが含まれていて、それぞれどのリビジョンの SATySFi・Satyrographos が同包されているか、そしてビルドした日付が書かれています。

バージョン付き

GitHub - na4zagin3/satyrographos-repo: Custom OPAM repository for SATySFi libraries managed by Satyrographos不定期で SATySFi のスナップショットを取ってくださっているので、 そのバージョンと同一のタグがついています (0.0.3+dev2019.11.16 なら 0.0.3-dev2019.11.16 というタグ。docker のタグは + が使えないようなので - にしています)。 複数人で SATySFi の文書を書くときには生成物の違いをなくすために各自のローカル環境のバージョンと CI のバージョンを揃えておきたいので、バージョン付きが便利です。

他の手軽に試す方法

macOS を使っている方は GitHub - nyuichi/homebrew-satysfi で1コマンドでインストールできます。こちらの方法でインストールすると (おそらく) HEAD になります。

他には Web 上で SATySFi による組版を試すことができるページがいくつかあります (以下2019-11-19時点で動いているもの)。

  • SATySFi Playground
    • 中で satysfi-docker (amutake/satysfi:slim) を使っていただいています。ありがとうございます。
  • satysfi.ml

おわりに

satysfi-docker はちゃんとメンテしていくつもりなのでなにか不具合や要望があれば issue にお願いします。 6日目には satysfi-docker と GitHub Actions を使って文書やパッケージの CI をする話を書くのでそちらもよろしくお願いします。

2018年の思い出

尊敬している先輩が毎年の年末に一年の総括を書いているので、自分も真似してやってみる。

仕事

今年の半分は sluicegate という、メディアストリームを fan-out させるシステムを作っていた。これに関しては Erlang & Elixir Fest. 2018 で発表しているので、概要はそちらの発表資料を見てほしい。設計・実装は、レビューはしてもらいつつもほぼ一人で作ったのでいい経験になったと思う。パフォーマンスチューニングもしたが、なかなか速くならず難しかった。

今年の1/4は fialyzer という、Erlang の (後付けの) 型検査ツールである dialyzer の軽量高速版を作ったりしていた。一応OSSになっているけど、まだ全然できていない。

あとは sluicegate の一部を Coq で証明して PPL2018 でポスター発表をしたりした。型検査器の開発や Coq での証明を給料をもらいながらできるのは改めてすごい環境だと思う。

趣味プログラミング

友人からの依頼などでコードを書いた (しなければいけなかった) ことはちょこちょこあったが、趣味では特にしていない。

最近ではプログラミングが楽しいと思うことがほとんどなくなってしまった。昔はプログラミング自体が楽しくて仕方がないこともあったような気がするけど、ここ1,2年はその気持ちになれなくて悲しい。やらないと怒られたり締め切りに追われたりしないとプログラミングする気が起きなくなってしまった。面倒という気持ちが強い。かといって他のことに熱中しているというわけでもなく、昔好きだったこともいまではそれほど心を動かされなくなってしまった。何かに熱中できる人が羨ましい。熱意を持ち続けられることが一番貴重な性質だなと最近よく思う。

ちなみにこういう気持ちは昨年からあって、「今年はなにかするのを極力やめよう、そうすれば治るかも」と思っていたけど、特に変わらなかった。悲しいね。

本・論文

全然読んでいなくてもうだめかもしれない。 ぱっと思いつくのは、

  • Communication and Agreement Abstractions for Fault-Tolerant Distributed Systems
  • みんなのデータ構造
  • 純粋関数型データ構造 (途中)
  • Real World HTTP
  • プロフェッショナルSSL/TLS (途中)
  • The QUIC Transport Protocol: Design and Internet-Scale Deployment

とかそのくらい。 本・論文以外ではQUIC関連のRFC・Internet-Draftは結構読んだかもしれない。

技術同人誌

技術書典4,5でも昨年同様サークル進捗大陸で合同誌を出した。 おそらく他のメンバーの記事目的の方が多いのだとは思うけど、たくさんの人に買っていただいてとても嬉しい。ありがとうございます。 自分のやったことが直接お金になるというのはあまり得られない経験だし楽しいので、とても大変だけど、機会があればまたやりたい。というかこういうのをやらないと腐っていく気がする。

前から飼いたかったねこを飼いはじめた。とてもかわいい。最近は寒いので、寝ているとよく布団の中に入ってきてかわいい (寝返りがうてなくなるけど)。

レーニン

少し太ってきたこともあって、12月初めから家でNIKEのアプリを使ってトレーニングを始めた。このアプリがけっこうよくて、自分専用のプランを作ってくれてその通りにやっていればいいので続けるハードルがだいぶ低い。トレーニングは自分で適当にやると本当にこれでいいのかなと思うこともあるけどこのアプリなら正しいトレーニングをしている感も出ていい。ダイソーで600円で売っていたヨガマットの上でやっている。まだ半月ほどだが腹筋が軽くついたおかげかお腹がへこんだ気がする。

Webサービス

以前ははてブスマホアプリを一日中眺めていたが、コメントが精神を蝕んでいくような気がしたのでアプリを消した。全然困っていない。 Twitter も宣伝以外はもうほとんどツイートしてない (タイムラインはわりと見てはいるけど)。

メモは scrapbox に全部寄せた。メモとか適当な文章は見られたくない (見られたことを知りたくない) ことがけっこうあって、 scrapbox はあまり検索にも出てこないし、自分にとってよかった。リンクも便利でスケールしそう。scrapbox は未来の自分用、他人に見せる用の文章ははてなブログなりQiitaなりでという使い分けになった。ただ情報発信したいという気持ちが基本ない (したほうがいいだろうなとは思うけど) ので、scrapbox ばかり使うことになりそう。

ゲーム

undertale がよかった。スマホのゲームも何個かやったけど一週間くらいですぐ飽きてしまう。

漫画

いま単行本を買っているのはアオアシ約束のネバーランドBLUE GIANT SUPREME。 あとは毎日朝起きたらLINE漫画の毎日更新される漫画を読んでから活動を始めるのが習慣になっている。

なにが幸せなのか

上にも書いたが、最近なにかについて楽しいと思うことが少なくなったり、つらいと思うことが多くなったので、なにをしたら幸せなのか、どうなったら幸せなのかを考えることが多くなった。もやもやとしていて結論はでていない。

あとは最近自分の存在価値がわからない。いや、頭では自分はいないよりいいはずだとは思うけれども、心ではそう思えなくなったりする (波がある)。無条件で自分という存在を心から認めることができている状態が一番よいのだろうけど、難しい。

活躍している人を見ると、なんで自分はこうなんだもうだめだと思ったりする。比較しなければいいのだろうけど難しい。穏やかな気持ちになりたい。歩き遍路とかしたい。

2019年

2019年はもうちょっと元気になりたい。

finch-0.9.2 の body と bodyOption のバグ

finagle の finch を触っています。

現時点での最新版は0.9.2なのですが、0.9.2には RequestReaders.bodyOption: RequestReader[Option[String]] とこれを使っている RequestReaders.body: RequestReader[String] にバグがあります。0.9.3-SNAPSHOT では直っています (自分が直したわけではない)。

finch-test を使っているときに、正しいはずの json のパーズに失敗する (expected whitespace or EOF but got \u0000 的なエラー) ので追っていったところ見つけました。でも普通にサーバとして起動するとなぜか起こらないです。finagle か netty がよしなにやってくれるんでしょうか。

↓再現コード

gist.github.com

↓バグレポート

github.com

↓修正PR

github.com

↓バグっていたところ

finch/RequestReaders.scala at 0.9.2 · finagle/finch · GitHub

割りと致命的なバグっぽいのでPRを送ってやろうと思っていたのですが先を越されてすこし残念でした。

はじめは master ブランチでバグっている箇所を探していたので見つかるはずもなく、v0.9.2 のタグに切り替えたところすぐ見つかったというあれなかんじでした。

dotfiles をアップデートした

前回 dotfiles を大幅にアップデートしたのがちょうど2013年の10月だったので、約2年ぶりの更新です。

以下変えた部分。

Emacs

  • el-get をアップデートした
  • init-loader を使うようにしたい
  • el-get-lock を使うようにした
  • helm, magit, projectile, git-gutter など超有名プラグインを導入した
    • helm-find-files だけ気に食わないけどそれ以外はとても便利
  • Coq 用の補完とかスニペットが入ってる company-coq を入れた。便利
    • それにともなって auto-complete から company に移行してみた
  • emacsclient を使うようにした
  • emacs-powerline を使うようにした

Zsh

  • oh-my-zsh への依存をほとんどなくした (ssh-agent だけ)
    • prezto にしようかと思ったけど、最初のシンボリックリンクのおかげで既存の dotfiles のなかにどうやって組み込めばいいかわからずやめた
  • fasd, k などの便利コマンドを入れた
  • prompt を pure のデフォルトに変えた
  • なんでも peco にやらせるようにした
  • zle や autoload などの使い方を覚えた
    • zstyle はまだよくわからない

Vim

  • NeoBundle をアップデートした
  • ほとんど使わないプラグインを消した

tmux

  • status bar の見た目を良くした
  • tpm を導入した
    • 適当に tmux-yank, tmux-copycat, tmux-open, tmux-resurrect を入れた
      • reattach-to-user-namespace のやつは tmux-yank がやってくれるのでシンプルになった

Setup

  • 若干複雑になってきたのでシェルスクリプトから Rakefile に変えた
  • Rakefile に変えたおかげで Ruby が最初から入っていないマシンでのセットアップが面倒になったので rbenv でのインストールを適当にやってくれるスクリプトを書いた
  • その他コマンドをインストールするスクリプトを書いた

見た目

これが

f:id:amutake:20150920235523p:plain

こうなった

f:id:amutake:20150920235713p:plain

crates.io のパッケージページで Reverse Dependencies を表示する Chrome 拡張

最近 Rust に再入門しています。

言語初心者によくある問題として、良い (信頼できる) ライブラリがどれかわからないというものがあります。 Rust の中央パッケージリポジトリである crates.io は各パッケージのダウンロード数が書かれていて、 良さそうなライブラリを見つけるときは基本的にはそれを参考にすると思うのですが、 論文での被引用論文のような感じでそのライブラリに依存しているパッケージ (Reverse Dependencies) 一覧やその数も見れると嬉しいです。

Reverse Dependencies のリンクを追加する Pull Request もあったのですが close されているようなので、 各 crate のページで Reverse Dependencies 一覧を表示する Chrome 拡張を書きました。

github.com

もともとこんなページだったのが、

https://github.com/amutake/crates.io-reverse-dependencies/raw/master/images/before.png

こんな感じに Reverse Dependencies を表示してくれるようになります。

https://github.com/amutake/crates.io-reverse-dependencies/raw/master/images/after.png

実装は Reverse Dependencies の API や一覧ページが既にあったので簡単にできました。ES6 の機能や fetch API も使ってみています。

若干面倒だったのは、Links や Dependencies の親要素である div#crate-links が非同期に挿入されることで、 "run_at": "document_idle" でも "run_at": "document_end" でもタイミングによっては挿入後にならなかったので document.addEventListener('DOMNodeInserted', ...)div#crate-links が挿入されるのを見ています。

Chrome 拡張は初めて書いたのですが便利ですね。

mbed で PS2 を操作するやつを作った

表題のとおり、mbed という自分のような初心者にも優しいマイコンPS2 を操作するなにかを、研究室の同期3人で作りました。

これは個人の日記ですのであとで3人でもう少し詳しい解説記事を書くかもしれませんが、とりあえず簡単に言うと、

こんなので、

こんなかんじのことができるようなものです。

自分がやったことは、

  • DUALSHOCK2 の回路シート?を読んで同じ回路を作る
  • ボタン入力ライブラリの大まかな設計

の2つです。

今回初めて電子工作をしたのですがめちゃくちゃ楽しかったです。他の2人は電子工作の経験者でついていくので精一杯で、いろいろ教えてもらいながらやってました。今度自分でもなにか作ってみたいです。もっと早くから電子工作に触れておけばよかったなあと思います。

今回は研究室の同期と作りましたが、研究室同期といっても自分はかなり高レイヤでしか生活したことがなくあとの2人は比較的低レイヤの方も詳しい感じで知識の方向性が若干違っていました。少し知識の方向性の違う優秀な人となにかするの、勉強になることが多くてとても楽しいです。もう一度一緒になにか作りたい気がします (もう機会なさそう)。

最後に、雑ですが、発表 (これはある授業の最終課題でした) のとき自分が担当したソフトウェア部分のスライドを載せておきます。