更新内容 2024/09/14 記事の内容を整理した。もともとRyeを使う際に詰まった記録を記事にしたものだったが、あまりにRye依存になる記述が多かったので、python-build-standaloneを例とした内容に置き換えた。 Ryeのときの話はRyeをNixOS上で動かそうとしたときの記録（2024年2月）に移動した。 前置き NixOSはNixOSの内側で生活するには十分快適だが、その外で作成されたソフトウェアを持ってこようとすると、途端にめんどくさくなる。その例として 動的リンカのパスが解決できず実行バイナリが動かない shebangのパスが解決できずシェルスクリプトが実行できない が挙げられるが、今回は前者の話をする。その解決方法としてpatchelfとnix-ldがあるのでそれを紹介する（後者はenvfsで解決可能だが、もしかしたら後日記事にまとめるかも） この件についてはすでにZennでまとめてくださっている人がいる（参考：NixOS に関する小ネタ集）し、なんならnix-ldの製作者のブログでほぼ同じ内容の記事を書かれていた。が、今一度自分も整理のため、具体的にぶち当たった事例も含めて書いておこうと思う。 要約 nix-ldを導入すれば、NixOS外の実行バイナリが動くようになる 共有ライブラリが足りないなどのエラーが出た場合は、LD_LIBRARY_PATHを指定する nix developで上記環境変数が設定されるようにnixファイルを書いたほうが良い python-build-standaloneがNixOS上で動かせないことの確認 ここでは、外部でビルドされたpythonであるpython-build-standaloneをNixOS上で動かそうとしてみよう。なおpythonはnixpkgsから入手可能であり、通常利用の場合はわざわざ外部からビルド済みのpythonを持ってくる必要はないのだが、今回は例のためにこれを実行することを考える。 pythonのstandaloneをDLしてくる。 1 2 3 4 5 6 7 8 9 10 11 [bombrary@nixos:~]$ curl -LO https://github.com/indygreg/python-build-standalone/releases/download/20240107/cpython-3.12.1+20240107-x86_64-unknown-linux-gnu-install_only.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 64.6M 100 64.6M 0 0 17.0M 0 0:00:03 0:00:03 --:--:-- 24.5M [bombrary@nixos:~]$ tar -xzf cpython-3.12.1+20240107-x86_64-unknown-linux-gnu-install_only.tar.gz [bombrary@nixos:~]$ cd python/bin [bombrary@nixos:~/python/bin]$ ls 2to3 2to3-3.12 idle3 idle3.12 pip pip3 pip3.12 pydoc3 pydoc3.12 python3 python3-config python3.12 python3.12-config 実行してみると、required file not found という、先ほどのNo such file or directoryと同じようなエラーが出てくる。 ...

更新内容 2024/09/14 これは2024年2月ごろにNixOS上でRyeを動かそうと悪戦苦闘したときの記録である。現在だと uv の登場でいろいろ変わっており、この記事の内容が再現しない可能性が高いので注意。 要約 NixOS外でビルドされたたいていのバイナリはリンカのパスが /lib/ や /lib64/ が前提であるようになっているが、NixOSにはこれがないのでそのままでは動かない 解決策としては以下のようになる nix-ldを導入する 共有ライブラリが足りないなどのエラーが出た場合は、LD_LIBRARY_PATHを指定する それでもうまく動かない場合はあるので、できればNix外のバイナリを使うのは避けたい 経緯 Pythonのプロジェクト管理ツールであるRyeを使いたくなった（もちろんNixOSを使っているんだからRyeを使わず全部nixファイルで管理しろ、と言われればその通りなのだが、手軽にパッケージや仮想環境を管理できるところに惹かれて使ってみたくなった） Ryeはまだ盛んに開発されており、まだまだ今後変わりうる可能性があるが、現バージョン（0.24.0）で試しに使ってみよう。nixの場合、以下のコマンドで一時的にRyeを入れて実行可能だ。 1 nix run nixpkgs#rye プロンプトに従って進めていく。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [bombrary@nixos:~/python/bin]$ nix run nixpkgs#rye Welcome to Rye! Rye has detected that it's not installed on this computer yet and automatically started the installer for you. For more information read https://rye-up.com/guide/installation/ This installer will install rye to /home/bombrary/.rye This path can be changed by exporting the RYE_HOME environment variable. Details: Rye Version: 0.24.0 Platform: linux (x86_64) ✔ Continue? · yes ✔ Select the preferred package installer · pip-tools (slow but stable) ✔ Determine Rye's python Shim behavior outside of Rye managed projects · Make Rye's own Python distribution available ✔ Which version of Python should be used as default toolchain? · cpython@3.12 ところが、最後のcpython@3.12.1のダウンロード後、No such file or directory という一見謎のエラーで終了する。 ...

