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スタイルのドキュメントを生成できる。 ...

$ docker -v Docker version 20.10.0, build 7287ab3 $ brew -v Homebrew 2.6.2 Homebrew/homebrew-core (git revision ce927; last commit 2020-12-19) Homebrew/homebrew-cask (git revision eb977; last commit 2020-12-19) $ brew info xquartz xquartz: 2.7.11 (auto_updates) https://www.xquartz.org/ /usr/local/Caskroom/xquartz/2.7.11 (74.6MB) From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/xquartz.rb ==> Name XQuartz ==> Description Open-source version of the X.Org X Window System Docker Desktop for Mac 3.0.2 (50996) macOS Catalina Version 10.15.7 XQuartzのインストール（HomebrewとHomebrew Cask） 現在はbrew caskコマンドは非推奨で、brewだけでOK（あるいは--caskオプションをつける）。 XQuartzの場合は--caskをつけなくても内部で勝手にbrew caskとしてインストールしてくれた。 Homebrew CaskというのはGUIアプリケーション向けのHomebrewの拡張らしいが、Homebrewと何が違うのかわからん。 Warning: Calling brew cask install is deprecated! Use brew install [--cask] instead. The Missing Package Manager for macOS (or Linux) — Homebrew homebrew-cask — Homebrew Formulae Homebrew/homebrew-cask: 🍻 A CLI workflow for the administration of macOS applications distributed as binaries command line - What is the difference between brew and brew cask? - Ask Different homebrew-cask/USAGE.md at master · Homebrew/homebrew-cask Homebrewは、開発元からソースコードが配布されていて、そのコンパイル済みのバイナリ（またはソースダウンロード＋自動ローカルビルド）を提供するもので、 Homebrew Caskは、*.dmgが配布されていてマウントして*.appを/Applicationsにコピーする操作（実際には/usr/local/Caskroomにインストールする）のを自動化する、というものなのだろうか? --caskを明示するのは両方に登録されていてもCaskを優先するみたいな指定なのか? XQuartzの場合は--caskを付けなくてもCaskとしてインストールされた。 ...

GitHubがパスワードによるGitアクセスを無効化する（正確にはパーソナルアクセストークン認証を必須化する、だが現状SSH認証は残る）旨のアナウンスをした（Token authentication requirements for Git operations - The GitHub Blog）。 これまで、コマンドラインGit操作のためのGitHubの認証にはパスワード認証（HTTPS Basic認証）を使っていた。 一応、リポジトリを操作するたびにパスワードを入力するのは面倒なので、 cacheは有効化していた。（git config --global credential.helper cache）。 パスワード認証は、持ち出せないPCやVPS、モバイル端末や新しいPCから一時的にリポジトリにアクセスする必要があるときに便利だった。 もちろん、キーロガーやgitコマンドなどシステムがハックされている可能性を考えると望ましくないことはわかっていたが..。 以前はSSH認証を使っていた時期もあったが、ブラウザ上での鍵の登録削除操作が必要でこういった一時的な認証には向かない（この記事ではこの問題は解決しない。都度PATを用意するか、平文保存するか、あるいは手元で認証情報を持つ必要のない自動デプロイを採用することになるかもしれない）。 また、同じGitホスティングサービスに複数アカウントを作っているとき、デバイス数×アカウント数と大量に鍵を管理する必要が出てくる（この記事ではこの問題も解決しない）。 自分の認識として、GitHubのGit操作をする認証にはパスワード認証（HTTPS Basic認証）、SSH認証、パーソナルアクセストークンがある（GitHub ActionsのトークンやOAuthなどは除く）。 SSH認証を使っていなかった理由は先に述べた問題（一時的なアクセス・大量の鍵管理）のほかに、プロキシがある。 自分の環境では、ネットワーク/場所が変わるたびにプロキシ設定を切り替える必要があり、 HTTPS認証の場合、毎回git config --global http.proxyあるいはgit config --global --unset http.proxyを打つことになっている（あるいはシェルスクリプト。globalなのはリポジトリ別に設定を残さないためとcloneができないから）。 ここでSSHを使うとHTTPプロキシ経由で通信するためのProxyCommandを設定することになるが、これがやっかいである。 まず、OSごとにプロキシコマンドが異なる。connect -H（Windows）、ncat --proxy-type http --proxy（macOS）、nc -X connect -x（Linux）とそれぞれのOS用の設定を用意することになる。 また、プロキシのON/OFF自体については、ふつうにsshでつなぐときは、ワイルドカード設定を使って接続先名でプロキシを切り替えるようにしているのだが、 Gitの場合は接続先名を変えるためにgit remote set-urlする必要があり、これにはリポジトリのパスを記憶して頻繁に入力する必要が出てきてしまう。今のところそのような認識であるので、パーソナルアクセストークンを使った認証に切り替えていく。 パーソナルアクセストークン（PAT）は、パスワードの代わりに利用可能な認証情報で、権限を絞ったトークンを生成できる。GitHub Package Registryを利用するときに使っていて（docker login docker.pkg.github.com。パスワード認証不可。現在GitHubのDockerレジストリはpull認証不要のGitHub Container Registry ghcr.io に置き換えられる予定でパブリックベータ中）、好印象を持っていた（PyPIやDocker Hubでもトークン認証が便利）。また、GitHubはSSH認証よりもHTTPS認証を推奨している。PATの設定箇所は若干わかりにくいが、Settings > Developer settings > Personal access tokensから設定できる。 主要機の切り替えにあたって、トークンを毎回入力するわけにはいかないので、入力されたパスワード（トークン）を認証情報マネージャを使って永続化する設定をする。Windows（Git for Windows）、macOSでは自動で設定されるように思うが、Ubuntuでは手動設定することになる。 libgnome-keyringのgit-credential-gnome-keyringというのがあるが、libgnome-keyringが非推奨になっている（linux - Error when using Git credential helper with gnome-keyring as Sudo - Stack Overflow、[libgnome-keyring] Deprecate libgnome-keyring. Use libsecret instead）ようなのでlibsecretを使う（裏側では同じgnome-keyringが動いているようだが）。 どちらもほぼ手順は同じだが、開発用パッケージからソースコードを取得したあと、手動でmakeするという謎手順がある（#パッケージマネージャとは）。これで一応保存時の暗号化（復元可能）は施された状態で永続化できる。 ...

Debian – buster の bash パッケージに関する詳細 http://ftp.jp.debian.org/debian/pool/main/b/bash/bash_5.0-4_amd64.deb wget http://ftp.jp.debian.org/debian/pool/main/b/bash/bash_5.0-4_amd64.deb mkdir bash tar xvf bash_5.0-4_amd64.deb -C bash/ cd bash mkdir data tar xvf data.tar.xz -C data/ cd data # here is root directory

docker save | Docker Documentation docker pull alpine:3 docker save -o out.tar alpine:3 mkdir out tar xvf out.tar -C out/ cd out/6709f754bd0ccbbea9a7481e92772a494cca1543b3421978edff62bc5de16662 tar xvf layer.tar -C layer/ cd layer # here is root directory