SSHポートフォワーディング：踏み台による中継接続 SSHポートフォワーディングには、 ローカルポートフォワーディング、 リモートポートフォワーディングの2種類があります。 sshポートフォワーディング - Qiita ローカルポートフォワーディングでは、 SSHサーバ側から見えるネットワークポートを SSHクライアント側に転送することができます。 例えば、ファイアウォール（NAT）に守られたネットワーク（ネットワークA）内にあるWebサーバ（ホストX）に 外部ネットワーク（ネットワークB）にあるクライアント（ホストY）から接続したいとき、 踏み台となる、ネットワークBから接続可能なSSHサーバ（ホストZ）がネットワークA内にあれば、 ホストYがホストZにSSH接続することで、 ホストXのWebサーバのネットワークポートに、 ホストYの指定したポートから接続できるようになります （「ホスト」は「各ネットワークに接続した、NICに割り当てられたIPアドレス」に対応）。 [email protected]: $ ssh [email protected] -L "127.0.0.1:10080:hostX.networkA.example:80" [email protected]: $ wget http://127.0.0.1:10080/index.html I am "hostX.networkA.example:80". リモートポートフォワーディングでは、 SSHクライアント側から見えるネットワークポートを SSHサーバ側に転送することができます。 先の例でいうと、ホストXがネットワークBに接続していて、 ファイアウォール（NAT）によってネットワークAにあるホストZから接続できないとき、 ホストYがホストZにSSH接続することで、ホストZからホストXに接続できるようになります。 [email protected]: $ ssh [email protected] -R "127.0.0.1:10080:hostX.networkB.example:80" [email protected]: $ wget http://127.0.0.1:10080/index.html I am "hostX.networkB.example:80". この方法は、ネットワーク内のあるホストにSSH接続ができる環境さえあれば、 VPNや他のTCPプロキシをセットアップするより簡単に隠されたネットワークにアクセスすることができるように思います。 ポートプロキシサーバ：2種類のSSHポートフォワーディングの組み合わせ ここで、別の構成のネットワークについても考えてみます。 新しくネットワークCを導入して、 ホストXはNAT内のネットワークC（hostX.networkC.example）、 ホストYはNAT内のネットワークB（hostY.networkB.example）、 ホストZはネットワークB、Cからともに接続可能なネットワークA（hostZ.networkA.example） という構成を考えてみます。 この構成で、ホストYからホストXに接続可能な環境を作るには、次のような手順が考えられます。 ホストXからホストZにSSH接続し、リモートポートフォワーディングによってホストZ上の"ポートQ"をホストX上の"ポートP"に転送する ホストYからホストZにSSH接続し、ローカルポートフォワーディングによってホストY上の"ポートR"をホストZ上の"ポートQ"に転送する これにより、ホストYは、自身のポートRを使って、ホストXのポートPに接続することができます。 もしホストXに物理的にアクセスできない環境でも、 あらかじめホストXをホストZに常時接続するように設定しておけば、 その接続（ポートQからポートPへの転送）が生きている限り、好きなタイミングでホストYからホストXに接続（ポートRからポートQへの転送、すなわちポートRからポートPへの転送）することができます。 SSH Port Forwardingを使ったPort Proxy Server in Docker 前項のポートプロキシサーバの問題として、次の3つを考えました。 ...