NixOS 23.11をセットアップした時のメモ。 目標 NixOS環境については以前構築したことがあるが、勉強のためもう一度一から構築する 今後、NixOSの環境をすぐに構築できるような設定ファイル、リポジトリを作る なるべくNix Flakesを使う NixOSの設定ファイルはNix言語で記述するが、自由度が結構高くて、どうファイル分け、ディレクトリ分けをしていくのかが悩ましい。 今回はWikiの紹介されていたdotfilesリポジトリを参考にしようと思う。 とはいえ、まだまだNixOSの初学者のため、小さな部分を少し真似して作っていく。 インストールディスクの起動 Download Nixのページ下部にある「NixOS the Linux distributeion」からISOイメージをダウンロードしてくる。 ダウンロードリンクとして、Graphical ISO ImageとMinimal ISO Imageがあるが、今回は後者でやる。 Graphical ISO Imageも一度試したが、ウィザード形式で設定をポチポチ進めるだけで設定が出来上がるので分かりやすい。おそらく初学者はこれで作成された configuration.nix を眺めて、少しずつ設定を理解していくのがよいのだと思う。 Minimal ISO Imageはコンソールでインストール作業を行う。パーティションを分けたり、ファイルシステムを作ったりするのは自分でやることになる。今回は勉強のためにこれでやる。 作業の大枠はNixOS 23.11 manualに乗っているのでそれに従う。 自分の環境の場合は、ESXiの入ったPCがあるので、コンテンツライブラリにそれをアップロードし、仮想マシン作成の時にそれをCDデバイスとしてセットする 物理HWに入れる場合、ISOイメージをUSBやCDに焼いておき、起動する 起動すると次の画面になるので、一番上を選択してEnterする。 SSH接続できるようにする しばらくすると以下の画面になる。 文章を読むと、 To log in over ssh you must set a password for ether “nixos” or “root” with passwd (prefix with sudo for “root”), or … と親切にもSSHへの入り方のガイドが示されている。証跡を残すためには画像よりもテキストの方が取りやすいため、SSHで作業することにする。なお、このままコンソール上で作業する場合、loadkeys でキーボードのレイアウトを変えないと記号が思った通りに打てないので注意。 ガイド通り、パスワードを変える。 SSHで入るためには、もちろんSSHで接続しに行く側との疎通ができないといけない。これは環境によって様々。 有線の場合 DHCP有効の場合：すでにIPアドレスが取得できている状態だと思う。ip a で確認可能 journalctl -xe を見るとわかるが、どうやら dhcpcd が動いている模様 DHCP無効の場合：ip a addなりifconfigなりでIPアドレスを手動設定する 無線の場合：wpa_supplicantを使った方法で接続できるっぽいので、これを試せばよいと思う 自分の環境の場合は、VM作成時にNICをつけたし、ルータのDHCPも有効なのですでにIPアドレスが取得できている状態だった。なのでそのままログインできる。 ...

