• 2025-01-24の日報

    2025年1月24日

    技術記事を書いて人に知識を伝える時に記事自体がボトルネックになってるんじゃないか?みたいなことを考えていた。

    AさんがBさんに技術的な知見を伝えたいとすると、

    A -> 記事 -> B
    

    となる。でも記事の体裁を整えるのにもコストがかかるし、 それを読み解いて自身の知識にするのにもコストがかかる。

    もし記事を書かずにAさんのメモをベースにしたLLMがこれを仲介したらどうなるのか?

    A -> LLM -> B
    

    となって、Aさんは記事の体裁を整えるコストを払わずに済むし、 Bさんも知りたい箇所だけを知ることができる。

    この方式だと、今書いてる日報みたいな形式でも(そのようなシステムを組めば)LLMが知識を吸収してくれるし、 BさんはAさんが記事を書くまで待たなくてもLLMを通して即日で最新の知識にアクセスできるようになる。

    ...ってのをここ最近考えていて、とりあえず自分のnoteとこのブログを使って検証してみたいなと思っている。

    今日やったこと

    Nim x ESP32

    NimでESP32する方法に取り組んでいたのだけど、 idf.pyを導入する過程でつまづいた...

    1/26追記: nixpkgs-esp-devを使えばidf.pyの環境を楽に導入できる。

    shellとpackageが提供されているので、こんな感じに書けばidf.pyが使える環境を作れる。 つまりidf.pyに依存するだけならFHSは必要ない。

    {
      inputs = {
        nixpkgs.url = "github:nixos/nixpkgs?ref=nixpkgs-unstable";
        flake-parts.url = "github:hercules-ci/flake-parts";
        systems.url = "github:nix-systems/default";
        esp-dev.url = "github:mirrexagon/nixpkgs-esp-dev";
      };
    
      outputs =
        inputs@{
          self,
          systems,
          nixpkgs,
          flake-parts,
          esp-dev,
          ...
        }:
        flake-parts.lib.mkFlake { inherit inputs; } {
          systems = import inputs.systems;
          perSystem =
            {
              config,
              pkgs,
              system,
              ...
            }:
    		{
              devShells.default = pkgs.mkShell {
                packages = with pkgs; [
    			  # idf.py導入
                  esp-dev.packages.${system}.esp-idf-esp32
    
    			  # ここにパッケージを列挙
                ];
    
                shellHook = ''
    			'';
              };
            };
        };
    }

    明日以降やりたいこと

    Nimの環境構築を試してはいるけど、でもこれってErlang(AtomVM)で楽にできるんじゃない? という疑念が出てきたのでそれを試してみたい。


    ko-fi ☕GitHub Sponsors 🐙