GitHub Self Hosted RunnerをさくらのVPS上に構築するスタートアップスクリプトを投稿しました。 https://secure.sakura.ad.jp/vps-beta/startupscripts/e3ad9634-6cda-4eeb-8a7a-6f68efedcc58 https://github.com/aoirint/sakura_vps_github_runner https://docs.github.com/en/free-pro-team@latest/actions/hosting-your-own-runners さくらインターネットさんのさくらのVPSは2010年9月にサービス開始し、2020年9月で10周年だそうで、 記念キャンペーンをやっています（応募したのは第2弾ですが、第3弾もやっていました）。 https://vps.sakura.ad.jp/news/vps-10th-campaign2/ さくらのVPS 10周年キャンペーン 第2弾 開催のお知らせ🎉 https://vps.sakura.ad.jp/news/vps-10th-campaign2/ — さくらのVPS (@sakura_vps) December 1, 2020 Twitterでこの10周年記念キャンペーンを見かけて、 ニンテンドープリペイドカードが当たる、ということで さくらのVPSの費用回収をするために Switchのゲームを買うために応募してみました（応募者が少なかったらしく当選した）。 — aoirint🎐 (@aoirint) March 20, 2021 （このステッカーほしい） スタートアップスクリプトは、新しい空っぽのVPSを契約した（単に契約済みの空っぽのVPSでも可）ときに初期設定をするためのシェルスクリプトです（初回起動時に自動実行してくれる）。環境変数みたいなものも注入することができます（スクリプトごとのプリセットに加えて、実行時に上書きもできる）。 本当は完全にSSHを使わなくていいように、自動アップデートやデータバックアップ、異常時のメール/Slack送信（おそらく異常時はバックアップからデータを復帰させてコンテナみたいにゼロベースで作り直すのがいい、と思うのだが、それならはじめからコンテナオーケストレーションサービスという選択肢があるのか..?）みたいなところまでスタートアップスクリプトに組み込めるとよいのですが、なかなかむずかしいので今回はそこまでやっていません。 さくらのVPSのスタートアップスクリプトには、公式が配布しているものに加えて、おそらくほとんど中の人なんじゃないかと思うがユーザ間での共有機能があります。 ゲームサーバ（7 Days to Die、ARK、Minecraft、Factorio、Terrariaなど）やアプリケーションサーバ（Mastodon、GitLab Foss、Nextcloud、Mattermostなど）、SoftEther VPNなんかの有名どころはそろっているように思います。 余計なアプリケーションも立ちませんし、うまくすれば完全にGUIで操作できるので、ゲーム配信者（サーバエンジニア系でなくて、事務所にも所属してない）なんかにも有用なんじゃないかな（参加型配信とか、IP公開しなくてよくなるので）と思います（国内サーバだし）。 GUI化というのはVPSのコンソールだけでなくて、Basic認証 over HTTPSとか付けてゲームサーバ制御用のWebアプリを添付してもおもしろいかもしれません（固定のサブドメインはもらえるので）。 サーバを借りるときにつらいところはメモリが少ないこと、ストレージが少ないことだと思っています（ラックサーバ構築したことないのでそれとの比較は知らないけど）が、単アプリケーションの動作なら大丈夫な気がします。 ストレージが少ないといっても、画像・動画サーバみたいな使い方をしなければ大丈夫な容量はある気がします（最安で25GB、次点で50GB）。 それはAWS S3でやったほうがいいんでしょうね。 問題は年7000-円と費用が小さくはないことですかね。 配信を含む業務に関連した目的で、個人事業主なら経費にはなると思いますが（税金）。 競合にAWS Lightsailがありますが、費用はLightsailの方が安い気がします（料金体系がよくわかってないですが。サーバ起動自体は定額でも、通信量で追加課金とかされるんでしょうか？　それこそS3があるので、アプリケーションサーバの場合ちゃんと組んでいて、小-中規模ならそんなに通信しないとは思いますが）。 趣味用途の人は「お客様満足度調査」に回答するとQUOカードの抽選があったりするのでそのへんで回収を..。 料金体系：https://vps.sakura.ad.jp/specification/ さくらお客様満足度調査、抽選当たった — aoirint🎐 (@aoirint) October 13, 2020 お客様満足度調査実施のお知らせ | さくらインターネット (2020/07)