このブログはまだCI/CDも分からない頃に始めたのもあって、GitHub Actionsを使っていないビルドをしていた。いちいちビルドしてリポジトリにpushするのも面倒だし、Chanomic Sketchを昨年開設したときにGitHub Actionによるビルドを学んだので、重い腰を上げて切り替えようと思った。そのときのメモ。 色々調べていたら、Chanomic Sketchで上げたときとは違って、gh-pagesのようなブランチを作らなくても良い方法が作られていたので、その方法でやっていく。 基本的な手順はHugoの公式に書かれているが、一応現時点でのやり方をメモっておく。 （参考）現状のデプロイ方法と今後のデプロイ方法の比較 現状は、 hugo new posts/.../index.mdで記事を作成 記事を書いてhugo serverで確認 書き終わったらindex.mdのdraft: tureを外してcommit hugoコマンドを単体で実行してページのビルドをする → docs/下にHTMLが展開されるので、それをcommit pushする と手順を踏んでいたが、今回の変更によって、 hugo new posts/.../index.mdで記事を作成 記事を書いてhugo serverで確認 書き終わったらindex.mdのdraft: tureを外してcommit pushする と手順が1個減る。また、docs/ディレクトリがなくなるためコミットログがすっきりすることも期待される。 ブログの修正 まず、config.tomlのpublishDirにてdocs/下にHTMLを展開するようにしてあったが、この記述はいらないので消す。 1 publishDir="docs" また、docs/ディレクトリは git rm -rfで消す。 GitHub Pagesの設定 Pagesの設定に移動して、Build and deploymentの項目のSourceを、「Deploy from a branch」から「GitHub Actions」に変更。 workflowの記述 次に、.github/workflows/<適当な名前>.yaml を作成し、そこに以下の記述をする。 注）これは現時点でのHugoの公式をそのまま借りてきている。最新版は公式を参照すること。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 name: Deploy Hugo site to Pages on: push: branches: - master workflow_dispatch: permissions: contents: read pages: write id-token: write concurrency: group: "pages" cancel-in-progress: false defaults: run: shell: bash jobs: build: runs-on: ubuntu-latest env: HUGO_VERSION: 0.121.0 steps: - name: Install Hugo CLI run: | wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \ && sudo dpkg -i ${{ runner.temp }}/hugo.deb - name: Install Dart Sass run: sudo snap install dart-sass - name: Checkout uses: actions/checkout@v4 with: submodules: recursive fetch-depth: 0 - name: Setup Pages id: pages uses: actions/configure-pages@v4 - name: Install Node.js dependencies run: "[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true" - name: Build with Hugo env: HUGO_ENVIRONMENT: production HUGO_ENV: production run: | hugo \ --gc \ --minify \ --baseURL "${{ steps.pages.outputs.base_url }}/" - name: Upload artifact uses: actions/upload-pages-artifact@v2 with: path: ./public deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v3 やっている内容としては、 ...

年末からお正月の間帰省したときにWindowsのラップトップを持っていった。しかしWSL2にはUbuntuしか入っておらず、最近デスクトップで使っているNixOSが入っていなかった。そこで試しに構築してみたときのメモ。最低限コーディングができる環境が整った。 （IT系あるあるだけれど）NixOS-WSLの開発はまあまあ早いため、ここに書いてある内容もすぐ陳腐化してしまいそう。 インストール RepositoryのReleasesからnixos-wsl.tar.gzをDLしてくる コマンドプロンプト or PowerShell で以下のコマンドを実行 1 2 3 wsl --import NixOS .\NixOS\ nixos-wsl.tar.gz --version 2 wsl -d NixOS nix-channel --update Flake化による初回セットアップ 今回はなるべくnix-channelを使わず、flake.nixからなるべく必要なファイルを入れるようにしたい。そのほうが、今後再セットアップするときにそのflakeファイルを指定するだけで環境が構築できることを期待しているため。 とはいえ、現状のNixOSにはVimもGitも入っておらず限界があるので、それはChannelから入手する。まず現時点での最新版のnixosのChannelを登録する。 1 2 sudo nix-channel --add https://nixos.org/channels/nixos-23.11 nixos sudo nix-channel --update 次にVimとGitを入れる。Vimはテキスト編集のため、Gitはnix-flakeの動作のために必要。 1 nix-shell -p vim git NixOSで最強のLinuxデスクトップを作ろうやUsing nix flakes with NixOSに書かれている内容を参考に進めていく。 まずホームディレクトリに移動し、適当なディレクトリnixos-configを作り、そこにNixOSの設定ファイル（configuration.nix）を持ってくる。 1 2 3 4 cd ~ mkdir nixos-config cd nixos-config cp /etc/nixos/* . flake.nixを作成し以下のようにする。 inputsにnixosのリポジトリと、NixOS-WSLのリポジトリを指定する inputsの書き方はattribute setとurl-likeな書き方の2種類がある。url-likeな書き方だとtag指定の方法がわからなかったので、NixOS-WSLのinputに関してはattribute setで書いている nixosSystemの引数としてspecialArgsが指定でき、これでconfiguration.nixに引数を渡せる 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 { inputs = { nixos.url = "github:NixOS/nixpkgs/nixos-23.11"; nixos-wsl = { type = "github"; owner = "nix-community"; repo = "NixOS-WSL"; ref = "2311.5.3"; }; }; outputs = inputs: { nixosConfigurations = { wsl = inputs.nixos.lib.nixosSystem { system = "x86_64-linux"; modules = [ ./configuration.nix ]; specialArgs = { nixos-wsl = inputs.nixos-wsl; }; }; }; }; } 現在、configuration.nixではWSL用のモジュールをnixos-wsl Channelから取得するようになっている。 ...

