---
# System prepended metadata

title: DenoでUnixコマンドを実装して将来性を確信した

---

---
type: slide
slideOptions:
    controls: false
    slideNumber: false
    progress: true
---

# DenoでUnixコマンドを実装して将来性を確信した

<!-- 
https://www.itmedia.co.jp/news/article
-->

---

## 皆さんこんにちは！

:wave:


---

<!-- 
初めましての方も多いと思いますので自己紹介させて
いただきます。

フリーランスのバックエンドエンジニアをやっております
音川といいます。

-->
My Profile

Otogawa Katsutoshi

freelance backend enginner

interesting

deno, golang, python, and more...

[twitter account](https://twitter.com/k_otogawa)

<!-- 
最近のプライベートだと、原神やって初めてソシャゲにハマったり、twitterでフロントエンドとバックエンドの言語を揃えたいためだけにtypescript採用するのはレガシーと言って炎上したりと、日々充実していますね。
-->

---

<!-- Setting 舞台 -->
## 突然ですがみなさん！jsは好きですか？

:sunglasses: 

---

## 私は大好きです！

---

<!-- 今回私が何しに来たか?というと -->

## 今回何しに来たか?というと

個人開発でdenoを使っていて、これまでに他の言語、ランタイムに無い可能性、将来性を見出したのでその紹介に来ました。


## 要するに

---

## denoの布教に来ました

![布教](https://i.imgur.com/FqNC6gr.png =x500)

入信したら幸せになれます!

---



## 前提条件

話す人のDenoの知識

1. 業務で使ったことは無い
2. 触り初めて1ヶ月経つかどうか

![ご了承下さい](https://i.imgur.com/GQNd5XU.png =x500)

<!-- 
なんで御了承ください。
Denoのコミッターや、プレビュアーがいたらなんか恥ずかしいこと言ってる気もするが、素人意見なので恐縮ですがみたいに思って聞いていただけたらと。
-->

---



## そもそもなんでDenoを触ったきっかけは

![問題提起](https://i.imgur.com/N4Umxfe.png =x500)


---

## それなりに経験あるし、名刺代わりになるようなアプリケーションが欲しい!と思った

コンテナ管理用のレポジトリを作成、管理するアプリケーションを作ることに。
できたらOSSとして公開しようかなと。

<!-- 
会社にいようが請負しようが、業務委託しようが、あれ僕が全部作ったんですよ！
とかあれあんだけ上手く言っているのは僕のおかけとか言いづらいと思うんです。

会社員だったら、マネージャーだろうがプレイヤーだろうが絶対会社のリソース使って
結果だしているわけだし、
フリーランスだったら、請負だったらそうは言っても規模ちっちゃいでしょ？とか、
業務委託でしょ？とか言われるので全部僕の実績と言いづらい。
-->

---

## ある程度nodejsで書き進めていた！

しかし...書き続けていて今後の懸念点が見つかる。

<!-- 
これはアプリケーションをnodejsで書き進めていたんですが、
-->

---

## nodejs採用の懸念点

nodejsだと

1. コマンドを実行するのが難しい。
2. 第三者から見た安全性を担保するのが難しい。

---

## 1. コマンドを実行するのが難しい。

標準で備わっているコマンド実行するための関数が難解かつ見辛い。

---

## nodejsでもzxだと頑張れるが

googleのzxを採用したら楽に。 <!-- これはnodejsからコマンドを実行するためのフレームワークなんですが、nodejs標準のやり方と比べて、1/2から1/3のぐらいの量に減りました。 -->

しかし、zxはエラーコードが0以外は全て例外と見なすため...


---

## zxだとtry catch地獄!

シェルの世界では別に異常でなくても0以外のエラーコードは頻繁に使う。

<!-- あるかないかなど確認するために0以外のエラーコードを返すので、 -->
通常のシェルスクリプトやコマンド実行するためのframeworkとしては癖がある。

一応、0以外でも例外を投げないようにもできるが...

<!-- 
ほとんどそういう設定にしてまで使いたいかというと...
多分これはgoogleさんの社内ではバックアップのスクリプトとか、そういうコケたらエラーにしないといけないものメインに使っていたからデフォルトでそういう作りにしてたんじゃ無いかなと。
だと仮定すると結構無駄が無い作りなので。
-->

---

## 2. 第三者から見た安全性を担保するのが難しい

作りたいものがコンテナとそのレポジトリ周りのアプリケーション

<!--
なのでどうしても
-->

1. 作りとして結構ファイルの読み書きを行う
2. 結構通信を送る作りになる
3. 結構管理者権限も必要(これはコンテナ扱うのでどうしても必要)

<!-- 
とりあえず、
-->

---

## どこの馬の骨が作ったものかわからんやつが作ったものとして

とても使いたく無い!

<!--
エンジニアとして名刺代わりにプロダクトを持ち歩きたいから作るのに、
気軽に僕が作ったのすごいから試しに使ってみてくださいと言いにくい。
 
ただ、有名エンジニアや会社が作ったから安全かというと
-->

---


## 有名なエンジニア、会社が作っているから安全

これはこれで、全然ロジカルじゃ無い

<!-- 
powershellのモジュールとかで管理者権限
-->

---

## エンジニアも会社も常に闇落ちする可能性がある

![闇落ち](https://hackmd.io/_uploads/BJ48hh4J6.png =x400)


<!-- 
twitter見てても本当かどうかわからないですが、某有名な賞を取った人にソースコードパクられたとかいうの流れて来たりとか、有名な人でもエビルなことをする可能性は常に付きまとう。
-->

---

## 安全性を担保するなら

使いたい人が

1. ソースコードを読む必要がある。
2. 権限の汚染の対策。

<!-- 
を行う必要がある。
-->

---

## 1. 疑うならソースコードを読む必要がある

読むとしてもすべてソースコードとして提供されているわけではない。
謎のバイナリが合って、そこからスクリプトとしてマッピングして呼び出しているなら..

みなさん!どうしますか？

---

## そうだね！逆コンパイルだね！:angel: 


![そうだねプロテイン](https://hackmd.io/_uploads/H1vVhJzxp.png =x400)


<!-- 
ちなみに今ここでCsharpとかjavaとか逆コンパイルしてソースコード読んだことある人どれぐらいいますか？

-->

---

## 逆コンパイルまでやるなら

ソースコード読むの辛すぎ...

1. コメントは無い。<!-- コンパイル時にコメントが消える -->
2. どこがnullなのかわからん。

<!-- 
値の状態がソースコードからわからない...
ということで結局
-->

---

## 読んでいて適当なところで妥協しがち

![匙を投げる](https://hackmd.io/_uploads/ByNQp1zep.png =x400)

---

## ソースコードを疑うなら、ハイスキルなエンジニアでも時間がかかる

こういうのやっていられないから仮装環境とかでサンドボックス環境を用意するけど、
仮装環境ゆえの縛りがあったりするから、すべてこれで解決はできない。

---

## 2.権限の汚染の対策

どういうことかというと、


---

## sudoにせよ、管理者権限にせよ

下記を実行するということは、helloに含まれている処理全てを管理者権限で実行するということ。

```bash=
# example
sudo hello
```

---

## そもそも管理者権限必要無い処理も含まれる

```bash=
# 必要無い処理
cat /etc/hosts

systemctl start httpd

#　やばい処理
rm -rf /*
```

---

## そんなの関係ねぇ！

1. 必要無い処理
2. 必要な処理
3. ヤバい処理

そんなの関係ねぇとすべて管理者権限で実行する。

<!-- 
っていう作りが今は普通です。
-->

---

## 本来やりたかったことは

特定のコマンド、処理のみ管理者権限を与えたかった。

---

<!-- 
改めて、
-->

## 改めて懸念点(改めて)

1. コマンドを実行するのが難しい。
2. 第三者から見た安全性を担保するのが難しい。

<!-- 
1.と2を解決できないかなぁ...
と色々調べたり、考える。

-->


---

## ここでたまたまDenoというjsの言語ランタイムをちょっと前に聞いたことを思い出す。

<!-- 
ここで最初のプロフィールの時の伏線を回収することになるんですが、
-->

---

## twitterで炎上したじゃ無いですか？

あの時、
「typescriptがレガシーなんて新しいDenoでもデフォルトで採用されているのにあり得ない！」
とかいうエンジニアが何人かいたなぁ..


---

## Deno?!なんやそれ？

---

## 期待せずに調べてみる

キラキラ言語で、自分には合わんかも...

---

## 想像以上に自分に作りたいものにマッチしていた!

![驚く](https://hackmd.io/_uploads/H1VlONaxp.png =x400)

---

## 先ほどの懸念点全部をこれ採用で解決できる!

---

## 1. コマンドを実行するのが難しい。

DenoはデフォルトでDeno.Commandという結構簡単に外部コマンドを実行するための関数があるのでこれで解決できる。
シンプルだが、本体にあるならそれに越した事はない。

---

## 2. 第三者から見た安全性を担保するのが難しい

Denoならパーミッションで担保できそう。

<!-- 
これについて
-->

---

## Denoのパーミッション

どこのファイル読み込むか？やどこに通信投げるかで、いちいち処理が止まる仕組み。

実行しているユーザーがやばい処理に気づきやすい。

<!-- 
説明してもわかりづらいので
-->

---

## 実際やってみましょう

今回denoでwhichコマンドを実装したので使ってみましょう!

<!-- 
Denoにwhichに当たる処理は無い。

こういうふうに許可聞いてくる
-->

----

## こいつめっちゃ聞いてくるやんwww!


![大笑い](https://hackmd.io/_uploads/Byuof9uka.png =x400)

---

## あらかじめ許可を与えることができる!

普段使い辛そう！とか思う人はdeno run時やコンパイル後のバイナリに対して、
-Aを引数として与えると、
すべて飛ばせる。

```bash=
# ,区切りで特定の値だけ許可
deno run --allow-read=/usr/local/bin,/usr/local/sbin which.ts

# 読み込みはすべて許可
deno run --allo-read which.ts


# 外部コマンドは全て許可
deno run --allow-run which.ts

# 全てのパーミッションの許可を与える。
deno run -A which.ts
```

---

## 全ての許可を与えると言うことは

セキュリティ的なリスクをユーザーが負うということ。
リスクを負うといっても、これで初めて、普通のプログラミング言語と同じぐらいのセキュリティ
基準になる。

---

## 管理者権限については

Denoならsudoの部分だけ、外部コマンドとして切り離せば良い

--allow-runのパーミッションで行ける!

外部コマンドの実行の部分だけみんなが知っているコマンドにしたら、第三者から見て安全性の確保は容易!


---

## 先ほど課題点二つともクリア!

1. コマンドを実行するのが難しい。
2. 第三者から見た安全性を担保するのが難しい。

めっちゃええやん！

---

## ただ、Denoにも弱点はある


---

## サードパーティのライブラリ少な過ぎ！

---

## sshクライアントさえない!



<!-- これは私はコンテナとそのレポジトリの管理アプリケーション作りたいから必要なんですよ
 
-->


---

## そんなバカな...

だって無いんだもん[ssh](https://deno.land/x?query=ssh)

---

## ということでdenoのsshクライアント作ることにしました

々色調べて、denoからrustのsshクライアントを使うのが一番楽っぽい。

---

## しかし、日本語でも英語でも

denoからrust、cppの処理を呼ぶのはHello worldレベルの処理しか
検索に出てこない。

---

## 挫けそう...

と思っていると..

---

## その時、天からの声が聞こえました

![天からの](https://hackmd.io/_uploads/SJLdPC61a.jpg =x400)


---

## そこに4つのDenoのソースコードがあるじゃろ？

![牧師](https://hackmd.io/_uploads/HkNEDCTJa.png =x400)


----

## わからなくなったら、聖書(Denoのソースコード)に帰る

![聖書](https://hackmd.io/_uploads/r1c6B0a16.png =x400)

---

## Denoで読むべきやつら

- Denoland/Deno -> Denoのソースコード(Denoからrustのライブラリ。最新、unstableの検索)
- Denoland/deno_std -> Denoの標準ライブラリ(Denoのtsのテスト、モジュールの書き方の参考)
- Denoland/deno_core -> Denoのコア部分。型の宣言があったり、いろいろ最低元なもの。
- Denoland/rusty_v8 -> denoで使っているCPPのV8エンジンにパッチ当てて、rustから呼べるようにしたもの

---

## denoland/denoのソースコードを読めば行けそう！

test_ffi配下にrustのソースコードをdenoで読み込んで検査している。

<!-- 
ここでffiという謎のキーワード出てきたんで、説明すると
-->

---

## ffiとは

プログラミング言語から、他のプログラミング言語を呼び出すインターフェイス。
denoからrustのソースコードを呼び出すための実装が入っていると思えば良い。

deno/test_ffi配下に書かれているffiのテストがffiとしての細かい仕様になる。

---

## 最新のdenoでもunstable

ただ、最新(v1.37.0)でも、unstableオプションをつける必要がある。

<!-- 
deno run --allow-ffi --unstable which
-->

---

## 公式のソースコード読めばいけそう!

---

## ということでざっくばらんに呼び出し方!


---


## rustの呼び出される側のルール

1. extern "C"と#[no_mangle]をつけた関数経由で呼び出す
2. 使える型はu8, u16, u32, pointer, struct, buffer, boolなど最低限のやつら
3. 文字列は*const u8でbufferとして渡す
4. bufferはDeno側に返さない方が良い。必要ならCのpointerとして返す(rustの未定義動作)

<!-- 
CのポインタなのでDeno側で使った後は
rust側でCのポインタを削除する関数を読んで削除。
rustのポインタじゃ無いとダメな理由はrustのポインタはプログラマが細かい処理を行えないため。
後でrustのポインタは型によって大きさ違ったり作りが複雑なので
-->

```rust=
#[no_mangle]
pub extern "C" fn connect(username: *const u8,username_len: u32, password: *const u8, password_len: u32, addr_octet: u8, addr_octet2: u8, addr_octet3: u8, addr_octet4: u8, port: u16) -> bool{
実装
}
```

---

## 以上の関数を作成して


rustの動的ライブラリとしてcargoでビルドする。

---

## deno側の呼び出しルール

1. Deno.dlopenで共有ライブラリを開く
2. 関数名と引数の型を文字列で渡す
3. 構造体を受け取るならDeno側に定義を書く必要がある
4. 構造体や文字列、ポインタをrustから受け取るならバイナリをデコードする必要あり
5. Cのポインタの削除処理
6. 最後に共有ライブラリはclose()

```ts=
const downloaded = "rustでビルドした共有ライブラリ"
  const library = Deno.dlopen(downloaded, {
  "connect": {
    name: "connect",
    parameters: [
    // username
    "buffer", 
    // username_len
    "u32",
    // password
    "buffer",
    // password_len
    "u32",
    // addr_octet
    "u8",
    // addr_octet2
    "u8",
    // addr_octet3
    "u8",
    // addr_octet4
    "u8",
    // port
    "u16"
    ],
    result: "bool"
  },
```


---

## 実際動作させてみる

docker containerからraspberrypiにあるmiyuuというユーザーにssh経由でechoで語りかけます。

<!-- 
miyuuというのは私の元カノです。
-->

---

## まとめ

Denoは
<!-- に入らせて頂きますと、 -->
1. コマンド打つの楽
2. セキュリティ意識高い
3. ライブラリ少ない!
4. rustの資産使えば結構いけそう

---

## ご清聴ありがとうございました

仕事頼みたいとか、denoのssh作ったら、使ってみたいという人はフォローよろしくお願いします。

zenn -> ![zenn](https://hackmd.io/_uploads/BkGsCMTgT.png =x300) twitter-> ![twitter](https://hackmd.io/_uploads/Bk8s1QalT.png =x300)

<!--


という事だけ覚えて頂けたら幸いです。

ご清聴ありがとうございました。
-->


---


## typescriptがデフォルトだからtypescriptはレガシーでない？


因果関係が逆で、microsoftのtypescriptのチームはwebとnodejsの方補完はサポートしている
わけじゃないですか。
nodejsのチームがtypescriptの動作を保証しているわけでもサポートしているわけでもないですよね。

例えば、あなたがdenoの作者や、rubyの作者ぐらい凄いプログラマーだったとして、javascriptのランタイムを作りました！
今作ってちょっとのところです！
typescriptのチームにあなたが作ったランタイムのサポートして欲しいというissueをあなたなり他の人なりが言ったとします。受け入れられますか？
受けいられないと思います。
なら、どうしますか？自分でtypesciprtのサポートできるようにフォークして、ランタイムがそのモジュール使いますよね？
それだけの話で、それをそのまま言うのはやらしいからマーケティング的にどういうか？って言うと、

typescriptをデフォルトでサポートしたランタイムです！って売り出すのがいいですよね？


経営的に言うと、新規だとtypescript使うのが普通みたいになっているから、typescriptのサポートしないと事業としてブーストかからないからそうしているってことです。

間口は広い方がいいので、


--- 

## powershellはとりあえず管理者権限で開いて

どういうことかというと、
管理者権限

sudo も同じような弱点を持っていて、
sudoに汚染される

これを防ぐ手段として

最近だったら、
OpenBSDのdoas

jsの世界に

プログラミング言語、ランタイムとしてはDenoが挙げられるように今後なるんじゃないかなと。

typescriptをデフォルトで使うようになったとか、nodejsよりもコマンド打つの楽になった。

---


## 標準ライブラリは言語ランタイムと切り離されている

地味だからか、Denoのすごいところとしてあまりみんな言わないけど、
これは丁寧な作りで、

例えば、nodejsは標準ライブラリと、言語ランタイムが張り付いている

するとどうなるか？

---

## みんなでDenoのライブラリを書く必要がある

特に私に任せて頂けたら、ええお値段で書きますぜ。


---

## typescriptがデフォルトということ



---

## typescript否定すると



<!-- 
rails のコアメンバーのDHHもtypescript否定派だからといって、
世界中からバカにされたり、色んな言語で
-->

---

## 

1. tsとjsどちらの破壊的な変更の影響を受ける


----

## typescript細かい仕様が無い

細かい仕様がないから、typescriptのコンパイラをrustで書こうという取り組みで難儀してたりする。

<!-- 
細かい仕様は無いのはrustも同じらしんですが、
仕様なくても、cppの仕事を置き換えるっていうのが大事な指名なんで、
迷ったらcppを参考に、教科書にするというやり方でいける

-->

---

## 細かい仕様が無いことの何が困るか

みなさんも経験あると思うんですが、

---

## 気がついたら、ドキュメントと

## 

tsは本質的にはjsのliterのメタプログラミングなので
それと役割が似ているやつでうまいこといっている、失敗している
言語を探して、それが今どんな

結果は現象

## powershellが適任かなと

powershellは本質的にはcsharpのメタプログラミング
(一部cppのdllを読んでいる処理もあります。)

## 気がついたら壊れている

私が確認しただけでもかなり壊れている、ドキュメント食い違っている処理があって、

1. Set-Acl
2. New-Vm
3. タスクスケジュール周り
4. csvのパース(excel、accessでも無い、ISO基準でも無い特にドキュメントに無い謎のcsvのパース)
その他色々
<!-- ムカつくことにinternal classになっているのでどういう基準のパースって言われたら、powershellで -->

---

## 

実務として、メッセージング、localize周りのclassとか処理だったら、リソースファイルを見て、ソースコードを作成するscaffoldを行う処理とかは規模大きくなったら、考えているやっているところあると思うんですが、それで壊れた処理を生成する可能性がある。

(厳密に言うと最終的にtsのバージョンが上がるとjsにした時に同じコードを吐くことが保証されない)

<!-- 
typescript否定すると大規模やった事無いとか謎マウント取る人結構いるんですけど、
typescriptが実は大規模に向いてないんじゃ無いかと個人的に思っている部分の一つ。これは結構客観的な事実かなと。
これを否定するなら、version上がっても同じソースコード吐く処理書いてあることを証明せよになる。
-->


---

これで選択しないといっても、内部的にはなんか選択しているんでしょ？


同じMSのプロジェクトですね。不思議ですね。

---

## denoは

おそらく、typescriptのコンパイラの部分は本体から切り離されて、
deno compilerみたいになって、
denoのバージョンに対応したtypescriptのバージョンでコンパイルするみたいになる

denoのバージョンに対してtypescriptのバージョンが張り付いている

関数型言語のelm使いたかったらそっち使おうとか。

ひょっとしたら、typescritptの悪いところを直したサブセットが今後出る可能性もあるのでそっちの方が良い可能性がある。

---

## あくまでdenoは言語ランタイム、ビルドなので


---

## パーミッションは安全か？

OSのカーネルランドでその都度ユーザーに対話形式で聞いているわけだから、実行時にユーザーが知らない間に読み書きしない、通信を打たないなどのことを起きないから安全ってことでセキュリティを担保している

<!-- わざわざOSのってつけているのはjs語で、カーネルランドって違う意味になる時があるからこういう言い方している -->

---

## 

ここら辺はエンジニアの設計スキルの腕の見せ所で
これだけでセキュリティ担保できるということはありえない。
あくまでdenoはランタイム時に知らないうちに実行されるのを止めるだけ。

---

## 

1. ユーザーランドからカーネルランドにその操作をやって良いか？という機能と組み合わせる。
-> sudo, doasなど

---

## 動的にバイナリ読み込み？できるよ！

runならいいけど、compileなら埋め込みのほうがいいですよね？

<!-- 
通常の読み込み権限で読み込めるから、今後はパーミッションで------allow-dynalic moduelとか適当な名前のパーミッション使われそう。
-->

---

## バイナリをどう呼び出したらいいかわからない。

英語でも日本語でもHelloWorld的なwasmの呼び出し方ばっか。
sqliteとかは結構メンテナンスされている感じはあるが、wasmかつcppなので、自分がやりたいものと構成が違う。

もうちょっと例が欲しいとかは結構ある。
前後の処理が欲しいとか。全体の構成とか。

---

## whichコマンドの実装としては厳密にはおかしい

どこがおかしい？

---

## カーネルに聞く必要がある

実行ファイルとしてOSが認識しているかチェック

1. chmodから見れるパーミッション
2. aclから見れるパーミッション
3. カーネルランドにあるセキュリティframeworkが判断する

---

## セキュリティ的にいいなら

カーネルはシステム上神様で最終てきにやって良いかはコイツに聞く必要がある。


---

## whichコマンド

[pythonのソースコード](https://github.com/python/cpython/blob/main/Lib/shutil.py)

os.access -> osのシステムコール faccessat

_exists

という設計
ヘッダーファイルは
/usr/include/unistd.h

これらをrustで設計したら良い。

[](https://github.com/rust-lang/libc/blob/main/src/unix/linux_like/linux/mod.rs)

---


## 

<!-- 
後、暗号化周りとかBuffer周りとかC言語と張り付いている部分のプログラミング言語自体のビルド時間が長くなる
--> 



---

## Denoの懸念点

褒めるところ合ったら、絶対懸念点はある

<!-- 
仕事にせよ、個人開発にせよ、趣味にせよ
-->

---

## ここら辺は

個人的な願望とか、そうなるんじゃないかなという個人的な
未来予測であることは伝えておきます

---

たまに言われるnpmが使えるようになったから、Denoでライブラリが新規作成されるの減るのでは無いか？
はあまり懸念点と思っていなくて、nodejsの昔から使われているライブラリは結構中身古くて、
そろそろ業界としてもリファクタリングする必要あるかなぁと思うやつが結構あるので、
暗号周りとか、システム周りとかに多いから、それらはDenoで書き直す勝ちはあるんじゃないかと。

それら参考にDenoのライブラリ書いたらええんじゃ無いかなと。

nodejsで一番使われているライブラリの一つにssh2とかあるんですが、
any型であることを利用して再代入しまくってたり、使われていないswitchがあったり、テストコードが読むのキツかったり、昔は結構ギークな人が個人のス

---

## ないコマンドはDeno.commandという形で
サブプロセスとして実行して戻り値とってくるという形もで着るけど、
それだとサブプロセスとして実行されたプロセスが何をやっているか？
はDenoからは見えないので、ファイルの書き込みしている

外部コマンドを
--allow-runを認めるとパーミッションのメリットが少なくなる。

と言うことはつまり。

----

---

## 

これも一応欠点があって、権限のチェックだけなら良いけど、権限をチェックしてそのまま実行するなと。
[access](https://manpages.ubuntu.com/manpages/impish/ja/man2/access.2.html)


denoland/x/plugもちょっとクセある。

“${DENO_DIR}/plug/file”
に共有ライブラリのモジュールをキャッシュで持ってしまう。

デフォルトだとキャッシュを持ってしまっていて、
もし値が変更されてても同じやつを実行してしまうので、

“${DENO_DIR}/plug”
にキャッシュを持ってしまっているので、削除する必要がある。

ここがリードされるたびにダウンロードさせるのはアレなので、
本番はキャッシュされないようにして、開発はキャッシュされないようにする。
など。

これはdeno本体か、denoland傘下のプロジェクトにあるべきなので、
denoのffiが安定したら、使わなくなる可能性があるのであまり散らばらないように実装する必要がある。

---

## debianの共有ライブラリを使う

postgresqlのクライアントを描いてみる



[psycopg](https://www.psycopg.org/install/)

インストール先や共有ライブラリの名前を調べる。

[libpg-dev](https://packages.debian.org/search?keywords=libpq-dev)


libpg-devを見るとbullseyeを使うのでそれを見る

list of files

https://packages.debian.org/bullseye/libpq-dev

<!-- 
見ないといけないのはdependencyというところと
list-filesというところで、
dependencyはdebianの場合は特に初期設定変更しなければ、


/usr/lib/x86_64-linux-gnu/libpq.soにファイルがある。
これはcpuがx86_64で動作しているlinuxの共有ライブラリという意味。


libpq5というライブラリに依存している
/usr/lib/x86_64-linux-gnu/libpq.so.5
/usr/lib/x86_64-linux-gnu/libpq.so.5.13

単なるラッパーっぽいので、

https://www.postgresql.jp/document/13/html/libpq.html
-->

---

## 単なるラッパーっぽいので、

libbp.soを参照するだけでよさそう

psycopgのソースコードを見て使い方も調べる。

---

## debug時はキャッシュを持たないようにする。

---

## 現時点でではstaticなモジュールは呼べない

ただ、denoでコンパイルして、シングルバイナリを作るという動きに今後なりそう


---


## よくある勢力図

jsランタイムとして三つ巴!戦国時代!

nodejs VS Deno VS bun

golangとpythonは他言語なのでカヤの外

でなくて、

---

## 実際はこうじゃね？

nodejs VS bun

Deno VS golang VS python

---


nodejs VS bun -> 速度、キラキラ技術。そのための運用、開発の手間は許容。

<!-- 
bunは1.0出たばっかなので、無い機能とか言っても、これからそれ書くつもりだよとか、草案としてある。とか結構ありそうなので、雑な考察ね。そもそもソースコードとビルド時依存が難しい！
-->

Deno VS golang VS python -> システム周り、バッチ処理など堅いことが要求されるもの(差別化点として、denoはV8エンジン、tsの破壊的変更の影響を受ける、golangはgoing my wayで壊さないことに全力投球できる)

---

## 

特にDenoの依存関係が独立しているのがシステムプログラム、OS周りの処理としてかなり強そう!

pythonはシステム周りのプログラムとして雑にバージョンを上げるのが難しい、
pythonはさくっとかけるので、やったらめったらいろんなもののビルド時依存に使われてている。
nodejsとか

<!-- 
この中でgentooを開発機として利用している人！自宅サーバーとして利用している人！
パッケージ周りの依存関係でトラブル起きるのが圧倒的にpythonで、その次はrubyかな？goに依存しているやつはバチくそ楽なので、全部golangに移行してくれんかな？とgentooの思想とgolangの得意なことが結構噛み合っているので、gentoo改造してandroidとchromeos作った会社の作った言語だなぁとは思いますねl。pythonで得意なことは全部golangが得意か？と言ったら、そうでなくて、その部分はDenoが補う未来が来ると思っています。
-->

---

golang好きな人はきっとDenoも気にいるはず！


---

## Deno君、君は意識高いキラキラ陽キャじゃない！

![](https://hackmd.io/_uploads/SkXp4lfep.png)



---

## 苦難に耐える修行僧か、ただのインテリ陰キャや！


![修行僧](https://hackmd.io/_uploads/ryiyIgfla.png =x400) ![インテリインキャ](https://hackmd.io/_uploads/ByKgJbGea.png =x400)



<!--
 
勘違いせずに席を詰めろと。

-->


---

## こういうオフラインの会で言うと、

新人の可愛いbunちゃんの隣に座りたいかもしれんが、


---

## 君の隣に座るのはgopher君だ！

あ、gopherです。隣座ってもいいですか？

![](https://hackmd.io/_uploads/S1w_ZWGlT.jpg)

<!-- 
勘違いせずに席を詰めろ！gopher君座れんやろ！
-->

---

## go君がネットでいくらディスられても同様に

2, 3年後には君もgopher君と同様の鋼のメンタルが要求される。

<!-- 
gopher君も3年前ぐらいはキラキラ言語と誤解されて、モテ屋はされて
今めっちゃ謎に雑殴りされてディスられているやろ？
-->

今のうちに先輩から心得をきておけ。
資産が多いnodejsとbunに比べて遅いから中途半端だのディスられる未来が見える。

![](https://hackmd.io/_uploads/SyoyDCSlp.png =x400)


---

## 俺たちインテリ陰キャ舐めんな！:angry: 


![チー牛](https://hackmd.io/_uploads/HJkEexMgp.png =x400)


<!-- 
多分、キラキラ技術だと思って、Deno触った人は適当に
disってnodejsか、bunに移ると思います。
-->