https://www.amazon.co.jp/dp/B08QJ6Y27V ときどきセール価格になる 持ち出し用Windows/Ubuntu機として購入。 自前でPCを（一応でも）新品で買うのは初めて。 最新のCPUを搭載したPCを買うのも初めて。 本機はサポーターズ ウインターハッカソン vol.7 最優秀賞の支援金30000+1000円と、 これまでの積読でためたAmazonポイントを消費し、 セール中であり（関係ないか?）、 若干の不安は残るもののAmazon アウトレットであり、 （実質的に）定価の3分の1近い値段で購入することができた。 特に支援金の力が大きい、感謝します（MacBookを買えって? 知らんな..）。 キーボードについて、 キーストロークの浅いキーボード、 ノートPCでありがちな幅の狭いキーボード、 InsertやHomeなどのキー配置が特殊なキーボードを避けて選んだ。 キーストロークについて、 以前使っていたFujitsu Lifebook S904はキーストロークが1.0mmと浅く、苦手だった（タイプするとぺたぺたする）。 よくあるノートPCのキーストロークは1.5mm程度らしく、このあたりを目指していた。 2015-2019年あたりのMacBookのバタフライキーボードはわからないが、おそらくキーストロークが（限界まで）浅いので苦手だと思う。 2014年以前のMacBookのキーボードは好きである。 キーの幅について、 Ideapad U310はカンマやピリオド周辺のキー幅が文字キーよりも狭く誤タイプしやすかった（右Shiftキーを大きくするためか）。 生協PCとして名高いLet’s noteも幾度か触ったことはあるが、キーが小さいため誤タイプしやすく、苦手である。 キー配置について、 Ideapad U310はBackspace/Enterキーの右側にHomeやEndキーがあり、誤タイプしやすかった（入力中に文書の最初/最後までキャレットが移動してしまう）。 ところで、JISキーボードよりUSキーボードの方が好きである。 最近使っているMacBookはUSキーボードなのだが、 Backspaceキーが大きく、 キー配置が素直である（無理やり詰め込んでいない）。 しかしUSキーボードのWindows ノートPCを手に入れるのは状況的にむずかしい部分があり、 キーボード配置をレビュー写真で確認した上でJISキーボードにした。 また、AppleやHHKB系のキーボードでないのなら、半角/全角キーはほしい気がする。 本機はBackspaceキーがBackslashキーに押されてかなり小さく、不安は残るが、これは慣れで対処するつもりである（文字キーの2/3程度の大きさ。USキーボードの場合、文字キーの4/3倍程度の大きさ）。 Amazonの写真はだいたいUSキーボード（※実際はJISキーボードです、のような感じ）なので、優良誤認つらいところがある。 トラックパッドについて、 Ideapad U310では、キーボード入力中に触ってしまってキャレットが外れてしまったり、見当違いの位置に移動してしまうことがよくあった。 この点は、今のところは問題なさそうである。 CPUについて、互換性に不安を残したくなかったため、Intel CPUにした。 予算を引き上げればARM M1 Mac、引き下げればAMD Ryzenが視野に入るが、 前者はMac/Windows/Ubuntuトリプルブートなどという環境にすることになりかねないほか、ARM CPUは開発用途ではまだまだ人柱的な要素が強いように思う。もう少し普及を待ちたい。 AMD Ryzenは残念ながら使ったことはないが、一応は数値計算をする人の端くれとして、Intel MKLの互換性などで問題が起こる可能性があるため避けた。 これまで価格の関係で古いCPUばかり使っていたが、ノートPC向けとはいえ本機はIntel 第11世代 CPUなので、浦島になれる気がする（といいつつCore i3ではなくi5にしてしまったのだが）。 RAMについて、スロット8GBx1、空きスロットx1という、いい感じに増設の余地を残した状態なのが好ましい。 デュアルチャネルも捨てがたいが、空きスロットがあることでメモリを買うのが1枚だけでよくなる。 また最近のノートPCは製造簡略化、薄型軽量化のためか基板にRAMを組み込んでいるものがあるらしい。増設したい場合は気をつける必要があるだろう。 またDDR4なので過去に使っていたノートPCからメモリを移植できると思われる。 ...

https://www.amazon.co.jp/dp/B08NCJMYNT ときどきセール価格になる 3枚目兼持ち出し用ディスプレイとして購入。 家ではTwitter用、持ち出しではカフェでノートPCを開いて作業するときなどに使いたい。 サイズ感は想定通り（A4紙より長辺が1.5-2cmくらい長い、短辺は同じくらい）、画面品質もよさそう。 応答速度もTweetDeckを見る分には問題なし。 付属スタンドは結構もろそうにみえる（上から技術書を載せたら割れそう）。 また前側のストッパーが低いので少しだけだが外れやすそう（多少手で揺らした程度なら問題なし）。 適当なタブレットスタンドを探してみてもいいかもしれない。 マグネットでくっついている本体カバー（折り返してちゃんと画面側も覆うことができる）もスタンド代わりになるが、 かなり薄いのでカバーがだめになりそう.. 給電はUSB 5V 2.4A電源、およびデスクトップPCのUSB 3.0ポートで動作を確認した。 ケーブル長1mのため近くに電源が必要。Type C 1本で接続できれば別電源は不要らしい。 Type C端子のないノートPCなら給電用Type A-Type Cケーブルを空いてるUSB-Aポートに繋げば給電できると思う。 バッテリ消費は激しくなるだろうが..。 Raspberry Pi 4B、USB 5V 3A電源、Raspberry Pi OS Desktopでは、他になにも繋がずにUSB 3.0ポートにつなげた状態では給電できた。 追加で7インチディスプレイのタッチパネル用USBケーブルを繋いだらモバイルモニタ側の表示が点いたり消えたりしたので、 Raspberry Piの場合、給電中は別のUSB機器を使えないかもしれない。 梱包 クッション・保護シートを取り外したところ、右は付属スタンド 表面（カバーは折り返したときに裏にくる面、内側にディスプレイがある） 裏面（カバーを折り返したときに内側に隠れる面） 付属品（HDMI-mini HDMIケーブル、Type C-TypeCケーブル、Type A-Type Cケーブル、クロス、説明書）、 付属ケーブルはすべておおむね1m程度の長さ、 HDMI-mini HDMIケーブルは太め カバーはマグネットで付いている ボタン（表面から見て左側、写真左側が下） ...