何をするか 以下の3つの機能を実装する。 ユーザを作成する。 ユーザを認証してトークンを生成し返す。 ユーザがログインしていないと401を返す：ここでは「ユーザ情報を返すAPI」を作成。 ユーザがログインしているかどうかで異なるレスポンスを返す：ここでは「ログインしているかどうかを真偽値で返すAPI」を作成。 方針 使う技術・フレームワーク、ライブラリなど PythonとMySQLはDocker Composeで動かす。 PythonのパッケージはPoetryで管理する。 APIサーバーはFastAPI + uvicornで動かす。 認可の方式としてOAuth2.0を用いる。認可グラントのタイプはシンプルなROPC。 なぜこれを選んだのかというと、単純にFastAPIのドキュメントに書かれていたのがこれだったため。いつかほかのタイプも実装してみたい。 DBのマイグレーションはalbemicを使用してみる。今回はユーザ情報しか作らないので、alembicの使用は間違いなくオーバーなのだが、勉強のため使ってみる。 プロジェクト構成 プロジェクトディレクトリは次のようにする。 DBに関するCRUDs処理はcrudsモジュールに書く。 DBと対応するモデルはmodelモジュールに書く。 APIのリクエストボディ、レスポンスボディの形式はschemas.pyに書く。 DBのセッションの作成はdb.pyに書く。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 . ├── api │ ├── cruds │ │ ├── __init__.py │ │ └── user.py │ ├── models │ │ ├── __init__.py │ │ └── user.py │ ├── routers │ │ ├── __init__.py │ │ └── auth.py │ ├── schemas │ │ ├── __init__.py │ │ └── user.py │ ├── db.py │ ├── main.py │ └── migrate_db.py ├── Dockerfile ├── docker-compose.yaml ├── poetry.lock └── pyproject.toml ちなみにこの図はtree -I __pycache__ --dirsfirsで生成。 ...

経緯 Alembicというライブラリを知ったので、試しに触ってみたメモ。 そもそもAlembicとは Alembicとは、DBマイグレーションライブラリの1つ。SQLAlchemyと一緒に用いる。 今回やってみること 今回行うマイグレーションは、以下の3つ。 空 User(email, password)を作成 User(email, password, name)に変更 使い方 Alembicの初期化 使うDBとの紐づけ エンティティ作成 マイグレーションファイルを作成 マイグレーション 想定する状況と準備 FastAPI上でWeb APIを提供し、その中でDBを操作することを想定する。ただし、メインテーマがマイグレーションのため、この記事でFastAPIの話は一切出ない。プロジェクト作成について、詳しくはFastAPI入門を参照するとよい。この記事では、ディレクトリ構成を大きく参考にしている。 パッケージ管理にはpoetryを使う。 DBにはMySQLを使う。 マイグレーションは同期処理で行うため、入れるのはPyMySQLだけでよい。しかしFastAPIでDBを処理するときに非同期での操作を行うことを見越し、aiomysqlを入れる。この時点でPyMySQLも入る。 1 poetry add sqlalchemy alembic aiomysql alembicの初期化 次のコマンドを実行する。 1 poetry run alembic init alembic プロジェクト配下にalembic/というディレクトリが生成される。 使うDBとの紐づけ alembic.iniを編集する。sqlalchemy.urlの記述を見つけたら以下のようにする。 1 sqlalchemy.url = mysql+pymysql://<url>/<name>?charset=utf8 <url>と<name>にはそれぞれ、mysqlのサーバーのURLとそのDBの名前を指定する。例えばmysqlがdbというDocker Composeのサービスとして稼働しており、3306ポートで受け付けており、そのDBの名前がappdbだった場合、次のようになる。 1 sqlalchemy.url = mysql+pymysql://root@db:3306/appdb?charset=utf8 api/db.pyにDBエンティティのベースを作っておく。 1 2 3 from sqlalchemy.ext.declarative import declarative_base Base = declarative_base() alembic/env.pyのtarget_metadataを以下のようにする。 1 2 3 from api.db import Base target_metadata = Base.metadata 空のマイグレーション まだエンティティを作成していない状態でマイグレーションを行ってみる。 マイグレーション用のファイル作成 以下でマイグレーション用のファイルを作成する ...

