技術ノート

https://js.wiki/get-started 無料とは思えない多機能っぷりなWikiインフラ「Wiki.js」レビュー、自前でホスト＆外部サービスと連携可能 - GIGAZINE メモリ消費量 $ docker stats CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS e225b6b77209 wikijs_wiki_1 0.01% 127.6MiB / 7.681GiB 1.62% 13.1MB / 22.7MB 44.5MB / 1.45MB 11 13d085313406 wikijs_db_1 0.00% 44.57MiB / 7.681GiB 0.57% 6.64MB / 4.09MB 4.27MB / 102MB 8 初期状態で150-200MiB程度の消費量と思われる。 下記の環境をサーバとして、別端末からNATループバックによる接続を試したところ、ページ遷移時のロードや記事の保存に少しだけ時間がかかるように思われたが、Wikiサイト自体がなかなか開かない、というような重さではなかった。 CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz Memory: 8GB Storage: SSD OS: Ubuntu Desktop 18.04 docker-compose.yaml version: "3.9" services: db: image: postgres:13-alpine environment: POSTGRES_DB: wiki POSTGRES_PASSWORD: wikijsrocks POSTGRES_USER: wikijs restart: unless-stopped volumes: - db-data:/var/lib/postgresql/data wiki: image: requarks/wiki:2 depends_on: - db environment: DB_TYPE: postgres DB_HOST: db DB_PORT: 5432 DB_USER: wikijs DB_PASS: wikijsrocks DB_NAME: wiki restart: unless-stopped ports: - "127.0.0.1:8000:3000" volumes: db-data: https://hub.docker.com/r/requarks/wiki https://hub.docker.com/_/postgres 基本的に初期設定で問題ない。 ...

2023-05-18 追記：この記事には、改訂版（2023年版）があります。 リポジトリ構造 .gitlab-ci.yml app/ Dockerfile .gitlab-ci.yml stages: - build build: stage: build image: docker:20.10 services: - docker:dind rules: - if: $CI_COMMIT_BRANCH == "main" script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker build ./app -t $CI_REGISTRY_IMAGE:latest - docker push $CI_REGISTRY_IMAGE:latest

GitHubが開発するElectron製高機能テキストエディタAtomをセットアップする。 Installation macOS, Windows https://atom.io/ Ubuntu https://flight-manual.atom.io/getting-started/sections/installing-atom/#platform-linux wget -qO - https://packagecloud.io/AtomEditor/atom/gpgkey | sudo apt-key add - sudo sh -c 'echo "deb [arch=amd64] https://packagecloud.io/AtomEditor/atom/any/ any main" > /etc/apt/sources.list.d/atom.list' sudo apt update sudo apt install atom Key Binding Resolver (Ctrl + .) キーバインドが重複してどれが動いているかわからないときに便利。 Packages パッケージにより機能拡張ができる。 https://atom.io/packages/ GUIによる操作 Install: Edit > Preferences > Install Config: Edit > Preferences > Packages CLIによる一括インストール # Export Package List apm list -b -e -i --no-v > atom_packages.txt # Import Package List and Install apm install --packages-file atom_packages.txt おすすめパッケージリスト ...

以前にもOpen JTalkを触っていたが、時間が経った＆記事が雑だったのでDockerでまとめ直しておく。 Open JTalk - aoirint’s note Dockerfileを作る。 FROM ubuntu:bionic RUN apt-get update && \ apt-get install -y \ open-jtalk \ open-jtalk-mecab-naist-jdic \ hts-voice-nitech-jp-atr503-m001 WORKDIR /data ENTRYPOINT [ "open_jtalk" ] mecab-naist-jdicは形態素解析辞書。 hts-voiceはボイスファイルだが、別途htsvoiceを用意する場合は不要。 ビルドする。 docker build . -t aoirint/open_jtalk 実行する。 echo "こんにちは" > text.txt # テキストファイルの文字列から音声を生成 docker run --rm -v "$PWD:/data" aoirint/open_jtalk -x /var/lib/mecab/dic/open-jtalk/naist-jdic/ -m /usr/share/hts-voice/nitech-jp-atr503-m001/nitech_jp_atr503_m001.htsvoice text.txt -ow output.wav # 標準入力の文字列から音声を生成 cat text.txt | docker run --rm -i -v "$PWD:/data" aoirint/open_jtalk -x /var/lib/mecab/dic/open-jtalk/naist-jdic/ -m /usr/share/hts-voice/nitech-jp-atr503-m001/nitech_jp_atr503_m001.htsvoice -ow output.wav # 標準入力の文字列から音声を生成して、標準出力に書き出す（wav形式） cat text.txt | docker run --rm -i -v "$PWD:/data" aoirint/open_jtalk -x /var/lib/mecab/dic/open-jtalk/naist-jdic/ -m /usr/share/hts-voice/nitech-jp-atr503-m001/nitech_jp_atr503_m001.htsvoice -ow /dev/stdout > output.wav ffmpegで出力されたwavファイルを見るとこのような形式。 ...

$ sudo apt update Get:1 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB] Get:2 http://archive.raspberrypi.org/debian buster InRelease [32.9 kB] Reading package lists... Done E: Release file for http://raspbian.raspberrypi.org/raspbian/dists/buster/InRelease is not valid yet (invalid for another 27d 15h 31min 39s). Updates for this repository will not be applied. E: Release file for http://archive.raspberrypi.org/debian/dists/buster/InRelease is not valid yet (invalid for another 26d 5h 35min 24s). Updates for this repository will not be applied. こういうエラーが出ることがある（ログはRaspberry Pi OS）。 sudo timedatectl set-timezone Asia/Tokyo sudo date --set 2021-04-04 sudo date --set 06:00 まずは手動でタイムゾーンと時刻を合わせる（だいたいでOK）。 ...

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を使いました。 ...