4人チーム（miniature-octo-guide）で、SpatialChatライクなUIでタブの音量調節をするChrome拡張を開発し、 約40人 17チームの中で最優秀賞をいただきました。 https://github.com/miniature-octo-guide/spatial-volume-controller https://talent.supporterz.jp/events/28d759c2-50b4-456d-889b-1f08abf6c053/ ツイート1 音声ボリュームをブラウザ上でコントロールすることで複数の講演を同時に視聴＆往来できる【Spatial Volume Control App】（電通大チーム）が最優秀賞を獲得！ 「講演を選び切れない」 「視聴しながら比較したい」 そんな課題とニーズに応える素晴らしい作品・・・！ #ウインターハッカソン #技育祭 — 楓博光@未来の技術者を育てる (@kaepon1219) February 28, 2021 ツイート2 最優秀賞いただきました！ 「Spatial Volume Control App」（Chrome拡張） https://github.com/miniature-octo-guide/spatial-volume-controller #技育祭 #ウインターハッカソン #ウインターハッカソンvol7 #サポーターズ — aoirint🎐 (@aoirint) February 28, 2021 内容 開発に使うOSは3人がWindows、1人がLinuxでした（macOSのテスト環境も用意はあった）。 開発経験は、Web系（Pythonなど） 3人、Unity・マイコン系 1人でした。 ハッカソンは全員初参加でした。 開発アイデアを集めたのち、実装可能性を検討している中で、ベースをChrome拡張としました。 当初はOSのAPIを叩くネイティブアプリ（スタンドアロンソフトウェア）としての実装を検討していました。 Windows Core Audio、macOS CoreAudio.framework、Linux PulseAudioのAPIを叩くことを考えていましたが、 いくつかの理由でネイティブアプリでの実装を取りやめました。 参考資料が少ない Windowsでの動作検証で、Chromeタブごとの音量制御ができなさそうだった プロセスごとの制御はできる マルチプラットフォームな実装が面倒 各OSごとのAPI呼び出し GUI実装 言語にはTypeScriptを選択しました。 TypeScriptの採用理由は、流行りの言語であること、型の記述によるデバッグ性・メンテナンス性が高いこと、あたりを考えていました。 全員簡単なJavaScriptを書いた経験はあったようですが、 テンプレートをいじった程度の簡単なコードを書いた経験があったわたしを除いてはTypeScriptの経験はなさそうでした。 しっかりしたChrome拡張を作った経験は全員ありませんでした。 準備期間で開発環境を用意しました（事前開発あり）。 Docker上で開発することを想定し、 GitHub上にOrganizationを作ってパブリックリポジトリでコードをホストし、 GitHub Actionsで自動コードチェック・ビルドする環境を整備しました。 実装課題はIssueを立て、 コードの共有は同一リモートリポジトリ内でブランチを切り、プルリクエストを作成し、 統合はプルリクエストのSquash Mergeですることにしました。 ドキュメントをNotion（1000ブロック制限付きのチーム）に作成し、 コミュニケーションはDiscord（通話あり）とハッカソン用Slackを使いました。 プロジェクトテンプレートの生成にはmazamachi/generator-chrome-extension-kickstart-typescriptを使いました。 https://github.com/mazamachi/generator-chrome-extension-kickstart-typescript Linterにはts-standardを使いました。 ...

