  |
はてなキーワード: コメントアウトとは
最近、SNS上では「BLは性的消費なのにフェミは男性の性的表現を叩くのはダブスタじゃないか？」というスレッドがトレンド入りしていた。
だがこの議論、よく見るとアーキテクチャの層が違う。つまり、話しているプロトコルが合っていない。
オタク文化圏では、「女性が描くBL」と「男性が描く女性向け性表現」を同一のAPIとして扱う傾向がある。
しかし実際には、両者は別レイヤーで動いているアプリケーションだ。
フェミニズムの文脈で語られる「性的表象の問題」は、主に「社会的リソースの不均衡」や「ジェンダー権力の構造」についての議論であって、単なる「表現内容」の良し悪しを審査しているわけではない。
つまり、BLを「性的に描いてるからフェミ的にアウト」と言うのは、仕様書を読まずにバグ報告を出すようなものなのだ。
歴史的に男性中心に最適化されてきた社会システムに、女性視点のパッチをあてて再コンパイルする運動と言える。
だから、「男性と女性を同じように扱うべき」という一般論をそのまま適用しようとすると、互換性エラーが出る。
たとえば「女性の性的表象は抑制されるべきだが、BLはOK」とされるのは、「権力構造上の対称性が存在しない」という前提で最適化されているからだ。
一方、「普通の女性はフェミと違う」「まともな女はそんな主張しない」という定番フレーズが出てくる。
だがそれは多くの場合、ユーザーの気分を和らげるためのUX的演出にすぎない。
実際、ほとんどの人間は制度的優遇（レディースデー、女性専用車両、離婚時の親権バイアスなど）という「プリインストールされた特権OS」の上で動いている。
たとえ本人が「私はフェミじゃない」と言っても、使っているAPIがすでにフェミ思想ベースで動作しているのだ。
つまり、「私は違う」という自己申告は、ただのUIレイヤー上の装飾にすぎない。
平等を掲げるなら、優遇措置をアンインストールする覚悟が必要になる。
だが現実には、多くの人が「平等という概念を口では支持しつつ、既得権のキャッシュを維持」している。
これはエンジニアリング的に言えば、「レガシーコードをリファクタリングすると言いながら結局コメントアウトで誤魔化している状態」だ。
男女平等を“動作保証付き”で実装しようとするなら、既存の社会制度をルート権限で書き換える必要がある。
だが、ほとんどの人はroot権限を持つどころか、ユーザーレベルの設定すらいじる気がない。
もっと根本的に言えば、日本社会の多くの仕組みは、女性優遇をデフォルト設定としてビルドされている。
その構造はあまりにも自然化されていて、誰もコードレビューをしようとしない。
アンチフェミを自称する男性すら、「女性は守るべき対象」という社会的テンプレートを内面化していることが多く、それが構造の永続化を促している。
結果として、「BLは性的消費」「フェミはダブスタ」という批判は、異なるフレームワーク間の非互換問題にすぎない。
BLは「個人の妄想の自由」をレンダリングするローカルアプリだが、フェミニズムは「社会構造の更新」を目指すサーバーサイドのシステム。
同じメソッド名を呼んでいるように見えても、実行される関数の意味がまったく違う。
つまり、「BL＝性的消費」「フェミ＝ダブスタ」という批判構造は、コードのバージョンが違うままマージしようとしている状態に近い。
根本的にAPI設計思想が違うのだから、いくら議論を積み重ねても互換性は取れない。
必要なのは、「どの層で話しているのか」「どの権力構造を前提にしているのか」を明示することだ。
わかった気にさせる本が悪いとは言わないが、自分はもっと厳密に分かりたいと思っていて、それで数学書を読むんだけど、こっちはこっちで「難しい議論をしている割に言葉足らず過ぎて分かりようがない」本になっているものが多すぎて、どないしろっちゅーねんって思いになる。
中学では十分証明問題になるような命題が、なんの説明もなくこれこれが成り立つ、だから～という調子でフォローなく証明が続けられるのを見てきた。
それが許されるのなら中学生は「～相似であることを証明せよ」という問題に対して「相似が成り立つからだ」とだけ書けば正解答案として成立してしまうことになる。
思うに証明にはいかにも証明らしい言い回しや言葉以外使ってはいけないかのような暗黙の了解もあるように感じる。
その割には術語を定義したときのその概念の説明には割と自由度を持たせている傾向が見られる。
その概念が関わる具体例を使って概念の目的を丁寧に説明していることも多い。
また証明といっても対角論法の証明は初めて見る人間へのそのとっつにくさがさすがに自覚されるのかなぜ証明が成り立つのか表なりを書いてイメージの力の存分に援用するもうちょっとカジュアルな内容になっていることがある例外もある。
しかしほとんどの場合そういった態度が証明(モード)では見られない。さらっと済まされてしまう。
計算問題では途中式の前後でも自由につまづきやすいポイントを解説した文章が挟まれたりするが、証明問題の解説は模範解答でもって代えていた記憶がある。
つまり模範解答の文章が難しく感じる人にとってはもうその解答を暗記するしかない。論語の丸暗記みたいなもの。
そのままテストとかで通用するようにそういうような解答になっているのだろうか。
数学書も論文として書いて格好悪くないものを、なんていう数学の本質ではないことに配慮して「真似るべきもの」としてそういうスタイルで証明を記述しているのではないかと思える。
であるなら、証明全体が一番目の文、二番目の文…というふうに出来ていたとして「(一番目の文)と書けるのはこれこれがこのような理由で成り立っているからです。しっくりこない人のためにこの理由をさらに掘り下げると～のようになっています。よって(数式)を証明の最初に書くことになります。次に～なのでこの式が二番目に来ることになります～」という解説ではダメなのだろうか？
またこの解説はそのまま証明の一つの形にもなってないのだろうか？
そもそも証明とは万人にその事実が成り立つことを理解できるような形で書かれたものを言う。
一部の人にとって意味も分からず丸暗記するしかないようなものはもはや証明の本来の目的を満たしていない。
オーソドックスな証明を構成する文の全てが含まれてさえいるなら、それの言わんとすることをさらにわかりやすく説明した肉付けの部分が加わった上記のような形の解説も証明の一つの形としていいのではないか。
それをしていいという感覚がないことが世の中の数学書の証明が言葉足らずになっている一因になっているのではないか。
もしそれが蛇足で証明全体の厳密性を損ねるというのなら、コメントアウトのような記法を使えばいいと思う。
//これの言わんとするところは～
とか、必要に応じて
式//<は～
みたいな書き方をするとか。二番目の例はサクラエディタで一文が続いているときに折り返しで便宜上改行されていることを示す記法を参考にした。
証明が長くなりすぎてその始まりと終わりが分からなくなるという懸念については既に証明の行頭のさらに横の余白に記号をつけて開始や終了を示すようにした数学書は存在するのでそれを他の数学書も参考にすればいい。
そもそも自然言語で書いている時点で完全な厳密性は諦めているわけなので、厳密だなんだと言うのはよりわかりよく書くことに対する言い訳にはならないと思う。
かといって従来の証明の構成要素を押さえた書き方なのであれば、それは一般書籍にあるような「わかったつもりにさせる文章」というのとも一線を画す。
数学の証明を完全に厳密に書こうとするとブルバキの数学原論やラッセルのプリンピキアマセマティカみたいになってしまい、後者は数学者には読む価値の無い本とされているし、前者にしても30年以上かけて刊行し続けて今だ数学の興味ある話題には到達できていないということになっているということから、数学書は省略するということが好まれるらしい。
でも既に数学基礎論レベルの厳密さを求めてはいない一般的な数学書の証明レベルの厳密さにわかるやすさという要素を足し合わせたところで、原論並みに極端に嵩が増すということにはならないと思う。
自分で考えないとその概念とかが身につかないから省略しているという反論に対しては、逐一圧倒的な量の具体例を持ち出すことで十分に補えるのではないかと思える(それでもメリハリをつければ原論ほどのボリュームにはならない)。
数学書は本当にチンプンカンプンな状態の本も多いので、考える力を身に着けさせるとか以前に、もっと理解できるような教えを工夫することに焦点を当てるべき。
考える力だろうがなんだろうが、そもそも書いてあることがわかんないってような構成の本ではしょうがないと思う。
コストがかかる割に日本語というローカライズされた市場で本が少しでも分厚くなるようなことはコストが回収できなくなるから避けたいという考えもあるのだろうが、それこそよほどの天才じゃなければはっきり言語化しないだけで私のような考えをしたことがある人はむしろ大半を占めていると思うし、比較的私の考えと同じ考えを持っていそうな裳華房の手を動かして学ぶシリーズがその出版社内のランキング上位を占めていた。
言葉足らずな数学書がまだまだ多い状況ではむしろどこぞのwebデザインの本のように何万部と売れるチャンスがごろごろ転がっているんじゃないかな。
わかりやすい解説が証明の一つの形として通用するようになれば、中高での試験答案においても純粋数学の論文でもそういう文章を証明として書いていいことになるのだから、参考書や数学書の証明部分も丸暗記するしかないようなわかりにくいものではなくなると思う。
https://id.fnshr.info/2017/12/10/polite-proof/
というジョーク記事があるけど、挨拶から書くとかは全く数学的な主張の分かりやすさにはつながらないから意味がないとしても(とはいえ親しみやすさもわかりやすさにつながることを完全否定もできないんだけど)根っこの部分ではもしかすると書き手は私と同じ問題意識を持っていたのではないかと感じさせる。
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250804185908# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaJCEcQAKCRBwMdsubs4+ SCv6APwPYZCxOIzijneKHMK5c+nrqS0YImv/gOsxm5/ERhIiXAD9EtAaFU6CTO3D UJ81tuHO6vv/pHwbom0ytd9gthgsPwU= =6OiQ -----END PGP SIGNATURE-----
昔の慣習に倣ってコメントを丁寧に書く人がいまだに居るけれど
以前のコードをコメントアウトしているようなソースは論外として
例えばメソッド・関数の頭にそれが何をする関数なのかを書いている人が多いけれど
メソッド名や引数名、戻り値の型をキッチリ付けておけば分からないことなんて無い
それ以上の複雑な処理をするなら機能分解するべきだし名前を付けにくい処理の場合はそもそもの設計がおかしい
昔は便利なIDEが無かったので変数や関数の名前に長い名前を付けると実装が大変で
仕方なくx1だとかval2だとかを使って実装してたのでコメントに書いておくようなこともあったけれど
Copilotを使える時代にコメントを書く必要なんて皆無だし
仮に意味が分からないコードがあってもCopilotに聞けばいいのでやっぱりコメントは必要ない
コメントがあった方が良い場合は「この実装はこのアルゴリズムに基づいて実装している」とURLのリンクを貼ったり
「この規則があるのでこういう実装をしている」とRFCを貼ったりするとかはあるけれど
それもほとんど変数名だとかで解決できるし、あっても1行で終わるレベル
そういう実装全体の設計に関するような話はReadmeに書けば良いのでソースコード内のコメントとしては必要無い
「それでも無いよりはいいでしょ？」みたいに言う人いるが逆に問題になることも多い
コメント内容と実装が違う場合にどっちが正解なのかが分からなくなったり
ソースコードの修正に対してコメントが修正されていなくて後々で揉めたりする
当然ながらコメント部分にはLintが効かないので（ChatGPT使えば作れそうな気もするが）
チェック内容も増えるし良いことがほとんどない
ヤバいJTCとかは「各行にコメントを書いて下さい」とか言ってきて正気の沙汰じゃ無い
まぁそういう案件が来たらChatGPTに丸投げするとは思うけれど下手すると「Copilot禁止」とかも言い出しそうだな
書いたところで誰も読まないのにアホすぎる
このAI説明が正しいならデバッガーが不要と言ってる、って話はかなり違うよな。
ここで書かれてるレベルのことは事前の取り決め等で発生を未然に防げることでしかないので、つまりブルシット・ジョブの人が言いたいのは
発生が十分に予想される問題に対して対策可能であるにも関わらず何の対策もしないことによって不要な仕事が発生している、という話でしかなくデバッガーが不要という話では全くないよな。
スパゲッティコード: 構造が複雑で理解しにくいコードは、バグの発見や修正が困難となり、多くの時間を費やすことになります。
コメントアウトされたセクション: 使用されなくなったコードが適切に削除されずに残っている場合、コード全体が読み解きにくくなり、メンテナンス性が低下します。
一貫性のないコーディングスタイル: チーム内でコーディング規約が統一されていない場合、コードの可読性と保守性が著しく低下します。
人類学者であるデヴィッド・グレーバー氏は、現代社会において多くの仕事が無意味であり、社会にとって価値を生み出していないと主張しています。2018年に出版された著書『ブルシット・ジョブ：クソどうでもいい仕事の理論』の中で、彼はこのような「ブルシット・ジョブ」の存在について論じています。
グレーバー氏は、以下の特徴を持つ仕事が「ブルシット・ジョブ」であると提案しています。
企業法務、テレマーケティング、広報、一部の管理職などが、「ブルシット・ジョブ」に該当する可能性があります。これらの職業は、必ずしも社会に貢献していないと断言することはできませんが、その価値が明確に見えにくい場合が多いと言えます。
粗雑なコードを修正するプログラマーは、「尻拭い」のカテゴリーに分類される可能性があり、以下のような問題に直面しがちです。
このような状況下でプログラマーは、本来創造的な活動であるはずの新しい価値を生み出す作業ではなく、過去の過ちの修正に追われることになります。これは、ソフトウェア開発プロセス全体に大きな問題があることを示唆しています。
複数の機能で成り立っている長いコードを分割して実装することののメリット/デメリットを教えてほしいです。
「コードの分割」が指してることを大まかに言うと、「メインの関数は各機能を呼び出すだけで、実際の機能の部分はサブルーチンとしての関数(って表現が正確かも謎)に持たせ、サブルーチンを順次呼び出すことで総体としての機能を成す」ような方式にするってことです。
より具体的に言うと、1.データの取り込み2.取り込んだデータの突合3.帳票の出力の3手順を別々の関数とし、メインの関数から1,2,3の手順の関数を順次呼び出すという具合です。
上記の方法と、全ての機能を詰め込んだ一つの長い関数にする方法と、どちらが結局よかったのかなと思っているんですね。
今のところ私は自分のわかりやすさのためにコードを分割する書き方をしています。理由は、1機能1関数で分けておいた方がステップインじゃないですけど「ここまでは完走できた」の切り分けがしやすいのかなーと思うのが一つ。もう一つは単純に上下に長くなっていくとどの変数がどれでと特定していくのが辛いってのがあるためです。
ただこの方法にも問題があると思っていて、一番はメイン/サブ関数間で右往左往するので今やってる工程が何なのかがよくわからん、他人が読むならなおのこと、ってことです。一応の対処として、メインの関数は目次的に「総体としてこのような機能を持っている、また分割した関数の機能はそれぞれこうである」とコメントアウトし、サブの関数にも「この関数はここからここまでの作業をします」とコメントアウトすることにしています。
あとは関数ごとに変数をいちいち定義し直すのがだるいみたいなのもありますね。グローバル変数は後々の修正とかのために使わないようにしています。
自分では思いつけてない部分でコード分割することのやばみってあるのかなーと思ったので質問させていただきました。近々退職する予定なので、他人への引継ぎって観点からどうなのかなと思っています。
以下自分語りです。語彙とか概念のインストールが足りないと適切な調べ方ができなくて困るんですねー。あと問題があることを認識できなかったり効率悪かったり車輪を再発明したりとか。
私は無学のバイトなんですが、あるとき上長から「暇なら適当にエクセルでも勉強しといて」と漠然と言われて、このVBAっちゅうもんを学べばええんか？と勘違いしたのが始まりでした。本当はセルの結合とか別のセルを参照するとか、エクセル方眼紙的なものをある程度作れるようになってほしかったらしいです。折角なのでなんとか役に立つものをと思って、ある集計作業を自動化させたところ、今後も暇なときはよろしくということになりました。
いろんなものを作りましたが何をどのように作るかから、その後の運用保守までほぼ一任してもらって大変面白かったです。しかしなにぶん仕様や実装方法について相談できる方がおらず全ては私の泥縄式学習術によって成り立っているという恐ろしい状態でした。体系的な知識や組織の経験知みたいなものが一切ないので自分がどこにいるのか、努力の方向性が合ってるのかも結果が出るまでわからない。先達のあらまほしきことなり。
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドはAWS EC2で動作しているがログインアカウントは共通化されていてパスワードを全員で共有している
ユーザーを追加しようとしたら「そのような勝手な行為はセキュリティ上許可されていません」とのこと
本番環境とStagingはインスタンスが分かれているが運用は同じ方法
Staging上で5人ぐらいが作業しているが、ホームの下にそれぞれのユーザーが自分の名前でディレクトリを作って作業している
バックエンド側のシステムは詳細は伏せるが、某システムで動いている
仮にNode.js系だとすると、package.jsonがあってnpm run installでインストールするのだが、普通にインストールしようとするとエラーになる
内容は依存関係で失敗しているのだが、本番も同じソースで動作している
動作させるにはnode_modulesをまるっとコピーして、とのこと
さっきの自分の名前のディレクトリ配下にコピーしてきて、適当なポート番号でサーバを立ち上げれば一応は動く
このため、新しいモジュールを入れようとすると依存関係で失敗するため、便利なモジュールがあってもインストールできないし
セキュリティアップデートも当てることはできない（現にバージョンがすごく古い）
ソースコードはGitHub管理されているがセーブポイント感覚でcommitされているのでコミットログを見ても何が起きているのかさっぱり分からない
おまけにPRも使わずにmainにマージしまくっていてわけがわからない
加えてソースコードはコメントアウトの嵐でどこに何が書いてあるのかさっぱりわからない
データベースはPostgreSQLだが山ほどテーブルがあるのに外部キー依存は入っていないしVIEWも作られていない
まぁ、他にもテーブルを見ていくとアンチパターンのオンパレードで、EAV、ジェイウォークあたりは確認できたしHTMLやSQLが格納されているテーブルも見つけた
ソース上でクエリを作ってAPIを作っているが、ザッと見ただけでもインジェクションし放題の状態になっていた
フロントエンドも詳細は伏せるが、いわゆるReact的なものを利用している
こちらは npm run installでインストールできるし npm run devでちゃんと動く
ただ前述の通りバックエンドはローカルで構築できないのでEC2を利用するしかなく、CORS対応のためのプロキシを自前で用意する必要があった
バックエンド同様にGitHub管理されているが、管理しているだけ
バックエンドは5人ぐらいが利用しているが、ソースコードを編集するのは実質1人なのでコンフリクトはほとんど起こさないらしいが
フロントエンドは5人ぐらいが編集するのでコンフリクトしまくっている
解消するときにデグレすることが日常茶飯事でその都度Hotfixしている
コードもコメントアウトだらけなのに加えて、不必要なコードが大量にあるので可読性が著しく低い
（難しい処理を読み解いて追いかけていったら最終的に使われていない、などが大量にある）
2000行ぐらいあるコードとかChatGPTに突っ込んだら20行ぐらいになる予感がある
また、DBがご覧の状態なので取得されるデータも全然抽象化できておらず、コードが膨れ上がっている
例えばProductの一覧データをサーバから取得して、ユーザーがクリックしたProductをCartに投入するのだが、投入する情報はProductではなく、CartItemにする必要があるし
OrderするときはOrderItemにしてAPIを叩く必要がある
ほとんど同じ情報なのだが微妙に変わっていたりKey名が違っていたりするのでそれぞれ変換する
他にも数え上げればキリがないが、コピペして少しだけ改変している部分などが大量にあってバグがあるのかどうかすら判別できない
DBにHTMLやSQLが入っていると言ったが、調べて見るとDBから取得したHTMLをそのまま埋め込んで表示していたりした
SQLについてはフロントエンド側でSQL生成しており、そのテキストをAPIに送り込んでサーバ側で実行して貰った上で格納とかしていたので
「ここにDROP TABLEとか書けばTABLE消えるんですか？」
と聞くと
とか言われたのでことの重大さを伝えたが、まだ対処できていないようだった
認証等はOAuth2を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
社内でエクセルのおじさんをやってる。
社長がケチで、絶対にサポートがちゃんとついてる既製品のシステム入れたほうが最終的に安いのに
ワイにエクセルで作らせればタダという謎理論で社内のほぼすべてがエクセルで構成されている。
そんな恐怖の会社に勤めている。
ワイも元々は零細ソフトハウスに勤めていたのだが終電徹夜徹夜終電徹夜徹夜徹夜の生活に疲れて退職。
元々のライン工みたいな仕事をしていたが、社長が「お前エクセルのプログラムできるのか」と言い出し
できますと答えたところ、社内の煩雑な業務のあれこれをマクロ化することになった。
現場の人間が「今はこういう処理を手入力してるんだけど自動化したい」みたいな感じで持ってくるので
とりあえずそれに着手する。
うちの会社にその仕事の適正な工数が分かる人間がいないのでめちゃくちゃ楽なペースで仕事をしている。
で、それを作りながら「どうせこういうことも言うてくるやろなぁ」と想定し、
拡張性を持たせるというか、もう機能作っちゃっといてコメントアウトして納品する。
で、まぁ「こういう機能もほしい」って言ってくるので「ちょっと時間がかかる」つって
適当な日数、増田したりいもげしたりして時間を潰して、コメント外して納品する。
動いた参考例
10-12行目の以下、「...」を「diffusers.」に
from ...models import AutoencoderKL, UNet2DConditionModel
from ...pipeline_utils import DiffusionPipeline
from ...schedulers import DDIMScheduler, LMSDiscreteScheduler, PNDMScheduler
13行目の以下、先頭に#でコメントアウト
from .safety_checker import StableDiffusionSafetyChecker
safety_checker: StableDiffusionSafetyChecker,
35行目の以下、先頭に#でコメントアウト
safety_checker=safety_checker,
164行目の以下を
return {"sample": image, "nsfw_content_detected": has_nsfw_concept}
以下にする
return {"sample": image}
エンジニアリング未経験者を採用して失敗する例もあると思うが、俺の場合は低レベルエンジニアばかりのところに参画して失敗した。
なので、その会社（チーム）も当然にレベルが高いと思っていたんだが全くそんなことがなかった。
かろうじて動いているようなコードが積み上がっており、たまに動かない時があると「アタリ」をつけてコメントアウトしてスキップして動いたからOK、みたいな感じのコードや運用が積み重なっていた。
コードの静的解析やフォーマットも行われておらず、記述がバラバラ。
ライブラリや言語のバージョンも古く、deprecatedやobsoletedな記述が残る。
「人材が不足しているから、経験者である増田くんに是非ジョインして欲しい。言語は**で、これこれこういうことがやりたい。」ぐらいのレベルまでしか話せてなかった。
RStudioがPC内から気がついたら消滅していたので何回もやり直すのが面倒で書いた
コメントアウトをいじればFedoraやmacOSでも動くと思う
https://pastebin.com/HiPqLVq7 (6/4 shコマンドでも動くように修正 以前はbash hogehoge起動していたので動作確認していなかった)
エラーでここに貼れなかった
util-linux(rev) libxml2-utils(xmllint) gpg curl coreutils(sha256sum)とR関連
echo "$HTML" | xmllint --nowarning --xpath hogehoge --html - | hogehoge
こうしないとxmllintがエラーでhtlmなどをうまく読み取らない
sed 's/href="//g;s/"//g;s/\s/\n/g;s/^.?$//g;s/^\n//g'
href="hogehoge"の形で出てxmllint内で除去出来なかったのでsedで妥協
hrefが1回しか出ないのでひとまとめにできそうだが面倒なので分けた
この書き方なら複数回出ても除去できるはず
先頭の謎のスペースの除去が面倒だった
echo "$HASH" "$FIELNAME" | sha256sum --status -c ;echo $?
スペースが2つないと書式で怒れられてハッシュ値が合っていてもsha256sumが終了ステータス0で正常終了を返してくれない
VScodium
ShellCheck
https://open-vsx.org/vscode/item?itemName=timonwong.shellcheck
XPath Helper
https://chrome.google.com/webstore/detail/xpath-helper/hgimnogjllphhhkhlmebbmlgjoejdpjl
zenn.devに書こうか迷ったがどちらの方が良かったのだろうか…
ダウンロードしたサーバーがやられてるならハッシュ値も改ざんするだろうgpgで確認しないと意味ないでしょとかsudoでやったらディレクトリがとか色々ガバあるから誰かいい感じに改良して
https://cran.rstudio.com/bin/linux/debian/
https://www.rstudio.com/code-signing/