注意 筆者はReact歴1週間なので、筋の良い書き方でなかったり、間違った書き方であったりするかもしれない。 前半は車輪の再発明をしてしまっている。書いている途中にreact-d3-cloudライブラリの存在に気づいたので、記事の最後にサンプルコードを記載している。 プロジェクト準備 このあたりは人によりけりだが、ここでは次のようにする。 Reactのビルド環境はDockerないしDocker Composeで構築。 Reactのプロジェクトはcreate-react-appで構築。 それではまずDocker・Docker Composeの構築から。 プロジェクトディレクトリを適当に作成し、そこにdocker-compose.yamlを書く。 1 2 3 4 5 6 7 8 9 10 version: "3.0" services: app: image: node:20-slim volumes: - ./app:/src ports: - 3000:3000 command: npm start working_dir: /src 続いて次のコマンドを実行してcreate-react-appを導入し、実行する。 1 $ docker-compose run --rm app sh -c "npm install -g create-react-app && create-react-app ." これによりappディレクトリが作成され、中にReactのプロジェクトが生成される。 ...

誤差逆伝播法の数式の説明なんて世の中にたくさんあると思うが、理解のために自分でもまとめる。 特に添字などのミスがあると思うので、見つけ次第修正する。 誤差逆伝播の計算 (1) 問題設定 入力を第 $0$ 層、出力を第 $L$ 層とする。ニューラルネットワークはよく次のようなグラフで描かれる。 円がノードを表す。ノードに入っていく矢印が入力、出ていく矢印が出力を表す。 第 $l$ 層 $j$ 番目のノードの出力を $y_j^l$ とおく (注意: この記事では $y_j^{l}$ の $l$ は添字を表すものとする。累乗ではない。これから現れる変数についても同様)。これはある関数 $f_l$ を用いて以下の式で表される。$f_l$ は活性化関数と呼ばれる。 ただし、$u_j^{l}$ は前の層の出力を用いて計算される線形和で、以下のように定義される。 このような、線形和を取って $f$ を適用するという流れは次のようなグラフで描かれる。 この $\sum | f$ のノードがたくさん集まって第 $l$ 層を形成している。 損失関数 $E$ は、重み$w_{ij}^{l}$ についての関数である。これは出力値 $y_i^{L}$ と教師データ $\tilde{y}_i$ との違いを測る尺度であるから、$y_i^{L}$ の関数でもある。 例えば、以下の二乗誤差は損失関数の一種である。 定義中に $w_{ij}^{l}$ が含まれていないじゃないか、と思うかもしれないが、$y_i^{L}$ の定義中に $w_{ij}^{L}$ が含まれている。さらにその中の $y_i^{L-1}$ 中に $w_{ij}^{L-1}$ が含まれている。以下同様にして $w_{ij}^l$ は $E$ の中に含まれている。 ...

前回の記事 と合わせて1つの記事にする予定だったが、前回があまりに長くなってしまったので分割した。 ある書式に従ったテキストファイルをパースすることを考える。パースしたデータを整形し、HTML文書として出力するところまでやる。 前回インポートした関数で今回使うものは、(漏れが無ければ)以下の通り。 1 2 3 4 import Control.Alt ((<|>)) import Control.Lazy (defer) import Text.Parsing.Parser (Parser, fail) import Text.Parsing.Parser.String (char) テキストの仕様 テキストファイルは、複数のentryで構成される。 1つのentryはタイトルtitleと中身bodyで構成される。 titleは[と]でくくられる。 titleとbodyの間、bodyと次のentryのtitleの間には、1つの改行と、0個以上の空行があり得る。それらはbodyには含まない。 空行とは、0個以上のスペースだけから構成される行のことである。 BNF風に書くと次のようになるだろう。 1 2 3 4 5 6 <entries> = (0個以上の<entry>) <entry> = <title> "\n" <empty lines> <body> "\n" <empty lines> <title> = "[" (文字列) "]" <body> = (先頭、末尾が<empty lines>でないような文字列) <empty lines> = (0個以上の<empty line>) <empty line> = (0個以上のスペース) "\n" 例えば、以下のファイルがあったとする。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [Title1] line1 line2 line3 line4 [Title2] line1 line2 [Title3] line1 line2 line3 これは次のようにパースされる。 ...