メモ書きにはSimplenoteとJoplin、Atomを主に使っています。 WYSIWYGの選択肢もありますが、基本的にはMarkdownが好きです。 Sphinxを使う関係でreStructuredTextを書いたりもしましたが、Markdownの方がずっと書いているので慣れています。 しかしMarkdownは方言が多く、込み入った機能を使おうとすると安定しないのが難点です。 ここに記事を書くにあたって脚注を使ってみようとしたのですが、 Simplenoteでは表示できず、 AtomのMarkdown Preview Plusでは手動で機能を有効化する必要があるようです。 Joplinもデフォルト有効のオプションみたいでしたが、ツールによって安定しないのは使いづらいです。 https://atom.io/packages/markdown-preview-plus SimplenoteはAndroid、iOS、Linux、MacOS、Windowsすべてから、ブラウザと認証情報さえあればすぐにアクセスできて、モバイルアプリもあるのが強みなように思います。 また、テキストオンリーということで動作の高速化を図っているらしいです。 ただし、Simplenoteに大量のメモを保存したことはない（200件程度）ので実際に大量に保存した場合（1000件以上）の動作は不明です。 Simplenoteは、必要なときにメモをとって、必要なくなったら削除する or 念のために残しておく、くらいの使い方が向いている気がします。 https://app.simplenote.com/ Joplinは、EvernoteライクなOSSです。 メモファイルはDropbox、OneDrive、S3ほかを使って同期できます。 テキストオンリーならばそれほど容量を消費しないという仮定に立てば、Dropboxライトユーザーなわたしには同期先としてDropboxがいい気がしています。 同期時は差分データをすべてダウンロードしてくるため、同期に時間がかかるのが難点です。 また、プロキシ非対応なのが不便です。 透過プロキシを使うことで強制的にHTTPプロキシを通過させることはできますが、便利とはいいがたいです。 https://github.com/laurent22/joplin/issues/164 https://github.com/wadahiro/go-transproxy Atomはメインのテキストエディタですが、Electronベースなので若干起動が遅いです。 コードやドキュメントを書くのに使い慣れているので、メモ書きにも使います。 ファイルの保存先選定に困るので、たいてい保存するときは他のアプリに移動しますが.. Notionも少し使いましたが、前記事の理由で使い続けるのはむずかしいです。 Confluenceは使い方がわかっていません（個人で使うには機能が多すぎるかも）。 Growiはそれなりによさそうなのですが、非公開利用には自前でホストする必要があったり、RAM消費が大きかったり、UI的に使い込めていない部分があります。 esa.ioは気になっていますが、Crowi/Growiベースに見えるので日常メモに向いているか不安があります。

文章1つ書くのにも余計なことを考えるようになってしまいました。 ツールを乗り換えつつ文章を書いていますが、（ツールとして）一番長く続いているのは Twitterなのかもしれません（アカウントは連続していないが、2013年にはアカウントがあったらしい）。 初期のTwitterアカウントやブログはarchive.orgに残っていて、 人間関係もリプライを検索すれば出てきます。 運用は今とほとんど変わらない（技術についてつぶやいたり、フリーソフトを公開したり）ですが、ある種のデジタルタトゥーです。 晒し、クソリプ（ブコメ、引リツ）、デジタルタトゥーのようなものを踏まえると、 個人的な考えを文章化して発信することには結構（精神的な）リスクがあります。 もちろん、技術的に未熟のため見当違い・陳腐な感想を書いてしまうのがあまり好きではないというのもあります。 これも後で見返したときに精神的ダメージを受ける可能性があるためというのがあります（前記事参照）。 技術記事ではそれ自体の性質に加えてこのようなリスクを避けるため、可能な限り感想的なものを排除したいというふうに思っています。 新しい記事では時折考えのようなものを含めていることもありますが、挑戦的なものです。 技術記事の寿命は、需要はともあれ、10年以上前の古い技術ブログを参照するようなこともあるなど、結構長かったりするように思います。 技術記事では、記事の内容は生きているが、思想が更新されたという状況は避けたいです。 大抵の場合、記事は自分が見返すために書いているので、リスクが高いです。 しかしお固い企業アカウントのような体裁でいてもつまらないので、お試しでダイアリーを書いてみます。 気が向いたらaoirint.comのサブドメインに移すかもしれませんし、やめてしまうかもしれません。 媒体ですが、マイブームはGit+SSG（JAMStack）なのですが、謎のYAMLヘッダを付ける必要がある、投稿自体が面倒、微修正が手間など、いろいろと利便性に欠けるところがあるので、はてなに戻ってきてみました。 好きなことを好きに書きたいので、Twitterに近い使い方をする可能性もあります。

わたしは一度書いたメモのことはわすれたいです。 必要なときがきたら検索で探せばいいのですから。 しかし今のメモアプリはわすれることができません。 エディタを開くと、夢の記録から作品の感想、創作のメモ、書きたい記事、開発のメモ、研究のメモまで、色んなジャンルのノート（あるいはノートブックの名前）が一覧表示されてしまいます。わたしはこれが苦手です。 例えば、メモアプリを開くたびに、 支離滅裂な夢のストーリー、それに対する考えを見る（あるいは思い出す）ことになり、 初見ではおもしろいと思った作品の粗探しをすることになり、 解決済みでわすれるべき課題が幾度も目に入る（いつまでも残っている警告の貼り紙は不快）ことになり、 創作の設定や筋書きほか、Not Safe for Publicなメモ内容、また個人情報などをスクリーンショットや画面共有、覗き見で晒すリスクもあります。 業務ならば大抵の場合、作業目的（タスク）がはっきりしているので、必要な情報にすぐアクセスできた方がよいのですが、 日常的なメモの場合は、ノートブックやノートの一覧が表示されると、 このような形で心理的に不安全です（Not Safe for Home/Work/Cafe）。 P.S かなり個人的な会話を人に聞かれることに抵抗がない、というのを観測してもいます。 カフェで個人的な会話を大きな声でするのに近いです。 歳月を重ねることで恥が積み重なっていって、気にしなくなるときが来るのかな。 きっと10年前も同じことを言っていたと思うので、10年後も同じことを言っているのだろうと思うけれど..

Psychopy - GitHub y軸反転と画素値をfloat（0-1）に変換すればOK。 npimg: np.ndarray # (height, width, num_channels) stimimg = np.flip(npimg.astype(np.float32) / 255, axis=0) ウインドウに表示させるサンプル import numpy as np # numpy>=1.20.1 import cv2 # type: ignore # opencv-python>=4.5.1.48 from psychopy import core # type: ignore # psychopy>=2020.2.10 from psychopy.visual import Window, ImageStim # type: ignore import sys # npimg: np.ndarray = cv2.imread('image.png', 1) npimg: np.ndarray = np.zeros((400, 400, 3), dtype=np.uint8) npimg = cv2.line(npimg, (0, 50), (400, 50), (127, 127, 127), 3) npimg = cv2.line(npimg, (50, 0), (50, 400), (255, 255, 255), 3) # cv2.imwrite('image.png', npimg) stimimg = np.flip(npimg.astype(np.float32) / 255, axis=0) window = Window((400, 400), color='black', units='pix') stim = ImageStim(window, pos=(0, 0), size=(400, 400)) stim.image = stimimg stim.draw() window.flip() core.wait(3) # while True: # stim.draw() # window.flip() # # for keys in event.getKeys(timeStamped=True): # if keys[0] in [ 'escape', 'q' ]: # sys.exit(0) # # core.wait(0.01)

Python製のドキュメント生成ツール。 Python 3.8.5 Sphinx 3.4.2 Sphinx · PyPI pip3 install Sphinx reST（reStructuredText） SphinxではデフォルトでreStructuredTextというマークアップ言語を使う。 https://www.sphinx-doc.org/ja/master/usage/restructuredtext/basics.html https://atom.io/packages/language-restructuredtext 既存Pythonプロジェクトにドキュメントを追加する setup.py などが存在するPyPIパッケージプロジェクトを想定する。 プロジェクトのルートに docs ディレクトリを作成し、 インタラクティブツール sphinx-quickstart を実行する。 mkdir docs cd docs/ sphinx-quickstart Separate source and build directories (y/n) と聞かれるので、 y 。 プロジェクト名、著者名、言語などを答える。 source ディレクトリ、 build ディレクトリ、 Makefile が生成される。 make html 以上のコマンドで build/html ディレクトリにHTMLが生成される。 python3 -m http.server -b localhost -d build/html などで確認する。 次はPythonモジュールのdocstringからドキュメントを自動生成する。 Sphinx でPythonのAPIドキュメントを自動作成 - Qiita python書くなら絶対に使いたい2つのドキュメント生成ツール - Qiita #!/bin/bash SCRIPT_DIR=$(cd $(dirname $0); pwd) cd "${SCRIPT_DIR}" sphinx-apidoc -f -o "./source/api" "../mymodule" make html docs/mkdocs.sh を以上のように作成し、実行する（TODO：Makefileへの入れ込み）。 ここでは、以下のように docs ディレクトリと並んで、パッケージとして提供するPythonモジュール mymodule のディレクトリがあることを想定している。 なお、 docs/source/conf.py は設定ファイルであり、 例えば html_theme = 'sphinx_rtd_theme' のような設定を追加し、 pip3 install sphinx-rtd-theme してから make html することで、Read the Docsスタイルのドキュメントを生成できる。 ...